Date: Thu, 26 Jan 2006 11:19:59 -0800 From: Nate Lawson <nate@root.org> To: Kevin Oberman <oberman@es.net> Cc: freebsd-acpi@freebsd.org Subject: Re: suspend/resume event Message-ID: <43D920DF.7020501@root.org> In-Reply-To: <20060126161526.EDF304503E@ptavv.es.net> References: <20060126161526.EDF304503E@ptavv.es.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Kevin Oberman wrote:
>>Date: Thu, 26 Jan 2006 14:30:40 +0100
>>From: Manfred Lotz <manfred.lotz@arcor.de>
>>Sender: owner-freebsd-acpi@freebsd.org
>>
>>On Sat, 21 Jan 2006 20:50:23 -0800
>>Nate Lawson <nate@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?43D920DF.7020501>