Date: Thu, 26 Jan 2006 08:15:26 -0800 From: "Kevin Oberman" <oberman@es.net> To: Manfred Lotz <manfred.lotz@arcor.de> Cc: freebsd-acpi@freebsd.org Subject: Re: suspend/resume event Message-ID: <20060126161526.EDF304503E@ptavv.es.net> In-Reply-To: Your message of "Thu, 26 Jan 2006 14:30:40 %2B0100." <20060126143040.a6b1f796.manfred.lotz@arcor.de>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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. :-(
--
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman@es.net Phone: +1 510 486-8634
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060126161526.EDF304503E>