[Charset iso-8859-1 unsupported, filtering to ASCII...] > Dear Bill, others, > > I've been working on getting my Deskpros to use their NIC under 4.2, but no > luck. The problem is as follows: I installed 4.0, and the NIC came up under > the lnc driver, reports its MAC address and works fine. > [...] > In 4.2, the lnc driver still probes and finds the NIC, but does not report > finding a MAC address, and the NIC remains dead. [...] > Compiling a kernel with the pcn driver does not help. Booting a lnc+pcn > kernel causes the behaviour described above, booting a pcn-only kernel makes > the NIC show up as an unknown device, vendor 0x1022, device 0x2000. *ahem* How about compiling a kernel *without* the pcn driver? I want to know why you didn't consider this combination. (Well, I know why: because giving me the answer straight away rather than making me drag it out of you would have been too easy. I would never be that lucky.) The pcn driver does *not* want this card. It specifically checks for the device code in the probe routine and rejects cards it doesn't like. Note that this is *not* the PCI vendor/device ID: the way AMD did it, the PCI ID is the same for all the PCnet devices. You need to read a register in I/O space to determine exactly what device this is. That said, I think I know what the problem is. The pcn driver is probing the card first and setting it to 32-bit mode. The lnc driver wants the device to be in 16-bit mode: if it isn't, it won't be able to properly access any of its registers. This is why reading the card type and MAC address fails. Next time, *remove* the pcn device from the kernel config and leave the lnc driver. That should work. In the meantime, I need to get out the PCnet manual and check how to put the device back into 16-bit mode at the end of pcn_probe() so that the lnc driver will play nice with it. -Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message