You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(3) |
Dec
(200) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(162) |
Feb
(338) |
Mar
(493) |
Apr
(706) |
May
(729) |
Jun
(316) |
Jul
(435) |
Aug
(325) |
Sep
(355) |
Oct
(314) |
Nov
(336) |
Dec
(330) |
| 2003 |
Jan
(320) |
Feb
(387) |
Mar
(362) |
Apr
(216) |
May
(391) |
Jun
(292) |
Jul
(369) |
Aug
(334) |
Sep
(429) |
Oct
(339) |
Nov
(340) |
Dec
(344) |
| 2004 |
Jan
(641) |
Feb
(611) |
Mar
(603) |
Apr
(308) |
May
(321) |
Jun
(355) |
Jul
(291) |
Aug
(508) |
Sep
(482) |
Oct
(490) |
Nov
(574) |
Dec
(408) |
| 2005 |
Jan
(568) |
Feb
(500) |
Mar
(485) |
Apr
(357) |
May
(219) |
Jun
(370) |
Jul
(336) |
Aug
(300) |
Sep
(388) |
Oct
(257) |
Nov
(298) |
Dec
(313) |
| 2006 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Pavel Machek <pavel@su...> - 2005-12-25 08:48:01
|
Hi! > New weird error. This may also be harmless though. Just first a few > notes, I'm back onto 2.6.14.3 kernel (fglrx doesn't work with 2.6.15-rc? > - it just crashes the whole system), and I really need that. > > With fglrx I can suspend to disk and resume. However, I can't > suspend-to-ram. Well, suspend works and it comes back up fine but as > soon as I switch back to X it hard-crashes the machine. Now, I'm > currently between resume and switching to X, and the last few lines from > dmesg looks as follows: > > Restarting tasks... done > ACPI-0284: *** Error: Region EmbeddedController(3) has no handler > ACPI-0508: *** Error: Method execution failed [\_SB_.EPWR.PCLK] > (Node c14d3200), AE_NOT_EXIST > ACPI-0508: *** Error: Method execution failed > [\_SB_.CPI0.LPC0.EC0_._Q1E] (Node c14ceee0), AE_NOT_EXIST ...something wrong with embedded controller... here fixed DSDT *might* help. > Now I have a very weird feeling down in my gut that I did not see this > before and it's probably due to the fglrx module in my kernel. And > interrupt 11, btw, is for the screen (it gets shown now in > /proc/interrupts after I restored most of my kernel). > > Now, initially when I switch back to X I get the correct image on the > bottom third of the screen with the top two thirds seemingly corrupted. > This is pretty normal and is identical to what I normally see when > switching between consoles and X. This lasts for about half a second > before it freezes up and causes a hard-lock. Normally the screen just > resets itself at the time it now locks up. I'm sorry, there's no way we can help you with fglrx. I'm glad at least s-t-disk works. Pavel -- Thanks, Sharp! |
|
From: <politi_mail@ya...> - 2005-12-25 08:34:22
|
If you can't see this mail press here =D7=90=D7=9D =D7=90=D7=99=D7=A0=D7=9A =D7=A8=D7=95=D7=90=D7=94 =D7=9E=D7=99=D7=99=D7=9C =D7=96=D7=94 =D7=9C=D7=97=D7=A5 =D7=9B=D7=90=D7=9F =D7=90=D7=99=D7=9E=D7=99=D7=99=D7=9C =D7=96=D7=94 =D7=A0=D7=A9=D7=9C=D7=97 =D7=9C=D7=9A =D7=91=D7=90=D7=95=D7=A4=D7=9F =D7=97=D7=93 =D7=A4=D7=A2=D7=9E=D7=99, =D7=91=D7=9B=D7=93=D7=99 =D7=9C=D7=94=D7=A1=D7=99=D7=A8 =D7=9E=D7=99=D7=99=D7=9C =D7=96=D7=94 =D7=9E=D7=94=D7=A8=D7=A9=D7=99=D7=9E=D7=94 =D7=9C=D7=97=D7=A5 =D7=9B=D7=90=D7=9F |
|
From: Jaco Kroon <jaco@kr...> - 2005-12-25 08:24:49
|
Pavel Machek wrote:
> On So 24-12-05 15:14:16, Jaco Kroon wrote:
>>Pavel Machek wrote:
>>>>Now, with APIC, but no IO-APIC there is a bug notice during resume.
>>>>Going to type it over (from dmesg):
>>>>
>>>>Back to C!
>>>>Debug: sleeping function called from invalid context at mm/slab.c:2472
>>>>in_atomic():0, irqs_disabled():1
>>>>__might_sleep+0x9e/0xa6
>>>>acpi_os_allocate+0x15/0x26
>>>>kmem_cache_alloc+0x95/0xad
>>>>acpi_ut_callocate+0x37/0x79
>>>
>>>I know, it is scary, but it is also known and harmless. You can ignore
>>>this one.
>>
>>Now _that_ made me raise an eyebrow. Even more than the fact that my
>>DSDT insists on checking for the version of Microsoft Windows I'm
>>running!
>
> See archives. Len even had a fix at some point, but it was too ugly
> IIRC.
>
Oh ok. No problem then.
New weird error. This may also be harmless though. Just first a few
notes, I'm back onto 2.6.14.3 kernel (fglrx doesn't work with 2.6.15-rc?
- it just crashes the whole system), and I really need that.
With fglrx I can suspend to disk and resume. However, I can't
suspend-to-ram. Well, suspend works and it comes back up fine but as
soon as I switch back to X it hard-crashes the machine. Now, I'm
currently between resume and switching to X, and the last few lines from
dmesg looks as follows:
Restarting tasks... done
ACPI-0284: *** Error: Region EmbeddedController(3) has no handler
ACPI-0508: *** Error: Method execution failed [\_SB_.EPWR.PCLK]
(Node c14d3200), AE_NOT_EXIST
ACPI-0508: *** Error: Method execution failed
[\_SB_.CPI0.LPC0.EC0_._Q1E] (Node c14ceee0), AE_NOT_EXIST
Now I have a very weird feeling down in my gut that I did not see this
before and it's probably due to the fglrx module in my kernel. And
interrupt 11, btw, is for the screen (it gets shown now in
/proc/interrupts after I restored most of my kernel).
Now, initially when I switch back to X I get the correct image on the
bottom third of the screen with the top two thirds seemingly corrupted.
This is pretty normal and is identical to what I normally see when
switching between consoles and X. This lasts for about half a second
before it freezes up and causes a hard-lock. Normally the screen just
resets itself at the time it now locks up.
Anyhow, not too serious, overall I'm pretty happy with the progress made
during this week. suspend-to-disk == much better than no suspend at all
(at least now I can stop my notebook halfway through some busy task to
shut it down, transport it and resume elsewhere).
Then again, I'll play around with the kernel options for fglrx and see
whether they don't perhaps make a difference.
Jaco
--
There are only 10 kinds of people in this world,
those that understand binary and those that don't.
http://www.kroon.co.za/
|
|
From: <info@fk...> - 2005-12-25 02:48:59
|
$B=i$a$^$7$F!#!ZNY$N<G@...$NBeI=!"H~M35*![$H?=$7$^$9!#(B
$B$3$N%5%$%H$K=P;q$7$F$k$N$GFCJL$K5v2D$rD:$-!"Jg=8$7$^$9!#(B
$B3d@...$C$?8r:]$r5a$a$kG/<}(B1000$BK|0J>e$N=w@...$H$N5U%5%]!{%H8r:]$r(B
$B$7$F$_$^$;$s$+!)(B
$B!}F~2q6b!&2qHqEy$9$Y$F=w@...!"CK@...$O$^$C$?$/EPO?NA6b$,3]$+(B
$B$j$^$;$s!#(B
$B!}7n(B1$B!A(B2$B2s(B($B=w@...$K$h$k!"Kt$OOC$79g$$$G(B)
$B!}3d@...$C$?4X78!"7k:'A0Ds!"%S%8%M%9%Q!<%H%J!<!"=w@...$NL\E*$b(B
$BMM!9$G$9(B
http://www.tonashiba1.net/?shibahu
$BM5J!$J=w@...$OF~2q6b!&2qHq$rJ'$C$FEPO?$7$F$$$^$9!#(B
$B5qH]!'(Bstop@...
|
|
From: Pavel Machek <pavel@su...> - 2005-12-24 13:58:25
|
On So 24-12-05 15:14:16, Jaco Kroon wrote: > Pavel Machek wrote: > > >>Now, with APIC, but no IO-APIC there is a bug notice during resume. > >>Going to type it over (from dmesg): > >> > >>Back to C! > >>Debug: sleeping function called from invalid context at mm/slab.c:2472 > >>in_atomic():0, irqs_disabled():1 > >> __might_sleep+0x9e/0xa6 > >> acpi_os_allocate+0x15/0x26 > >> kmem_cache_alloc+0x95/0xad > >> acpi_ut_callocate+0x37/0x79 > > > > I know, it is scary, but it is also known and harmless. You can ignore > > this one. > > Now _that_ made me raise an eyebrow. Even more than the fact that my > DSDT insists on checking for the version of Microsoft Windows I'm > running! See archives. Len even had a fix at some point, but it was too ugly IIRC. > Not right now. The festive season awaits (yay ...). So in that spirit, > Merry Christmas and a Happy New Year! Merry Christmas! > > Oh and thanks for video.txt diff, applied. > > Shees. That is my second accepted patch in a week. Also my first two > accepted patches. LOL. Hopefully there will be more to come. Now I :-). Pavel -- Thanks, Sharp! |
|
From: Jaco Kroon <jaco@kr...> - 2005-12-24 13:12:42
|
Pavel Machek wrote: >>Now, with APIC, but no IO-APIC there is a bug notice during resume. >>Going to type it over (from dmesg): >> >>Back to C! >>Debug: sleeping function called from invalid context at mm/slab.c:2472 >>in_atomic():0, irqs_disabled():1 >> __might_sleep+0x9e/0xa6 >> acpi_os_allocate+0x15/0x26 >> kmem_cache_alloc+0x95/0xad >> acpi_ut_callocate+0x37/0x79 > > I know, it is scary, but it is also known and harmless. You can ignore > this one. Now _that_ made me raise an eyebrow. Even more than the fact that my DSDT insists on checking for the version of Microsoft Windows I'm running! >>ACPI: PCI Interrupt 0000:00:14.1[A] -> Link [LNK0] -> GSI 11 (level, >>low) -> IRQ 11 >>ACPI: PCI Interrupt 0000:02:04.0[A] -> Link [LNK0] -> GSI 11 (level, >>low) -> IRQ 11 >>Restarting tasks... done >> >>Both cases looks identical. /proc/interrupts doesn't list 11 as an >>interrupt ?!? > > Talk to acpi people about that. Well, acpi-devel is on the CC list. Hopefully somebody will read. [--snip--] >>Anyhow, suspended twice to ram now in succession, make cleaned and >>rebuilt the kernel, installed it, and the only thing that even suggests >>there is a glitch is that trace. >> >>Looks like I need APIC on and IO-APIC off. Any explanations very >>welcome: and don't tell me the IO-APIC is buggy - I've been running >>with both those options on for as long as I've had this notebook now. > > I do not know enough explanations, feel free to investigate. Not right now. The festive season awaits (yay ...). So in that spirit, Merry Christmas and a Happy New Year! > Anyway so both suspend-to-ram and suspend-to-disk now works for you, > right? No need to press keys to make it write image on disk? How did you know about the key? Yes, it now correctly goes away and comes back up. Guess I'm going to get rid of hibernate though and use my own custom scripts though. > Oh and thanks for video.txt diff, applied. Shees. That is my second accepted patch in a week. Also my first two accepted patches. LOL. Hopefully there will be more to come. Now I need to get my notebook back to a "user-friendly" state. Thanks for all the help and all the patience from everyone. Jaco -- There are only 10 kinds of people in this world, those that understand binary and those that don't. http://www.kroon.co.za/ |
|
From: Pavel Machek <pavel@su...> - 2005-12-24 12:49:37
|
Hi! > I presume you're looking for ide0 and ide1 interrupts, yes, after > suspending to ram twice the command showed that interrupt 14 (ide0) > increased from 994 to 1011 and for 15 (ide1) it stayed at 24. My hdd is > on hda so that'll be on ide0, dvd-rw is on hdc or ide1. > > The interrupt counts for cascade (irq 2), rtc (irq 8) and acpi (irq 9) > stayed constant though, at 0, 2 and 4 respectively. > > No NMI or ERR conditions were ever signaled. > > Now, with APIC, but no IO-APIC there is a bug notice during resume. > Going to type it over (from dmesg): > > Back to C! > Debug: sleeping function called from invalid context at mm/slab.c:2472 > in_atomic():0, irqs_disabled():1 > __might_sleep+0x9e/0xa6 > acpi_os_allocate+0x15/0x26 > kmem_cache_alloc+0x95/0xad > acpi_ut_callocate+0x37/0x79 I know, it is scary, but it is also known and harmless. You can ignore this one. > ACPI: PCI Interrupt 0000:00:14.1[A] -> Link [LNK0] -> GSI 11 (level, > low) -> IRQ 11 > ACPI: PCI Interrupt 0000:02:04.0[A] -> Link [LNK0] -> GSI 11 (level, > low) -> IRQ 11 > Restarting tasks... done > > Both cases looks identical. /proc/interrupts doesn't list 11 as an > interrupt ?!? Talk to acpi people about that. > Also, this time round the auto-repeat on the keys is working again after > resume. In fact, everything seems to be working. Just that debug > stacktrace that bothers me. Oh, and my console blanking time also seems > to get lost but I can fix that with the help of echo and /dev/tty*. Good. > Anyhow, suspended twice to ram now in succession, make cleaned and > rebuilt the kernel, installed it, and the only thing that even suggests > there is a glitch is that trace. > > Looks like I need APIC on and IO-APIC off. Any explanations very > welcome: and don't tell me the IO-APIC is buggy - I've been running > with both those options on for as long as I've had this notebook now. I do not know enough explanations, feel free to investigate. Anyway so both suspend-to-ram and suspend-to-disk now works for you, right? No need to press keys to make it write image on disk? Oh and thanks for video.txt diff, applied. Pavel -- Thanks, Sharp! |
|
From: Jaco Kroon <jaco@kr...> - 2005-12-24 12:43:55
|
Pavel Machek wrote: > Hi! > > >>Damn. I just thought I solved it. I disabled the APIC and tried again. >> This time round I managed to re-enable APIC in the kernel source >>(without IO-APIC) and _recompile_ it entirely. Only upon issueing "make >>install modules_install" did it pop. >> >>Sequence was something like: >> >>echo mem > /sys/power/state >>cd /usr/src/linux >>make menuconfig >>make menuconfig >>echo mem > /sys/power/state >>make menuconfig >>--> re-enable APIC but not IO-APIC >>make >>make install modules_install >>->> pop. When copying the image from the source directory to /boot. >> >>This is beginning to sound more and more like some obscure >>race-condition if you ask me. > > > I would be surprised if that was the case. Are you sure it is not just > "disk does not work after resume", and depending of stuff in cache, it > fails at random places? Yes. If the first thing I do after boot is "echo mem > /sys/power/state", then how can tools like dmesg, make, gcc, cat and even ls be in the cache? -- There are only 10 kinds of people in this world, those that understand binary and those that don't. http://www.kroon.co.za/ |
|
From: Jaco Kroon <jaco@kr...> - 2005-12-24 12:41:46
|
Pavel Machek wrote: > Hi! > > >>>>>Okay, what *other* patches do you have installed? What kernel are you >>>>>running? 2.6.15-rc6? >>>> >>>>I'm trying with 2.6.14.3, but I've got 2.6.15rc5 available here (can >>>>always get the VI patch to rc6). Was intending to run the acpi_include >>>>patch, but since that is a standard option in 2.6.14.x I never actually >>>>pulled in that patch, so no other patches and I've backed out suspend2 >>>>now. Will also give 15rc6 a go in the morning. >>> >>>rc5 should be good enough. >> >>Same problem. SysRq+T reveals that the newly spawned process is getting >>stuck in: >> >>ide_do_request+0x18a/0x3c5 >>io_schedule+0xe/0x16 >>sync_page+0x3e/0x4b >>__wait_on_bit_lock+0x41/0x61 >>sync_page+0x0/0x4b >>__lock_page+0x9d/0xb1 >>wake_bit_function+0x0/0x55 >>wake_bit_function+0x0/0x55 >>do_generic_mapping_read+0x335/0x7fd >>__generic_file_aio_read+0x19d/0x203 >>file_read_actor+0x0/0xfa >>generic_file_read+0xba/0xd8 >>autoremove_wake_function+0x0/0x57 >>vfs_read+0x1a5/0x1aa >>kernel_read+0x50/0x5f >>prepare_binprm+0xd8/0x103 >>do_execve+0xfe/0x203 >>sys_execve+0x3c/0x6f >>sysenter_past_esp+0x54/0x75 >> >>Second run round the first command I issued worked fine, as did cd to >>/usr/src/linux, but running make menuconfig failed. This time the stack >>trace was considerably longer (I'm not going to type that over). The >>top two calls are the same, but it comes in from sync_buffer, >>__wait_on_bit, sync_buffer, sync_buffer, out_of_line_wait_on_bit, >>wake_bit_function, wakebit_function, and so forth. A quick scan of the >>VI between rc5 and rc6 doesn't reveal any changes that could possibly >>affect this (I'm going to patch to rc6 in any case). >> >>Could it be a bug in reiserfs? I have run a fsck but no errors were >>found, so I presume the fs is still in tact. > > Seife is right, this looks like an ide problem. And the fact that > autorepeat does not work for you may mean something bad with > interrupts. Can you try "noapic"? See my other mail. >>>>Will do if I get it working. more-or-less is simply not good enough (or >>>>should I just make a note there?). >>> >>>It is good enough for video.txt. It describes how to get _video_ >>>working, and video works just ok for you. >> >>You should have received the patch. > > I don't see it here. Can you just attach it to this discussion? It > should be small enough... http://sourceforge.net/mailarchive/forum.php?thread_id=9313913&forum_id=6102 -- There are only 10 kinds of people in this world, those that understand binary and those that don't. http://www.kroon.co.za/ |
|
From: Jaco Kroon <jaco@kr...> - 2005-12-24 12:33:36
|
Pavel Machek wrote: > Hi! > > >>>I have a Vaio which has the same ide problem (at least I think so): >>>after resume, all processes wishing to access the disk hang, >>>dmesg shows lots of "hda: lost interrupt" messages. >>>However, doing a "hdparm -w /dev/hda" after resume makes everything >>>work again. >>> >> >>>From the man page: >> >> -w Perform a device reset (DANGEROUS). Do NOT use this >>option. It >> exists for unlikely situations where a reboot might >>otherwise be >> required to get a confused drive back into a useable state. >> >>Ok. I don't have really important data on the notebook atm (all backed >>up for obvious reasons). So I gave this a try. It causes the kernel to >>crash entirely. No more SysRq. No OOPS. Nothing. It outputs a single >>string namely "/dev/hda:" and then dies. > > > Try verifying that your interrupts work after resume. (I assume we are > still talking suspend-to-RAM here, and that you got suspend-to-disk to > more or less work?) Do cat /proc/interrupts; sleep 10; cat > /proc/interrupts both before and after suspend. I presume you're looking for ide0 and ide1 interrupts, yes, after suspending to ram twice the command showed that interrupt 14 (ide0) increased from 994 to 1011 and for 15 (ide1) it stayed at 24. My hdd is on hda so that'll be on ide0, dvd-rw is on hdc or ide1. The interrupt counts for cascade (irq 2), rtc (irq 8) and acpi (irq 9) stayed constant though, at 0, 2 and 4 respectively. No NMI or ERR conditions were ever signaled. Now, with APIC, but no IO-APIC there is a bug notice during resume. Going to type it over (from dmesg): Back to C! Debug: sleeping function called from invalid context at mm/slab.c:2472 in_atomic():0, irqs_disabled():1 __might_sleep+0x9e/0xa6 acpi_os_allocate+0x15/0x26 kmem_cache_alloc+0x95/0xad acpi_ut_callocate+0x37/0x79 acpi_os_acquire_object+0xf/0x3c acpi_ut_allocate_object_desc_dbg+0xc/0x49 acpi_ut_create_internal_object_dbg+0x18/0x6d acpi_rs_set_srs_method_data+0x41/0xc kmem_cache_alloc+0x6d/0xad acpi_pci_link_set+0x4c/0x1ad acpi_pci_link_set+0x126/0x1ad acpi_pci_link_resume+0x22/0x28 irqrouters_resume+0x25/0x38 __sysdev_resume+0x3d/0x71 sysdev_resume+0x38/0x5e device_power_up+0x5/0xa suspend_enter+0x36/0x54 enter_state+0x49/0x8a state_store+0x9a/0xad subsys_attr_store+0x37/0x40 flush_write_buffer+0x3e/0x4a sysfs_write_file+0x6b/0x92 vfs_write+0x1a5/0x1aa sys_write+0x51/0x80 sysenter_past_esp+0x54/0x75 ACPI: PCI Interrupt 0000:00:14.1[A] -> Link [LNK0] -> GSI 11 (level, low) -> IRQ 11 ACPI: PCI Interrupt 0000:02:04.0[A] -> Link [LNK0] -> GSI 11 (level, low) -> IRQ 11 Restarting tasks... done Both cases looks identical. /proc/interrupts doesn't list 11 as an interrupt ?!? Also, this time round the auto-repeat on the keys is working again after resume. In fact, everything seems to be working. Just that debug stacktrace that bothers me. Oh, and my console blanking time also seems to get lost but I can fix that with the help of echo and /dev/tty*. Anyhow, suspended twice to ram now in succession, make cleaned and rebuilt the kernel, installed it, and the only thing that even suggests there is a glitch is that trace. Looks like I need APIC on and IO-APIC off. Any explanations very welcome: and don't tell me the IO-APIC is buggy - I've been running with both those options on for as long as I've had this notebook now. Jaco -- There are only 10 kinds of people in this world, those that understand binary and those that don't. http://www.kroon.co.za/ |
|
From: Pavel Machek <pavel@su...> - 2005-12-24 12:22:46
|
Hi! > Damn. I just thought I solved it. I disabled the APIC and tried again. > This time round I managed to re-enable APIC in the kernel source > (without IO-APIC) and _recompile_ it entirely. Only upon issueing "make > install modules_install" did it pop. > > Sequence was something like: > > echo mem > /sys/power/state > cd /usr/src/linux > make menuconfig > make menuconfig > echo mem > /sys/power/state > make menuconfig > --> re-enable APIC but not IO-APIC > make > make install modules_install > ->> pop. When copying the image from the source directory to /boot. > > This is beginning to sound more and more like some obscure > race-condition if you ask me. I would be surprised if that was the case. Are you sure it is not just "disk does not work after resume", and depending of stuff in cache, it fails at random places? Pavel -- Thanks, Sharp! |
|
From: <cthulhufhtagn@sp...> - 2005-12-24 12:01:34
|
I'm geting this four errors which I suppose are caused by that objects bein=
g=0D
defined before (never heard about the "ACPI language" 'till today).=0D
----------------=0D
# ./iasl -tc dsdt.dsl=0D
=0D
Intel ACPI Component Architecture=0D
ASL Optimizing Compiler / AML Disassembler version 20030228 [Feb 28 2003]=
=0D
Copyright (C) 2000 - 2003 Intel Corporation=0D
Supports ACPI Specification Revision 2.0b=0D
=0D
dsdt.dsl 370: If (LEqual (And (PDC0, 0x0A), 0x0A))=0D
Error 1022 - Object does not exist ^ (PDC0)=0D
=0D
dsdt.dsl 375: If (LEqual (And (PDC1, 0x0A), 0x0A))=0D
Error 1022 - Object does not exist ^ (PDC1)=0D
=0D
dsdt.dsl 3936: Z003,=0D
Error 1022 - ^ Object does not exist (Z003)=0D
=0D
dsdt.dsl 3937: Z003,=0D
Error 1022 - ^ Object does not exist (Z003)=0D
=0D
ASL Input: dsdt.dsl - 4240 lines, 137275 bytes, 1880 keywords=0D
Compilation complete. 4 Errors, 0 Warnings, 0 Remarks, 546 Optimizations=0D
------------------=0D
=0D
I fixed the Z003 deleting that two entries, which I think is tricky. Couldn=
't fix=0D
the PDCs after researching on Google for almost an hour. This are the fragm=
ents=0D
of code:=0D
=0D
-------------------=0D
Method (PNOT, 0, Serialized)=0D
{=0D
If (HTTE)=0D
{=0D
If (LEqual (And (PDC0, 0x0A), 0x0A))=0D
{=0D
Notify (\_PR.CPU0, 0x80)=0D
}=0D
=0D
If (LEqual (And (PDC1, 0x0A), 0x0A))=0D
{=0D
Notify (\_PR.CPU1, 0x80)=0D
}=0D
}=0D
Else=0D
{=0D
Notify (\_PR.CPU0, 0x80)=0D
Sleep (0x64)=0D
Notify (\_PR.CPU0, 0x81)=0D
}=0D
}=0D
---------------------=0D
=0D
And:=0D
=0D
---------------------=0D
Device (BAT1)=0D
{=0D
Name (_HID, EisaId ("PNP0C0A"))=0D
Name (_UID, 0x01)=0D
Name (CBTI, 0x00)=0D
Name (PBTI, 0x00)=0D
Name (BTIN, 0x00)=0D
Name (BTCH, 0x00)=0D
Name (BIFI, 0x00)=0D
Name (SEL0, 0x00)=0D
Name (BCRI, 0x00)=0D
Name (PBIF, Package (0x0D)=0D
{=0D
0x01,=0D
0x1130,=0D
0x1130,=0D
0x01,=0D
0x2B5C,=0D
0x012C,=0D
0x84,=0D
0x20,=0D
0x20,=0D
"PA34200-1BRS",=0D
"11 ",=0D
"11 ",=0D
"TOSHIBA "=0D
})=0D
Name (PBST, Package (0x04)=0D
{=0D
0x00,=0D
Z003,=0D
Z003,=0D
0x2710=0D
})=0D
Name (ERRC, 0x00)=0D
Name (_PCL, Package (0x01)=0D
{=0D
\_SB=0D
})=0D
--------------------=0D
=0D
I'm not sure about I'm giving enough info, and didn't think posting the who=
le=0D
archive was very polite.=0D
=0D
Has anyone a idea on how to fix it? If you need the full *dsl to give me so=
me=0D
advice, tell me and I'll send it off the list. I'm starting to learn C, so =
please=0D
don't blame me for not knowing how to programm in such a low level thingy. =
I=0D
would appreciate it if you could give me some links to an introduction to "=
ACPI=0D
programming", too.=0D
=0D
Thank you very much!=0D
|
|
From: Jaco Kroon <jaco@kr...> - 2005-12-24 12:00:42
|
Jaco Kroon wrote: > Stefan Seyfried wrote: >>>Same problem. SysRq+T reveals that the newly spawned process is getting >>>stuck in: >>> >>>ide_do_request+0x18a/0x3c5 >>>io_schedule+0xe/0x16 [--snip--] >>To my untrained eye this looks like an IDE suspend / resume problem. >>Maybe another machine that needs those ACPI methods for the IDE drives >>badly :-( > > > To mine as well. _WAK? Some other methods? I'm posting my DSDT at > http://www.kroon.co.za/downloads/toshiba_p10-792/ now. If somebody else > can take a look it just might reveal something I'm missing. Damn. I just thought I solved it. I disabled the APIC and tried again. This time round I managed to re-enable APIC in the kernel source (without IO-APIC) and _recompile_ it entirely. Only upon issueing "make install modules_install" did it pop. Sequence was something like: echo mem > /sys/power/state cd /usr/src/linux make menuconfig make menuconfig echo mem > /sys/power/state make menuconfig --> re-enable APIC but not IO-APIC make make install modules_install ->> pop. When copying the image from the source directory to /boot. This is beginning to sound more and more like some obscure race-condition if you ask me. Jaco -- There are only 10 kinds of people in this world, those that understand binary and those that don't. http://www.kroon.co.za/ |
|
From: Pavel Machek <pavel@su...> - 2005-12-24 11:48:26
|
Hi! > > I have a Vaio which has the same ide problem (at least I think so): > > after resume, all processes wishing to access the disk hang, > > dmesg shows lots of "hda: lost interrupt" messages. > > However, doing a "hdparm -w /dev/hda" after resume makes everything > > work again. > > > > >From the man page: > > -w Perform a device reset (DANGEROUS). Do NOT use this > option. It > exists for unlikely situations where a reboot might > otherwise be > required to get a confused drive back into a useable state. > > Ok. I don't have really important data on the notebook atm (all backed > up for obvious reasons). So I gave this a try. It causes the kernel to > crash entirely. No more SysRq. No OOPS. Nothing. It outputs a single > string namely "/dev/hda:" and then dies. Try verifying that your interrupts work after resume. (I assume we are still talking suspend-to-RAM here, and that you got suspend-to-disk to more or less work?) Do cat /proc/interrupts; sleep 10; cat /proc/interrupts both before and after suspend. Pavel -- Thanks, Sharp! |
|
From: Pavel Machek <pavel@su...> - 2005-12-24 11:46:50
|
Hi! > >>>Okay, what *other* patches do you have installed? What kernel are you > >>>running? 2.6.15-rc6? > >> > >>I'm trying with 2.6.14.3, but I've got 2.6.15rc5 available here (can > >>always get the VI patch to rc6). Was intending to run the acpi_include > >>patch, but since that is a standard option in 2.6.14.x I never actually > >>pulled in that patch, so no other patches and I've backed out suspend2 > >>now. Will also give 15rc6 a go in the morning. > > > > rc5 should be good enough. > > Same problem. SysRq+T reveals that the newly spawned process is getting > stuck in: > > ide_do_request+0x18a/0x3c5 > io_schedule+0xe/0x16 > sync_page+0x3e/0x4b > __wait_on_bit_lock+0x41/0x61 > sync_page+0x0/0x4b > __lock_page+0x9d/0xb1 > wake_bit_function+0x0/0x55 > wake_bit_function+0x0/0x55 > do_generic_mapping_read+0x335/0x7fd > __generic_file_aio_read+0x19d/0x203 > file_read_actor+0x0/0xfa > generic_file_read+0xba/0xd8 > autoremove_wake_function+0x0/0x57 > vfs_read+0x1a5/0x1aa > kernel_read+0x50/0x5f > prepare_binprm+0xd8/0x103 > do_execve+0xfe/0x203 > sys_execve+0x3c/0x6f > sysenter_past_esp+0x54/0x75 > > Second run round the first command I issued worked fine, as did cd to > /usr/src/linux, but running make menuconfig failed. This time the stack > trace was considerably longer (I'm not going to type that over). The > top two calls are the same, but it comes in from sync_buffer, > __wait_on_bit, sync_buffer, sync_buffer, out_of_line_wait_on_bit, > wake_bit_function, wakebit_function, and so forth. A quick scan of the > VI between rc5 and rc6 doesn't reveal any changes that could possibly > affect this (I'm going to patch to rc6 in any case). > > Could it be a bug in reiserfs? I have run a fsck but no errors were > found, so I presume the fs is still in tact. Seife is right, this looks like an ide problem. And the fact that autorepeat does not work for you may mean something bad with interrupts. Can you try "noapic"? > >>Will do if I get it working. more-or-less is simply not good enough (or > >>should I just make a note there?). > > > > It is good enough for video.txt. It describes how to get _video_ > > working, and video works just ok for you. > > You should have received the patch. I don't see it here. Can you just attach it to this discussion? It should be small enough... Pavel -- Thanks, Sharp! |
|
From: Jaco Kroon <jaco@kr...> - 2005-12-24 11:20:09
|
Manuel Lauss wrote:
> Jaco Kroon wrote:
>
>
>>ide_do_request+0x18a/0x3c5
>>io_schedule+0xe/0x16
>>sync_page+0x3e/0x4b
>>__wait_on_bit_lock+0x41/0x61
>>sync_page+0x0/0x4b
>>__lock_page+0x9d/0xb1
>>wake_bit_function+0x0/0x55
>>wake_bit_function+0x0/0x55
>>do_generic_mapping_read+0x335/0x7fd
>>__generic_file_aio_read+0x19d/0x203
>>file_read_actor+0x0/0xfa
>>generic_file_read+0xba/0xd8
>>autoremove_wake_function+0x0/0x57
>>vfs_read+0x1a5/0x1aa
>>kernel_read+0x50/0x5f
>>prepare_binprm+0xd8/0x103
>>do_execve+0xfe/0x203
>>sys_execve+0x3c/0x6f
>>sysenter_past_esp+0x54/0x75
>>
>>Second run round the first command I issued worked fine, as did cd to
>>/usr/src/linux, but running make menuconfig failed. This time the stack
>>trace was considerably longer (I'm not going to type that over). The
>>top two calls are the same, but it comes in from sync_buffer,
>>__wait_on_bit, sync_buffer, sync_buffer, out_of_line_wait_on_bit,
>>wake_bit_function, wakebit_function, and so forth. A quick scan of the
>>VI between rc5 and rc6 doesn't reveal any changes that could possibly
>>affect this (I'm going to patch to rc6 in any case).
>
>
> I have a Vaio which has the same ide problem (at least I think so):
> after resume, all processes wishing to access the disk hang,
> dmesg shows lots of "hda: lost interrupt" messages.
> However, doing a "hdparm -w /dev/hda" after resume makes everything
> work again.
>
>From the man page:
-w Perform a device reset (DANGEROUS). Do NOT use this
option. It
exists for unlikely situations where a reboot might
otherwise be
required to get a confused drive back into a useable state.
Ok. I don't have really important data on the notebook atm (all backed
up for obvious reasons). So I gave this a try. It causes the kernel to
crash entirely. No more SysRq. No OOPS. Nothing. It outputs a single
string namely "/dev/hda:" and then dies.
Jaco
--
There are only 10 kinds of people in this world,
those that understand binary and those that don't.
http://www.kroon.co.za/
|
|
From: Manuel Lauss <mano@ro...> - 2005-12-24 10:45:03
|
Jaco Kroon wrote: > ide_do_request+0x18a/0x3c5 > io_schedule+0xe/0x16 > sync_page+0x3e/0x4b > __wait_on_bit_lock+0x41/0x61 > sync_page+0x0/0x4b > __lock_page+0x9d/0xb1 > wake_bit_function+0x0/0x55 > wake_bit_function+0x0/0x55 > do_generic_mapping_read+0x335/0x7fd > __generic_file_aio_read+0x19d/0x203 > file_read_actor+0x0/0xfa > generic_file_read+0xba/0xd8 > autoremove_wake_function+0x0/0x57 > vfs_read+0x1a5/0x1aa > kernel_read+0x50/0x5f > prepare_binprm+0xd8/0x103 > do_execve+0xfe/0x203 > sys_execve+0x3c/0x6f > sysenter_past_esp+0x54/0x75 > > Second run round the first command I issued worked fine, as did cd to > /usr/src/linux, but running make menuconfig failed. This time the stack > trace was considerably longer (I'm not going to type that over). The > top two calls are the same, but it comes in from sync_buffer, > __wait_on_bit, sync_buffer, sync_buffer, out_of_line_wait_on_bit, > wake_bit_function, wakebit_function, and so forth. A quick scan of the > VI between rc5 and rc6 doesn't reveal any changes that could possibly > affect this (I'm going to patch to rc6 in any case). I have a Vaio which has the same ide problem (at least I think so): after resume, all processes wishing to access the disk hang, dmesg shows lots of "hda: lost interrupt" messages. However, doing a "hdparm -w /dev/hda" after resume makes everything work again. -- Manuel Lauss |
|
From: Jaco Kroon <jaco@kr...> - 2005-12-24 09:12:06
|
Stefan Seyfried wrote: > On Sat, Dec 24, 2005 at 10:45:58AM +0200, Jaco Kroon wrote: > >>Pavel Machek wrote: >> >>>rc5 should be good enough. >> >>Same problem. SysRq+T reveals that the newly spawned process is getting >>stuck in: >> >>ide_do_request+0x18a/0x3c5 >>io_schedule+0xe/0x16 >>sync_page+0x3e/0x4b >>__wait_on_bit_lock+0x41/0x61 >>sync_page+0x0/0x4b >>__lock_page+0x9d/0xb1 >>wake_bit_function+0x0/0x55 >>wake_bit_function+0x0/0x55 >>do_generic_mapping_read+0x335/0x7fd >>__generic_file_aio_read+0x19d/0x203 >>file_read_actor+0x0/0xfa >>generic_file_read+0xba/0xd8 >>autoremove_wake_function+0x0/0x57 >>vfs_read+0x1a5/0x1aa >>kernel_read+0x50/0x5f >>prepare_binprm+0xd8/0x103 >>do_execve+0xfe/0x203 >>sys_execve+0x3c/0x6f >>sysenter_past_esp+0x54/0x75 > > > To my untrained eye this looks like an IDE suspend / resume problem. > Maybe another machine that needs those ACPI methods for the IDE drives > badly :-( To mine as well. _WAK? Some other methods? I'm posting my DSDT at http://www.kroon.co.za/downloads/toshiba_p10-792/ now. If somebody else can take a look it just might reveal something I'm missing. dsdt.dat (orriginal DSDT) dsdt.dsl (my so-far edited version) dsdt.dsl.orig (orriginal decompiled version). Hmm, just noticed that iasl still creates a .hex file even though it gives me 13 errors! Including into kernel ... same issue. Jaco -- There are only 10 kinds of people in this world, those that understand binary and those that don't. http://www.kroon.co.za/ |
|
From: Stefan Seyfried <seife@su...> - 2005-12-24 08:54:17
|
On Sat, Dec 24, 2005 at 10:45:58AM +0200, Jaco Kroon wrote: > Pavel Machek wrote: > > rc5 should be good enough. >=20 > Same problem. SysRq+T reveals that the newly spawned process is gettin= g > stuck in: >=20 > ide_do_request+0x18a/0x3c5 > io_schedule+0xe/0x16 > sync_page+0x3e/0x4b > __wait_on_bit_lock+0x41/0x61 > sync_page+0x0/0x4b > __lock_page+0x9d/0xb1 > wake_bit_function+0x0/0x55 > wake_bit_function+0x0/0x55 > do_generic_mapping_read+0x335/0x7fd > __generic_file_aio_read+0x19d/0x203 > file_read_actor+0x0/0xfa > generic_file_read+0xba/0xd8 > autoremove_wake_function+0x0/0x57 > vfs_read+0x1a5/0x1aa > kernel_read+0x50/0x5f > prepare_binprm+0xd8/0x103 > do_execve+0xfe/0x203 > sys_execve+0x3c/0x6f > sysenter_past_esp+0x54/0x75 To my untrained eye this looks like an IDE suspend / resume problem. Maybe another machine that needs those ACPI methods for the IDE drives badly :-( --=20 Stefan Seyfried \ "I didn't want to write for pay. I QA / R&D Team Mobile Devices \ wanted to be paid for what I write." SUSE LINUX Products GmbH, N=FCrnberg \ -- Leonard Cohe= n |
|
From: Jaco Kroon <jaco@kr...> - 2005-12-24 08:44:37
|
Pavel Machek wrote: > Hi! > > >>>Okay, what *other* patches do you have installed? What kernel are you >>>running? 2.6.15-rc6? >> >>I'm trying with 2.6.14.3, but I've got 2.6.15rc5 available here (can >>always get the VI patch to rc6). Was intending to run the acpi_include >>patch, but since that is a standard option in 2.6.14.x I never actually >>pulled in that patch, so no other patches and I've backed out suspend2 >>now. Will also give 15rc6 a go in the morning. > > rc5 should be good enough. Same problem. SysRq+T reveals that the newly spawned process is getting stuck in: ide_do_request+0x18a/0x3c5 io_schedule+0xe/0x16 sync_page+0x3e/0x4b __wait_on_bit_lock+0x41/0x61 sync_page+0x0/0x4b __lock_page+0x9d/0xb1 wake_bit_function+0x0/0x55 wake_bit_function+0x0/0x55 do_generic_mapping_read+0x335/0x7fd __generic_file_aio_read+0x19d/0x203 file_read_actor+0x0/0xfa generic_file_read+0xba/0xd8 autoremove_wake_function+0x0/0x57 vfs_read+0x1a5/0x1aa kernel_read+0x50/0x5f prepare_binprm+0xd8/0x103 do_execve+0xfe/0x203 sys_execve+0x3c/0x6f sysenter_past_esp+0x54/0x75 Second run round the first command I issued worked fine, as did cd to /usr/src/linux, but running make menuconfig failed. This time the stack trace was considerably longer (I'm not going to type that over). The top two calls are the same, but it comes in from sync_buffer, __wait_on_bit, sync_buffer, sync_buffer, out_of_line_wait_on_bit, wake_bit_function, wakebit_function, and so forth. A quick scan of the VI between rc5 and rc6 doesn't reveal any changes that could possibly affect this (I'm going to patch to rc6 in any case). Could it be a bug in reiserfs? I have run a fsck but no errors were found, so I presume the fs is still in tact. Right, I've done this for userspace programs linked with -rdynamic before, but how do I convert those hexadecimal offsets into line numbers for the kernel? Just point me at the docs to RTFM so that I can RTFS. The keyboard auto-repeat still breaks. If it's possible to re-enable this using some command-line tool (which I'm not aware off) then I can just re-enable that manually from a suspend/resume script. >>>>This feels like a post-wakeup racecondition to me... Disabling the big >>>>kernel lock preemption think again... yes, seems to be working better >>>>now. Suspending to ram and then to disk still fails. (resume from mem >>>>works, can do make menuconfig - a few times - and then it starts >>>>suspend-to-disk process and then just hangs). >>> >>>So... there's no module to blame? I do have CONFIG_PREEMPT=y and >>>CONFIG_PREEMPT_BKL=y set here, but there were some problems with those >>>before, so keeping it disabled may be wise. >> >>I've also found that I forgot to disable registers. Neither made a >>difference though. > > CONFIG_REGPARM? Argh. It was too early in the morning (late at night?). Yes. >>>Ouch and now that suspend-to-ram more or less works for you, can you >>>submit update to Doc*/power/video.txt? >> >>Will do if I get it working. more-or-less is simply not good enough (or >>should I just make a note there?). > > It is good enough for video.txt. It describes how to get _video_ > working, and video works just ok for you. You should have received the patch. Jaco -- There are only 10 kinds of people in this world, those that understand binary and those that don't. http://www.kroon.co.za/ |
|
From: Jaco Kroon <jkroon@kr...> - 2005-12-24 08:07:21
|
This patch adds the Toshiba Satellite P10-792 to the list of systems where video can be made to work during suspend-to-ram. Signed-of-by: Jaco Kroon <jaco@...> --- linux/Documentation/power/video.txt.orig 2005-12-24 09:57:04.000000000 +0200 +++ linux/Documentation/power/video.txt 2005-12-24 09:57:15.000000000 +0200 @@ -134,6 +134,7 @@ Toshiba Satellite 4080XCDT s3_mode (3) Toshiba Satellite 4090XCDT ??? (*) Toshiba Satellite P10-554 s3_bios,s3_mode (4)(****) +Toshiba Satellite P10-792 s3_bios,s3_mode (4)(****) Toshiba M30 (2) xor X with nvidia driver using internal AGP Uniwill 244IIO ??? (*) |
|
From: Pavel Machek <pavel@su...> - 2005-12-24 00:38:32
|
Hi! > > Okay, what *other* patches do you have installed? What kernel are you > > running? 2.6.15-rc6? > > I'm trying with 2.6.14.3, but I've got 2.6.15rc5 available here (can > always get the VI patch to rc6). Was intending to run the acpi_include > patch, but since that is a standard option in 2.6.14.x I never actually > pulled in that patch, so no other patches and I've backed out suspend2 > now. Will also give 15rc6 a go in the morning. rc5 should be good enough. > >>This feels like a post-wakeup racecondition to me... Disabling the big > >>kernel lock preemption think again... yes, seems to be working better > >>now. Suspending to ram and then to disk still fails. (resume from mem > >>works, can do make menuconfig - a few times - and then it starts > >>suspend-to-disk process and then just hangs). > > > > So... there's no module to blame? I do have CONFIG_PREEMPT=y and > > CONFIG_PREEMPT_BKL=y set here, but there were some problems with those > > before, so keeping it disabled may be wise. > > I've also found that I forgot to disable registers. Neither made a > difference though. CONFIG_REGPARM? > > Ouch and now that suspend-to-ram more or less works for you, can you > > submit update to Doc*/power/video.txt? > > Will do if I get it working. more-or-less is simply not good enough (or > should I just make a note there?). It is good enough for video.txt. It describes how to get _video_ working, and video works just ok for you. Pavel -- Thanks, Sharp! |
|
From: Jaco Kroon <jaco@kr...> - 2005-12-24 00:34:25
|
Pavel Machek wrote: > Hi! > > >>... and I didn't get the rest cause as soon as I accidentally pressed a >>key it powered down ... >> >>It halted directly after "Shutting down hda" (can't remember the exact >>message). Powering up resuming worked just fine. Including issues I >>had with suspend-to-ram (described below). > > Okay, what *other* patches do you have installed? What kernel are you > running? 2.6.15-rc6? I'm trying with 2.6.14.3, but I've got 2.6.15rc5 available here (can always get the VI patch to rc6). Was intending to run the acpi_include patch, but since that is a standard option in 2.6.14.x I never actually pulled in that patch, so no other patches and I've backed out suspend2 now. Will also give 15rc6 a go in the morning. >>This happened at least twice. Having to hit some key to make it go away >>is probably not the biggest issue I've had in my life, I guess if need >>be I can live with that. > > I have seen that before with acpi vgapost or something like > that... Strange. Can you insert printks to find out what is going on? In the morning. >>This feels like a post-wakeup racecondition to me... Disabling the big >>kernel lock preemption think again... yes, seems to be working better >>now. Suspending to ram and then to disk still fails. (resume from mem >>works, can do make menuconfig - a few times - and then it starts >>suspend-to-disk process and then just hangs). > > So... there's no module to blame? I do have CONFIG_PREEMPT=y and > CONFIG_PREEMPT_BKL=y set here, but there were some problems with those > before, so keeping it disabled may be wise. I've also found that I forgot to disable registers. Neither made a difference though. > Ouch and now that suspend-to-ram more or less works for you, can you > submit update to Doc*/power/video.txt? Will do if I get it working. more-or-less is simply not good enough (or should I just make a note there?). >>If I posted my DSDT, could you possibly take a look? It seems that the >>compiler error message doesn't mean what it says. Under certain >>conditions it will complain if a certain string is set but some index is >>not. And I don't know enough with regards to DSL to be able to spot the >>errors. > > I'm not DSDT expert, sorry. (And problem is probably not in DSDT > anyway). Figured. Thanks for you patience on this. Jaco -- There are only 10 kinds of people in this world, those that understand binary and those that don't. http://www.kroon.co.za/ |
|
From: Pavel Machek <pavel@su...> - 2005-12-24 00:25:55
|
Hi! > ... and I didn't get the rest cause as soon as I accidentally pressed a > key it powered down ... > > It halted directly after "Shutting down hda" (can't remember the exact > message). Powering up resuming worked just fine. Including issues I > had with suspend-to-ram (described below). Okay, what *other* patches do you have installed? What kernel are you running? 2.6.15-rc6? > This happened at least twice. Having to hit some key to make it go away > is probably not the biggest issue I've had in my life, I guess if need > be I can live with that. I have seen that before with acpi vgapost or something like that... Strange. Can you insert printks to find out what is going on? > This feels like a post-wakeup racecondition to me... Disabling the big > kernel lock preemption think again... yes, seems to be working better > now. Suspending to ram and then to disk still fails. (resume from mem > works, can do make menuconfig - a few times - and then it starts > suspend-to-disk process and then just hangs). So... there's no module to blame? I do have CONFIG_PREEMPT=y and CONFIG_PREEMPT_BKL=y set here, but there were some problems with those before, so keeping it disabled may be wise. Ouch and now that suspend-to-ram more or less works for you, can you submit update to Doc*/power/video.txt? > If I posted my DSDT, could you possibly take a look? It seems that the > compiler error message doesn't mean what it says. Under certain > conditions it will complain if a certain string is set but some index is > not. And I don't know enough with regards to DSL to be able to spot the > errors. I'm not DSDT expert, sorry. (And problem is probably not in DSDT anyway). Pavel -- Thanks, Sharp! |
|
From: Jaco Kroon <jaco@kr...> - 2005-12-24 00:05:37
|
Pavel Machek wrote: > Hi! > > >>>But try _minimal config_, first. >> >>Doesn't include CONFIG_NET imho, but kernel/power/ui.h (part of >>suspend2?) doesn't compile without it. I can probably write a patch, >>the problem seems to be that ui_helper_data only gets declared if >>CONFIG_NET is set, but it gets used elsewhere even if CONFIG_NET is >>not set. > > You did not tell me your kernel contains suspend2. Revert those > patches. In-kernel code tends to have less bells/whistles, but seems > more reliable to me. (And it is the only one I can help you with.) Oops. Reverted. Still does the same thing though, doing: # echo shutdown > /sys/power/disk # echo disk > /sys/power/state (then on that special VT): Stopping tasks: =========| Freeing memory... done (0 pages freed) swsusp: Need to copy 10553 pages swsusp: critical section/: done (10595 pages copied) ACPI: PCI Interrupt 0000:00:14: ... and I didn't get the rest cause as soon as I accidentally pressed a key it powered down ... It halted directly after "Shutting down hda" (can't remember the exact message). Powering up resuming worked just fine. Including issues I had with suspend-to-ram (described below). This happened at least twice. Having to hit some key to make it go away is probably not the biggest issue I've had in my life, I guess if need be I can live with that. >>Setting CONFIG_NET works around this problem. >> >>With almost nothing in the kernel though (only what is essential to make >>it boot) suspend-to-ram works. Still suspend-to-disk though. >> >>Guess it's time to go find the module that causes the problem and fix it >>(if I can figure it out). > > Yep ;-). Keep us updated with name of offending module. Actually, I lie. There are weird lockups. I can typically do "echo foo", or "ls", but I for example can't run make, diff or anything funky (mount without any params works but mount -o rw,remount /boot locks up). This may be due to incompatibilities with the running kernel and the installed glibc but I somehow suspect this is not the case. I can also post my kernel config somewhere if that would help. In both cases issues any further suspend/resume commands locks up the system. As in this could also be that caused the lockup after resuming from ram. Indeed. Retrying the suspend-to-ram and then performing a remount works. However, running make menuconfig in /usr/src/linux after that does not. This feels like a post-wakeup racecondition to me... Disabling the big kernel lock preemption think again... yes, seems to be working better now. Suspending to ram and then to disk still fails. (resume from mem works, can do make menuconfig - a few times - and then it starts suspend-to-disk process and then just hangs). Guess I should start by enable many more of those kernel debugging options ..., right now I need some sleep however. If I posted my DSDT, could you possibly take a look? It seems that the compiler error message doesn't mean what it says. Under certain conditions it will complain if a certain string is set but some index is not. And I don't know enough with regards to DSL to be able to spot the errors. Jaco -- There are only 10 kinds of people in this world, those that understand binary and those that don't. http://www.kroon.co.za/ |