Bug 41651 - printtool locks up machine
printtool locks up machine
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
7.1
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Tim Waugh
Aaron Brown
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-05-21 14:11 EDT by Need Real Name
Modified: 2007-04-18 12:33 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-05-30 04:43:54 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
interrupts (411 bytes, text/plain)
2001-05-29 13:06 EDT, Michael Schwendt
no flags Details
ioports (704 bytes, text/plain)
2001-05-29 13:07 EDT, Michael Schwendt
no flags Details
lspci (1.96 KB, text/plain)
2001-05-29 13:07 EDT, Michael Schwendt
no flags Details

  None (edit)
Description Need Real Name 2001-05-21 14:11:17 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.77 [en] (X11; U; Linux 2.4.2-2 i586)

Description of problem:
I am running Red Hat Linux 7.1 on an AMD k6-2 400 with 192 ram. Everything
runs fine and when I load printtool in X, it loads the print-conf box and
then freezes the whole system. I can't control-c, or control-alt-backspace
or even control-alt-delete to get out. The only way is to do a hard reboot
of the system.

How reproducible:
Always

Steps to Reproduce:
1. startx
2. load gnome-terminal
3. type printtool
	

Actual Results:  The print-conf box shows up and then the whole system is
locked. I can't move my mouse or anything.

Expected Results:  I should have been able to set up my printer?

Additional info:
Comment 1 Michael Schwendt 2001-05-27 04:25:37 EDT
Same here with Kernel 2.4.2-2, updated rpms, AMD Duron 650 MHz, 128 MB RAM,
Gigabyte GA-7ZX, VIA KT133 chipset. Tried to re-awaken a very old non-postscript
matrix printer Star LC24-10 on parallel port (0x378).

No log message, no error/std output, no oops. Freezes the display, freezes the
keyboard, onboard sound (if active) keeps looping on the last buffer.

$ rpm --verify printconf-gui
$

# rpm --verify `rpm -qa | grep print`
#

Last lines of an strace run give this (approx.):

stat64("/usr/lib/python1.5/lib-dynload/_gnome", 0xbfffd8f0) = -1 ENOENT (No such
file or directory)
open("/usr/lib/python1.5/lib-dynload/_gnome.so", O_RDONLY) = -1 ENOENT (No such
file or directory)
open("/usr/lib/python1.5/lib-dynload/_gnomemodule.so", O_RDONLY) = -1 ENOENT (No
such file or directory)
open("/usr/lib/python1.5/lib-dynload/_gnome.py", O_RDONLY) = -1 ENOENT (No such
file or directory)
open("/usr/lib/python1.5/lib-dynload/_gnome.pyo", O_RDONLY) = -1 ENOENT (No such
file or directory)
stat64("/usr/lib/python1.5/site-packages/_gnome", 0xbfffd8f0) = -1 ENOENT (No
such file or directory)
open("/usr/lib/python1.5/site-packages/_gnome.so", O_RDONLY) = -1 ENOENT (No
such file or directory)
open("/usr/lib/python1.5/site-packages/_gnomemodule.so", O_RDONLY) = 8
fstat64(8, {st_mode=S_IFREG|0755, st_size = 45584, ...}) = 0
[...]
close(9) = 0
close(8) = 0
close(7) = 0
open/"/dev/lp0", O_WRONLY|O_NONBLOCK) = -1 ENOSYS (Function not implemented)
open/"/dev/lp0", O_WRONLY|O_NONBLOCK) = -1 ENOSYS (Function not implemented)
Comment 2 Michael Schwendt 2001-05-27 14:47:55 EDT
To <joey@linuxhelp.net>, try:

$ insmod parport
$ insmod parport_pc

With the parallel port kernel driver modules loaded, printtool no longer crashes
my machine.

After I had added this entry to /etc/modules.conf to re-enable my ZIP drive, the
loaded modules have fixed the printtool crash for me.

alias parport_lowlevel parport_pc
options -k parport_pc io=0x378 irq=7

Anyway, without those drivers, printtool should not be able to crash the machine
so badly.
Comment 3 Tim Waugh 2001-05-28 13:49:57 EDT
If the keyboard doesn't respond to num-lcok etc, it's a kernel bug.

Starting from the modules not being loaded, does 'insmod parport; insmod 
parport_pc' cause the machine to hang?
Comment 4 Michael Schwendt 2001-05-28 18:25:09 EDT
Hmm, I don't think I understand your question. Maybe see my comment from
2001-05-27 14:47:55 for details. I've had to experiment with the parport*
modules to re-enable my parallel port ZIP drive. With both parport and
parport_pc loaded, printconf-gui no longer crashes. I've not really used it yet,
though.

So, my questions at this time are: Should uninstalled kernel modules be able to
lock up the kernel? What is the recommended way to detect required parport
drivers and add entries to /etc/modules.conf automatically? Doesn't the kernel
module daemon try to load the modules when the device is accessed?

Comment 5 Tim Waugh 2001-05-28 18:38:22 EDT
> Should uninstalled kernel modules be able to lock up the kernel?

When you start printconf-gui, it will try to open the printer device nodes, 
which will in turn cause the kernel to autoload the lp module, which requires 
parport, which loads parport_lowlevel, which is aliases to parport_pc.

So just because modules aren't loaded before you start printconf-gui, it's no 
reason to suppose that the lock up is unrelated to those modules.

Further, the only thing that's in a position to lock up the machine is the 
kernel.

I am ignoring your ZIP drive thing at the moment (you shouldn't have had to do 
anything other than load the imm (or ppa) module), because I want to 
understand the lock-up problem.

Please do the following, to help me understand what's going on:

- Take out any lines in /etc/modules.conf that start 'options parport_pc'
- Unload the parport module.  You may have to unload imm, ppa, lp, parport_pc, 
  and anything else that's using it first.
- Type 'modprobe parport_pc'.
- Tell me what happens.

Does it lock up?  Does it find your parallel port correctly?  What does 
'dmesg' say?

Thanks,
Comment 6 Tim Waugh 2001-05-29 12:59:51 EDT
(I gather than the above experiment results in a locked machine.)

I would be very interested in the output of:

1. cat /proc/ioports
2. cat /proc/interrupts
3. lspci -v

When parport_pc loads, it probes for a port at 0x278, 0x378, and 0x3bc, and 
also looks around for PCI devices that it thinks are parallel port cards.  
Since 0x378 works for you when you supply the parameters, it's something like:

- 0x278 or 0x3bc lock up the machine when probed
- 0x378 is advertising an incorrect IRQ (perhaps a keyboard-related one)
- there is a PCI device which is confusing it

Comment 7 Michael Schwendt 2001-05-29 13:02:42 EDT
1) Taking out any entries for parport, parport_pc, from modules.conf.

2) # lsmod
Module                  Size  Used by
es1371                 25968   0 
ac97_codec              8800   0  (autoclean) [es1371]
soundcore               4464   4  (autoclean) [es1371]
autofs                 11264   3  (autoclean)
ne                      7424   1 
8390                    6816   0  (autoclean) [ne]

3) sync
4) modprobe parport_pc

*CRASH*

I knew this would happen because "modprobe" is just the equivalent of letting
load a module stack automatically by opening /dev/lp0.
Comment 8 Michael Schwendt 2001-05-29 13:06:35 EDT
Created attachment 19893 [details]
interrupts
Comment 9 Michael Schwendt 2001-05-29 13:07:04 EDT
Created attachment 19894 [details]
ioports
Comment 10 Michael Schwendt 2001-05-29 13:07:39 EDT
Created attachment 19895 [details]
lspci
Comment 11 Michael Schwendt 2001-05-29 13:12:23 EDT
1) Enabling

alias parport_lowlevel parport_pc
options -k parport_pc io=0x378 irq=7

2) # rmmod lp parport_pc parport ; lsmod
Module                  Size  Used by
es1371                 25968   0 
ac97_codec              8800   0  (autoclean) [es1371]
soundcore               4464   4  (autoclean) [es1371]
autofs                 11264   3  (autoclean)
ne                      7424   1 
8390                    6816   0  (autoclean) [ne]

3) printtool
(or "Python printconf-probe.py" as supplied by crutcher@redhat.com)

4) (entry in dmesg)
parport0: PC-style at 0x378, irq 7 [PCSPP,TRISTATE,EPP]
parport0: cpp_daisy: aa5500ff(38)
parport0: assign_addrs: aa5500ff(38)
parport0: cpp_daisy: aa5500ff(38)
parport0: assign_addrs: aa5500ff(38)
lp0: using parport0 (interrupt-driven).

NO crash.

Comment 12 Tim Waugh 2001-05-29 13:16:35 EDT
Aha.  A Via SIO chip:

00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 
22)
	Subsystem: VIA Technologies, Inc. VT82C686/A PCI to ISA Bridge
	Flags: bus master, stepping, medium devsel, latency 0

I have one of these too, but it's a different revision (mine is 40, yours is 
22).

I think that it's something to do with this.  Are you able to rebuild the 
kernel with additional patches if I supply them?
Comment 13 Michael Schwendt 2001-05-29 13:28:27 EDT
Of course, shouldn't be a problem (or do you see any? :). Running kernel-2.4.2-2
here right now, btw.

Comment 14 Tim Waugh 2001-05-29 13:51:55 EDT
Okay.  First some simple things:

- Please do 'dmesg -n 8' first, and then load parport_pc with no options.  See 
if there are some messages displayed on the console (make sure you're not in 
X) just before the lock-up.

- Recompile with CONFIG_PARPORT_PC_SUPERIO disabled, and see if that stops the 
lock ups.
Comment 15 Michael Schwendt 2001-05-29 16:58:35 EDT
The "modprobe parport_pc" test case at the console gives:

Winbond Super-IO detection, now testing ports 3F0,370,250,4E,2E ...

*CRASH*

FWIW, my old NE2000 card is listed as being based at 0x240-25F. It's ISA and in
there only temporarily. The system doesn't like it.

Recompiled kernel without Super-IO chipset support works flawlessly. Here're the
last lines of dmesg after modprobe parport_pc. Notice how the last line differs
from before (see 2001-05-29 13:12:23) due to autodetection:

parport0: PC-style at 0x378, irq 7 [PCSPP,TRISTATE,EPP]
parport0: cpp_daisy: aa5500ff(38)
parport0: assign_addrs: aa5500ff(38)
parport0: cpp_daisy: aa5500ff(38)
parport0: assign_addrs: aa5500ff(38)
parport_pc: Via 686A parallel port: io=0x378, irq=7

Comment 16 Tim Waugh 2001-05-30 04:43:49 EDT
Okay, it's the ISA SuperIO code then.
Comment 17 Tim Waugh 2001-06-05 04:56:39 EDT
The 2.4.5-0.2.9 kernel has that option disabled (the ISA SuperIO detection 
code will shortly be replaced in the Linus tree anyway).

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