[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

GENERIC vs custom kernel oddities in pre2.4



I'm mystified by the different behaviior between a GENERIC and custom
kernels with regard to probing a 3c589 card in my laptop. Source is
-current (ie v2.4) Only the GENERIC kernel does its thing "correctly." Both
build directories were completely empty before compile. The sources are
likewise identical.

The lines for pcic, pcmcia and ep* are identical between the 2
configuration files. What I find amazing is the the APM info and memory
values change with every new TECRA kernel. The GENERIC one doesn't change
values at all.

The output differs thus:

- = GENERIC
+ = TECRA (ie stripped down from GENERIC)
-------------------------
-avail mem = 74637312
+avail mem = 76496896
-bios0: apminfo 0xf046500c diskinfo 0xf0465034 cksumlen 1 memmap 0xf04650b0
+bios0: apminfo 0xf02a300c diskinfo 0xf02a3034 cksumlen 1 memmap 0xf02a30b0
...
-ep1 at pcmcia0 function 0 port 0x360-0x36f: 3com 3c589 10Mbps Ethernet,
address 00:60:97:89:e1:e4, utp/aui/bnc (default utp)
+ep0 at pcmcia0 function 0 port 0x200-0x20f: 3com 3c589 10Mbps Ethernet,
address 00:60:97:89:e1:e4, wrote 2047 to TX_AVAIL_THRESH, read back 61680.
Interface disabled

Clearly, in the course of doing probes for all sorts of other devices, the
GENERIC kernel manages NOT to think the item at 0x200 is a 3com card or
something else gets kicked so the 3com shows up at 0x360 instead. I find it
*VERY* interesting that the only NIC card in this laptop shows up as ep1
instead of ep0 when using the GENERIC kernel. It's as if a 'stub' ep device
was found on some other bus.

The kernel config file entries:
pcic0	at isa? port 0x3e0 iomem 0xd0000 iosiz 0x4000
pcic1	at isa? port 0x3e2 iomem 0xd4000 iosiz 0x4000
pcmcia* at pcic? controller ? socket ?
ep*	at pcmcia? function ?
/* GENERIC has other ep* device entries */

Next up, commenting out all spurious devices from a GENERIC kernel and see
what the magic probe is that makes it work/fail. This is going to be a very
tedious process. Is there a better way to debug it?

And *NO* using a GENERIC kernel is NOT the solution! It's 2MB vs 960kb.

=====
 Matthew Patton, 1LT USAF	Webmaster, Resource Analysis
 PGP Fingerprint: 17D4 98B1 51F1 BCD9 D815  5F3D 3B1C 5C26 762C C9C9
          Key ID: 0x762CC9C9    Expires: 7/31/99