Bizarre oops after suspend to RAM (was: Re: [ACPI] Resume from Suspend to RAM)

public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed

* Bizarre oops after suspend to RAM (was: Re: [ACPI] Resume from Suspend to RAM)
       [not found]     ` <1118053578.6648.142.camel@tyrosine>
@ 2005-06-06 11:06       ` Matthew Garrett
  2005-06-06 14:45         ` Pavel Machek
  2005-06-06 15:31         ` Stefan Dösinger
  0 siblings, 2 replies; 23+ messages in thread
From: Matthew Garrett @ 2005-06-06 11:06 UTC (permalink / raw)
  To: acpi-devel; +Cc: linux-kernel

On Mon, 2005-06-06 at 11:26 +0100, Matthew Garrett wrote:
> On Sun, 2005-06-05 at 17:32 +0000, Stefan Dösinger wrote:
> 
> > I've no idea how to debug a reboot, but if the system hangs it's possible to 
> > add "lcall $0xffff,$0" early in the wakeup assembler code. If the system 
> > reboots immediatly then, the kernels wakeup code was reached and the kernel 
> > hangs later during resume.
> 
> Ok, I've just tried that. The system still just freezes.

Whoops. May have been a bit too hasty there. I'm not sure why that
doesn't reset it, but we've now got the following (really rather odd)
serial output. Does anyone have any idea what might be triggering this?
Shell builtins work fine, but anything else seems to explode very
messily. Memory corruption of some description?

^MRestarting tasks... done
^Mroot@(none):/# ^M
root@(none):/# ls -la ^M
Unable to handle kernel NULL pointer dereference at virtual address 00000024
^M printing eip:
^Mc015ac62
^M*pde = 00000000
^MOops: 0002 [#1]
^MPREEMPT
^MModules linked in:
^MCPU:    0
^MEIP:    0060:[<c015ac62>]    Not tainted VLI
^MEFLAGS: 00010246   (2.6.12-rc5)
^MEIP is at filp_open+0x32/0x70
^Meax: f7ccb000   ebx: 00000000   ecx: 00000003   edx: 00000000
^Mesi: 00000000   edi: f7ccb000   ebp: f7c5c000   esp: f7c5df48
^Mds: 007b   es: 007b   ss: 0068
^MProcess ls (pid: 875, threadinfo=f7c5c000 task=c1bbc060)
^MStack: 00000000 00000001 c015a5d5 f7c5df58 00000000 c0109806 fffffeff 00000000^M       c1bcf1ec 00000000 f7ccb000 00000003 c18c0c80 f7c5c000 c015af95 c18c0c80^M       00000003 00000003 f7ccb000 00000000 00000003 c015b109 f7ccb000 00000000^MCall Trace:
^M [<c015a5d5>] sys_access+0x85/0x150
^M [<c0109806>] old_mmap+0xd6/0x110
^M [<c015af95>] get_unused_fd+0xa5/0xe0
^M [<c015b109>] sys_open+0x49/0x90
^M [<c0103245>] syscall_call+0x7/0xb
^MCode: 8b 5c 24 5c 8d 43 01 a8 03 0f 44 c3 89 c2 83 ca 02 f6 c4 02 0f 45 c2 8d
54 24 10 89 54 24 0c 8b 54 24 60 89 44 24 04 8b 44 24 58 <89> 56 24 08 89 04 24
e8 62 19 01 00 85 c0 74 0e 8b 5c 24 50 83
^M Segmentation fault^M
root@(none):/# ^M
root@(none):/# free^M
<1>Unable to handle kernel NULL pointer dereference at virtual address 00000024
^M printing eip:
^Mc015ac62
^M*pde = 00000000
^MOops: 0002 [#2]
^MPREEMPT
^MModules linked in:
^MCPU:    0
^MEIP:    0060:[<c015ac62>]    Not tainted VLI
^MEFLAGS: 00010246   (2.6.12-rc5)
^MEIP is at filp_open+0x32/0x70
^Meax: f7ce3000   ebx: 00000000   ecx: 00000003   edx: 00000000
^Mesi: 00000000   edi: f7ce3000   ebp: f7c5c000   esp: f7c5df48
^Mds: 007b   es: 007b   ss: 0068
^MProcess free (pid: 876, threadinfo=f7c5c000 task=c1bbc560)
^MStack: 00000000 00000001 c015a5d5 f7c5df58 00000000 c0109806 fffffeff 00000000^M       c1bcf1ec 00000000 f7ce3000 00000003 c18c0040 f7c5c000 c015af95 c18c0040^M       00000003 00000003 f7ce3000 00000000 00000003 c015b109 f7ce3000 00000000^MCall Trace:
^M [<c015a5d5>] sys_access+0x85/0x150
^M [<c0109806>] old_mmap+0xd6/0x110
^M [<c015af95>] get_unused_fd+0xa5/0xe0
^M [<c015b109>] sys_open+0x49/0x90
^M [<c0103245>] syscall_call+0x7/0xb
^MCode: 8b 5c 24 5c 8d 43 01 a8 03 0f 44 c3 89 c2 83 ca 02 f6 c4 02 0f 45 c2 8d
54 24 10 89 54 24 0c 8b 54 24 60 89 44 24 04 8b 44 24 58 <89> 56 24 08 89 04 24
e8 62 19 01 00 85 c0 74 0e 8b 5c 24 50 83
^M Segmentation fault^M


-- 
Matthew Garrett | mjg59@srcf.ucam.org


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Bizarre oops after suspend to RAM (was: Re: [ACPI] Resume from Suspend to RAM)
  2005-06-06 11:06       ` Bizarre oops after suspend to RAM (was: Re: [ACPI] Resume from Suspend to RAM) Matthew Garrett
@ 2005-06-06 14:45         ` Pavel Machek
  2005-06-06 14:54           ` Matthew Garrett
  2005-06-06 15:31         ` Stefan Dösinger
  1 sibling, 1 reply; 23+ messages in thread
From: Pavel Machek @ 2005-06-06 14:45 UTC (permalink / raw)
  To: Matthew Garrett; +Cc: acpi-devel, linux-kernel

Hi!

> > > I've no idea how to debug a reboot, but if the system hangs it's possible to 
> > > add "lcall $0xffff,$0" early in the wakeup assembler code. If the system 
> > > reboots immediatly then, the kernels wakeup code was reached and the kernel 
> > > hangs later during resume.
> > 
> > Ok, I've just tried that. The system still just freezes.
> 
> Whoops. May have been a bit too hasty there. I'm not sure why that
> doesn't reset it, but we've now got the following (really rather odd)
> serial output. Does anyone have any idea what might be triggering this?
> Shell builtins work fine, but anything else seems to explode very
> messily. Memory corruption of some description?
> 
> ^MRestarting tasks... done
> ^Mroot@(none):/# ^M
> root@(none):/# ls -la ^M
> Unable to handle kernel NULL pointer dereference at virtual address
> > > 00000024

NULL pointer dereference in filp_open; whats that strange about it?
Use printks to debug this one, nothing mysterious.
								Pavel


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Bizarre oops after suspend to RAM (was: Re: [ACPI] Resume from Suspend to RAM)
  2005-06-06 14:45         ` Pavel Machek
@ 2005-06-06 14:54           ` Matthew Garrett
  2005-06-06 15:09             ` Pavel Machek
  0 siblings, 1 reply; 23+ messages in thread
From: Matthew Garrett @ 2005-06-06 14:54 UTC (permalink / raw)
  To: Pavel Machek; +Cc: acpi-devel, linux-kernel

On Mon, Jun 06, 2005 at 04:45:01PM +0200, Pavel Machek wrote:

> NULL pointer dereference in filp_open; whats that strange about it?
> Use printks to debug this one, nothing mysterious.

I can't see any way that a null pointer could get to filp_open without 
something already being very wrong - the kernel worked fine before 
suspend. Unfortunately, that's the one occasion that we've got the 
machine (an HP nc4000) to resume. Since then, it simply freezes before 
hitting "Back to C" despite having had no kernel or configuration 
changes. The behaviour is very non-deterministic, which makes me wonder 
about something in the suspend or resume process damaging state.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Bizarre oops after suspend to RAM (was: Re: [ACPI] Resume from Suspend to RAM)
  2005-06-06 14:54           ` Matthew Garrett
@ 2005-06-06 15:09             ` Pavel Machek
  2005-06-07 14:14               ` Martin Michlmayr
  0 siblings, 1 reply; 23+ messages in thread
From: Pavel Machek @ 2005-06-06 15:09 UTC (permalink / raw)
  To: Matthew Garrett; +Cc: acpi-devel, linux-kernel

Hi!

> > NULL pointer dereference in filp_open; whats that strange about it?
> > Use printks to debug this one, nothing mysterious.
> 
> I can't see any way that a null pointer could get to filp_open without 
> something already being very wrong - the kernel worked fine before 
> suspend. Unfortunately, that's the one occasion that we've got the 
> machine (an HP nc4000) to resume. Since then, it simply freezes before 
> hitting "Back to C" despite having had no kernel or configuration 
> changes. The behaviour is very non-deterministic, which makes me wonder 
> about something in the suspend or resume process damaging state.

Hmm, strange. You may want to test if length of sleep affects it...

									Pavel

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Bizarre oops after suspend to RAM (was: Re: [ACPI] Resume from Suspend to RAM)
  2005-06-06 15:09             ` Pavel Machek
@ 2005-06-07 14:14               ` Martin Michlmayr
  0 siblings, 0 replies; 23+ messages in thread
From: Martin Michlmayr @ 2005-06-07 14:14 UTC (permalink / raw)
  To: Pavel Machek; +Cc: Matthew Garrett, acpi-devel, linux-kernel

* Pavel Machek <pavel@ucw.cz> [2005-06-06 15:10]:
> > machine (an HP nc4000) to resume. Since then, it simply freezes before 
> > hitting "Back to C" despite having had no kernel or configuration 
> > changes. The behaviour is very non-deterministic, which makes me wonder 
> > about something in the suspend or resume process damaging state.
> 
> Hmm, strange. You may want to test if length of sleep affects it...

I tried to resume immediately when the screen goes blank and got the
following results.  Out of 9 trials I got:

 - 4x: it would say "Restarting tasks..." but then oops and hang
   immediately.  See the oops below.
 - 4x: come back and give me a shell - but it hangs
 - 1x: come back, give me a shell and let me type; built-ins worked
   but commands produced the oops posted by Matthew a few days ago.

So far it has never come back when I don't resume immediately.

The new oops I got is:

root@(none):/# mount -t proc none /proc
root@(none):/# echo 3 > /proc/acpi/sleep
Stopping tasks: ===|
    ACPI-0286: *** Error: No installed handler for fixed event [00000002]
Restarting tasks... done
Unable to handle kernel paging request at virtual address 00008265
 printing eip:
c015ac62
*pde = 00000000
Oops: 0002 [#2]
PREEMPT
Modules linked in:
CPU:    0
EIP:    0060:[<c015ac62>]    Not tainted VLI
EFLAGS: 00010202   (2.6.12-rc5)
EIP is at filp_open+0x32/0x70
eax: f7c7a000   ebx: 00008241   ecx: 00000003   edx: 00000180
esi: 00008241   edi: f7c7a000   ebp: c191c000   esp: c191df48
ds: 007b   es: 007b   ss: 0068
Process bash (pid: 1, threadinfo=c191c000 task=c18bfa20)
Stack: bfeafcf4 00008242 c191df64 c191df58 c016690b 080f1f48 c191df64 c191df6c
       00000014 00000000 f7c7a000 00000003 c18c0e40 c191c000 c015af95 c18c0e40
       00000003 00000003 f7c7a000 00008241 00000003 c015b109 f7c7a000 00008241
Call Trace:
 [<c016690b>] sys_stat64+0x1b/0x40
 [<c015af95>] get_unused_fd+0xa5/0xe0
 [<c015b109>] sys_open+0x49/0x90
 [<c0103245>] syscall_call+0x7/0xb
Code: 8b 5c 24 5c 8d 43 01 a8 03 0f 44 c3 89 c2 83 ca 02 f6 c4 02 0f 45 c2 8d 54 24 10 89 54 24 0c 8b 54 24 60 89 44 24 04 8b 44 24 58 <89> 56 24 08 89 04 24 e8 62 19 01 00 85 c0 74 0e 8b 5c 24 50 83
 <0>Kernel panic - not syncing: Attempted to kill init!

-- 
Martin Michlmayr
http://www.cyrius.com/

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Bizarre oops after suspend to RAM (was: Re: [ACPI] Resume from Suspend to RAM)
  2005-06-06 11:06       ` Bizarre oops after suspend to RAM (was: Re: [ACPI] Resume from Suspend to RAM) Matthew Garrett
  2005-06-06 14:45         ` Pavel Machek
@ 2005-06-06 15:31         ` Stefan Dösinger
  2005-06-07  6:23           ` S3 test tool (was : Re: Bizarre oops after suspend to RAM (was: Re: [ACPI] Resume from Suspend to RAM)) Shaohua Li
  1 sibling, 1 reply; 23+ messages in thread
From: Stefan Dösinger @ 2005-06-06 15:31 UTC (permalink / raw)
  To: acpi-devel; +Cc: Matthew Garrett, linux-kernel

Am Montag, 6. Juni 2005 11:06 schrieb Matthew Garrett:
> Whoops. May have been a bit too hasty there. I'm not sure why that
> doesn't reset it, but we've now got the following (really rather odd)
> serial output. Does anyone have any idea what might be triggering this?
> Shell builtins work fine, but anything else seems to explode very
> messily. Memory corruption of some description?

<snip>
So it does reach the kernel, right? I don't know if I remembered that call 
correctly, but "lcall $0xffff,$0" should call the real mode BIOS reset 
code...
Anyone else who can correct me here?

Perhaps the disk driver is going mad? Has anyone tried to boot a kernel 
without any disk drivers with a minimal root system on an initrd?

Cheers,
Stefan

^ permalink raw reply	[flat|nested] 23+ messages in thread

* S3 test tool (was : Re: Bizarre oops after suspend to RAM (was: Re: [ACPI] Resume from Suspend to RAM))
  2005-06-06 15:31         ` Stefan Dösinger
@ 2005-06-07  6:23           ` Shaohua Li
  2005-06-07 12:07             ` Martin Michlmayr
  2005-06-14  7:25             ` dagit
  0 siblings, 2 replies; 23+ messages in thread
From: Shaohua Li @ 2005-06-07  6:23 UTC (permalink / raw)
  To: stefandoesinger; +Cc: acpi-dev, Matthew Garrett, lkml, Pavel Machek

On Mon, 2005-06-06 at 23:31 +0800, stefandoesinger@gmx.at wrote:
> Am Montag, 6. Juni 2005 11:06 schrieb Matthew Garrett: 
> > Whoops. May have been a bit too hasty there. I'm not sure why that 
> > doesn't reset it, but we've now got the following (really rather
> odd) 
> > serial output. Does anyone have any idea what might be triggering
> this? 
> > Shell builtins work fine, but anything else seems to explode very 
> > messily. Memory corruption of some description?
> 
> <snip> 
> So it does reach the kernel, right? I don't know if I remembered that
> call  
> correctly, but "lcall $0xffff,$0" should call the real mode BIOS
> reset  
> code... 
> Anyone else who can correct me here?
> 
> Perhaps the disk driver is going mad? Has anyone tried to boot a
> kernel  
> without any disk drivers with a minimal root system on an initrd?
For those who suffer from strange S3 resume problem such as resume hang,
could you please try this debug patch.
It uses machine_real_restart to switch to real mode, and soon jump to
the S3 wakeup address. So it simulates how BIOS resume a system from S3,
but completely bypasses BIOS. If the system lives after S3 with the
patch, at least we can know the suspend/resume code path is ok and it's
not a Linux driver issue.

Thanks,
Shaohua

--- a/drivers/acpi/hardware/hwsleep.c	2005-06-07 13:45:04.088273424 +0800
+++ b/drivers/acpi/hardware/hwsleep.c	2005-06-07 13:49:31.858566152 +0800
@@ -242,6 +242,19 @@ acpi_enter_sleep_state_prep (
  *              THIS FUNCTION MUST BE CALLED WITH INTERRUPTS DISABLED
  *
  ******************************************************************************/
+#define S3_DEBUG
+#ifdef S3_DEBUG
+#include <asm/io.h>
+extern void machine_real_restart(unsigned char *code, int length);
+static unsigned char jump_to_pm [] =
+{
+	0xea,
+	0x00,
+	0x00,
+	0x00,
+	0x00		/*    ljmp  $0x0000,$0x0000  */
+};
+#endif
 
 acpi_status asmlinkage
 acpi_enter_sleep_state (
@@ -315,6 +328,14 @@ acpi_enter_sleep_state (
 	PM1Acontrol |= (acpi_gbl_sleep_type_a << sleep_type_reg_info->bit_position);
 	PM1Bcontrol |= (acpi_gbl_sleep_type_b << sleep_type_reg_info->bit_position);
 
+#ifdef S3_DEBUG
+	if (sleep_state == ACPI_STATE_S3) {
+		*((short *)&jump_to_pm[3]) =
+			(short)(virt_to_phys((void *)acpi_wakeup_address)) >> 4;
+		/* Directly jump to acpi_wakeup_address */
+		machine_real_restart(jump_to_pm, sizeof(jump_to_pm));
+	}
+#endif
 	/*
 	 * We split the writes of SLP_TYP and SLP_EN to workaround
 	 * poorly implemented hardware.



^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: S3 test tool (was : Re: Bizarre oops after suspend to RAM (was: Re: [ACPI] Resume from Suspend to RAM))
  2005-06-07  6:23           ` S3 test tool (was : Re: Bizarre oops after suspend to RAM (was: Re: [ACPI] Resume from Suspend to RAM)) Shaohua Li
@ 2005-06-07 12:07             ` Martin Michlmayr
  2005-06-14  7:25             ` dagit
  1 sibling, 0 replies; 23+ messages in thread
From: Martin Michlmayr @ 2005-06-07 12:07 UTC (permalink / raw)
  To: Shaohua Li; +Cc: stefandoesinger, acpi-dev, Matthew Garrett, lkml, Pavel Machek

* Shaohua Li <shaohua.li@intel.com> [2005-06-07 14:23]:
> For those who suffer from strange S3 resume problem such as resume hang,
> could you please try this debug patch.

This works on a HP Compaq nc4000 which previously never comes back
from resume (except for one time in which case the kernel oopsed in a
strange way, as posted by Matthew the other day).  I see a yellow
'Linu' on the screen, then I hear the hard drive spinning up, the
screen comes back and I see 'Restarting tasks... done' on the serial
console.  (this is with init=/bin/bash console=ttyS0)
-- 
Martin Michlmayr
http://www.cyrius.com/

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: S3 test tool (was : Re: Bizarre oops after suspend to RAM (was: Re: [ACPI] Resume from Suspend to RAM))
  2005-06-07  6:23           ` S3 test tool (was : Re: Bizarre oops after suspend to RAM (was: Re: [ACPI] Resume from Suspend to RAM)) Shaohua Li
  2005-06-07 12:07             ` Martin Michlmayr
@ 2005-06-14  7:25             ` dagit
  2005-06-14  8:47               ` Matthew Garrett
  2005-06-14  9:06               ` Pavel Machek
  1 sibling, 2 replies; 23+ messages in thread
From: dagit @ 2005-06-14  7:25 UTC (permalink / raw)
  To: Shaohua Li; +Cc: stefandoesinger, acpi-dev, Matthew Garrett, lkml, Pavel Machek

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

Shaohua Li <shaohua.li@intel.com> writes:

> On Mon, 2005-06-06 at 23:31 +0800, stefandoesinger@gmx.at wrote:
>> Am Montag, 6. Juni 2005 11:06 schrieb Matthew Garrett: 
>> > Whoops. May have been a bit too hasty there. I'm not sure why that 
>> > doesn't reset it, but we've now got the following (really rather
>> odd) 
>> > serial output. Does anyone have any idea what might be triggering
>> this? 
>> > Shell builtins work fine, but anything else seems to explode very 
>> > messily. Memory corruption of some description?
>> 
>> <snip> 
>> So it does reach the kernel, right? I don't know if I remembered that
>> call  
>> correctly, but "lcall $0xffff,$0" should call the real mode BIOS
>> reset  
>> code... 
>> Anyone else who can correct me here?
>> 
>> Perhaps the disk driver is going mad? Has anyone tried to boot a
>> kernel  
>> without any disk drivers with a minimal root system on an initrd?
> For those who suffer from strange S3 resume problem such as resume hang,
> could you please try this debug patch.
> It uses machine_real_restart to switch to real mode, and soon jump to
> the S3 wakeup address. So it simulates how BIOS resume a system from S3,
> but completely bypasses BIOS. If the system lives after S3 with the
> patch, at least we can know the suspend/resume code path is ok and it's
> not a Linux driver issue.

If you've looked at this bug you will know that myself at and atleast
one other person experience a reboot on resume at a specific line in
the wakeup code:
http://bugme.osdl.org/show_bug.cgi?id=3586

One note about the code in the bug, my code for detecting PM is
backwards, so ignore it, what I say in this email is still valid.

Specifically, if I get rid of the pushl;popl then the computer does
not reboot.  See the attached diff.  The question is 1) is this
pushl;popl the final nail in the coffin? 2) Does windows not clear the
flags completely, but instead sets them to some "special value"?

The reason for (1) is because as I understand it, when a certain
number of illegal operations (3 iirc) are issued at certain times
(real mode iirc) the machine automatically reboots.  That could be
what we are seeing here.

The reason for (2) is because if I remove the pushl;popl, boot into
windows suspend/resume, and immeditaly boot into linux then the
suspend/resume works.  I have screen blanking issues, but I can type
blindly and the commands all work just fine (I can startx for
example).

Also, what flags are being cleared?  What is their meaning?  Can you
or someone on this list point me to the approriate documentation?  I'd
love to look at it and try to understand my hardware better.

I would encourage others following this thread to try my patch and
the the trick of doing a suspend/resume in windows followed by a
reboot into linux where you try suspend/resume.

Thanks,
Jason

[-- Attachment #2: patch-popl.diff --]
[-- Type: text/plain, Size: 484 bytes --]

--- /home/dagit/kernels/linux-2.6.12-rc6/arch/i386/kernel/acpi/wakeup.S	2005-03-01 23:37:49.000000000 -0800
+++ arch/i386/kernel/acpi/wakeup.S	2005-06-13 23:24:30.000000000 -0700
@@ -34,8 +34,8 @@
 	mov	$(wakeup_stack - wakeup_code), %sp		# Private stack is needed for ASUS board
 	movw	$0x0e00 + 'S', %fs:(0x12)

-	pushl	$0						# Kill any dangerous flags
-	popfl
+#	pushl	$0						# Kill any dangerous flags
+#	popfl

 	movl	real_magic - wakeup_code, %eax
 	cmpl	$0x12345678, %eax

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: S3 test tool (was : Re: Bizarre oops after suspend to RAM (was: Re: [ACPI] Resume from Suspend to RAM))
  2005-06-14  7:25             ` dagit
@ 2005-06-14  8:47               ` Matthew Garrett
  2005-06-14 16:24                 ` dagit
  2005-06-14  9:06               ` Pavel Machek
  1 sibling, 1 reply; 23+ messages in thread
From: Matthew Garrett @ 2005-06-14  8:47 UTC (permalink / raw)
  To: dagit; +Cc: Shaohua Li, stefandoesinger, acpi-dev, lkml, Pavel Machek

On Tue, 2005-06-14 at 00:25 -0700, dagit@codersbase.com wrote:

> The reason for (2) is because if I remove the pushl;popl, boot into
> windows suspend/resume, and immeditaly boot into linux then the
> suspend/resume works.  I have screen blanking issues, but I can type
> blindly and the commands all work just fine (I can startx for
> example).

Can you do a lspci -vxxx

a) After a cold boot into linux
b) After a warm boot into linux from Windows

and see if there's any difference between the two?

-- 
Matthew Garrett | mjg59@srcf.ucam.org


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: S3 test tool (was : Re: Bizarre oops after suspend to RAM (was: Re: [ACPI] Resume from Suspend to RAM))
  2005-06-14  8:47               ` Matthew Garrett
@ 2005-06-14 16:24                 ` dagit
  2005-06-17 13:16                   ` Matthew Garrett
  0 siblings, 1 reply; 23+ messages in thread
From: dagit @ 2005-06-14 16:24 UTC (permalink / raw)
  To: Matthew Garrett; +Cc: Shaohua Li, stefandoesinger, acpi-dev, lkml, Pavel Machek

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

Matthew Garrett <mjg59@srcf.ucam.org> writes:

> On Tue, 2005-06-14 at 00:25 -0700, dagit@codersbase.com wrote:
>
>> The reason for (2) is because if I remove the pushl;popl, boot into
>> windows suspend/resume, and immeditaly boot into linux then the
>> suspend/resume works.  I have screen blanking issues, but I can type
>> blindly and the commands all work just fine (I can startx for
>> example).
>
> Can you do a lspci -vxxx
>
> a) After a cold boot into linux
> b) After a warm boot into linux from Windows

Sure thing, (a) is called lspci-coldboot.txt and the other is
lspci-warmboot.txt.  I've attached them so that you can see the whole
thing, it doesn't look very helpful to me and the diff was even more
cryptic, so good luck ;)

Thanks,
Jason


[-- Attachment #2: lspci-coldboot.txt --]
[-- Type: text/plain, Size: 16231 bytes --]

0000:00:00.0 Host bridge: VIA Technologies, Inc. VT8378 [KM400] Chipset Host Bridge
	Subsystem: VIA Technologies, Inc.: Unknown device 0000
	Flags: bus master, 66MHz, medium devsel, latency 8
	Memory at e0000000 (32-bit, prefetchable) [size=64M]
	Capabilities: [80] AGP version 3.5
	Capabilities: [c0] Power Management version 2
00: 06 11 05 32 06 00 30 22 00 00 00 06 00 08 00 00
10: 08 00 00 e0 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 06 11 00 00
30: 00 00 00 00 80 00 00 00 00 00 00 00 00 00 00 00
40: 00 19 88 80 82 44 01 04 1b 99 88 80 82 44 01 00
50: 08 00 00 80 60 85 20 20 e0 01 10 20 20 20 20 20
60: 40 aa aa 20 66 99 c1 30 44 6d 54 d8 81 43 00 00
70: 82 c8 00 01 60 8f 11 00 81 00 00 00 00 00 00 02
80: 02 c0 35 00 04 0a 00 1f 00 00 00 00 00 00 00 00
90: 80 01 00 00 30 0f 01 00 00 00 ee 1c 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 21 98 00 00
b0: c0 9b 01 96 26 00 00 02 46 00 00 01 f0 8a fd 0c
c0: 01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 16 f4 79 ea 07 1c f1 19 72 ff 00 00 61 72 75 01
e0: 81 dd 66 04 20 ff c1 00 a6 87 bb 00 02 96 33 40
f0: 00 01 20 20 08 00 84 00 00 03 f0 08 00 04 00 00

0000:00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI Bridge (prog-if 00 [Normal decode])
	Flags: bus master, 66MHz, medium devsel, latency 0
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
	Memory behind bridge: dde00000-dfefffff
	Prefetchable memory behind bridge: d5d00000-ddcfffff
	Capabilities: [80] Power Management version 2
00: 06 11 98 b1 07 01 30 02 00 00 04 06 00 00 01 00
10: 00 00 00 00 00 00 00 00 00 01 01 00 f0 00 20 a2
20: e0 dd e0 df d0 d5 c0 dd 00 00 00 00 00 00 00 00
30: 00 00 00 00 80 00 00 00 00 00 00 00 00 00 0c 00
40: 81 c0 80 44 35 72 98 b1 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 02 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 00 00 00 00 00 00 00 00

0000:00:09.0 Network controller: RaLink Ralink RT2500 802.11 Cardbus Reference Card (rev 01)
	Subsystem: Micro-Star International Co., Ltd.: Unknown device 6833
	Flags: bus master, slow devsel, latency 32, IRQ 11
	Memory at dfffe000 (32-bit, non-prefetchable) [size=8K]
	Capabilities: [40] Power Management version 2
00: 14 18 01 02 17 00 10 04 01 00 80 02 08 20 00 00
10: 00 e0 ff df 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 01 06 00 00 62 14 33 68
30: 00 00 00 00 40 00 00 00 00 00 00 00 0b 01 00 00
40: 01 00 02 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 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

0000:00:0a.0 CardBus bridge: O2 Micro, Inc. OZ6912 Cardbus Controller
	Subsystem: TWINHEAD INTERNATIONAL Corp: Unknown device c602
	Flags: bus master, slow devsel, latency 64, IRQ 255
	Memory at 1e000000 (32-bit, non-prefetchable) [size=4K]
	Bus: primary=00, secondary=02, subordinate=05, sec-latency=176
	I/O window 0: 00000000-00000003
	I/O window 1: 00000000-00000003
	16-bit legacy interface ports at 0001
00: 17 12 72 69 07 00 10 04 00 00 07 06 00 40 02 00
10: 00 00 00 1e a0 00 00 02 00 02 05 b0 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00
30: 01 00 00 00 01 00 00 00 01 00 00 00 ff 01 80 00
40: ff 14 02 c6 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: 00 00 00 00 00 00 00 00 00 00 00 00 82 18 8c 01
90: 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 01 00 02 fe 00 41 c0 09 00 00 00 00 09 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 40 00 08 ea 03 82 02 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

0000:00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 80) (prog-if 00 [UHCI])
	Subsystem: TWINHEAD INTERNATIONAL Corp: Unknown device c905
	Flags: bus master, medium devsel, latency 32, IRQ 7
	I/O ports at e400 [size=32]
	Capabilities: [80] Power Management version 2
00: 06 11 38 30 17 00 10 02 80 00 03 0c 08 20 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 01 e4 00 00 00 00 00 00 00 00 00 00 ff 14 05 c9
30: 00 00 00 00 80 00 00 00 00 00 00 00 07 01 00 00
40: 40 12 03 00 00 00 00 00 00 0b 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: 01 00 c2 ff 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 20 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 03 00 00 00 00 00 00 00 00

0000:00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 80) (prog-if 00 [UHCI])
	Subsystem: TWINHEAD INTERNATIONAL Corp: Unknown device c905
	Flags: bus master, medium devsel, latency 32, IRQ 7
	I/O ports at e800 [size=32]
	Capabilities: [80] Power Management version 2
00: 06 11 38 30 17 00 10 02 80 00 03 0c 08 20 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 01 e8 00 00 00 00 00 00 00 00 00 00 ff 14 05 c9
30: 00 00 00 00 80 00 00 00 00 00 00 00 07 02 00 00
40: 40 12 03 00 00 00 00 00 00 0b 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: 01 00 c2 ff 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 20 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 03 00 00 00 00 00 00 00 00

0000:00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 80) (prog-if 00 [UHCI])
	Subsystem: TWINHEAD INTERNATIONAL Corp: Unknown device c905
	Flags: bus master, medium devsel, latency 32, IRQ 7
	I/O ports at ec00 [size=32]
	Capabilities: [80] Power Management version 2
00: 06 11 38 30 17 00 10 02 80 00 03 0c 08 20 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 01 ec 00 00 00 00 00 00 00 00 00 00 ff 14 05 c9
30: 00 00 00 00 80 00 00 00 00 00 00 00 07 03 00 00
40: 40 12 03 00 00 00 00 00 00 0b 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: 01 00 c2 ff 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 20 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 03 00 00 00 00 00 00 00 00

0000:00:10.3 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 82) (prog-if 20 [EHCI])
	Subsystem: TWINHEAD INTERNATIONAL Corp: Unknown device c905
	Flags: bus master, medium devsel, latency 32, IRQ 7
	Memory at dfffdf00 (32-bit, non-prefetchable) [size=256]
	Capabilities: [80] Power Management version 2
00: 06 11 04 31 17 00 10 02 82 20 03 0c 10 20 00 00
10: 00 df ff df 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 ff 14 05 c9
30: 00 00 00 00 80 00 00 00 00 00 00 00 07 04 00 00
40: 00 00 03 00 00 00 00 00 80 20 00 09 00 00 00 00
50: 00 5a 00 80 00 00 00 00 04 0b 66 88 33 66 00 00
60: 20 20 01 00 00 00 00 00 01 00 00 00 00 00 08 c0
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 01 00 c2 ff 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 03 00 00 00 00 00 00 00 00

0000:00:11.0 ISA bridge: VIA Technologies, Inc. VT8235 ISA Bridge
	Subsystem: VIA Technologies, Inc.: Unknown device 0000
	Flags: bus master, stepping, medium devsel, latency 0
	Capabilities: [c0] Power Management version 2
00: 06 11 77 31 87 00 10 02 00 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 06 11 00 00
30: 00 00 00 00 c0 00 00 00 00 00 00 00 00 00 00 00
40: 44 00 f8 0b 00 00 00 00 0c 20 00 00 44 00 08 08
50: 01 18 08 00 00 b0 a0 70 02 9c ff 01 00 00 04 08
60: 00 00 00 00 10 00 02 04 00 00 00 00 00 00 00 00
70: 06 11 00 00 00 00 00 00 00 00 00 00 20 00 00 00
80: 20 84 49 00 02 10 00 00 01 08 00 00 04 18 00 00
90: 00 10 bf 00 b0 c5 02 00 10 80 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: 01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 01 04 01 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 04 00 01 01 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 05 00 00 00 00 00 00 00 00 00

0000:00:11.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) (prog-if 8a [Master SecP PriP])
	Subsystem: TWINHEAD INTERNATIONAL Corp: Unknown device 1205
	Flags: bus master, medium devsel, latency 32, IRQ 255
	I/O ports at fc00 [size=16]
	Capabilities: [c0] Power Management version 2
00: 06 11 71 05 07 00 90 02 06 8a 01 01 00 20 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 01 fc 00 00 00 00 00 00 00 00 00 00 ff 14 05 12
30: 00 00 00 00 c0 00 00 00 00 00 00 00 ff 01 00 00
40: 0b f2 09 05 18 1c c0 00 a8 20 a8 20 ff 00 20 20
50: 07 e6 07 e1 0c 00 00 00 a8 a8 a8 a8 00 00 00 00
60: 00 02 00 00 00 00 00 00 00 02 00 00 00 00 00 00
70: 02 01 00 00 00 00 00 00 02 01 00 00 00 00 00 00
80: 00 10 51 01 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: 01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 06 00 71 05 ff 14 05 12 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 07 00 00 00 00 00 00 00 00 00

0000:00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 50)
	Subsystem: TWINHEAD INTERNATIONAL Corp: Unknown device 0408
	Flags: medium devsel, IRQ 10
	I/O ports at dc00 [size=256]
	Capabilities: [c0] Power Management version 2
00: 06 11 59 30 01 00 10 02 50 00 01 04 00 00 00 00
10: 01 dc 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 ff 14 08 04
30: 00 00 00 00 c0 00 00 00 00 00 00 00 0a 03 00 00
40: 05 cc 00 00 c0 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: 01 00 02 06 00 00 00 00 00 00 00 00 00 00 00 00
d0: 01 00 02 06 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

0000:00:11.6 Communication controller: VIA Technologies, Inc. Intel 537 [AC97 Modem] (rev 80)
	Subsystem: TWINHEAD INTERNATIONAL Corp: Unknown device 1005
	Flags: medium devsel, IRQ 10
	I/O ports at e000 [size=256]
	Capabilities: [d0] Power Management version 2
00: 06 11 68 30 01 00 10 02 80 00 80 07 00 00 00 00
10: 01 e0 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 ff 14 05 10
30: 00 00 00 00 d0 00 00 00 00 00 00 00 0a 03 00 00
40: 05 cc 00 00 c0 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: 01 00 02 06 00 00 00 00 00 00 00 00 00 00 00 00
d0: 01 00 02 06 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

0000:00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 74)
	Subsystem: TWINHEAD INTERNATIONAL Corp: Unknown device 0207
	Flags: bus master, medium devsel, latency 32, IRQ 11
	I/O ports at d800 [size=256]
	Memory at dfffde00 (32-bit, non-prefetchable) [size=256]
	Capabilities: [40] Power Management version 2
00: 06 11 65 30 17 00 10 02 74 00 00 02 08 20 00 00
10: 01 d8 00 00 00 de ff df 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 ff 14 07 02
30: 00 00 00 00 40 00 00 00 00 00 00 00 0b 01 03 08
40: 01 00 02 fe 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 02
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 00 00 00 00 00 00 00 00

0000:01:00.0 VGA compatible controller: VIA Technologies, Inc. VT8378 [S3 UniChrome] Integrated Video (rev 01) (prog-if 00 [VGA])
	Subsystem: TWINHEAD INTERNATIONAL Corp: Unknown device 030d
	Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 11
	Memory at d8000000 (32-bit, prefetchable) [size=64M]
	Memory at de000000 (32-bit, non-prefetchable) [size=16M]
	Expansion ROM at dfef0000 [disabled] [size=64K]
	Capabilities: [60] Power Management version 2
	Capabilities: [70] AGP version 2.0
00: 06 11 05 72 07 00 30 02 01 00 00 03 00 20 00 00
10: 08 00 00 d8 00 00 00 de 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 ff 14 0d 03
30: 00 00 ef df 60 00 00 00 00 00 00 00 0b 01 02 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: 01 70 22 06 00 00 00 00 00 00 00 00 00 00 00 00
70: 02 00 20 00 07 02 00 1f 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 00 00 00 00 00 00 00 00


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

0000:00:00.0 Host bridge: VIA Technologies, Inc. VT8378 [KM400] Chipset Host Bridge
	Subsystem: VIA Technologies, Inc.: Unknown device 0000
	Flags: bus master, 66MHz, medium devsel, latency 8
	Memory at e0000000 (32-bit, prefetchable) [size=64M]
	Capabilities: [80] AGP version 3.5
	Capabilities: [c0] Power Management version 2
00: 06 11 05 32 06 00 30 22 00 00 00 06 00 08 00 00
10: 08 00 00 e0 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 06 11 00 00
30: 00 00 00 00 80 00 00 00 00 00 00 00 00 00 00 00
40: 00 19 88 80 82 44 01 04 1b 99 88 80 82 44 01 00
50: 08 00 00 80 60 85 20 20 e0 01 10 20 20 20 20 20
60: 40 aa aa 20 66 99 c1 11 4f 6d 54 d8 81 47 00 00
70: 82 c8 00 01 60 8f 11 00 81 00 00 00 00 00 00 02
80: 02 c0 35 00 04 0a 00 1f 00 00 00 00 00 00 00 00
90: 80 01 00 00 30 0f 01 00 00 00 0a 1d 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 21 98 00 00
b0: c0 9b 01 96 26 00 00 02 46 00 00 01 f0 8a fd 0c
c0: 01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 16 f4 79 ea 07 1c f1 19 72 ff 00 00 61 72 75 01
e0: 81 dd 66 04 20 ff c1 00 a6 87 bb 00 02 96 33 40
f0: 00 01 20 20 08 00 84 00 00 03 f0 08 00 04 00 00

0000:00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI Bridge (prog-if 00 [Normal decode])
	Flags: bus master, 66MHz, medium devsel, latency 0
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
	Memory behind bridge: dde00000-dfefffff
	Prefetchable memory behind bridge: d5d00000-ddcfffff
	Capabilities: [80] Power Management version 2
00: 06 11 98 b1 07 01 30 02 00 00 04 06 00 00 01 00
10: 00 00 00 00 00 00 00 00 00 01 01 00 f0 00 20 a2
20: e0 dd e0 df d0 d5 c0 dd 00 00 00 00 00 00 00 00
30: 00 00 00 00 80 00 00 00 00 00 00 00 00 00 0c 00
40: 81 c0 80 44 35 72 98 b1 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 02 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 00 00 00 00 00 00 00 00

0000:00:09.0 Network controller: RaLink Ralink RT2500 802.11 Cardbus Reference Card (rev 01)
	Subsystem: Micro-Star International Co., Ltd.: Unknown device 6833
	Flags: bus master, slow devsel, latency 32, IRQ 11
	Memory at dfffe000 (32-bit, non-prefetchable) [size=8K]
	Capabilities: [40] Power Management version 2
00: 14 18 01 02 17 00 10 04 01 00 80 02 08 20 00 00
10: 00 e0 ff df 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 01 06 00 00 62 14 33 68
30: 00 00 00 00 40 00 00 00 00 00 00 00 0b 01 00 00
40: 01 00 02 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 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

0000:00:0a.0 CardBus bridge: O2 Micro, Inc. OZ6912 Cardbus Controller
	Subsystem: TWINHEAD INTERNATIONAL Corp: Unknown device c602
	Flags: bus master, slow devsel, latency 64, IRQ 255
	Memory at 1e000000 (32-bit, non-prefetchable) [size=4K]
	Bus: primary=00, secondary=02, subordinate=05, sec-latency=176
	I/O window 0: 00000000-00000003
	I/O window 1: 00000000-00000003
	16-bit legacy interface ports at 0001
00: 17 12 72 69 07 00 10 04 00 00 07 06 00 40 02 00
10: 00 00 00 1e a0 00 00 02 00 02 05 b0 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00
30: 01 00 00 00 01 00 00 00 01 00 00 00 ff 01 80 00
40: ff 14 02 c6 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: 00 00 00 00 00 00 00 00 00 00 00 00 82 18 8c 01
90: 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 01 00 02 fe 00 41 c0 09 00 00 00 00 09 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 40 00 08 ea 03 82 02 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

0000:00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 80) (prog-if 00 [UHCI])
	Subsystem: TWINHEAD INTERNATIONAL Corp: Unknown device c905
	Flags: bus master, medium devsel, latency 32, IRQ 7
	I/O ports at e400 [size=32]
	Capabilities: [80] Power Management version 2
00: 06 11 38 30 17 00 10 02 80 00 03 0c 08 20 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 01 e4 00 00 00 00 00 00 00 00 00 00 ff 14 05 c9
30: 00 00 00 00 80 00 00 00 00 00 00 00 07 01 00 00
40: 40 12 03 00 00 00 00 00 00 0b 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: 01 00 c2 ff 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 20 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 03 00 00 00 00 00 00 00 00

0000:00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 80) (prog-if 00 [UHCI])
	Subsystem: TWINHEAD INTERNATIONAL Corp: Unknown device c905
	Flags: bus master, medium devsel, latency 32, IRQ 7
	I/O ports at e800 [size=32]
	Capabilities: [80] Power Management version 2
00: 06 11 38 30 17 00 10 02 80 00 03 0c 08 20 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 01 e8 00 00 00 00 00 00 00 00 00 00 ff 14 05 c9
30: 00 00 00 00 80 00 00 00 00 00 00 00 07 02 00 00
40: 40 12 03 00 00 00 00 00 00 0b 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: 01 00 c2 ff 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 20 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 03 00 00 00 00 00 00 00 00

0000:00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 80) (prog-if 00 [UHCI])
	Subsystem: TWINHEAD INTERNATIONAL Corp: Unknown device c905
	Flags: bus master, medium devsel, latency 32, IRQ 7
	I/O ports at ec00 [size=32]
	Capabilities: [80] Power Management version 2
00: 06 11 38 30 17 00 10 02 80 00 03 0c 08 20 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 01 ec 00 00 00 00 00 00 00 00 00 00 ff 14 05 c9
30: 00 00 00 00 80 00 00 00 00 00 00 00 07 03 00 00
40: 40 12 03 00 00 00 00 00 00 0b 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: 01 00 c2 ff 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 20 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 03 00 00 00 00 00 00 00 00

0000:00:10.3 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 82) (prog-if 20 [EHCI])
	Subsystem: TWINHEAD INTERNATIONAL Corp: Unknown device c905
	Flags: bus master, medium devsel, latency 32, IRQ 7
	Memory at dfffdf00 (32-bit, non-prefetchable) [size=256]
	Capabilities: [80] Power Management version 2
00: 06 11 04 31 17 00 10 02 82 20 03 0c 10 20 00 00
10: 00 df ff df 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 ff 14 05 c9
30: 00 00 00 00 80 00 00 00 00 00 00 00 07 04 00 00
40: 00 00 03 00 00 00 00 00 80 20 00 09 00 00 00 00
50: 00 5a 00 80 00 00 00 00 04 0b 66 88 33 66 00 00
60: 20 20 01 00 00 00 00 00 01 00 00 00 00 00 08 c0
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 01 00 c2 ff 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 03 00 00 00 00 00 00 00 00

0000:00:11.0 ISA bridge: VIA Technologies, Inc. VT8235 ISA Bridge
	Subsystem: VIA Technologies, Inc.: Unknown device 0000
	Flags: bus master, stepping, medium devsel, latency 0
	Capabilities: [c0] Power Management version 2
00: 06 11 77 31 87 00 10 02 00 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 06 11 00 00
30: 00 00 00 00 c0 00 00 00 00 00 00 00 00 00 00 00
40: 44 00 f8 0b 00 00 00 00 0c 20 00 00 44 00 08 08
50: 01 18 08 00 00 b0 a0 70 02 9c ff 01 00 00 04 08
60: 00 00 00 00 10 00 02 04 00 00 00 00 00 00 00 00
70: 06 11 00 00 00 00 00 00 00 00 00 00 20 00 00 00
80: 20 84 49 00 02 10 00 00 01 08 00 00 04 18 00 00
90: 00 10 bf 00 b0 c5 02 00 10 14 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: 01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 01 04 01 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 04 00 01 01 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 05 00 00 00 00 00 00 00 00 00

0000:00:11.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) (prog-if 8a [Master SecP PriP])
	Subsystem: TWINHEAD INTERNATIONAL Corp: Unknown device 1205
	Flags: bus master, medium devsel, latency 32, IRQ 255
	I/O ports at fc00 [size=16]
	Capabilities: [c0] Power Management version 2
00: 06 11 71 05 07 00 90 02 06 8a 01 01 00 20 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 01 fc 00 00 00 00 00 00 00 00 00 00 ff 14 05 12
30: 00 00 00 00 c0 00 00 00 00 00 00 00 ff 01 00 00
40: 0b f2 09 05 18 1c c0 00 a8 20 a8 20 ff 00 20 20
50: 07 e6 07 e1 0c 00 00 00 a8 a8 a8 a8 00 00 00 00
60: 00 02 00 00 00 00 00 00 00 02 00 00 00 00 00 00
70: 02 01 00 00 00 00 00 00 02 01 00 00 00 00 00 00
80: 00 00 51 01 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: 01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 06 00 71 05 ff 14 05 12 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 07 00 00 00 00 00 00 00 00 00

0000:00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 50)
	Subsystem: TWINHEAD INTERNATIONAL Corp: Unknown device 0408
	Flags: medium devsel, IRQ 10
	I/O ports at dc00 [size=256]
	Capabilities: [c0] Power Management version 2
00: 06 11 59 30 01 00 10 02 50 00 01 04 00 00 00 00
10: 01 dc 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 ff 14 08 04
30: 00 00 00 00 c0 00 00 00 00 00 00 00 0a 03 00 00
40: 05 cc 00 00 c0 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: 01 00 02 06 00 00 00 00 00 00 00 00 00 00 00 00
d0: 01 00 02 06 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

0000:00:11.6 Communication controller: VIA Technologies, Inc. Intel 537 [AC97 Modem] (rev 80)
	Subsystem: TWINHEAD INTERNATIONAL Corp: Unknown device 1005
	Flags: medium devsel, IRQ 10
	I/O ports at e000 [size=256]
	Capabilities: [d0] Power Management version 2
00: 06 11 68 30 01 00 10 02 80 00 80 07 00 00 00 00
10: 01 e0 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 ff 14 05 10
30: 00 00 00 00 d0 00 00 00 00 00 00 00 0a 03 00 00
40: 05 cc 00 00 c0 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: 01 00 02 06 00 00 00 00 00 00 00 00 00 00 00 00
d0: 01 00 02 06 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

0000:00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 74)
	Subsystem: TWINHEAD INTERNATIONAL Corp: Unknown device 0207
	Flags: bus master, medium devsel, latency 32, IRQ 11
	I/O ports at d800 [size=256]
	Memory at dfffde00 (32-bit, non-prefetchable) [size=256]
	Capabilities: [40] Power Management version 2
00: 06 11 65 30 17 00 10 02 74 00 00 02 08 20 00 00
10: 01 d8 00 00 00 de ff df 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 ff 14 07 02
30: 00 00 00 00 40 00 00 00 00 00 00 00 0b 01 03 08
40: 01 00 02 fe 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 02
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 00 00 00 00 00 00 00 00

0000:01:00.0 VGA compatible controller: VIA Technologies, Inc. VT8378 [S3 UniChrome] Integrated Video (rev 01) (prog-if 00 [VGA])
	Subsystem: TWINHEAD INTERNATIONAL Corp: Unknown device 030d
	Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 11
	Memory at d8000000 (32-bit, prefetchable) [size=64M]
	Memory at de000000 (32-bit, non-prefetchable) [size=16M]
	Expansion ROM at dfef0000 [disabled] [size=64K]
	Capabilities: [60] Power Management version 2
	Capabilities: [70] AGP version 2.0
00: 06 11 05 72 07 00 30 02 01 00 00 03 00 20 00 00
10: 08 00 00 d8 00 00 00 de 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 ff 14 0d 03
30: 00 00 ef df 60 00 00 00 00 00 00 00 0b 01 02 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: 01 70 22 06 00 00 00 00 00 00 00 00 00 00 00 00
70: 02 00 20 00 07 02 00 1f 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 00 00 00 00 00 00 00 00


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: S3 test tool (was : Re: Bizarre oops after suspend to RAM (was: Re: [ACPI] Resume from Suspend to RAM))
  2005-06-14 16:24                 ` dagit
@ 2005-06-17 13:16                   ` Matthew Garrett
  0 siblings, 0 replies; 23+ messages in thread
From: Matthew Garrett @ 2005-06-17 13:16 UTC (permalink / raw)
  To: dagit; +Cc: Shaohua Li, stefandoesinger, acpi-dev, lkml, Pavel Machek

On Tue, 2005-06-14 at 09:24 -0700, dagit@codersbase.com wrote:
> Sure thing, (a) is called lspci-coldboot.txt and the other is
> lspci-warmboot.txt.  I've attached them so that you can see the whole
> thing, it doesn't look very helpful to me and the diff was even more
> cryptic, so good luck ;)

Ok, this is probably a long shot, but try:

setpci -s 00:00.0 67.b=11
setpci -s 00:00.0 68.b=4f
setpci -s 00:00.0 6d.b=47
setpci -s 00:00.0 9a.b=0a
setpci -s 00:00.0 9b.b=1d

after a cold boot, and then see if that changes the behaviour. My
suspicion is that Windows enables some northbridge features that affect
the behaviour of the system in suspend. Working out /what/ would be much
easier with datasheets, but ATI and VIA don't seem willing to provide
them (if anyone could provide me with northbridge PCI configuration
register specs for any non-Intel chipsets, that would be astonishingly
helpful)

-- 
Matthew Garrett | mjg59@srcf.ucam.org

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: S3 test tool (was : Re: Bizarre oops after suspend to RAM (was: Re: [ACPI] Resume from Suspend to RAM))
  2005-06-14  7:25             ` dagit
  2005-06-14  8:47               ` Matthew Garrett
@ 2005-06-14  9:06               ` Pavel Machek
  2005-06-14 15:51                 ` dagit
  1 sibling, 1 reply; 23+ messages in thread
From: Pavel Machek @ 2005-06-14  9:06 UTC (permalink / raw)
  To: dagit; +Cc: Shaohua Li, stefandoesinger, acpi-dev, Matthew Garrett, lkml

Hi!

> If you've looked at this bug you will know that myself at and atleast
> one other person experience a reboot on resume at a specific line in
> the wakeup code:
> http://bugme.osdl.org/show_bug.cgi?id=3586
> 
> One note about the code in the bug, my code for detecting PM is
> backwards, so ignore it, what I say in this email is still valid.
> 
> Specifically, if I get rid of the pushl;popl then the computer does
> not reboot.  See the attached diff.  The question is 1) is this
> pushl;popl the final nail in the coffin? 2) Does windows not clear the
> flags completely, but instead sets them to some "special value"?
> 
> The reason for (1) is because as I understand it, when a certain
> number of illegal operations (3 iirc) are issued at certain times
> (real mode iirc) the machine automatically reboots.  That could be
> what we are seeing here.

You got this wrong. It is three illegal instructions but
*nested*. Like error, error in fault handler, error in doublefault
handler.

Try replacing flags manipulation with any stack manipulation to see
what is wrong.

> Also, what flags are being cleared?  What is their meaning?  Can you
> or someone on this list point me to the approriate documentation?  I'd
> love to look at it and try to understand my hardware better.

Like perhaps processor docs?
								Pavel
-- 
teflon -- maybe it is a trademark, but it should not be.

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: S3 test tool (was : Re: Bizarre oops after suspend to RAM (was: Re: [ACPI] Resume from Suspend to RAM))
  2005-06-14  9:06               ` Pavel Machek
@ 2005-06-14 15:51                 ` dagit
  2005-06-14 21:37                   ` Pavel Machek
  0 siblings, 1 reply; 23+ messages in thread
From: dagit @ 2005-06-14 15:51 UTC (permalink / raw)
  To: Pavel Machek; +Cc: Shaohua Li, stefandoesinger, acpi-dev, Matthew Garrett, lkml

Pavel Machek <pavel@ucw.cz> writes:

> Hi!
>
>> If you've looked at this bug you will know that myself at and atleast
>> one other person experience a reboot on resume at a specific line in
>> the wakeup code:
>> http://bugme.osdl.org/show_bug.cgi?id=3586
>> 
>> One note about the code in the bug, my code for detecting PM is
>> backwards, so ignore it, what I say in this email is still valid.
>> 
>> Specifically, if I get rid of the pushl;popl then the computer does
>> not reboot.  See the attached diff.  The question is 1) is this
>> pushl;popl the final nail in the coffin? 2) Does windows not clear the
>> flags completely, but instead sets them to some "special value"?
>> 
>> The reason for (1) is because as I understand it, when a certain
>> number of illegal operations (3 iirc) are issued at certain times
>> (real mode iirc) the machine automatically reboots.  That could be
>> what we are seeing here.
>
> You got this wrong. It is three illegal instructions but
> *nested*. Like error, error in fault handler, error in doublefault
> handler.

Ah.  Yeah, this isn't an area I know much about :)  Thanks for the
correction. 

> Try replacing flags manipulation with any stack manipulation to see
> what is wrong.

Do you mean try something like this? Replace the push 0 with push
0x1234 ; push 0x1234 ; pop ; pop and try to figure out which line
causes the reboot?

> Like perhaps processor docs?

Is that what I want to look at?  I was the one asking the question. ;)

Thanks,
Jason


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: S3 test tool (was : Re: Bizarre oops after suspend to RAM (was: Re: [ACPI] Resume from Suspend to RAM))
  2005-06-14 15:51                 ` dagit
@ 2005-06-14 21:37                   ` Pavel Machek
  2005-06-14 22:01                     ` dagit
  0 siblings, 1 reply; 23+ messages in thread
From: Pavel Machek @ 2005-06-14 21:37 UTC (permalink / raw)
  To: dagit; +Cc: Shaohua Li, stefandoesinger, acpi-dev, Matthew Garrett, lkml

Hi!

> > You got this wrong. It is three illegal instructions but
> > *nested*. Like error, error in fault handler, error in doublefault
> > handler.
> 
> Ah.  Yeah, this isn't an area I know much about :)  Thanks for the
> correction. 
> 
> > Try replacing flags manipulation with any stack manipulation to see
> > what is wrong.
> 
> Do you mean try something like this? Replace the push 0 with push
> 0x1234 ; push 0x1234 ; pop ; pop and try to figure out which line
> causes the reboot?

Yep, try pushl $0, popl %eax; if that causes problems, something is
seriously wrong with stack, otherwise changing flags hurts.

> > Like perhaps processor docs?
> 
> Is that what I want to look at?  I was the one asking the question. ;)

Yes.
								Pavel
-- 
teflon -- maybe it is a trademark, but it should not be.

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: S3 test tool (was : Re: Bizarre oops after suspend to RAM (was: Re: [ACPI] Resume from Suspend to RAM))
  2005-06-14 21:37                   ` Pavel Machek
@ 2005-06-14 22:01                     ` dagit
  2005-06-14 22:09                       ` Pavel Machek
  0 siblings, 1 reply; 23+ messages in thread
From: dagit @ 2005-06-14 22:01 UTC (permalink / raw)
  To: Pavel Machek; +Cc: Shaohua Li, stefandoesinger, acpi-dev, Matthew Garrett, lkml

Pavel Machek <pavel@suse.cz> writes:

> Hi!
>
>> > You got this wrong. It is three illegal instructions but
>> > *nested*. Like error, error in fault handler, error in doublefault
>> > handler.
>> 
>> Ah.  Yeah, this isn't an area I know much about :)  Thanks for the
>> correction. 
>> 
>> > Try replacing flags manipulation with any stack manipulation to see
>> > what is wrong.
>> 
>> Do you mean try something like this? Replace the push 0 with push
>> 0x1234 ; push 0x1234 ; pop ; pop and try to figure out which line
>> causes the reboot?
>
> Yep, try pushl $0, popl %eax; if that causes problems, something is
> seriously wrong with stack, otherwise changing flags hurts.

pushl $0, popl %eax gets the reboot.  So it's changing the flags that
is bad?

What should we try next?

thanks,
Jason



^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: S3 test tool (was : Re: Bizarre oops after suspend to RAM (was: Re: [ACPI] Resume from Suspend to RAM))
  2005-06-14 22:01                     ` dagit
@ 2005-06-14 22:09                       ` Pavel Machek
  2005-06-14 22:18                         ` dagit
  0 siblings, 1 reply; 23+ messages in thread
From: Pavel Machek @ 2005-06-14 22:09 UTC (permalink / raw)
  To: dagit; +Cc: Shaohua Li, stefandoesinger, acpi-dev, Matthew Garrett, lkml

Hi!

> >> > You got this wrong. It is three illegal instructions but
> >> > *nested*. Like error, error in fault handler, error in doublefault
> >> > handler.
> >> 
> >> Ah.  Yeah, this isn't an area I know much about :)  Thanks for the
> >> correction. 
> >> 
> >> > Try replacing flags manipulation with any stack manipulation to see
> >> > what is wrong.
> >> 
> >> Do you mean try something like this? Replace the push 0 with push
> >> 0x1234 ; push 0x1234 ; pop ; pop and try to figure out which line
> >> causes the reboot?
> >
> > Yep, try pushl $0, popl %eax; if that causes problems, something is
> > seriously wrong with stack, otherwise changing flags hurts.
> 
> pushl $0, popl %eax gets the reboot.  So it's changing the flags that
> is bad?
> 
> What should we try next?

??? You wanted it to reboot? If not, something is wrong with
stack. Not sure whats next.

							Pavel
-- 
teflon -- maybe it is a trademark, but it should not be.

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: S3 test tool (was : Re: Bizarre oops after suspend to RAM (was: Re: [ACPI] Resume from Suspend to RAM))
  2005-06-14 22:09                       ` Pavel Machek
@ 2005-06-14 22:18                         ` dagit
  2005-06-14 23:11                           ` Pavel Machek
  0 siblings, 1 reply; 23+ messages in thread
From: dagit @ 2005-06-14 22:18 UTC (permalink / raw)
  To: Pavel Machek; +Cc: Shaohua Li, stefandoesinger, acpi-dev, Matthew Garrett, lkml

Pavel Machek <pavel@suse.cz> writes:

> Hi!
>
>> >> > You got this wrong. It is three illegal instructions but
>> >> > *nested*. Like error, error in fault handler, error in doublefault
>> >> > handler.
>> >> 
>> >> Ah.  Yeah, this isn't an area I know much about :)  Thanks for the
>> >> correction. 
>> >> 
>> >> > Try replacing flags manipulation with any stack manipulation to see
>> >> > what is wrong.
>> >> 
>> >> Do you mean try something like this? Replace the push 0 with push
>> >> 0x1234 ; push 0x1234 ; pop ; pop and try to figure out which line
>> >> causes the reboot?
>> >
>> > Yep, try pushl $0, popl %eax; if that causes problems, something is
>> > seriously wrong with stack, otherwise changing flags hurts.
>> 
>> pushl $0, popl %eax gets the reboot.  So it's changing the flags that
>> is bad?
>> 
>> What should we try next?
>
> ??? You wanted it to reboot? If not, something is wrong with
> stack. Not sure whats next.

I don't want it to reboot, I guess I got confused.  As you say, maybe
something is wrong with the stack.  It's weird that something would be
wrong with the stack, because the other test to check the
suspend/resume code path works like a charm, the machine will do the
fake suspend/resume just fine.

So the bios must be messing up the stack right?  Is there a way to
examine or dump the stack so that we can compare the stack when
windows does the suspend/resume compared to when linux does it?

thanks,
Jason


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: S3 test tool (was : Re: Bizarre oops after suspend to RAM (was: Re: [ACPI] Resume from Suspend to RAM))
  2005-06-14 22:18                         ` dagit
@ 2005-06-14 23:11                           ` Pavel Machek
  2005-06-15  0:41                             ` dagit
  0 siblings, 1 reply; 23+ messages in thread
From: Pavel Machek @ 2005-06-14 23:11 UTC (permalink / raw)
  To: dagit; +Cc: Shaohua Li, stefandoesinger, acpi-dev, Matthew Garrett, lkml

Hi!

> >> >> Do you mean try something like this? Replace the push 0 with push
> >> >> 0x1234 ; push 0x1234 ; pop ; pop and try to figure out which line
> >> >> causes the reboot?
> >> >
> >> > Yep, try pushl $0, popl %eax; if that causes problems, something is
> >> > seriously wrong with stack, otherwise changing flags hurts.
> >> 
> >> pushl $0, popl %eax gets the reboot.  So it's changing the flags that
> >> is bad?
> >> 
> >> What should we try next?
> >
> > ??? You wanted it to reboot? If not, something is wrong with
> > stack. Not sure whats next.
> 
> I don't want it to reboot, I guess I got confused.  As you say, maybe
> something is wrong with the stack.  It's weird that something would be
> wrong with the stack, because the other test to check the
> suspend/resume code path works like a charm, the machine will do the
> fake suspend/resume just fine.

Well, we set up stack few instructions before that. But we do it in
quite a complicated way; could you just put stack at 0x00:0x200 or
something like that? Also test if push alone is enough to kill it.

								Pavel
-- 
teflon -- maybe it is a trademark, but it should not be.

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: S3 test tool (was : Re: Bizarre oops after suspend to RAM (was: Re: [ACPI] Resume from Suspend to RAM))
  2005-06-14 23:11                           ` Pavel Machek
@ 2005-06-15  0:41                             ` dagit
  2005-06-15  0:50                               ` dagit
  2005-06-15 18:41                               ` Pavel Machek
  0 siblings, 2 replies; 23+ messages in thread
From: dagit @ 2005-06-15  0:41 UTC (permalink / raw)
  To: Pavel Machek; +Cc: Shaohua Li, stefandoesinger, acpi-dev, Matthew Garrett, lkml

Pavel Machek <pavel@suse.cz> writes:

> Hi!
>
>> >> >> Do you mean try something like this? Replace the push 0 with push
>> >> >> 0x1234 ; push 0x1234 ; pop ; pop and try to figure out which line
>> >> >> causes the reboot?
>> >> >
>> >> > Yep, try pushl $0, popl %eax; if that causes problems, something is
>> >> > seriously wrong with stack, otherwise changing flags hurts.
>> >> 
>> >> pushl $0, popl %eax gets the reboot.  So it's changing the flags that
>> >> is bad?
>> >> 
>> >> What should we try next?
>> >
>> > ??? You wanted it to reboot? If not, something is wrong with
>> > stack. Not sure whats next.
>> 
>> I don't want it to reboot, I guess I got confused.  As you say, maybe
>> something is wrong with the stack.  It's weird that something would be
>> wrong with the stack, because the other test to check the
>> suspend/resume code path works like a charm, the machine will do the
>> fake suspend/resume just fine.
>
> Well, we set up stack few instructions before that. But we do it in
> quite a complicated way; could you just put stack at 0x00:0x200 or
> something like that? Also test if push alone is enough to kill it.

Could you send me the code you want me to test, I'd don't know enough
asm to move the stack.  I tried replacing the line with the comment
about the ASUS board private stack with a line like, "mov $0x200,
%sp", but I don't understand it.

As for check about the push alone causing the reboot, I removed the
pop, and it still reboots, but to me that doesn't say that it's the
push that does it.  It could be the next line.  I'll try to put in an
infinite loop.

Thanks,
Jason


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: S3 test tool (was : Re: Bizarre oops after suspend to RAM (was: Re: [ACPI] Resume from Suspend to RAM))
  2005-06-15  0:41                             ` dagit
@ 2005-06-15  0:50                               ` dagit
  2005-06-15 18:41                               ` Pavel Machek
  1 sibling, 0 replies; 23+ messages in thread
From: dagit @ 2005-06-15  0:50 UTC (permalink / raw)
  To: Pavel Machek; +Cc: Shaohua Li, stefandoesinger, acpi-dev, Matthew Garrett, lkml

> As for check about the push alone causing the reboot, I removed the
> pop, and it still reboots, but to me that doesn't say that it's the
> push that does it.  It could be the next line.  I'll try to put in an
> infinite loop.

I added a loop "jmp ." right after the pushl and the machine still
reboots.  So the pushl does cause the reboot.

Hopefully, you can show me how to move the stack and I will try that
as well.

Thanks,
Jason


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: S3 test tool (was : Re: Bizarre oops after suspend to RAM (was: Re: [ACPI] Resume from Suspend to RAM))
  2005-06-15  0:41                             ` dagit
  2005-06-15  0:50                               ` dagit
@ 2005-06-15 18:41                               ` Pavel Machek
  1 sibling, 0 replies; 23+ messages in thread
From: Pavel Machek @ 2005-06-15 18:41 UTC (permalink / raw)
  To: dagit; +Cc: Shaohua Li, stefandoesinger, acpi-dev, Matthew Garrett, lkml

Hi!

> >> >> What should we try next?
> >> >
> >> > ??? You wanted it to reboot? If not, something is wrong with
> >> > stack. Not sure whats next.
> >> 
> >> I don't want it to reboot, I guess I got confused.  As you say, maybe
> >> something is wrong with the stack.  It's weird that something would be
> >> wrong with the stack, because the other test to check the
> >> suspend/resume code path works like a charm, the machine will do the
> >> fake suspend/resume just fine.
> >
> > Well, we set up stack few instructions before that. But we do it in
> > quite a complicated way; could you just put stack at 0x00:0x200 or
> > something like that? Also test if push alone is enough to kill it.
> 
> Could you send me the code you want me to test, I'd don't know enough
> asm to move the stack.  I tried replacing the line with the comment
> about the ASUS board private stack with a line like, "mov $0x200,
> %sp", but I don't understand it.

mov 0x200, %sp was good idea, but try to zero %ss, too. (xor %eax,
%eax; mov %eax, %ss).
								Pavel

-- 
teflon -- maybe it is a trademark, but it should not be.

^ permalink raw reply	[flat|nested] 23+ messages in thread

[parent not found: <4cnEB-7Y5-13@gated-at.bofh.it>]

[parent not found: <4cnEB-7Y5-19@gated-at.bofh.it>]

[parent not found: <4cnEB-7Y5-11@gated-at.bofh.it>]

[parent not found: <4cpZW-1yL-13@gated-at.bofh.it>]

* Re: Bizarre oops after suspend to RAM (was: Re: [ACPI] Resume from Suspend to RAM)
       [not found]     ` <4cpZW-1yL-13@gated-at.bofh.it>
@ 2005-06-07  1:06       ` Bodo Eggert
  0 siblings, 0 replies; 23+ messages in thread
From: Bodo Eggert @ 2005-06-07  1:06 UTC (permalink / raw)
  To: Stefan Dösinger, acpi-devel, Matthew Garrett, linux-kernel

Stefan Dösinger <stefandoesinger@gmx.at> wrote:

> So it does reach the kernel, right? I don't know if I remembered that call
> correctly, but "lcall $0xffff,$0" should call the real mode BIOS reset
> code...
> Anyone else who can correct me here?

If it's realmode, it should do a jump to the boot entry point of the BIOS.
This does not imply a reset, some machines will just hang. Especially after
messing with the interrupts or mapping some RAM over the lower half of the
BIOS, where the boot code is expected.

Good (== long gone) old times with DOS.
-- 
Ich danke GMX dafür, die Verwendung meiner Adressen mittels per SPF
verbreiteten Lügen zu sabotieren.

^ permalink raw reply	[flat|nested] 23+ messages in thread

end of thread, other threads:[~2005-06-17 13:16 UTC | newest]

Thread overview: 23+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <200506051456.44810.hugelmopf@web.de>
     [not found] ` <1117978635.6648.136.camel@tyrosine>
     [not found]   ` <200506051732.08854.stefandoesinger@gmx.at>
     [not found]     ` <1118053578.6648.142.camel@tyrosine>
2005-06-06 11:06       ` Bizarre oops after suspend to RAM (was: Re: [ACPI] Resume from Suspend to RAM) Matthew Garrett
2005-06-06 14:45         ` Pavel Machek
2005-06-06 14:54           ` Matthew Garrett
2005-06-06 15:09             ` Pavel Machek
2005-06-07 14:14               ` Martin Michlmayr
2005-06-06 15:31         ` Stefan Dösinger
2005-06-07  6:23           ` S3 test tool (was : Re: Bizarre oops after suspend to RAM (was: Re: [ACPI] Resume from Suspend to RAM)) Shaohua Li
2005-06-07 12:07             ` Martin Michlmayr
2005-06-14  7:25             ` dagit
2005-06-14  8:47               ` Matthew Garrett
2005-06-14 16:24                 ` dagit
2005-06-17 13:16                   ` Matthew Garrett
2005-06-14  9:06               ` Pavel Machek
2005-06-14 15:51                 ` dagit
2005-06-14 21:37                   ` Pavel Machek
2005-06-14 22:01                     ` dagit
2005-06-14 22:09                       ` Pavel Machek
2005-06-14 22:18                         ` dagit
2005-06-14 23:11                           ` Pavel Machek
2005-06-15  0:41                             ` dagit
2005-06-15  0:50                               ` dagit
2005-06-15 18:41                               ` Pavel Machek
     [not found] <4cnEB-7Y5-13@gated-at.bofh.it>
     [not found] ` <4cnEB-7Y5-19@gated-at.bofh.it>
     [not found]   ` <4cnEB-7Y5-11@gated-at.bofh.it>
     [not found]     ` <4cpZW-1yL-13@gated-at.bofh.it>
2005-06-07  1:06       ` Bizarre oops after suspend to RAM (was: Re: [ACPI] Resume from Suspend to RAM) Bodo Eggert

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox