* Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)
@ 2008-12-02 7:53 Frans Pop
0 siblings, 0 replies; 71+ messages in thread
From: Frans Pop @ 2008-12-02 7:53 UTC (permalink / raw)
To: linux-kernel
(resending to list only as original attempt did not make it)
> 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.]
This almost exactly describes problems I've been seeing on my HP 2510p. I
never tried Alt-SysRq-b and have not seen the spontaneous power-off, but
the percentage correct boots and relationship with the sound driver are
spot on.
I worked around the sound driver relationship by using a very low power
save setting so I can virtually count on it being disabled when I
suspend.
I'll give your patch a go and report the results. Nice work!
Cheers,
FJP
^ permalink raw reply [flat|nested] 71+ messages in thread* Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)
@ 2008-12-02 2:20 Rafael J. Wysocki
2008-12-02 3:32 ` Linus Torvalds
0 siblings, 1 reply; 71+ messages in thread
From: Rafael J. Wysocki @ 2008-12-02 2:20 UTC (permalink / raw)
To: Linus Torvalds
Cc: Greg KH, Ingo Molnar, Jesse Barnes, Len Brown, LKML,
Takashi Iwai, Andrew Morton
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: "
^ permalink raw reply [flat|nested] 71+ messages in thread* Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected) 2008-12-02 2:20 Rafael J. Wysocki @ 2008-12-02 3:32 ` Linus Torvalds 2008-12-02 3:42 ` Linus Torvalds ` (2 more replies) 0 siblings, 3 replies; 71+ messages in thread From: Linus Torvalds @ 2008-12-02 3:32 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Greg KH, Ingo Molnar, Jesse Barnes, Len Brown, LKML, Takashi Iwai, Andrew Morton 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 ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected) 2008-12-02 3:32 ` Linus Torvalds @ 2008-12-02 3:42 ` Linus Torvalds 2008-12-02 4:31 ` Frans Pop 2008-12-02 4:13 ` Frans Pop 2008-12-02 15:49 ` Rafael J. Wysocki 2 siblings, 1 reply; 71+ messages in thread From: Linus Torvalds @ 2008-12-02 3:42 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Greg KH, Ingo Molnar, Jesse Barnes, Len Brown, LKML, Takashi Iwai, Andrew Morton, Ivan Kokshaysky 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 ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected) 2008-12-02 3:42 ` Linus Torvalds @ 2008-12-02 4:31 ` Frans Pop 2008-12-02 4:46 ` Linus Torvalds 0 siblings, 1 reply; 71+ messages in thread From: Frans Pop @ 2008-12-02 4:31 UTC (permalink / raw) To: Linus Torvalds Cc: rjw, greg, mingo, jbarnes, lenb, linux-kernel, tiwai, akpm, ink > 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 ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected) 2008-12-02 4:31 ` Frans Pop @ 2008-12-02 4:46 ` Linus Torvalds 2008-12-02 5:29 ` Frans Pop 0 siblings, 1 reply; 71+ messages in thread From: Linus Torvalds @ 2008-12-02 4:46 UTC (permalink / raw) To: Frans Pop; +Cc: rjw, greg, mingo, jbarnes, lenb, linux-kernel, tiwai, akpm, ink 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 ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected) 2008-12-02 4:46 ` Linus Torvalds @ 2008-12-02 5:29 ` Frans Pop 2008-12-02 5:56 ` Frans Pop 2008-12-02 15:46 ` Linus Torvalds 0 siblings, 2 replies; 71+ messages in thread From: Frans Pop @ 2008-12-02 5:29 UTC (permalink / raw) To: Linus Torvalds Cc: rjw, greg, mingo, jbarnes, lenb, linux-kernel, tiwai, akpm, ink [-- 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 ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected) 2008-12-02 5:29 ` Frans Pop @ 2008-12-02 5:56 ` Frans Pop 2008-12-02 15:46 ` Linus Torvalds 1 sibling, 0 replies; 71+ messages in thread From: Frans Pop @ 2008-12-02 5:56 UTC (permalink / raw) To: Linus Torvalds Cc: rjw, greg, mingo, jbarnes, lenb, linux-kernel, tiwai, akpm, ink 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 ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected) 2008-12-02 5:29 ` Frans Pop 2008-12-02 5:56 ` Frans Pop @ 2008-12-02 15:46 ` Linus Torvalds 2008-12-02 17:46 ` Frans Pop 1 sibling, 1 reply; 71+ messages in thread From: Linus Torvalds @ 2008-12-02 15:46 UTC (permalink / raw) To: Frans Pop; +Cc: rjw, greg, mingo, jbarnes, lenb, linux-kernel, tiwai, akpm, ink 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 ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected) 2008-12-02 15:46 ` Linus Torvalds @ 2008-12-02 17:46 ` Frans Pop 2008-12-02 18:17 ` Linus Torvalds 0 siblings, 1 reply; 71+ messages in thread From: Frans Pop @ 2008-12-02 17:46 UTC (permalink / raw) To: Linus Torvalds Cc: rjw, greg, mingo, jbarnes, lenb, linux-kernel, tiwai, akpm, ink 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. ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected) 2008-12-02 17:46 ` Frans Pop @ 2008-12-02 18:17 ` Linus Torvalds 0 siblings, 0 replies; 71+ messages in thread From: Linus Torvalds @ 2008-12-02 18:17 UTC (permalink / raw) To: Frans Pop; +Cc: rjw, greg, mingo, jbarnes, lenb, linux-kernel, tiwai, akpm, ink 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 ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected) 2008-12-02 3:32 ` Linus Torvalds 2008-12-02 3:42 ` Linus Torvalds @ 2008-12-02 4:13 ` Frans Pop 2008-12-02 4:36 ` Linus Torvalds 2008-12-02 15:49 ` Rafael J. Wysocki 2 siblings, 1 reply; 71+ messages in thread From: Frans Pop @ 2008-12-02 4:13 UTC (permalink / raw) To: Linus Torvalds; +Cc: rjw, greg, mingo, jbarnes, lenb, linux-kernel, tiwai, akpm 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 ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected) 2008-12-02 4:13 ` Frans Pop @ 2008-12-02 4:36 ` Linus Torvalds 2008-12-02 22:38 ` Rafael J. Wysocki 0 siblings, 1 reply; 71+ messages in thread From: Linus Torvalds @ 2008-12-02 4:36 UTC (permalink / raw) To: Frans Pop; +Cc: rjw, greg, mingo, jbarnes, lenb, linux-kernel, tiwai, akpm 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 ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected) 2008-12-02 4:36 ` Linus Torvalds @ 2008-12-02 22:38 ` Rafael J. Wysocki 2008-12-02 23:37 ` Linus Torvalds 0 siblings, 1 reply; 71+ messages in thread From: Rafael J. Wysocki @ 2008-12-02 22:38 UTC (permalink / raw) To: Linus Torvalds Cc: Frans Pop, greg, mingo, jbarnes, lenb, linux-kernel, tiwai, akpm 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 ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected) 2008-12-02 22:38 ` Rafael J. Wysocki @ 2008-12-02 23:37 ` Linus Torvalds 2008-12-03 0:00 ` Rafael J. Wysocki 0 siblings, 1 reply; 71+ messages in thread From: Linus Torvalds @ 2008-12-02 23:37 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Frans Pop, Greg KH, Ingo Molnar, jbarnes, lenb, Linux Kernel Mailing List, tiwai, Andrew Morton 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 ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected) 2008-12-02 23:37 ` Linus Torvalds @ 2008-12-03 0:00 ` Rafael J. Wysocki 2008-12-03 0:05 ` Rafael J. Wysocki ` (2 more replies) 0 siblings, 3 replies; 71+ messages in thread From: Rafael J. Wysocki @ 2008-12-03 0:00 UTC (permalink / raw) To: Linus Torvalds Cc: Frans Pop, Greg KH, Ingo Molnar, jbarnes, lenb, Linux Kernel Mailing List, tiwai, Andrew Morton 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 ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected) 2008-12-03 0:00 ` Rafael J. Wysocki @ 2008-12-03 0:05 ` Rafael J. Wysocki 2008-12-03 0:31 ` Rafael J. Wysocki 2008-12-03 0:41 ` Linus Torvalds 2 siblings, 0 replies; 71+ messages in thread From: Rafael J. Wysocki @ 2008-12-03 0:05 UTC (permalink / raw) To: Linus Torvalds Cc: Frans Pop, Greg KH, Ingo Molnar, jbarnes, lenb, Linux Kernel Mailing List, tiwai, Andrew Morton 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 ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected) 2008-12-03 0:00 ` Rafael J. Wysocki 2008-12-03 0:05 ` Rafael J. Wysocki @ 2008-12-03 0:31 ` Rafael J. Wysocki 2008-12-03 0:41 ` Linus Torvalds 2 siblings, 0 replies; 71+ messages in thread From: Rafael J. Wysocki @ 2008-12-03 0:31 UTC (permalink / raw) To: Linus Torvalds Cc: Frans Pop, Greg KH, Ingo Molnar, jbarnes, lenb, Linux Kernel Mailing List, tiwai, Andrew Morton 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 ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected) 2008-12-03 0:00 ` Rafael J. Wysocki 2008-12-03 0:05 ` Rafael J. Wysocki 2008-12-03 0:31 ` Rafael J. Wysocki @ 2008-12-03 0:41 ` Linus Torvalds 2008-12-03 1:22 ` Rafael J. Wysocki 2 siblings, 1 reply; 71+ messages in thread From: Linus Torvalds @ 2008-12-03 0:41 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Frans Pop, Greg KH, Ingo Molnar, jbarnes, lenb, Linux Kernel Mailing List, tiwai, Andrew Morton 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 ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected) 2008-12-03 0:41 ` Linus Torvalds @ 2008-12-03 1:22 ` Rafael J. Wysocki 2008-12-03 2:02 ` Linus Torvalds 0 siblings, 1 reply; 71+ messages in thread From: Rafael J. Wysocki @ 2008-12-03 1:22 UTC (permalink / raw) To: Linus Torvalds Cc: Frans Pop, Greg KH, Ingo Molnar, jbarnes, lenb, Linux Kernel Mailing List, tiwai, Andrew Morton 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 ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected) 2008-12-03 1:22 ` Rafael J. Wysocki @ 2008-12-03 2:02 ` Linus Torvalds 2008-12-03 7:40 ` Rafael J. Wysocki 0 siblings, 1 reply; 71+ messages in thread From: Linus Torvalds @ 2008-12-03 2:02 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Frans Pop, Greg KH, Ingo Molnar, jbarnes, lenb, Linux Kernel Mailing List, tiwai, Andrew Morton 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 ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected) 2008-12-03 2:02 ` Linus Torvalds @ 2008-12-03 7:40 ` Rafael J. Wysocki 2008-12-03 7:52 ` Rafael J. Wysocki 0 siblings, 1 reply; 71+ messages in thread From: Rafael J. Wysocki @ 2008-12-03 7:40 UTC (permalink / raw) To: Linus Torvalds Cc: Frans Pop, Greg KH, Ingo Molnar, jbarnes, lenb, Linux Kernel Mailing List, tiwai, Andrew Morton 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 ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected) 2008-12-03 7:40 ` Rafael J. Wysocki @ 2008-12-03 7:52 ` Rafael J. Wysocki 2008-12-03 11:20 ` Rafael J. Wysocki 0 siblings, 1 reply; 71+ messages in thread From: Rafael J. Wysocki @ 2008-12-03 7:52 UTC (permalink / raw) To: Linus Torvalds Cc: Frans Pop, Greg KH, Ingo Molnar, jbarnes, lenb, Linux Kernel Mailing List, tiwai, Andrew Morton 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: " ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected) 2008-12-03 7:52 ` Rafael J. Wysocki @ 2008-12-03 11:20 ` Rafael J. Wysocki 2008-12-03 15:53 ` Linus Torvalds 0 siblings, 1 reply; 71+ messages in thread From: Rafael J. Wysocki @ 2008-12-03 11:20 UTC (permalink / raw) To: Linus Torvalds Cc: Frans Pop, Greg KH, Ingo Molnar, jbarnes, lenb, Linux Kernel Mailing List, tiwai, Andrew Morton 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 ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected) 2008-12-03 11:20 ` Rafael J. Wysocki @ 2008-12-03 15:53 ` Linus Torvalds 2008-12-04 1:23 ` Rafael J. Wysocki 2008-12-04 11:29 ` Frans Pop 0 siblings, 2 replies; 71+ messages in thread From: Linus Torvalds @ 2008-12-03 15:53 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Frans Pop, Greg KH, Ingo Molnar, jbarnes, lenb, Linux Kernel Mailing List, tiwai, Andrew Morton 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) { ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected) 2008-12-03 15:53 ` Linus Torvalds @ 2008-12-04 1:23 ` Rafael J. Wysocki 2008-12-04 4:40 ` Linus Torvalds 2008-12-04 11:29 ` Frans Pop 1 sibling, 1 reply; 71+ messages in thread From: Rafael J. Wysocki @ 2008-12-04 1:23 UTC (permalink / raw) To: Linus Torvalds Cc: Frans Pop, Greg KH, Ingo Molnar, jbarnes, lenb, Linux Kernel Mailing List, tiwai, Andrew Morton 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 ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected) 2008-12-04 1:23 ` Rafael J. Wysocki @ 2008-12-04 4:40 ` Linus Torvalds 2008-12-04 8:21 ` Frans Pop 2008-12-04 22:01 ` Rafael J. Wysocki 0 siblings, 2 replies; 71+ messages in thread From: Linus Torvalds @ 2008-12-04 4:40 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Frans Pop, Greg KH, Ingo Molnar, jbarnes, lenb, Linux Kernel Mailing List, tiwai, Andrew Morton 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 ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected) 2008-12-04 4:40 ` Linus Torvalds @ 2008-12-04 8:21 ` Frans Pop 2008-12-04 22:01 ` Rafael J. Wysocki 1 sibling, 0 replies; 71+ messages in thread From: Frans Pop @ 2008-12-04 8:21 UTC (permalink / raw) To: Linus Torvalds Cc: Rafael J. Wysocki, Greg KH, Ingo Molnar, jbarnes, lenb, Linux Kernel Mailing List, tiwai, Andrew Morton 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 ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected) 2008-12-04 4:40 ` Linus Torvalds 2008-12-04 8:21 ` Frans Pop @ 2008-12-04 22:01 ` Rafael J. Wysocki 1 sibling, 0 replies; 71+ messages in thread From: Rafael J. Wysocki @ 2008-12-04 22:01 UTC (permalink / raw) To: Linus Torvalds Cc: Frans Pop, Greg KH, Ingo Molnar, jbarnes, lenb, Linux Kernel Mailing List, tiwai, Andrew Morton 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 ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected) 2008-12-03 15:53 ` Linus Torvalds 2008-12-04 1:23 ` Rafael J. Wysocki @ 2008-12-04 11:29 ` Frans Pop 2008-12-04 16:17 ` Linus Torvalds 2008-12-04 22:09 ` Rafael J. Wysocki 1 sibling, 2 replies; 71+ messages in thread From: Frans Pop @ 2008-12-04 11:29 UTC (permalink / raw) To: Linus Torvalds Cc: Rafael J. Wysocki, Greg KH, Ingo Molnar, jbarnes, lenb, Linux Kernel Mailing List, tiwai, Andrew Morton [-- 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 --] ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected) 2008-12-04 11:29 ` Frans Pop @ 2008-12-04 16:17 ` Linus Torvalds 2008-12-04 18:00 ` Frans Pop 2008-12-04 22:40 ` Rafael J. Wysocki 2008-12-04 22:09 ` Rafael J. Wysocki 1 sibling, 2 replies; 71+ messages in thread From: Linus Torvalds @ 2008-12-04 16:17 UTC (permalink / raw) To: Frans Pop Cc: Rafael J. Wysocki, Greg KH, Ingo Molnar, jbarnes, lenb, Linux Kernel Mailing List, tiwai, Andrew Morton 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 ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected) 2008-12-04 16:17 ` Linus Torvalds @ 2008-12-04 18:00 ` Frans Pop 2008-12-04 20:03 ` Linus Torvalds 2008-12-04 22:46 ` Rafael J. Wysocki 2008-12-04 22:40 ` Rafael J. Wysocki 1 sibling, 2 replies; 71+ messages in thread From: Frans Pop @ 2008-12-04 18:00 UTC (permalink / raw) To: Linus Torvalds Cc: Rafael J. Wysocki, Greg KH, Ingo Molnar, jbarnes, lenb, Linux Kernel Mailing List, tiwai, Andrew Morton 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 ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected) 2008-12-04 18:00 ` Frans Pop @ 2008-12-04 20:03 ` Linus Torvalds 2008-12-05 21:26 ` Linus Torvalds 2008-12-04 22:46 ` Rafael J. Wysocki 1 sibling, 1 reply; 71+ messages in thread From: Linus Torvalds @ 2008-12-04 20:03 UTC (permalink / raw) To: Frans Pop Cc: Rafael J. Wysocki, Greg KH, Ingo Molnar, jbarnes, lenb, Linux Kernel Mailing List, tiwai, Andrew Morton 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 ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected) 2008-12-04 20:03 ` Linus Torvalds @ 2008-12-05 21:26 ` Linus Torvalds 2008-12-05 22:01 ` Rafael J. Wysocki 2009-01-28 12:00 ` Frans Pop 0 siblings, 2 replies; 71+ messages in thread From: Linus Torvalds @ 2008-12-05 21:26 UTC (permalink / raw) To: Frans Pop Cc: Rafael J. Wysocki, Greg KH, Ingo Molnar, jbarnes, lenb, Linux Kernel Mailing List, tiwai, Andrew Morton 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); } ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected) 2008-12-05 21:26 ` Linus Torvalds @ 2008-12-05 22:01 ` Rafael J. Wysocki 2008-12-05 22:14 ` Linus Torvalds 2009-01-28 12:00 ` Frans Pop 1 sibling, 1 reply; 71+ messages in thread From: Rafael J. Wysocki @ 2008-12-05 22:01 UTC (permalink / raw) To: Linus Torvalds Cc: Frans Pop, Greg KH, Ingo Molnar, jbarnes, lenb, Linux Kernel Mailing List, tiwai, Andrew Morton 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 ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected) 2008-12-05 22:01 ` Rafael J. Wysocki @ 2008-12-05 22:14 ` Linus Torvalds 2008-12-06 0:04 ` Rafael J. Wysocki 0 siblings, 1 reply; 71+ messages in thread From: Linus Torvalds @ 2008-12-05 22:14 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Frans Pop, Greg KH, Ingo Molnar, jbarnes, lenb, Linux Kernel Mailing List, tiwai, Andrew Morton 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 ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected) 2008-12-05 22:14 ` Linus Torvalds @ 2008-12-06 0:04 ` Rafael J. Wysocki 2008-12-06 0:50 ` Linus Torvalds 0 siblings, 1 reply; 71+ messages in thread From: Rafael J. Wysocki @ 2008-12-06 0:04 UTC (permalink / raw) To: Linus Torvalds Cc: Frans Pop, Greg KH, Ingo Molnar, jbarnes, lenb, Linux Kernel Mailing List, tiwai, Andrew Morton 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; } ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected) 2008-12-06 0:04 ` Rafael J. Wysocki @ 2008-12-06 0:50 ` Linus Torvalds 2008-12-06 1:18 ` Rafael J. Wysocki 0 siblings, 1 reply; 71+ messages in thread From: Linus Torvalds @ 2008-12-06 0:50 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Frans Pop, Greg KH, Ingo Molnar, jbarnes, lenb, Linux Kernel Mailing List, tiwai, Andrew Morton 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 ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected) 2008-12-06 0:50 ` Linus Torvalds @ 2008-12-06 1:18 ` Rafael J. Wysocki 2008-12-06 1:55 ` Linus Torvalds 0 siblings, 1 reply; 71+ messages in thread From: Rafael J. Wysocki @ 2008-12-06 1:18 UTC (permalink / raw) To: Linus Torvalds Cc: Frans Pop, Greg KH, Ingo Molnar, jbarnes, lenb, Linux Kernel Mailing List, tiwai, Andrew Morton 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; } ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected) 2008-12-06 1:18 ` Rafael J. Wysocki @ 2008-12-06 1:55 ` Linus Torvalds 2008-12-06 2:18 ` Rafael J. Wysocki 2008-12-06 2:45 ` Greg KH 0 siblings, 2 replies; 71+ messages in thread From: Linus Torvalds @ 2008-12-06 1:55 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Frans Pop, Greg KH, Ingo Molnar, jbarnes, lenb, Linux Kernel Mailing List, tiwai, Andrew Morton 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 ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected) 2008-12-06 1:55 ` Linus Torvalds @ 2008-12-06 2:18 ` Rafael J. Wysocki 2008-12-06 13:53 ` Rafael J. Wysocki 2008-12-06 2:45 ` Greg KH 1 sibling, 1 reply; 71+ messages in thread From: Rafael J. Wysocki @ 2008-12-06 2:18 UTC (permalink / raw) To: Linus Torvalds Cc: Frans Pop, Greg KH, Ingo Molnar, jbarnes, lenb, Linux Kernel Mailing List, tiwai, Andrew Morton 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 ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected) 2008-12-06 2:18 ` Rafael J. Wysocki @ 2008-12-06 13:53 ` Rafael J. Wysocki 0 siblings, 0 replies; 71+ messages in thread From: Rafael J. Wysocki @ 2008-12-06 13:53 UTC (permalink / raw) To: Linus Torvalds Cc: Frans Pop, Greg KH, Ingo Molnar, jbarnes, lenb, Linux Kernel Mailing List, tiwai, Andrew Morton 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 ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected) 2008-12-06 1:55 ` Linus Torvalds 2008-12-06 2:18 ` Rafael J. Wysocki @ 2008-12-06 2:45 ` Greg KH 1 sibling, 0 replies; 71+ messages in thread From: Greg KH @ 2008-12-06 2:45 UTC (permalink / raw) To: Linus Torvalds Cc: Rafael J. Wysocki, Frans Pop, Ingo Molnar, jbarnes, lenb, Linux Kernel Mailing List, tiwai, Andrew Morton 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 ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected) 2008-12-05 21:26 ` Linus Torvalds 2008-12-05 22:01 ` Rafael J. Wysocki @ 2009-01-28 12:00 ` Frans Pop 2009-01-29 14:11 ` Ingo Molnar 1 sibling, 1 reply; 71+ messages in thread From: Frans Pop @ 2009-01-28 12:00 UTC (permalink / raw) To: Linus Torvalds Cc: Rafael J. Wysocki, Greg KH, Ingo Molnar, jbarnes, lenb, Linux Kernel Mailing List, tiwai, Andrew Morton 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 ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected) 2009-01-28 12:00 ` Frans Pop @ 2009-01-29 14:11 ` Ingo Molnar 2009-01-29 14:48 ` Rafael J. Wysocki 2009-01-30 4:35 ` Frans Pop 0 siblings, 2 replies; 71+ messages in thread From: Ingo Molnar @ 2009-01-29 14:11 UTC (permalink / raw) To: Frans Pop Cc: Linus Torvalds, Rafael J. Wysocki, Greg KH, jbarnes, lenb, Linux Kernel Mailing List, tiwai, Andrew Morton * 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 ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected) 2009-01-29 14:11 ` Ingo Molnar @ 2009-01-29 14:48 ` Rafael J. Wysocki 2009-01-29 16:44 ` Alexey Starikovskiy 2009-01-30 4:35 ` Frans Pop 1 sibling, 1 reply; 71+ messages in thread From: Rafael J. Wysocki @ 2009-01-29 14:48 UTC (permalink / raw) To: Ingo Molnar, Alexey Starikovskiy Cc: Frans Pop, Linus Torvalds, Greg KH, jbarnes, lenb, Linux Kernel Mailing List, tiwai, Andrew Morton 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 ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected) 2009-01-29 14:48 ` Rafael J. Wysocki @ 2009-01-29 16:44 ` Alexey Starikovskiy 0 siblings, 0 replies; 71+ messages in thread From: Alexey Starikovskiy @ 2009-01-29 16:44 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Ingo Molnar, Frans Pop, Linus Torvalds, Greg KH, jbarnes, lenb, Linux Kernel Mailing List, tiwai, Andrew Morton 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. ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected) 2009-01-29 14:11 ` Ingo Molnar 2009-01-29 14:48 ` Rafael J. Wysocki @ 2009-01-30 4:35 ` Frans Pop 1 sibling, 0 replies; 71+ messages in thread From: Frans Pop @ 2009-01-30 4:35 UTC (permalink / raw) To: Ingo Molnar Cc: Linus Torvalds, Rafael J. Wysocki, Greg KH, jbarnes, lenb, Linux Kernel Mailing List, tiwai, Andrew Morton 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. ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected) 2008-12-04 18:00 ` Frans Pop 2008-12-04 20:03 ` Linus Torvalds @ 2008-12-04 22:46 ` Rafael J. Wysocki 1 sibling, 0 replies; 71+ messages in thread From: Rafael J. Wysocki @ 2008-12-04 22:46 UTC (permalink / raw) To: Frans Pop Cc: Linus Torvalds, Greg KH, Ingo Molnar, jbarnes, lenb, Linux Kernel Mailing List, tiwai, Andrew Morton 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 ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected) 2008-12-04 16:17 ` Linus Torvalds 2008-12-04 18:00 ` Frans Pop @ 2008-12-04 22:40 ` Rafael J. Wysocki 2008-12-04 23:22 ` Linus Torvalds 1 sibling, 1 reply; 71+ messages in thread From: Rafael J. Wysocki @ 2008-12-04 22:40 UTC (permalink / raw) To: Linus Torvalds Cc: Frans Pop, Greg KH, Ingo Molnar, jbarnes, lenb, Linux Kernel Mailing List, tiwai, Andrew Morton 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 ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected) 2008-12-04 22:40 ` Rafael J. Wysocki @ 2008-12-04 23:22 ` Linus Torvalds 2008-12-04 23:45 ` Rafael J. Wysocki 0 siblings, 1 reply; 71+ messages in thread From: Linus Torvalds @ 2008-12-04 23:22 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Frans Pop, Greg KH, Ingo Molnar, jbarnes, lenb, Linux Kernel Mailing List, tiwai, Andrew Morton 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 ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected) 2008-12-04 23:22 ` Linus Torvalds @ 2008-12-04 23:45 ` Rafael J. Wysocki 2008-12-05 0:07 ` Linus Torvalds 2008-12-05 6:55 ` Frans Pop 0 siblings, 2 replies; 71+ messages in thread From: Rafael J. Wysocki @ 2008-12-04 23:45 UTC (permalink / raw) To: Linus Torvalds Cc: Frans Pop, Greg KH, Ingo Molnar, jbarnes, lenb, Linux Kernel Mailing List, tiwai, Andrew Morton 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 ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected) 2008-12-04 23:45 ` Rafael J. Wysocki @ 2008-12-05 0:07 ` Linus Torvalds 2008-12-05 0:20 ` Rafael J. Wysocki 2008-12-05 6:55 ` Frans Pop 1 sibling, 1 reply; 71+ messages in thread From: Linus Torvalds @ 2008-12-05 0:07 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Frans Pop, Greg KH, Ingo Molnar, jbarnes, lenb, Linux Kernel Mailing List, tiwai, Andrew Morton 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 ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected) 2008-12-05 0:07 ` Linus Torvalds @ 2008-12-05 0:20 ` Rafael J. Wysocki 0 siblings, 0 replies; 71+ messages in thread From: Rafael J. Wysocki @ 2008-12-05 0:20 UTC (permalink / raw) To: Linus Torvalds Cc: Frans Pop, Greg KH, Ingo Molnar, jbarnes, lenb, Linux Kernel Mailing List, tiwai, Andrew Morton 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 ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected) 2008-12-04 23:45 ` Rafael J. Wysocki 2008-12-05 0:07 ` Linus Torvalds @ 2008-12-05 6:55 ` Frans Pop 1 sibling, 0 replies; 71+ messages in thread From: Frans Pop @ 2008-12-05 6:55 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linus Torvalds, Greg KH, Ingo Molnar, jbarnes, lenb, Linux Kernel Mailing List, tiwai, Andrew Morton 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 ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected) 2008-12-04 11:29 ` Frans Pop 2008-12-04 16:17 ` Linus Torvalds @ 2008-12-04 22:09 ` Rafael J. Wysocki 2008-12-04 22:20 ` Linus Torvalds 1 sibling, 1 reply; 71+ messages in thread From: Rafael J. Wysocki @ 2008-12-04 22:09 UTC (permalink / raw) To: Frans Pop Cc: Linus Torvalds, Greg KH, Ingo Molnar, jbarnes, lenb, Linux Kernel Mailing List, tiwai, Andrew Morton 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 ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected) 2008-12-04 22:09 ` Rafael J. Wysocki @ 2008-12-04 22:20 ` Linus Torvalds 2008-12-04 23:31 ` Rafael J. Wysocki 0 siblings, 1 reply; 71+ messages in thread From: Linus Torvalds @ 2008-12-04 22:20 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Frans Pop, Greg KH, Ingo Molnar, jbarnes, lenb, Linux Kernel Mailing List, tiwai, Andrew Morton 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 ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected) 2008-12-04 22:20 ` Linus Torvalds @ 2008-12-04 23:31 ` Rafael J. Wysocki 2008-12-05 0:03 ` Linus Torvalds 0 siblings, 1 reply; 71+ messages in thread From: Rafael J. Wysocki @ 2008-12-04 23:31 UTC (permalink / raw) To: Linus Torvalds Cc: Frans Pop, Greg KH, Ingo Molnar, jbarnes, lenb, Linux Kernel Mailing List, tiwai, Andrew Morton [-- 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 ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected) 2008-12-04 23:31 ` Rafael J. Wysocki @ 2008-12-05 0:03 ` Linus Torvalds 2008-12-05 0:45 ` Linus Torvalds 0 siblings, 1 reply; 71+ messages in thread From: Linus Torvalds @ 2008-12-05 0:03 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Frans Pop, Greg KH, Ingo Molnar, jbarnes, lenb, Linux Kernel Mailing List, tiwai, Andrew Morton 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 ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected) 2008-12-05 0:03 ` Linus Torvalds @ 2008-12-05 0:45 ` Linus Torvalds 2008-12-05 1:08 ` Rafael J. Wysocki 0 siblings, 1 reply; 71+ messages in thread From: Linus Torvalds @ 2008-12-05 0:45 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Frans Pop, Greg KH, Ingo Molnar, jbarnes, lenb, Linux Kernel Mailing List, tiwai, Andrew Morton 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 ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected) 2008-12-05 0:45 ` Linus Torvalds @ 2008-12-05 1:08 ` Rafael J. Wysocki 2008-12-05 1:45 ` Linus Torvalds 0 siblings, 1 reply; 71+ messages in thread From: Rafael J. Wysocki @ 2008-12-05 1:08 UTC (permalink / raw) To: Linus Torvalds Cc: Frans Pop, Greg KH, Ingo Molnar, jbarnes, lenb, Linux Kernel Mailing List, tiwai, Andrew Morton 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 ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected) 2008-12-05 1:08 ` Rafael J. Wysocki @ 2008-12-05 1:45 ` Linus Torvalds 2008-12-05 2:55 ` Linus Torvalds 0 siblings, 1 reply; 71+ messages in thread From: Linus Torvalds @ 2008-12-05 1:45 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Frans Pop, Greg KH, Ingo Molnar, jbarnes, lenb, Linux Kernel Mailing List, tiwai, Andrew Morton 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) ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected) 2008-12-05 1:45 ` Linus Torvalds @ 2008-12-05 2:55 ` Linus Torvalds 2008-12-05 3:25 ` Linus Torvalds 0 siblings, 1 reply; 71+ messages in thread From: Linus Torvalds @ 2008-12-05 2:55 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Frans Pop, Greg KH, Ingo Molnar, jbarnes, lenb, Linux Kernel Mailing List, tiwai, Andrew Morton 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 ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected) 2008-12-05 2:55 ` Linus Torvalds @ 2008-12-05 3:25 ` Linus Torvalds 2008-12-05 6:44 ` Frans Pop ` (2 more replies) 0 siblings, 3 replies; 71+ messages in thread From: Linus Torvalds @ 2008-12-05 3:25 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Frans Pop, Greg KH, Ingo Molnar, jbarnes, lenb, Linux Kernel Mailing List, tiwai, Andrew Morton 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, ®ion); 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 ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected) 2008-12-05 3:25 ` Linus Torvalds @ 2008-12-05 6:44 ` Frans Pop 2008-12-05 8:27 ` Frans Pop 2008-12-05 12:00 ` Rafael J. Wysocki 2008-12-05 17:25 ` Jesse Barnes 2 siblings, 1 reply; 71+ messages in thread From: Frans Pop @ 2008-12-05 6:44 UTC (permalink / raw) To: Linus Torvalds Cc: Rafael J. Wysocki, Greg KH, Ingo Molnar, jbarnes, lenb, Linux Kernel Mailing List, tiwai, Andrew Morton 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 ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected) 2008-12-05 6:44 ` Frans Pop @ 2008-12-05 8:27 ` Frans Pop 0 siblings, 0 replies; 71+ messages in thread From: Frans Pop @ 2008-12-05 8:27 UTC (permalink / raw) To: Linus Torvalds Cc: Rafael J. Wysocki, Greg KH, Ingo Molnar, jbarnes, lenb, Linux Kernel Mailing List, tiwai, Andrew Morton 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 ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected) 2008-12-05 3:25 ` Linus Torvalds 2008-12-05 6:44 ` Frans Pop @ 2008-12-05 12:00 ` Rafael J. Wysocki 2008-12-05 15:57 ` Linus Torvalds 2008-12-05 17:25 ` Jesse Barnes 2 siblings, 1 reply; 71+ messages in thread From: Rafael J. Wysocki @ 2008-12-05 12:00 UTC (permalink / raw) To: Linus Torvalds Cc: Frans Pop, Greg KH, Ingo Molnar, jbarnes, lenb, Linux Kernel Mailing List, tiwai, Andrew Morton 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 ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected) 2008-12-05 12:00 ` Rafael J. Wysocki @ 2008-12-05 15:57 ` Linus Torvalds 2008-12-05 21:32 ` Rafael J. Wysocki 0 siblings, 1 reply; 71+ messages in thread From: Linus Torvalds @ 2008-12-05 15:57 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Frans Pop, Greg KH, Ingo Molnar, jbarnes, lenb, Linux Kernel Mailing List, tiwai, Andrew Morton 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 ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected) 2008-12-05 15:57 ` Linus Torvalds @ 2008-12-05 21:32 ` Rafael J. Wysocki 0 siblings, 0 replies; 71+ messages in thread From: Rafael J. Wysocki @ 2008-12-05 21:32 UTC (permalink / raw) To: Linus Torvalds Cc: Frans Pop, Greg KH, Ingo Molnar, jbarnes, lenb, Linux Kernel Mailing List, tiwai, Andrew Morton 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 ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected) 2008-12-05 3:25 ` Linus Torvalds 2008-12-05 6:44 ` Frans Pop 2008-12-05 12:00 ` Rafael J. Wysocki @ 2008-12-05 17:25 ` Jesse Barnes 2 siblings, 0 replies; 71+ messages in thread From: Jesse Barnes @ 2008-12-05 17:25 UTC (permalink / raw) To: Linus Torvalds Cc: Rafael J. Wysocki, Frans Pop, Greg KH, Ingo Molnar, lenb, Linux Kernel Mailing List, tiwai, Andrew Morton 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 ^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected) 2008-12-02 3:32 ` Linus Torvalds 2008-12-02 3:42 ` Linus Torvalds 2008-12-02 4:13 ` Frans Pop @ 2008-12-02 15:49 ` Rafael J. Wysocki 2 siblings, 0 replies; 71+ messages in thread From: Rafael J. Wysocki @ 2008-12-02 15:49 UTC (permalink / raw) To: Linus Torvalds Cc: Greg KH, Ingo Molnar, Jesse Barnes, Len Brown, LKML, Takashi Iwai, Andrew Morton 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 ^ permalink raw reply [flat|nested] 71+ messages in thread
end of thread, other threads:[~2009-01-30 4:35 UTC | newest] Thread overview: 71+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2008-12-02 7:53 Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected) Frans Pop -- strict thread matches above, loose matches on Subject: below -- 2008-12-02 2:20 Rafael J. Wysocki 2008-12-02 3:32 ` Linus Torvalds 2008-12-02 3:42 ` Linus Torvalds 2008-12-02 4:31 ` Frans Pop 2008-12-02 4:46 ` Linus Torvalds 2008-12-02 5:29 ` Frans Pop 2008-12-02 5:56 ` Frans Pop 2008-12-02 15:46 ` Linus Torvalds 2008-12-02 17:46 ` Frans Pop 2008-12-02 18:17 ` Linus Torvalds 2008-12-02 4:13 ` Frans Pop 2008-12-02 4:36 ` Linus Torvalds 2008-12-02 22:38 ` Rafael J. Wysocki 2008-12-02 23:37 ` Linus Torvalds 2008-12-03 0:00 ` Rafael J. Wysocki 2008-12-03 0:05 ` Rafael J. Wysocki 2008-12-03 0:31 ` Rafael J. Wysocki 2008-12-03 0:41 ` Linus Torvalds 2008-12-03 1:22 ` Rafael J. Wysocki 2008-12-03 2:02 ` Linus Torvalds 2008-12-03 7:40 ` Rafael J. Wysocki 2008-12-03 7:52 ` Rafael J. Wysocki 2008-12-03 11:20 ` Rafael J. Wysocki 2008-12-03 15:53 ` Linus Torvalds 2008-12-04 1:23 ` Rafael J. Wysocki 2008-12-04 4:40 ` Linus Torvalds 2008-12-04 8:21 ` Frans Pop 2008-12-04 22:01 ` Rafael J. Wysocki 2008-12-04 11:29 ` Frans Pop 2008-12-04 16:17 ` Linus Torvalds 2008-12-04 18:00 ` Frans Pop 2008-12-04 20:03 ` Linus Torvalds 2008-12-05 21:26 ` Linus Torvalds 2008-12-05 22:01 ` Rafael J. Wysocki 2008-12-05 22:14 ` Linus Torvalds 2008-12-06 0:04 ` Rafael J. Wysocki 2008-12-06 0:50 ` Linus Torvalds 2008-12-06 1:18 ` Rafael J. Wysocki 2008-12-06 1:55 ` Linus Torvalds 2008-12-06 2:18 ` Rafael J. Wysocki 2008-12-06 13:53 ` Rafael J. Wysocki 2008-12-06 2:45 ` Greg KH 2009-01-28 12:00 ` Frans Pop 2009-01-29 14:11 ` Ingo Molnar 2009-01-29 14:48 ` Rafael J. Wysocki 2009-01-29 16:44 ` Alexey Starikovskiy 2009-01-30 4:35 ` Frans Pop 2008-12-04 22:46 ` Rafael J. Wysocki 2008-12-04 22:40 ` Rafael J. Wysocki 2008-12-04 23:22 ` Linus Torvalds 2008-12-04 23:45 ` Rafael J. Wysocki 2008-12-05 0:07 ` Linus Torvalds 2008-12-05 0:20 ` Rafael J. Wysocki 2008-12-05 6:55 ` Frans Pop 2008-12-04 22:09 ` Rafael J. Wysocki 2008-12-04 22:20 ` Linus Torvalds 2008-12-04 23:31 ` Rafael J. Wysocki 2008-12-05 0:03 ` Linus Torvalds 2008-12-05 0:45 ` Linus Torvalds 2008-12-05 1:08 ` Rafael J. Wysocki 2008-12-05 1:45 ` Linus Torvalds 2008-12-05 2:55 ` Linus Torvalds 2008-12-05 3:25 ` Linus Torvalds 2008-12-05 6:44 ` Frans Pop 2008-12-05 8:27 ` Frans Pop 2008-12-05 12:00 ` Rafael J. Wysocki 2008-12-05 15:57 ` Linus Torvalds 2008-12-05 21:32 ` Rafael J. Wysocki 2008-12-05 17:25 ` Jesse Barnes 2008-12-02 15:49 ` Rafael J. Wysocki
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®