I tried your proposals, but it helped only to solve a
part of the problems:
By either adding "nosegfixup" to the kernel command line
and/or renaming /lib/tls, I could get rid of the segfaults which
totally prevented the 2.6.7 kernel from booting in Dom0 (Csets 1.1158+).
So, in this case, it helped a lot ;-)
However, it did not remove the segfaults generated by
kudzu and hwclock, which were introduced around
It seems that something was changed concerning how
you directly access hardware in xen(-linux) starting
around CSet 1.1154, because both kudzu and hwclock
directly address hardware (..?).
If you need any further debugging for both issues (I assume
"nosegfixup" is only a workaround and not a real bugfix)
from me, just drop me an email and tell me what debug
options I have to activate ;-)
Thx + have a nice weekend to all,
Sven...switching over from computer live to real live....
*********** REPLY SEPARATOR ***********
On 07.08.2004 at 00:22 Ian Pratt wrote:
>> It seems that newer changesets broke booting a Dom0 with kernel 2.6.7.
>> At least with Fedora Core 2, which I am using.
>> CSet 1.1153 was the last one working correctly for me.
>> CSet 1.1154 introduced segfaults during bootprocess with kudzu and
>> but the kernel was still able to finish the bootprocess.
>> (I did not test any CSets between 1.1153 and 1.1154).
>> Cset 1.1156: Like 1.1154
>> CSet 1.1158 Additonal segfaults during Dom0 boot with
>> /sbin/devlabel, initlog and mounting file systems.
>> The kernel is no longer able to boot Dom0; the boot process
>Thanks for the report.
>Please can you try 'mv /lib/tls /lib/tlsXXX'. If that helps,
>please can you put it back and try adding 'nosegfixup' on the
>kernel command line.
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
Xen-devel mailing list