suspend/resume event

Nate Lawson nate at root.org
Thu Jan 26 11:19:52 PST 2006


Kevin Oberman wrote:
>>Date: Thu, 26 Jan 2006 14:30:40 +0100
>>From: Manfred Lotz <manfred.lotz at arcor.de>
>>Sender: owner-freebsd-acpi at freebsd.org
>>
>>On Sat, 21 Jan 2006 20:50:23 -0800
>>Nate Lawson <nate at root.org> wrote:
>>
>>
>>>Manfred Lotz wrote:
>>>
>>>>Hi there,
>>>>With my Samsung X20 1730 suspend /resume works fine when doing
>>>>acpiconf -s 3. I added /etc/rc.d/moused restart in /etc/rc.resume
>>>>and the touchpad mouse gets awake after resuming. That's great.
>>>>
>>>>However when closing the lid (I set hw.acpi.lid_switch_state=S3) and
>>>>then pressing the power button although suspend/resume works
>>>>fine the mouse won't get restarted. This means /etc/rc.resume and
>>>>presumably /etc/rc.suspend won't get called in this case.
>>>>
>>>>Same happen when pressing Fn-ESC the key for suspend.
>>>>
>>>>How can I make sure /etc/rc.suspend as well as /etc/rc.resuem gets
>>>>called in the "non-acpiconf" cases?
>>>
>>>Ok, I committed code to -current to provide a resume event and will
>>>mfc in a week or two.  You can catch it in devd.conf with:
>>>
>>>notify 10 {
>>>         match "system"          "kern";
>>>         match "subsystem"       "power";
>>>	match "type"		"resume";
>>>         action "SOME SCRIPT";
>>>};
>>>
>>
>>Well, I had problems testing it. I actually have a 6.0 STABLE on my
>>Samsung and installed a small 7.0 current system. However, it didn´'t
>>even boot with ACPI. It stumbles over acd0 where it is simply hanging
>>with timeout stuff or so.
>>
>>Could I possible copy some src files to my 6.0 system and rebuild a
>>kernel in order to test it?
> 
> 
> This is a known problem with current. The work-around is to disable
> DMA for the cd. Add hw.ata.ata_dma=0 to /boot/loader.conf.
> 
> While there have been MANY reports of the problem, the ata maintainer
> has no hardware that exhibits the problem, so it is unclear on when a
> fix might appear. :-(

I think the same problem has been reintroduced in the last 4 major ata 
commits, and then fixed a while later.  The problem is that there is a 
phantom slave device on the secondary bus (i.e., drive bay on 
thinkpads).  Putting any dvd or cd drive in that bay triggers the issue.

I got so tired of this recurring that I run RELENG_5 ata on my laptop 
with -current everything else.

-- 
Nate


More information about the freebsd-acpi mailing list