https://bugzilla.novell.com/show_bug.cgi?id=799475
https://bugzilla.novell.com/show_bug.cgi?id=799475#c3
--- Comment #3 from Anton Samsonov 2013-01-20 17:00:57 UTC ---
There has been a development. Today it didn't boot even with “nohz=off
highres=off” options, resulting in 1 crash report followed by deep freeze (see
trace03.png in new attachments). Although I could not scroll back to see the
first lines, this looked very similar to the situation I was experiencing
originally until applying updates yesterday, though the numbers after function
names were different from the very first text transcript posted here. The other
difference was the falling into deep freeze instead of entering single-user
mode.
I retried just for the case to check whether I could have misspelled the
options. The outcome was a new story: after quickly displaying a couple of
crash reports, it stuck for a while with the message about “fsck /boot”
(trace04.png), then after 30 seconds it displayed another crash report, and
after 23 more seconds it ultimately halted on watchdog timer (trace05.png).
The most strange thing here is that fsck said that /boot (labeled “LinuxBoot”)
partition had 130'560 files, while in reality it has 361 files and 11 folders.
I must also add that in previous tryouts, when a single-user prompt was
available but incapable to shutdown, and I used REISUB magic to force
rebooting, there were new messages about fsck and mount after sending SIGTERM,
as well as then after SIGKILL.
Booting with the complete set of failsafe options still worked though, so I
then started to check other configurations. Trying to boot with “powersaved=off
nohz=off highres=off processor.max_cstate=1” resulted in yet unseen crash
referring to CPU cache tuning, but still caused by some ext4 handling routines
(see trace06.png). Was finally able to boot with
apm=off edd=off powersaved=off nohz=off highres=off processor.max_cstate=1 nomodeset
or something like this, don't remember exactly which one of “edd” or
“nomodeset” was excluded.
At this moment I could start to consider the possibility of a real hardware
failure, if only openSUSE was the only one operating system on this computer.
But my primary OS is Windows 7, and it boots just fine and [almost] never
screws the fake-RAID on shutdown, and runs demanding modern videogames, as well
as CPU-, GPU- and RAM-intensive BOINC computations that are cross-validated
against other nodes. Of course, it's not a strong proof, but I'm more inclined
towards a software bug, taking into account that the situation worsened each
time after updating openSUSE.
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.