Subject: A few kernel problems...
To: None <port-i386@netbsd.org, netbsd-help@netbsd.org>
From: Richard Rauch <rauch@eecs.ukans.edu>
List: netbsd-help
Date: 06/07/1999 09:13:29
I don't know which is the best list for this, so I'm posting to port-i386
and netbsd-help.  I read netbsd-help, but only peruse port-i386 from the
NetBSD web pages (I DID check port-i386 before posting, however, to before
the 1.4 release; I saw no mention of my problems by others).

My system is an i386 (Pentium II, 233mHz Gateway 2000 system about 18
months old; 32 MB RAM).

I noticed a few oddities when I recently upgraded to NetBSD 1.4:


.) I began building a custom kernel.  I copied GENERIC; I built from
   my copy; I trimmed a little (first 50 or so lines of the config),
   and built with that; finally, I heavily went through the whole
   thing (killing PCMCIA stuff, etc.) and built again.

   On the last build, I got a link-time error on ip_gre.o, I believe
   it was.  Since I had wiped my drive, locate(1) wasn't able to
   help me find the .c file.  I didn't feel like guessing and didn't
   care to wait on find(1), so I just deleted the object file and
   re-executed make.

   This time it compiled & linked cleanly!

   It seems that stuff that SHOULD have been updated (yes, I am
   pretty sure that I did a config and make depend) was not updated.

   So, I moved the new kernel to a safe spot, did a ``make clean'' and
   ``make depend && make'' (dunno if the make-depend was needed, but
   it shouldn't have hurt).  The kernel compiled cleanly, but was
   a few KB smaller than the kernel I had just compiled from the same
   configuration!

   It is possible that I forgot to do a make depend, and mis-remember
   now.  But I don't think that that's what happened.  Can anyone
   confirm similar behavior?


.) Around March, I recall, someone was talking about adding a driver
   for the LinkSys Ethernet cards (mis-identified by the kernel as
   being products of a ``Lite-on'' company).  I have one, and it
   is still mis-identified & is not configured.  The full line from
   dmesg is something like:

Lite-On Communications 82C168/82C169 (PNIC) 10/100 Ethernet (ethernet
network, revision 0x20) at pci0 dev 16 function 0 not configured

   (This card was bought last fall.)  Currently, I don't need it to
   run under NetBSD, but it would be nice.  Did the driver just miss
   being incorporated into the kernel, or was it another LinkSys
   card that was being worked on last March?

   If the card isn't supported, and no one is working on it, then I
   might try my hand at it.  I'm not the best person to write a
   device driver, but I may be marginally better than having no one
   working on it.  (^&  (I would, of course, need some technical info
   on the card; LinkSys provides none.  And some advice on where to start
   with writing a driver would be helpful.)

   Even better, just tell me that it is supported and I need to enable
   a line in the config file somewhere.  (I _thought_ that I left all
   of the PCI ethernet drivers in, Just In Case.  Maybe the GENERIC
   kernel doesn't the right driver by default?)


.) My Ensoniq card produces the following two lines:

eap0 at pci0 dev 13 function 0: Ensoniq AudioPCI (rev. 0x00)
eap0: can't map i/o space

   I tracked this down to a failing call to bus_space_map(9) (or
   some such).  Is there any way that I can get more informatin out
   of the kernel, easily?  Or anything I can tweak?  It surely
   wouldn't help to swap cards to different slots, would it?

   The system has 4 PCI slots.  One for the Ensoniq, one for the
   LinkSys (not configured, so it shouldn't use any resources, right?),
   one for an Adaptect SCSI card, and one for the STB Nitro 3D graphics
   card.

   Other things that appear to be on the PCI bus are: The HD controller,
   the ATAPI controller for the CD-ROM, USB (ALSO ``can't map i/o space'';
   uhci0 at pci0 dev 7 function 2: Intel 82371AB USB Host Controller
   (PIIX4) (rev. 0x01)), and Advanced Power Management (disabled in
   kernel).  Those, however, are hardwired on the motherboard and not
   in PCI slots.

   All suggestions gratefully accepted.  (^&


  "I probably don't know what I'm talking about." --rauch@eecs.ukans.edu