Bug 55342

Summary:	System freezes during GNOME or KDE startup
Product:	[Retired] Red Hat Linux	Reporter:	Need Real Name <dan.waites>
Component:	autofs	Assignee:	Arjan van de Ven <arjanv>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Brock Organ <borgan>
Severity:	high	Docs Contact:
Priority:	medium
Version:	7.2	CC:	cajun
Target Milestone:	---
Target Release:	---
Hardware:	i686
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2004-03-19 20:02:33 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Need Real Name 2001-10-29 23:13:04 UTC

From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)

Description of problem:
After installation, I attempted to login to the system (using gdm), 
selecting the KDE session.  The KDE splash appears, but the system freezes 
when the panel is loading.  The mouse cursor and keyboard appear to work, 
but X simply stops.  Hard drive light remains lit, but no activity. 
Switching to other ttys is possible (and keyboard appears to work), but 
the login prompt does not respond to input. Soft reset is not possible, 
and hard reset is only possible by cycling master power switch. 

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
use test system with Matrox Mystique 4MB and AWE64 sound card
1. install Redhat 7.2, but remove X Windows Classic from package list
2. allow kudzu to set up all devices on first boot.
3. attempt to login with either KDE or GNOME.
	

Actual Results:  Complete system freeze (keyboard and mouse still work, 
but system does not respond to input) on all terminals.

Expected Results:  a normal login.


Additional info:

I am using XFree 4.1, using the mga driver.
I have a Matrox Mystique 4MB and Soundblaster AWE64 sound card.
After rebooting, I attempted to login using a GNOME session. The same 
problem appears, only when the 'GNOME loading: done.' message appears. 
Incidentally, in both of these situtations, the freeze appears to happen 
at the moment when some sort of startup sound might be played. 
Checking /var/log/messages reveals a number of modprobe errors (after 
login), but I do not know if these are the cause of the problem.  There 
are usually several, and they say things to the effect of "modprobe: 
modprobe: cannot locate module sound-slot-0-0", "modprobe: modprobe: 
cannot locate module sound-service-1-0", and so forth. I tried running 
sndconfig. sndconfig correctly detects the sound card and plays both the 
FM synth file and the midi file correctly. This does not appear to 
alleviate the problem, however. Disabling gdm and using startx to load X 
does not appear to make a difference, either. I _can_ load X using the 
manager-less Failsafe session. X appears to function normally here, so I 
suspect it is a sound problem. However, I cannot isolate the cause, as the 
problem causes a system freeze and leaves no other error messages other 
than those described above. It is also possible that it is a kudzu 
problem, though I don't know how to diagnose it.

Comment 1 Arjan van de Ven 2001-10-30 08:48:36 UTC

Is this with the 2.4.7 kernel or with the updated 2.4.9 kernel ?

Comment 2 Need Real Name 2001-10-30 17:07:17 UTC

Upgrading to the 2.4.9-7 packages apparently doesn't resolve the problem. The
lock up happens in exactly the same way. /var/log/messages shows a different
error this time, though: 'modprobe: modprobe: can't locate module
char-major-81'. Also, the last message in the log before reboot is the
gnome-name-server starting, in the GNOME case.

Comment 3 Need Real Name 2001-10-30 23:02:44 UTC

I'm starting to think this isn't a kernel problem. I can get sound to play using
XMMS in failsafe mode. X appears to work fine in failsafe mode, so there must be
a problem with both GNOME and KDE. Maybe there is a permissions problem?

Comment 4 Need Real Name 2001-10-31 18:59:48 UTC

New info: there is an additional message in /var/log/messages that pops up only
occasionally, and it is the last message before the failure. It is 'kernel:
ide-floppy driver 0.97.sv'. It is possible there is an IRQ conflict with the
floppy drive? It know that Nautilus automatically scans drives when it sets up
the desktop, so this is probably why the floppy driver is getting loaded here. I
tried to disable access to the floppy drive in /etc/fstab, but kudzu keeps
putting its line back in. I'm going to try to do some floppy operations in X and
see if I can reproduce the freeze.

Comment 5 Need Real Name 2001-10-31 19:13:57 UTC

Okay, there appears to be either an address or an IRQ conflict between the
floppy drive and the sound card.  After mounting an ext2 floppy, the sound card
will no longer work. I will try to resolve the conflict. Is kudzu supposed to
catch this sort of thing?

Comment 6 Need Real Name 2001-11-01 03:52:38 UTC

Actually, I don't believe this is a device conflict now. Sorry for the lengthy 
rambling so far, but I believe I've finally found the source of the problem.

I checked all of the addresses, DMAs, and IRQs allocated to the floppy drive 
and sound card. There is no overlap. Believing that I might have inadvertantly 
done something naughty, and started over from scratch.

I reinstalled 7.2, and then applied all update packages for 7.2 that are 
available. I then attempted to start GNOME from gdm, and it locked up exactly 
the same way as before. The same happens in KDE, only it occurs while the 
desktop is loading, and only when the CDROM and Floppy icons appear. So, I 
rebooted, and then switched to tty1, and logged in as root. I mounted the 
cdrom manually, and then logged in using gdm. The desktop came up without a 
problem. No crashes whatsoever. Incidentally, I noticed that while running the 
init.d scripts, the autofs script shows the following error: No Mountpoints 
Defined. Perhaps autofs in not configured properly by the installation 
program, or by kudzu?

So, this problem probably needs to be filed under autofs instead of kernel.