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 M. <pa...@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: <cth...@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 K. <ja...@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 M. <pa...@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 M. <pa...@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 K. <ja...@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 L. <ma...@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 K. <ja...@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 S. <se...@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 K. <ja...@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 K. <jk...@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 <ja...@kr...> --- 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 M. <pa...@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 K. <ja...@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 M. <pa...@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 K. <ja...@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/ |
From: Jaco K. <ja...@kr...> - 2005-12-23 23:58:03
|
Matthew Garrett wrote: > On Fri, Dec 23, 2005 at 08:44:34AM +0200, Jaco Kroon wrote: > > >>LOL! I wish. fglrx is the ati binary drivers (as asked in the response >>from Pavel). According to another friend of mine the answer to this one >>is no. He can suspend/resume his notebook as long as he's using the >>opensource radeon driver and not fglrx. He's not using a P10 though. > > > The latest fglrx should support suspend/resume. I don't think any > distributions include it yet, so you'll have to get it from ati.com. > Sweet. Trust me, upgrading those drivers is almost as important as keeping your system secure. They are probably my worst experience in Linux - matched only by a very weird bug in OpenLDAP which turned out to be a permissions problem caused by udev default permissions of 600 on /dev/urandom (SSL failed to initialise). I'm currently running version 8.20.8 of the ati drivers (On Gentoo - only one way to live Linux: be one with the source). This also seems to be the newest version available - so just maybe I'm lucky. Not that I feel very lucky right at this moment :p. 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: Matthew G. <mj...@sr...> - 2005-12-23 23:25:41
|
On Fri, Dec 23, 2005 at 08:44:34AM +0200, Jaco Kroon wrote: > LOL! I wish. fglrx is the ati binary drivers (as asked in the response > from Pavel). According to another friend of mine the answer to this one > is no. He can suspend/resume his notebook as long as he's using the > opensource radeon driver and not fglrx. He's not using a P10 though. The latest fglrx should support suspend/resume. I don't think any distributions include it yet, so you'll have to get it from ati.com. -- Matthew Garrett | mj...@sr... |
From: Pavel M. <pa...@su...> - 2005-12-23 23:01:57
|
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.) > 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. Pavel -- Thanks, Sharp! |
From: Jaco K. <ja...@kr...> - 2005-12-23 22:56:45
|
Pavel Machek wrote: > 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. 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). >>And that is where it all stops. > > See Doc*/power/swsusp.txt. suspend to disk should be easier to fix. That didn't really teach me anything new. -- 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: Randy.Dunlap <rd...@xe...> - 2005-12-23 21:48:05
|
From: Jae-hyeon Park <jh...@tu...> Identify which device is not power-manageable to make the message more useful. Signed-off-by: Randy Dunlap <rd...@xe...> --- drivers/acpi/bus.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletion(-) --- linux-2615-rc6g4.orig/drivers/acpi/bus.c +++ linux-2615-rc6g4/drivers/acpi/bus.c @@ -198,7 +198,8 @@ int acpi_bus_set_power(acpi_handle handl if (!device->flags.power_manageable) { ACPI_DEBUG_PRINT((ACPI_DB_WARN, - "Device is not power manageable\n")); + "Device '%s' is not power manageable\n", + device->kobj.name)); return_VALUE(-ENODEV); } /* --- |
From: Pavel M. <pa...@su...> - 2005-12-23 17:25:29
|
Hi! > >>I still haven't managed to finish of the resume process. The screen > >>comes back up and console switching works but that is just about where > >>it ends. I don't see any kernel panic messages either. Will RTFM and > >>fool around some more. > > > > RTFM will not help you here, I'm afraid. Try it with minimal kernel > > config. > > Ok, that sucks. This is what I get, one some VT that is not reachable > with Alt+Fx, I get this: > > inu > Back to C! > ACPI: PCI Interrupt 0000:00:14.1[A] -> GSI 16 (level, low) -> IRQ >177 > The inu is in yellow and I presume forms part of the word "Linux". I > get this screen when it comes back, from here I can switch to all twelfe > VTs with Alt+Fx, and back to this screen with Alt+right from tty1. Yep, "Linux" is printed from assembly header. Fortunately your machine gets into C, so you'll not have to debug _that_. You can just debug it using printk(). But try _minimal config_, first. > On tty1 I can type, but that is the only VT. This is also the VT I run > hibernate-ram from. Auto-repeat however does not function. The same > applies when running "echo mem > /sys/power/state" > > When running hibernate it doesn't power down! This seems odd since > powerdown works when going "init 0". Anyhow, the last messages I see is > this: > > Freezing processes > Preparing Image. > Starting to save the image.. > Writing caches... > Doing atormic copy. > Writing kernel & process data... > > And that is where it all stops. See Doc*/power/swsusp.txt. suspend to disk should be easier to fix. Pavel -- Thanks, Sharp! |
From: Jaco K. <ja...@kr...> - 2005-12-23 16:52:48
|
Pavel Machek wrote: > Hi! > > >>>>With regards to the ACPI code though - I've managed to fix all the >>>>warnings and errors, except the one about the ResourceSource error, >>>>which according to the spec is optional but iasl insists it's required. >>>>No idea what I'm going to do about that. Also not sure whether fixing >>>>_WAK to always return a value will actually do something. >>> >>>I do not remember that i would have to fix any DSDT bugs, everything worked >>>with the original DSDT. >> >>There is only really one error that bothers me, and I read somewhere >>that the kernel doesn't look at it's value, and that is the _WAK call >>that doesn't return a value. Unless that of course changed recently. >>And I can't recompile the DSDT due to those ResourceSource required >>errors, which seems to be a bug in iasl. > > > Fix iasl, then ;-). Will try when I get back from the movies. I've seen one other message that mentioned this same error in iasl, can't remember where though. >>I still haven't managed to finish of the resume process. The screen >>comes back up and console switching works but that is just about where >>it ends. I don't see any kernel panic messages either. Will RTFM and >>fool around some more. > > RTFM will not help you here, I'm afraid. Try it with minimal kernel > config. Ok, that sucks. This is what I get, one some VT that is not reachable with Alt+Fx, I get this: inu Back to C! ACPI: PCI Interrupt 0000:00:14.1[A] -> GSI 16 (level, low) -> IRQ 177 The inu is in yellow and I presume forms part of the word "Linux". I get this screen when it comes back, from here I can switch to all twelfe VTs with Alt+Fx, and back to this screen with Alt+right from tty1. On tty1 I can type, but that is the only VT. This is also the VT I run hibernate-ram from. Auto-repeat however does not function. The same applies when running "echo mem > /sys/power/state" When running hibernate it doesn't power down! This seems odd since powerdown works when going "init 0". Anyhow, the last messages I see is this: Freezing processes Preparing Image. Starting to save the image.. Writing caches... Doing atormic copy. Writing kernel & process data... And that is where it all stops. That is all I've managed to become wizer today. Really not particularly usefull I know. Sorry for the noise. -- 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: Sebastian H. <ac...@ko...> - 2005-12-23 13:43:59
|
howdy folks.. * Jaco Kroon <ja...@cs...> [2005-12-23 12:16 +0100]: > Stefan Seyfried wrote: > >On Thu, Dec 22, 2005 at 03:59:26PM +0200, Jaco Kroon wrote: >=20 > LOL! I wish. fglrx is the ati binary drivers (as asked in the response= =20 > from Pavel). According to another friend of mine the answer to this one= =20 > is no. He can suspend/resume his notebook as long as he's using the=20 > opensource radeon driver and not fglrx. He's not using a P10 though. ATI has introduced support for suspension recently, since version 8.19.x or so.=EE=80=80i had good luck in S3+S4 with the latest drivers on Samsung = X20 and IBM T43p. cheers, Sebastian --=20 _ ascii ribbon campaign .oOo. GCSd-s:+aC++ULB+++W++M+PS+++Y+ ( ) X Jeden Tag eine Erisische Tat! / \ =20 |
From: Karol K. <sz...@he...> - 2005-12-23 12:19:38
|
Thus wrote Christian Aichinger: > > Here it goes. Rediffed, also plugs a leak my previous patch introduced. I > > believe it addresses Linus' comments. It's still not a proper fix (see > > below), but I believe it's better than none. > > Best regards, > This will break other hardware as the P30/P35 as well, since there > are some buggy DSDT's out there that return an ACPI_TYPE_BUFFER. I've never seen one, I'd like to look at those if you've got them. Are you sure it's the actual machine code that returns buffers, and not an implicit return of the interpreter? > That's the whole reason why I was testing exactly for > ACPI_TYPE_INTEGER in my patch. I don't really seem to follow: my logic checks for ACPI_TYPE_STRING, and if not found, looks at DSDT signatures. If something different than a string is returned by INIT _and_ the machine isn't a P30/P35 (DSDT sigs) then the defaults are set as in every other case a machine is not recognized by the driver. > My first version was pretty simmilar to yours, until I was told on > acpi-devel that this breaks someone elses hardware (causing it to be > considered as P30/P35, while it isn't). I can dig up the mails if > you want. The original driver behaviour was: ( if INIT returns NULL && DSDT sigs match ) machine is a P30. My patch changes that to ( if INIT returns !ACPI_TYPE_STRING && DSDT sigs match ) machine is a P30. I'd like to see those reports please. Best regards, -- Karol 'sziwan' Kozimor sz...@he... |
From: Christian A. <Gr...@gm...> - 2005-12-23 11:33:47
|
On Thu, Dec 22, 2005 at 06:42:26PM +0100, Karol Kozimor wrote: > Thus wrote Brown, Len: > > Karol, > > Do you have an update of your asus driver in the pipeline > > that addresses this? >=20 > Here it goes. Rediffed, also plugs a leak my previous patch introduced. I > believe it addresses Linus' comments. It's still not a proper fix (see > below), but I believe it's better than none. > Best regards, This will break other hardware as the P30/P35 as well, since there are some buggy DSDT's out there that return an ACPI_TYPE_BUFFER. That's the whole reason why I was testing exactly for ACPI_TYPE_INTEGER in my patch. My first version was pretty simmilar to yours, until I was told on acpi-devel that this breaks someone elses hardware (causing it to be considered as P30/P35, while it isn't). I can dig up the mails if you want. Cheers, Christian |