Subject: kern/31455: ex (905[BC]) cards can hang in -current kernels
To: None <kern-bug-people@netbsd.org, gnats-admin@netbsd.org,>
From: None <kre@munnari.OZ.AU>
List: netbsd-bugs
Date: 10/03/2005 14:34:00
>Number:         31455
>Category:       kern
>Synopsis:       ex (905[BC]) cards can hang in -current kernels
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Oct 03 14:34:00 +0000 2005
>Originator:     Robert Elz
>Release:        NetBSD 3.99.8  (-current from a couple of days ago)
>Organization:
	Prince of Songkla University
>Environment:
System: NetBSD delta.noi.kre.to 2.0.1 NetBSD 2.0.1 (DELTA-1.11-20050129) #1: Sat Jan 29 15:31:14 ICT 2005 kre@lilac.noi.kre.to:/usr/obj/2.0/kernels/DELTA i386
	That's my laptop I'm using for send-pr, and isn't relevant...
Architecture: i386
Machine: i386
>Description:
	It is possible to cause an XL variety ex card (905B or C I think
	that means, though PC hardware naming is beyone by ability) to
	cause the kernel to loop.
>How-To-Repeat:
	DOn't know to to force it, but sending enough traffic at a half
	duplex 100Mbit/sec ethernet connected to an appropriate card does
	it for me fairly quickly (about a minute of two at most).
>Fix:
	No direct fix, I'm not sure what you want to do.   But the
	problem was caused by rev 1.27 of elink3reg.h which changed
	the value of TXS_COMPLETE from 0x80 to 0x8000.

	Unfortunately, ex_txstatus() in elinkxl.c wasn't updated to
	match, and texts TXS_COMPLETE against a value that is only 8
	bits wide (that's the kind of programming error that diagnostics
	in gcc could usefully detect, rather than some of what they
	currently complain about...)

	You can see this by inspection once you know to look.   I am surprised
	this has not been reported before, I see now, that this change was
	made in August last year, not this year (as I thought when I just
	posted about this to current-users)

	Whether the fix is to go back to 8 bit operations, to somehow change
	elinlxk to use 16 bits (the register definitions seem to suggest an
	8 bit register, the offset is 1B - but I do not have the data sheet)
	or to simply split more of the xl code from the elink3 code, and
	use different constants for the bits in this register I have no idea.

	But I'm sure someone who does know can and will fix it soon.   If
	you let me know (via private mail not cc'd to any NetBSD list)
	when that has been done, I can test it easily...