Re: [ACPI] Toshiba Satellite P10

[Manuel L. <ma...@ro...>]

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