Recipie for CPU souffle'

[Arthur Chance]

On 04/02/13 20:55, Ronald F. Guilmette wrote:
>
> In message <515AAE16.9030707 at 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".