On Toshiba Satellite NB10-A-104 laptop, the Realtek ethernet controller is not working at all. After booting Linux, the PCI BAR 2 and 4 of the ethernet controller are set to addresses which are inside the MMCONFIG area (which I assume is illegal). The MMCONFIG node does not even appear in /proc/iomem. The beginning of its memory range is instead used by PCI bus 3. On Windows, the ethernet controller works fine, and has a different memory range assigned. (all other PCI devices have mostly the same addresses in Windows and Linux) The MMCONFIG area has an address range 0xe0000000-0xefffffff. Comparison: Linux: Region 0: I/O ports at e000 [size=256] Region 2: Memory at e0004000 (64-bit, prefetchable) [size=4K] Region 4: Memory at e0000000 (64-bit, prefetchable) [size=16K] Windows: Region 0: I/O ports at e000 [size=256] Region 2: Memory at cfffb000 (64-bit, prefetchable) [size=4K] Region 4: Memory at cfffc000 (64-bit, prefetchable) [size=16K] (IO ports are the same in Linux and Windows, and the controller works on Linux if I patch the r8169 driver to use port-mapped IO)
Created attachment 273943 [details] dmesg
Adding the following quirk to arch/x86/pci/fixup.c and booting the kernel on Toshiba Satellite NB10-A-104 fixes the problem: static void quirk_toshiba_nb10(struct pci_dev *pdev) { struct device *dev = &pdev->dev; struct resource *res; if (!dmi_match(DMI_PRODUCT_NAME, "SATELLITE NB10-A-104")) return; // reserve [mem 0xe0000000-0xe00ffffe] res = request_mem_region(0xe0000000, 0xfffff, "Toshiba NB10 PCI MMCONFIG address conflict workaround"); if (res) dev_warn(dev, "claimed %s %pR\n", res->name, res); else dev_warn(dev, "can't work around Toshiba NB10 issue\n"); } DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x0f4c, quirk_toshiba_nb10);