* Rt2x00 problem traced back to x86 ACPI/PCI/e820 handling.
@ 2009-12-07 22:28 Gertjan van Wingerde
2009-12-07 22:52 ` Yinghai Lu
0 siblings, 1 reply; 3+ messages in thread
From: Gertjan van Wingerde @ 2009-12-07 22:28 UTC (permalink / raw)
To: Ingo Molnar, Yinghai Lu; +Cc: LKML, erbrochendes, divinespear, andjelo
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
---
Gertjan.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Rt2x00 problem traced back to x86 ACPI/PCI/e820 handling.
2009-12-07 22:28 Rt2x00 problem traced back to x86 ACPI/PCI/e820 handling Gertjan van Wingerde
@ 2009-12-07 22:52 ` Yinghai Lu
2009-12-09 6:43 ` Gertjan van Wingerde
0 siblings, 1 reply; 3+ messages in thread
From: Yinghai Lu @ 2009-12-07 22:52 UTC (permalink / raw)
To: Gertjan van Wingerde, Linus Torvalds
Cc: Ingo Molnar, LKML, erbrochendes, divinespear, andjelo, Jesse Barnes
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
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: Rt2x00 problem traced back to x86 ACPI/PCI/e820 handling.
2009-12-07 22:52 ` Yinghai Lu
@ 2009-12-09 6:43 ` Gertjan van Wingerde
0 siblings, 0 replies; 3+ messages in thread
From: Gertjan van Wingerde @ 2009-12-09 6:43 UTC (permalink / raw)
To: Yinghai Lu
Cc: Linus Torvalds, Ingo Molnar, LKML, erbrochendes, divinespear,
andjelo, Jesse Barnes
On 12/07/09 23:52, Yinghai Lu wrote:
> 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++) {
>
Thanks for the quick turnaround on this issue.
I got information from one of the bug reporters that the patch indeed fixes the problem.
Please submit patch for mainline and stable for inclusion in mainline and stable 2.6.31
and stable 2.6.32.
---
Gertjan.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2009-12-09 6:43 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-12-07 22:28 Rt2x00 problem traced back to x86 ACPI/PCI/e820 handling Gertjan van Wingerde
2009-12-07 22:52 ` Yinghai Lu
2009-12-09 6:43 ` Gertjan van Wingerde
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).