Bug 28953

please cut/paste to here:

/etc/sysconfig/mouse

and

ls -l /dev/mouse

We (Red Hat) should really try to resolve this before next release.

----------/etc/sysconfig/mouse --------------
MOUSETYPE="ps/2"
XMOUSETYPE="PS/2"
FULLNAME="Generic Mouse (PS/2)"
XEMU3=yes
---------------------------------------------
ls -l /dev/mouse shows link to psaux
  (I'm running Win98 just now,
    for obvious reasons I can't cut/paste ls -l output
    with a dead mouse, but I did check it earlier)

I note the Fisher CD boots with a graphics screen with Tux top left,
but after install Fisher boots with old style text screen, curious 
(uname -a shows 2.4... kernel) 
     
Hope this helps

Some more info:
-----cat /proc/interrupts --------------
           CPU0       
  0:     247678          XT-PIC  timer
  1:       4034          XT-PIC  keyboard
  2:          0          XT-PIC  cascade
  8:          1          XT-PIC  rtc
 11:       1006          XT-PIC  eth0
 12:    1741844          XT-PIC  PS/2 Mouse
 14:     166661          XT-PIC  ide0
 15:        286          XT-PIC  ide1
NMI:          0 
ERR:          0
----------------------------------------
Although mouse is dead (and untouched) the interrupt count 
increases by roughly 700 interrupts per sec.
Thi count seems to vary in the 600 to 800 range
and seems to be independent of other activity (eg disk io).
(Above cut/paste done in Win98 using 'explore2fs' -handy) 


M/b is Gigabyte GA 5AX.  I u/g from the F1 to the F3 latest
flash BIOS with no change.  Interesting that Win98 noticed
the BIOS u/g and reconfigured, but RH (kudzu ?) did not notice. 

Well it seems to definitely be a 2.4+ kernel bug with my M/B.

I did a Workstation clean-install (NOT upgade) of Wolverine
and still had desd mouse.

I then  upgraded to the very latest kernel-2.4.1-0.1.13.i586.rpm
at rawhide and still dead mouse.

I then downgraded to the latest released RH7.0 kernel-2.2.17-14.i386.rpm
and now MY MOUSE WORKS (with nothing else changed).

Created attachment 11240 [details]
Config file for "my mouse now working" recompile of Wolverine kernel

 Same 'dead mouse' with latest Wolverine stock kernel 2.4.2-0.1.19
but this latest kernel works when recompiled with .config attached above.

The only config option I see that your .config has that looks like it might be
relevant is ACPI.  Could you try the "working" kernel with CONFIG_ACPI turned
off?  Please update this bug with the results of that test.  Thanks!

Created attachment 12522 [details]
suprising diff using xconfig rather than menuconfig

I edited a copy of the 'working' .config to # out CONFIG_ACPI, loaded it 
using menuconfig and wrote out a new .config (save and exit). 
 A diff between old and new is as expected:
-------------------------------------
[root@user1-hos linux-2.4]# diff .config test6
93c93
< # CONFIG_ACPI is not set
---
> # CONFIG_ACPI=y
------------------------------
Compile/install leads to a MOUSE IS (still) WORKING 
so  the .config above works with  CONFIG_ACPI either set or not.

Perhaps the following is unrelated but:
Oddly -- if I do exactly the same as above (load then save/exit)
but using make xconfig instead of menuconfig the result is
not as expected (at least by me):
-------------------------------------------
[root@user1-hos linux-2.4]# diff .config test6 >foo (attached )
-------------------------------------------

Created attachment 12523 [details]
curprising diff using xconfig

Is this still present in seawolf?

Problem is stil present in stock Wolverine  Kernel 2.4.2-0.1.49 and is 
still fixed for me by a re-compile as above.   I have not u/g to Seawolf as yet.
Will advise in a few days re Seawolf.

Wes

Have now u/g to Seawolf.  Problem is still present in stock kernel
and is still fixed by a recompile as above.

I have also seen the same behaviour after upgrading to RedHat 7.1 from 7.0,
where my generic PS/2 mouse stopped working. I installed kernel-2.4.2-2BOOT and
when I boot from this, my PS/2 mouse is detected and I can use X. However when I
try to boot from the standard kernel-2.4.2-2, my PS/2 mouse is not detected and
X fails to start.

It appears that the mouse stops working under RedHat 7.1 when I compile Plug and Play support into the kernel, eg the two options
CONFIG_PNP=y
CONFIG_ISAPNP=y

I have downloaded and compiled 2.4.4 kernel from source and still no working mouse if I compile in Plug and Play support as above. If I turn off Plug and 
Play, the mouse works OK.

$ less /etc/sysconfig/mouse
MOUSETYPE="ps/2"
XMOUSETYPE="PS/2"
FULLNAME="Generic Mouse (PS/2)"
XEMU3=yes
DEVICE=/dev/mouse

$ cat /proc/interrupts
           CPU0
  0:   19174895          XT-PIC  timer
  1:         10          XT-PIC  keyboard
  2:          0          XT-PIC  cascade
 10:    1040832          XT-PIC  eth0
 11:          0          XT-PIC  usb-uhci
 12:         24          XT-PIC  PS/2 Mouse
 14:      59056          XT-PIC  ide0
 15:          5          XT-PIC  ide1
NMI:          0
ERR:          0

$ ls -al /dev/mouse
lrwxrwxrwx    1 root     root            5 May 10 15:30 /dev/mouse -> psaux

Hope this helps,
Lachlan

Installed 2.2.19-7.0.1 kernel under RedHat 7.1 and booted from that. Mouse is not detected.. /proc/interrupts is interesting this time however:

$ cat /proc/interrupts
           CPU0
  0:      28220          XT-PIC  timer
  1:          4          XT-PIC  keyboard
  2:          0          XT-PIC  cascade
  5:          0          XT-PIC  Crystal audio controller
  8:          1          XT-PIC  rtc
 10:       1524          XT-PIC  eth0
 11:          0          XT-PIC  usb-uhci
 12:          0          XT-PIC  MPU-401 UART
 13:          1          XT-PIC  fpu
 14:      77803          XT-PIC  ide0
 15:          2          XT-PIC  ide1

ie IRQ12 has been stolen by the sound card. The bizarre thing is that the mouse and sound card have both worked fine under RedHat 6.1, 6.2 and 7.0 
out of the box, but not with RedHat 7.1. Before upgrading RedHat 7.0 to 7.1 I was running the 2.4.2 kernel compiled from source and everything was also 
OK...

Lachlan

Lachlan bought this bug to my attention after I posted the message below.  The
message contains a workaround.

The comment in the e-mail about the PC BIOS was pure speculation and one
that I am now regretting making.  I downloaded pcmcia-cs 3.1.26 from SourceForge
to get the "lspnp" utility that decodes the /proc/bus/pnp entries.

Firstly for a benchmark, is an excerpt from ./lspnp -vv from my Dell Latitude
CPx H450GT

06 PNP0303 input device: keyboard
    flags: [no disable] [no config] [input] [static]
    allocated resources:
	irq 1 [high edge]
	io 0x0060-0x0060 [16-bit decode]
	io 0x0064-0x0064 [16-bit decode]

07 PNP0f13 input device: mouse
    flags: [no disable] [no config] [input] [static]
    allocated resources:
	irq 12 [high edge]

That is, the mouse IRQ is statically allocated.

Next is an excerpt from ./lspnp -vv run on an Acer AcerPower 4100
with BIOS version 3.2.

09 PNP0303 input device: keyboard
    flags: [no disable] [no config] [input] [static]
    allocated resources:
        io 0x0060-0x0060 [16-bit decode]
        io 0x0064-0x0064 [16-bit decode]
        irq 1 [high edge]

0a PNP0f13 input device: mouse
    flags: [dynamic]
    allocated resources:
        irq 12 [high edge]
    possible resources:
        irq 12 [high edge]

That is, the mouse IRQ is dynamically allocated, but there
is only one potential value.

[Both machines are running 2.4.5-ac7-mpls1.0p2-pwc7.01-gdt3
 which is a standard kernel with Alan Cox patches, MPLS networking 
 patches, Philips web cam reverted to non-kernel source, and some
 extra debugging of routing table access.  I doubt any of this matters,
 if it does I can redo the lspnp with a standard kernel.]

I'm not yet sure whether this points to a bug in the Linux
kernel PNP code or the user-space sound configuration
code.  I'm a bit surprised that IRQs are not allocated
such that IRQs that can be used by only one device are
consumed last if being allocated to devices that have
a choice of IRQs.

In any case, the above should give people a firm starting
point as the triggering cause of the bug is now apparent.

Following is an e-mail I posted *before* the above investigation
which incorrectly blames BIOS.  It does contain a workaround
until a kernel/sound fix can be developed.

Subject:  RH 7.1 and AcerPower 4100 -- fix for mouse failure
Date: Mon, 18 Jun 2001 11:43:29 +0930
From: Glen Turner <glen.turner.au>
Organization: Australian Academic and Research Network
To:  Linux South Australia User Group <linuxsa.au>

Fresh install of Red Hat Linux 7.1 onto Acer AcerPower 4100
with BIOS version 3.2.  The PC has a SCSI card installed
which uses one interrupt, some I/O ports and some ROM
memory.

Initialisation of "gpm" and "X" fails as opening /dev/mouse
(really /dev/psaux) reports "resource busy".  Failure of
X causes standard boot to repeatedly hang prior to graphical
login screen.

Turns out that PS/2 mouse uses IRQ12 and the Linux PNP
system is not aware that this interrupt is taken and
may allocate a device to that interrupt.  This is most
likely a Acer BIOS bug.

In this specific case, the MIDI interrupt was allocated
to IRQ12.  This was unfortunate, as Red Hat 7.1 rewrites
the sound entries in /etc/modules.conf upon each boot,
so simply modifiying entries in /etc/modules.conf to
use an IRQ other than IRQ12 had no effect.

Fix is to pass kernel parameter to expliticly reserve
IRQ12.  Alter every "image" entry in /etc/lilo.conf to
add the line

      append="isapnp_reserve_irq=12"

and install new MBR using using /sbin/lilo.

Possible that the fault may not be encountered on later BIOSes.
Fault may not be tickled in machines which have less PCI cards,
and thus less competition for free IRQ numbers.

-- 
 Glen Turner                                 Network Engineer
 (08) 8303 3936      Australian Academic and Research Network
 glen.turner.au          http://www.aarnet.edu.au/

Does this still happen with the 2.4.9 errata kernel or 2.4.15pre4 from
kernel.org?

Hi:
I fixed the problem (FOR ME) by adding a line in lilo.conf
"append="isapnp_reserve_irq=12"
I got this fix from a comment added to this bug quite a long time ago.
When I next reboot I'll try it without the append= and let you know
for both kernels 2.4.9 and 2.4.14.

Wes

Well I still need the append= line for kernels 2.4.9-13 and 2.4.14 
or my PS/2 Mouse is not found (kudzu pops up).

Wes  (now on RH 7.2)

   

Created attachment 37602 [details]
reduce priority of irq12 allocation

Wes, could you test the previously attached patch?  If it solves the problem,
I'll forward it upstream to the isapnp folks.  Thanks!

I applied the patch and recompiled 2.4.14 
with NO CHANGE - let me know if you want me
to try 2.4.9 also (I assume it would be the same).

Wes

Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem
persists.

The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, 
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/