freebsd stable - Jun 2003 - fxp0: device timeout | SCB already complete (me too)

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?
>
> 	I'm beginning to think it's a scsi problem of sorts as well so
> 	I clipped -hardware and Cc'd -scsi on this. I just happed to
> 	(unfortunately) run into this on another box yesterday after
> 	four months of relative quiet. I happened to be moving an
> 	interface over from some crap Nortel switch to a nice Cisco
> 	switch and promptly a different interface began to do it's dance.
> 	It's the same interface each time (and I've changed cards...)
> 	Anyway, for the record, a little from messages:
>
> Jun  2 18:48:43 nol33n0x /kernel: fxp0: Microcode loaded, int_delay: 1000
usec
> bundle_max: 6
> 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:51 nol33n0x /kernel: fxp1: SCB timeout: 0x80 0xe0 0x50 0x400
> Jun  4 16:57:58 nol33n0x /kernel: fxp1: SCB timeout: 0x80 0xe0 0x50 0x0
> 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.
> #> >The only suggestion I can offer at the moment is to try various
card
> #> >placements over your PCI slots. I've found stability using
one of the
> #> >first two slots for my Adaptec controller (2940U[2]W, 29160[N])
and the
> #> >rest for the Intel nics.
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.

-Nate

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.
#> 
#> > #> >The only suggestion I can offer at the moment is to try
various card
#> > #> >placements over your PCI slots. I've found stability
using one of the
#> > #> >first two slots for my Adaptec controller (2940U[2]W,
29160[N]) and the
#> > #> >rest for the Intel nics.
#> 
#> 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 won't rule out that PC hardware sucks,
	etc., because I've worked on enough of it to already know that.
	BIOS's have been updated or not, same problems show up on at 
	least 3 different mainboards from two different manufacturers on
	both VIA and Intel chipsets.  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. 
#> 
#> -Nate

-- 
Med vennlig hilsen/Sincerely,

Shaun D. Jurrens
Drift og Sikkerhetskonsulent
IKT-Avdeling
Oslo Skoleetaten

gpg key fingerprint: 007A B6BD 8B1B BAB9 C583  2D19 3A7F 4A3E F83E 84AE
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url :
http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20030605/f94e5a62/attachment.bin