fxp0: device timeout | SCB already complete (me too)

[Nate Lawson]

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