and, amusingly, from a stock 2.6.32.27 kernel that exhibits the problem,
I plugged in a PCI NIC and *both* interfaces came up happy. :o/ One
might suspect that PCNet32 now assumes some level of initialization that
isn't being done in the platform code, and lucks out if a more
thoroughly paranoid driver gets loaded first.
/K.
On 1/8/2011 10:40 AM, Kevin D. Kissell wrote:
> 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.
>
