From Bugzilla Helper: User-Agent: Mozilla/4.78 [en] (X11; U; Linux 2.4.9-21 i686) Description of problem: On at least the Supermicro 370DER, and I believe the 370DLR adn P3TDER and P3TDLR and P3TDE6 motherboards, when kudzu runs and probes the parallel port the system locks up. The only recovery possible is to press the reset button. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. run it Actual Results: locks up Expected Results: works Additional info: the following change to /etc/modules.conf will allow kudzu to work on these machines. #alias parport_lowlevel parport_pc alias parport_lowlevel off alias parport_pc off This problem has existed for the last several releases. I should have filed this a long time ago.
Tim, any ideas? All it does is load parport_pc (with no arguments) and read /proc/sys/dev/parport/lp<whatever>/autoprobe.
What type of parallel port hardware is this? What's in /proc/pci, for example? If you load parport_pc manually (like 'modprobe parport_pc'), does the same lock-up occur? (Presumably..) If you load parport_pc manually while specifying the correct base I/O address and no IRQ/DMA probing (like 'modprobe parport_pc io=0x378 irq=none dma=none'), does the lock-up still occur? (Hopefully not..)
we've always worked around the problem by using the following lines in the /etc/modules.conf file: #alias parport_lowlevel parport_pc alias parport_lowlevel off alias parport_pc off I just installed a 370der system using 7.3, and kudzu locked up the system again when it tried to poke at the parallel port. with the /etc/modules.conf file as above, "modprobe parport_pc" has no effect - nothing in /var/log/messages, no module loaded, no error message printed, and system does not lock up. reverse the commenting above, and "modprobe parport_pc" instantly locks up the system. I confirmed in the bios the settings for the parallel port: io address 0x378, IRQ 7, mode ECP, DMA channel 3. these are the bios defaults as set by supermicro; I haven't changed anything. I just now ran the following command, and the module loaded and the system seems happy. I have not tested that the parallel port is functional. modprobe parport_pc io=0x378 irq=none dma=none /proc/pci to follow. also, all the above is with the box-set install of 7.3. I'm going to apply all current errata and see if anything changes.
Created attachment 82187 [details] /proc/pci
just updated to all available errata, including kernel 2.4.18-17.7.xsmp. running "modprobe parport_pc" with the alias uncommented in the /etc/modules.conf file results in the machine instantly locking up hard.
Please do this: dmesg -c >/dev/null modprobe parport_pc io=0x378 irq=none dma=none dmesg and show me the output?
# dmesg -c # modprobe parport_pc io=0x378 irq=none dma=none # dmesg 0x378: FIFO is 16 bytes 0x378: writeIntrThreshold is 8 0x378: readIntrThreshold is 8 0x378: PWord is 8 bits 0x378: Interrupts are ISA-Pulses 0x378: ECP port cfgA=0x14 cfgB=0x40 0x378: ECP settings irq=<none or set by other means> dma=<none or set by other means> parport0: PC-style at 0x378 (0x778) [PCSPP,TRISTATE,COMPAT,ECP] parport0: cpp_daisy: aa5500ff(38) parport0: assign_addrs: aa5500ff(38) parport0: cpp_daisy: aa5500ff(38) parport0: assign_addrs: aa5500ff(38)
From looking at the code I guess that it's the ECP IRQ probe that's causing problems. Sounds like a buggy ECP implementation. Does it make a different whether or not you have a device plugged into the port (probably not)?
can't say, because I'm not aware of anyone ever plugging anything into the parallel port. and I don't have any parallel devices handy to test with. this may or may not be related, but I just tried to install RH80 on the system using pxe and kickstart. the system hung very early in the process and required hitting the reset button. this was repeatable. more details here or do you prefer a separate bugzilla report?
Was about to file a new bug, but this is similar. Inspiron 5150 has NO LEGACY PORTS... but the parport modules are still attempted to load by default. This was harmless except for warnings. However, on the 2.6.1 build 65 dev kernel at least, if these modules are not aliased in /etc/modprobe.conf install parport /bin/true install parport_pc /bin/true install parport_lowlevel /bin/true Then the vmware vmware-config.pl script freezes the entire module interface when it attempts to remove any existing vmware modules. After this lsmod or any other module-related action freezes the bash session until a reboot. Traced to this by seeing the frozen modprobe -r for parport modules in ps -Af. After aliasing out the parport modules it worked fine. Basically having the parport modules on a machine with no parports is no longer harmless.
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/