Bug 13940 - 2.6.31-rc1 - iwlagn and sky2 stopped working when ACPI enabled - Toshiba U400-17b, Acer Aspire 8935G
2.6.31-rc1 - iwlagn and sky2 stopped working when ACPI enabled - Toshiba U400...
Status: CLOSED CODE_FIX
Product: ACPI
Classification: Unclassified
Component: Config-Other
All Linux
: P1 normal
Assigned To: Len Brown
:
: 14450 (view as bug list)
Depends on:
Blocks: 13615
  Show dependency treegraph
 
Reported: 2009-08-09 21:31 UTC by Rafael J. Wysocki
Modified: 2011-08-18 21:52 UTC (History)
11 users (show)

See Also:
Kernel Version: 2.6.31-rc5
Tree: Mainline
Regression: Yes


Attachments
/proc/iomem of unpatched kernel (1.88 KB, text/plain)
2009-08-25 22:59 UTC, Ricardo Ferreira
Details
/proc/iomem of kernel with commit pointed out by git reverted (1.94 KB, text/plain)
2009-08-25 23:03 UTC, Ricardo Ferreira
Details
/proc/iomem of kernel patched with patch from this bugreport (1.97 KB, text/plain)
2009-08-25 23:06 UTC, Ricardo Ferreira
Details
dmesg of not wroking kernel booted with "debug pci=earlydump" (88.90 KB, text/plain)
2009-08-26 16:54 UTC, Ricardo Ferreira
Details
dmesg of not wroking kernel booted with "pci=nommconf" (62.96 KB, text/plain)
2009-08-27 12:57 UTC, Ricardo Ferreira
Details
acpidump output of non-working 2.6.31-rc7 (205.72 KB, text/plain)
2009-08-31 15:57 UTC, Ricardo Ferreira
Details
2.6.32-rc3 revert of 5d423ccd7ba4285f1084e91b26805e1d0ae978ed (1.45 KB, patch)
2009-10-06 03:20 UTC, Len Brown
Details | Diff
increase the alignment (889 bytes, patch)
2009-10-11 21:22 UTC, Yinghai Lu
Details | Diff
Kernel booted with pci=earlydump CONFIG_PCI_DEBUG=y and Bjorn's patch (317.63 KB, text/x-log)
2009-10-13 19:00 UTC, Ricardo Ferreira
Details
Kernel booted with pci=earlydump,use_crs CONFIG_PCI_DEBUG=y and Bjorn's patch (109.96 KB, text/x-log)
2009-10-13 19:01 UTC, Ricardo Ferreira
Details
lspci from not-working 2.6.31 boot (11.06 KB, text/plain)
2009-10-13 19:57 UTC, Bjorn Helgaas
Details
2.6.30 dmesg (working) (47.62 KB, text/plain)
2011-08-18 21:50 UTC, Bjorn Helgaas
Details
2.6.31 dmesg (not working) (48.79 KB, text/plain)
2011-08-18 21:51 UTC, Bjorn Helgaas
Details
2.6.31 dmesg with acpi=off (working) (41.63 KB, text/plain)
2011-08-18 21:52 UTC, Bjorn Helgaas
Details

Description Rafael J. Wysocki 2009-08-09 21:31:29 UTC
Subject    : Regression in ACPI in 2.6.31-rc5
Submitter  : Ricardo Jorge da Fonseca Marques Ferreira <storm@sys49152.net>
Date       : 2009-08-07 22:33
References : http://marc.info/?l=linux-kernel&m=124968457731107&w=4

This entry is being used for tracking a regression from 2.6.30.  Please don't
close it until the problem is fixed in the mainline.
Comment 1 Rafael J. Wysocki 2009-08-20 14:58:14 UTC
On Thursday 20 August 2009, Ricardo Jorge da Fonseca Marques Ferreira wrote:
> Yes, 2.6.31-rc6 still has the bug.
> 
> On Wednesday 19 August 2009, Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> > 
> > The following bug entry is on the current list of known regressions
> > from 2.6.30.  Please verify if it still should be listed and let me know
> > (either way).
> > 
> > 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13940
> > Subject		: iwlagn and sky2 stopped working, ACPI-related
> > Submitter	: Ricardo Jorge da Fonseca Marques Ferreira <storm@sys49152.net>
> > Date		: 2009-08-07 22:33 (13 days old)
> > References	: http://marc.info/?l=linux-kernel&m=124968457731107&w=4
Comment 2 Chuck Ebbert 2009-08-25 15:54:11 UTC
Can you attach the contents of /proc/iomem from both the working and broken kernels?

From the original report:

[    7.878413] sky2 driver version 1.23
[    7.884402] sky2 0000:07:00.0: enabling device (0000 -> 0003)
[    7.889483] sky2 0000:07:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[    7.894502] sky2 0000:07:00.0: setting latency timer to 64
[    7.894555] sky2 0000:07:00.0: unsupported chip type 0xff
[    7.899554] sky2 0000:07:00.0: PCI INT A disabled
[    7.904379] sky2: probe of 0000:07:00.0 failed with error -95

It looks like the PCI reads are returning all 1's, indicating failed/broken allocations.
Comment 3 Yinghai Lu 2009-08-25 17:57:38 UTC
bugzilla-daemon@bugzilla.kernel.org wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=13940
> 
> 
> Chuck Ebbert <cebbert@redhat.com> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |yinghai@kernel.org
> 
> 
> 
> 


[    0.000000] BIOS-provided physical RAM map:
[    0.000000]  BIOS-e820: 0000000000000000 - 000000000009f400 (usable)
[    0.000000]  BIOS-e820: 000000000009f400 - 00000000000a0000 (reserved)
[    0.000000]  BIOS-e820: 00000000000d2000 - 00000000000d4000 (reserved)
[    0.000000]  BIOS-e820: 00000000000dc000 - 0000000000100000 (reserved)
[    0.000000]  BIOS-e820: 0000000000100000 - 00000000b5aa1000 (usable)
[    0.000000]  BIOS-e820: 00000000b5aa1000 - 00000000b5aa7000 (reserved)
[    0.000000]  BIOS-e820: 00000000b5aa7000 - 00000000b5bba000 (usable)
[    0.000000]  BIOS-e820: 00000000b5bba000 - 00000000b5c0f000 (reserved)
[    0.000000]  BIOS-e820: 00000000b5c0f000 - 00000000b5d08000 (usable)
[    0.000000]  BIOS-e820: 00000000b5d08000 - 00000000b5f0f000 (reserved)
[    0.000000]  BIOS-e820: 00000000b5f0f000 - 00000000b5f18000 (usable)
[    0.000000]  BIOS-e820: 00000000b5f18000 - 00000000b5f1f000 (reserved)
[    0.000000]  BIOS-e820: 00000000b5f1f000 - 00000000b5f65000 (usable)
[    0.000000]  BIOS-e820: 00000000b5f65000 - 00000000b5f9f000 (ACPI NVS)
[    0.000000]  BIOS-e820: 00000000b5f9f000 - 00000000b5fe1000 (usable)
[    0.000000]  BIOS-e820: 00000000b5fe1000 - 00000000b5fff000 (ACPI data)
[    0.000000]  BIOS-e820: 00000000b5fff000 - 00000000b6000000 (usable)
[    0.000000]  BIOS-e820: 0000000100000000 - 0000000140000000 (usable)

some devices don't get allocated resources from BIOS

[    0.819921] pci 0000:00:1f.3: reg 10 64bit mmio: [0x000000-0x0000ff]
[    0.819939] pci 0000:00:1f.3: reg 20 io port: [0x1c00-0x1c1f]
[    0.820029] pci 0000:00:1c.0: bridge io port: [0x00-0xfff]
[    0.820033] pci 0000:00:1c.0: bridge 32bit mmio: [0x000000-0x0fffff]
[    0.820041] pci 0000:00:1c.0: bridge 64bit mmio pref: [0x000000-0x0fffff]
[    0.820113] pci 0000:07:00.0: reg 10 64bit mmio: [0x000000-0x003fff]
[    0.820123] pci 0000:07:00.0: reg 18 io port: [0x00-0xff]
[    0.820203] pci 0000:07:00.0: supports D1 D2
[    0.820204] pci 0000:07:00.0: PME# supported from D0 D1 D2 D3hot D3cold
[    0.820213] pci 0000:07:00.0: PME# disabled
[    0.820289] pci 0000:00:1c.4: bridge io port: [0x00-0xfff]
[    0.820294] pci 0000:00:1c.4: bridge 32bit mmio: [0x000000-0x0fffff]
[    0.820301] pci 0000:00:1c.4: bridge 64bit mmio pref: [0x000000-0x0fffff]
[    0.820388] pci 0000:08:00.0: reg 10 64bit mmio: [0x000000-0x001fff]
[    0.820501] pci 0000:08:00.0: PME# supported from D0 D3hot D3cold
[    0.820510] pci 0000:08:00.0: PME# disabled
[    0.820593] pci 0000:00:1c.5: bridge io port: [0x00-0xfff]
[    0.820598] pci 0000:00:1c.5: bridge 32bit mmio: [0x000000-0x0fffff]
[    0.820605] pci 0000:00:1c.5: bridge 64bit mmio pref: [0x000000-0x0fffff]


will be in
[    0.000000] Allocating PCI resources starting at b6000000 (gap: b6000000:4a000000)

[    7.878413] sky2 driver version 1.23
[    7.884402] sky2 0000:07:00.0: enabling device (0000 -> 0003)
[    7.889483] sky2 0000:07:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[    7.894502] sky2 0000:07:00.0: setting latency timer to 64
[    7.894555] sky2 0000:07:00.0: unsupported chip type 0xff
[    7.899554] sky2 0000:07:00.0: PCI INT A disabled
[    7.904379] sky2: probe of 0000:07:00.0 failed with error -95

[    8.857709] iwlagn: Intel(R) Wireless WiFi Link AGN driver for Linux, 1.3.27kds
[    8.863357] iwlagn: Copyright(c) 2003-2009 Intel Corporation
[    8.875763] iwlagn 0000:08:00.0: enabling device (0000 -> 0002)
[    8.881477] iwlagn 0000:08:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
[    8.887083] iwlagn 0000:08:00.0: setting latency timer to 64
[    8.887128] iwlagn 0000:08:00.0: Detected Intel Wireless WiFi Link 5100AGN REV=0xFDFFFFFF
[    8.892723]   alloc irq_desc for 22 on node 0
[    8.892726]   alloc kstat_irqs on node 0
[    9.073995] iwlagn 0000:08:00.0: Failed, HW not ready
[    9.080292] iwlagn 0000:08:00.0: PCI INT A disabled


07:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8040 PCI-E Fast Ethernet Controller (rev \
12)  Subsystem: Toshiba America Info Systems Device ff50
...
	Memory at b6000000 (64-bit, non-prefetchable) [size=16K]
	I/O ports at 2000 [size=256]
...

08:00.0 Network controller: Intel Corporation Wireless WiFi Link 5100
...
	Memory at b6100000 (64-bit, non-prefetchable) [size=8K]
...



please try to attached patch, that will increae alignment from 32M to 64M.

---
 arch/x86/kernel/e820.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Index: linux-2.6/arch/x86/kernel/e820.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/e820.c
+++ linux-2.6/arch/x86/kernel/e820.c
@@ -1378,8 +1378,8 @@ static unsigned long ram_alignment(resou
 	if (mb < 16)
 		return 1024*1024;
 
-	/* To 32MB for anything above that */
-	return 32*1024*1024;
+	/* To 64MB for anything above that */
+	return 64*1024*1024;
 }
 
 #define MAX_RESOURCE_SIZE ((resource_size_t)-1)
Comment 4 Linus Torvalds 2009-08-25 18:42:43 UTC
On Tue, 25 Aug 2009, Yinghai Lu wrote:
> 
> please try to attached patch, that will increae alignment from 32M to 64M.

Hmm. That may indeed fix the problem, because we have:

 - working-2.6.30.log:

	Allocating PCI resources starting at b8000000 (gap: b6000000:4a000000)

 - not-working-2.6.31.log:

	Allocating PCI resources starting at b6000000 (gap: b6000000:4a000000)

HOWEVER. We also have:

 - working-2.6.31_acpi=off.log:

	Allocating PCI resources starting at b6000000 (gap: b6000000:4a000000)

ie it really does seem to be ACPI-related somehow: starting PCI 
allocations at that b6000000 address works perfectly fine if ACPI is not 
enabled.

In the not-working version, we end up getting:

[    1.408588] pci 0000:00:1c.4: PCI bridge, secondary bus 0000:07
[    1.408593] pci 0000:00:1c.4:   IO window: 0x2000-0x2fff
[    1.408600] pci 0000:00:1c.4:   MEM window: 0xb6000000-0xb60fffff
[    1.408606] pci 0000:00:1c.4:   PREFETCH window: disabled
[    1.408623] pci 0000:00:1c.5: PCI bridge, secondary bus 0000:08
[    1.408626] pci 0000:00:1c.5:   IO window: disabled
[    1.408633] pci 0000:00:1c.5:   MEM window: 0xb6100000-0xb61fffff
[    1.408639] pci 0000:00:1c.5:   PREFETCH window: disabled


while in the working version we have:

 - ACPI off - looks like a BIOS allocated memory window:

	[    0.290854] pci 0000:00:1c.4: PCI bridge, secondary bus 0000:07
	[    0.290854] pci 0000:00:1c.4:   IO window: 0x3000-0x3fff
	[    0.290854] pci 0000:00:1c.4:   MEM window: 0xf4500000-0xf45fffff
	[    0.290854] pci 0000:00:1c.4:   PREFETCH window: disabled
	[    0.290854] pci 0000:00:1c.5: PCI bridge, secondary bus 0000:08
	[    0.290854] pci 0000:00:1c.5:   IO window: disabled
	[    0.290854] pci 0000:00:1c.5:   MEM window: 0xf4600000-0xf46fffff
	[    0.290854] pci 0000:00:1c.5:   PREFETCH window: disabled

 - ACPI on - we allocated the memory window, but at 0xb8000000+, rather 
   than directly after end-of-RAM:

	[    0.842970] pci 0000:00:1c.4: PCI bridge, secondary bus 0000:07
	[    0.842975] pci 0000:00:1c.4:   IO window: 0x2000-0x2fff
	[    0.842983] pci 0000:00:1c.4:   MEM window: 0xb8000000-0xb80fffff
	[    0.842989] pci 0000:00:1c.4:   PREFETCH window: disabled
	[    0.843012] pci 0000:00:1c.5: PCI bridge, secondary bus 0000:08
	[    0.843016] pci 0000:00:1c.5:   IO window: disabled
	[    0.843023] pci 0000:00:1c.5:   MEM window: 0xb8100000-0xb81fffff
	[    0.843029] pci 0000:00:1c.5:   PREFETCH window: disabled

ie for some reason ACPI caused that bus to be re-allocated, and 
re-allocating it right after the memory window doesn't work.

Crazy.

I wonder what is hiding at that 0xb6000000 address. And while I think that 
in this case rounding up to 64MB will fix it, I worry that our old model 
(of never starting directly after RAM, even if it was aligned) may not 
have been safer.

		Linus
Comment 5 Yinghai Lu 2009-08-25 19:01:22 UTC
Linus Torvalds wrote:
> 
> On Tue, 25 Aug 2009, Yinghai Lu wrote:
>> please try to attached patch, that will increae alignment from 32M to 64M.
> 
> Hmm. That may indeed fix the problem, because we have:
> 
>  - working-2.6.30.log:
> 
> 	Allocating PCI resources starting at b8000000 (gap: b6000000:4a000000)
> 
>  - not-working-2.6.31.log:
> 
> 	Allocating PCI resources starting at b6000000 (gap: b6000000:4a000000)
> 
> HOWEVER. We also have:
> 
>  - working-2.6.31_acpi=off.log:
> 
> 	Allocating PCI resources starting at b6000000 (gap: b6000000:4a000000)
> 
> ie it really does seem to be ACPI-related somehow: starting PCI 
> allocations at that b6000000 address works perfectly fine if ACPI is not 
> enabled.
> 
> In the not-working version, we end up getting:
> 
> [    1.408588] pci 0000:00:1c.4: PCI bridge, secondary bus 0000:07
> [    1.408593] pci 0000:00:1c.4:   IO window: 0x2000-0x2fff
> [    1.408600] pci 0000:00:1c.4:   MEM window: 0xb6000000-0xb60fffff
> [    1.408606] pci 0000:00:1c.4:   PREFETCH window: disabled
> [    1.408623] pci 0000:00:1c.5: PCI bridge, secondary bus 0000:08
> [    1.408626] pci 0000:00:1c.5:   IO window: disabled
> [    1.408633] pci 0000:00:1c.5:   MEM window: 0xb6100000-0xb61fffff
> [    1.408639] pci 0000:00:1c.5:   PREFETCH window: disabled
> 
> 
> while in the working version we have:
> 
>  - ACPI off - looks like a BIOS allocated memory window:
> 
> 	[    0.290854] pci 0000:00:1c.4: PCI bridge, secondary bus 0000:07
> 	[    0.290854] pci 0000:00:1c.4:   IO window: 0x3000-0x3fff
> 	[    0.290854] pci 0000:00:1c.4:   MEM window: 0xf4500000-0xf45fffff
> 	[    0.290854] pci 0000:00:1c.4:   PREFETCH window: disabled
> 	[    0.290854] pci 0000:00:1c.5: PCI bridge, secondary bus 0000:08
> 	[    0.290854] pci 0000:00:1c.5:   IO window: disabled
> 	[    0.290854] pci 0000:00:1c.5:   MEM window: 0xf4600000-0xf46fffff
> 	[    0.290854] pci 0000:00:1c.5:   PREFETCH window: disabled

interesting, when acpi=off, BIOS does allocate resource for them

[    0.261960] pci 0000:07:00.0: reg 10 64bit mmio: [0xf4500000-0xf4503fff]
[    0.261970] pci 0000:07:00.0: reg 18 io port: [0x3000-0x30ff]
[    0.262049] pci 0000:07:00.0: supports D1 D2
[    0.262051] pci 0000:07:00.0: PME# supported from D0 D1 D2 D3hot D3cold
[    0.262058] pci 0000:07:00.0: PME# disabled
[    0.272117] pci 0000:00:1c.4: bridge io port: [0x3000-0x3fff]
[    0.272122] pci 0000:00:1c.4: bridge 32bit mmio: [0xf4500000-0xf45fffff]
[    0.272212] pci 0000:08:00.0: reg 10 64bit mmio: [0xf4600000-0xf4601fff]
[    0.272321] pci 0000:08:00.0: PME# supported from D0 D3hot D3cold
[    0.272330] pci 0000:08:00.0: PME# disabled
[    0.280128] pci 0000:00:1c.5: bridge 32bit mmio: [0xf4600000-0xf46fffff]


> 
>  - ACPI on - we allocated the memory window, but at 0xb8000000+, rather 
>    than directly after end-of-RAM:
> 
> 	[    0.842970] pci 0000:00:1c.4: PCI bridge, secondary bus 0000:07
> 	[    0.842975] pci 0000:00:1c.4:   IO window: 0x2000-0x2fff
> 	[    0.842983] pci 0000:00:1c.4:   MEM window: 0xb8000000-0xb80fffff
> 	[    0.842989] pci 0000:00:1c.4:   PREFETCH window: disabled
> 	[    0.843012] pci 0000:00:1c.5: PCI bridge, secondary bus 0000:08
> 	[    0.843016] pci 0000:00:1c.5:   IO window: disabled
> 	[    0.843023] pci 0000:00:1c.5:   MEM window: 0xb8100000-0xb81fffff
> 	[    0.843029] pci 0000:00:1c.5:   PREFETCH window: disabled
> 
> ie for some reason ACPI caused that bus to be re-allocated, and 
> re-allocating it right after the memory window doesn't work.
> 
> Crazy.
> 
> I wonder what is hiding at that 0xb6000000 address. And while I think that 
> in this case rounding up to 64MB will fix it, I worry that our old model 
> (of never starting directly after RAM, even if it was aligned) may not 
> have been safer.
> 

acpi does clear sth.

YH
Comment 6 Ricardo Ferreira 2009-08-25 22:42:37 UTC
(In reply to comment #3)
> please try to attached patch, that will increae alignment from 32M to 64M.

Yes, that patch fixes the problem.

About acpi=off, it also fixes the problem but my laptop feels extremely slow when running a kernel without acpi.
Comment 7 Ricardo Ferreira 2009-08-25 22:57:54 UTC
(In reply to comment #2)
> Can you attach the contents of /proc/iomem from both the working and broken
> kernels?

I'll attach three files:

iomem_not_working.log - /proc/iomem of unpatched kernel.
iomem_working_bisect.log - /proc/iomem with commit pointed out by git reverted.
iomem_working.log - /proc/iomem with patch from this page.
Comment 8 Ricardo Ferreira 2009-08-25 22:59:33 UTC
Created attachment 22842 [details]
/proc/iomem of unpatched kernel
Comment 9 Ricardo Ferreira 2009-08-25 23:03:24 UTC
Created attachment 22843 [details]
/proc/iomem of kernel with commit pointed out by git reverted
Comment 10 Ricardo Ferreira 2009-08-25 23:06:22 UTC
Created attachment 22844 [details]
/proc/iomem of kernel patched with patch from this bugreport
Comment 11 Yinghai Lu 2009-08-26 09:23:18 UTC
bugzilla-daemon@bugzilla.kernel.org wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=13940
> 
> 
> Ricardo Ferreira <bugzillas@sys49152.net> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |bugzillas@sys49152.net
> 
> 
> 
> 
> --- Comment #6 from Ricardo Ferreira <bugzillas@sys49152.net>  2009-08-25 22:42:37 ---
> (In reply to comment #3)
>> please try to attached patch, that will increae alignment from 32M to 64M.
> 
> Yes, that patch fixes the problem.
> 
> About acpi=off, it also fixes the problem but my laptop feels extremely slow
> when running a kernel without acpi.
> 

can boot the system with "debug pci=earlydump" ?

YH
Comment 12 Ricardo Ferreira 2009-08-26 16:54:49 UTC
Created attachment 22864 [details]
dmesg of not wroking kernel booted with "debug pci=earlydump"

This is of the 2.6.31-rc6 kernel with neither the patch applied or the commit reverted.
Comment 13 Yinghai Lu 2009-08-26 17:45:11 UTC
bugzilla-daemon@bugzilla.kernel.org wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=13940
> 
> 
> 
> 
> 
> --- Comment #12 from Ricardo Ferreira <bugzillas@sys49152.net>  2009-08-26 16:54:49 ---
> Created an attachment (id=22864)
>  --> (http://bugzilla.kernel.org/attachment.cgi?id=22864)
> dmesg of not wroking kernel booted with "debug pci=earlydump"
> 
> This is of the 2.6.31-rc6 kernel with neither the patch applied or the commit
> reverted.
> 

[    0.000000] pci 0000:07:00.0 config space:
[    0.000000]   00: ab 11 55 43 07 00 10 00 12 00 00 02 10 00 00 00
[    0.000000]   10: 04 00 50 f4 00 00 00 00 01 30 00 00 00 00 00 00
[    0.000000]   20: 00 00 00 00 00 00 00 00 00 00 00 00 79 11 50 ff
[    0.000000]   30: 00 00 00 00 48 00 00 00 00 00 00 00 0b 01 00 00
[    0.000000]   40: 00 00 b0 84 09 c0 a0 01 01 5c 03 fe 00 20 00 13
[    0.000000]   50: 03 5c 00 80 00 00 00 00 00 00 04 00 05 c0 80 00
[    0.000000]   60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    0.000000]   70: 00 07 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    0.000000]   80: 00 00 00 00 00 30 00 00 00 00 00 00 82 a8 e8 00
[    0.000000]   90: 00 00 00 00 00 00 00 00 a0 25 26 00 00 00 00 00
[    0.000000]   a0: f6 00 00 ff 40 00 08 01 0c 31 33 40 04 0a 10 44
[    0.000000]   b0: 00 00 00 05 00 00 60 20 fa 00 00 00 00 00 00 00
[    0.000000]   c0: 10 00 12 00 c0 8f 04 05 00 20 19 00 11 ac 07 00
[    0.000000]   d0: 48 01 11 10 00 00 00 00 00 00 00 00 00 00 00 00
[    0.000000]   e0: 00 00 00 00 10 00 00 00 00 00 00 00 00 00 00 00
[    0.000000]   f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    0.000000] pci 0000:08:00.0 config space:
[    0.000000]   00: 86 80 32 42 06 00 10 00 00 00 80 02 10 00 00 00
[    0.000000]   10: 04 00 60 f4 00 00 00 00 00 00 00 00 00 00 00 00
[    0.000000]   20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 01 12
[    0.000000]   30: 00 00 00 00 c8 00 00 00 00 00 00 00 05 01 00 00
[    0.000000]   40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    0.000000]   50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    0.000000]   60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    0.000000]   70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    0.000000]   80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    0.000000]   90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    0.000000]   a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    0.000000]   b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    0.000000]   c0: 00 00 00 00 00 00 00 00 01 d0 23 c8 00 00 00 0d
[    0.000000]   d0: 05 e0 80 00 00 00 00 00 00 00 00 00 00 00 00 00
[    0.000000]   e0: 10 00 01 00 c0 8e 00 10 10 08 19 00 11 9c 06 00
[    0.000000]   f0: 40 01 11 10 00 00 00 00 00 00 00 00 00 00 00 00


[    0.815933] pci 0000:07:00.0: reg 10 64bit mmio: [0x000000-0x003fff]
[    0.815946] pci 0000:07:00.0: reg 18 io port: [0x00-0xff]
[    0.816029] pci 0000:07:00.0: supports D1 D2
[    0.816033] pci 0000:07:00.0: PME# supported from D0 D1 D2 D3hot D3cold
[    0.816041] pci 0000:07:00.0: PME# disabled
[    0.816223] pci 0000:08:00.0: reg 10 64bit mmio: [0x000000-0x001fff]
[    0.816339] pci 0000:08:00.0: PME# supported from D0 D3hot D3cold
[    0.816348] pci 0000:08:00.0: PME# disabled

not sure it is caused by acpi or mmconf...

please try to boot with pci=nommconf

YH
Comment 14 Ricardo Ferreira 2009-08-26 22:31:19 UTC
Doesn't work with pci=nommconf. The messages from the drivers are the same as the original non-working kernel.
Comment 15 Yinghai Lu 2009-08-27 04:32:37 UTC
bugzilla-daemon@bugzilla.kernel.org wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=13940
>
>
>
>
>
> --- Comment #12 from Ricardo Ferreira <bugzillas@sys49152.net>   
> 2009-08-26 16:54:49 ---
> Created an attachment (id=22864)
> --> (http://bugzilla.kernel.org/attachment.cgi?id=22864)
> dmesg of not wroking kernel booted with "debug pci=earlydump"
>
> This is of the 2.6.31-rc6 kernel with neither the patch applied or  
> the commit
> reverted.
>

[    0.000000] pci 0000:07:00.0 config space:
[    0.000000]   00: ab 11 55 43 07 00 10 00 12 00 00 02 10 00 00 00
[    0.000000]   10: 04 00 50 f4 00 00 00 00 01 30 00 00 00 00 00 00
[    0.000000]   20: 00 00 00 00 00 00 00 00 00 00 00 00 79 11 50 ff
[    0.000000]   30: 00 00 00 00 48 00 00 00 00 00 00 00 0b 01 00 00
[    0.000000]   40: 00 00 b0 84 09 c0 a0 01 01 5c 03 fe 00 20 00 13
[    0.000000]   50: 03 5c 00 80 00 00 00 00 00 00 04 00 05 c0 80 00
[    0.000000]   60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    0.000000]   70: 00 07 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    0.000000]   80: 00 00 00 00 00 30 00 00 00 00 00 00 82 a8 e8 00
[    0.000000]   90: 00 00 00 00 00 00 00 00 a0 25 26 00 00 00 00 00
[    0.000000]   a0: f6 00 00 ff 40 00 08 01 0c 31 33 40 04 0a 10 44
[    0.000000]   b0: 00 00 00 05 00 00 60 20 fa 00 00 00 00 00 00 00
[    0.000000]   c0: 10 00 12 00 c0 8f 04 05 00 20 19 00 11 ac 07 00
[    0.000000]   d0: 48 01 11 10 00 00 00 00 00 00 00 00 00 00 00 00
[    0.000000]   e0: 00 00 00 00 10 00 00 00 00 00 00 00 00 00 00 00
[    0.000000]   f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    0.000000] pci 0000:08:00.0 config space:
[    0.000000]   00: 86 80 32 42 06 00 10 00 00 00 80 02 10 00 00 00
[    0.000000]   10: 04 00 60 f4 00 00 00 00 00 00 00 00 00 00 00 00
[    0.000000]   20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 01 12
[    0.000000]   30: 00 00 00 00 c8 00 00 00 00 00 00 00 05 01 00 00
[    0.000000]   40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    0.000000]   50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    0.000000]   60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    0.000000]   70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    0.000000]   80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    0.000000]   90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    0.000000]   a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    0.000000]   b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    0.000000]   c0: 00 00 00 00 00 00 00 00 01 d0 23 c8 00 00 00 0d
[    0.000000]   d0: 05 e0 80 00 00 00 00 00 00 00 00 00 00 00 00 00
[    0.000000]   e0: 10 00 01 00 c0 8e 00 10 10 08 19 00 11 9c 06 00
[    0.000000]   f0: 40 01 11 10 00 00 00 00 00 00 00 00 00 00 00 00


[    0.815933] pci 0000:07:00.0: reg 10 64bit mmio: [0x000000-0x003fff]
[    0.815946] pci 0000:07:00.0: reg 18 io port: [0x00-0xff]
[    0.816029] pci 0000:07:00.0: supports D1 D2
[    0.816033] pci 0000:07:00.0: PME# supported from D0 D1 D2 D3hot  
D3cold
[    0.816041] pci 0000:07:00.0: PME# disabled
[    0.816223] pci 0000:08:00.0: reg 10 64bit mmio: [0x000000-0x001fff]
[    0.816339] pci 0000:08:00.0: PME# supported from D0 D3hot D3cold
[    0.816348] pci 0000:08:00.0: PME# disabled

not sure it is caused by acpi or mmconf...

please try to boot with pci=nommconf

YH
Comment 16 Ricardo Ferreira 2009-08-27 12:57:45 UTC
Created attachment 22881 [details]
dmesg of not wroking kernel booted with "pci=nommconf"
Comment 17 ykzhao 2009-08-31 13:21:43 UTC
From the dmesg log it seems that this issue is very interesting. And agree with what Yu Linghai pointed in comment #13.

In the phase of dump pci conf register, we can get the IO/Memory base/limit for 0:1c.x/07:0.0/08:0.0 pci devices.
    For example: 
    07:0.0: memory space: [0xf4500000-0xf4503fff]
            IO space [0x3000-0x30ff]

But after the acpi is enabled, we can get the different IO/memory base/limit for the above pci devices.
    07:0.0: memory space: [0-0x3fff]
            I/O space [0-0xff]

In such case OS will reallocate the memory space for the above pci devices. 
Why will we get the different IO/MEM base for the same pci devices before and after acpi is enabled?
Comment 18 ykzhao 2009-08-31 13:37:51 UTC
Another issue is that the memory region from 0xb6000000 can't be used for the PCI space region if the acpi is enabled.

Is this region accessed by AML code when ACPI is enabled?

Can someone attach the output of acpidump on this box?
Thanks.
Comment 19 Ricardo Ferreira 2009-08-31 15:57:34 UTC
Created attachment 22932 [details]
acpidump output of non-working 2.6.31-rc7
Comment 20 Ricardo Ferreira 2009-09-02 15:59:40 UTC
Still not working with 2.6.31-rc8
Comment 21 Zhang Rui 2009-09-03 03:22:32 UTC
what't the model of this laptop?
Comment 22 Ricardo Ferreira 2009-09-03 08:21:44 UTC
The laptop is a Toshiba U400-17b. It has the latest BIOS (4.00) available from Toshiba.
Comment 23 Ricardo Ferreira 2009-09-04 21:19:41 UTC
Just found another sideeffect of this bug. Suspend to RAM doesn't work in all the non-working kernels but works in the others.
Comment 24 Rafael J. Wysocki 2009-09-10 23:03:02 UTC
On Sunday 06 September 2009, Ricardo Jorge da Fonseca Marques Ferreira wrote:
> On Sunday 06 September 2009, Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> > 
> > The following bug entry is on the current list of known regressions
> > from 2.6.30.  Please verify if it still should be listed and let me know
> > (either way).
> 
> Yes, the regression is still present.
Comment 25 Jose 2009-09-29 11:42:57 UTC
I had the same problem with the Mandriva Linux 2.6.31.1 kernel, and the patch indicated in this bug (32->64) worked. Hardware is a laptop : Acer Aspire 8935G .
Comment 26 Ricardo Ferreira 2009-10-01 02:46:36 UTC
Right now i'm modifying the kernel SRPMS of OpenSuSE with the patch because the final 2.6.31 still contains the bug. With this bug my laptop has non-working ethernet, wireless and suspend to RAM.

I'm sure this bug is affecting much more people that don't know how to report the bug.
Comment 27 Len Brown 2009-10-06 03:20:22 UTC
Created attachment 23280 [details]
2.6.32-rc3 revert of 5d423ccd7ba4285f1084e91b26805e1d0ae978ed

Ricardo reports here

http://marc.info/?l=linux-acpi&m=125039173717813&w=4

"git bisect tells me that commit 5d423ccd7ba4285f1084e91b26805e1d0ae978ed 
(x86/pci: remove rounding quirk from e820_setup_gap()) caused the problem."

So the attachment is a patch containing that commit reverted from 2.6.32-rc3.
Comment 28 Yinghai Lu 2009-10-06 04:15:08 UTC
that is right fix. 
looks like you like to put the cover back to hide the bug.

need to root cause why some BARs are cleared when ACPI subsystem is enabled.

YH
Comment 29 Andrea Orrù 2009-10-11 11:05:22 UTC
I'm experiencing this (very annoying) bug. Will the fix be included in the 2.6.31.4 kernel?
Comment 30 Yinghai Lu 2009-10-11 21:22:52 UTC
Created attachment 23346 [details]
increase the alignment

this should have enough space for unassigned devices.
Comment 31 Rafael J. Wysocki 2009-10-11 22:14:49 UTC
Handled-By : Len Brown <lenb@kernel.org>
Patch : http://bugzilla.kernel.org/attachment.cgi?id=23280
Comment 33 Andrea Orrù 2009-10-12 13:34:17 UTC
At the risk of being insistent: will the next 2.6.31.x patch fix this bug?
Comment 34 Ricardo Ferreira 2009-10-13 19:00:19 UTC
Created attachment 23394 [details]
Kernel booted with pci=earlydump CONFIG_PCI_DEBUG=y and Bjorn's patch
Comment 35 Ricardo Ferreira 2009-10-13 19:01:14 UTC
Created attachment 23395 [details]
Kernel booted with pci=earlydump,use_crs CONFIG_PCI_DEBUG=y and Bjorn's patch
Comment 36 Ricardo Ferreira 2009-10-13 19:04:48 UTC
I patched the latest git tree with Bjorn Helgaas's patch and got the debug info he requested in the email message.

I was not able to get the resources windows uses, because i do not have windows installed in this laptop.

On the bright side, booting with pci=use_crs in both the latest kernel and 2.6.31 fixes the problem.
Comment 37 Bjorn Helgaas 2009-10-13 19:57:02 UTC
Created attachment 23396 [details]
lspci from not-working 2.6.31 boot

From the original report at http://marc.info/?l=linux-kernel&m=124968457731107&w=4
Comment 38 Yinghai Lu 2009-10-14 07:06:24 UTC
before EC code that BAR 0x10 is cleared already.

[    0.109022] pci 0000:07:00.0 config space:
[    0.109025]   00: ab 11 55 43 00 00 10 00 12 00 00 02 10 00 00 00
[    0.109045]   10: 04 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00
[    0.109063]   20: 00 00 00 00 00 00 00 00 00 00 00 00 79 11 50 ff
[    0.109081]   30: 00 00 00 00 48 00 00 00 00 00 00 00 0b 01 00 00
[    0.109100]   40: 00 00 b0 80 09 c0 a0 01 01 5c 03 fe 00 20 00 13
[    0.109119]   50: 03 5c 00 80 00 00 00 00 00 00 04 00 05 c0 80 00
[    0.109137]   60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    0.109155]   70: 00 07 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    0.109174]   80: 00 00 00 00 15 30 ff 68 4a 03 4a 03 82 a8 e8 00
[    0.109192]   90: 00 00 00 00 03 01 f6 01 a0 25 26 00 00 00 00 00
[    0.109211]   a0: f6 00 00 ff 40 00 08 01 0c 31 33 40 04 0a 10 44
[    0.109230]   b0: 00 00 00 05 00 00 60 20 fa 00 00 00 00 00 00 00
[    0.109248]   c0: 10 00 12 00 c0 8f 04 05 00 20 19 00 11 ac 07 00
[    0.109267]   d0: 48 01 11 10 00 00 00 00 00 00 00 00 00 00 00 00
[    0.109286]   e0: 00 00 00 00 10 00 00 00 00 00 00 00 00 00 00 00
[    0.109304]   f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    0.110710] ACPI: EC: Look up EC in DSDT
Comment 39 ykzhao 2009-10-14 07:45:38 UTC
It seems that the BAR is changed when ACPI is enabled.
  In fact the ACPI is enabled by writing some predefined value into SMI command port, which then triggers the SMI. And we can't know what happens in SMI.
  Maybe the BAR is changed by SMI. If so, we can do nothing about it.
   Thanks.
Comment 40 Florian Mickler 2010-12-18 01:09:19 UTC
*** Bug 14450 has been marked as a duplicate of this bug. ***
Comment 41 Bjorn Helgaas 2011-08-18 21:50:51 UTC
Created attachment 69342 [details]
2.6.30 dmesg (working)

Much of the analysis on this bug is based on dmesg logs that aren't attached.  I dug them out of email and am attaching them here for completeness.
Comment 42 Bjorn Helgaas 2011-08-18 21:51:44 UTC
Created attachment 69352 [details]
2.6.31 dmesg (not working)
Comment 43 Bjorn Helgaas 2011-08-18 21:52:25 UTC
Created attachment 69362 [details]
2.6.31 dmesg with acpi=off (working)

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