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 (bu
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&m=118167999520788&w=2
--
~Randy
Is it possible to write a kernel module which, when loaded, will blow
the PC speaker?
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
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
Is it possible to write a kernel module which, when loaded, will blow
the PC speaker?
Is it possible to write a kernel module which, when loaded, will blow
the PC speaker?
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-kerne
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&m=118165248822375&w=2
are you a bot?
--
~Randy
Is it possible to write a kernel module which, when loaded, will blow
the PC speaker?
Is it possible to write a kernel module which, when loaded, will blow
the PC speaker?
re very important.
>
> This should not be confused with the click function in certain specialized
> keyboards such as lkkbd.c.
> That function does a serio write to the client to activate clicks locally.
> In contrast, this function generates a one-time pulse at the pc speaker,
> or
activate clicks locally.
In contrast, this function generates a one-time pulse at the pc speaker,
or through a similar driver, so that modules can click whenever they want,
e.g. when a key is echoed back to you by a running application,
perhaps a thousand miles away over ssh, so you know all is well.
A
ered output devices?
Are "force-feedback" devices meaning devices like a rumble-gamepad
device? Isn't that providing output via feedback?
Though, I would agree, most of these devices would be thought of
as "input" devices. Dang PC-SPEAKER...um...since the driver is co
On Fri, 15 Feb 2008 13:19:11 PST, Linda Walsh said:
> I'm wondering how the generic, builtin PC-Speaker (config option
> "INPUT_PCSPKR") can be used as an input device.
>
> If it can not be used for input, why is it under the input config section:
>
> &quo
On 02/15/2008 10:19 PM, Linda Walsh wrote:
I'm wondering how the generic, builtin PC-Speaker (config option
"INPUT_PCSPKR") can be used as an input device.
If it can not be used for input, why is it under the input config section:
"Device Drivers"
+
I'm wondering how the generic, builtin PC-Speaker (config option
"INPUT_PCSPKR") can be used as an input device.
If it can not be used for input, why is it under the input config section:
"Device Drivers"
+ -> "Input Device Support"
+ -> "M
Linus Torvalds writes:
> and wouldn't it be nice if we just changed it to
>
> #include
>
> and got rid of one totally unnecessary stupid arch difference?
Looks fine to me. I'll do a patch for powerpc & ppc.
Paul.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
On Fri, 2 Nov 2007, Ralf Baechle wrote:
>
> The Jazz machines have to use the PIT timer for dyntick and highresolution
> kernels. This may break because currently just like i386 used to do MIPS
> uses two separate spinlocks in the actual PIT code and the PC speaker
> code. So
The Jazz machines have to use the PIT timer for dyntick and highresolution
kernels. This may break because currently just like i386 used to do MIPS
uses two separate spinlocks in the actual PIT code and the PC speaker
code. So switch to do it the same that x86 currently does PIT locking.
Signed
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 t
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
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 completel
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
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
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, usua
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
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 cryst
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 f
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 ea
> 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
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 sc
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 te
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 th
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
> > >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 th
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
-
der 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.
> >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 *DESI
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 loade
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 m
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?
>>
>
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
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
th
Is it possible to write a kernel module which, when loaded, will blow the PC
speaker?
-
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
26,27 +27,13 @@
static char pcspkr_name[] = "PC Speaker";
static char pcspkr_phys[] = "isa0061/input0";
static struct input_dev pcspkr_dev;
+enum { PCSPKR_NORMAL, PCSPKR_SUSPENDED };
-static DEFINE_SPINLOCK(i8253_beep_lock);
-
-static int pcspkr_event(struct input_dev *dev,
Quoth Nico Schottelius:
> Can somebody give me a hint where to find documentation about
> sysctl and howto use/program that ?
> This is what Simon and David suggested.
>
> But as long as I am not able to make sysctl's, I would like
> to add this feature under the General setup.
>
> What do you
serspace bugs in the kernel, and
> probably not desirable, even if I think I'd disable the pc speaker if
> the kernel actually asked me. If nothing else, I figure it would make
> my kernel 0.5k or so smaller ;)
Something about that, didn't make any comparision to a original
2.
Keith Owens wrote:
> On Fri, 04 May 2001 13:37:08 +0200,
> Nico Schottelius <[EMAIL PROTECTED]> wrote:
> >I have searched a long time for a method to disable the internal
> >speaker for every application, every daemon and so on.
>
> Userspace problem, userspace fix.
This sounds good :) ...
gree that this is fixing userspace bugs in the kernel, and
probably not desirable, even if I think I'd disable the pc speaker if
the kernel actually asked me. If nothing else, I figure it would make
my kernel 0.5k or so smaller ;)
Oystein
--
When in doubt: Recompile.
-
To unsubscribe from th
On Fri, 04 May 2001 13:37:08 +0200,
Nico Schottelius <[EMAIL PROTECTED]> wrote:
>I have searched a long time for a method to disable the internal
>speaker for every application, every daemon and so on.
Userspace problem, userspace fix.
setterm -blength 0 (text)
xset b 0 (X11)
-
To unsubscr
On Fri, 4 May 2001, Nico Schottelius wrote:
> I have searched a long time for a method to disable the internal
> speaker for every application, every daemon and so on.
It would be cool if that weren't a compile time option but configurable at
runtime (via sysctl).
Simon
--
GPG public key a
2. Changed arch/{i386,alpha,ppc,arm,mips}/config.in :
if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then
bool ' Disable the PC-Speaker' CONFIG_DISABLE_PC_SPEAKER
fi
(should be the last item of the 'General Setup' Menu)
3. Changed init/
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
>
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 so
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 g
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 c
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
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'.
> > > Shifti
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.
> >
>
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
[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 righ
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 get
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. -- j
ROTECTED]>
>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?
>>
>>
>> -
> 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 Consul
> >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 "unsubscr
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.
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-
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.
--
dwmw2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Includes a fix provided by Paul for building without CONFIG_PCSP_MIXER.
ftp.uk.linux.org:/pub/people/dwmw2/pcsp/patch-pcsp-soundcore-2.2.1{7,8-pre16}
--
dwmw2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the
71 matches
Mail list logo
