Re: PC speaker

[Oleksandr Natalenko]

Hello.

On Thu, Jun 18, 2020 at 01:49:37PM -0400, R.F. Burns wrote:
> Is it possible to write a kernel module which, when loaded, will blow
> the PC speaker?

1) where have you been starting from 2011 till 2015?
2) why does the posting date of this letter varies a little bit?
3) why June (but July in 2008)?
4) are you a robot?
5) if you are a robot, what's your setup?
6) if you are not a robot, blink.

I'm eagerly waiting for this email each year, but it's a shame you
neither reveal any details nor respond to questions. We are intrigued!

Please uncover this great LKML mystery. We'd like to know you closer.

Thanks.

-- 
  Best regards,
Oleksandr Natalenko (post-factum)
Principal Software Maintenance Engineer

Re: PC speaker

[Randy Dunlap]

On 6/18/20 10:49 AM, R.F. Burns wrote:
> Is it possible to write a kernel module which, when loaded, will blow
> the PC speaker?
> 

Are you still having problems with those school students?


https://marc.info/?l=linux-kernel=118167999520788=2

-- 
~Randy

Re: PC speaker

[Randy Dunlap]

On 6/13/19 12:57 PM, Theodore Ts'o wrote:
> On Thu, Jun 13, 2019 at 12:16:37PM -0400, R.F. Burns wrote:
>> Is it possible to write a kernel module which, when loaded, will blow
>> the PC speaker?
> 
> Yes; in fact, it's already been done.  See sound/drivers/pcsp/ in the
> Linux kernel sources.
> 
>   - Ted
> 

Must be some kind of ritual by R.F. Burns:

Lots of repeated postings from them on June 12 of multiple years.

See 
https://lore.kernel.org/lkml/cabg1bonjirpd1bh5pyetz8jvsv6pymwpyfhhvqwyztp8w-x...@mail.gmail.com/


-- 
~Randy

Re: PC speaker

[Theodore Ts'o]

On Thu, Jun 13, 2019 at 12:16:37PM -0400, R.F. Burns wrote:
> Is it possible to write a kernel module which, when loaded, will blow
> the PC speaker?

Yes; in fact, it's already been done.  See sound/drivers/pcsp/ in the
Linux kernel sources.

- Ted

Re: PC speaker

[Dmitry Torokhov]

On Mon, Jun 12, 2017 at 2:25 PM, Randy Dunlap  wrote:
> On 06/12/17 12:13, R.F. Burns wrote:
>> Is it possible to write a kernel module which, when loaded, will blow
>> the PC speaker?
>>
>
> deja vu all over again.  Same author.
>
> http://marc.info/?l=linux-kernel=118165248822375=2

10 years to the day ;)

-- 
Dmitry

Re: PC speaker

[Dmitry Torokhov]

On Mon, Jun 12, 2017 at 2:25 PM, Randy Dunlap  wrote:
> On 06/12/17 12:13, R.F. Burns wrote:
>> Is it possible to write a kernel module which, when loaded, will blow
>> the PC speaker?
>>
>
> deja vu all over again.  Same author.
>
> http://marc.info/?l=linux-kernel=118165248822375=2

10 years to the day ;)

-- 
Dmitry

Re: PC speaker

[Randy Dunlap]

On 06/12/17 12:13, R.F. Burns wrote:
> Is it possible to write a kernel module which, when loaded, will blow
> the PC speaker?
> 

deja vu all over again.  Same author.

http://marc.info/?l=linux-kernel=118165248822375=2

are you a bot?

-- 
~Randy

Re: PC speaker

[Randy Dunlap]

On 06/12/17 12:13, R.F. Burns wrote:
> Is it possible to write a kernel module which, when loaded, will blow
> the PC speaker?
> 

deja vu all over again.  Same author.

http://marc.info/?l=linux-kernel=118165248822375=2

are you a bot?

-- 
~Randy

Re: PC speaker

[Kyle Moffett]

On Jun 15, 2007, at 15:34:52, Jan Engelhardt wrote:
Perhaps live cd? In which case, the OP should, as recommended in  
this thread already, deactivate choosing boot devices, if that's  
possible.


(Unfortunately, newer BIOSes with 'integrated bootmenu' with F8 or  
so, but I have not seen a way to deactivate _that_ menu.)


Heh, with virtually every PC BIOS I've seen, the procedure is  
something like this:


1)  Reboot into BIOS
2)  Set a BIOS "Supervisor Password" (as opposed to "User" or "Boot"  
password)
3)  Go to the "Boot Devices" list and uncheck everything except "Hard  
Disk"

4)  Go to the "USB Stick Hard Disk Emulation" feature and turn that off
5)  Save settings to BIOS and reboot (Usually "F10" or "ESC-Y" )

The "Integrated BootMenu (F8)" stuff only lists boot devices that are  
enabled in the BIOS.  If everything but the hard disk is disabled  
then pressing (F8) is _really_useful_ :-)

  1) Boot from Hard Disk
  2) Enter BIOS Setup

Of course, choosing option 2 is also quite an entertaining thing for  
the student:

,--.
| Enter Password:  |
`--'

And since they don't actually know the password, it's followed by the  
inevitable:

,--.
| Invalid Password |
`--'

Admittedly there are more things to turn off than with older BIOSen,  
but there are also more features too.  Of course, with OpenFirmware- 
based systems (like the PowerPC macs) it's scriptable and doesn't  
require rebooting.

  1)  Install the "nvsetenv" utility via your distro

  2)  Encode your password by xoring each character's ascii value  
with 0xAA and printing the result in hex.  This perl oneliner will do  
it easily (Change 'my-password' to your plain-text password).
perl -ne 'map { printf "%%%02x", 0xaa ^ ord($_) } split //, $1;  
print "\n"' my-password


  For example, the password "linux" is encoded as "%c6%c3%c4%df%d2"

  3)  Run "nvsetenv security-password %c6%c3%c4%df%d2", where the  
hex stuff is your encoded password


  4)  Run "nvsetenv security-mode command"

Then it auto-locks all possible ways of modifying the open-firmware  
boot device or specifying alternative boot options.  The only way to  
get around it on most systems is with the firmware-reset button on  
the inside of the case or moving RAM around and rebooting with some  
magic key combo held down (Cmd-Opt-P-R on mac systems).  Typically if  
your students can do that there's exactly nothing you can do to  
prevent them from doing whatever they want.  They could always just  
stick in a different hard-drive, after all.


Cheers,
Kyle Moffett

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PC speaker

[Phillip Susi]

Jan Engelhardt wrote:

On Jun 15 2007 13:07, Phillip Susi wrote:

R.F. Burns wrote:

However, over the past several weeks, the students have found more
creative ways to abuse the PC speaker (outside of the OS.)  The Powers
that Be are asking that the PC speakers be disabled completely.  With
the small number of techs we have, it would be very impractical to go
around to all systems and remove the PC speaker from each and every
computer case.

Now I am curious; how are they getting the pc speaker to make any sound with
the kernel module disabled?


ioperm(), inb(), and outb() from userspace. Needs root, though. Or 
/dev/port, with write. Which comes to the question how they gained root. 
Perhaps live cd? In which case, the OP should, as recommended in this 
thread already, deactivate choosing boot devices, if that's possible.


(Unfortunately, newer BIOSes with 'integrated bootmenu' with F8 or so, 
but I have not seen a way to deactivate _that_ menu.)


He already said they don't have root access and that allowed him to stop 
them from accessing the sound card by setting appropriate permissions.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PC speaker

[Jan Engelhardt]

On Jun 15 2007 13:07, Phillip Susi wrote:
> R.F. Burns wrote:
>> However, over the past several weeks, the students have found more
>> creative ways to abuse the PC speaker (outside of the OS.)  The Powers
>> that Be are asking that the PC speakers be disabled completely.  With
>> the small number of techs we have, it would be very impractical to go
>> around to all systems and remove the PC speaker from each and every
>> computer case.
>
> Now I am curious; how are they getting the pc speaker to make any sound with
> the kernel module disabled?

ioperm(), inb(), and outb() from userspace. Needs root, though. Or 
/dev/port, with write. Which comes to the question how they gained root. 
Perhaps live cd? In which case, the OP should, as recommended in this 
thread already, deactivate choosing boot devices, if that's possible.

(Unfortunately, newer BIOSes with 'integrated bootmenu' with F8 or so, 
but I have not seen a way to deactivate _that_ menu.)



Jan
-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PC speaker

[Phillip Susi]

R.F. Burns wrote:

However, over the past several weeks, the students have found more
creative ways to abuse the PC speaker (outside of the OS.)  The Powers
that Be are asking that the PC speakers be disabled completely.  With
the small number of techs we have, it would be very impractical to go
around to all systems and remove the PC speaker from each and every
computer case.


Now I am curious; how are they getting the pc speaker to make any sound 
with the kernel module disabled?


Also there is a very simple solution to your problem.  When a student 
abuses the computer, take a yardstick ( there should be one in any 
classroom ), approach said student from behind, and break said yardstick 
over their ass.  Or you could just ban them from using the computers 
again.



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PC speaker

[Phillip Susi]

R.F. Burns wrote:

However, over the past several weeks, the students have found more
creative ways to abuse the PC speaker (outside of the OS.)  The Powers
that Be are asking that the PC speakers be disabled completely.  With
the small number of techs we have, it would be very impractical to go
around to all systems and remove the PC speaker from each and every
computer case.


Now I am curious; how are they getting the pc speaker to make any sound 
with the kernel module disabled?


Also there is a very simple solution to your problem.  When a student 
abuses the computer, take a yardstick ( there should be one in any 
classroom ), approach said student from behind, and break said yardstick 
over their ass.  Or you could just ban them from using the computers 
again.



-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PC speaker

[Jan Engelhardt]

On Jun 15 2007 13:07, Phillip Susi wrote:
 R.F. Burns wrote:
 However, over the past several weeks, the students have found more
 creative ways to abuse the PC speaker (outside of the OS.)  The Powers
 that Be are asking that the PC speakers be disabled completely.  With
 the small number of techs we have, it would be very impractical to go
 around to all systems and remove the PC speaker from each and every
 computer case.

 Now I am curious; how are they getting the pc speaker to make any sound with
 the kernel module disabled?

ioperm(), inb(), and outb() from userspace. Needs root, though. Or 
/dev/port, with write. Which comes to the question how they gained root. 
Perhaps live cd? In which case, the OP should, as recommended in this 
thread already, deactivate choosing boot devices, if that's possible.

(Unfortunately, newer BIOSes with 'integrated bootmenu' with F8 or so, 
but I have not seen a way to deactivate _that_ menu.)



Jan
-- 
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PC speaker

[Phillip Susi]

Jan Engelhardt wrote:

On Jun 15 2007 13:07, Phillip Susi wrote:

R.F. Burns wrote:

However, over the past several weeks, the students have found more
creative ways to abuse the PC speaker (outside of the OS.)  The Powers
that Be are asking that the PC speakers be disabled completely.  With
the small number of techs we have, it would be very impractical to go
around to all systems and remove the PC speaker from each and every
computer case.

Now I am curious; how are they getting the pc speaker to make any sound with
the kernel module disabled?


ioperm(), inb(), and outb() from userspace. Needs root, though. Or 
/dev/port, with write. Which comes to the question how they gained root. 
Perhaps live cd? In which case, the OP should, as recommended in this 
thread already, deactivate choosing boot devices, if that's possible.


(Unfortunately, newer BIOSes with 'integrated bootmenu' with F8 or so, 
but I have not seen a way to deactivate _that_ menu.)


He already said they don't have root access and that allowed him to stop 
them from accessing the sound card by setting appropriate permissions.


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PC speaker

[Kyle Moffett]

On Jun 15, 2007, at 15:34:52, Jan Engelhardt wrote:
Perhaps live cd? In which case, the OP should, as recommended in  
this thread already, deactivate choosing boot devices, if that's  
possible.


(Unfortunately, newer BIOSes with 'integrated bootmenu' with F8 or  
so, but I have not seen a way to deactivate _that_ menu.)


Heh, with virtually every PC BIOS I've seen, the procedure is  
something like this:


1)  Reboot into BIOS
2)  Set a BIOS Supervisor Password (as opposed to User or Boot  
password)
3)  Go to the Boot Devices list and uncheck everything except Hard  
Disk

4)  Go to the USB Stick Hard Disk Emulation feature and turn that off
5)  Save settings to BIOS and reboot (Usually F10 or ESC-Y )

The Integrated BootMenu (F8) stuff only lists boot devices that are  
enabled in the BIOS.  If everything but the hard disk is disabled  
then pressing (F8) is _really_useful_ :-)

  1) Boot from Hard Disk
  2) Enter BIOS Setup

Of course, choosing option 2 is also quite an entertaining thing for  
the student:

,--.
| Enter Password:  |
`--'

And since they don't actually know the password, it's followed by the  
inevitable:

,--.
| Invalid Password |
`--'

Admittedly there are more things to turn off than with older BIOSen,  
but there are also more features too.  Of course, with OpenFirmware- 
based systems (like the PowerPC macs) it's scriptable and doesn't  
require rebooting.

  1)  Install the nvsetenv utility via your distro

  2)  Encode your password by xoring each character's ascii value  
with 0xAA and printing the result in hex.  This perl oneliner will do  
it easily (Change 'my-password' to your plain-text password).
perl -ne 'map { printf %%%02x, 0xaa ^ ord($_) } split //, $1;  
print \n' my-password


  For example, the password linux is encoded as %c6%c3%c4%df%d2

  3)  Run nvsetenv security-password %c6%c3%c4%df%d2, where the  
hex stuff is your encoded password


  4)  Run nvsetenv security-mode command

Then it auto-locks all possible ways of modifying the open-firmware  
boot device or specifying alternative boot options.  The only way to  
get around it on most systems is with the firmware-reset button on  
the inside of the case or moving RAM around and rebooting with some  
magic key combo held down (Cmd-Opt-P-R on mac systems).  Typically if  
your students can do that there's exactly nothing you can do to  
prevent them from doing whatever they want.  They could always just  
stick in a different hard-drive, after all.


Cheers,
Kyle Moffett

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PC speaker

[Kyle Moffett]

On Jun 13, 2007, at 15:53:30, Pavel Machek wrote:
Other great examples are hardware that allows you to control  
voltages, fan speeds, and operating frequencies. Sometimes you can  
overvoltage it directly and blow it immediately. Other times, you  
can increase the voltage and operating frequency and decrease the  
fan speed to the point where it stops spinning. This is possible  
on many modern graphics cards and CPUs.


Not true for cpus; try it before spreading FUD. Thermal protection  
will kill the machine when cpu goes over 95C or so.


Well, sorta.  Things tend to die early heat deaths if you repeatedly  
spike the temperature (different rates of thermal expansion and all  
that jazz).  If you alternated repeatedly between max-CPU/no-fan and  
no-CPU/max-fan, staying just within the thermal kill limits and  
spending 3/4 of the time at near max temp, you'd probably have a 30%  
chance to kill an average CPU within a couple weeks.


I know when designing the G5 CPU, IBM had to be _really_ careful  
about the variably high operating temperature.  Their first few  
designs ended up having BGA breakdown well before the desired  
lifetime due to thermal creep (long-duration at high temp) and  
fatigue shear failure (alternation between high and low temp).   
There's a paper somewhere on the web about the whole deal.


Cheers,
Kyle Moffett

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PC speaker

[Kyle Moffett]

On Jun 13, 2007, at 15:53:30, Pavel Machek wrote:
Other great examples are hardware that allows you to control  
voltages, fan speeds, and operating frequencies. Sometimes you can  
overvoltage it directly and blow it immediately. Other times, you  
can increase the voltage and operating frequency and decrease the  
fan speed to the point where it stops spinning. This is possible  
on many modern graphics cards and CPUs.


Not true for cpus; try it before spreading FUD. Thermal protection  
will kill the machine when cpu goes over 95C or so.


Well, sorta.  Things tend to die early heat deaths if you repeatedly  
spike the temperature (different rates of thermal expansion and all  
that jazz).  If you alternated repeatedly between max-CPU/no-fan and  
no-CPU/max-fan, staying just within the thermal kill limits and  
spending 3/4 of the time at near max temp, you'd probably have a 30%  
chance to kill an average CPU within a couple weeks.


I know when designing the G5 CPU, IBM had to be _really_ careful  
about the variably high operating temperature.  Their first few  
designs ended up having BGA breakdown well before the desired  
lifetime due to thermal creep (long-duration at high temp) and  
fatigue shear failure (alternation between high and low temp).   
There's a paper somewhere on the web about the whole deal.


Cheers,
Kyle Moffett

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PC speaker

[Pavel Machek]

Hi!

> > > >I'd say impossible. Just disconnect it from the motherboard.
> > >
> > > The days when hardware *relied* on software (hence, where software
> > > could damage hardware) are over.
> 
> > Nice theory but you can destroy or render useless a fair amount of PC
> > hardware via software, usually because the thing is *DESIGNED* that way
> > for convenience. (Flash update interfaces without jumpers, locking
> > interfaces for drives etc)
> 
> Other great examples are hardware that allows you to control voltages, fan
> speeds, and operating frequencies. Sometimes you can overvoltage it directly
> and blow it immediately. Other times, you can increase the voltage and
> operating frequency and decrease the fan speed to the point where it stops
> spinning. This is possible on many modern graphics cards and CPUs.

Not true for cpus; try it before spreading FUD. Thermal protection
will kill the machine when cpu goes over 95C or so.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PC speaker

[Chris Smith]

So, the idea was raised about seeing if there was a way to blow the PC
speaker by loading a kernel module.  If so, a mass-deployment of a
kernel module overnight would take care of the PC speaker problem once
and for all.


Sounds as though the problem has more to do with the students than the
hardware.  The Powers That Be are chasing symptoms, as opposed to the
disease.
The real questions center around how to point the creativity on
display away from abusing speakers and towards something useful.
--
Christopher Smith
Pursuer of knowledge
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PC speaker

[Paulo Marques]

Maciej W. Rozycki wrote:

On Tue, 12 Jun 2007, Jan Engelhardt wrote:


4) It assumes the current will be sufficient to burn out the speaker. (I
know it will get very hot on older machines, whether it will burn out --
might even depend on the exact speaker model.)

Since you can set the x86's crystals frequency from 1193182 to 18 Hz
(PIT_TICK_RATE / 1 to PIT_TICK_RATE / 65535) [*], you can never really
bust it. But even then, what would a speaker do it was constanly given


 I am fairly sure you have a choice between a steady low and a steady high 
level on the speaker output available if you switch the 8254 to the right 
single-shot mode.  In case you have not been into such details -- the 8254 
offers six modes of operation, selected for each channel separately, of 
which only two are periodic.


Can we please stop this non-sense thread? Anyone designing the speaker 
circuit would certainly place a small capacitor in series with the 
speaker to kill the DC component of the signal.


Since the speaker itself wouldn't be able to play very low frequencies 
anyway, the capacitor wouldn't have to be that big.


So I'm pretty sure that on any half-way decent piece of hardware, you 
won't be able to kill the speaker with software...


--
Paulo Marques - www.grupopie.com

"Don't hit a man when he's down -- kick him; it's easier."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: PC speaker

[Maciej W. Rozycki]

On Tue, 12 Jun 2007, Jan Engelhardt wrote:

> >4) It assumes the current will be sufficient to burn out the speaker. (I
> >know it will get very hot on older machines, whether it will burn out --
> >might even depend on the exact speaker model.)
> 
> Since you can set the x86's crystals frequency from 1193182 to 18 Hz
> (PIT_TICK_RATE / 1 to PIT_TICK_RATE / 65535) [*], you can never really
> bust it. But even then, what would a speaker do it was constanly given

 I am fairly sure you have a choice between a steady low and a steady high 
level on the speaker output available if you switch the 8254 to the right 
single-shot mode.  In case you have not been into such details -- the 8254 
offers six modes of operation, selected for each channel separately, of 
which only two are periodic.

  Maciej
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PC speaker

[Helge Hafting]

Jan Engelhardt wrote:

Since you can set the x86's crystals frequency from 1193182 to 18 Hz
(PIT_TICK_RATE / 1 to PIT_TICK_RATE / 65535) [*], you can never really
bust it. But even then, what would a speaker do it was constanly given
+5V? (I _suppose_ the other level is 0V, not -5V -- makes for easy 
design.) That's IMO just like a sound file with volume(x) = 1, nothing 
spectacular if you ask me.
  


I guess a motherboard don't provide enough current to
burn out that speaker.

But generally, speakers that handle some maximum
alternating current *will* burn out if you give them
the same amount DC.  This becasue speakers
are designed to handle AC - some of the energy is dissipated
as sound waves, some as an alternating magnetic field,
some has heat. And the speaker moves, so moving
air helps cooling it.

A speaker getting DC converts all that current into heat only,
and it stands still so no extra cooling.  So it burns out.

Helge Hafting

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PC speaker

[Helge Hafting]

Jan Engelhardt wrote:

Since you can set the x86's crystals frequency from 1193182 to 18 Hz
(PIT_TICK_RATE / 1 to PIT_TICK_RATE / 65535) [*], you can never really
bust it. But even then, what would a speaker do it was constanly given
+5V? (I _suppose_ the other level is 0V, not -5V -- makes for easy 
design.) That's IMO just like a sound file with volume(x) = 1, nothing 
spectacular if you ask me.
  


I guess a motherboard don't provide enough current to
burn out that speaker.

But generally, speakers that handle some maximum
alternating current *will* burn out if you give them
the same amount DC.  This becasue speakers
are designed to handle AC - some of the energy is dissipated
as sound waves, some as an alternating magnetic field,
some has heat. And the speaker moves, so moving
air helps cooling it.

A speaker getting DC converts all that current into heat only,
and it stands still so no extra cooling.  So it burns out.

Helge Hafting

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: PC speaker

[Maciej W. Rozycki]

On Tue, 12 Jun 2007, Jan Engelhardt wrote:

 4) It assumes the current will be sufficient to burn out the speaker. (I
 know it will get very hot on older machines, whether it will burn out --
 might even depend on the exact speaker model.)
 
 Since you can set the x86's crystals frequency from 1193182 to 18 Hz
 (PIT_TICK_RATE / 1 to PIT_TICK_RATE / 65535) [*], you can never really
 bust it. But even then, what would a speaker do it was constanly given

 I am fairly sure you have a choice between a steady low and a steady high 
level on the speaker output available if you switch the 8254 to the right 
single-shot mode.  In case you have not been into such details -- the 8254 
offers six modes of operation, selected for each channel separately, of 
which only two are periodic.

  Maciej
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PC speaker

[Paulo Marques]

Maciej W. Rozycki wrote:

On Tue, 12 Jun 2007, Jan Engelhardt wrote:


4) It assumes the current will be sufficient to burn out the speaker. (I
know it will get very hot on older machines, whether it will burn out --
might even depend on the exact speaker model.)

Since you can set the x86's crystals frequency from 1193182 to 18 Hz
(PIT_TICK_RATE / 1 to PIT_TICK_RATE / 65535) [*], you can never really
bust it. But even then, what would a speaker do it was constanly given


 I am fairly sure you have a choice between a steady low and a steady high 
level on the speaker output available if you switch the 8254 to the right 
single-shot mode.  In case you have not been into such details -- the 8254 
offers six modes of operation, selected for each channel separately, of 
which only two are periodic.


Can we please stop this non-sense thread? Anyone designing the speaker 
circuit would certainly place a small capacitor in series with the 
speaker to kill the DC component of the signal.


Since the speaker itself wouldn't be able to play very low frequencies 
anyway, the capacitor wouldn't have to be that big.


So I'm pretty sure that on any half-way decent piece of hardware, you 
won't be able to kill the speaker with software...


--
Paulo Marques - www.grupopie.com

Don't hit a man when he's down -- kick him; it's easier.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PC speaker

[Chris Smith]

So, the idea was raised about seeing if there was a way to blow the PC
speaker by loading a kernel module.  If so, a mass-deployment of a
kernel module overnight would take care of the PC speaker problem once
and for all.


Sounds as though the problem has more to do with the students than the
hardware.  The Powers That Be are chasing symptoms, as opposed to the
disease.
The real questions center around how to point the creativity on
display away from abusing speakers and towards something useful.
--
Christopher Smith
Pursuer of knowledge
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PC speaker

[Pavel Machek]

Hi!

   I'd say impossible. Just disconnect it from the motherboard.
  
   The days when hardware *relied* on software (hence, where software
   could damage hardware) are over.
 
  Nice theory but you can destroy or render useless a fair amount of PC
  hardware via software, usually because the thing is *DESIGNED* that way
  for convenience. (Flash update interfaces without jumpers, locking
  interfaces for drives etc)
 
 Other great examples are hardware that allows you to control voltages, fan
 speeds, and operating frequencies. Sometimes you can overvoltage it directly
 and blow it immediately. Other times, you can increase the voltage and
 operating frequency and decrease the fan speed to the point where it stops
 spinning. This is possible on many modern graphics cards and CPUs.

Not true for cpus; try it before spreading FUD. Thermal protection
will kill the machine when cpu goes over 95C or so.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PC speaker

[David Schwartz]

> So, the idea was raised about seeing if there was a way to blow the PC
> speaker by loading a kernel module.  If so, a mass-deployment of a
> kernel module overnight would take care of the PC speaker problem once
> and for all.

No way. None of the conceivable ways of burning out hardware are 
sufficiently safe to intentionally mass employ them like this. If you could 
overload the coil, the only imaginable way to burn out a speaker, it could 
start a fire. This risk is at least significant enough that it's easier to 
open the case than take it.

DS


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PC speaker

[Clemens Koller]

R.F. Burns schrieb:

On 6/12/07, Lee Revell <[EMAIL PROTECTED]> wrote:

On 6/12/07, R.F. Burns <[EMAIL PROTECTED]> wrote:
> Is it possible to write a kernel module which, when loaded, will 
blow the PC

> speaker?

LOL.  May I ask what your use case is?


I am helping a small school system with a number of Linux
workstations.  Previously, the students (middle and high schools)
abused the sound cards in the systems.  This was remedied by changing
the permissions on sound devices so that non-root users would be
denied access (something easily done remotely, and on an automated
basis.)

> [...]

*smile*
What about denying students permissions to change all unwanted
 on the system? They propably don't need to be root.


At that point, the students started finding creative ways to abuse the
PC speaker, which became rather distracting.  We unloaded and disabled
the PC speaker kernel module, which remedied the situation for a
while.


Disable kernel modules at all. Compile in what you need, and kick
out all unwanted stuff. Disable booting from anything else than
harddisk or network...

[OT on]


So, the idea was raised about seeing if there was a way to blow the PC
speaker by loading a kernel module.  If so, a mass-deployment of a
kernel module overnight would take care of the PC speaker problem once
and for all.


A speaker is basically an inductor. Together with the driving circuit,
it may form a resonant circuit. If you drive it exactly with the resonant
frequency[1], you might be able to overheat it. But take care, not to
burn your CPU too, when you reach microwave frequencies and get electromagnetic
waves reflected in the computer's case. Cross-check with Maxwell's
equations! ;-)

OTOH the students propably learn more in hacking a linux system than in any
other lesson. Tell them that the first one gets an A who can get real speech
output working on the PC speaker.

[1] http://en.wikipedia.org/wiki/Resonant_frequency

[OT off]

Good luck,
--
Clemens Koller
__
R Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PC speaker

[Jan Engelhardt]

On Jun 12 2007 16:25, R.F. Burns wrote:
>
> However, over the past several weeks, the students have found more
> creative ways to abuse the PC speaker (outside of the OS.)  The Powers
> that Be are asking that the PC speakers be disabled completely.  With
> the small number of techs we have, it would be very impractical to go
> around to all systems and remove the PC speaker from each and every
> computer case.

But you only have to do it once anyway.

> So, the idea was raised about seeing if there was a way to blow the PC
> speaker by loading a kernel module.  If so, a mass-deployment of a
> kernel module overnight would take care of the PC speaker problem once
> and for all.

And once you need a speaker (BIOS beep codes come to mind), you don't have any.



Jan
-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: PC speaker

[Jan Engelhardt]

On Jun 12 2007 13:08, David Schwartz wrote:
>
>As far as burning out a speaker goes, if you can drop the frequency to zero
>(DC) and get continuous current through the speaker, that could burn it out.
>This makes several assumptions, many of which may not be true on modern PCs:
>
>1) It assumes the speaker is a conventional coil speaker, not a piezo
>element. (This is certainly true on some PCs, although it's increasingly
>false on newer PCs.)
>
>2) It assumes the speaker is DC driven. (I'm pretty sure this was true on
>the original IBM PC. Not sure about newer computers.)

Most likely. AC is hardly any good inside a computer :)

>3) It assumes you can configure the circuitry that drives the speaker such
>that it will stay on. (No idea.)

A crystal will drive the frequency, which can be set with outb(0x42).
Whether the crystal's oscillating signal is connected to the speaker
can be controlled with outb(0x61) IIRC [or just see
drivers/input/misc/pcspkr.c].

>4) It assumes the current will be sufficient to burn out the speaker. (I
>know it will get very hot on older machines, whether it will burn out --
>might even depend on the exact speaker model.)

Since you can set the x86's crystals frequency from 1193182 to 18 Hz
(PIT_TICK_RATE / 1 to PIT_TICK_RATE / 65535) [*], you can never really
bust it. But even then, what would a speaker do it was constanly given
+5V? (I _suppose_ the other level is 0V, not -5V -- makes for easy 
design.) That's IMO just like a sound file with volume(x) = 1, nothing 
spectacular if you ask me.

[*] The line "if (value > 20 && value < 32767) in pcspkr.c looks a bit bogus.


>On at least some older computers, you could burn out the hardware that
>drove the speaker this way. I think it was either the Pet or the Apple
>][ (didn't work on all machines, depended on how much current the
>speaker drew and other odd factors). I witnessed an Apple ][e blow out
>an I/O chip when it crashed with an output (that was supposed to be
>pulsed) left in the on position.


Jan
-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PC speaker

[R.F. Burns]

On 6/12/07, Lee Revell <[EMAIL PROTECTED]> wrote:

On 6/12/07, R.F. Burns <[EMAIL PROTECTED]> wrote:
> Is it possible to write a kernel module which, when loaded, will blow the PC
> speaker?

LOL.  May I ask what your use case is?


I am helping a small school system with a number of Linux
workstations.  Previously, the students (middle and high schools)
abused the sound cards in the systems.  This was remedied by changing
the permissions on sound devices so that non-root users would be
denied access (something easily done remotely, and on an automated
basis.)

At that point, the students started finding creative ways to abuse the
PC speaker, which became rather distracting.  We unloaded and disabled
the PC speaker kernel module, which remedied the situation for a
while.

However, over the past several weeks, the students have found more
creative ways to abuse the PC speaker (outside of the OS.)  The Powers
that Be are asking that the PC speakers be disabled completely.  With
the small number of techs we have, it would be very impractical to go
around to all systems and remove the PC speaker from each and every
computer case.

So, the idea was raised about seeing if there was a way to blow the PC
speaker by loading a kernel module.  If so, a mass-deployment of a
kernel module overnight would take care of the PC speaker problem once
and for all.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: PC speaker

[David Schwartz]

> > >I'd say impossible. Just disconnect it from the motherboard.
> >
> > The days when hardware *relied* on software (hence, where software
> > could damage hardware) are over.

> Nice theory but you can destroy or render useless a fair amount of PC
> hardware via software, usually because the thing is *DESIGNED* that way
> for convenience. (Flash update interfaces without jumpers, locking
> interfaces for drives etc)

Other great examples are hardware that allows you to control voltages, fan
speeds, and operating frequencies. Sometimes you can overvoltage it directly
and blow it immediately. Other times, you can increase the voltage and
operating frequency and decrease the fan speed to the point where it stops
spinning. This is possible on many modern graphics cards and CPUs.

As far as burning out a speaker goes, if you can drop the frequency to zero
(DC) and get continuous current through the speaker, that could burn it out.
This makes several assumptions, many of which may not be true on modern PCs:

1) It assumes the speaker is a conventional coil speaker, not a piezo
element. (This is certainly true on some PCs, although it's increasingly
false on newer PCs.)

2) It assumes the speaker is DC driven. (I'm pretty sure this was true on
the original IBM PC. Not sure about newer computers.)

3) It assumes you can configure the circuitry that drives the speaker such
that it will stay on. (No idea.)

4) It assumes the current will be sufficient to burn out the speaker. (I
know it will get very hot on older machines, whether it will burn out --
might even depend on the exact speaker model.)

On at least some older computers, you could burn out the hardware that drove
the speaker this way. I think it was either the Pet or the Apple ][ (didn't
work on all machines, depended on how much current the speaker drew and
other odd factors). I witnessed an Apple ][e blow out an I/O chip when it
crashed with an output (that was supposed to be pulsed) left in the on
position.

DS


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PC speaker

[jimmy bahuleyan]

Lee Revell wrote:
> On 6/12/07, R.F. Burns <[EMAIL PROTECTED]> wrote:
>> Is it possible to write a kernel module which, when loaded, will blow
>> the PC
>> speaker?
> 
> LOL.  May I ask what your use case is?
> 
or isn't it mis-use case :)

> Lee

-jb
-- 
Tact is the art of making a point without making an enemy.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PC speaker

[Jan Engelhardt]

On Jun 12 2007 16:19, Alan Cox wrote:
>
>> >I'd say impossible. Just disconnect it from the motherboard.
>> 
>> The days when hardware *relied* on software (hence, where software
>> could damage hardware) are over.
>
>Nice theory but you can destroy or render useless a fair amount of PC
>hardware via software, usually because the thing is *DESIGNED* that way
>for convenience. (Flash update interfaces without jumpers, locking
>interfaces for drives etc)

Let's just say the PC speaker was not designed to be proactively be destroyed.



Jan
-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PC speaker

[Alan Cox]

> >I'd say impossible. Just disconnect it from the motherboard.
> 
> The days when hardware *relied* on software (hence, where software
> could damage hardware) are over.

Nice theory but you can destroy or render useless a fair amount of PC
hardware via software, usually because the thing is *DESIGNED* that way
for convenience. (Flash update interfaces without jumpers, locking
interfaces for drives etc)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PC speaker

[Jan Engelhardt]

On Jun 12 2007 15:57, Jan Engelhardt wrote:
>On Jun 12 2007 09:54, R.F. Burns wrote:
>> On 6/12/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote:
>>> On Jun 12 2007 08:45, R.F. Burns wrote:
>
>>> > Is it possible to write a kernel module which, when loaded, will blow the
>>> > PC
>>> > speaker?
>>>
>>> Define blow.
>>> (As in "damage"?)
>>
>> Yes.  As in, blow it out/damage it so that it is no longer usable.
>
>I'd say impossible. Just disconnect it from the motherboard.

The days when hardware *relied* on software (hence, where software
could damage hardware) are over.



Jan
-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PC speaker

[Lee Revell]

On 6/12/07, R.F. Burns <[EMAIL PROTECTED]> wrote:

Is it possible to write a kernel module which, when loaded, will blow the PC
speaker?


LOL.  May I ask what your use case is?

Lee
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PC speaker

[Jan Engelhardt]

On Jun 12 2007 09:54, R.F. Burns wrote:
> On 6/12/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote:
>> On Jun 12 2007 08:45, R.F. Burns wrote:

>> > Is it possible to write a kernel module which, when loaded, will blow the
>> > PC
>> > speaker?
>>
>> Define blow.
>> (As in "damage"?)
>
> Yes.  As in, blow it out/damage it so that it is no longer usable.

I'd say impossible. Just disconnect it from the motherboard.


Jan
-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PC speaker

[R.F. Burns]

On 6/12/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote:


On Jun 12 2007 08:45, R.F. Burns wrote:
>
> Is it possible to write a kernel module which, when loaded, will blow the PC
> speaker?

Define blow.
(As in "damage"?)


Yes.  As in, blow it out/damage it so that it is no longer usable.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PC speaker

[Jan Engelhardt]

On Jun 12 2007 08:45, R.F. Burns wrote:
>
> Is it possible to write a kernel module which, when loaded, will blow the PC
> speaker?

Define blow.
(As in "damage"?)

Jan
-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PC speaker

[Jan Engelhardt]

On Jun 12 2007 08:45, R.F. Burns wrote:

 Is it possible to write a kernel module which, when loaded, will blow the PC
 speaker?

Define blow.
(As in damage?)

Jan
-- 
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PC speaker

[R.F. Burns]

On 6/12/07, Jan Engelhardt [EMAIL PROTECTED] wrote:


On Jun 12 2007 08:45, R.F. Burns wrote:

 Is it possible to write a kernel module which, when loaded, will blow the PC
 speaker?

Define blow.
(As in damage?)


Yes.  As in, blow it out/damage it so that it is no longer usable.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PC speaker

[Jan Engelhardt]

On Jun 12 2007 09:54, R.F. Burns wrote:
 On 6/12/07, Jan Engelhardt [EMAIL PROTECTED] wrote:
 On Jun 12 2007 08:45, R.F. Burns wrote:

  Is it possible to write a kernel module which, when loaded, will blow the
  PC
  speaker?

 Define blow.
 (As in damage?)

 Yes.  As in, blow it out/damage it so that it is no longer usable.

I'd say impossible. Just disconnect it from the motherboard.


Jan
-- 
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PC speaker

[Lee Revell]

On 6/12/07, R.F. Burns [EMAIL PROTECTED] wrote:

Is it possible to write a kernel module which, when loaded, will blow the PC
speaker?


LOL.  May I ask what your use case is?

Lee
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PC speaker

[Jan Engelhardt]

On Jun 12 2007 15:57, Jan Engelhardt wrote:
On Jun 12 2007 09:54, R.F. Burns wrote:
 On 6/12/07, Jan Engelhardt [EMAIL PROTECTED] wrote:
 On Jun 12 2007 08:45, R.F. Burns wrote:

  Is it possible to write a kernel module which, when loaded, will blow the
  PC
  speaker?

 Define blow.
 (As in damage?)

 Yes.  As in, blow it out/damage it so that it is no longer usable.

I'd say impossible. Just disconnect it from the motherboard.

The days when hardware *relied* on software (hence, where software
could damage hardware) are over.



Jan
-- 
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PC speaker

[Alan Cox]

 I'd say impossible. Just disconnect it from the motherboard.
 
 The days when hardware *relied* on software (hence, where software
 could damage hardware) are over.

Nice theory but you can destroy or render useless a fair amount of PC
hardware via software, usually because the thing is *DESIGNED* that way
for convenience. (Flash update interfaces without jumpers, locking
interfaces for drives etc)
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PC speaker

[Jan Engelhardt]

On Jun 12 2007 16:19, Alan Cox wrote:

 I'd say impossible. Just disconnect it from the motherboard.
 
 The days when hardware *relied* on software (hence, where software
 could damage hardware) are over.

Nice theory but you can destroy or render useless a fair amount of PC
hardware via software, usually because the thing is *DESIGNED* that way
for convenience. (Flash update interfaces without jumpers, locking
interfaces for drives etc)

Let's just say the PC speaker was not designed to be proactively be destroyed.



Jan
-- 
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PC speaker

[jimmy bahuleyan]

Lee Revell wrote:
 On 6/12/07, R.F. Burns [EMAIL PROTECTED] wrote:
 Is it possible to write a kernel module which, when loaded, will blow
 the PC
 speaker?
 
 LOL.  May I ask what your use case is?
 
or isn't it mis-use case :)

 Lee

-jb
-- 
Tact is the art of making a point without making an enemy.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: PC speaker

[David Schwartz]

  I'd say impossible. Just disconnect it from the motherboard.
 
  The days when hardware *relied* on software (hence, where software
  could damage hardware) are over.

 Nice theory but you can destroy or render useless a fair amount of PC
 hardware via software, usually because the thing is *DESIGNED* that way
 for convenience. (Flash update interfaces without jumpers, locking
 interfaces for drives etc)

Other great examples are hardware that allows you to control voltages, fan
speeds, and operating frequencies. Sometimes you can overvoltage it directly
and blow it immediately. Other times, you can increase the voltage and
operating frequency and decrease the fan speed to the point where it stops
spinning. This is possible on many modern graphics cards and CPUs.

As far as burning out a speaker goes, if you can drop the frequency to zero
(DC) and get continuous current through the speaker, that could burn it out.
This makes several assumptions, many of which may not be true on modern PCs:

1) It assumes the speaker is a conventional coil speaker, not a piezo
element. (This is certainly true on some PCs, although it's increasingly
false on newer PCs.)

2) It assumes the speaker is DC driven. (I'm pretty sure this was true on
the original IBM PC. Not sure about newer computers.)

3) It assumes you can configure the circuitry that drives the speaker such
that it will stay on. (No idea.)

4) It assumes the current will be sufficient to burn out the speaker. (I
know it will get very hot on older machines, whether it will burn out --
might even depend on the exact speaker model.)

On at least some older computers, you could burn out the hardware that drove
the speaker this way. I think it was either the Pet or the Apple ][ (didn't
work on all machines, depended on how much current the speaker drew and
other odd factors). I witnessed an Apple ][e blow out an I/O chip when it
crashed with an output (that was supposed to be pulsed) left in the on
position.

DS


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PC speaker

[R.F. Burns]

On 6/12/07, Lee Revell [EMAIL PROTECTED] wrote:

On 6/12/07, R.F. Burns [EMAIL PROTECTED] wrote:
 Is it possible to write a kernel module which, when loaded, will blow the PC
 speaker?

LOL.  May I ask what your use case is?


I am helping a small school system with a number of Linux
workstations.  Previously, the students (middle and high schools)
abused the sound cards in the systems.  This was remedied by changing
the permissions on sound devices so that non-root users would be
denied access (something easily done remotely, and on an automated
basis.)

At that point, the students started finding creative ways to abuse the
PC speaker, which became rather distracting.  We unloaded and disabled
the PC speaker kernel module, which remedied the situation for a
while.

However, over the past several weeks, the students have found more
creative ways to abuse the PC speaker (outside of the OS.)  The Powers
that Be are asking that the PC speakers be disabled completely.  With
the small number of techs we have, it would be very impractical to go
around to all systems and remove the PC speaker from each and every
computer case.

So, the idea was raised about seeing if there was a way to blow the PC
speaker by loading a kernel module.  If so, a mass-deployment of a
kernel module overnight would take care of the PC speaker problem once
and for all.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: PC speaker

[Jan Engelhardt]

On Jun 12 2007 13:08, David Schwartz wrote:

As far as burning out a speaker goes, if you can drop the frequency to zero
(DC) and get continuous current through the speaker, that could burn it out.
This makes several assumptions, many of which may not be true on modern PCs:

1) It assumes the speaker is a conventional coil speaker, not a piezo
element. (This is certainly true on some PCs, although it's increasingly
false on newer PCs.)

2) It assumes the speaker is DC driven. (I'm pretty sure this was true on
the original IBM PC. Not sure about newer computers.)

Most likely. AC is hardly any good inside a computer :)

3) It assumes you can configure the circuitry that drives the speaker such
that it will stay on. (No idea.)

A crystal will drive the frequency, which can be set with outb(0x42).
Whether the crystal's oscillating signal is connected to the speaker
can be controlled with outb(0x61) IIRC [or just see
drivers/input/misc/pcspkr.c].

4) It assumes the current will be sufficient to burn out the speaker. (I
know it will get very hot on older machines, whether it will burn out --
might even depend on the exact speaker model.)

Since you can set the x86's crystals frequency from 1193182 to 18 Hz
(PIT_TICK_RATE / 1 to PIT_TICK_RATE / 65535) [*], you can never really
bust it. But even then, what would a speaker do it was constanly given
+5V? (I _suppose_ the other level is 0V, not -5V -- makes for easy 
design.) That's IMO just like a sound file with volume(x) = 1, nothing 
spectacular if you ask me.

[*] The line if (value  20  value  32767) in pcspkr.c looks a bit bogus.


On at least some older computers, you could burn out the hardware that
drove the speaker this way. I think it was either the Pet or the Apple
][ (didn't work on all machines, depended on how much current the
speaker drew and other odd factors). I witnessed an Apple ][e blow out
an I/O chip when it crashed with an output (that was supposed to be
pulsed) left in the on position.


Jan
-- 
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PC speaker

[Jan Engelhardt]

On Jun 12 2007 16:25, R.F. Burns wrote:

 However, over the past several weeks, the students have found more
 creative ways to abuse the PC speaker (outside of the OS.)  The Powers
 that Be are asking that the PC speakers be disabled completely.  With
 the small number of techs we have, it would be very impractical to go
 around to all systems and remove the PC speaker from each and every
 computer case.

But you only have to do it once anyway.

 So, the idea was raised about seeing if there was a way to blow the PC
 speaker by loading a kernel module.  If so, a mass-deployment of a
 kernel module overnight would take care of the PC speaker problem once
 and for all.

And once you need a speaker (BIOS beep codes come to mind), you don't have any.



Jan
-- 
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PC speaker

[Clemens Koller]

R.F. Burns schrieb:

On 6/12/07, Lee Revell [EMAIL PROTECTED] wrote:

On 6/12/07, R.F. Burns [EMAIL PROTECTED] wrote:
 Is it possible to write a kernel module which, when loaded, will 
blow the PC

 speaker?

LOL.  May I ask what your use case is?


I am helping a small school system with a number of Linux
workstations.  Previously, the students (middle and high schools)
abused the sound cards in the systems.  This was remedied by changing
the permissions on sound devices so that non-root users would be
denied access (something easily done remotely, and on an automated
basis.)

 [...]

*smile*
What about denying students permissions to change all unwanted
foo on the system? They propably don't need to be root.


At that point, the students started finding creative ways to abuse the
PC speaker, which became rather distracting.  We unloaded and disabled
the PC speaker kernel module, which remedied the situation for a
while.


Disable kernel modules at all. Compile in what you need, and kick
out all unwanted stuff. Disable booting from anything else than
harddisk or network...

[OT on]


So, the idea was raised about seeing if there was a way to blow the PC
speaker by loading a kernel module.  If so, a mass-deployment of a
kernel module overnight would take care of the PC speaker problem once
and for all.


A speaker is basically an inductor. Together with the driving circuit,
it may form a resonant circuit. If you drive it exactly with the resonant
frequency[1], you might be able to overheat it. But take care, not to
burn your CPU too, when you reach microwave frequencies and get electromagnetic
waves reflected in the computer's case. Cross-check with Maxwell's
equations! ;-)

OTOH the students propably learn more in hacking a linux system than in any
other lesson. Tell them that the first one gets an A who can get real speech
output working on the PC speaker.

[1] http://en.wikipedia.org/wiki/Resonant_frequency

[OT off]

Good luck,
--
Clemens Koller
__
RD Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PC speaker

[David Schwartz]

 So, the idea was raised about seeing if there was a way to blow the PC
 speaker by loading a kernel module.  If so, a mass-deployment of a
 kernel module overnight would take care of the PC speaker problem once
 and for all.

No way. None of the conceivable ways of burning out hardware are 
sufficiently safe to intentionally mass employ them like this. If you could 
overload the coil, the only imaginable way to burn out a speaker, it could 
start a fire. This risk is at least significant enough that it's easier to 
open the case than take it.

DS


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PC-speaker control

[Robert Read]

On Tue, Jan 02, 2001 at 01:40:43AM +0100, Daniel Phillips wrote:
> Daniel Phillips wrote:
> > 
> > Robert Read wrote:
> > > Try this on the console:
> > >
> > > setterm -blength 0
> > >
> > > no assembly required. :)
> > 
> > Yes, and my xterm still beeps - if I make that go away then something
> > else will beep.
> > 
> > Somebody posted a patch to do a global disable of the speaker some time
> > back, and I wish that the patch were generally available.  The result of
> > not having the global disable is an office full of beeping
> > computers.

Right, I see what you mean. Disabling the beep is one thing I always
do, and it requires a few differnt steps, like "xset b off" for xterms
and so on.  It would be nice to switch it off in one place and be done
with it.

> > 
> > How does this look:
> > 
>   echo 0 >/proc/sys/dev/speaker/beep
> 

This looks good to me.  As far as I can tell, it looks like the beep
is generated by kd_mksound, which is a function pointer that usually
points to drivers/char/vt.c:_kd_mksound().  Can anyone verify this?

It doesn't look to hard to write a sysctl driver that would change the
function pointer to something quieter.  Is this what patch did?

robert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: PC-speaker control

[Daniel Phillips]

Daniel Phillips wrote:
> 
> Robert Read wrote:
> > Try this on the console:
> >
> > setterm -blength 0
> >
> > no assembly required. :)
> 
> Yes, and my xterm still beeps - if I make that go away then something
> else will beep.
> 
> Somebody posted a patch to do a global disable of the speaker some time
> back, and I wish that the patch were generally available.  The result of
> not having the global disable is an office full of beeping computers.
> 
> How does this look:
> 
>   cat 0 >/proc/sys/dev/speaker/beep

eh,

  echo 0 >/proc/sys/dev/speaker/beep

--
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: PC-speaker control

[Daniel Phillips]

Robert Read wrote:
> Try this on the console:
> 
> setterm -blength 0
> 
> no assembly required. :)

Yes, and my xterm still beeps - if I make that go away then something
else will beep.

Somebody posted a patch to do a global disable of the speaker some time
back, and I wish that the patch were generally available.  The result of
not having the global disable is an office full of beeping computers.

How does this look:

  cat 0 >/proc/sys/dev/speaker/beep

--
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: PC-speaker control

[Robert Read]

Try this on the console:

setterm -blength 0

no assembly required. :)

robert


On Mon, Jan 01, 2001 at 06:30:37PM -0200, Rafael Diniz wrote:
> Hey, Is there a way to control the PC-speaker with the Linux kernel 2.2?
> I want to disable it.
> I guy told me that with this assembly code I can disable it:
>   in al , 97
>   and al,253
>   out 97,al
> Linux 2.4 will have any syscall to do this?
> 
> Thanks
> Rafael Diniz
> Brazil
> =
> Conectiva Linux 6.0 (2.2.17)  XFree86-4.0.1
> PII 233mhz 96Mb ram
> SB16, USR56k, S3 VirgeDX/GX 4Mb, CD creative48X 
> HDa 10Gb Quantum  HDb 4.1Gb Fugitsu
> MSX2.0 256k MegaRam 256k Mapper 128k Vram
> MSX is the future
> =
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: PC-speaker control

[Robert Read]

Try this on the console:

setterm -blength 0

no assembly required. :)

robert


On Mon, Jan 01, 2001 at 06:30:37PM -0200, Rafael Diniz wrote:
 Hey, Is there a way to control the PC-speaker with the Linux kernel 2.2?
 I want to disable it.
 I guy told me that with this assembly code I can disable it:
   in al , 97
   and al,253
   out 97,al
 Linux 2.4 will have any syscall to do this?
 
 Thanks
 Rafael Diniz
 Brazil
 =
 Conectiva Linux 6.0 (2.2.17)  XFree86-4.0.1
 PII 233mhz 96Mb ram
 SB16, USR56k, S3 VirgeDX/GX 4Mb, CD creative48X 
 HDa 10Gb Quantum  HDb 4.1Gb Fugitsu
 MSX2.0 256k MegaRam 256k Mapper 128k Vram
 MSX is the future
 =
 -
 To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
 the body of a message to [EMAIL PROTECTED]
 Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: PC-speaker control

[Daniel Phillips]

Robert Read wrote:
 Try this on the console:
 
 setterm -blength 0
 
 no assembly required. :)

Yes, and my xterm still beeps - if I make that go away then something
else will beep.

Somebody posted a patch to do a global disable of the speaker some time
back, and I wish that the patch were generally available.  The result of
not having the global disable is an office full of beeping computers.

How does this look:

  cat 0 /proc/sys/dev/speaker/beep

--
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: PC-speaker control

[Robert Read]

On Tue, Jan 02, 2001 at 01:40:43AM +0100, Daniel Phillips wrote:
 Daniel Phillips wrote:
  
  Robert Read wrote:
   Try this on the console:
  
   setterm -blength 0
  
   no assembly required. :)
  
  Yes, and my xterm still beeps - if I make that go away then something
  else will beep.
  
  Somebody posted a patch to do a global disable of the speaker some time
  back, and I wish that the patch were generally available.  The result of
  not having the global disable is an office full of beeping
  computers.

Right, I see what you mean. Disabling the beep is one thing I always
do, and it requires a few differnt steps, like "xset b off" for xterms
and so on.  It would be nice to switch it off in one place and be done
with it.

  
  How does this look:
  
   echo 0 /proc/sys/dev/speaker/beep
 

This looks good to me.  As far as I can tell, it looks like the beep
is generated by kd_mksound, which is a function pointer that usually
points to drivers/char/vt.c:_kd_mksound().  Can anyone verify this?

It doesn't look to hard to write a sysctl driver that would change the
function pointer to something quieter.  Is this what patch did?

robert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: PC speaker driver patch for 2.4.0-test10-pre3

[Oliver Xymoron]

On Tue, 24 Oct 2000, Pavel Machek wrote:

> Hi!
> 
> > > [EMAIL PROTECTED] said:
> > > >  You can also pretty trivially keep track of an error term so that the
> > > > clock is right on average: 
> > > 
> > > True, but I don't want 'right on average'. I want 'not screwed with at all'.
> > > Shifting the timer tick onto the RTC will give me that. 
> > > 
> > > Even if we _do_ get the maths right, fudging with the frequency of the 
> > > system timer is still an ugly hack.
> > 
> > I personally think the system timer is already an ugly hack. HZ is
> > arbitrary, slow by modern standards, and introduces latency.
> > As the comment you quoted points out, it's also not very accurate.  
> > Much better would be an agenda structure with one shot timers between
> > events and jiffies based on cycle counters. This works on modern hardware
> > and scales well for higher processor speeds. 
> 
> ...and breaks horribly when your CPU frequency changes... like on most
> current notebooks.

The unit of time is arbitrary. Cycle counts just happens to be convenient
on most machines and very high resolution. The important point is that
hanging tasks off a periodic low-resolution timer is not scaling with CPU
clock speeds at all and there are ways to throw it out.

--
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.." 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: PC speaker driver patch for 2.4.0-test10-pre3

[Pavel Machek]

Hi!

> > [EMAIL PROTECTED] said:
> > >  You can also pretty trivially keep track of an error term so that the
> > > clock is right on average: 
> > 
> > True, but I don't want 'right on average'. I want 'not screwed with at all'.
> > Shifting the timer tick onto the RTC will give me that. 
> > 
> > Even if we _do_ get the maths right, fudging with the frequency of the 
> > system timer is still an ugly hack.
> 
> I personally think the system timer is already an ugly hack. HZ is
> arbitrary, slow by modern standards, and introduces latency.
> As the comment you quoted points out, it's also not very accurate.  
> Much better would be an agenda structure with one shot timers between
> events and jiffies based on cycle counters. This works on modern hardware
> and scales well for higher processor speeds. 

...and breaks horribly when your CPU frequency changes... like on most
current notebooks.
Pavel
-- 
I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: PC speaker driver patch for 2.4.0-test10-pre3

[Pavel Machek]

Hi!

  [EMAIL PROTECTED] said:
You can also pretty trivially keep track of an error term so that the
   clock is right on average: 
  
  True, but I don't want 'right on average'. I want 'not screwed with at all'.
  Shifting the timer tick onto the RTC will give me that. 
  
  Even if we _do_ get the maths right, fudging with the frequency of the 
  system timer is still an ugly hack.
 
 I personally think the system timer is already an ugly hack. HZ is
 arbitrary, slow by modern standards, and introduces latency.
 As the comment you quoted points out, it's also not very accurate.  
 Much better would be an agenda structure with one shot timers between
 events and jiffies based on cycle counters. This works on modern hardware
 and scales well for higher processor speeds. 

...and breaks horribly when your CPU frequency changes... like on most
current notebooks.
Pavel
-- 
I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: PC speaker driver patch for 2.4.0-test10-pre3

[Oliver Xymoron]

On Tue, 24 Oct 2000, Pavel Machek wrote:

 Hi!
 
   [EMAIL PROTECTED] said:
 You can also pretty trivially keep track of an error term so that the
clock is right on average: 
   
   True, but I don't want 'right on average'. I want 'not screwed with at all'.
   Shifting the timer tick onto the RTC will give me that. 
   
   Even if we _do_ get the maths right, fudging with the frequency of the 
   system timer is still an ugly hack.
  
  I personally think the system timer is already an ugly hack. HZ is
  arbitrary, slow by modern standards, and introduces latency.
  As the comment you quoted points out, it's also not very accurate.  
  Much better would be an agenda structure with one shot timers between
  events and jiffies based on cycle counters. This works on modern hardware
  and scales well for higher processor speeds. 
 
 ...and breaks horribly when your CPU frequency changes... like on most
 current notebooks.

The unit of time is arbitrary. Cycle counts just happens to be convenient
on most machines and very high resolution. The important point is that
hanging tasks off a periodic low-resolution timer is not scaling with CPU
clock speeds at all and there are ways to throw it out.

--
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.." 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: PC speaker driver patch for 2.4.0-test10-pre3

[Oliver Xymoron]

On Mon, 23 Oct 2000, David Woodhouse wrote:

> 
> [EMAIL PROTECTED] said:
> >  You can also pretty trivially keep track of an error term so that the
> > clock is right on average: 
> 
> True, but I don't want 'right on average'. I want 'not screwed with at all'.
> Shifting the timer tick onto the RTC will give me that. 
> 
> Even if we _do_ get the maths right, fudging with the frequency of the 
> system timer is still an ugly hack.

I personally think the system timer is already an ugly hack. HZ is
arbitrary, slow by modern standards, and introduces latency.
As the comment you quoted points out, it's also not very accurate.  
Much better would be an agenda structure with one shot timers between
events and jiffies based on cycle counters. This works on modern hardware
and scales well for higher processor speeds. 

As for the current inaccuracy, the jitter introduced by using an error
term can never be more than a single real interrupt cycle, which is
already well below the average userspace latency.

--
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.." 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: PC speaker driver patch for 2.4.0-test10-pre3

[David Woodhouse]

[EMAIL PROTECTED] said:
>  You can also pretty trivially keep track of an error term so that the
> clock is right on average: 

True, but I don't want 'right on average'. I want 'not screwed with at all'.
Shifting the timer tick onto the RTC will give me that. 

Even if we _do_ get the maths right, fudging with the frequency of the 
system timer is still an ugly hack.



--
dwmw2


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: PC speaker driver patch for 2.4.0-test10-pre3

[Oliver Xymoron]

On Mon, 23 Oct 2000, David Woodhouse wrote:

> See arch/i386/kernel/time.c:
> 
> /* This function must be called with interrupts disabled 
>  * It was inspired by Steve McCanne's microtime-i386 for BSD.  -- jrs
>  * 
>  * However, the pc-audio speaker driver changes the divisor so that
>  * it gets interrupted rather more often - it loads 64 into the
>  * counter rather than 11932! This has an adverse impact on
>  * do_gettimeoffset() -- it stops working! What is also not
>  * good is that the interval that our timer function gets called
>  * is no longer 10.0002 ms, but 9.9767 ms. To get around this
>  * would require using a different timing source.

You can also pretty trivially keep track of an error term so that the
clock is right on average:

#define CLK_HZ 1193200 /* or whatever */
#define ET_PRECISION 1000
#define ET_TIMER_TICKS CLK_HZ*ET_PRECISION/HZ
#define ET_PCSP_TICKS 64*ET_PRECISION
...
static long et=0;

...
et+=ET_PCSP_TICKS;
if(et>ET_TIMER_TICKS) {
et-=ET_TIMER_TICKS;
simulate_timer_tick();
}

This keeps track of the residual timing error to a few decimal places to
several decimal places and will get closer to HZ than even the current
code.

--
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.." 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: PC speaker driver patch for 2.4.0-test10-pre3

[David Woodhouse]

[EMAIL PROTECTED] said:
> Apparently Linus doesn't like the way it handles interrupts or
> something, and is therefore 'wrong.' ::shrug:: As long as it's
> available though, I'll use it ;p 

It's not just 'wrong'. It's 'sick'. But it works. The correct fix is to
shift the system timer onto the RTC, leaving the 8253 timer available for us
to abuse for the PC speaker.

See arch/i386/kernel/time.c:

/* This function must be called with interrupts disabled 
 * It was inspired by Steve McCanne's microtime-i386 for BSD.  -- jrs
 * 
 * However, the pc-audio speaker driver changes the divisor so that
 * it gets interrupted rather more often - it loads 64 into the
 * counter rather than 11932! This has an adverse impact on
 * do_gettimeoffset() -- it stops working! What is also not
 * good is that the interval that our timer function gets called
 * is no longer 10.0002 ms, but 9.9767 ms. To get around this
 * would require using a different timing source. Maybe someone
 * could use the RTC - I know that this can interrupt at frequencies
 * ranging from 8192Hz to 2Hz. If I had the energy, I'd somehow fix
 * it so that at startup, the timer code in sched.c would select
 * using either the RTC or the 8253 timer. The decision would be
 * based on whether there was any other device around that needed
 * to trample on the 8253. I'd set up the RTC to interrupt at 1024 Hz,
 * and then do some jiggery to have a version of do_timer that 
 * advanced the clock by 1/1024 s. Every time that reached over 1/100
 * of a second, then do all the old code. If the time was kept correct
 * then do_gettimeoffset could just return 0 - there is no low order
 * divider that can be accessed.
 *
 * Ideally, you would be able to use the RTC for the speaker driver,
 * but it appears that the speaker driver really needs interrupt more
 * often than every 120 us or so.
 *
 * Anyway, this needs more thought  pjsg (1993-08-28)
 * 
 * If you are really that interested, you should be reading
 * comp.protocols.time.ntp!
 */


--
dwmw2


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: PC speaker driver patch for 2.4.0-test10-pre3

[David Woodhouse]

[EMAIL PROTECTED] said:
 Apparently Linus doesn't like the way it handles interrupts or
 something, and is therefore 'wrong.' ::shrug:: As long as it's
 available though, I'll use it ;p 

It's not just 'wrong'. It's 'sick'. But it works. The correct fix is to
shift the system timer onto the RTC, leaving the 8253 timer available for us
to abuse for the PC speaker.

See arch/i386/kernel/time.c:

/* This function must be called with interrupts disabled 
 * It was inspired by Steve McCanne's microtime-i386 for BSD.  -- jrs
 * 
 * However, the pc-audio speaker driver changes the divisor so that
 * it gets interrupted rather more often - it loads 64 into the
 * counter rather than 11932! This has an adverse impact on
 * do_gettimeoffset() -- it stops working! What is also not
 * good is that the interval that our timer function gets called
 * is no longer 10.0002 ms, but 9.9767 ms. To get around this
 * would require using a different timing source. Maybe someone
 * could use the RTC - I know that this can interrupt at frequencies
 * ranging from 8192Hz to 2Hz. If I had the energy, I'd somehow fix
 * it so that at startup, the timer code in sched.c would select
 * using either the RTC or the 8253 timer. The decision would be
 * based on whether there was any other device around that needed
 * to trample on the 8253. I'd set up the RTC to interrupt at 1024 Hz,
 * and then do some jiggery to have a version of do_timer that 
 * advanced the clock by 1/1024 s. Every time that reached over 1/100
 * of a second, then do all the old code. If the time was kept correct
 * then do_gettimeoffset could just return 0 - there is no low order
 * divider that can be accessed.
 *
 * Ideally, you would be able to use the RTC for the speaker driver,
 * but it appears that the speaker driver really needs interrupt more
 * often than every 120 us or so.
 *
 * Anyway, this needs more thought  pjsg (1993-08-28)
 * 
 * If you are really that interested, you should be reading
 * comp.protocols.time.ntp!
 */


--
dwmw2


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: PC speaker driver patch for 2.4.0-test10-pre3

[Oliver Xymoron]

On Mon, 23 Oct 2000, David Woodhouse wrote:

 See arch/i386/kernel/time.c:
 
 /* This function must be called with interrupts disabled 
  * It was inspired by Steve McCanne's microtime-i386 for BSD.  -- jrs
  * 
  * However, the pc-audio speaker driver changes the divisor so that
  * it gets interrupted rather more often - it loads 64 into the
  * counter rather than 11932! This has an adverse impact on
  * do_gettimeoffset() -- it stops working! What is also not
  * good is that the interval that our timer function gets called
  * is no longer 10.0002 ms, but 9.9767 ms. To get around this
  * would require using a different timing source.

You can also pretty trivially keep track of an error term so that the
clock is right on average:

#define CLK_HZ 1193200 /* or whatever */
#define ET_PRECISION 1000
#define ET_TIMER_TICKS CLK_HZ*ET_PRECISION/HZ
#define ET_PCSP_TICKS 64*ET_PRECISION
...
static long et=0;

...
et+=ET_PCSP_TICKS;
if(etET_TIMER_TICKS) {
et-=ET_TIMER_TICKS;
simulate_timer_tick();
}

This keeps track of the residual timing error to a few decimal places to
several decimal places and will get closer to HZ than even the current
code.

--
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.." 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: PC speaker driver patch for 2.4.0-test10-pre3

[David Woodhouse]

[EMAIL PROTECTED] said:
  You can also pretty trivially keep track of an error term so that the
 clock is right on average: 

True, but I don't want 'right on average'. I want 'not screwed with at all'.
Shifting the timer tick onto the RTC will give me that. 

Even if we _do_ get the maths right, fudging with the frequency of the 
system timer is still an ugly hack.



--
dwmw2


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: PC speaker driver patch for 2.4.0-test10-pre3

[Oliver Xymoron]

On Mon, 23 Oct 2000, David Woodhouse wrote:

 
 [EMAIL PROTECTED] said:
   You can also pretty trivially keep track of an error term so that the
  clock is right on average: 
 
 True, but I don't want 'right on average'. I want 'not screwed with at all'.
 Shifting the timer tick onto the RTC will give me that. 
 
 Even if we _do_ get the maths right, fudging with the frequency of the 
 system timer is still an ugly hack.

I personally think the system timer is already an ugly hack. HZ is
arbitrary, slow by modern standards, and introduces latency.
As the comment you quoted points out, it's also not very accurate.  
Much better would be an agenda structure with one shot timers between
events and jiffies based on cycle counters. This works on modern hardware
and scales well for higher processor speeds. 

As for the current inaccuracy, the jitter introduced by using an error
term can never be more than a single real interrupt cycle, which is
already well below the average userspace latency.

--
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.." 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: PC speaker driver patch for 2.4.0-test10-pre3

[Mike A. Harris]

On Sun, 22 Oct 2000, Dr. Kelsey Hudson wrote:

>Date: Sun, 22 Oct 2000 13:39:09 -0700 (PDT)
>From: Dr. Kelsey Hudson <[EMAIL PROTECTED]>
>To: Mike A. Harris <[EMAIL PROTECTED]>
>Cc: David Woodhouse <[EMAIL PROTECTED]>,
> Linux Kernel mailing list <[EMAIL PROTECTED]>
>Content-Type: TEXT/PLAIN; charset=US-ASCII
>Subject: Re: PC speaker driver patch for 2.4.0-test10-pre3
>
>> Is there a major compelling reason that this patch isn't included
>> in the standard kernel tree?
>> 
>> 
>> --
>>   Mike A. Harris  -  Linux advocate  -  Open source advocate
>>   Computer Consultant - Capslock Consulting
>>  Copyright 2000 all rights reserved
>> --
>
>Apparently Linus doesn't like the way it handles interrupts or something,
>and is therefore 'wrong.' ::shrug:: As long as it's available though, I'll
>use it ;p

Someone has explained to me why it isn't included, and it made
decent sense to me.  Probably best left as a patch...


--
  Mike A. Harris  -  Linux advocate  -  Open source advocate
  Computer Consultant - Capslock Consulting
 Copyright 2000 all rights reserved
--

#[Mike A. Harris bash tip #1 - separate history files per virtual console]
# Put the following at the bottom of your ~/.bash_profile
[ ! -d ~/.bash_histdir ] && mkdir ~/.bash_histdir
tty |grep "^/dev/tty[0-9]" >& /dev/null && \
export HISTFILE=~/.bash_histdir/.$(tty | sed -e 's/.*\///')

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: PC speaker driver patch for 2.4.0-test10-pre3

[Dr. Kelsey Hudson]

> Is there a major compelling reason that this patch isn't included
> in the standard kernel tree?
> 
> 
> --
>   Mike A. Harris  -  Linux advocate  -  Open source advocate
>   Computer Consultant - Capslock Consulting
>  Copyright 2000 all rights reserved
> --

Apparently Linus doesn't like the way it handles interrupts or something,
and is therefore 'wrong.' ::shrug:: As long as it's available though, I'll
use it ;p

 Kelsey Hudson   [EMAIL PROTECTED] 
 Software Engineer
 Compendium Technologies, Inc   (619) 725-0771
--- 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: PC speaker driver patch for 2.4.0-test10-pre3

[Dr. Kelsey Hudson]

 Is there a major compelling reason that this patch isn't included
 in the standard kernel tree?
 
 
 --
   Mike A. Harris  -  Linux advocate  -  Open source advocate
   Computer Consultant - Capslock Consulting
  Copyright 2000 all rights reserved
 --

Apparently Linus doesn't like the way it handles interrupts or something,
and is therefore 'wrong.' ::shrug:: As long as it's available though, I'll
use it ;p

 Kelsey Hudson   [EMAIL PROTECTED] 
 Software Engineer
 Compendium Technologies, Inc   (619) 725-0771
--- 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: PC speaker driver patch for 2.4.0-test10-pre3

[Mike A. Harris]

On Sun, 22 Oct 2000, Dr. Kelsey Hudson wrote:

Date: Sun, 22 Oct 2000 13:39:09 -0700 (PDT)
From: Dr. Kelsey Hudson [EMAIL PROTECTED]
To: Mike A. Harris [EMAIL PROTECTED]
Cc: David Woodhouse [EMAIL PROTECTED],
 Linux Kernel mailing list [EMAIL PROTECTED]
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: Re: PC speaker driver patch for 2.4.0-test10-pre3

 Is there a major compelling reason that this patch isn't included
 in the standard kernel tree?
 
 
 --
   Mike A. Harris  -  Linux advocate  -  Open source advocate
   Computer Consultant - Capslock Consulting
  Copyright 2000 all rights reserved
 --

Apparently Linus doesn't like the way it handles interrupts or something,
and is therefore 'wrong.' ::shrug:: As long as it's available though, I'll
use it ;p

Someone has explained to me why it isn't included, and it made
decent sense to me.  Probably best left as a patch...


--
  Mike A. Harris  -  Linux advocate  -  Open source advocate
  Computer Consultant - Capslock Consulting
 Copyright 2000 all rights reserved
--

#[Mike A. Harris bash tip #1 - separate history files per virtual console]
# Put the following at the bottom of your ~/.bash_profile
[ ! -d ~/.bash_histdir ]  mkdir ~/.bash_histdir
tty |grep "^/dev/tty[0-9]"  /dev/null  \
export HISTFILE=~/.bash_histdir/.$(tty | sed -e 's/.*\///')

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: PC speaker driver patch for 2.4.0-test10-pre3

[Alan Cox]

> >Thanks to Erik Inge Bols=F8 for porting it to 2.3.45, this saving me m=
> ost of=20
> >the work.
> 
> Is there a major compelling reason that this patch isn't included
> in the standard kernel tree?

It goes hacking around with the clock

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: PC speaker driver patch for 2.4.0-test10-pre3

[David Woodhouse]

On Tue, 17 Oct 2000, Mike A. Harris wrote:

> Is there a major compelling reason that this patch isn't included
> in the standard kernel tree?

It does _evil_ things with the timers. If we shift the system timer tick
onto the RTC, it won't be so evil, and I'd consider trying to submit it
for 2.5.

Patches accepted. 

-- 
dwmw2


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: PC speaker driver patch for 2.4.0-test10-pre3

[Alan Cox]

 Thanks to Erik Inge Bols=F8 for porting it to 2.3.45, this saving me m=
 ost of=20
 the work.
 
 Is there a major compelling reason that this patch isn't included
 in the standard kernel tree?

It goes hacking around with the clock

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: PC speaker driver patch for 2.4.0-test10-pre3

[Mike A. Harris]

On Mon, 16 Oct 2000, David Woodhouse wrote:

>Date: Mon, 16 Oct 2000 16:07:13 +0100
>From: David Woodhouse <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Cc: [EMAIL PROTECTED]
>Content-Type: text/plain; charset=iso-8859-15
>Subject: PC speaker driver patch for 2.4.0-test10-pre3
>
>ftp.uk.linux.org:/pub/people/dwmw2/pcsp/patch-pcsp-soundcore-2.4.0-test10-pre3
>
>Thanks to Erik Inge Bolsø for porting it to 2.3.45, this saving me most of 
>the work.

Is there a major compelling reason that this patch isn't included
in the standard kernel tree?


--
  Mike A. Harris  -  Linux advocate  -  Open source advocate
  Computer Consultant - Capslock Consulting
 Copyright 2000 all rights reserved
--

[Quote: Linus Torvalds linux-2.4.0-test8-pre6 release message - Sept 6, 2000]
But I have this ugly feeling that I'm coming down with the same flu that
everybody else in my family had the last week, so I'd better release this
before I start puking on my keyboard.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: PC speaker driver patch for 2.4.0-test10-pre3

[Mike A. Harris]

On Mon, 16 Oct 2000, David Woodhouse wrote:

Date: Mon, 16 Oct 2000 16:07:13 +0100
From: David Woodhouse [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Content-Type: text/plain; charset=iso-8859-15
Subject: PC speaker driver patch for 2.4.0-test10-pre3

ftp.uk.linux.org:/pub/people/dwmw2/pcsp/patch-pcsp-soundcore-2.4.0-test10-pre3

Thanks to Erik Inge Bolsø for porting it to 2.3.45, this saving me most of 
the work.

Is there a major compelling reason that this patch isn't included
in the standard kernel tree?


--
  Mike A. Harris  -  Linux advocate  -  Open source advocate
  Computer Consultant - Capslock Consulting
 Copyright 2000 all rights reserved
--

[Quote: Linus Torvalds linux-2.4.0-test8-pre6 release message - Sept 6, 2000]
But I have this ugly feeling that I'm coming down with the same flu that
everybody else in my family had the last week, so I'd better release this
before I start puking on my keyboard.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/