linux-kernel - Re: Rt2x00 problem traced back to x86 ACPI/PCI/e820 handling.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 07 Dec 2009 14:52:51 -0800
From:	Yinghai Lu <yinghai@...nel.org>
To:	Gertjan van Wingerde <gwingerde@...il.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>
CC:	Ingo Molnar <mingo@...e.hu>, LKML <linux-kernel@...r.kernel.org>,
	erbrochendes@....de, divinespear@...il.com, andjelo@....net,
	Jesse Barnes <jbarnes@...tuousgeek.org>
Subject: Re: Rt2x00 problem traced back to x86 ACPI/PCI/e820 handling.

Gertjan van Wingerde wrote:
> Hi Ingo, Yinghai,
> 
> For a while now we have seen reports of the rt2x00 driver not working correctly
> where bogus information was read from the EEPROM. This resulted in a non-functional
> driver.
> It has been established that the problem has introduced itself sometimes in the 2.6.31
> development cycle.
> 
> Lately the failures have been traced back to commit 5d423ccd7ba4285f1084e91b26805e1d0ae978ed
> of a patch created by Yinghai and committed Ingo.
> 
> Reverting this patch seems to fix the problems with the rt2x00 driver.
> 
> Also, it has been established that another work-around is to supply the pci=use_crs boot parameter.
> 
> Do any of you have any idea as to what is going on here, and if this is something where the
> rt2x00 driver is at fault, or where the x86 ACPI/PCI/e820 code is buggy?
> 
> So far I can establish that all the cases for which it is known what kind of HW it is that these
> are all MSI laptops.
> 
> The related bug reports are:
> 	http://bugzilla.kernel.org/show_bug.cgi?id=14460
> 	https://bugs.launchpad.net/ubuntu/+source/linux/+bug/404596
> 

[    0.000000] BIOS-provided physical RAM map:
[    0.000000]  BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
[    0.000000]  BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
[    0.000000]  BIOS-e820: 00000000000e4000 - 0000000000100000 (reserved)
[    0.000000]  BIOS-e820: 0000000000100000 - 000000006ffd0000 (usable)
[    0.000000]  BIOS-e820: 000000006ffd0000 - 000000006ffde000 (ACPI data)
[    0.000000]  BIOS-e820: 000000006ffde000 - 0000000070000000 (ACPI NVS)
[    0.000000]  BIOS-e820: 00000000fff80000 - 0000000100000000 (reserved)
...
[    0.000000] Allocating PCI resources starting at 70000000 (gap: 70000000:8ff80000)
...

[    0.144853] node 0 link 0: io port [1000, ffffff]
[    0.144853] TOM: 0000000080000000 aka 2048M
[    0.144853] node 0 link 0: mmio [bdf00000, ddeeffff]
[    0.144853] node 0 link 0: mmio [80000000, bdefffff]
[    0.144853] node 0 link 0: mmio [e0000000, efffffff]
[    0.144853] node 0 link 0: mmio [ddef0000, dfffffff]
[    0.144853] node 0 link 0: mmio [a0000, bffff]
[    0.144853] node 0 link 0: mmio [f0000000, ffffffff]
[    0.144853] bus: [00,ff] on node 0 link 0
[    0.144853] bus: 00 index 0 io port: [0, ffff]
[    0.144853] bus: 00 index 1 mmio: [80000000, dfffffff]
[    0.144853] bus: 00 index 2 mmio: [e0000000, fcffffffff]
[    0.144853] bus: 00 index 3 mmio: [a0000, bffff]
...

[    0.200570] pci 0000:00:14.0: reg 14 32bit mmio: [0x000000-0x0003ff]
...
[    0.201755] pci 0000:05:04.0: reg 10 32bit mmio: [0x000000-0x000fff]
[    0.201765] pci 0000:05:04.0: reg 14 32bit mmio: [0x000000-0x0007ff]
[    0.201986] pci 0000:05:04.2: reg 10 32bit mmio: [0x000000-0x0000ff]
[    0.202215] pci 0000:05:04.3: reg 10 32bit mmio: [0x000000-0x000fff]
[    0.202865] pci 0000:05:09.0: reg 10 32bit mmio: [0x000000-0x007fff]
[    0.202997] pci 0000:00:14.4: transparent bridge
[    0.203051] pci 0000:00:14.4: bridge 32bit mmio: [0x000000-0x0fffff]

..

[    0.283503] pci 0000:00:14.4: PCI bridge, secondary bus 0000:05
[    0.283547] pci 0000:00:14.4:   IO window: disabled
[    0.283596] pci 0000:00:14.4:   MEM window: 0x70000000-0x700fffff
[    0.283643] pci 0000:00:14.4:   PREFETCH window: disabled


[    0.283764] pci_bus 0000:05: resource 1 mem: [0x70000000-0x700fffff]


[    2.140079] ohci1394 0000:05:04.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20
[    2.357886] ohci1394: fw-host0: Get PHY Reg timeout [0x00000000/0x00000000/100]
[    2.399313] ohci1394: fw-host0: Set PHY Reg timeout [0x000044c0/0x00004000/100]
[    2.494572] ohci1394: fw-host0: OHCI-1394 0.0 (PCI): IRQ=[20]  MMIO=[70008000-700087ff]  Max Packet=[2]  IR/IT contexts=[32/32]
[    2.529013] ohci1394: fw-host0: Get PHY Reg timeout [0x00000000/0x00000000/100]
[    2.593817] ohci1394: fw-host0: Serial EEPROM has suspicious values, attempting to set max_packet_size to 512 bytes
[    3.596012] ohci1394: fw-host0: Get PHY Reg timeout [0x00008500/0x00000000/100]
[    3.695273] ohci1394: fw-host0: Set PHY Reg timeout [0x00004540/0x00004000/100]


...


and 2.6.30...

[    0.000000] Allocating PCI resources starting at 80000000 (gap: 70000000:8ff80000)


looks like BIOS is using [0x70000000 - 0x80000000] 235M ram range for some purpose.

please try this on top of 2.6.32.

diff --git a/arch/x86/pci/amd_bus.c b/arch/x86/pci/amd_bus.c
index 572ee97..44f7c3d 100644
--- a/arch/x86/pci/amd_bus.c
+++ b/arch/x86/pci/amd_bus.c
@@ -48,8 +48,8 @@ void x86_pci_root_bus_res_quirks(struct pci_bus *b)
 	    b->resource[1] != &iomem_resource)
 		return;
 
-	/* if only one root bus, don't need to anything */
-	if (pci_root_num < 2)
+	/* if no reading for pci conf, don't need to do anything */
+	if (!pci_root_num)
 		return;
 
 	for (i = 0; i < pci_root_num; i++) {



YH


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