Date: Thu, 5 Jun 2003 14:35:28 -0700 (PDT) From: Nate Lawson <nate@root.org> To: Shaun Jurrens <shaun.jurrens@skoleetaten.oslo.no> Cc: Palle Girgensohn <girgen@pingpong.net> Subject: Re: fxp0: device timeout | SCB already complete (me too) Message-ID: <20030605142931.F28156@root.org> In-Reply-To: <20030605212011.GQ98443@nevada.skoleetaten.oslo.no> References: <20030603152123.GM98443@nevada.skoleetaten.oslo.no> <20030605091532.GO98443@nevada.skoleetaten.oslo.no> <20030605212011.GQ98443@nevada.skoleetaten.oslo.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 5 Jun 2003, Shaun Jurrens wrote: > On Thu, Jun 05, 2003 at 09:56:27AM -0700, Nate Lawson wrote: > #> On Thu, 5 Jun 2003, Shaun Jurrens wrote: > #> > On Wed, Jun 04, 2003 at 06:32:46PM +0200, Palle Girgensohn wrote: > #> > #> Hi Shaun, > #> > #> > #> > #> Thanks for the input! Glad to hear I'm not the only one > #> > #> > #> > #> In my case, both the SCSI and NIC are integrated on the motherboard, so I > #> > #> cannot really move them around... :) > #> > #> > #> > #> Also, as I mentioned, I tried a de0 (PCI card, not onboard, and it > #> > #> literally stopped the machine). Is the de0 driver also a problem? > #> > > #> > Jun 4 16:57:50 nol33n0x /kernel: fxp1: SCB timeout: 0x80 0xe0 0x50 0x0 > #> > Jun 4 16:57:51 nol33n0x last message repeated 4 times > #> > Jun 4 16:57:58 nol33n0x last message repeated 3 times > #> > #> This doesn't mention SCSI anywhere. Your problem is almost certainly a > #> PCI/interrupt problem. I'm redirecting this thread to -stable. > > I found the printf finally in /usr/src/sys/dev/fxp/if_fxp.c . > Excuse the -scsi pollution. I've just seen the combination > very often of an ahc controller and the fxp nic being at the > scene of the problem, even from others on IRC. That's understandable. > #> I got panics on boot with my BP6 (SMP) when I had an ahc controller in a > #> PCI slot that didn't support bus mastering. I suggest you do what the > #> above message says and try different combinations of cards in slots (i.e. > #> keep removing one until you no longer get the messages and move around > #> which slot is free). This will help people track down the problem. Also > #> get your mobo manual and check if any slots force interrupt sharing or > #> don't support bus mastering. > > Since I wrote the original message, it's something I've had to > do an incredible amount of, quite frankly. In fact, so much that > it can't be normal. An identical box running linux with 8 nics, > 2 of which are dual intel nic's has no problems whatsoever. The > generic 3com (xl) nic's don't display this problem either. > > Either the 3com's are more generous in what they accept for > interrupt routing or DMA failures, or the fxp driver is a > little b0rked somewhere. I expect the problem is one or more of the following: deficiencies in our PCI subsystem and/or deficiencies in the fxp driver coupled with potential quirks in your motherboard. Note that I am not saying your mobo is at fault, just that it is probably what is revealing the issues in FreeBSD. > To the best of my knowledge, this > began late last year. I wish I had some more modern hardware and > some decent Serverworks boards to work on, but that stuff only > sees windblows terminal servers here. I'll see if I can track > this down somehow, but my time, like the rest of yours, is limited. > I'm trying to keep this show running on a rubberband and a > shoestring. It would help if you found exactly the minimal hw combination to trigger it (i.e. "no PCI cards except for one fxp each in slot 4 and slot 5"). Then, find out why slot 4 and 5 are special on your mobo. In parallel, you should use cvs -D to work back to the particular fxp or pci commit that broke your system. -Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030605142931.F28156>