Bug 5557 - lspci missing my pcmcia tv-card
lspci missing my pcmcia tv-card
Product: Drivers
Classification: Unclassified
Component: PCMCIA
i386 Linux
: P2 normal
Assigned To: Dominik Brodowski
Depends on:
  Show dependency treegraph
Reported: 2005-11-05 15:47 UTC by dex1980
Modified: 2006-04-19 14:02 UTC (History)
5 users (show)

See Also:
Kernel Version: 2.6.14
Tree: Mainline
Regression: ---

dmesg of 2.6.13-gentoo-r5 (13.53 KB, text/plain)
2005-11-11 12:01 UTC, dex1980
dmesg of 2.6.14 vanilla (11.91 KB, text/plain)
2005-11-11 12:02 UTC, dex1980
iomem of 2.6.13-gentoo-r5 (1.48 KB, text/plain)
2005-11-14 07:14 UTC, dex1980
iomem of 2.6.14 (1.42 KB, text/plain)
2005-11-14 07:15 UTC, dex1980
ioports of 2.6.13-gentoo-r5 (831 bytes, text/plain)
2005-11-14 07:16 UTC, dex1980
ioports of 2.6.14 (813 bytes, text/plain)
2005-11-14 07:17 UTC, dex1980
debug patch (1.79 KB, patch)
2005-11-15 11:56 UTC, Dominik Brodowski
Details | Diff
some lspci combinations: with override_bios without it, with the 0x40000000 and without it... (50.00 KB, application/octet-stream)
2005-11-16 03:05 UTC, dex1980
busnr warning and trying to fix them up (2.36 KB, patch)
2005-12-05 00:52 UTC, Dominik Brodowski
Details | Diff
allocate bus numbers sparsely, add warning for hidden busses (2.36 KB, patch)
2005-12-07 02:23 UTC, Dominik Brodowski
Details | Diff

Description dex1980 2005-11-05 15:47:36 UTC
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
Comment 1 Dominik Brodowski 2005-11-11 01:45:12 UTC
Can you upload a dmesg of 2.6.13 and 2.6.14, please? (create an attachment)
Comment 2 dex1980 2005-11-11 12:01:24 UTC
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
Comment 3 dex1980 2005-11-11 12:02:30 UTC
Created attachment 6546 [details]
dmesg of 2.6.14 vanilla
Comment 4 Adrian Bunk 2005-11-13 07:33:46 UTC
-PCI: Using configuration type 1

This might be the same problem as in #5550 .
Comment 5 dex1980 2005-11-13 09:50:28 UTC
if have changed a function of this file:

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.
Comment 6 Dominik Brodowski 2005-11-13 13:26:12 UTC
Please create attachments with /proc/iomem and /proc/ioports of the working and
non-working kernel.
Comment 7 dex1980 2005-11-14 07:14:16 UTC
Created attachment 6579 [details]
iomem of 2.6.13-gentoo-r5

iomem of 2.6.13-gentoo-r5
Comment 8 dex1980 2005-11-14 07:15:18 UTC
Created attachment 6580 [details]
iomem of 2.6.14

iomem of 2.6.14
Comment 9 dex1980 2005-11-14 07:16:28 UTC
Created attachment 6581 [details]
ioports of 2.6.13-gentoo-r5

ioports of 2.6.13-gentoo-r5
Comment 10 dex1980 2005-11-14 07:17:23 UTC
Created attachment 6582 [details]
ioports of 2.6.14

ioports of 2.6.14
Comment 11 Dominik Brodowski 2005-11-15 09:14:41 UTC
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

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;

Comment 12 Dominik Brodowski 2005-11-15 09:16:52 UTC
... 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.
Comment 13 dex1980 2005-11-15 10:29:55 UTC
@Dominik Brodowski:

if have override_bios with the yenta module.
it was no help.

i also have hardcoded your code.
both was no help.
i have checked dmesg. the changes were applied.
Comment 14 Dominik Brodowski 2005-11-15 10:56:20 UTC
Well, then I'm back in the dark.... However: does lspci -vvv show any differences?
Comment 15 Dominik Brodowski 2005-11-15 11:56:50 UTC
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().
Comment 16 Daniel Ritz 2005-11-15 13:12:11 UTC
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())
 	while (parent->parent && parent->subordinate < max) {
 		parent->subordinate = max;
Comment 17 dex1980 2005-11-16 03:05:02 UTC
Created attachment 6595 [details]
some lspci combinations: with override_bios without it, with the 0x40000000 and without it...
Comment 18 dex1980 2005-11-16 03:07:41 UTC
@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.
Comment 19 dex1980 2005-11-16 03:12:37 UTC
@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())

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?

Comment 20 Dominik Brodowski 2005-11-16 15:21:18 UTC
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?
Comment 21 Daniel Ritz 2005-11-17 10:17:36 UTC
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:
but some systems can hang w/o that...any ideas?
Comment 22 Dominik Brodowski 2005-12-05 00:52:24 UTC
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...
Comment 23 Dominik Brodowski 2005-12-07 02:23:48 UTC
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.
Comment 24 Dominik Brodowski 2005-12-08 01:53:49 UTC
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?
Comment 25 Greg Kroah-Hartman 2005-12-08 07:38:04 UTC
Send me the patch please.
Comment 26 Dominik Brodowski 2006-01-10 09:16:08 UTC
Patch is in mainline now.
Comment 27 Bernhard Kaindl 2006-04-19 14:02:06 UTC
For people which came here from
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:


As the commits to this tree are also used in Andrew Morton's -mm kernels, it is
also found in his latest kernel:


For more information, also look at Bug #2944

Note You need to log in before you can comment on or make changes to this bug.