On Wed Nov 17 10, Alexander Best wrote:
On Wed Nov 17 10, Alexander Motin wrote:
Alexander Best wrote:
On Wed Nov 17 10, Alexander Motin wrote:
Alexander Best wrote:
On Tue Nov 16 10, Bruce Cran wrote:
On Fri, 22 Oct 2010 10:03:09 +
Alexander Best arun...@freebsd.org wrote:
so how about olivers patch? it will only apply to ata devices so it's
garanteed not to break any other CAM devices (i'm thinking about the
aac controller issue). you could revert your previous shutdown work
and plug olivers patch into CAM. you might want to replace the
combination of flush/standby immediate with sleep.
One problem with the code that's been committed is that the shutdown
event handler doesn't get run during a suspend operation so an
emergency unload still gets done when running acpiconf -s3.
unfortunately i don't think a can help you on that one. acpi never
worked for
me! even 'acpiconf -s1' will hopelessly crash my system. :(
It is not necessary to have fully working suspend to work on this.
Bounce mode should be enough. If bounce is also not working for you - it
definitely should be the first thing to fix.
bounce mode? sorry i'm lost.
sysctl debug.acpi.suspend_bounce=1
It will make system to wake up back immediately after suspending all
devices, instead of transition to requested S-state.
thanks. i'll investigate a little bit regarding this issue. under single user
mode 'acpiconf -s 1' works with and without bounce mode set.
under multi user mode however both modes fail. i've made sure kldstat reports
the same modules loaded both under single and multi user mode so it seems no
module (i suspected nvidia.ko or rtc.ko) is causing the acpi issue in multi
user mode. maybe HAL is causing problems. i'll check that out.
alexander leidinger informd me that the cause for this might be the fact that
the kernel modules might be loaded in single user mode, but they're not being
accessed.
since i read somewhere that snd_hda might be causing problems with acpi i
stopped the musicpd daemon and unloaded snd_hda ans sound. doing 'acpiconf -s1'
didn't stall the system (i set debug.acpi.suspend_bounce=1) and my system came
backup again. so snd_hda/sound are defanetly causing problems for acpi.
however they are not the only modules causing problems. after the system came
back the following message was printed repeatedlyy to the console:
swap_pager: indefinite wait buffer ...
although my usb keyboard was working i couldn't perform certain actions:
1) switching to a differnt tty worked, but i couldn't log in (input was simply
ignored)
2) i could enter chars on ttyv0, but ctrl+alt+del didn't do anything so i had
to do a hard reset.
cheers.
alex
cheers.
alex
--
Alexander Motin
--
a13x
--
a13x
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
