From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows 98) Upgraded to Fisher from working tweaked RH 6.2 by booting CD. (had ryo kernel and XF86 4.0) GUI Installer detected and used mouse (ps/2 3-button Logitech) but after reboot mouse is dead to gpm and X Mother bd has AMD-K2-400, ALI chipset, ATI-Rage-PCI video Reproducible: Didn't try - can't go back easily Since the mouse is dead in text mode and in X I assume it is a lower level configuration or kernel buglet.
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/