Hmm, if you don't mind send me the information from the command

     hwinfo --mouse

Thanks

Sure, no problem:

# hwinfo --mouse
16: PS/2 00.0: 10500 PS/2 Mouse
  [Created at input.157]
  UDI: /org/freedesktop/Hal/devices/computer_i8042_Aux_Port_logicaldev_input
  Unique ID: AH6Q.wF_upDHbWx5
  Hardware Class: mouse
  Model: "PS/2 Logitech Mouse"
  Vendor: int 0x0210
  Device: int 0x0002 "PS/2 Logitech Mouse"
  Device File: /dev/input/mice (/dev/input/mouse0)
  Device Files: /dev/input/mice, /dev/input/mouse0, /dev/input/event2
  Device Number: char 13:63 (char 13:32)
  Driver Info #0:
    Buttons: 2
    Wheels: 0
    XFree86 Protocol: explorerps/2
    GPM Protocol: exps2
  Config Status: cfg=no, avail=yes, need=no, active=unknown

Hmm, looks like a standard model. would you please call the
following command from within runlevel 3 (init 3):

  sax2 -r

- this call will start its own X-Server, does the mouse work ?
- if not please exit the program and send me the log file

  /var/log/SaX.log

Thanks

Mouse didn't work, but it produced about 10'000 of lines like:

Nov 15 11:11:48 tintin kernel: psmouse.c: bad data from KBC - timeout
Nov 15 11:11:48 tintin kernel: psmouse.c: bad data from KBC - timeout
Nov 15 11:11:48 tintin kernel: psmouse.c: bad data from KBC - timeout
Nov 15 11:11:48 tintin kernel: psmouse.c: bad data from KBC - timeout
Nov 15 11:11:48 tintin kernel: psmouse.c: bad data from KBC - timeout

When I unplugged the mouse, it stopped.  I tried another mouse (no-name), which
also produced the messages above, but at a much slower rate.  I'm beginning to suspect a hardware problem?  Will attach the sax-log in a minute.

Created attachment 57354 [details]
SaX.log

Hmm, this seems to be a kernel problem

It really looks like a HW problem, please add i8042.debug on the kernel command
line and attach a 'dmesg' of the non-working state.

Created attachment 57750 [details]
dmesg before startiong sax2 and touching mouse

Created attachment 57751 [details]
dmesg after starting sax2 and moving mouse

Both dmesg listings are from a non-working state.  #1 is after a normal startup (with i8042.debug) before starting "sax2 -r" and moving the mouse about. #2 is taken after leaving sax2 - the minute I move the mouse a bit, the timeouts (as above) start appearing.

It looks like the VGA card is issuing IRQ12, confusing the mouse controller and driver.
Are you using 3D acceleration?
If not, try disabling VGA IRQ in the BIOS.
Also, please make sure IRQ 12 isn't assigned to any PCI IRQ line in the BIOS.

What mouse is that exactly? Is it a Logitech mouse? What is the model number
(written on the bottom side of the mouse)?

Another test to do is to install input-utils, and then test the mouse using

       evtest /dev/input/event2

This should print a line for each movement/click of the mouse. Please try this
before running SaX, since afterwards it has no chance of working.

The graphics is built-in Cirrus Logic CD5446 - I don't think it's got any 3D acceleration features.  I've been thru the BIOS settings and I don't see 12 being assinged for VGA, nor anything else.  (this is using Compaqs SmartStart, which is a little restrictive).  
The mouse is a Logitech M-S34, 2 button.  Compaq S/N 166861-001. Looks farily ordinary.
I tried the evtest - seems to work fine.  Moving the mouse and clicking the buttons are reported in a normal way.  (i.e. it looks normal to me, I'm not sure what to expect from evtest). 

I assume evtest works fine before you start SaX and doesn't at all after
you do?

Also, please attach your xorg.conf.

Created attachment 57787 [details]
xorg.conf from tintin (compaq pl1600)

Yes, you are right - evtest works fine before I start SaX and doesn't work at all afterwards.

Your xorg.conf looks reasonable. Do you have the same problems after just
running X? (type X on the command prompt, then exit with ctrl-alt-backspace when
it comes up).

It seems the Cirrus driver somehow upsets the mouse controller.

It could also be that it's the vesa X driver instead (and this is quite a bit
more likely, since BIOS is involved, which is always asking for problems).

If after running X the problem doesn't appear, and mouse works in X (which I'd
expect), then I'd say: Don't use SaX on your hardware.

If I just type X, I get a black screen and a system that doesn't respond to anything.  I tried cycling the system to runlevel 5, which produces the KDE login prompt etc. - but the mouse still doesn't work. 

The question is: Does the mouse work (in evtest) after you return from X (KDE) back to console? You can either use ctrl-alt-F1 or just switch back to runlevel 3.
Don't run SaX, as we already know it kills the mouse.

After having gone to level 5 with KDE and then back to 3, evtest no longer works. 

Thanks. Now we know that X, and most likely the X server, kills the mouse.

Can you try the following:

    * Whether just running "X -probeonly" kills the mouse, too
    * Whether if you change the driver from "cirrus" to "vesa" it gets better
    * Send me the /var/log/Xorg.0.log

Adding Egbert to CC: Egbert, do you have any idea how the cirrus driver could
do bad stuff to the i8042 kbd/mouse controller?

The driver should not access anyting outside of the VGA range.
It's likely that the driver isn't to blame at all. If the 'vesa' driver also causes problems it would be good to replace it with the 'dummy' driver.
This driver doesn't touch any hw at all. So the user should just get a black screen - but the Xserver would operate as expected towards a client. Also it
does the entire init semantics.
Per, would you please replace the driver 'cirrus' with the driver 'dummy' in your config file?

In theory it still could be the X "kbd" driver - it's still does access
the i8042 hardware directly under some circumstances in the latest X.Org release.

Right. It does so under certain circumstances. I will investigate if they are accidentally met with the current code.
Assinging this to me to find out. 

I've checked: These fallbacks are not called on my 10.0.
I would like to ask the reporter to investigate the issues that Vojtech and I have been asking for.

Apologies, I've been busy elsewhere. I should have an opportunity to get back to you on this tomorrow morning. 

1) with driver=cirrus and X -probeonly, the mouse works fine afterwards.  I'm attaching the Xorg.0.log
2) with driver=vesa, and X -probeonly, the system either locks up hard, or at least locks up the screen.  
3) with driver=dummy and X -probeonly, the mouse works fine afterwards.. I'm attaching the Xorg.0.log. 

Created attachment 58905 [details]
Xorg.0.log after X -probeonly with driver=cirrus

Created attachment 58906 [details]
Xorg.0.log after X -probeonly with driver=dummy

Comment #28 shows pretty clearly that it's related to the VESA driver. It's probably the VESA BIOS that's doing this.
We may be able to intercept some port accesses if we know what to look for.
However I think it's difficult to investigate this remotely.
Vojtech, if you can give me a list of PIO registers I should look out for I can hack this in and supply Per with a debugging module for testing.

Adding Vojtech and Stefan to Cc:
and reassigning to Vojtech for NEEDINFO.
Vojtech, please check last comment.

Just a quick comment before too much effort goes into this - this particular box will most probably not need to run X; that is, I don't have a hard need for a fix for this problem.  I reported the problem as it's a fairly standard box, and I suspected something simple had been overlooked.  I'll be perfectly happy to continue to assist the debugging/problem-solving effort, but just so you are aware.

The list would be anything in the 0x60-0x6f and 0x90-0x9f range, however, the
i8042 can be responsible for handling other stuff, too, depending on the
firmware.

Setting this to Enhancement

JFYI, Matthias. This is a bugreport, which is assigned to Egbert/me or with Egbert/me in CC or reported by Egbert/me.

This particular system is (finally) being removed from service, so I will no longer be able to test anything.  As far as I am concerned, this report can be closed without further action.

Ok. Better close this one finally.