On Tue, Apr 17, 2012 at 08:40:37AM -0400, John Baldwin wrote: > Hmm, this has been broken for a long time on HEAD and 9 it seems. However, > there you get compile breakage (as acpi is no longer supported as a module > in 9+) if you try to build a kernel with 'nodevice mem'.
Yes, I am aware. Unfortunately, I am frightened to upgrade to 9.x as I have no confidence that it behaves well on my laptop. I still do not know how to fix 8.x after January which broke suspend/resume for me (EDIT: see below!). > Hmm, mp_machdep.c also breaks. That is probably true on i386 as well, and > has been true even on 7.x. (That is, you can't use 'nodevice mem' and 'SMP' > in the same kernel.) Right, I have appropriate comment about it in my kernel config file. :-) > OTOH, what are you trying to gain by putting mem.ko into a module rather > than part of the base kernel? Do you just want no /dev/mem file or are you > trying to disable all of the MTRR support as well? No, no, nothing other than checking how far can I go in putting everything possible into modules and loading them from /boot/loader.conf. I was not aware it affects MTRR support... > It may be that we need to rethink what goes into mem.ko and have it only > exclude /dev/mem but always leave MTRR support enabled. Hmm, this is interesting. I've been waiting for you to MFC r232742 to RELENG_8 as jkim@ mentioned that these are features that could be responsible for broken suspend/resume on i386. Are you saying that having loading mem.ko as module could affect certain registers restoration, and thus preventing correct resume? I've just tried to zzz/resume several times in a row with latest 8.x kernel with io/mem compiled in. Maybe I am speaking too fast, but guess what: keyboard works now, network service are accessible, bluetooth mouse works, etc. Unbelievable. My stupid "nodevice" gimmick prevented me from having working resume, LOL. I think that if we continue to install mem.ko as module, it should be clearly documented that results of such setup might be quite different from defaults. Thanks for pieces of valuable wisdom John. ./danfe _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
