As per an email to the linux-mips group from Thomas Schwinge on July 30,
2010, there's a problem using current (post 2.6.29) sources for a kernel
with the pcnet32 driver with the PCNet32 chip on the MIPS Malta platform
in some configurations. The probe1 routine fails the test below and
spits out the "No access methods" diagnostic:
...
/* NOTE: 16-bit check is first, otherwise some older PCnet chips
fail */
if (pcnet32_wio_read_csr(ioaddr, 0) == 4 &&
pcnet32_wio_check(ioaddr)) {
a = &pcnet32_wio;
} else {
pcnet32_dwio_reset(ioaddr);
if (pcnet32_dwio_read_csr(ioaddr, 0) == 4
&& pcnet32_dwio_check(ioaddr)) {
a = &pcnet32_dwio;
} else {
if (pcnet32_debug & NETIF_MSG_PROBE)
printk(KERN_ERR PFX "No access methods\n");
goto err_release_region;
}
}
The chip is visible to the kernel and turns up in lspci:
-bash-3.1# lspci -tv
-[0000:00]-+-0a.0 Intel Corporation 82371AB/EB/MB PIIX4 ISA
+-0a.1 Intel Corporation 82371AB/EB/MB PIIX4 IDE
+-0a.2 Intel Corporation 82371AB/EB/MB PIIX4 USB
+-0a.3 Intel Corporation 82371AB/EB/MB PIIX4 ACPI
+-0b.0 Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE]
+-0c.0 Cirrus Logic Crystal CS4281 PCI Audio
+-11.0 MIPS Technologies, Inc. SOC-it 101 System Controller
\-13.0-[0000:01]----00.0 Matrox Graphics, Inc. G400/G450
-bash-3.1# lspci -n
00:0a.0 0601: 8086:7110 (rev 02)
00:0a.1 0101: 8086:7111 (rev 01)
00:0a.2 0c03: 8086:7112 (rev 01)
00:0a.3 0680: 8086:7113 (rev 02)
00:0b.0 0200: 1022:2000 (rev 44)
00:0c.0 0401: 1013:6005 (rev 01)
00:11.0 0600: 153f:0001 (rev 01)
00:13.0 0604: 3388:0021 (rev 13)
01:00.0 0300: 102b:0525 (rev 85)
I'm suspecting that the problem is at least as likely to be in the Malta
PCI support as in the PCNet driver itself. Is this phenomenon
understood? Has there been a fix circulated for it?
Regards,
Kevin K.
