Re: [ACPI] Toshiba Satellite P10

[Jaco K. <ja...@kr...>]

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/