[vortex] Problem with built-in dual 3c982, Dual AMD S2462 MB.
Heflin, Roger A.
Roger.A.Heflin@conoco.com
Fri Jan 18 15:28:01 2002
Update,
We have confirmed that noapic is now turned on, noapic did
improve things, it appears that the situation is probably 10
times better, but is still a significant problem.
If someone with proper skills is willing to try to work on the
problem, I can probably have a machine of the proper type
and configuration sent to do the debugging/testing on,
and then have us pay the return shipping when the issue
has been figured out.
Other funding arrangements may be possible as
needed to get the problem quick resolved.
And from what I can tell all of the recent tyan dual
cpu AMD boards S2462 with the 3com's on them
seem to do this. I have a very large number of
the machines (100+) and the all appear to
have the issue, or at the very least alot of them
appear to have the issue.
Roger
> -----Original Message-----
> From: Heflin, Roger A.
> Sent: 1/ 18/ 2002 12:27 PM
> To: Bogdan Costescu
> Cc: vortex@scyld.com
> Subject: RE: [vortex] Problem with built-in dual 3c982, Dual AMD
> S2462 MB.
>
> We have updated our lilo version, and this does set noapic correctly.
>
> Before when doing cat /proc/cmdline the line was cutoff early and had
> cut the noapic and at least part of 1 other option.
>
> The noapic test is in process (with the original 99Uc driver), and so
> far
> looks like it works correctly.
>
> I will update when all of tests get finished.
>
> Roger
>
> > -----Original Message-----
> > From: Heflin, Roger A.
> > Sent: 1/ 18/ 2002 9:06 AM
> > To: Bogdan Costescu
> > Cc: vortex@scyld.com
> > Subject: RE: [vortex] Problem with built-in dual 3c982, Dual AMD
> > S2462 MB.
> >
> >
> > Apparently we were not running noapic on the test machines.
> >
> > Lilo or the kernel cut the kernel boot line at 80 chars or so and
> cut
> > off
> > noapic and apparently also cutoff part of our serial port speed (115
> > baud
> > vs. 115200 baud), we had noticed that the boot across the serial was
> > slow
> > but had not put our fingers on why. We are investigating how to
> > correct
> > this feature.
> >
> > And your assertion does agree with out new test data, the machines
> > still
> > lose their networking, just not nearly as quickly as before.
> >
> > Roger
> >
> > > -----Original Message-----
> > > From: Bogdan Costescu
> > [SMTP:bogdan.costescu@iwr.uni-heidelberg.de]
> > > Sent: 1/ 18/ 2002 7:22 AM
> > > To: Heflin, Roger A.
> > > Cc: vortex@scyld.com
> > > Subject: RE: [vortex] Problem with built-in dual 3c982, Dual AMD
> > > S2462 MB.
> > >
> > > On Wed, 16 Jan 2002, Heflin, Roger A. wrote:
> > >
> > > > Jan 16 13:25:57 poeplx1008 kernel: eth0: Interrupt
> posted but
> > > > not delivered -- IRQ blocked by another device?
> > >
> > > That's the problem: an interrupt gets lost. That's consistent with
> > > your
> > > observations on increasing Tx timeout and Tx ring size. I'm
> actually
> >
> > > surprised that the "noapic" didn't help. Could you make sure that
> > it's
> > >
> > > really running in "noapic" mode by making sure that
> /proc/interrupts
> > > only
> > > contains "XT-PIC" entries ?
> > >
> > > The problem is that because of the Tx interrupt mitigation,
> > sometimes
> > > a
> > > full Tx ring waits for one interrupt to free it all. If this
> > interrupt
> > > is
> > > lost, the Tx timeout occurs. By increasing the Tx ring size you
> are
> > > not
> > > solving the problem, just decreasing the probability of happening.
> > >
> > > I still wonder what's the difference between using 905C and 982...
> > >
> > > --
> > > Bogdan Costescu
> > >
> > > IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen
> > > Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY
> > > Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868
> > > E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De
> > >
> > _______________________________________________
> > vortex mailing list
> > vortex@scyld.com
> > http://www.scyld.com/mailman/listinfo/vortex
> _______________________________________________
> vortex mailing list
> vortex@scyld.com
> http://www.scyld.com/mailman/listinfo/vortex