Most recent kernel where this bug did not occur:2.6.16.20 Distribution:Fedora Core 5 Hardware Environment:Cyrix/MediaGX, CS5520(SouthBridge), Ricoh RL5c475 Software Environment:kernel 2.6.17.3 Problem Description: kernel can't found CardBus card. From /proc/ioports, kernel 2.6.17 excludes region. dmesg of kernel 2.6.16.20: pccard: CardBus card inserted into slot 0 cs: IO port probe 0x3d4-0x4ff: excluding 0x47c-0x493 0x4cc-0x4d3 cs: IO port probe 0x3c0-0x3d2: clean. cs: IO port probe 0x100-0x3af: excluding 0x398-0x39f cs: IO port probe 0xc00-0xcff: clean. cs: IO port probe 0x800-0x8ff: clean. cs: IO port probe 0xa00-0xaff: clean. dmesg of kernel 2.6.17.3: pccard: CardBus card inserted into slot 0 cs: IO port probe 0x3d4-0x4ff: excluding 0x47c-0x493 0x4cc-0x4d3 cs: IO port probe 0x3c0-0x3d2: clean. cs: IO port probe 0x100-0x3af: excluding 0x398-0x39f cs: IO port probe 0xc00-0xcff: excluding 0xcf8-0xcff cs: IO port probe 0x800-0x8ff: clean. cs: IO port probe 0xa00-0xaff: clean. /proc/ioports of 2.6.16.20 0cf8-0cff : PCI conf1 1000-10ff : PCI CardBus #01 1000-10ff : 0000:01:00.0 1000-10ff : 8139too /proc/ioports of 2.6.17.3 1000-10ff : PCI CardBus #01 1400-14ff : PCI CardBus #01 Why will not 2.6.17-kernel assign "PCI conf1" region? Steps to reproduce:
Created attachment 8498 [details] dmesg of 2.6.16.20
Created attachment 8499 [details] dmesg of kernel 2.6.17.3 diff. with 2.6.16.20: - cs: IO port probe 0xc00-0xcff: clean. + cs: IO port probe 0xc00-0xcff: excluding 0xcf8-0xcff
Created attachment 8500 [details] output of lspci with 2.6.16.20. output of lspci, lspci -tv, lspci -v.
Created attachment 8501 [details] output of lspci with 2.6.17.3
Well, if /proc/ioports shows it is because it's actually _assigned_ to something: "conf1" (I don't know if that means something though) There're differences between the 2.6.16 and the 2.6.17 dmesg, but that doesn't neccesarily means there's a bug, if everything works.
Reply-To: matthew@wil.cx On Fri, Jul 07, 2006 at 07:47:08AM -0700, bugme-daemon@bugzilla.kernel.org wrote: > Well, if /proc/ioports shows it is because it's actually _assigned_ to > something: "conf1" (I don't know if that means something though) PCI config space 1. If that range were assigned to a cardbus card, you'd not be able to access it as the chipset would intercept writes to that address, and generate config space cycles instead. This is a red herring, the problem is something different.
"PCI conf1" is allocated even when don't insert a CardBus card. I think that a problem is a region 0xcf8-0xcff to be excluded. However, a difference is not found in claim_region() and do_io_probe() of linux/ drivers/pcmcia/rsrc_nonstatic.c in kernel-2.6.16.20 and 2.6.17.3.
Of course the Ethernet card which lspci do not show does not work. As for 8139too, it is not found a Ethernet card with kernel 2.6.17. When it is 2.6.16.20, it works well.
it's PCI problem, not PCMCIA: in 2.6.17 the ordering of the PCI access function probing was changed (commit 92c05fc1a32e5ccef5e0e8201f32dcdab041524c). the diff between the to dmesg makes it clear: the behaviour should be changed back to have PCIBIOS as last fallback.
Created attachment 8504 [details] pci access - pcibios as last fallback
Thanks for many comments. I tried to modify arch/i386/pci/init.c.(applied #10) CardBus did not work. Next, I changed CONFIG_PCI_ANY to CONFIG_PCI_BIOS in .config. After all the CardBus did not work.
the BIOS access methos is broken on your box (broken BIOS): PCI: PCI BIOS revision 2.10 entry at 0xfb9a0, last bus=0 "last bus=0" is wrong. your 2.6.16 kernel shows this additional line: PCI: Using configuration type 1 so what you want is direct access. my patch should have enabled that again, but it seems i missed something. anyway, set PCI access method to "Direct" using menuconfig and recompile the kernel.
OK, The problem was solved. CardBus works when change CONFIG_PCI_BIOS to CONFIG_PCI_DIRECT in .config. Thanks.
*** Bug 6834 has been marked as a duplicate of this bug. ***
Sorry, this was a typo.
Could people take a look at #6920? It's the same bug?
can this bug be closed, as per comment #13 ?
Yes, This bug is fixed in 2.6.18.