Bug 676538 - Hard lock after starting installation
Summary: Hard lock after starting installation
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-nouveau
Version: 14
Hardware: Unspecified
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Ben Skeggs
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-02-10 07:18 UTC by Phil
Modified: 2018-04-11 09:01 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-02-15 05:11:56 UTC
Type: ---


Attachments (Terms of Use)
program.log (1.01 KB, text/plain)
2011-02-10 22:29 UTC, Phil
no flags Details
X.log (25.42 KB, text/plain)
2011-02-10 22:29 UTC, Phil
no flags Details
syslog (78.05 KB, text/plain)
2011-02-10 22:30 UTC, Phil
no flags Details
dmidecode - sans asset numbers (21.10 KB, text/plain)
2011-02-10 22:30 UTC, Phil
no flags Details
dmesg - ref comment 10 (123.73 KB, text/plain)
2011-02-15 06:07 UTC, Phil
no flags Details
messages - ref comment 10 (228.13 KB, text/plain)
2011-02-15 06:08 UTC, Phil
no flags Details
xorg.log - ref comment 10 (47.47 KB, text/plain)
2011-02-15 06:09 UTC, Phil
no flags Details

Description Phil 2011-02-10 07:18:22 UTC
Description of problem:
The HP 8100 Elite SFF hard locks when trying to install Fedora 14 32 & 64.  Strangely though the mouse is still movable but the keyboard is unresponsive and the only way out is to hold the power button. (machine spec in the additional info below)


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


How reproducible:
Every time on multiple machines of the same specification, we have over 60 machines on campus that we need to run Fedora on.


Steps to Reproduce:
1. Boot in to installation via DVD or PXE
2. Select defaults and get to stage 2 when X is started
3. Select "ok" on the welcome screen.
4. HARD LOCK with no way to change VT's
  

Actual results:
can not install.


Expected results:
able to install


Additional info:

* Rescue mode is flawless

* Computer specification
http://h10010.www1.hp.com/wwpc/us/en/sm/WF06a/12454-12454-64287-321860-3328898-4098436.html
** i5 650
** NVIDIA Quadro NVS 295 (256 MB) dual display port
** 8 GB RAM
** 320GB HD

Comment 1 Chris Lumens 2011-02-10 19:42:34 UTC
anaconda doesn't do anything special with input hardware.  Let's first try reassigning over to X and see if they have any clever ideas about how to get more debugging information.

Comment 2 Phil 2011-02-10 22:28:37 UTC
Yeah, I was about to update this to reflect an X issue.  thanks for the reassignment.


Ways to make it crash:

PXE boot -> kickstart.
Everything is fine until X starts, an "Examining Devices" dialogue pops up then insta-freeze

DVD boot -> standard install.
As soon as X is started I can switch to any one of the other VT's and all is good.  As soon as I switch back to VT6, insta-freeze.  This is good as I have been able to get the logs before crashing and have noticed that there is an error in program.log

Comment 3 Phil 2011-02-10 22:29:09 UTC
Created attachment 478136 [details]
program.log

Comment 4 Phil 2011-02-10 22:29:35 UTC
Created attachment 478137 [details]
X.log

Comment 5 Phil 2011-02-10 22:30:01 UTC
Created attachment 478138 [details]
syslog

Comment 6 Phil 2011-02-10 22:30:44 UTC
Created attachment 478139 [details]
dmidecode - sans asset numbers

Comment 7 Phil 2011-02-11 01:10:40 UTC
I was able to do a text mode installation and everything completed successfully.  During bootup RHGB worked a treat and i saw the animated "F".  Because I did a text mode installation the default init level was 3.  When logging in as root and calling init 5 the machine hard locks and is virtually unusable.  I was able to, before the init 5, start the network and sshd.  I don't know what information to gather so I've only included messages after init 5.


Tail of /var/log/messages after "init 5":

Feb 11 11:36:11 localhost init: start-ttys main process (1810) terminated with status 1
Feb 11 11:36:12 localhost kernel: [  101.882713] [drm] nouveau 0000:01:00.0: Allocating FIFO number 2
Feb 11 11:36:12 localhost kernel: [  101.894516] [drm] nouveau 0000:01:00.0: nouveau_channel_alloc: initialised FIFO 2
Feb 11 11:36:12 localhost kernel: [  102.046627] [drm] nouveau 0000:01:00.0: Allocating FIFO number 3
Feb 11 11:36:12 localhost kernel: [  102.063723] [drm] nouveau 0000:01:00.0: nouveau_channel_alloc: initialised FIFO 3
Feb 11 11:36:13 localhost NetworkManager[1141]: <error> [1297386373.261732] [nm-manager.c:1332] user_proxy_init(): could not init user settings proxy: (3) Could not get owner of name 'org.freedesktop.NetworkManagerUserSettings': no such name
Feb 11 11:36:15 localhost kernel: [  104.628356] [drm] nouveau 0000:01:00.0: PRAMIN flush timeout
Feb 11 11:36:15 localhost kernel: [  104.996777] [drm] nouveau 0000:01:00.0: PFIFO_INTR 0x04000000 - Ch 2


NOTES:
* Xorg is using effectively 100% cpu but other processes are running fine.
* Xorg can only be killed with -9
* After killing X with -9 the machine freezes and is completely unresponsive locally or remotely.

Comment 8 Phil 2011-02-11 02:03:55 UTC
the same issue exists with the proprietary Nvidia driver installed from rpmfusion

Note: I am running x86_64..

Comment 9 Phil 2011-02-11 02:57:36 UTC
sorry for stretching all of this information over so many comments but after each post I've had a brain wave of something else to try..

I removed the add in pci-ex Nvidia card and booted with the default on board intel i915 based gpu.  X still sits on 100% and does start -but- it seems to be working albeit slower than a sloth in a slowest sloth of all time contest.  Pressing the number lock takes a good 30-60 seconds to register and turn on/off.

Using nomodeset doesn't work without writing an xorg.conf file and right now I don't have the time.

Switching back to the addin nvidia card and after removing all rpmfusion nvidia packages and custom xorg.conf shizite when X is started and it hit's 100% cpu, the load average goes up to 1.00-1.11 and the numlock test nets no response at all.  The system is still remote manageable.

Comment 10 Matěj Cepl 2011-02-14 12:42:30 UTC
This looks like kernel issue to me (or Xorg drivers' kernel parts issue). Could we ask you to (without any nomodeset, but you can start in runlevel 3 and run startx as a normal user)

add drm.debug=0x04 to the kernel command line, restart computer, and attach

* your X server config file (/etc/X11/xorg.conf, if available),
* full X server log file (/var/log/Xorg.*.log)
* output of the dmesg command (obtained via ssh if necessary), and
* system log (/var/log/messages)

to the bug report as individual uncompressed file attachments using the bugzilla file attachment link above.

We will review this issue again once you've had a chance to attach this information.

Thanks in advance.

Comment 11 Phil 2011-02-15 06:07:52 UTC
Created attachment 478765 [details]
dmesg - ref comment 10

Comment 12 Phil 2011-02-15 06:08:21 UTC
Created attachment 478766 [details]
messages - ref comment 10

Comment 13 Phil 2011-02-15 06:09:38 UTC
Created attachment 478767 [details]
xorg.log - ref comment 10

I logged in, not su -, as a user and was able to start X -BUT- it locked again..

Comment 14 Phil 2011-02-17 02:42:34 UTC
I see that this has been refiled as a nouveau bug but as detailed in comment 8 and comment 9 this doesn't appear to wholly be a specifically nouveau issue.  The motherboard has mainly intel based components including an i915 GMA (disabled due to addin card) and still exhibits issues when there is no nvidia hardware plugged in.


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