Subject: Re: NetBSD RC3 and my laptop.
To: Richard Rauch <rauch@rice.edu>
From: Chris Gilbert <chris@dokein.co.uk>
List: port-i386
Date: 09/12/2002 08:56:32
----- Original Message -----
From: "Richard Rauch" <rauch@rice.edu>
To: "Chris Gilbert" <chris@dokein.co.uk>
Cc: <port-i386@netbsd.org>
Sent: Thursday, September 12, 2002 3:20 AM
Subject: Re: NetBSD RC3 and my laptop.


> > ----- Original Message -----
> > From: "Richard Rauch" <rauch@rice.edu>
> > To: <port-i386@netbsd.org>
> > Sent: Tuesday, September 10, 2002 9:43 AM
> > Subject: NetBSD RC3 and my laptop.
> > >
> > >  a) I canNOT seem to access my ethernet at all with either of these
> > >     1.6 kernels.  I haven't tried building a custom kernel.
> > >     (Maybe I needed to warmboot 1.6 GENERIC a second time; but
> > >     GENERIC_LAPTOP put the card at ne0; it just failed to support it.)
> >
> > Looks to be nearly right
> >
> > Where did you get the GENERIC_LAPTOP kernel from?  Self built or from
> > somewhere else?
>
> I just downloaded GENERIC and GENERIC_LAPTOP from the pre-release site
> (releng?  whatever) and put them on my root filesystem to see how they
> booted.  So that's what a user with a comparable computer could expect to
> see when installing NetBSD/i386 1.6 RC3.
>
>
> > > ne0 at pcmcia0 function 0
> > > ne0 (manf 00008a01 prod 0000c1ab) cis PCMCIA 10/100 Ethernet Card:
can't
> > match ethernet vendor code
> >
> > a quick look through the source shows that card should match (entries in
> > pcmciadevs):
> > vendor MELCO                    0x8a01  Melco Corporation
> > product MELCO LPC3_TX           0xc1ab Melco LPC3-TX
> >
> > and a matching entry in if_ne_pcmcia.c
> >     { PCMCIA_STR_MELCO_LPC3_TX,
> >       PCMCIA_VENDOR_MELCO, PCMCIA_PRODUCT_MELCO_LPC3_TX,
> >       PCMCIA_CIS_MELCO_LPC3_TX,
> >       0, -1, { 0x00, 0x40, 0x26 }, NE2000DVF_AX88190 },
> >
> > Can you confirm the above exist in those files?
>
> No.  I am not autobuild@tgm.daemon.org.  I am in no especially good
> position to determine what files were or were not used on Sept. 8 to build
> that kernel.  I assume that, as of Sept. 8, the files were current with
> what was destined to becoem 1.6, but that's as much as I can say.

Yes, should be clean files.

> I don't really have the time to upgrade the whole laptop, install kernel
> sources, and rebuild just to see if it might work.  Not right now.
>
> What I have time to do is try extant kernels.  And, when 1.6 is really
> released, I hope to be able to make time to do the upgrade (allowing that
> I may have to revert to 1.5.2 if I can't fix the ethernet problem).  I
> just can't do that upgrade dance multiple times over the next month or so.

That should be RSN 8)

> If you have reason to believe that the Sept. 8 kernel on the pre-release
> site was built incorrectly (or built from bogus sources), I can get a
> newer one (now, or whenever one next shows up).

No, it's just that if it had been a local build I'd have just asked if you'd
confirm that your source code was all in sync.

> How does NetBSD (1.6 "RC3", if that distinction matters) search the list
> for vendor/product codes?  Does it do a bsearch() on an array that it
> assumes is sorted?  If so, is the array possibly out of order?  (I think
> that /usr/bin/find had a bug like this in its option parsing a year or so
> ago; someone inserted an option in a table where it "made more sense", but
> the bsearch() (or whatever) failed to find it because the algorithm
> required the table to be sorted lexicographically.)

It starts at the top and works through an entry at a time, IE no special
ordering, this is one of those it's only done rarely, so performance is not
critical.

>
> Thanks for the helpful answer.  Though I mostly expected:
>
>  a) To simply provide feedback ("this works; that doesn't").  This
>     may be of help to others (both end-users such as myself, and perhaps
>     people working on NetBSD).

>  b) To maybe be told, "Whups.  Heh.  Okay, should be fixed, now..."
>     Failing that, it would be nice to know, "Fixing this in a standard
>     kernel would break more things, due to PC hardware bogosity.  But,
>     it's easily fixed by building your own kernel..."  (I expect to
>     build a custom kernel anyway, after installing 1.6.)

From what I can tell of the code it's doing the right thing. (well it looks
to be, hence me asking for more details etc 8)

Could you send-pr this?

Cheers,
Chris