Bug 5557

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