Most recent kernel where this bug did not occur: 2.6.13 Distribution: gentoo,ubuntu Hardware Environment: Laptop Targa 826T Software Environment: Problem Description: since 2.6.14 my tv-card is not detected by lspci. its a Typhoon DVB-T Duo Digital/Analog Cardbus i have copyied the old .config from the 2.6.13 kernel and used make oldconfig to compile the new kernel Steps to reproduce: use lspci
Can you upload a dmesg of 2.6.13 and 2.6.14, please? (create an attachment)
Created attachment 6545 [details] dmesg of 2.6.13-gentoo-r5 its a gentoo dmesg of the 2.6.13 if you need i can try to compile a vanilla 2.6.13
Created attachment 6546 [details] dmesg of 2.6.14 vanilla
-PCI: Using configuration type 1 +PCI: Using MMCONFIG This might be the same problem as in #5550 .
if have changed a function of this file: /usr/src/linux/arch/i386/pci/mmconfig.c static int __init pci_mmcfg_init(void) { return 0; } this forces to use the ( dmesg says this ): Using configuration type 1 but it does not solve my problem.
Please create attachments with /proc/iomem and /proc/ioports of the working and non-working kernel.
Created attachment 6579 [details] iomem of 2.6.13-gentoo-r5 iomem of 2.6.13-gentoo-r5
Created attachment 6580 [details] iomem of 2.6.14 iomem of 2.6.14
Created attachment 6581 [details] ioports of 2.6.13-gentoo-r5 ioports of 2.6.13-gentoo-r5
Created attachment 6582 [details] ioports of 2.6.14 ioports of 2.6.14
OK, a few ideas: 1.) can you pass the option bios_override=1 to yenta_socket? if it is modular, do modprobe yenta_socket bios_override=1, if it is built into the kernel, pass yenta_socket.bios_override=1 to the kernel in the boot loader 2.) working: Allocating PCI resources starting at 40000000 (gap: 40000000:a0000000) broken: Allocating PCI resources starting at 50000000 (gap: 40000000:a0000000) Can you try "hardcoding" (and don't add or remove an memory in the system before, when, or after doing so, unless you use a "fresh" kernel) in arch/i386/kernel/setup.c::register_memory(), where it reads: /* Fun with two's complement */ pci_mem_start = (gapstart + round) & -round;
... pressed enter too early, sorry. Could you replace that line with pci_mem_start = 0x40000000; once, and once with pci_mem_start = 0x80000000; And tell us what happens, please? Don't do this if you're not familiar with modifying the kernel sources, though; then -- if the others don't shout at me that I'm looking in the wrong place -- I can prepare a patch for you to apply.
@Dominik Brodowski: 1) if have override_bios with the yenta module. it was no help. 2) i also have hardcoded your code. both was no help. i have checked dmesg. the changes were applied.
Well, then I'm back in the dark.... However: does lspci -vvv show any differences?
Created attachment 6593 [details] debug patch Also, could you apply the attached patch to 2.6.14. It should report us whether the bug is before or after cb_alloc().
could you try: 1) to boot with pci=assign-busses added to the kernel command line 2) with this patch: diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c index fce2cb2..4d3bc92 100644 --- a/drivers/pci/probe.c +++ b/drivers/pci/probe.c @@ -403,10 +403,12 @@ static void __devinit pci_fixup_parent_s { struct pci_bus *parent = child->parent; +#if 0 /* Attempts to fix that up are really dangerous unless we're going to re-assign all bus numbers. */ if (!pcibios_assign_all_busses()) return; +#endif while (parent->parent && parent->subordinate < max) { parent->subordinate = max;
Created attachment 6595 [details] some lspci combinations: with override_bios without it, with the 0x40000000 and without it...
@Dominik Brodowski: i have applied the debug patch. now i can see the messages in dmesg when i insert my tv-card or take it out.
@Daniel Ritz: BINGO! ;-) if have apllied your patch: +#if 0 /* Attempts to fix that up are really dangerous unless we're going to re-assign all bus numbers. */ if (!pcibios_assign_all_busses()) return; +#endif now lspci shows my tv-card ! my tv-card is found also without the pci=assign-busses kernel parameter dmesg shows no real difference. both work. bug found?
pci=assign-busses is equivalent to the little patch. What shall we do with this bug now? Several systems require this boot parameter... what harm can it do if enabled unconditionally? what harm can it do when enabled, but it isn't needed?
nope. pci=assign-busses can renumber everything while the little patch only makes sure the a bridgs's parent bridge has the subordinate right (in the seconds pass of the PCI scanning). there's a change in behaviour between 2.6.13 and 2.6.14, introduced by this patch: http://www.kernel.org/git/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=12f44f46bc9c6dc79255e661b085797af395d8da but some systems can hang w/o that...any ideas?
Created attachment 6767 [details] busnr warning and trying to fix them up How about this patch? It adds a warning to add pci=assign-busses in the case of possibly inaccessible busses. The first two hunks try to do the following: On my notebook, "lspci -vvv | grep subordinate" returns: Bus: primary=00, secondary=02, subordinate=02, sec-latency=64 Bus: primary=02, secondary=03, subordinate=06, sec-latency=176 Bus: primary=02, secondary=07, subordinate=0a, sec-latency=176 the subordinate setting of the first bridge is clearly invalid. However, there is no bus range at all we can use for the cardbus busses (#03-#0a), so leave this setting alone. On dex1980@web.de's system, it is: Bus: primary=00, secondary=02, subordinate=04, sec-latency=64 Bus: primary=02, secondary=03, subordinate=06, sec-latency=176 Bus: primary=02, secondary=07, subordinate=0a, sec-latency=176 Try to make Bus: primary=02, secondary=03, subordinate=03... Bus: primary=02, secondary=04, subordinate=04... out of this...
Created attachment 6777 [details] allocate bus numbers sparsely, add warning for hidden busses Fix off-by-one error, pcibios_assign_all_busses is a function, not a value.
OK, just received a report that the patch http://bugzilla.kernel.org/attachment.cgi?id=6777&action=view does the right thing. And if it can't do the right thing (allocating bus numbers sparsely if we only have few available), it prints out a warning. So, could we get that upstream? Greg? akpm?
Send me the patch please.
Patch is in mainline now.
For people which came here from http://www.kernel.org/pub/linux/utils/kernel/pcmcia/pcmcia.html for information to make their cardbus cards seen: A patch to make hidden Cardbus cards seen has now been committed to the PCMCIA git tree by Dominik Brodowski: http://kernel.org/git/?p=linux/kernel/git/brodo/pcmcia-2.6.git;a=commit;h=a1c9056cdda13d11a58624fc232b659836e01bb3 As the commits to this tree are also used in Andrew Morton's -mm kernels, it is also found in his latest kernel: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc1/2.6.17-rc1-mm3/ For more information, also look at Bug #2944