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 +0000 > > >>>> 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"
