Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Rafael J. Wysocki]

Hi Linus,

For some time I've been having problems with resume from hibernation and
suspend on Toshiba Portege R500 I'm currently testing.  Initially I thought
that was a regression from 2.6.27, because some 2.6.27-based kernels appeared
to work correctly on this box, but today I realized that in fact 2.6.27-rc6
failed too and then I confirmed that the problem was also present in 2.6.27
and in all of the -stable 2.6.27.y kernels.  Still, I was unable to reproduce
the problem with the 2.6.27-rc3 kernel and that made me carry out bisection
between 2.6.27-rc3 and 2.6.27-rc6 that turned up the following commit of yours:

commit 5f17cfce5776c566d64430f543a289e5cfa4538b
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Thu Sep 4 01:33:59 2008 -0700

    PCI: fix pbus_size_mem() resource alignment for CardBus controllers

Following this, I applied the appended patch on top of the current mainline
and it appears to have fixed my hibernation/resume problems on this box
(at least, with the patch applied the box have survived ~20 hibernation/resume
and suspend/resume cycles in a row, which was not achievable with the mainline
without the patch).

The symptoms of the breakage are that sometimes the box hangs solid during
resume, sometimes it hangs but can be rebooted by pressing Alt-SysRq-b, and
sometimes it just powers off while resuming.  Still, it resumes correctly in
about 75% of cases and that made the issue very hard to debug.  [Interestingly
enough, it was not reproducible with snd_hda_intel unloaded, which made me
think it was related to the driver, but evidently it wasn't.]  Also, I'm sure
hibernation is affected, but recently there have been some other sources of
breakage of resume from suspend to RAM, so I'm not so sure to what extent it
is affected too.

Please let me know if you need debug information from the affected box.

Thanks,
Rafael


Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
---
 drivers/pci/setup-bus.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux-2.6/drivers/pci/setup-bus.c
===================================================================
--- linux-2.6.orig/drivers/pci/setup-bus.c
+++ linux-2.6/drivers/pci/setup-bus.c
@@ -352,7 +352,7 @@ static int pbus_size_mem(struct pci_bus 
 				continue;
 			r_size = resource_size(r);
 			/* For bridges size != alignment */
-			align = resource_alignment(r);
+			align = (i < PCI_BRIDGE_RESOURCES) ? r_size : r->start;
 			order = __ffs(align) - 20;
 			if (order > 11) {
 				dev_warn(&dev->dev, "BAR %d bad alignment %llx: "

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Linus Torvalds]

On Tue, 2 Dec 2008, Rafael J. Wysocki wrote:
>  			r_size = resource_size(r);
>  			/* For bridges size != alignment */
> -			align = resource_alignment(r);
> +			align = (i < PCI_BRIDGE_RESOURCES) ? r_size : r->start;

Hmm. This means that something set the alignment flags incorrectly. The 
resource _should_ have IORESOURCE_SIZEALIGN set for a resource with size 
alignment, and IORESOURCE_STARTALIGN for one that has start alignment.

Your patch doesn't fix anything, it just hides the bug.

It would be good to hear what resource this is, and where it got set. So 
instead of that broken patch that just hides the problem, please try to 
debug it with something like

	resource_size_t expected_align;

	expected_align = (i < PCI_BRIDGE_RESOURCES) ? r_size : r->start;
	align = resource_alignment(r);
	if (align != expected_align) {
		dev_warn(&dev->dev,
			"BAR %d %llx-%llx wrong alignment flags %lx %llx (%llx)\n",
			i,
			(unsigned long long) r->start,
			(unsigned long long) r->end,
			r->flags,
			(unsigned long long) align,
			(unsigned long long) expected_align);
		/* Hacky and wrong, but trying to keep things 
		align = expected_align;
	}

or something like that. And then we just need to figure out which setup 
routine sets the wrong alignment flag,.

		Linus

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Linus Torvalds]

On Mon, 1 Dec 2008, Linus Torvalds wrote:
> 
> or something like that. And then we just need to figure out which setup 
> routine sets the wrong alignment flag,.

Oh, btw, one more thing: since it apparently sometimes _does_ resume 
from hibernation without all this, I'd also like to see the actual 
differences in /proc/ioports and /proc/iomem that happen as a result of 
the different alignment. 

I also really suspect we should add a whole "alignment" field to "struct 
resource", instead of the size-vs-start flags. The fact is, some PCI 
devices have alignment that is neither tied to size or anything else: I 
think some PCI bus resources are really always 4kB-aligned, for example 
(and aligning them by size will give a bigger alignment than actually 
required).

			Linus

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Frans Pop]

Hi Linus,

> Your patch doesn't fix anything, it just hides the bug.

> It would be good to hear what resource this is, and where it got set. So 
> instead of that broken patch that just hides the problem, please try to 
> debug it with something like

Your debug patch gives me on boot (hp 2510p; x86_64; current git head):

  system 00:00: iomem range 0x0-0x9ffff could not be reserved
  system 00:00: iomem range 0xe0000-0xfffff could not be reserved
  system 00:00: iomem range 0x100000-0x7e7fffff could not be reserved
  system 00:0a: ioport range 0x500-0x55f has been reserved
  system 00:0a: ioport range 0x800-0x80f has been reserved
  system 00:0a: iomem range 0xffb00000-0xffbfffff has been reserved
  system 00:0a: iomem range 0xfff00000-0xffffffff has been reserved
  system 00:0c: ioport range 0x4d0-0x4d1 has been reserved
  system 00:0c: ioport range 0x2f8-0x2ff has been reserved
  system 00:0c: ioport range 0x3f8-0x3ff has been reserved
  system 00:0c: ioport range 0x1000-0x107f has been reserved
  system 00:0c: ioport range 0x1100-0x113f has been reserved
  system 00:0c: ioport range 0x1200-0x121f has been reserved
  system 00:0c: iomem range 0xf8000000-0xfbffffff has been reserved
  system 00:0c: iomem range 0xfec00000-0xfec000ff has been reserved
  system 00:0c: iomem range 0xfed20000-0xfed3ffff has been reserved
  system 00:0c: iomem range 0xfed45000-0xfed8ffff has been reserved
  system 00:0c: iomem range 0xfed90000-0xfed99fff has been reserved
  system 00:0d: iomem range 0xcee00-0xcffff has been reserved
  system 00:0d: iomem range 0xd2000-0xd3fff has been reserved
  system 00:0d: iomem range 0xfeda0000-0xfedbffff has been reserved
  system 00:0d: iomem range 0xfee00000-0xfee00fff has been reserved
! pci 0000:02:06.0: BAR 9 0-3ffffff wrong alignment flags 21200 4000000 (0)
! pci 0000:02:06.0: BAR 9 bad alignment 0: [0x000000-0x3ffffff]
  pci 0000:00:1c.0: PCI bridge, secondary bus 0000:08
  pci 0000:00:1c.0:   IO window: disabled
  pci 0000:00:1c.0:   MEM window: disabled
  pci 0000:00:1c.0:   PREFETCH window: disabled
  pci 0000:00:1c.1: PCI bridge, secondary bus 0000:10
  pci 0000:00:1c.1:   IO window: disabled
  pci 0000:00:1c.1:   MEM window: 0xe0000000-0xe00fffff
  pci 0000:00:1c.1:   PREFETCH window: disabled
  pci 0000:02:06.0: CardBus bridge, secondary bus 0000:03
  pci 0000:02:06.0:   IO window: 0x003000-0x0030ff
  pci 0000:02:06.0:   IO window: 0x003400-0x0034ff
  pci 0000:02:06.0:   MEM window: 0x80000000-0x83ffffff
  pci 0000:00:1e.0: PCI bridge, secondary bus 0000:02
  pci 0000:00:1e.0:   IO window: 0x3000-0x3fff
  pci 0000:00:1e.0:   MEM window: 0xe0100000-0xe03fffff
  pci 0000:00:1e.0:   PREFETCH window: disabled
  pci 0000:00:1c.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
  pci 0000:00:1c.0: setting latency timer to 64
  pci 0000:00:1c.1: PCI INT B -> GSI 17 (level, low) -> IRQ 17
  pci 0000:00:1c.1: setting latency timer to 64
  pci 0000:00:1e.0: setting latency timer to 64
  pci 0000:02:06.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18

>From lspci -vv:
02:06.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev ba)
        Subsystem: Hewlett-Packard Company Device 30c9
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 168
        Interrupt: pin A routed to IRQ 18
        Region 0: Memory at e0100000 (32-bit, non-prefetchable) [size=4K]
        Bus: primary=02, secondary=03, subordinate=06, sec-latency=176
        Memory window 0: 84400000-847ff000 (prefetchable)
        Memory window 1: 80000000-83fff000
        I/O window 0: 00003000-000030ff
        I/O window 1: 00003400-000034ff
        BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset- 16bInt+ PostWrite+
        16-bit legacy interface ports at 0001
        Kernel driver in use: yenta_cardbus
        Kernel modules: yenta_socket

02:06.1 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev 04) (prog-if 10 [OHCI])
        Subsystem: Hewlett-Packard Company Device 30c9
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 64 (500ns min, 1000ns max), Cache Line Size: 64 bytes
        Interrupt: pin B routed to IRQ 19
        Region 0: Memory at e0101000 (32-bit, non-prefetchable) [size=2K]
        Capabilities: [dc] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=2 PME+
        Kernel driver in use: ohci1394
        Kernel modules: ohci1394

02:06.2 SD Host controller: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 21)
        Subsystem: Hewlett-Packard Company Device 30c9
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 64, Cache Line Size: 64 bytes
        Interrupt: pin C routed to IRQ 20
        Region 0: Memory at e0102000 (32-bit, non-prefetchable) [size=256]
        Capabilities: [80] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=2 PME-
        Kernel driver in use: sdhci-pci
        Kernel modules: sdhci-pci

02:06.3 System peripheral: Ricoh Co Ltd R5C843 MMC Host Controller (rev ff) (prog-if ff)
        !!! Unknown header type 7f
        Kernel driver in use: ricoh-mmc
        Kernel modules: ricoh_mmc

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Frans Pop]

> Oh, btw, one more thing: since it apparently sometimes _does_ resume
> from hibernation without all this, I'd also like to see the actual
> differences in /proc/ioports and /proc/iomem that happen as a result of
> the different alignment.

You're in luck. I still had /proc/io* contents from .28-rc3 lying around 
from working on some other issue.

Here's the relevant diff for iomem; there's no diff for ioports.

--- iomem_2.6.28-rc3    2008-11-03 10:59:37.000000000 +0100
+++ iomem_2.6.28-rc6_linus      2008-12-02 05:20:31.000000000 +0100
@@ -10,10 +10,9 @@
 7e7b0000-7e7c53ff : reserved
 7e7c5400-7e7e7fb7 : ACPI Non-volatile Storage
 7e7e7fb8-7effffff : reserved
-80000000-83ffffff : PCI Bus 0000:02
-  80000000-83ffffff : PCI CardBus 0000:03
-84000000-87ffffff : PCI CardBus 0000:03
-88000000-88000fff : Intel Flush Page
+80000000-83ffffff : PCI CardBus 0000:03
+84000000-84000fff : Intel Flush Page
+84400000-847fffff : PCI CardBus 0000:03
 d0000000-dfffffff : 0000:00:02.0
   d0000000-d076ffff : vesafb
 e0000000-e00fffff : PCI Bus 0000:10

I've tried a few quick suspend/resume cycles and no failures so far, but 
that's not really conclusive yet.

Besides snd_hda_intel I've also been unloading e1000e before suspend 
because I thought it contributed to resume failures. I'm now keeping that 
loaded as well. Will report results.

Cheers,
FJP

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Linus Torvalds]

On Tue, 2 Dec 2008, Frans Pop wrote:
> 
> Your debug patch gives me on boot (hp 2510p; x86_64; current git head):
> 
> ! pci 0000:02:06.0: BAR 9 0-3ffffff wrong alignment flags 21200 4000000 (0)
> ! pci 0000:02:06.0: BAR 9 bad alignment 0: [0x000000-0x3ffffff]

Hmm. flags 21200 means that IORESOURCE_SIZEALIGN is set, and 'align' is 
_correct_ (0x4000000==size), while 'expected_align' is total crap (0).

So at least on your machine, using the expected_align value (which is 
effectively what Rafael's patch does) would definitely be the wrong thing.

Of course, it might then happen to work (because the thing doesn't 
actually need that big alignment at all).

Also:

> From lspci -vv:
> 02:06.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev ba)
>         Subsystem: Hewlett-Packard Company Device 30c9
>         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
>         Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
>         Latency: 168
>         Interrupt: pin A routed to IRQ 18
>         Region 0: Memory at e0100000 (32-bit, non-prefetchable) [size=4K]
>         Bus: primary=02, secondary=03, subordinate=06, sec-latency=176
>         Memory window 0: 84400000-847ff000 (prefetchable)
>         Memory window 1: 80000000-83fff000
>         I/O window 0: 00003000-000030ff
>         I/O window 1: 00003400-000034ff

the above all looks fine, and it apparently works for you.

I'd like to see what Rafael's machine does.

Of course, the thing to keep in mind here is that resource alignment is 
one of those things that changes how PCI resources get laid out, and two 
different layouts may well _both_ be correct - but then one of them may 
not work, because there is some hidden SMI resource that we don't know 
about, or some other stupid BIOS issue where the BIOS is unhappy about how 
we laid things out.

We've had many of those before. And they can easily result in "innocent" 
changes (including real fixes) just then exposing problems that were 
hidden before due to just a subtly different layout.

That's why I'd like to see what the layout differences are for Rafael with 
and without his patch (and also both before and after hibernate/resume). 
Maybe both layouts are "correct", but the non-working one can give us a 
clue about what may be triggering the problem.

			Linus

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Linus Torvalds]

On Tue, 2 Dec 2008, Frans Pop wrote:
> 
> You're in luck. I still had /proc/io* contents from .28-rc3 lying around 
> from working on some other issue.
> 
> Here's the relevant diff for iomem; there's no diff for ioports.
> 
> --- iomem_2.6.28-rc3    2008-11-03 10:59:37.000000000 +0100
> +++ iomem_2.6.28-rc6_linus      2008-12-02 05:20:31.000000000 +0100
> @@ -10,10 +10,9 @@
>  7e7b0000-7e7c53ff : reserved
>  7e7c5400-7e7e7fb7 : ACPI Non-volatile Storage
>  7e7e7fb8-7effffff : reserved
> -80000000-83ffffff : PCI Bus 0000:02
> -  80000000-83ffffff : PCI CardBus 0000:03
> -84000000-87ffffff : PCI CardBus 0000:03
> -88000000-88000fff : Intel Flush Page
> +80000000-83ffffff : PCI CardBus 0000:03
> +84000000-84000fff : Intel Flush Page
> +84400000-847fffff : PCI CardBus 0000:03
>  d0000000-dfffffff : 0000:00:02.0
>    d0000000-d076ffff : vesafb
>  e0000000-e00fffff : PCI Bus 0000:10

I'm not seeing how this could matter. In the latter one, we apparently 
don't set up any PCI bus memory window, but I bet it's a transparent 
bridge, and it shouldn't matter. IOW, your dmesg probably has a line like 
this somewhere:

	pci 0000:00:1e.0: transparent bridge

and whether there is an explicit bus window or not is simply immaterial.

That said, if you can show the differences in dmesg from the two cases, it 
would probably be interesting to see why it happens that way.  Why did we 
bother setting up that PCI bus window in -rc3 at all? Was it there from 
the beginning?

> I've tried a few quick suspend/resume cycles and no failures so far, but 
> that's not really conclusive yet.
> 
> Besides snd_hda_intel I've also been unloading e1000e before suspend 
> because I thought it contributed to resume failures. I'm now keeping that 
> loaded as well. Will report results.

There were some HDA fixes recently, although I don't think they should 
matter for suspend/resume (well, at least a couple of them should fix the 
case of sound being _silent_ on resume, but shouldn't have caused any 
other issues).

		Linus

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Frans Pop]

[-- Attachment #1: Type: text/plain, Size: 762 bytes --]

On Tuesday 02 December 2008, Linus Torvalds wrote:
> That said, if you can show the differences in dmesg from the two cases,
> it would probably be interesting to see why it happens that way.  Why
> did we bother setting up that PCI bus window in -rc3 at all? Was it
> there from the beginning?

Attached is a full diff between dmesg from -rc3 and -rc6 with your debug 
patch.

I've cleaned up the diff a bit to make it more readable (mostly removal of 
changes that I always get due to random USB load order changes - UHCI 
still frequently loads before EHCI).

The most interesting points are probably at lines 298-346 and 639-649.

At the bottom there's a fairly long addition from the few suspend/resume 
cycles I did (again, running with the debug patch).


[-- Attachment #2: rc3-rc6.diff --]
[-- Type: text/x-diff, Size: 94937 bytes --]

--- 2.6.28-rc3	2008-11-03 10:51:51.000000000 +0100
+++ 2.6.28-rc6_linus	2008-12-02 06:12:15.000000000 +0100
@@ -1,676 +1,1625 @@
 BIOS EBDA/lowmem at: 0009fc00/0009fc00
-Linux version 2.6.28-rc3 (root@faramir) (gcc version 4.3.2 (Debian 4.3.2-1) ) #47 SMP Mon Nov 3 10:30:30 CET 2008
+Linux version 2.6.28-rc6 (root@faramir) (gcc version 4.3.2 (Debian 4.3.2-1) ) #58 SMP Tue Dec 2 04:56:59 CET 2008
 Command line: root=/dev/mapper/main-root ro vga=791 quiet
 KERNEL supported cpus:
   Intel GenuineIntel
   AMD AuthenticAMD
   Centaur CentaurHauls
 BIOS-provided physical RAM map:
  BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
  BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
  BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
  BIOS-e820: 0000000000100000 - 000000007e7b0000 (usable)
  BIOS-e820: 000000007e7b0000 - 000000007e7c5400 (reserved)
  BIOS-e820: 000000007e7c5400 - 000000007e7e7fb8 (ACPI NVS)
  BIOS-e820: 000000007e7e7fb8 - 000000007f000000 (reserved)
  BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
  BIOS-e820: 00000000fed20000 - 00000000fed9a000 (reserved)
  BIOS-e820: 00000000feda0000 - 00000000fedc0000 (reserved)
  BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
  BIOS-e820: 00000000ffb00000 - 00000000ffc00000 (reserved)
  BIOS-e820: 00000000fff00000 - 0000000100000000 (reserved)
 DMI 2.4 present.
 last_pfn = 0x7e7b0 max_arch_pfn = 0x3ffffffff
 x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
 init_memory_mapping: 0000000000000000-000000007e7b0000
  0000000000 - 007e600000 page 2M
  007e600000 - 007e7b0000 page 4k
 kernel direct mapping tables up to 7e7b0000 @ 8000-c000
 last_map_addr: 7e7b0000 end: 7e7b0000
-RAMDISK: 37ab8000 - 37fef345
+RAMDISK: 37ab8000 - 37fefbd6
 ACPI: RSDP 000F7960, 0024 (r2 HP    )
 ACPI: XSDT 7E7C81C8, 007C (r1 HPQOEM SLIC-MPC        1 HP          1)
 ACPI: FACP 7E7C8084, 00F4 (r4 HP     30C9            3 HP          1)
 ACPI: DSDT 7E7C8538, 13484 (r1 HP       nc2500    10000 MSFT  3000001)
 ACPI: FACS 7E7E7D80, 0040
 ACPI: SLIC 7E7C8244, 0176 (r1 HPQOEM SLIC-MPC        1 HP          1)
 ACPI: HPET 7E7C83BC, 0038 (r1 HP     30C9            1 HP          1)
 ACPI: APIC 7E7C83F4, 0068 (r1 HP     30C9            1 HP          1)
 ACPI: MCFG 7E7C845C, 003C (r1 HP     30C9            1 HP          1)
 ACPI: TCPA 7E7C8498, 0032 (r2 HP     30C9            1 HP          1)
 ACPI: ASF! 7E7C84CC, 0069 (r16 HP     CHIMAYU         1 HP          0)
 ACPI: SSDT 7E7DB9BC, 02BE (r1 HP       HPQPAT        1 MSFT  3000001)
 ACPI: SSDT 7E7DC640, 025F (r1 HP      Cpu0Tst     3000 INTL 20060317)
 ACPI: SSDT 7E7DC89F, 00A6 (r1 HP      Cpu1Tst     3000 INTL 20060317)
 ACPI: SSDT 7E7DC945, 04D7 (r1 HP        CpuPm     3000 INTL 20060317)
-ACPI: DMI detected: Hewlett-Packard
 ACPI: Local APIC address 0xfee00000
 (6 early reservations) ==> bootmem [0000000000 - 007e7b0000]
   #0 [0000000000 - 0000001000]   BIOS data page ==> [0000000000 - 0000001000]
   #1 [0000006000 - 0000008000]       TRAMPOLINE ==> [0000006000 - 0000008000]
-  #2 [0000200000 - 000074e550]    TEXT DATA BSS ==> [0000200000 - 000074e550]
-  #3 [0037ab8000 - 0037fef345]          RAMDISK ==> [0037ab8000 - 0037fef345]
+  #2 [0000200000 - 000074c510]    TEXT DATA BSS ==> [0000200000 - 000074c510]
+  #3 [0037ab8000 - 0037fefbd6]          RAMDISK ==> [0037ab8000 - 0037fefbd6]
   #4 [000009fc00 - 0000100000]    BIOS reserved ==> [000009fc00 - 0000100000]
   #5 [0000008000 - 000000a000]          PGTABLE ==> [0000008000 - 000000a000]
  [ffffe20000000000-ffffe20001ffffff] PMD -> [ffff880001200000-ffff8800031fffff] on node 0
 Zone PFN ranges:
   DMA      0x00000000 -> 0x00001000
   DMA32    0x00001000 -> 0x00100000
   Normal   0x00100000 -> 0x00100000
 Movable zone start PFN for each node
 early_node_map[2] active PFN ranges
     0: 0x00000000 -> 0x0000009f
     0: 0x00000100 -> 0x0007e7b0
 On node 0 totalpages: 517967
   DMA zone: 64 pages used for memmap
-  DMA zone: 1459 pages reserved
-  DMA zone: 2476 pages, LIFO batch:0
+  DMA zone: 1457 pages reserved
+  DMA zone: 2478 pages, LIFO batch:0
   DMA32 zone: 8031 pages used for memmap
   DMA32 zone: 505937 pages, LIFO batch:31
   Normal zone: 0 pages used for memmap
   Movable zone: 0 pages used for memmap
 ACPI: PM-Timer IO Port: 0x1008
 ACPI: Local APIC address 0xfee00000
 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
 ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
 ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
 ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1])
 ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
 IOAPIC[0]: apic_id 1, version 0, address 0xfec00000, GSI 0-23
 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
 ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
 ACPI: IRQ0 used by override.
 ACPI: IRQ2 used by override.
 ACPI: IRQ9 used by override.
 ACPI: HPET id: 0x8086a201 base: 0xfed00000
 SMP: Allowing 2 CPUs, 0 hotplug CPUs
 PM: Registered nosave memory: 000000000009f000 - 00000000000a0000
 PM: Registered nosave memory: 00000000000a0000 - 00000000000e0000
 PM: Registered nosave memory: 00000000000e0000 - 0000000000100000
 Allocating PCI resources starting at 80000000 (gap: 7f000000:7fc00000)
 PERCPU: Allocating 49152 bytes of per cpu data
 NR_CPUS: 8, nr_cpu_ids: 2, nr_node_ids 1
-Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 508413
+Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 508415
 Kernel command line: root=/dev/mapper/main-root ro vga=791 quiet
 Initializing CPU#0
 PID hash table entries: 4096 (order: 12, 32768 bytes)
 Extended CMOS year: 2000
 Fast TSC calibration using PIT
-Detected 1330.160 MHz processor.
+Detected 1330.139 MHz processor.
 Console: colour dummy device 80x25
 console [tty0] enabled
 Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
 Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
 Checking aperture...
 No AGP bridge found
-Memory: 2024344k/2072256k available (2300k kernel code, 388k absent, 46900k reserved, 1509k data, 324k init)
+Memory: 2024352k/2072256k available (2302k kernel code, 388k absent, 46892k reserved, 1507k data, 316k init)
 SLUB: Genslabs=12, HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
 hpet clockevent registered
 HPET: 3 timers in total, 0 timers will be used for per-cpu timer
-Calibrating delay loop (skipped), value calculated using timer frequency.. 2660.32 BogoMIPS (lpj=5320640)
+Calibrating delay loop (skipped), value calculated using timer frequency.. 2660.27 BogoMIPS (lpj=5320556)
 Security Framework initialized
 SELinux:  Disabled at boot.
 Mount-cache hash table entries: 256
 CPU: L1 I cache: 32K, L1 D cache: 32K
 CPU: L2 cache: 2048K
 CPU: Physical Processor ID: 0
 CPU: Processor Core ID: 0
 CPU0: Thermal monitoring handled by SMI
 using mwait in idle threads.
 ACPI: Core revision 20080926
 Setting APIC routing to flat
 ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
 CPU0: Intel(R) Core(TM)2 Duo CPU     U7700  @ 1.33GHz stepping 0d
 Booting processor 1 APIC 0x1 ip 0x6000
 Initializing CPU#1
-Calibrating delay using timer specific routine.. 2659.99 BogoMIPS (lpj=5319980)
+Calibrating delay using timer specific routine.. 2659.98 BogoMIPS (lpj=5319962)
 CPU: L1 I cache: 32K, L1 D cache: 32K
 CPU: L2 cache: 2048K
 CPU: Physical Processor ID: 0
 CPU: Processor Core ID: 1
 CPU1: Thermal monitoring enabled (TM2)
 x86 PAT enabled: cpu 1, old 0x7040600070406, new 0x7010600070106
 CPU1: Intel(R) Core(TM)2 Duo CPU     U7700  @ 1.33GHz stepping 0d
 checking TSC synchronization [CPU#0 -> CPU#1]: passed.
 Brought up 2 CPUs
-Total of 2 processors activated (5320.31 BogoMIPS).
+Total of 2 processors activated (5320.25 BogoMIPS).
 CPU0 attaching sched-domain:
  domain 0: span 0-1 level MC
   groups: 0 1
 CPU1 attaching sched-domain:
  domain 0: span 0-1 level MC
   groups: 1 0
 net_namespace: 1400 bytes
 NET: Registered protocol family 16
 ACPI FADT declares the system doesn't support PCIe ASPM, so disable it
 ACPI: bus type pci registered
 PCI: MCFG configuration 0: base f8000000 segment 0 buses 0 - 63
 PCI: Not using MMCONFIG.
 PCI: Using configuration type 1 for base access
 ACPI: EC: Look up EC in DSDT
 ACPI: EC: non-query interrupt received, switching to interrupt mode
 ACPI: Interpreter enabled
 ACPI: (supports S0 S3 S4 S5)
 ACPI: Using IOAPIC for interrupt routing
 PCI: MCFG configuration 0: base f8000000 segment 0 buses 0 - 63
 PCI: MCFG area at f8000000 reserved in ACPI motherboard resources
 PCI: Using MMCONFIG at f8000000 - fbffffff
 ACPI: EC: GPE = 0x16, I/O: command/status = 0x66, data = 0x62
 ACPI: EC: driver started in interrupt mode
 ACPI: No dock devices found.
 ACPI: PCI Root Bridge [C003] (0000:00)
 pci 0000:00:02.0: reg 10 64bit mmio: [0xe0400000-0xe04fffff]
 pci 0000:00:02.0: reg 18 64bit mmio: [0xd0000000-0xdfffffff]
 pci 0000:00:02.0: reg 20 io port: [0x2000-0x2007]
 pci 0000:00:02.1: reg 10 64bit mmio: [0xe0500000-0xe05fffff]
 pci 0000:00:03.0: reg 10 64bit mmio: [0xe0600000-0xe060000f]
 pci 0000:00:03.0: PME# supported from D0 D3hot D3cold
 pci 0000:00:03.0: PME# disabled
 pci 0000:00:03.2: reg 10 io port: [0x2008-0x200f]
 pci 0000:00:03.2: reg 14 io port: [0x2010-0x2013]
 pci 0000:00:03.2: reg 18 io port: [0x2018-0x201f]
 pci 0000:00:03.2: reg 1c io port: [0x2020-0x2023]
 pci 0000:00:03.2: reg 20 io port: [0x2030-0x203f]
 pci 0000:00:03.3: reg 10 io port: [0x2040-0x2047]
 pci 0000:00:03.3: reg 14 32bit mmio: [0xe0601000-0xe0601fff]
 pci 0000:00:19.0: reg 10 32bit mmio: [0xe0620000-0xe063ffff]
 pci 0000:00:19.0: reg 14 32bit mmio: [0xe0640000-0xe0640fff]
 pci 0000:00:19.0: reg 18 io port: [0x2060-0x207f]
 pci 0000:00:19.0: PME# supported from D0 D3hot D3cold
 pci 0000:00:19.0: PME# disabled
 pci 0000:00:1a.0: reg 20 io port: [0x2080-0x209f]
 pci 0000:00:1a.1: reg 20 io port: [0x20a0-0x20bf]
 pci 0000:00:1a.7: reg 10 32bit mmio: [0xe0641000-0xe06413ff]
 pci 0000:00:1a.7: PME# supported from D0 D3hot D3cold
 pci 0000:00:1a.7: PME# disabled
 pci 0000:00:1b.0: reg 10 64bit mmio: [0xe0644000-0xe0647fff]
 pci 0000:00:1b.0: PME# supported from D0 D3hot D3cold
 pci 0000:00:1b.0: PME# disabled
 pci 0000:00:1c.0: PME# supported from D0 D3hot D3cold
 pci 0000:00:1c.0: PME# disabled
 pci 0000:00:1c.1: PME# supported from D0 D3hot D3cold
 pci 0000:00:1c.1: PME# disabled
 pci 0000:00:1d.0: reg 20 io port: [0x20c0-0x20df]
 pci 0000:00:1d.1: reg 20 io port: [0x20e0-0x20ff]
 pci 0000:00:1d.2: reg 20 io port: [0x2100-0x211f]
 pci 0000:00:1d.7: reg 10 32bit mmio: [0xe0648000-0xe06483ff]
 pci 0000:00:1d.7: PME# supported from D0 D3hot D3cold
 pci 0000:00:1d.7: PME# disabled
 pci 0000:00:1f.0: quirk: region 1000-107f claimed by ICH6 ACPI/GPIO/TCO
 pci 0000:00:1f.0: quirk: region 1100-113f claimed by ICH6 GPIO
 pci 0000:00:1f.1: reg 10 io port: [0x00-0x07]
 pci 0000:00:1f.1: reg 14 io port: [0x00-0x03]
 pci 0000:00:1f.1: reg 18 io port: [0x00-0x07]
 pci 0000:00:1f.1: reg 1c io port: [0x00-0x03]
 pci 0000:00:1f.1: reg 20 io port: [0x2120-0x212f]
 pci 0000:10:00.0: reg 10 64bit mmio: [0xe0000000-0xe0001fff]
 pci 0000:10:00.0: PME# supported from D0 D3hot D3cold
 pci 0000:10:00.0: PME# disabled
 pci 0000:00:1c.1: bridge 32bit mmio: [0xe0000000-0xe00fffff]
 pci 0000:02:06.0: reg 10 32bit mmio: [0xe0100000-0xe0100fff]
 pci 0000:02:06.0: supports D1 D2
 pci 0000:02:06.0: PME# supported from D0 D1 D2 D3hot D3cold
 pci 0000:02:06.0: PME# disabled
 pci 0000:02:06.1: reg 10 32bit mmio: [0xe0101000-0xe01017ff]
 pci 0000:02:06.1: supports D1 D2
 pci 0000:02:06.1: PME# supported from D0 D1 D2 D3hot D3cold
 pci 0000:02:06.1: PME# disabled
 pci 0000:02:06.2: reg 10 32bit mmio: [0xe0102000-0xe01020ff]
 pci 0000:02:06.2: supports D1 D2
 pci 0000:02:06.2: PME# supported from D0 D1 D2 D3hot D3cold
 pci 0000:02:06.2: PME# disabled
 pci 0000:02:06.3: reg 10 32bit mmio: [0xe0103000-0xe01030ff]
 pci 0000:02:06.3: supports D1 D2
 pci 0000:02:06.3: PME# supported from D0 D1 D2 D3hot D3cold
 pci 0000:02:06.3: PME# disabled
 pci 0000:00:1e.0: transparent bridge
 pci 0000:00:1e.0: bridge 32bit mmio: [0xe0100000-0xe03fffff]
 bus 00 -> node 0
 ACPI: PCI Interrupt Routing Table [\_SB_.C003._PRT]
 ACPI: PCI Interrupt Routing Table [\_SB_.C003.C0B2._PRT]
 ACPI: PCI Interrupt Routing Table [\_SB_.C003.C11F._PRT]
 ACPI: PCI Interrupt Routing Table [\_SB_.C003.C133._PRT]
 ACPI: PCI Interrupt Link [C12F] (IRQs *10 11)
 ACPI: PCI Interrupt Link [C130] (IRQs *10 11)
 ACPI: PCI Interrupt Link [C131] (IRQs 10 *11)
 ACPI: PCI Interrupt Link [C132] (IRQs 10 11) *5
 ACPI: PCI Interrupt Link [C142] (IRQs *10 11)
 ACPI: PCI Interrupt Link [C143] (IRQs 10 11) *0, disabled.
 ACPI: PCI Interrupt Link [C144] (IRQs 10 *11)
 ACPI Exception (pci_link-0189): AE_NOT_FOUND, Evaluating _PRS [20080926]
 ACPI: Power Resource [C29F] (on)
 ACPI: Power Resource [C1C7] (off)
 ACPI: Power Resource [C3AD] (off)
 ACPI: Power Resource [C3B0] (off)
 ACPI: Power Resource [C3C3] (off)
 ACPI: Power Resource [C3C4] (off)
 ACPI: Power Resource [C3C5] (off)
 ACPI: Power Resource [C3C6] (off)
 ACPI: Power Resource [C3C7] (off)
 usbcore: registered new interface driver usbfs
 usbcore: registered new interface driver hub
 usbcore: registered new device driver usb
 PCI: Using ACPI for IRQ routing
 PCI-GART: No AMD GART found.
 hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0
 hpet0: 3 comparators, 64-bit 14.318180 MHz counter
 pnp: PnP ACPI init
 ACPI: bus type pnp registered
 pnp: PnP ACPI: found 14 devices
 ACPI: ACPI bus type pnp unregistered
 system 00:00: iomem range 0x0-0x9ffff could not be reserved
 system 00:00: iomem range 0xe0000-0xfffff could not be reserved
 system 00:00: iomem range 0x100000-0x7e7fffff could not be reserved
 system 00:0a: ioport range 0x500-0x55f has been reserved
 system 00:0a: ioport range 0x800-0x80f has been reserved
 system 00:0a: iomem range 0xffb00000-0xffbfffff has been reserved
 system 00:0a: iomem range 0xfff00000-0xffffffff has been reserved
 system 00:0c: ioport range 0x4d0-0x4d1 has been reserved
 system 00:0c: ioport range 0x2f8-0x2ff has been reserved
 system 00:0c: ioport range 0x3f8-0x3ff has been reserved
 system 00:0c: ioport range 0x1000-0x107f has been reserved
 system 00:0c: ioport range 0x1100-0x113f has been reserved
 system 00:0c: ioport range 0x1200-0x121f has been reserved
 system 00:0c: iomem range 0xf8000000-0xfbffffff has been reserved
 system 00:0c: iomem range 0xfec00000-0xfec000ff has been reserved
 system 00:0c: iomem range 0xfed20000-0xfed3ffff has been reserved
 system 00:0c: iomem range 0xfed45000-0xfed8ffff has been reserved
 system 00:0c: iomem range 0xfed90000-0xfed99fff has been reserved
 system 00:0d: iomem range 0xcee00-0xcffff has been reserved
 system 00:0d: iomem range 0xd2000-0xd3fff has been reserved
 system 00:0d: iomem range 0xfeda0000-0xfedbffff has been reserved
 system 00:0d: iomem range 0xfee00000-0xfee00fff has been reserved
+pci 0000:02:06.0: BAR 9 0-3ffffff wrong alignment flags 21200 4000000 (0)
+pci 0000:02:06.0: BAR 9 bad alignment 0: [0x000000-0x3ffffff]
 pci 0000:00:1c.0: PCI bridge, secondary bus 0000:08
 pci 0000:00:1c.0:   IO window: disabled
 pci 0000:00:1c.0:   MEM window: disabled
 pci 0000:00:1c.0:   PREFETCH window: disabled
 pci 0000:00:1c.1: PCI bridge, secondary bus 0000:10
 pci 0000:00:1c.1:   IO window: disabled
 pci 0000:00:1c.1:   MEM window: 0xe0000000-0xe00fffff
 pci 0000:00:1c.1:   PREFETCH window: disabled
 pci 0000:02:06.0: CardBus bridge, secondary bus 0000:03
 pci 0000:02:06.0:   IO window: 0x003000-0x0030ff
 pci 0000:02:06.0:   IO window: 0x003400-0x0034ff
-pci 0000:02:06.0:   PREFETCH window: 0x80000000-0x83ffffff
-pci 0000:02:06.0:   MEM window: 0x84000000-0x87ffffff
+pci 0000:02:06.0:   MEM window: 0x80000000-0x83ffffff
 pci 0000:00:1e.0: PCI bridge, secondary bus 0000:02
 pci 0000:00:1e.0:   IO window: 0x3000-0x3fff
 pci 0000:00:1e.0:   MEM window: 0xe0100000-0xe03fffff
-pci 0000:00:1e.0:   PREFETCH window: 0x00000080000000-0x00000083ffffff
+pci 0000:00:1e.0:   PREFETCH window: disabled
 pci 0000:00:1c.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
 pci 0000:00:1c.0: setting latency timer to 64
 pci 0000:00:1c.1: PCI INT B -> GSI 17 (level, low) -> IRQ 17
 pci 0000:00:1c.1: setting latency timer to 64
 pci 0000:00:1e.0: setting latency timer to 64
 pci 0000:02:06.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
 bus: 00 index 0 io port: [0x00-0xffff]
 bus: 00 index 1 mmio: [0x000000-0xffffffffffffffff]
 bus: 08 index 0 mmio: [0x0-0x0]
 bus: 08 index 1 mmio: [0x0-0x0]
 bus: 08 index 2 mmio: [0x0-0x0]
 bus: 08 index 3 mmio: [0x0-0x0]
 bus: 10 index 0 mmio: [0x0-0x0]
 bus: 10 index 1 mmio: [0xe0000000-0xe00fffff]
 bus: 10 index 2 mmio: [0x0-0x0]
 bus: 10 index 3 mmio: [0x0-0x0]
 bus: 02 index 0 io port: [0x3000-0x3fff]
 bus: 02 index 1 mmio: [0xe0100000-0xe03fffff]
-bus: 02 index 2 mmio: [0x80000000-0x83ffffff]
+bus: 02 index 2 mmio: [0x0-0x0]
 bus: 02 index 3 io port: [0x00-0xffff]
 bus: 02 index 4 mmio: [0x000000-0xffffffffffffffff]
 bus: 03 index 0 io port: [0x3000-0x30ff]
 bus: 03 index 1 io port: [0x3400-0x34ff]
-bus: 03 index 2 mmio: [0x80000000-0x83ffffff]
-bus: 03 index 3 mmio: [0x84000000-0x87ffffff]
+bus: 03 index 2 mmio: [0x0-0x3ffffff]
+bus: 03 index 3 mmio: [0x80000000-0x83ffffff]
 NET: Registered protocol family 2
-Switched to high resolution mode on CPU 1
 IP route cache hash table entries: 65536 (order: 7, 524288 bytes)
 TCP established hash table entries: 262144 (order: 10, 4194304 bytes)
-Switched to high resolution mode on CPU 0
 TCP bind hash table entries: 65536 (order: 9, 2097152 bytes)
 TCP: Hash tables configured (established 262144 bind 65536)
 TCP reno registered
+Switched to high resolution mode on CPU 1
+Switched to high resolution mode on CPU 0
 NET: Registered protocol family 1
 checking if image is initramfs... it is
-Freeing initrd memory: 5340k freed
+Freeing initrd memory: 5342k freed
 audit: initializing netlink socket (disabled)
-type=2000 audit(1225705229.141:1): initialized
+type=2000 audit(1228190448.133:1): initialized
 VFS: Disk quotas dquot_6.5.1
 Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
 msgmni has been set to 3965
 alg: No test for stdrng (krng)
 io scheduler noop registered
 io scheduler anticipatory registered
 io scheduler deadline registered
 io scheduler cfq registered (default)
 pci 0000:00:02.0: Boot video device
 pcieport-driver 0000:00:1c.0: setting latency timer to 64
 pcieport-driver 0000:00:1c.0: found MSI capability
-pcieport-driver 0000:00:1c.0: irq 47 for MSI/MSI-X
+pcieport-driver 0000:00:1c.0: irq 511 for MSI/MSI-X
 pci_express 0000:00:1c.0:pcie00: allocate port service
 pci_express 0000:00:1c.0:pcie03: allocate port service
 pcieport-driver 0000:00:1c.1: setting latency timer to 64
 pcieport-driver 0000:00:1c.1: found MSI capability
-pcieport-driver 0000:00:1c.1: irq 46 for MSI/MSI-X
+pcieport-driver 0000:00:1c.1: irq 510 for MSI/MSI-X
 pci_express 0000:00:1c.1:pcie00: allocate port service
 pci_express 0000:00:1c.1:pcie03: allocate port service
 vesafb: framebuffer at 0xd0000000, mapped to 0xffffc20004100000, using 3072k, total 7616k
 vesafb: mode is 1024x768x16, linelength=2048, pages=3
 vesafb: scrolling: redraw
 vesafb: Truecolor: size=0:5:6:5, shift=0:11:5:0
 Console: switching to colour frame buffer device 128x48
 fb0: VESA VGA frame buffer device
 Linux agpgart interface v0.103
 Serial: 8250/16550 driver4 ports, IRQ sharing enabled
 serial 0000:00:03.3: PCI INT B -> GSI 17 (level, low) -> IRQ 17
 0000:00:03.3: ttyS0 at I/O 0x2040 (irq = 17) is a 16550A
 brd: module loaded
 PNP: PS/2 Controller [PNP0303:C29C,PNP0f13:C29D] at 0x60,0x64 irq 1,12
 i8042.c: Detected active multiplexing controller, rev 1.1.
 serio: i8042 KBD port at 0x60,0x64 irq 1
 serio: i8042 AUX0 port at 0x60,0x64 irq 12
 serio: i8042 AUX1 port at 0x60,0x64 irq 12
 serio: i8042 AUX2 port at 0x60,0x64 irq 12
 serio: i8042 AUX3 port at 0x60,0x64 irq 12
 mice: PS/2 mouse device common for all mice
 rtc_cmos 00:06: RTC can wake from S4
 rtc_cmos 00:06: rtc core: registered rtc_cmos as rtc0
-rtc0: alarms up to one month, y3k, 114 bytes nvram, , hpet irqs irqs
+rtc0: alarms up to one month, y3k, 114 bytes nvram, hpet irqs
 cpuidle: using governor ladder
 cpuidle: using governor menu
 TCP bic registered
 NET: Registered protocol family 17
-rtc_cmos 00:06: setting system clock to 2008-11-03 09:40:30 UTC (1225705230)
-Freeing unused kernel memory: 324k freed
+rtc_cmos 00:06: setting system clock to 2008-12-02 04:00:49 UTC (1228190449)
+Freeing unused kernel memory: 316k freed
 input: AT Translated Set 2 keyboard as /class/input/input0
-ACPI: Transitioning device [C3B1] to D3
 fan PNP0C0B:00: registered as cooling_device0
 ACPI: Fan [C3B1] (off)
-ACPI: Transitioning device [C3B2] to D3
 fan PNP0C0B:01: registered as cooling_device1
 ACPI: Fan [C3B2] (off)
-ACPI: Transitioning device [C3C8] to D3
 fan PNP0C0B:02: registered as cooling_device2
 ACPI: Fan [C3C8] (off)
-ACPI: Transitioning device [C3C9] to D3
 fan PNP0C0B:03: registered as cooling_device3
 ACPI: Fan [C3C9] (off)
-ACPI: Transitioning device [C3CA] to D3
 fan PNP0C0B:04: registered as cooling_device4
 ACPI: Fan [C3CA] (off)
-ACPI: Transitioning device [C3CB] to D3
 fan PNP0C0B:05: registered as cooling_device5
 ACPI: Fan [C3CB] (off)
-ACPI: Transitioning device [C3CC] to D3
 fan PNP0C0B:06: registered as cooling_device6
 ACPI: Fan [C3CC] (off)
 ACPI: SSDT 7E7DBD42, 027F (r1 HP      Cpu0Ist     3000 INTL 20060317)
 ACPI: SSDT 7E7DC046, 05FA (r1 HP      Cpu0Cst     3001 INTL 20060317)
 Monitor-Mwait will be used to enter C-1 state
 Monitor-Mwait will be used to enter C-2 state
 Monitor-Mwait will be used to enter C-3 state
 ACPI: CPU0 (power states: C1[C1] C2[C2] C3[C3])
-processor ACPI0007:00: registered as cooling_device7
+processor ACPI_CPU:00: registered as cooling_device7
 ACPI: Processor [CPU0] (supports 8 throttling states)
 ACPI: SSDT 7E7DBC7A, 00C8 (r1 HP      Cpu1Ist     3000 INTL 20060317)
 ACPI: SSDT 7E7DBFC1, 0085 (r1 HP      Cpu1Cst     3000 INTL 20060317)
 Marking TSC unstable due to TSC halts in idle
 ACPI: CPU1 (power states: C1[C1] C2[C2] C3[C3])
-processor ACPI0007:01: registered as cooling_device8
+processor ACPI_CPU:01: registered as cooling_device8
 ACPI: Processor [CPU1] (supports 8 throttling states)
 thermal LNXTHERM:01: registered as thermal_zone0
 ACPI: Thermal Zone [TZ6] (25 C)
 thermal LNXTHERM:02: registered as thermal_zone1
-ACPI: Thermal Zone [TZ0] (45 C)
+ACPI: Thermal Zone [TZ0] (36 C)
 thermal LNXTHERM:03: registered as thermal_zone2
-ACPI: Thermal Zone [TZ1] (47 C)
+ACPI: Thermal Zone [TZ1] (39 C)
 thermal LNXTHERM:04: registered as thermal_zone3
-ACPI: Thermal Zone [TZ3] (36 C)
+ACPI: Thermal Zone [TZ3] (26 C)
 thermal LNXTHERM:05: registered as thermal_zone4
-ACPI: Thermal Zone [TZ4] (30 C)
+ACPI: Thermal Zone [TZ4] (21 C)
 thermal LNXTHERM:06: registered as thermal_zone5
-ACPI: Thermal Zone [TZ5] (26 C)
+ACPI: Thermal Zone [TZ5] (0 C)
 e1000e: Intel(R) PRO/1000 Network Driver - 0.3.3.3-k6
 e1000e: Copyright (c) 1999-2008 Intel Corporation.
 libata version 3.00 loaded.
 e1000e 0000:00:19.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22
 e1000e 0000:00:19.0: setting latency timer to 64
-e1000e 0000:00:19.0: irq 45 for MSI/MSI-X
+e1000e 0000:00:19.0: irq 509 for MSI/MSI-X
 SCSI subsystem initialized
 ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
 uhci_hcd: USB Universal Host Controller Interface driver
 ricoh-mmc: Ricoh MMC Controller disabling driver
 ricoh-mmc: Copyright(c) Philip Langdale
 ricoh-mmc: Ricoh MMC controller found at 0000:02:06.3 [1180:0843] (rev 11)
 ricoh-mmc: Controller is now disabled.
 sdhci: Secure Digital Host Controller Interface driver
 sdhci: Copyright(c) Pierre Ossman
 sdhci-pci 0000:02:06.2: SDHCI controller found [1180:0822] (rev 21)
 sdhci-pci 0000:02:06.2: PCI INT C -> GSI 20 (level, low) -> IRQ 20
 mmc0: SDHCI controller on PCI [0000:02:06.2] using PIO
 ohci1394 0000:02:06.1: PCI INT B -> GSI 19 (level, low) -> IRQ 19
 ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[19]  MMIO=[e0101000-e01017ff]  Max Packet=[2048]  IR/IT contexts=[4/4]
 0000:00:19.0: eth0: (PCI Express:2.5GB/s:Width x1) 00:1e:68:5e:3b:04
 0000:00:19.0: eth0: Intel(R) PRO/1000 Network Connection
 0000:00:19.0: eth0: MAC: 5, PHY: 6, PBA No: ffffff-0ff
 ehci_hcd 0000:00:1a.7: PCI INT C -> GSI 18 (level, low) -> IRQ 18
 ehci_hcd 0000:00:1a.7: setting latency timer to 64
 ehci_hcd 0000:00:1a.7: EHCI Host Controller
 ehci_hcd 0000:00:1a.7: new USB bus registered, assigned bus number 1
 ehci_hcd 0000:00:1a.7: debug port 1
 ehci_hcd 0000:00:1a.7: cache line size of 32 is not supported
 ehci_hcd 0000:00:1a.7: irq 18, io mem 0xe0641000
 ehci_hcd 0000:00:1a.7: USB 2.0 started, EHCI 1.00
 usb usb1: configuration #1 chosen from 1 choice
 hub 1-0:1.0: USB hub found
 hub 1-0:1.0: 4 ports detected
 uhci_hcd 0000:00:1a.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
 uhci_hcd 0000:00:1a.0: setting latency timer to 64
 uhci_hcd 0000:00:1a.0: UHCI Host Controller
 uhci_hcd 0000:00:1a.0: new USB bus registered, assigned bus number 2
 uhci_hcd 0000:00:1a.0: irq 16, io base 0x00002080
 usb usb2: configuration #1 chosen from 1 choice
 hub 2-0:1.0: USB hub found
 hub 2-0:1.0: 2 ports detected
 ehci_hcd 0000:00:1d.7: PCI INT A -> GSI 20 (level, low) -> IRQ 20
 ehci_hcd 0000:00:1d.7: setting latency timer to 64
 ehci_hcd 0000:00:1d.7: EHCI Host Controller
 ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 3
 ehci_hcd 0000:00:1d.7: debug port 1
 ehci_hcd 0000:00:1d.7: cache line size of 32 is not supported
 ehci_hcd 0000:00:1d.7: irq 20, io mem 0xe0648000
 ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00
 usb usb3: configuration #1 chosen from 1 choice
 hub 3-0:1.0: USB hub found
 hub 3-0:1.0: 6 ports detected
 uhci_hcd 0000:00:1a.1: PCI INT B -> GSI 17 (level, low) -> IRQ 17
 uhci_hcd 0000:00:1a.1: setting latency timer to 64
 uhci_hcd 0000:00:1a.1: UHCI Host Controller
 uhci_hcd 0000:00:1a.1: new USB bus registered, assigned bus number 4
 uhci_hcd 0000:00:1a.1: irq 17, io base 0x000020a0
 usb usb4: configuration #1 chosen from 1 choice
 hub 4-0:1.0: USB hub found
 hub 4-0:1.0: 2 ports detected
 uhci_hcd 0000:00:1d.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20
 uhci_hcd 0000:00:1d.0: setting latency timer to 64
 uhci_hcd 0000:00:1d.0: UHCI Host Controller
 uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 5
 uhci_hcd 0000:00:1d.0: irq 20, io base 0x000020c0
 usb usb5: configuration #1 chosen from 1 choice
 hub 5-0:1.0: USB hub found
 hub 5-0:1.0: 2 ports detected
 uhci_hcd 0000:00:1d.1: PCI INT B -> GSI 22 (level, low) -> IRQ 22
 uhci_hcd 0000:00:1d.1: setting latency timer to 64
 uhci_hcd 0000:00:1d.1: UHCI Host Controller
 uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 6
 uhci_hcd 0000:00:1d.1: irq 22, io base 0x000020e0
 usb usb6: configuration #1 chosen from 1 choice
 hub 6-0:1.0: USB hub found
 hub 6-0:1.0: 2 ports detected
 uhci_hcd 0000:00:1d.2: PCI INT C -> GSI 18 (level, low) -> IRQ 18
 uhci_hcd 0000:00:1d.2: setting latency timer to 64
 uhci_hcd 0000:00:1d.2: UHCI Host Controller
 uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 7
 uhci_hcd 0000:00:1d.2: irq 18, io base 0x00002100
 usb usb7: configuration #1 chosen from 1 choice
 hub 7-0:1.0: USB hub found
 hub 7-0:1.0: 2 ports detected
 pata_acpi 0000:00:03.2: PCI INT C -> GSI 18 (level, low) -> IRQ 18
 pata_acpi 0000:00:03.2: setting latency timer to 64
 pata_acpi 0000:00:03.2: PCI INT C disabled
 pata_acpi 0000:00:1f.1: PCI INT A -> GSI 16 (level, low) -> IRQ 16
 pata_acpi 0000:00:1f.1: setting latency timer to 64
 pata_acpi 0000:00:1f.1: PCI INT A disabled
 ata_piix 0000:00:1f.1: version 2.12
 ata_piix 0000:00:1f.1: quirky BIOS, skipping spindown on poweroff and hibernation
 ata_piix 0000:00:1f.1: PCI INT A -> GSI 16 (level, low) -> IRQ 16
 ata_piix 0000:00:1f.1: setting latency timer to 64
 Uniform Multi-Platform E-IDE driver
 scsi0 : ata_piix
 scsi1 : ata_piix
 ata1: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0x2120 irq 14
 ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0x2128 irq 15
 ata1.00: ATA-7: SAMSUNG HS122JC, GQ100-04, max UDMA/100
 ata1.00: 234441648 sectors, multi 16: LBA 
 ata1.01: ATAPI: MATSHITADVD-RAM UJ-852S, 1.02, max MWDMA2
 ata1.00: configured for UDMA/100
 ata1.01: configured for MWDMA2
 ata2: port disabled. ignoring.
 isa bounce pool size: 16 pages
 scsi 0:0:0:0: Direct-Access     ATA      SAMSUNG HS122JC  GQ10 PQ: 0 ANSI: 5
 scsi 0:0:1:0: CD-ROM            MATSHITA DVD-RAM UJ-852S  1.02 PQ: 0 ANSI: 5
 Driver 'sd' needs updating - please use bus_type methods
 sd 0:0:0:0: [sda] 234441648 512-byte hardware sectors: (120 GB/111 GiB)
 sd 0:0:0:0: [sda] Write Protect is off
 sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
 sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
 sd 0:0:0:0: [sda] 234441648 512-byte hardware sectors: (120 GB/111 GiB)
 sd 0:0:0:0: [sda] Write Protect is off
 sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
 sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
  sda: sda1 sda2 sda3 sda4 <<4>Driver 'sr' needs updating - please use bus_type methods
  sda5 sda6 sda7 >
 sd 0:0:0:0: [sda] Attached SCSI disk
 sr0: scsi3-mmc drive: 24x/24x writer dvd-ram cd/rw xa/form2 cdda tray
 Uniform CD-ROM driver Revision: 3.20
 sr 0:0:1:0: Attached scsi CD-ROM sr0
 sd 0:0:0:0: Attached scsi generic sg0 type 0
 sr 0:0:1:0: Attached scsi generic sg1 type 5
 Clocksource tsc unstable (delta = -96409064 ns)
 usb 5-2: new full speed USB device using uhci_hcd and address 2
 usb 5-2: configuration #1 chosen from 1 choice
 device-mapper: ioctl: 4.14.0-ioctl (2008-04-23) initialised: dm-devel@redhat.com
 usb 2-1: new full speed USB device using uhci_hcd and address 2
 ieee1394: Host added: ID:BUS[0-00:1023]  GUID[001b249929192210]
 usb 2-1: configuration #1 chosen from 1 choice
 PM: Starting manual resume from disk
 kjournald starting.  Commit interval 5 seconds
 EXT3-fs: mounted filesystem with ordered data mode.
 udevd version 125 started
 input: Power Button (FF) as /class/input/input1
 ACPI: Power Button (FF) [PWRF]
 input: Sleep Button (CM) as /class/input/input2
 ACPI: Sleep Button (CM) [C2BF]
 ACPI: AC Adapter [C23B] (off-line)
 input: Lid Switch as /class/input/input3
 ACPI: Lid Switch [C155]
 Registered led device: hp:red:hddprotection
 leds-hp-disk driver loaded.
 acpi device:02: registered as cooling_device9
 input: Video Bus as /class/input/input4
 ACPI: WMI: Mapper loaded
 ACPI: Video Device [C09A] (multi-head: yes  rom: no  post: no)
 ACPI: Battery Slot [C23D] (battery present)
 agpgart-intel 0000:00:00.0: Intel 965GM Chipset
 agpgart-intel 0000:00:00.0: detected 7676K stolen memory
 agpgart-intel 0000:00:00.0: AGP aperture is 256M @ 0xd0000000
 cfg80211: Using static regulatory domain info
 cfg80211: Regulatory domain: EU
 	(start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
 	(2402000 KHz - 2482000 KHz @ 40000 KHz), (600 mBi, 2000 mBm)
 	(5170000 KHz - 5190000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
 	(5190000 KHz - 5210000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
 	(5210000 KHz - 5230000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
 	(5230000 KHz - 5330000 KHz @ 40000 KHz), (600 mBi, 2000 mBm)
 	(5490000 KHz - 5710000 KHz @ 40000 KHz), (600 mBi, 3000 mBm)
 yenta_cardbus 0000:02:06.0: CardBus bridge found [103c:30c9]
 iTCO_wdt: Intel TCO WatchDog Timer Driver v1.03 (30-Apr-2008)
 iTCO_wdt: Found a ICH8M-E TCO device (Version=2, TCOBASE=0x1060)
 iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)
+yenta_cardbus 0000:02:06.0: CardBus bridge, secondary bus 0000:03
+yenta_cardbus 0000:02:06.0:   IO window: 0x003000-0x0030ff
+yenta_cardbus 0000:02:06.0:   IO window: 0x003400-0x0034ff
+yenta_cardbus 0000:02:06.0:   PREFETCH window: 0x84400000-0x847fffff
+yenta_cardbus 0000:02:06.0:   MEM window: 0x80000000-0x83ffffff
 yenta_cardbus 0000:02:06.0: ISA IRQ mask 0x0cb8, PCI irq 18
 yenta_cardbus 0000:02:06.0: Socket status: 30000006
 pci_bus 0000:02: Raising subordinate bus# of parent bus (#02) from #03 to #06
 yenta_cardbus 0000:02:06.0: pcmcia: parent PCI bridge I/O window: 0x3000 - 0x3fff
 yenta_cardbus 0000:02:06.0: pcmcia: parent PCI bridge Memory window: 0xe0100000 - 0xe03fffff
-yenta_cardbus 0000:02:06.0: pcmcia: parent PCI bridge Memory window: 0x80000000 - 0x83ffffff
 input: PC Speaker as /class/input/input5
 input: PS/2 Generic Mouse as /class/input/input6
 iwlagn: Intel(R) Wireless WiFi Link AGN driver for Linux, 1.3.27ks
 iwlagn: Copyright(c) 2003-2008 Intel Corporation
 iwlagn 0000:10:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
 iwlagn 0000:10:00.0: setting latency timer to 64
 iwlagn: Detected Intel Wireless WiFi Link 4965AGN REV=0x4
 iwlagn: Tunable channels: 11 802.11bg, 13 802.11a channels
 iwlagn 0000:10:00.0: PCI INT A disabled
 phy0: Selected rate control algorithm 'iwl-agn-rs'
 HDA Intel 0000:00:1b.0: power state changed by ACPI to D0
 HDA Intel 0000:00:1b.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
 HDA Intel 0000:00:1b.0: setting latency timer to 64
 Synaptics Touchpad, model: 1, fw: 6.3, id: 0x1a0b1, caps: 0xa04711/0xa00000
 input: SynPS/2 Synaptics TouchPad as /class/input/input7
 EXT3 FS on dm-1, internal journal
 loop: module loaded
 kjournald starting.  Commit interval 5 seconds
 EXT3 FS on dm-5, internal journal
 EXT3-fs: mounted filesystem with ordered data mode.
 kjournald starting.  Commit interval 5 seconds
 EXT3 FS on dm-6, internal journal
 EXT3-fs: mounted filesystem with ordered data mode.
 kjournald starting.  Commit interval 5 seconds
 EXT3 FS on dm-4, internal journal
 EXT3-fs: mounted filesystem with ordered data mode.
 kjournald starting.  Commit interval 5 seconds
 EXT3 FS on dm-2, internal journal
 EXT3-fs: mounted filesystem with ordered data mode.
 kjournald starting.  Commit interval 5 seconds
 EXT3 FS on dm-3, internal journal
 EXT3-fs: mounted filesystem with ordered data mode.
 Adding 2097144k swap on /dev/mapper/main-swap.  Priority:-1 extents:1 across:2097144k
 iwlagn 0000:10:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
 iwlagn 0000:10:00.0: restoring config space at offset 0x1 (was 0x100002, writing 0x100006)
-iwlagn 0000:10:00.0: irq 44 for MSI/MSI-X
+iwlagn 0000:10:00.0: irq 508 for MSI/MSI-X
 iwlagn 0000:10:00.0: firmware: requesting iwlwifi-4965-2.ucode
 Registered led device: iwl-phy0:radio
 Registered led device: iwl-phy0:assoc
 Registered led device: iwl-phy0:RX
 Registered led device: iwl-phy0:TX
 wlan0: authenticate with AP 00:14:c1:38:e5:15
 wlan0: authenticated
 wlan0: associate with AP 00:14:c1:38:e5:15
 wlan0: RX AssocResp from 00:14:c1:38:e5:15 (capab=0x411 status=0 aid=1)
 wlan0: associated
 NET: Registered protocol family 10
 lo: Disabled Privacy Extensions
 RPC: Registered udp transport module.
 RPC: Registered tcp transport module.
 wlan0: no IPv6 routers present
 [drm] Initialized drm 1.1.0 20060810
 pci 0000:00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
 pci 0000:00:02.0: setting latency timer to 64
 [drm] Initialized i915 1.6.0 20080730 on minor 0
 CPU0 attaching NULL sched-domain.
 CPU1 attaching NULL sched-domain.
 CPU0 attaching sched-domain:
  domain 0: span 0-1 level MC
   groups: 0 1
   domain 1: span 0-1 level CPU
    groups: 0-1
 CPU1 attaching sched-domain:
  domain 0: span 0-1 level MC
   groups: 1 0
   domain 1: span 0-1 level CPU
    groups: 0-1
-hda_intel: azx_get_response timeout, switching to polling mode: last cmd=0x006f0900
+e1000e 0000:00:19.0: PCI INT A disabled
+PM: Syncing filesystems ... done.
+Freezing user space processes ... (elapsed 0.00 seconds) done.
+Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
+Suspending console(s) (use no_console_suspend to debug)
+pci 0000:00:02.0: PCI INT A disabled
+sd 0:0:0:0: [sda] Synchronizing SCSI cache
+sd 0:0:0:0: [sda] Stopping disk
+ACPI handle has no context!
+ACPI handle has no context!
+sdhci-pci 0000:02:06.2: PCI INT C disabled
+ACPI handle has no context!
+ACPI handle has no context!
+iwlagn 0000:10:00.0: PCI INT A disabled
+ata2: port disabled. ignoring.
+ata_piix 0000:00:1f.1: PCI INT A disabled
+ehci_hcd 0000:00:1d.7: PCI INT A disabled
+uhci_hcd 0000:00:1d.2: PCI INT C disabled
+uhci_hcd 0000:00:1d.1: PCI INT B disabled
+uhci_hcd 0000:00:1d.0: PCI INT A disabled
+HDA Intel 0000:00:1b.0: PCI INT A disabled
+HDA Intel 0000:00:1b.0: power state changed by ACPI to D3
+ehci_hcd 0000:00:1a.7: PCI INT C disabled
+uhci_hcd 0000:00:1a.1: PCI INT B disabled
+uhci_hcd 0000:00:1a.0: PCI INT A disabled
+ACPI handle has no context!
+ACPI: Preparing to enter system sleep state S3
+Disabling non-boot CPUs ...
+CPU 1 is now offline
+SMP alternatives: switching to UP code
+CPU0 attaching NULL sched-domain.
+CPU1 attaching NULL sched-domain.
+CPU0 attaching NULL sched-domain.
+CPU1 is down
+ricoh-mmc: Suspending.
+ricoh-mmc: Controller is now re-enabled.
+Extended CMOS year: 2000
+x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
+Back to C!
+Extended CMOS year: 2000
+ricoh-mmc: Resuming.
+ricoh-mmc: Controller is now disabled.
+Enabling non-boot CPUs ...
+SMP alternatives: switching to SMP code
+Booting processor 1 APIC 0x1 ip 0x6000
+Initializing CPU#1
+Calibrating delay using timer specific routine.. 2660.01 BogoMIPS (lpj=5320031)
+CPU: L1 I cache: 32K, L1 D cache: 32K
+CPU: L2 cache: 2048K
+CPU: Physical Processor ID: 0
+CPU: Processor Core ID: 1
+x86 PAT enabled: cpu 1, old 0x7040600070406, new 0x7010600070106
+CPU1: Intel(R) Core(TM)2 Duo CPU     U7700  @ 1.33GHz stepping 0d
+CPU0 attaching NULL sched-domain.
+Switched to high resolution mode on CPU 1
+CPU0 attaching sched-domain:
+ domain 0: span 0-1 level MC
+  groups: 0 1
+  domain 1: span 0-1 level CPU
+   groups: 0-1
+CPU1 attaching sched-domain:
+ domain 0: span 0-1 level MC
+  groups: 1 0
+  domain 1: span 0-1 level CPU
+   groups: 0-1
+CPU1 is up
+ACPI: Waking up from system sleep state S3
+APIC error on CPU1: 00(40)
+ACPI: EC: non-query interrupt received, switching to interrupt mode
+pci 0000:00:02.0: restoring config space at offset 0x8 (was 0x1, writing 0x2001)
+pci 0000:00:02.1: restoring config space at offset 0x4 (was 0x4, writing 0xe0500004)
+pci 0000:00:02.1: restoring config space at offset 0x1 (was 0x900000, writing 0x900007)
+pci 0000:00:03.0: restoring config space at offset 0xf (was 0x100, writing 0x1ff)
+pci 0000:00:03.0: restoring config space at offset 0x4 (was 0xfed12004, writing 0xe0600004)
+pci 0000:00:03.2: restoring config space at offset 0xf (was 0x300, writing 0x30b)
+pci 0000:00:03.2: restoring config space at offset 0x8 (was 0x1, writing 0x2031)
+pci 0000:00:03.2: restoring config space at offset 0x7 (was 0x1, writing 0x2021)
+pci 0000:00:03.2: restoring config space at offset 0x6 (was 0x1, writing 0x2019)
+pci 0000:00:03.2: restoring config space at offset 0x5 (was 0x1, writing 0x2011)
+pci 0000:00:03.2: restoring config space at offset 0x4 (was 0x1, writing 0x2009)
+pci 0000:00:03.2: restoring config space at offset 0x1 (was 0xb00000, writing 0xb00001)
+serial 0000:00:03.3: restoring config space at offset 0xf (was 0x200, writing 0x20a)
+serial 0000:00:03.3: restoring config space at offset 0x5 (was 0x0, writing 0xe0601000)
+serial 0000:00:03.3: restoring config space at offset 0x4 (was 0x1, writing 0x2041)
+serial 0000:00:03.3: restoring config space at offset 0x1 (was 0xb00000, writing 0xb00007)
+pci 0000:00:19.0: restoring config space at offset 0xf (was 0x100, writing 0x10b)
+pci 0000:00:19.0: restoring config space at offset 0x6 (was 0x1, writing 0x2061)
+pci 0000:00:19.0: restoring config space at offset 0x5 (was 0x0, writing 0xe0640000)
+pci 0000:00:19.0: restoring config space at offset 0x1 (was 0x100000, writing 0x100003)
+uhci_hcd 0000:00:1a.0: enabling device (0000 -> 0001)
+uhci_hcd 0000:00:1a.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
+uhci_hcd 0000:00:1a.0: setting latency timer to 64
+uhci_hcd 0000:00:1a.0: restoring config space at offset 0xf (was 0x100, writing 0x10a)
+uhci_hcd 0000:00:1a.0: restoring config space at offset 0x8 (was 0x1, writing 0x2081)
+usb usb2: root hub lost power or was reset
+uhci_hcd 0000:00:1a.1: enabling device (0000 -> 0001)
+uhci_hcd 0000:00:1a.1: PCI INT B -> GSI 17 (level, low) -> IRQ 17
+uhci_hcd 0000:00:1a.1: setting latency timer to 64
+uhci_hcd 0000:00:1a.1: restoring config space at offset 0xf (was 0x200, writing 0x20a)
+uhci_hcd 0000:00:1a.1: restoring config space at offset 0x8 (was 0x1, writing 0x20a1)
+usb usb4: root hub lost power or was reset
+ehci_hcd 0000:00:1a.7: enabling device (0000 -> 0002)
+ehci_hcd 0000:00:1a.7: PCI INT C -> GSI 18 (level, low) -> IRQ 18
+ehci_hcd 0000:00:1a.7: setting latency timer to 64
+ehci_hcd 0000:00:1a.7: restoring config space at offset 0xf (was 0x300, writing 0x30b)
+ehci_hcd 0000:00:1a.7: restoring config space at offset 0x4 (was 0x0, writing 0xe0641000)
+HDA Intel 0000:00:1b.0: power state changed by ACPI to D0
+HDA Intel 0000:00:1b.0: restoring config space at offset 0xf (was 0x100, writing 0x10a)
+HDA Intel 0000:00:1b.0: restoring config space at offset 0x3 (was 0x0, writing 0x10)
+HDA Intel 0000:00:1b.0: restoring config space at offset 0x1 (was 0x100000, writing 0x100002)
+HDA Intel 0000:00:1b.0: power state changed by ACPI to D0
+HDA Intel 0000:00:1b.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
+HDA Intel 0000:00:1b.0: setting latency timer to 64
+pcieport-driver 0000:00:1c.0: restoring config space at offset 0xf (was 0x100, writing 0x4010a)
+pcieport-driver 0000:00:1c.0: restoring config space at offset 0x9 (was 0x10001, writing 0x1fff1)
+pcieport-driver 0000:00:1c.0: restoring config space at offset 0x8 (was 0x0, writing 0xfff0)
+pcieport-driver 0000:00:1c.0: restoring config space at offset 0x7 (was 0x0, writing 0x200000f0)
+pcieport-driver 0000:00:1c.0: restoring config space at offset 0x6 (was 0x0, writing 0x80800)
+pcieport-driver 0000:00:1c.0: restoring config space at offset 0x3 (was 0x810000, writing 0x810010)
+pcieport-driver 0000:00:1c.0: restoring config space at offset 0x1 (was 0x100000, writing 0x100407)
+pcieport-driver 0000:00:1c.0: setting latency timer to 64
+pcieport-driver 0000:00:1c.1: restoring config space at offset 0xf (was 0x200, writing 0x4020a)
+pcieport-driver 0000:00:1c.1: restoring config space at offset 0x9 (was 0x10001, writing 0x1fff1)
+pcieport-driver 0000:00:1c.1: restoring config space at offset 0x8 (was 0x0, writing 0xe000e000)
+pcieport-driver 0000:00:1c.1: restoring config space at offset 0x7 (was 0x0, writing 0xf0)
+pcieport-driver 0000:00:1c.1: restoring config space at offset 0x3 (was 0x810000, writing 0x810010)
+pcieport-driver 0000:00:1c.1: restoring config space at offset 0x1 (was 0x100000, writing 0x100407)
+pcieport-driver 0000:00:1c.1: setting latency timer to 64
+uhci_hcd 0000:00:1d.0: enabling device (0000 -> 0001)
+uhci_hcd 0000:00:1d.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20
+uhci_hcd 0000:00:1d.0: setting latency timer to 64
+uhci_hcd 0000:00:1d.0: restoring config space at offset 0xf (was 0x100, writing 0x10a)
+uhci_hcd 0000:00:1d.0: restoring config space at offset 0x8 (was 0x1, writing 0x20c1)
+usb usb5: root hub lost power or was reset
+uhci_hcd 0000:00:1d.1: enabling device (0000 -> 0001)
+uhci_hcd 0000:00:1d.1: PCI INT B -> GSI 22 (level, low) -> IRQ 22
+uhci_hcd 0000:00:1d.1: setting latency timer to 64
+uhci_hcd 0000:00:1d.1: restoring config space at offset 0xf (was 0x200, writing 0x20b)
+uhci_hcd 0000:00:1d.1: restoring config space at offset 0x8 (was 0x1, writing 0x20e1)
+usb usb6: root hub lost power or was reset
+uhci_hcd 0000:00:1d.2: enabling device (0000 -> 0001)
+uhci_hcd 0000:00:1d.2: PCI INT C -> GSI 18 (level, low) -> IRQ 18
+uhci_hcd 0000:00:1d.2: setting latency timer to 64
+uhci_hcd 0000:00:1d.2: restoring config space at offset 0xf (was 0x300, writing 0x30b)
+uhci_hcd 0000:00:1d.2: restoring config space at offset 0x8 (was 0x1, writing 0x2101)
+usb usb7: root hub lost power or was reset
+ehci_hcd 0000:00:1d.7: enabling device (0000 -> 0002)
+ehci_hcd 0000:00:1d.7: PCI INT A -> GSI 20 (level, low) -> IRQ 20
+ehci_hcd 0000:00:1d.7: setting latency timer to 64
+ehci_hcd 0000:00:1d.7: restoring config space at offset 0xf (was 0x100, writing 0x10a)
+ehci_hcd 0000:00:1d.7: restoring config space at offset 0x4 (was 0x0, writing 0xe0648000)
+pci 0000:00:1e.0: restoring config space at offset 0x9 (was 0x10001, writing 0x1fff1)
+pci 0000:00:1e.0: restoring config space at offset 0x8 (was 0x0, writing 0xe030e010)
+pci 0000:00:1e.0: restoring config space at offset 0x7 (was 0x228000f0, writing 0x22803030)
+pci 0000:00:1e.0: restoring config space at offset 0x1 (was 0x100007, writing 0x100107)
+pci 0000:00:1e.0: setting latency timer to 64
+ata_piix 0000:00:1f.1: restoring config space at offset 0xf (was 0x100, writing 0x10a)
+ata_piix 0000:00:1f.1: restoring config space at offset 0x8 (was 0xc01, writing 0x2121)
+ata_piix 0000:00:1f.1: restoring config space at offset 0x1 (was 0x2800005, writing 0x2880005)
+ata_piix 0000:00:1f.1: PCI INT A -> GSI 16 (level, low) -> IRQ 16
+ata_piix 0000:00:1f.1: setting latency timer to 64
+ata2: port disabled. ignoring.
+ACPI Exception (exoparg2-0444): AE_AML_PACKAGE_LIMIT, Index (000000005) is beyond end of object [20080926]
+ACPI Error (psparse-0524): Method parse/execution failed [\_SB_.C2C3] (Node ffff88007e01de80), AE_AML_PACKAGE_LIMIT
+ACPI Error (psparse-0524): Method parse/execution failed [\_SB_.C003.C0F6.C3F3._STM] (Node ffff88007e043dc0), AE_AML_PACKAGE_LIMIT
+ata1: ACPI set timing mode failed (status=0x300b)
+iwlagn 0000:10:00.0: enabling device (0000 -> 0002)
+iwlagn 0000:10:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
+iwlagn 0000:10:00.0: restoring config space at offset 0xf (was 0x100, writing 0x10a)
+iwlagn 0000:10:00.0: restoring config space at offset 0x4 (was 0x4, writing 0xe0000004)
+iwlagn 0000:10:00.0: restoring config space at offset 0x3 (was 0x0, writing 0x10)
+iwlagn 0000:10:00.0: restoring config space at offset 0x1 (was 0x100002, writing 0x100006)
+iwlagn 0000:10:00.0: irq 509 for MSI/MSI-X
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0xf (was 0x3000100, writing 0x580010b)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0xe (was 0x0, writing 0x34fc)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0xd (was 0x0, writing 0x3400)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0xc (was 0x0, writing 0x30fc)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0xb (was 0x0, writing 0x3000)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0xa (was 0x0, writing 0x83fff000)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0x9 (was 0x0, writing 0x80000000)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0x8 (was 0x0, writing 0x847ff000)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0x7 (was 0x0, writing 0x84400000)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0x6 (was 0x0, writing 0xb0060302)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0x4 (was 0x0, writing 0xe0100000)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0x3 (was 0x820000, writing 0x82a800)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0x1 (was 0x2100000, writing 0x2100007)
+ohci1394 0000:02:06.1: restoring config space at offset 0xf (was 0x4020200, writing 0x4020205)
+ohci1394 0000:02:06.1: restoring config space at offset 0x4 (was 0x0, writing 0xe0101000)
+ohci1394 0000:02:06.1: restoring config space at offset 0x3 (was 0x800000, writing 0x804010)
+ohci1394 0000:02:06.1: restoring config space at offset 0x1 (was 0x2100000, writing 0x2100006)
+Registered led device: iwl-phy0:radio
+Registered led device: iwl-phy0:assoc
+Registered led device: iwl-phy0:RX
+Registered led device: iwl-phy0:TX
+ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[19]  MMIO=[e0101000-e01017ff]  Max Packet=[2048]  IR/IT contexts=[4/4]
+sdhci-pci 0000:02:06.2: restoring config space at offset 0xf (was 0x300, writing 0x30a)
+sdhci-pci 0000:02:06.2: restoring config space at offset 0x4 (was 0x0, writing 0xe0102000)
+sdhci-pci 0000:02:06.2: restoring config space at offset 0x3 (was 0x800000, writing 0x804010)
+sdhci-pci 0000:02:06.2: restoring config space at offset 0x1 (was 0x2100000, writing 0x2100006)
+sdhci-pci 0000:02:06.2: PCI INT C -> GSI 20 (level, low) -> IRQ 20
+sd 0:0:0:0: [sda] Starting disk
+ata1.01: ACPI cmd ef/03:0c:00:00:00:b0 filtered out
+ata1.01: ACPI cmd ef/03:40:00:00:00:b0 filtered out
+ata1.00: ACPI cmd ef/03:01:00:00:00:a0 filtered out
+ata1.00: ACPI cmd ef/03:45:00:00:00:a0 filtered out
+ata1.00: ACPI cmd f5/00:00:00:00:00:a0 filtered out
+ata1.00: ACPI cmd b1/c1:00:00:00:00:a0 filtered out
+ata1.00: ACPI cmd c6/00:10:00:00:00:a0 succeeded
+ata1.00: configured for UDMA/100
+ata1.01: configured for MWDMA2
+ata1.00: configured for UDMA/100
+ata1.01: configured for MWDMA2
+ata1: EH complete
+sd 0:0:0:0: [sda] 234441648 512-byte hardware sectors: (120 GB/111 GiB)
+sd 0:0:0:0: [sda] Write Protect is off
+sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
+sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
+sd 0:0:0:0: [sda] 234441648 512-byte hardware sectors: (120 GB/111 GiB)
+sd 0:0:0:0: [sda] Write Protect is off
+sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
+sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
+usb 5-2: reset full speed USB device using uhci_hcd and address 2
+usb 2-1: reset full speed USB device using uhci_hcd and address 2
+pci 0000:00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
+pci 0000:00:02.0: setting latency timer to 64
+Restarting tasks ... done.
+e1000e: Intel(R) PRO/1000 Network Driver - 0.3.3.3-k6
+e1000e: Copyright (c) 1999-2008 Intel Corporation.
+e1000e 0000:00:19.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22
+e1000e 0000:00:19.0: setting latency timer to 64
+e1000e 0000:00:19.0: irq 508 for MSI/MSI-X
+0000:00:19.0: eth0: (PCI Express:2.5GB/s:Width x1) 00:1e:68:5e:3b:04
+0000:00:19.0: eth0: Intel(R) PRO/1000 Network Connection
+0000:00:19.0: eth0: MAC: 5, PHY: 6, PBA No: ffffff-0ff
+PM: Syncing filesystems ... done.
+Freezing user space processes ... (elapsed 0.00 seconds) done.
+Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
+Suspending console(s) (use no_console_suspend to debug)
+pci 0000:00:02.0: PCI INT A disabled
+sd 0:0:0:0: [sda] Synchronizing SCSI cache
+sd 0:0:0:0: [sda] Stopping disk
+ACPI handle has no context!
+ACPI handle has no context!
+sdhci-pci 0000:02:06.2: PCI INT C disabled
+ACPI handle has no context!
+ACPI handle has no context!
+iwlagn 0000:10:00.0: PCI INT A disabled
+ata2: port disabled. ignoring.
+ata_piix 0000:00:1f.1: PCI INT A disabled
+ehci_hcd 0000:00:1d.7: PCI INT A disabled
+uhci_hcd 0000:00:1d.2: PCI INT C disabled
+uhci_hcd 0000:00:1d.1: PCI INT B disabled
+uhci_hcd 0000:00:1d.0: PCI INT A disabled
+HDA Intel 0000:00:1b.0: PCI INT A disabled
+HDA Intel 0000:00:1b.0: power state changed by ACPI to D3
+ehci_hcd 0000:00:1a.7: PCI INT C disabled
+uhci_hcd 0000:00:1a.1: PCI INT B disabled
+uhci_hcd 0000:00:1a.0: PCI INT A disabled
+e1000e 0000:00:19.0: PME# enabled
+e1000e 0000:00:19.0: wake-up capability enabled by ACPI
+e1000e 0000:00:19.0: PME# enabled
+e1000e 0000:00:19.0: wake-up capability enabled by ACPI
+e1000e 0000:00:19.0: PCI INT A disabled
+ACPI handle has no context!
+ACPI: Preparing to enter system sleep state S3
+Disabling non-boot CPUs ...
+CPU 1 is now offline
+SMP alternatives: switching to UP code
+CPU0 attaching NULL sched-domain.
+CPU1 attaching NULL sched-domain.
+CPU0 attaching NULL sched-domain.
+CPU1 is down
+ricoh-mmc: Suspending.
+ricoh-mmc: Controller is now re-enabled.
+Extended CMOS year: 2000
+x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
+Back to C!
+Extended CMOS year: 2000
+ricoh-mmc: Resuming.
+ricoh-mmc: Controller is now disabled.
+Enabling non-boot CPUs ...
+SMP alternatives: switching to SMP code
+Booting processor 1 APIC 0x1 ip 0x6000
+Initializing CPU#1
+Calibrating delay using timer specific routine.. 2660.06 BogoMIPS (lpj=5320131)
+CPU: L1 I cache: 32K, L1 D cache: 32K
+CPU: L2 cache: 2048K
+CPU: Physical Processor ID: 0
+CPU: Processor Core ID: 1
+x86 PAT enabled: cpu 1, old 0x7040600070406, new 0x7010600070106
+CPU1: Intel(R) Core(TM)2 Duo CPU     U7700  @ 1.33GHz stepping 0d
+CPU0 attaching NULL sched-domain.
+Switched to high resolution mode on CPU 1
+CPU0 attaching sched-domain:
+ domain 0: span 0-1 level MC
+  groups: 0 1
+  domain 1: span 0-1 level CPU
+   groups: 0-1
+CPU1 attaching sched-domain:
+ domain 0: span 0-1 level MC
+  groups: 1 0
+  domain 1: span 0-1 level CPU
+   groups: 0-1
+CPU1 is up
+ACPI: Waking up from system sleep state S3
+APIC error on CPU1: 00(40)
+ACPI: EC: non-query interrupt received, switching to interrupt mode
+pci 0000:00:02.0: restoring config space at offset 0x8 (was 0x1, writing 0x2001)
+pci 0000:00:02.1: restoring config space at offset 0x4 (was 0x4, writing 0xe0500004)
+pci 0000:00:02.1: restoring config space at offset 0x1 (was 0x900000, writing 0x900007)
+pci 0000:00:03.0: restoring config space at offset 0xf (was 0x100, writing 0x1ff)
+pci 0000:00:03.0: restoring config space at offset 0x4 (was 0xfed12004, writing 0xe0600004)
+pci 0000:00:03.0: restoring config space at offset 0x1 (was 0x100006, writing 0x180006)
+pci 0000:00:03.2: restoring config space at offset 0xf (was 0x300, writing 0x30b)
+pci 0000:00:03.2: restoring config space at offset 0x8 (was 0x1, writing 0x2031)
+pci 0000:00:03.2: restoring config space at offset 0x7 (was 0x1, writing 0x2021)
+pci 0000:00:03.2: restoring config space at offset 0x6 (was 0x1, writing 0x2019)
+pci 0000:00:03.2: restoring config space at offset 0x5 (was 0x1, writing 0x2011)
+pci 0000:00:03.2: restoring config space at offset 0x4 (was 0x1, writing 0x2009)
+pci 0000:00:03.2: restoring config space at offset 0x1 (was 0xb00000, writing 0xb00001)
+serial 0000:00:03.3: restoring config space at offset 0xf (was 0x200, writing 0x20a)
+serial 0000:00:03.3: restoring config space at offset 0x5 (was 0x0, writing 0xe0601000)
+serial 0000:00:03.3: restoring config space at offset 0x4 (was 0x1, writing 0x2041)
+serial 0000:00:03.3: restoring config space at offset 0x1 (was 0xb00000, writing 0xb00007)
+e1000e 0000:00:19.0: restoring config space at offset 0xf (was 0x100, writing 0x10b)
+e1000e 0000:00:19.0: restoring config space at offset 0x6 (was 0x1, writing 0x2061)
+e1000e 0000:00:19.0: restoring config space at offset 0x5 (was 0x0, writing 0xe0640000)
+e1000e 0000:00:19.0: restoring config space at offset 0x1 (was 0x100000, writing 0x100007)
+e1000e 0000:00:19.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22
+e1000e 0000:00:19.0: setting latency timer to 64
+e1000e 0000:00:19.0: wake-up capability disabled by ACPI
+e1000e 0000:00:19.0: PME# disabled
+e1000e 0000:00:19.0: wake-up capability disabled by ACPI
+e1000e 0000:00:19.0: PME# disabled
+e1000e 0000:00:19.0: irq 509 for MSI/MSI-X
+uhci_hcd 0000:00:1a.0: enabling device (0000 -> 0001)
+uhci_hcd 0000:00:1a.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
+uhci_hcd 0000:00:1a.0: setting latency timer to 64
+uhci_hcd 0000:00:1a.0: restoring config space at offset 0xf (was 0x100, writing 0x10a)
+uhci_hcd 0000:00:1a.0: restoring config space at offset 0x8 (was 0x1, writing 0x2081)
+usb usb2: root hub lost power or was reset
+uhci_hcd 0000:00:1a.1: enabling device (0000 -> 0001)
+uhci_hcd 0000:00:1a.1: PCI INT B -> GSI 17 (level, low) -> IRQ 17
+uhci_hcd 0000:00:1a.1: setting latency timer to 64
+uhci_hcd 0000:00:1a.1: restoring config space at offset 0xf (was 0x200, writing 0x20a)
+uhci_hcd 0000:00:1a.1: restoring config space at offset 0x8 (was 0x1, writing 0x20a1)
+usb usb4: root hub lost power or was reset
+ehci_hcd 0000:00:1a.7: enabling device (0000 -> 0002)
+ehci_hcd 0000:00:1a.7: PCI INT C -> GSI 18 (level, low) -> IRQ 18
+ehci_hcd 0000:00:1a.7: setting latency timer to 64
+ehci_hcd 0000:00:1a.7: restoring config space at offset 0xf (was 0x300, writing 0x30b)
+ehci_hcd 0000:00:1a.7: restoring config space at offset 0x4 (was 0x0, writing 0xe0641000)
+HDA Intel 0000:00:1b.0: power state changed by ACPI to D0
+HDA Intel 0000:00:1b.0: restoring config space at offset 0xf (was 0x100, writing 0x10a)
+HDA Intel 0000:00:1b.0: restoring config space at offset 0x3 (was 0x0, writing 0x10)
+HDA Intel 0000:00:1b.0: restoring config space at offset 0x1 (was 0x100000, writing 0x100002)
+HDA Intel 0000:00:1b.0: power state changed by ACPI to D0
+HDA Intel 0000:00:1b.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
+HDA Intel 0000:00:1b.0: setting latency timer to 64
+pcieport-driver 0000:00:1c.0: restoring config space at offset 0xf (was 0x100, writing 0x4010a)
+pcieport-driver 0000:00:1c.0: restoring config space at offset 0x9 (was 0x10001, writing 0x1fff1)
+pcieport-driver 0000:00:1c.0: restoring config space at offset 0x8 (was 0x0, writing 0xfff0)
+pcieport-driver 0000:00:1c.0: restoring config space at offset 0x7 (was 0x0, writing 0xf0)
+pcieport-driver 0000:00:1c.0: restoring config space at offset 0x6 (was 0x0, writing 0x80800)
+pcieport-driver 0000:00:1c.0: restoring config space at offset 0x3 (was 0x810000, writing 0x810010)
+pcieport-driver 0000:00:1c.0: restoring config space at offset 0x1 (was 0x100000, writing 0x100407)
+pcieport-driver 0000:00:1c.0: setting latency timer to 64
+pcieport-driver 0000:00:1c.1: restoring config space at offset 0xf (was 0x200, writing 0x4020a)
+pcieport-driver 0000:00:1c.1: restoring config space at offset 0x9 (was 0x10001, writing 0x1fff1)
+pcieport-driver 0000:00:1c.1: restoring config space at offset 0x8 (was 0x0, writing 0xe000e000)
+pcieport-driver 0000:00:1c.1: restoring config space at offset 0x7 (was 0x0, writing 0xf0)
+pcieport-driver 0000:00:1c.1: restoring config space at offset 0x3 (was 0x810000, writing 0x810010)
+pcieport-driver 0000:00:1c.1: restoring config space at offset 0x1 (was 0x100000, writing 0x100407)
+pcieport-driver 0000:00:1c.1: setting latency timer to 64
+uhci_hcd 0000:00:1d.0: enabling device (0000 -> 0001)
+uhci_hcd 0000:00:1d.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20
+uhci_hcd 0000:00:1d.0: setting latency timer to 64
+uhci_hcd 0000:00:1d.0: restoring config space at offset 0xf (was 0x100, writing 0x10a)
+uhci_hcd 0000:00:1d.0: restoring config space at offset 0x8 (was 0x1, writing 0x20c1)
+usb usb5: root hub lost power or was reset
+uhci_hcd 0000:00:1d.1: enabling device (0000 -> 0001)
+uhci_hcd 0000:00:1d.1: PCI INT B -> GSI 22 (level, low) -> IRQ 22
+uhci_hcd 0000:00:1d.1: setting latency timer to 64
+uhci_hcd 0000:00:1d.1: restoring config space at offset 0xf (was 0x200, writing 0x20b)
+uhci_hcd 0000:00:1d.1: restoring config space at offset 0x8 (was 0x1, writing 0x20e1)
+usb usb6: root hub lost power or was reset
+uhci_hcd 0000:00:1d.2: enabling device (0000 -> 0001)
+uhci_hcd 0000:00:1d.2: PCI INT C -> GSI 18 (level, low) -> IRQ 18
+uhci_hcd 0000:00:1d.2: setting latency timer to 64
+uhci_hcd 0000:00:1d.2: restoring config space at offset 0xf (was 0x300, writing 0x30b)
+uhci_hcd 0000:00:1d.2: restoring config space at offset 0x8 (was 0x1, writing 0x2101)
+usb usb7: root hub lost power or was reset
+ehci_hcd 0000:00:1d.7: enabling device (0000 -> 0002)
+ehci_hcd 0000:00:1d.7: PCI INT A -> GSI 20 (level, low) -> IRQ 20
+ehci_hcd 0000:00:1d.7: setting latency timer to 64
+ehci_hcd 0000:00:1d.7: restoring config space at offset 0xf (was 0x100, writing 0x10a)
+ehci_hcd 0000:00:1d.7: restoring config space at offset 0x4 (was 0x0, writing 0xe0648000)
+pci 0000:00:1e.0: restoring config space at offset 0x9 (was 0x10001, writing 0x1fff1)
+pci 0000:00:1e.0: restoring config space at offset 0x8 (was 0x0, writing 0xe030e010)
+pci 0000:00:1e.0: restoring config space at offset 0x7 (was 0x228000f0, writing 0x22803030)
+pci 0000:00:1e.0: restoring config space at offset 0x1 (was 0x100007, writing 0x100107)
+pci 0000:00:1e.0: setting latency timer to 64
+ata_piix 0000:00:1f.1: restoring config space at offset 0xf (was 0x100, writing 0x10a)
+ata_piix 0000:00:1f.1: restoring config space at offset 0x8 (was 0xc01, writing 0x2121)
+ata_piix 0000:00:1f.1: restoring config space at offset 0x1 (was 0x2800005, writing 0x2880005)
+ata_piix 0000:00:1f.1: PCI INT A -> GSI 16 (level, low) -> IRQ 16
+ata_piix 0000:00:1f.1: setting latency timer to 64
+ata2: port disabled. ignoring.
+ACPI Exception (exoparg2-0444): AE_AML_PACKAGE_LIMIT, Index (000000005) is beyond end of object [20080926]
+ACPI Error (psparse-0524): Method parse/execution failed [\_SB_.C2C3] (Node ffff88007e01de80), AE_AML_PACKAGE_LIMIT
+ACPI Error (psparse-0524): Method parse/execution failed [\_SB_.C003.C0F6.C3F3._STM] (Node ffff88007e043dc0), AE_AML_PACKAGE_LIMIT
+ata1: ACPI set timing mode failed (status=0x300b)
+iwlagn 0000:10:00.0: enabling device (0000 -> 0002)
+iwlagn 0000:10:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
+iwlagn 0000:10:00.0: restoring config space at offset 0xf (was 0x100, writing 0x10a)
+iwlagn 0000:10:00.0: restoring config space at offset 0x4 (was 0x4, writing 0xe0000004)
+iwlagn 0000:10:00.0: restoring config space at offset 0x3 (was 0x0, writing 0x10)
+iwlagn 0000:10:00.0: restoring config space at offset 0x1 (was 0x100002, writing 0x100006)
+iwlagn 0000:10:00.0: irq 508 for MSI/MSI-X
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0xf (was 0x3000100, writing 0x580010b)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0xe (was 0x0, writing 0x34fc)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0xd (was 0x0, writing 0x3400)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0xc (was 0x0, writing 0x30fc)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0xb (was 0x0, writing 0x3000)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0xa (was 0x0, writing 0x83fff000)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0x9 (was 0x0, writing 0x80000000)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0x8 (was 0x0, writing 0x847ff000)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0x7 (was 0x0, writing 0x84400000)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0x6 (was 0x0, writing 0xb0060302)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0x4 (was 0x0, writing 0xe0100000)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0x3 (was 0x820000, writing 0x82a800)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0x1 (was 0x2100000, writing 0x2100007)
+ohci1394 0000:02:06.1: restoring config space at offset 0xf (was 0x4020200, writing 0x4020205)
+ohci1394 0000:02:06.1: restoring config space at offset 0x4 (was 0x0, writing 0xe0101000)
+ohci1394 0000:02:06.1: restoring config space at offset 0x3 (was 0x800000, writing 0x804010)
+ohci1394 0000:02:06.1: restoring config space at offset 0x1 (was 0x2100000, writing 0x2100006)
+ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[19]  MMIO=[e0101000-e01017ff]  Max Packet=[2048]  IR/IT contexts=[4/4]
+sdhci-pci 0000:02:06.2: restoring config space at offset 0xf (was 0x300, writing 0x30a)
+sdhci-pci 0000:02:06.2: restoring config space at offset 0x4 (was 0x0, writing 0xe0102000)
+sdhci-pci 0000:02:06.2: restoring config space at offset 0x3 (was 0x800000, writing 0x804010)
+sdhci-pci 0000:02:06.2: restoring config space at offset 0x1 (was 0x2100000, writing 0x2100006)
+sdhci-pci 0000:02:06.2: PCI INT C -> GSI 20 (level, low) -> IRQ 20
+Registered led device: iwl-phy0:radio
+Registered led device: iwl-phy0:assoc
+Registered led device: iwl-phy0:RX
+Registered led device: iwl-phy0:TX
+sd 0:0:0:0: [sda] Starting disk
+ata1.01: ACPI cmd ef/03:0c:00:00:00:b0 filtered out
+ata1.01: ACPI cmd ef/03:40:00:00:00:b0 filtered out
+ata1.00: ACPI cmd ef/03:01:00:00:00:a0 filtered out
+ata1.00: ACPI cmd ef/03:45:00:00:00:a0 filtered out
+ata1.00: ACPI cmd f5/00:00:00:00:00:a0 filtered out
+ata1.00: ACPI cmd b1/c1:00:00:00:00:a0 filtered out
+ata1.00: ACPI cmd c6/00:10:00:00:00:a0 succeeded
+ata1.00: configured for UDMA/100
+ata1.01: configured for MWDMA2
+ata1.00: configured for UDMA/100
+ata1.01: configured for MWDMA2
+ata1: EH complete
+sd 0:0:0:0: [sda] 234441648 512-byte hardware sectors: (120 GB/111 GiB)
+sd 0:0:0:0: [sda] Write Protect is off
+sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
+sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
+sd 0:0:0:0: [sda] 234441648 512-byte hardware sectors: (120 GB/111 GiB)
+sd 0:0:0:0: [sda] Write Protect is off
+sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
+sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
+usb 5-2: reset full speed USB device using uhci_hcd and address 2
+usb 2-1: reset full speed USB device using uhci_hcd and address 2
+pci 0000:00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
+pci 0000:00:02.0: setting latency timer to 64
+Restarting tasks ... done.
+PM: Syncing filesystems ... done.
+Freezing user space processes ... (elapsed 0.00 seconds) done.
+Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done.
+Suspending console(s) (use no_console_suspend to debug)
+pci 0000:00:02.0: PCI INT A disabled
+sd 0:0:0:0: [sda] Synchronizing SCSI cache
+sd 0:0:0:0: [sda] Stopping disk
+ACPI handle has no context!
+ACPI handle has no context!
+sdhci-pci 0000:02:06.2: PCI INT C disabled
+ACPI handle has no context!
+ACPI handle has no context!
+iwlagn 0000:10:00.0: PCI INT A disabled
+ata2: port disabled. ignoring.
+ata_piix 0000:00:1f.1: PCI INT A disabled
+ehci_hcd 0000:00:1d.7: PCI INT A disabled
+uhci_hcd 0000:00:1d.2: PCI INT C disabled
+uhci_hcd 0000:00:1d.1: PCI INT B disabled
+uhci_hcd 0000:00:1d.0: PCI INT A disabled
+HDA Intel 0000:00:1b.0: PCI INT A disabled
+HDA Intel 0000:00:1b.0: power state changed by ACPI to D3
+ehci_hcd 0000:00:1a.7: PCI INT C disabled
+uhci_hcd 0000:00:1a.1: PCI INT B disabled
+uhci_hcd 0000:00:1a.0: PCI INT A disabled
+e1000e 0000:00:19.0: PME# enabled
+e1000e 0000:00:19.0: wake-up capability enabled by ACPI
+e1000e 0000:00:19.0: PME# enabled
+e1000e 0000:00:19.0: wake-up capability enabled by ACPI
+e1000e 0000:00:19.0: PCI INT A disabled
+ACPI handle has no context!
+ACPI: Preparing to enter system sleep state S3
+Disabling non-boot CPUs ...
+CPU 1 is now offline
+SMP alternatives: switching to UP code
+CPU0 attaching NULL sched-domain.
+CPU1 attaching NULL sched-domain.
+CPU0 attaching NULL sched-domain.
+CPU1 is down
+ricoh-mmc: Suspending.
+ricoh-mmc: Controller is now re-enabled.
+Extended CMOS year: 2000
+x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
+Back to C!
+Extended CMOS year: 2000
+ricoh-mmc: Resuming.
+ricoh-mmc: Controller is now disabled.
+Enabling non-boot CPUs ...
+SMP alternatives: switching to SMP code
+Booting processor 1 APIC 0x1 ip 0x6000
+Initializing CPU#1
+Calibrating delay using timer specific routine.. 2660.08 BogoMIPS (lpj=5320176)
+CPU: L1 I cache: 32K, L1 D cache: 32K
+CPU: L2 cache: 2048K
+CPU: Physical Processor ID: 0
+CPU: Processor Core ID: 1
+x86 PAT enabled: cpu 1, old 0x7040600070406, new 0x7010600070106
+CPU1: Intel(R) Core(TM)2 Duo CPU     U7700  @ 1.33GHz stepping 0d
+CPU0 attaching NULL sched-domain.
+Switched to high resolution mode on CPU 1
+CPU0 attaching sched-domain:
+ domain 0: span 0-1 level MC
+  groups: 0 1
+  domain 1: span 0-1 level CPU
+   groups: 0-1
+CPU1 attaching sched-domain:
+ domain 0: span 0-1 level MC
+  groups: 1 0
+  domain 1: span 0-1 level CPU
+   groups: 0-1
+CPU1 is up
+ACPI: Waking up from system sleep state S3
+APIC error on CPU1: 00(40)
+ACPI: EC: non-query interrupt received, switching to interrupt mode
+pci 0000:00:02.0: restoring config space at offset 0x8 (was 0x1, writing 0x2001)
+pci 0000:00:02.1: restoring config space at offset 0x4 (was 0x4, writing 0xe0500004)
+pci 0000:00:02.1: restoring config space at offset 0x1 (was 0x900000, writing 0x900007)
+pci 0000:00:03.0: restoring config space at offset 0xf (was 0x100, writing 0x1ff)
+pci 0000:00:03.0: restoring config space at offset 0x4 (was 0xfed12004, writing 0xe0600004)
+pci 0000:00:03.0: restoring config space at offset 0x1 (was 0x100006, writing 0x180006)
+pci 0000:00:03.2: restoring config space at offset 0xf (was 0x300, writing 0x30b)
+pci 0000:00:03.2: restoring config space at offset 0x8 (was 0x1, writing 0x2031)
+pci 0000:00:03.2: restoring config space at offset 0x7 (was 0x1, writing 0x2021)
+pci 0000:00:03.2: restoring config space at offset 0x6 (was 0x1, writing 0x2019)
+pci 0000:00:03.2: restoring config space at offset 0x5 (was 0x1, writing 0x2011)
+pci 0000:00:03.2: restoring config space at offset 0x4 (was 0x1, writing 0x2009)
+pci 0000:00:03.2: restoring config space at offset 0x1 (was 0xb00000, writing 0xb00001)
+serial 0000:00:03.3: restoring config space at offset 0xf (was 0x200, writing 0x20a)
+serial 0000:00:03.3: restoring config space at offset 0x5 (was 0x0, writing 0xe0601000)
+serial 0000:00:03.3: restoring config space at offset 0x4 (was 0x1, writing 0x2041)
+serial 0000:00:03.3: restoring config space at offset 0x1 (was 0xb00000, writing 0xb00007)
+e1000e 0000:00:19.0: restoring config space at offset 0xf (was 0x100, writing 0x10b)
+e1000e 0000:00:19.0: restoring config space at offset 0x6 (was 0x1, writing 0x2061)
+e1000e 0000:00:19.0: restoring config space at offset 0x5 (was 0x0, writing 0xe0640000)
+e1000e 0000:00:19.0: restoring config space at offset 0x1 (was 0x100000, writing 0x100007)
+e1000e 0000:00:19.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22
+e1000e 0000:00:19.0: setting latency timer to 64
+e1000e 0000:00:19.0: wake-up capability disabled by ACPI
+e1000e 0000:00:19.0: PME# disabled
+e1000e 0000:00:19.0: wake-up capability disabled by ACPI
+e1000e 0000:00:19.0: PME# disabled
+e1000e 0000:00:19.0: irq 509 for MSI/MSI-X
+uhci_hcd 0000:00:1a.0: enabling device (0000 -> 0001)
+uhci_hcd 0000:00:1a.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
+uhci_hcd 0000:00:1a.0: setting latency timer to 64
+uhci_hcd 0000:00:1a.0: restoring config space at offset 0xf (was 0x100, writing 0x10a)
+uhci_hcd 0000:00:1a.0: restoring config space at offset 0x8 (was 0x1, writing 0x2081)
+usb usb2: root hub lost power or was reset
+uhci_hcd 0000:00:1a.1: enabling device (0000 -> 0001)
+uhci_hcd 0000:00:1a.1: PCI INT B -> GSI 17 (level, low) -> IRQ 17
+uhci_hcd 0000:00:1a.1: setting latency timer to 64
+uhci_hcd 0000:00:1a.1: restoring config space at offset 0xf (was 0x200, writing 0x20a)
+uhci_hcd 0000:00:1a.1: restoring config space at offset 0x8 (was 0x1, writing 0x20a1)
+usb usb4: root hub lost power or was reset
+ehci_hcd 0000:00:1a.7: enabling device (0000 -> 0002)
+ehci_hcd 0000:00:1a.7: PCI INT C -> GSI 18 (level, low) -> IRQ 18
+ehci_hcd 0000:00:1a.7: setting latency timer to 64
+ehci_hcd 0000:00:1a.7: restoring config space at offset 0xf (was 0x300, writing 0x30b)
+ehci_hcd 0000:00:1a.7: restoring config space at offset 0x4 (was 0x0, writing 0xe0641000)
+HDA Intel 0000:00:1b.0: power state changed by ACPI to D0
+HDA Intel 0000:00:1b.0: restoring config space at offset 0xf (was 0x100, writing 0x10a)
+HDA Intel 0000:00:1b.0: restoring config space at offset 0x3 (was 0x0, writing 0x10)
+HDA Intel 0000:00:1b.0: restoring config space at offset 0x1 (was 0x100000, writing 0x100002)
+HDA Intel 0000:00:1b.0: power state changed by ACPI to D0
+HDA Intel 0000:00:1b.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
+HDA Intel 0000:00:1b.0: setting latency timer to 64
+pcieport-driver 0000:00:1c.0: restoring config space at offset 0xf (was 0x100, writing 0x4010a)
+pcieport-driver 0000:00:1c.0: restoring config space at offset 0x9 (was 0x10001, writing 0x1fff1)
+pcieport-driver 0000:00:1c.0: restoring config space at offset 0x8 (was 0x0, writing 0xfff0)
+pcieport-driver 0000:00:1c.0: restoring config space at offset 0x7 (was 0x0, writing 0xf0)
+pcieport-driver 0000:00:1c.0: restoring config space at offset 0x6 (was 0x0, writing 0x80800)
+pcieport-driver 0000:00:1c.0: restoring config space at offset 0x3 (was 0x810000, writing 0x810010)
+pcieport-driver 0000:00:1c.0: restoring config space at offset 0x1 (was 0x100000, writing 0x100407)
+pcieport-driver 0000:00:1c.0: setting latency timer to 64
+pcieport-driver 0000:00:1c.1: restoring config space at offset 0xf (was 0x200, writing 0x4020a)
+pcieport-driver 0000:00:1c.1: restoring config space at offset 0x9 (was 0x10001, writing 0x1fff1)
+pcieport-driver 0000:00:1c.1: restoring config space at offset 0x8 (was 0x0, writing 0xe000e000)
+pcieport-driver 0000:00:1c.1: restoring config space at offset 0x7 (was 0x0, writing 0xf0)
+pcieport-driver 0000:00:1c.1: restoring config space at offset 0x3 (was 0x810000, writing 0x810010)
+pcieport-driver 0000:00:1c.1: restoring config space at offset 0x1 (was 0x100000, writing 0x100407)
+pcieport-driver 0000:00:1c.1: setting latency timer to 64
+uhci_hcd 0000:00:1d.0: enabling device (0000 -> 0001)
+uhci_hcd 0000:00:1d.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20
+uhci_hcd 0000:00:1d.0: setting latency timer to 64
+uhci_hcd 0000:00:1d.0: restoring config space at offset 0xf (was 0x100, writing 0x10a)
+uhci_hcd 0000:00:1d.0: restoring config space at offset 0x8 (was 0x1, writing 0x20c1)
+usb usb5: root hub lost power or was reset
+uhci_hcd 0000:00:1d.1: enabling device (0000 -> 0001)
+uhci_hcd 0000:00:1d.1: PCI INT B -> GSI 22 (level, low) -> IRQ 22
+uhci_hcd 0000:00:1d.1: setting latency timer to 64
+uhci_hcd 0000:00:1d.1: restoring config space at offset 0xf (was 0x200, writing 0x20b)
+uhci_hcd 0000:00:1d.1: restoring config space at offset 0x8 (was 0x1, writing 0x20e1)
+usb usb6: root hub lost power or was reset
+uhci_hcd 0000:00:1d.2: enabling device (0000 -> 0001)
+uhci_hcd 0000:00:1d.2: PCI INT C -> GSI 18 (level, low) -> IRQ 18
+uhci_hcd 0000:00:1d.2: setting latency timer to 64
+uhci_hcd 0000:00:1d.2: restoring config space at offset 0xf (was 0x300, writing 0x30b)
+uhci_hcd 0000:00:1d.2: restoring config space at offset 0x8 (was 0x1, writing 0x2101)
+usb usb7: root hub lost power or was reset
+ehci_hcd 0000:00:1d.7: enabling device (0000 -> 0002)
+ehci_hcd 0000:00:1d.7: PCI INT A -> GSI 20 (level, low) -> IRQ 20
+ehci_hcd 0000:00:1d.7: setting latency timer to 64
+ehci_hcd 0000:00:1d.7: restoring config space at offset 0xf (was 0x100, writing 0x10a)
+ehci_hcd 0000:00:1d.7: restoring config space at offset 0x4 (was 0x0, writing 0xe0648000)
+pci 0000:00:1e.0: restoring config space at offset 0x9 (was 0x10001, writing 0x1fff1)
+pci 0000:00:1e.0: restoring config space at offset 0x8 (was 0x0, writing 0xe030e010)
+pci 0000:00:1e.0: restoring config space at offset 0x7 (was 0x228000f0, writing 0x22803030)
+pci 0000:00:1e.0: restoring config space at offset 0x1 (was 0x100007, writing 0x100107)
+pci 0000:00:1e.0: setting latency timer to 64
+ata_piix 0000:00:1f.1: restoring config space at offset 0xf (was 0x100, writing 0x10a)
+ata_piix 0000:00:1f.1: restoring config space at offset 0x8 (was 0xc01, writing 0x2121)
+ata_piix 0000:00:1f.1: restoring config space at offset 0x1 (was 0x2800005, writing 0x2880005)
+ata_piix 0000:00:1f.1: PCI INT A -> GSI 16 (level, low) -> IRQ 16
+ata_piix 0000:00:1f.1: setting latency timer to 64
+ata2: port disabled. ignoring.
+ACPI Exception (exoparg2-0444): AE_AML_PACKAGE_LIMIT, Index (000000005) is beyond end of object [20080926]
+ACPI Error (psparse-0524): Method parse/execution failed [\_SB_.C2C3] (Node ffff88007e01de80), AE_AML_PACKAGE_LIMIT
+ACPI Error (psparse-0524): Method parse/execution failed [\_SB_.C003.C0F6.C3F3._STM] (Node ffff88007e043dc0), AE_AML_PACKAGE_LIMIT
+ata1: ACPI set timing mode failed (status=0x300b)
+iwlagn 0000:10:00.0: enabling device (0000 -> 0002)
+iwlagn 0000:10:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
+iwlagn 0000:10:00.0: restoring config space at offset 0xf (was 0x100, writing 0x10a)
+iwlagn 0000:10:00.0: restoring config space at offset 0x4 (was 0x4, writing 0xe0000004)
+iwlagn 0000:10:00.0: restoring config space at offset 0x3 (was 0x0, writing 0x10)
+iwlagn 0000:10:00.0: restoring config space at offset 0x1 (was 0x100002, writing 0x100006)
+iwlagn 0000:10:00.0: irq 508 for MSI/MSI-X
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0xf (was 0x3000100, writing 0x580010b)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0xe (was 0x0, writing 0x34fc)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0xd (was 0x0, writing 0x3400)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0xc (was 0x0, writing 0x30fc)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0xb (was 0x0, writing 0x3000)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0xa (was 0x0, writing 0x83fff000)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0x9 (was 0x0, writing 0x80000000)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0x8 (was 0x0, writing 0x847ff000)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0x7 (was 0x0, writing 0x84400000)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0x6 (was 0x0, writing 0xb0060302)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0x4 (was 0x0, writing 0xe0100000)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0x3 (was 0x820000, writing 0x82a800)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0x1 (was 0x2100000, writing 0x2100007)
+ohci1394 0000:02:06.1: restoring config space at offset 0xf (was 0x4020200, writing 0x4020205)
+ohci1394 0000:02:06.1: restoring config space at offset 0x4 (was 0x0, writing 0xe0101000)
+ohci1394 0000:02:06.1: restoring config space at offset 0x3 (was 0x800000, writing 0x804010)
+ohci1394 0000:02:06.1: restoring config space at offset 0x1 (was 0x2100000, writing 0x2100006)
+Registered led device: iwl-phy0:radio
+Registered led device: iwl-phy0:assoc
+Registered led device: iwl-phy0:RX
+Registered led device: iwl-phy0:TX
+ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[19]  MMIO=[e0101000-e01017ff]  Max Packet=[2048]  IR/IT contexts=[4/4]
+sdhci-pci 0000:02:06.2: restoring config space at offset 0xf (was 0x300, writing 0x30a)
+sdhci-pci 0000:02:06.2: restoring config space at offset 0x4 (was 0x0, writing 0xe0102000)
+sdhci-pci 0000:02:06.2: restoring config space at offset 0x3 (was 0x800000, writing 0x804010)
+sdhci-pci 0000:02:06.2: restoring config space at offset 0x1 (was 0x2100000, writing 0x2100006)
+sdhci-pci 0000:02:06.2: PCI INT C -> GSI 20 (level, low) -> IRQ 20
+sd 0:0:0:0: [sda] Starting disk
+ata1.01: ACPI cmd ef/03:0c:00:00:00:b0 filtered out
+ata1.01: ACPI cmd ef/03:40:00:00:00:b0 filtered out
+ata1.00: ACPI cmd ef/03:01:00:00:00:a0 filtered out
+ata1.00: ACPI cmd ef/03:45:00:00:00:a0 filtered out
+ata1.00: ACPI cmd f5/00:00:00:00:00:a0 filtered out
+ata1.00: ACPI cmd b1/c1:00:00:00:00:a0 filtered out
+ata1.00: ACPI cmd c6/00:10:00:00:00:a0 succeeded
+ata1.00: configured for UDMA/100
+ata1.01: configured for MWDMA2
+ata1.00: configured for UDMA/100
+ata1.01: configured for MWDMA2
+ata1: EH complete
+sd 0:0:0:0: [sda] 234441648 512-byte hardware sectors: (120 GB/111 GiB)
+sd 0:0:0:0: [sda] Write Protect is off
+sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
+sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
+sd 0:0:0:0: [sda] 234441648 512-byte hardware sectors: (120 GB/111 GiB)
+sd 0:0:0:0: [sda] Write Protect is off
+sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
+sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
+usb 5-2: reset full speed USB device using uhci_hcd and address 2
+usb 2-1: reset full speed USB device using uhci_hcd and address 2
+pci 0000:00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
+pci 0000:00:02.0: setting latency timer to 64
+Restarting tasks ... done.
+PM: Syncing filesystems ... done.
+Freezing user space processes ... (elapsed 0.01 seconds) done.
+Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done.
+Suspending console(s) (use no_console_suspend to debug)
+pci 0000:00:02.0: PCI INT A disabled
+sd 0:0:0:0: [sda] Synchronizing SCSI cache
+sd 0:0:0:0: [sda] Stopping disk
+ACPI handle has no context!
+ACPI handle has no context!
+sdhci-pci 0000:02:06.2: PCI INT C disabled
+ACPI handle has no context!
+ACPI handle has no context!
+iwlagn 0000:10:00.0: PCI INT A disabled
+ata2: port disabled. ignoring.
+ata_piix 0000:00:1f.1: PCI INT A disabled
+ehci_hcd 0000:00:1d.7: PCI INT A disabled
+uhci_hcd 0000:00:1d.2: PCI INT C disabled
+uhci_hcd 0000:00:1d.1: PCI INT B disabled
+uhci_hcd 0000:00:1d.0: PCI INT A disabled
+HDA Intel 0000:00:1b.0: PCI INT A disabled
+HDA Intel 0000:00:1b.0: power state changed by ACPI to D3
+ehci_hcd 0000:00:1a.7: PCI INT C disabled
+uhci_hcd 0000:00:1a.1: PCI INT B disabled
+uhci_hcd 0000:00:1a.0: PCI INT A disabled
+e1000e 0000:00:19.0: PME# enabled
+e1000e 0000:00:19.0: wake-up capability enabled by ACPI
+e1000e 0000:00:19.0: PME# enabled
+e1000e 0000:00:19.0: wake-up capability enabled by ACPI
+e1000e 0000:00:19.0: PCI INT A disabled
+ACPI handle has no context!
+ACPI: Preparing to enter system sleep state S3
+Disabling non-boot CPUs ...
+CPU 1 is now offline
+SMP alternatives: switching to UP code
+CPU0 attaching NULL sched-domain.
+CPU1 attaching NULL sched-domain.
+CPU0 attaching NULL sched-domain.
+CPU1 is down
+ricoh-mmc: Suspending.
+ricoh-mmc: Controller is now re-enabled.
+Extended CMOS year: 2000
+x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
+Back to C!
+Extended CMOS year: 2000
+ricoh-mmc: Resuming.
+ricoh-mmc: Controller is now disabled.
+Enabling non-boot CPUs ...
+SMP alternatives: switching to SMP code
+Booting processor 1 APIC 0x1 ip 0x6000
+Initializing CPU#1
+Calibrating delay using timer specific routine.. 2659.98 BogoMIPS (lpj=5319972)
+CPU: L1 I cache: 32K, L1 D cache: 32K
+CPU: L2 cache: 2048K
+CPU: Physical Processor ID: 0
+CPU: Processor Core ID: 1
+x86 PAT enabled: cpu 1, old 0x7040600070406, new 0x7010600070106
+CPU1: Intel(R) Core(TM)2 Duo CPU     U7700  @ 1.33GHz stepping 0d
+CPU0 attaching NULL sched-domain.
+Switched to high resolution mode on CPU 1
+CPU0 attaching sched-domain:
+ domain 0: span 0-1 level MC
+  groups: 0 1
+  domain 1: span 0-1 level CPU
+   groups: 0-1
+CPU1 attaching sched-domain:
+ domain 0: span 0-1 level MC
+  groups: 1 0
+  domain 1: span 0-1 level CPU
+   groups: 0-1
+CPU1 is up
+ACPI: Waking up from system sleep state S3
+APIC error on CPU1: 00(40)
+ACPI: EC: non-query interrupt received, switching to interrupt mode
+pci 0000:00:02.0: restoring config space at offset 0x8 (was 0x1, writing 0x2001)
+pci 0000:00:02.1: restoring config space at offset 0x4 (was 0x4, writing 0xe0500004)
+pci 0000:00:02.1: restoring config space at offset 0x1 (was 0x900000, writing 0x900007)
+pci 0000:00:03.0: restoring config space at offset 0xf (was 0x100, writing 0x1ff)
+pci 0000:00:03.0: restoring config space at offset 0x4 (was 0xfed12004, writing 0xe0600004)
+pci 0000:00:03.0: restoring config space at offset 0x1 (was 0x100006, writing 0x180006)
+pci 0000:00:03.2: restoring config space at offset 0xf (was 0x300, writing 0x30b)
+pci 0000:00:03.2: restoring config space at offset 0x8 (was 0x1, writing 0x2031)
+pci 0000:00:03.2: restoring config space at offset 0x7 (was 0x1, writing 0x2021)
+pci 0000:00:03.2: restoring config space at offset 0x6 (was 0x1, writing 0x2019)
+pci 0000:00:03.2: restoring config space at offset 0x5 (was 0x1, writing 0x2011)
+pci 0000:00:03.2: restoring config space at offset 0x4 (was 0x1, writing 0x2009)
+pci 0000:00:03.2: restoring config space at offset 0x1 (was 0xb00000, writing 0xb00001)
+serial 0000:00:03.3: restoring config space at offset 0xf (was 0x200, writing 0x20a)
+serial 0000:00:03.3: restoring config space at offset 0x5 (was 0x0, writing 0xe0601000)
+serial 0000:00:03.3: restoring config space at offset 0x4 (was 0x1, writing 0x2041)
+serial 0000:00:03.3: restoring config space at offset 0x1 (was 0xb00000, writing 0xb00007)
+e1000e 0000:00:19.0: restoring config space at offset 0xf (was 0x100, writing 0x10b)
+e1000e 0000:00:19.0: restoring config space at offset 0x6 (was 0x1, writing 0x2061)
+e1000e 0000:00:19.0: restoring config space at offset 0x5 (was 0x0, writing 0xe0640000)
+e1000e 0000:00:19.0: restoring config space at offset 0x1 (was 0x100000, writing 0x100007)
+e1000e 0000:00:19.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22
+e1000e 0000:00:19.0: setting latency timer to 64
+e1000e 0000:00:19.0: wake-up capability disabled by ACPI
+e1000e 0000:00:19.0: PME# disabled
+e1000e 0000:00:19.0: wake-up capability disabled by ACPI
+e1000e 0000:00:19.0: PME# disabled
+e1000e 0000:00:19.0: irq 509 for MSI/MSI-X
+uhci_hcd 0000:00:1a.0: enabling device (0000 -> 0001)
+uhci_hcd 0000:00:1a.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
+uhci_hcd 0000:00:1a.0: setting latency timer to 64
+uhci_hcd 0000:00:1a.0: restoring config space at offset 0xf (was 0x100, writing 0x10a)
+uhci_hcd 0000:00:1a.0: restoring config space at offset 0x8 (was 0x1, writing 0x2081)
+usb usb2: root hub lost power or was reset
+uhci_hcd 0000:00:1a.1: enabling device (0000 -> 0001)
+uhci_hcd 0000:00:1a.1: PCI INT B -> GSI 17 (level, low) -> IRQ 17
+uhci_hcd 0000:00:1a.1: setting latency timer to 64
+uhci_hcd 0000:00:1a.1: restoring config space at offset 0xf (was 0x200, writing 0x20a)
+uhci_hcd 0000:00:1a.1: restoring config space at offset 0x8 (was 0x1, writing 0x20a1)
+usb usb4: root hub lost power or was reset
+ehci_hcd 0000:00:1a.7: enabling device (0000 -> 0002)
+ehci_hcd 0000:00:1a.7: PCI INT C -> GSI 18 (level, low) -> IRQ 18
+ehci_hcd 0000:00:1a.7: setting latency timer to 64
+ehci_hcd 0000:00:1a.7: restoring config space at offset 0xf (was 0x300, writing 0x30b)
+ehci_hcd 0000:00:1a.7: restoring config space at offset 0x4 (was 0x0, writing 0xe0641000)
+HDA Intel 0000:00:1b.0: power state changed by ACPI to D0
+HDA Intel 0000:00:1b.0: restoring config space at offset 0xf (was 0x100, writing 0x10a)
+HDA Intel 0000:00:1b.0: restoring config space at offset 0x3 (was 0x0, writing 0x10)
+HDA Intel 0000:00:1b.0: restoring config space at offset 0x1 (was 0x100000, writing 0x100002)
+HDA Intel 0000:00:1b.0: power state changed by ACPI to D0
+HDA Intel 0000:00:1b.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
+HDA Intel 0000:00:1b.0: setting latency timer to 64
+pcieport-driver 0000:00:1c.0: restoring config space at offset 0xf (was 0x100, writing 0x4010a)
+pcieport-driver 0000:00:1c.0: restoring config space at offset 0x9 (was 0x10001, writing 0x1fff1)
+pcieport-driver 0000:00:1c.0: restoring config space at offset 0x8 (was 0x0, writing 0xfff0)
+pcieport-driver 0000:00:1c.0: restoring config space at offset 0x7 (was 0x0, writing 0xf0)
+pcieport-driver 0000:00:1c.0: restoring config space at offset 0x6 (was 0x0, writing 0x80800)
+pcieport-driver 0000:00:1c.0: restoring config space at offset 0x3 (was 0x810000, writing 0x810010)
+pcieport-driver 0000:00:1c.0: restoring config space at offset 0x1 (was 0x100000, writing 0x100407)
+pcieport-driver 0000:00:1c.0: setting latency timer to 64
+pcieport-driver 0000:00:1c.1: restoring config space at offset 0xf (was 0x200, writing 0x4020a)
+pcieport-driver 0000:00:1c.1: restoring config space at offset 0x9 (was 0x10001, writing 0x1fff1)
+pcieport-driver 0000:00:1c.1: restoring config space at offset 0x8 (was 0x0, writing 0xe000e000)
+pcieport-driver 0000:00:1c.1: restoring config space at offset 0x7 (was 0x0, writing 0xf0)
+pcieport-driver 0000:00:1c.1: restoring config space at offset 0x3 (was 0x810000, writing 0x810010)
+pcieport-driver 0000:00:1c.1: restoring config space at offset 0x1 (was 0x100000, writing 0x100407)
+pcieport-driver 0000:00:1c.1: setting latency timer to 64
+uhci_hcd 0000:00:1d.0: enabling device (0000 -> 0001)
+uhci_hcd 0000:00:1d.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20
+uhci_hcd 0000:00:1d.0: setting latency timer to 64
+uhci_hcd 0000:00:1d.0: restoring config space at offset 0xf (was 0x100, writing 0x10a)
+uhci_hcd 0000:00:1d.0: restoring config space at offset 0x8 (was 0x1, writing 0x20c1)
+usb usb5: root hub lost power or was reset
+uhci_hcd 0000:00:1d.1: enabling device (0000 -> 0001)
+uhci_hcd 0000:00:1d.1: PCI INT B -> GSI 22 (level, low) -> IRQ 22
+uhci_hcd 0000:00:1d.1: setting latency timer to 64
+uhci_hcd 0000:00:1d.1: restoring config space at offset 0xf (was 0x200, writing 0x20b)
+uhci_hcd 0000:00:1d.1: restoring config space at offset 0x8 (was 0x1, writing 0x20e1)
+usb usb6: root hub lost power or was reset
+uhci_hcd 0000:00:1d.2: enabling device (0000 -> 0001)
+uhci_hcd 0000:00:1d.2: PCI INT C -> GSI 18 (level, low) -> IRQ 18
+uhci_hcd 0000:00:1d.2: setting latency timer to 64
+uhci_hcd 0000:00:1d.2: restoring config space at offset 0xf (was 0x300, writing 0x30b)
+uhci_hcd 0000:00:1d.2: restoring config space at offset 0x8 (was 0x1, writing 0x2101)
+usb usb7: root hub lost power or was reset
+ehci_hcd 0000:00:1d.7: enabling device (0000 -> 0002)
+ehci_hcd 0000:00:1d.7: PCI INT A -> GSI 20 (level, low) -> IRQ 20
+ehci_hcd 0000:00:1d.7: setting latency timer to 64
+ehci_hcd 0000:00:1d.7: restoring config space at offset 0xf (was 0x100, writing 0x10a)
+ehci_hcd 0000:00:1d.7: restoring config space at offset 0x4 (was 0x0, writing 0xe0648000)
+pci 0000:00:1e.0: restoring config space at offset 0x9 (was 0x10001, writing 0x1fff1)
+pci 0000:00:1e.0: restoring config space at offset 0x8 (was 0x0, writing 0xe030e010)
+pci 0000:00:1e.0: restoring config space at offset 0x7 (was 0x228000f0, writing 0x22803030)
+pci 0000:00:1e.0: restoring config space at offset 0x1 (was 0x100007, writing 0x100107)
+pci 0000:00:1e.0: setting latency timer to 64
+ata_piix 0000:00:1f.1: restoring config space at offset 0xf (was 0x100, writing 0x10a)
+ata_piix 0000:00:1f.1: restoring config space at offset 0x8 (was 0xc01, writing 0x2121)
+ata_piix 0000:00:1f.1: restoring config space at offset 0x1 (was 0x2800005, writing 0x2880005)
+ata_piix 0000:00:1f.1: PCI INT A -> GSI 16 (level, low) -> IRQ 16
+ata_piix 0000:00:1f.1: setting latency timer to 64
+ata2: port disabled. ignoring.
+ACPI Exception (exoparg2-0444): AE_AML_PACKAGE_LIMIT, Index (000000005) is beyond end of object [20080926]
+ACPI Error (psparse-0524): Method parse/execution failed [\_SB_.C2C3] (Node ffff88007e01de80), AE_AML_PACKAGE_LIMIT
+ACPI Error (psparse-0524): Method parse/execution failed [\_SB_.C003.C0F6.C3F3._STM] (Node ffff88007e043dc0), AE_AML_PACKAGE_LIMIT
+ata1: ACPI set timing mode failed (status=0x300b)
+iwlagn 0000:10:00.0: enabling device (0000 -> 0002)
+iwlagn 0000:10:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
+iwlagn 0000:10:00.0: restoring config space at offset 0xf (was 0x100, writing 0x10a)
+iwlagn 0000:10:00.0: restoring config space at offset 0x4 (was 0x4, writing 0xe0000004)
+iwlagn 0000:10:00.0: restoring config space at offset 0x3 (was 0x0, writing 0x10)
+iwlagn 0000:10:00.0: restoring config space at offset 0x1 (was 0x100002, writing 0x100006)
+iwlagn 0000:10:00.0: irq 508 for MSI/MSI-X
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0xf (was 0x3000100, writing 0x580010b)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0xe (was 0x0, writing 0x34fc)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0xd (was 0x0, writing 0x3400)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0xc (was 0x0, writing 0x30fc)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0xb (was 0x0, writing 0x3000)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0xa (was 0x0, writing 0x83fff000)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0x9 (was 0x0, writing 0x80000000)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0x8 (was 0x0, writing 0x847ff000)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0x7 (was 0x0, writing 0x84400000)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0x6 (was 0x0, writing 0xb0060302)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0x4 (was 0x0, writing 0xe0100000)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0x3 (was 0x820000, writing 0x82a800)
+yenta_cardbus 0000:02:06.0: restoring config space at offset 0x1 (was 0x2100000, writing 0x2100007)
+ohci1394 0000:02:06.1: restoring config space at offset 0xf (was 0x4020200, writing 0x4020205)
+ohci1394 0000:02:06.1: restoring config space at offset 0x4 (was 0x0, writing 0xe0101000)
+ohci1394 0000:02:06.1: restoring config space at offset 0x3 (was 0x800000, writing 0x804010)
+ohci1394 0000:02:06.1: restoring config space at offset 0x1 (was 0x2100000, writing 0x2100006)
+ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[19]  MMIO=[e0101000-e01017ff]  Max Packet=[2048]  IR/IT contexts=[4/4]
+sdhci-pci 0000:02:06.2: restoring config space at offset 0xf (was 0x300, writing 0x30a)
+sdhci-pci 0000:02:06.2: restoring config space at offset 0x4 (was 0x0, writing 0xe0102000)
+sdhci-pci 0000:02:06.2: restoring config space at offset 0x3 (was 0x800000, writing 0x804010)
+sdhci-pci 0000:02:06.2: restoring config space at offset 0x1 (was 0x2100000, writing 0x2100006)
+sdhci-pci 0000:02:06.2: PCI INT C -> GSI 20 (level, low) -> IRQ 20
+Registered led device: iwl-phy0:radio
+Registered led device: iwl-phy0:assoc
+Registered led device: iwl-phy0:RX
+Registered led device: iwl-phy0:TX
+sd 0:0:0:0: [sda] Starting disk
+ata1.01: ACPI cmd ef/03:0c:00:00:00:b0 filtered out
+ata1.01: ACPI cmd ef/03:40:00:00:00:b0 filtered out
+ata1.00: ACPI cmd ef/03:01:00:00:00:a0 filtered out
+ata1.00: ACPI cmd ef/03:45:00:00:00:a0 filtered out
+ata1.00: ACPI cmd f5/00:00:00:00:00:a0 filtered out
+ata1.00: ACPI cmd b1/c1:00:00:00:00:a0 filtered out
+ata1.00: ACPI cmd c6/00:10:00:00:00:a0 succeeded
+ata1.00: configured for UDMA/100
+ata1.01: configured for MWDMA2
+ata1.00: configured for UDMA/100
+ata1.01: configured for MWDMA2
+ata1: EH complete
+sd 0:0:0:0: [sda] 234441648 512-byte hardware sectors: (120 GB/111 GiB)
+sd 0:0:0:0: [sda] Write Protect is off
+sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
+sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
+sd 0:0:0:0: [sda] 234441648 512-byte hardware sectors: (120 GB/111 GiB)
+sd 0:0:0:0: [sda] Write Protect is off
+sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
+sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
+usb 5-2: reset full speed USB device using uhci_hcd and address 2
+usb 2-1: reset full speed USB device using uhci_hcd and address 2
+pci 0000:00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
+pci 0000:00:02.0: setting latency timer to 64
+Restarting tasks ... <7>wlan0: deauthenticated
+done.
+wlan0: direct probe to AP 00:14:c1:38:e5:15 try 1
+wlan0 direct probe responded
+wlan0: authenticate with AP 00:14:c1:38:e5:15
+wlan0: authenticated
+wlan0: associate with AP 00:14:c1:38:e5:15
+wlan0: RX ReassocResp from 00:14:c1:38:e5:15 (capab=0x411 status=0 aid=1)
+wlan0: associated

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Frans Pop]

On Tuesday 02 December 2008, Frans Pop wrote:
> +yenta_cardbus 0000:02:06.0: CardBus bridge, secondary bus 0000:03
> +yenta_cardbus 0000:02:06.0:   IO window: 0x003000-0x0030ff
> +yenta_cardbus 0000:02:06.0:   IO window: 0x003400-0x0034ff
> +yenta_cardbus 0000:02:06.0:   PREFETCH window: 0x84400000-0x847fffff
> +yenta_cardbus 0000:02:06.0:   MEM window: 0x80000000-0x83ffffff

Wild speculation, but could all this possibly also be related to occasional
"irq 19: nobody cared" errors I'm seeing on resume for ohci1394?

My FireWire controller is sitting behind this bridge after all.

Here's an example:
Dec  2 04:57:32 aragorn kernel: irq 19: nobody cared (try booting with the "irqpoll" option)
Dec  2 04:57:32 aragorn kernel: Pid: 0, comm: swapper Not tainted 2.6.28-rc6 #57
Dec  2 04:57:32 aragorn kernel: Call Trace:
Dec  2 04:57:32 aragorn kernel:  <IRQ>  [<ffffffffa01009e1>] ? ohci_irq_handler+0x60/0x7e9 [ohci1394]
Dec  2 04:57:32 aragorn kernel:  [<ffffffff8026aa29>] __report_bad_irq+0x38/0x87
Dec  2 04:57:32 aragorn kernel:  [<ffffffff8026ab86>] note_interrupt+0x10e/0x174
Dec  2 04:57:32 aragorn kernel:  [<ffffffff8026b23e>] handle_fasteoi_irq+0xa7/0xd1
Dec  2 04:57:32 aragorn kernel:  [<ffffffff8020eb87>] do_IRQ+0x73/0xe4
Dec  2 04:57:32 aragorn kernel:  [<ffffffff8020c626>] ret_from_intr+0x0/0xa
Dec  2 04:57:32 aragorn kernel:  <EOI>  [<ffffffffa0012606>] ? acpi_idle_enter_bm+0x26b/0x2b2 [processor]
Dec  2 04:57:32 aragorn kernel:  [<ffffffffa00125fc>] ? acpi_idle_enter_bm+0x261/0x2b2 [processor]
Dec  2 04:57:32 aragorn kernel:  [<ffffffff8024f33b>] ? notifier_call_chain+0x33/0x5b
Dec  2 04:57:32 aragorn kernel:  [<ffffffff803b9ca4>] ? cpuidle_idle_call+0x8c/0xc4
Dec  2 04:57:32 aragorn kernel:  [<ffffffff8020b312>] ? cpu_idle+0x4a/0x9a
Dec  2 04:57:32 aragorn kernel:  [<ffffffff8042c528>] ? rest_init+0x5c/0x5e
Dec  2 04:57:32 aragorn kernel: handlers:
Dec  2 04:57:32 aragorn kernel: [<ffffffffa0100981>] (ohci_irq_handler+0x0/0x7e9 [ohci1394])
Dec  2 04:57:32 aragorn kernel: Disabling IRQ #19

I can send full kernel log from the start of that boot if desired.

Cheers,
FJP

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Linus Torvalds]

On Tue, 2 Dec 2008, Frans Pop wrote:
> 
> Attached is a full diff between dmesg from -rc3 and -rc6 with your debug 
> patch.
> 
> I've cleaned up the diff a bit to make it more readable (mostly removal of 
> changes that I always get due to random USB load order changes - UHCI 
> still frequently loads before EHCI).
> 
> The most interesting points are probably at lines 298-346 and 639-649.

So, it looks like you have MSI enabled in -rc6, and not in -rc3. And yes, 
for some reason -rc3 will create the prefetchable memory range windows, 
but -rc6 won't.

I have to admit that I'm not seeing _why_ to that latter one. I don't 
think we've done any resource allocation changes since -rc3 (the "clean up 
late e820 resource allocation" thing happened just _before_ -rc3), so I'm 
really not seeing why -rc3 would act differently from -rc6..

> At the bottom there's a fairly long addition from the few suspend/resume 
> cycles I did (again, running with the debug patch).

Sure. Quite frankly, from these messages, I'm not seeing anything really 
even remotely wrong. And apparently it does actually work for you.

It would perhaps be more interesting to see if there is some dmesg 
difference in a boot that then ends up _not_ able to resume from 
hibernation? But apparently that hasn't happened to you lately?

I don't like not knowing why you have prefetchable windows in one, and not 
in the other, but it is indeed a transparent bridge and so that difference 
really shouldn't even matter.

Do you perhaps dual-boot that laptop? What can sometimes happen is that 
PCI resources do not get totally reset over a warm-boot.

We've (very occasionally) had situations where PCI resource bugs only 
happen when you warm-boot from another OS (generally Windows), or when you 
warm-boot from an earlier version of Linux. Exactly because some firmware 
didn't fully re-initialize the state of the PCI bus, and because Linux 
will try to honor everything that the firmware set up..

		Linus

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Rafael J. Wysocki]

On Tuesday, 2 of December 2008, Linus Torvalds wrote:
> 
> On Tue, 2 Dec 2008, Rafael J. Wysocki wrote:
> >  			r_size = resource_size(r);
> >  			/* For bridges size != alignment */
> > -			align = resource_alignment(r);
> > +			align = (i < PCI_BRIDGE_RESOURCES) ? r_size : r->start;
> 
> Hmm. This means that something set the alignment flags incorrectly. The 
> resource _should_ have IORESOURCE_SIZEALIGN set for a resource with size 
> alignment, and IORESOURCE_STARTALIGN for one that has start alignment.
> 
> Your patch doesn't fix anything, it just hides the bug.

Well, it's just a partial revert of commit
5f17cfce5776c566d64430f543a289e5cfa4538b ("PCI: fix pbus_size_mem() resource
alignment for CardBus controllers"). 

> It would be good to hear what resource this is, and where it got set. So 
> instead of that broken patch that just hides the problem, please try to 
> debug it with something like
> 
> 	resource_size_t expected_align;
> 
> 	expected_align = (i < PCI_BRIDGE_RESOURCES) ? r_size : r->start;
> 	align = resource_alignment(r);
> 	if (align != expected_align) {
> 		dev_warn(&dev->dev,
> 			"BAR %d %llx-%llx wrong alignment flags %lx %llx (%llx)\n",
> 			i,
> 			(unsigned long long) r->start,
> 			(unsigned long long) r->end,
> 			r->flags,
> 			(unsigned long long) align,
> 			(unsigned long long) expected_align);
> 		/* Hacky and wrong, but trying to keep things 
> 		align = expected_align;
> 	}
> 
> or something like that. And then we just need to figure out which setup 
> routine sets the wrong alignment flag,.

Yeah, I'll give it a try later today, when I get back from the Uni.

Thanks,
Rafael

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Frans Pop]

On Tuesday 02 December 2008, Linus Torvalds wrote:
> So, it looks like you have MSI enabled in -rc6, and not in -rc3. And
> yes, for some reason -rc3 will create the prefetchable memory range
> windows, but -rc6 won't.

I have no changes in my config that would explain that (checked the diff). 
The only changes are simple 'make oldconfig' updates.

> I have to admit that I'm not seeing _why_ to that latter one. I don't
> think we've done any resource allocation changes since -rc3 (the "clean
> up late e820 resource allocation" thing happened just _before_ -rc3),
> so I'm really not seeing why -rc3 would act differently from -rc6..

I could reinstall some intermediate versions and check when that change 
got introduced if that would help, or revert to the kernel I was using 
before I did the pull today and applied the debug patch (which was plain 
rc6 + a few selected bug fix patches that had not yet been merged).

> > At the bottom there's a fairly long addition from the few
> > suspend/resume cycles I did (again, running with the debug patch).
>
> Sure. Quite frankly, from these messages, I'm not seeing anything
> really even remotely wrong. And apparently it does actually work for
> you.

Right. All these resumes were perfect.

> It would perhaps be more interesting to see if there is some dmesg
> difference in a boot that then ends up _not_ able to resume from
> hibernation? But apparently that hasn't happened to you lately?

It did happen once a few days ago, but with the workarounds I had resume 
failures were extremely rare. I'll see if I can work out which boot it 
was, but that could well be very tricky as a failed resume leaves no 
trace.

The way I "see" the failure is that the wireless led does not come on

> I don't like not knowing why you have prefetchable windows in one, and
> not in the other, but it is indeed a transparent bridge and so that
> difference really shouldn't even matter.

/me always likes the use of "should" in such situations ;-)

> Do you perhaps dual-boot that laptop? What can sometimes happen is that
> PCI resources do not get totally reset over a warm-boot.

No. I only run Debian testing on that machine. As Debian Lenny is getting 
close to release there are very few changes in userland ATM. For kernels 
I essentially follow git starting with -rc2/3 or so of each new minor.

> We've (very occasionally) had situations where PCI resource bugs only
> happen when you warm-boot from another OS (generally Windows), or when
> you warm-boot from an earlier version of Linux. Exactly because some
> firmware didn't fully re-initialize the state of the PCI bus, and
> because Linux will try to honor everything that the firmware set up..

Given the above that does not seem relevant.

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Linus Torvalds]

On Tue, 2 Dec 2008, Frans Pop wrote:
> 
> I could reinstall some intermediate versions and check when that change 
> got introduced if that would help, or revert to the kernel I was using 
> before I did the pull today and applied the debug patch (which was plain 
> rc6 + a few selected bug fix patches that had not yet been merged).

It might be interesting, but probably not very relevant. I don't really 
think that the resume problem is related to this.

> It did happen once a few days ago, but with the workarounds I had resume 
> failures were extremely rare. I'll see if I can work out which boot it 
> was, but that could well be very tricky as a failed resume leaves no 
> trace.

If you just save the dmesg before each resume try, you'd have at least the 
dmesg of the bootup that leads to failure. It's _likely_ exactly the same 
as the ones that don't lead to failures, but..

> The way I "see" the failure is that the wireless led does not come on

Quite frankly, from everything I hear, I personally strongly suspect that 
it's something timing-related to some driver, and most likely totally 
unrelated to any PCI resource allocation in any other way. IOW, _if_ the 
resource allocation makes a difference, it's more likely through just 
mattering from a timing standpoint.

For example, the bad alignment you get from picking the alignment from the 
wrong place (with Rafael's patch or with my debugging patch) results in 
this:

 - PCI init time:

	+pci 0000:02:06.0: BAR 9 0-3ffffff wrong alignment flags 21200 4000000 (0)
	+pci 0000:02:06.0: BAR 9 bad alignment 0: [0x000000-0x3ffffff]

 - CardBus init time:

	+yenta_cardbus 0000:02:06.0: CardBus bridge, secondary bus 0000:03
	+yenta_cardbus 0000:02:06.0:   IO window: 0x003000-0x0030ff
	+yenta_cardbus 0000:02:06.0:   IO window: 0x003400-0x0034ff
	+yenta_cardbus 0000:02:06.0:   PREFETCH window: 0x84400000-0x847fffff
	+yenta_cardbus 0000:02:06.0:   MEM window: 0x80000000-0x83ffffff

ie what happened is that when using the wrong alignment, the PCI bus setup 
code would fail to set up the memory windows (bar 9), but then the cardbus 
init which happens later will fix that, since it re-does the setup (see 
"yenta_allocate_resources()": it will re-do "pci_setup_cardbus()" if the 
resources didn't get set up earlier)

End result? There should be no real difference, but timing does change.

Now, there are _some_ subtle issues that change depending on whether we do 
the "failure case" in yenta_allocate_resources() or not: for example, the 
code in yenta_allocate_res() actually knows about the fact that CardBus 
memory resources have a 4kB granularity, while the generic PCI code uses 
the resource size as the alignment.

The yenta code also tries to potentially find a smaller resource than the 
generic PCI resource code did (the generic PCI code just tries to use 
2*pci_cardbus_io_size and 2*pci_cardbus_mem_size for sizing, while the 
Yenta code tries to aim for BRIDGE_IO/MEM_MAX but knows to try to make 
them smaller if it cannot fit.

So the resources can end up being laid out at different points as a 
result, and again, that can lead to totally independent bugs showing up 
(overlap with random unknown motherboard resources set up by firmware). 
But more relevantly, it can simply just cause some timing differences.

Anyway, I'm not at all sure that you and Rafael even necessarily see 
exactly the same thing. It doesn't look like my debug patch (which tries 
to emulate Rafael's patch in behavior, in addition to adding the debug 
printouts) really even matters for you. Because you seemed to be 
hibernating ok even without that "break alignment in PCI layer" thing.

			Linus

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Rafael J. Wysocki]

On Tuesday, 2 of December 2008, Linus Torvalds wrote:
> 
> That's why I'd like to see what the layout differences are for Rafael with 
> and without his patch (and also both before and after hibernate/resume). 
> Maybe both layouts are "correct", but the non-working one can give us a 
> clue about what may be triggering the problem.

OK

Sorry for the delay, it took me more time than expected to generate all the
data.

* dmesg output including one hibernation-resume cycle from 2.6.28-rc7 with the
  debug patch (appended for completness):

  http://www.sisk.pl/kernel/debug/mainline/2.6.28-rc7/dmesg-rc7-patched-prep.log

* dmesg output including one hibernation-resume cycle from 2.6.28-rc7 without
  the debug patch:

  http://www.sisk.pl/kernel/debug/mainline/2.6.28-rc7/dmesg-rc7-nopatch-prep.log

* diff between the two:

  http://www.sisk.pl/kernel/debug/mainline/2.6.28-rc7/dmesg-rc7_nopatch-rc7_patched.diff

This part of the diff  (+ is the patched one) seems to be particularly
interesting to me, especially the overlapping MEM windows for 0000:00:1e.0 and
0000:03:0b.0 (may that be the reason for the observed failures?):

@@ -276,0 +277,4 @@
+bad alignment flags 21200 4000000 (0)
+pci 0000:03:0b.0: BAR 9 bad alignment 0: [0x000000-0x3ffffff]
+bad alignment flags 20200 4000000 (0)
+pci 0000:03:0b.0: BAR 10 bad alignment 0: [0x000000-0x3ffffff]
@@ -288,2 +291,0 @@
-pci 0000:03:0b.0:   PREFETCH window: 0x88000000-0x8bffffff
-pci 0000:03:0b.0:   MEM window: 0x8c000000-0x8fffffff
@@ -292,2 +294,2 @@
-pci 0000:00:1e.0:   MEM window: 0x8c000000-0x91ffffff
-pci 0000:00:1e.0:   PREFETCH window: 0x00000088000000-0x0000008bffffff
+pci 0000:00:1e.0:   MEM window: 0x88000000-0x880fffff
+pci 0000:00:1e.0:   PREFETCH window: disabled
@@ -312,2 +314,2 @@
-bus: 03 index 1 mmio: [0x8c000000-0x91ffffff]
-bus: 03 index 2 mmio: [0x88000000-0x8bffffff]
+bus: 03 index 1 mmio: [0x88000000-0x880fffff]
+bus: 03 index 2 mmio: [0x0-0x0]
@@ -318,2 +320,2 @@
-bus: 04 index 2 mmio: [0x88000000-0x8bffffff]
-bus: 04 index 3 mmio: [0x8c000000-0x8fffffff]
+bus: 04 index 2 mmio: [0x0-0x3ffffff]
+bus: 04 index 3 mmio: [0x0-0x3ffffff]

* the output of 'lspci -vv'

  http://www.sisk.pl/kernel/debug/mainline/2.6.28-rc7/lspci-vv.txt

* diff between /proc/iomem between 2.6.28-rc7 without and with the patch
  (+ is from the patched kernel):

diff -U 0 -r rc7-nopatch//iomem rc7-patched//iomem
--- rc7-nopatch//iomem	2008-12-02 22:57:34.000000000 +0100
+++ rc7-patched//iomem	2008-12-02 23:07:02.000000000 +0100
@@ -7,2 +7,2 @@
-  00200000-00450496 : Kernel code
-  00450497-00603c37 : Kernel data
+  00200000-00450526 : Kernel code
+  00450527-00603c37 : Kernel data
@@ -14,15 +14,14 @@
-88000000-8bffffff : PCI Bus 0000:03
-  88000000-8bffffff : PCI CardBus 0000:04
-8c000000-91ffffff : PCI Bus 0000:03
-  8c000000-8fffffff : PCI CardBus 0000:04
-  90000000-90003fff : 0000:03:0b.1
-  90004000-90004fff : 0000:03:0b.0
-    90004000-90004fff : yenta_socket
-  90005000-900057ff : 0000:03:0b.1
-    90005000-900057ff : firewire_ohci
-  90005800-900058ff : 0000:03:0b.3
-    90005800-900058ff : mmc0
-92000000-9207ffff : 0000:00:02.1
-92080000-92083fff : 0000:00:1b.0
-  92080000-92083fff : ICH HD audio
-92084000-92084fff : Intel Flush Page
+88000000-880fffff : PCI Bus 0000:03
+  88000000-88003fff : 0000:03:0b.1
+  88004000-88004fff : 0000:03:0b.0
+    88004000-88004fff : yenta_socket
+  88005000-880057ff : 0000:03:0b.1
+    88005000-880057ff : firewire_ohci
+  88005800-880058ff : 0000:03:0b.3
+    88005800-880058ff : mmc0
+88100000-8817ffff : 0000:00:02.1
+88180000-88183fff : 0000:00:1b.0
+  88180000-88183fff : ICH HD audio
+88184000-88184fff : Intel Flush Page
+88400000-887fffff : PCI CardBus 0000:04
+88800000-88bfffff : PCI CardBus 0000:04

All of the files above plus some more data are available from
http://www.sisk.pl/kernel/debug/mainline/2.6.28-rc7/

HTH

Thanks,
Rafael

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Linus Torvalds]

On Tue, 2 Dec 2008, Rafael J. Wysocki wrote:
> 
> * dmesg output including one hibernation-resume cycle from 2.6.28-rc7 with the
>   debug patch (appended for completness):
> 
>   http://www.sisk.pl/kernel/debug/mainline/2.6.28-rc7/dmesg-rc7-patched-prep.log
> 
> * dmesg output including one hibernation-resume cycle from 2.6.28-rc7 without
>   the debug patch:
> 
>   http://www.sisk.pl/kernel/debug/mainline/2.6.28-rc7/dmesg-rc7-nopatch-prep.log

As with Frans, the debug patch seems to make no difference what-so-ever. 
Yes, the cardbus regions get allocated differently, but they're fine in 
either case, and arguably (exactly as with Frans) the debug patch actually 
makes things uglier by actively getting the alignment wrong, and skipping 
cardbus setup until later.

That's what your patch (without debugging) should have resulted in too, 
except you'd not have seen the "bad alignment flags" printout, of course 
(but you probably would have seen the "bad alignment 0: [...]" one).

In fact, I'm starting to think I know why we set up the prefetch window 
without the patch, and why we don't with it - because with the patch, the 
PCI code ends up never seeing any valid prefetchable region for the 
cardbus controller at all, so it never even bothers to try to set up a 
prefetchable window.

So in many ways, the debug patch that gets the alignment wrong (on 
purpose) is really the inferior one. Plain -rc7 seems to do everything 
right.

> * diff between the two:
> 
>   http://www.sisk.pl/kernel/debug/mainline/2.6.28-rc7/dmesg-rc7_nopatch-rc7_patched.diff

Gaah. Using "-U 0" is likely the least readable form of diffs there 
exists, even if it makes the diff smaller.

> This part of the diff  (+ is the patched one) seems to be particularly
> interesting to me, especially the overlapping MEM windows for 0000:00:1e.0 and
> 0000:03:0b.0 (may that be the reason for the observed failures?):

No, those are very much on purpose. 

Device 0000:00:1e.0 is the PCI bridge that bridges to PCI bus#3, so the 
MEM window is very much intentional - exactly because MMIO goes through 
that PCI bridge bus to get to bus#3, which is where the cardbus controller 
is.

IOW, the topology is as follows: 
 - CPU is on the root bus (bus #0)
 - device 00:1e.0 is the PCI bridge to bus #3
 - device 03:0b.0 is the CardBus bridge (to bus #4)
and any actual cardbus cards (if you had any) would be on that bus #4, so 
they'd be named "04:xx.y".

Now, that PCI bridge 00:1e.0 is a transparent bridge (aka "[Subtractive 
decode]" in your lspci output - as compared to the other bridges that say 
"[Normal decode]"), which means that you don't actually _have_ to set up 
any MMIO window on them, since the bridge will forward _any_ PCI cycles 
that don't get responded to by any other PCI device.

But having an explicit window is still generally a good idea, since it 
should allow the PCI bridge to pick up the PCI cycles earlier (no need to 
wait to see if others respond to it), and possibly allows for better 
prefetching behavior. So again, the dmesg and the PCI layout actually 
looks _better_ without the hacky patch.

So are you saying that the unpatched kernel still reliably doesn't 
hibernate for you, while the (arguably _incorrect_) patched kernel 
reliably does hibernate? 

			Linus

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Rafael J. Wysocki]

On Wednesday, 3 of December 2008, Linus Torvalds wrote:
> 
> On Tue, 2 Dec 2008, Rafael J. Wysocki wrote:
> > 
> > * dmesg output including one hibernation-resume cycle from 2.6.28-rc7 with the
> >   debug patch (appended for completness):
> > 
> >   http://www.sisk.pl/kernel/debug/mainline/2.6.28-rc7/dmesg-rc7-patched-prep.log
> > 
> > * dmesg output including one hibernation-resume cycle from 2.6.28-rc7 without
> >   the debug patch:
> > 
> >   http://www.sisk.pl/kernel/debug/mainline/2.6.28-rc7/dmesg-rc7-nopatch-prep.log
> 
> As with Frans, the debug patch seems to make no difference what-so-ever. 
> Yes, the cardbus regions get allocated differently, but they're fine in 
> either case, and arguably (exactly as with Frans) the debug patch actually 
> makes things uglier by actively getting the alignment wrong, and skipping 
> cardbus setup until later.

Hm, what about (from the copy of /proc/iomem without the patch at
http://www.sisk.pl/kernel/debug/mainline/2.6.28-rc7/rc7-nopatch/iomem):

88000000-8bffffff : PCI Bus 0000:03
  88000000-8bffffff : PCI CardBus 0000:04
8c000000-91ffffff : PCI Bus 0000:03
  8c000000-8fffffff : PCI CardBus 0000:04

(1) Why two ranges are allocated for 0000:03 without the patch while there is
    only one range with the patch:

88000000-880fffff : PCI Bus 0000:03

    (copy of the file at
    http://www.sisk.pl/kernel/debug/mainline/2.6.28-rc7/rc7-patched/iomem)?
    That seems to look like a difference to me.

(2) Why are they so large without the patch while with the patch they are much
    smaller (O(2^28) vs O(2^21) if I'm not mistaken)?

(3) Why are they overlapping with the ranges for CardBus 0000:04, although
    without the patch they aren't?  Is that actually correct at all?

> That's what your patch (without debugging) should have resulted in too, 
> except you'd not have seen the "bad alignment flags" printout, of course 
> (but you probably would have seen the "bad alignment 0: [...]" one).

Yes, I saw that:

bad alignment flags 21200 4000000 (0)
pci 0000:03:0b.0: BAR 9 bad alignment 0: [0x000000-0x3ffffff]
bad alignment flags 20200 4000000 (0)
pci 0000:03:0b.0: BAR 10 bad alignment 0: [0x000000-0x3ffffff]

> In fact, I'm starting to think I know why we set up the prefetch window 
> without the patch, and why we don't with it - because with the patch, the 
> PCI code ends up never seeing any valid prefetchable region for the 
> cardbus controller at all, so it never even bothers to try to set up a 
> prefetchable window.
> 
> So in many ways, the debug patch that gets the alignment wrong (on 
> purpose) is really the inferior one. Plain -rc7 seems to do everything 
> right.

Well, I'm not sure ...

> > * diff between the two:
> > 
> >   http://www.sisk.pl/kernel/debug/mainline/2.6.28-rc7/dmesg-rc7_nopatch-rc7_patched.diff
> 
> Gaah. Using "-U 0" is likely the least readable form of diffs there 
> exists, even if it makes the diff smaller.

Sorry.

To me it's more readable this way, but well.

> > This part of the diff  (+ is the patched one) seems to be particularly
> > interesting to me, especially the overlapping MEM windows for 0000:00:1e.0 and
> > 0000:03:0b.0 (may that be the reason for the observed failures?):
> 
> No, those are very much on purpose. 
> 
> Device 0000:00:1e.0 is the PCI bridge that bridges to PCI bus#3, so the 
> MEM window is very much intentional - exactly because MMIO goes through 
> that PCI bridge bus to get to bus#3, which is where the cardbus controller 
> is.
> 
> IOW, the topology is as follows: 
>  - CPU is on the root bus (bus #0)
>  - device 00:1e.0 is the PCI bridge to bus #3
>  - device 03:0b.0 is the CardBus bridge (to bus #4)
> and any actual cardbus cards (if you had any) would be on that bus #4, so 
> they'd be named "04:xx.y".
> 
> Now, that PCI bridge 00:1e.0 is a transparent bridge (aka "[Subtractive 
> decode]" in your lspci output - as compared to the other bridges that say 
> "[Normal decode]"), which means that you don't actually _have_ to set up 
> any MMIO window on them, since the bridge will forward _any_ PCI cycles 
> that don't get responded to by any other PCI device.
> 
> But having an explicit window is still generally a good idea, since it 
> should allow the PCI bridge to pick up the PCI cycles earlier (no need to 
> wait to see if others respond to it), and possibly allows for better 
> prefetching behavior. So again, the dmesg and the PCI layout actually 
> looks _better_ without the hacky patch.
> 
> So are you saying that the unpatched kernel still reliably doesn't 
> hibernate for you, while the (arguably _incorrect_) patched kernel 
> reliably does hibernate?

Yes, I am.

Thanks,
Rafael

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Rafael J. Wysocki]

On Wednesday, 3 of December 2008, Rafael J. Wysocki wrote:
> On Wednesday, 3 of December 2008, Linus Torvalds wrote:
> > 
> > So are you saying that the unpatched kernel still reliably doesn't 
> > hibernate for you, while the (arguably _incorrect_) patched kernel 
> > reliably does hibernate?
> 
> Yes, I am.

To be more precise, the patched kernel resumes reliably (100% of the time)
while the plain -rc7 doesn't.  Both hibernate (ie. create the image and save
it) reliably.

Thanks,
Rafael

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Rafael J. Wysocki]

On Wednesday, 3 of December 2008, Rafael J. Wysocki wrote:
> On Wednesday, 3 of December 2008, Linus Torvalds wrote:
> > 
> > On Tue, 2 Dec 2008, Rafael J. Wysocki wrote:
> > > 
> > > * dmesg output including one hibernation-resume cycle from 2.6.28-rc7 with the
> > >   debug patch (appended for completness):
> > > 
> > >   http://www.sisk.pl/kernel/debug/mainline/2.6.28-rc7/dmesg-rc7-patched-prep.log
> > > 
> > > * dmesg output including one hibernation-resume cycle from 2.6.28-rc7 without
> > >   the debug patch:
> > > 
> > >   http://www.sisk.pl/kernel/debug/mainline/2.6.28-rc7/dmesg-rc7-nopatch-prep.log
> > 
> > As with Frans, the debug patch seems to make no difference what-so-ever. 
> > Yes, the cardbus regions get allocated differently, but they're fine in 
> > either case, and arguably (exactly as with Frans) the debug patch actually 
> > makes things uglier by actively getting the alignment wrong, and skipping 
> > cardbus setup until later.
> 
> Hm, what about (from the copy of /proc/iomem without the patch at
> http://www.sisk.pl/kernel/debug/mainline/2.6.28-rc7/rc7-nopatch/iomem):
> 
> 88000000-8bffffff : PCI Bus 0000:03
>   88000000-8bffffff : PCI CardBus 0000:04
> 8c000000-91ffffff : PCI Bus 0000:03
>   8c000000-8fffffff : PCI CardBus 0000:04
> 
> (1) Why two ranges are allocated for 0000:03 without the patch while there is
>     only one range with the patch:
> 
> 88000000-880fffff : PCI Bus 0000:03
> 
>     (copy of the file at
>     http://www.sisk.pl/kernel/debug/mainline/2.6.28-rc7/rc7-patched/iomem)?
>     That seems to look like a difference to me.

OK, I see why this happens.

> (2) Why are they so large without the patch while with the patch they are much
>     smaller (O(2^28) vs O(2^21) if I'm not mistaken)?

I don't see why this should happen, though.  Even if the prefetch window is
discarded, the MEM window seems to be much wider without the patch.

> (3) Why are they overlapping with the ranges for CardBus 0000:04, although
>     without the patch they aren't?  Is that actually correct at all?

OK, I see why this happens too.

Sorry for the noise,
Rafael

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Linus Torvalds]

On Wed, 3 Dec 2008, Rafael J. Wysocki wrote:
> 
> Hm, what about (from the copy of /proc/iomem without the patch at
> http://www.sisk.pl/kernel/debug/mainline/2.6.28-rc7/rc7-nopatch/iomem):
> 
> 88000000-8bffffff : PCI Bus 0000:03
>   88000000-8bffffff : PCI CardBus 0000:04
> 8c000000-91ffffff : PCI Bus 0000:03
>   8c000000-8fffffff : PCI CardBus 0000:04
> 
> (1) Why two ranges are allocated for 0000:03 without the patch while there is
>     only one range with the patch:
> 
> 88000000-880fffff : PCI Bus 0000:03

So look at the lspci information that has more details for info on this.

Basically, a Cardbus controller (as well as a PCI bridge) has _two_ very 
different MMIO windows - one for prefetchable MMIO, and one for 
non-prefetchable.

And the windows should match up, although it's always ok to map a 
prefetchable region in a non-prefetchable window (although you may lose 
some performance, since the upstream will now not be able to prefetch).

And it's not really different, exactly because 00:1e.0 is a transparent 
bridge. That "transparency" means that there is an implied decoding window 
DESPITE a lack of an explicit one - it may just be a few PCI cycles slower 
(or not, depending on how the bridge is implemented. It's probably 
technically quite ok for a transparent bridge to ignore its IO/MEM window 
contents entirely).

So those "PCI Bus 0000:03" windows are technically irrelevant, except as a 
possible performance improvement. The bridge will forward PCI cycles 
whether they are there or not. That is what "transparent" means.

> (2) Why are they so large without the patch while with the patch they are much
>     smaller (O(2^28) vs O(2^21) if I'm not mistaken)?

Because without the patch, we'll size the PCI bridge windows according to 
the default setup of the CardBus controller, namely:

 - two IO regions of size 'pci_cardbus_io_size' (256 bytes)

 - one prefetchable and one non-prefetchable IO region of size 
   'pci_cardbus_mem_size' (64MB by default, you can change it with 
   the 'pci=cbmemsize=xyz' kernel command line parameter but nobody ever 
   does)

See pci_bus_size_cardbus() in drivers/pci/setup-bus.c for details.

HOWEVER - when the alignment is wrong, we skip all that, and don't set up 
the CardBus regions there at all, because the whole "pbus_size_mem()" 
thing will just give up.

And then what happens is that we won't set up the CardBus bridge during 
PCI bus setup AT ALL, but later, by the Yenta code. And that one will try 
to do something else entirely.

[ And yes, if you think that it might be a good idea to try to share the 
  code and not have two different cardbus sizing logics, I'm not going to 
  argue against that AT ALL! ]

In the yenta code, we don't try to to just have a fixed maximum size, 
because that code is literally designed to be a fallback case for when the 
PCI sizing fails (ie literally "oops, we had so little space that we 
couldn't use the default max size!" case).

For the yenta code, see drivers/pcmcia/yenta_socket.c ("Yenta" is just the 
name for the CardBus standard programming model), and notice all the logic 
there, see:

 - BRIDGE_MEM_MAX/ACC/MIN and BRIDGE_IO_MAX/ACC/MIN for "max", 
   "acceptable" and "minimum" values respectively.

   Realize thatt he "MAX" value is just 4MB, which is obviously smaller 
   than the 64MB mentioned above, and that's exactly because this is 
   assumed to be a "uhhuh, we ran out of space" case.

 - See yenta_allocate_res() and the helper functions above it that in 
   addition try to shrink the window further if it doesn't fit.

 - Notice how the Yenta code - unlike the generic PCI code - does _not_ 
   try to allocate parent PCI bridge memory window resources, so if we 
   fall into this case, we're going to depend on previously set up windows 
   and/or the fact that a transparent bridge doesn't need them.

So this explains why in one case you'd see a 64M resource, and in another 
just a 4M resource.

_Most_ cardbus cards by far only need a few kB of IOMEM resources, but 
there are some crazy people who do CardBus graphics cards and/or video 
capture cards, and they really do want 32MB+ of MMIO, which is why we try 
to get such a big CardBus MMIO window by default.

As mentioned, you could try to just use

	pci=cbmemsize=4M

on the kernel command line, and see if that also hides the bug. It's 
entirely possible that your suspend/resume problem is not so much about 
the cardbus allocation itself, as about some other memory area that wants 
to use it (eg hidden RAM used by the bios SMM code, whatever).

> (3) Why are they overlapping with the ranges for CardBus 0000:04, although
>     without the patch they aren't?  Is that actually correct at all?

See the earlier explanation of the topology, and realize the 
overlappingness is actually _required_ in order for a PCI bridge to work, 
and forward the PCI cycles to the right lower bus.

But then, with a transparent bridge, if nobody else overlaps, it will 
do what's called "negative decode", which just means that "if nobody else 
said they wanted this PCI cycle, I'll decode it and forward it to the 
lower bus", so a transparent bridge doesn't _need_ the overlap.

Do

	/sbin/lspci -t

to understand the relationship, in particular see how device 0:1e.0 is the 
one that bridges _to_ that CardBus controller.

See the comments about "topology" in my previous email.

> > So in many ways, the debug patch that gets the alignment wrong (on 
> > purpose) is really the inferior one. Plain -rc7 seems to do everything 
> > right.
> 
> Well, I'm not sure ...

I'm pretty sure. 

The fact that you then have hibernation issues is almost certainly due to 
something else. Most likely something else that we don't know about from a 
resource angle that now got "hidden" by the fact that we programmed the 
0:1e.0 bridge to forward to the cardbus controller rather than to some 
insane power management chip.

It's why we have all those quirks in drivers/pci/quirks.c. It's very 
possible that your chipset is missing some quirk.

> > So are you saying that the unpatched kernel still reliably doesn't 
> > hibernate for you, while the (arguably _incorrect_) patched kernel 
> > reliably does hibernate?
> 
> Yes, I am.

So see what happens if you add

	pci=cbmemsize=4M

to make the cardbus allocations smaller. Perhaps that will just change the 
allocations enough that now it doesn't cover something else.

Oh, and please do a "lspci -vvxxx" (as root) too so that I can see the 
actual values in your PCI config space. We have two quirks already 
triggering for you:

  pci 0000:00:1f.0: quirk: region d800-d87f claimed by ICH6 ACPI/GPIO/TCO
  pci 0000:00:1f.0: quirk: region eec0-eeff claimed by ICH6 GPIO

but I'm maybe there's another one missing.

		Linus

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Rafael J. Wysocki]

On Wednesday, 3 of December 2008, Linus Torvalds wrote:
> 
> On Wed, 3 Dec 2008, Rafael J. Wysocki wrote:
> > 
> > > So are you saying that the unpatched kernel still reliably doesn't 
> > > hibernate for you, while the (arguably _incorrect_) patched kernel 
> > > reliably does hibernate?
> > 
> > Yes, I am.
> 
> So see what happens if you add
> 
> 	pci=cbmemsize=4M
> 
> to make the cardbus allocations smaller. Perhaps that will just change the 
> allocations enough that now it doesn't cover something else.
> 
> Oh, and please do a "lspci -vvxxx" (as root) too so that I can see the 
> actual values in your PCI config space. We have two quirks already 
> triggering for you:
> 
>   pci 0000:00:1f.0: quirk: region d800-d87f claimed by ICH6 ACPI/GPIO/TCO
>   pci 0000:00:1f.0: quirk: region eec0-eeff claimed by ICH6 GPIO
> 
> but I'm maybe there's another one missing.

Here's the output of 'lspci -vvxxx':

00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub (rev 03)
	Subsystem: Toshiba America Info Systems Device 0001
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ >SERR- <PERR- INTx-
	Latency: 0
	Capabilities: [e0] Vendor Specific Information <?>
	Kernel driver in use: agpgart-intel
	Kernel modules: intel-agp
00: 86 80 a0 27 06 00 90 20 03 00 00 06 00 00 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 79 11 01 00
30: 00 00 00 00 e0 00 00 00 00 00 00 00 00 00 00 00
40: 01 90 d1 fe 01 40 d1 fe 05 00 00 f0 01 80 d1 fe
50: 00 00 30 00 19 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 10 11 11 00 00 11 33 00 ff 03 00 00 80 4a b8 00
a0: 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 09 00 09 71 23 25 0a a1 0e 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 86 0f 05 00 10 00 00 00

00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03) (prog-if 00 [VGA controller])
	Subsystem: Toshiba America Info Systems Device 0022
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin A routed to IRQ 16
	Region 0: Memory at ffc80000 (32-bit, non-prefetchable) [size=512K]
	Region 1: I/O ports at cff8 [size=8]
	Region 2: Memory at e0000000 (32-bit, prefetchable) [size=256M]
	Region 3: Memory at ffc40000 (32-bit, non-prefetchable) [size=256K]
	Capabilities: [90] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable-
		Address: 00000000  Data: 0000
	Capabilities: [d0] Power Management version 2
		Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Kernel modules: intelfb
00: 86 80 a2 27 07 00 90 00 03 00 00 03 00 00 80 00
10: 00 00 c8 ff f9 cf 00 00 08 00 00 e0 00 00 c4 ff
20: 00 00 00 00 00 00 00 00 00 00 00 00 79 11 22 00
30: 00 00 00 00 90 00 00 00 00 00 00 00 0a 01 00 00
40: 00 00 00 00 48 00 00 00 09 00 09 71 23 25 0a a1
50: 0e 00 30 00 19 00 00 00 00 00 00 00 00 00 80 7f
60: 00 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 05 d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 01 00 22 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 64 34 00 00 00 00 86 0f 05 00 00 00 00 00

00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03)
	Subsystem: Toshiba America Info Systems Device 0022
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Region 0: Memory at 88100000 (32-bit, non-prefetchable) [disabled] [size=512K]
	Capabilities: [d0] Power Management version 2
		Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00: 86 80 a6 27 00 00 90 00 03 00 80 03 00 00 80 00
10: 00 00 10 88 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 79 11 22 00
30: 00 00 00 00 d0 00 00 00 00 00 00 00 00 00 00 00
40: 00 00 00 00 48 00 00 00 09 00 09 71 23 25 0a a1
50: 0e 00 30 00 19 00 00 00 00 00 00 00 00 00 80 7f
60: 00 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 01 00 22 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 64 34 00 00 00 00 86 0f 05 00 00 00 00 00

00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 02)
	Subsystem: Toshiba America Info Systems Device 0001
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 32 bytes
	Interrupt: pin A routed to IRQ 22
	Region 0: Memory at 88180000 (64-bit, non-prefetchable) [size=16K]
	Capabilities: [50] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [60] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable-
		Address: 0000000000000000  Data: 0000
	Capabilities: [70] Express (v1) Root Complex Integrated Endpoint, MSI 00
		DevCap:	MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
			ExtTag- RBE- FLReset-
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+
			MaxPayload 128 bytes, MaxReadReq 128 bytes
		DevSta:	CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
		LnkCap:	Port #0, Speed unknown, Width x0, ASPM unknown, Latency L0 <64ns, L1 <1us
			ClockPM- Suprise- LLActRep- BwNot-
		LnkCtl:	ASPM Disabled; Disabled- Retrain- CommClk-
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed unknown, Width x0, TrErr- Train- SlotClk- DLActive- BWMgmt- ABWMgmt-
	Capabilities: [100] Virtual Channel <?>
	Capabilities: [130] Root Complex Link <?>
	Kernel driver in use: HDA Intel
	Kernel modules: snd-hda-intel
00: 86 80 d8 27 06 00 10 00 02 00 03 04 08 00 00 00
10: 04 00 18 88 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 79 11 01 00
30: 00 00 00 00 50 00 00 00 00 00 00 00 ff 01 00 00
40: 01 00 00 03 00 00 00 00 00 00 00 00 00 00 00 00
50: 01 60 42 c8 00 00 00 00 00 00 00 00 00 00 00 00
60: 05 70 80 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 10 00 91 00 00 00 00 00 00 08 10 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 86 0f 02 00 00 00 00 00

00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 02) (prog-if 00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 32 bytes
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
	I/O behind bridge: 0000b000-0000bfff
	Memory behind bridge: ff900000-ff9fffff
	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
	BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
	Capabilities: [40] Express (v1) Root Port (Slot-), MSI 00
		DevCap:	MaxPayload 128 bytes, PhantFunc 0, Latency L0s unlimited, L1 unlimited
			ExtTag- RBE- FLReset-
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
			MaxPayload 128 bytes, MaxReadReq 128 bytes
		DevSta:	CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
		LnkCap:	Port #1, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <256ns, L1 <4us
			ClockPM- Suprise- LLActRep+ BwNot-
		LnkCtl:	ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt- ABWMgmt-
		RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible-
		RootCap: CRSVisible-
		RootSta: PME ReqID 0000, PMEStatus- PMEPending-
	Capabilities: [80] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable+
		Address: fee0300c  Data: 4161
	Capabilities: [90] Subsystem: Toshiba America Info Systems Device 0001
	Capabilities: [a0] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [100] Virtual Channel <?>
	Capabilities: [180] Root Complex Link <?>
	Kernel driver in use: pcieport-driver
	Kernel modules: shpchp
00: 86 80 d0 27 07 04 10 00 02 00 04 06 08 00 81 00
10: 00 00 00 00 00 00 00 00 00 01 01 00 b0 b0 00 00
20: 90 ff 90 ff f1 ff 01 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 40 00 00 00 00 00 00 00 0b 01 00 00
40: 10 80 41 00 c0 0f 00 00 00 00 10 00 11 2c 11 01
50: 40 00 11 30 60 05 00 00 00 00 40 01 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 05 90 01 00 0c 30 e0 fe 61 41 00 00 00 00 00 00
90: 0d a0 00 00 79 11 01 00 00 00 00 00 00 00 00 00
a0: 01 00 02 c8 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 80 00 11 80 00 00 00 00
e0: 00 0f c7 00 06 07 08 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 86 0f 02 00 00 00 00 00

00:1c.2 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 3 (rev 02) (prog-if 00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 32 bytes
	Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
	Memory behind bridge: ff800000-ff8fffff
	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
	BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
	Capabilities: [40] Express (v1) Root Port (Slot-), MSI 00
		DevCap:	MaxPayload 128 bytes, PhantFunc 0, Latency L0s unlimited, L1 unlimited
			ExtTag- RBE- FLReset-
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
			MaxPayload 128 bytes, MaxReadReq 128 bytes
		DevSta:	CorrErr+ UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
		LnkCap:	Port #3, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <256ns, L1 <4us
			ClockPM- Suprise- LLActRep+ BwNot-
		LnkCtl:	ASPM L0s L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk+
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt- ABWMgmt-
		RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible-
		RootCap: CRSVisible-
		RootSta: PME ReqID 0000, PMEStatus- PMEPending-
	Capabilities: [80] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable+
		Address: fee0300c  Data: 4169
	Capabilities: [90] Subsystem: Toshiba America Info Systems Device 0001
	Capabilities: [a0] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [100] Virtual Channel <?>
	Capabilities: [180] Root Complex Link <?>
	Kernel driver in use: pcieport-driver
	Kernel modules: shpchp
00: 86 80 d4 27 07 04 10 00 02 00 04 06 08 00 81 00
10: 00 00 00 00 00 00 00 00 00 02 02 00 f0 00 00 20
20: 80 ff 80 ff f1 ff 01 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 40 00 00 00 00 00 00 00 0b 03 00 00
40: 10 80 41 00 c0 0f 00 00 00 00 11 00 11 2c 11 03
50: 43 00 11 30 60 05 00 00 00 00 40 01 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 05 90 01 00 0c 30 e0 fe 69 41 00 00 00 00 00 00
90: 0d a0 00 00 79 11 01 00 00 00 00 00 00 00 00 00
a0: 01 00 02 c8 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 80 00 11 80 00 00 00 00
e0: 00 0f c7 00 06 07 08 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 86 0f 02 00 00 00 00 00

00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 (rev 02) (prog-if 00 [UHCI])
	Subsystem: Toshiba America Info Systems Device 0001
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin A routed to IRQ 23
	Region 4: I/O ports at afe0 [size=32]
	Kernel driver in use: uhci_hcd
	Kernel modules: uhci-hcd
00: 86 80 c8 27 05 00 80 02 02 00 03 0c 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: e1 af 00 00 00 00 00 00 00 00 00 00 79 11 01 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 0b 01 00 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 2f 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 86 0f 02 00 00 00 00 00

00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 (rev 02) (prog-if 00 [UHCI])
	Subsystem: Toshiba America Info Systems Device 0001
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin B routed to IRQ 19
	Region 4: I/O ports at af80 [size=32]
	Kernel driver in use: uhci_hcd
	Kernel modules: uhci-hcd
00: 86 80 c9 27 05 00 80 02 02 00 03 0c 00 00 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 81 af 00 00 00 00 00 00 00 00 00 00 79 11 01 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 0b 02 00 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 2f 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 86 0f 02 00 00 00 00 00

00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 (rev 02) (prog-if 00 [UHCI])
	Subsystem: Toshiba America Info Systems Device 0001
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin C routed to IRQ 18
	Region 4: I/O ports at af60 [size=32]
	Kernel driver in use: uhci_hcd
	Kernel modules: uhci-hcd
00: 86 80 ca 27 05 00 80 02 02 00 03 0c 00 00 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 61 af 00 00 00 00 00 00 00 00 00 00 79 11 01 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 0b 03 00 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 2f 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 86 0f 02 00 00 00 00 00

00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #4 (rev 02) (prog-if 00 [UHCI])
	Subsystem: Toshiba America Info Systems Device 0001
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin D routed to IRQ 16
	Region 4: I/O ports at af40 [size=32]
	Kernel driver in use: uhci_hcd
	Kernel modules: uhci-hcd
00: 86 80 cb 27 05 00 80 02 02 00 03 0c 00 00 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 41 af 00 00 00 00 00 00 00 00 00 00 79 11 01 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 0a 04 00 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 2f 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 86 0f 02 00 00 00 00 00

00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 02) (prog-if 20 [EHCI])
	Subsystem: Toshiba America Info Systems Device 0001
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin A routed to IRQ 23
	Region 0: Memory at ffc3fc00 (32-bit, non-prefetchable) [size=1K]
	Capabilities: [50] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [58] Debug port: BAR=1 offset=00a0
	Kernel driver in use: ehci_hcd
	Kernel modules: ehci-hcd
00: 86 80 cc 27 06 00 90 02 02 20 03 0c 00 00 00 00
10: 00 fc c3 ff 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 79 11 01 00
30: 00 00 00 00 50 00 00 00 00 00 00 00 0b 01 00 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 01 58 c2 c9 00 00 00 00 0a 00 a0 20 00 00 00 00
60: 20 20 ff 01 00 00 00 00 01 00 00 00 00 00 08 c0
70: 00 00 d7 3f 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 11 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 aa ff 00 ff 00 ff 00 20 00 00 88
e0: 00 00 00 00 db b6 6d 00 00 00 00 00 00 00 00 00
f0: 00 80 00 09 88 85 40 00 86 0f 02 00 06 17 02 20

00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2) (prog-if 01 [Subtractive decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Bus: primary=00, secondary=03, subordinate=07, sec-latency=32
	I/O behind bridge: 00001000-00001fff
	Memory behind bridge: 88000000-880fffff
	Secondary status: 66MHz- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
	BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
	Capabilities: [50] Subsystem: Toshiba America Info Systems Device 0001
00: 86 80 48 24 07 00 10 00 e2 01 04 06 00 00 01 00
10: 00 00 00 00 00 00 00 00 00 03 07 20 10 10 80 22
20: 00 88 00 88 f1 ff 01 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 50 00 00 00 00 00 00 00 ff 00 00 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 12 00 00
50: 0d 00 00 00 79 11 01 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 86 0f 02 00 00 00 00 00

00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 02)
	Subsystem: Toshiba America Info Systems Device 0001
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Capabilities: [e0] Vendor Specific Information <?>
	Kernel modules: iTCO_wdt
00: 86 80 b9 27 07 00 10 02 02 00 01 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 79 11 01 00
30: 00 00 00 00 e0 00 00 00 00 00 00 00 00 00 00 00
40: 01 d8 00 00 80 00 00 00 c1 ee 00 00 10 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 80 80 80 80 91 00 00 00 80 80 80 80 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 2c 81 06 7c 00 00 00 00 00 00 00 00 00
90: e1 01 0c 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 80 06 00 00 00 00 00 00 13 1c 0a 00 00 03 00 00
b0: 00 00 f0 00 00 00 00 00 00 00 01 04 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 33 22 11 00 67 45 00 00 c0 f0 00 00 00 00 00 00
e0: 09 00 0c 10 b4 02 24 17 00 00 00 00 00 00 00 00
f0: 01 c0 d1 fe 00 00 00 00 86 0f 02 00 00 00 00 00

00:1f.2 SATA controller: Intel Corporation 82801GBM/GHM (ICH7 Family) SATA AHCI Controller (rev 02) (prog-if 01 [AHCI 1.0])
	Subsystem: Toshiba America Info Systems Device 0001
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin B routed to IRQ 317
	Region 0: I/O ports at af38 [size=8]
	Region 1: I/O ports at af34 [size=4]
	Region 2: I/O ports at af28 [size=8]
	Region 3: I/O ports at af24 [size=4]
	Region 4: I/O ports at af10 [size=16]
	Region 5: Memory at ffc3f800 (32-bit, non-prefetchable) [size=1K]
	Capabilities: [80] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable+
		Address: fee0300c  Data: 4179
	Capabilities: [70] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Kernel driver in use: ahci
	Kernel modules: ahci
00: 86 80 c5 27 07 04 b0 02 02 01 06 01 00 00 00 00
10: 39 af 00 00 35 af 00 00 29 af 00 00 25 af 00 00
20: 11 af 00 00 00 f8 c3 ff 00 00 00 00 79 11 01 00
30: 00 00 00 00 80 00 00 00 00 00 00 00 0b 02 00 00
40: 07 a3 00 00 00 00 00 00 01 00 01 00 00 00 00 00
50: 00 00 00 00 10 10 04 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 01 00 02 40 00 00 00 00 00 00 00 00 00 00 00 00
80: 05 70 01 00 0c 30 e0 fe 79 41 00 00 00 00 00 00
90: 40 00 11 10 80 01 00 5a 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 86 0f 02 00 00 00 00 00

01:00.0 Ethernet controller: Intel Corporation 82573L Gigabit Ethernet Controller
	Subsystem: Toshiba America Info Systems Device 0001
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 316
	Region 0: Memory at ff9e0000 (32-bit, non-prefetchable) [size=128K]
	Region 2: I/O ports at bfe0 [size=32]
	Capabilities: [c8] Power Management version 2
		Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=1 PME-
	Capabilities: [d0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable+
		Address: 00000000fee0100c  Data: 41d1
	Capabilities: [e0] Express (v1) Endpoint, MSI 00
		DevCap:	MaxPayload 256 bytes, PhantFunc 0, Latency L0s <512ns, L1 <64us
			ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset-
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
			MaxPayload 128 bytes, MaxReadReq 512 bytes
		DevSta:	CorrErr- UncorrErr+ FatalErr- UnsuppReq+ AuxPwr+ TransPend-
		LnkCap:	Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <128ns, L1 <64us
			ClockPM+ Suprise- LLActRep- BwNot-
		LnkCtl:	ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
			ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
	Capabilities: [100] Advanced Error Reporting <?>
	Capabilities: [140] Device Serial Number ac-dd-af-ff-ff-7e-1c-00
	Kernel driver in use: e1000e
	Kernel modules: e1000e
00: 86 80 9a 10 07 04 10 00 00 00 00 02 10 00 00 00
10: 00 00 9e ff 00 00 00 00 e1 bf 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 79 11 01 00
30: 00 00 00 00 c8 00 00 00 00 00 00 00 0a 01 00 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 01 d0 22 c8 00 20 00 0f
d0: 05 e0 81 00 0c 10 e0 fe 00 00 00 00 d1 41 00 00
e0: 10 00 01 00 c1 0c 00 00 10 28 1a 00 11 1c 07 00
f0: 40 01 11 10 00 00 00 00 00 00 00 00 00 00 00 00

02:00.0 Network controller: Intel Corporation PRO/Wireless 4965 AG or AGN Network Connection (rev 61)
	Subsystem: Intel Corporation Device 1101
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 32 bytes
	Interrupt: pin A routed to IRQ 315
	Region 0: Memory at ff8fe000 (64-bit, non-prefetchable) [size=8K]
	Capabilities: [c8] Power Management version 3
		Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [d0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable+
		Address: 00000000fee0100c  Data: 41d9
	Capabilities: [e0] Express (v1) Endpoint, MSI 00
		DevCap:	MaxPayload 128 bytes, PhantFunc 0, Latency L0s <512ns, L1 unlimited
			ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
			MaxPayload 128 bytes, MaxReadReq 128 bytes
		DevSta:	CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr+ TransPend-
		LnkCap:	Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <128ns, L1 <64us
			ClockPM+ Suprise- LLActRep- BwNot-
		LnkCtl:	ASPM L0s L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk+
			ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
	Capabilities: [100] Advanced Error Reporting <?>
	Capabilities: [140] Device Serial Number e7-38-c3-ff-ff-3b-1f-00
	Kernel driver in use: iwlagn
	Kernel modules: iwlagn
00: 86 80 29 42 06 00 10 00 61 00 80 02 08 00 00 00
10: 04 e0 8f ff 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 01 11
30: 00 00 00 00 c8 00 00 00 00 00 00 00 0b 01 00 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 01 d0 23 c8 00 00 00 0d
d0: 05 e0 81 00 0c 10 e0 fe 00 00 00 00 d9 41 00 00
e0: 10 00 01 00 c0 8e 00 00 10 08 19 00 11 1c 07 00
f0: 43 01 11 10 00 00 00 00 00 00 00 00 00 00 00 00

03:0b.0 CardBus bridge: Texas Instruments PCIxx12 Cardbus Controller
	Subsystem: Toshiba America Info Systems Device 0001
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 168, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 21
	Region 0: Memory at 88004000 (32-bit, non-prefetchable) [size=4K]
	Bus: primary=03, secondary=04, subordinate=07, sec-latency=176
	Memory window 0: 88400000-887ff000 (prefetchable)
	Memory window 1: 88800000-88bff000
	I/O window 0: 00001000-000010ff
	I/O window 1: 00001400-000014ff
	BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset+ 16bInt+ PostWrite+
	16-bit legacy interface ports at 0001
	Kernel driver in use: yenta_cardbus
	Kernel modules: yenta_socket
00: 4c 10 39 80 07 00 10 02 00 00 07 06 10 a8 82 00
10: 00 40 00 88 a0 00 00 02 03 04 07 b0 00 00 40 88
20: 00 f0 7f 88 00 00 80 88 00 f0 bf 88 00 10 00 00
30: fc 10 00 00 00 14 00 00 fc 14 00 00 ff 01 c0 05
40: 79 11 01 00 01 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 60 d0 00 08 19 00 b3 02 00 00 0f 00 22 10 aa 01
90: c0 04 64 60 00 00 00 00 00 00 00 00 00 00 00 00
a0: 01 00 02 7e 00 00 c0 00 00 00 00 00 00 00 00 00
b0: 00 00 00 08 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 08 3e c5 ef a8 9e 01 c2 00 00 00 00 00 00 00 00

03:0b.1 FireWire (IEEE 1394): Texas Instruments PCIxx12 OHCI Compliant IEEE 1394 Host Controller (prog-if 10 [OHCI])
	Subsystem: Toshiba America Info Systems Device 0001
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 64 (500ns min, 1000ns max), Cache Line Size: 32 bytes
	Interrupt: pin B routed to IRQ 20
	Region 0: Memory at 88005000 (32-bit, non-prefetchable) [size=2K]
	Region 1: Memory at 88000000 (32-bit, non-prefetchable) [size=16K]
	Capabilities: [44] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME+
	Kernel driver in use: firewire_ohci
	Kernel modules: firewire-ohci
00: 4c 10 3a 80 06 00 10 02 00 10 00 0c 08 40 80 00
10: 00 50 00 88 00 00 00 88 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 79 11 01 00
30: 00 00 00 00 44 00 00 00 00 00 00 00 ff 02 02 04
40: 00 00 00 00 01 00 02 7e 00 80 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 08 00 00 00
f0: 10 08 00 00 82 00 00 00 79 11 01 00 00 00 00 00

03:0b.3 SD Host controller: Texas Instruments PCIxx12 SDA Standard Compliant SD Host Controller (prog-if 01)
	Subsystem: Toshiba America Info Systems Device 0001
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 64 (1750ns min, 1000ns max), Cache Line Size: 32 bytes
	Interrupt: pin D routed to IRQ 23
	Region 0: Memory at 88005800 (32-bit, non-prefetchable) [size=256]
	Capabilities: [80] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Kernel driver in use: sdhci-pci
	Kernel modules: sdhci-pci
00: 4c 10 3c 80 06 00 10 02 00 01 05 08 08 40 80 00
10: 00 58 00 88 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 79 11 01 00
30: 00 00 00 00 80 00 00 00 00 00 00 00 ff 04 07 04
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 01 00 02 7e 00 00 00 00 63 00 00 00 79 11 01 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

I'll run the 'pci=cbmemsize=4M' test tomorrow (need to have some sleep).

Thanks,
Rafael

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Linus Torvalds]

On Wed, 3 Dec 2008, Rafael J. Wysocki wrote:
> 
> Here's the output of 'lspci -vvxxx':

Ok, I'm not finding any documented quirks that would be memory regions, 
and in fact it doesn't look like there is even any remotely likely 32-bit 
valies that might be pointers in your PCI config space that look remotely 
like they might be conflicting in the area of MMIO space that we allocate 
PCI resources from (ie 0x88000000-0x92000000).

Of course, any odd MMIO regions might be descibed by some insane model 
that doesn't look like an aligned 32-bit value, but that's unlikely.

So I'm still not seeing anything wrong in there.

> I'll run the 'pci=cbmemsize=4M' test tomorrow (need to have some sleep).

Sure. It will be interesting to see if it makes any difference.

		Linus

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Rafael J. Wysocki]

On Wednesday, 3 of December 2008, Linus Torvalds wrote:
> 
> On Wed, 3 Dec 2008, Rafael J. Wysocki wrote:
> > 
> > Here's the output of 'lspci -vvxxx':
> 
> Ok, I'm not finding any documented quirks that would be memory regions, 
> and in fact it doesn't look like there is even any remotely likely 32-bit 
> valies that might be pointers in your PCI config space that look remotely 
> like they might be conflicting in the area of MMIO space that we allocate 
> PCI resources from (ie 0x88000000-0x92000000).
> 
> Of course, any odd MMIO regions might be descibed by some insane model 
> that doesn't look like an aligned 32-bit value, but that's unlikely.
> 
> So I'm still not seeing anything wrong in there.
> 
> > I'll run the 'pci=cbmemsize=4M' test tomorrow (need to have some sleep).
> 
> Sure. It will be interesting to see if it makes any difference.

It didn't help (failure in the 4th consecutive hibernation/resume cycle).

The patched kernel still hibernates and resumes without problems.

Thanks,
Rafael

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Rafael J. Wysocki]

On Wednesday, 3 of December 2008, Rafael J. Wysocki wrote:
> On Wednesday, 3 of December 2008, Linus Torvalds wrote:
> > 
> > On Wed, 3 Dec 2008, Rafael J. Wysocki wrote:
> > > 
> > > Here's the output of 'lspci -vvxxx':
> > 
> > Ok, I'm not finding any documented quirks that would be memory regions, 
> > and in fact it doesn't look like there is even any remotely likely 32-bit 
> > valies that might be pointers in your PCI config space that look remotely 
> > like they might be conflicting in the area of MMIO space that we allocate 
> > PCI resources from (ie 0x88000000-0x92000000).
> > 
> > Of course, any odd MMIO regions might be descibed by some insane model 
> > that doesn't look like an aligned 32-bit value, but that's unlikely.
> > 
> > So I'm still not seeing anything wrong in there.
> > 
> > > I'll run the 'pci=cbmemsize=4M' test tomorrow (need to have some sleep).
> > 
> > Sure. It will be interesting to see if it makes any difference.
> 
> It didn't help (failure in the 4th consecutive hibernation/resume cycle).

Moreover, to check if the problem may be related to the prefetch window,
I added the appended patch on top of -rc7 (instead of the previous debug
patch), which resulted in the following layout in /proc/iomem:

88000000-8dffffff : PCI Bus 0000:03
  88000000-8bffffff : PCI CardBus 0000:04
  8c000000-8c003fff : 0000:03:0b.1
  8c004000-8c004fff : 0000:03:0b.0
    8c004000-8c004fff : yenta_socket
  8c005000-8c0057ff : 0000:03:0b.1
    8c005000-8c0057ff : firewire_ohci
  8c005800-8c0058ff : 0000:03:0b.3
    8c005800-8c0058ff : mmc0
  8c400000-8c7fffff : PCI CardBus 0000:04

and the first hibernation-resume cycle failed.

Thanks,
Rafael

---
 drivers/pci/setup-bus.c |   19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

Index: linux-2.6/drivers/pci/setup-bus.c
===================================================================
--- linux-2.6.orig/drivers/pci/setup-bus.c
+++ linux-2.6/drivers/pci/setup-bus.c
@@ -353,6 +353,25 @@ static int pbus_size_mem(struct pci_bus 
 			r_size = resource_size(r);
 			/* For bridges size != alignment */
 			align = resource_alignment(r);
+			if (r->flags & IORESOURCE_PREFETCH) {
+				resource_size_t expected_align;
+
+				expected_align = (i < PCI_BRIDGE_RESOURCES) ?
+							r_size : r->start;
+				if (align != expected_align) {
+					dev_warn(&dev->dev,
+						"BAR %d [%llx-%llx] "
+						"alignment issue: flags=%lx "
+						"align=%llx (%llx)\n", i,
+						(unsigned long long)r->start,
+						(unsigned long long)r->end,
+						r->flags,
+						(unsigned long long)align,
+						(unsigned long long)expected_align);
+					/* Hacky and wrong, but trying to keep things */
+					align = expected_align;
+				}
+			}
 			order = __ffs(align) - 20;
 			if (order > 11) {
 				dev_warn(&dev->dev, "BAR %d bad alignment %llx: "

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Rafael J. Wysocki]

On Wednesday, 3 of December 2008, Rafael J. Wysocki wrote:
> On Wednesday, 3 of December 2008, Rafael J. Wysocki wrote:
> > On Wednesday, 3 of December 2008, Linus Torvalds wrote:
> > > 
> > > On Wed, 3 Dec 2008, Rafael J. Wysocki wrote:
> > > > 
> > > > Here's the output of 'lspci -vvxxx':
> > > 
> > > Ok, I'm not finding any documented quirks that would be memory regions, 
> > > and in fact it doesn't look like there is even any remotely likely 32-bit 
> > > valies that might be pointers in your PCI config space that look remotely 
> > > like they might be conflicting in the area of MMIO space that we allocate 
> > > PCI resources from (ie 0x88000000-0x92000000).
> > > 
> > > Of course, any odd MMIO regions might be descibed by some insane model 
> > > that doesn't look like an aligned 32-bit value, but that's unlikely.
> > > 
> > > So I'm still not seeing anything wrong in there.
> > > 
> > > > I'll run the 'pci=cbmemsize=4M' test tomorrow (need to have some sleep).
> > > 
> > > Sure. It will be interesting to see if it makes any difference.
> > 
> > It didn't help (failure in the 4th consecutive hibernation/resume cycle).
> 
> Moreover, to check if the problem may be related to the prefetch window,
> I added the appended patch on top of -rc7 (instead of the previous debug
> patch), which resulted in the following layout in /proc/iomem:
> 
> 88000000-8dffffff : PCI Bus 0000:03
>   88000000-8bffffff : PCI CardBus 0000:04
>   8c000000-8c003fff : 0000:03:0b.1
>   8c004000-8c004fff : 0000:03:0b.0
>     8c004000-8c004fff : yenta_socket
>   8c005000-8c0057ff : 0000:03:0b.1
>     8c005000-8c0057ff : firewire_ohci
>   8c005800-8c0058ff : 0000:03:0b.3
>     8c005800-8c0058ff : mmc0
>   8c400000-8c7fffff : PCI CardBus 0000:04
> 
> and the first hibernation-resume cycle failed.
> 
> Thanks,
> Rafael
> 
> ---
>  drivers/pci/setup-bus.c |   19 +++++++++++++++++++
>  1 file changed, 19 insertions(+)
> 
> Index: linux-2.6/drivers/pci/setup-bus.c
> ===================================================================
> --- linux-2.6.orig/drivers/pci/setup-bus.c
> +++ linux-2.6/drivers/pci/setup-bus.c
> @@ -353,6 +353,25 @@ static int pbus_size_mem(struct pci_bus 
>  			r_size = resource_size(r);
>  			/* For bridges size != alignment */
>  			align = resource_alignment(r);
> +			if (r->flags & IORESOURCE_PREFETCH) {
> +				resource_size_t expected_align;
> +
> +				expected_align = (i < PCI_BRIDGE_RESOURCES) ?
> +							r_size : r->start;
> +				if (align != expected_align) {
> +					dev_warn(&dev->dev,
> +						"BAR %d [%llx-%llx] "
> +						"alignment issue: flags=%lx "
> +						"align=%llx (%llx)\n", i,
> +						(unsigned long long)r->start,
> +						(unsigned long long)r->end,
> +						r->flags,
> +						(unsigned long long)align,
> +						(unsigned long long)expected_align);
> +					/* Hacky and wrong, but trying to keep things */
> +					align = expected_align;
> +				}
> +			}
>  			order = __ffs(align) - 20;
>  			if (order > 11) {
>  				dev_warn(&dev->dev, "BAR %d bad alignment %llx: "
> --

Now _that_ seems interesting.

I noticed that on this particular box my first patch is equivalent to replacing
IORESOURCE_SIZEALIGN with IORESOURCE_STARTALIGN in two places under the last
'if()' in pci_bus_size_cardbus(), so I wondered what would happen if we only
allocated the prefetchable region in there.  Following that, I did:

--- linux-2.6.orig/drivers/pci/setup-bus.c
+++ linux-2.6/drivers/pci/setup-bus.c
@@ -432,12 +432,14 @@ static void pci_bus_size_cardbus(struct 
 	 */
 	if (ctrl & PCI_CB_BRIDGE_CTL_PREFETCH_MEM0) {
 		b_res[2].start = 0;
-		b_res[2].end = pci_cardbus_mem_size - 1;
+		b_res[2].end = pci_cardbus_mem_size * 2 - 1;
 		b_res[2].flags |= IORESOURCE_MEM | IORESOURCE_PREFETCH | IORESOURCE_SIZEALIGN;
 
+#if 0
 		b_res[3].start = 0;
 		b_res[3].end = pci_cardbus_mem_size - 1;
 		b_res[3].flags |= IORESOURCE_MEM | IORESOURCE_SIZEALIGN;
+#endif
 	} else {
 		b_res[3].start = 0;
 		b_res[3].end = pci_cardbus_mem_size * 2 - 1;

(well, I didn't have to allocate twice the size but that was to check if the
size of the allocation was going to matter), which resulted in the appended
/proc/iomem.

Then, voila!, I'm not able to reproduce the hibernation-resume failure.

This appears to mean that:
(1) The sizes of the allocations and the locations of devices in the memory
    address space don't matter here.
(2) The presence and size of the prefetchable memory window don't matter here.
(3) What matters is the presence of non-prefetchable memory window on the
    supposedly transparent bridge.  Namely, if the window is there, resume from
    hibernation occasionally fails (again, the size of the window and the
    location of it in the memory address space doesn't seem to matter).

So, apparently, on this box (and I guess on Frans' too) we could avoid the
problem if we didn't allocate the non-prefetchable memory window in
pci_bus_size_cardbus(), but I guess that wouldn't be generally correct.

Also, I would be happy to actually understand _why_ this happens.

Thanks,
Rafael

---
00000000-0009fbff : System RAM
0009fc00-0009ffff : reserved
000e0000-000eedff : reserved
000eee00-000eefff : ACPI Non-volatile Storage
000ef000-000fffff : reserved
00100000-7f74ffff : System RAM
  00200000-00450486 : Kernel code
  00450487-00603c37 : Kernel data
  00678000-00784d3b : Kernel bss
7f750000-7fffffff : reserved
  7f750000-7f75ffff : pnp 00:00
  7f760000-7f7fffff : pnp 00:00
  7f800000-7fffffff : pnp 00:00
88000000-8fffffff : PCI Bus 0000:03 <-- the prefetchable window
  88000000-8fffffff : PCI CardBus 0000:04 <-- the prefetchable window
90000000-900fffff : PCI Bus 0000:03
  90000000-90003fff : 0000:03:0b.1
  90004000-90004fff : 0000:03:0b.0
    90004000-90004fff : yenta_socket
  90005000-900057ff : 0000:03:0b.1
    90005000-900057ff : firewire_ohci
  90005800-900058ff : 0000:03:0b.3
    90005800-900058ff : mmc0
90100000-9017ffff : 0000:00:02.1
90180000-90183fff : 0000:00:1b.0
  90180000-90183fff : ICH HD audio
90184000-90184fff : Intel Flush Page
90400000-907fffff : PCI CardBus 0000:04 <-- last interesting line
e0000000-efffffff : 0000:00:02.0
  e0000000-e07affff : vesafb
f0000000-f3ffffff : PCI MMCONFIG 0
  f0000000-f3ffffff : pnp 00:01
fec00000-fec17fff : reserved
  fec00000-fec17fff : pnp 00:00
    fec00000-fec00fff : IOAPIC 0
fec20000-fec27fff : reserved
  fec20000-fec27fff : pnp 00:00
fed00000-fed003ff : HPET 0
  fed00000-fed003ff : reserved
fed14000-fed19fff : reserved
  fed14000-fed19fff : pnp 00:00
fed1c000-fed8ffff : reserved
  fed1c000-fed1ffff : pnp 00:00
  fed20000-fed3ffff : pnp 00:00
  fed45000-fed8ffff : pnp 00:00
feda0000-fedbffff : reserved
  feda0000-fedbffff : pnp 00:00
fee00000-fee00fff : Local APIC
  fee00000-fee00fff : reserved
    fee00000-fee00fff : pnp 00:00
ff800000-ff8fffff : PCI Bus 0000:02
  ff8fe000-ff8fffff : 0000:02:00.0
    ff8fe000-ff8fffff : iwlagn
ff900000-ff9fffff : PCI Bus 0000:01
  ff9e0000-ff9fffff : 0000:01:00.0
    ff9e0000-ff9fffff : e1000e
ffa00000-ffbfffff : reserved
  ffa00000-ffbfffff : pnp 00:00
ffc3f800-ffc3fbff : 0000:00:1f.2
  ffc3f800-ffc3fbff : ahci
ffc3fc00-ffc3ffff : 0000:00:1d.7
  ffc3fc00-ffc3ffff : ehci_hcd
ffc40000-ffc7ffff : 0000:00:02.0
ffc80000-ffcfffff : 0000:00:02.0
ffd00000-ffffffff : reserved
  ffd00000-ffffffff : pnp 00:00

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Linus Torvalds]

On Wed, 3 Dec 2008, Rafael J. Wysocki wrote:
> 
> Then, voila!, I'm not able to reproduce the hibernation-resume failure.
> 
> This appears to mean that:
> (1) The sizes of the allocations and the locations of devices in the memory
>     address space don't matter here.
> (2) The presence and size of the prefetchable memory window don't matter here.
> (3) What matters is the presence of non-prefetchable memory window on the
>     supposedly transparent bridge.  Namely, if the window is there, resume from
>     hibernation occasionally fails (again, the size of the window and the
>     location of it in the memory address space doesn't seem to matter).

That is indeed rather odd, and very interesting. 

> So, apparently, on this box (and I guess on Frans' too) we could avoid the
> problem if we didn't allocate the non-prefetchable memory window in
> pci_bus_size_cardbus(), but I guess that wouldn't be generally correct.

Well, I think that what _would_ be generally correct, and actually pretty 
simple, is a rather different approach: just not sizing things behind a 
transparent bridge AT ALL, since it really shouldn't matter.

So if the appended patch fixes things for you, I think this might 
potentially be the right approach.

NOTE NOTE NOTE! This patch is entirely untested, as usual. I didn't check 
that this is necessarily the correct place to test for this, but it 
does make sense. IOW, it _feels_ like the rigth thing. However, even if it 
fixes things for you, I think we're too late in the 2.6.28 cycle to really 
apply this.

So it really does make sense to consider a root bridge and a transparent 
one to be equivalent here, since in both cases any bridge windows should 
be irrelevant. Which is why I think this patch is interesting.

> Also, I would be happy to actually understand _why_ this happens.

100% agreed. I do _not_ see why it should ever matter how we set up a PCI 
bridging window - whether prefetchable or not - on a bridge that should be 
transparent. It sounds really odd. I'm wondering if there is something 
we're missing here.

But apart from the existence of the bridging window, the only thing that 
it seems to affect is really just a minor layour issue. So it does seem 
like it matters. Odd.

			Linus

---
 drivers/pci/setup-bus.c |    8 ++++++--
 1 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index ea979f2..586451c 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -467,8 +467,12 @@ void __ref pci_bus_size_bridges(struct pci_bus *bus)
 		}
 	}
 
-	/* The root bus? */
-	if (!bus->self)
+	/*
+	 * We don't need to allocate PCI bridging windows
+	 * for a root bus (everything bridged) or for a
+	 * transparent one.
+	 */
+	if (!bus->self || bus->self->transparent)
 		return;
 
 	switch (bus->self->class >> 8) {

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Rafael J. Wysocki]

On Wednesday, 3 of December 2008, Linus Torvalds wrote:
> 
> On Wed, 3 Dec 2008, Rafael J. Wysocki wrote:
> > 
> > Then, voila!, I'm not able to reproduce the hibernation-resume failure.
> > 
> > This appears to mean that:
> > (1) The sizes of the allocations and the locations of devices in the memory
> >     address space don't matter here.
> > (2) The presence and size of the prefetchable memory window don't matter here.
> > (3) What matters is the presence of non-prefetchable memory window on the
> >     supposedly transparent bridge.  Namely, if the window is there, resume from
> >     hibernation occasionally fails (again, the size of the window and the
> >     location of it in the memory address space doesn't seem to matter).
> 
> That is indeed rather odd, and very interesting. 
> 
> > So, apparently, on this box (and I guess on Frans' too) we could avoid the
> > problem if we didn't allocate the non-prefetchable memory window in
> > pci_bus_size_cardbus(), but I guess that wouldn't be generally correct.
> 
> Well, I think that what _would_ be generally correct, and actually pretty 
> simple, is a rather different approach: just not sizing things behind a 
> transparent bridge AT ALL, since it really shouldn't matter.
> 
> So if the appended patch fixes things for you, I think this might 
> potentially be the right approach.
> 
> NOTE NOTE NOTE! This patch is entirely untested, as usual. I didn't check 
> that this is necessarily the correct place to test for this, but it 
> does make sense. IOW, it _feels_ like the rigth thing.

Yes, it _looks_ sane.

> However, even if it fixes things for you, I think we're too late in the
> 2.6.28 cycle to really apply this.

Absolutely.

> So it really does make sense to consider a root bridge and a transparent 
> one to be equivalent here, since in both cases any bridge windows should 
> be irrelevant. Which is why I think this patch is interesting.
> 
> > Also, I would be happy to actually understand _why_ this happens.
> 
> 100% agreed. I do _not_ see why it should ever matter how we set up a PCI 
> bridging window - whether prefetchable or not - on a bridge that should be 
> transparent. It sounds really odd. I'm wondering if there is something 
> we're missing here.
> 
> But apart from the existence of the bridging window, the only thing that 
> it seems to affect is really just a minor layour issue. So it does seem 
> like it matters. Odd.

Well, in principle it may be related to the way we handle bridges during
resume, but I really need to read some docs and compare them with the code
before I can say anything more about that.  Surely, nothing like this issue has
ever been reported before.

Anyway, thanks for the patch, I'm going to try it tomorrow.

Best,
Rafael

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Linus Torvalds]

On Thu, 4 Dec 2008, Rafael J. Wysocki wrote:
> 
> Well, in principle it may be related to the way we handle bridges during
> resume

Ahh. Yes, that's possible. It's quite possible that the problem isn't 
resource allocation per se, but just the bigger complexity at resume time.

This is a hibernate-only issue for you, right? Or is it about regular 
suspend-to-ram too?

> but I really need to read some docs and compare them with the code 
> before I can say anything more about that.  Surely, nothing like this 
> issue has ever been reported before.

Well, how stable has hibernate been on that particular machine 
historically?

Because the half-revert alignment patch (ie reverting part of 5f17cf) that 
made it work for you would actually have been a non-issue in the original 
code that was pre-PCI-resource-alignment cleanup (commit 88452565).

So the patch you partially reverted was literally the one that made the 
Cardbus allocation work the _same_ way as it did historically, before 
88452565. So if the new code breaks for you, then so should the "old" code 
(ie 2.6.25 and earlier).

So the "hasn't been reported before" case may well be just another way of 
saying "hibernate has never been very reliable".

			Linus

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Frans Pop]

OOn Thursday 04 December 2008, you wrote:
> On Thu, 4 Dec 2008, Rafael J. Wysocki wrote:
> > Well, in principle it may be related to the way we handle bridges
> > during resume
>
> This is a hibernate-only issue for you, right? Or is it about regular
> suspend-to-ram too?

It is regular suspend to ram.

I feel now confident in saying that with the debug patch resume from STR 
is 100% reliable. And the two workarounds I was using to improve resume 
reliability are no longer needed:
- unloading e1000e before suspend
- using aggressive powersave setting on snd_hda_intel to ensure that
  sound controller was already sleeping before entering suspend

I don't think we have any theory yet on how those workarounds were helping 
to improve things, right?

> Well, how stable has hibernate been on that particular machine
> historically?

I cannot comment on this as I have not owned this laptop long enough.


One other thing: the ohci1394 "irq 19: nobody cared" issue is definitely 
unrelated as I just got one during a resume with the debug patch.

Cheers,
FJP

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Frans Pop]

[-- Attachment #1: Type: text/plain, Size: 3636 bytes --]

On Wednesday 03 December 2008, Linus Torvalds wrote:
> Well, I think that what _would_ be generally correct, and actually
> pretty simple, is a rather different approach: just not sizing things
> behind a transparent bridge AT ALL, since it really shouldn't matter.

I've given your patch a try and the few resumes from STR I've done were 
all successful. That's not 100% conclusive yet, but a nice start.
Some info from logs etc. below.

> > Also, I would be happy to actually understand _why_ this happens.
>
> 100% agreed. I do _not_ see why it should ever matter how we set up a
> PCI bridging window - whether prefetchable or not - on a bridge that
> should be transparent. It sounds really odd. I'm wondering if there is
> something we're missing here.

The theory that it is really a resume issue and not a device layout issue 
sounds logical. Especially as everything always works correctly after a 
normal boot.

Cheers,
FJP

Below info from 3 kernels, all based on 2.6.28-rc7-91:
A) unpatched
B) with the revert/debug patch
C) with the oneliner "ignore transparent bridges" patch

AFAICT all results are probably as expected.

From lspci -vvxxx:
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge
- for A)
	I/O behind bridge: 00003000-00003fff
	Memory behind bridge: e0100000-e03fffff
	Prefetchable memory behind bridge: 0000000080000000-0000000083ffffff
- for B)
	I/O behind bridge: 00003000-00003fff
	Memory behind bridge: e0100000-e03fffff
- for C)
	Memory behind bridge: e0100000-e03fffff
02:06.0 CardBus bridge: Ricoh Co Ltd RL5c476 II
- for A)
	Memory window 0: 80000000-83fff000 (prefetchable)
	Memory window 1: 84000000-87fff000
	I/O window 0: 00003000-000030ff
	I/O window 1: 00003400-000034ff
- for B)
	Memory window 0: 84400000-847ff000 (prefetchable)
	Memory window 1: 80000000-83fff000
	I/O window 0: 00003000-000030ff
	I/O window 1: 00003400-000034ff
- for C)
	Memory window 0: 80000000-83fff000 (prefetchable)
	Memory window 1: 84000000-87fff000
	I/O window 0: 00001400-000014ff
	I/O window 1: 00001800-000018ff

From /proc/iomem:
- for A)
80000000-83ffffff : PCI Bus 0000:02
  80000000-83ffffff : PCI CardBus 0000:03
84000000-87ffffff : PCI CardBus 0000:03
88000000-88000fff : Intel Flush Page
- for B)
80000000-83ffffff : PCI CardBus 0000:03
84000000-84000fff : Intel Flush Page
84400000-847fffff : PCI CardBus 0000:03
- for C)
80000000-83ffffff : PCI CardBus 0000:03
84000000-87ffffff : PCI CardBus 0000:03
88000000-88000fff : Intel Flush Page

Attached a tarball with dmesg for all 3 kernel, including a successful 
STR/resume cycle for each (not cleaned up this time).
A) 2.6.28-rc7_nofix
B) 2.6.28-rc7_revert
C) 2.6.28-rc7_resumefix

From the last one:
pci 0000:02:06.0: CardBus bridge, secondary bus 0000:03
pci 0000:02:06.0:   IO window: 0x001400-0x0014ff
pci 0000:02:06.0:   IO window: 0x001800-0x0018ff
pci 0000:02:06.0:   PREFETCH window: 0x80000000-0x83ffffff
pci 0000:02:06.0:   MEM window: 0x84000000-0x87ffffff
pci 0000:00:1e.0: PCI bridge, secondary bus 0000:02
pci 0000:00:1e.0:   IO window: disabled
pci 0000:00:1e.0:   MEM window: 0xe0100000-0xe03fffff
pci 0000:00:1e.0:   PREFETCH window: disabled
[...]
bus: 02 index 0 mmio: [0x0-0x0]
bus: 02 index 1 mmio: [0xe0100000-0xe03fffff]
bus: 02 index 2 mmio: [0x0-0x0]
bus: 02 index 3 io port: [0x00-0xffff]
bus: 02 index 4 mmio: [0x000000-0xffffffffffffffff]
bus: 03 index 0 io port: [0x1400-0x14ff]
bus: 03 index 1 io port: [0x1800-0x18ff]
bus: 03 index 2 mmio: [0x80000000-0x83ffffff]
bus: 03 index 3 mmio: [0x84000000-0x87ffffff]


[-- Attachment #2: dmesg.tgz --]
[-- Type: application/x-tgz, Size: 32289 bytes --]

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Linus Torvalds]

On Thu, 4 Dec 2008, Frans Pop wrote:

> On Wednesday 03 December 2008, Linus Torvalds wrote:
> > Well, I think that what _would_ be generally correct, and actually
> > pretty simple, is a rather different approach: just not sizing things
> > behind a transparent bridge AT ALL, since it really shouldn't matter.
> 
> I've given your patch a try and the few resumes from STR I've done were 
> all successful. That's not 100% conclusive yet, but a nice start.
> Some info from logs etc. below.

Ok, but I thought you had a hard time reproducing this _anyway_, even with 
just plain -rc7. No?

That said, of the various patches posted, the "don't bother allocating 
bridging windows for transparent bridges" one is not just the simplest, 
but the only one that actually makes sense so far.

So I'm happy it's apparently working for you, I'm just wondering about 
whather your success means a lot. It seems that Rafael is the one who had 
more failures?

> > > Also, I would be happy to actually understand _why_ this happens.
> >
> > 100% agreed. I do _not_ see why it should ever matter how we set up a
> > PCI bridging window - whether prefetchable or not - on a bridge that
> > should be transparent. It sounds really odd. I'm wondering if there is
> > something we're missing here.
> 
> The theory that it is really a resume issue and not a device layout issue 
> sounds logical. Especially as everything always works correctly after a 
> normal boot.

Yes, that does sound like a convincing argument. Usually real PCI resource 
clashes result in some kind of run-time problems, and wouldn't necessarily 
be suspend-specific per se.

That said, suspend/resume does a lot of unusual things, so it could still 
be some odd PCI resource clash that only triggers problems in the 
suspend/resume case. But since the exact layouts and the sizing of the 
resources doesn't really seem to matter, a simple PCI resource clash seems 
rather unlikely.

So some kind of resume-time ordering or timing issue does seem like the 
most likely thing. But that still leaves us not knowing what the real 
_root_ cause of this all is - very irritating. Even if not allocating the 
unnecessary bridging windows "fixes" things, it would be really really 
good to know exactly what it is that causes problems.

> Below info from 3 kernels, all based on 2.6.28-rc7-91:
> A) unpatched
> B) with the revert/debug patch
> C) with the oneliner "ignore transparent bridges" patch
> 
> AFAICT all results are probably as expected.
> 
> From lspci -vvxxx:
> 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge
> - for A)
> 	I/O behind bridge: 00003000-00003fff
> 	Memory behind bridge: e0100000-e03fffff
> 	Prefetchable memory behind bridge: 0000000080000000-0000000083ffffff
> - for B)
> 	I/O behind bridge: 00003000-00003fff
> 	Memory behind bridge: e0100000-e03fffff
> - for C)
> 	Memory behind bridge: e0100000-e03fffff

And this all makes total sense. The e0100000-e03fffff MMIO bridge range is 
apparently set up by the firmware, which is why it shows up in all cases. 
And the (A) case has that prefetchable memory range, because that's the 
only case that finds - and cares about - the prefetch window for the 
CardBus controller. 

And both (A) and (B) have the IO bridging window, because regardless of 
whether we see a valid CardBus prefetchable memory window with good 
alignment, we'll always see the IO ports, so we'll try to allocate that 
bridging window, except in (C) when we decide that due to the transparent 
nature, we simply don't care.

So the PCI resources make sense in all three cases, and we understand 
those. The differences in the actual Cardbus ranges also all make sense. 
So it all still boils down to the PCI layer doing everything right in 
_all_ cases, just making slightly different - but all valid - choices 
depending on essentially random details (eg the revert/debug patch case 
the "random detail" is just enabling a small incorrect alignment).

IOW, it really doesn't look like a PCI resource allocator bug. Quite the 
reverse, I'd say that in the end this whole thread points out just how 
robust the whole PCI and cardbus resource allocation is, with the code 
really very gracefully just adjusting in a sane manner to all these 
different cases.

Of course, none of that helps us with any kind of idea of what the real 
problem is. Device ordering bug in setting up PCI resources at resume? 
Perhaps just a plain bug in PCI bridge resume code (even when you resume 
things in the right order)?

And I still worry that perhaps it's just a timing bug, where having a PCI 
bridging window changes timing of various PCI accesses, and the _real_ bug 
is actually in the sound card or ethernet driver resume, which happens to 
work with one timing and not with another.

Since it's apparently STR, has anybody gotten _anything_ sane out of 
trying to enable PM_TRACE_RTC, and then doing that 

	echo 1 > /sys/power/pm_trace

because even with the (very limited) set of standard trace-points, it 
should still be able to tell which device we were trying to resume last in 
the failure case Maybe that gives some hint?

				Linus

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Frans Pop]

On Thursday 04 December 2008, Linus Torvalds wrote:
> On Thu, 4 Dec 2008, Frans Pop wrote:
> > I've given your patch a try and the few resumes from STR I've done
> > were all successful. That's not 100% conclusive yet, but a nice
> > start. Some info from logs etc. below.
>
> Ok, but I thought you had a hard time reproducing this _anyway_, even
> with just plain -rc7. No?

Well, I had a failure rate of about 1 in 5-10 resumes originally.
See: http://bugzilla.kernel.org/show_bug.cgi?id=11545

Then I found the 2 workarounds and *with those in place* I got almost 100% 
reliable resumes. Now I've removed those workarounds and with either the 
revert or your oneliner I still get 100% success.
>From my PoV that is a very definite improvement: the machine now "feels" a 
hell of a lot more reliable for critical use.

So I _could_ reproduce it reliably given enough suspend/resume cycles.
But I guess this does support your suspicion that it may be a timing 
issue: if the timing happens to be right, the resume succeeds; if it's 
wrong I get a dead box.

> Since it's apparently STR, has anybody gotten _anything_ sane out of
> trying to enable PM_TRACE_RTC, and then doing that
>
> 	echo 1 > /sys/power/pm_trace

I did try that at the beginning. That's how I ended up removing e1000e 
before suspend. See http://bugzilla.kernel.org/show_bug.cgi?id=11545.

My next hint was that Matthew Garret, who has the same notebook, was 
surprised at my resume problems as he did not see them. So I did a 
comparison of our kernel configs and made some changes to mine. From
that I found that a very low value for SND_HDA_POWER_SAVE_DEFAULT (5) 
reduced the failure rate to practically zero.

At some point I tried keeping e1000e loaded for a bit, but that quickly 
gave me a failure again, so I starting removing it again during suspend.

So I did have some data, but as I got no response on my BR I had no idea 
where to go from there. I was really very happy to see Rafael's mail as 
his description almost exactly matched what I had been seeing.

I'd be happy to run with unpatched kernels for a while and do some more 
pm_traces, but only if someone is going to follow up and interpret the 
results for me or provide suggestions for targeted additional debugging.

Cheers,
FJP

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Linus Torvalds]

Ingo, Len, can you check the end of the email about the apparent 
very-early interrupt issue? Can we get into acpi_ec_gpe_handler() without 
interrupts being enabled some way?

Greg, Jesse, can you think about and look at the USB PCI resume ordering?

On Thu, 4 Dec 2008, Frans Pop wrote:
> 
> Well, I had a failure rate of about 1 in 5-10 resumes originally.
> See: http://bugzilla.kernel.org/show_bug.cgi?id=11545

Ok, very interesting. Thanks for the pointer.

> Then I found the 2 workarounds and *with those in place* I got almost 100% 
> reliable resumes. Now I've removed those workarounds and with either the 
> revert or your oneliner I still get 100% success.
> From my PoV that is a very definite improvement: the machine now "feels" a 
> hell of a lot more reliable for critical use.

Sure. I'd love to apply the "transparency fix" (the last patch), but my 
main worry is that while it feels really right, and it fixes things for 
you and Rafael, these kinds of changes historically _always_ end up biting 
us. Because even if it's 100% the correct thing to do, it will show up 
some problem for somebody else just because we're really unlucky, and it 
just ends up exposing some totally unrelated bug.

Exactly the same way that this whole PCI resource setting thing was 100% 
correct in the first place, but exposed some other bug.

> So I _could_ reproduce it reliably given enough suspend/resume cycles.
> But I guess this does support your suspicion that it may be a timing 
> issue: if the timing happens to be right, the resume succeeds; if it's 
> wrong I get a dead box.

Yes.

> I did try that at the beginning. That's how I ended up removing e1000e 
> before suspend. See http://bugzilla.kernel.org/show_bug.cgi?id=11545.

What is interesting is that it's apparently not reliably that e1000e thing 
that is being resumed when it fails. You have another report there that 
says that it's a match on PNP0C0A.

Of course, the way that hash works, we only have a few bits to create it, 
and sometimes you just get false positives (there's not a whole lot you 
can reliably do with about 24 bits of information ;(

So it would be interesting to get a few more debug traces of that lockup.

HOWEVER. Having now looked through your fuller dmesg output even for the 
_successful_ case, I actually find a few things that are a bit worrying.

Looking at the unpatched dmesg, since that's the most interesting one 
(since it's the one that should hopefully show behaviour that is 
potentially triggering the problem), I see two worrying things:

	pci 0000:00:1e.0: restoring config space at offset 0x9 (was 0x10001, writing 0x83f18001)
	pci 0000:00:1e.0: restoring config space at offset 0x8 (was 0x0, writing 0xe030e010)
	pci 0000:00:1e.0: restoring config space at offset 0x7 (was 0x228000f0, writing 0x22803030)
	pci 0000:00:1e.0: restoring config space at offset 0x1 (was 0x100007, writing 0x100107)
	pci 0000:00:1e.0: setting latency timer to 64

That "offset 0x9/0x8/0x7" are the PCI bridge window prefetchable memory, 
non-prefetchable memory, and IO bases respectively (when it says '0x9', 
it's counting in quad-words, so it's really config space offset 0x24L 
PCI_PREF_MEMORY_BASE).

Now, that really means:
 - 0x9 prefetchable window: was disabled, is now 0x80000000-0x83ffffff
 - 0x8 nonprefetch window: was disabled, is now  0xe0100000-0xe03fffff
 - 0x7 IO window: was disabled, is noe 0x3000-0x3fff

That all looks correct, BUT the IO base reprogramming actually worries me. 
It's correct only because it's a 16-bit range. For a 32-bit range (which 
is not supported on an x86 platform, since IO ports are always just 16 
bits), the ordering would be very different, and we'd have to make sure 
that we write the upper bits in a special order to avoid problems.

With the "revert fix", the sequence is essentially the same, just 
different values:

	pci 0000:00:1e.0: restoring config space at offset 0x9 (was 0x10001, writing 0x1fff1)
	pci 0000:00:1e.0: restoring config space at offset 0x8 (was 0x0, writing 0xe030e010)
	pci 0000:00:1e.0: restoring config space at offset 0x7 (was 0x228000f0, writing 0x22803030)
	pci 0000:00:1e.0: restoring config space at offset 0x1 (was 0x100007, writing 0x100107)
	pci 0000:00:1e.0: setting latency timer to 64

the difference is that we now disable the prefetchable window (since we 
never allocated it), we just disable it with a different value than the 
one the BIOS used (0x10001 _could_ be imagined to mean "bridge the range 
0x00000000-0x0000ffff, while the kernel disables the IO region by setting 
the lower range higher than the high range, which is why you see those 
fff's there).

But the "revert fix" still has the IO range restore. It's still correct in 
this case (no 32-bit IO bits set), but still has the 32-bit range worry 
for non-x86.

With the "fix transparent bridges", the sequence is different:

	pci 0000:00:1e.0: restoring config space at offset 0x9 (was 0x10001, writing 0x1fff1)
	pci 0000:00:1e.0: restoring config space at offset 0x8 (was 0x0, writing 0xe030e010)
	pci 0000:00:1e.0: restoring config space at offset 0x1 (was 0x100007, writing 0x100107)
	pci 0000:00:1e.0: setting latency timer to 64

ie now we don't even touch the IO window, since we agree with the BIOS on 
how to disable it (ie the kernel also disables it by writing 0x00f0 to the 
low 16 bits).

Anyway, the bridge reprogramming itself all looks correct, and the only 
worry really is that I'm not sure our PCI resume code really stricly 
speaking does the right thing for 32-bit IO resources for other non-x86
architectures.

The "transparent bridge" fix results in the simplest resume sequence for 
that bridge, but the "revert" fix really makes almost no difference at 
all, and again should not matter in the _least_ from a resume standpoint!

So there is a _small_ worry there, but it's not relevant for PC platforms, 
and in no case does it look like the programming of the transparent bridge 
should matter in any way what-so-ever for the resume code.

In many ways the bigger worry is actually in the totally unrelated USB 
UHCI and EHCI drivers that resume _before_ the bridge does:

	uhci_hcd 0000:00:1d.2: enabling device (0000 -> 0001)
	uhci_hcd 0000:00:1d.2: PCI INT C -> GSI 18 (level, low) -> IRQ 18
	uhci_hcd 0000:00:1d.2: setting latency timer to 64
	uhci_hcd 0000:00:1d.2: restoring config space at offset 0xf (was 0x300, writing 0x30b)
	uhci_hcd 0000:00:1d.2: restoring config space at offset 0x8 (was 0x1, writing 0x2101)
	usb usb7: root hub lost power or was reset
	ehci_hcd 0000:00:1d.7: enabling device (0000 -> 0002)
	ehci_hcd 0000:00:1d.7: PCI INT A -> GSI 20 (level, low) -> IRQ 20
	ehci_hcd 0000:00:1d.7: setting latency timer to 64
	ehci_hcd 0000:00:1d.7: restoring config space at offset 0xf (was 0x100, writing 0x10a)
	ehci_hcd 0000:00:1d.7: restoring config space at offset 0x4 (was 0x0, writing 0xe0648000)

and the worry I have here is that we actually enable the device _before_ 
we've restored the BAR information. That sounds very iffy. It sounds 
doubly iffy in the 'resume from hibernate' case, where we are going to 
have an already-set-up PCI bus and the config space values are going to 
all be live as we reprogram them.

That "restoring config space at offset 0x8" thing is where we restore 
the BAR (dword 0x8 = offset 0x20 = PCI_BASE_ADDRESS_4), and we're changing 
it from 0x1 to 0x2101, with the IO BAR enabled. In this case, the old 
value meant that the BAR started out disabled, but hibernate would have 
been different.

So I'd _much_ rather have seen the sequence have the BAR restore sequence 
be something like

	uhci_hcd 0000:00:1d.2: restoring config space at offset 0xf (was 0x300, writing 0x30b)
	uhci_hcd 0000:00:1d.2: restoring config space at offset 0x8 (was 0x1, writing 0x2101)
	uhci_hcd 0000:00:1d.2: enabling device (0000 -> 0001)
	uhci_hcd 0000:00:1d.2: PCI INT C -> GSI 18 (level, low) -> IRQ 18
	uhci_hcd 0000:00:1d.2: setting latency timer to 64

instead. Possibly even with an explicit disable of the memory/IO/busmaster 
bits before the whole sequence.

That said, I don't think this is the cause of the problem either. For one 
thing, the USB resume happens after the e1000e resume, so since you've 
apparently seen it hang in the e1000e driver, the real problem must have 
occurred earlier. And e1000e is resumed not just before USB on your 
machine, but even before the PCI bridge is (since it's on the root bus).

For another, in your case, the BAR really was disabled, so there was 
nothing "live" going on here anyway.

The third thing that worries me is the _very_ early occurrence of

	ACPI: Waking up from system sleep state S3
	APIC error on CPU1: 00(40)
	ACPI: EC: non-query interrupt received, switching to interrupt mode

Now, that "APIC error" thing is worrisome. It's worrisome for multiple 
reasons:

 - errors are never good (0x40 means "received illegal vector", whatever 
   caused _that_)

 - more importantly, it seems to imply that interrupts are enabled on 
   CPU1, and they sure as hell shouldn't be enabled at this stage!

   Do we perhaps have a SMP resume bug where we resume the other CPU's 
   with interrupts enabled?

 - the "ACPI: EC: non-query interrupt received, switching to interrupt 
   mode" thing is from ACPI, and _also_ implies that interrupts are on. 

Why are interrupts enabled that early? I really don't like seeing 
interrupts enabled before we've even done the basic PCI resume. 

I'd really like to resume the other CPU's much later (last in the whole 
sequnce, long after we've set up devices), but the f'ing ACPI rules seem 
to be against that. And maybe some setup actually needs the CPU's alive to 
act as a bridge for IO (eg with HT or CSI).

And interrupts happening at random times could certainly cause 
"interesting" and timing-dependent resume problems. Hmm...

The problem with the whole interrupt issue is that it seems to have 
nothing what-so-ever to do with the programming of that bridge in any way, 
shape or form. The timing issues/problems it could introduce should be 
totally irrelevant to anything else.

> I'd be happy to run with unpatched kernels for a while and do some more 
> pm_traces, but only if someone is going to follow up and interpret the 
> results for me or provide suggestions for targeted additional debugging.

I don't really have any better patches to try right now. But as usual, 
from everything I can see, the actual bridge setup itself should be 
totally irrelevant to the problem you see. Which is really irritating, 
since the only patches we _do_ have that seem to matter are purely about 
that bridge resource that shouldn't matter at all!

			Linus

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Rafael J. Wysocki]

On Thursday, 4 of December 2008, Linus Torvalds wrote:
> 
> On Thu, 4 Dec 2008, Rafael J. Wysocki wrote:
> > 
> > Well, in principle it may be related to the way we handle bridges during
> > resume
> 
> Ahh. Yes, that's possible. It's quite possible that the problem isn't 
> resource allocation per se, but just the bigger complexity at resume time.
> 
> This is a hibernate-only issue for you, right? Or is it about regular 
> suspend-to-ram too?

It is suspend to RAM too, from what I can tell.

> > but I really need to read some docs and compare them with the code 
> > before I can say anything more about that.  Surely, nothing like this 
> > issue has ever been reported before.
> 
> Well, how stable has hibernate been on that particular machine 
> historically?
> 
> Because the half-revert alignment patch (ie reverting part of 5f17cf) that 
> made it work for you would actually have been a non-issue in the original 
> code that was pre-PCI-resource-alignment cleanup (commit 88452565).
> 
> So the patch you partially reverted was literally the one that made the 
> Cardbus allocation work the _same_ way as it did historically, before 
> 88452565. So if the new code breaks for you, then so should the "old" code 
> (ie 2.6.25 and earlier).
> 
> So the "hasn't been reported before" case may well be just another way of 
> saying "hibernate has never been very reliable".

This is a new box and the kernels earlier than 2.6.27-rc3 have not been tested
on it.  So, in fact, it's quite possible that hibernation would fail on it with
earlier kernels as well.

Thanks,
Rafael

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Rafael J. Wysocki]

On Thursday, 4 of December 2008, Frans Pop wrote:
> On Wednesday 03 December 2008, Linus Torvalds wrote:
> > Well, I think that what _would_ be generally correct, and actually
> > pretty simple, is a rather different approach: just not sizing things
> > behind a transparent bridge AT ALL, since it really shouldn't matter.
> 
> I've given your patch a try and the few resumes from STR I've done were 
> all successful. That's not 100% conclusive yet, but a nice start.
> Some info from logs etc. below.

It doesn't help on my box, though.  I've got a failure to resume from
hibernation on the first attempt.

However, this one appears to work reliably for me (on top of vanilla current
mainline):

--- linux-2.6.orig/drivers/pci/setup-bus.c
+++ linux-2.6/drivers/pci/setup-bus.c
@@ -350,6 +350,11 @@ static int pbus_size_mem(struct pci_bus 
 
 			if (r->parent || (r->flags & mask) != type)
 				continue;
+
+			if ((dev->class >> 8) == PCI_CLASS_BRIDGE_CARDBUS
+			    && bus->self->transparent)
+				continue;
+
 			r_size = resource_size(r);
 			/* For bridges size != alignment */
 			align = resource_alignment(r);

> > > Also, I would be happy to actually understand _why_ this happens.
> >
> > 100% agreed. I do _not_ see why it should ever matter how we set up a
> > PCI bridging window - whether prefetchable or not - on a bridge that
> > should be transparent. It sounds really odd. I'm wondering if there is
> > something we're missing here.
> 
> The theory that it is really a resume issue and not a device layout issue 
> sounds logical. Especially as everything always works correctly after a 
> normal boot.

Well, in fact I'm pretty sure this is the case.  By changing memory address
space layout we effectively change conditions during suspend-resume and
apparently we can choose one for which the failure condition doesn't trigger
(or, IOW, the probability of it is _so_ small that we just can't see it).

There seems to be a race of some kind or a missing delay or something similar.

Thanks,
Rafael

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Linus Torvalds]

On Thu, 4 Dec 2008, Rafael J. Wysocki wrote:
> 
> However, this one appears to work reliably for me (on top of vanilla current
> mainline):

Not very interesting. It just does the same thing your previous patches 
have done - ignores the cardbus slot for sizing. It just does it 
differently and more explicitly.

Your original patch did it by simply giving the resources invalid 
alignments (in a very non-obvious way). This one does it by being explicit 
and saying "we won't care about cardbus resources behind transparent 
bridges". But it's still a very hacky thing, and thus not really 
interesting at all as a patch.

IOW, it's not a patch that makes sense - it's just a patch that ON YOUR 
PARTICULAR MACHINE causes us to get the layout you want in order to hide 
the bug. And it doesn't really even do anything new - it's just doing the 
same thing in an old way.

But it's interesting that the "don't size _anything_ behind a transparent 
bridge" apparently made no difference for you.

Can you send "lspci -vv" and "dmesg" output for that kernel? Even if it 
failed the suspend/resume, it's interesting, because I would actually have 
expected that one to have the same layout as the successful ones.

			Linus

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Rafael J. Wysocki]

On Thursday, 4 of December 2008, Linus Torvalds wrote:
> 
> On Thu, 4 Dec 2008, Frans Pop wrote:
> 
> > On Wednesday 03 December 2008, Linus Torvalds wrote:
> > > Well, I think that what _would_ be generally correct, and actually
> > > pretty simple, is a rather different approach: just not sizing things
> > > behind a transparent bridge AT ALL, since it really shouldn't matter.
> > 
> > I've given your patch a try and the few resumes from STR I've done were 
> > all successful. That's not 100% conclusive yet, but a nice start.
> > Some info from logs etc. below.
> 
> Ok, but I thought you had a hard time reproducing this _anyway_, even with 
> just plain -rc7. No?
> 
> That said, of the various patches posted, the "don't bother allocating 
> bridging windows for transparent bridges" one is not just the simplest, 
> but the only one that actually makes sense so far.
> 
> So I'm happy it's apparently working for you, I'm just wondering about 
> whather your success means a lot. It seems that Rafael is the one who had 
> more failures?

This most probably is correct and I got a resume failure with that patch
applied, so it evidently doesn't fix the problem. :-(

> > > > Also, I would be happy to actually understand _why_ this happens.
> > >
> > > 100% agreed. I do _not_ see why it should ever matter how we set up a
> > > PCI bridging window - whether prefetchable or not - on a bridge that
> > > should be transparent. It sounds really odd. I'm wondering if there is
> > > something we're missing here.
> > 
> > The theory that it is really a resume issue and not a device layout issue 
> > sounds logical. Especially as everything always works correctly after a 
> > normal boot.
> 
> Yes, that does sound like a convincing argument. Usually real PCI resource 
> clashes result in some kind of run-time problems, and wouldn't necessarily 
> be suspend-specific per se.
> 
> That said, suspend/resume does a lot of unusual things, so it could still 
> be some odd PCI resource clash that only triggers problems in the 
> suspend/resume case. But since the exact layouts and the sizing of the 
> resources doesn't really seem to matter, a simple PCI resource clash seems 
> rather unlikely.

I agree.

That said the "don't bother allocating bridging windows for transparent
bridges" patch resulted in the following layout on my box (from /proc/iomem):

88000000-8807ffff : 0000:00:02.1
88080000-88083fff : 0000:00:1b.0
  88080000-88083fff : ICH HD audio
88084000-88087fff : 0000:03:0b.1
88088000-88088fff : 0000:03:0b.0
  88088000-88088fff : yenta_socket
88089000-880897ff : 0000:03:0b.1
  88089000-880897ff : firewire_ohci
88089800-880898ff : 0000:03:0b.3
  88089800-880898ff : mmc0
8808a000-8808afff : Intel Flush Page
8c000000-8fffffff : PCI CardBus 0000:04
90000000-93ffffff : PCI CardBus 0000:04

while my "don't allocate bridging windows for cardbus bridges behind
transparent bridges" patch I've just sent (appended for easier reference)
results in the layout:

88000000-880fffff : PCI Bus 0000:03
  88000000-88003fff : 0000:03:0b.1
  88004000-88004fff : 0000:03:0b.0
    88004000-88004fff : yenta_socket
  88005000-880057ff : 0000:03:0b.1
    88005000-880057ff : firewire_ohci
  88005800-880058ff : 0000:03:0b.3
    88005800-880058ff : mmc0
88100000-8817ffff : 0000:00:02.1
88180000-88183fff : 0000:00:1b.0
  88180000-88183fff : ICH HD audio
88184000-88184fff : Intel Flush Page
8c000000-8fffffff : PCI CardBus 0000:04
90000000-93ffffff : PCI CardBus 0000:04

where devices behind the transparent bridge (PCI Bus 0000:03) are located
_before_ ICH HD audio in the memory address space, and this one appears to
work.  So there _may_ be an effect of the layout too.

> So some kind of resume-time ordering or timing issue does seem like the 
> most likely thing. But that still leaves us not knowing what the real 
> _root_ cause of this all is - very irritating. Even if not allocating the 
> unnecessary bridging windows "fixes" things, it would be really really 
> good to know exactly what it is that causes problems.

Well, given that both affected boxes have the same chipset (945GM), I seriously
suspect a nastiness in that chipset we're not aware of.  Especially that
the problem is not reproducible without snd_hda_intel (at least on my box).

> > Below info from 3 kernels, all based on 2.6.28-rc7-91:
> > A) unpatched
> > B) with the revert/debug patch
> > C) with the oneliner "ignore transparent bridges" patch
> > 
> > AFAICT all results are probably as expected.
> > 
> > From lspci -vvxxx:
> > 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge
> > - for A)
> > 	I/O behind bridge: 00003000-00003fff
> > 	Memory behind bridge: e0100000-e03fffff
> > 	Prefetchable memory behind bridge: 0000000080000000-0000000083ffffff
> > - for B)
> > 	I/O behind bridge: 00003000-00003fff
> > 	Memory behind bridge: e0100000-e03fffff
> > - for C)
> > 	Memory behind bridge: e0100000-e03fffff
> 
> And this all makes total sense. The e0100000-e03fffff MMIO bridge range is 
> apparently set up by the firmware, which is why it shows up in all cases. 
> And the (A) case has that prefetchable memory range, because that's the 
> only case that finds - and cares about - the prefetch window for the 
> CardBus controller. 
> 
> And both (A) and (B) have the IO bridging window, because regardless of 
> whether we see a valid CardBus prefetchable memory window with good 
> alignment, we'll always see the IO ports, so we'll try to allocate that 
> bridging window, except in (C) when we decide that due to the transparent 
> nature, we simply don't care.
> 
> So the PCI resources make sense in all three cases, and we understand 
> those. The differences in the actual Cardbus ranges also all make sense. 
> So it all still boils down to the PCI layer doing everything right in 
> _all_ cases, just making slightly different - but all valid - choices 
> depending on essentially random details (eg the revert/debug patch case 
> the "random detail" is just enabling a small incorrect alignment).
> 
> IOW, it really doesn't look like a PCI resource allocator bug. Quite the 
> reverse, I'd say that in the end this whole thread points out just how 
> robust the whole PCI and cardbus resource allocation is, with the code 
> really very gracefully just adjusting in a sane manner to all these 
> different cases.
> 
> Of course, none of that helps us with any kind of idea of what the real 
> problem is. Device ordering bug in setting up PCI resources at resume? 
> Perhaps just a plain bug in PCI bridge resume code (even when you resume 
> things in the right order)?
> 
> And I still worry that perhaps it's just a timing bug, where having a PCI 
> bridging window changes timing of various PCI accesses, and the _real_ bug 
> is actually in the sound card or ethernet driver resume, which happens to 
> work with one timing and not with another.
> 
> Since it's apparently STR, has anybody gotten _anything_ sane out of 
> trying to enable PM_TRACE_RTC, and then doing that 
> 
> 	echo 1 > /sys/power/pm_trace
> 
> because even with the (very limited) set of standard trace-points, it 
> should still be able to tell which device we were trying to resume last in 
> the failure case Maybe that gives some hint?

Well, I think more fine-grained debugging will be necessary.

I've already checked the resume ordering of PCI devices on my box and it
is the following:

pci:0000:00:00.0
pci:0000:00:02.0 <- graphics
pci:0000:00:02.1 <- graphics
pci:0000:00:1b.0 <- snd_hda_intel
pci:0000:00:1c.0 <- PCI Express port 1
pci:0000:00:1c.2 <- PCI Express port 3
pci:0000:00:1d.0 <- USB UHCI
pci:0000:00:1d.1 <- USB UHCI
pci:0000:00:1d.2 <- USB UHCI
pci:0000:00:1d.3 <- USB UHCI
pci:0000:00:1d.7 <- USB EHCI
pci:0000:00:1e.0 <- transparent bridge (Intel Corporation 82801 Mobile PCI Bridge)
pci:0000:00:1f.0 <- ISA bridge
pci:0000:00:1f.2 <- SATA (ahci)
pci:0000:01:00.0 <- e1000e
No Bus:0000:01
pci:0000:02:00.0 <- wireless (iwlagn)
No Bus:0000:02
pci:0000:03:0b.0 <- cardbus bridge
pci:0000:03:0b.1 <- FireWire
pci:0000:03:0b.3 <- SD Host controller (Texas Instruments)
No Bus:0000:04
No Bus:0000:03

So, snd_hda_intel resumes before all of the bridges and the layout of devices
_behind_ the transparent bridge shouldn't affect it at all.

Thanks,
Rafael

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Rafael J. Wysocki]

On Thursday, 4 of December 2008, Frans Pop wrote:
> On Thursday 04 December 2008, Linus Torvalds wrote:
> > On Thu, 4 Dec 2008, Frans Pop wrote:
> > > I've given your patch a try and the few resumes from STR I've done
> > > were all successful. That's not 100% conclusive yet, but a nice
> > > start. Some info from logs etc. below.
> >
> > Ok, but I thought you had a hard time reproducing this _anyway_, even
> > with just plain -rc7. No?
> 
> Well, I had a failure rate of about 1 in 5-10 resumes originally.
> See: http://bugzilla.kernel.org/show_bug.cgi?id=11545
> 
> Then I found the 2 workarounds and *with those in place* I got almost 100% 
> reliable resumes. Now I've removed those workarounds and with either the 
> revert or your oneliner I still get 100% success.
> From my PoV that is a very definite improvement: the machine now "feels" a 
> hell of a lot more reliable for critical use.
> 
> So I _could_ reproduce it reliably given enough suspend/resume cycles.
> But I guess this does support your suspicion that it may be a timing 
> issue: if the timing happens to be right, the resume succeeds; if it's 
> wrong I get a dead box.
> 
> > Since it's apparently STR, has anybody gotten _anything_ sane out of
> > trying to enable PM_TRACE_RTC, and then doing that
> >
> > 	echo 1 > /sys/power/pm_trace
> 
> I did try that at the beginning. That's how I ended up removing e1000e 
> before suspend. See http://bugzilla.kernel.org/show_bug.cgi?id=11545.
> 
> My next hint was that Matthew Garret, who has the same notebook, was 
> surprised at my resume problems as he did not see them. So I did a 
> comparison of our kernel configs and made some changes to mine. From
> that I found that a very low value for SND_HDA_POWER_SAVE_DEFAULT (5) 
> reduced the failure rate to practically zero.
> 
> At some point I tried keeping e1000e loaded for a bit, but that quickly 
> gave me a failure again, so I starting removing it again during suspend.
> 
> So I did have some data, but as I got no response on my BR I had no idea 
> where to go from there. I was really very happy to see Rafael's mail as 
> his description almost exactly matched what I had been seeing.
> 
> I'd be happy to run with unpatched kernels for a while and do some more 
> pm_traces, but only if someone is going to follow up and interpret the 
> results for me or provide suggestions for targeted additional debugging.

Please go for it, I'm very interested in understanding the underlying problem.

Thanks,
Rafael

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Linus Torvalds]

On Thu, 4 Dec 2008, Rafael J. Wysocki wrote:
> 
> That said the "don't bother allocating bridging windows for transparent
> bridges" patch resulted in the following layout on my box (from /proc/iomem):
> 
> 88000000-8807ffff : 0000:00:02.1
> 88080000-88083fff : 0000:00:1b.0
>   88080000-88083fff : ICH HD audio
> 88084000-88087fff : 0000:03:0b.1
> 88088000-88088fff : 0000:03:0b.0
>   88088000-88088fff : yenta_socket
> 88089000-880897ff : 0000:03:0b.1
>   88089000-880897ff : firewire_ohci
> 88089800-880898ff : 0000:03:0b.3
>   88089800-880898ff : mmc0
> 8808a000-8808afff : Intel Flush Page
> 8c000000-8fffffff : PCI CardBus 0000:04
> 90000000-93ffffff : PCI CardBus 0000:04
> 
> while my "don't allocate bridging windows for cardbus bridges behind
> transparent bridges" patch I've just sent (appended for easier reference)
> results in the layout:
> 
> 88000000-880fffff : PCI Bus 0000:03
>   88000000-88003fff : 0000:03:0b.1
>   88004000-88004fff : 0000:03:0b.0
>     88004000-88004fff : yenta_socket
>   88005000-880057ff : 0000:03:0b.1
>     88005000-880057ff : firewire_ohci
>   88005800-880058ff : 0000:03:0b.3
>     88005800-880058ff : mmc0
> 88100000-8817ffff : 0000:00:02.1
> 88180000-88183fff : 0000:00:1b.0
>   88180000-88183fff : ICH HD audio
> 88184000-88184fff : Intel Flush Page
> 8c000000-8fffffff : PCI CardBus 0000:04
> 90000000-93ffffff : PCI CardBus 0000:04

Well, this happens because in the second case, you still will allocate a 
non-prefetchable window due to the _other_ devices behind the bridge (ie 
the firewire and mmc device.

So with your "ignore cardbus device resources", you still do end up with a 
bridge window allocated, but now it will depend entirely on what other 
devices exist on that PCI bus. Which is why I really dislike that patch, 
because it really makes no sense at all. 

And once you've allocated the PCI bridge window, then the alignment 
requirements are that you end up having at least 1MB of window, and now 
because a window exists, and will fit, it will then happily put the yenta 
control mappings into that window even though it didn't size it for them.

See?

Also, notice how it doesn't put the actual cardbus bridge windows 
themselves into that PCI bridge window, because they won't fit. So these 
resources:

	8c000000-8fffffff : PCI CardBus 0000:04
	90000000-93ffffff : PCI CardBus 0000:04

are outside the window, even though that bus is topologically inside the 
same bus, and they both end up depending on the fact that the PCI bus 
controller is transparent.

So the above results are fairly easy to explain.

The _ordering_ difference comes simply from the allocation order. We'll do 
bus allocations first (if we do them), which is why _if_ we allocate a 
window for that PCI bus 03 (ie the one that is bridged to by 0:1e.0, that 
transparent bridge), then we'll end up allocating it first. So that's why 
the PCI bridge window shows up at 0x88000000, if it shows up at all 
(because that's the starting address for PCI allocations).

Then, we'll do the regular devices in the order we found them, so then 
we'll allocate the resources for device 0:02.1 and then 0:1b.0. Now, _if_ 
we did a bus window allocation, they'll end up being after the bus window 
we allocated. Otherwise they'll end up being the first allocations.

So then, by the time we actually get to bus#3, and devices 3:0b.*, where 
they end up is going to depend on whether we allocated that bus window (in 
which case they'll preferentially get allocated inside the window - ie 
starting at 0x88000000), or they'll just get allocated inside the parent 
(root) PCI bus. In the latter case they'll be allocated after the 0:02.1 
etc devices.

So the differences in ordering really do make sense, and are a direct 
consequence of whether we decided to need to allocate a bridging window 
for that PCI-PCI bridge at 0:1e.0.

Also note that _if_ PCI bus #3 had had other devices with prefetchable 
memory resources, then we'd have allocated a prefetchable window for 
those even with your patch, and then we'd have been back to the original 
allocation again (although sizing might cause changes, since your patch 
will make us ignore the cardbus controlle for sizing).

> where devices behind the transparent bridge (PCI Bus 0000:03) are located
> _before_ ICH HD audio in the memory address space, and this one appears to
> work.  So there _may_ be an effect of the layout too.

I do agree that your patch will affect layout. I just don't think it makes 
any real amount of sense because of how it essentially does so "randomly" 
depending on what other devices you'd have behind the transparent bridge.

Which is why I think we should either not size transparent bridges at all, 
or we should size _all_ the devices behind them.

Oh, btw, I thought your and Frans' laptops were identical? They don't seem 
to be: in Frans' case, the firmware does seem to set up one memory window, 
so he gets that one even with my "don't size anything" patch, just because 
we'll still honor allocations done by firmware.

> Well, given that both affected boxes have the same chipset (945GM), I seriously
> suspect a nastiness in that chipset we're not aware of.  Especially that
> the problem is not reproducible without snd_hda_intel (at least on my box).

Well, the counter-argument to that is that the 945GM should be a _very_ 
common chipset. So I'd not expect a chipset nastiness.

I'd be more wary about the BIOS doing something odd. Or an ACPI thing. 

> I've already checked the resume ordering of PCI devices on my box and it
> is the following:
>   [snip]
> So, snd_hda_intel resumes before all of the bridges and the layout of devices
> _behind_ the transparent bridge shouldn't affect it at all.

Yes. And in the case of Frans' machine, the e1000e controller was before 
all the bridges too.

		Linus

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Rafael J. Wysocki]

[-- Attachment #1: Type: text/plain, Size: 2336 bytes --]

On Thursday, 4 of December 2008, Linus Torvalds wrote:
> 
> On Thu, 4 Dec 2008, Rafael J. Wysocki wrote:
> > 
> > However, this one appears to work reliably for me (on top of vanilla current
> > mainline):
> 
> Not very interesting. It just does the same thing your previous patches 
> have done - ignores the cardbus slot for sizing. It just does it 
> differently and more explicitly.

There's a difference, though.  It doesn't cause the resources flags to be
cleared for the cardbus bridge and the cardbus bridge gets the correct sizes
of both prefetchable and non-prefetchable windows (64 MB).

> Your original patch did it by simply giving the resources invalid 
> alignments (in a very non-obvious way). This one does it by being explicit 
> and saying "we won't care about cardbus resources behind transparent 
> bridges". But it's still a very hacky thing, and thus not really 
> interesting at all as a patch.
> 
> IOW, it's not a patch that makes sense - it's just a patch that ON YOUR 
> PARTICULAR MACHINE causes us to get the layout you want in order to hide 
> the bug.

I know that. :-)  Still, I find it important to notice that the memory windows
of the cardbus bridge can be 64 MB-wide and things work in that case too.
Also, I like it more than the previous patch. ;-)

Moreover, I _think_ it would work for Frans too, because I _suspect_ the
problem is related to a cardbus bridge being located behind that "transparent"
thing somehow.

> And it doesn't really even do anything new - it's just doing the  
> same thing in an old way.
> 
> But it's interesting that the "don't size _anything_ behind a transparent 
> bridge" apparently made no difference for you.
> 
> Can you send "lspci -vv" and "dmesg" output for that kernel?

No prob, both attached along with the contents of /proc/iomem .

> Even if it failed the suspend/resume, it's interesting, because I would
> actually have expected that one to have the same layout as the successful
> ones. 

Well, not exactly.  Actually, with this patch the graphics and "ICH HD audio"
get their memory ranges before the ranges of _all_ devices behind the
transparent bridge, while in the "working" case their memory ranges are located
_after_ the memory ranges of devices behind the transparent bridge _except_
for the cardbus bridge's memory windows.

Thanks,
Rafael

[-- Attachment #2: dmesg.log --]
[-- Type: text/x-log, Size: 54515 bytes --]

[    0.000000] BIOS EBDA/lowmem at: 0009fc00/0009fc00
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Linux version 2.6.28-rc7-rjw (rafael@chimera) (gcc version 4.2.1 (SUSE Linux)) #57 SMP Thu Dec 4 23:55:55 CET 2008
[    0.000000] Command line: root=/dev/disk/by-id/scsi-SATA_Hitachi_HTS5425080611BB6300ACJRP5TG-part3 edd=off resume=/dev/sda2 vga=0x314
[    0.000000] KERNEL supported cpus:
[    0.000000]   Intel GenuineIntel
[    0.000000]   AMD AuthenticAMD
[    0.000000]   Centaur CentaurHauls
[    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: 00000000000e0000 - 00000000000eee00 (reserved)
[    0.000000]  BIOS-e820: 00000000000eee00 - 00000000000ef000 (ACPI NVS)
[    0.000000]  BIOS-e820: 00000000000ef000 - 0000000000100000 (reserved)
[    0.000000]  BIOS-e820: 0000000000100000 - 000000007f750000 (usable)
[    0.000000]  BIOS-e820: 000000007f750000 - 0000000080000000 (reserved)
[    0.000000]  BIOS-e820: 00000000fec00000 - 00000000fec18000 (reserved)
[    0.000000]  BIOS-e820: 00000000fec20000 - 00000000fec28000 (reserved)
[    0.000000]  BIOS-e820: 00000000fed00000 - 00000000fed00400 (reserved)
[    0.000000]  BIOS-e820: 00000000fed14000 - 00000000fed1a000 (reserved)
[    0.000000]  BIOS-e820: 00000000fed1c000 - 00000000fed90000 (reserved)
[    0.000000]  BIOS-e820: 00000000feda0000 - 00000000fedc0000 (reserved)
[    0.000000]  BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
[    0.000000]  BIOS-e820: 00000000ffa00000 - 00000000ffc00000 (reserved)
[    0.000000]  BIOS-e820: 00000000ffd00000 - 0000000100000000 (reserved)
[    0.000000] DMI 2.4 present.
[    0.000000] last_pfn = 0x7f750 max_arch_pfn = 0x3ffffffff
[    0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
[    0.000000] init_memory_mapping: 0000000000000000-000000007f750000
[    0.000000]  0000000000 - 007f600000 page 2M
[    0.000000]  007f600000 - 007f750000 page 4k
[    0.000000] kernel direct mapping tables up to 7f750000 @ 8000-c000
[    0.000000] last_map_addr: 7f750000 end: 7f750000
[    0.000000] RAMDISK: 37770000 - 37feff02
[    0.000000] ACPI: RSDP 000F0210, 0014 (r0 TOSHIB)
[    0.000000] ACPI: RSDT 7F750000, 004C (r1 TOSHIB A0058    20070822 TASM  4010000)
[    0.000000] ACPI: FACP 7F750078, 0084 (r2 TOSHIB A0058    20070822 TASM  4010000)
[    0.000000] ACPI: DSDT 7F7500FC, 5CA1 (r2 TOSHIB A0058    20070822 MSFT  100000E)
[    0.000000] ACPI: FACS 000EEE00, 0040
[    0.000000] ACPI: SSDT 7F755D9D, 0306 (r2 TOSHIB A0058    20060907 MSFT  100000E)
[    0.000000] ACPI: BOOT 7F750050, 0028 (r1 TOSHIB A0058    20070822 TASM  4010000)
[    0.000000] ACPI: APIC 7F756955, 0068 (r1 TOSHIB A0058    20070822 TASM  4010000)
[    0.000000] ACPI: MCFG 7F7569BD, 003C (r1 TOSHIB A0058    20070822 TASM  4010000)
[    0.000000] ACPI: HPET 7F756A2D, 0038 (r1 TOSHIB A0058    20070822 TASM  4010000)
[    0.000000] ACPI: TCPA 7F756A65, 0032 (r2 TOSHIB A0058    20070822 TASM  4010000)
[    0.000000] ACPI: SLIC 7F756A97, 0176 (r1 TOSHIB A0058    20070822 TASM  4010000)
[    0.000000] ACPI: SSDT 7F756C0D, 016C (r2 TOSHIB A0058    20070309 MSFT  100000E)
[    0.000000] ACPI: SSDT 7F7576BF, 0081 (r2 TOSHIB A0058    20060907 MSFT  100000E)
[    0.000000] ACPI: Local APIC address 0xfee00000
[    0.000000] (6 early reservations) ==> bootmem [0000000000 - 007f750000]
[    0.000000]   #0 [0000000000 - 0000001000]   BIOS data page ==> [0000000000 - 0000001000]
[    0.000000]   #1 [0000006000 - 0000008000]       TRAMPOLINE ==> [0000006000 - 0000008000]
[    0.000000]   #2 [0000200000 - 0000784d3c]    TEXT DATA BSS ==> [0000200000 - 0000784d3c]
[    0.000000]   #3 [0037770000 - 0037feff02]          RAMDISK ==> [0037770000 - 0037feff02]
[    0.000000]   #4 [000009fc00 - 0000100000]    BIOS reserved ==> [000009fc00 - 0000100000]
[    0.000000]   #5 [0000008000 - 000000a000]          PGTABLE ==> [0000008000 - 000000a000]
[    0.000000]  [ffffe20000000000-ffffe20001bfffff] PMD -> [ffff880001200000-ffff880002dfffff] on node 0
[    0.000000] Zone PFN ranges:
[    0.000000]   DMA      0x00000000 -> 0x00001000
[    0.000000]   DMA32    0x00001000 -> 0x00100000
[    0.000000]   Normal   0x00100000 -> 0x00100000
[    0.000000] Movable zone start PFN for each node
[    0.000000] early_node_map[2] active PFN ranges
[    0.000000]     0: 0x00000000 -> 0x0000009f
[    0.000000]     0: 0x00000100 -> 0x0007f750
[    0.000000] On node 0 totalpages: 521967
[    0.000000]   DMA zone: 56 pages used for memmap
[    0.000000]   DMA zone: 1513 pages reserved
[    0.000000]   DMA zone: 2430 pages, LIFO batch:0
[    0.000000]   DMA32 zone: 7082 pages used for memmap
[    0.000000]   DMA32 zone: 510886 pages, LIFO batch:31
[    0.000000]   Normal zone: 0 pages used for memmap
[    0.000000]   Movable zone: 0 pages used for memmap
[    0.000000] ACPI: PM-Timer IO Port: 0xd808
[    0.000000] ACPI: Local APIC address 0xfee00000
[    0.000000] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
[    0.000000] ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
[    0.000000] IOAPIC[0]: apic_id 1, version 0, address 0xfec00000, GSI 0-23
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[    0.000000] ACPI: IRQ0 used by override.
[    0.000000] ACPI: IRQ2 used by override.
[    0.000000] ACPI: IRQ9 used by override.
[    0.000000] ACPI: HPET id: 0x8086a201 base: 0xfed00000
[    0.000000] Using ACPI (MADT) for SMP configuration information
[    0.000000] SMP: Allowing 2 CPUs, 0 hotplug CPUs
[    0.000000] PM: Registered nosave memory: 000000000009f000 - 00000000000a0000
[    0.000000] PM: Registered nosave memory: 00000000000a0000 - 00000000000e0000
[    0.000000] PM: Registered nosave memory: 00000000000e0000 - 00000000000ee000
[    0.000000] PM: Registered nosave memory: 00000000000ee000 - 00000000000ef000
[    0.000000] PM: Registered nosave memory: 00000000000ef000 - 0000000000100000
[    0.000000] Allocating PCI resources starting at 88000000 (gap: 80000000:7ec00000)
[    0.000000] PERCPU: Allocating 45056 bytes of per cpu data
[    0.000000] NR_CPUS: 2, nr_cpu_ids: 2, nr_node_ids 1
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 513316
[    0.000000] Kernel command line: root=/dev/disk/by-id/scsi-SATA_Hitachi_HTS5425080611BB6300ACJRP5TG-part3 edd=off resume=/dev/sda2 vga=0x314
[    0.000000] Initializing CPU#0
[    0.000000] RCU-based detection of stalled CPUs is enabled.
[    0.000000] PID hash table entries: 4096 (order: 12, 32768 bytes)
[    0.000000] Fast TSC calibration using PIT
[    0.000000] Detected 1330.112 MHz processor.
[    0.004000] Console: colour dummy device 80x25
[    0.004000] console [tty0] enabled
[    0.004000] Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
[    0.004000] Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
[    0.004000] Checking aperture...
[    0.004000] No AGP bridge found
[    0.004000] Memory: 2040900k/2088256k available (2369k kernel code, 388k absent, 46340k reserved, 1741k data, 356k init)
[    0.004000] hpet clockevent registered
[    0.004000] HPET: 3 timers in total, 0 timers will be used for per-cpu timer
[    0.004000] Calibrating delay loop (skipped), value calculated using timer frequency.. 2660.22 BogoMIPS (lpj=5320448)
[    0.004000] Security Framework initialized
[    0.004000] Mount-cache hash table entries: 256
[    0.004000] CPU: L1 I cache: 32K, L1 D cache: 32K
[    0.004000] CPU: L2 cache: 2048K
[    0.004000] CPU: Physical Processor ID: 0
[    0.004000] CPU: Processor Core ID: 0
[    0.004000] CPU0: Thermal monitoring handled by SMI
[    0.004000] using mwait in idle threads.
[    0.004000] ACPI: Core revision 20080926
[    0.014425] Setting APIC routing to flat
[    0.014850] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
[    0.054558] CPU0: Intel(R) Core(TM)2 Duo CPU     U7700  @ 1.33GHz stepping 0d
[    0.056001] Booting processor 1 APIC 0x1 ip 0x6000
[    0.004000] Initializing CPU#1
[    0.004000] Calibrating delay using timer specific routine.. 2659.97 BogoMIPS (lpj=5319951)
[    0.004000] CPU: L1 I cache: 32K, L1 D cache: 32K
[    0.004000] CPU: L2 cache: 2048K
[    0.004000] CPU: Physical Processor ID: 0
[    0.004000] CPU: Processor Core ID: 1
[    0.004000] CPU1: Thermal monitoring enabled (TM2)
[    0.004000] x86 PAT enabled: cpu 1, old 0x7040600070406, new 0x7010600070106
[    0.141643] CPU1: Intel(R) Core(TM)2 Duo CPU     U7700  @ 1.33GHz stepping 0d
[    0.141709] checking TSC synchronization [CPU#0 -> CPU#1]: passed.
[    0.144033] Brought up 2 CPUs
[    0.144040] Total of 2 processors activated (5320.19 BogoMIPS).
[    0.144103] CPU0 attaching sched-domain:
[    0.144107]  domain 0: span 0-1 level MC
[    0.144111]   groups: 0 1
[    0.144119] CPU1 attaching sched-domain:
[    0.144121]  domain 0: span 0-1 level MC
[    0.144124]   groups: 1 0
[    0.144213] net_namespace: 1376 bytes
[    0.144297] Time: 23:00:06  Date: 12/04/08
[    0.144297] NET: Registered protocol family 16
[    0.144297] ACPI: bus type pci registered
[    0.144297] PCI: MCFG configuration 0: base f0000000 segment 0 buses 0 - 63
[    0.144297] PCI: Not using MMCONFIG.
[    0.144297] PCI: Using configuration type 1 for base access
[    0.149237] ACPI: EC: Look up EC in DSDT
[    0.154570] ACPI Warning (dsobject-0501): Package List length (C) larger than NumElements count (3), truncated
[    0.154584]  [20080926]
[    0.158240] ACPI: Interpreter enabled
[    0.158247] ACPI: (supports S0 S3 S4 S5)
[    0.158286] ACPI: Using IOAPIC for interrupt routing
[    0.158371] PCI: MCFG configuration 0: base f0000000 segment 0 buses 0 - 63
[    0.163833] PCI: MCFG area at f0000000 reserved in ACPI motherboard resources
[    0.168551] PCI: Using MMCONFIG at f0000000 - f3ffffff
[    0.181279] ACPI: ACPI Dock Station Driver: 1 docks/bays found
[    0.181308] ACPI: PCI Root Bridge [PCI0] (0000:00)
[    0.181353] pci 0000:00:02.0: reg 10 32bit mmio: [0xffc80000-0xffcfffff]
[    0.181353] pci 0000:00:02.0: reg 14 io port: [0xcff8-0xcfff]
[    0.181353] pci 0000:00:02.0: reg 18 32bit mmio: [0xe0000000-0xefffffff]
[    0.181353] pci 0000:00:02.0: reg 1c 32bit mmio: [0xffc40000-0xffc7ffff]
[    0.181353] pci 0000:00:02.1: reg 10 32bit mmio: [0x000000-0x07ffff]
[    0.181353] pci 0000:00:1b.0: reg 10 64bit mmio: [0x000000-0x003fff]
[    0.181353] pci 0000:00:1b.0: PME# supported from D0 D3hot D3cold
[    0.181353] pci 0000:00:1b.0: PME# disabled
[    0.181353] pci 0000:00:1c.0: PME# supported from D0 D3hot D3cold
[    0.181353] pci 0000:00:1c.0: PME# disabled
[    0.181353] pci 0000:00:1c.2: PME# supported from D0 D3hot D3cold
[    0.181353] pci 0000:00:1c.2: PME# disabled
[    0.181353] pci 0000:00:1d.0: reg 20 io port: [0xafe0-0xafff]
[    0.181353] pci 0000:00:1d.1: reg 20 io port: [0xaf80-0xaf9f]
[    0.181353] pci 0000:00:1d.2: reg 20 io port: [0xaf60-0xaf7f]
[    0.181353] pci 0000:00:1d.3: reg 20 io port: [0xaf40-0xaf5f]
[    0.181353] pci 0000:00:1d.7: reg 10 32bit mmio: [0xffc3fc00-0xffc3ffff]
[    0.181353] pci 0000:00:1d.7: PME# supported from D0 D3hot D3cold
[    0.181353] pci 0000:00:1d.7: PME# disabled
[    0.181353] pci 0000:00:1f.0: quirk: region d800-d87f claimed by ICH6 ACPI/GPIO/TCO
[    0.181353] pci 0000:00:1f.0: quirk: region eec0-eeff claimed by ICH6 GPIO
[    0.181353] pci 0000:00:1f.2: reg 10 io port: [0xaf38-0xaf3f]
[    0.181353] pci 0000:00:1f.2: reg 14 io port: [0xaf34-0xaf37]
[    0.181353] pci 0000:00:1f.2: reg 18 io port: [0xaf28-0xaf2f]
[    0.181356] pci 0000:00:1f.2: reg 1c io port: [0xaf24-0xaf27]
[    0.181366] pci 0000:00:1f.2: reg 20 io port: [0xaf10-0xaf1f]
[    0.181377] pci 0000:00:1f.2: reg 24 32bit mmio: [0xffc3f800-0xffc3fbff]
[    0.181402] pci 0000:00:1f.2: PME# supported from D3hot
[    0.181411] pci 0000:00:1f.2: PME# disabled
[    0.181523] pci 0000:01:00.0: reg 10 32bit mmio: [0xff9e0000-0xff9fffff]
[    0.181551] pci 0000:01:00.0: reg 18 io port: [0xbfe0-0xbfff]
[    0.181623] pci 0000:01:00.0: PME# supported from D0 D3hot D3cold
[    0.181636] pci 0000:01:00.0: PME# disabled
[    0.181696] pci 0000:01:00.0: disabling ASPM on pre-1.1 PCIe device.  You can enable it with 'pcie_aspm=force'
[    0.181766] pci 0000:00:1c.0: bridge io port: [0xb000-0xbfff]
[    0.181772] pci 0000:00:1c.0: bridge 32bit mmio: [0xff900000-0xff9fffff]
[    0.181942] pci 0000:02:00.0: reg 10 64bit mmio: [0xff8fe000-0xff8fffff]
[    0.182062] pci 0000:02:00.0: PME# supported from D0 D3hot D3cold
[    0.182093] pci 0000:02:00.0: PME# disabled
[    0.182550] pci 0000:00:1c.2: bridge 32bit mmio: [0xff800000-0xff8fffff]
[    0.184005] pci 0000:03:0b.0: reg 10 32bit mmio: [0x000000-0x000fff]
[    0.184020] pci 0000:03:0b.0: supports D1 D2
[    0.184023] pci 0000:03:0b.0: PME# supported from D0 D1 D2 D3hot
[    0.184033] pci 0000:03:0b.0: PME# disabled
[    0.184087] pci 0000:03:0b.1: reg 10 32bit mmio: [0x000000-0x0007ff]
[    0.184098] pci 0000:03:0b.1: reg 14 32bit mmio: [0x000000-0x003fff]
[    0.184149] pci 0000:03:0b.1: supports D1 D2
[    0.184152] pci 0000:03:0b.1: PME# supported from D0 D1 D2 D3hot
[    0.184162] pci 0000:03:0b.1: PME# disabled
[    0.184217] pci 0000:03:0b.3: reg 10 32bit mmio: [0x000000-0x0000ff]
[    0.184276] pci 0000:03:0b.3: supports D1 D2
[    0.184279] pci 0000:03:0b.3: PME# supported from D0 D1 D2 D3hot
[    0.184289] pci 0000:03:0b.3: PME# disabled
[    0.184346] pci 0000:00:1e.0: transparent bridge
[    0.184415] bus 00 -> node 0
[    0.184425] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
[    0.184750] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCIB._PRT]
[    0.185003] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX1._PRT]
[    0.185223] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.MPEX._PRT]
[    0.188573] ACPI: PCI Interrupt Link [LNKA] (IRQs *10)
[    0.192116] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 *11)
[    0.192410] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 *11)
[    0.192699] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 *11)
[    0.192987] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 *11)
[    0.193274] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 *11)
[    0.193562] ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 *11)
[    0.193850] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 *11)
[    0.193948] SCSI subsystem initialized
[    0.193948] PCI: Using ACPI for IRQ routing
[    0.208013] NetLabel: Initializing
[    0.208019] NetLabel:  domain hash size = 128
[    0.208024] NetLabel:  protocols = UNLABELED CIPSOv4
[    0.208058] NetLabel:  unlabeled traffic allowed by default
[    0.208090] PCI-GART: No AMD GART found.
[    0.208105] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0
[    0.208115] hpet0: 3 comparators, 64-bit 14.318180 MHz counter
[    0.228011] pnp: PnP ACPI init
[    0.228028] ACPI: bus type pnp registered
[    0.235698] pnp: PnP ACPI: found 12 devices
[    0.235706] ACPI: ACPI bus type pnp unregistered
[    0.235724] system 00:00: iomem range 0x0-0x9ffff could not be reserved
[    0.235732] system 00:00: iomem range 0xe0000-0xfffff could not be reserved
[    0.235741] system 00:00: iomem range 0x100000-0x7f74ffff could not be reserved
[    0.235750] system 00:00: iomem range 0x7f750000-0x7f75ffff has been reserved
[    0.235758] system 00:00: iomem range 0x7f760000-0x7f7fffff has been reserved
[    0.235766] system 00:00: iomem range 0x7f800000-0x7fffffff has been reserved
[    0.235774] system 00:00: iomem range 0xfec00000-0xfec17fff has been reserved
[    0.235783] system 00:00: iomem range 0xfec20000-0xfec27fff has been reserved
[    0.235791] system 00:00: iomem range 0xfed14000-0xfed19fff has been reserved
[    0.235799] system 00:00: iomem range 0xfed1c000-0xfed1ffff has been reserved
[    0.235807] system 00:00: iomem range 0xfed20000-0xfed3ffff has been reserved
[    0.235815] system 00:00: iomem range 0xfed45000-0xfed8ffff has been reserved
[    0.235823] system 00:00: iomem range 0xfeda0000-0xfedbffff has been reserved
[    0.235831] system 00:00: iomem range 0xfee00000-0xfee00fff has been reserved
[    0.235839] system 00:00: iomem range 0xffa00000-0xffbfffff has been reserved
[    0.235848] system 00:00: iomem range 0xffd00000-0xffffffff has been reserved
[    0.235860] system 00:01: iomem range 0xf0000000-0xf3ffffff has been reserved
[    0.235876] system 00:09: ioport range 0x1e0-0x1ef has been reserved
[    0.235884] system 00:09: ioport range 0x480-0x48f has been reserved
[    0.235891] system 00:09: ioport range 0xe000-0xe07f has been reserved
[    0.235899] system 00:09: ioport range 0xe080-0xe0ff has been reserved
[    0.235907] system 00:09: ioport range 0xe400-0xe47f has been reserved
[    0.235914] system 00:09: ioport range 0xe480-0xe4ff has been reserved
[    0.235922] system 00:09: ioport range 0xe800-0xe87f has been reserved
[    0.235930] system 00:09: ioport range 0xe880-0xe8ff has been reserved
[    0.235937] system 00:09: ioport range 0xec00-0xec7f has been reserved
[    0.235945] system 00:09: ioport range 0xec80-0xecff has been reserved
[    0.235953] system 00:09: ioport range 0xd800-0xd87f has been reserved
[    0.235960] system 00:09: ioport range 0xd880-0xd89f has been reserved
[    0.235968] system 00:09: ioport range 0xeeb0-0xeebf has been reserved
[    0.235976] system 00:09: ioport range 0xeec0-0xeeff has been reserved
[    0.235984] system 00:09: ioport range 0x690-0x6ff has been reserved
[    0.235994] system 00:09: ioport range 0x4d0-0x4d1 has been reserved
[    0.241200] pci 0000:00:1c.0: PCI bridge, secondary bus 0000:01
[    0.241210] pci 0000:00:1c.0:   IO window: 0xb000-0xbfff
[    0.241221] pci 0000:00:1c.0:   MEM window: 0xff900000-0xff9fffff
[    0.241231] pci 0000:00:1c.0:   PREFETCH window: disabled
[    0.241245] pci 0000:00:1c.2: PCI bridge, secondary bus 0000:02
[    0.241251] pci 0000:00:1c.2:   IO window: disabled
[    0.241262] pci 0000:00:1c.2:   MEM window: 0xff800000-0xff8fffff
[    0.241272] pci 0000:00:1c.2:   PREFETCH window: disabled
[    0.241307] pci 0000:03:0b.0: CardBus bridge, secondary bus 0000:04
[    0.241314] pci 0000:03:0b.0:   IO window: 0x001000-0x0010ff
[    0.241324] pci 0000:03:0b.0:   IO window: 0x001400-0x0014ff
[    0.241333] pci 0000:03:0b.0:   PREFETCH window: 0x8c000000-0x8fffffff
[    0.241344] pci 0000:03:0b.0:   MEM window: 0x90000000-0x93ffffff
[    0.241354] pci 0000:00:1e.0: PCI bridge, secondary bus 0000:03
[    0.241360] pci 0000:00:1e.0:   IO window: disabled
[    0.241371] pci 0000:00:1e.0:   MEM window: disabled
[    0.241380] pci 0000:00:1e.0:   PREFETCH window: disabled
[    0.241406] pci 0000:00:1c.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
[    0.241418] pci 0000:00:1c.0: setting latency timer to 64
[    0.241430] pci 0000:00:1c.2: PCI INT C -> GSI 18 (level, low) -> IRQ 18
[    0.241441] pci 0000:00:1c.2: setting latency timer to 64
[    0.241451] pci 0000:00:1e.0: setting latency timer to 64
[    0.241462] pci 0000:03:0b.0: enabling device (0000 -> 0003)
[    0.241472] pci 0000:03:0b.0: PCI INT A -> GSI 21 (level, low) -> IRQ 21
[    0.241485] bus: 00 index 0 io port: [0x00-0xffff]
[    0.241492] bus: 00 index 1 mmio: [0x000000-0xffffffffffffffff]
[    0.241499] bus: 01 index 0 io port: [0xb000-0xbfff]
[    0.241505] bus: 01 index 1 mmio: [0xff900000-0xff9fffff]
[    0.241511] bus: 01 index 2 mmio: [0x0-0x0]
[    0.241516] bus: 01 index 3 mmio: [0x0-0x0]
[    0.241521] bus: 02 index 0 mmio: [0x0-0x0]
[    0.241527] bus: 02 index 1 mmio: [0xff800000-0xff8fffff]
[    0.241533] bus: 02 index 2 mmio: [0x0-0x0]
[    0.241538] bus: 02 index 3 mmio: [0x0-0x0]
[    0.241543] bus: 03 index 0 mmio: [0x0-0x0]
[    0.241548] bus: 03 index 1 mmio: [0x0-0x0]
[    0.241553] bus: 03 index 2 mmio: [0x0-0x0]
[    0.241558] bus: 03 index 3 io port: [0x00-0xffff]
[    0.241564] bus: 03 index 4 mmio: [0x000000-0xffffffffffffffff]
[    0.241571] bus: 04 index 0 io port: [0x1000-0x10ff]
[    0.241577] bus: 04 index 1 io port: [0x1400-0x14ff]
[    0.241583] bus: 04 index 2 mmio: [0x8c000000-0x8fffffff]
[    0.241589] bus: 04 index 3 mmio: [0x90000000-0x93ffffff]
[    0.241632] NET: Registered protocol family 2
[    0.280082] IP route cache hash table entries: 65536 (order: 7, 524288 bytes)
[    0.280646] TCP established hash table entries: 262144 (order: 10, 4194304 bytes)
[    0.283847] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
[    0.284834] TCP: Hash tables configured (established 262144 bind 65536)
[    0.284843] TCP reno registered
[    0.296131] NET: Registered protocol family 1
[    0.296308] checking if image is initramfs...<7>Switched to high resolution mode on CPU 1
[    0.503972] Switched to high resolution mode on CPU 0
[    0.783076]  it is
[    1.298597] Freeing initrd memory: 8703k freed
[    1.305128] Simple Boot Flag value 0xb read from CMOS RAM was invalid
[    1.305142] Simple Boot Flag at 0x7c set to 0x1
[    1.306461] audit: initializing netlink socket (disabled)
[    1.306491] type=2000 audit(1228431607.305:1): initialized
[    1.306856] HugeTLB registered 2 MB page size, pre-allocated 0 pages
[    1.307036] VFS: Disk quotas dquot_6.5.1
[    1.307086] Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[    1.307189] msgmni has been set to 4004
[    1.307464] alg: No test for stdrng (krng)
[    1.307481] io scheduler noop registered
[    1.307488] io scheduler anticipatory registered
[    1.307494] io scheduler deadline registered
[    1.307518] io scheduler cfq registered (default)
[    1.308057] pci 0000:00:02.0: Boot video device
[    1.313171] pcieport-driver 0000:00:1c.0: setting latency timer to 64
[    1.313229] pcieport-driver 0000:00:1c.0: found MSI capability
[    1.313280] pcieport-driver 0000:00:1c.0: irq 319 for MSI/MSI-X
[    1.313301] pci_express 0000:00:1c.0:pcie00: allocate port service
[    1.313360] pci_express 0000:00:1c.0:pcie03: allocate port service
[    1.313589] pcieport-driver 0000:00:1c.2: setting latency timer to 64
[    1.313647] pcieport-driver 0000:00:1c.2: found MSI capability
[    1.313799] pcieport-driver 0000:00:1c.2: irq 318 for MSI/MSI-X
[    1.313819] pci_express 0000:00:1c.2:pcie00: allocate port service
[    1.313874] pci_express 0000:00:1c.2:pcie03: allocate port service
[    1.314399] vesafb: framebuffer at 0xe0000000, mapped to 0xffffc20004100000, using 1875k, total 7872k
[    1.314410] vesafb: mode is 800x600x16, linelength=1600, pages=7
[    1.314416] vesafb: scrolling: redraw
[    1.314422] vesafb: Truecolor: size=0:5:6:5, shift=0:11:5:0
[    1.327854] Console: switching to colour frame buffer device 100x37
[    1.338710] fb0: VESA VGA frame buffer device
[    1.353232] Non-volatile memory driver v1.2
[    1.353428] Linux agpgart interface v0.103
[    1.353588] Serial: 8250/16550 driver4 ports, IRQ sharing disabled
[    1.356635] brd: module loaded
[    1.356889] PNP: PS/2 Controller [PNP0303:KBC,PNP0f13:PS2M] at 0x60,0x64 irq 1,12
[    1.362155] serio: i8042 KBD port at 0x60,0x64 irq 1
[    1.364006] serio: i8042 AUX port at 0x60,0x64 irq 12
[    1.365933] mice: PS/2 mouse device common for all mice
[    1.367995] input: PC Speaker as /class/input/input0
[    1.378485] input: AT Translated Set 2 keyboard as /class/input/input1
[    1.397117] cpuidle: using governor ladder
[    1.399494] cpuidle: using governor menu
[    1.402721] registered taskstats version 1
[    1.405441]   Magic number: 4:738:48
[    1.408226] Freeing unused kernel memory: 356k freed
[    1.411246] Write protecting the kernel read-only data: 3820k
[    1.471233] ACPI: SSDT 7F7563E5, 00F3 (r2 TOSHIB A0058    20060907 MSFT  100000E)
[    1.475513] ACPI: SSDT 7F75654E, 034E (r2 TOSHIB A0058    20060907 MSFT  100000E)
[    1.479893] ACPI: CPU0 (power states: C1[C1] C2[C2] C3[C3])
[    1.483809] processor ACPI_CPU:00: registered as cooling_device0
[    1.488084] ACPI: SSDT 7F7564D8, 0076 (r2 TOSHIB A0058    20060907 MSFT  100000E)
[    1.492875] ACPI: SSDT 7F75689C, 0079 (r2 TOSHIB A0058    20060907 MSFT  100000E)
[    1.497917] ACPI: CPU1 (power states: C1[C1] C2[C2] C3[C3])
[    1.502467] processor ACPI_CPU:01: registered as cooling_device1
[    1.506447] Marking TSC unstable due to TSC halts in idle
[    1.516663] thermal LNXTHERM:01: registered as thermal_zone0
[    1.521930] ACPI: Thermal Zone [THRM] (66 C)
[    1.547500] libata version 3.00 loaded.
[    1.552220] ahci 0000:00:1f.2: version 3.0
[    1.552249] ahci 0000:00:1f.2: PCI INT B -> GSI 19 (level, low) -> IRQ 19
[    1.557597] ahci 0000:00:1f.2: irq 317 for MSI/MSI-X
[    1.557685] ahci 0000:00:1f.2: AHCI 0001.0100 32 slots 4 ports 1.5 Gbps 0x1 impl SATA mode
[    1.562910] ahci 0000:00:1f.2: flags: 64bit ncq pm led clo pio slum part 
[    1.568215] ahci 0000:00:1f.2: setting latency timer to 64
[    1.568408] scsi0 : ahci
[    1.573773] scsi1 : ahci
[    1.578904] scsi2 : ahci
[    1.583949] scsi3 : ahci
[    1.589196] ata1: SATA max UDMA/133 irq_stat 0x00400040, connection status changed irq 317
[    1.594142] ata2: DUMMY
[    1.599067] ata3: DUMMY
[    1.603817] ata4: DUMMY
[    2.000172] Clocksource tsc unstable (delta = -385447840 ns)
[    2.332153] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[    2.337822] ACPI Error (nspredef-0163): \_SB_.PCI0.FNC2.PRT0._GTF: Missing expected return value [20080926]
[    2.348206] ata1.00: ATA-8: Hitachi HTS542516K9SA00, BBCOC33P, max UDMA/133
[    2.353573] ata1.00: 312581808 sectors, multi 0: LBA48 NCQ (depth 31/32)
[    2.360202] ata1.00: configured for UDMA/133
[    2.380464] scsi 0:0:0:0: Direct-Access     ATA      Hitachi HTS54251 BBCO PQ: 0 ANSI: 5
[    2.414442] BIOS EDD facility v0.16 2004-Jun-25, 0 devices found
[    2.419900] EDD information not available.
[    2.725174] usbcore: registered new interface driver usbfs
[    2.731201] usbcore: registered new interface driver hub
[    2.733432] Driver 'sd' needs updating - please use bus_type methods
[    2.733590] sd 0:0:0:0: [sda] 312581808 512-byte hardware sectors: (160 GB/149 GiB)
[    2.733614] sd 0:0:0:0: [sda] Write Protect is off
[    2.733618] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[    2.733656] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[    2.733749] sd 0:0:0:0: [sda] 312581808 512-byte hardware sectors: (160 GB/149 GiB)
[    2.733771] sd 0:0:0:0: [sda] Write Protect is off
[    2.733774] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[    2.733812] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[    2.733816]  sda: sda1 sda2 sda3 sda4 < sda5<6>usbcore: registered new device driver usb
[    2.799812] uhci_hcd: USB Universal Host Controller Interface driver
[    2.803584] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    2.803642] ehci_hcd 0000:00:1d.7: PCI INT A -> GSI 23 (level, low) -> IRQ 23
[    2.819116] ehci_hcd 0000:00:1d.7: setting latency timer to 64
[    2.819122] ehci_hcd 0000:00:1d.7: EHCI Host Controller
[    2.825507]  sda6<6>ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 1
[    2.839762] ehci_hcd 0000:00:1d.7: debug port 1
[    2.846456] ehci_hcd 0000:00:1d.7: cache line size of 32 is not supported
[    2.846479]  sda7 >
[    2.853306] sd 0:0:0:0: [sda] Attached SCSI disk
[    2.860085] ehci_hcd 0000:00:1d.7: irq 23, io mem 0xffc3fc00
[    2.884044] ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00
[    2.890788] usb usb1: configuration #1 chosen from 1 choice
[    2.897207] hub 1-0:1.0: USB hub found
[    2.903664] hub 1-0:1.0: 8 ports detected
[    2.909999] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[    2.916314] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    2.922437] usb usb1: Product: EHCI Host Controller
[    2.928492] usb usb1: Manufacturer: Linux 2.6.28-rc7-rjw ehci_hcd
[    2.928494] usb usb1: SerialNumber: 0000:00:1d.7
[    2.932071] uhci_hcd 0000:00:1d.0: PCI INT A -> GSI 23 (level, low) -> IRQ 23
[    2.932085] uhci_hcd 0000:00:1d.0: setting latency timer to 64
[    2.932090] uhci_hcd 0000:00:1d.0: UHCI Host Controller
[    2.932141] uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 2
[    2.932182] uhci_hcd 0000:00:1d.0: irq 23, io base 0x0000afe0
[    2.932339] usb usb2: configuration #1 chosen from 1 choice
[    2.932386] hub 2-0:1.0: USB hub found
[    2.932395] hub 2-0:1.0: 2 ports detected
[    2.932533] usb usb2: New USB device found, idVendor=1d6b, idProduct=0001
[    2.932536] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    2.932539] usb usb2: Product: UHCI Host Controller
[    2.932541] usb usb2: Manufacturer: Linux 2.6.28-rc7-rjw uhci_hcd
[    2.932543] usb usb2: SerialNumber: 0000:00:1d.0
[    2.932574] uhci_hcd 0000:00:1d.1: PCI INT B -> GSI 19 (level, low) -> IRQ 19
[    2.932582] uhci_hcd 0000:00:1d.1: setting latency timer to 64
[    2.932586] uhci_hcd 0000:00:1d.1: UHCI Host Controller
[    2.932619] uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 3
[    2.932670] uhci_hcd 0000:00:1d.1: irq 19, io base 0x0000af80
[    2.932788] usb usb3: configuration #1 chosen from 1 choice
[    2.932828] hub 3-0:1.0: USB hub found
[    2.932837] hub 3-0:1.0: 2 ports detected
[    2.932968] usb usb3: New USB device found, idVendor=1d6b, idProduct=0001
[    2.932971] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    2.932974] usb usb3: Product: UHCI Host Controller
[    2.932976] usb usb3: Manufacturer: Linux 2.6.28-rc7-rjw uhci_hcd
[    2.932978] usb usb3: SerialNumber: 0000:00:1d.1
[    2.933005] uhci_hcd 0000:00:1d.2: PCI INT C -> GSI 18 (level, low) -> IRQ 18
[    2.933013] uhci_hcd 0000:00:1d.2: setting latency timer to 64
[    2.933017] uhci_hcd 0000:00:1d.2: UHCI Host Controller
[    2.933049] uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 4
[    2.933092] uhci_hcd 0000:00:1d.2: irq 18, io base 0x0000af60
[    2.933212] usb usb4: configuration #1 chosen from 1 choice
[    2.933252] hub 4-0:1.0: USB hub found
[    2.933261] hub 4-0:1.0: 2 ports detected
[    2.933391] usb usb4: New USB device found, idVendor=1d6b, idProduct=0001
[    2.933394] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    2.933397] usb usb4: Product: UHCI Host Controller
[    2.933399] usb usb4: Manufacturer: Linux 2.6.28-rc7-rjw uhci_hcd
[    2.933401] usb usb4: SerialNumber: 0000:00:1d.2
[    2.933432] uhci_hcd 0000:00:1d.3: PCI INT D -> GSI 16 (level, low) -> IRQ 16
[    2.933440] uhci_hcd 0000:00:1d.3: setting latency timer to 64
[    2.933444] uhci_hcd 0000:00:1d.3: UHCI Host Controller
[    2.933483] uhci_hcd 0000:00:1d.3: new USB bus registered, assigned bus number 5
[    2.933526] uhci_hcd 0000:00:1d.3: irq 16, io base 0x0000af40
[    2.933641] usb usb5: configuration #1 chosen from 1 choice
[    2.933685] hub 5-0:1.0: USB hub found
[    2.933693] hub 5-0:1.0: 2 ports detected
[    2.933829] usb usb5: New USB device found, idVendor=1d6b, idProduct=0001
[    2.933832] usb usb5: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    2.933835] usb usb5: Product: UHCI Host Controller
[    2.933837] usb usb5: Manufacturer: Linux 2.6.28-rc7-rjw uhci_hcd
[    2.933839] usb usb5: SerialNumber: 0000:00:1d.3
[    3.461236] PM: Starting manual resume from disk
[    3.628069] usb 1-4: new high speed USB device using ehci_hcd and address 4
[    3.766296] usb 1-4: configuration #1 chosen from 1 choice
[    3.774690] usb 1-4: New USB device found, idVendor=0930, idProduct=0c05
[    3.781178] usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[    3.787119] usb 1-4: Product: Optical Drive Controller
[    3.792932] usb 1-4: Manufacturer: TOSHIBA
[    3.855769] kjournald starting.  Commit interval 5 seconds
[    3.862448] EXT3 FS on sda3, internal journal
[    3.868884] EXT3-fs: mounted filesystem with ordered data mode.
[    4.148124] usb 2-2: new full speed USB device using uhci_hcd and address 2
[    4.317422] usb 2-2: configuration #1 chosen from 1 choice
[    4.335436] usb 2-2: New USB device found, idVendor=0930, idProduct=1302
[    4.342122] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=2
[    4.348852] usb 2-2: Product: Novatel Wireless HSDPA Modem
[    4.355510] usb 2-2: Manufacturer: Novatel Wireless
[    4.362125] usb 2-2: SerialNumber: Novatel Wireless HSDPA Modem
[    4.608065] usb 3-1: new full speed USB device using uhci_hcd and address 2
[    4.777838] usb 3-1: configuration #1 chosen from 1 choice
[    4.786985] usb 3-1: New USB device found, idVendor=08ff, idProduct=1600
[    4.793693] usb 3-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[    4.800401] usb 3-1: Product: Fingerprint Sensor
[    5.044063] usb 4-1: new full speed USB device using uhci_hcd and address 2
[    5.225297] usb 4-1: configuration #1 chosen from 1 choice
[    5.237431] usb 4-1: New USB device found, idVendor=046d, idProduct=c526
[    5.243894] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[    5.250257] usb 4-1: Product: USB Receiver
[    5.256375] usb 4-1: Manufacturer: Logitech
[    6.910048] sd 0:0:0:0: Attached scsi generic sg0 type 0
[    7.086238] iTCO_vendor_support: vendor-support=0
[    7.221463] ACPI Warning (nspredef-0858): \_SB_.BAT1._BIF: Return Package type mismatch at index 12 - found Integer, expected String/Buffer [20080926]
[    7.233732] ACPI: Battery Slot [BAT1] (battery present)
[    7.241393] input: Power Button (FF) as /class/input/input2
[    7.261012] ACPI: AC Adapter [ADP1] (on-line)
[    7.284152] ACPI: Power Button (FF) [PWRF]
[    7.290161] input: Lid Switch as /class/input/input3
[    7.308268] ACPI: Lid Switch [LID]
[    7.314191] input: Power Button (CM) as /class/input/input4
[    7.330658] e1000e: Intel(R) PRO/1000 Network Driver - 0.3.3.3-k6
[    7.336353] e1000e: Copyright (c) 1999-2008 Intel Corporation.
[    7.342666] e1000e 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[    7.348572] e1000e 0000:01:00.0: setting latency timer to 64
[    7.348871] e1000e 0000:01:00.0: irq 316 for MSI/MSI-X
[    7.369154] ACPI: Power Button (CM) [PWRB]
[    7.380199] cfg80211: Calling CRDA to update world regulatory domain
[    7.409338] e1000e 0000:01:00.0: Warning: detected ASPM enabled in EEPROM
[    7.472822] 0000:01:00.0: eth0: (PCI Express:2.5GB/s:Width x1) 00:1c:7e:af:dd:ac
[    7.478447] 0000:01:00.0: eth0: Intel(R) PRO/1000 Network Connection
[    7.484235] 0000:01:00.0: eth0: MAC: 2, PHY: 2, PBA No: ffffff-0ff
[    7.509464] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.04
[    7.515348] iTCO_wdt: Found a ICH7-M or ICH7-U TCO device (Version=2, TCOBASE=0xd860)
[    7.521224] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)
[    7.531674] agpgart-intel 0000:00:00.0: Intel 945GM Chipset
[    7.538278] agpgart-intel 0000:00:00.0: detected 7932K stolen memory
[    7.547561] agpgart-intel 0000:00:00.0: AGP aperture is 256M @ 0xe0000000
[    7.700568] Initializing USB Mass Storage driver...
[    7.708456] scsi4 : SCSI emulation for USB Mass Storage devices
[    7.714637] usbcore: registered new interface driver usb-storage
[    7.720799] USB Mass Storage support registered.
[    7.720975] usb-storage: device found at 4
[    7.720977] usb-storage: waiting for device to settle before scanning
[    7.726997] input: PS/2 Mouse as /class/input/input5
[    7.795742] input: AlpsPS/2 ALPS GlidePoint as /class/input/input6
[    7.925834] rtc_cmos 00:08: RTC can wake from S4
[    7.931808] rtc_cmos 00:08: rtc core: registered rtc_cmos as rtc0
[    7.938495] rtc0: alarms up to one year, 114 bytes nvram, hpet irqs
[    8.748797] yenta_cardbus 0000:03:0b.0: CardBus bridge found [1179:0001]
[    8.754473] yenta_cardbus 0000:03:0b.0: Enabling burst memory read transactions
[    8.760298] yenta_cardbus 0000:03:0b.0: Using CSCINT to route CSC interrupts to PCI
[    8.765927] yenta_cardbus 0000:03:0b.0: Routing CardBus interrupts to PCI
[    8.771566] yenta_cardbus 0000:03:0b.0: TI: mfunc 0x01aa1022, devctl 0x64
[    8.794719] usbcore: registered new interface driver hiddev
[    8.803607] input: Logitech USB Receiver as /class/input/input7
[    8.840166] generic-usb 0003:046D:C526.0001: input,hidraw0: USB HID v1.11 Mouse [Logitech USB Receiver] on usb-0000:00:1d.2-1/input0
[    8.857322] input: Logitech USB Receiver as /class/input/input8
[    8.885028] acpi device:0a: registered as cooling_device2
[    8.891840] input: Video Bus as /class/input/input9
[    8.900251] generic-usb 0003:046D:C526.0002: input,hiddev0,hidraw1: USB HID v1.11 Device [Logitech USB Receiver] on usb-0000:00:1d.2-1/input1
[    8.912591] usbcore: registered new interface driver usbhid
[    8.918943] usbhid: v2.6:USB HID core driver
[    8.946265] sdhci: Secure Digital Host Controller Interface driver
[    8.952289] sdhci: Copyright(c) Pierre Ossman
[    8.952425] ACPI: Video Device [VGA] (multi-head: yes  rom: yes  post: no)
[    9.032874] yenta_cardbus 0000:03:0b.0: ISA IRQ mask 0x0cf8, PCI irq 21
[    9.039193] yenta_cardbus 0000:03:0b.0: Socket status: 30000006
[    9.045169] pci_bus 0000:03: Raising subordinate bus# of parent bus (#03) from #04 to #07
[    9.065819] firewire_ohci 0000:03:0b.1: enabling device (0000 -> 0002)
[    9.072353] firewire_ohci 0000:03:0b.1: PCI INT B -> GSI 20 (level, low) -> IRQ 20
[    9.152069] firewire_ohci: Added fw-ohci device 0000:03:0b.1, OHCI version 1.10
[    9.158403] sdhci-pci 0000:03:0b.3: SDHCI controller found [104c:803c] (rev 0)
[    9.164857] sdhci-pci 0000:03:0b.3: enabling device (0000 -> 0002)
[    9.171094] sdhci-pci 0000:03:0b.3: PCI INT D -> GSI 23 (level, low) -> IRQ 23
[    9.172574] toshiba_acpi: Toshiba Laptop ACPI Extras version 0.19
[    9.172577] toshiba_acpi:     HCI method: \_SB_.VALZ.GHCI
[    9.187726] input: Toshiba RFKill Switch as /class/input/input10
[    9.218430] mmc0: SDHCI controller on PCI [0000:03:0b.3] using DMA
[    9.551971] HDA Intel 0000:00:1b.0: power state changed by ACPI to D0
[    9.558305] HDA Intel 0000:00:1b.0: enabling device (0000 -> 0002)
[    9.564851] HDA Intel 0000:00:1b.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22
[    9.571358] HDA Intel 0000:00:1b.0: setting latency timer to 64
[    9.656214] firewire_core: created device fw0: GUID 0000390000be012e, S400
[    9.680080] usb 5-2: new full speed USB device using uhci_hcd and address 2
[    9.872681] iwlagn: Intel(R) Wireless WiFi Link AGN driver for Linux, 1.3.27ks
[    9.878934] iwlagn: Copyright(c) 2003-2008 Intel Corporation
[    9.879130] usb 5-2: configuration #1 chosen from 1 choice
[    9.891964] iwlagn 0000:02:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
[    9.892354] usb 5-2: New USB device found, idVendor=0930, idProduct=0508
[    9.892358] usb 5-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[    9.911106] iwlagn 0000:02:00.0: setting latency timer to 64
[    9.914819] iwlagn: Detected Intel Wireless WiFi Link 4965AGN REV=0x4
[    9.971524] iwlagn: Tunable channels: 13 802.11bg, 19 802.11a channels
[    9.977853] iwlagn 0000:02:00.0: PCI INT A disabled
[    9.984485] phy0: Selected rate control algorithm 'iwl-agn-rs'
[   10.249982] Bluetooth: Core ver 2.13
[   10.258034] NET: Registered protocol family 31
[   10.263837] Bluetooth: HCI device and connection manager initialized
[   10.269873] Bluetooth: HCI socket layer initialized
[   10.578379] Bluetooth: Generic Bluetooth USB driver ver 0.3
[   10.584301] usbcore: registered new interface driver btusb
[   11.520616] Bluetooth: L2CAP ver 2.11
[   11.526480] Bluetooth: L2CAP socket layer initialized
[   11.563289] Bluetooth: RFCOMM socket layer initialized
[   11.569021] Bluetooth: RFCOMM TTY layer initialized
[   11.574616] Bluetooth: RFCOMM ver 1.10
[   11.674873] Adding 4200988k swap on /dev/sda2.  Priority:-1 extents:1 across:4200988k
[   12.716152] isa bounce pool size: 16 pages
[   12.722950] scsi 4:0:0:0: CD-ROM            MATSHITA DVD-RAM UJ-844S  1.10 PQ: 0 ANSI: 0
[   12.729928] scsi 4:0:0:0: Attached scsi generic sg1 type 5
[   12.743701] usb-storage: device scan complete
[   12.808924] Driver 'sr' needs updating - please use bus_type methods
[   12.822035] sr0: scsi3-mmc drive: 24x/24x writer dvd-ram cd/rw xa/form2 cdda tray
[   12.828086] Uniform CD-ROM driver Revision: 3.20
[   12.834121] sr 4:0:0:0: Attached scsi CD-ROM sr0
[   13.531610] device-mapper: uevent: version 1.0.3
[   13.538112] device-mapper: ioctl: 4.14.0-ioctl (2008-04-23) initialised: dm-devel@redhat.com
[   15.022438] loop: module loaded
[   15.066028] kjournald starting.  Commit interval 5 seconds
[   15.066299] EXT3 FS on sda7, internal journal
[   15.066306] EXT3-fs: mounted filesystem with ordered data mode.
[   15.111438] kjournald starting.  Commit interval 5 seconds
[   15.111703] EXT3 FS on sda6, internal journal
[   15.111708] EXT3-fs: mounted filesystem with ordered data mode.
[   15.179126] kjournald starting.  Commit interval 5 seconds
[   15.179408] EXT3 FS on sda5, internal journal
[   15.179413] EXT3-fs: mounted filesystem with ordered data mode.
[   15.373458] fuse init (API version 7.10)
[   19.313397] platform microcode: firmware: requesting intel-ucode/06-0f-0d
[   19.388051] platform microcode: firmware: requesting intel-ucode/06-0f-0d
[   19.398786] Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
[   20.285818] NET: Registered protocol family 10
[   20.291080] lo: Disabled Privacy Extensions
[   20.643977] ip6_tables: (C) 2000-2006 Netfilter Core Team
[   21.067004] ip_tables: (C) 2000-2006 Netfilter Core Team
[   21.515617] nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
[   21.522388] CONFIG_NF_CT_ACCT is deprecated and will be removed soon. Please use
[   21.527818] nf_conntrack.acct=1 kernel paramater, acct=1 nf_conntrack module option or
[   21.533190] sysctl net.netfilter.nf_conntrack_acct=1 to enable it.
[   22.066794] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[   22.072350] Bluetooth: BNEP filters: protocol multicast
[   24.959113] BIOS EDD facility v0.16 2004-Jun-25, 0 devices found
[   24.959117] EDD information not available.
[   28.017836] e1000e 0000:01:00.0: irq 316 for MSI/MSI-X
[   28.073159] e1000e 0000:01:00.0: irq 316 for MSI/MSI-X
[   28.076079] ADDRCONF(NETDEV_UP): eth0: link is not ready
[   28.086868] iwlagn 0000:02:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
[   28.087006] iwlagn 0000:02:00.0: restoring config space at offset 0x1 (was 0x100002, writing 0x100006)
[   28.087172] iwlagn 0000:02:00.0: irq 315 for MSI/MSI-X
[   28.087299] iwlagn 0000:02:00.0: firmware: requesting iwlwifi-4965-2.ucode
[   28.457373] Registered led device: iwl-phy0:radio
[   28.458072] Registered led device: iwl-phy0:assoc
[   28.462528] Registered led device: iwl-phy0:RX
[   28.462605] Registered led device: iwl-phy0:TX
[   28.506242] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[   28.824609] NET: Registered protocol family 17
[   34.537881] [drm] Initialized drm 1.1.0 20060810
[   34.621165] pci 0000:00:02.0: power state changed by ACPI to D0
[   34.621183] pci 0000:00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[   34.621192] pci 0000:00:02.0: setting latency timer to 64
[   34.621597] [drm] Initialized i915 1.6.0 20080730 on minor 0
[   37.648145] evdev.c(EVIOCGBIT): Suspicious buffer size 511, limiting output to 64 bytes. See http://userweb.kernel.org/~dtor/eviocgbit-bug.html
[  457.782731] CPU0 attaching NULL sched-domain.
[  457.782742] CPU1 attaching NULL sched-domain.
[  457.793186] CPU0 attaching sched-domain:
[  457.793194]  domain 0: span 0-1 level MC
[  457.793199]   groups: 0 1
[  457.793208]   domain 1: span 0-1 level CPU
[  457.793213]    groups: 0-1
[  457.793222] CPU1 attaching sched-domain:
[  457.793227]  domain 0: span 0-1 level MC
[  457.793231]   groups: 1 0
[  457.793238]   domain 1: span 0-1 level CPU
[  457.793243]    groups: 0-1
[  458.838671] wlan0: direct probe to AP 00:1d:7e:aa:87:ee try 1
[  458.843799] wlan0 direct probe responded
[  458.843809] wlan0: authenticate with AP 00:1d:7e:aa:87:ee
[  458.845708] wlan0: authenticated
[  458.845718] wlan0: associate with AP 00:1d:7e:aa:87:ee
[  458.848476] wlan0: RX AssocResp from 00:1d:7e:aa:87:ee (capab=0x411 status=0 aid=1)
[  458.848482] wlan0: associated
[  458.877940] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[  462.725909] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC= SRC=192.168.100.100 DST=224.0.0.251 LEN=64 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353 DPT=5353 LEN=44 
[  462.877927] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC= SRC=192.168.100.100 DST=224.0.0.251 LEN=468 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353 DPT=5353 LEN=448 
[  462.928382] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC= SRC=192.168.100.100 DST=224.0.0.251 LEN=242 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353 DPT=5353 LEN=222 
[  463.128769] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC= SRC=192.168.100.100 DST=224.0.0.251 LEN=468 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353 DPT=5353 LEN=448 
[  463.379176] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC= SRC=192.168.100.100 DST=224.0.0.251 LEN=468 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353 DPT=5353 LEN=448 
[  468.956114] wlan0: no IPv6 routers present
[  469.730168] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC= SRC=192.168.100.100 DST=224.0.0.251 LEN=64 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353 DPT=5353 LEN=44 
[  470.608643] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=01:00:5e:00:00:01:00:1d:7e:aa:87:ee:08:00 SRC=192.168.100.254 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=1 ID=6211 PROTO=2 
[  477.735086] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC= SRC=192.168.100.100 DST=224.0.0.251 LEN=64 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353 DPT=5353 LEN=44 
[  480.733900] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=01:00:5e:00:00:01:00:1d:7e:aa:87:ee:08:00 SRC=62.121.83.254 DST=224.0.0.1 LEN=28 TOS=0x00 PREC=0xC0 TTL=1 ID=34144 PROTO=2 
[  493.748617] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC= SRC=192.168.100.100 DST=224.0.0.251 LEN=64 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353 DPT=5353 LEN=44 
[  525.760640] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC= SRC=192.168.100.100 DST=224.0.0.251 LEN=64 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353 DPT=5353 LEN=44 
[  531.279188] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=01:00:5e:00:00:01:00:1d:7e:aa:87:ee:08:00 SRC=192.168.100.254 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=1 ID=6233 PROTO=2 
[  535.222619] CE: hpet increasing min_delta_ns to 15000 nsec
[  540.934330] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=01:00:5e:00:00:01:00:1d:7e:aa:87:ee:08:00 SRC=62.121.83.254 DST=224.0.0.1 LEN=28 TOS=0x00 PREC=0xC0 TTL=1 ID=37454 PROTO=2 
[  589.780169] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC= SRC=192.168.100.100 DST=224.0.0.251 LEN=64 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353 DPT=5353 LEN=44 
[  591.189410] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=01:00:5e:00:00:01:00:1d:7e:aa:87:ee:08:00 SRC=192.168.100.254 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=1 ID=6270 PROTO=2 
[  601.072925] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=01:00:5e:00:00:01:00:1d:7e:aa:87:ee:08:00 SRC=62.121.83.254 DST=224.0.0.1 LEN=28 TOS=0x00 PREC=0xC0 TTL=1 ID=41154 PROTO=2 
[  608.068229] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=00:1f:3b:c3:38:e7:00:1d:7e:aa:87:ee:08:00 SRC=192.168.100.254 DST=192.168.100.100 LEN=78 TOS=0x00 PREC=0x00 TTL=64 ID=6271 PROTO=UDP SPT=2224 DPT=137 LEN=58 
[  619.154128] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=00:1f:3b:c3:38:e7:00:1d:7e:aa:87:ee:08:00 SRC=192.168.100.254 DST=192.168.100.100 LEN=78 TOS=0x00 PREC=0x00 TTL=64 ID=6282 PROTO=UDP SPT=2224 DPT=137 LEN=58 
[  629.164217] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=00:1f:3b:c3:38:e7:00:1d:7e:aa:87:ee:08:00 SRC=192.168.100.254 DST=192.168.100.100 LEN=78 TOS=0x00 PREC=0x00 TTL=64 ID=6283 PROTO=UDP SPT=2225 DPT=137 LEN=58 
[  631.551246] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=00:1f:3b:c3:38:e7:00:1d:7e:aa:87:ee:08:00 SRC=192.168.100.254 DST=192.168.100.100 LEN=78 TOS=0x00 PREC=0x00 TTL=64 ID=6284 PROTO=UDP SPT=2225 DPT=137 LEN=58 
[  638.804178] CE: hpet increasing min_delta_ns to 22500 nsec
[  643.846962] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=00:1f:3b:c3:38:e7:00:1d:7e:aa:87:ee:08:00 SRC=192.168.100.254 DST=192.168.100.100 LEN=78 TOS=0x00 PREC=0x00 TTL=64 ID=6295 PROTO=UDP SPT=2225 DPT=137 LEN=58 
[  650.259141] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=00:1f:3b:c3:38:e7:00:1d:7e:aa:87:ee:08:00 SRC=192.168.100.254 DST=192.168.100.100 LEN=78 TOS=0x00 PREC=0x00 TTL=64 ID=6296 PROTO=UDP SPT=2226 DPT=137 LEN=58 
[  656.194406] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=00:1f:3b:c3:38:e7:00:1d:7e:aa:87:ee:08:00 SRC=192.168.100.254 DST=192.168.100.100 LEN=78 TOS=0x00 PREC=0x00 TTL=64 ID=6298 PROTO=UDP SPT=2226 DPT=137 LEN=58 
[  668.622210] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=00:1f:3b:c3:38:e7:00:1d:7e:aa:87:ee:08:00 SRC=192.168.100.254 DST=192.168.100.100 LEN=78 TOS=0x00 PREC=0x00 TTL=64 ID=6309 PROTO=UDP SPT=2226 DPT=137 LEN=58 
[  711.018111] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=01:00:5e:00:00:01:00:1d:7e:aa:87:ee:08:00 SRC=192.168.100.254 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=1 ID=6320 PROTO=2 
[  717.847346] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC= SRC=192.168.100.100 DST=224.0.0.251 LEN=64 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353 DPT=5353 LEN=44 
[  721.378919] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=01:00:5e:00:00:01:00:1d:7e:aa:87:ee:08:00 SRC=62.121.83.254 DST=224.0.0.1 LEN=28 TOS=0x00 PREC=0xC0 TTL=1 ID=49397 PROTO=2 
[  771.777958] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=01:00:5e:00:00:01:00:1d:7e:aa:87:ee:08:00 SRC=192.168.100.254 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=1 ID=6359 PROTO=2 
[  781.797633] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=01:00:5e:00:00:01:00:1d:7e:aa:87:ee:08:00 SRC=62.121.83.254 DST=224.0.0.1 LEN=28 TOS=0x00 PREC=0xC0 TTL=1 ID=52938 PROTO=2 
[  797.932181] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=00:1f:3b:c3:38:e7:00:1d:7e:aa:87:ee:08:00 SRC=192.168.100.254 DST=192.168.100.100 LEN=78 TOS=0x00 PREC=0x00 TTL=64 ID=6370 PROTO=UDP SPT=2230 DPT=137 LEN=58 
[  803.982015] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=00:1f:3b:c3:38:e7:00:1d:7e:aa:87:ee:08:00 SRC=192.168.100.254 DST=192.168.100.100 LEN=78 TOS=0x00 PREC=0x00 TTL=64 ID=6371 PROTO=UDP SPT=2230 DPT=137 LEN=58 
[  816.428242] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=00:1f:3b:c3:38:e7:00:1d:7e:aa:87:ee:08:00 SRC=192.168.100.254 DST=192.168.100.100 LEN=78 TOS=0x00 PREC=0x00 TTL=64 ID=6382 PROTO=UDP SPT=2230 DPT=137 LEN=58 
[  819.032711] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=00:1f:3b:c3:38:e7:00:1d:7e:aa:87:ee:08:00 SRC=192.168.100.254 DST=192.168.100.100 LEN=78 TOS=0x00 PREC=0x00 TTL=64 ID=6383 PROTO=UDP SPT=2231 DPT=137 LEN=58 
[  828.810006] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=00:1f:3b:c3:38:e7:00:1d:7e:aa:87:ee:08:00 SRC=192.168.100.254 DST=192.168.100.100 LEN=78 TOS=0x00 PREC=0x00 TTL=64 ID=6384 PROTO=UDP SPT=2231 DPT=137 LEN=58 
[  831.689495] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=01:00:5e:00:00:01:00:1d:7e:aa:87:ee:08:00 SRC=192.168.100.254 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=1 ID=6385 PROTO=2 
[  840.127230] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=00:1f:3b:c3:38:e7:00:1d:7e:aa:87:ee:08:00 SRC=192.168.100.254 DST=192.168.100.100 LEN=78 TOS=0x00 PREC=0x00 TTL=64 ID=6386 PROTO=UDP SPT=2232 DPT=137 LEN=58 
[  841.128815] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=00:1f:3b:c3:38:e7:00:1d:7e:aa:87:ee:08:00 SRC=192.168.100.254 DST=192.168.100.100 LEN=78 TOS=0x00 PREC=0x00 TTL=64 ID=6397 PROTO=UDP SPT=2232 DPT=137 LEN=58 
[  892.444899] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=01:00:5e:00:00:01:00:1d:7e:aa:87:ee:08:00 SRC=192.168.100.254 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=1 ID=6419 PROTO=2 
[  902.129978] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=01:00:5e:00:00:01:00:1d:7e:aa:87:ee:08:00 SRC=62.121.83.254 DST=224.0.0.1 LEN=28 TOS=0x00 PREC=0xC0 TTL=1 ID=60532 PROTO=2 
[  952.360345] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=01:00:5e:00:00:01:00:1d:7e:aa:87:ee:08:00 SRC=192.168.100.254 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=1 ID=6440 PROTO=2 
[  962.200380] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=01:00:5e:00:00:01:00:1d:7e:aa:87:ee:08:00 SRC=62.121.83.254 DST=224.0.0.1 LEN=28 TOS=0x00 PREC=0xC0 TTL=1 ID=63631 PROTO=2 
[  973.927221] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC= SRC=192.168.100.100 DST=224.0.0.251 LEN=64 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353 DPT=5353 LEN=44 
[ 1012.275976] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=01:00:5e:00:00:01:00:1d:7e:aa:87:ee:08:00 SRC=192.168.100.254 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=1 ID=6461 PROTO=2 
[ 1022.283353] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=01:00:5e:00:00:01:00:1d:7e:aa:87:ee:08:00 SRC=62.121.83.254 DST=224.0.0.1 LEN=28 TOS=0x00 PREC=0xC0 TTL=1 ID=16577 PROTO=2 
[ 1072.187524] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=01:00:5e:00:00:01:00:1d:7e:aa:87:ee:08:00 SRC=192.168.100.254 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=1 ID=6492 PROTO=2 
[ 1082.294164] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=01:00:5e:00:00:01:00:1d:7e:aa:87:ee:08:00 SRC=62.121.83.254 DST=224.0.0.1 LEN=28 TOS=0x00 PREC=0xC0 TTL=1 ID=20510 PROTO=2 
[ 1132.103381] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=01:00:5e:00:00:01:00:1d:7e:aa:87:ee:08:00 SRC=192.168.100.254 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=1 ID=6513 PROTO=2 
[ 1142.424284] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=01:00:5e:00:00:01:00:1d:7e:aa:87:ee:08:00 SRC=62.121.83.254 DST=224.0.0.1 LEN=28 TOS=0x00 PREC=0xC0 TTL=1 ID=23675 PROTO=2 
[ 1192.861176] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=01:00:5e:00:00:01:00:1d:7e:aa:87:ee:08:00 SRC=192.168.100.254 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=1 ID=6534 PROTO=2 
[ 1202.990844] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=01:00:5e:00:00:01:00:1d:7e:aa:87:ee:08:00 SRC=62.121.83.254 DST=224.0.0.1 LEN=28 TOS=0x00 PREC=0xC0 TTL=1 ID=27461 PROTO=2 
[ 1253.620878] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=01:00:5e:00:00:01:00:1d:7e:aa:87:ee:08:00 SRC=192.168.100.254 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=1 ID=6565 PROTO=2 
[ 1263.273181] SFW2-INext-DROP-DEFLT IN=wlan0 OUT= MAC=01:00:5e:00:00:01:00:1d:7e:aa:87:ee:08:00 SRC=62.121.83.254 DST=224.0.0.1 LEN=28 TOS=0x00 PREC=0xC0 TTL=1 ID=30511 PROTO=2 

[-- Attachment #3: lspci-vv.txt --]
[-- Type: text/plain, Size: 18833 bytes --]

00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub (rev 03)
	Subsystem: Toshiba America Info Systems Device 0001
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ >SERR- <PERR- INTx-
	Latency: 0
	Capabilities: [e0] Vendor Specific Information <?>
	Kernel driver in use: agpgart-intel
	Kernel modules: intel-agp

00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03) (prog-if 00 [VGA controller])
	Subsystem: Toshiba America Info Systems Device 0022
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin A routed to IRQ 16
	Region 0: Memory at ffc80000 (32-bit, non-prefetchable) [size=512K]
	Region 1: I/O ports at cff8 [size=8]
	Region 2: Memory at e0000000 (32-bit, prefetchable) [size=256M]
	Region 3: Memory at ffc40000 (32-bit, non-prefetchable) [size=256K]
	Capabilities: [90] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable-
		Address: 00000000  Data: 0000
	Capabilities: [d0] Power Management version 2
		Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Kernel modules: intelfb

00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03)
	Subsystem: Toshiba America Info Systems Device 0022
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Region 0: Memory at 88000000 (32-bit, non-prefetchable) [disabled] [size=512K]
	Capabilities: [d0] Power Management version 2
		Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 02)
	Subsystem: Toshiba America Info Systems Device 0001
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 32 bytes
	Interrupt: pin A routed to IRQ 22
	Region 0: Memory at 88080000 (64-bit, non-prefetchable) [size=16K]
	Capabilities: [50] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [60] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable-
		Address: 0000000000000000  Data: 0000
	Capabilities: [70] Express (v1) Root Complex Integrated Endpoint, MSI 00
		DevCap:	MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
			ExtTag- RBE- FLReset-
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+
			MaxPayload 128 bytes, MaxReadReq 128 bytes
		DevSta:	CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
		LnkCap:	Port #0, Speed unknown, Width x0, ASPM unknown, Latency L0 <64ns, L1 <1us
			ClockPM- Suprise- LLActRep- BwNot-
		LnkCtl:	ASPM Disabled; Disabled- Retrain- CommClk-
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed unknown, Width x0, TrErr- Train- SlotClk- DLActive- BWMgmt- ABWMgmt-
	Capabilities: [100] Virtual Channel <?>
	Capabilities: [130] Root Complex Link <?>
	Kernel driver in use: HDA Intel
	Kernel modules: snd-hda-intel

00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 02) (prog-if 00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 32 bytes
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
	I/O behind bridge: 0000b000-0000bfff
	Memory behind bridge: ff900000-ff9fffff
	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
	BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
	Capabilities: [40] Express (v1) Root Port (Slot-), MSI 00
		DevCap:	MaxPayload 128 bytes, PhantFunc 0, Latency L0s unlimited, L1 unlimited
			ExtTag- RBE- FLReset-
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
			MaxPayload 128 bytes, MaxReadReq 128 bytes
		DevSta:	CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
		LnkCap:	Port #1, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <256ns, L1 <4us
			ClockPM- Suprise- LLActRep+ BwNot-
		LnkCtl:	ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt- ABWMgmt-
		RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible-
		RootCap: CRSVisible-
		RootSta: PME ReqID 0000, PMEStatus- PMEPending-
	Capabilities: [80] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable+
		Address: fee0300c  Data: 4161
	Capabilities: [90] Subsystem: Toshiba America Info Systems Device 0001
	Capabilities: [a0] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [100] Virtual Channel <?>
	Capabilities: [180] Root Complex Link <?>
	Kernel driver in use: pcieport-driver
	Kernel modules: shpchp

00:1c.2 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 3 (rev 02) (prog-if 00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 32 bytes
	Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
	Memory behind bridge: ff800000-ff8fffff
	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
	BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
	Capabilities: [40] Express (v1) Root Port (Slot-), MSI 00
		DevCap:	MaxPayload 128 bytes, PhantFunc 0, Latency L0s unlimited, L1 unlimited
			ExtTag- RBE- FLReset-
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
			MaxPayload 128 bytes, MaxReadReq 128 bytes
		DevSta:	CorrErr+ UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
		LnkCap:	Port #3, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <256ns, L1 <4us
			ClockPM- Suprise- LLActRep+ BwNot-
		LnkCtl:	ASPM L0s L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk+
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt- ABWMgmt-
		RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible-
		RootCap: CRSVisible-
		RootSta: PME ReqID 0000, PMEStatus- PMEPending-
	Capabilities: [80] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable+
		Address: fee0300c  Data: 4169
	Capabilities: [90] Subsystem: Toshiba America Info Systems Device 0001
	Capabilities: [a0] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [100] Virtual Channel <?>
	Capabilities: [180] Root Complex Link <?>
	Kernel driver in use: pcieport-driver
	Kernel modules: shpchp

00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 (rev 02) (prog-if 00 [UHCI])
	Subsystem: Toshiba America Info Systems Device 0001
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin A routed to IRQ 23
	Region 4: I/O ports at afe0 [size=32]
	Kernel driver in use: uhci_hcd
	Kernel modules: uhci-hcd

00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 (rev 02) (prog-if 00 [UHCI])
	Subsystem: Toshiba America Info Systems Device 0001
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin B routed to IRQ 19
	Region 4: I/O ports at af80 [size=32]
	Kernel driver in use: uhci_hcd
	Kernel modules: uhci-hcd

00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 (rev 02) (prog-if 00 [UHCI])
	Subsystem: Toshiba America Info Systems Device 0001
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin C routed to IRQ 18
	Region 4: I/O ports at af60 [size=32]
	Kernel driver in use: uhci_hcd
	Kernel modules: uhci-hcd

00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #4 (rev 02) (prog-if 00 [UHCI])
	Subsystem: Toshiba America Info Systems Device 0001
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin D routed to IRQ 16
	Region 4: I/O ports at af40 [size=32]
	Kernel driver in use: uhci_hcd
	Kernel modules: uhci-hcd

00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 02) (prog-if 20 [EHCI])
	Subsystem: Toshiba America Info Systems Device 0001
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin A routed to IRQ 23
	Region 0: Memory at ffc3fc00 (32-bit, non-prefetchable) [size=1K]
	Capabilities: [50] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [58] Debug port: BAR=1 offset=00a0
	Kernel driver in use: ehci_hcd
	Kernel modules: ehci-hcd

00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2) (prog-if 01 [Subtractive decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Bus: primary=00, secondary=03, subordinate=07, sec-latency=32
	Secondary status: 66MHz- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
	BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
	Capabilities: [50] Subsystem: Toshiba America Info Systems Device 0001

00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 02)
	Subsystem: Toshiba America Info Systems Device 0001
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Capabilities: [e0] Vendor Specific Information <?>
	Kernel modules: iTCO_wdt

00:1f.2 SATA controller: Intel Corporation 82801GBM/GHM (ICH7 Family) SATA AHCI Controller (rev 02) (prog-if 01 [AHCI 1.0])
	Subsystem: Toshiba America Info Systems Device 0001
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin B routed to IRQ 317
	Region 0: I/O ports at af38 [size=8]
	Region 1: I/O ports at af34 [size=4]
	Region 2: I/O ports at af28 [size=8]
	Region 3: I/O ports at af24 [size=4]
	Region 4: I/O ports at af10 [size=16]
	Region 5: Memory at ffc3f800 (32-bit, non-prefetchable) [size=1K]
	Capabilities: [80] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable+
		Address: fee0300c  Data: 4179
	Capabilities: [70] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Kernel driver in use: ahci
	Kernel modules: ahci

01:00.0 Ethernet controller: Intel Corporation 82573L Gigabit Ethernet Controller
	Subsystem: Toshiba America Info Systems Device 0001
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 316
	Region 0: Memory at ff9e0000 (32-bit, non-prefetchable) [size=128K]
	Region 2: I/O ports at bfe0 [size=32]
	Capabilities: [c8] Power Management version 2
		Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=1 PME-
	Capabilities: [d0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable+
		Address: 00000000fee0100c  Data: 41b1
	Capabilities: [e0] Express (v1) Endpoint, MSI 00
		DevCap:	MaxPayload 256 bytes, PhantFunc 0, Latency L0s <512ns, L1 <64us
			ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset-
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
			MaxPayload 128 bytes, MaxReadReq 512 bytes
		DevSta:	CorrErr- UncorrErr+ FatalErr- UnsuppReq+ AuxPwr+ TransPend-
		LnkCap:	Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <128ns, L1 <64us
			ClockPM+ Suprise- LLActRep- BwNot-
		LnkCtl:	ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
			ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
	Capabilities: [100] Advanced Error Reporting <?>
	Capabilities: [140] Device Serial Number ac-dd-af-ff-ff-7e-1c-00
	Kernel driver in use: e1000e
	Kernel modules: e1000e

02:00.0 Network controller: Intel Corporation PRO/Wireless 4965 AG or AGN Network Connection (rev 61)
	Subsystem: Intel Corporation Device 1101
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 32 bytes
	Interrupt: pin A routed to IRQ 315
	Region 0: Memory at ff8fe000 (64-bit, non-prefetchable) [size=8K]
	Capabilities: [c8] Power Management version 3
		Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [d0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable+
		Address: 00000000fee0300c  Data: 41b9
	Capabilities: [e0] Express (v1) Endpoint, MSI 00
		DevCap:	MaxPayload 128 bytes, PhantFunc 0, Latency L0s <512ns, L1 unlimited
			ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
			MaxPayload 128 bytes, MaxReadReq 128 bytes
		DevSta:	CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr+ TransPend-
		LnkCap:	Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <128ns, L1 <64us
			ClockPM+ Suprise- LLActRep- BwNot-
		LnkCtl:	ASPM L0s L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk+
			ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
	Capabilities: [100] Advanced Error Reporting <?>
	Capabilities: [140] Device Serial Number e7-38-c3-ff-ff-3b-1f-00
	Kernel driver in use: iwlagn
	Kernel modules: iwlagn

03:0b.0 CardBus bridge: Texas Instruments PCIxx12 Cardbus Controller
	Subsystem: Toshiba America Info Systems Device 0001
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 168, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 21
	Region 0: Memory at 88088000 (32-bit, non-prefetchable) [size=4K]
	Bus: primary=03, secondary=04, subordinate=07, sec-latency=176
	Memory window 0: 8c000000-8ffff000 (prefetchable)
	Memory window 1: 90000000-93fff000
	I/O window 0: 00001000-000010ff
	I/O window 1: 00001400-000014ff
	BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset+ 16bInt+ PostWrite+
	16-bit legacy interface ports at 0001
	Kernel driver in use: yenta_cardbus
	Kernel modules: yenta_socket

03:0b.1 FireWire (IEEE 1394): Texas Instruments PCIxx12 OHCI Compliant IEEE 1394 Host Controller (prog-if 10 [OHCI])
	Subsystem: Toshiba America Info Systems Device 0001
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 64 (500ns min, 1000ns max), Cache Line Size: 32 bytes
	Interrupt: pin B routed to IRQ 20
	Region 0: Memory at 88089000 (32-bit, non-prefetchable) [size=2K]
	Region 1: Memory at 88084000 (32-bit, non-prefetchable) [size=16K]
	Capabilities: [44] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME+
	Kernel driver in use: firewire_ohci
	Kernel modules: firewire-ohci

03:0b.3 SD Host controller: Texas Instruments PCIxx12 SDA Standard Compliant SD Host Controller (prog-if 01)
	Subsystem: Toshiba America Info Systems Device 0001
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 64 (1750ns min, 1000ns max), Cache Line Size: 32 bytes
	Interrupt: pin D routed to IRQ 23
	Region 0: Memory at 88089800 (32-bit, non-prefetchable) [size=256]
	Capabilities: [80] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Kernel driver in use: sdhci-pci
	Kernel modules: sdhci-pci


[-- Attachment #4: proc_iomem.txt --]
[-- Type: text/plain, Size: 2070 bytes --]

00000000-0009fbff : System RAM
0009fc00-0009ffff : reserved
000e0000-000eedff : reserved
000eee00-000eefff : ACPI Non-volatile Storage
000ef000-000fffff : reserved
00100000-7f74ffff : System RAM
  00200000-00450686 : Kernel code
  00450687-00603c37 : Kernel data
  00678000-00784d3b : Kernel bss
7f750000-7fffffff : reserved
  7f750000-7f75ffff : pnp 00:00
  7f760000-7f7fffff : pnp 00:00
  7f800000-7fffffff : pnp 00:00
88000000-8807ffff : 0000:00:02.1
88080000-88083fff : 0000:00:1b.0
  88080000-88083fff : ICH HD audio
88084000-88087fff : 0000:03:0b.1
88088000-88088fff : 0000:03:0b.0
  88088000-88088fff : yenta_socket
88089000-880897ff : 0000:03:0b.1
  88089000-880897ff : firewire_ohci
88089800-880898ff : 0000:03:0b.3
  88089800-880898ff : mmc0
8808a000-8808afff : Intel Flush Page
8c000000-8fffffff : PCI CardBus 0000:04
90000000-93ffffff : PCI CardBus 0000:04
e0000000-efffffff : 0000:00:02.0
  e0000000-e07affff : vesafb
f0000000-f3ffffff : PCI MMCONFIG 0
  f0000000-f3ffffff : pnp 00:01
fec00000-fec17fff : reserved
  fec00000-fec17fff : pnp 00:00
    fec00000-fec00fff : IOAPIC 0
fec20000-fec27fff : reserved
  fec20000-fec27fff : pnp 00:00
fed00000-fed003ff : HPET 0
  fed00000-fed003ff : reserved
fed14000-fed19fff : reserved
  fed14000-fed19fff : pnp 00:00
fed1c000-fed8ffff : reserved
  fed1c000-fed1ffff : pnp 00:00
  fed20000-fed3ffff : pnp 00:00
  fed45000-fed8ffff : pnp 00:00
feda0000-fedbffff : reserved
  feda0000-fedbffff : pnp 00:00
fee00000-fee00fff : Local APIC
  fee00000-fee00fff : reserved
    fee00000-fee00fff : pnp 00:00
ff800000-ff8fffff : PCI Bus 0000:02
  ff8fe000-ff8fffff : 0000:02:00.0
    ff8fe000-ff8fffff : iwlagn
ff900000-ff9fffff : PCI Bus 0000:01
  ff9e0000-ff9fffff : 0000:01:00.0
    ff9e0000-ff9fffff : e1000e
ffa00000-ffbfffff : reserved
  ffa00000-ffbfffff : pnp 00:00
ffc3f800-ffc3fbff : 0000:00:1f.2
  ffc3f800-ffc3fbff : ahci
ffc3fc00-ffc3ffff : 0000:00:1d.7
  ffc3fc00-ffc3ffff : ehci_hcd
ffc40000-ffc7ffff : 0000:00:02.0
ffc80000-ffcfffff : 0000:00:02.0
ffd00000-ffffffff : reserved
  ffd00000-ffffffff : pnp 00:00

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Rafael J. Wysocki]

On Friday, 5 of December 2008, Linus Torvalds wrote:
> 
> On Thu, 4 Dec 2008, Rafael J. Wysocki wrote:
> > 
> > That said the "don't bother allocating bridging windows for transparent
> > bridges" patch resulted in the following layout on my box (from /proc/iomem):
> > 
> > 88000000-8807ffff : 0000:00:02.1
> > 88080000-88083fff : 0000:00:1b.0
> >   88080000-88083fff : ICH HD audio
> > 88084000-88087fff : 0000:03:0b.1
> > 88088000-88088fff : 0000:03:0b.0
> >   88088000-88088fff : yenta_socket
> > 88089000-880897ff : 0000:03:0b.1
> >   88089000-880897ff : firewire_ohci
> > 88089800-880898ff : 0000:03:0b.3
> >   88089800-880898ff : mmc0
> > 8808a000-8808afff : Intel Flush Page
> > 8c000000-8fffffff : PCI CardBus 0000:04
> > 90000000-93ffffff : PCI CardBus 0000:04
> > 
> > while my "don't allocate bridging windows for cardbus bridges behind
> > transparent bridges" patch I've just sent (appended for easier reference)
> > results in the layout:
> > 
> > 88000000-880fffff : PCI Bus 0000:03
> >   88000000-88003fff : 0000:03:0b.1
> >   88004000-88004fff : 0000:03:0b.0
> >     88004000-88004fff : yenta_socket
> >   88005000-880057ff : 0000:03:0b.1
> >     88005000-880057ff : firewire_ohci
> >   88005800-880058ff : 0000:03:0b.3
> >     88005800-880058ff : mmc0
> > 88100000-8817ffff : 0000:00:02.1
> > 88180000-88183fff : 0000:00:1b.0
> >   88180000-88183fff : ICH HD audio
> > 88184000-88184fff : Intel Flush Page
> > 8c000000-8fffffff : PCI CardBus 0000:04
> > 90000000-93ffffff : PCI CardBus 0000:04
> 
> Well, this happens because in the second case, you still will allocate a 
> non-prefetchable window due to the _other_ devices behind the bridge (ie 
> the firewire and mmc device.
> 
> So with your "ignore cardbus device resources", you still do end up with a 
> bridge window allocated, but now it will depend entirely on what other 
> devices exist on that PCI bus. Which is why I really dislike that patch, 
> because it really makes no sense at all. 
> 
> And once you've allocated the PCI bridge window, then the alignment 
> requirements are that you end up having at least 1MB of window, and now 
> because a window exists, and will fit, it will then happily put the yenta 
> control mappings into that window even though it didn't size it for them.
> 
> See?
> 
> Also, notice how it doesn't put the actual cardbus bridge windows 
> themselves into that PCI bridge window, because they won't fit. So these 
> resources:
> 
> 	8c000000-8fffffff : PCI CardBus 0000:04
> 	90000000-93ffffff : PCI CardBus 0000:04
> 
> are outside the window, even though that bus is topologically inside the 
> same bus, and they both end up depending on the fact that the PCI bus 
> controller is transparent.
> 
> So the above results are fairly easy to explain.
> 
> The _ordering_ difference comes simply from the allocation order. We'll do 
> bus allocations first (if we do them), which is why _if_ we allocate a 
> window for that PCI bus 03 (ie the one that is bridged to by 0:1e.0, that 
> transparent bridge), then we'll end up allocating it first. So that's why 
> the PCI bridge window shows up at 0x88000000, if it shows up at all 
> (because that's the starting address for PCI allocations).
> 
> Then, we'll do the regular devices in the order we found them, so then 
> we'll allocate the resources for device 0:02.1 and then 0:1b.0. Now, _if_ 
> we did a bus window allocation, they'll end up being after the bus window 
> we allocated. Otherwise they'll end up being the first allocations.
> 
> So then, by the time we actually get to bus#3, and devices 3:0b.*, where 
> they end up is going to depend on whether we allocated that bus window (in 
> which case they'll preferentially get allocated inside the window - ie 
> starting at 0x88000000), or they'll just get allocated inside the parent 
> (root) PCI bus. In the latter case they'll be allocated after the 0:02.1 
> etc devices.
> 
> So the differences in ordering really do make sense, and are a direct 
> consequence of whether we decided to need to allocate a bridging window 
> for that PCI-PCI bridge at 0:1e.0.
> 
> Also note that _if_ PCI bus #3 had had other devices with prefetchable 
> memory resources, then we'd have allocated a prefetchable window for 
> those even with your patch, and then we'd have been back to the original 
> allocation again (although sizing might cause changes, since your patch 
> will make us ignore the cardbus controlle for sizing).

Yes, I do realize all of what you said above.  I only wanted to note that the
layouts of device's memory ranges are different with both patches.

> > where devices behind the transparent bridge (PCI Bus 0000:03) are located
> > _before_ ICH HD audio in the memory address space, and this one appears to
> > work.  So there _may_ be an effect of the layout too.
> 
> I do agree that your patch will affect layout. I just don't think it makes 
> any real amount of sense because of how it essentially does so "randomly" 
> depending on what other devices you'd have behind the transparent bridge.
> 
> Which is why I think we should either not size transparent bridges at all, 
> or we should size _all_ the devices behind them.

I'm not saying it's unreasonable to do this in general.  Still, on this
particular box it appears to break things in a very subtle way.

Also, I do realize that most probably the root cause of that is something
else, but we can make it show up itself or hide by changing the layout of
the memory space.  What is this, though, I don't know.

> Oh, btw, I thought your and Frans' laptops were identical?

No, they are from different vendors. :-)  Mine is a Toshiba one and the Frans'
one is from HP.

> They don't seem to be: in Frans' case, the firmware does seem to set up one
> memory window, so he gets that one even with my "don't size anything" patch,
> just because we'll still honor allocations done by firmware.
> 
> > Well, given that both affected boxes have the same chipset (945GM), I seriously
> > suspect a nastiness in that chipset we're not aware of.  Especially that
> > the problem is not reproducible without snd_hda_intel (at least on my box).
> 
> Well, the counter-argument to that is that the 945GM should be a _very_ 
> common chipset. So I'd not expect a chipset nastiness.

Unless people don't report problems with it, because they are so rare that
are regarded as "random" and "unreproducible".

Also, since the layout of devices in the PCI config space seems to matter,
the problem need not appear on other systems with that chipset at all.

> I'd be more wary about the BIOS doing something odd. Or an ACPI thing. 

Well, unlikely, _unless_ Toshiba and HP both use the same Intel reference
BIOS or something.

> > I've already checked the resume ordering of PCI devices on my box and it
> > is the following:
> >   [snip]
> > So, snd_hda_intel resumes before all of the bridges and the layout of devices
> > _behind_ the transparent bridge shouldn't affect it at all.
> 
> Yes. And in the case of Frans' machine, the e1000e controller was before 
> all the bridges too.

Hm.  And unloading it before suspend made things work?  Interesting.

Rafael

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Linus Torvalds]

On Fri, 5 Dec 2008, Rafael J. Wysocki wrote:
> > 
> > Not very interesting. It just does the same thing your previous patches 
> > have done - ignores the cardbus slot for sizing. It just does it 
> > differently and more explicitly.
> 
> There's a difference, though.  It doesn't cause the resources flags to be
> cleared for the cardbus bridge and the cardbus bridge gets the correct sizes
> of both prefetchable and non-prefetchable windows (64 MB).

Yes, true. In that sense, it minimizes the differences between the 
"working" and "nonworking" case. 

Which is interesting in the sense that it makes it even less likely that 
it's an actual resource clash. 

> I know that. :-)  Still, I find it important to notice that the memory windows
> of the cardbus bridge can be 64 MB-wide and things work in that case too.
> Also, I like it more than the previous patch. ;-)
> 
> Moreover, I _think_ it would work for Frans too, because I _suspect_ the
> problem is related to a cardbus bridge being located behind that "transparent"
> thing somehow.

Well, I suspect that on Frans' machine, there will be no difference at all 
between your patch and my previous patch, since he already had a bridge 
window allocated by the BIOS. And he also had just that firewire and mmc 
thing that only needed that memory window, so he'd end up with the exact 
same resource allocation, methinks.

> > Can you send "lspci -vv" and "dmesg" output for that kernel?
> 
> No prob, both attached along with the contents of /proc/iomem .

It all looks very sane. Too bad it apparently doesn't work.

> > Even if it failed the suspend/resume, it's interesting, because I would
> > actually have expected that one to have the same layout as the successful
> > ones. 
> 
> Well, not exactly.  Actually, with this patch the graphics and "ICH HD audio"
> get their memory ranges before the ranges of _all_ devices behind the
> transparent bridge, while in the "working" case their memory ranges are located
> _after_ the memory ranges of devices behind the transparent bridge _except_
> for the cardbus bridge's memory windows.

Yes, however, it shouldn't matter.

Except in cae the audio driver (for example) were to access past its MMIO 
window, and we'd have a situation where we care what was just before it or 
after it. That doesn't seem very likely, though.

		Linus

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Linus Torvalds]

On Fri, 5 Dec 2008, Rafael J. Wysocki wrote:
> > 
> > Yes. And in the case of Frans' machine, the e1000e controller was before 
> > all the bridges too.
> 
> Hm.  And unloading it before suspend made things work?  Interesting.

Yeah. Frans' workaround was

 - unloading e1000e before suspend
 - using aggressive powersave setting on snd_hda_intel to ensure that
   sound controller was already sleeping before entering suspend

and both of those devices are on the root PCI bus and are enumerated (and 
thus resumed) before the transparent bridge.

So yeah, the whole "resource allocation for that bridge" saga should 
_really_ not matter. But it clearly does seem to.

			Linus

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Rafael J. Wysocki]

On Friday, 5 of December 2008, Linus Torvalds wrote:
> 
> On Fri, 5 Dec 2008, Rafael J. Wysocki wrote:
> > > 
> > > Yes. And in the case of Frans' machine, the e1000e controller was before 
> > > all the bridges too.
> > 
> > Hm.  And unloading it before suspend made things work?  Interesting.
> 
> Yeah. Frans' workaround was
> 
>  - unloading e1000e before suspend
>  - using aggressive powersave setting on snd_hda_intel to ensure that
>    sound controller was already sleeping before entering suspend
> 
> and both of those devices are on the root PCI bus and are enumerated (and 
> thus resumed) before the transparent bridge.
> 
> So yeah, the whole "resource allocation for that bridge" saga should 
> _really_ not matter. But it clearly does seem to.

Well, I'm going to have a closer look at what we're doing to PCI bridges in the
resume code path, as this _feels_ relevant in this case.

Perhaps we're not doing something we're supposed to do (that already happened
for regular devices in the past) or we're doing something we're not supposed
to do.  Unfortunately, I'd have to dig into the PCI bridge spec for this
purpose and that will take time.  Still, I suspect that's worth doing, as
potentially the problem may affect a wide range of systems.

The fact that I have a box on which I can reproduce the problem should help
here. ;-)

Thanks,
Rafael

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Linus Torvalds]

On Thu, 4 Dec 2008, Linus Torvalds wrote:
> 
> On Fri, 5 Dec 2008, Rafael J. Wysocki wrote:
> > 
> > There's a difference, though.  It doesn't cause the resources flags to be
> > cleared for the cardbus bridge and the cardbus bridge gets the correct sizes
> > of both prefetchable and non-prefetchable windows (64 MB).
> 
> Yes, true. In that sense, it minimizes the differences between the 
> "working" and "nonworking" case. 

Hmm. 

One other issue: we've been looking mostly at MMIO, but another thing that 
differs here is the PIO part.

Your patch only changes pbus_size_mem(), so what happens is that it avoids 
allocating the prefetch window. But it still allocates the PIO window, 
because pbus_size_io() is still run.

Maybe the PIO window matters? Any magic suspend registers are usually in 
PIO space, not in MMIO space. Did /proc/ioports change, and if so, how? 

		Linus

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Rafael J. Wysocki]

On Friday, 5 of December 2008, Linus Torvalds wrote:
> 
> On Thu, 4 Dec 2008, Linus Torvalds wrote:
> > 
> > On Fri, 5 Dec 2008, Rafael J. Wysocki wrote:
> > > 
> > > There's a difference, though.  It doesn't cause the resources flags to be
> > > cleared for the cardbus bridge and the cardbus bridge gets the correct sizes
> > > of both prefetchable and non-prefetchable windows (64 MB).
> > 
> > Yes, true. In that sense, it minimizes the differences between the 
> > "working" and "nonworking" case. 
> 
> Hmm. 
> 
> One other issue: we've been looking mostly at MMIO, but another thing that 
> differs here is the PIO part.
> 
> Your patch only changes pbus_size_mem(), so what happens is that it avoids 
> allocating the prefetch window. But it still allocates the PIO window, 
> because pbus_size_io() is still run.
> 
> Maybe the PIO window matters? Any magic suspend registers are usually in 
> PIO space, not in MMIO space. Did /proc/ioports change, and if so, how? 

|18,20c18,19
|< 1000-1fff : PCI Bus 0000:03
|<   1000-10ff : PCI CardBus 0000:04
|<   1400-14ff : PCI CardBus 0000:04
|---
|> 1000-10ff : PCI CardBus 0000:04
|> 1400-14ff : PCI CardBus 0000:04

where the first one is with my patch and the second one is with the "no sizing
for transparent bridges" patch.  No difference to my eyes, if the "transparent"
bridge is really transparent. :-)

Thanks,
Rafael

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Linus Torvalds]

On Fri, 5 Dec 2008, Rafael J. Wysocki wrote:
> > 
> > Maybe the PIO window matters? Any magic suspend registers are usually in 
> > PIO space, not in MMIO space. Did /proc/ioports change, and if so, how? 
> 
> |18,20c18,19
> |< 1000-1fff : PCI Bus 0000:03
> |<   1000-10ff : PCI CardBus 0000:04
> |<   1400-14ff : PCI CardBus 0000:04
> |---
> |> 1000-10ff : PCI CardBus 0000:04
> |> 1400-14ff : PCI CardBus 0000:04
> 
> where the first one is with my patch and the second one is with the "no sizing
> for transparent bridges" patch.  No difference to my eyes, if the "transparent"
> bridge is really transparent. :-)

Well, there _is_ a difference, although a subtle one. Not for the Cardbus 
card itself, but for decode of _non-cardbus_ IO ranges.

IOW, if there is a secret magic IO port that we don't know about at (say) 
address 0x1100, then the difference is that now there would be a fight 
over who would take it.

And I think I actually have found some secret IO decoding in ICH7. Damn. I 
_hate_ it when Intel does that. I asked (long ago) that Intel double-check 
that we have quirks for all their idiotic magic IO addresses, but they 
clearly never did that.

Or maybe I'm reading the ICH7 docs wrong. But I don't think I am.

NOTE NOTE NOTE! I didn't check which all LPC bridges there are out there 
that have these magic registers. But it shows up in the ICH7 docs. It 
migth exist in ICH[5-9] for all I know. But at least for ICH7, the only 
LPC bridge ID's I find in the spec update are 27b8, 27b9 and 27bd, which 
are those three devices that I list in the quirks.

Somebody should double-check this, and also check whether ICH6-9 have the 
same LPC decode logic..

Anyway, does this cause anything to be printed out for you? I have _not_ 
checked whether this is the only such programmable hidden range register 
set.

That said, the "no IO window" case should be the safe one (if there are 
hidden IO ports that clash), and it's the one that does _not_ work for 
you, so this may not be it either. But these kinds of quirks were very 
common reasons for ACPI power states not working (because we would just 
allocate something else on top of the damn hidden things that we didn't 
know about).

		Linus

---
 drivers/pci/quirks.c |   36 ++++++++++++++++++++++++++++++++++++
 1 files changed, 36 insertions(+), 0 deletions(-)

diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 5f4f85f..355ccf2 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -474,6 +474,42 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_ICH9_4, quirk_
 DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_ICH9_7, quirk_ich6_lpc_acpi);
 DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_ICH9_8, quirk_ich6_lpc_acpi);
 
+static void __devinit ich7_lpc_generic_decode(struct pci_dev *dev, unsigned reg, const char *name)
+{
+	u32 val;
+	u32 mask, base;
+
+	pci_read_config_dword(dev, reg, &val);
+
+	/* Enabled? */
+	if (!(val & 1))
+		return;
+
+	/* Base in bits 15:2 */
+	base = val & 0xfffc;
+
+	/* Decode mask in bits 23:18 */
+	mask = (val >> 16) & 0xfc;
+
+	/* The mask is only on a dword address, the word/byte is always matched */
+	mask |= 3;
+
+	/* Just print it out for now. We should reserve it after debugging */
+	dev_info(&dev->dev, "%s PIO at %04x (mask %04x)\n", name, base, mask);
+}
+
+static void __devinit quirk_ich7_lpc_decode(struct pci_dev *dev)
+{
+	ich7_lpc_generic_decode(dev, 0x84, "ICH7 LPC Generic IO decode 1");
+	ich7_lpc_generic_decode(dev, 0x88, "ICH7 LPC Generic IO decode 2");
+	ich7_lpc_generic_decode(dev, 0x8c, "ICH7 LPC Generic IO decode 3");
+	ich7_lpc_generic_decode(dev, 0x90, "ICH7 LPC Generic IO decode 4");
+}
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,   PCI_DEVICE_ID_INTEL_ICH7_0, quirk_ich7_lpc_decode);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,   PCI_DEVICE_ID_INTEL_ICH7_1, quirk_ich7_lpc_decode);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,   PCI_DEVICE_ID_INTEL_ICH7_31, quirk_ich7_lpc_decode);
+
+
 /*
  * VIA ACPI: One IO region pointed to by longword at
  *	0x48 or 0x20 (256 bytes of ACPI registers)

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Linus Torvalds]

On Thu, 4 Dec 2008, Linus Torvalds wrote:
> 
> NOTE NOTE NOTE! I didn't check which all LPC bridges there are out there 
> that have these magic registers. But it shows up in the ICH7 docs. It 
> migth exist in ICH[5-9] for all I know. But at least for ICH7, the only 
> LPC bridge ID's I find in the spec update are 27b8, 27b9 and 27bd, which 
> are those three devices that I list in the quirks.

Ok, the ICH6 LPC side has something similar, but not the same. Just two 
ranges, and slightly less flexible wrt sizing.

And ICH8/9/10 seems to have the same thing as ICH7.

And looking at my own machine (ICH10) it actually appears like my ICH10 
setup has two of the magic IO ranges that it decodes, and only one of them 
is covered by the BIOS PnP tables.

They're both below 0x1000, though, so Linux shouldn't ever allocate 
anything on top of them. And that's the norm - when firmware sets up 
hidden magic system IO ranges, they do tend to be low IO ports.

But if some incompetent firmware person screws that up...

		Linus

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Linus Torvalds]

On Thu, 4 Dec 2008, Linus Torvalds wrote:
> 
> Ok, the ICH6 LPC side has something similar, but not the same. Just two 
> ranges, and slightly less flexible wrt sizing.
> 
> And ICH8/9/10 seems to have the same thing as ICH7.

Here's a patch that implements what I think is the correct quirks (apart 
from the commented ICH6 lazy detail I didn't do).

It would be very interesting to see if people affected get any printouts 
about IO decodes that don't show up in /proc/ioports...

And I know I've looked for these kinds of things before in the Intel ICH 
docs, and apparently always missed these things (or been too lazy to 
react), so can somebody else see if they can find any other ranges like 
this? Maybe in non-LPC controllers? 

Jesse, are there any Intel chipset people who could once and for all say 
"these are the things we decode in our chipset" for _all_ chipsets and 
_all_ dynamic ranges? I've asked for that before. There must be people who 
know this, without having to wade through many thousands of pages of 
boring datasheets?

The ICH datasheets tend to be 850 pages each, and there is more than one 
of them. And they _do_ differ in the details, even if there is a lot of 
sharing going on. So reading the docs is a huge effort, when there's bound 
to be somebody who just knows the answer.

NOTE! This patch will just add a _printout_ of the IO regions it finds. It 
won't actually register them as known resources. So it won't make the 
kernel know to avoid them if they were to clash!

Also, see the "This is not correct" for the ICH6 dynamically sized case. 

		Linus

---
 drivers/pci/quirks.c |  105 ++++++++++++++++++++++++++++++++++++++++++-------
 1 files changed, 90 insertions(+), 15 deletions(-)

diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 5f4f85f..1b64b28 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -449,7 +449,7 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,    PCI_DEVICE_ID_INTEL_82801DB_12,
 DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,    PCI_DEVICE_ID_INTEL_82801EB_0,		quirk_ich4_lpc_acpi);
 DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,    PCI_DEVICE_ID_INTEL_ESB_1,		quirk_ich4_lpc_acpi);
 
-static void __devinit quirk_ich6_lpc_acpi(struct pci_dev *dev)
+static void __devinit ich6_lpc_acpi_gpio(struct pci_dev *dev)
 {
 	u32 region;
 
@@ -459,20 +459,95 @@ static void __devinit quirk_ich6_lpc_acpi(struct pci_dev *dev)
 	pci_read_config_dword(dev, 0x48, &region);
 	quirk_io_region(dev, region, 64, PCI_BRIDGE_RESOURCES+1, "ICH6 GPIO");
 }
-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_ICH6_0, quirk_ich6_lpc_acpi);
-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_ICH6_1, quirk_ich6_lpc_acpi);
-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_ICH7_0, quirk_ich6_lpc_acpi);
-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_ICH7_1, quirk_ich6_lpc_acpi);
-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_ICH7_31, quirk_ich6_lpc_acpi);
-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_ICH8_0, quirk_ich6_lpc_acpi);
-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_ICH8_2, quirk_ich6_lpc_acpi);
-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_ICH8_3, quirk_ich6_lpc_acpi);
-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_ICH8_1, quirk_ich6_lpc_acpi);
-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_ICH8_4, quirk_ich6_lpc_acpi);
-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_ICH9_2, quirk_ich6_lpc_acpi);
-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_ICH9_4, quirk_ich6_lpc_acpi);
-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_ICH9_7, quirk_ich6_lpc_acpi);
-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_ICH9_8, quirk_ich6_lpc_acpi);
+
+static void __devinit ich6_lpc_generic_decode(struct pci_dev *dev, unsigned reg, const char *name, int dynsize)
+{
+	u32 val;
+	u32 size, base;
+
+	pci_read_config_dword(dev, reg, &val);
+
+	/* Enabled? */
+	if (!(val & 1))
+		return;
+	base = val & 0xfffc;
+	if (dynsize) {
+		/*
+		 * This is not correct. It is 16, 32 or 64 bytes depending on
+		 * register D31:F0:ADh bits 5:4.
+		 *
+		 * But this gets us at least _part_ of it.
+		 */
+		size = 16;
+	} else {
+		size = 128;
+	}
+	base &= ~(size-1);
+
+	/* Just print it out for now. We should reserve it after more debugging */
+	dev_info(&dev->dev, "%s PIO at %04x-%04x\n", name, base, base+size-1);
+}
+
+static void __devinit quirk_ich6_lpc(struct pci_dev *dev)
+{
+	/* Shared ACPI/GPIO decode with all ICH6+ */
+	ich6_lpc_acpi_gpio(dev);
+
+	/* ICH6-specific generic IO decode */
+	ich6_lpc_generic_decode(dev, 0x84, "LPC Generic IO decode 1", 0);
+	ich6_lpc_generic_decode(dev, 0x88, "LPC Generic IO decode 2", 1);
+}
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_ICH6_0, quirk_ich6_lpc);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_ICH6_1, quirk_ich6_lpc);
+
+static void __devinit ich7_lpc_generic_decode(struct pci_dev *dev, unsigned reg, const char *name)
+{
+	u32 val;
+	u32 mask, base;
+
+	pci_read_config_dword(dev, reg, &val);
+
+	/* Enabled? */
+	if (!(val & 1))
+		return;
+
+	/*
+	 * IO base in bits 15:2, mask in bits 23:18, both
+	 * are dword-based
+	 */
+	base = val & 0xfffc;
+	mask = (val >> 16) & 0xfc;
+	mask |= 3;
+
+	/* Just print it out for now. We should reserve it after more debugging */
+	dev_info(&dev->dev, "%s PIO at %04x (mask %04x)\n", name, base, mask);
+}
+
+/* ICH7-10 has the same common LPC generic IO decode registers */
+static void __devinit quirk_ich7_lpc(struct pci_dev *dev)
+{
+	/* We share the common ACPI/DPIO decode with ICH6 */
+	ich6_lpc_acpi_gpio(dev);
+
+	/* And have 4 ICH7+ generic decodes */
+	ich7_lpc_generic_decode(dev, 0x84, "ICH7 LPC Generic IO decode 1");
+	ich7_lpc_generic_decode(dev, 0x88, "ICH7 LPC Generic IO decode 2");
+	ich7_lpc_generic_decode(dev, 0x8c, "ICH7 LPC Generic IO decode 3");
+	ich7_lpc_generic_decode(dev, 0x90, "ICH7 LPC Generic IO decode 4");
+}
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_ICH7_0, quirk_ich7_lpc);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_ICH7_1, quirk_ich7_lpc);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_ICH7_31, quirk_ich7_lpc);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_ICH8_0, quirk_ich7_lpc);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_ICH8_2, quirk_ich7_lpc);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_ICH8_3, quirk_ich7_lpc);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_ICH8_1, quirk_ich7_lpc);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_ICH8_4, quirk_ich7_lpc);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_ICH9_2, quirk_ich7_lpc);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_ICH9_4, quirk_ich7_lpc);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_ICH9_7, quirk_ich7_lpc);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_ICH9_8, quirk_ich7_lpc);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,   PCI_DEVICE_ID_INTEL_ICH10_1, quirk_ich7_lpc);
 
 /*
  * VIA ACPI: One IO region pointed to by longword at

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Frans Pop]

On Friday 05 December 2008, Linus Torvalds wrote:
> Here's a patch that implements what I think is the correct quirks
> (apart from the commented ICH6 lazy detail I didn't do).

I get:
pci 0000:00:1f.0: quirk: region 1000-107f claimed by ICH6 ACPI/GPIO/TCO
pci 0000:00:1f.0: quirk: region 1100-113f claimed by ICH6 GPIO
pci 0000:00:1f.0: ICH7 LPC Generic IO decode 1 PIO at 0500 (mask 007f)
pci 0000:00:1f.0: ICH7 LPC Generic IO decode 4 PIO at 02e8 (mask 0007)

The ICH6 and ICH7 in those messages is a bit weird given that my system is 
ICH8...

Hardware info (JFYI):
00:1f.0 ISA bridge [0601]: Intel Corporation 82801HBM (ICH8M-E) LPC 
Interface Controller [8086:2811] (rev 03)

System Information
        Manufacturer: Hewlett-Packard
        Product Name: HP Compaq 2510p Notebook PC
        Version: F.0C
Base Board Information
        Manufacturer: Hewlett-Packard
        Product Name: 30C9
        Version: KBC Version 75.28
BIOS Information
        Vendor: Hewlett-Packard
        Version: 68MSP Ver. F.0C
        Release Date: 06/18/2008

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Frans Pop]

On Friday 05 December 2008, Rafael J. Wysocki wrote:
> On Friday, 5 of December 2008, Linus Torvalds wrote:
> > Oh, btw, I thought your and Frans' laptops were identical?
>
> No, they are from different vendors. :-)  Mine is a Toshiba one and the
> Frans' one is from HP.

Also, the CardBus bridge and what's behind them are quite different
(and we use different firewire stacks).

Mine is:
02:06.0 CardBus bridge [0607]: Ricoh Co Ltd RL5c476 II [1180:0476] (rev ba)
        Kernel driver in use: yenta_cardbus
        Kernel modules: yenta_socket
02:06.1 FireWire (IEEE 1394) [0c00]: Ricoh Co Ltd R5C832 IEEE 1394 Controller [1180:0832] (rev 04)
        Kernel driver in use: ohci1394
        Kernel modules: ohci1394
02:06.2 SD Host controller [0805]: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter [1180:0822] (rev 21)
        Kernel driver in use: sdhci-pci
        Kernel modules: sdhci-pci
02:06.3 System peripheral [0880]: Ricoh Co Ltd R5C843 MMC Host Controller [1180:0843] (rev ff)
        Kernel driver in use: ricoh-mmc
        Kernel modules: ricoh_mmc
(The ricoh_mmc module disables the last one.)

While Rafael has:
03:0b.0 CardBus bridge: Texas Instruments PCIxx12 Cardbus Controller
	Kernel driver in use: yenta_cardbus
	Kernel modules: yenta_socket
03:0b.1 FireWire (IEEE 1394): Texas Instruments PCIxx12 OHCI Compliant IEEE 1394 Host Controller (prog-if 10 [OHCI])
	Kernel driver in use: firewire_ohci
	Kernel modules: firewire-ohci
03:0b.3 SD Host controller: Texas Instruments PCIxx12 SDA Standard Compliant SD Host Controller (prog-if 01)
	Kernel driver in use: sdhci-pci
	Kernel modules: sdhci-pci

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Frans Pop]

On Friday 05 December 2008, Frans Pop wrote:
> On Friday 05 December 2008, Linus Torvalds wrote:
> > Here's a patch that implements what I think is the correct quirks
> > (apart from the commented ICH6 lazy detail I didn't do).
>
> I get:
> pci 0000:00:1f.0: quirk: region 1000-107f claimed by ICH6 ACPI/GPIO/TCO
> pci 0000:00:1f.0: quirk: region 1100-113f claimed by ICH6 GPIO
> pci 0000:00:1f.0: ICH7 LPC Generic IO decode 1 PIO at 0500 (mask 007f)
> pci 0000:00:1f.0: ICH7 LPC Generic IO decode 4 PIO at 02e8 (mask 0007)

Sorry, I missed:
> It would be very interesting to see if people affected get any
> printouts about IO decodes that don't show up in /proc/ioports...

Looks like 02e8 is missing (see /proc/ioports below).


I also tried the patch on my ICH7 desktop which gives:
pci 0000:00:1f.0: quirk: region 0400-047f claimed by ICH6 ACPI/GPIO/TCO
pci 0000:00:1f.0: quirk: region 0500-053f claimed by ICH6 GPIO
pci 0000:00:1f.0: ICH7 LPC Generic IO decode 1 PIO at 0680 (mask 007f)
But 0680 is accounted for in /proc/ioports:
0680-06ff : pnp 00:06

Cheers,
FJP

/proc/ioports (for notebook):
0000-001f : dma1
0020-0021 : pic1
0040-0043 : timer0
0050-0053 : timer1
0060-0060 : keyboard
0064-0064 : keyboard
0070-0071 : rtc0
0080-008f : dma page reg
00a0-00a1 : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : 0000:00:1f.1
  0170-0177 : ata_piix
01f0-01f7 : 0000:00:1f.1
  01f0-01f7 : ata_piix
02f8-02ff : pnp 00:0c
0376-0376 : 0000:00:1f.1
  0376-0376 : ata_piix
03c0-03df : vesafb
03f6-03f6 : 0000:00:1f.1
  03f6-03f6 : ata_piix
03f8-03ff : pnp 00:0c
04d0-04d1 : pnp 00:0c
0500-055f : pnp 00:0a
0800-080f : pnp 00:0a
0cf8-0cff : PCI conf1
1000-107f : 0000:00:1f.0
  1000-107f : pnp 00:0c
    1000-1003 : ACPI PM1a_EVT_BLK
    1004-1005 : ACPI PM1a_CNT_BLK
    1008-100b : ACPI PM_TMR
    1010-1015 : ACPI CPU throttle
    1020-1020 : ACPI PM2_CNT_BLK
    1028-102f : ACPI GPE0_BLK
    1060-107f : iTCO_wdt
1100-113f : 0000:00:1f.0
  1100-113f : pnp 00:0c
1200-121f : pnp 00:0c
2000-2007 : 0000:00:02.0
2008-200f : 0000:00:03.2
2010-2013 : 0000:00:03.2
2018-201f : 0000:00:03.2
2020-2023 : 0000:00:03.2
2030-203f : 0000:00:03.2
2040-2047 : 0000:00:03.3
  2040-2047 : serial
2060-207f : 0000:00:19.0
2080-209f : 0000:00:1a.0
  2080-209f : uhci_hcd
20a0-20bf : 0000:00:1a.1
  20a0-20bf : uhci_hcd
20c0-20df : 0000:00:1d.0
  20c0-20df : uhci_hcd
20e0-20ff : 0000:00:1d.1
  20e0-20ff : uhci_hcd
2100-211f : 0000:00:1d.2
  2100-211f : uhci_hcd
2120-212f : 0000:00:1f.1
  2120-212f : ata_piix
3000-3fff : PCI Bus 0000:02
  3000-30ff : PCI CardBus 0000:03
  3400-34ff : PCI CardBus 0000:03

MSI changes in .28

[Frans Pop]

On Tuesday 02 December 2008, Linus Torvalds wrote:
> So, it looks like you have MSI enabled in -rc6, and not in -rc3.

I've just compared dmesg for my *desktop* and there I see the following
between 2.6.28-rc6 and current 2.6.28-rc7:

 pcieport-driver 0000:00:1c.0: setting latency timer to 64
 pcieport-driver 0000:00:1c.0: found MSI capability
-pcieport-driver 0000:00:1c.0: irq 47 for MSI/MSI-X
+pcieport-driver 0000:00:1c.0: irq 511 for MSI/MSI-X
 pci_express 0000:00:1c.0:pcie00: allocate port service
 pci_express 0000:00:1c.0:pcie02: allocate port service
 pcieport-driver 0000:00:1c.2: setting latency timer to 64
 pcieport-driver 0000:00:1c.2: found MSI capability
-pcieport-driver 0000:00:1c.2: irq 46 for MSI/MSI-X
+pcieport-driver 0000:00:1c.2: irq 510 for MSI/MSI-X
 pci_express 0000:00:1c.2:pcie00: allocate port service
 pci_express 0000:00:1c.2:pcie02: allocate port service
 pcieport-driver 0000:00:1c.3: setting latency timer to 64
 pcieport-driver 0000:00:1c.3: found MSI capability
-pcieport-driver 0000:00:1c.3: irq 45 for MSI/MSI-X
+pcieport-driver 0000:00:1c.3: irq 509 for MSI/MSI-X
 pci_express 0000:00:1c.3:pcie00: allocate port service
 pci_express 0000:00:1c.3:pcie02: allocate port service
 pcieport-driver 0000:00:1c.4: setting latency timer to 64
 pcieport-driver 0000:00:1c.4: found MSI capability
-pcieport-driver 0000:00:1c.4: irq 44 for MSI/MSI-X
+pcieport-driver 0000:00:1c.4: irq 508 for MSI/MSI-X
 pci_express 0000:00:1c.4:pcie00: allocate port service
 pci_express 0000:00:1c.4:pcie02: allocate port service
 pcieport-driver 0000:00:1c.5: setting latency timer to 64
 pcieport-driver 0000:00:1c.5: found MSI capability
-pcieport-driver 0000:00:1c.5: irq 43 for MSI/MSI-X
+pcieport-driver 0000:00:1c.5: irq 507 for MSI/MSI-X
[...]
 ahci 0000:00:1f.2: PCI INT B -> GSI 19 (level, low) -> IRQ 19
-ahci 0000:00:1f.2: irq 42 for MSI/MSI-X
+ahci 0000:00:1f.2: irq 506 for MSI/MSI-X
 ahci 0000:00:1f.2: AHCI 0001.0100 32 slots 4 ports 3 Gbps 0xf impl SATA mode
[...]
 e1000e 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
 e1000e 0000:01:00.0: setting latency timer to 64
-e1000e 0000:01:00.0: irq 41 for MSI/MSI-X
+e1000e 0000:01:00.0: irq 505 for MSI/MSI-X

I.e. very similar to the change between rc-3 and rc-7 you commented on
for my notebook.

Is this really MSI being (not) enabled, or just it using much higher
IRQ numbers?

Re: MSI changes in .28

[Yinghai Lu]

On Fri, Dec 5, 2008 at 12:53 AM, Frans Pop <elendil@planet.nl> wrote:
> On Tuesday 02 December 2008, Linus Torvalds wrote:
>> So, it looks like you have MSI enabled in -rc6, and not in -rc3.
>
> I've just compared dmesg for my *desktop* and there I see the following
> between 2.6.28-rc6 and current 2.6.28-rc7:
>
>  pcieport-driver 0000:00:1c.0: setting latency timer to 64
>  pcieport-driver 0000:00:1c.0: found MSI capability
> -pcieport-driver 0000:00:1c.0: irq 47 for MSI/MSI-X
> +pcieport-driver 0000:00:1c.0: irq 511 for MSI/MSI-X
>  pci_express 0000:00:1c.0:pcie00: allocate port service
>  pci_express 0000:00:1c.0:pcie02: allocate port service
>  pcieport-driver 0000:00:1c.2: setting latency timer to 64
>  pcieport-driver 0000:00:1c.2: found MSI capability
> -pcieport-driver 0000:00:1c.2: irq 46 for MSI/MSI-X
> +pcieport-driver 0000:00:1c.2: irq 510 for MSI/MSI-X
>  pci_express 0000:00:1c.2:pcie00: allocate port service
>  pci_express 0000:00:1c.2:pcie02: allocate port service
>  pcieport-driver 0000:00:1c.3: setting latency timer to 64
>  pcieport-driver 0000:00:1c.3: found MSI capability
> -pcieport-driver 0000:00:1c.3: irq 45 for MSI/MSI-X
> +pcieport-driver 0000:00:1c.3: irq 509 for MSI/MSI-X
>  pci_express 0000:00:1c.3:pcie00: allocate port service
>  pci_express 0000:00:1c.3:pcie02: allocate port service
>  pcieport-driver 0000:00:1c.4: setting latency timer to 64
>  pcieport-driver 0000:00:1c.4: found MSI capability
> -pcieport-driver 0000:00:1c.4: irq 44 for MSI/MSI-X
> +pcieport-driver 0000:00:1c.4: irq 508 for MSI/MSI-X
>  pci_express 0000:00:1c.4:pcie00: allocate port service
>  pci_express 0000:00:1c.4:pcie02: allocate port service
>  pcieport-driver 0000:00:1c.5: setting latency timer to 64
>  pcieport-driver 0000:00:1c.5: found MSI capability
> -pcieport-driver 0000:00:1c.5: irq 43 for MSI/MSI-X
> +pcieport-driver 0000:00:1c.5: irq 507 for MSI/MSI-X
> [...]
>  ahci 0000:00:1f.2: PCI INT B -> GSI 19 (level, low) -> IRQ 19
> -ahci 0000:00:1f.2: irq 42 for MSI/MSI-X
> +ahci 0000:00:1f.2: irq 506 for MSI/MSI-X
>  ahci 0000:00:1f.2: AHCI 0001.0100 32 slots 4 ports 3 Gbps 0xf impl SATA mode
> [...]
>  e1000e 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
>  e1000e 0000:01:00.0: setting latency timer to 64
> -e1000e 0000:01:00.0: irq 41 for MSI/MSI-X
> +e1000e 0000:01:00.0: irq 505 for MSI/MSI-X
>
> I.e. very similar to the change between rc-3 and rc-7 you commented on
> for my notebook.
>
> Is this really MSI being (not) enabled, or just it using much higher
> IRQ numbers?

because NR_IRQS is increased. and MSI irq is back counting from NR_IRQS - 1.

we have patch in sparse_irq, will start dyn irq for MSI from
nr_irqs_gsi ( the max irq ioapic will use) .. ( according to Thomas)

before that reach mainline, the effects for you is wasting some space
from some big irq_desc[].
but only 450... that is not bad.

YH

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Rafael J. Wysocki]

On Friday, 5 of December 2008, Linus Torvalds wrote:
> 
> On Thu, 4 Dec 2008, Linus Torvalds wrote:
> > 
> > Ok, the ICH6 LPC side has something similar, but not the same. Just two 
> > ranges, and slightly less flexible wrt sizing.
> > 
> > And ICH8/9/10 seems to have the same thing as ICH7.
> 
> Here's a patch that implements what I think is the correct quirks (apart 
> from the commented ICH6 lazy detail I didn't do).
> 
> It would be very interesting to see if people affected get any printouts 
> about IO decodes that don't show up in /proc/ioports...

>From my box:

pci 0000:00:1f.0: quirk: region d800-d87f claimed by ICH6 ACPI/GP IO/TCO
pci 0000:00:1f.0: quirk: region eec0-eeff claimed by ICH6 GPIO
pci 0000:00:1f.0: ICH7 LPC Generic IO decode 1 PIO at 0680 (mask 007f)
pci 0000:00:1f.0: ICH7 LPC Generic IO decode 4 PIO at 01e0 (mask 000f)

The second one shows up in /proc/ioports as "01e0-01ef : pnp 00:09", but the
first one (at 680) doesn't.

Thanks,
Rafael

Re: MSI changes in .28

[Ingo Molnar]

* Frans Pop <elendil@planet.nl> wrote:

> On Tuesday 02 December 2008, Linus Torvalds wrote:
> > So, it looks like you have MSI enabled in -rc6, and not in -rc3.
> 
> I've just compared dmesg for my *desktop* and there I see the following 
> between 2.6.28-rc6 and current 2.6.28-rc7:
> 
>  pcieport-driver 0000:00:1c.0: setting latency timer to 64
>  pcieport-driver 0000:00:1c.0: found MSI capability
> -pcieport-driver 0000:00:1c.0: irq 47 for MSI/MSI-X
> +pcieport-driver 0000:00:1c.0: irq 511 for MSI/MSI-X
>  pci_express 0000:00:1c.0:pcie00: allocate port service
>  pci_express 0000:00:1c.0:pcie02: allocate port service
>  pcieport-driver 0000:00:1c.2: setting latency timer to 64
>  pcieport-driver 0000:00:1c.2: found MSI capability
> -pcieport-driver 0000:00:1c.2: irq 46 for MSI/MSI-X
> +pcieport-driver 0000:00:1c.2: irq 510 for MSI/MSI-X
>  pci_express 0000:00:1c.2:pcie00: allocate port service
>  pci_express 0000:00:1c.2:pcie02: allocate port service
>  pcieport-driver 0000:00:1c.3: setting latency timer to 64
>  pcieport-driver 0000:00:1c.3: found MSI capability
> -pcieport-driver 0000:00:1c.3: irq 45 for MSI/MSI-X
> +pcieport-driver 0000:00:1c.3: irq 509 for MSI/MSI-X
>  pci_express 0000:00:1c.3:pcie00: allocate port service
>  pci_express 0000:00:1c.3:pcie02: allocate port service
>  pcieport-driver 0000:00:1c.4: setting latency timer to 64
>  pcieport-driver 0000:00:1c.4: found MSI capability
> -pcieport-driver 0000:00:1c.4: irq 44 for MSI/MSI-X
> +pcieport-driver 0000:00:1c.4: irq 508 for MSI/MSI-X
>  pci_express 0000:00:1c.4:pcie00: allocate port service
>  pci_express 0000:00:1c.4:pcie02: allocate port service
>  pcieport-driver 0000:00:1c.5: setting latency timer to 64
>  pcieport-driver 0000:00:1c.5: found MSI capability
> -pcieport-driver 0000:00:1c.5: irq 43 for MSI/MSI-X
> +pcieport-driver 0000:00:1c.5: irq 507 for MSI/MSI-X
> [...]
>  ahci 0000:00:1f.2: PCI INT B -> GSI 19 (level, low) -> IRQ 19
> -ahci 0000:00:1f.2: irq 42 for MSI/MSI-X
> +ahci 0000:00:1f.2: irq 506 for MSI/MSI-X
>  ahci 0000:00:1f.2: AHCI 0001.0100 32 slots 4 ports 3 Gbps 0xf impl SATA mode
> [...]
>  e1000e 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
>  e1000e 0000:01:00.0: setting latency timer to 64
> -e1000e 0000:01:00.0: irq 41 for MSI/MSI-X
> +e1000e 0000:01:00.0: irq 505 for MSI/MSI-X
> 
> I.e. very similar to the change between rc-3 and rc-7 you commented on 
> for my notebook.
> 
> Is this really MSI being (not) enabled, or just it using much higher 
> IRQ numbers?

The MSI IRQ number is a pure software detail that was already non-stable 
due to device detection ordering, etc. It's counted back from NR_IRQS, 
and the sizing of NR_IRQS changed (upwards) in 2.6.28 - that's what you 
see.

The fact that MSI numbers goes back from NR_IRQs i consider a (minor) 
misbehavior: it should not count down but should count up - and it should 
not go to unreasonably high numbers if possible - that is confusing to 
users when the sizing of NR_IRQS changes to to a higher NR_CPUS for 
example.

A better (because more human-compatible) numbering scheme is to start 
counting upwards from the high end of physical interrupt lines. We've 
done that in the for-.29 sparseirq tree - there we'll start counting from 
256 upwards in essence. (the first 256 IRQs are GSI interrupts)

Maybe it should be counted starting at 1000? That might be an even more 
human-friendly numbering scheme.

	Ingo

Re: MSI changes in .28

[Eric Dumazet]

Ingo Molnar a écrit :
> The MSI IRQ number is a pure software detail that was already non-stable 
> due to device detection ordering, etc. It's counted back from NR_IRQS, 
> and the sizing of NR_IRQS changed (upwards) in 2.6.28 - that's what you 
> see.
> 
> The fact that MSI numbers goes back from NR_IRQs i consider a (minor) 
> misbehavior: it should not count down but should count up - and it should 
> not go to unreasonably high numbers if possible - that is confusing to 
> users when the sizing of NR_IRQS changes to to a higher NR_CPUS for 
> example.
> 
> A better (because more human-compatible) numbering scheme is to start 
> counting upwards from the high end of physical interrupt lines. We've 
> done that in the for-.29 sparseirq tree - there we'll start counting from 
> 256 upwards in essence. (the first 256 IRQs are GSI interrupts)
> 
> Maybe it should be counted starting at 1000? That might be an even more 
> human-friendly numbering scheme.

I agree a better scheme would be good, given some distros use NR_CPUS=256

I had a (legacy & buggy) program that segfaulted when parsing /proc/stat on new kernel (NR_CPUS=64)

$ cat /proc/stat
cpu  386 0 534 38332 1193 0 7 0 0
cpu0 26 0 101 4757 195 0 0 0 0
cpu1 32 0 29 4884 142 0 1 0 0
cpu2 32 0 93 4727 218 0 1 0 0
cpu3 35 0 55 4829 141 0 1 0 0
cpu4 58 0 53 4810 135 0 0 0 0
cpu5 112 0 47 4755 137 0 0 0 0
cpu6 47 0 95 4754 100 0 0 0 0
cpu7 40 0 57 4813 123 0 0 0 0
intr 38370 123 4 0 0 0 0 0 0 0 0 0 0 5 0 0 0 0 0 0 0 0 0 93 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 771 39 4602 0 0 0 0 0 0 0 0 0
ctxt 110659
btime 1228482025
processes 5163
procs_running 1
procs_blocked 1
$ cat /proc/stat|wc
     15    2406    4980
$ cat /proc/interrupts
           CPU0       CPU1       CPU2       CPU3       CPU4       CPU5       CPU6       CPU7
  0:        122          0          1          0          0          0          0          0   IO-APIC-edge      timer
  1:          1          1          0          0          0          0          1          1   IO-APIC-edge      i8042
  9:          0          0          0          0          0          0          0          0   IO-APIC-fasteoi   acpi
 12:          0          0          1          1          1          2          0          0   IO-APIC-edge      i8042
 14:          0          0          0          0          0          0          0          0   IO-APIC-edge      ide0
 15:          0          0          0          0          0          0          0          0   IO-APIC-edge      ide1
 16:          0          0          0          0          0          0          0          0   IO-APIC-fasteoi   uhci_hcd:usb1
 17:          0          0          0          0          0          0          0          0   IO-APIC-fasteoi   uhci_hcd:usb2
 18:          0          0          0          0          0          0          0          0   IO-APIC-fasteoi   uhci_hcd:usb3
 19:          0          0          0          0          0          0          0          0   IO-APIC-fasteoi   uhci_hcd:usb4
 22:         11         13         11         10         13         13          9         13   IO-APIC-fasteoi   uhci_hcd:usb5
2292:         49         44        119        121        111        110        140        142   PCI-MSI-edge      eth1
2293:          6          6          4          9          7         10          7          5   PCI-MSI-edge      eth0
2294:        637        638        564        557        570        563        549        539   PCI-MSI-edge      cciss0
NMI:          0          0          0          0          0          0          0          0   Non-maskable interrupts
LOC:       5053       4982       3564       3552       3069       3256       3541       2363   Local timer interrupts
RES:         62         83         33         78        150        204         75        179   Rescheduling interrupts
CAL:         55         69         66         64         60         60         63         60   Function call interrupts
TLB:        267        192        253        194        440        354        435        387   TLB shootdowns
TRM:          0          0          0          0          0          0          0          0   Thermal event interrupts
SPU:          0          0          0          0          0          0          0          0   Spurious interrupts
ERR:          0
MIS:          0

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Linus Torvalds]

On Fri, 5 Dec 2008, Rafael J. Wysocki wrote:
> > 
> > It would be very interesting to see if people affected get any printouts 
> > about IO decodes that don't show up in /proc/ioports...
> 
> From my box:
> 
> pci 0000:00:1f.0: quirk: region d800-d87f claimed by ICH6 ACPI/GP IO/TCO
> pci 0000:00:1f.0: quirk: region eec0-eeff claimed by ICH6 GPIO
> pci 0000:00:1f.0: ICH7 LPC Generic IO decode 1 PIO at 0680 (mask 007f)
> pci 0000:00:1f.0: ICH7 LPC Generic IO decode 4 PIO at 01e0 (mask 000f)
> 
> The second one shows up in /proc/ioports as "01e0-01ef : pnp 00:09", but the
> first one (at 680) doesn't.

Ok, so the patch is interesting and probably worth expanding on (to 
actually allocate the regions), but at the same time it too doesn't 
actually explain your problems.

While the kernel doesn't know about that magic 0x680 allocation, it also 
won't be allocating anything over it, since we define PCIBIOS_MIN_IO to 
0x1000 on x86, and will never allocate new resources under that.

		Linus

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Jesse Barnes]

On Thursday, December 4, 2008 7:25 pm Linus Torvalds wrote:
> On Thu, 4 Dec 2008, Linus Torvalds wrote:
> > Ok, the ICH6 LPC side has something similar, but not the same. Just two
> > ranges, and slightly less flexible wrt sizing.
> >
> > And ICH8/9/10 seems to have the same thing as ICH7.
>
> Here's a patch that implements what I think is the correct quirks (apart
> from the commented ICH6 lazy detail I didn't do).
>
> It would be very interesting to see if people affected get any printouts
> about IO decodes that don't show up in /proc/ioports...
>
> And I know I've looked for these kinds of things before in the Intel ICH
> docs, and apparently always missed these things (or been too lazy to
> react), so can somebody else see if they can find any other ranges like
> this? Maybe in non-LPC controllers?
>
> Jesse, are there any Intel chipset people who could once and for all say
> "these are the things we decode in our chipset" for _all_ chipsets and
> _all_ dynamic ranges? I've asked for that before. There must be people who
> know this, without having to wade through many thousands of pages of
> boring datasheets?

Yeah, I can get that info.  Sorry I haven't spent more time on this bug so 
far, I've been on vacation this week and very selective about which mails I 
reply to. :)

> The ICH datasheets tend to be 850 pages each, and there is more than one
> of them. And they _do_ differ in the details, even if there is a lot of
> sharing going on. So reading the docs is a huge effort, when there's bound
> to be somebody who just knows the answer.
>
> NOTE! This patch will just add a _printout_ of the IO regions it finds. It
> won't actually register them as known resources. So it won't make the
> kernel know to avoid them if they were to clash!
>
> Also, see the "This is not correct" for the ICH6 dynamically sized case.

Some of these may be listed as ACPI PNP ranges too...

Jesse

Re: MSI changes in .28

[H. Peter Anvin]

Ingo Molnar wrote:
> 
> The MSI IRQ number is a pure software detail that was already non-stable 
> due to device detection ordering, etc. It's counted back from NR_IRQS, 
> and the sizing of NR_IRQS changed (upwards) in 2.6.28 - that's what you 
> see.
> 
> The fact that MSI numbers goes back from NR_IRQs i consider a (minor) 
> misbehavior: it should not count down but should count up - and it should 
> not go to unreasonably high numbers if possible - that is confusing to 
> users when the sizing of NR_IRQS changes to to a higher NR_CPUS for 
> example.
> 
> A better (because more human-compatible) numbering scheme is to start 
> counting upwards from the high end of physical interrupt lines. We've 
> done that in the for-.29 sparseirq tree - there we'll start counting from 
> 256 upwards in essence. (the first 256 IRQs are GSI interrupts)
> 

Although it's kind of broken to limit the number of GSI interrupts to
256, at least for HyperTransport systems where you can have MSIs that
look like IOAPICs (although discovered using a slightly different
mechanism.)

This also means, at least in theory, that IOAPICs could be discovered at
runtime!

> Maybe it should be counted starting at 1000? That might be an even more 
> human-friendly numbering scheme.

Personally I think we should just fix the legacy PIC and southbridge
IOAPIC at zero, and let everything grow up from there.  We'll assign
IOAPIC numbers first just by virtue of them being discovered first, but
I don't really see a huge need to partition the space.

Assigning them numbers starting with 1000 does stand out, of course;
however, if we do that then we really need to make sure we don't run
into ugly surprises on HT systems.  On the other hand, perhaps none will
ever be built, since newer HT silicon is likely to use MSI-X rather than
MSI-HT just for compatiblity.

	-hpa

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Linus Torvalds]

On Thu, 4 Dec 2008, Linus Torvalds wrote:
> 
> The third thing that worries me is the _very_ early occurrence of
> 
> 	ACPI: Waking up from system sleep state S3
> 	APIC error on CPU1: 00(40)
> 	ACPI: EC: non-query interrupt received, switching to interrupt mode
> 
> Now, that "APIC error" thing is worrisome. It's worrisome for multiple 
> reasons:
> 
>  - errors are never good (0x40 means "received illegal vector", whatever 
>    caused _that_)
> 
>  - more importantly, it seems to imply that interrupts are enabled on 
>    CPU1, and they sure as hell shouldn't be enabled at this stage!
> 
>    Do we perhaps have a SMP resume bug where we resume the other CPU's 
>    with interrupts enabled?
> 
>  - the "ACPI: EC: non-query interrupt received, switching to interrupt 
>    mode" thing is from ACPI, and _also_ implies that interrupts are on. 
> 
> Why are interrupts enabled that early? I really don't like seeing 
> interrupts enabled before we've even done the basic PCI resume. 

Oh, I finally started looking more at this.

It's because the PCI layer uses the late resume for resuming. Which is 
horrid. It really shouldn't. Resuming your device after interrupts were 
enabled really sounds like a disaster. *Especially* if the device was 
active before, either because of hibernation or simply because firmware 
pre-initialized it to some "live" state (which could easily happen with 
ethernet in particular).

I do wonder why the PCI layer wants to resume things so late. It sounds 
totally insane to do things like resume the PCI bridge setup long *after* 
you have resumed other devices early. So by doing the default resume late, 
it just means that nobody can possibly use the early resume, and now 
everybody needs to resume everything with interrupts already going full 
blast.

IOW, the _sane_ thing would be to do something like the following patch 
does, namely:

 - if the driver has a suspend or suspend_early function, _only_ call that 
   (whether legacy or not)

 - otherwise, do the default suspend/resume late/early with interrupts 
   disabled.

which means that by default, we'll do all save-restore of the PCI state 
close to the actual CPU suspend event as possible.

Of course, hibernate probably depends on ->suspend() saving state, which 
it won't. Again, if thats' the case, then that's just hibernate (again) 
being totally fundamentally broken, and messing with STR functions. 

Rafael?

I have neither tested the patch nor even tried to compile it - it's meant 
to be an example and get people thinking about this, rather than anything 
else.

		Linus
---
 drivers/pci/pci-driver.c |   20 ++++++++++----------
 1 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
index b4cdd69..6395983 100644
--- a/drivers/pci/pci-driver.c
+++ b/drivers/pci/pci-driver.c
@@ -346,8 +346,6 @@ static int pci_legacy_suspend(struct device *dev, pm_message_t state)
 	if (drv && drv->suspend) {
 		i = drv->suspend(pci_dev, state);
 		suspend_report_result(drv->suspend, i);
-	} else {
-		pci_default_pm_suspend(pci_dev);
 	}
 	return i;
 }
@@ -361,7 +359,8 @@ static int pci_legacy_suspend_late(struct device *dev, pm_message_t state)
 	if (drv && drv->suspend_late) {
 		i = drv->suspend_late(pci_dev, state);
 		suspend_report_result(drv->suspend_late, i);
-	}
+	} else if (!drv || !drv->suspend)
+		pci_default_pm_suspend(pci_dev);
 	return i;
 }
 
@@ -373,8 +372,6 @@ static int pci_legacy_resume(struct device *dev)
 
 	if (drv && drv->resume)
 		error = drv->resume(pci_dev);
-	else
-		error = pci_default_pm_resume(pci_dev);
 	return error;
 }
 
@@ -386,6 +383,8 @@ static int pci_legacy_resume_early(struct device *dev)
 
 	if (drv && drv->resume_early)
 		error = drv->resume_early(pci_dev);
+	else if (!drv || !drv->resume)
+		error = pci_default_pm_resume(pci_dev);
 	return error;
 }
 
@@ -420,8 +419,6 @@ static int pci_pm_suspend(struct device *dev)
 		if (drv->pm->suspend) {
 			error = drv->pm->suspend(dev);
 			suspend_report_result(drv->pm->suspend, error);
-		} else {
-			pci_default_pm_suspend(pci_dev);
 		}
 	} else {
 		error = pci_legacy_suspend(dev, PMSG_SUSPEND);
@@ -441,7 +438,8 @@ static int pci_pm_suspend_noirq(struct device *dev)
 		if (drv->pm->suspend_noirq) {
 			error = drv->pm->suspend_noirq(dev);
 			suspend_report_result(drv->pm->suspend_noirq, error);
-		}
+		} else if (!drv->pm->suspend)
+			pci_default_pm_suspend(pci_dev);
 	} else {
 		error = pci_legacy_suspend_late(dev, PMSG_SUSPEND);
 	}
@@ -458,8 +456,7 @@ static int pci_pm_resume(struct device *dev)
 	pci_fixup_device(pci_fixup_resume, pci_dev);
 
 	if (drv && drv->pm) {
-		error = drv->pm->resume ? drv->pm->resume(dev) :
-			pci_default_pm_resume(pci_dev);
+		error = drv->pm->resume ? drv->pm->resume(dev) : 0;
 	} else {
 		error = pci_legacy_resume(dev);
 	}
@@ -467,6 +464,7 @@ static int pci_pm_resume(struct device *dev)
 	return error;
 }
 
+
 static int pci_pm_resume_noirq(struct device *dev)
 {
 	struct pci_dev *pci_dev = to_pci_dev(dev);
@@ -478,6 +476,8 @@ static int pci_pm_resume_noirq(struct device *dev)
 	if (drv && drv->pm) {
 		if (drv->pm->resume_noirq)
 			error = drv->pm->resume_noirq(dev);
+		else if (!drv->pm->resume)
+			error = pci_default_pm_resume(pci_dev);
 	} else {
 		error = pci_legacy_resume_early(dev);
 	}

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Rafael J. Wysocki]

On Friday, 5 of December 2008, Linus Torvalds wrote:
> 
> On Fri, 5 Dec 2008, Rafael J. Wysocki wrote:
> > > 
> > > It would be very interesting to see if people affected get any printouts 
> > > about IO decodes that don't show up in /proc/ioports...
> > 
> > From my box:
> > 
> > pci 0000:00:1f.0: quirk: region d800-d87f claimed by ICH6 ACPI/GP IO/TCO
> > pci 0000:00:1f.0: quirk: region eec0-eeff claimed by ICH6 GPIO
> > pci 0000:00:1f.0: ICH7 LPC Generic IO decode 1 PIO at 0680 (mask 007f)
> > pci 0000:00:1f.0: ICH7 LPC Generic IO decode 4 PIO at 01e0 (mask 000f)
> > 
> > The second one shows up in /proc/ioports as "01e0-01ef : pnp 00:09", but the
> > first one (at 680) doesn't.
> 
> Ok, so the patch is interesting and probably worth expanding on (to 
> actually allocate the regions), but at the same time it too doesn't 
> actually explain your problems.
> 
> While the kernel doesn't know about that magic 0x680 allocation, it also 
> won't be allocating anything over it, since we define PCIBIOS_MIN_IO to 
> 0x1000 on x86, and will never allocate new resources under that.

In the meantime I did some more debugging with unpatched mainline and found
that if resume from hibernation fails, it usually fails immediately after
resuming the SATA controller (once it apparently failed right after resuming
EHCI, but then it just might be a problem with printing more messages), where
the resume sequence is (again, for easier reference):

pci:0000:00:00.0
pci:0000:00:02.0 <- graphics
pci:0000:00:02.1 <- graphics
pci:0000:00:1b.0 <- snd_hda_intel
pci:0000:00:1c.0 <- PCI Express port 1
pci:0000:00:1c.2 <- PCI Express port 3
pci:0000:00:1d.0 <- USB UHCI
pci:0000:00:1d.1 <- USB UHCI
pci:0000:00:1d.2 <- USB UHCI
pci:0000:00:1d.3 <- USB UHCI
pci:0000:00:1d.7 <- USB EHCI
pci:0000:00:1e.0 <- transparent bridge (Intel Corporation 82801 Mobile PCI Bridge)
pci:0000:00:1f.0 <- ISA bridge
pci:0000:00:1f.2 <- SATA (ahci)

--> so it usually hangs here or during the e1000e resume (I don't
get any messages from e1000e in the failing cycles, though).

pci:0000:01:00.0 <- e1000e
No Bus:0000:01
pci:0000:02:00.0 <- wireless (iwlagn)
No Bus:0000:02
pci:0000:03:0b.0 <- cardbus bridge
pci:0000:03:0b.1 <- FireWire
pci:0000:03:0b.3 <- SD Host controller (Texas Instruments)
No Bus:0000:04
No Bus:0000:03

Interestingly enough, usually after a failure some messages still get printed
into the screen (eg. messages from the ACPI battery driver) and the keyboard
sort of works, although the keys are not decoded correctly.

Next, as I was unable to get anything with the help of magic sysrq, so I tried
to boot the kernel with nmi_watchdog=1 and in this configuration I could not
reproduce the problem.  This clearly indicates that this really is a timing
issue.

I also noticed two things that may or may not be relevant.

First, the snd_hda_intel device is a PCI Express endpoind integrated into the
root complex which is the host bridge in this case.  This may be relevant since
unloading the snd_hda_intel driver makes things work 100% of the time.

Second, the transparent bridge 0000:00:1e.0 does supports subtractive
decoding, so if there is a device doing subtractive decode behind it (the
cardbus bridge may do that, for example) it will claim any transaction not
claimed by any other device on bus 0.

Next, I'm going to hack the magic sysrq so that it will allow me to get a stack
dump after a resume failure and I will add some debug printks to the PCI
resume code path.

Thanks,
Rafael

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Rafael J. Wysocki]

On Friday, 5 of December 2008, Linus Torvalds wrote:
> 
> On Thu, 4 Dec 2008, Linus Torvalds wrote:
> > 
> > The third thing that worries me is the _very_ early occurrence of
> > 
> > 	ACPI: Waking up from system sleep state S3
> > 	APIC error on CPU1: 00(40)
> > 	ACPI: EC: non-query interrupt received, switching to interrupt mode
> > 
> > Now, that "APIC error" thing is worrisome. It's worrisome for multiple 
> > reasons:
> > 
> >  - errors are never good (0x40 means "received illegal vector", whatever 
> >    caused _that_)
> > 
> >  - more importantly, it seems to imply that interrupts are enabled on 
> >    CPU1, and they sure as hell shouldn't be enabled at this stage!
> > 
> >    Do we perhaps have a SMP resume bug where we resume the other CPU's 
> >    with interrupts enabled?
> > 
> >  - the "ACPI: EC: non-query interrupt received, switching to interrupt 
> >    mode" thing is from ACPI, and _also_ implies that interrupts are on. 
> > 
> > Why are interrupts enabled that early? I really don't like seeing 
> > interrupts enabled before we've even done the basic PCI resume. 
> 
> Oh, I finally started looking more at this.
> 
> It's because the PCI layer uses the late resume for resuming. Which is 
> horrid. It really shouldn't. Resuming your device after interrupts were 
> enabled really sounds like a disaster. *Especially* if the device was 
> active before, either because of hibernation or simply because firmware 
> pre-initialized it to some "live" state (which could easily happen with 
> ethernet in particular).
> 
> I do wonder why the PCI layer wants to resume things so late. It sounds 
> totally insane to do things like resume the PCI bridge setup long *after* 
> you have resumed other devices early. So by doing the default resume late, 
> it just means that nobody can possibly use the early resume, and now 
> everybody needs to resume everything with interrupts already going full 
> blast.
> 
> IOW, the _sane_ thing would be to do something like the following patch 
> does, namely:
> 
>  - if the driver has a suspend or suspend_early function, _only_ call that 
>    (whether legacy or not)
> 
>  - otherwise, do the default suspend/resume late/early with interrupts 
>    disabled.
> 
> which means that by default, we'll do all save-restore of the PCI state 
> close to the actual CPU suspend event as possible.
> 
> Of course, hibernate probably depends on ->suspend() saving state, which 
> it won't. Again, if thats' the case, then that's just hibernate (again) 
> being totally fundamentally broken, and messing with STR functions. 

No, hibernate doesn't care whether ->suspend() or ->suspend_late() saves
the state, if that's what you mean.  Also, we have the hibernation-specific
callbacks in the new framework anyway.

> Rafael?

Well, actually I think we should go further and save the standard config
registers of _all_ PCI devices in the _late() callbacks (ie. with interrupts
disabled) and restore them in the _early() callbacks.

I don't really understand why pci_restore_state() is not called by the core
and every single driver calls it by itself.  Moreover, many of them
call pci_set_power_state(dev, PCI_D0) before calling pci_restore_state(),
although this is not really necessary, because they subsequently call
pci_enable_device() which calls pci_set_power_state(dev, PCI_D0) again.

IOW, I would split the resume of PCI devices into two parts, the first of
which will call pci_restore_state() with interrupts disabled and the second
will do the remaining stuff.

> I have neither tested the patch nor even tried to compile it - it's meant 
> to be an example and get people thinking about this, rather than anything 
> else.

I'm going to try it, though, and see what happens. ;-)

Thanks,
Rafael


> ---
>  drivers/pci/pci-driver.c |   20 ++++++++++----------
>  1 files changed, 10 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
> index b4cdd69..6395983 100644
> --- a/drivers/pci/pci-driver.c
> +++ b/drivers/pci/pci-driver.c
> @@ -346,8 +346,6 @@ static int pci_legacy_suspend(struct device *dev, pm_message_t state)
>  	if (drv && drv->suspend) {
>  		i = drv->suspend(pci_dev, state);
>  		suspend_report_result(drv->suspend, i);
> -	} else {
> -		pci_default_pm_suspend(pci_dev);
>  	}
>  	return i;
>  }
> @@ -361,7 +359,8 @@ static int pci_legacy_suspend_late(struct device *dev, pm_message_t state)
>  	if (drv && drv->suspend_late) {
>  		i = drv->suspend_late(pci_dev, state);
>  		suspend_report_result(drv->suspend_late, i);
> -	}
> +	} else if (!drv || !drv->suspend)
> +		pci_default_pm_suspend(pci_dev);
>  	return i;
>  }
>  
> @@ -373,8 +372,6 @@ static int pci_legacy_resume(struct device *dev)
>  
>  	if (drv && drv->resume)
>  		error = drv->resume(pci_dev);
> -	else
> -		error = pci_default_pm_resume(pci_dev);
>  	return error;
>  }
>  
> @@ -386,6 +383,8 @@ static int pci_legacy_resume_early(struct device *dev)
>  
>  	if (drv && drv->resume_early)
>  		error = drv->resume_early(pci_dev);
> +	else if (!drv || !drv->resume)
> +		error = pci_default_pm_resume(pci_dev);
>  	return error;
>  }
>  
> @@ -420,8 +419,6 @@ static int pci_pm_suspend(struct device *dev)
>  		if (drv->pm->suspend) {
>  			error = drv->pm->suspend(dev);
>  			suspend_report_result(drv->pm->suspend, error);
> -		} else {
> -			pci_default_pm_suspend(pci_dev);
>  		}
>  	} else {
>  		error = pci_legacy_suspend(dev, PMSG_SUSPEND);
> @@ -441,7 +438,8 @@ static int pci_pm_suspend_noirq(struct device *dev)
>  		if (drv->pm->suspend_noirq) {
>  			error = drv->pm->suspend_noirq(dev);
>  			suspend_report_result(drv->pm->suspend_noirq, error);
> -		}
> +		} else if (!drv->pm->suspend)
> +			pci_default_pm_suspend(pci_dev);
>  	} else {
>  		error = pci_legacy_suspend_late(dev, PMSG_SUSPEND);
>  	}
> @@ -458,8 +456,7 @@ static int pci_pm_resume(struct device *dev)
>  	pci_fixup_device(pci_fixup_resume, pci_dev);
>  
>  	if (drv && drv->pm) {
> -		error = drv->pm->resume ? drv->pm->resume(dev) :
> -			pci_default_pm_resume(pci_dev);
> +		error = drv->pm->resume ? drv->pm->resume(dev) : 0;
>  	} else {
>  		error = pci_legacy_resume(dev);
>  	}
> @@ -467,6 +464,7 @@ static int pci_pm_resume(struct device *dev)
>  	return error;
>  }
>  
> +
>  static int pci_pm_resume_noirq(struct device *dev)
>  {
>  	struct pci_dev *pci_dev = to_pci_dev(dev);
> @@ -478,6 +476,8 @@ static int pci_pm_resume_noirq(struct device *dev)
>  	if (drv && drv->pm) {
>  		if (drv->pm->resume_noirq)
>  			error = drv->pm->resume_noirq(dev);
> +		else if (!drv->pm->resume)
> +			error = pci_default_pm_resume(pci_dev);
>  	} else {
>  		error = pci_legacy_resume_early(dev);
>  	}
> 
> 



-- 
Everyone knows that debugging is twice as hard as writing a program
in the first place.  So if you're as clever as you can be when you write it,
how will you ever debug it? --- Brian Kernighan

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Linus Torvalds]

On Fri, 5 Dec 2008, Rafael J. Wysocki wrote:
> 
> Well, actually I think we should go further and save the standard config
> registers of _all_ PCI devices in the _late() callbacks (ie. with interrupts
> disabled) and restore them in the _early() callbacks.

That would certainly simplify the code. 

> I don't really understand why pci_restore_state() is not called by the core
> and every single driver calls it by itself.

The idea was to allow PCI drivers to override it if they wanted to.

That said, the ones that do their own state restore generally do it wrong 
(eg the USB host controllers doing things in the wrong order and enabling 
the device before having actually written back the BAR values), so it's 
arguably broken to let drivers override it.

> IOW, I would split the resume of PCI devices into two parts, the first of
> which will call pci_restore_state() with interrupts disabled and the second
> will do the remaining stuff.

I would definitely not disagree with that - leave the regular 
"suspend/resume" callbacks for purely higher-level actions. It would 
interesting to hear what it does for you.

			Linus

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Rafael J. Wysocki]

On Friday, 5 of December 2008, Linus Torvalds wrote:
> 
> On Fri, 5 Dec 2008, Rafael J. Wysocki wrote:
> > 
> > Well, actually I think we should go further and save the standard config
> > registers of _all_ PCI devices in the _late() callbacks (ie. with interrupts
> > disabled) and restore them in the _early() callbacks.
> 
> That would certainly simplify the code. 
> 
> > I don't really understand why pci_restore_state() is not called by the core
> > and every single driver calls it by itself.
> 
> The idea was to allow PCI drivers to override it if they wanted to.
> 
> That said, the ones that do their own state restore generally do it wrong 
> (eg the USB host controllers doing things in the wrong order and enabling 
> the device before having actually written back the BAR values), so it's 
> arguably broken to let drivers override it.
> 
> > IOW, I would split the resume of PCI devices into two parts, the first of
> > which will call pci_restore_state() with interrupts disabled and the second
> > will do the remaining stuff.
> 
> I would definitely not disagree with that - leave the regular 
> "suspend/resume" callbacks for purely higher-level actions. It would 
> interesting to hear what it does for you.

I tested the appended patch with suspend-to-RAM and it just hangs during
resume.

Next, I'll try to do that only for devices the drivers of which don't define their own
suspend-resume callbacks at all.

Thanks,
Rafael

---
 drivers/pci/pci-driver.c |   50 ++++++++++++++++++++++++++++++++++++++++++++---
 1 file changed, 47 insertions(+), 3 deletions(-)

Index: linux-2.6/drivers/pci/pci-driver.c
===================================================================
--- linux-2.6.orig/drivers/pci/pci-driver.c
+++ linux-2.6/drivers/pci/pci-driver.c
@@ -300,6 +300,46 @@ static void pci_device_shutdown(struct d
 
 #ifdef CONFIG_PM_SLEEP
 
+static void pci_default_suspend_noirq(struct pci_dev *pci_dev)
+{
+	dev_info(&pci_dev->dev, "saving standard PCI config registers\n");
+
+	/* save the PCI config space */
+	pci_save_state(pci_dev);
+	/*
+	 * mark its power state as "unknown", since we don't know if
+	 * e.g. the BIOS will change its device state when we suspend.
+	 */
+	if (pci_dev->current_state == PCI_D0)
+		pci_dev->current_state = PCI_UNKNOWN;
+}
+
+static void pci_default_resume_noirq(struct pci_dev *pci_dev)
+{
+	dev_info(&pci_dev->dev, "restoring standard PCI config registers\n");
+
+	/* restore the PCI config space */
+	pci_restore_state(pci_dev);
+}
+
+static int pci_default_resume(struct pci_dev *pci_dev)
+{
+	int retval = 0;
+
+	dev_info(&pci_dev->dev, "trying to reenable device\n");
+
+	/* if the device was enabled before suspend, reenable */
+	retval = pci_reenable_device(pci_dev);
+	/*
+	 * if the device was busmaster before the suspend, make it busmaster
+	 * again
+	 */
+	if (pci_dev->is_busmaster)
+		pci_set_master(pci_dev);
+
+	return retval;
+}
+
 /*
  * Default "suspend" method for devices that have no driver provided suspend,
  * or not even a driver at all.
@@ -346,8 +386,6 @@ static int pci_legacy_suspend(struct dev
 	if (drv && drv->suspend) {
 		i = drv->suspend(pci_dev, state);
 		suspend_report_result(drv->suspend, i);
-	} else {
-		pci_default_pm_suspend(pci_dev);
 	}
 	return i;
 }
@@ -362,6 +400,9 @@ static int pci_legacy_suspend_late(struc
 		i = drv->suspend_late(pci_dev, state);
 		suspend_report_result(drv->suspend_late, i);
 	}
+
+	pci_default_suspend_noirq(pci_dev);
+
 	return i;
 }
 
@@ -374,7 +415,7 @@ static int pci_legacy_resume(struct devi
 	if (drv && drv->resume)
 		error = drv->resume(pci_dev);
 	else
-		error = pci_default_pm_resume(pci_dev);
+		error = pci_default_resume(pci_dev);
 	return error;
 }
 
@@ -384,8 +425,11 @@ static int pci_legacy_resume_early(struc
 	struct pci_dev * pci_dev = to_pci_dev(dev);
 	struct pci_driver * drv = pci_dev->driver;
 
+	pci_default_resume_noirq(pci_dev);
+
 	if (drv && drv->resume_early)
 		error = drv->resume_early(pci_dev);
+
 	return error;
 }
 

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Linus Torvalds]

On Sat, 6 Dec 2008, Rafael J. Wysocki wrote:
> 
> I tested the appended patch with suspend-to-RAM and it just hangs during
> resume.

That patch looks bogus. It only changes the "legacy" cases as far as I can 
tell, so anybogy who has drv->pm set will now not do any state save at 
all.

Or am I misreading it?

		Linus

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Rafael J. Wysocki]

On Saturday, 6 of December 2008, Linus Torvalds wrote:
> 
> On Sat, 6 Dec 2008, Rafael J. Wysocki wrote:
> > 
> > I tested the appended patch with suspend-to-RAM and it just hangs during
> > resume.
> 
> That patch looks bogus. It only changes the "legacy" cases as far as I can 
> tell, so anybogy who has drv->pm set will now not do any state save at 
> all.
> 
> Or am I misreading it?

It only affects the legacy handling, but the non-legacy handling was left
untouched.  IOW, the old "default" functions are still there and are being
called by the "non-legacy" code (it's only used by USB at the moment, AFAICS).

Anyway, I did the test doing it only to the devices which don't have any
non-default suspend-resume handling at all and _that_ apparently fixed the
problem on my box. :-)

Appended is a very crude version of the patch (it duplicates some code),
tomorrow I'll post a cleaned-up version.

I'm still thinkig it will be reasonable to save standard config registers for
all devices with interrupts disabled, but that appears to be more complicated
that I thought it would be.

Thanks,
Rafael

---
 drivers/pci/pci-driver.c |   66 +++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 66 insertions(+)

Index: linux-2.6/drivers/pci/pci-driver.c
===================================================================
--- linux-2.6.orig/drivers/pci/pci-driver.c
+++ linux-2.6/drivers/pci/pci-driver.c
@@ -300,6 +300,54 @@ static void pci_device_shutdown(struct d
 
 #ifdef CONFIG_PM_SLEEP
 
+static void pci_default_suspend_noirq(struct pci_dev *pci_dev)
+{
+	dev_info(&pci_dev->dev, "saving standard PCI config registers\n");
+
+	/* save the PCI config space */
+	pci_save_state(pci_dev);
+	/*
+	 * mark its power state as "unknown", since we don't know if
+	 * e.g. the BIOS will change its device state when we suspend.
+	 */
+	if (pci_dev->current_state == PCI_D0)
+		pci_dev->current_state = PCI_UNKNOWN;
+}
+
+static void pci_default_resume_noirq(struct pci_dev *pci_dev)
+{
+	dev_info(&pci_dev->dev, "restoring standard PCI config registers\n");
+
+	/* restore the PCI config space */
+	pci_restore_state(pci_dev);
+}
+
+static int pci_default_resume(struct pci_dev *pci_dev)
+{
+	int retval = 0;
+
+	dev_info(&pci_dev->dev, "trying to reenable device\n");
+
+	/* if the device was enabled before suspend, reenable */
+	retval = pci_reenable_device(pci_dev);
+	/*
+	 * if the device was busmaster before the suspend, make it busmaster
+	 * again
+	 */
+	if (pci_dev->is_busmaster)
+		pci_set_master(pci_dev);
+
+	return retval;
+}
+
+static bool pci_has_legacy_pm_handling(struct pci_dev *pci_dev)
+{
+	struct pci_driver *drv = pci_dev->driver;
+
+	return drv && (drv->suspend || drv->suspend_late || drv->resume
+		|| drv->resume_early);
+}
+
 /*
  * Default "suspend" method for devices that have no driver provided suspend,
  * or not even a driver at all.
@@ -343,6 +391,9 @@ static int pci_legacy_suspend(struct dev
 	struct pci_driver * drv = pci_dev->driver;
 	int i = 0;
 
+	if (!pci_has_legacy_pm_handling(pci_dev))
+		return 0;
+
 	if (drv && drv->suspend) {
 		i = drv->suspend(pci_dev, state);
 		suspend_report_result(drv->suspend, i);
@@ -358,10 +409,16 @@ static int pci_legacy_suspend_late(struc
 	struct pci_driver * drv = pci_dev->driver;
 	int i = 0;
 
+	if (!pci_has_legacy_pm_handling(pci_dev)) {
+		pci_default_suspend_noirq(pci_dev);
+		return 0;
+	}
+
 	if (drv && drv->suspend_late) {
 		i = drv->suspend_late(pci_dev, state);
 		suspend_report_result(drv->suspend_late, i);
 	}
+
 	return i;
 }
 
@@ -371,6 +428,9 @@ static int pci_legacy_resume(struct devi
 	struct pci_dev * pci_dev = to_pci_dev(dev);
 	struct pci_driver * drv = pci_dev->driver;
 
+	if (!pci_has_legacy_pm_handling(pci_dev))
+		return pci_default_resume(pci_dev);
+
 	if (drv && drv->resume)
 		error = drv->resume(pci_dev);
 	else
@@ -384,8 +444,14 @@ static int pci_legacy_resume_early(struc
 	struct pci_dev * pci_dev = to_pci_dev(dev);
 	struct pci_driver * drv = pci_dev->driver;
 
+	if (!pci_has_legacy_pm_handling(pci_dev)) {
+		pci_default_resume_noirq(pci_dev);
+		return 0;
+	}
+
 	if (drv && drv->resume_early)
 		error = drv->resume_early(pci_dev);
+
 	return error;
 }
 

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Linus Torvalds]

On Sat, 6 Dec 2008, Rafael J. Wysocki wrote:
>
> It only affects the legacy handling, but the non-legacy handling was left
> untouched.  IOW, the old "default" functions are still there and are being
> called by the "non-legacy" code (it's only used by USB at the moment, AFAICS).

Ok.

> Anyway, I did the test doing it only to the devices which don't have any
> non-default suspend-resume handling at all and _that_ apparently fixed the
> problem on my box. :-)

Which makes sense, btw. Because if you do the pci_save_state() on a device 
that _does_ have a suspend function, you'll be saving the post-suspend 
state - ie the device turned off.

So yeah, we really can only do the default suspend if the device has no 
pre-existing suspend function - or we'd need to make sure that all PCI 
drivers that do have suspend functions would only do the higher-level 
functionality.

Anyway, what I'm most interested in hearing is whether this actually 
improves your situation. I can _easily_ see that your resume problem could 
be due to interrupt timing. That's especially true if there are shared 
interrupts, but even in the absense of that, I'm not at all sure that the 
e1000e resume code is interrupt-safe, for example.

		Linus

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Rafael J. Wysocki]

On Saturday, 6 of December 2008, Linus Torvalds wrote:
> 
> On Sat, 6 Dec 2008, Rafael J. Wysocki wrote:
> >
> > It only affects the legacy handling, but the non-legacy handling was left
> > untouched.  IOW, the old "default" functions are still there and are being
> > called by the "non-legacy" code (it's only used by USB at the moment, AFAICS).
> 
> Ok.
> 
> > Anyway, I did the test doing it only to the devices which don't have any
> > non-default suspend-resume handling at all and _that_ apparently fixed the
> > problem on my box. :-)
> 
> Which makes sense, btw. Because if you do the pci_save_state() on a device 
> that _does_ have a suspend function, you'll be saving the post-suspend 
> state - ie the device turned off.
> 
> So yeah, we really can only do the default suspend if the device has no 
> pre-existing suspend function - or we'd need to make sure that all PCI 
> drivers that do have suspend functions would only do the higher-level 
> functionality.
> 
> Anyway, what I'm most interested in hearing is whether this actually 
> improves your situation.

Yes, it does, from what I can tell at the moment. :-)

Tomorrow I'll do more testing to (hopefully) confirm that.

> I can _easily_ see that your resume problem could be due to interrupt
> timing. That's especially true if there are shared interrupts, but even in
> the absense of that, I'm not at all sure that the e1000e resume code is
> interrupt-safe, for example. 

Agreed.

Thanks,
Rafael

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Greg KH]

On Fri, Dec 05, 2008 at 05:55:16PM -0800, Linus Torvalds wrote:
> 
> 
> On Sat, 6 Dec 2008, Rafael J. Wysocki wrote:
> >
> > It only affects the legacy handling, but the non-legacy handling was left
> > untouched.  IOW, the old "default" functions are still there and are being
> > called by the "non-legacy" code (it's only used by USB at the moment, AFAICS).
> 
> Ok.
> 
> > Anyway, I did the test doing it only to the devices which don't have any
> > non-default suspend-resume handling at all and _that_ apparently fixed the
> > problem on my box. :-)
> 
> Which makes sense, btw. Because if you do the pci_save_state() on a device 
> that _does_ have a suspend function, you'll be saving the post-suspend 
> state - ie the device turned off.

I think that is why we did not do it for every device, we didn't want to
touch drivers that already had working suspend calls.

> So yeah, we really can only do the default suspend if the device has no 
> pre-existing suspend function - or we'd need to make sure that all PCI 
> drivers that do have suspend functions would only do the higher-level 
> functionality.

Agreed.

thanks,

greg k-h

[patch,rfc] usb: restore config before enabling device on resume

[Frans Pop]

[-- Attachment #1: Type: text/plain, Size: 3331 bytes --]

On Thursday 04 December 2008, Linus Torvalds wrote:
> Greg, Jesse, can you think about and look at the USB PCI resume
> ordering?
[...]
> In many ways the bigger worry is actually in the totally unrelated USB
> UHCI and EHCI drivers that resume _before_ the bridge does:
>
> 	uhci_hcd 0000:00:1d.2: enabling device (0000 -> 0001)
> 	uhci_hcd 0000:00:1d.2: PCI INT C -> GSI 18 (level, low) -> IRQ 18
> 	uhci_hcd 0000:00:1d.2: setting latency timer to 64
> 	uhci_hcd 0000:00:1d.2: restoring config space at offset 0xf (was 0x300, writing 0x30b)
>	uhci_hcd 0000:00:1d.2: restoring config space at offset 0x8 (was 0x1, writing 0x2101)
>	usb usb7: root hub lost power or was reset
> 	ehci_hcd 0000:00:1d.7: enabling device (0000 -> 0002)
> 	ehci_hcd 0000:00:1d.7: PCI INT A -> GSI 20 (level, low) -> IRQ 20
> 	ehci_hcd 0000:00:1d.7: setting latency timer to 64
> 	ehci_hcd 0000:00:1d.7: restoring config space at offset 0xf (was 0x100, writing 0x10a)
>	ehci_hcd 0000:00:1d.7: restoring config space at offset 0x4 (was 0x0, writing 0xe0648000)
>
> and the worry I have here is that we actually enable the device
> _before_ we've restored the BAR information. That sounds very iffy. It
> sounds doubly iffy in the 'resume from hibernate' case, where we are
> going to have an already-set-up PCI bus and the config space values are
> going to all be live as we reprogram them.
>
> That "restoring config space at offset 0x8" thing is where we restore
> the BAR (dword 0x8 = offset 0x20 = PCI_BASE_ADDRESS_4), and we're
> changing it from 0x1 to 0x2101, with the IO BAR enabled. In this case,
> the old value meant that the BAR started out disabled, but hibernate
> would have been different.
>
> So I'd _much_ rather have seen the sequence have the BAR restore
> sequence be something like
>
> 	uhci_hcd 0000:00:1d.2: restoring config space at offset 0xf (was 0x300, writing 0x30b)
>	uhci_hcd 0000:00:1d.2: restoring config space at offset 0x8 (was 0x1, writing 0x2101)
>	uhci_hcd 0000:00:1d.2: enabling device (0000 -> 0001)
> 	uhci_hcd 0000:00:1d.2: PCI INT C -> GSI 18 (level, low) -> IRQ 18
> 	uhci_hcd 0000:00:1d.2: setting latency timer to 64
>
> instead. Possibly even with an explicit disable of the
> memory/IO/busmaster bits before the whole sequence.

I've taken a very naive look at this, basically by comparing what usb
(usb/core/hcd-pci.c) is doing compared to other drivers.

I used the following command to get an overview:
$ git grep -E -n -C5 "pci_(enable_device|set_master|restore_state|power_state.*D0)"
(The line numbers give some indication whether work is split over functions.)

Most drivers seem to do some variation of the following, which looks
logical and is in line with Documentation/power/pci.txt:
pci_set_power_state(dev, PCI_D0);
pci_restore_state(dev);
pci_enable_device(dev);
pci_set_master(dev);

But quite a lot of drivers (including usb and e.g. ide/setup-pci.c) do
something like:
pci_enable_device(dev);
pci_set_master(dev);
pci_restore_state(dev);

Maybe the whole tree should get a review for this?

Anyway, I gave the patch below a try on both my notebook and desktop.
My desktop has USB keyboard and mouse and the notebook has wireless and
a fingerprint scanner on USB. Everything still worked after resume.

Diff of the resume dmesg of my motebook attached. Looks better I think?

Cheers,
FJP


[-- Attachment #2: usb_resume.patch --]
[-- Type: text/x-diff, Size: 1107 bytes --]

From: Frans Pop <elendil@planet.nl>

usb: restore state before enabling device on resume
    
When resuming from suspend, restore the PCI config before
enabling the device.
    
Signed-off-by: Frans Pop <elendil@planet.nl>

diff --git a/drivers/usb/core/hcd-pci.c b/drivers/usb/core/hcd-pci.c
index 5b87ae7..85bcd80 100644
--- a/drivers/usb/core/hcd-pci.c
+++ b/drivers/usb/core/hcd-pci.c
@@ -389,11 +389,9 @@ int usb_hcd_pci_resume(struct pci_dev *dev)
 		dev_dbg(hcd->self.controller, "PCI legacy resume\n");
 	}
 
-	/* NOTE:  the PCI API itself is asymmetric here.  We don't need to
-	 * pci_set_power_state(PCI_D0) since that's part of re-enabling;
-	 * but that won't re-enable bus mastering.  Yet pci_disable_device()
-	 * explicitly disables bus mastering...
-	 */
+	pci_set_power_state(dev, PCI_D0);
+	pci_restore_state(dev);
+
 	retval = pci_enable_device(dev);
 	if (retval < 0) {
 		dev_err(hcd->self.controller,
@@ -401,7 +399,6 @@ int usb_hcd_pci_resume(struct pci_dev *dev)
 		return retval;
 	}
 	pci_set_master(dev);
-	pci_restore_state(dev);
 
 	clear_bit(HCD_FLAG_SAW_IRQ, &hcd->flags);
 

[-- Attachment #3: dmesg_resume.diff --]
[-- Type: text/x-diff, Size: 15761 bytes --]

 Back to C!
 Extended CMOS year: 2000
 ricoh-mmc: Resuming.
 ricoh-mmc: Controller is now disabled.
 Enabling non-boot CPUs ...
 SMP alternatives: switching to SMP code
 Booting processor 1 APIC 0x1 ip 0x6000
 Initializing CPU#1
-Calibrating delay using timer specific routine.. 2660.03 BogoMIPS (lpj=5320063)
+Calibrating delay using timer specific routine.. 2660.00 BogoMIPS (lpj=5320000)
 CPU: L1 I cache: 32K, L1 D cache: 32K
 CPU: L2 cache: 2048K
 CPU: Physical Processor ID: 0
 CPU: Processor Core ID: 1
 x86 PAT enabled: cpu 1, old 0x7040600070406, new 0x7010600070106
 CPU1: Intel(R) Core(TM)2 Duo CPU     U7700  @ 1.33GHz stepping 0d
 CPU0 attaching NULL sched-domain.
 Switched to high resolution mode on CPU 1
 CPU0 attaching sched-domain:
  domain 0: span 0-1 level MC
   groups: 0 1
   domain 1: span 0-1 level CPU
    groups: 0-1
 CPU1 attaching sched-domain:
  domain 0: span 0-1 level MC
   groups: 1 0
   domain 1: span 0-1 level CPU
    groups: 0-1
 CPU1 is up
 ACPI: Waking up from system sleep state S3
 APIC error on CPU1: 00(40)
 ACPI: EC: non-query interrupt received, switching to interrupt mode
 pci 0000:00:02.0: restoring config space at offset 0x8 (was 0x1, writing 0x2001)
 pci 0000:00:02.1: restoring config space at offset 0x4 (was 0x4, writing 0xe0500004)
 pci 0000:00:02.1: restoring config space at offset 0x1 (was 0x900000, writing 0x900007)
 pci 0000:00:03.0: restoring config space at offset 0xf (was 0x100, writing 0x1ff)
 pci 0000:00:03.0: restoring config space at offset 0x4 (was 0xfed12004, writing 0xe0600004)
 pci 0000:00:03.2: restoring config space at offset 0xf (was 0x300, writing 0x30b)
 pci 0000:00:03.2: restoring config space at offset 0x8 (was 0x1, writing 0x2031)
 pci 0000:00:03.2: restoring config space at offset 0x7 (was 0x1, writing 0x2021)
 pci 0000:00:03.2: restoring config space at offset 0x6 (was 0x1, writing 0x2019)
 pci 0000:00:03.2: restoring config space at offset 0x5 (was 0x1, writing 0x2011)
 pci 0000:00:03.2: restoring config space at offset 0x4 (was 0x1, writing 0x2009)
 pci 0000:00:03.2: restoring config space at offset 0x1 (was 0xb00000, writing 0xb00001)
 serial 0000:00:03.3: restoring config space at offset 0xf (was 0x200, writing 0x20a)
 serial 0000:00:03.3: restoring config space at offset 0x5 (was 0x0, writing 0xe0601000)
 serial 0000:00:03.3: restoring config space at offset 0x4 (was 0x1, writing 0x2041)
 serial 0000:00:03.3: restoring config space at offset 0x1 (was 0xb00000, writing 0xb00007)
 e1000e 0000:00:19.0: restoring config space at offset 0xf (was 0x100, writing 0x10b)
 e1000e 0000:00:19.0: restoring config space at offset 0x6 (was 0x1, writing 0x2061)
 e1000e 0000:00:19.0: restoring config space at offset 0x5 (was 0x0, writing 0xe0640000)
 e1000e 0000:00:19.0: restoring config space at offset 0x1 (was 0x100000, writing 0x100007)
 e1000e 0000:00:19.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22
 e1000e 0000:00:19.0: setting latency timer to 64
 e1000e 0000:00:19.0: wake-up capability disabled by ACPI
 e1000e 0000:00:19.0: PME# disabled
 e1000e 0000:00:19.0: wake-up capability disabled by ACPI
 e1000e 0000:00:19.0: PME# disabled
 e1000e 0000:00:19.0: irq 509 for MSI/MSI-X
-uhci_hcd 0000:00:1a.0: enabling device (0000 -> 0001)
-uhci_hcd 0000:00:1a.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
-uhci_hcd 0000:00:1a.0: setting latency timer to 64
 uhci_hcd 0000:00:1a.0: restoring config space at offset 0xf (was 0x100, writing 0x10a)
 uhci_hcd 0000:00:1a.0: restoring config space at offset 0x8 (was 0x1, writing 0x2081)
+uhci_hcd 0000:00:1a.0: restoring config space at offset 0x1 (was 0x2800000, writing 0x2800005)
+uhci_hcd 0000:00:1a.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
+uhci_hcd 0000:00:1a.0: setting latency timer to 64
 usb usb1: root hub lost power or was reset
-uhci_hcd 0000:00:1a.1: enabling device (0000 -> 0001)
-uhci_hcd 0000:00:1a.1: PCI INT B -> GSI 17 (level, low) -> IRQ 17
-uhci_hcd 0000:00:1a.1: setting latency timer to 64
 uhci_hcd 0000:00:1a.1: restoring config space at offset 0xf (was 0x200, writing 0x20a)
 uhci_hcd 0000:00:1a.1: restoring config space at offset 0x8 (was 0x1, writing 0x20a1)
+uhci_hcd 0000:00:1a.1: restoring config space at offset 0x1 (was 0x2800000, writing 0x2800005)
+uhci_hcd 0000:00:1a.1: PCI INT B -> GSI 17 (level, low) -> IRQ 17
+uhci_hcd 0000:00:1a.1: setting latency timer to 64
 usb usb3: root hub lost power or was reset
-ehci_hcd 0000:00:1a.7: enabling device (0000 -> 0002)
-ehci_hcd 0000:00:1a.7: PCI INT C -> GSI 18 (level, low) -> IRQ 18
-ehci_hcd 0000:00:1a.7: setting latency timer to 64
 ehci_hcd 0000:00:1a.7: restoring config space at offset 0xf (was 0x300, writing 0x30b)
 ehci_hcd 0000:00:1a.7: restoring config space at offset 0x4 (was 0x0, writing 0xe0641000)
+ehci_hcd 0000:00:1a.7: restoring config space at offset 0x1 (was 0x2900000, writing 0x2900006)
+ehci_hcd 0000:00:1a.7: PCI INT C -> GSI 18 (level, low) -> IRQ 18
+ehci_hcd 0000:00:1a.7: setting latency timer to 64
 HDA Intel 0000:00:1b.0: power state changed by ACPI to D0
 HDA Intel 0000:00:1b.0: restoring config space at offset 0xf (was 0x100, writing 0x10a)
 HDA Intel 0000:00:1b.0: restoring config space at offset 0x3 (was 0x0, writing 0x10)
 HDA Intel 0000:00:1b.0: restoring config space at offset 0x1 (was 0x100000, writing 0x100002)
 HDA Intel 0000:00:1b.0: power state changed by ACPI to D0
 HDA Intel 0000:00:1b.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
 HDA Intel 0000:00:1b.0: setting latency timer to 64
 pcieport-driver 0000:00:1c.0: restoring config space at offset 0xf (was 0x100, writing 0x4010a)
 pcieport-driver 0000:00:1c.0: restoring config space at offset 0x9 (was 0x10001, writing 0x1fff1)
 pcieport-driver 0000:00:1c.0: restoring config space at offset 0x8 (was 0x0, writing 0xfff0)
 pcieport-driver 0000:00:1c.0: restoring config space at offset 0x7 (was 0x0, writing 0x200000f0)
 pcieport-driver 0000:00:1c.0: restoring config space at offset 0x6 (was 0x0, writing 0x80800)
 pcieport-driver 0000:00:1c.0: restoring config space at offset 0x3 (was 0x810000, writing 0x810010)
 pcieport-driver 0000:00:1c.0: restoring config space at offset 0x1 (was 0x100000, writing 0x100407)
 pcieport-driver 0000:00:1c.0: setting latency timer to 64
 pcieport-driver 0000:00:1c.1: restoring config space at offset 0xf (was 0x200, writing 0x4020a)
 pcieport-driver 0000:00:1c.1: restoring config space at offset 0x9 (was 0x10001, writing 0x1fff1)
 pcieport-driver 0000:00:1c.1: restoring config space at offset 0x8 (was 0x0, writing 0xe000e000)
 pcieport-driver 0000:00:1c.1: restoring config space at offset 0x7 (was 0x0, writing 0xf0)
 pcieport-driver 0000:00:1c.1: restoring config space at offset 0x3 (was 0x810000, writing 0x810010)
 pcieport-driver 0000:00:1c.1: restoring config space at offset 0x1 (was 0x100000, writing 0x100407)
 pcieport-driver 0000:00:1c.1: setting latency timer to 64
-uhci_hcd 0000:00:1d.0: enabling device (0000 -> 0001)
-uhci_hcd 0000:00:1d.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20
-uhci_hcd 0000:00:1d.0: setting latency timer to 64
 uhci_hcd 0000:00:1d.0: restoring config space at offset 0xf (was 0x100, writing 0x10a)
 uhci_hcd 0000:00:1d.0: restoring config space at offset 0x8 (was 0x1, writing 0x20c1)
+uhci_hcd 0000:00:1d.0: restoring config space at offset 0x1 (was 0x2800000, writing 0x2800005)
+uhci_hcd 0000:00:1d.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20
+uhci_hcd 0000:00:1d.0: setting latency timer to 64
 usb usb5: root hub lost power or was reset
-uhci_hcd 0000:00:1d.1: enabling device (0000 -> 0001)
-uhci_hcd 0000:00:1d.1: PCI INT B -> GSI 22 (level, low) -> IRQ 22
-uhci_hcd 0000:00:1d.1: setting latency timer to 64
 uhci_hcd 0000:00:1d.1: restoring config space at offset 0xf (was 0x200, writing 0x20b)
 uhci_hcd 0000:00:1d.1: restoring config space at offset 0x8 (was 0x1, writing 0x20e1)
+uhci_hcd 0000:00:1d.1: restoring config space at offset 0x1 (was 0x2800000, writing 0x2800005)
+uhci_hcd 0000:00:1d.1: PCI INT B -> GSI 22 (level, low) -> IRQ 22
+uhci_hcd 0000:00:1d.1: setting latency timer to 64
 usb usb6: root hub lost power or was reset
-uhci_hcd 0000:00:1d.2: enabling device (0000 -> 0001)
-uhci_hcd 0000:00:1d.2: PCI INT C -> GSI 18 (level, low) -> IRQ 18
-uhci_hcd 0000:00:1d.2: setting latency timer to 64
 uhci_hcd 0000:00:1d.2: restoring config space at offset 0xf (was 0x300, writing 0x30b)
 uhci_hcd 0000:00:1d.2: restoring config space at offset 0x8 (was 0x1, writing 0x2101)
+uhci_hcd 0000:00:1d.2: restoring config space at offset 0x1 (was 0x2800000, writing 0x2800005)
+uhci_hcd 0000:00:1d.2: PCI INT C -> GSI 18 (level, low) -> IRQ 18
+uhci_hcd 0000:00:1d.2: setting latency timer to 64
 usb usb7: root hub lost power or was reset
-ehci_hcd 0000:00:1d.7: enabling device (0000 -> 0002)
-ehci_hcd 0000:00:1d.7: PCI INT A -> GSI 20 (level, low) -> IRQ 20
-ehci_hcd 0000:00:1d.7: setting latency timer to 64
 ehci_hcd 0000:00:1d.7: restoring config space at offset 0xf (was 0x100, writing 0x10a)
 ehci_hcd 0000:00:1d.7: restoring config space at offset 0x4 (was 0x0, writing 0xe0648000)
+ehci_hcd 0000:00:1d.7: restoring config space at offset 0x1 (was 0x2900000, writing 0x2900006)
+ehci_hcd 0000:00:1d.7: PCI INT A -> GSI 20 (level, low) -> IRQ 20
+ehci_hcd 0000:00:1d.7: setting latency timer to 64
 pci 0000:00:1e.0: restoring config space at offset 0x9 (was 0x10001, writing 0x1fff1)
 pci 0000:00:1e.0: restoring config space at offset 0x8 (was 0x0, writing 0xe030e010)
 pci 0000:00:1e.0: restoring config space at offset 0x1 (was 0x100007, writing 0x100107)
 pci 0000:00:1e.0: setting latency timer to 64
 ata_piix 0000:00:1f.1: restoring config space at offset 0xf (was 0x100, writing 0x10a)
 ata_piix 0000:00:1f.1: restoring config space at offset 0x8 (was 0xc01, writing 0x2121)
 ata_piix 0000:00:1f.1: restoring config space at offset 0x1 (was 0x2800005, writing 0x2880005)
 ata_piix 0000:00:1f.1: PCI INT A -> GSI 16 (level, low) -> IRQ 16
 ata_piix 0000:00:1f.1: setting latency timer to 64
 ata2: port disabled. ignoring.
 ACPI Exception (exoparg2-0444): AE_AML_PACKAGE_LIMIT, Index (000000005) is beyond end of object [20080926]
 ACPI Error (psparse-0524): Method parse/execution failed [\_SB_.C2C3] (Node ffff88007e01de80), AE_AML_PACKAGE_LIMIT
 ACPI Error (psparse-0524): Method parse/execution failed [\_SB_.C003.C0F6.C3F3._STM] (Node ffff88007e043dc0), AE_AML_PACKAGE_LIMIT
 ata1: ACPI set timing mode failed (status=0x300b)
 iwlagn 0000:10:00.0: enabling device (0000 -> 0002)
 iwlagn 0000:10:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
 iwlagn 0000:10:00.0: restoring config space at offset 0xf (was 0x100, writing 0x10a)
 iwlagn 0000:10:00.0: restoring config space at offset 0x4 (was 0x4, writing 0xe0000004)
 iwlagn 0000:10:00.0: restoring config space at offset 0x3 (was 0x0, writing 0x10)
 iwlagn 0000:10:00.0: restoring config space at offset 0x1 (was 0x100002, writing 0x100006)
 iwlagn 0000:10:00.0: irq 508 for MSI/MSI-X
 yenta_cardbus 0000:02:06.0: restoring config space at offset 0xf (was 0x3000100, writing 0x580010b)
 yenta_cardbus 0000:02:06.0: restoring config space at offset 0xe (was 0x0, writing 0x18fc)
 yenta_cardbus 0000:02:06.0: restoring config space at offset 0xd (was 0x0, writing 0x1800)
 yenta_cardbus 0000:02:06.0: restoring config space at offset 0xc (was 0x0, writing 0x14fc)
 yenta_cardbus 0000:02:06.0: restoring config space at offset 0xb (was 0x0, writing 0x1400)
 yenta_cardbus 0000:02:06.0: restoring config space at offset 0xa (was 0x0, writing 0x87fff000)
 yenta_cardbus 0000:02:06.0: restoring config space at offset 0x9 (was 0x0, writing 0x84000000)
 yenta_cardbus 0000:02:06.0: restoring config space at offset 0x8 (was 0x0, writing 0x83fff000)
 yenta_cardbus 0000:02:06.0: restoring config space at offset 0x7 (was 0x0, writing 0x80000000)
 yenta_cardbus 0000:02:06.0: restoring config space at offset 0x6 (was 0x0, writing 0xb0060302)
 yenta_cardbus 0000:02:06.0: restoring config space at offset 0x4 (was 0x0, writing 0xe0100000)
 yenta_cardbus 0000:02:06.0: restoring config space at offset 0x3 (was 0x820000, writing 0x82a800)
 yenta_cardbus 0000:02:06.0: restoring config space at offset 0x1 (was 0x2100000, writing 0x2100007)
 ohci1394 0000:02:06.1: restoring config space at offset 0xf (was 0x4020200, writing 0x4020205)
 ohci1394 0000:02:06.1: restoring config space at offset 0x4 (was 0x0, writing 0xe0101000)
 ohci1394 0000:02:06.1: restoring config space at offset 0x3 (was 0x800000, writing 0x804010)
 ohci1394 0000:02:06.1: restoring config space at offset 0x1 (was 0x2100000, writing 0x2100006)
 Registered led device: iwl-phy0:radio
 Registered led device: iwl-phy0:assoc
 Registered led device: iwl-phy0:RX
 Registered led device: iwl-phy0:TX
 ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[19]  MMIO=[e0101000-e01017ff]  Max Packet=[2048]  IR/IT contexts=[4/4]
 sdhci-pci 0000:02:06.2: restoring config space at offset 0xf (was 0x300, writing 0x30a)
 sdhci-pci 0000:02:06.2: restoring config space at offset 0x4 (was 0x0, writing 0xe0102000)
 sdhci-pci 0000:02:06.2: restoring config space at offset 0x3 (was 0x800000, writing 0x804010)
 sdhci-pci 0000:02:06.2: restoring config space at offset 0x1 (was 0x2100000, writing 0x2100006)
 sdhci-pci 0000:02:06.2: PCI INT C -> GSI 20 (level, low) -> IRQ 20
 sd 0:0:0:0: [sda] Starting disk
 ata1.01: ACPI cmd ef/03:0c:00:00:00:b0 filtered out
 ata1.01: ACPI cmd ef/03:40:00:00:00:b0 filtered out
 ata1.00: ACPI cmd ef/03:01:00:00:00:a0 filtered out
 ata1.00: ACPI cmd ef/03:45:00:00:00:a0 filtered out
 ata1.00: ACPI cmd f5/00:00:00:00:00:a0 filtered out
 ata1.00: ACPI cmd b1/c1:00:00:00:00:a0 filtered out
 ata1.00: ACPI cmd c6/00:10:00:00:00:a0 succeeded
 ata1.00: configured for UDMA/100
 ata1.01: configured for MWDMA2
 ata1.00: configured for UDMA/100
 ata1.01: configured for MWDMA2
 ata1: EH complete
 sd 0:0:0:0: [sda] 234441648 512-byte hardware sectors: (120 GB/111 GiB)
 sd 0:0:0:0: [sda] Write Protect is off
 sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
 sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
 sd 0:0:0:0: [sda] 234441648 512-byte hardware sectors: (120 GB/111 GiB)
 sd 0:0:0:0: [sda] Write Protect is off
 sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
 sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
-usb 5-2: reset full speed USB device using uhci_hcd and address 2
 usb 1-1: reset full speed USB device using uhci_hcd and address 2
 irq 19: nobody cared (try booting with the "irqpoll" option)
-Pid: 0, comm: swapper Not tainted 2.6.28-rc7-test-resumefix #67
+Pid: 0, comm: swapper Not tainted 2.6.28-rc7-test-resumefix+usb #70
 Call Trace:
- <IRQ>  [<ffffffffa00ee9e1>] ? ohci_irq_handler+0x60/0x7e9 [ohci1394]
+ <IRQ>  [<ffffffffa01009e1>] ? ohci_irq_handler+0x60/0x7e9 [ohci1394]
  [<ffffffff8026aa4d>] __report_bad_irq+0x38/0x87
  [<ffffffff8026abaa>] note_interrupt+0x10e/0x174
  [<ffffffff8026b262>] handle_fasteoi_irq+0xa7/0xd1
  [<ffffffff8020eb87>] do_IRQ+0x73/0xe4
  [<ffffffff8020c626>] ret_from_intr+0x0/0xa
  <EOI>  [<ffffffffa0012606>] ? acpi_idle_enter_bm+0x26b/0x2b2 [processor]
  [<ffffffffa00125fc>] ? acpi_idle_enter_bm+0x261/0x2b2 [processor]
  [<ffffffff8024f30f>] ? notifier_call_chain+0x33/0x5b
- [<ffffffff803b9c64>] ? cpuidle_idle_call+0x8c/0xc4
+ [<ffffffff803b9c6c>] ? cpuidle_idle_call+0x8c/0xc4
  [<ffffffff8020b312>] ? cpu_idle+0x4a/0x9a
  [<ffffffff8042c5c8>] ? rest_init+0x5c/0x5e
 handlers:
-[<ffffffffa00ee981>] (ohci_irq_handler+0x0/0x7e9 [ohci1394])
+[<ffffffffa0100981>] (ohci_irq_handler+0x0/0x7e9 [ohci1394])
 Disabling IRQ #19
+usb 5-2: reset full speed USB device using uhci_hcd and address 2
 pci 0000:00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
 pci 0000:00:02.0: setting latency timer to 64
 Restarting tasks ... done.

Re: [patch,rfc] usb: restore config before enabling device on resume

[Rafael J. Wysocki]

On Saturday, 6 of December 2008, Frans Pop wrote:
> On Thursday 04 December 2008, Linus Torvalds wrote:
> > Greg, Jesse, can you think about and look at the USB PCI resume
> > ordering?
> [...]
> > In many ways the bigger worry is actually in the totally unrelated USB
> > UHCI and EHCI drivers that resume _before_ the bridge does:
> >
> > 	uhci_hcd 0000:00:1d.2: enabling device (0000 -> 0001)
> > 	uhci_hcd 0000:00:1d.2: PCI INT C -> GSI 18 (level, low) -> IRQ 18
> > 	uhci_hcd 0000:00:1d.2: setting latency timer to 64
> > 	uhci_hcd 0000:00:1d.2: restoring config space at offset 0xf (was 0x300, writing 0x30b)
> >	uhci_hcd 0000:00:1d.2: restoring config space at offset 0x8 (was 0x1, writing 0x2101)
> >	usb usb7: root hub lost power or was reset
> > 	ehci_hcd 0000:00:1d.7: enabling device (0000 -> 0002)
> > 	ehci_hcd 0000:00:1d.7: PCI INT A -> GSI 20 (level, low) -> IRQ 20
> > 	ehci_hcd 0000:00:1d.7: setting latency timer to 64
> > 	ehci_hcd 0000:00:1d.7: restoring config space at offset 0xf (was 0x100, writing 0x10a)
> >	ehci_hcd 0000:00:1d.7: restoring config space at offset 0x4 (was 0x0, writing 0xe0648000)
> >
> > and the worry I have here is that we actually enable the device
> > _before_ we've restored the BAR information. That sounds very iffy. It
> > sounds doubly iffy in the 'resume from hibernate' case, where we are
> > going to have an already-set-up PCI bus and the config space values are
> > going to all be live as we reprogram them.
> >
> > That "restoring config space at offset 0x8" thing is where we restore
> > the BAR (dword 0x8 = offset 0x20 = PCI_BASE_ADDRESS_4), and we're
> > changing it from 0x1 to 0x2101, with the IO BAR enabled. In this case,
> > the old value meant that the BAR started out disabled, but hibernate
> > would have been different.
> >
> > So I'd _much_ rather have seen the sequence have the BAR restore
> > sequence be something like
> >
> > 	uhci_hcd 0000:00:1d.2: restoring config space at offset 0xf (was 0x300, writing 0x30b)
> >	uhci_hcd 0000:00:1d.2: restoring config space at offset 0x8 (was 0x1, writing 0x2101)
> >	uhci_hcd 0000:00:1d.2: enabling device (0000 -> 0001)
> > 	uhci_hcd 0000:00:1d.2: PCI INT C -> GSI 18 (level, low) -> IRQ 18
> > 	uhci_hcd 0000:00:1d.2: setting latency timer to 64
> >
> > instead. Possibly even with an explicit disable of the
> > memory/IO/busmaster bits before the whole sequence.
> 
> I've taken a very naive look at this, basically by comparing what usb
> (usb/core/hcd-pci.c) is doing compared to other drivers.
> 
> I used the following command to get an overview:
> $ git grep -E -n -C5 "pci_(enable_device|set_master|restore_state|power_state.*D0)"
> (The line numbers give some indication whether work is split over functions.)
> 
> Most drivers seem to do some variation of the following, which looks
> logical and is in line with Documentation/power/pci.txt:
> pci_set_power_state(dev, PCI_D0);
> pci_restore_state(dev);
> pci_enable_device(dev);
> pci_set_master(dev);
> 
> But quite a lot of drivers (including usb and e.g. ide/setup-pci.c) do
> something like:
> pci_enable_device(dev);
> pci_set_master(dev);
> pci_restore_state(dev);
> 
> Maybe the whole tree should get a review for this?

I think so.

> Anyway, I gave the patch below a try on both my notebook and desktop.
> My desktop has USB keyboard and mouse and the notebook has wireless and
> a fingerprint scanner on USB. Everything still worked after resume.
> 
> Diff of the resume dmesg of my motebook attached. Looks better I think?

Yes, to me it does.

In fact, I think you could even move the pci_restore_state(dev) into
usb_hcd_pci_resume_early() that would be executed with interrupts off and
drop the pci_set_power_state(dev, PCI_D0); entirely (the
pci_enable_device(dev); would invoke it anyway).

Thanks,
Rafael


PS
Please append patches instead of attaching them, they are a lot easier to
discuss this way.

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Rafael J. Wysocki]

On Saturday, 6 of December 2008, Rafael J. Wysocki wrote:
> On Saturday, 6 of December 2008, Linus Torvalds wrote:
> > 
> > On Sat, 6 Dec 2008, Rafael J. Wysocki wrote:
> > >
> > > It only affects the legacy handling, but the non-legacy handling was left
> > > untouched.  IOW, the old "default" functions are still there and are being
> > > called by the "non-legacy" code (it's only used by USB at the moment, AFAICS).
> > 
> > Ok.
> > 
> > > Anyway, I did the test doing it only to the devices which don't have any
> > > non-default suspend-resume handling at all and _that_ apparently fixed the
> > > problem on my box. :-)
> > 
> > Which makes sense, btw. Because if you do the pci_save_state() on a device 
> > that _does_ have a suspend function, you'll be saving the post-suspend 
> > state - ie the device turned off.
> > 
> > So yeah, we really can only do the default suspend if the device has no 
> > pre-existing suspend function - or we'd need to make sure that all PCI 
> > drivers that do have suspend functions would only do the higher-level 
> > functionality.
> > 
> > Anyway, what I'm most interested in hearing is whether this actually 
> > improves your situation.
> 
> Yes, it does, from what I can tell at the moment. :-)

OK, this patch alone doesn't fix the problem, ie. I was able to reproduce it
with this patch applied, but it decreases the probability of a failure.

_However_, when I added two more patches to the mix:
- a patch that moved the PCI Express port suspend and resume to functions
  executed with interrupts disabled
- a patch that moves the restoration of the PCI config space in snd_hda_intel
  to a ->resume_early() callback
I'm not able to reproduce the problem any more (I did over 20
hibernation-resume cycles with this combination of patches applied with
occasional suspend-to-RAM-resume cycles in between and there were no problems
resuming).

I'm going to post the three patches in a separate thread for discussion.

Thanks,
Rafael

[PATCH 0/3] Fix hibernation regression on Toshiba Portege R500

[Rafael J. Wysocki]

Hi,

The following three patches address the hibernation/suspend issue described in
http://bugzilla.kernel.org/show_bug.cgi?id=12121 and in the very long thread at
http://lkml.org/lkml/2008/12/1/382.

In short, the problem is that resume (from hibernation and/or suspend-to-RAM)
occasionally fails (approximately 20-25% of attempts) in the middle of resuming
PCI devices.  We were able to find a specific layout of devices within the
memory address space in which the failure appeared to be extremely unlikely,
but this layout was no really valid for other reasons.  We also found out that
using the NMI watchdog decreased the probablitily of failure which indicated
that the problem could be timing-related.

Next, we started to look at the PCI resume code and we generally agreed that
it would be a good idea to restore the standard PCI configuration registers
with interrupts disabled.  Also, we thought we could move the saving of those
registers for some devices into functions executed with interrupts disabled.

I have followed these observations and created the three following patches.
With all of these patches applied, I'm not able to reproduce the problem.

Thanks,
Rafael

[PATCH 1/3] PCI: Rework default handling of suspend and resume

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rjw@sisk.pl>
Subject: PCI: Rework default handling of suspend and resume

Rework the handling of suspend and resume of PCI devices which have
no drivers or the drivers of which do not provide any suspend-resume
callbacks in such a way that their standard PCI configuration
registers will be saved and restored with interrupts disabled.  This
should prevent such devices, including PCI bridges, from being
resumed too late to be able to function correctly during the resume
of the other PCI devices that may depend on them.

Also, to remove one possible source of future confusion, drop the
default handling of suspend and resume for PCI devices with drivers
providing the 'pm' object introduced by the new suspend-resume
framework (there are no such PCI drivers at the moment).

This patch addresses the regression from 2.6.26 tracked as
http://bugzilla.kernel.org/show_bug.cgi?id=12121 .

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
---
 drivers/pci/pci-driver.c |   90 ++++++++++++++++++++++++++++++-----------------
 1 file changed, 59 insertions(+), 31 deletions(-)

Index: linux-2.6/drivers/pci/pci-driver.c
===================================================================
--- linux-2.6.orig/drivers/pci/pci-driver.c
+++ linux-2.6/drivers/pci/pci-driver.c
@@ -300,6 +300,14 @@ static void pci_device_shutdown(struct d
 
 #ifdef CONFIG_PM_SLEEP
 
+static bool pci_has_legacy_pm_support(struct pci_dev *pci_dev)
+{
+	struct pci_driver *drv = pci_dev->driver;
+
+	return drv && (drv->suspend || drv->suspend_late || drv->resume
+		|| drv->resume_early);
+}
+
 /*
  * Default "suspend" method for devices that have no driver provided suspend,
  * or not even a driver at all.
@@ -317,14 +325,22 @@ static void pci_default_pm_suspend(struc
 
 /*
  * Default "resume" method for devices that have no driver provided resume,
- * or not even a driver at all.
+ * or not even a driver at all (first part).
  */
-static int pci_default_pm_resume(struct pci_dev *pci_dev)
+static void pci_default_pm_resume_early(struct pci_dev *pci_dev)
 {
-	int retval = 0;
-
 	/* restore the PCI config space */
 	pci_restore_state(pci_dev);
+}
+
+/*
+ * Default "resume" method for devices that have no driver provided resume,
+ * or not even a driver at all (second part).
+ */
+static int pci_default_pm_resume_late(struct pci_dev *pci_dev)
+{
+	int retval;
+
 	/* if the device was enabled before suspend, reenable */
 	retval = pci_reenable_device(pci_dev);
 	/*
@@ -371,10 +387,12 @@ static int pci_legacy_resume(struct devi
 	struct pci_dev * pci_dev = to_pci_dev(dev);
 	struct pci_driver * drv = pci_dev->driver;
 
-	if (drv && drv->resume)
+	if (drv && drv->resume) {
 		error = drv->resume(pci_dev);
-	else
-		error = pci_default_pm_resume(pci_dev);
+	} else {
+		pci_default_pm_resume_early(pci_dev);
+		error = pci_default_pm_resume_late(pci_dev);
+	}
 	return error;
 }
 
@@ -420,10 +438,8 @@ static int pci_pm_suspend(struct device 
 		if (drv->pm->suspend) {
 			error = drv->pm->suspend(dev);
 			suspend_report_result(drv->pm->suspend, error);
-		} else {
-			pci_default_pm_suspend(pci_dev);
 		}
-	} else {
+	} else if (pci_has_legacy_pm_support(pci_dev)) {
 		error = pci_legacy_suspend(dev, PMSG_SUSPEND);
 	}
 	pci_fixup_device(pci_fixup_suspend, pci_dev);
@@ -442,8 +458,10 @@ static int pci_pm_suspend_noirq(struct d
 			error = drv->pm->suspend_noirq(dev);
 			suspend_report_result(drv->pm->suspend_noirq, error);
 		}
-	} else {
+	} else if (pci_has_legacy_pm_support(pci_dev)) {
 		error = pci_legacy_suspend_late(dev, PMSG_SUSPEND);
+	} else {
+		pci_default_pm_suspend(pci_dev);
 	}
 
 	return error;
@@ -453,15 +471,17 @@ static int pci_pm_resume(struct device *
 {
 	struct pci_dev *pci_dev = to_pci_dev(dev);
 	struct device_driver *drv = dev->driver;
-	int error;
+	int error = 0;
 
 	pci_fixup_device(pci_fixup_resume, pci_dev);
 
 	if (drv && drv->pm) {
-		error = drv->pm->resume ? drv->pm->resume(dev) :
-			pci_default_pm_resume(pci_dev);
-	} else {
+		if (drv->pm->resume)
+			error = drv->pm->resume(dev);
+	} else if (pci_has_legacy_pm_support(pci_dev)) {
 		error = pci_legacy_resume(dev);
+	} else {
+		error = pci_default_pm_resume_late(pci_dev);
 	}
 
 	return error;
@@ -478,8 +498,10 @@ static int pci_pm_resume_noirq(struct de
 	if (drv && drv->pm) {
 		if (drv->pm->resume_noirq)
 			error = drv->pm->resume_noirq(dev);
-	} else {
+	} else if (pci_has_legacy_pm_support(pci_dev)) {
 		error = pci_legacy_resume_early(dev);
+	} else {
+		pci_default_pm_resume_early(pci_dev);
 	}
 
 	return error;
@@ -506,10 +528,8 @@ static int pci_pm_freeze(struct device *
 		if (drv->pm->freeze) {
 			error = drv->pm->freeze(dev);
 			suspend_report_result(drv->pm->freeze, error);
-		} else {
-			pci_default_pm_suspend(pci_dev);
 		}
-	} else {
+	} else if (pci_has_legacy_pm_support(pci_dev)) {
 		error = pci_legacy_suspend(dev, PMSG_FREEZE);
 		pci_fixup_device(pci_fixup_suspend, pci_dev);
 	}
@@ -528,8 +548,10 @@ static int pci_pm_freeze_noirq(struct de
 			error = drv->pm->freeze_noirq(dev);
 			suspend_report_result(drv->pm->freeze_noirq, error);
 		}
-	} else {
+	} else if (pci_has_legacy_pm_support(pci_dev)) {
 		error = pci_legacy_suspend_late(dev, PMSG_FREEZE);
+	} else {
+		pci_default_pm_suspend(pci_dev);
 	}
 
 	return error;
@@ -537,14 +559,15 @@ static int pci_pm_freeze_noirq(struct de
 
 static int pci_pm_thaw(struct device *dev)
 {
+	struct pci_dev *pci_dev = to_pci_dev(dev);
 	struct device_driver *drv = dev->driver;
 	int error = 0;
 
 	if (drv && drv->pm) {
 		if (drv->pm->thaw)
 			error =  drv->pm->thaw(dev);
-	} else {
-		pci_fixup_device(pci_fixup_resume, to_pci_dev(dev));
+	} else if (pci_has_legacy_pm_support(pci_dev)) {
+		pci_fixup_device(pci_fixup_resume, pci_dev);
 		error = pci_legacy_resume(dev);
 	}
 
@@ -560,7 +583,7 @@ static int pci_pm_thaw_noirq(struct devi
 	if (drv && drv->pm) {
 		if (drv->pm->thaw_noirq)
 			error = drv->pm->thaw_noirq(dev);
-	} else {
+	} else if (pci_has_legacy_pm_support(pci_dev)) {
 		pci_fixup_device(pci_fixup_resume_early, pci_dev);
 		error = pci_legacy_resume_early(dev);
 	}
@@ -570,17 +593,18 @@ static int pci_pm_thaw_noirq(struct devi
 
 static int pci_pm_poweroff(struct device *dev)
 {
+	struct pci_dev *pci_dev = to_pci_dev(dev);
 	struct device_driver *drv = dev->driver;
 	int error = 0;
 
-	pci_fixup_device(pci_fixup_suspend, to_pci_dev(dev));
+	pci_fixup_device(pci_fixup_suspend, pci_dev);
 
 	if (drv && drv->pm) {
 		if (drv->pm->poweroff) {
 			error = drv->pm->poweroff(dev);
 			suspend_report_result(drv->pm->poweroff, error);
 		}
-	} else {
+	} else if (pci_has_legacy_pm_support(pci_dev)) {
 		error = pci_legacy_suspend(dev, PMSG_HIBERNATE);
 	}
 
@@ -598,7 +622,7 @@ static int pci_pm_poweroff_noirq(struct 
 			error = drv->pm->poweroff_noirq(dev);
 			suspend_report_result(drv->pm->poweroff_noirq, error);
 		}
-	} else {
+	} else if (pci_has_legacy_pm_support(pci_dev)) {
 		error = pci_legacy_suspend_late(dev, PMSG_HIBERNATE);
 	}
 
@@ -609,13 +633,15 @@ static int pci_pm_restore(struct device 
 {
 	struct pci_dev *pci_dev = to_pci_dev(dev);
 	struct device_driver *drv = dev->driver;
-	int error;
+	int error = 0;
 
 	if (drv && drv->pm) {
-		error = drv->pm->restore ? drv->pm->restore(dev) :
-			pci_default_pm_resume(pci_dev);
-	} else {
+		if (drv->pm->restore)
+			error = drv->pm->restore(dev);
+	} else if (pci_has_legacy_pm_support(pci_dev)) {
 		error = pci_legacy_resume(dev);
+	} else {
+		error = pci_default_pm_resume_late(pci_dev);
 	}
 	pci_fixup_device(pci_fixup_resume, pci_dev);
 
@@ -633,8 +659,10 @@ static int pci_pm_restore_noirq(struct d
 	if (drv && drv->pm) {
 		if (drv->pm->restore_noirq)
 			error = drv->pm->restore_noirq(dev);
-	} else {
+	} else if (pci_has_legacy_pm_support(pci_dev)) {
 		error = pci_legacy_resume_early(dev);
+	} else {
+		pci_default_pm_resume_early(pci_dev);
 	}
 	pci_fixup_device(pci_fixup_resume_early, pci_dev);
 

[PATCH 2/3] PCI: Suspend and resume PCI Express ports with interrupts disabled

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rjw@sisk.pl>
Subject: PCI: Suspend and resume PCI Express ports with interrupts disabled

I don't see why the suspend and resume of PCI Express ports should be
handled with interrupts enabled and it may even lead to problems in
some situations.  For this reason, move the suspending and resuming
of PCI Express ports into ->suspend_late() and ->resume_early()
callbacks executed with interrupts disabled.

This patch addresses the regression from 2.6.26 tracked as
http://bugzilla.kernel.org/show_bug.cgi?id=12121 .

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
---
 drivers/pci/pcie/portdrv_pci.c |   12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

Index: linux-2.6/drivers/pci/pcie/portdrv_pci.c
===================================================================
--- linux-2.6.orig/drivers/pci/pcie/portdrv_pci.c
+++ linux-2.6/drivers/pci/pcie/portdrv_pci.c
@@ -50,7 +50,7 @@ static int pcie_portdrv_restore_config(s
 }
 
 #ifdef CONFIG_PM
-static int pcie_portdrv_suspend(struct pci_dev *dev, pm_message_t state)
+static int pcie_portdrv_suspend_late(struct pci_dev *dev, pm_message_t state)
 {
 	int ret = pcie_port_device_suspend(dev, state);
 
@@ -59,14 +59,14 @@ static int pcie_portdrv_suspend(struct p
 	return ret;
 }
 
-static int pcie_portdrv_resume(struct pci_dev *dev)
+static int pcie_portdrv_resume_early(struct pci_dev *dev)
 {
 	pcie_portdrv_restore_config(dev);
 	return pcie_port_device_resume(dev);
 }
 #else
-#define pcie_portdrv_suspend NULL
-#define pcie_portdrv_resume NULL
+#define pcie_portdrv_suspend_late NULL
+#define pcie_portdrv_resume_early NULL
 #endif
 
 /*
@@ -282,8 +282,8 @@ static struct pci_driver pcie_portdriver
 	.probe		= pcie_portdrv_probe,
 	.remove		= pcie_portdrv_remove,
 
-	.suspend	= pcie_portdrv_suspend,
-	.resume		= pcie_portdrv_resume,
+	.suspend_late	= pcie_portdrv_suspend_late,
+	.resume_early	= pcie_portdrv_resume_early,
 
 	.err_handler 	= &pcie_portdrv_err_handler,
 };

[PATCH 3/3] Sound (HDA Intel): Restore PCI configuration space with interrupts off

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rjw@sisk.pl>
Subject: Sound (HDA Intel): Restore PCI configuration space with interrupts off

Move the restoration of the standard PCI configuration registers
in the snd_hda_intel driver to a ->resume_early() callback executed
with interrupts disabled, since doing that with interrupts enabled
may lead to problems in some cases.

This patch addresses the regression from 2.6.26 tracked as
http://bugzilla.kernel.org/show_bug.cgi?id=12121 .

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
---
 sound/pci/hda/hda_intel.c |    8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

Index: linux-2.6/sound/pci/hda/hda_intel.c
===================================================================
--- linux-2.6.orig/sound/pci/hda/hda_intel.c
+++ linux-2.6/sound/pci/hda/hda_intel.c
@@ -1951,13 +1951,16 @@ static int azx_suspend(struct pci_dev *p
 	return 0;
 }
 
+static int azx_resume_early(struct pci_dev *pci)
+{
+	return pci_restore_state(pci);
+}
+
 static int azx_resume(struct pci_dev *pci)
 {
 	struct snd_card *card = pci_get_drvdata(pci);
 	struct azx *chip = card->private_data;
 
-	pci_set_power_state(pci, PCI_D0);
-	pci_restore_state(pci);
 	if (pci_enable_device(pci) < 0) {
 		printk(KERN_ERR "hda-intel: pci_enable_device failed, "
 		       "disabling device\n");
@@ -2465,6 +2468,7 @@ static struct pci_driver driver = {
 	.remove = __devexit_p(azx_remove),
 #ifdef CONFIG_PM
 	.suspend = azx_suspend,
+	.resume_early = azx_resume_early,
 	.resume = azx_resume,
 #endif
 };

Re: [patch,rfc] usb: restore config before enabling device on resume

[Frans Pop]

On Saturday 06 December 2008, Rafael J. Wysocki wrote:
> In fact, I think you could even move the pci_restore_state(dev) into
> usb_hcd_pci_resume_early() that would be executed with interrupts off
> and drop the pci_set_power_state(dev, PCI_D0); entirely (the
> pci_enable_device(dev); would invoke it anyway).

There is quite a lot going on in the resume function that happens before 
pci_restore_state is called and I'm absolutely not confident with messing 
with that, so I'll leave anything more invasive to the USB maintainers.

Cheers,
FJP

Re: [PATCH 1/3] PCI: Rework default handling of suspend and resume

[Linus Torvalds]

On Sat, 6 Dec 2008, Rafael J. Wysocki wrote:
> 
> Rework the handling of suspend and resume of PCI devices which have
> no drivers or the drivers of which do not provide any suspend-resume
> callbacks in such a way that their standard PCI configuration
> registers will be saved and restored with interrupts disabled.

Ok, I think this is good, but I _also_ think that we should do one more 
fix:

 - if a device uses the new-format suspend/resume structure, we should do 
   the low-level save-restore _unconditionally_ in the PCI layer.

Because apparently there is only a single user of the new format, and that 
single user got it wrong. So wouldn't it be much nicer to just _remove_ 
the code from the USB host controllers that does the save/restore thing.

Quite frankly, the USB code really does look wrong. Not just in that it 
enables the BAR's before restoring them, but on the suspend side it 
actually puts the device into D3_hot _before_ it then does the whole 
"pci_enable_wake()", which I'm not at all sure will necessarily work. I'm 
pretty sure that you should enable wakeup events _before_ going to sleep.

If the generic PCI layer unconditionally did the suspend as the last thing 
it does (and the resume as the first thing), then drivers couldn't do 
insane things like that, even by mistake.

Hmm?

				Linus

Re: [PATCH 2/3] PCI: Suspend and resume PCI Express ports with interrupts disabled

[Linus Torvalds]

On Sat, 6 Dec 2008, Rafael J. Wysocki wrote:
> 
> I don't see why the suspend and resume of PCI Express ports should be
> handled with interrupts enabled and it may even lead to problems in
> some situations.

Absolutely. A PCI Express port is really just a PCI bridge, with some odd 
rules. We need to enable them early, exacly like regular PCI bridges, or 
we cannot walk the PCI bus hierarchy correctly.

Anyway, ack, ack, ack for the whole series.

			Linus

Re: [PATCH 1/3] PCI: Rework default handling of suspend and resume

[Rafael J. Wysocki]

On Saturday, 6 of December 2008, Linus Torvalds wrote:
> 
> On Sat, 6 Dec 2008, Rafael J. Wysocki wrote:
> > 
> > Rework the handling of suspend and resume of PCI devices which have
> > no drivers or the drivers of which do not provide any suspend-resume
> > callbacks in such a way that their standard PCI configuration
> > registers will be saved and restored with interrupts disabled.
> 
> Ok, I think this is good, but I _also_ think that we should do one more 
> fix:
> 
>  - if a device uses the new-format suspend/resume structure, we should do 
>    the low-level save-restore _unconditionally_ in the PCI layer.
> 
> Because apparently there is only a single user of the new format, and that 
> single user got it wrong. So wouldn't it be much nicer to just _remove_ 
> the code from the USB host controllers that does the save/restore thing.

USB doesn't use that for PCI suspend-resume, it uses it for suspend-resume of
USB devices behind the controller.

> Quite frankly, the USB code really does look wrong. Not just in that it 
> enables the BAR's before restoring them, but on the suspend side it 
> actually puts the device into D3_hot _before_ it then does the whole 
> "pci_enable_wake()", which I'm not at all sure will necessarily work. I'm 
> pretty sure that you should enable wakeup events _before_ going to sleep.

Yeah.  Or simply use pci_prepare_to_sleep() and be done with it.

> If the generic PCI layer unconditionally did the suspend as the last thing 
> it does (and the resume as the first thing), then drivers couldn't do 
> insane things like that, even by mistake.
> 
> Hmm?

OK

But then we will save the device's registers in the "sleeping" state.  Is this
going to be entirely correct in all possible cases?  [pci_save_state() doesn't
save the PM registers, so that _should_ be correct, but I don't have _that_
much experience with these things.]

Rafael

Re: [PATCH 2/3] PCI: Suspend and resume PCI Express ports with interrupts disabled

[Rafael J. Wysocki]

On Saturday, 6 of December 2008, Linus Torvalds wrote:
> 
> On Sat, 6 Dec 2008, Rafael J. Wysocki wrote:
> > 
> > I don't see why the suspend and resume of PCI Express ports should be
> > handled with interrupts enabled and it may even lead to problems in
> > some situations.
> 
> Absolutely. A PCI Express port is really just a PCI bridge, with some odd 
> rules. We need to enable them early, exacly like regular PCI bridges, or 
> we cannot walk the PCI bus hierarchy correctly.
> 
> Anyway, ack, ack, ack for the whole series.

Thanks! :-)

I think it should go through Jesse?

Rafael

Re: [PATCH 1/3] PCI: Rework default handling of suspend and resume

[Linus Torvalds]

On Sat, 6 Dec 2008, Rafael J. Wysocki wrote:
> 
> USB doesn't use that for PCI suspend-resume, it uses it for suspend-resume of
> USB devices behind the controller.

Oh, in that case there are no PCI users of this at all, and what the PCI 
driver does is immaterial ;)

> But then we will save the device's registers in the "sleeping" state. 

No no. The rule would be that a PCI driver - if it uses the new 
infrastructure, which apparently nobody does _as_ a PCI driver - simply 
would never do the whole "pci_set_power_state(PCI_D3hot)" etc crud AT ALL.

So a PCI driver would only do higher-level stuff in its suspend/resume 
code. For example, a USB host controller would initiate the USB bus level 
stuff, and likely just stop the controller (not suspend it - just stop 
it).

			Linus

Re: [PATCH 2/3] PCI: Suspend and resume PCI Express ports with interrupts disabled

[Linus Torvalds]

On Sat, 6 Dec 2008, Rafael J. Wysocki wrote:
> 
> I think it should go through Jesse?

Probably correct. And we want it in -next, so that it can get some testing 
even before I open the merge window. Because I hope everybody realizes 
that there's no way we're doing this in 2.6.28, and we'll leave the broken 
and unreliable suspend.

Because afaik this is not a new bug (I tried to push a patch to do 
suspend_late/resume_early for the PCI code a _loong_ time ago, but it 
never got merged), and the only reason it showed up as a regression was 
almost certainly simply that we've always had this.

IOW, suspend/resume has always been dodgy wrt interrupts, and there's some 
luck involved. And your machine just happened to get unlucky.

I'd love to fix this in 2.6.28, but it's just not reasonable - it needs 
widespread testing with an early -rc merge. And if it turns out to fix a 
lot of machines, and there are no regressions, we can always back-port it 
later.

Jesse?

			Linus

Re: [PATCH 1/3] PCI: Rework default handling of suspend and resume

[Rafael J. Wysocki]

On Saturday, 6 of December 2008, Linus Torvalds wrote:
> 
> On Sat, 6 Dec 2008, Rafael J. Wysocki wrote:
> > 
> > USB doesn't use that for PCI suspend-resume, it uses it for suspend-resume of
> > USB devices behind the controller.
> 
> Oh, in that case there are no PCI users of this at all, and what the PCI 
> driver does is immaterial ;)
> 
> > But then we will save the device's registers in the "sleeping" state. 
> 
> No no. The rule would be that a PCI driver - if it uses the new 
> infrastructure, which apparently nobody does _as_ a PCI driver - simply 
> would never do the whole "pci_set_power_state(PCI_D3hot)" etc crud AT ALL.

Now _that_ sounds good. :-)

> So a PCI driver would only do higher-level stuff in its suspend/resume 
> code. For example, a USB host controller would initiate the USB bus level 
> stuff, and likely just stop the controller (not suspend it - just stop 
> it).

I like this idea very much.

So, to fix the issue at hand, I'd like the $subject patch to go first.  Then,
there is a major update of the new framework waiting for .29 in the Greg's
tree (that's the main reason why nobody uses it so far, BTW) and I'd really
prefer it to go next.  After it's been merged, I'm going to add the mandatory
suspend-resume things (save state and go to a low power state on suspend,
restore state on resume) to the new framework in a separete patch.

Is this plan acceptable?

Rafael

Re: [PATCH 2/3] PCI: Suspend and resume PCI Express ports with interrupts disabled

[Rafael J. Wysocki]

On Saturday, 6 of December 2008, Linus Torvalds wrote:
> 
> On Sat, 6 Dec 2008, Rafael J. Wysocki wrote:
> > 
> > I think it should go through Jesse?
> 
> Probably correct. And we want it in -next, so that it can get some testing 
> even before I open the merge window. Because I hope everybody realizes 
> that there's no way we're doing this in 2.6.28, and we'll leave the broken 
> and unreliable suspend.
> 
> Because afaik this is not a new bug (I tried to push a patch to do 
> suspend_late/resume_early for the PCI code a _loong_ time ago, but it 
> never got merged), and the only reason it showed up as a regression was 
> almost certainly simply that we've always had this.
> 
> IOW, suspend/resume has always been dodgy wrt interrupts, and there's some 
> luck involved. And your machine just happened to get unlucky.
> 
> I'd love to fix this in 2.6.28, but it's just not reasonable - it needs 
> widespread testing with an early -rc merge. And if it turns out to fix a 
> lot of machines, and there are no regressions, we can always back-port it 
> later.

I agree.

Thanks,
Rafael

Re: [PATCH 1/3] PCI: Rework default handling of suspend and resume

[Linus Torvalds]

On Sat, 6 Dec 2008, Rafael J. Wysocki wrote:
> 
> So, to fix the issue at hand, I'd like the $subject patch to go first.  Then,
> there is a major update of the new framework waiting for .29 in the Greg's
> tree (that's the main reason why nobody uses it so far, BTW) and I'd really
> prefer it to go next.  After it's been merged, I'm going to add the mandatory
> suspend-resume things (save state and go to a low power state on suspend,
> restore state on resume) to the new framework in a separete patch.
> 
> Is this plan acceptable?

Sounds good to me. And assuming Jesse/Greg are all aboard, I'll just wait 
for the pull requests from Jesse and Greg.

The only thing I'll do right now is to send off my "print out ICH6+ 
LPC resources" patch again to Jesse, with a changelog etc. It can probably 
go in as-is (it really just adds printk's), but since it didn't matter 
anyway we migth as well just do it as a PCI thing for 2.6.29 too.

On a similar note, I wonder what we should do about the whole "transparent 
bridge resource allocation" thing. It also didn't end up really mattering, 
even if it apparently made a difference for Frans. The question is just 
whether we would be better off with IO windows for transparent buses (the 
way we try to set things up now), or with a simpler PCI resource tree that 
just takes advantage of the transparency.

The bridge windows _may_ result in better PCI throughput behind such a 
bridge, so there is some argument for keeping them. On the other hand, 
transparent bridges aren't generally for high-performance stuff anyway, 
and one advantage of the transparency is the flexibility it allows (ie we 
don't _need_ to set up the static bridging windows).

I dunno. I wonder what Windows does. Following Windows in areas like this 
tends to have the advantage that it's what the firmware and the hardware 
has generally been tested with most. At the same time, I'm not sure this 
is necessarily a very bug-prone area for either firmware or hardware. If 
there's actual bridge bugs wrt the windows, I suspect such a bridge would 
be broken enough to be unusable regardless.

			Linus

Re: [linux-pm] [PATCH 1/3] PCI: Rework default handling of suspend and resume

[Alan Stern]

On Sat, 6 Dec 2008, Rafael J. Wysocki wrote:

> On Saturday, 6 of December 2008, Linus Torvalds wrote:
> > 
> > On Sat, 6 Dec 2008, Rafael J. Wysocki wrote:
> > > 
> > > USB doesn't use that for PCI suspend-resume, it uses it for suspend-resume of
> > > USB devices behind the controller.
> > 
> > Oh, in that case there are no PCI users of this at all, and what the PCI 
> > driver does is immaterial ;)
> > 
> > > But then we will save the device's registers in the "sleeping" state. 
> > 
> > No no. The rule would be that a PCI driver - if it uses the new 
> > infrastructure, which apparently nobody does _as_ a PCI driver - simply 
> > would never do the whole "pci_set_power_state(PCI_D3hot)" etc crud AT ALL.
> 
> Now _that_ sounds good. :-)
> 
> > So a PCI driver would only do higher-level stuff in its suspend/resume 
> > code. For example, a USB host controller would initiate the USB bus level 
> > stuff, and likely just stop the controller (not suspend it - just stop 
> > it).
> 
> I like this idea very much.

Rafael, I'd be happy to help with fixing up the USB PCI PM code.  At
this point I'm not sure exactly what's needed, though.  For instance,
is there any compelling reason to switch over to the new dev_pm_ops
approach?  And what should the correct sequence of calls be?

Alan Stern

Re: [PATCH 0/3] Fix hibernation regression on Toshiba Portege R500

[Frans Pop]

> The following three patches address the hibernation/suspend issue
> described in http://bugzilla.kernel.org/show_bug.cgi?id=12121 and in
> the very long thread at http://lkml.org/lkml/2008/12/1/382.

I've just built a kernel with your three patches, and without the earlier
"revert/debug" and "ignore transparent bridge" patches.

It also includes my patch that somewhat improves USB resume and my fix for 
the ohci1394: "irq 19: nobody cared" issue. (Although I understand that 
it's likely we'll get a much more structural improvement for USB than my 
naive patch.)

I'll run my notebook with this kernel for the next few days and let you 
know the results. First suspend/resume cycle was fine and showed, as 
expected, a lot of config restores moved up, including HDA intel and 
pcieport-driver.

It's nice to see something of significance happening before the ricoh-mmc 
controller gets disabled :-P

Cheers,
FJP

Re: [PATCH 1/3] PCI: Rework default handling of suspend and resume

[Alan Cox]

> prefer it to go next.  After it's been merged, I'm going to add the mandatory
> suspend-resume things (save state and go to a low power state on suspend,
> restore state on resume) to the new framework in a separete patch.
> 
> Is this plan acceptable?

I have at least two drivers I look after where if you put the device into
D3 you lost. We survive because on a successful suspend/resume sequence
the BIOS puts it back coming out of suspend but that means we must not
put those devices into D3 ourselves ever - including during a suspend
before we are 100% comitted to the suspend completing or reboot.

Re: [PATCH 1/3] PCI: Rework default handling of suspend and resume

[Rafael J. Wysocki]

On Saturday, 6 of December 2008, Linus Torvalds wrote:
> 
> On Sat, 6 Dec 2008, Rafael J. Wysocki wrote:
> > 
> > So, to fix the issue at hand, I'd like the $subject patch to go first.  Then,
> > there is a major update of the new framework waiting for .29 in the Greg's
> > tree (that's the main reason why nobody uses it so far, BTW) and I'd really
> > prefer it to go next.  After it's been merged, I'm going to add the mandatory
> > suspend-resume things (save state and go to a low power state on suspend,
> > restore state on resume) to the new framework in a separete patch.
> > 
> > Is this plan acceptable?
> 
> Sounds good to me. And assuming Jesse/Greg are all aboard, I'll just wait 
> for the pull requests from Jesse and Greg.
> 
> The only thing I'll do right now is to send off my "print out ICH6+ 
> LPC resources" patch again to Jesse, with a changelog etc. It can probably 
> go in as-is (it really just adds printk's), but since it didn't matter 
> anyway we migth as well just do it as a PCI thing for 2.6.29 too.
> 
> On a similar note, I wonder what we should do about the whole "transparent 
> bridge resource allocation" thing. It also didn't end up really mattering, 
> even if it apparently made a difference for Frans. The question is just 
> whether we would be better off with IO windows for transparent buses (the 
> way we try to set things up now), or with a simpler PCI resource tree that 
> just takes advantage of the transparency.
> 
> The bridge windows _may_ result in better PCI throughput behind such a 
> bridge, so there is some argument for keeping them. On the other hand, 
> transparent bridges aren't generally for high-performance stuff anyway, 
> and one advantage of the transparency is the flexibility it allows (ie we 
> don't _need_ to set up the static bridging windows).

The static bridging windows help understand the system topology a bit IMO,
because you can just look at /proc/iomem and see what resources are
behind the bridge.

> I dunno. I wonder what Windows does. Following Windows in areas like this 
> tends to have the advantage that it's what the firmware and the hardware 
> has generally been tested with most. At the same time, I'm not sure this 
> is necessarily a very bug-prone area for either firmware or hardware. If 
> there's actual bridge bugs wrt the windows, I suspect such a bridge would 
> be broken enough to be unusable regardless.

I think Intel people should be able to find out what Windows does in this
area.

Thanks,
Rafael

Re: [linux-pm] [PATCH 1/3] PCI: Rework default handling of suspend and resume

[Rafael J. Wysocki]

Hi Alan,

On Saturday, 6 of December 2008, Alan Stern wrote:
> On Sat, 6 Dec 2008, Rafael J. Wysocki wrote:
> 
> > On Saturday, 6 of December 2008, Linus Torvalds wrote:
> > > 
> > > On Sat, 6 Dec 2008, Rafael J. Wysocki wrote:
> > > > 
> > > > USB doesn't use that for PCI suspend-resume, it uses it for suspend-resume of
> > > > USB devices behind the controller.
> > > 
> > > Oh, in that case there are no PCI users of this at all, and what the PCI 
> > > driver does is immaterial ;)
> > > 
> > > > But then we will save the device's registers in the "sleeping" state. 
> > > 
> > > No no. The rule would be that a PCI driver - if it uses the new 
> > > infrastructure, which apparently nobody does _as_ a PCI driver - simply 
> > > would never do the whole "pci_set_power_state(PCI_D3hot)" etc crud AT ALL.
> > 
> > Now _that_ sounds good. :-)
> > 
> > > So a PCI driver would only do higher-level stuff in its suspend/resume 
> > > code. For example, a USB host controller would initiate the USB bus level 
> > > stuff, and likely just stop the controller (not suspend it - just stop 
> > > it).
> > 
> > I like this idea very much.
> 
> Rafael, I'd be happy to help with fixing up the USB PCI PM code.  At
> this point I'm not sure exactly what's needed, though.  For instance,
> is there any compelling reason to switch over to the new dev_pm_ops
> approach?

Certainly not at the moment.  There will be a reason some time after .29.

That said, it apparently is possible to clean up the resume callbacks of PCI
USB controllers, as mentioned here: http://lkml.org/lkml/2008/12/6/38

> And what should the correct sequence of calls be?

Well, that's something I'm not exactly sure about myself.  Surely it seems
reasonable to call pci_restore_state() with interrupts disabled and do the rest
of resume after that.  Also, I think that the core could execute things like
pci_enable_device() during resume and pci_set_power_state()/pci_enable_wake()
on suspend so that the drivers didn't have to.  This way we could reduce code
duplication quite a bit.

However, I'm not quite sure about the freeing and requesting IRQs during
suspend and resume.  Many drivers do that, many others don't.  Still,
apparently some drivers don't work correctly after resume if this is not done.
So, if that should generally be done, I also think that moving it to the core
might be a good idea.

Thanks,
Rafael

Re: [PATCH 1/3] PCI: Rework default handling of suspend and resume

[Rafael J. Wysocki]

On Saturday, 6 of December 2008, Alan Cox wrote:
> > prefer it to go next.  After it's been merged, I'm going to add the mandatory
> > suspend-resume things (save state and go to a low power state on suspend,
> > restore state on resume) to the new framework in a separete patch.
> > 
> > Is this plan acceptable?
> 
> I have at least two drivers I look after where if you put the device into
> D3 you lost. We survive because on a successful suspend/resume sequence
> the BIOS puts it back coming out of suspend but that means we must not
> put those devices into D3 ourselves ever - including during a suspend
> before we are 100% comitted to the suspend completing or reboot.

We can mark them as devices not to put into D3.  There already is a
mechanism for that in place.

Thanks,
Rafael

Re: [linux-pm] [PATCH 1/3] PCI: Rework default handling of suspend and resume

[Linus Torvalds]

On Sat, 6 Dec 2008, Rafael J. Wysocki wrote:
> 
> However, I'm not quite sure about the freeing and requesting IRQs during
> suspend and resume.  Many drivers do that, many others don't.  Still,
> apparently some drivers don't work correctly after resume if this is not done.
> So, if that should generally be done, I also think that moving it to the core
> might be a good idea.

I'd suggest against it.

A lot of drivers that want to disable (or unregister) interrupts almost 
certainly want to do it simply because they are not ready and willing to 
handle any interrupts after having run their "suspend()" function. 

So if the generic layer does it _after_ calling ->suspend() (or at 
suspend_late()) time, it's too late.

And the generic layer certainly must not disable/unregister interrupts 
_before_ calling ->suspend(), since the driver may well need to handle 
interrupts for suspending.

So there is no right time for the generic layer to do this. Not to mention 
that the generic layer doesn't even know what kind of interrupt (if any - 
or if perhaps even _multiple_) that the driver has registered.

I also suspect that a lot of drivers simply do not want or need to 
unregister the interrupt handler. I'm personally pretty sure that the only 
reason that drivers do this in the first place is exactly because they do 
their suspend() thing with interrupts enabled in the first place, and 
moving the core suspend routines to inside the irq-off region just means 
that they don't even want/need to do anything about interrupts.

			Linus

Re: [linux-pm] [PATCH 1/3] PCI: Rework default handling of suspend and resume

[Arjan van de Ven]

On Sat, 6 Dec 2008 14:24:55 -0800 (PST)
Linus Torvalds <torvalds@linux-foundation.org> wrote:

> 
> 
> On Sat, 6 Dec 2008, Rafael J. Wysocki wrote:
> > 
> > However, I'm not quite sure about the freeing and requesting IRQs
> > during suspend and resume.  Many drivers do that, many others
> > don't.  Still, apparently some drivers don't work correctly after
> > resume if this is not done. So, if that should generally be done, I
> > also think that moving it to the core might be a good idea.
> 
> I'd suggest against it.
> 
> A lot of drivers that want to disable (or unregister) interrupts
> almost certainly want to do it simply because they are not ready and
> willing to handle any interrupts after having run their "suspend()"
> function. 

the problem is that the system bios can have reassigned interrupts
after resume, and afaik we need to re-evaluate the ACPI methods to
get the new mapping.
So we need to unregister + re-register to make that happen

Re: [linux-pm] [PATCH 1/3] PCI: Rework default handling of suspend and resume

[Alan Cox]

> So we need to unregister + re-register to make that happen

Agreed - and to cope with coming back up with some masked IRQs for those
lovely hardware vendors whose idea of amusement is handing the resumed
system a pending IRQ. To be fair its often hardware flagging things like
'device has become ready' from power up events...

Re: [linux-pm] [PATCH 1/3] PCI: Rework default handling of suspend and resume

[Alan Stern]

On Sat, 6 Dec 2008, Rafael J. Wysocki wrote:

> > Rafael, I'd be happy to help with fixing up the USB PCI PM code.  At
> > this point I'm not sure exactly what's needed, though.  For instance,
> > is there any compelling reason to switch over to the new dev_pm_ops
> > approach?
> 
> Certainly not at the moment.  There will be a reason some time after .29.
> 
> That said, it apparently is possible to clean up the resume callbacks of PCI
> USB controllers, as mentioned here: http://lkml.org/lkml/2008/12/6/38
> 
> > And what should the correct sequence of calls be?
> 
> Well, that's something I'm not exactly sure about myself.  Surely it seems
> reasonable to call pci_restore_state() with interrupts disabled and do the rest
> of resume after that.  Also, I think that the core could execute things like
> pci_enable_device() during resume and pci_set_power_state()/pci_enable_wake()
> on suspend so that the drivers didn't have to.  This way we could reduce code
> duplication quite a bit.

Do you plan to change the PCI core to do these things any time soon?  
Wouldn't that require changing a whole bunch of PCI drivers too?  I
tend to agree that having the core take care of these choreographed
activities would be good -- it would leave less room for drivers to
make mistakes.

So for now maybe it would be best just to rearrange the existing calls
in USB, and wait for the core changes before doing anything more
ambitious.

> However, I'm not quite sure about the freeing and requesting IRQs during
> suspend and resume.  Many drivers do that, many others don't.  Still,
> apparently some drivers don't work correctly after resume if this is not done.
> So, if that should generally be done, I also think that moving it to the core
> might be a good idea.

For USB this doesn't matter; we don't free the IRQs during suspend.

Alan Stern

Re: [PATCH 2/3] PCI: Suspend and resume PCI Express ports with interrupts disabled

[Jesse Barnes]

On Saturday, December 6, 2008 9:46 am Rafael J. Wysocki wrote:
> On Saturday, 6 of December 2008, Linus Torvalds wrote:
> > On Sat, 6 Dec 2008, Rafael J. Wysocki wrote:
> > > I think it should go through Jesse?
> >
> > Probably correct. And we want it in -next, so that it can get some
> > testing even before I open the merge window. Because I hope everybody
> > realizes that there's no way we're doing this in 2.6.28, and we'll leave
> > the broken and unreliable suspend.
> >
> > Because afaik this is not a new bug (I tried to push a patch to do
> > suspend_late/resume_early for the PCI code a _loong_ time ago, but it
> > never got merged), and the only reason it showed up as a regression was
> > almost certainly simply that we've always had this.
> >
> > IOW, suspend/resume has always been dodgy wrt interrupts, and there's
> > some luck involved. And your machine just happened to get unlucky.
> >
> > I'd love to fix this in 2.6.28, but it's just not reasonable - it needs
> > widespread testing with an early -rc merge. And if it turns out to fix a
> > lot of machines, and there are no regressions, we can always back-port it
> > later.
>
> I agree.

I'll stuff it into my -next branch tonight.

-- 
Jesse Barnes, Intel Open Source Technology Center

Re: [PATCH 1/3] PCI: Rework default handling of suspend and resume

[Jesse Barnes]

On Saturday, December 6, 2008 10:00 am Linus Torvalds wrote:
> On Sat, 6 Dec 2008, Rafael J. Wysocki wrote:
> > So, to fix the issue at hand, I'd like the $subject patch to go first. 
> > Then, there is a major update of the new framework waiting for .29 in the
> > Greg's tree (that's the main reason why nobody uses it so far, BTW) and
> > I'd really prefer it to go next.  After it's been merged, I'm going to
> > add the mandatory suspend-resume things (save state and go to a low power
> > state on suspend, restore state on resume) to the new framework in a
> > separete patch.
> >
> > Is this plan acceptable?
>
> Sounds good to me. And assuming Jesse/Greg are all aboard, I'll just wait
> for the pull requests from Jesse and Greg.
>
> The only thing I'll do right now is to send off my "print out ICH6+
> LPC resources" patch again to Jesse, with a changelog etc. It can probably
> go in as-is (it really just adds printk's), but since it didn't matter
> anyway we migth as well just do it as a PCI thing for 2.6.29 too.

Ok, I applied the set (Rafael's 1-2 and your ICH patch) to my linux-next 
branch.  We should get a little build coverage this week at least, hopefully 
nothing breaks too badly.

> On a similar note, I wonder what we should do about the whole "transparent
> bridge resource allocation" thing. It also didn't end up really mattering,
> even if it apparently made a difference for Frans. The question is just
> whether we would be better off with IO windows for transparent buses (the
> way we try to set things up now), or with a simpler PCI resource tree that
> just takes advantage of the transparency.
>
> The bridge windows _may_ result in better PCI throughput behind such a
> bridge, so there is some argument for keeping them. On the other hand,
> transparent bridges aren't generally for high-performance stuff anyway,
> and one advantage of the transparency is the flexibility it allows (ie we
> don't _need_ to set up the static bridging windows).
>
> I dunno. I wonder what Windows does. Following Windows in areas like this
> tends to have the advantage that it's what the firmware and the hardware
> has generally been tested with most. At the same time, I'm not sure this
> is necessarily a very bug-prone area for either firmware or hardware. If
> there's actual bridge bugs wrt the windows, I suspect such a bridge would
> be broken enough to be unusable regardless.

Just so happens that I'm working with some people internally on transparent 
bridge related issues atm, I'll see what I can dig up.

-- 
Jesse Barnes, Intel Open Source Technology Center

Re: [PATCH 3/3] Sound (HDA Intel): Restore PCI configuration space with interrupts off

[Jesse Barnes]

On Saturday, December 6, 2008 6:09 am Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <rjw@sisk.pl>
> Subject: Sound (HDA Intel): Restore PCI configuration space with interrupts
> off
>
> Move the restoration of the standard PCI configuration registers
> in the snd_hda_intel driver to a ->resume_early() callback executed
> with interrupts disabled, since doing that with interrupts enabled
> may lead to problems in some cases.
>
> This patch addresses the regression from 2.6.26 tracked as
> http://bugzilla.kernel.org/show_bug.cgi?id=12121 .

Since I only applied 1 and 2 you'll need to send this one through Takashi.

Thanks,
-- 
Jesse Barnes, Intel Open Source Technology Center

Re: [PATCH 1/3] PCI: Rework default handling of suspend and resume

[Greg KH]

On Sat, Dec 06, 2008 at 10:00:35AM -0800, Linus Torvalds wrote:
> 
> 
> On Sat, 6 Dec 2008, Rafael J. Wysocki wrote:
> > 
> > So, to fix the issue at hand, I'd like the $subject patch to go first.  Then,
> > there is a major update of the new framework waiting for .29 in the Greg's
> > tree (that's the main reason why nobody uses it so far, BTW) and I'd really
> > prefer it to go next.  After it's been merged, I'm going to add the mandatory
> > suspend-resume things (save state and go to a low power state on suspend,
> > restore state on resume) to the new framework in a separete patch.
> > 
> > Is this plan acceptable?
> 
> Sounds good to me. And assuming Jesse/Greg are all aboard, I'll just wait 
> for the pull requests from Jesse and Greg.

No objection from me, I'll wait for Jesse to "go first" in the .29 merge
window.

thanks,

greg k-h

Re: [linux-pm] [PATCH 1/3] PCI: Rework default handling of suspend and resume

[Linus Torvalds]

On Sat, 6 Dec 2008, Arjan van de Ven wrote:
> 
> the problem is that the system bios can have reassigned interrupts
> after resume, and afaik we need to re-evaluate the ACPI methods to
> get the new mapping.
> So we need to unregister + re-register to make that happen

Can you give actual examples of real life situations?

Because quite frankly, it sounds less and less likely for any relevant 
hardware. It's a non-issue for MSI, for example. And it's a non-issue for 
any sane interrupt source I can think of.

In other words, I've heard that claim before - and I just don't believe 
it. I've never heard a realistic explanation of why it would happen for a 
normal PCI driver. And I still claim that it's a very odd and special case 
if it does.

And btw, I'm talking suspend, not hibernate. 

			Linus

Re: [linux-pm] [PATCH 1/3] PCI: Rework default handling of suspend and resume

[Linus Torvalds]

On Sat, 6 Dec 2008, Linus Torvalds wrote:
> 
> And btw, I'm talking suspend, not hibernate. 

And, btw, even if anybody actually does this, it should be up to the 
interrupt controller logic to re-initialize the interrupts so that they 
are back where they belong. IOW, we should never show such _idiotic_ 
brokenness to any actual driver, it should all be remapped and handled 
below them.

And I still have never heard any valid reason to do it in the first place, 
so until somebody actually gives a real example and an explanation, I 
would suggest ignoring the whole issue as some insane rumblings from crazy 
hw/firmare people doing idiotic things.

			Linus

Re: [linux-pm] [PATCH 1/3] PCI: Rework default handling of suspend and resume

[Takashi Iwai]

At Sat, 6 Dec 2008 22:00:59 -0800 (PST),
Linus Torvalds wrote:
> 
> 
> 
> On Sat, 6 Dec 2008, Arjan van de Ven wrote:
> > 
> > the problem is that the system bios can have reassigned interrupts
> > after resume, and afaik we need to re-evaluate the ACPI methods to
> > get the new mapping.
> > So we need to unregister + re-register to make that happen
> 
> Can you give actual examples of real life situations?

There were such cases on intel8x0 and maestro3 on-board sound devices,
but all they were about hibernate, IIRC.  Just though a quick git 
log search, I found the following:
	http://bugzilla.kernel.org/show_bug.cgi?id=4416


Takashi

Re: [PATCH 3/3] Sound (HDA Intel): Restore PCI configuration space with interrupts off

[Takashi Iwai]

At Sat, 6 Dec 2008 20:45:35 -0800,
Jesse Barnes wrote:
> 
> On Saturday, December 6, 2008 6:09 am Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki <rjw@sisk.pl>
> > Subject: Sound (HDA Intel): Restore PCI configuration space with interrupts
> > off
> >
> > Move the restoration of the standard PCI configuration registers
> > in the snd_hda_intel driver to a ->resume_early() callback executed
> > with interrupts disabled, since doing that with interrupts enabled
> > may lead to problems in some cases.
> >
> > This patch addresses the regression from 2.6.26 tracked as
> > http://bugzilla.kernel.org/show_bug.cgi?id=12121 .
> 
> Since I only applied 1 and 2 you'll need to send this one through Takashi.

OK, I merged it to for-next branch now.
It should appear in the linux-next tree of tomorrow.


thanks,

Takashi

Re: [PATCH 1/3] PCI: Rework default handling of suspend and resume

[Rafael J. Wysocki]

On Sunday, 7 of December 2008, Greg KH wrote:
> On Sat, Dec 06, 2008 at 10:00:35AM -0800, Linus Torvalds wrote:
> > 
> > 
> > On Sat, 6 Dec 2008, Rafael J. Wysocki wrote:
> > > 
> > > So, to fix the issue at hand, I'd like the $subject patch to go first.  Then,
> > > there is a major update of the new framework waiting for .29 in the Greg's
> > > tree (that's the main reason why nobody uses it so far, BTW) and I'd really
> > > prefer it to go next.  After it's been merged, I'm going to add the mandatory
> > > suspend-resume things (save state and go to a low power state on suspend,
> > > restore state on resume) to the new framework in a separete patch.
> > > 
> > > Is this plan acceptable?
> > 
> > Sounds good to me. And assuming Jesse/Greg are all aboard, I'll just wait 
> > for the pull requests from Jesse and Greg.
> 
> No objection from me, I'll wait for Jesse to "go first" in the .29 merge
> window.

Unfortunately, the merge of the $subject patch with the one in your tree
results in code that doesn't compile.  Namely, some lines of code that the
$subject patch relies on are removed by the patch in your tree.

If there is no objection from Jesse and if you don't mind, I'll prepare a
version of the $subject patch on top of the patch in your tree and send it to
you.

Thanks,
Rafael

Re: [PATCH 2/3] PCI: Suspend and resume PCI Express ports with interrupts disabled

[Rafael J. Wysocki]

On Sunday, 7 of December 2008, Jesse Barnes wrote:
> On Saturday, December 6, 2008 9:46 am Rafael J. Wysocki wrote:
> > On Saturday, 6 of December 2008, Linus Torvalds wrote:
> > > On Sat, 6 Dec 2008, Rafael J. Wysocki wrote:
> > > > I think it should go through Jesse?
> > >
> > > Probably correct. And we want it in -next, so that it can get some
> > > testing even before I open the merge window. Because I hope everybody
> > > realizes that there's no way we're doing this in 2.6.28, and we'll leave
> > > the broken and unreliable suspend.
> > >
> > > Because afaik this is not a new bug (I tried to push a patch to do
> > > suspend_late/resume_early for the PCI code a _loong_ time ago, but it
> > > never got merged), and the only reason it showed up as a regression was
> > > almost certainly simply that we've always had this.
> > >
> > > IOW, suspend/resume has always been dodgy wrt interrupts, and there's
> > > some luck involved. And your machine just happened to get unlucky.
> > >
> > > I'd love to fix this in 2.6.28, but it's just not reasonable - it needs
> > > widespread testing with an early -rc merge. And if it turns out to fix a
> > > lot of machines, and there are no regressions, we can always back-port it
> > > later.
> >
> > I agree.
> 
> I'll stuff it into my -next branch tonight.

Well, if the [1/3] patch goes into your tree as is, there will be a bad merge
conflict between your tree and the Greg's one.  I think it's better if I rebase
that patch on top of the Greg's tree and push it to him (please see my last
message to Greg, http://lkml.org/lkml/2008/12/7/58).

The $subject patch is safe to pick up, though.

Thanks,
Rafael

Re: [linux-pm] [PATCH 1/3] PCI: Rework default handling of suspend and resume

[Rafael J. Wysocki]

On Sunday, 7 of December 2008, Alan Stern wrote:
> On Sat, 6 Dec 2008, Rafael J. Wysocki wrote:
> 
> > > Rafael, I'd be happy to help with fixing up the USB PCI PM code.  At
> > > this point I'm not sure exactly what's needed, though.  For instance,
> > > is there any compelling reason to switch over to the new dev_pm_ops
> > > approach?
> > 
> > Certainly not at the moment.  There will be a reason some time after .29.
> > 
> > That said, it apparently is possible to clean up the resume callbacks of PCI
> > USB controllers, as mentioned here: http://lkml.org/lkml/2008/12/6/38
> > 
> > > And what should the correct sequence of calls be?
> > 
> > Well, that's something I'm not exactly sure about myself.  Surely it seems
> > reasonable to call pci_restore_state() with interrupts disabled and do the rest
> > of resume after that.  Also, I think that the core could execute things like
> > pci_enable_device() during resume and pci_set_power_state()/pci_enable_wake()
> > on suspend so that the drivers didn't have to.  This way we could reduce code
> > duplication quite a bit.
> 
> Do you plan to change the PCI core to do these things any time soon?  

I'm going to do that after the patches from this series are merged.

> Wouldn't that require changing a whole bunch of PCI drivers too?

Only those that start to use the new framework before this happens
(which probably is only MMC at this point).

> I tend to agree that having the core take care of these choreographed
> activities would be good -- it would leave less room for drivers to
> make mistakes.
> 
> So for now maybe it would be best just to rearrange the existing calls
> in USB, and wait for the core changes before doing anything more
> ambitious.

Sounds good.

Thanks,
Rafael

Re: [linux-pm] [PATCH 1/3] PCI: Rework default handling of suspend and resume

[Rafael J. Wysocki]

On Sunday, 7 of December 2008, Linus Torvalds wrote:
> 
> On Sat, 6 Dec 2008, Linus Torvalds wrote:
> > 
> > And btw, I'm talking suspend, not hibernate. 

Even as far as hibernation is concerned, I wouldn't _expect_ any BIOS to do
anything like this as long as we use the ACPI facility to enter S4.

> And, btw, even if anybody actually does this, it should be up to the 
> interrupt controller logic to re-initialize the interrupts so that they 
> are back where they belong. IOW, we should never show such _idiotic_ 
> brokenness to any actual driver, it should all be remapped and handled 
> below them.
> 
> And I still have never heard any valid reason to do it in the first place, 
> so until somebody actually gives a real example and an explanation, I 
> would suggest ignoring the whole issue as some insane rumblings from crazy 
> hw/firmare people doing idiotic things.

While I'd really like to do that, I also think that we should make all drivers
behave in the same way in this area.

Also, we need to state clearly what the _recommended_way of doing that is,
at least as a guidance for driver writers if not for anything else.

So, can we just say that PCI drivers shouldn't free IRQs during suspend and
request them during resume, and if there's any problem that leads to, then it
should be solved differently?

Rafael

Re: [linux-pm] [PATCH 1/3] PCI: Rework default handling of suspend and resume

[Linus Torvalds]

On Sun, 7 Dec 2008, Rafael J. Wysocki wrote:
> 
> So, can we just say that PCI drivers shouldn't free IRQs during suspend and
> request them during resume, and if there's any problem that leads to, then it
> should be solved differently?

Well, there are reasons why _individual_ drivers might want to free and 
re-request irq's during suspend, so I wouldn't say it's wrong either.

For example, let's say that driver xyzzy has a suspend function (note: not 
"suspend_late" or "suspend_noirq"), and that in that suspend routine it 
turns off some slow part of itself (ie it doesn't go into D3, but let's 
say that it's a wireless device and it turns off its radio).

And maybe that driver is written in such a way that the interrupt routine 
wants to access the radio chip.

Now, the driver has two choices:

 - just make the irq handler happy with the partially suspended state (and 
   admittedly this is likely the _sane_ choice and interrupt handlers 
   should always be robust, but never mind)

 - or just make the suspend routine make sure that the chip doesn't 
   generate any interrupts, and release the interrupt handler (the latter 
   is needed because of shared interrupts - even if _that_ chip doesn't 
   generate any interrupts, the interrupt handler will still get called if 
   there are shared interrupts, of course)

IOW, I think an _acceptable_ solution to a problem like this is "hey, I'm 
turning myself off, so I'll also turn off my interrupts and disable my irq 
handler).

I just don't think it's a very -good- approach. I think it's an acceptable 
one, but it sure as hell shouldn't be the _default_ one. Especially not 
for a lot of simple devices that can probably do all of their save/restore 
entirely inside the "noirq" window, so they would never have this kind of 
issue anyway.

			Linus

Re: [PATCH 1/3] PCI: Rework default handling of suspend and resume

[Linus Torvalds]

On Sun, 7 Dec 2008, Rafael J. Wysocki wrote:
> 
> If there is no objection from Jesse and if you don't mind, I'll prepare a
> version of the $subject patch on top of the patch in your tree and send it to
> you.

Rafael: there's a bug in your 1/3 patch. 

It looks like "pci_save_state()" is currently unhappy with being called 
with interrupts disabled. Or at least "pci_save_pci[ex]_state()" state 
are. They both do a kzalloc(GFP_KERNEL).

So you should change that GFP_KERNEL into a GFP_ATOMIC. Or do something 
more complicated like pre-allocate them during early suspend, but just 
changing it to GFP_ATOMIC seems to be the trivial fix.

I'm not seeing any other issues with saving/restoring things with irq's 
disabled, but people should be on the lookout for details like this.

			Linus

Re: [linux-pm] [PATCH 1/3] PCI: Rework default handling of suspend and resume

[Arjan van de Ven]

On Sun, 7 Dec 2008 14:39:27 +0100
"Rafael J. Wysocki" <rjw@sisk.pl> wrote:

> On Sunday, 7 of December 2008, Linus Torvalds wrote:
> > 
> > On Sat, 6 Dec 2008, Linus Torvalds wrote:
> > > 
> > > And btw, I'm talking suspend, not hibernate. 
> 
> Even as far as hibernation is concerned, I wouldn't _expect_ any BIOS
> to do anything like this as long as we use the ACPI facility to enter
> S4.

there are funky scenarios where the BIOS ends up .. not knowing.
Like

you boot your laptop
you then hot-dock your laptop
then you suspend (say S4)

..
during resume, the bios sees a very different system than it saw before.
I can totally imagine not all of them getting it right, esp if other
OSes would just re-register interrupts

Re: [PATCH 1/3] PCI: Rework default handling of suspend and resume

[Greg KH]

On Sun, Dec 07, 2008 at 01:47:18PM +0100, Rafael J. Wysocki wrote:
> On Sunday, 7 of December 2008, Greg KH wrote:
> > On Sat, Dec 06, 2008 at 10:00:35AM -0800, Linus Torvalds wrote:
> > > 
> > > 
> > > On Sat, 6 Dec 2008, Rafael J. Wysocki wrote:
> > > > 
> > > > So, to fix the issue at hand, I'd like the $subject patch to go first.  Then,
> > > > there is a major update of the new framework waiting for .29 in the Greg's
> > > > tree (that's the main reason why nobody uses it so far, BTW) and I'd really
> > > > prefer it to go next.  After it's been merged, I'm going to add the mandatory
> > > > suspend-resume things (save state and go to a low power state on suspend,
> > > > restore state on resume) to the new framework in a separete patch.
> > > > 
> > > > Is this plan acceptable?
> > > 
> > > Sounds good to me. And assuming Jesse/Greg are all aboard, I'll just wait 
> > > for the pull requests from Jesse and Greg.
> > 
> > No objection from me, I'll wait for Jesse to "go first" in the .29 merge
> > window.
> 
> Unfortunately, the merge of the $subject patch with the one in your tree
> results in code that doesn't compile.  Namely, some lines of code that the
> $subject patch relies on are removed by the patch in your tree.
> 
> If there is no objection from Jesse and if you don't mind, I'll prepare a
> version of the $subject patch on top of the patch in your tree and send it to
> you.

I sure don't mind.

thanks,

greg k-h

Re: [PATCH 1/3] PCI: Rework default handling of suspend and resume

[Rafael J. Wysocki]

On Sunday, 7 of December 2008, Linus Torvalds wrote:
> 
> On Sun, 7 Dec 2008, Rafael J. Wysocki wrote:
> > 
> > If there is no objection from Jesse and if you don't mind, I'll prepare a
> > version of the $subject patch on top of the patch in your tree and send it to
> > you.
> 
> Rafael: there's a bug in your 1/3 patch. 
> 
> It looks like "pci_save_state()" is currently unhappy with being called 
> with interrupts disabled. Or at least "pci_save_pci[ex]_state()" state 
> are. They both do a kzalloc(GFP_KERNEL).
> 
> So you should change that GFP_KERNEL into a GFP_ATOMIC. Or do something 
> more complicated like pre-allocate them during early suspend, but just 
> changing it to GFP_ATOMIC seems to be the trivial fix.
> 
> I'm not seeing any other issues with saving/restoring things with irq's 
> disabled, but people should be on the lookout for details like this.

I overlooked that, sorry.

What about doing the following in addition to patch [1/3]?

Rafael

---
 drivers/pci/pci.c   |   73 ++++++++++++++++++++++++++++++++++++----------------
 drivers/pci/pci.h   |    1 
 drivers/pci/probe.c |    3 ++
 3 files changed, 55 insertions(+), 22 deletions(-)

Index: linux-2.6/drivers/pci/probe.c
===================================================================
--- linux-2.6.orig/drivers/pci/probe.c
+++ linux-2.6/drivers/pci/probe.c
@@ -958,6 +958,9 @@ static void pci_init_capabilities(struct
 	/* MSI/MSI-X list */
 	pci_msi_init_pci_dev(dev);
 
+	/* Buffers for saving PCIe and PCI-X capabilities */
+	pci_allocate_cap_save_buffers(dev);
+
 	/* Power Management */
 	pci_pm_init(dev);
 
Index: linux-2.6/drivers/pci/pci.h
===================================================================
--- linux-2.6.orig/drivers/pci/pci.h
+++ linux-2.6/drivers/pci/pci.h
@@ -41,6 +41,7 @@ struct pci_platform_pm_ops {
 
 extern int pci_set_platform_pm(struct pci_platform_pm_ops *ops);
 extern void pci_pm_init(struct pci_dev *dev);
+extern void pci_allocate_cap_save_buffers(struct pci_dev *dev);
 
 extern int pci_user_read_config_byte(struct pci_dev *dev, int where, u8 *val);
 extern int pci_user_read_config_word(struct pci_dev *dev, int where, u16 *val);
Index: linux-2.6/drivers/pci/pci.c
===================================================================
--- linux-2.6.orig/drivers/pci/pci.c
+++ linux-2.6/drivers/pci/pci.c
@@ -640,19 +640,14 @@ static int pci_save_pcie_state(struct pc
 	int pos, i = 0;
 	struct pci_cap_saved_state *save_state;
 	u16 *cap;
-	int found = 0;
 
 	pos = pci_find_capability(dev, PCI_CAP_ID_EXP);
 	if (pos <= 0)
 		return 0;
 
 	save_state = pci_find_saved_cap(dev, PCI_CAP_ID_EXP);
-	if (!save_state)
-		save_state = kzalloc(sizeof(*save_state) + sizeof(u16) * 4, GFP_KERNEL);
-	else
-		found = 1;
 	if (!save_state) {
-		dev_err(&dev->dev, "out of memory in pci_save_pcie_state\n");
+		dev_err(&dev->dev, "buffer not found in %s\n", __FUNCTION__);
 		return -ENOMEM;
 	}
 	cap = (u16 *)&save_state->data[0];
@@ -661,9 +656,7 @@ static int pci_save_pcie_state(struct pc
 	pci_read_config_word(dev, pos + PCI_EXP_LNKCTL, &cap[i++]);
 	pci_read_config_word(dev, pos + PCI_EXP_SLTCTL, &cap[i++]);
 	pci_read_config_word(dev, pos + PCI_EXP_RTCTL, &cap[i++]);
-	save_state->cap_nr = PCI_CAP_ID_EXP;
-	if (!found)
-		pci_add_saved_cap(dev, save_state);
+
 	return 0;
 }
 
@@ -688,30 +681,21 @@ static void pci_restore_pcie_state(struc
 
 static int pci_save_pcix_state(struct pci_dev *dev)
 {
-	int pos, i = 0;
+	int pos;
 	struct pci_cap_saved_state *save_state;
-	u16 *cap;
-	int found = 0;
 
 	pos = pci_find_capability(dev, PCI_CAP_ID_PCIX);
 	if (pos <= 0)
 		return 0;
 
 	save_state = pci_find_saved_cap(dev, PCI_CAP_ID_PCIX);
-	if (!save_state)
-		save_state = kzalloc(sizeof(*save_state) + sizeof(u16), GFP_KERNEL);
-	else
-		found = 1;
 	if (!save_state) {
-		dev_err(&dev->dev, "out of memory in pci_save_pcie_state\n");
+		dev_err(&dev->dev, "buffer not found in %s\n", __FUNCTION__);
 		return -ENOMEM;
 	}
-	cap = (u16 *)&save_state->data[0];
 
-	pci_read_config_word(dev, pos + PCI_X_CMD, &cap[i++]);
-	save_state->cap_nr = PCI_CAP_ID_PCIX;
-	if (!found)
-		pci_add_saved_cap(dev, save_state);
+	pci_read_config_word(dev, pos + PCI_X_CMD, (u16 *)save_state->data);
+
 	return 0;
 }
 
@@ -1301,6 +1285,51 @@ void pci_pm_init(struct pci_dev *dev)
 }
 
 /**
+ * pci_add_save_buffer - allocate buffer for saving given capability registers
+ * @dev: the PCI device
+ * @cap: the capability to allocate the buffer for
+ * @size: requested size of the buffer
+ */
+static int pci_add_cap_save_buffer(
+	struct pci_dev *dev, char cap, unsigned int size)
+{
+	int pos;
+	struct pci_cap_saved_state *save_state;
+
+	pos = pci_find_capability(dev, cap);
+	if (pos <= 0)
+		return 0;
+
+	save_state = kzalloc(sizeof(*save_state) + size, GFP_KERNEL);
+	if (!save_state)
+		return -ENOMEM;
+
+	save_state->cap_nr = cap;
+	pci_add_saved_cap(dev, save_state);
+
+	return 0;
+}
+
+/**
+ * pci_allocate_cap_save_buffers - allocate buffers for saving capabilities
+ * @dev: the PCI device
+ */
+void pci_allocate_cap_save_buffers(struct pci_dev *dev)
+{
+	int error;
+
+	error = pci_add_cap_save_buffer(dev, PCI_CAP_ID_EXP, 4 * sizeof(u16));
+	if (error)
+		dev_err(&dev->dev,
+			"unable to preallocate PCI Express save buffer\n");
+
+	error = pci_add_cap_save_buffer(dev, PCI_CAP_ID_PCIX, sizeof(u16));
+	if (error)
+		dev_err(&dev->dev,
+			"unable to preallocate PCI-X save buffer\n");
+}
+
+/**
  * pci_enable_ari - enable ARI forwarding if hardware support it
  * @dev: the PCI device
  */

[PATCH 1/3] PCI: Rework default handling of suspend and resume (rebased)

[Rafael J. Wysocki]

On Sunday, 7 of December 2008, Greg KH wrote:
> On Sun, Dec 07, 2008 at 01:47:18PM +0100, Rafael J. Wysocki wrote:
> > On Sunday, 7 of December 2008, Greg KH wrote:
> > > On Sat, Dec 06, 2008 at 10:00:35AM -0800, Linus Torvalds wrote:
> > > > 
> > > > 
> > > > On Sat, 6 Dec 2008, Rafael J. Wysocki wrote:
> > > > > 
> > > > > So, to fix the issue at hand, I'd like the $subject patch to go first.  Then,
> > > > > there is a major update of the new framework waiting for .29 in the Greg's
> > > > > tree (that's the main reason why nobody uses it so far, BTW) and I'd really
> > > > > prefer it to go next.  After it's been merged, I'm going to add the mandatory
> > > > > suspend-resume things (save state and go to a low power state on suspend,
> > > > > restore state on resume) to the new framework in a separete patch.
> > > > > 
> > > > > Is this plan acceptable?
> > > > 
> > > > Sounds good to me. And assuming Jesse/Greg are all aboard, I'll just wait 
> > > > for the pull requests from Jesse and Greg.
> > > 
> > > No objection from me, I'll wait for Jesse to "go first" in the .29 merge
> > > window.
> > 
> > Unfortunately, the merge of the $subject patch with the one in your tree
> > results in code that doesn't compile.  Namely, some lines of code that the
> > $subject patch relies on are removed by the patch in your tree.
> > 
> > If there is no objection from Jesse and if you don't mind, I'll prepare a
> > version of the $subject patch on top of the patch in your tree and send it to
> > you.
> 
> I sure don't mind.

OK, thanks.

So, please add the patch below to your tree (Jesse doesn't object).

The GFP_KERNEL issue noticed by Linus will be fixed by a separate patch going
through Jesse.

Thanks,
Rafael

---
From: Rafael J. Wysocki <rjw@sisk.pl>
Subject: PCI: Rework default handling of suspend and resume

Rework the handling of suspend and resume of PCI devices which have
no drivers or the drivers of which do not provide any suspend-resume
callbacks in such a way that their standard PCI configuration
registers will be saved and restored with interrupts disabled.  This
should prevent such devices, including PCI bridges, from being
resumed too late to be able to function correctly during the resume
of the other PCI devices that may depend on them.

Also, to remove one possible source of future confusion, drop the
default handling of suspend and resume for PCI devices with drivers
providing the 'pm' object introduced by the new suspend-resume
framework (there are no such PCI drivers at the moment).

This patch addresses the regression from 2.6.26 tracked as
http://bugzilla.kernel.org/show_bug.cgi?id=12121 .

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
---
 drivers/pci/pci-driver.c |   94 +++++++++++++++++++++++++++++++----------------
 1 file changed, 63 insertions(+), 31 deletions(-)

Index: linux-2.6/drivers/pci/pci-driver.c
===================================================================
--- linux-2.6.orig/drivers/pci/pci-driver.c
+++ linux-2.6/drivers/pci/pci-driver.c
@@ -300,6 +300,14 @@ static void pci_device_shutdown(struct d
 
 #ifdef CONFIG_PM_SLEEP
 
+static bool pci_has_legacy_pm_support(struct pci_dev *pci_dev)
+{
+	struct pci_driver *drv = pci_dev->driver;
+
+	return drv && (drv->suspend || drv->suspend_late || drv->resume
+		|| drv->resume_early);
+}
+
 /*
  * Default "suspend" method for devices that have no driver provided suspend,
  * or not even a driver at all.
@@ -317,14 +325,22 @@ static void pci_default_pm_suspend(struc
 
 /*
  * Default "resume" method for devices that have no driver provided resume,
- * or not even a driver at all.
+ * or not even a driver at all (first part).
  */
-static int pci_default_pm_resume(struct pci_dev *pci_dev)
+static void pci_default_pm_resume_early(struct pci_dev *pci_dev)
 {
-	int retval = 0;
-
 	/* restore the PCI config space */
 	pci_restore_state(pci_dev);
+}
+
+/*
+ * Default "resume" method for devices that have no driver provided resume,
+ * or not even a driver at all (second part).
+ */
+static int pci_default_pm_resume_late(struct pci_dev *pci_dev)
+{
+	int retval;
+
 	/* if the device was enabled before suspend, reenable */
 	retval = pci_reenable_device(pci_dev);
 	/*
@@ -371,10 +387,12 @@ static int pci_legacy_resume(struct devi
 	struct pci_dev * pci_dev = to_pci_dev(dev);
 	struct pci_driver * drv = pci_dev->driver;
 
-	if (drv && drv->resume)
+	if (drv && drv->resume) {
 		error = drv->resume(pci_dev);
-	else
-		error = pci_default_pm_resume(pci_dev);
+	} else {
+		pci_default_pm_resume_early(pci_dev);
+		error = pci_default_pm_resume_late(pci_dev);
+	}
 	return error;
 }
 
@@ -420,10 +438,8 @@ static int pci_pm_suspend(struct device 
 		if (drv->pm->suspend) {
 			error = drv->pm->suspend(dev);
 			suspend_report_result(drv->pm->suspend, error);
-		} else {
-			pci_default_pm_suspend(pci_dev);
 		}
-	} else {
+	} else if (pci_has_legacy_pm_support(pci_dev)) {
 		error = pci_legacy_suspend(dev, PMSG_SUSPEND);
 	}
 	pci_fixup_device(pci_fixup_suspend, pci_dev);
@@ -433,6 +449,7 @@ static int pci_pm_suspend(struct device 
 
 static int pci_pm_suspend_noirq(struct device *dev)
 {
+	struct pci_dev *pci_dev = to_pci_dev(dev);
 	struct device_driver *drv = dev->driver;
 	int error = 0;
 
@@ -441,8 +458,10 @@ static int pci_pm_suspend_noirq(struct d
 			error = drv->pm->suspend_noirq(dev);
 			suspend_report_result(drv->pm->suspend_noirq, error);
 		}
-	} else {
+	} else if (pci_has_legacy_pm_support(pci_dev)) {
 		error = pci_legacy_suspend_late(dev, PMSG_SUSPEND);
+	} else {
+		pci_default_pm_suspend(pci_dev);
 	}
 
 	return error;
@@ -452,15 +471,17 @@ static int pci_pm_resume(struct device *
 {
 	struct pci_dev *pci_dev = to_pci_dev(dev);
 	struct device_driver *drv = dev->driver;
-	int error;
+	int error = 0;
 
 	pci_fixup_device(pci_fixup_resume, pci_dev);
 
 	if (drv && drv->pm) {
-		error = drv->pm->resume ? drv->pm->resume(dev) :
-			pci_default_pm_resume(pci_dev);
-	} else {
+		if (drv->pm->resume)
+			error = drv->pm->resume(dev);
+	} else if (pci_has_legacy_pm_support(pci_dev)) {
 		error = pci_legacy_resume(dev);
+	} else {
+		error = pci_default_pm_resume_late(pci_dev);
 	}
 
 	return error;
@@ -468,6 +489,7 @@ static int pci_pm_resume(struct device *
 
 static int pci_pm_resume_noirq(struct device *dev)
 {
+	struct pci_dev *pci_dev = to_pci_dev(dev);
 	struct device_driver *drv = dev->driver;
 	int error = 0;
 
@@ -476,8 +498,10 @@ static int pci_pm_resume_noirq(struct de
 	if (drv && drv->pm) {
 		if (drv->pm->resume_noirq)
 			error = drv->pm->resume_noirq(dev);
-	} else {
+	} else if (pci_has_legacy_pm_support(pci_dev)) {
 		error = pci_legacy_resume_early(dev);
+	} else {
+		pci_default_pm_resume_early(pci_dev);
 	}
 
 	return error;
@@ -504,10 +528,8 @@ static int pci_pm_freeze(struct device *
 		if (drv->pm->freeze) {
 			error = drv->pm->freeze(dev);
 			suspend_report_result(drv->pm->freeze, error);
-		} else {
-			pci_default_pm_suspend(pci_dev);
 		}
-	} else {
+	} else if (pci_has_legacy_pm_support(pci_dev)) {
 		error = pci_legacy_suspend(dev, PMSG_FREEZE);
 		pci_fixup_device(pci_fixup_suspend, pci_dev);
 	}
@@ -517,6 +539,7 @@ static int pci_pm_freeze(struct device *
 
 static int pci_pm_freeze_noirq(struct device *dev)
 {
+	struct pci_dev *pci_dev = to_pci_dev(dev);
 	struct device_driver *drv = dev->driver;
 	int error = 0;
 
@@ -525,8 +548,10 @@ static int pci_pm_freeze_noirq(struct de
 			error = drv->pm->freeze_noirq(dev);
 			suspend_report_result(drv->pm->freeze_noirq, error);
 		}
-	} else {
+	} else if (pci_has_legacy_pm_support(pci_dev)) {
 		error = pci_legacy_suspend_late(dev, PMSG_FREEZE);
+	} else {
+		pci_default_pm_suspend(pci_dev);
 	}
 
 	return error;
@@ -534,14 +559,15 @@ static int pci_pm_freeze_noirq(struct de
 
 static int pci_pm_thaw(struct device *dev)
 {
+	struct pci_dev *pci_dev = to_pci_dev(dev);
 	struct device_driver *drv = dev->driver;
 	int error = 0;
 
 	if (drv && drv->pm) {
 		if (drv->pm->thaw)
 			error =  drv->pm->thaw(dev);
-	} else {
-		pci_fixup_device(pci_fixup_resume, to_pci_dev(dev));
+	} else if (pci_has_legacy_pm_support(pci_dev)) {
+		pci_fixup_device(pci_fixup_resume, pci_dev);
 		error = pci_legacy_resume(dev);
 	}
 
@@ -550,13 +576,14 @@ static int pci_pm_thaw(struct device *de
 
 static int pci_pm_thaw_noirq(struct device *dev)
 {
+	struct pci_dev *pci_dev = to_pci_dev(dev);
 	struct device_driver *drv = dev->driver;
 	int error = 0;
 
 	if (drv && drv->pm) {
 		if (drv->pm->thaw_noirq)
 			error = drv->pm->thaw_noirq(dev);
-	} else {
+	} else if (pci_has_legacy_pm_support(pci_dev)) {
 		pci_fixup_device(pci_fixup_resume_early, to_pci_dev(dev));
 		error = pci_legacy_resume_early(dev);
 	}
@@ -566,17 +593,18 @@ static int pci_pm_thaw_noirq(struct devi
 
 static int pci_pm_poweroff(struct device *dev)
 {
+	struct pci_dev *pci_dev = to_pci_dev(dev);
 	struct device_driver *drv = dev->driver;
 	int error = 0;
 
-	pci_fixup_device(pci_fixup_suspend, to_pci_dev(dev));
+	pci_fixup_device(pci_fixup_suspend, pci_dev);
 
 	if (drv && drv->pm) {
 		if (drv->pm->poweroff) {
 			error = drv->pm->poweroff(dev);
 			suspend_report_result(drv->pm->poweroff, error);
 		}
-	} else {
+	} else if (pci_has_legacy_pm_support(pci_dev)) {
 		error = pci_legacy_suspend(dev, PMSG_HIBERNATE);
 	}
 
@@ -593,7 +621,7 @@ static int pci_pm_poweroff_noirq(struct 
 			error = drv->pm->poweroff_noirq(dev);
 			suspend_report_result(drv->pm->poweroff_noirq, error);
 		}
-	} else {
+	} else if (pci_has_legacy_pm_support(to_pci_dev(dev))) {
 		error = pci_legacy_suspend_late(dev, PMSG_HIBERNATE);
 	}
 
@@ -604,13 +632,15 @@ static int pci_pm_restore(struct device 
 {
 	struct pci_dev *pci_dev = to_pci_dev(dev);
 	struct device_driver *drv = dev->driver;
-	int error;
+	int error = 0;
 
 	if (drv && drv->pm) {
-		error = drv->pm->restore ? drv->pm->restore(dev) :
-			pci_default_pm_resume(pci_dev);
-	} else {
+		if (drv->pm->restore)
+			error = drv->pm->restore(dev);
+	} else if (pci_has_legacy_pm_support(pci_dev)) {
 		error = pci_legacy_resume(dev);
+	} else {
+		error = pci_default_pm_resume_late(pci_dev);
 	}
 	pci_fixup_device(pci_fixup_resume, pci_dev);
 
@@ -628,8 +658,10 @@ static int pci_pm_restore_noirq(struct d
 	if (drv && drv->pm) {
 		if (drv->pm->restore_noirq)
 			error = drv->pm->restore_noirq(dev);
-	} else {
+	} else if (pci_has_legacy_pm_support(pci_dev)) {
 		error = pci_legacy_resume_early(dev);
+	} else {
+		pci_default_pm_resume_early(pci_dev);
 	}
 	pci_fixup_device(pci_fixup_resume_early, pci_dev);
 

"APIC error on CPU1: 00(40)" during resume (was: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500)

[Frans Pop]

Anybody interested in persuing this issue?

On Thursday 04 December 2008, Linus Torvalds wrote:
> Ingo, Len, can you check the end of the email about the apparent
> very-early interrupt issue? Can we get into acpi_ec_gpe_handler()
> without interrupts being enabled some way?
>
> HOWEVER. Having now looked through your fuller dmesg output even for
> the _successful_ case, I actually find a few things that are a bit
> worrying.
[...]
> The third thing that worries me is the _very_ early occurrence of
>
> 	ACPI: Waking up from system sleep state S3
> 	APIC error on CPU1: 00(40)
> 	ACPI: EC: non-query interrupt received, switching to interrupt mode
>
> Now, that "APIC error" thing is worrisome. It's worrisome for multiple
> reasons:
>
>  - errors are never good (0x40 means "received illegal vector",
>    whatever caused _that_)
>
>  - more importantly, it seems to imply that interrupts are enabled on
>    CPU1, and they sure as hell shouldn't be enabled at this stage!
>
>    Do we perhaps have a SMP resume bug where we resume the other CPU's
>    with interrupts enabled?
>
>  - the "ACPI: EC: non-query interrupt received, switching to interrupt
>    mode" thing is from ACPI, and _also_ implies that interrupts are on.
>
> Why are interrupts enabled that early? I really don't like seeing
> interrupts enabled before we've even done the basic PCI resume.
>
> I'd really like to resume the other CPU's much later (last in the whole
> sequnce, long after we've set up devices), but the f'ing ACPI rules
> seem to be against that. And maybe some setup actually needs the CPU's
> alive to act as a bridge for IO (eg with HT or CSI).

Re: "APIC error on CPU1: 00(40)" during resume (was: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500)

[Linus Torvalds]

On Wed, 10 Dec 2008, Frans Pop wrote:
>
> Anybody interested in persuing this issue?

> > The third thing that worries me is the _very_ early occurrence of
> >
> > 	ACPI: Waking up from system sleep state S3
> > 	APIC error on CPU1: 00(40)
> > 	ACPI: EC: non-query interrupt received, switching to interrupt mode

Well, the "too early" part is fixed with the PCI resume changes in -next, 
and googling for "APIC error on CPU1: 00(40)" shows that it's actually 
pretty common. Which is sad, but makes it somewhat less scary.

The fact that it happens at resume for you (and not randomly) does imply 
that we perhaps don't have a wonderful APIC wakeup sequence and are doing 
something slightly wrong. But it likely isn't a big deal.

Is that message new? If it is, maybe you can pinpoint roughly when it 
started happening, and we could try guess which change triggered it.

		Linus

Re: "APIC error on CPU1: 00(40)" during resume (was: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500)

[Frans Pop]

On Wednesday 10 December 2008, Linus Torvalds wrote:
> On Wed, 10 Dec 2008, Frans Pop wrote:
> > Anybody interested in persuing this issue?
> >
> > > The third thing that worries me is the _very_ early occurrence of
> > >
> > > 	ACPI: Waking up from system sleep state S3
> > > 	APIC error on CPU1: 00(40)
> > > 	ACPI: EC: non-query interrupt received, switching to interrupt
> > > mode
>
> Well, the "too early" part is fixed with the PCI resume changes in
> -next, and googling for "APIC error on CPU1: 00(40)" shows that it's
> actually pretty common. Which is sad, but makes it somewhat less scary.
>
> The fact that it happens at resume for you (and not randomly) does
> imply that we perhaps don't have a wonderful APIC wakeup sequence and
> are doing something slightly wrong. But it likely isn't a big deal.
>
> Is that message new? If it is, maybe you can pinpoint roughly when it
> started happening, and we could try guess which change triggered it.

It's been there since 2.6.26.3, which was the first kernel I've run on 
this notebook.

Re: "APIC error on CPU1: 00(40)" during resume (was: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500)

[Linus Torvalds]

Ingo - who's the main apic person these days?

On Wed, 10 Dec 2008, Frans Pop wrote:

> On Wednesday 10 December 2008, Linus Torvalds wrote:
> > On Wed, 10 Dec 2008, Frans Pop wrote:
> > > Anybody interested in persuing this issue?
> > >
> > > > The third thing that worries me is the _very_ early occurrence of
> > > >
> > > > 	ACPI: Waking up from system sleep state S3
> > > > 	APIC error on CPU1: 00(40)
> > > > 	ACPI: EC: non-query interrupt received, switching to interrupt
> > > > mode
> >
> > Well, the "too early" part is fixed with the PCI resume changes in
> > -next, and googling for "APIC error on CPU1: 00(40)" shows that it's
> > actually pretty common. Which is sad, but makes it somewhat less scary.
> >
> > The fact that it happens at resume for you (and not randomly) does
> > imply that we perhaps don't have a wonderful APIC wakeup sequence and
> > are doing something slightly wrong. But it likely isn't a big deal.
> >
> > Is that message new? If it is, maybe you can pinpoint roughly when it
> > started happening, and we could try guess which change triggered it.
> 
> It's been there since 2.6.26.3, which was the first kernel I've run on 
> this notebook.

Hmm. Our IO-APIC reprogramming looks pretty simple, and may well be 
correct.

However, it looks like our _local_ APIC suspend/resume is a total piece of 
sh*t.  It's set up as a "system device" and has a single suspend/resume 
buffer, but the local APIC is a per-CPU thing. We even have a comment 
there (written by yours trule back in 2003!) that says:

         * FIXME! This will be wrong if we ever support suspend on
         * SMP! We'll need to do this as part of the CPU restore!

and back then suspend/resume on SMP was just a crazy notion, but now it's 
obviously every-day reality. 

So it looks like we don't reprogram the APIC -at-all- on secondary CPU's.

What am I missing?

			Linus

Re: "APIC error on CPU1: 00(40)" during resume (was: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500)

[Matthew Garrett]

On Wed, Dec 10, 2008 at 08:26:37AM -0800, Linus Torvalds wrote:

> So it looks like we don't reprogram the APIC -at-all- on secondary CPU's.
> 
> What am I missing?

We unplug all CPUs except the boot one at suspend time. Does the APIC 
get reprogrammed when they're replugged on resume?

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: "APIC error on CPU1: 00(40)" during resume (was: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500)

[Linus Torvalds]

On Wed, 10 Dec 2008, Matthew Garrett wrote:

> On Wed, Dec 10, 2008 at 08:26:37AM -0800, Linus Torvalds wrote:
> 
> > So it looks like we don't reprogram the APIC -at-all- on secondary CPU's.
> > 
> > What am I missing?
> 
> We unplug all CPUs except the boot one at suspend time. Does the APIC 
> get reprogrammed when they're replugged on resume?

Ahh, indeed. That ends up doing setup_local_APIC() in smp_callin().

I wonder if we should do that from apic_resume() too - instead of saving 
any state we could probably just re-initialize it.

The setup_local_APIC() function also seems to be a lot more careful than 
"resume_apic()" is about ordering (well, at least it has _comments_ on the 
ordering), and it does things like ack'ing all pending irq's.

Hmm.

			Linus

Re: "APIC error on CPU1: 00(40)" during resume (was: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500)

[Ingo Molnar]

* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> Ingo - who's the main apic person these days?

When it comes to blame someone for bugs then it's me :-)

When it comes to code details, it's multiple people: Yinghai, Suresh, 
Venki, Maciej and Thomas, Peter and me as x86 maintainers. I tried to Cc: 
everyone.

> On Wed, 10 Dec 2008, Frans Pop wrote:
> 
> > On Wednesday 10 December 2008, Linus Torvalds wrote:
> > > On Wed, 10 Dec 2008, Frans Pop wrote:
> > > > Anybody interested in persuing this issue?
> > > >
> > > > > The third thing that worries me is the _very_ early occurrence of
> > > > >
> > > > > 	ACPI: Waking up from system sleep state S3
> > > > > 	APIC error on CPU1: 00(40)
> > > > > 	ACPI: EC: non-query interrupt received, switching to interrupt
> > > > > mode
> > >
> > > Well, the "too early" part is fixed with the PCI resume changes in
> > > -next, and googling for "APIC error on CPU1: 00(40)" shows that it's
> > > actually pretty common. Which is sad, but makes it somewhat less scary.
> > >
> > > The fact that it happens at resume for you (and not randomly) does
> > > imply that we perhaps don't have a wonderful APIC wakeup sequence and
> > > are doing something slightly wrong. But it likely isn't a big deal.
> > >
> > > Is that message new? If it is, maybe you can pinpoint roughly when it
> > > started happening, and we could try guess which change triggered it.
> > 
> > It's been there since 2.6.26.3, which was the first kernel I've run on 
> > this notebook.
> 
> Hmm. Our IO-APIC reprogramming looks pretty simple, and may well be 
> correct.
> 
> However, it looks like our _local_ APIC suspend/resume is a total piece 
> of sh*t.  It's set up as a "system device" and has a single 
> suspend/resume buffer, but the local APIC is a per-CPU thing. We even 
> have a comment there (written by yours trule back in 2003!) that says:
> 
>          * FIXME! This will be wrong if we ever support suspend on
>          * SMP! We'll need to do this as part of the CPU restore!
> 
> and back then suspend/resume on SMP was just a crazy notion, but now 
> it's obviously every-day reality.
> 
> So it looks like we don't reprogram the APIC -at-all- on secondary 
> CPU's.
> 
> What am I missing?

we do reset it - local APIC timer IRQs would not be working, the NMI 
watchdog wouldnt be working, we wouldnt be able to do cross-IPIs nor TLB 
flushes etc. - so a non-working lapic is the sure way to a system lockup.
But the resume/hotplug path is still a maze, agreed.

regarding those APIC error messages:

> > > > >       ACPI: Waking up from system sleep state S3
> > > > >       APIC error on CPU1: 00(40)
> > > > >       ACPI: EC: non-query interrupt received, switching to interrupt

that does suggest that the APIC was re-enabled (we dont get any APIC 
error exceptions otherwise!), and its LVT was programmed as well, but 
somehow we got an erroneous APIC message from an illegal vector.

Illegal APIC message vectors can have two sources in practice:

 1) the system bus being thermally unstable and corrupting APIC messages 
    that would randomly contain the wrong vector (zero for example).
    I had one (old) testbox that would do this. (Maybe other hw 
    conditions can animate the southbridge to do this to us too.)

 2) _another CPU_ sending an IPI with an illegal vector field. An APIC 
    vector is 'illegal' if it is below 16 (architecturally protected 
    exception entries), or if it points to an IDT entry that is not
    present.

#2: in this case would mean another CPU has set a target vector smaller
than 16: we dont have any IDT entry that is explicitly non-existent (we 
have a dummy entry mapped for everything). That seems unlikely - but we 
could stick in a WARN_ON_ONCE() into the IPI send methods to catch this. 

[ sidenote: as weird as it might seem it is valid IPI use to trigger
  architectural exception vectors between 16 and 31. ]

#1: seems like a too easy path out to blame the hw for it :-/ By all 
means this has the appearance of kernel-induced damage to me, and seems 
to occur when we fiddle the hw and are in a sensitive path of 
resume-wakeup. I'd blame the kernel 9 times out of 10 bugs that trigger 
at this stage.

Still i have no idea how this APIC message could be kernel-inflicted - 
even assuming buggy resume time lapic setup. The lapic timer cannot 
inject 'bad' vectors to itself AFAIK. It's pretty hard to do it even 
intentionally from another CPU, and when we do it we kill the whole 
system by flooding it with bad IPIs.

Maybe we have a window of setup where one of the LVT entries has zero in 
the vector field but is still enabled, and the hw condition (lapic timer 
tick) happens that triggers the IRQ injection - but the lapic cannot do 
it due to the zero vector? I do not see such window of setup in the APIC 
re-setup codepath though.

Maybe it's the reschedule or TLB flush IPI from another CPU somehow 
hitting the lapic in the wrong moment?

Dunno. Does anyone else on the Cc: list have another theory that matches 
up with some detail of the code?

	Ingo

Re: "APIC error on CPU1: 00(40)" during resume (was: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500)

[Maxim Levitsky]

On Wed, 2008-12-10 at 18:33 +0100, Ingo Molnar wrote:
> * Linus Torvalds <torvalds@linux-foundation.org> wrote:
> 
> > Ingo - who's the main apic person these days?
> 
> When it comes to blame someone for bugs then it's me :-)
> 
> When it comes to code details, it's multiple people: Yinghai, Suresh, 
> Venki, Maciej and Thomas, Peter and me as x86 maintainers. I tried to Cc: 
> everyone.
> 
> > On Wed, 10 Dec 2008, Frans Pop wrote:
> > 
> > > On Wednesday 10 December 2008, Linus Torvalds wrote:
> > > > On Wed, 10 Dec 2008, Frans Pop wrote:
> > > > > Anybody interested in persuing this issue?
> > > > >
> > > > > > The third thing that worries me is the _very_ early occurrence of
> > > > > >
> > > > > > 	ACPI: Waking up from system sleep state S3
> > > > > > 	APIC error on CPU1: 00(40)
> > > > > > 	ACPI: EC: non-query interrupt received, switching to interrupt
> > > > > > mode
> > > >
> > > > Well, the "too early" part is fixed with the PCI resume changes in
> > > > -next, and googling for "APIC error on CPU1: 00(40)" shows that it's
> > > > actually pretty common. Which is sad, but makes it somewhat less scary.
> > > >
> > > > The fact that it happens at resume for you (and not randomly) does
> > > > imply that we perhaps don't have a wonderful APIC wakeup sequence and
> > > > are doing something slightly wrong. But it likely isn't a big deal.
> > > >
> > > > Is that message new? If it is, maybe you can pinpoint roughly when it
> > > > started happening, and we could try guess which change triggered it.
> > > 
> > > It's been there since 2.6.26.3, which was the first kernel I've run on 
> > > this notebook.
> > 
> > Hmm. Our IO-APIC reprogramming looks pretty simple, and may well be 
> > correct.
> > 
> > However, it looks like our _local_ APIC suspend/resume is a total piece 
> > of sh*t.  It's set up as a "system device" and has a single 
> > suspend/resume buffer, but the local APIC is a per-CPU thing. We even 
> > have a comment there (written by yours trule back in 2003!) that says:
> > 
> >          * FIXME! This will be wrong if we ever support suspend on
> >          * SMP! We'll need to do this as part of the CPU restore!
> > 
> > and back then suspend/resume on SMP was just a crazy notion, but now 
> > it's obviously every-day reality.
> > 
> > So it looks like we don't reprogram the APIC -at-all- on secondary 
> > CPU's.
> > 
> > What am I missing?
> 
> we do reset it - local APIC timer IRQs would not be working, the NMI 
> watchdog wouldnt be working, we wouldnt be able to do cross-IPIs nor TLB 
> flushes etc. - so a non-working lapic is the sure way to a system lockup.
> But the resume/hotplug path is still a maze, agreed.
> 
> regarding those APIC error messages:
> 
> > > > > >       ACPI: Waking up from system sleep state S3
> > > > > >       APIC error on CPU1: 00(40)
> > > > > >       ACPI: EC: non-query interrupt received, switching to interrupt
> 
> that does suggest that the APIC was re-enabled (we dont get any APIC 
> error exceptions otherwise!), and its LVT was programmed as well, but 
> somehow we got an erroneous APIC message from an illegal vector.
> 
> Illegal APIC message vectors can have two sources in practice:
> 
>  1) the system bus being thermally unstable and corrupting APIC messages 
>     that would randomly contain the wrong vector (zero for example).
>     I had one (old) testbox that would do this. (Maybe other hw 
>     conditions can animate the southbridge to do this to us too.)
> 
>  2) _another CPU_ sending an IPI with an illegal vector field. An APIC 
>     vector is 'illegal' if it is below 16 (architecturally protected 
>     exception entries), or if it points to an IDT entry that is not
>     present.
> 
> #2: in this case would mean another CPU has set a target vector smaller
> than 16: we dont have any IDT entry that is explicitly non-existent (we 
> have a dummy entry mapped for everything). That seems unlikely - but we 
> could stick in a WARN_ON_ONCE() into the IPI send methods to catch this. 
> 
> [ sidenote: as weird as it might seem it is valid IPI use to trigger
>   architectural exception vectors between 16 and 31. ]
> 
> #1: seems like a too easy path out to blame the hw for it :-/ By all 
> means this has the appearance of kernel-induced damage to me, and seems 
> to occur when we fiddle the hw and are in a sensitive path of 
> resume-wakeup. I'd blame the kernel 9 times out of 10 bugs that trigger 
> at this stage.
> 
> Still i have no idea how this APIC message could be kernel-inflicted - 
> even assuming buggy resume time lapic setup. The lapic timer cannot 
> inject 'bad' vectors to itself AFAIK. It's pretty hard to do it even 
> intentionally from another CPU, and when we do it we kill the whole 
> system by flooding it with bad IPIs.
> 
> Maybe we have a window of setup where one of the LVT entries has zero in 
> the vector field but is still enabled, and the hw condition (lapic timer 
> tick) happens that triggers the IRQ injection - but the lapic cannot do 
> it due to the zero vector? I do not see such window of setup in the APIC 
> re-setup codepath though.
> 
> Maybe it's the reschedule or TLB flush IPI from another CPU somehow 
> hitting the lapic in the wrong moment?
> 
> Dunno. Does anyone else on the Cc: list have another theory that matches 
> up with some detail of the code?
> 
> 	Ingo


Who knows, maybe this is related...

I have a notebook (acer aspire 5720) that won't wake up again from
second resume from ram is row.

For example, this works: 'disk ram disk disk ram disk ...',
but this doesn't: 'disk ram ram'.

I found out that bios doesn't pass control to linux at all on second
resume, so there is nothing to debug.

As there is  very few places bios should touch in resume, couldn't this
be io apic/ local apic related?

It seems that a single resume sets a 'bomb' that explodes on second
resume.


I have tried noapic nolapic, but this would hang the system on first
resume, I didn't yet tested this deeply.


I know that bios uses local apic thermal interrupt to monitor cpu
temperature.




Best regards,
	Maxim Levitsky

Re: [PATCH 3/3] Sound (HDA Intel): Restore PCI configuration space with interrupts off

[Takashi Iwai]

At Sun, 07 Dec 2008 10:47:56 +0100,
I wrote:
> 
> At Sat, 6 Dec 2008 20:45:35 -0800,
> Jesse Barnes wrote:
> > 
> > On Saturday, December 6, 2008 6:09 am Rafael J. Wysocki wrote:
> > > From: Rafael J. Wysocki <rjw@sisk.pl>
> > > Subject: Sound (HDA Intel): Restore PCI configuration space with interrupts
> > > off
> > >
> > > Move the restoration of the standard PCI configuration registers
> > > in the snd_hda_intel driver to a ->resume_early() callback executed
> > > with interrupts disabled, since doing that with interrupts enabled
> > > may lead to problems in some cases.
> > >
> > > This patch addresses the regression from 2.6.26 tracked as
> > > http://bugzilla.kernel.org/show_bug.cgi?id=12121 .
> > 
> > Since I only applied 1 and 2 you'll need to send this one through Takashi.
> 
> OK, I merged it to for-next branch now.
> It should appear in the linux-next tree of tomorrow.

There is no build errors at least on linux-next, but I guess the
testing about PM has been rarely done on linux-next kernel...

BTW, Rafael, is this particular patch (against hda_intel.c) works in
general or dependent on other two patches?


thanks,

Takashi

Re: [PATCH 3/3] Sound (HDA Intel): Restore PCI configuration space with interrupts off

[Rafael J. Wysocki]

On Thursday, 11 of December 2008, Takashi Iwai wrote:
> At Sun, 07 Dec 2008 10:47:56 +0100,
> I wrote:
> > 
> > At Sat, 6 Dec 2008 20:45:35 -0800,
> > Jesse Barnes wrote:
> > > 
> > > On Saturday, December 6, 2008 6:09 am Rafael J. Wysocki wrote:
> > > > From: Rafael J. Wysocki <rjw@sisk.pl>
> > > > Subject: Sound (HDA Intel): Restore PCI configuration space with interrupts
> > > > off
> > > >
> > > > Move the restoration of the standard PCI configuration registers
> > > > in the snd_hda_intel driver to a ->resume_early() callback executed
> > > > with interrupts disabled, since doing that with interrupts enabled
> > > > may lead to problems in some cases.
> > > >
> > > > This patch addresses the regression from 2.6.26 tracked as
> > > > http://bugzilla.kernel.org/show_bug.cgi?id=12121 .
> > > 
> > > Since I only applied 1 and 2 you'll need to send this one through Takashi.
> > 
> > OK, I merged it to for-next branch now.
> > It should appear in the linux-next tree of tomorrow.
> 
> There is no build errors at least on linux-next, but I guess the
> testing about PM has been rarely done on linux-next kernel...
> 
> BTW, Rafael, is this particular patch (against hda_intel.c) works in
> general or dependent on other two patches?

It should be safe without the other patches too.

Thanks,
Rafael

Re: [PATCH 3/3] Sound (HDA Intel): Restore PCI configuration space with interrupts off

[Takashi Iwai]

At Thu, 11 Dec 2008 21:03:16 +0100,
Rafael J. Wysocki wrote:
> 
> On Thursday, 11 of December 2008, Takashi Iwai wrote:
> > At Sun, 07 Dec 2008 10:47:56 +0100,
> > I wrote:
> > > 
> > > At Sat, 6 Dec 2008 20:45:35 -0800,
> > > Jesse Barnes wrote:
> > > > 
> > > > On Saturday, December 6, 2008 6:09 am Rafael J. Wysocki wrote:
> > > > > From: Rafael J. Wysocki <rjw@sisk.pl>
> > > > > Subject: Sound (HDA Intel): Restore PCI configuration space with interrupts
> > > > > off
> > > > >
> > > > > Move the restoration of the standard PCI configuration registers
> > > > > in the snd_hda_intel driver to a ->resume_early() callback executed
> > > > > with interrupts disabled, since doing that with interrupts enabled
> > > > > may lead to problems in some cases.
> > > > >
> > > > > This patch addresses the regression from 2.6.26 tracked as
> > > > > http://bugzilla.kernel.org/show_bug.cgi?id=12121 .
> > > > 
> > > > Since I only applied 1 and 2 you'll need to send this one through Takashi.
> > > 
> > > OK, I merged it to for-next branch now.
> > > It should appear in the linux-next tree of tomorrow.
> > 
> > There is no build errors at least on linux-next, but I guess the
> > testing about PM has been rarely done on linux-next kernel...
> > 
> > BTW, Rafael, is this particular patch (against hda_intel.c) works in
> > general or dependent on other two patches?
> 
> It should be safe without the other patches too.

OK, but this alone doesn't make much sense without others, right?

I'm asking this because I'm not pretty sure how this should be handled.
Certainly it must be in 2.6.29, but about for 2.6.28...


thanks,

Takashi

Re: [PATCH 3/3] Sound (HDA Intel): Restore PCI configuration space with interrupts off

[Rafael J. Wysocki]

On Thursday, 11 of December 2008, Takashi Iwai wrote:
> At Thu, 11 Dec 2008 21:03:16 +0100,
> Rafael J. Wysocki wrote:
> > 
> > On Thursday, 11 of December 2008, Takashi Iwai wrote:
> > > At Sun, 07 Dec 2008 10:47:56 +0100,
> > > I wrote:
> > > > 
> > > > At Sat, 6 Dec 2008 20:45:35 -0800,
> > > > Jesse Barnes wrote:
> > > > > 
> > > > > On Saturday, December 6, 2008 6:09 am Rafael J. Wysocki wrote:
> > > > > > From: Rafael J. Wysocki <rjw@sisk.pl>
> > > > > > Subject: Sound (HDA Intel): Restore PCI configuration space with interrupts
> > > > > > off
> > > > > >
> > > > > > Move the restoration of the standard PCI configuration registers
> > > > > > in the snd_hda_intel driver to a ->resume_early() callback executed
> > > > > > with interrupts disabled, since doing that with interrupts enabled
> > > > > > may lead to problems in some cases.
> > > > > >
> > > > > > This patch addresses the regression from 2.6.26 tracked as
> > > > > > http://bugzilla.kernel.org/show_bug.cgi?id=12121 .
> > > > > 
> > > > > Since I only applied 1 and 2 you'll need to send this one through Takashi.
> > > > 
> > > > OK, I merged it to for-next branch now.
> > > > It should appear in the linux-next tree of tomorrow.
> > > 
> > > There is no build errors at least on linux-next, but I guess the
> > > testing about PM has been rarely done on linux-next kernel...
> > > 
> > > BTW, Rafael, is this particular patch (against hda_intel.c) works in
> > > general or dependent on other two patches?
> > 
> > It should be safe without the other patches too.
> 
> OK, but this alone doesn't make much sense without others, right?
> 
> I'm asking this because I'm not pretty sure how this should be handled.
> Certainly it must be in 2.6.29, but about for 2.6.28...

Well, I think 2.6.29 would be fine.

Thanks,
Rafael

Re: [PATCH 3/3] Sound (HDA Intel): Restore PCI configuration space with interrupts off

[Takashi Iwai]

At Thu, 11 Dec 2008 21:38:56 +0100,
Rafael J. Wysocki wrote:
> 
> On Thursday, 11 of December 2008, Takashi Iwai wrote:
> > At Thu, 11 Dec 2008 21:03:16 +0100,
> > Rafael J. Wysocki wrote:
> > > 
> > > On Thursday, 11 of December 2008, Takashi Iwai wrote:
> > > > At Sun, 07 Dec 2008 10:47:56 +0100,
> > > > I wrote:
> > > > > 
> > > > > At Sat, 6 Dec 2008 20:45:35 -0800,
> > > > > Jesse Barnes wrote:
> > > > > > 
> > > > > > On Saturday, December 6, 2008 6:09 am Rafael J. Wysocki wrote:
> > > > > > > From: Rafael J. Wysocki <rjw@sisk.pl>
> > > > > > > Subject: Sound (HDA Intel): Restore PCI configuration space with interrupts
> > > > > > > off
> > > > > > >
> > > > > > > Move the restoration of the standard PCI configuration registers
> > > > > > > in the snd_hda_intel driver to a ->resume_early() callback executed
> > > > > > > with interrupts disabled, since doing that with interrupts enabled
> > > > > > > may lead to problems in some cases.
> > > > > > >
> > > > > > > This patch addresses the regression from 2.6.26 tracked as
> > > > > > > http://bugzilla.kernel.org/show_bug.cgi?id=12121 .
> > > > > > 
> > > > > > Since I only applied 1 and 2 you'll need to send this one through Takashi.
> > > > > 
> > > > > OK, I merged it to for-next branch now.
> > > > > It should appear in the linux-next tree of tomorrow.
> > > > 
> > > > There is no build errors at least on linux-next, but I guess the
> > > > testing about PM has been rarely done on linux-next kernel...
> > > > 
> > > > BTW, Rafael, is this particular patch (against hda_intel.c) works in
> > > > general or dependent on other two patches?
> > > 
> > > It should be safe without the other patches too.
> > 
> > OK, but this alone doesn't make much sense without others, right?
> > 
> > I'm asking this because I'm not pretty sure how this should be handled.
> > Certainly it must be in 2.6.29, but about for 2.6.28...
> 
> Well, I think 2.6.29 would be fine.

OK, thanks.
If any, this could be pushed later from stable tree, too.


Takashi

Re: [linux-pm] [PATCH 1/3] PCI: Rework default handling of suspend and resume

[Pavel Machek]

On Sun 2008-12-07 08:34:43, Linus Torvalds wrote:
> On Sun, 7 Dec 2008, Rafael J. Wysocki wrote:
> > 
> > So, can we just say that PCI drivers shouldn't free IRQs during suspend and
> > request them during resume, and if there's any problem that leads to, then it
> > should be solved differently?
> 
> Well, there are reasons why _individual_ drivers might want to free and 
> re-request irq's during suspend, so I wouldn't say it's wrong either.

Another (not too good) reason why you may want to unregister the
interrupt is similarity between suspend and rmmod (and resume and
insmod).

In some cases you can get away with sharing code between those two
paths...
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: "APIC error on CPU1: 00(40)" during resume

[Frans Pop]

On Wednesday 10 December 2008, Ingo Molnar wrote:
> regarding those APIC error messages:
> >        ACPI: Waking up from system sleep state S3
> >        APIC error on CPU1: 00(40)
> >        ACPI: EC: non-query interrupt received, switching to interrupt
>
> that does suggest that the APIC was re-enabled (we dont get any APIC
> error exceptions otherwise!), and its LVT was programmed as well, but
> somehow we got an erroneous APIC message from an illegal vector.

I wonder if this may help tracing the cause. Today I got a KERN_ERR in the 
middle of those messages:

ACPI: Waking up from system sleep state S3
BUG: sleeping function called from invalid context at kernel/sched.c:5571
in_atomic(): 0, irqs_disabled(): 1, pid: 70, name: kacpid
Pid: 70, comm: kacpid Not tainted 2.6.28-rc7-rjw #77
Call Trace:
 [<ffffffff80345013>] ? acpi_os_release_object+0x9/0xd
 [<ffffffff8022d588>] __might_sleep+0xcf/0xd1
 [<ffffffff80234e32>] __cond_resched+0x15/0x4b
 [<ffffffff8043b1d7>] _cond_resched+0x2d/0x38
 [<ffffffff80357bc9>] acpi_ps_complete_op+0x235/0x24b
 [<ffffffff803582de>] acpi_ps_parse_loop+0x6ff/0x859
 [<ffffffff803574db>] acpi_ps_parse_aml+0x7c/0x2bb
 [<ffffffff80358a35>] acpi_ps_execute_method+0x144/0x213
 [<ffffffff80354e9e>] acpi_ns_evaluate+0x152/0x230
 [<ffffffff803452d0>] ? acpi_os_execute_deferred+0x0/0x39
 [<ffffffff8034c6a6>] acpi_ev_asynch_execute_gpe_method+0xc1/0x119
 [<ffffffff803452fc>] acpi_os_execute_deferred+0x2c/0x39
 [<ffffffff802480c7>] run_workqueue+0x95/0x12a
 [<ffffffff80248251>] worker_thread+0xf5/0x109
 [<ffffffff8024b9cb>] ? autoremove_wake_function+0x0/0x38
 [<ffffffff8024815c>] ? worker_thread+0x0/0x109
 [<ffffffff8024b678>] kthread+0x49/0x76
 [<ffffffff8020d009>] child_rip+0xa/0x11
 [<ffffffff8022da41>] ? pick_next_task_fair+0x8b/0x93
 [<ffffffff8024b62f>] ? kthread+0x0/0x76
 [<ffffffff8020cfff>] ? child_rip+0x0/0x11
APIC error on CPU1: 00(40)
ACPI: EC: non-query interrupt received, switching to interrupt mode

This is the first time I've seen this error. Kernel is based on commit 
f6f7b52e2f61 (just after -rc7) and includes the final versions of the 
patches Rafael posted in this thread [1].

More complete log available on request.

Cheers,
FJP

[1] http://lkml.org/lkml/2008/12/6/69

Re: "APIC error on CPU1: 00(40)" during resume

[Ingo Molnar]

* Frans Pop <elendil@planet.nl> wrote:

> On Wednesday 10 December 2008, Ingo Molnar wrote:
> > regarding those APIC error messages:
> > >        ACPI: Waking up from system sleep state S3
> > >        APIC error on CPU1: 00(40)
> > >        ACPI: EC: non-query interrupt received, switching to interrupt
> >
> > that does suggest that the APIC was re-enabled (we dont get any APIC
> > error exceptions otherwise!), and its LVT was programmed as well, but
> > somehow we got an erroneous APIC message from an illegal vector.
> 
> I wonder if this may help tracing the cause. Today I got a KERN_ERR in the 
> middle of those messages:
> 
> ACPI: Waking up from system sleep state S3
> BUG: sleeping function called from invalid context at kernel/sched.c:5571
> in_atomic(): 0, irqs_disabled(): 1, pid: 70, name: kacpid
> Pid: 70, comm: kacpid Not tainted 2.6.28-rc7-rjw #77
> Call Trace:
>  [<ffffffff80345013>] ? acpi_os_release_object+0x9/0xd
>  [<ffffffff8022d588>] __might_sleep+0xcf/0xd1
>  [<ffffffff80234e32>] __cond_resched+0x15/0x4b
>  [<ffffffff8043b1d7>] _cond_resched+0x2d/0x38
>  [<ffffffff80357bc9>] acpi_ps_complete_op+0x235/0x24b
>  [<ffffffff803582de>] acpi_ps_parse_loop+0x6ff/0x859
>  [<ffffffff803574db>] acpi_ps_parse_aml+0x7c/0x2bb
>  [<ffffffff80358a35>] acpi_ps_execute_method+0x144/0x213
>  [<ffffffff80354e9e>] acpi_ns_evaluate+0x152/0x230
>  [<ffffffff803452d0>] ? acpi_os_execute_deferred+0x0/0x39
>  [<ffffffff8034c6a6>] acpi_ev_asynch_execute_gpe_method+0xc1/0x119
>  [<ffffffff803452fc>] acpi_os_execute_deferred+0x2c/0x39
>  [<ffffffff802480c7>] run_workqueue+0x95/0x12a
>  [<ffffffff80248251>] worker_thread+0xf5/0x109
>  [<ffffffff8024b9cb>] ? autoremove_wake_function+0x0/0x38
>  [<ffffffff8024815c>] ? worker_thread+0x0/0x109
>  [<ffffffff8024b678>] kthread+0x49/0x76
>  [<ffffffff8020d009>] child_rip+0xa/0x11
>  [<ffffffff8022da41>] ? pick_next_task_fair+0x8b/0x93
>  [<ffffffff8024b62f>] ? kthread+0x0/0x76
>  [<ffffffff8020cfff>] ? child_rip+0x0/0x11
> APIC error on CPU1: 00(40)
> ACPI: EC: non-query interrupt received, switching to interrupt mode
> 
> This is the first time I've seen this error. Kernel is based on commit 
> f6f7b52e2f61 (just after -rc7) and includes the final versions of the 
> patches Rafael posted in this thread [1].
> 
> More complete log available on request.

hm, that warning seems to show an ACPI bug (Len Cc:-ed): we preempt in an 
atomic section - right during executing an AML scriptlet. Executing ACPI 
AMLs is a rather fragile moment of the kernel: they are used by the BIOS 
to indirectly instruct the kernel to tweak lowlevel chipset registers and 
other platform details.

The kernel executes AMLs 'blindly' - they tweak details that Linux 
typically has no knowledge about via any driver - so these things must 
absolutely run atomic, and scheduling away in the wrong moment (which 
means implicitly re-enabling interrupts) can leave the system in an 
inconsistent state.

This 'blindness' and opaqueness of AML execution is perhaps the nastiest 
aspect of the whole ACPI engine (because their opacity makes them 
undebuggable and unfixable in essence). Nevertheless, it still might be 
some unrelated phenomenon to your APIC illegal vector errors.

	Ingo

Re: "APIC error on CPU1: 00(40)" during resume

[Len Brown]

On Sun, 21 Dec 2008, Ingo Molnar wrote:

> 
> * Frans Pop <elendil@planet.nl> wrote:
> 
> > On Wednesday 10 December 2008, Ingo Molnar wrote:
> > > regarding those APIC error messages:
> > > >        ACPI: Waking up from system sleep state S3
> > > >        APIC error on CPU1: 00(40)
> > > >        ACPI: EC: non-query interrupt received, switching to interrupt
> > >
> > > that does suggest that the APIC was re-enabled (we dont get any APIC
> > > error exceptions otherwise!), and its LVT was programmed as well, but
> > > somehow we got an erroneous APIC message from an illegal vector.
> > 
> > I wonder if this may help tracing the cause. Today I got a KERN_ERR in the 
> > middle of those messages:
> > 
> > ACPI: Waking up from system sleep state S3
> > BUG: sleeping function called from invalid context at kernel/sched.c:5571
> > in_atomic(): 0, irqs_disabled(): 1, pid: 70, name: kacpid
> > Pid: 70, comm: kacpid Not tainted 2.6.28-rc7-rjw #77
> > Call Trace:
> >  [<ffffffff80345013>] ? acpi_os_release_object+0x9/0xd
> >  [<ffffffff8022d588>] __might_sleep+0xcf/0xd1
> >  [<ffffffff80234e32>] __cond_resched+0x15/0x4b
> >  [<ffffffff8043b1d7>] _cond_resched+0x2d/0x38
> >  [<ffffffff80357bc9>] acpi_ps_complete_op+0x235/0x24b
> >  [<ffffffff803582de>] acpi_ps_parse_loop+0x6ff/0x859
> >  [<ffffffff803574db>] acpi_ps_parse_aml+0x7c/0x2bb
> >  [<ffffffff80358a35>] acpi_ps_execute_method+0x144/0x213
> >  [<ffffffff80354e9e>] acpi_ns_evaluate+0x152/0x230
> >  [<ffffffff803452d0>] ? acpi_os_execute_deferred+0x0/0x39
> >  [<ffffffff8034c6a6>] acpi_ev_asynch_execute_gpe_method+0xc1/0x119
> >  [<ffffffff803452fc>] acpi_os_execute_deferred+0x2c/0x39
> >  [<ffffffff802480c7>] run_workqueue+0x95/0x12a
> >  [<ffffffff80248251>] worker_thread+0xf5/0x109
> >  [<ffffffff8024b9cb>] ? autoremove_wake_function+0x0/0x38
> >  [<ffffffff8024815c>] ? worker_thread+0x0/0x109
> >  [<ffffffff8024b678>] kthread+0x49/0x76
> >  [<ffffffff8020d009>] child_rip+0xa/0x11
> >  [<ffffffff8022da41>] ? pick_next_task_fair+0x8b/0x93
> >  [<ffffffff8024b62f>] ? kthread+0x0/0x76
> >  [<ffffffff8020cfff>] ? child_rip+0x0/0x11
> > APIC error on CPU1: 00(40)
> > ACPI: EC: non-query interrupt received, switching to interrupt mode
> > 
> > This is the first time I've seen this error. Kernel is based on commit 
> > f6f7b52e2f61 (just after -rc7) and includes the final versions of the 
> > patches Rafael posted in this thread [1].
> > 
> > More complete log available on request.
> 
> hm, that warning seems to show an ACPI bug (Len Cc:-ed): we preempt in an 
> atomic section - right during executing an AML scriptlet. Executing ACPI 
> AMLs is a rather fragile moment of the kernel: they are used by the BIOS 
> to indirectly instruct the kernel to tweak lowlevel chipset registers and 
> other platform details.
> 
> The kernel executes AMLs 'blindly' - they tweak details that Linux 
> typically has no knowledge about via any driver - so these things must 
> absolutely run atomic, and scheduling away in the wrong moment (which 
> means implicitly re-enabling interrupts) can leave the system in an 
> inconsistent state.
> 
> This 'blindness' and opaqueness of AML execution is perhaps the nastiest 
> aspect of the whole ACPI engine (because their opacity makes them 
> undebuggable and unfixable in essence). Nevertheless, it still might be 
> some unrelated phenomenon to your APIC illegal vector errors.

I believe that it is a bug that run_workqueue() is called
with interrupts off.  I've seen this reported on one other machine,
and Rui debugged it down to the BIOS returning from an SMM entry
with interrupts off:-(  So who knows, maybe run_workqueue()
had interrupts enabled and some AML triggered an SMM
to have the same failure here?

Re: executing AML's blindly.
Yes, and no.  We do know exactly what we interpret --
but yes, it is the BIOS writer that wrote the AML:-(

Above a ACPI interrupt has been deferred to non-interrupt
context for the OS to run its AML handler.  Unfortunately,
we somehow found ourselves running the work-queue with
interrupts off...

Also, the assert above is about to be hidden by a real
bug fix which I sent upstream today -- we'll not call cond_resched()
when  interrupts are off.
This is for the benefit of irqrouter_resume() 
which runs AML with interrupts off.

-Len

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Frans Pop]

On Friday 05 December 2008, Linus Torvalds wrote:
> On Thu, 4 Dec 2008, Linus Torvalds wrote:
> > The third thing that worries me is the _very_ early occurrence of
> >
> > 	ACPI: Waking up from system sleep state S3
> > 	APIC error on CPU1: 00(40)
> > 	ACPI: EC: non-query interrupt received, switching to interrupt mode
> >
> > Now, that "APIC error" thing is worrisome. It's worrisome for
> > multiple reasons:
> >
> >  - errors are never good (0x40 means "received illegal vector",
> > whatever caused _that_)
> >
> >  - more importantly, it seems to imply that interrupts are enabled on
> >    CPU1, and they sure as hell shouldn't be enabled at this stage!
> >
> >    Do we perhaps have a SMP resume bug where we resume the other
> > CPU's with interrupts enabled?
> >
> >  - the "ACPI: EC: non-query interrupt received, switching to
> > interrupt mode" thing is from ACPI, and _also_ implies that
> > interrupts are on.
> >
> > Why are interrupts enabled that early? I really don't like seeing
> > interrupts enabled before we've even done the basic PCI resume.

Quick revival of this old thread with good news.
The "APIC error on CPU1" message is now gone!

With current git head I get:
   ACPI: Waking up from system sleep state S3
   ACPI: EC: non-query interrupt received, switching to interrupt mode

Looks like the recent suspend/resume changes are definitely moving us in 
the right direction.

Cheers,
FJP

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Ingo Molnar]

* Frans Pop <elendil@planet.nl> wrote:

> On Friday 05 December 2008, Linus Torvalds wrote:
> > On Thu, 4 Dec 2008, Linus Torvalds wrote:
> > > The third thing that worries me is the _very_ early occurrence of
> > >
> > > 	ACPI: Waking up from system sleep state S3
> > > 	APIC error on CPU1: 00(40)
> > > 	ACPI: EC: non-query interrupt received, switching to interrupt mode
> > >
> > > Now, that "APIC error" thing is worrisome. It's worrisome for
> > > multiple reasons:
> > >
> > >  - errors are never good (0x40 means "received illegal vector",
> > > whatever caused _that_)
> > >
> > >  - more importantly, it seems to imply that interrupts are enabled on
> > >    CPU1, and they sure as hell shouldn't be enabled at this stage!
> > >
> > >    Do we perhaps have a SMP resume bug where we resume the other
> > > CPU's with interrupts enabled?
> > >
> > >  - the "ACPI: EC: non-query interrupt received, switching to
> > > interrupt mode" thing is from ACPI, and _also_ implies that
> > > interrupts are on.
> > >
> > > Why are interrupts enabled that early? I really don't like seeing
> > > interrupts enabled before we've even done the basic PCI resume.
> 
> Quick revival of this old thread with good news.
> The "APIC error on CPU1" message is now gone!

that was an old mystery!

So enabling interrupts too early (possibly before the lapic, the hpet or 
both are initialized properly?) can generate an APIC error message?

> With current git head I get:
>    ACPI: Waking up from system sleep state S3
>    ACPI: EC: non-query interrupt received, switching to interrupt mode

i started getting those messages too - but earlier in the cycle, during 
one of the ACPI merges i think.

	Ingo

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Rafael J. Wysocki]

On Thursday 29 January 2009, Ingo Molnar wrote:
> 
> * Frans Pop <elendil@planet.nl> wrote:
> 
> > On Friday 05 December 2008, Linus Torvalds wrote:
> > > On Thu, 4 Dec 2008, Linus Torvalds wrote:
> > > > The third thing that worries me is the _very_ early occurrence of
> > > >
> > > > 	ACPI: Waking up from system sleep state S3
> > > > 	APIC error on CPU1: 00(40)
> > > > 	ACPI: EC: non-query interrupt received, switching to interrupt mode
> > > >
> > > > Now, that "APIC error" thing is worrisome. It's worrisome for
> > > > multiple reasons:
> > > >
> > > >  - errors are never good (0x40 means "received illegal vector",
> > > > whatever caused _that_)
> > > >
> > > >  - more importantly, it seems to imply that interrupts are enabled on
> > > >    CPU1, and they sure as hell shouldn't be enabled at this stage!
> > > >
> > > >    Do we perhaps have a SMP resume bug where we resume the other
> > > > CPU's with interrupts enabled?
> > > >
> > > >  - the "ACPI: EC: non-query interrupt received, switching to
> > > > interrupt mode" thing is from ACPI, and _also_ implies that
> > > > interrupts are on.
> > > >
> > > > Why are interrupts enabled that early? I really don't like seeing
> > > > interrupts enabled before we've even done the basic PCI resume.
> > 
> > Quick revival of this old thread with good news.
> > The "APIC error on CPU1" message is now gone!
> 
> that was an old mystery!
> 
> So enabling interrupts too early (possibly before the lapic, the hpet or 
> both are initialized properly?) can generate an APIC error message?

Hmm, I think that's something different, because the APIC error was on CPU1.
Perhaps the restoration of all standard PCI config spaces before bringing CPU1
up helped here.

> > With current git head I get:
> >    ACPI: Waking up from system sleep state S3
> >    ACPI: EC: non-query interrupt received, switching to interrupt mode
> 
> i started getting those messages too - but earlier in the cycle, during 
> one of the ACPI merges i think.

AFAICS, the last message only means that the ACPI EC code is now going to use
interrupts instead of polling, which generally is good.

Alex, is that correct?

Thanks,
Rafael

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Alexey Starikovskiy]

Rafael J. Wysocki wrote:
> On Thursday 29 January 2009, Ingo Molnar wrote:
>> * Frans Pop <elendil@planet.nl> wrote:
>>> With current git head I get:
>>>    ACPI: Waking up from system sleep state S3
>>>    ACPI: EC: non-query interrupt received, switching to interrupt mode
>> i started getting those messages too - but earlier in the cycle, during 
>> one of the ACPI merges i think.
> 
> AFAICS, the last message only means that the ACPI EC code is now going to use
> interrupts instead of polling, which generally is good.
> 
> Alex, is that correct?
Yes. Interrupt mode is better.

Regards,
Alex.

Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

[Frans Pop]

On Thursday 29 January 2009, Ingo Molnar wrote:
> > Quick revival of this old thread with good news.
> > The "APIC error on CPU1" message is now gone!
>
> that was an old mystery!
>
> So enabling interrupts too early (possibly before the lapic, the hpet
> or both are initialized properly?) can generate an APIC error message?

I'm not really sure what change has caused the error to disappear. I could 
do some investigation, but fear we may have had too many changes (and 
broken suspend between them) to accurately pinpoint it.

> > With current git head I get:
> >    ACPI: Waking up from system sleep state S3
> >    ACPI: EC: non-query interrupt received, switching to interrupt
> > mode
>
> i started getting those messages too - but earlier in the cycle, during
> one of the ACPI merges i think.

I get the same message during a normal boot and in roughly the same place: 
shortly after CPU1 is enabled and CPUs attaching to sched-domains. So I'm 
happy with Alexey's comment that this is normal.