Is there any way on an x86 system that a working ps2 keyboard/mouse can be
disabled by writing data to the device?

Thanks.

On Fri, 23 Nov 2007 08:22:53 -0600, Eccentric OpenBSD User Dave
<spamtrap@crayne.org> wrote:

>Is there any way on an x86 system that a working ps2 keyboard/mouse can be
>disabled by writing data to the device?
>
>Thanks.

If using Windows (95-XP) you can use BlockInput.
http://msdn2.microsoft.com/en-us/library/ms646290.aspx

Am Fri, 23 Nov 2007 08:22:53 -0600 schrieb Eccentric OpenBSD User Dave:

> Is there any way on an x86 system that a working ps2 keyboard/mouse can be
> disabled by writing data to the device?
> 
> Thanks.
------------------
http://www.advancedcontent.net/warrior/Old%20stuff/files/mouse.inc
------------------
http://cutemouse.sourceforge.net
------------------
Ralf Browns Interrupt List(RBIL)
http://www.pobox.com/~ralf/files.html
ftp://ftp.cs.cmu.edu/afs/cs.cmu.edu/user/ralf/pub/
RBIL->Inter61a.zip->Interrup.c
--------M-15C200-----------------------------
INT 15 - SYSTEM - POINTING DEVICE BIOS INTERFACE (PS) - ENABLE/DISABLE
.....
.....
disablePS2:
xor	bx, bx		; set mouse off
mov	ax, 0C200h
int 15h
xor     bx, bx
mov     es, bx
mov     ax, 0C207h	; es:bx=ptr to handler
int 15h
------------------

Dirk

In alt.comp.hardware.amd.x86-64 Ed <spamtrap@crayne.org> wrote:
> On Fri, 23 Nov 2007 08:22:53 -0600, Eccentric OpenBSD User Dave
> <spamtrap@crayne.org> wrote:
> 
>>Is there any way on an x86 system that a working ps2 keyboard/mouse can be
>>disabled by writing data to the device?
>>
>>Thanks.
> 
> If using Windows (95-XP) you can use BlockInput.
> http://msdn2.microsoft.com/en-us/library/ms646290.aspx

Thanks. Actually, I am running X windows and I was looking for info 
about a possible exploit that I may be experiencing. 

In alt.comp.hardware.amd.x86-64 Eccentric OpenBSD User Dave <spamtrap@crayne.org> wrote:
> In alt.comp.hardware.amd.x86-64 Ed <spamtrap@crayne.org> wrote:
>> On Fri, 23 Nov 2007 08:22:53 -0600, Eccentric OpenBSD User Dave
>> <spamtrap@crayne.org> wrote:
>> 
>>>Is there any way on an x86 system that a working ps2 keyboard/mouse can be
>>>disabled by writing data to the device?
>>>
>>>Thanks.
>> 
>> If using Windows (95-XP) you can use BlockInput.
>> http://msdn2.microsoft.com/en-us/library/ms646290.aspx
> 
> Thanks. Actually, I am running X windows and I was looking for info 
> about a possible exploit that I may be experiencing. 

The question I am really trying to get an answer to is whether it is
possible for the cpu to send commands to the x86 keyboard/mouse that
will cause those devices to shut down permanently, effectively making
them useless. 

Dirk Wolfgang Glomp <spamtrap@crayne.org> wrote:
> Am Fri, 23 Nov 2007 08:22:53 -0600 schrieb Eccentric OpenBSD User Dave:
> 
>> Is there any way on an x86 system that a working ps2 keyboard/mouse can be
>> disabled by writing data to the device?
>> 
>> Thanks.
> ------------------
> http://www.advancedcontent.net/warrior/Old%20stuff/files/mouse.inc
> ------------------
> http://cutemouse.sourceforge.net
> ------------------
> Ralf Browns Interrupt List(RBIL)
> http://www.pobox.com/~ralf/files.html
> ftp://ftp.cs.cmu.edu/afs/cs.cmu.edu/user/ralf/pub/
> RBIL->Inter61a.zip->Interrup.c
> --------M-15C200-----------------------------
> INT 15 - SYSTEM - POINTING DEVICE BIOS INTERFACE (PS) - ENABLE/DISABLE
> ....
> ....
> disablePS2:
> xor     bx, bx          ; set mouse off
> mov     ax, 0C200h
> int 15h
> xor     bx, bx
> mov     es, bx
> mov     ax, 0C207h      ; es:bx=ptr to handler
> int 15h
> ------------------
> 
> Dirk

Thanks! Does this code actually disable the mouse or just tell the
cpu to ignore mouse input? If disable, will the mouse stay disabled
through power cycling or start working again after the power has been
cycled?

 

Am Sat, 24 Nov 2007 15:37:09 -0600 schrieb Eccentric OpenBSD User Dave:

> Dirk Wolfgang Glomp <spamtrap@crayne.org> wrote:
>> Am Fri, 23 Nov 2007 08:22:53 -0600 schrieb Eccentric OpenBSD User Dave:
>> 
>>> Is there any way on an x86 system that a working ps2 keyboard/mouse can be
>>> disabled by writing data to the device?
>>> 
>>> Thanks.
>> ------------------
>> http://www.advancedcontent.net/warrior/Old%20stuff/files/mouse.inc
>> ------------------
>> http://cutemouse.sourceforge.net
>> ------------------
>> Ralf Browns Interrupt List(RBIL)
>> http://www.pobox.com/~ralf/files.html
>> ftp://ftp.cs.cmu.edu/afs/cs.cmu.edu/user/ralf/pub/
>> RBIL->Inter61a.zip->Interrup.c
>> --------M-15C200-----------------------------
>> INT 15 - SYSTEM - POINTING DEVICE BIOS INTERFACE (PS) - ENABLE/DISABLE
>> ....
>> ....
>> disablePS2:
>> xor     bx, bx          ; set mouse off
>> mov     ax, 0C200h
>> int 15h
>> xor     bx, bx
>> mov     es, bx
>> mov     ax, 0C207h      ; es:bx=ptr to handler
>> int 15h
>> ------------------
>> 
>> Dirk
> 
> Thanks! Does this code actually disable the mouse or just tell the
> cpu to ignore mouse input?

I think the first bios-interrupt disable the mouse via port-acess and the
second interrupt disable only a mousehandler.

> If disable, will the mouse stay disabled
> through power cycling or start working again after the power has been
> cycled?

Reinititialize is possible.

RBIL->Inter61d.zip->Ports.a
--------K-P0060006F--------------------------
PORT 0060-006F - KEYBOARD CONTROLLER 804x (8041, 8042)...
....
(Table P0387)
Values for Mouse functions (for PS/2-like pointing devices):
....
Table P0401)
Values for keyboard controller commands (data goes to PORT 0060h):
....
A7h	MCA	disable mouse port
....
A8h	MCA	enable mouse port

Dirk

Dirk Wolfgang Glomp <spamtrap@crayne.org> wrote:
> Am Sat, 24 Nov 2007 15:37:09 -0600 schrieb Eccentric OpenBSD User Dave:
> 
>> Dirk Wolfgang Glomp <spamtrap@crayne.org> wrote:
>>> Am Fri, 23 Nov 2007 08:22:53 -0600 schrieb Eccentric OpenBSD User Dave:
>>> 
>>>> Is there any way on an x86 system that a working ps2 keyboard/mouse can be
>>>> disabled by writing data to the device?
>>>> 
>>>> Thanks.
>>> ------------------
>>> http://www.advancedcontent.net/warrior/Old%20stuff/files/mouse.inc
>>> ------------------
>>> http://cutemouse.sourceforge.net
>>> ------------------
>>> Ralf Browns Interrupt List(RBIL)
>>> http://www.pobox.com/~ralf/files.html
>>> ftp://ftp.cs.cmu.edu/afs/cs.cmu.edu/user/ralf/pub/
>>> RBIL->Inter61a.zip->Interrup.c
>>> --------M-15C200-----------------------------
>>> INT 15 - SYSTEM - POINTING DEVICE BIOS INTERFACE (PS) - ENABLE/DISABLE
>>> ....
>>> ....
>>> disablePS2:
>>> xor     bx, bx          ; set mouse off
>>> mov     ax, 0C200h
>>> int 15h
>>> xor     bx, bx
>>> mov     es, bx
>>> mov     ax, 0C207h      ; es:bx=ptr to handler
>>> int 15h
>>> ------------------
>>> 
>>> Dirk
>> 
>> Thanks! Does this code actually disable the mouse or just tell the
>> cpu to ignore mouse input?
> 
> I think the first bios-interrupt disable the mouse via port-acess and the
> second interrupt disable only a mousehandler.
> 
>> If disable, will the mouse stay disabled
>> through power cycling or start working again after the power has been
>> cycled?
> 
> Reinititialize is possible.
> 
> RBIL->Inter61d.zip->Ports.a
> --------K-P0060006F--------------------------
> PORT 0060-006F - KEYBOARD CONTROLLER 804x (8041, 8042)...
> ...
> (Table P0387)
> Values for Mouse functions (for PS/2-like pointing devices):
> ...
> Table P0401)
> Values for keyboard controller commands (data goes to PORT 0060h):
> ...
> A7h     MCA     disable mouse port
> ...
> A8h     MCA     enable mouse port
> 
> Dirk

The reason I ask about this is that in the last few months I have had
several keyboards and mice just stop working. Some of these devices
were essentially brand new. If they are not being disabled by exploits
breaking the hardware, then the quality of mice and keyboards seems to
be going downhill. I'm still trying to figure out what's going on. 

On Sat, 24 Nov 2007 18:55:03 -0600
Eccentric OpenBSD User Dave  <spamtrap@crayne.org> wrote:

> The reason I ask about this is that in the last few months I have had
> several keyboards and mice just stop working. Some of these devices
> were essentially brand new. If they are not being disabled by exploits
> breaking the hardware, then the quality of mice and keyboards seems to
> be going downhill. I'm still trying to figure out what's going on. 

In the past, there have been components which could be made useless by
software commands. For example, monitors could be made to burn out by
setting invalid scan frequencies, and disk drives could be ruined by
making them try to seek to invalid cylinder numbers. However, I have
never heard of anything that similar for keyboards and mice.

-- Chuck

Eccentric OpenBSD User Dave wrote:
> 
> The reason I ask about this is that in the last few months I have had
> several keyboards and mice just stop working. Some of these devices
> were essentially brand new. If they are not being disabled by exploits
> breaking the hardware, then the quality of mice and keyboards seems to
> be going downhill. I'm still trying to figure out what's going on. 
> 

You might be a victim of one of the latest idiocies pushed by Microsoft, 
called "tilt bits."  They are a requirement for the Vista logo, as far 
as I understand.  The explicit purpose of a tilt bit is to turn a minor 
glitch into a total malfunction.  The purpose of this, of course, is DRM 
-- only approved hardware devices can talk to only approved software 
systems to display approved media.

Welcome to facism as applied to hardware.

	-hpa

H. Peter Anvin <spamtrap@crayne.org> wrote:
> Eccentric OpenBSD User Dave wrote:
>> 
>> The reason I ask about this is that in the last few months I have had
>> several keyboards and mice just stop working. Some of these devices
>> were essentially brand new. If they are not being disabled by exploits
>> breaking the hardware, then the quality of mice and keyboards seems to
>> be going downhill. I'm still trying to figure out what's going on. 
>> 
> 
> You might be a victim of one of the latest idiocies pushed by Microsoft, 
> called "tilt bits."  They are a requirement for the Vista logo, as far 
> as I understand.  The explicit purpose of a tilt bit is to turn a minor 
> glitch into a total malfunction.  The purpose of this, of course, is DRM 
> -- only approved hardware devices can talk to only approved software 
> systems to display approved media.
> 
> Welcome to facism as applied to hardware.
> 
>        -hpa

I quit using MS software about 1995 after an internet exploit wiped
out several ntfs scsi disks and corrupted the flash bios on the computer
so that I could not boot from cdrom to reinstall until after the bios
was reflashed. I have been running ever since OpenBSD. I have become
convinced that OpenBSD has backdoors via the video card which backdoors
can be activated when X windows is running. I am no longer
running x-windows while connected to the internet because of the problems
I have had the last few months since I upgraded to OpenBSD 4.1 and 4.2
with dying keyboards and mice. 4.2 seems to have many problems right now.

Charles Crayne wrote:

>> The reason I ask about this is that in the last few months I have had
>> several keyboards and mice just stop working. Some of these devices
>> were essentially brand new. If they are not being disabled by exploits
>> breaking the hardware, then the quality of mice and keyboards seems to
>> be going downhill. I'm still trying to figure out what's going on.

> In the past, there have been components which could be made useless by
> software commands. For example, monitors could be made to burn out by
> setting invalid scan frequencies, and disk drives could be ruined by
> making them try to seek to invalid cylinder numbers. However, I have
> never heard of anything that similar for keyboards and mice.

I once found a few defective PS/2 keyboards & mousies claimed by
a client. The problem disappeared after we told him that only
USB-connected devices are 'hot-plug' units. And by any luck the
PS/2-controller seems to be protected and survived this attack.

__
wolfgang

Eccentric OpenBSD User Dave wrote:
> In alt.comp.hardware.amd.x86-64 Eccentric OpenBSD User Dave <spamtrap@crayne.org> wrote:
>> In alt.comp.hardware.amd.x86-64 Ed <spamtrap@crayne.org> wrote:
>>> On Fri, 23 Nov 2007 08:22:53 -0600, Eccentric OpenBSD User Dave
>>> <spamtrap@crayne.org> wrote:
>>>
>>>> Is there any way on an x86 system that a working ps2 keyboard/mouse can be
>>>> disabled by writing data to the device?
>>>>
>>>> Thanks.
>>> If using Windows (95-XP) you can use BlockInput.
>>> http://msdn2.microsoft.com/en-us/library/ms646290.aspx
>> Thanks. Actually, I am running X windows and I was looking for info 
>> about a possible exploit that I may be experiencing. 
> 
> The question I am really trying to get an answer to is whether it is
> possible for the cpu to send commands to the x86 keyboard/mouse that
> will cause those devices to shut down permanently, effectively making
> them useless. 
> 
Why would you want to do this?

In alt.comp.hardware.amd.x86-64 Marcus Red <spamtrap@crayne.org> wrote:
> Eccentric OpenBSD User Dave wrote:
>> In alt.comp.hardware.amd.x86-64 Eccentric OpenBSD User Dave <spamtrap@crayne.org> wrote:
>>> In alt.comp.hardware.amd.x86-64 Ed <spamtrap@crayne.org> wrote:
>>>> On Fri, 23 Nov 2007 08:22:53 -0600, Eccentric OpenBSD User Dave
>>>> <spamtrap@crayne.org> wrote:
>>>>
>>>>> Is there any way on an x86 system that a working ps2 keyboard/mouse can be
>>>>> disabled by writing data to the device?
>>>>>
>>>>> Thanks.
>>>> If using Windows (95-XP) you can use BlockInput.
>>>> http://msdn2.microsoft.com/en-us/library/ms646290.aspx
>>> Thanks. Actually, I am running X windows and I was looking for info 
>>> about a possible exploit that I may be experiencing. 
>> 
>> The question I am really trying to get an answer to is whether it is
>> possible for the cpu to send commands to the x86 keyboard/mouse that
>> will cause those devices to shut down permanently, effectively making
>> them useless. 
>> 
> Why would you want to do this?

I don't want to do this, but I suspect that some X-related exploit is doing
it to me as a simple DOS attack. If this is *not* happening to me, then I
am buying really crappy mice and keyboards and need to switch to better
brands. 

On Sat, 24 Nov 2007 18:55:03 -0600, Eccentric OpenBSD User Dave
<spamtrap@crayne.org> wrote:
>
>The reason I ask about this is that in the last few months I have had
>several keyboards and mice just stop working. Some of these devices
>were essentially brand new. If they are not being disabled by exploits
>breaking the hardware, then the quality of mice and keyboards seems to
>be going downhill. I'm still trying to figure out what's going on. 
>

Hmm, my first thought (well before thinking it was an exploit) would
be that there is some system chip that services both the keyboards
and mice that is getting flaky... maybe an I/O port controller.  You
can easily rule out the quality of keyboards and mice as an issue by
testing them on another system.  As far as telling hardware from
software problems, maybe you can boot from a bootable CD with
a clean version of Linux on it.   If there is a software exploit that
turns off the ports, then it must run on each boot *or* there must be
a port map in CMOS RAM that can be modified... which I doubt.

Another possible exploit:  I presume that these I/O ports are under
control of the PnP system, and their addresses can be modified.
But I'm not sure where that info is stored... I think some devices
(like sound cards) store it in flash ram on the device itself, so it
would still be there after a reboot.  I don't know how likely it would
be for keyboard and mouse addresses to be in flash.  At any rate,
after a clean boot, the device manager ought to show the actual
addresses and allow you to set them properly (since no exploit
would be able to interpose itself and misdirect the changes).

Best regards,


Bob Masta
 
              DAQARTA  v3.50
   Data AcQuisition And Real-Time Analysis
             www.daqarta.com
Scope, Spectrum, Spectrogram, FREE Signal Generator
        Science with your sound card!

"Eccentric OpenBSD User Dave" <spamtrap@crayne.org> wrote in message
> The reason I ask about this is that in the last few months I have had
> several keyboards and mice just stop working. Some of these devices
> were essentially brand new. If they are not being disabled by exploits
> breaking the hardware, then the quality of mice and keyboards seems to
> be going downhill. I'm still trying to figure out what's going on.
>

It's possible to be drawing too much current for a keyboard, but I'd have
doubts about a mouse.  This would damage the motherboard circuitry and then
no keyboards would work at all.  But, it seems that replacement keyboards
and
mice work for you...

If you're using an old AT keyboard with an AT to PS/2
adapter, then you could be exceeding the PS/2 port's ability to supply
current.  According to this link, old keyboards required about 112ma of
current whereas a modern keyboard only draws about 1.2ma.
http://www.geocities.com/jszybowski/keyboard/

Probably the easiest way for you to test is to setup a DOS boot disk and
mouse drivers:
http://www.freedos.org/
http://cutemouse.sourceforge.net/

Do they work with DOS?


Rod Pemberton

"Eccentric OpenBSD User Dave" <spamtrap@crayne.org> wrote in message
> The question I am really trying to get an answer to is whether it is
> possible for the cpu to send commands to the x86 keyboard/mouse that
> will cause those devices to shut down permanently, effectively making
> them useless.
>

Permanently?...

Does your BIOS may allow you to disable them, e.g., for USB or embedded?  If
so, maybe CMOS is being corrupted.  But, I'd think that would be temporary
and would block other keyboards from working...

You can temporarily disable access by reprogramming PIC's or sending
commands to the keyboard controller, if your OS gives you the privilege.
For the later to become "permanent," it could be written into the
bootloader, some part of the early OS stages, BIOS, video BIOS, etc.  The
sequences are small and short.  Of course, this wouldn't allow replacement
keyboards and mice to work...

If it's an exploit, as you mentioned elsewhere, you need to systematically
replace all possible "bad" code with good.   First, wipe the CMOS, or you
could try toggling all the BIOS settings, saving, toggling back, resaving,
to "wipe" CMOS, then reinstall your bootloader, reinstalling FreeBSD,
reinstalling XWindows, and as a last resort reflashing your BIOS (taking
care with this one...), etc.


Rod Pemberton

"H. Peter Anvin" <spamtrap@crayne.org> wrote in message
news:4748DB91.1060008@zytor.com...
> Eccentric OpenBSD User Dave wrote:
> >
> > The reason I ask about this is that in the last few months I have had
> > several keyboards and mice just stop working. Some of these devices
> > were essentially brand new. If they are not being disabled by exploits
> > breaking the hardware, then the quality of mice and keyboards seems to
> > be going downhill. I'm still trying to figure out what's going on.
> >
>
> You might be a victim of one of the latest idiocies pushed by Microsoft,
> called "tilt bits."  They are a requirement for the Vista logo, as far
> as I understand.  The explicit purpose of a tilt bit is to turn a minor
> glitch into a total malfunction.  The purpose of this, of course, is DRM
> -- only approved hardware devices can talk to only approved software
> systems to display approved media.
>
> Welcome to facism as applied to hardware.
>

I'm amazed this applies for our "OpenBSD User" who is running "X windows
[sic]"...  I quess I better buy some MS stock due to their amazing inroads
into the *nix software market!  I didn't know they had a OpenBSD distro
called Vista!  ;-)


Rod Pemberton

Bob Masta <NoSpam@daqarta.com> wrote:
> On Sat, 24 Nov 2007 18:55:03 -0600, Eccentric OpenBSD User Dave
> <spamtrap@crayne.org> wrote:
>>
>>The reason I ask about this is that in the last few months I have had
>>several keyboards and mice just stop working. Some of these devices
>>were essentially brand new. If they are not being disabled by exploits
>>breaking the hardware, then the quality of mice and keyboards seems to
>>be going downhill. I'm still trying to figure out what's going on. 
>>
> 
> Hmm, my first thought (well before thinking it was an exploit) would
> be that there is some system chip that services both the keyboards
> and mice that is getting flaky... maybe an I/O port controller.  You
> can easily rule out the quality of keyboards and mice as an issue by
> testing them on another system.

I did this. Keyboards had hard errors for specific keys which made the
keyboards unusable although they still functioned. Mice positioning simply
stopped working on two mice, one of them 2 months old. Both mice failed
with the same symptoms.

>  As far as telling hardware from
> software problems, maybe you can boot from a bootable CD with
> a clean version of Linux on it.   If there is a software exploit that
> turns off the ports, then it must run on each boot *or* there must be
> a port map in CMOS RAM that can be modified... which I doubt.

Actually I am running OpenBSD on an AM2 AMD64 computer. What that means
is that, in addition to having to worry about soft malware, I also need
to think about SMM and VM malware, not to mention a possibly reprogrammed
bios. There are other symptoms which suggest the above possibilities.

> Another possible exploit:  I presume that these I/O ports are under
> control of the PnP system, and their addresses can be modified.
> But I'm not sure where that info is stored... I think some devices
> (like sound cards) store it in flash ram on the device itself, so it
> would still be there after a reboot.  I don't know how likely it would
> be for keyboard and mouse addresses to be in flash.  At any rate,
> after a clean boot, the device manager ought to show the actual
> addresses and allow you to set them properly (since no exploit
> would be able to interpose itself and misdirect the changes).

The keyboard and mouse problems appear only when I am running X. 
So I have quit running X while connected to the internet.
Unfortunately, X is getting ever more deeply embedded into the OS,
and the system is now not very usable if the X libraries are not
installed, whether or not X is actually run. 
Other people using OpenBSD are starting to report keyboard and mouse
problems on the misc mailing list. It has occurred to me that backdoors
may have been introduced into the OS. How much cash would it take from
a spook to get you to introduce a back door into a secure OS that you were
a developer for? Just call me paranoid. :-)

> Best regards,
> 
> 
> Bob Masta
> 
>              DAQARTA  v3.50
>   Data AcQuisition And Real-Time Analysis
>             www.daqarta.com
> Scope, Spectrum, Spectrogram, FREE Signal Generator
>        Science with your sound card!
> 

In comp.lang.asm.x86 Rod Pemberton <spamtrap@crayne.org> wrote:
> 
> "Eccentric OpenBSD User Dave" <spamtrap@crayne.org> wrote in message
>> The question I am really trying to get an answer to is whether it is
>> possible for the cpu to send commands to the x86 keyboard/mouse that
>> will cause those devices to shut down permanently, effectively making
>> them useless.
>>
> 
> Permanently?...

As in 'the keyboards and mice don't work any more on other computers'.
 
> Does your BIOS may allow you to disable them, e.g., for USB or embedded?  If
> so, maybe CMOS is being corrupted.  But, I'd think that would be temporary
> and would block other keyboards from working...

Actually, one of the other problems I was having was the loss of the ability
to enter the bios at boot time by pressing the delete key. This was the
problem that made me start thinking that it might be time to reflash the bios.

> You can temporarily disable access by reprogramming PIC's or sending
> commands to the keyboard controller, if your OS gives you the privilege.
> For the later to become "permanent," it could be written into the
> bootloader, some part of the early OS stages, BIOS, video BIOS, etc.  The

Don't forget SMM.

> sequences are small and short.  Of course, this wouldn't allow replacement
> keyboards and mice to work...
> 
> If it's an exploit, as you mentioned elsewhere, you need to systematically
> replace all possible "bad" code with good.   First, wipe the CMOS, or you
> could try toggling all the BIOS settings, saving, toggling back, resaving,
> to "wipe" CMOS, then reinstall your bootloader, reinstalling FreeBSD,

Did all that multiple times.
I'm running OpenBSD. I reinstall early and often :-).

One of the problems that suggests to me that there is a backdoor in OpenBSD is
that, after installing OpenBSD from cdrom and doing nothing else, within a few
hours the cdrom would not open when the OS was running. This happened several
times immediately after installing the OS and verifying that the cdrom drive
was working properly. At one point all of the usb devices malfunctioned althoughthe devices I was trying to read worked without error on a different system.

> reinstalling XWindows, and as a last resort reflashing your BIOS (taking
> care with this one...), etc.

Thanks for the ideas!
 
> 
> Rod Pemberton
> 

Rod Pemberton <spamtrap@crayne.org> wrote:
> 
> "Eccentric OpenBSD User Dave" <spamtrap@crayne.org> wrote in message
>> The reason I ask about this is that in the last few months I have had
>> several keyboards and mice just stop working. Some of these devices
>> were essentially brand new. If they are not being disabled by exploits
>> breaking the hardware, then the quality of mice and keyboards seems to
>> be going downhill. I'm still trying to figure out what's going on.
>>
> 
> It's possible to be drawing too much current for a keyboard, but I'd have
> doubts about a mouse.  This would damage the motherboard circuitry and then
> no keyboards would work at all.  But, it seems that replacement keyboards
> and mice work for you...
> 
> If you're using an old AT keyboard with an AT to PS/2
> adapter, then you could be exceeding the PS/2 port's ability to supply
> current.  According to this link, old keyboards required about 112ma of
> current whereas a modern keyboard only draws about 1.2ma.
> http://www.geocities.com/jszybowski/keyboard/
> 
> Probably the easiest way for you to test is to setup a DOS boot disk and
> mouse drivers:
> http://www.freedos.org/
> http://cutemouse.sourceforge.net/

I looked at this code. 
 
> Do they work with DOS?

I haven't had any dos capability for a while now. I tested the mice and
keyboards on other systems. Those tests confirmed hard errors in the 
devices.

YANSWBVCG wrote:
> In alt.comp.hardware.amd.x86-64 Marcus Red <spamtrap@crayne.org> wrote:
>> Eccentric OpenBSD User Dave wrote:
>>> In alt.comp.hardware.amd.x86-64 Eccentric OpenBSD User Dave <spamtrap@crayne.org> wrote:
>>>> In alt.comp.hardware.amd.x86-64 Ed <spamtrap@crayne.org> wrote:
>>>>> On Fri, 23 Nov 2007 08:22:53 -0600, Eccentric OpenBSD User Dave
>>>>> <spamtrap@crayne.org> wrote:
>>>>>
>>>>>> Is there any way on an x86 system that a working ps2 keyboard/mouse can be
>>>>>> disabled by writing data to the device?
>>>>>>
>>>>>> Thanks.
>>>>> If using Windows (95-XP) you can use BlockInput.
>>>>> http://msdn2.microsoft.com/en-us/library/ms646290.aspx
>>>> Thanks. Actually, I am running X windows and I was looking for info 
>>>> about a possible exploit that I may be experiencing. 
>>> The question I am really trying to get an answer to is whether it is
>>> possible for the cpu to send commands to the x86 keyboard/mouse that
>>> will cause those devices to shut down permanently, effectively making
>>> them useless. 
>>>
>> Why would you want to do this?
> 
> I don't want to do this, but I suspect that some X-related exploit is doing
> it to me as a simple DOS attack. If this is *not* happening to me, then I
> am buying really crappy mice and keyboards and need to switch to better
> brands. 
> 
Ah good, I found the requirement a bit suspicious; I can't think of (not 
to say there aren't any) any exploit to kill keyboard input (mouse 
disabling being covered earlier).
OTOH, way back when (early 80's) there used to be games that required 
the original boot floppy to run off, and some code on there disabled 
Ctrl-Alt-Delete; so it may be possible.

In alt.comp.hardware.amd.x86-64 Esra Sdrawkcab <spamtrap@crayne.org> wrote:
> YANSWBVCG wrote:
>> In alt.comp.hardware.amd.x86-64 Marcus Red <spamtrap@crayne.org> wrote:
>>> Eccentric OpenBSD User Dave wrote:
>>>> In alt.comp.hardware.amd.x86-64 Eccentric OpenBSD User Dave <spamtrap@crayne.org> wrote:
>>>>> In alt.comp.hardware.amd.x86-64 Ed <spamtrap@crayne.org> wrote:
>>>>>> On Fri, 23 Nov 2007 08:22:53 -0600, Eccentric OpenBSD User Dave
>>>>>> <spamtrap@crayne.org> wrote:
>>>>>>
>>>>>>> Is there any way on an x86 system that a working ps2 keyboard/mouse can be
>>>>>>> disabled by writing data to the device?
>>>>>>>
>>>>>>> Thanks.
>>>>>> If using Windows (95-XP) you can use BlockInput.
>>>>>> http://msdn2.microsoft.com/en-us/library/ms646290.aspx
>>>>> Thanks. Actually, I am running X windows and I was looking for info 
>>>>> about a possible exploit that I may be experiencing. 
>>>> The question I am really trying to get an answer to is whether it is
>>>> possible for the cpu to send commands to the x86 keyboard/mouse that
>>>> will cause those devices to shut down permanently, effectively making
>>>> them useless. 
>>>>
>>> Why would you want to do this?
>> 
>> I don't want to do this, but I suspect that some X-related exploit is doing
>> it to me as a simple DOS attack. If this is *not* happening to me, then I
>> am buying really crappy mice and keyboards and need to switch to better
>> brands. 
>> 
> Ah good, I found the requirement a bit suspicious; I can't think of (not 
> to say there aren't any) any exploit to kill keyboard input (mouse 
> disabling being covered earlier).
> OTOH, way back when (early 80's) there used to be games that required 
> the original boot floppy to run off, and some code on there disabled 
> Ctrl-Alt-Delete; so it may be possible.

Today I discovered that a kvm switch I have just started using is defective.
The mouse port to the kvm switch no longer works although a mouse taken
from that port and plugged directly into the computer does work. The kvm
switch joins the list of new equipment going mysteriously bad within weeks
of being placed into service with the AMD64 computer which itself has run
flawlessly in 64-bit mode for over a year now. 

In article <g92dnfe4Hc8vndfanZ2dnUVZ_saknZ2d@comcast.com>, 
spamtrap@crayne.org says...

[ ... ]

> Today I discovered that a kvm switch I have just started using is defective.
> The mouse port to the kvm switch no longer works although a mouse taken
> from that port and plugged directly into the computer does work. The kvm
> switch joins the list of new equipment going mysteriously bad within weeks
> of being placed into service with the AMD64 computer which itself has run
> flawlessly in 64-bit mode for over a year now. 

I'd put odds at about 1000:1 that this is a hardware problem. In theory, 
it's probably even a repairable one, though given the cost of a 
motherboard, it's rarely worthwhile to do so.

It's very likely that the signals your computer's mouse port are 
generating are no longer within specifications -- something like a bad 
voltage regulator or even just a bad capacitor can allow it to send out 
signals it's not supposed to. The circuits that attach to the port 
normally have small electrostatic discharge protection circuits (like 
tiny surge protectors) on their inputs, so they can last a while -- but 
much like a surge protector, there's a limit to the protection they 
provide before the protection is gone. After that, the bad signal kills 
them.

You've got a couple of obvious ways to deal with this. One is to simply 
replace the motherboard. Another is to treat your current mouse port as 
dead, and hook your mouse to a different port (e.g. USB). Yet another 
possibility is to use that machine only in a headless configuration.

To conclude: you're not going to find this mysterious mouse-killing 
software, because that's not what's causing the problem.

-- 
    Later,
    Jerry.

The universe is a figment of its own imagination.

I found one more example for a ps2-mouse using port acess-> psmouse.asm.
http://www.programmersheaven.com/download/36764/download.aspx

Dirk

"YANSWBVCG" <spamtrap@crayne.org> wrote in message
news:g92dnfe4Hc8vndfanZ2dnUVZ_saknZ2d@comcast.com...
> Today I discovered that a kvm switch I have just started using is
defective.
> The mouse port to the kvm switch no longer works although a mouse taken
> from that port and plugged directly into the computer does work. The kvm
> switch joins the list of new equipment going mysteriously bad within weeks
> of being placed into service with the AMD64 computer which itself has run
> flawlessly in 64-bit mode for over a year now.
>

Dave or YANSWBVCG,

Okay, this thread has become a "mystery novel" and I'm getting bored with
it.  Each response seems to adds more information that wasn't mentioned
earlier...  Since it seems we are no closer to finding the issue, I'll
"shotgun" some ideas for you:

1) The "hard errors" on the keyboards and mice suggest electrical problems
to me (blown circuitry, flaky cable, pepsi, heavy handedness).
2) The loss of usb etc., implies electrical problems to me (power dropout),
but could be software.
3) The "blown" KVM port implies electrical problems to me.
4) The locking of the cdrom drive is normal for Live-CD's if the OS has
mounted the CD for access or install or swap file, etc.
5) The locking of the cdrom drive if not mounted, e.g., hardisk or floppy
boot, suggests memory corruption to me.
6) The inability to access BIOS via delete key at boot could be a failure to
detect the CPU (overheated, overclocked), CMOS corruption (wrong cpu or bus
speed setting), or A20 issue (can't execute part of BIOS or video BIOS).
Does the BIOS detect the CPU?  If CPU, this implies an electrical or heat
problem to me.  If CMOS, this implies a software bug, like A20 being
disabled.

Completely unrelated questions, just in case there are multiple unrelated
issues...:

Is this a normal home computer, with a tower case?  Or, is it this
"corporate?"  If corporate, could it be sabotage, say from a vendor trying
to sell you stuff?  What about a vendor stealing or a coworker (different
department) swapping bad stuff for the good "hardly used" stuff your
department has (I've seen this happen...a few times.)?  Do the serial
numbers match what you bought?  If a home PC, why the KVM switch?  Could the
KVM switch be blowing stuff as you replace it?  Is this system being
overclocked (overheating, underpowered, "aged" circuitry from overclocking
or poor ventilation)?  Was it moved just recently to near a window (memory
corruption from cosmic rays, solar rays, high energy particles, or
background radiation)?  What are the PS ratings?  What are the 12V current
rating(s) (underpowered)?  Since it's an AMD, what are the 3.3V current
rating (since AMD's need more current on the 3.3V line)?  Was the PC
recently "upset" by relocating, opening, dusting, vacuuming, etc. (loose
cables, memory or cpu not set in socket or slot, ventilation esp. rack unit,
static zapped)?  Are you using RAID (hard disk failures)?  Are you using
Western Digital hard disks?

This link indicates that harddisk, raid, or memory errors occur far more
often than detected:
http://storagemojo.com/2007/09/19/cerns-data-corruption-research/


Rod Pemberton

On Mon, 26 Nov 2007 03:38:15 -0500, "Rod Pemberton"
<spamtrap@crayne.org> wrote:

<snip>
>
>Okay, this thread has become a "mystery novel" and I'm getting bored with
>it.  Each response seems to adds more information that wasn't mentioned
>earlier...  Since it seems we are no closer to finding the issue, I'll
>"shotgun" some ideas for you:
<snip>

I was thinking much the same way.  I was about to suggest:

A) Get a *GOOD* memory test program, and let it run for 5 or 10 passes
(that would probably be several days for a really good one)

B) Get a new *OVERSIZED* power supply - at least 50 or 100 watts
bigger than the current one.

C) Get a new system.  If neither A or B solve the problem, there isn't
really any other choice.
-- 
ArarghMail711 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html

To reply by email, remove the extra stuff from the reply address.

> Is there any way on an x86 system that a working ps2 keyboard/mouse can be
> disabled by writing data to the device?
>
> Thanks.
>

No..

Hardware fault.
Faulty Motherboard &/ Power Supply.

In alt.comp.hardware.amd.x86-64 Rod Pemberton <spamtrap@crayne.org> wrote:
> 
> "YANSWBVCG" <spamtrap@crayne.org> wrote in message
> news:g92dnfe4Hc8vndfanZ2dnUVZ_saknZ2d@comcast.com...
>> Today I discovered that a kvm switch I have just started using is
> defective.
>> The mouse port to the kvm switch no longer works although a mouse taken
>> from that port and plugged directly into the computer does work. The kvm
>> switch joins the list of new equipment going mysteriously bad within weeks
>> of being placed into service with the AMD64 computer which itself has run
>> flawlessly in 64-bit mode for over a year now.
>>
> 
> Dave or YANSWBVCG,
> 
> Okay, this thread has become a "mystery novel" and I'm getting bored with
> it.  Each response seems to adds more information that wasn't mentioned
> earlier...  Since it seems we are no closer to finding the issue, I'll
> "shotgun" some ideas for you:
> 
> 1) The "hard errors" on the keyboards and mice suggest electrical problems
> to me (blown circuitry, flaky cable, pepsi, heavy handedness).
> 2) The loss of usb etc., implies electrical problems to me (power dropout),
> but could be software.
> 3) The "blown" KVM port implies electrical problems to me.
> 4) The locking of the cdrom drive is normal for Live-CD's if the OS has

I'm not using live cds.

> mounted the CD for access or install or swap file, etc.
> 5) The locking of the cdrom drive if not mounted, e.g., hardisk or floppy
> boot, suggests memory corruption to me.
> 6) The inability to access BIOS via delete key at boot could be a failure to
> detect the CPU (overheated, overclocked), CMOS corruption (wrong cpu or bus
> speed setting), or A20 issue (can't execute part of BIOS or video BIOS).
> Does the BIOS detect the CPU?  If CPU, this implies an electrical or heat
> problem to me.  If CMOS, this implies a software bug, like A20 being
> disabled.
> 
> Completely unrelated questions, just in case there are multiple unrelated
> issues...:
> 
> Is this a normal home computer, with a tower case?

Yes.

>  Or, is it this
> "corporate?"  If corporate, could it be sabotage, say from a vendor trying
> to sell you stuff?  What about a vendor stealing or a coworker (different
> department) swapping bad stuff for the good "hardly used" stuff your
> department has (I've seen this happen...a few times.)?  Do the serial
> numbers match what you bought?  If a home PC, why the KVM switch?

I'm running more than one computer and I have very little space.

>  Could the
> KVM switch be blowing stuff as you replace it?  Is this system being
> overclocked (overheating, underpowered, "aged" circuitry from overclocking
> or poor ventilation)?  Was it moved just recently to near a window (memory
> corruption from cosmic rays, solar rays, high energy particles, or
> background radiation)?  What are the PS ratings?  What are the 12V current
> rating(s) (underpowered)?  Since it's an AMD, what are the 3.3V current
> rating (since AMD's need more current on the 3.3V line)?  Was the PC
> recently "upset" by relocating, opening, dusting, vacuuming, etc. (loose
> cables, memory or cpu not set in socket or slot, ventilation esp. rack unit,
> static zapped)?  Are you using RAID (hard disk failures)?  Are you using
> Western Digital hard disks?

No.
 
> This link indicates that harddisk, raid, or memory errors occur far more
> often than detected:
> http://storagemojo.com/2007/09/19/cerns-data-corruption-research/
> 
> 
> Rod Pemberton

Thanks for all your ideas!
Dave Feustel

Rod Pemberton wrote:

....
> I'm amazed this applies for our "OpenBSD User" who is running "X windows
> [sic]"...  I quess I better buy some MS stock due to their amazing inroads
> into the *nix software market!  I didn't know they had a OpenBSD distro
> called Vista!  ;-)

Apparently, in addition to the obvious step of not purchasing/installing 
any "Vista Distro", we're going to have to carefully scan any hardware 
purchases for the absence of the "Vista Logo".

http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.html

If this piece isn't "alarmist", I'm "amazed", too! Do they think they 
can get away with this? Perhaps they can. Baaa! Baaa!

(I doubt if this - or an "exploit" - is Dave's problem. I'd say, 
"Replace the power supply.")

Best,
Frank

Frank Kotler <spamtrap@crayne.org> wrote:
> Rod Pemberton wrote:
> 
> ...
>> I'm amazed this applies for our "OpenBSD User" who is running "X windows
>> [sic]"...  I quess I better buy some MS stock due to their amazing inroads
>> into the *nix software market!  I didn't know they had a OpenBSD distro
>> called Vista!  ;-)
> 
> Apparently, in addition to the obvious step of not purchasing/installing 
> any "Vista Distro", we're going to have to carefully scan any hardware 
> purchases for the absence of the "Vista Logo".
> 
> http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.html
> 
> If this piece isn't "alarmist", I'm "amazed", too! Do they think they 
> can get away with this? Perhaps they can. Baaa! Baaa!
> 
> (I doubt if this - or an "exploit" - is Dave's problem. I'd say, 
> "Replace the power supply.")
> 
> Best,
> Frank

Actually the power supply is new.
I suggest we drop this thread. 

On Sun, 25 Nov 2007 05:31:24 -0600, YANSWBVCG  <spamtrap@crayne.org>
wrote:

>I don't want to do this, but I suspect that some X-related exploit is doing
>it to me as a simple DOS attack. If this is *not* happening to me, then I
>am buying really crappy mice and keyboards and need to switch to better
>brands. 

Or your keyboard and mouse ports are shot.

Jim Higgins <spamtrap@crayne.org> wrote:
> On Sun, 25 Nov 2007 05:31:24 -0600, YANSWBVCG  <spamtrap@crayne.org>
> wrote:
> 
>>I don't want to do this, but I suspect that some X-related exploit is doing
>>it to me as a simple DOS attack. If this is *not* happening to me, then I
>>am buying really crappy mice and keyboards and need to switch to better
>>brands. 
> 
> Or your keyboard and mouse ports are shot.

This is beginning to look like a real possibility. 

Rod Pemberton wrote:
> "H. Peter Anvin" <spamtrap@crayne.org> wrote in message
> news:4748DB91.1060008@zytor.com...
>> Eccentric OpenBSD User Dave wrote:
>>> The reason I ask about this is that in the last few months I have had
>>> several keyboards and mice just stop working. Some of these devices
>>> were essentially brand new. If they are not being disabled by exploits
>>> breaking the hardware, then the quality of mice and keyboards seems to
>>> be going downhill. I'm still trying to figure out what's going on.
>>>
>> You might be a victim of one of the latest idiocies pushed by Microsoft,
>> called "tilt bits."  They are a requirement for the Vista logo, as far
>> as I understand.  The explicit purpose of a tilt bit is to turn a minor
>> glitch into a total malfunction.  The purpose of this, of course, is DRM
>> -- only approved hardware devices can talk to only approved software
>> systems to display approved media.
>>
>> Welcome to facism as applied to hardware.
>>
> 
> I'm amazed this applies for our "OpenBSD User" who is running "X windows
> [sic]"...  I quess I better buy some MS stock due to their amazing inroads
> into the *nix software market!  I didn't know they had a OpenBSD distro
> called Vista!  ;-)
> 

MS is forcing *HARDWARE* vendors to put this crap in their hardware.  It 
doesn't matter what software you're running.

	-hpa

"H. Peter Anvin" <spamtrap@crayne.org> wrote in message
news:48ednV7WBpe2sdbanZ2dnUVZ_gydnZ2d@comcast.com...
> Rod Pemberton wrote:
> > "H. Peter Anvin" <spamtrap@crayne.org> wrote in message
> > news:4748DB91.1060008@zytor.com...
> >> Eccentric OpenBSD User Dave wrote:
> >>> The reason I ask about this is that in the last few months I have had
> >>> several keyboards and mice just stop working. Some of these devices
> >>> were essentially brand new. If they are not being disabled by exploits
> >>> breaking the hardware, then the quality of mice and keyboards seems to
> >>> be going downhill. I'm still trying to figure out what's going on.
> >>>
> >> You might be a victim of one of the latest idiocies pushed by
Microsoft,
> >> called "tilt bits."  They are a requirement for the Vista logo, as far
> >> as I understand.  The explicit purpose of a tilt bit is to turn a minor
> >> glitch into a total malfunction.  The purpose of this, of course, is
DRM
> >> -- only approved hardware devices can talk to only approved software
> >> systems to display approved media.
> >>
> >> Welcome to facism as applied to hardware.
> >
> > I'm amazed this applies for our "OpenBSD User" who is running "X windows
> > [sic]"...  I quess I better buy some MS stock due to their amazing
inroads
> > into the *nix software market!  I didn't know they had a OpenBSD distro
> > called Vista!  ;-)
> >
>
> MS is forcing *HARDWARE* vendors to put this crap in their hardware.  It
> doesn't matter what software you're running.
>

Yes, I am opposed to DRM.  It does support capitalistic enterprise (a good
thing) and it supports the goals of Business Software Alliance (and members)
against corporate software piracy (in theory good, but implemenation is
lacking...).  But, I believe giving rights to others is a major security
risk to the PC owner and encroachment of the PC owner's rights to control
their own PC.  Otherwise, I have to say:

So?  Raising your competitors cost of doing business is a standard American
corporation practice.  It's been used to excellent effect by MS and good
effect by GM and RJR.  GM has done it for decades with excellent results,
i.e., winning court cases, embracing clear air legislation and higher fuel
economy requirements.  The US tabacco industry, with their Tabacco Master
Settlement Agreement, blocked much competition by raising competitors costs.
Their tabacco competitors have to pay even if they weren't involved or were
started later, i.e., higher costs.  US business profits immensely from the
economic ignorance of US politicians...   MicroSoft raised the costs of
other DOSes effectively killing them and is now doing it to Linux too:
"Legacy-Free Hardware and BIOS Requirements", Winmodem's, USB, software
patents, pushing for rapid changes in PC circuitry to increase competitors
software development time and costs, migrating to smaller specialized
computing devices (phones, music, game machines, etc)...  When it comes to
PC hardware, the lowest cost solution usually wins.  But, for PC software,
OS brand and (currently) gaming ability are important.  The real primary
long-term issue for Linux is money.  And, I don't believe that Linux can
continue to succeed in the face of rapid PC hardware changes or small
specialized computing devices without phenomenally huge amounts of it.


Rod Pemberton

   [Fup set to ALA]
Rod Pemberton <spamtrap@crayne.org> wrote in part:
> "H. Peter Anvin" <spamtrap@crayne.org> wrote in message
>> >> called "tilt bits."  They are a requirement for the Vista logo, as far
>> >> as I understand.  The explicit purpose of a tilt bit is to turn a minor
>> >> glitch into a total malfunction.  The purpose of this, of course, is DRM
>> >> -- only approved hardware devices can talk to only approved software
>> >> systems to display approved media.
>>
>> MS is forcing *HARDWARE* vendors to put this crap in their hardware.  
>> It doesn't matter what software you're running.

Sure.  But AFAIK, the tilt bits are only a msg sent to the OS driver
by peripheral hardware.  An OS driver is free to ignore the bits,
but the OpenBSD driver probably has not been so re-written.

> So?  Raising your competitors cost of doing business is a
> standard American corporation practice.

Rather cynical:  RRC (Raising Rivals Costs) is an illegal
anticompetitive business practice (even if hard to prove):
http://ftc.gov/be/RRCGMU.pdf

> economic ignorance of US politicians...   MicroSoft raised the costs of
> other DOSes effectively killing them and is now doing it to Linux too:
> "Legacy-Free Hardware and BIOS Requirements", Winmodem's, USB, software
> patents, pushing for rapid changes in PC circuitry to increase competitors
> software development time and costs, migrating to smaller specialized

As a convicted monopolist in both the US and EU (US penalties but
not judgement reversed on appeal), Microsoft must legally follow a
higher standard of behaviour lest it be subject to further action
for anti-competitive behaviour.  In essence, they lost their
presumption of innocence.  Still, they are formidible litigants.

But coercing hardware mfrs to make significant hardware non-operable
with competitive OSes likely would bring down the wrath of the EU
and quite possibly the US antitrust authorities.

Now, if the hardware merely locks up easily, who could possibly know :)
More seriously, the anti-trust authorities probably could find no
anti-competitive intent unless MS-Windows somehow could unlock.

-- Robert

s> int *f(int x)
s> {
s>     return(&x); /* this address points to storage local of f() */
s> }
s>
s> such a returned pointer is ... invalid,

RP> False, not in agreement.  The pointer is valid.  A pointer
RP> can point to anything.  The value from the derefenced
RP> pointer is invalid.
RP> [...] it can be returned and assigned to another pointer
RP> without being dereferenced...

Incorrect.  There exist implementations (e.g. x86 architecture when
using far or huge data memory models and the AS/400) where
deallocation of storage causes the _values_ of any pointers to that
storage to become invalid.  (Loading the value of the pointer into a
CPU pointer register causes a processor fault.)  So simply using the
_values_ of the pointers, without even dereferencing them, causes
undefined behaviour.  The C++ standard mentions this in regard to
storage with dynamic storage duration.  The C standard is more general
and points out that the values of pointers to an object become
indeterminate after that object's lifetime, irrespective of storage
duration, ends.

J de Boyne Pollard wrote:
[Who cares? I think it's about angels and pins]

Just a suggestion to snip followups if replying...