There seems to be some strange things going on...
Normally, the first thing I do after cloning a new xeno-unstable
distribution is to change the drivers for my ethercards from
non-module to module config (Because when I boot a
normal, non-xen kernel on the same machine, it always
orders my cards differently than the xen kernel. With
modules and modprobe.conf, I can assign it always to
eth0, eth1, etc. like I want it to be).
If I just do (in an empty dir):
1.) bk clone
2.) make world
3.) make linux26
4.) make install (it seems that this step repeats compiling the 2.4. kernels,
why ?)
and reboot, I can _not_ see any problems with kudzu and hwclock during boot
process,
even with the newest changesets (and "nosegfixup" boot option is set !).
Only when shutting down the machine (via "halt"), I can see a "syncing hardware
clock to system time [failed]", but no (visible) segfault.
However, if I don't set the "nosegfixup" boot option, the boot process will
freeze
with segfaults of devlabel, initlog and mounting filesystems, but even in this
case
no segfaults occur with kudzu and hwclock (they get called earlier in the boot
process
before booting freezes).
Then I do the following to configure my ethercard drivers (100/1000 MBits)
as modules:
1.) cd linux-2.6.7-xen0
2.) make menuconfig ARCH=xen
3.) change the needed ethercard drivers from [*] to [M] (and really nothing
else)
4.) save the new config when asked when I exit
5.) make clean ARCH=xen
6.) make ARCH=xen
7.) make modules_install ARCH=xen
8.) make install ARCH=xen
9.) reboot
After rebooting now I see all errors I have reported before:
segfaults with kudzu and hwclock (even with "nosegfixup" boot option set)
and if I dont set the "nosegfixup" boot option, the boot process does not finish
and freezes like before.
So after changing the ethercard drivers from compiled in to module,
hwclock and kudzu don't work correctly any more ??
I also think, the Dom0 2.6.7 kenrnel is normally using no modules at all ?
Am I doing something wrong here ? Does the top directory Makefile
use another config (not the .config in the kernel source directory) ?
If my procedure of changing the kernel configs is wrong, what is
the correct one ?
TIA,
Sven
*********** REPLY SEPARATOR ***********
On 08.08.2004 at 18:56 Keir Fraser wrote:
>I am unable to reproduce any of these problems booting vanilla RedHat
>9 as DOM0. This is odd as I might expect to at least see the
>hwclock/kudzu problem...
>
>I'll install vanilla FC2 tomorrow and see what happens.
>
> -- Keir
>
>>
>> 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
>> CSet 1.1154.
>> 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
>> >hwclock,
>> >> 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
>> >> freezes.
>> >
>> >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.
>> >
>> >Thanks,
>> >Ian
>>
>>
>>
>>
>>
>> -------------------------------------------------------
>> 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
>> Xen-devel@xxxxxxxxxxxxxxxxxxxxx
>> https://lists.sourceforge.net/lists/listinfo/xen-devel
-------------------------------------------------------
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
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel
|
Home