[2.6.18-git] Lost all PCI devices

[Luca Tettamanti]

Hi Andi,
I'm testing current git on my notebook, but kernel doesn't find any
PCI device: no video card, no IDE, nothing.

Using git bisect I've tracked down the commit that broke my machine:

5e544d618f0fb21011f36f28d5e3952b9dc109d2 is first bad commit
commit 5e544d618f0fb21011f36f28d5e3952b9dc109d2
Author: Andi Kleen <***@suse.de>
Date: Tue Sep 26 10:52:40 2006 +0200

[PATCH] i386/x86-64: PCI: split probing and initialization of type 1 config space access

First probe if type1/2 accesses work, but then only initialize them at the end.

This is useful for a later patch that needs this information inbetween.

Signed-off-by: Andi Kleen <***@suse.de>

:040000 040000 5340a14d6abcce04258ce42d99bdb9dba59b0806 14fc88c780f388f70159ee7bdd2b50e7a7ceff3e M arch

I also tried pci=routeirq without success. I'm not using
PCI_MULTITHREAD_PROBE. This is lspci of the machine:

00:00.0 Host bridge: Silicon Integrated Systems [SiS] 740 Host (rev 01)
00:01.0 PCI bridge: Silicon Integrated Systems [SiS] Virtual PCI-to-PCI bridge (AGP)
00:02.0 ISA bridge: Silicon Integrated Systems [SiS] SiS962 [MuTIOL Media IO] (rev 04)
00:02.1 SMBus: Silicon Integrated Systems [SiS] SiS961/2 SMBus Controller
00:02.5 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE]
00:02.6 Modem: Silicon Integrated Systems [SiS] AC'97 Modem Controller (rev a0)
00:02.7 Multimedia audio controller: Silicon Integrated Systems [SiS] AC'97 Sound Controller (rev a0)
00:03.0 USB Controller: Silicon Integrated Systems [SiS] USB 1.0 Controller (rev 0f)
00:03.1 USB Controller: Silicon Integrated Systems [SiS] USB 1.0 Controller (rev 0f)
00:03.2 USB Controller: Silicon Integrated Systems [SiS] USB 1.0 Controller (rev 0f)
00:03.3 USB Controller: Silicon Integrated Systems [SiS] USB 2.0 Controller
00:04.0 Ethernet controller: Silicon Integrated Systems [SiS] SiS900 PCI Fast Ethernet (rev 90)
00:0a.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev aa)
00:0a.1 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev aa)
00:0a.2 FireWire (IEEE 1394): Ricoh Co Ltd R5C552 IEEE 1394 Controller (rev 02)
01:00.0 VGA compatible controller: Silicon Integrated Systems [SiS] 65x/M650/740 PCI/AGP VGA Display Adapter
02:00.0 Network controller: RaLink RT2500 802.11g Cardbus/mini-PCI (rev 01)

I'm attaching the output of lspci -vvxxx, and dmesg of working and non
working system (with CONFIG_PCI_DEBUG). Tell me if you need further
information.

Luca

[Andi Kleen]

Post by Luca Tettamanti
Hi Andi,
I'm testing current git on my notebook, but kernel doesn't find any
PCI device: no video card, no IDE, nothing.

Can you test it with this patch please?

-Andi

Fix PCI BIOS config space access

Got broken by a earlier change.

Signed-off-by: Andi Kleen <***@suse.de>

Index: linux/arch/i386/pci/direct.c
===================================================================
--- linux.orig/arch/i386/pci/direct.c
+++ linux/arch/i386/pci/direct.c
@@ -256,6 +256,8 @@ static int __init pci_check_type2(void)

void __init pci_direct_init(int type)
{
+ if (type == 0)
+ return;
printk(KERN_INFO "PCI: Using configuration type %d\n", type);
if (type == 1)
raw_pci_ops = &pci_direct_conf1;
Index: linux/arch/i386/pci/init.c
===================================================================
--- linux.orig/arch/i386/pci/init.c
+++ linux/arch/i386/pci/init.c
@@ -28,6 +28,10 @@ static __init int pci_access_init(void)
#ifdef CONFIG_PCI_DIRECT
pci_direct_init(type);
#endif
+ if (!raw_pci_ops)
+ printk(KERN_ERR
+ "PCI: Fatal: No config space access function found\n");
+
return 0;
}
arch_initcall(pci_access_init);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Luca Tettamanti]

Post by Andi Kleen

Post by Luca Tettamanti
Hi Andi,
I'm testing current git on my notebook, but kernel doesn't find any
PCI device: no video card, no IDE, nothing.

Can you test it with this patch please?

Works fine, I can boot with it. Thank you!

Post by Andi Kleen
Fix PCI BIOS config space access
Got broken by a earlier change.
Index: linux/arch/i386/pci/direct.c
===================================================================
--- linux.orig/arch/i386/pci/direct.c
+++ linux/arch/i386/pci/direct.c
@@ -256,6 +256,8 @@ static int __init pci_check_type2(void)
void __init pci_direct_init(int type)
{
+ if (type == 0)
+ return;
printk(KERN_INFO "PCI: Using configuration type %d\n", type);
if (type == 1)
raw_pci_ops = &pci_direct_conf1;
Index: linux/arch/i386/pci/init.c
===================================================================
--- linux.orig/arch/i386/pci/init.c
+++ linux/arch/i386/pci/init.c
@@ -28,6 +28,10 @@ static __init int pci_access_init(void)
#ifdef CONFIG_PCI_DIRECT
pci_direct_init(type);
#endif
+ if (!raw_pci_ops)
+ printk(KERN_ERR
+ "PCI: Fatal: No config space access function found\n");
+
return 0;
}
arch_initcall(pci_access_init);

Luca

[Andi Kleen]

Post by Luca Tettamanti

Post by Andi Kleen

Post by Luca Tettamanti
Hi Andi,
I'm testing current git on my notebook, but kernel doesn't find any
PCI device: no video card, no IDE, nothing.

Can you test it with this patch please?

Works fine, I can boot with it. Thank you!

Just curious - i assume you have CONFIG_PCI_GOBIOS set. Does your system
also work when you set CONFIG_PCI_GODIRECT instead?

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Luca Tettamanti]

Post by Andi Kleen

Post by Luca Tettamanti

Post by Andi Kleen

Post by Luca Tettamanti
Hi Andi,
I'm testing current git on my notebook, but kernel doesn't find any
PCI device: no video card, no IDE, nothing.

Can you test it with this patch please?

Works fine, I can boot with it. Thank you!

Just curious - i assume you have CONFIG_PCI_GOBIOS set.

Not really, it's set to any:

#
# Bus options (PCI, PCMCIA, EISA, MCA, ISA)
#
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GOMMCONFIG is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_MMCONFIG=y

I'm a bit clueless about those options so I let the default.

Post by Andi Kleen
Does your system also work when you set CONFIG_PCI_GODIRECT instead?

Without the patch I assume. No, I tried both PCI_GODIRECT and
PCI_GOMMCONFIG; the former survive the boot but doesn't find any device,
the latter explodes somewhere in ACPI code.

PCI_GODIRECT with a few printk and initcall_debug:

Calling initcall 0xc036cc40: acpi_pci_init+0x0/0x30()
ACPI: bus type pci registered
Calling initcall 0xc036e4ff: init_acpi_device_notify+0x0/0x43()
Calling initcall 0xc0372270: pci_access_init+0x0/0x40()
inside pci_access_init
calling pci_direct_probe
pci_direct_probe conf1
pci_direct_probe conf2
pci_direct_probe fail2
PCI: Using configuration type 0
Calling initcall 0xc035e1f0: request_standard_resources+0x0/0x320()
Setting up standard PCI resources

"pci_direct_probe conf*" printk are placed before calling into
pci_check_type{1,2}, it doesn't call pci_sanity_check so it's the I/O
check that fails.
I can do further debugging if you're interested.

PCI_GOMMCONFIG:

ACPI: Access to PCI configuration space unavailable
ACPI: Interpreter enabled
ACPI: Using PIC for interrupt routing
------------[ cut here ]------------
Kernel BUG at [verbose debug info unavailable]
invalid opcode: 0000 [#1]
PREEMPT
CPU: 0
EIP: 0060:[<c0233103>] Not tainted VLI
EFLAGS: 00010246 (2.6.18-g5ffd1a6a-dirty #20)
EIP is at acpi_os_read_pci_configuration+0x4f/0x87
eax: 00000001 ebx: defd0aa0 ecx: defc9c53 edx: 00000008
esi: 00000001 edi: 00000000 ebp: defc9c34 esp: defc9c20
ds: 007b es: 007b ss: 0068
Process swapper (pid: 1, ti=defc9000 task=defc8a50 task.ti=defc9000)
Stack: defc9c53 0000000e defc9c53 defc9c70 defc9c77 defc9c60 c0233342 00000008
00000006 00020000 defd0aa0 c144d9b4 c02d3630 defc9c70 00000000 c02cfc3e
defc9c7c c02333cb defc9c70 defc9c77 00000001 00fc9c9c defc9c9c defc9cb4
Call Trace:
[<c0233342>] acpi_os_derive_pci_id_2+0xab/0x110
[<c02333cb>] acpi_os_derive_pci_id+0x24/0x2b
[<c0238807>] acpi_ev_pci_config_region_setup+0x1d4/0x1e8
[<c0237893>] acpi_ev_address_space_dispatch+0xb5/0x186
[<c023b831>] acpi_ex_access_region+0x1c0/0x1d9
[<c023b980>] acpi_ex_field_datum_io+0x136/0x1bb
[<c023ba96>] acpi_ex_extract_from_field+0x91/0x224
[<c023a3b9>] acpi_ex_read_data_from_field+0x125/0x151
[<c023f41c>] acpi_ex_resolve_node_to_value+0x14c/0x1cc
[<c023af77>] acpi_ex_resolve_to_value+0x201/0x20e
[<c023cf92>] acpi_ex_resolve_operands+0x1f5/0x4df
[<c02351a1>] acpi_ds_exec_end_op+0xaf/0x3be
[<c0243a3c>] acpi_ps_parse_loop+0x59c/0x8a8
[<c024309e>] acpi_ps_parse_aml+0x68/0x20b
[<c02441ba>] acpi_ps_execute_pass+0x73/0x87
[<c02442cd>] acpi_ps_execute_method+0xcb/0x15a
[<c02416cf>] acpi_ns_evaluate+0x97/0xf4
[<c024133c>] acpi_evaluate_object+0x11f/0x1bf
[<c0233914>] acpi_evaluate_integer+0x7d/0xb0
[<c024a1f9>] acpi_bus_get_status+0x31/0x83
[<c0250bcf>] acpi_add_single_object+0x1b6/0x807
[<c0251319>] acpi_bus_scan+0xf9/0x163
[<c036ef77>] acpi_scan_init+0x14a/0x16c
[<c01003b5>] init+0x75/0x290
[<c0103c3b>] kernel_thread_helper+0x7/0x1c
=======================
Code: 20 74 12 83 fa 08 66 b8 01 00 75 4f eb 0e be 02 00 00 00 eb 0c be
04 00 00 00 eb 05 be 01 00 00 00 8b 3d 14 63 3a c0 85 ff 75 02 <0f> 0b
0f b7 4b 04 0f b7 43 06 ff 75 ec 0f b7 53 02 56 ff 75 f0
EIP: [<c0233103>] acpi_os_read_pci_configuration+0x4f/0x87 SS:ESP
0068:defc9c20

BTW changing those 2 options causes the re-compilation of almost all the
kernel (due to: include/config/pci/mmconfig.h), it's a bit awkward on my
not-very-fast machine...

Luca
--
"L'abilita` politica e` l'abilita` di prevedere quello che
accadra` domani, la prossima settimana, il prossimo mese e
l'anno prossimo. E di essere cosi` abili, piu` tardi,
da spiegare perche' non e` accaduto."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Andi Kleen]

Post by Luca Tettamanti
"pci_direct_probe conf*" printk are placed before calling into
pci_check_type{1,2}, it doesn't call pci_sanity_check so it's the I/O
check that fails.
I can do further debugging if you're interested.

No I was just curious. It's strange that your system doesn't work without
PCI BIOS though. Is it an older laptop? The assumption so far
was that everything modern can do type 1 without problems (except
one broken Apple system). Apparently that's not universally true.

Post by Luca Tettamanti
ACPI: Access to PCI configuration space unavailable
ACPI: Interpreter enabled
ACPI: Using PIC for interrupt routing
------------[ cut here ]------------
Kernel BUG at [verbose debug info unavailable]
invalid opcode: 0000 [#1]
PREEMPT
CPU: 0
EIP: 0060:[<c0233103>] Not tainted VLI
EFLAGS: 00010246 (2.6.18-g5ffd1a6a-dirty #20)
EIP is at acpi_os_read_pci_configuration+0x4f/0x87

The patch I posted should have fixed that.

Although I think it might be better to do panic() instead of printk.

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Luca Tettamanti]

Post by Andi Kleen

Post by Luca Tettamanti
"pci_direct_probe conf*" printk are placed before calling into
pci_check_type{1,2}, it doesn't call pci_sanity_check so it's the I/O
check that fails.
I can do further debugging if you're interested.

No I was just curious. It's strange that your system doesn't work without
PCI BIOS though. Is it an older laptop? The assumption so far
was that everything modern can do type 1 without problems (except
one broken Apple system). Apparently that's not universally true.

The machine is an ASUS L3D, it's about 3 years old (the built-in memory
module was manufactured on week 41 / 2003). I'm using the latest BIOS,
02/10/2004.

Luca