NetBSD Problem Report #27299

Received: (qmail 24171 invoked by uid 605); 19 Oct 2004 08:14:33 -0000
Message-Id: <20041019081432.058012523A0@narn.netbsd.org>
Date: Tue, 19 Oct 2004 08:14:32 +0000 (UTC)
From: rkr@olib.org
Sender: gnats-bugs-owner@NetBSD.org
Reply-To: rkr@olib.org
To: gnats-bugs@gnats.NetBSD.org
Subject: ne(4) broken for me
X-Send-Pr-Version: www-1.0

>Number:         27299
>Category:       kern
>Synopsis:       ne(4) broken for me
>Confidential:   no
>Severity:       critical
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Oct 19 08:15:00 +0000 2004
>Closed-Date:    
>Last-Modified:  Sun Apr 13 05:09:21 +0000 2008
>Originator:     Richard Rauch
>Release:        NetBSD/i386 2.99.9
>Organization:
n/a
>Environment:
Can't produce it here, sorry.  Ask in followup, but it's a vanilla 2.99.9 body of sources except for the if_pcmcia_ne.c and ne2000.c files that were updated within the past few hours---and a kernel config slightly modified from GENERIC_LAPTOP.

>Description:
Under NetBSD/i386 1.6, I formerly received these messages (typed
manually) during boot:

ne0 at pcmcia0 function 0
ne0: LAN iobase 0x300 (0x4300) -> 0x300
ne0: Melco LPC3-TX (AX88190) Ethernet
ne0: Ethernet address 00:02:dd:77:2b:1d
 [...]
ne0: LAN iobase 0x300 (0x4300) -> 0x300

(The latter was printed when the device was actually configured.)

In order to get that I had to introduce a hack (see PR kern/18359),
but after the hack, it worked.  Without the hack, the device would
fail to attach correctly during boot.  Since the former PR was closed
and stayed closed despite followup on 2004 09 03 (accidentally not
appended to the formal PR audit trail until a little around Oct. 10),
I am opening a new report.  The behavior is very different than the old
bug, though it may still be in some way related to peculiarities of
my card.  Anyway:


Sometime over this past summer, the driver was reorganized and my hack
no longer applies.  Nor does the vanilla device work---now, rather than
failing to attach (the problem in 1.6), the device probes and attaches,
but does not function.

The new messages are of the form:

ne0 at pcmcia0 function 0: <PCMCIA, 10/100 Ethernet Card, , >
ne0: Ethernet address 0a:00:0a:00:0a:00
 [...other devices...get down to network config in /etc/rc*...]
ne0: remote transmit DMA failed to complete
ne0: remote transmit DMA failed to complete
 [...more of these...]
ne0: device timeout


Note especially the botched ethernet address.  I didn't notice that
until typing this report.

I assume that this is not related to the reported general PCMCIA
problems in 2.0, since this has been biting me for a couple of
months.
>How-To-Repeat:
Using a suitable[*] ne(4) based ethernet device, attempt to boot with
a current kernel.


[*: If you are in Houston (or perhaps as far away as Austin, especially
    if you have a spare beer..?  (^& ) and have a PCMCIA slot, I'm
    happy to lend you my card for short periods.  However, the card
    is usable with a NetBSD 1.6-current (1.6ZC), and I have
    occasional need of the laptop with ethernet support---nor do I have
    any other Ethernet options for it.

    It is possible that other PCMCIA ne(4) cards have the same problems.]

>Fix:
None known.

No known workaround.

>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->feedback
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Sun, 06 Apr 2008 03:01:26 +0000
State-Changed-Why:
Does this work any better in -current? If not, what do the symptoms now look
like?


State-Changed-From-To: feedback->open
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Sun, 13 Apr 2008 01:50:45 +0000
State-Changed-Why:
feedback mail bounced


Responsible-Changed-From-To: kern-bug-people->dholland
Responsible-Changed-By: dholland@NetBSD.org
Responsible-Changed-When: Sun, 13 Apr 2008 01:51:15 +0000
Responsible-Changed-Why:
I want to look at this a bit, because I was just digging in the pcmcia ne
probe code recently.


Responsible-Changed-From-To: dholland->kern-bug-people
Responsible-Changed-By: dholland@NetBSD.org
Responsible-Changed-When: Sun, 13 Apr 2008 05:09:21 +0000
Responsible-Changed-Why:
I'm reasonably certain this is a manifestation of kern/32938. The card is
an AX88190; there used to be code for such cards to frob the iobase to
what the pcmcia subsystem was expecting. The 1.6 hack bypassed the test
that checked whether that frob succeeded; in the 1.6 world apparently that
made the card work, but in 2.0 and later it doesn't. Nowadays that code is
not there anymore; instead there's a test in the attach logic marked "This
is highly bogus." Once 32938 is sorted out, that test probably needs to be
removed, and then maybe it'll work... if I understand all this correctly,
which is an open question.

In any event, this is as far as I can take it.


>Unformatted:

Home	PR Database Search