Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 12 Dec 2006 04:41:06 +1100 (EST)
From:      Ian Smith <smithi@nimnet.asn.au>
To:        RJ White <rj@moxad.com>
Cc:        freebsd-mobile@freebsd.org
Subject:   Re: suspend using APM on a Sony PCG-F350 with FreeBSD 6.1
Message-ID:  <Pine.BSF.3.96.1061212030555.9914G-100000@gaia.nimnet.asn.au>
In-Reply-To: <20061210221440.GA49840@server2.moxad.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 10 Dec 2006, RJ White wrote:

 > To add some more data to my problem after trying Ian Smith's suggestions :
 > 
 > Yes, I have :
 > 	apm_enable="YES"
 > 	apmd_enable="YES"
 > set in /etc/rc.conf.
 > During boot, I see :
 > 	Starting apmd.
 > There are no errors in /var/log/messages, only :
 > 	Dec 10 16:46:36 laptop2 kernel: apm0: <APM BIOS> on motherboard
 > 	Dec 10 16:46:36 laptop2 kernel: apm0: found APM BIOS v1.2,
 > 		connected at v1.2
 > 	Dec 10 16:46:45 laptop2 apmd[471]: start
 > 
 > I tried  :
 > 	hw.syscons.sc_no_suspend_vtswitch=1
 > in /etc/sysctl.conf.  It's seen during boot and reports :
 > 	hw.syscons.sc_no_suspend_vtswitch: 0 -> 1
 > 
 > and trying suspend (zzz) from a normal vty (not in X), caused no response.

No clues in /var/log/messages like 'suspend failed' ono?  Running out of
ideas fast here, but it still sounds familiar from when I upgraded from
4.5 to 5.4 a couple of years ago, struggling to remember details .. 

I run apmd -v here for the extra noise to syslog, and quit using zzz
and use the sleep button instead, because with apmd running it runs
rc.suspend, which logs suspend (as well as resume) times to syslog,
unlike using zzz, plus allowing custom kldunloads etc.  Just now:

Dec 12 03:35:40 paqi apmd[444]: apmevent 000a index 6    <-- apmd -v
Dec 12 03:35:41 paqi apm: suspend at 20061212 03:35:41   <-- rc.suspend
Dec 12 03:36:05 paqi kernel: xe0: detached
Dec 12 03:36:05 paqi kernel: wakeup from sleeping state (slept 00:00:18)
Dec 12 03:36:04 paqi apmd[444]: apmevent 0003 index 7    <-- apmd -v
Dec 12 03:36:04 paqi apm: resumed at 20061212 03:36:04   <-- rc.resume
Dec 12 03:36:08 paqi kernel: xe0: <Xircom CreditCard Ethernet+Modem 33.6>
 at port 0x2f8-0x2ff irq 11 function 0 config 2 on pccard0
Dec 12 03:36:08 paqi kernel: xe0: Ethernet address: 00:80:c7:ea:cb:c5

 > When I tried to switch vty's, my cursor disappeared.  Eventually trying
 > another vty switch caused the constant beep and I had to power-cycle.

Been there too .. um, are you loading VESA at all?

 > I then tried it from X, and whether I uncommented the usb entries
 > in /etc/{rc.resume,rc.suspend} or not, as Ian suggested, when I did
 > a zzz, nothing seemed to happen (although 2 out of 3 times, I
 > detected a flicker (1/10 sec) of a 1-pixel horizontal line across
 > my screen), and my mouse went dead.  It is a NON-usb mouse.

zzz is now an sh script, you can play with delays etc which might help,
have it exec rc.suspend instead of running apm -z (both for logging and
the chance to disable usb, VESA, etc), or try adding extra logging .. ?
See apmd.conf, /usr/sbin/zzz, maybe extend machdep.apm_suspend_delay?

In /sys/conf/NOTES there are a couple of mouse items there needed for
_some_ laptops (but more for resume, which hardly matters if you can't
suspend first, but anyway see PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND)

And on reflection and file notes, I'm not entirely certain that setting
hw.syscons.sc_no_suspend_vtswitch=1 in syslog.conf worked just as well
as compiling it into the kernel .. might be worth a desperate try .. 

 > My shell was still ok.  ie: a 'echo hi' worked.
 > But as soon as I tried something that required a disk-access, like running
 > my 'fix-moused' script, or 'who', then it hung.  Trying to switch
 > to another vty caused the constant beep and then I power-cycle again.
 > 
 > Once when my xterm was still active with dead mouse and I was typing,
 > a lower frequency constant beep (I'll call it a boop) happened, until
 > I tried a vty switch, when the constant boop got replaced with a higher
 > frequency constant beep.
 > 
 > thanx for any and all help!

Hope you get some more.  I suppose you do have the latest BIOS version?
What does just 'apm' have to say about capabilities?  That's me done ..

Cheers, Ian




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.1061212030555.9914G-100000>