Date: Wed, 23 Jan 2002 03:15:18 +0000 From: John Rochester <john@jrochester.org> To: Greg Black <gjb@gbch.net> Cc: hackers@FreeBSD.ORG Subject: Re: cpu info in userland Message-ID: <3C4E2AC6.9060700@jrochester.org> References: <20020122113351.A25927@Odin.AC.HMC.Edu> <20020122155202.J2872@numachi.com> <3C4DD39B.2050906@rambo.simx.org> <20020122161406.L2872@numachi.com> <nospam-1011750084.73718@bambi.gbch.net> <20020122175631.A83184@blossom.cjclark.org> <nospam-1011751447.75737@bambi.gbch.net>
next in thread | previous in thread | raw e-mail | index | archive | help
This is a multi-part message in MIME format. --------------040102030403080900050609 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Greg Black wrote: > "Crist J . Clark" wrote: > > | On Wed, Jan 23, 2002 at 11:41:24AM +1000, Greg Black wrote: > | > Brian Reichert wrote: > | > > | > | I've seen situations where 'dmesg' (and by extension dmesg.boot) > | > | will contain multiple passes of device probes, etc. I could easily > | > | be imagining this, as I can't think of a mechanism to allow for > | > | it, nor a reason to do it... > | > > | > You're not imagining it -- certainly 4.4-RELEASE does this. > | > | If you drop to single-user and go back to multi-user, dmesg.boot gets > | written again in rc(8). I have patched rc(8) to only write dmesg.boot > | at boot. I should look again at committing that. > > I have never dropped to single-user. But my 4.4-RELEASE laptop > has the records of several full reboots in /var/run/dmesg.boot, > which I really wish it wouldn't ... A simple hack to handle this would be to place the untested attached nodmesg.sh into /usr/local/etc/rc.d and make it executable. This should clear the kernel's message buffer on shutdown. Alternatively you could patch your kernel to disable the attempt to save the message buffer on boot. The function msgbufinit in src/sys/kern/subr_prf.c is the culprit. I would supply a patch but the check has changed since 4.4-RELEASE (it would sometimes fail to detect a corrupt message buffer). Interestingly it appears that only laptops manage to keep the buffer contents between boots - must be something about the memory architecture or BIOS. -- John Rochester Software Architect, Merus Software Ltd. Tel: +44 7870 174690 http://merus.co.uk --------------040102030403080900050609 Content-Type: text/plain; name="nodmesg.sh" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="nodmesg.sh" #!/bin/sh case $1 in stop) sysctl -w kern.msgbuf_clear=1 > /dev/null esac --------------040102030403080900050609-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C4E2AC6.9060700>