Bug 964443 - Fedora 19 Live Alpha, Beta and Release Candidate 1 hangs/freezes on HP Envy 23 (solved); hardware bug is root cause
Fedora 19 Live Alpha, Beta and Release Candidate 1 hangs/freezes on HP Envy 2...
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
19
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: Kernel Maintainer List
RejectedBlocker
:
: 948641 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-05-18 11:54 EDT by schaefi
Modified: 2013-09-23 13:52 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-07-24 16:15:23 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description schaefi 2013-05-18 11:54:44 EDT
Description of problem:
Trying to boot Fedora 19 alpha on a HP Envy 23 fails.

Details:

1. Fedora-Live-Desktop-x86_64-19-Alpha-1.iso is booted from USB. Grub starts correctly.

2. Choosing in grub:

2.a "Fedora-Live-Desktop-x86_64-19-A1"
-> The blue Fedora Sign appears on the display with an offset. The mouse can still be move but shows that the Window has an offset to the screen. The systems hangs and does not come to the login-window.
"CTRL + ALT + F2" gives me the shell.The last line in /var/log/messages is:

May 18 13:20:29 localhost setroubleshoot: SELinux is preventing /usr/bin/login from getattr access on the directory /run/systemd/system. For complete messages. run sealert -1 7d408226-3381-4b09-901b-b08063e7ebcb

Then the screen and the mouse freeze/hang. The mouse can not be moved anymore. CTRL + ALT + F1/F2 does not work. CTRL + ALT + DELETE does not work. The system has to be powered-off to reboot.


2.b "Fedora-Live-Desktop-x86_64-19-A1" and edit details:
in Grub choose "Fedora-Live-Desktop-x86_64-19-A1"and with "e" edit the boot command. Change rgbh to nomodset. The boot command is then:

linuxefi /isolinux/vmlinuz0 root=live:LABEL=FEdora-Live_Desktop-x86_64-10-A1 ro rd.live.image quiet nomodeset

Press F10 to exit the edit mode and boot. The system starts booting although the displayed window has an offset to the screen. The mouse works but has also this offset. The system advances to "[ok] Started GNOME Display Manager". Then it hangs. The mouse still works. "CTRL + ALT + F2" gives me the shell.The last line in /var/log/messages is:

May 18 13:37:23 localhost setroubleshoot: SELinux is preventing /usr/bin/login from getattr access on the directory /run/systemd/system. For complete messages. run sealert -1 08021dc7-061b-4e60-aaf9-7eb5c0b384ea.

Then the screen and the mouse freeze/hang. The mouse can not be moved anymore. CTRL + ALT + F1/F2 does not work. CTRL + ALT + DELETE does not work. The system has to be powered-off to reboot.


2.c "Verify and Boot Fedora-Live--Desktop-x86_64-19-A1"
The USB-stick is checked and given ok. Then blue Fedora Sign appears on the display with an offset. The mouse can still be move but shows that the Window has an offset to the screen. The systems hangs and does not come to the login-window. Then the system hangs completely. The mouse can not be moved anymore. CTRL + ALT + F1/F2 does not work. CTRL + ALT + DELETE does not work. The system has to be powered-off to reboot.


Hardware Details:
- HP envy 23
- Video graphics: Radeon HD 7450A
- Multi-touch enabled 58.42 cm (23 inch) diagonal widescreen full high-definition LED backlit display
- Details on: 
http://h10025.www1.hp.com/ewfrf/wc/document?docname=c03683196&cc=ad&dlc=en&lc=en&jumpid=reg_r1002_usen_c-001_title_r0001#N1445


Boot Medium:
USB-stick with Fedora-Live-Desktop-x86_64-19-Alpha-1.iso of 18.05.2013.
The correctness of the USB-stick has been verified by executing the respective grub program and the result is "ok".


Version-Release number of selected component (if applicable):
Fedora-Live-Desktop-x86_64-19-Alpha-1.iso of 18.05.2013



Additional info:
From my interpretation this might even be two bugs. One bug in the installation media that is not able to correctly display the boot-windows (display is frozen, but mouse still moves). And a second bug in xorg that freezes the complete system (mouse can not be moved anymore)
Comment 1 schaefi 2013-05-26 18:21:06 EDT
Test with Fedora 19 Mate Beta Live

I tried again with Fedora-Live-MATE-Compiz-x86_64-19-Beta-1.iso (version as of 23.05.13) on HP Envy 23 from:
https://dl.fedoraproject.org/pub/alt/stage/19-Beta-RC4/Live/x86_64/

Results:
Fedora 19 boots and runs correctly.
After ca. 15min the system hangs (keyboard freezes; mouse freezes; ping stops answering)

I ran also the following options:

1. Boot with adding "noacpi" as bootparameter in grub

2. Boot with adding "noacpi" as boot parameter in grub and setting power save mode to "endless"

3. Boot with adding "noacpi" as boot parameter in grub and setting power save mode to "endless" and switching of xorg with "service lightdm stop"

All 3 attempts lead to a system hand.

Interpretation:
in Fedora-Live-MATE-Compiz-x86_64-19-Beta-1.iso the boot problems are fixed.
Yet there is still another bug. This bug is not within xorg but in a level below.

I am very open to any suggestion what I could do to track down the issue.
Comment 2 Adam Williamson 2013-05-30 21:11:02 EDT
One obvious thing would be to leave a terminal running 'journalctl -f' running until the system hangs and see if you can catch any related messages in it.
Comment 3 schaefi 2013-06-11 18:04:53 EDT
(In reply to Adam Williamson from comment #2)
> One obvious thing would be to leave a terminal running 'journalctl -f'
> running until the system hangs and see if you can catch any related messages
> in it.

Hi Adam,

thanks for your suggestion. However running 'journalctl -f' did not capture any message just before the freeze (keyboard freezes; mouse freezes; ping stops answering).

I suspect, that the root cause of the freeze is a kernel bug. 

I would apreciate very much any comment on the issue or any method I could look into.

(by the way: I tried installing Fedora-Live-MATE-Compiz-x86_64-19-Beta-1.iso and the installation routine screwed up my efi-boot systems of all my other Linux operating systems. I am now left in a complete mess).
Comment 4 Adam Williamson 2013-06-11 19:27:21 EDT
"I would apreciate very much any comment on the issue or any method I could look into."

If you have another system handy, you can enable sshd, ssh in from the other system, and 'tail -f /var/log/messages' and see if you can catch the error that way. I agree, BTW, that what's happening is very likely a kernel crash and we need to capture it somehow.

"by the way: I tried installing Fedora-Live-MATE-Compiz-x86_64-19-Beta-1.iso and the installation routine screwed up my efi-boot systems of all my other Linux operating systems. I am now left in a complete mess"

Sad to hear - could you file that separately, with some details? Thanks.
Comment 5 schaefi 2013-06-13 18:49:11 EDT
Hi Adam,

I have another system ready. Unfortunately the installation routine of Fedora-Live-MATE-Compiz-x86_64-19-Beta-1.iso does not work correctly, so that I can not install the system. I can only let it run from USB.

Booting Live-MATE-Compiz-x86_64-19-Beta-1.iso from USB and changing to su I start the sshd:
system sshd start

I can ping the system (I have given it a fix IP in my network):
ping 192.168.1.53

However I can not login with:
ssh 192.168.1.53
since I do not have a user or password on the machine

Which password would I have to give in order to login with ssh into the live media?
Comment 6 Adam Williamson 2013-06-13 18:58:13 EDT
Set a password for the liveuser or root account with 'passwd', and log in as that account.
Comment 7 schaefi 2013-06-15 01:43:23 EDT
(In reply to Adam Williamson from comment #6)
> Set a password for the liveuser or root account with 'passwd', and log in as
> that account.

Here is what I did:
Boot Live-MATE-Compiz-x86_64-19-Beta-1.iso from USB and changing to su I start the sshd:
service sshd start
Then I set the password for root with:
passwd

From another system I can ping the system (I have given it a fix IP in my network):
ping 192.168.1.53

Then from the other system I login into the system:
ssh root@192.168.1.53
(if this procedure is repeated it might be necessary to delete or change .ssh/known_host on the other system in order to enable the connection)

Then from the other system I start the monitoring:
tail -f /var/log/messages

The system freezes (keyboard freezes; mouse freezes; ping stops answering) in about 10 minuted. The displayed message of 'tail -f /var/log/messages' is:

------------------------------------------------(first attempt)
Jun 15 02:33:18 localhost NetworkManager[773]: <info> Activation (eno1) Stage 4 of 5 (IPv6 Configure Timeout) complete.
Jun 15 02:33:29 localhost systemd[1]: Starting Stop Read-Ahead Data Collection...
Jun 15 02:33:29 localhost systemd[1]: Started Stop Read-Ahead Data Collection.
Jun 15 02:33:52 localhost su: (to liveuser) liveuser on none
Jun 15 02:38:14 localhost systemd[1]: Starting OpenSSH server daemon...
Jun 15 02:38:14 localhost sshd-keygen[1959]: Generating SSH2 RSA host key: [  OK  ]
Jun 15 02:38:14 localhost sshd-keygen[1959]: Generating SSH1 RSA host key: [  OK  ]
Jun 15 02:38:14 localhost sshd-keygen[1959]: Generating SSH2 DSA host key: [  OK  ]
Jun 15 02:38:14 localhost systemd[1]: Started OpenSSH server daemon.
Jun 15 02:39:39 localhost systemd-logind[608]: New session 2 of user root.
Jun 15 02:47:45 localhost systemd[1]: Starting Cleanup of Temporary Directories...
Jun 15 02:47:46 localhost systemd-tmpfiles[2063]: stat(/run/user/1000/gvfs) failed: Permission denied
Jun 15 02:47:46 localhost systemd[1]: Started Cleanup of Temporary Directories

---------------------------------------------

------------------------------------------------(second attempt)
[root@localhost ~]# tail -f /var/log/messsages
tail: cannot open ‘/var/log/messsages’ for reading: No such file or directory
[root@localhost ~]# tail -f /var/log/messages 
Jun 15 01:10:17 localhost NetworkManager[768]: <info> Activation (eno1) Stage 4 of 5 (IPv6 Configure Timeout) complete.
Jun 15 01:10:30 localhost systemd[1]: Starting Stop Read-Ahead Data Collection...
Jun 15 01:10:30 localhost systemd[1]: Started Stop Read-Ahead Data Collection.
Jun 15 01:10:48 localhost su: (to liveuser) liveuser on none
Jun 15 01:10:53 localhost systemd[1]: Starting OpenSSH server daemon...
Jun 15 01:10:53 localhost sshd-keygen[1933]: Generating SSH2 RSA host key: [  OK  ]
Jun 15 01:10:53 localhost sshd-keygen[1933]: Generating SSH1 RSA host key: [  OK  ]
Jun 15 01:10:53 localhost sshd-keygen[1933]: Generating SSH2 DSA host key: [  OK  ]
Jun 15 01:10:53 localhost systemd[1]: Started OpenSSH server daemon.
Jun 15 01:12:27 localhost systemd-logind[618]: New session 2 of user root.
Jun 15 01:24:45 localhost systemd[1]: Starting Cleanup of Temporary Directories...
Jun 15 01:24:45 localhost systemd-tmpfiles[2038]: stat(/run/user/1000/gvfs) failed: Permission denied
Jun 15 01:24:45 localhost systemd[1]: Started Cleanup of Temporary Directories.

---------------------------------------------

I have watched the monitoring. The last message has been displayed not in the moment of freezing but perhaps 4-6 minutes before freezing.
Also I like to mention that the system went down automatically after 2 minutes after freezing and rebooted.

Further informations are
- the system run ok with Windows 8. So there does not seem to be a hardware problem
- running the HP tools to check hardware e.g. RAM also whos that the hardware is ok

I hope that helps (Myself I am still clueless).

If I can provide any further information or if I can try anything else please let me know. I would also be interested in an application to completely check the system and the hardware (ubuntu has such an app). Is there a test app for fedora?
Comment 8 Adam Williamson 2013-06-22 12:01:33 EDT
Unfortunately, we can't really block releases for this kind of bug if it only seems to affect one system, or a small number of systems: there's just so much hardware out there that it's effectively impossible to commit to something like 'there can't be any hardware we know about where the system just doesn't work', we'd never get a release out.

The log messages don't give us much of a hint unfortunately. If you can do it again, can you try running 'journalctl -f' instead of 'tail -f /var/log/messages' ? That might give us a chance at catching more output (sorry I didn't think of it before).
Comment 9 schaefi 2013-06-23 18:21:03 EDT
Hi Adam,
thanks a lot for your comment. Your helo is very much apreciated.

> If you can do it again, can you try running 'journalctl -f' instead of 'tail -f
> /var/log/messages' ? That might give us a chance at catching more output

In Comment 3 I already debugged the system with 'journalctl -f'. Now I did it again with a remote login from another machine (see comment 7). Then I ran:
journalctl -f

The system freezes (keyboard freezes; mouse freezes; ping stops answering) in about 20 minuted. The displayed message of 'journalctl -f' is:

------------------------------------------------------------
[root@localhost ~]# journalctl -f
-- Logs begin at Sun 2013-06-23 19:41:20 EDT. --
Jun 23 17:42:29 localhost sshd-keygen[1924]: Generating SSH1 RSA host key: [...]
Jun 23 17:42:29 localhost sshd-keygen[1924]: Generating SSH2 DSA host key: [...]
Jun 23 17:42:29 localhost systemd[1]: Started OpenSSH server daemon.
Jun 23 17:42:29 localhost sshd[1946]: Server listening on 0.0.0.0 port 22.
Jun 23 17:42:29 localhost sshd[1946]: Server listening on :: port 22.
Jun 23 17:42:47 localhost passwd[1948]: pam_unix(passwd:chauthtok): password...t
Jun 23 17:43:38 localhost sshd[1951]: Connection closed by 192.168.1.52 [pr...h]
Jun 23 17:44:36 localhost sshd[1953]: Accepted password for root from 192.1...h2
Jun 23 17:44:36 localhost systemd-logind[597]: New session 2 of user root.
Jun 23 17:44:36 localhost sshd[1953]: pam_unix(sshd:session): session opene...0)
Jun 23 17:47:29 localhost su[2031]: (to liveuser) liveuser on none
Jun 23 17:47:29 localhost su[2031]: pam_unix(su:session): session opened fo...0)
Jun 23 17:56:29 localhost systemd[1]: Starting Cleanup of Temporary Directo.....
Jun 23 17:56:29 localhost systemd-tmpfiles[2106]: stat(/run/user/1000/gvfs) f...
Jun 23 17:56:29 localhost systemd[1]: Started Cleanup of Temporary Directories.
-----------------------------------------------------------------

The result look pretty much like in the other tests.
Personally I still do not know/guess what the bug could be.


> Unfortunately, we can't really block releases for this kind of bug if it
> only seems to affect one system, or a small number of systems

I guess we agree that this is a kernel bug. Then it is very likely that it will effect other users as well. As today nearly everybody tests on virtual instead of real hardware, the bugs discoverd with real hardware should be taken even more serious. I would expect Fedora to treat this as a blocker for the moment and at least give me some more help to debug the system. Later - if the bug can be narrowed down to something specific - it might be re-evaluated as non-blocking. But untill more info is available the bug should be treated as blocker because the risk is high.
Comment 10 Adam Williamson 2013-06-24 11:43:40 EDT
"I guess we agree that this is a kernel bug."

Yes.

"Then it is very likely that it will effect other users as well."

No. In fact it's *less* likely that kernel bugs will affect large numbers of users than other bugs. Kernel bugs are highly likely to be very hardware-specific: it's quite rare to find a serious kernel bug that is not tied quite tightly to a fairly specific range of hardware. I would expect it will affect anyone who has precisely the hardware configuration involved, but no-one else.

"As today nearly everybody tests on virtual instead of real hardware"

This is not actually true. I have F19 running full-time on both my primary machines, for instance. Many of our testers are using metal, not VMs (or, rather, both); you can't really test stuff like RAID and UEFI very well in a VM.

"I would expect Fedora to treat this as a blocker for the moment and at least give me some more help to debug the system"

I'm afraid it's not practical to operate that way; if you look through BZ you'll probably find a hundred bugs fairly similar to this (i.e., 'on this specific system, there's a major problem which doesn't seem to happen on other systems'). We can't treat them all as release blockers.

In practice, when there is a bug which affects a significant proportion of hardware, we find that we get several duplicate reports of it in short succession, which makes the fact fairly obvious. That has not happened in this case.

I'm afraid I can't help you debug beyond what I've already suggested; I hope the kernel team is able to take a look at this bug soon.
Comment 11 Adam Williamson 2013-06-24 12:14:44 EDT
If the time period before the system freezes is pretty consistent, this could be to do with the screen saver kicking in, or it could be something is running the CPU to 100% and it takes that long to overheat? Can you try disabling screen saver / screen lock in MATE preferences, and/or check 'top' or 'htop' and see if something is running the CPU to a high usage (and if you can, install and configure lm_sensors and take a look at the CPU temps). Thanks!
Comment 12 Adam Williamson 2013-06-24 12:16:07 EDT
Discussed at 2013-06-24 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-06-24/f19final-blocker-review-8.2013-06-24-16.00.log.txt . Rejected as a blocker: no-one present had seen reports of anything similar on any other hardware, and we have no other indications that this is affecting many users. It can be re-proposed if more data becomes available that suggests otherwise.
Comment 13 Jérôme Glisse 2013-06-24 13:09:38 EDT
Could you boot with radeon.modeset=0 and see if it helps. This will disable gpu acceleration.
Comment 14 schaefi 2013-06-24 17:24:10 EDT
(In reply to Adam Williamson from comment #11)
> If the time period before the system freezes is pretty consistent, this
> could be to do with the screen saver kicking in, or it could be something is
> running the CPU to 100% and it takes that long to overheat? Can you try
> disabling screen saver / screen lock in MATE preferences, and/or check 'top'
> or 'htop' and see if something is running the CPU to a high usage (and if
> you can, install and configure lm_sensors and take a look at the CPU temps).
> Thanks!

Here is what I did: 
I booted Live-MATE-Compiz-x86_64-19-Beta-1.iso from USB disabled the screensaver:
system -> preferences -> screensaver:
   - set 2h for time untill computer is regarded as idle
   - uncheck "Activate Screensaver when computer is idle"
   - uncheck "Lock Sceen after Computer is idle"

Then I installed all packages of "sensor" and logged in from a remote system (see comment 7). I run "top" and here are the results:

---------------------------------------------- after ca. 10 minutes
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND          
 1692 liveuser  20   0  500452  24692  10312 R 99.81 0.305  17:23.15 mate-notificati
 2113 root      20   0  119412   1620   1128 R 0.333 0.020   0:00.55 top
    1 root      20   0   51348   7560   2404 S 0.000 0.093   0:01.26 systemd
    2 root      20   0       0      0      0 S 0.000 0.000   0:00.00 kthreadd
    3 root      20   0       0      0      0 S 0.000 0.000   0:00.02 ksoftirqd/0
    5 root       0 -20       0      0      0 S 0.000 0.000   0:00.00 kworker/0:0H
--------------------------------------------------------------------

---------------------------------------------- after ca. 20 minutes
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND          
  606 root      20   0   19188   1188    936 S 0.332 0.015   0:00.07 irqbalance
 1202 root      20   0  250016  49688  23120 S 0.332 0.613   0:11.93 X
    1 root      20   0   51348   7560   2404 S 0.000 0.093   0:01.27 systemd
    2 root      20   0       0      0      0 S 0.000 0.000   0:00.00 kthreadd
    3 root      20   0       0      0      0 S 0.000 0.000   0:00.02 ksoftirqd/0
    5 root       0 -20       0      0      0 S 0.000 0.000   0:00.00 kworker/0:0H
    7 root       0 -20       0      0      0 S 0.000 0.000   0:00.00 kworker/u:0H
--------------------------------------------------------------------

---------------------------------------------- in the moment of freezing (after ca. 45 minutes)
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND          
 2808 root      20   0       0      0      0 S 0.997 0.000   0:00.04 kworker/u:2
    1 root      20   0   51348   7560   2404 S 0.000 0.093   0:01.27 systemd
    2 root      20   0       0      0      0 S 0.000 0.000   0:00.00 kthreadd
    3 root      20   0       0      0      0 S 0.000 0.000   0:00.03 ksoftirqd/0
    5 root       0 -20       0      0      0 S 0.000 0.000   0:00.00 kworker/0:0H
    7 root       0 -20       0      0      0 S 0.000 0.000   0:00.00 kworker/u:0H
--------------------------------------------------------------------



At the same time I was running sensor rempotely with a little script that I executed uder root:
while [ 1 ];
do
  sensors;
  sleep 2;
done

Here are the results:
------------------------------------- after ca. 10 minutes
[root@localhost ~]# sensors
acpitz-virtual-0
Adapter: Virtual device
temp1:        +27.8°C  (crit = +104.0°C)
temp2:        +29.8°C  (crit = +104.0°C)

radeon-pci-0100
Adapter: PCI adapter
temp1:        +47.0°C

coretemp-isa-0000
Adapter: ISA adapter
Physical id 0:  +55.0°C  (high = +93.0°C, crit = +103.0°C)
Core 0:         +51.0°C  (high = +93.0°C, crit = +103.0°C)
Core 1:         +55.0°C  (high = +93.0°C, crit = +103.0°C)
Core 2:         +48.0°C  (high = +93.0°C, crit = +103.0°C)
Core 3:         +48.0°C  (high = +93.0°C, crit = +103.0°C)
--------------------------------------------------------------------

---------------------------------------------- after ca. 20 minutes
[root@localhost ~]# sensors
acpitz-virtual-0
Adapter: Virtual device
temp1:        +27.8°C  (crit = +104.0°C)
temp2:        +29.8°C  (crit = +104.0°C)

radeon-pci-0100
Adapter: PCI adapter
temp1:        +45.0°C

coretemp-isa-0000
Adapter: ISA adapter
Physical id 0:  +42.0°C  (high = +93.0°C, crit = +103.0°C)
Core 0:         +41.0°C  (high = +93.0°C, crit = +103.0°C)
Core 1:         +40.0°C  (high = +93.0°C, crit = +103.0°C)
Core 2:         +41.0°C  (high = +93.0°C, crit = +103.0°C)
Core 3:         +42.0°C  (high = +93.0°C, crit = +103.0°C)
--------------------------------------------------------------------

---------------------------------------------- in the moment of freezing (after ca. 45 minutes)
acpitz-virtual-0
Adapter: Virtual device
temp1:        +27.8°C  (crit = +104.0°C)
temp2:        +29.8°C  (crit = +104.0°C)

radeon-pci-0100
Adapter: PCI adapter
temp1:        +45.5°C

coretemp-isa-0000
Adapter: ISA adapter
Physical id 0:  +41.0°C  (high = +93.0°C, crit = +103.0°C)
Core 0:         +41.0°C  (high = +93.0°C, crit = +103.0°C)
Core 1:         +40.0°C  (high = +93.0°C, crit = +103.0°C)
Core 2:         +41.0°C  (high = +93.0°C, crit = +103.0°C)
Core 3:         +41.0°C  (high = +93.0°C, crit = +103.0°C)
--------------------------------------------------------------------


Here are my conclusions/interpretations:
1. First it is remarkable that it took considerabel longer (ca. 45 min) to freeze than before (ca. 20 min). 
2. Moreover it is remarkable that in the first 15 minutes there is a process of liveuser called "mate-notificati" that consumes all the memory. Suddenly this process disappears after ca. 20 minutes. In the moment of freeze no special CPU-consumtion was going on. Could the process "mate-notificati" have something to do with the freeze?
3. Temperature does not seem to play a role. It rises slightly with the CPU-consumtion but is far from critical levels.

What do you think? and what could I do to further debug?
Comment 15 schaefi 2013-06-24 17:39:58 EDT
(In reply to Jerome Glisse from comment #13)
> Could you boot with radeon.modeset=0 and see if it helps. This will disable
> gpu acceleration.

Here is what I did: 
I booted Live-MATE-Compiz-x86_64-19-Beta-1.iso from USB and in the grub menu entered with "e" to edit the boot command. I added as last parameter:
radeon.modeset=0

The system then hang in the boot process with the following error message:

----------------------------------------------------------
....
[6.393686] [drm:radeon.init] *ERROR* No UMS support in radeon module!
....
Starting Terminate Plymouth Boot Screen ...
----------------------------------------------------------

I tried two mode timew with similar results. The error deferred a little bit each time.

I hope that information helps. If I can provide anything else please let me know.
I appreciate your help very much.
Comment 16 schaefi 2013-06-26 15:45:45 EDT
Here is my next try with the Fedora 19 release candidate 1:

I tried with Fedora-Live-MATE-Compiz-x86_64-19-1.iso (version as of 23.06.13) on HP Envy 23 from:
http://dl.fedoraproject.org/pub/alt/stage/19-RC2/Spins/x86_64/

After booting, to exclude other influences I switched off the screensaver and power management:
system -> preferences -> screensaver:
   - set 2h for time untill computer is regarded as idle
   - uncheck "Activate Screensaver when computer is idle"
   - uncheck "Lock Sceen after Computer is idle"
system -> preferences -> power management:
   - set to no power saving mode

Moreover I logged into the machine from a remote machine (see comment 7).

Results: 
Fedora 19 boots correctly. After 15min the kernel send a "kernel panic" and some errors to the console. The system then rebooted after 30 secs automatically.

This has been kept in the moment of "kernel panic" by "top":

----------------------------------------------------------------------
top - 15:29:27 up 18 min,  4 users,  load average: 0.06, 0.03, 0.05
Tasks: 190 total,   1 running, 189 sleeping,   0 stopped,   0 zombie
%Cpu(s):  1.1 us,  0.1 sy,  0.0 ni, 98.8 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem:   8108480 total,  1284852 used,  6823628 free,   123080 buffers
KiB Swap:  8142844 total,        0 used,  8142844 free,   758256 cached

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND    
 1507 liveuser  20   0  591852  21732  12612 S 2.992 0.268   0:00.40 nm-applet  
  763 root      20   0  238192  41944  19884 S 1.330 0.517   0:06.19 X          
 1938 root      20   0  119412   1612   1124 S 0.332 0.020   0:01.31 top        
    1 root      20   0   51364   7532   2388 S 0.000 0.093   0:01.18 systemd    
    2 root      20   0       0      0      0 S 0.000 0.000   0:00.00 kthreadd   
    3 root      20   0       0      0      0 S 0.000 0.000   0:00.02 ksoftirqd+ 
---------------------------------------------------------------------


And this has been kept in the moment of "kernel panic" by "journalctl -f"

------------------------------------------------------------------------
[root@localhost ~]# journalctl -f
-- Logs begin at Wed 2013-06-26 15:12:26 EDT. --
Jun 26 15:16:53 localhost userhelper[1953]: pam_unix(liveinst:auth): auth co...]
Jun 26 15:16:53 localhost userhelper[1953]: pam_unix(liveinst:auth): convers...d
Jun 26 15:16:53 localhost userhelper[1953]: pam_unix(liveinst:auth): auth co...]
Jun 26 15:18:16 localhost sshd[1960]: Connection closed by 192.168.1.52 [pr...h]
Jun 26 15:18:43 localhost sshd[1962]: Accepted password for root from 192.1...h2
Jun 26 15:18:43 localhost systemd-logind[622]: New session 2 of user root.
Jun 26 15:18:43 localhost sshd[1962]: pam_unix(sshd:session): session opene...0)
Jun 26 15:19:04 localhost sshd[2005]: Accepted password for root from 192.1...h2
Jun 26 15:19:04 localhost systemd-logind[622]: New session 3 of user root.
Jun 26 15:19:04 localhost sshd[2005]: pam_unix(sshd:session): session opene...0)
Jun 26 15:26:22 localhost systemd[1]: Starting Cleanup of Temporary Directo.....
Jun 26 15:26:22 localhost systemd-tmpfiles[2100]: stat(/run/user/1000/gvfs) f...
Jun 26 15:26:22 localhost systemd[1]: Started Cleanup of Temporary Directories.
----------------------------------------------------------------------------

What can I do? What shoud I do now?
Comment 17 Adam Williamson 2013-06-26 15:55:36 EDT
At this point I'm kind of at a loss, and I'd have to pass you over to the kernel team - sorry.
Comment 18 schaefi 2013-06-30 16:41:48 EDT
Hi guys,

thanks for your help so far!

On Thursday I discovered that I got a similar freeze under Windows 8. Yet, the standard UEFI hardware check provided by HP did not show any defects. On Firday I installed an advanced hardware check provided by HP and was able to get a freeze repeatetly. I am now waiting for the check and repacement/repair of the hardware by HP.

So please do not work on this bug untill I provide further information: I will be back with fedora as soon as I got the hardware back from HP.
Comment 19 schaefi 2013-07-24 16:15:23 EDT
Hi everybody,

I got the hardware back from the HP support. The support confirmed that there has been a hardware bug in the motherboard of the system.

The motherboard has been exchanged. I have now installed Fedora-19-Mate and everything works ok. 

Hence this has definetly not been a Fedora or Linux bug. This bug can be closed.

By the way: The support by HP has been very helpful allthough the bug appeared in Linux and this is offically not supported

Thanks for everybody for the support!!!

Hopefully the debug strategy helps to at least for other people to trace down their bugs.
Comment 20 schaefi 2013-07-24 16:20:22 EDT
*** Bug 948641 has been marked as a duplicate of this bug. ***
Comment 21 Adam Williamson 2013-09-23 13:52:14 EDT
Doesn't need commonbugs, if it was a hardware issue.

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