[snip] > > The ps/2 mouse problem bit me again this morning. Just a fropzen pointer. > > > It happened again but I was watching the boot messages this time. > > Said /dev/psaux doesn't exist which is interesting as it does. > > It worked O.K. on the next boot. Mmm, also Felix has trouble with psaux. It's to soon to say they are related though...
> Here's some info > > cd /dev > ls ps* -l | more > lr-xr-xr-x 1 root root 10 Sep 24 06:53 psaux -> misc/psaux > cd misc > ls ps* -l | more > crw-r----- 1 root root 10, 1 Sep 24 10:56 psaux > vi psaux > "psaux" is not a file Uhm, psaux is a character device. In principle, you can open it like an ordinary file but I guess vi stat's the file first to determine its type. Better to look at /proc/interrupts f.i. to see if interrupts are being caught. > Not sure whether you need dmesg, but here it is > [snip] IRQ 14, IDE0 IRQ 15, IDE1 [snip] IRQ 5, USB [snip] > eth0: RealTek RTL-8029 found at 0xa800, IRQ 11, 00:E0:7D:76:E0:4E. IRQ 11, 10Mbit card? Mmm, can you show us lspci -v? > eth1: ns83820 v0.18: DP83820 v1.2: 00:04:5a:72:2a:cc io=0xe5000000 irq=5 f=sg > eth1: link now down. IRQ 5, 10M/100M/1Gbit card? Sharing with USB device! Show us ifconfig eth1 if you can get the link up... [snip] > es1371: found es1371 rev 2 at io 0xa400 irq 10 > es1371: features: joystick 0x0 > ac97_codec: AC97 Audio codec, id: 0x8384:0x7608 (SigmaTel STAC9708) IRQ 10, Sound card... [snip] > parport0: PC-style at 0x378 (0x778) [PCSPP,TRISTATE] > parport0: irq 7 detected (IRQ 7, parallel port..., standard IRQ...) It probably all works but it is an ugly IRQ setup, at least according to my experience and taste :-) We need /proc/interrupts anyway... (make sure to move the mouse a bit after boot even if it doesn't move the cursor, we want to know if it is a hardware/driver problem or a software problem(gpm/X).) Anyway, if it worked before and stopped working recently, it is either : * the mouse or the PS/2 mouse port has become flaky * the kernel PS/2 driver changed * isapnp changed and ISA probing is screwing up the hardware even harder than it was notoriously able to do before (that's why probing should be avoided once the resources are known and isapnp.conf is updated accordingly). * the PS/2 mouse packet driver in X has changed and now contains a rarely tripped bug. (It is most likely adapted to the "new" XF86 4.0 architecture but it is rather hardware independent so most people using PS/2 mice should have experienced this bug if there is one.) * new hardware was recently inserted and it (or its driver) is interfering with the PS/2 mouse port. This breakdown counts for everybody experiencing (PS/2) mouse problems... Guy PS: Maybe in some critical cases, PS/2 doesn't like cooperating through devfs. That would be option 6...
