Bug 166339 - System (Dell Dimension 9100) freezes during installation
Summary: System (Dell Dimension 9100) freezes during installation
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: xorg-x11   
(Show other bugs)
Version: 4.0
Hardware: i686
OS: Linux
Target Milestone: ---
: ---
Assignee: Adam Jackson
QA Contact:
Keywords: Regression, Reopened
Depends On:
TreeView+ depends on / blocked
Reported: 2005-08-19 13:24 UTC by Martin Hejl
Modified: 2007-11-30 22:07 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-07-11 21:16:32 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Output of lspci (1.58 KB, text/plain)
2005-08-19 13:25 UTC, Martin Hejl
no flags Details
contents of /proc/cpuinfo (463 bytes, text/plain)
2005-08-19 13:26 UTC, Martin Hejl
no flags Details
output of dmesg (7.54 KB, text/plain)
2005-08-19 13:27 UTC, Martin Hejl
no flags Details
xorg.conf (2.83 KB, text/plain)
2006-05-11 15:51 UTC, Alan Matsuoka
no flags Details
Xorg.0.log (43.14 KB, text/plain)
2006-05-11 15:52 UTC, Alan Matsuoka
no flags Details
sysreport of affected system (965.67 KB, application/octet-stream)
2006-07-26 11:09 UTC, Martin Hejl
no flags Details
Sysreport of another affected system (1016.08 KB, application/x-bzip2)
2006-07-26 11:17 UTC, Dirk Gfroerer
no flags Details
Another sysreport of an affected machine (821.81 KB, application/x-bzip2)
2006-07-26 15:40 UTC, Dirk Gfroerer
no flags Details

Description Martin Hejl 2005-08-19 13:24:41 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.10) Gecko/20050717 Firefox/1.0.6

Description of problem:
I'm trying to install RHEL 4 U1 WS via NFS on a Dell Dimension 9100.

After a short period of time (usually after anaconda switches to graphical mode) the system completely freezes - mouse and keyboard (both attached via USB) are dead.

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

How reproducible:

Steps to Reproduce:
1. Boot from boot-CD
2. Select language and keyboard mapping
3. Fill in Network info and NFS server


Actual Results:  Anaconda switches to graphical mode and the system freezes shortly thereafter (once we got as far as disk druid)

Expected Results:  Installation proceeds

Additional info:

Comment 1 Martin Hejl 2005-08-19 13:25:37 UTC
Created attachment 117908 [details]
Output of lspci

Comment 2 Martin Hejl 2005-08-19 13:26:44 UTC
Created attachment 117909 [details]
contents of /proc/cpuinfo

Comment 3 Martin Hejl 2005-08-19 13:27:13 UTC
Created attachment 117910 [details]
output of dmesg

Comment 4 Jeremy Katz 2005-08-19 14:42:57 UTC
Does booting with 'linux nofb' help?  Are your keyboard leds blinking at this point?

Comment 5 Martin Hejl 2005-08-19 14:55:38 UTC
When booting with 'linux nofb' my LC Display goes blank stating "no signal" as
soon as anaconda is supposed to start the graphical mode (after entering network
info and info on the NFS server) .
Keyboard leds don't flash.
I just installed RHEL 3 U5 and the installation went without a hitch (but with
the Vesa video driver)

Comment 6 Martin Hejl 2005-08-19 16:15:37 UTC
I just installed RHEL 4 U1 WS with "linux nofb text" and the install went
through smoothly. I'll test tomorrow with the proprietary display drivers from
ATI, to see if X works.

Comment 7 Martin Hejl 2005-08-20 12:05:35 UTC
Ok, after a bit of tweaking, the install of WS4 seems to work. Here's what I
needed to do to get through the installation (including firstboot) without
locking up the system:
* boot from the install CD with "linux nofb text" 
* after the install, when the system is rebooted, remove "rhgb quiet" from grub
and add "nofb"
* remove the radeon driver from /etc/X11/xorg.conf and replace it with the vesa
driver (or install the driver from ATI)

Comment 8 Martin Hejl 2005-08-20 12:18:57 UTC
I just tried the beta for WS4 Update 2 - it locks up at the screen asking wether
I want to test the installation media

Comment 15 Martin Hejl 2006-05-04 11:30:51 UTC
Bug also applies to RHEL 4 U3 - see Support requests
873768, 873766, 873764 and 849096 

Comment 18 Alan Matsuoka 2006-05-11 15:51:33 UTC
Created attachment 128899 [details]

as requested

Comment 19 Alan Matsuoka 2006-05-11 15:52:57 UTC
Created attachment 128900 [details]

Comment 26 Mike A. Harris 2006-07-25 16:39:24 UTC
(In reply to comment #25)
> In RHEL 4 U3
> Internal Status set to 'Resolved'
> Status set to: Closed by Client
> This event sent from IssueTracker by Charles_Rose 
>  issue 84778

Closing bugzilla bug to match issue tracker status.  Assuming the problem
is no longer reproduceable.  If the problem recurs, please reopen and
respond to previous engineering inquiry in comment #22 above.

Comment 27 Martin Hejl 2006-07-26 06:19:18 UTC
I don't see "comment #22 above" (comments 20 to 25 are not visible to me, all I
see is #19 and #26), so it's hard to respond to it. But the bug surely still
applies. The service requests 873768, 873766, 873764 and 849096 are still open,
in status "Waiting on Red Hat"

Comment 28 Martin Hejl 2006-07-26 06:27:37 UTC
I'd love to reopen the bug, but when I try to, all I get is this:
"You tried to change the Status field from CLOSED to NEW, but only the owner or
submitter of the bug, or a sufficiently empowered user, may change that field."

Comment 29 Mike A. Harris 2006-07-26 09:16:38 UTC
(In reply to comment #27)
> I don't see "comment #22 above" (comments 20 to 25 are not visible to me, all I
> see is #19 and #26), so it's hard to respond to it.

This bug was originally filed directly in bugzilla instead of coming in
via Red Hat support services.  Since then, it has had numerous issue-tracker
requests attached to it.  The bug contains a number of comments which are
private communication between engineering and support, which are flagged
private.  Any time you see missing comment numbers in a bug, it indicates
there are private comments present intended for internal communication,

I have made private requests for more information, which should have
gotten passed along to all customers who have issue-tracker requests
linked to this issue, however there have not been any responses to
the request.  Since then some of the linked issues were closed as
Resolved, so under the assumption that the issue was no longer a problem
for some of the people who reported it, and the lack of any type of
response to inquiries, must indicate the issue is no longer relevant.

I don't know if you have filed an official Red Hat support request for
this issue via http://www.redhat.com/support or not, however now that
you have confirmed the issue is still occuring, I'm reopening it.

> But the bug surely still applies. The service requests 873768, 873766,
> 873764 and 849096 are still open, in status "Waiting on Red Hat"

Thanks for confirming the issue.

To get everyone on the same page, I'll reiterate the current status in
public comment, so that everyone sees the same thing:

So far, Red Hat has been unable to reproduce the reported problem
internally.  In order to diagnose the problem and potentially fix it,
we first need a way to reproduce the issue in our labs.  Since it
seems to be affecting a lot of people, we need _everyone_ who is
experiencing the issue to attach there information directly into this
bug report so that engineering has all of the details from _all_ of
the systems the problem is occuring on.

Once that information is available, we can review it and try to determine
what commonality the problematic systems may share, and can hopefully
get a test system to reproduce the issue.

If we can not reproduce the issue, then we will require a system be
sent to our Westford lab which is known to reproduce the issue, so that
we can directly investigate it.

If everyone can attach their info now, that would be very useful.

To Red Hat support services:  Please ensure that this above engineering
request has been passed on to _all_ customers experiencing this problem,
and that any information that is returned to Red Hat via issue-tracker
and/or CRM, is directly copied into this bugzilla report so that engineering
has the data to work with.

Comment 31 Mike A. Harris 2006-07-26 09:31:16 UTC
(In reply to comment #27)
> I don't see "comment #22 above" (comments 20 to 25 are not visible to me, all I
> see is #19 and #26), so it's hard to respond to it. But the bug surely still
> applies. The service requests 873768, 873766, 873764 and 849096 are still open,
> in status "Waiting on Red Hat"

Only bugzilla is visible to Red Hat engineering, so any information present
in issues filed in CRM or issue-tracker which are relevant to engineering,
need to be copied through to the bugzilla report tracking the issue
by support folk, or engineering never sees it, as we do not use CRM or
issue-tracker directly.

Basically it works like this:

- Customer reports issue to Red Hat support services
- Support services work with customer to try and resolve the issue and to
  gather information.
- If support can not resolve the issue directly, they gather information,
  and it gets escalated to RHAT engineering via bugzilla, and all details
  of the issue are copied through to bugzilla.
- Red Hat engineering works directly with bugzilla.  Any requests made,
  go back to support services, who work with the customer to obtain the
  information requested by engineering, which then gets copied back into

customer <-> support <-> engineering

This bug is a bit confusing because it was originally a direct-filed bugzilla
bug, which flows as:  user <-> engineering  - which is outside of the
Red Hat support organization.  Later, official issues got attached, but
Red Hat support appears to have not attached themselves to the bug report, so
the flowchart appears to be:

user -> engineering


customer -> RH support -> bugzilla -> engineering -> bugzilla -> STOP

I'm trying to reconnect things so that it becomes:

customer <-> RH support <-> bugzilla -> engineering -> bugzilla -> RH support ->

Hopefully this helps explain any confusion, and we can get the required info

Thanks again for reopening.

Comment 32 Martin Hejl 2006-07-26 11:09:45 UTC
Created attachment 133063 [details]
sysreport of affected system

Comment 33 Dirk Gfroerer 2006-07-26 11:17:39 UTC
Created attachment 133064 [details]
Sysreport of another affected system

This sysreport should be identical to the sysreport Martin just added. Both
machines are Dell Dimension 9100 machines. We ordered them via the same order.
The main difference to the sysreport Martin added, is, this machine is
currently running the ATI proprietary drivers. Maybe there's some additional
information in the logs which might help you.
Please contact us if more details / information is needed.

Comment 34 Dirk Gfroerer 2006-07-26 15:40:11 UTC
Created attachment 133077 [details]
Another sysreport of an affected machine

This is a sysreport of a Dell Dimension 9150 which is also facing the issue.
Currently running with the ATI proprietary drivers.

Comment 37 Dirk Gfroerer 2006-08-17 11:00:19 UTC
Just an FYI: Update 4 didn't resolve the issue.

Comment 38 Dirk Gfroerer 2006-11-18 13:48:29 UTC
Installed RHEL5 Beta2. Worked like a charm. Dekstop effects are working, too. So
no issues with RHEL5 Beta so far.

Comment 44 Alan Matsuoka 2007-04-30 18:24:05 UTC
Looks like this one fell through the cracks.

Comment 47 Adam Jackson 2007-07-11 21:16:32 UTC
Closing as per comment #46.  If you still want this issue considered for RHEL4,
please reopen, and explain the nature of the modifications mentioned in comment #42.

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