Re: Recipie for CPU souffle'
In freebsd-questions Digest, Vol 461, Issue 6, Message: 1 (sorry about the threading) On Wed, 3 Apr 2013 15:12:17 +0200 Polytropon free...@edvax.de wrote: On Tue, 02 Apr 2013 19:10:59 -0700, Ronald F. Guilmette wrote: See how the entire ioctl() interface for these device types is completely documented IN THE MAN PAGE? That's the way it should be... None of this rooting around in the sources for something that should have been documented properly, external to the kernel sources. I agree that especially to developers, that sounds logical and very helpful. Seems that manpages do not aim for that goal anymore... Well I can't help but feel this is being taken a tad more seriously than speaker(4) deserves - but it was first committed to FreeBSD 1.0 in '93, 19 years and 9 months ago in what is now SVN revision 4 (!), originally written by Eric Raymond in '90 then modified by ache(@) from 386bsd only clean version, all SYSV stuff removed, suggesting more ancient origins. So I'm not sure this doesn't rather predate 'anymore' :) One's referred to the source in /sys/dev/speaker/speaker.h (a few lines) and it's not a long jump to peek at /sys/dev/speaker/spkr.c http://svnweb.freebsd.org/base/head/sys/dev/speaker/spkr.c?annotate=4 This original one is easier to follow at the bare metal level, with direct inb() and outb() to the PIT (i8254) timer #2, functions later moved into clock.c, making one have to refer to all of 4 source files for the 'machine independent' modern version, though I wonder if anyone not on x86/pc98 is/was actually using spkr(4)? With r177648 5 years ago, phk@ said If somebody cleaned this code up to proper style(9), it could become a great educational starting point for aspiring kernel hackers. 2 months later: Move speaker a lot closer to style(9). It was one of the first devices I could follow, at any rate. It doesn't have to cover everything. But it _should_ completely describe the programatic interface. At least is leaves questions, like stating use the syscalls in order to..., and the reader is left with the most obvious question: _which_ syscalls? Sometimes examples are the best teachers. spkrtest(8) is just a sh script that writes to the device. For more sophisticated use (!) spkr.c is overcommented, if anything, and it's only ~550 well-spaced lines. But like I said, somewher along the line, a lot of man page writers apparently got lazy... VERY lazy. Mmm, and a few man page readers too? It's really not rocket science .. But keep in mind they're still alive! Judging from the manpages of... *cough* can I say this? YOu know, more prominent open source operating systems for desktops... they're usually much worse _if_ there is a manpage. In most cases, there's none. True. And I can usually get little more sense out of info(1) than from windows 'troubleshooter' :) Second order question: Why can't I just pipe a .wav file to the /dev/speaker device file and have it play? Wouldn't that make quite a lot of sense? No, that does not work. Apparently not. Why it doesn't work (or couldn't work) is less clear. The speaker interface to the _PC speaker_ is not a DSP. It's programming is much simpler. The note language that it uses on FreeBSD is much more than other interfaces offer. Better ones have stuff like pitch, duration, turn off. Not to mention staccato, legato, dotted notes - sophisticated stuff! [..] % echo c /dev/speaker Humm... now _that_ is both interesting and enlightening. I actually remember having used something comparable on BASIC, when my brain wasn't fully developed yet. :-) The note language is _from_ BASIC .. do read the source, Luke(s)! echo cdefgabc /dev/speaker It's still a nice interface to generate attention sounds in case you want to make an audible alarm or signal for some specific action, like a program which has aborted, an unverified backup or the successful completition of a task. Indeed it is. On an old laptop using APM I used to play little tunes as the battery got down to 30, 20, 10%, noiser just before forced suspend, which saved me not a few times. A nice little chirp when fully charged. [..] I wonder if whoever write and distributed this realized that he/she could be sued for copyright infringement for about 5 of the simple tunes that are embedded in that thing. Sad but true. :-( I hope noone's losing too much sleep, after ~20 uneventful years :) cheers, Ian ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Recipie for CPU souffle'
On Fri, 5 Apr 2013 05:23:31 +1100 (EST), Ian Smith wrote: In freebsd-questions Digest, Vol 461, Issue 6, Message: 1 (sorry about the threading) On Wed, 3 Apr 2013 15:12:17 +0200 Polytropon free...@edvax.de wrote: On Tue, 02 Apr 2013 19:10:59 -0700, Ronald F. Guilmette wrote: It doesn't have to cover everything. But it _should_ completely describe the programatic interface. At least is leaves questions, like stating use the syscalls in order to..., and the reader is left with the most obvious question: _which_ syscalls? Sometimes examples are the best teachers. Somethimes even manpages contain EXAMPLES. :-) But like I said, somewher along the line, a lot of man page writers apparently got lazy... VERY lazy. Mmm, and a few man page readers too? It's really not rocket science .. No, it's just reading the letters which form words and sentences, expressing things. But that can already be considered hard work if you're not used to that intellectual stuff. :-) But keep in mind they're still alive! Judging from the manpages of... *cough* can I say this? YOu know, more prominent open source operating systems for desktops... they're usually much worse _if_ there is a manpage. In most cases, there's none. True. And I can usually get little more sense out of info(1) than from windows 'troubleshooter' :) You can shoot trouble as much as you like. It doesn't work. It always comes back. To eliminate the source, you need to understand the initial problem, then kill it with fire. :-) Second order question: Why can't I just pipe a .wav file to the /dev/speaker device file and have it play? Wouldn't that make quite a lot of sense? No, that does not work. Apparently not. Why it doesn't work (or couldn't work) is less clear. The speaker interface to the _PC speaker_ is not a DSP. It's programming is much simpler. The note language that it uses on FreeBSD is much more than other interfaces offer. Better ones have stuff like pitch, duration, turn off. Not to mention staccato, legato, dotted notes - sophisticated stuff! Plus interpretation of UTF-8 strings that contain note language, I assume those characters are in there... :-) % echo c /dev/speaker Humm... now _that_ is both interesting and enlightening. I actually remember having used something comparable on BASIC, when my brain wasn't fully developed yet. :-) The note language is _from_ BASIC .. do read the source, Luke(s)! That's why I could remember it. I think it was QBasic (on a PC platform, no idea if other platforms also supported it, but I assume more sophisticated BASICs could have contained that functionality). echo cdefgabc /dev/speaker It's still a nice interface to generate attention sounds in case you want to make an audible alarm or signal for some specific action, like a program which has aborted, an unverified backup or the successful completition of a task. Indeed it is. On an old laptop using APM I used to play little tunes as the battery got down to 30, 20, 10%, noiser just before forced suspend, which saved me not a few times. A nice little chirp when fully charged. You can still find it in /etc/apmd.conf: echo T250L16B+BA+AG+GF+FED+DC+CC /dev/speaker echo T250L8CE-GE-C /dev/speaker Sadly, when APM was working properly, it has been abolished. :-( -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Recipie for CPU souffle'
On 04/02/13 20:55, Ronald F. Guilmette wrote: In message 515aae16.9030...@qeng-ho.org, you wrote: On 04/02/13 04:02, Ronald F. Guilmette wrote: [Overheating CPU war story snipped.] ... I've had a fan jam that way. Cable ties are your friends. Yes. P.P.S. I have a (relatively) monster sized heatsink in this system, and it sits atop a quite modest 2.7GHz single-core Athlon, so it is not at all surprising that the ``stable'' CPU temp is around 30c (86f). I tend to use Intel processors so I'm not familiar with your exact processor, but does the amdtemp kernel module work for it? I dunno. This is the first I have ever heard of that. Is there any specific advantage to using that, relative to using mbmon? Only that it's in the base system without needing any ports. If so, you could write a shell script that loops doing sysctl -n dev.cpu.N.temperature Right, but I can do something similar also with mbmon. ...man speaker... Humm... I'm looking at that now and it raises more questions that it answers. First order question: Why is it that in FreeBSD there are so many man pages like this one, _purporting_ to describe some low level interface to some sort of hardware, and the man page _doesn't_ include a clear and explicit description of the relevant ioctls ? At least in this case the man page does sort of describe, in just prose, what the relevant ioctls are, but it doesn't actually show the calls explicitly. But look at the man pages for usb(4) or uart(4) or tty(4) or essentially anything you find in /usr/share/man/man4. Maybe I'm just spoiled or something, but I do seem to remember, back in the old old OLD days, that device file man pages always explicitly listed the relevant ioctls. (But then I suppose that that was SystemV I'm thinking of.) It's worth remembering that in the old**3 days the people programming Unix were doing it as part of their paid employment. These days I suspect many people hacking on FBSD have jobs, families and real lives contending with their open source work. The job's not done until the documentation is written is a great principle, but difficult in practice for anyone whose FBSD coding is done in snatched time. Second order question: Why can't I just pipe a .wav file to the /dev/speaker device file and have it play? Wouldn't that make quite a lot of sense? You're thinking of /dev/audio, which is a Sparc sound system workalike that plays IIRC mu-law sound (not .wav, that's got headers mixed up with the data). However, you specifically asked for something that would use the motherboard speaker, whereas /dev/audio sits over the /dev/dsp* stuff, which drives the normal external speaker audio. (man snd for that.) Historically the type the notes interface to /dev/speaker goes back a long way. Back in the mid 80s I worked on a Symbolics Lisp Machine that had the same interface. /usr/sbin/spkrtest might be useful Humm... well... it is at least mildly entertaining. I meant useful to look at for ideas, not use. :-) I wonder if whoever write and distributed this realized that he/she could be sued for copyright infringement for about 5 of the simple tunes that are embedded in that thing. Sad but true. Have you actually tried it? I'm not sure even the music industry's paranoid lawyers would worry about something that sounds that bad, and any half way sane judge would throw it out as de minimis. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Recipie for CPU souffle'
On Tue, 02 Apr 2013 19:10:59 -0700, Ronald F. Guilmette wrote:
See how the entire ioctl() interface for these device types is completely
documented IN THE MAN PAGE? That's the way it should be... None of this
rooting around in the sources for something that should have been documented
properly, external to the kernel sources.
I agree that especially to developers, that sounds logical
and very helpful. Seems that manpages do not aim for that
goal anymore...
It doesn't have to cover everything. But it _should_ completely describe
the programatic interface.
At least is leaves questions, like stating use the syscalls
in order to..., and the reader is left with the most obvious
question: _which_ syscalls?
But like I said, somewher along the line, a lot of man page writers
apparently got lazy... VERY lazy.
But keep in mind they're still alive! Judging from the manpages
of... *cough* can I say this? YOu know, more prominent open
source operating systems for desktops... they're usually much
worse _if_ there is a manpage. In most cases, there's none.
Second order question: Why can't I just pipe a .wav file to the
/dev/speaker device file and have it play? Wouldn't that make quite
a lot of sense?
No, that does not work.
Apparently not.
Why it doesn't work (or couldn't work) is less clear.
The speaker interface to the _PC speaker_ is not a DSP. It's
programming is much simpler. The note language that it
uses on FreeBSD is much more than other interfaces offer.
Better ones have stuff like pitch, duration, turn off.
Worse ones only can emit ^G (BEL character) and have
some terminal driver make a beep and nothing more.
However, try this example (cw.sh):
#!/bin/sh
read -p CW === TEXT
echo ${TEXT} | morse | awk '{
if(length($0) == 0)
printf(P4\n);
else {
gsub( dit, P32L32E, $0);
gsub( di, P32L32E, $0);
gsub( dah, P32L8E, $0);
printf(%sP16\n, $0);
}
}' | dd bs=256 of=/dev/speaker /dev/null 21
Ummm
% /tmp/beeps.sh
CW === x
/tmp/beeps.sh: morse: not found
Seems your OS is installed incompletely?
% which morse
/usr/games/morse
This is on my home 8.2 system. The morse program is part of
the games distribution. Maybe you've decided to leave it out
when installing your system?
Just in case, you can easily install it from the source tree,
cd /usr/src/games/morse/ and make install.
But probably not required, because the simplest test you could
construct is something like
% echo c /dev/speaker
Humm... now _that_ is both interesting and enlightening.
I actually remember having used something comparable on
BASIC, when my brain wasn't fully developed yet. :-)
echo cdefgabc /dev/speaker
It's still a nice interface to generate attention sounds
in case you want to make an audible alarm or signal for
some specific action, like a program which has aborted,
an unverified backup or the successful completition of
a task.
Can you hear a sound?
Yes.
This means two things: Your speaker is present and works, and
the /dev/speaker mechanism also works.
I wonder if whoever write and distributed this realized that he/she could
be sued for copyright infringement for about 5 of the simple tunes that are
embedded in that thing. Sad but true.
:-(
Is it really that bad already?
Haven't you noticed?
I _try_ not to notice it, because in some cases, it's totally
insane what's happenning on that front...
In the future, there will be no more engineers... only lawyers.
Two lawyers, three opinions. ;-)
--
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Recipie for CPU souffle'
On Wed, 03 Apr 2013 12:35:49 +0100, Arthur Chance wrote: I'm not sure even the music industry's paranoid lawyers would worry about something that sounds that bad, and any half way sane judge would throw it out as de minimis. They care about the crappy glaring sound of 8 bit, 11 kHz, mono, with low bitrate and ugly quality which comes out of almost any smartphone these days. And you don't even need a judge to bully people or scare them into paying money (at least in Germany a lawyer can work for your and have you pay money even if you've never met him), de impera et virtutibus loquitur, as the lawman would say. ;-) -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Recipie for CPU souffle'
Polytropon free...@edvax.de writes:
On Tue, 02 Apr 2013 12:55:20 -0700, Ronald F. Guilmette wrote:
No, that does not work. Read the manpage to recognize clearly
_what_ kind of input the /dev/speaker device accepts. It does
not understand WAV files.
However, try this example (cw.sh):
#!/bin/sh
read -p CW === TEXT
echo ${TEXT} | morse | awk '{
if(length($0) == 0)
printf(P4\n);
else {
gsub( dit, P32L32E, $0);
gsub( di, P32L32E, $0);
gsub( dah, P32L8E, $0);
printf(%sP16\n, $0);
}
}' | dd bs=256 of=/dev/speaker /dev/null 21
This script doesn't require any non-OS components. You can use
it as a basis to build a program that will send you system messages
in an audible way in morse code... :-)
Have you looked at the morse man page lately, specifically the -p
option? :-) Just try 'morse -p sos' to test it.
--
Carl Johnsonca...@peak.org
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Recipie for CPU souffle'
On Wed, 03 Apr 2013 08:51:21 -0700, Carl Johnson wrote:
Polytropon free...@edvax.de writes:
On Tue, 02 Apr 2013 12:55:20 -0700, Ronald F. Guilmette wrote:
No, that does not work. Read the manpage to recognize clearly
_what_ kind of input the /dev/speaker device accepts. It does
not understand WAV files.
However, try this example (cw.sh):
#!/bin/sh
read -p CW === TEXT
echo ${TEXT} | morse | awk '{
if(length($0) == 0)
printf(P4\n);
else {
gsub( dit, P32L32E, $0);
gsub( di, P32L32E, $0);
gsub( dah, P32L8E, $0);
printf(%sP16\n, $0);
}
}' | dd bs=256 of=/dev/speaker /dev/null 21
This script doesn't require any non-OS components. You can use
it as a basis to build a program that will send you system messages
in an audible way in morse code... :-)
Have you looked at the morse man page lately, specifically the -p
option? :-) Just try 'morse -p sos' to test it.
That's actually quite cool, didn't know about that - but the
script shown is already old, so _maybe_ I have written it
when -p hasn't been introduced yet. And note -p does have
a better space and pausing melody.
A nice means to transmit system messages! :-)
--
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Recipie for CPU souffle'
You might want to confirm that your processor model requires a thermal pad and not grease. Then hunt some down and use it instead of thermal grease. I seem to recall they were somewhat difficult to locate a place from which to purchase. It's not that bad these days, search amazon or something for thermal pad and you'll get a bunch of results. Just make sure you get an actual flexible pad and not a polished copper shim, which are often sold under the same name. __ it has a certain smooth-brained appeal ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Recipie for CPU souffle'
On 4/1/2013 10:02 PM, Ronald F. Guilmette wrote: [[ Mostly, this posting is just a story. But it does include one question, towards the end. See below. ]] Well, I accidentally found what I believe is most likely the reason for the system halts I have been having recently, so I just thought that I would share that. It _is_ a bit humorous. (The mystery system shutdowns have _not_ been due to a power issue, it would appear.) I just now experienced another episode in which the machine powered itself off, as I was working on it, for no apparently good reason. Since it was down anyway, I decided that this would be a good time to pull out that *^%$#@ bleedin' new USB 3.0 PCIe card I had recently installed... just in case that was causing the problem. As I reached in to begin extracting the PCIe card, the tip of one of my fingers accidentally brushed up against my CPU heatsink. I in- stinctively yanked it away immediately. If I had not done so, I would probably have gotten a third degree burn. I left the system off for a couple of minutes after that... to let it cool down a bit before doing anything else... and then I powered it back on, checked that the CPU fan was indeed turning (it was) and then I went immediately to the BIOS and the PC Heath Status. The CPU temperature was listed as being 63c == 145f !!! And this was _after_ I had allowed the system to be powered down for a couple of minutes to cool down!!! So anyway, the fan turned and I watched the CPU temp slowly inch down to something more normal... like in the vicinity of 24c. I don't know what to make of this, except to suspect that some loose wires inside my case got in the way of the CPU fan turning. (I am not neat like some folks. The inside of myu case _is_ really rather sloppy, so this could easly have happened.) I've now installed mbmon and xmbmon and will be watching the CPU temp closely for awhile. I really wish that one or the other of those tools allowed setting a threshold CPU temp, beyond which the tool would emit an ear piercing alarm via the motherboard speaker... you know.. in case the regular external stereo speakers are turned off. question What *is* the best way to achieve the above effect, i.e. to arrange for the machine to scream for help in case it is getting too hot? I don't want it to just die, like it is doing now. I want it to scream so that I can rush over and at least try to do an orderly shutdown. /question Regards, rfg P.S. I am loading the system pretty heavily now, and have been for the last 20+ minutes, and xmbmon is showing me a nice constant 31c for the CPU temp. So for the moment at least, all is well. P.P.S. I have a (relatively) monster sized heatsink in this system, and it sits atop a quite modest 2.7GHz single-core Athlon, so it is not at all surprising that the ``stable'' CPU temp is around 30c (86f). Use stress in ports. I recently had to fix two computers at work(and I'm not IT) due to overheating. One had the fan start to go bad. The automatic thermal control would turn the fan on and off for silence. Sometimes it wouldn't kick back on when under load. I changed the bios to always on, and it worked. Another had the thermal paste so dry, it insulated the processor. Both were pentium 4's. We don't get the good computers. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Recipie for CPU souffle'
On 04/02/13 04:02, Ronald F. Guilmette wrote: [Overheating CPU war story snipped.] I don't know what to make of this, except to suspect that some loose wires inside my case got in the way of the CPU fan turning. (I am not neat like some folks. The inside of myu case _is_ really rather sloppy, so this could easly have happened.) I've had a fan jam that way. Cable ties are your friends. I've now installed mbmon and xmbmon and will be watching the CPU temp closely for awhile. I really wish that one or the other of those tools allowed setting a threshold CPU temp, beyond which the tool would emit an ear piercing alarm via the motherboard speaker... you know.. in case the regular external stereo speakers are turned off. question What *is* the best way to achieve the above effect, i.e. to arrange for the machine to scream for help in case it is getting too hot? I don't want it to just die, like it is doing now. I want it to scream so that I can rush over and at least try to do an orderly shutdown. /question Regards, rfg P.S. I am loading the system pretty heavily now, and have been for the last 20+ minutes, and xmbmon is showing me a nice constant 31c for the CPU temp. So for the moment at least, all is well. P.P.S. I have a (relatively) monster sized heatsink in this system, and it sits atop a quite modest 2.7GHz single-core Athlon, so it is not at all surprising that the ``stable'' CPU temp is around 30c (86f). I tend to use Intel processors so I'm not familiar with your exact processor, but does the amdtemp kernel module work for it? If so, you could write a shell script that loops doing sysctl -n dev.cpu.N.temperature for suitable values of N and do whatever you like when/if the temperature goes above a threshold. man speaker and looking at /usr/sbin/spkrtest might be useful, just remember you'll probably have to kldload speaker first. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Recipie for CPU souffle'
On Mon, 01 Apr 2013 20:02:02 -0700, Ronald F. Guilmette wrote: I've now installed mbmon and xmbmon and will be watching the CPU temp closely for awhile. I have xmbmon running on the lower left of my screen, together with xcpufreq and xload. Just for my information. :-) I really wish that one or the other of those tools allowed setting a threshold CPU temp, beyond which the tool would emit an ear piercing alarm via the motherboard speaker... you know.. in case the regular external stereo speakers are turned off. question What *is* the best way to achieve the above effect, i.e. to arrange for the machine to scream for help in case it is getting too hot? If I remember correctly, that should be healthd? Additionally, you can probably enable CPUFREQ (if that's the name of the feature I'm refering to) support in the kernel configuration, even though it's mostly directed at mobile use (laptops and such). -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Recipie for CPU souffle'
On Mon, 01 Apr 2013 20:02:02 -0700 Ronald F. Guilmette r...@tristatelogic.com wrote: I really wish that one or the other of those tools allowed setting a threshold CPU temp, beyond which the tool would emit an ear piercing alarm via the motherboard speaker... you know.. in case the regular external stereo speakers are turned off. question What *is* the best way to achieve the above effect, i.e. to arrange for the machine to scream for help in case it is getting too hot? I don't want it to just die, like it is doing now. I want it to scream so that I can rush over and at least try to do an orderly shutdown. /question Among other startup scritps in my laptop, I use this for setup the temperature threshold: root@camibar:/root # cat .setcooling.sh #!/bin/sh sysctl hw.acpi.thermal.user_override=1 sysctl hw.acpi.thermal.tz0._PSV=65C sysctl hw.acpi.thermal.user_override=0 Default value is 101C, which I think is excessive optimistic value. --- --- Eduardo Morras emorr...@yahoo.es ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Recipie for CPU souffle'
In message 515aae16.9030...@qeng-ho.org, you wrote: On 04/02/13 04:02, Ronald F. Guilmette wrote: [Overheating CPU war story snipped.] ... I've had a fan jam that way. Cable ties are your friends. Yes. P.P.S. I have a (relatively) monster sized heatsink in this system, and it sits atop a quite modest 2.7GHz single-core Athlon, so it is not at all surprising that the ``stable'' CPU temp is around 30c (86f). I tend to use Intel processors so I'm not familiar with your exact processor, but does the amdtemp kernel module work for it? I dunno. This is the first I have ever heard of that. Is there any specific advantage to using that, relative to using mbmon? If so, you could write a shell script that loops doing sysctl -n dev.cpu.N.temperature Right, but I can do something similar also with mbmon. ...man speaker... Humm... I'm looking at that now and it raises more questions that it answers. First order question: Why is it that in FreeBSD there are so many man pages like this one, _purporting_ to describe some low level interface to some sort of hardware, and the man page _doesn't_ include a clear and explicit description of the relevant ioctls ? At least in this case the man page does sort of describe, in just prose, what the relevant ioctls are, but it doesn't actually show the calls explicitly. But look at the man pages for usb(4) or uart(4) or tty(4) or essentially anything you find in /usr/share/man/man4. Maybe I'm just spoiled or something, but I do seem to remember, back in the old old OLD days, that device file man pages always explicitly listed the relevant ioctls. (But then I suppose that that was SystemV I'm thinking of.) Second order question: Why can't I just pipe a .wav file to the /dev/speaker device file and have it play? Wouldn't that make quite a lot of sense? /usr/sbin/spkrtest might be useful Humm... well... it is at least mildly entertaining. I wonder if whoever write and distributed this realized that he/she could be sued for copyright infringement for about 5 of the simple tunes that are embedded in that thing. Sad but true. :-( Regards, rfg ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Recipie for CPU souffle'
On Tue, 02 Apr 2013 12:55:20 -0700, Ronald F. Guilmette wrote:
Is there any specific advantage to using that, relative to using mbmon?
As far as I understand, it's utilizing a different infrastructure
to obtain data. You can see man amdtemp in comparison to the
reporting mechanisms mbmon uses.
...man speaker...
Humm... I'm looking at that now and it raises more questions that it answers.
It's just an interface to the PC speaker, what question? :-)
First order question: Why is it that in FreeBSD there are so many man
pages like this one, _purporting_ to describe some low level interface
to some sort of hardware, and the man page _doesn't_ include a clear
and explicit description of the relevant ioctls ?
Discovering those usually involved using the driver sources.
The driver description provided in the manpage doesn't cover
everything, but it says: definitions for the ioctl(2)
interface are in dev/speaker/speaker.h.
Second order question: Why can't I just pipe a .wav file to the
/dev/speaker device file and have it play? Wouldn't that make quite
a lot of sense?
No, that does not work. Read the manpage to recognize clearly
_what_ kind of input the /dev/speaker device accepts. It does
not understand WAV files.
However, try this example (cw.sh):
#!/bin/sh
read -p CW === TEXT
echo ${TEXT} | morse | awk '{
if(length($0) == 0)
printf(P4\n);
else {
gsub( dit, P32L32E, $0);
gsub( di, P32L32E, $0);
gsub( dah, P32L8E, $0);
printf(%sP16\n, $0);
}
}' | dd bs=256 of=/dev/speaker /dev/null 21
This script doesn't require any non-OS components. You can use
it as a basis to build a program that will send you system messages
in an audible way in morse code... :-)
/usr/sbin/spkrtest might be useful
Humm... well... it is at least mildly entertaining.
But probably not required, because the simplest test you could
construct is something like
% echo c /dev/speaker
Can you hear a sound? Yes? Good. Speaker works. Don't hear
anything? Either your system doesn't have a speaker, or the
driver isn't loaded. :-)
Hint: Make sure permissions are set properly.
own speaker root:operator
permspeaker 0660
You can add those to /etc/devfs.conf if you're a member of
the operator group.
I wonder if whoever write and distributed this realized that he/she could
be sued for copyright infringement for about 5 of the simple tunes that are
embedded in that thing. Sad but true.
:-(
Is it really that bad already? Patent of swinging on a swing
or exercising a cat time? ;-)
--
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Recipie for CPU souffle'
In message 20130402231522.71cb7352.free...@edvax.de,
Polytropon free...@edvax.de wrote:
First order question: Why is it that in FreeBSD there are so many man
pages like this one, _purporting_ to describe some low level interface
to some sort of hardware, and the man page _doesn't_ include a clear
and explicit description of the relevant ioctls ?
Discovering those usually involved using the driver sources.
Like I said, that was *not* true back in the old days.
Somewhere along the line, somebody decided to get lazy when it came to
writing man pages for device files.
Here is a good example that is not even that old:
http://linux.die.net/man/4/tty_ioctl
(Of course, all of this information _should_ be in the tty(4) man page
itself... NOT in a separate man page.)
Here are two even better examples:
http://www.s-gms.ms.edus.si/cgi-bin/man-cgi?uscsi+7I
http://www.manpages.info/sunos/fdio.7.html
See how the entire ioctl() interface for these device types is completely
documented IN THE MAN PAGE? That's the way it should be... None of this
rooting around in the sources for something that should have been documented
properly, external to the kernel sources.
The driver description provided in the manpage doesn't cover
everything,
It doesn't have to cover everything. But it _should_ completely describe
the programatic interface.
I mean seriously, imagine if the man page for (for example) sem_init(3)
failed to clearly specific the programatic interfece (aka the C language
binding). You would think that is was ridiculous if everybody who just
wanted to write some code to use sem_init was forced to go grunging around
in the kernel sources, just to find out the proper way to call this
premitice function.
but it says: definitions for the ioctl(2)
interface are in dev/speaker/speaker.h.
See above. One should not have to look beyond the (properly written) man
page just in order to write some client code.
But like I said, somewher along the line, a lot of man page writers
apparently got lazy... VERY lazy.
Second order question: Why can't I just pipe a .wav file to the
/dev/speaker device file and have it play? Wouldn't that make quite
a lot of sense?
No, that does not work.
Apparently not.
Why it doesn't work (or couldn't work) is less clear.
However, try this example (cw.sh):
#!/bin/sh
read -p CW === TEXT
echo ${TEXT} | morse | awk '{
if(length($0) == 0)
printf(P4\n);
else {
gsub( dit, P32L32E, $0);
gsub( di, P32L32E, $0);
gsub( dah, P32L8E, $0);
printf(%sP16\n, $0);
}
}' | dd bs=256 of=/dev/speaker /dev/null 21
Ummm
% /tmp/beeps.sh
CW === x
/tmp/beeps.sh: morse: not found
But probably not required, because the simplest test you could
construct is something like
% echo c /dev/speaker
Humm... now _that_ is both interesting and enlightening.
Thank you.
Can you hear a sound?
Yes.
I wonder if whoever write and distributed this realized that he/she could
be sued for copyright infringement for about 5 of the simple tunes that are
embedded in that thing. Sad but true.
:-(
Is it really that bad already?
Haven't you noticed?
Jeezzze. Go to Google News and search for the word copyright and look
at how many stories there are in the news JUST TODAY about various
copyright lawsuits.
There is one about an attorney named John Steele, Who Has Sued More Than
20,000 People.
There is another one about (the artist formerly known as) Prince.
There is another one about Angelina Jolie.
There is another one about St. Louis University... which is apparently
threatening its own faculty with copyright suits.
Oh yea, and another one about an ongoing battle between Viacom and YouTube.
And another story about textbook rentals in the Sydney Morning Herald.
In the future, there will be no more engineers... only lawyers.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Recipie for CPU souffle'
On 02/04/2013 13:32, Ronald F. Guilmette wrote: I've now installed mbmon and xmbmon and will be watching the CPU temp closely for awhile. I really wish that one or the other of those tools allowed setting a threshold CPU temp, beyond which the tool would emit an ear piercing alarm via the motherboard speaker... you know.. in case the regular external stereo speakers are turned off. It's been a while since I used it but conky is pretty customisable. Worst case you have it run your own scripts that returns monitored values and performs whatever steps you want at the thresholds. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Recipie for CPU souffle'
Ronald F. Guilmette wrote: [[ Mostly, this posting is just a story. But it does include one question, towards the end. See below. ]] Well, I accidentally found what I believe is most likely the reason for the system halts I have been having recently, so I just thought that I would share that. It _is_ a bit humorous. (The mystery system shutdowns have _not_ been due to a power issue, it would appear.) I just now experienced another episode in which the machine powered itself off, as I was working on it, for no apparently good reason. Since it was down anyway, I decided that this would be a good time to pull out that *^%$#@ bleedin' new USB 3.0 PCIe card I had recently installed... just in case that was causing the problem. As I reached in to begin extracting the PCIe card, the tip of one of my fingers accidentally brushed up against my CPU heatsink. I in- stinctively yanked it away immediately. If I had not done so, I would probably have gotten a third degree burn. I left the system off for a couple of minutes after that... to let it cool down a bit before doing anything else... and then I powered it back on, checked that the CPU fan was indeed turning (it was) and then I went immediately to the BIOS and the PC Heath Status. The CPU temperature was listed as being 63c == 145f !!! And this was _after_ I had allowed the system to be powered down for a couple of minutes to cool down!!! So anyway, the fan turned and I watched the CPU temp slowly inch down to something more normal... like in the vicinity of 24c. I don't know what to make of this, except to suspect that some loose wires inside my case got in the way of the CPU fan turning. (I am not neat like some folks. The inside of myu case _is_ really rather sloppy, so this could easly have happened.) I've now installed mbmon and xmbmon and will be watching the CPU temp closely for awhile. I really wish that one or the other of those tools allowed setting a threshold CPU temp, beyond which the tool would emit an ear piercing alarm via the motherboard speaker... you know.. in case the regular external stereo speakers are turned off. question What *is* the best way to achieve the above effect, i.e. to arrange for the machine to scream for help in case it is getting too hot? I don't want it to just die, like it is doing now. I want it to scream so that I can rush over and at least try to do an orderly shutdown. /question Regards, rfg P.S. I am loading the system pretty heavily now, and have been for the last 20+ minutes, and xmbmon is showing me a nice constant 31c for the CPU temp. So for the moment at least, all is well. P.P.S. I have a (relatively) monster sized heatsink in this system, and it sits atop a quite modest 2.7GHz single-core Athlon, so it is not at all surprising that the ``stable'' CPU temp is around 30c (86f). Many old Athlons from the older generation used a thermal pad for heat transfer. It was what looked like a little piece of soft plastic almost something like a milimeter thick and an inch or so square that would have come preapplied to the OEM heat sink which accompanied the CPU in a retail box set. With these processors you cannot just simply smear a lot of thermal grease in there as a replacement. Indeed, doing so (not using a thermal pad) voids the warranty. Thermal grease works best when it is applied as a very thin but evenly distributed layer and the heat sink is then clamped down very tightly so it is in very close contact with the processor. Doing this (using just thermal grease in lieu of the pad) leaves a small void or gap through there will be little heat transfer. You might want to confirm that your processor model requires a thermal pad and not grease. Then hunt some down and use it instead of thermal grease. I seem to recall they were somewhat difficult to locate a place from which to purchase. Also the backing paper was darn near impossible to get off without destroying it (why the OEM cooler had it pre-applied). So get a few of them so you can tear up a couple before you succeed. -Mike ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
