Re: [ACPI] Toshiba Satellite P10

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

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/