On Wed, 18 Mar 2015 15:30:23 -0600, Warner Losh wrote: > > On Mar 18, 2015, at 10:06 AM, Anthony Jenkins <[email protected]> > > wrote: > > > > On 03/18/2015 11:29 AM, Warner Losh wrote: > >>> On Mar 17, 2015, at 7:02 AM, Anthony Jenkins <[email protected]> > >>> wrote: > >>>> \Where else might ATRTC_VERBOSE be set otherwise? > >>> I'm picturing a (future?) config(5) knob, e.g. > >>> > >>> device atrtc > >>> options ATRTC_VERBOSE=1 > >>> > >>> > >>> so it can be set at compile time. > >> Why not just boot verbose? history has shown too many options like > >> this is hard to use.
You can blame this on me :) I agree about the option not being needed; the way it is you can just set sysctl hw.acpi.atrtc_verbose=0 to quell reports of successful access, if it turns out these are routine on some machines, especially outside of boot/suspend/resume contexts. However I'll still argue that, this being a new gadget and that we could use finding out which vendors want to read or write which locations in CMOS for whatever reason, at least while it's in head, we should log all access by default unless setting atrtc_verbose=0, and in _any_ case we should be logging attempts to R/W out-of-bounds CMOS locations. > > I think I understand what you're saying... I also prefer fewer config(5) > > knobs. So you're suggesting I determine (at runtime) the boot verbose > > setting (kenv(2) or however it's properly done) and dump the > > compile-time verbosity setting? > > if (bootverbose) > do verbose things; > > is how thatÿÿs done. Sure, and maybe successful access could be limited to bootverbose, and we could ask people whose boxes fail to boot/suspend/resume/whatever to boot verbose to reveal such as why Anthony's HP Envy either failed to suspend or immediately resumed - which isn't entirely clear, even with the messages - unless its ACPI AML succeeded in reading minute, hour and weekday, but I have a feeling we may see more of this sort of thing. cheers, Ian _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "[email protected]"
