Ben Reser wrote: > On Sun, Sep 22, 2002 at 03:15:35PM -0400, Felix Miata wrote:
>>You want to know why loud? You have to be. I've reported a number of >>bugs over several Mandrake beta programs, and only one has produced a >>response from anyone with a mandrake.com email address. That one was >>Guillaume Cottenceau, who explicitly thanked me on the list for my >>persistence. > I understand that but your issue does not warrant a delay in the It might if a fix can come quickly and easily. > release. And BTW it's @mandrakesoft.com not @mandrake.com. @mandrakesoft.com is in my mailfilters to segregate all such posts into their own folder. >>The problem with my disappearing psaux is that no one with a >>mandrake.com email address has suggested what log files or further >>procedures on my part would help them either to understand what is >>happening or to reproduce. Totally zip. So, I've been logging my >>activity on the subject on the mailing list on the hope that sometime >>someone else will notice and either allow me to help myself, or actually >>produce a fix. >>There used to be Kudzu to handle hardware changes upon bootup. Kudzu was >>easy: configure new, remove old, ignore. Most importantly, it gave you >>time to become aware what it proposed to do, with a nice long default >>pause to allow user input. >>Whatever is happening now instead of Kuduz is buried. A brief message >>flashes on the screen, with no chance to pause startup to digest the >>problem, or know what utility is actually doing its deed, much less what >>config or /dev files it is screwing up. If you were in interactive >>startup, you could do something, except you have to know in advance you >>need to select interactive, since once the reconfiguration has happened, >>you don't get a second chance the next time around. Have to reinstall >>all over again to get another chance. So far, I've been unable to locate >>what log file, if any, that this bad startup behavior generated. >>Preliminary indication is that it happens before / is mounted rw, and so >>logging is lost. >>A mouse is no less essential to a desktop environment than a keyboard. >>These are basic stuff that has been around almost since the beginning of >>time. There is no excuse for basic stuff to be allowed to get screwed >>up. It worked before, and always should. > Your issue has very little to do with your actually mouse than with the > kernel/devfs not thinking that you have a psaux device. There isn't > much to tell you to look for because you either have a psaux device or > you don't. There isn't really a log file to look in to see why it isn't > showing up. I'd like to know why the kernel and/or devfs think there is no psaux: With mouse working, before running sndconfig: lr-xr-xr-x 1 root root 10 Sep 22 14:14 /dev/psaux->/misc/psaux crw-r----- 1 root root 10, 1 Sep 22 18:33 /dev/misc/psaux After changing nothing in configuration except to run sndconfig and then reboot with devfs=mount to find mouse no longer works: lr-xr-xr-x 1 root root 10 Sep 22 14:47 /dev/psaux->/misc/psaux crw-r----- 1 root root 10, 1 Dec 31 1969 /dev/misc/psaux Other the different timestamp on /dev/misc/psaux, what is the difference here? > Your problem is much deeper than something that Kudzu would have had > anything to do with. When it comes to mice all Kudzu did was detect the > mouse that was connected and configure X and gpm to know what type of > mouse it was. However as your system stands there is no /dev/psaux so > there is no way to detect a mouse. I tried simply removing the sound card lines from /etc/modules.conf to see if that restored the mouse. Mouse now works again. Sound card lines removed: alias sound-slot-0 cs4232 options sound dmabuf=1 alias synth0 opl3 options opl3 io=0x388 options cs4232 io=0x530 irq=5 dma=0 dma2=0 mpuio=0x330 mpuirq=9 On boot BIOS reports USB (devno 7), NIC (devno 9), and ACPI (devno -) on IRQ 5; ISA device WSS/SB on IRQ 9, DMA 1,0. IDE 2 is not in use, so IRQ 15 is not in use. SCSI (devno 8) is on IRQ 10. Video (devno 10) is on IRQ 11. AGP is not used. PCI slots are IRQ forced in the BIOS, video on 10 slot 1, NIC on 5 slot 2, and SCSI on 11 slot 3. Slot 4 is empty on AUTO. NIC was forced to IRQ 5 because for some reason I never figured out, OS/2 wants ISA sound on IRQ 9 instead of the customary 5, at least it did with the ESS1868 card that the CS4235 replaced. When NIC was allowed to use IRQ 9, ESS1868 sound could not be made to work. Sound card is not cs4232. It is cs4235. Motherboard is Tyan S1590 Trinity. Chipset is VIA MVP3. CPU is K6/2-550. > IOW your problem is a much lower level. It has nothing to do with the > particular mouse you're using. I'd doubt it has much to do with > anything Mandrake is doing at all. It might be interesting to see if a > totally unpatched clean 2.4.19 kernel from kernel.org behaves the same > way. If it does then your specific motherboard has a problem with the > 2.4.19 kernel. Without access to the hardware it'll be very difficult > to figure out why. Going to try that next unless something I just wrote above generates better suggestion(s). > It also might be interesting to see if your your mouse works when booting with >devfs=nomount I tried that last week. No apparent impact. > If it does then it's a problem with devfs... but I highly doubt this. > devfs finds out about what hardware is present from the kernel and it > would seem that your kernel doesn't think you have a /dev/psaux device > on your system. But, as shown above, it really is there! Running sndconfig also broke something else. I'm running the VC's on vga=788. When I run mc on the VC's, turning the panel back on with M-o causes a bunch of the prior contents of the screen display to scroll at a different virtual number of rows and columns (gibberish) before the panel draws. -- ". . . . in everything, do to others what you would have them do to you . . . ." Matthew 7:12 NIV Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://members.ij.net/mrmazda/
