Bug 13940
|
Description
Rafael J. Wysocki
2009-08-09 21:31:29 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
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. 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) 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
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 (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. (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. Created attachment 22842 [details]
/proc/iomem of unpatched kernel
Created attachment 22843 [details]
/proc/iomem of kernel with commit pointed out by git reverted
Created attachment 22844 [details]
/proc/iomem of kernel patched with patch from this bugreport
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 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.
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 Doesn't work with pci=nommconf. The messages from the drivers are the same as the original non-working kernel. 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 Created attachment 22881 [details]
dmesg of not wroking kernel booted with "pci=nommconf"
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? 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. Created attachment 22932 [details]
acpidump output of non-working 2.6.31-rc7
Still not working with 2.6.31-rc8 what't the model of this laptop? The laptop is a Toshiba U400-17b. It has the latest BIOS (4.00) available from Toshiba. Just found another sideeffect of this bug. Suspend to RAM doesn't work in all the non-working kernels but works in the others. 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.
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 . 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. 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. 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 I'm experiencing this (very annoying) bug. Will the fix be included in the 2.6.31.4 kernel? Created attachment 23346 [details]
increase the alignment
this should have enough space for unassigned devices.
Handled-By : Len Brown <lenb@kernel.org> Patch : http://bugzilla.kernel.org/attachment.cgi?id=23280 At the risk of being insistent: will the next 2.6.31.x patch fix this bug? Created attachment 23394 [details]
Kernel booted with pci=earlydump CONFIG_PCI_DEBUG=y and Bjorn's patch
Created attachment 23395 [details]
Kernel booted with pci=earlydump,use_crs CONFIG_PCI_DEBUG=y and Bjorn's patch
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. 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 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 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. *** Bug 14450 has been marked as a duplicate of this bug. *** 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.
Created attachment 69352 [details]
2.6.31 dmesg (not working)
Created attachment 69362 [details]
2.6.31 dmesg with acpi=off (working)
|