Bug 60233 - kudzu locks up machine when probing parallel port
kudzu locks up machine when probing parallel port
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Arjan van de Ven
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2002-02-22 11:53 EST by Jim Wright
Modified: 2008-08-01 12:22 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-09-30 11:39:23 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
/proc/pci (2.62 KB, text/plain)
2002-10-26 02:59 EDT, Jim Wright
no flags Details

  None (edit)
Description Jim Wright 2002-02-22 11:53:18 EST
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:

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

#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.
Comment 1 Bill Nottingham 2002-02-22 11:56:48 EST
Tim, any ideas?  All it does is load parport_pc (with no arguments) and read
Comment 2 Tim Waugh 2002-02-26 03:52:03 EST
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..)
Comment 3 Jim Wright 2002-10-26 02:57:41 EDT
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

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.
Comment 4 Jim Wright 2002-10-26 02:59:02 EDT
Created attachment 82187 [details]
Comment 5 Jim Wright 2002-10-26 03:19:27 EDT
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.
Comment 6 Tim Waugh 2002-11-07 09:08:58 EST
Please do this:

dmesg -c >/dev/null
modprobe parport_pc io=0x378 irq=none dma=none

and show me the output?
Comment 7 Jim Wright 2002-11-07 17:02:17 EST
# 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
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)
Comment 8 Tim Waugh 2002-11-11 12:59:06 EST
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)?
Comment 9 Jim Wright 2002-11-13 01:08:04 EST
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?
Comment 10 Andy Green 2004-02-02 02:20:09 EST
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.
Comment 11 Bugzilla owner 2004-09-30 11:39:23 EDT
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

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/

Note You need to log in before you can comment on or make changes to this bug.