Skip to contentSkip to conversation

suspend/resume regression fixes

PATCH In review Thomas Gleixner 10 participants 19 messages Sep 22, 2007 – Oct 1, 2007

Subsystems (3)
lore
Share & tools
lore
#0 lore raw

cover suspend/resume regression fixes

Sorry, it took me quite a while to realize the real root cause of the VAIO - and probably many other machines - suspend/resume regressions, which were unearthed by the dyntick / clockevents patches.

We disable a lot of ACPI/BIOS functionality during suspend, but we keep the lower idle C-states functionality active across suspend/resume. It seems that this causes trouble with certain BIOSes, but I assume that the problem is more wide spread and just not surfacing due to the various scenarios in which a machine goes into suspend/resume. I spent some quality time to figure out a set of debug mechanisms, which did not influence the problem. So it is quite likely that a lot of machines might be affected by this, but due to the configuration, interrupt scenarios, .... the problem just does not show up.

My final enlightment was, when I removed the ACPI processor module, which controls the lower idle C-states, right before resume; this worked fine all the time even without all the workaround hacks.

I really hope that this two patches finally set an end to the "jinxed VAIO heisenbug series", which started when we removed the periodic tick with the clockevents/dyntick patches.

Venki, can you please add the analogous fix to the cpuidle patch set ?

Thanks,

tglx

#1 lore raw

PATCH 1/2 ACPI: disable lower idle C-states across suspend/resume

device_suspend() calls ACPI suspend functions, which seems to have undesired side effects on lower idle C-states. It took me some time to realize that especially the VAIO BIOSes (both Andrews jinxed UP and my elfstruck SMP one) show this effect. I'm quite sure that other bug reports against suspend/resume about turning the system into a brick have the same root cause.

After fishing in the dark for quite some time, I realized that removing the ACPI processor module before suspend (this removes the lower C-state functionality) made the problem disappear. Interestingly enough the propability of having a bricked box is influenced by various factors (interrupts, size of the ram image, ...). Even adding a bunch of printks in the wrong places made the problem go away. The previous periodic tick implementation simply pampered over the problem, which explains why the dyntick / clockevents changes made this more prominent.

We avoid complex functionality during the boot process and we have to do the same during suspend/resume. It is a similar scenario and equaly fragile.

Add suspend / resume functions to the ACPI processor code and disable the lower idle C-states across suspend/resume. Fall back to the default idle implementation (halt) instead.

Cc Len Brown <[email protected]>
Cc Venkatesh Pallipadi <[email protected]>
Cc Rafael J. Wysocki <[email protected]>
---
 drivers/acpi/processor_core.c |    2 ++
 drivers/acpi/processor_idle.c |   19 ++++++++++++++++++-
 include/acpi/processor.h      |    2 ++
 3 files changed, 22 insertions(+), 1 deletion(-)
drivers/acpi/processor_core.c +2 -0
Index: linux-2.6/drivers/acpi/processor_core.c
===================================================================
@@ -102,6 +102,8 @@ static struct acpi_driver acpi_processor
 		.add = acpi_processor_add,
 		.remove = acpi_processor_remove,
 		.start = acpi_processor_start,
+		.suspend = acpi_processor_suspend,
+		.resume = acpi_processor_resume,
 		},
 };
 
drivers/acpi/processor_idle.c +18 -1
Index: linux-2.6/drivers/acpi/processor_idle.c
===================================================================
@@ -325,6 +325,23 @@ static void acpi_state_timer_broadcast(s
 
 #endif
 
+/*
+ * Suspend / resume control
+ */
+static int acpi_idle_suspend;
+
+int acpi_processor_suspend(struct acpi_device * device, pm_message_t state)
+{
+	acpi_idle_suspend = 1;
+	return 0;
+}
+
+int acpi_processor_resume(struct acpi_device * device)
+{
+	acpi_idle_suspend = 0;
+	return 0;
+}
+
 static void acpi_processor_idle(void)
 {
 	struct acpi_processor *pr = NULL;
@@ -355,7 +372,7 @@ static void acpi_processor_idle(void)
 	}
 
 	cx = pr->power.state;
-	if (!cx) {
+	if (!cx || acpi_idle_suspend) {
 		if (pm_idle_save)
 			pm_idle_save();
 		else
include/acpi/processor.h +2 -0
Index: linux-2.6/include/acpi/processor.h
===================================================================
@@ -320,6 +320,8 @@ int acpi_processor_power_init(struct acp
 int acpi_processor_cst_has_changed(struct acpi_processor *pr);
 int acpi_processor_power_exit(struct acpi_processor *pr,
 			      struct acpi_device *device);
+int acpi_processor_suspend(struct acpi_device * device, pm_message_t state);
+int acpi_processor_resume(struct acpi_device * device);
 
 /* in processor_thermal.c */
 int acpi_processor_get_limit_info(struct acpi_processor *pr);
#2 lore raw

Re: [patch 1/2] ACPI: disable lower idle C-states across suspend/resume

Quoted 7 lines · Thomas Gleixner
drivers/acpi/processor_idle.c +6 -0
+/*
+ * Suspend / resume control
+ */
+static int acpi_idle_suspend;
+
+int acpi_processor_suspend(struct acpi_device * device, pm_message_t state)

drivers/acpi/processor_idle.c static void acpi_state_timer_broadcast(s · line 343

Quoted 10 lines
drivers/acpi/processor_idle.c +10 -0
+{
+	acpi_idle_suspend = 1;
+	return 0;
+}
+
+int acpi_processor_resume(struct acpi_device * device)
+{
+	acpi_idle_suspend = 0;
+	return 0;
+}

Instead of the ugly global variable you could you could just change pm_idle back to NULL (= default_idle) and then later restore it.

-Andi

#3 lore raw

PATCH 2/2 clockevents: remove the suspend/resume workaround^Wthinko

In reply to Thomas Gleixner

In a desparate attempt to fix the suspend/resume problem on Andrews VAIO I added a workaround which enforced the broadcast of the oneshot timer on resume. This was actually resolving the problem on the VAIO but was just a stupid workaround, which was not tackling the root
cause: the assignement of lower idle C-States in the ACPI processor_idle code. The cpuidle patches, which utilize the dynamic tick feature and go faster into deeper C-states exposed the problem again. The correct solution is the previous patch, which prevents lower C-states across the suspend/resume.

Remove the enforcement code, including the conditional broadcast timer arming, which helped to pamper over the real problem for quite a time. The oneshot broadcast flag for the cpu, which runs the resume code can never be set at the time when this code is executed. It only gets set, when the CPU is entering a lower idle C-State.

Cc Len Brown <[email protected]>
Cc Venkatesh Pallipadi <[email protected]>
Cc Rafael J. Wysocki <[email protected]>
---
 kernel/time/tick-broadcast.c |   17 +----------------
 1 file changed, 1 insertion(+), 16 deletions(-)
kernel/time/tick-broadcast.c +1 -16
Index: linux-2.6/kernel/time/tick-broadcast.c
===================================================================
@@ -382,23 +382,8 @@ static int tick_broadcast_set_event(ktim
 
 int tick_resume_broadcast_oneshot(struct clock_event_device *bc)
 {
-	int cpu = smp_processor_id();
-
-	/*
-	 * If the CPU is marked for broadcast, enforce oneshot
-	 * broadcast mode. The jinxed VAIO does not resume otherwise.
-	 * No idea why it ends up in a lower C State during resume
-	 * without notifying the clock events layer.
-	 */
-	if (cpu_isset(cpu, tick_broadcast_mask))
-		cpu_set(cpu, tick_broadcast_oneshot_mask);
-
 	clockevents_set_mode(bc, CLOCK_EVT_MODE_ONESHOT);
-
-	if(!cpus_empty(tick_broadcast_oneshot_mask))
-		tick_broadcast_set_event(ktime_get(), 1);
-
-	return cpu_isset(cpu, tick_broadcast_oneshot_mask);
+	return 0;
 }
 
 /*
#4 lore raw
In reply to Thomas Gleixner
Quoted 8 lines · Thomas Gleixner

My final enlightment was, when I removed the ACPI processor module, which controls the lower idle C-states, right before resume; this worked fine all the time even without all the workaround hacks.

I really hope that this two patches finally set an end to the "jinxed VAIO heisenbug series", which started when we removed the periodic tick with the clockevents/dyntick patches.

Ok, so the patches look fine, but I somehow have this slight feeling that you gave up a bit too soon on the "*why* does this happen?" question.

I realize that the answer is easily "because ACPI screwed up", but I'm wondering if there's something we do to trigger that screw-up.

In particular, I also suspect that this may not really fix the problem - maybe it just makes the window sufficiently small that it no longer triggers. Because we don't necessarily understand what the real background for the problem is, I'm not sure we can say that it is solved.

The reason I say this is that I have a suspicion on what triggers it.

I suspect that the problem is that we do

	pm_ops->prepare();
	disable_nonboot_cpus()
	suspend_enter();
	enable_nonboot_cpus()
	pm_finish()

and here the big thing to notice is that "pm_ops->prepare()" call, which sets the wakup vector etc etc.

So maybe the real problem here is that once we've done the "->prepare()" call and ACPI has set up various stuff, we MUST NOT do any calls to any ACPI routines to set low-power states, because the stupid firmware isn't expecting it.

Now, if this is the cause, then I think your patch should indeed fix it, since you get called by the early-suspend code (which happens *before* the "->prepare()" call), but at the same time, I wonder if maybe it would be slightly "more correct" to instead of using the suspend/resume callbacks, simply do this in the "acpi_pm_prepare()" stage, since that is likely the thing that triggers it?

But hey, I think I'll apply the patches as-is. I'd just feel even better if we actually understood *why* doing the CPU Cx states is not something we can do around the suspend code!

Linus

#5 lore raw

Linus,

Quoted 10 lines · Linus Torvalds
Quoted 7 lines

My final enlightment was, when I removed the ACPI processor module, which controls the lower idle C-states, right before resume; this worked fine all the time even without all the workaround hacks.

I really hope that this two patches finally set an end to the "jinxed VAIO heisenbug series", which started when we removed the periodic tick with the clockevents/dyntick patches.

Ok, so the patches look fine, but I somehow have this slight feeling that you gave up a bit too soon on the "*why* does this happen?" question.

Yeah, I gave up at the point where I was not longer able to dig deeper :)

Quoted 2 lines

I realize that the answer is easily "because ACPI screwed up", but I'm wondering if there's something we do to trigger that screw-up.

Fair enough.

Quoted 15 lines

In particular, I also suspect that this may not really fix the problem - maybe it just makes the window sufficiently small that it no longer triggers. Because we don't necessarily understand what the real background for the problem is, I'm not sure we can say that it is solved.

The reason I say this is that I have a suspicion on what triggers it.

I suspect that the problem is that we do

	pm_ops->prepare();
	disable_nonboot_cpus()
	suspend_enter();
	enable_nonboot_cpus()
	pm_finish()
Quoted 7 lines

and here the big thing to notice is that "pm_ops->prepare()" call, which sets the wakup vector etc etc.

So maybe the real problem here is that once we've done the "->prepare()" call and ACPI has set up various stuff, we MUST NOT do any calls to any ACPI routines to set low-power states, because the stupid firmware isn't expecting it.

That's what I suspect and deduced from the various experiments including a force the cpu into a lower c-state one, which triggered the problem fully reproducible. Note that in case of the "force a lower c-state" I verified, that the PIT was activated to avoid the local apic stops in c3 issue. But I never got an PIT interrupt. Either the box was completely stuck or I was able to recover by hitting a key, which is as well one of the unexplained phenomenons.

Quoted 6 lines

Now, if this is the cause, then I think your patch should indeed fix it, since you get called by the early-suspend code (which happens *before* the "->prepare()" call), but at the same time, I wonder if maybe it would be slightly "more correct" to instead of using the suspend/resume callbacks, simply do this in the "acpi_pm_prepare()" stage, since that is likely the thing that triggers it?

Yeah, probably that's the correct point, but I leave this to the ACPI wizards.

Quoted 3 lines

But hey, I think I'll apply the patches as-is. I'd just feel even better if we actually understood *why* doing the CPU Cx states is not something we can do around the suspend code!

That needs some explanation of the folks who can actually look beyond the ACPI/BIOS internals.

tglx

#6 lore raw
In reply to Linus Torvalds

* Sat, 22 Sep 2007 15:59:25 -0700 (PDT)

As i never had any suspend working ever, let me point this LKML post

http://mid.gmane.org/[email protected]

from Mihal, who just managed to do some other magic in sligtly different context (maybe yet another anti "ACPI screwed up").

Mihai, you can find whole thread by above URL, requesting message-ids from in-reply-to or references headers of this message.
_____

#7 lore raw
Quoted 5 lines · Oleg Verych

As i never had any suspend working ever, let me point this LKML post

http://mid.gmane.org/[email protected]

Quoted 7 lines

from Mihal, who just managed to do some other magic in sligtly different context (maybe yet another anti "ACPI screwed up").

Mihai, you can find whole thread by above URL, requesting message-ids from in-reply-to or references headers of this message.

From a "future behaviour" standpoint it would probably be interesting to

hear whether Mihai can make his machine with not with the old IDE layer (which distributions are migrating away from) but with the ATA layer (libata) instead. It too should hopefully know about using ACPI to restore any ATA controller quirks.

Linus

#8 lore raw
Quoted 5 lines · Linus Torvalds

From a "future behaviour" standpoint it would probably be interesting to hear whether Mihai can make his machine with not with the old IDE layer (which distributions are migrating away from) but with the ATA layer (libata) instead. It too should hopefully know about using ACPI to restore any ATA controller quirks.

I switched to libata, but it behaves like the old IDE without ACPI. I did not manage to get a full dmesg (apparently all volumes are mounted r/o right after a power up from a s2ram) but I did make a picture, from which I quote (if I may say so):

"
ata1.00: configured for PIO0
sd 0:0:0:0: [sda] Result: hostbyte=0x00 driverbyte=0x08 sd 0:0:0:0: [sda] Sense key : 0xb [current] [descriptor] Descriptor sense data with sense descriptors (in hex):

          72 0b 00 00 00 00 00 0c 00 0a 80 00 00 00 00 00
          07 65 35 25
  sd 0:0:0:0: [sda] ASC=0x0 ASCQ=0x0
  end_request: I/O error, dev sda, sector 124073509
  ata1: EH complete
  sd 0:0:0:0: [sda] Write Protect is off
  sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
  ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
  ata1.00: cmd c5/00:10:75:36:65/00:00:00:00:00/e7 tag 0 cdb 0x0 data 8192 out
           res 51/04:10:75:36:65/00:00:00:00:00/e7 Emask 0x1 (device error)

ata1.00: configured for PIO0
ata1: EH complete
"

The last six lines repeat six times after which the whole things goes from the beginning:
"
ata1.00: configured for PIO0
...
"

It all gets crazy the moment I (or a process) try to access the root (or any other drive), until then, everything is nice and quiet.

Mmm... in the excerpt above it says: "Write Protect is off" but when I did

  $ mount -o remount,rw /
  I got something like: "the device is write protected".

I tried to save the dmesg on a mmc, but after powering up it said:
"out of disk space"

These are about all symptoms that I noticed... oh, and 'scsi_eh_0/1' enters disk-sleep often.

I attached the dmesg pre s2ram.

Thanks,

Signature · 1 line
Mihai Donțu
[    0.000000] Linux version 2.6.23-rc7 (root@mdontu-l) (gcc version 4.1.2 (Gentoo 4.1.2)) #10 PREEMPT Sun Sep 23 06:54:24 EEST 2007
[    0.000000] Command line: nohz=on root=/dev/sda7
[    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 - 0000000000100000 (reserved)
[    0.000000]  BIOS-e820: 0000000000100000 - 0000000037fd0000 (usable)
[    0.000000]  BIOS-e820: 0000000037fd0000 - 0000000037fefc00 (reserved)
[    0.000000]  BIOS-e820: 0000000037fefc00 - 0000000037ffb000 (ACPI NVS)
[    0.000000]  BIOS-e820: 0000000037ffb000 - 0000000040000000 (reserved)
[    0.000000]  BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
[    0.000000]  BIOS-e820: 00000000fec00000 - 00000000fec02000 (reserved)
[    0.000000]  BIOS-e820: 00000000ffb80000 - 00000000ffc00000 (reserved)
[    0.000000]  BIOS-e820: 00000000fff80000 - 0000000100000000 (reserved)
[    0.000000] Entering add_active_range(0, 0, 159) 0 entries of 256 used
[    0.000000] Entering add_active_range(0, 256, 229328) 1 entries of 256 used
[    0.000000] end_pfn_map = 1048576
[    0.000000] DMI 2.3 present.
[    0.000000] ACPI: RSDP 000FE270, 0014 (r0 HP    )
[    0.000000] ACPI: RSDT 37FEFC84, 0034 (r1 HP     0944     22110520 HP          1)
[    0.000000] ACPI: FACP 37FEFC00, 0084 (r2 HP     0944            2 HP          1)
[    0.000000] ACPI: DSDT 37FEFD50, 7489 (r1 HP        SB400    10000 MSFT  100000E)
[    0.000000] ACPI: FACS 37FFAE80, 0040
[    0.000000] ACPI: APIC 37FEFCB8, 005A (r1 HP     0944            1 HP          1)
[    0.000000] ACPI: MCFG 37FEFD14, 003C (r1 HP     0944            1 HP          1)
[    0.000000] ACPI: SSDT 37FF71D9, 0382 (r1 HP       HPQPpc     1001 MSFT  100000E)
[    0.000000] Entering add_active_range(0, 0, 159) 0 entries of 256 used
[    0.000000] Entering add_active_range(0, 256, 229328) 1 entries of 256 used
[    0.000000] No mptable found.
[    0.000000] Zone PFN ranges:
[    0.000000]   DMA             0 ->     4096
[    0.000000]   DMA32        4096 ->  1048576
[    0.000000]   Normal    1048576 ->  1048576
[    0.000000] Movable zone start PFN for each node
[    0.000000] early_node_map[2] active PFN ranges
[    0.000000]     0:        0 ->      159
[    0.000000]     0:      256 ->   229328
[    0.000000] On node 0 totalpages: 229231
[    0.000000]   DMA zone: 56 pages used for memmap
[    0.000000]   DMA zone: 1911 pages reserved
[    0.000000]   DMA zone: 2032 pages, LIFO batch:0
[    0.000000]   DMA32 zone: 3079 pages used for memmap
[    0.000000]   DMA32 zone: 222153 pages, LIFO batch:31
[    0.000000]   Normal zone: 0 pages used for memmap
[    0.000000]   Movable zone: 0 pages used for memmap
[    0.000000] ATI board detected. Disabling timer routing over 8254.
[    0.000000] ACPI: PM-Timer IO Port: 0x8008
[    0.000000] ACPI: Local APIC address 0xfec01000
[    0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
[    0.000000] Processor #0 (Bootup-CPU)
[    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, 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 21 low level)
[    0.000000] ACPI: IRQ0 used by override.
[    0.000000] ACPI: IRQ2 used by override.
[    0.000000] Setting APIC routing to flat
[    0.000000] Using ACPI (MADT) for SMP configuration information
[    0.000000] Allocating PCI resources starting at 50000000 (gap: 40000000:a0000000)
[    0.000000] Built 1 zonelists in Zone order.  Total pages: 224185
[    0.000000] Kernel command line: nohz=on root=/dev/sda7
[    0.000000] Initializing CPU#0
[    0.000000] PID hash table entries: 4096 (order: 12, 32768 bytes)
[   39.453640] time.c: Detected 2194.613 MHz processor.
[   39.455401] Console: colour VGA+ 80x25
[   39.455404] console [tty0] enabled
[   39.459072] Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
[   39.460107] Inode-cache hash table entries: 65536 (order: 7, 524288 bytes)
[   39.475161] Memory: 894868k/917312k available (4163k kernel code, 21796k reserved, 1802k data, 232k init)
[   39.534509] Calibrating delay using timer specific routine.. 4391.68 BogoMIPS (lpj=2195841)
[   39.534639] Mount-cache hash table entries: 256
[   39.534832] CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
[   39.534878] CPU: L2 Cache: 1024K (64 bytes/line)
[   39.534934] CPU: AMD Turion(tm) 64 Mobile ML-40                  stepping 02
[   39.535066] ACPI: Core revision 20070126
[   39.580970] ..MP-BIOS bug: 8254 timer not connected to IO-APIC
[   39.591012] Using local APIC timer interrupts.
[   39.636564] result 12469396
[   39.636607] Detected 12.469 MHz APIC timer.
[   39.637555] NET: Registered protocol family 16
[   39.637769] No dock devices found.
[   39.637872] ACPI: bus type pci registered
[   39.643017] PCI: Using MMCONFIG at e0000000 - efffffff
[   39.643108] PCI: No mmconfig possible on device 00:18
[   39.646112] ACPI: EC: Look up EC in DSDT
[   39.646190] ACPI: EC: GPE = 0x11, I/O: command/status = 0x66, data = 0x62
[   39.662709] ACPI: Interpreter enabled
[   39.662754] ACPI: (supports S0 S3)
[   39.662910] ACPI: Using IOAPIC for interrupt routing
[   39.670228] ACPI: EC: GPE = 0x11, I/O: command/status = 0x66, data = 0x62
[   39.670321] ACPI: PCI Root Bridge [C047] (0000:00)
[   39.671725] PCI: Transparent bridge - 0000:00:14.4
[   39.671845] ACPI: PCI Interrupt Routing Table [\_SB_.C047._PRT]
[   39.672031] ACPI: PCI Interrupt Routing Table [\_SB_.C047.C048._PRT]
[   39.672112] ACPI: PCI Interrupt Routing Table [\_SB_.C047.C0AB._PRT]
[   39.685997] ACPI: PCI Interrupt Link [C0F0] (IRQs 10 11) *0, disabled.
[   39.686381] ACPI: PCI Interrupt Link [C0F1] (IRQs 10 11) *0, disabled.
[   39.686773] ACPI: PCI Interrupt Link [C0F2] (IRQs 10 11) *0, disabled.
[   39.687172] ACPI: PCI Interrupt Link [C0F3] (IRQs 10 11) *0, disabled.
[   39.687575] ACPI: PCI Interrupt Link [C0F4] (IRQs 10 11) *0, disabled.
[   39.687973] ACPI: PCI Interrupt Link [C0F5] (IRQs 9) *0, disabled.
[   39.688339] ACPI: PCI Interrupt Link [C0F6] (IRQs 10 11) *0, disabled.
[   39.688745] ACPI: PCI Interrupt Link [C0F7] (IRQs *10 11)
[   39.689043] ACPI: Power Resource [C1CF] (off)
[   39.689233] ACPI: Power Resource [C1B7] (on)
[   39.689317] ACPI: Power Resource [C1C7] (on)
[   39.689453] ACPI: Power Resource [C26C] (off)
[   39.689567] ACPI: Power Resource [C26D] (off)
[   39.689680] ACPI: Power Resource [C26E] (off)
[   39.689795] ACPI: Power Resource [C26F] (off)
[   39.689867] Linux Plug and Play Support v0.97 (c) Adam Belay
[   39.689929] pnp: PnP ACPI init
[   39.689977] ACPI: bus type pnp registered
[   39.696206] pnp: PnP ACPI: found 12 devices
[   39.696250] ACPI: ACPI bus type pnp unregistered
[   39.696468] SCSI subsystem initialized
[   39.696529] libata version 2.21 loaded.
[   39.696644] usbcore: registered new interface driver usbfs
[   39.696724] usbcore: registered new interface driver hub
[   39.696796] usbcore: registered new device driver usb
[   39.696983] PCI: Using ACPI for IRQ routing
[   39.697028] PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a report
[   39.697084] PCI: Cannot allocate resource region 7 of bridge 0000:00:04.0
[   39.697130] PCI: Cannot allocate resource region 8 of bridge 0000:00:04.0
[   39.697175] PCI: Cannot allocate resource region 9 of bridge 0000:00:04.0
[   39.697221] PCI: Cannot allocate resource region 7 of bridge 0000:00:05.0
[   39.697270] PCI: Cannot allocate resource region 8 of bridge 0000:00:05.0
[   39.697316] PCI: Cannot allocate resource region 9 of bridge 0000:00:05.0
[   39.700272] Bluetooth: Core ver 2.11
[   39.700357] NET: Registered protocol family 31
[   39.700401] Bluetooth: HCI device and connection manager initialized
[   39.700447] Bluetooth: HCI socket layer initialized
[   39.700492] NET: Registered protocol family 8
[   39.700536] NET: Registered protocol family 20
[   39.701257] Time: tsc clocksource has been installed.
[   39.703276] pnp: 00:00: iomem range 0x0-0x9ffff could not be reserved
[   39.703322] pnp: 00:00: iomem range 0xe0000-0xfffff could not be reserved
[   39.703368] pnp: 00:00: iomem range 0x100000-0x37ffffff could not be reserved
[   39.703419] pnp: 00:09: ioport range 0x40b-0x40b has been reserved
[   39.703464] pnp: 00:09: ioport range 0x4d0-0x4d1 has been reserved
[   39.703510] pnp: 00:09: ioport range 0x4d6-0x4d6 has been reserved
[   39.703556] pnp: 00:09: iomem range 0xffb80000-0xffbfffff could not be reserved
[   39.703607] pnp: 00:09: iomem range 0xfff80000-0xffffffff could not be reserved
[   39.703660] pnp: 00:0a: ioport range 0x8000-0x802f has been reserved
[   39.703708] pnp: 00:0a: ioport range 0x8100-0x811f has been reserved
[   39.703753] pnp: 00:0a: iomem range 0xe0000000-0xefffffff could not be reserved
[   39.703804] pnp: 00:0a: iomem range 0xfec00000-0xfec000ff has been reserved
[   39.703852] pnp: 00:0b: iomem range 0xcf000-0xdffff has been reserved
[   39.703898] pnp: 00:0b: iomem range 0x38000000-0x3fffffff could not be reserved
[   39.703949] pnp: 00:0b: iomem range 0xfec01000-0xfec01fff could not be reserved
[   39.704215] PCI: Bridge: 0000:00:01.0
[   39.704263]   IO window: 2000-2fff
[   39.704307]   MEM window: d0400000-d07fffff
[   39.704350]   PREFETCH window: c0000000-cfffffff
[   39.704394] PCI: Bridge: 0000:00:04.0
[   39.704437]   IO window: disabled.
[   39.704480]   MEM window: disabled.
[   39.704523]   PREFETCH window: disabled.
[   39.704567] PCI: Bridge: 0000:00:05.0
[   39.704610]   IO window: disabled.
[   39.704653]   MEM window: disabled.
[   39.704696]   PREFETCH window: disabled.
[   39.704741] PCI: Bus 3, cardbus bridge: 0000:02:04.0
[   39.704786]   IO window: 00001000-000010ff
[   39.704830]   IO window: 00001400-000014ff
[   39.704867]   PREFETCH window: 50000000-53ffffff
[   39.704905]   MEM window: 54000000-57ffffff
[   39.704943] PCI: Bridge: 0000:00:14.4
[   39.704982]   IO window: 1000-1fff
[   39.705025]   MEM window: d0000000-d03fffff
[   39.705063]   PREFETCH window: 50000000-53ffffff
[   39.705117] PCI: Setting latency timer of device 0000:00:04.0 to 64
[   39.705122] PCI: Setting latency timer of device 0000:00:05.0 to 64
[   39.705145] ACPI: PCI Interrupt 0000:02:04.0[A] -> GSI 20 (level, low) -> IRQ 20
[   39.705254] NET: Registered protocol family 2
[   39.715267] IP route cache hash table entries: 32768 (order: 6, 262144 bytes)
[   39.715757] TCP established hash table entries: 131072 (order: 9, 2097152 bytes)
[   39.718128] TCP bind hash table entries: 65536 (order: 7, 524288 bytes)
[   39.718740] TCP: Hash tables configured (established 131072 bind 65536)
[   39.718786] TCP reno registered
[   39.722123] VFS: Disk quotas dquot_6.5.1
[   39.722178] Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[   39.722328] Installing knfsd (copyright (C) 1996 [email protected]).
[   39.722606] NTFS driver 2.1.28 [Flags: R/O].
[   39.722675] fuse init (API version 7.8)
[   39.722864] io scheduler noop registered
[   39.722908] io scheduler anticipatory registered
[   39.722953] io scheduler deadline registered
[   39.723004] io scheduler cfq registered (default)
[   39.723051] PCI: MSI quirk detected. MSI deactivated.
[   39.724429] Boot video device is 0000:01:05.0
[   39.724585] PCI: Setting latency timer of device 0000:00:04.0 to 64
[   39.724599] assign_interrupt_mode Found MSI capability
[   39.724652] Allocate Port Service[0000:00:04.0:pcie00]
[   39.724680] Allocate Port Service[0000:00:04.0:pcie01]
[   39.724703] Allocate Port Service[0000:00:04.0:pcie02]
[   39.724742] PCI: Setting latency timer of device 0000:00:05.0 to 64
[   39.724755] assign_interrupt_mode Found MSI capability
[   39.724801] Allocate Port Service[0000:00:05.0:pcie00]
[   39.724823] Allocate Port Service[0000:00:05.0:pcie01]
[   39.724847] Allocate Port Service[0000:00:05.0:pcie02]
[   39.724939] AER service couldn't init device 0000:00:04.0:pcie01 - no _OSC support
[   39.724952] AER service couldn't init device 0000:00:05.0:pcie01 - no _OSC support
[   39.726300] ACPI: AC Adapter [C177] (on-line)
[   39.726537] ACPI: Battery Slot [C179] (battery present)
[   39.726739] ACPI: Battery Slot [C178] (battery absent)
[   39.726881] input: Power Button (FF) as /class/input/input0
[   39.726926] ACPI: Power Button (FF) [PWRF]
[   39.728785] input: Sleep Button (CM) as /class/input/input1
[   39.728830] ACPI: Sleep Button (CM) [C1F0]
[   39.728926] input: Lid Switch as /class/input/input2
[   39.728970] ACPI: Lid Switch [C1F1]
[   39.729179] ACPI: Transitioning device [C270] to D3
[   39.729227] ACPI: Transitioning device [C270] to D3
[   39.729273] ACPI: Fan [C270] (off)
[   39.729451] ACPI: Transitioning device [C271] to D3
[   39.729496] ACPI: Transitioning device [C271] to D3
[   39.729541] ACPI: Fan [C271] (off)
[   39.729718] ACPI: Transitioning device [C272] to D3
[   39.729763] ACPI: Transitioning device [C272] to D3
[   39.729808] ACPI: Fan [C272] (off)
[   39.729985] ACPI: Transitioning device [C273] to D3
[   39.730030] ACPI: Transitioning device [C273] to D3
[   39.730075] ACPI: Fan [C273] (off)
[   39.730419] input: Video Bus as /class/input/input3
[   39.730464] ACPI: Video Device [C049] (multi-head: yes  rom: no  post: no)
[   39.730741] ACPI: CPU0 (power states: C1[C1] C3[C3])
[   39.730894] ACPI: Processor [C000] (supports 8 throttling states)
[   39.738416] ACPI: Thermal Zone [TZ1] (68 C)
[   39.741642] ACPI: Thermal Zone [TZ2] (54 C)
[   39.749583] ACPI: Thermal Zone [TZ3] (27 C)
[   39.765001] Real Time Clock Driver v1.12ac
[   39.765151] Non-volatile memory driver v1.2
[   39.765209] Linux agpgart interface v0.102
[   39.765304] ipmi message handler version 39.1
[   39.765351] ipmi device interface
[   39.765440] IPMI System Interface driver.
[   39.773182] ipmi_si: Unable to find any System Interface(s)
[   39.773229] IPMI Watchdog: driver initialized
[   39.773273] Copyright (C) 2004 MontaVista Software - IPMI Powerdown via sys_reboot.
[   39.773325] Hangcheck: starting hangcheck timer 0.9.0 (tick is 180 seconds, margin is 60 seconds).
[   39.773377] Hangcheck: Using get_cycles().
[   39.773421] Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
[   39.773832] ACPI: PCI Interrupt 0000:00:14.6[B] -> GSI 17 (level, low) -> IRQ 17
[   39.773923] ACPI: PCI interrupt for device 0000:00:14.6 disabled
[   39.774338] RAMDISK driver initialized: 16 RAM disks of 65536K size 1024 blocksize
[   39.774577] loop: module loaded
[   39.774757] nbd: registered device at major 43
[   39.775336] ACPI: PCI Interrupt 0000:02:04.3[B] -> GSI 21 (level, low) -> IRQ 21
[   39.775535] tg3.c:v3.81 (September 5, 2007)
[   39.775599] ACPI: PCI Interrupt 0000:02:01.0[A] -> GSI 23 (level, low) -> IRQ 23
[   39.796130] tifm_core: MMC/SD card detected in socket 0:3
[   39.805943] eth0: Tigon3 [partno(BCM95788A50) rev 3003 PHY(5705)] (PCI:33MHz:32-bit) 10/100/1000Base-T Ethernet 00:0f:b0:f7:d7:da
[   39.806215] eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] WireSpeed[0] TSOcap[1]
[   39.806266] eth0: dma_rwctrl[763f0000] dma_mask[32-bit]
[   39.806375] PPP generic driver version 2.4.2
[   39.806463] PPP Deflate Compression module registered
[   39.806508] PPP BSD Compression module registered
[   39.806601] PPP MPPE Compression module registered
[   39.806646] NET: Registered protocol family 24
[   39.806756] tun: Universal TUN/TAP device driver, 1.6
[   39.806800] tun: (C) 1999-2004 Max Krasnyansky <[email protected]>
[   39.807073] ACPI: PCI Interrupt 0000:00:14.1[A] -> GSI 16 (level, low) -> IRQ 16
[   39.807264] scsi0 : pata_atiixp
[   39.807347] scsi1 : pata_atiixp
[   39.807421] ata1: PATA max UDMA/100 cmd 0x00000000000101f0 ctl 0x00000000000103f6 bmdma 0x0000000000013010 irq 14
[   39.807474] ata2: PATA max UDMA/100 cmd 0x0000000000010170 ctl 0x0000000000010376 bmdma 0x0000000000013018 irq 15
[   39.841053] Marking TSC unstable due to TSC halts in C3
[   39.841103] Time: acpi_pm clocksource has been installed.
[   39.961398] ata1.00: ATA-6: FUJITSU MHV2080AH, 00830096, max UDMA/100
[   39.961444] ata1.00: 156301488 sectors, multi 16: LBA 
[   39.983340] ata1.00: configured for UDMA/100
[   40.288012] ata2.00: ATAPI: MATSHITAUJ-840D, 1.02, max MWDMA2
[   40.444789] ata2.00: configured for MWDMA2
[   40.444905] scsi 0:0:0:0: Direct-Access     ATA      FUJITSU MHV2080A 0083 PQ: 0 ANSI: 5
[   40.445021] sd 0:0:0:0: [sda] 156301488 512-byte hardware sectors (80026 MB)
[   40.445074] sd 0:0:0:0: [sda] Write Protect is off
[   40.445118] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[   40.445128] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[   40.445220] sd 0:0:0:0: [sda] 156301488 512-byte hardware sectors (80026 MB)
[   40.445270] sd 0:0:0:0: [sda] Write Protect is off
[   40.445315] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[   40.445324] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[   40.445377]  sda: sda1 sda2 < sda5 sda6 sda7 sda8 >
[   40.501311] sd 0:0:0:0: [sda] Attached SCSI disk
[   40.501399] sd 0:0:0:0: Attached scsi generic sg0 type 0
[   40.503265] scsi 1:0:0:0: CD-ROM            MATSHITA UJ-840D          1.02 PQ: 0 ANSI: 5
[   40.509950] sr0: scsi3-mmc drive: 24x/24x writer cd/rw xa/form2 cdda tray
[   40.509998] Uniform CD-ROM driver Revision: 3.20
[   40.510085] sr 1:0:0:0: Attached scsi CD-ROM sr0
[   40.510129] sr 1:0:0:0: Attached scsi generic sg1 type 5
[   40.510363] ACPI: PCI Interrupt 0000:02:04.2[C] -> GSI 21 (level, low) -> IRQ 21
[   40.560581] ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[21]  MMIO=[d0013000-d00137ff]  Max Packet=[2048]  IR/IT contexts=[4/8]
[   40.560721] ieee1394: raw1394: /dev/raw1394 device initialized
[   40.560840] usbmon: debugfs is not available
[   40.560921] ACPI: PCI Interrupt 0000:00:13.2[A] -> GSI 19 (level, low) -> IRQ 19
[   40.561423] ehci_hcd 0000:00:13.2: EHCI Host Controller
[   40.561587] ehci_hcd 0000:00:13.2: new USB bus registered, assigned bus number 1
[   40.561694] ehci_hcd 0000:00:13.2: irq 19, io mem 0xd0802000
[   40.561749] ehci_hcd 0000:00:13.2: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
[   40.561959] usb usb1: configuration #1 chosen from 1 choice
[   40.562068] hub 1-0:1.0: USB hub found
[   40.562117] hub 1-0:1.0: 8 ports detected
[   40.662947] ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller (OHCI) Driver
[   40.662985] ACPI: PCI Interrupt 0000:00:13.0[A] -> GSI 19 (level, low) -> IRQ 19
[   40.663224] ohci_hcd 0000:00:13.0: OHCI Host Controller
[   40.663378] ohci_hcd 0000:00:13.0: new USB bus registered, assigned bus number 2
[   40.663446] ohci_hcd 0000:00:13.0: irq 19, io mem 0xd0800000
[   40.717892] usb usb2: configuration #1 chosen from 1 choice
[   40.717970] hub 2-0:1.0: USB hub found
[   40.718023] hub 2-0:1.0: 4 ports detected
[   40.818689] ACPI: PCI Interrupt 0000:00:13.1[A] -> GSI 19 (level, low) -> IRQ 19
[   40.818907] ohci_hcd 0000:00:13.1: OHCI Host Controller
[   40.819063] ohci_hcd 0000:00:13.1: new USB bus registered, assigned bus number 3
[   40.819131] ohci_hcd 0000:00:13.1: irq 19, io mem 0xd0801000
[   40.873683] usb usb3: configuration #1 chosen from 1 choice
[   40.873762] hub 3-0:1.0: USB hub found
[   40.873815] hub 3-0:1.0: 4 ports detected
[   41.445670] usb 3-1: new full speed USB device using ohci_hcd and address 2
[   41.581674] usb 3-1: configuration #1 chosen from 1 choice
[   41.800143] usb 3-3: new low speed USB device using ohci_hcd and address 3
[   41.814233] ieee1394: Host added: ID:BUS[0-00:1023]  GUID[00023f99292d1c0c]
[   41.941192] usb 3-3: configuration #1 chosen from 1 choice
[   41.943249] usbcore: registered new interface driver usblp
[   41.943294] Initializing USB Mass Storage driver...
[   41.943364] usbcore: registered new interface driver usb-storage
[   41.943410] USB Mass Storage support registered.
[   41.943511] PNP: PS/2 Controller [PNP0303:C1C4,PNP0f13:C1C5] at 0x60,0x64 irq 1,12
[   41.945365] i8042.c: Detected active multiplexing controller, rev 1.1.
[   41.946170] serio: i8042 KBD port at 0x60,0x64 irq 1
[   41.946250] serio: i8042 AUX0 port at 0x60,0x64 irq 12
[   41.946322] serio: i8042 AUX1 port at 0x60,0x64 irq 12
[   41.946395] serio: i8042 AUX2 port at 0x60,0x64 irq 12
[   41.946465] serio: i8042 AUX3 port at 0x60,0x64 irq 12
[   41.946581] mice: PS/2 mouse device common for all mice
[   41.968645] input: AT Translated Set 2 keyboard as /class/input/input4
[   41.980759] input: PC Speaker as /class/input/input5
[   42.589206] Synaptics Touchpad, model: 1, fw: 6.2, id: 0x1a0b1, caps: 0xa04713/0x200000
[   42.629015] input: SynPS/2 Synaptics TouchPad as /class/input/input6
[   42.631917] I2O subsystem v1.325
[   42.631961] i2o: max drivers = 8
[   42.632079] I2O Configuration OSM v1.323
[   42.632139] I2O Bus Adapter OSM v1.317
[   42.632199] I2O Block Device OSM v1.325
[   42.632293] I2O SCSI Peripheral OSM v1.316
[   42.632354] I2O ProcFS OSM v1.316
[   42.632414] i2c /dev entries driver
[   42.632562] piix4_smbus 0000:00:14.0: Found 0000:00:14.0 device
[   42.709894] sc520_wdt: WDT driver for SC520 initialised. timeout=30 sec (nowayout=0)
[   42.709946] sc1200wdt: build 20020303
[   42.710007] sc1200wdt: io parameter must be specified
[   42.710068] SoftDog: cannot register miscdev on minor=130 (err=-16)
[   42.710147] device-mapper: ioctl: 4.11.0-ioctl (2006-10-12) initialised: [email protected]
[   42.710211] Bluetooth: HCI USB driver ver 2.9
[   42.710279] usbcore: registered new interface driver hci_usb
[   42.710325] Bluetooth: Virtual HCI driver ver 1.2
[   42.710390] Bluetooth: HCI UART driver ver 2.2
[   42.710435] Bluetooth: HCI H4 protocol initialized
[   42.710480] Bluetooth: HCI BCSP protocol initialized
[   42.710524] Bluetooth: Broadcom Blutonium firmware driver ver 1.1
[   42.710590] usbcore: registered new interface driver bcm203x
[   42.710636] Bluetooth: Digianswer Bluetooth USB driver ver 0.8
[   42.710701] usbcore: registered new interface driver bpa10x
[   42.710747] Bluetooth: BlueFRITZ! USB driver ver 1.1
[   42.712550] usbcore: registered new interface driver bfusb
[   42.712596] EDAC MC: Ver: 2.1.0 Sep 23 2007
[   42.712824] sdhci: Secure Digital Host Controller Interface driver
[   42.712869] sdhci: Copyright(c) Pierre Ossman
[   42.712937] sdhci: SDHCI controller found at 0000:02:04.4 [104c:8034] (rev 0)
[   42.713004] ACPI: PCI Interrupt 0000:02:04.4[C] -> GSI 21 (level, low) -> IRQ 21
[   42.713620] mmc0: SDHCI at 0xd001a000 irq 21 DMA
[   42.713934] mmc1: SDHCI at 0xd001b000 irq 21 DMA
[   42.714212] mmc2: SDHCI at 0xd001c000 irq 21 DMA
[   42.714280] wbsd: Winbond W83L51xD SD/MMC card interface driver
[   42.714325] wbsd: Copyright(c) Pierre Ossman
[   42.763775] usbcore: registered new interface driver hiddev
[   42.770230] input: Logitech USB Receiver as /class/input/input7
[   42.770325] input: USB HID v1.10 Mouse [Logitech USB Receiver] on usb-0000:00:13.1-3
[   42.770454] usbcore: registered new interface driver usbhid
[   42.770499] drivers/hid/usbhid/hid-core.c: v2.6:USB HID core driver
[   42.770584] Advanced Linux Sound Architecture Driver Version 1.0.14 (Fri Jul 20 09:12:58 2007 UTC).
[   42.770843] ACPI: PCI Interrupt 0000:00:14.5[B] -> GSI 17 (level, low) -> IRQ 17
[   42.779916] ACPI: PCI Interrupt 0000:00:14.6[B] -> GSI 17 (level, low) -> IRQ 17
[   42.808996] mmc3: new MMC card at address 0001
[   42.809158] mmcblk0: mmc3:0001 000000 62720KiB 
[   42.809236]  mmcblk0: p1
[   42.882578] MC'97 0 converters and GPIO not ready (0x1)
[   42.883156] ALSA device list:
[   42.883200]   #0: ATI IXP rev 2 with unknown codec at 0xd0804000, irq 17
[   42.883246]   #1: ATI IXP Modem rev 2 at 0xd0805000, irq 17
[   42.883326] oprofile: using NMI interrupt.
[   42.883396] Netfilter messages via NETLINK v0.30.
[   42.883469] ip_tables: (C) 2000-2006 Netfilter Core Team
[   42.883538] arp_tables: (C) 2002 David S. Miller
[   42.883590] TCP cubic registered
[   42.883639] NET: Registered protocol family 1
[   42.883708] NET: Registered protocol family 10
[   42.883802] lo: Disabled Privacy Extensions
[   42.883899] ip6_tables: (C) 2000-2006 Netfilter Core Team
[   42.883957] IPv6 over IPv4 tunneling driver
[   42.884068] sit0: Disabled Privacy Extensions
[   42.884183] NET: Registered protocol family 17
[   42.884231] Bluetooth: L2CAP ver 2.8
[   42.884274] Bluetooth: L2CAP socket layer initialized
[   42.884320] Bluetooth: SCO (Voice Link) ver 0.5
[   42.884364] Bluetooth: SCO socket layer initialized
[   42.884426] Bluetooth: RFCOMM socket layer initialized
[   42.884483] Bluetooth: RFCOMM TTY layer initialized
[   42.884527] Bluetooth: RFCOMM ver 1.8
[   42.884577] Bluetooth: BNEP (Ethernet Emulation) ver 1.2
[   42.884622] Bluetooth: BNEP filters: protocol multicast
[   42.884666] Bluetooth: HIDP (Human Interface Emulation) ver 1.2
[   42.884752] 802.1Q VLAN Support v1.8 Ben Greear <[email protected]>
[   42.884798] All bugs added by David S. Miller <[email protected]>
[   42.884876] ieee80211: 802.11 data/management/control stack, git-1.1.13
[   42.884921] ieee80211: Copyright (C) 2004-2005 Intel Corporation <[email protected]>
[   42.884975] ieee80211_crypt: registered algorithm 'NULL'
[   42.884977] ieee80211_crypt: registered algorithm 'WEP'
[   42.884978] ieee80211_crypt: registered algorithm 'CCMP'
[   42.884980] ieee80211_crypt: registered algorithm 'TKIP'
[   42.885003] powernow-k8: Found 1 AMD Turion(tm) 64 Mobile ML-40                  processors (1 cpu cores) (version 2.00.00)
[   42.887340] powernow-k8:    0 : fid 0xe (2200 MHz), vid 0x4
[   42.887385] powernow-k8:    1 : fid 0xc (2000 MHz), vid 0x6
[   42.887430] powernow-k8:    2 : fid 0xa (1800 MHz), vid 0x8
[   42.887475] powernow-k8:    3 : fid 0x8 (1600 MHz), vid 0xa
[   42.887520] powernow-k8:    4 : fid 0x0 (800 MHz), vid 0x16
[   42.887609] powernow-k8: ph2 null fid transition 0xe
[   42.887803] drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
[   42.901199] EXT3-fs: INFO: recovery required on readonly filesystem.
[   42.901245] EXT3-fs: write access will be enabled during recovery.
[   43.235697] kjournald starting.  Commit interval 5 seconds
[   43.235761] EXT3-fs: recovery complete.
[   43.236451] EXT3-fs: mounted filesystem with ordered data mode.
[   43.236513] VFS: Mounted root (ext3 filesystem) readonly.
[   43.236571] Freeing unused kernel memory: 232k freed
[   47.801222] EXT3 FS on sda7, internal journal
[   57.795525] kjournald starting.  Commit interval 5 seconds
[   57.795970] EXT3 FS on sda8, internal journal
[   57.795974] EXT3-fs: mounted filesystem with ordered data mode.
[   57.846526] NTFS volume version 3.1.
[   57.941964] Adding 1791208k swap on /dev/sda6.  Priority:-1 extents:1 across:1791208k
[   70.223467] ADDRCONF(NETDEV_UP): eth0: link is not ready
[   71.812629] tg3: eth0: Link is up at 100 Mbps, full duplex.
[   71.812632] tg3: eth0: Flow control is on for TX and on for RX.
[   71.813280] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[   82.609570] eth0: no IPv6 routers present
[   95.264814] usb 1-5: new high speed USB device using ehci_hcd and address 5
[   95.391652] usb 1-5: configuration #1 chosen from 1 choice
[  125.202698] tifm0 : demand removing card from socket 0:3
[  125.202787] mmc3: card 0001 removed
[  125.731299] tifm_core: MMC/SD card detected in socket 0:3
[  125.766459] mmc3: new MMC card at address 0001
[  125.766880] mmcblk0: mmc3:0001 000000 62720KiB 
[  125.766948]  mmcblk0: p1
[  179.088895] APIC error on CPU0: 00(40)
[  271.819874] APIC error on CPU0: 40(40)
[  282.081037] APIC error on CPU0: 40(40)
[  468.014140] APIC error on CPU0: 40(40)
#9 lore raw
Quoted 4 lines

I switched to libata, but it behaves like the old IDE without ACPI. I did not manage to get a full dmesg (apparently all volumes are mounted r/o right after a power up from a s2ram) but I did make a picture, from which I quote (if I may say so):

Device errors.

Libata currently (wrongly IMHO) defaults to avoiding the use of ACPI suspend/resume methods

So you also need to boot with "libata.noacpi=0" and if that works beat up Jeff a bit ..

#10 lore raw
Quoted 5 lines · Alan Cox
Quoted 4 lines

I switched to libata, but it behaves like the old IDE without ACPI. I did not manage to get a full dmesg (apparently all volumes are mounted r/o right after a power up from a s2ram) but I did make a picture, from which I quote (if I may say so):

Quoted 7 lines

Device errors.

Libata currently (wrongly IMHO) defaults to avoiding the use of ACPI suspend/resume methods

So you also need to boot with "libata.noacpi=0" and if that works beat up Jeff a bit ..

You were right, 'libata.noacpi=0' does the trick :)

It's interesting my mmc is unmounted before s2ram and then mounted back on resume.

So, to sum up, I have a working suspend-to-ram with libata. Not bad, not bad at all...

Thanks,

Signature · 1 line
Mihai Donțu
#11 lore raw
In reply to Linus Torvalds
Quoted 5 lines · Linus Torvalds

From a "future behaviour" standpoint it would probably be interesting to hear whether Mihai can make his machine with not with the old IDE layer (which distributions are migrating away from) but with the ATA layer (libata) instead. It too should hopefully know about using ACPI to restore any ATA controller quirks.

It does, but it's disabled by default. libata needs to be loaded with noacpi=0.

Signature · 1 line
Matthew Garrett | [email protected]
#12 lore raw
In reply to Linus Torvalds
Quoted 32 lines · Linus Torvalds
Quoted 8 lines · Thomas Gleixner

My final enlightment was, when I removed the ACPI processor module, which controls the lower idle C-states, right before resume; this worked fine all the time even without all the workaround hacks.

I really hope that this two patches finally set an end to the "jinxed VAIO heisenbug series", which started when we removed the periodic tick with the clockevents/dyntick patches.

Ok, so the patches look fine, but I somehow have this slight feeling that you gave up a bit too soon on the "*why* does this happen?" question.

I realize that the answer is easily "because ACPI screwed up", but I'm wondering if there's something we do to trigger that screw-up.

In particular, I also suspect that this may not really fix the problem - maybe it just makes the window sufficiently small that it no longer triggers. Because we don't necessarily understand what the real background for the problem is, I'm not sure we can say that it is solved.

The reason I say this is that I have a suspicion on what triggers it.

I suspect that the problem is that we do

	pm_ops->prepare();
	disable_nonboot_cpus()
	suspend_enter();
	enable_nonboot_cpus()
	pm_finish()
Quoted 7 lines

and here the big thing to notice is that "pm_ops->prepare()" call, which sets the wakup vector etc etc.

So maybe the real problem here is that once we've done the "->prepare()" call and ACPI has set up various stuff, we MUST NOT do any calls to any ACPI routines to set low-power states, because the stupid firmware isn't expecting it.

I think that this is the case.

Quoted 10 lines

Now, if this is the cause, then I think your patch should indeed fix it, since you get called by the early-suspend code (which happens *before* the "->prepare()" call), but at the same time, I wonder if maybe it would be slightly "more correct" to instead of using the suspend/resume callbacks, simply do this in the "acpi_pm_prepare()" stage, since that is likely the thing that triggers it?

But hey, I think I'll apply the patches as-is. I'd just feel even better if we actually understood *why* doing the CPU Cx states is not something we can do around the suspend code!

Greetings,
Rafael

#13 lore raw
In reply to Linus Torvalds
Quoted 11 lines · Linus Torvalds
Quoted 7 lines · Thomas Gleixner

My final enlightment was, when I removed the ACPI processor module, which controls the lower idle C-states, right before resume; this worked fine all the time even without all the workaround hacks.

I really hope that this two patches finally set an end to the "jinxed VAIO heisenbug series", which started when we removed the periodic tick with the clockevents/dyntick patches.

Ok, so the patches look fine, but I somehow have this slight feeling that you gave up a bit too soon on the "*why* does this happen?" question.

On a closely related note: I just now submitted a patch to fix SMP-poweroff, by having it do disable_nonboot_cpus before doing poweroff.

Which has led me to thinking..
..are similar precautions perhaps necessary for *all* ACPI BIOS calls?

Because one never knows what the other CPUs are doing at the same time, and what the side effects may be on the ACPI BIOS functions.

And also, I wonder if at a minimum we should be guaranteeing ACPI BIOS calls
only ever happen from CPU#0 (or the "boot" CPU)? Or do we do that already?

-ml

#14 lore raw
Quoted 17 lines · Mark Lord
Quoted 6 lines · Linus Torvalds
Quoted 4 lines · Thomas Gleixner

My final enlightment was, when I removed the ACPI processor module, which controls the lower idle C-states, right before resume; this worked fine all the time even without all the workaround hacks.

Quoted 6 lines
Quoted 3 lines

I really hope that this two patches finally set an end to the "jinxed VAIO heisenbug series", which started when we removed the periodic tick with the clockevents/dyntick patches.

Ok, so the patches look fine, but I somehow have this slight feeling that you gave up a bit too soon on the "*why* does this happen?" question.

On a closely related note: I just now submitted a patch to fix SMP-poweroff, by having it do disable_nonboot_cpus before doing poweroff.

Quoted 8 lines

Which has led me to thinking..
..are similar precautions perhaps necessary for *all* ACPI BIOS calls?

Because one never knows what the other CPUs are doing at the same time, and what the side effects may be on the ACPI BIOS functions.

And also, I wonder if at a minimum we should be guaranteeing ACPI BIOS calls
only ever happen from CPU#0 (or the "boot" CPU)? Or do we do that already?

The ACPI calls are serialized in the kernel, AFAICT. But the fragile situations (suspend, resume, shutdown, reboot) are probably those, where some BIOS implementation expect that certain things are not called or not active.

tglx

#15 lore raw
Quoted 1 line · Thomas Gleixner

On Fri, 2007-09-28 at 16:27 -0400, Mark Lord wrote:

..

Quoted 9 lines
Quoted 9 lines

On a closely related note: I just now submitted a patch to fix SMP-poweroff, by having it do disable_nonboot_cpus before doing poweroff.

Which has led me to thinking..
..are similar precautions perhaps necessary for *all* ACPI BIOS calls?

Because one never knows what the other CPUs are doing at the same time, and what the side effects may be on the ACPI BIOS functions.

Quoted 7 lines
Quoted 2 lines

And also, I wonder if at a minimum we should be guaranteeing ACPI BIOS calls
only ever happen from CPU#0 (or the "boot" CPU)? Or do we do that already?

The ACPI calls are serialized in the kernel, AFAICT. But the fragile situations (suspend, resume, shutdown, reboot) are probably those, where some BIOS implementation expect that certain things are not called or not active.

Mmm.. *do* we actually do this for reboot? I don't see it there. And how about for kexec?

I'm probably just missing seeing it. Right?

Cheers

#16 lore raw
Quoted 20 lines · Mark Lord
Quoted 1 line · Thomas Gleixner

On Fri, 2007-09-28 at 16:27 -0400, Mark Lord wrote:

..

Quoted 9 lines
Quoted 9 lines

On a closely related note: I just now submitted a patch to fix SMP-poweroff, by having it do disable_nonboot_cpus before doing poweroff.

Which has led me to thinking..
..are similar precautions perhaps necessary for *all* ACPI BIOS calls?

Because one never knows what the other CPUs are doing at the same time, and what the side effects may be on the ACPI BIOS functions.

Quoted 7 lines
Quoted 2 lines

And also, I wonder if at a minimum we should be guaranteeing ACPI BIOS calls
only ever happen from CPU#0 (or the "boot" CPU)? Or do we do that already?

The ACPI calls are serialized in the kernel, AFAICT. But the fragile situations (suspend, resume, shutdown, reboot) are probably those, where some BIOS implementation expect that certain things are not called or not active.

Quoted 4 lines

Mmm.. *do* we actually do this for reboot? I don't see it there. And how about for kexec?

I'm probably just missing seeing it. Right?

Nope.

Till now, only hibernation and suspend disabled the nonboot CPUs before invoking the platform firmware.

Greetings,
Rafael

#17 lore raw
In reply to Mark Lord
Quoted 2 lines

And also, I wonder if at a minimum we should be guaranteeing ACPI BIOS calls
only ever happen from CPU#0 (or the "boot" CPU)? Or do we do that already?

The real question that matters is "does windows" which possibly someone who touches Windows can definitively answer. For APM we lock to CPU 0 and have to because its what MS did, not because of the spec.

#18 lore raw
In reply to Mark Lord
Quoted 16 lines · Mark Lord
Quoted 11 lines · Linus Torvalds
Quoted 7 lines · Thomas Gleixner

My final enlightment was, when I removed the ACPI processor module, which controls the lower idle C-states, right before resume; this worked fine all the time even without all the workaround hacks.

I really hope that this two patches finally set an end to the "jinxed VAIO heisenbug series", which started when we removed the periodic tick with the clockevents/dyntick patches.

Ok, so the patches look fine, but I somehow have this slight feeling that you gave up a bit too soon on the "*why* does this happen?" question.

On a closely related note: I just now submitted a patch to fix SMP-poweroff, by having it do disable_nonboot_cpus before doing poweroff.

Quoted 9 lines

Which has led me to thinking..
..are similar precautions perhaps necessary for *all* ACPI BIOS calls?

Because one never knows what the other CPUs are doing at the same time, and what the side effects may be on the ACPI BIOS functions.

And also, I wonder if at a minimum we should be guaranteeing ACPI BIOS calls
only ever happen from CPU#0 (or the "boot" CPU)? Or do we do that already?

Boot CPU, and AFAIK suspend is the only place which does it.

Signature · 3 lines
Bill Davidsen <[email protected]>
  "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot