Hello Hackers
booting l4linux stops with:
KDB: thread_schedule: param_word bits 16-19 must be 0. Fix your bindings!
My grub menu contains:
+-------------------------------------------------------------------[0]---+ | 0: kernel (hd0,2)/denny/Dresden/rmgr -sigma0 | | 1: modaddr 0x02000000 | | 2: module (hd0,2)/denny/Dresden/main -nokdb -nowait -comspeed 9600 -com| | 3: module (hd0,2)/denny/Dresden/sigma0 | | 4: module (hd0,2)/denny/Dresden/glinux root=/dev/hda3 | | 5: module (hd0,2)/denny/Dresden/hello
umm, pasting from the remote serial console.. line 2 ends in "-comport 1"
OK let's reboot the big system & paste the whole thing. BTW your hackked grub is now sitting in the mbr of (hd0) AND it WORKS ! 8-)
title failsafe chavin:/boot/grub # less menu.lst # Modified by YaST2. Last modification on Tue Aug 26 06:06:59 2003
color white/blue black/light-gray # default 0 # timeout 8 serial --unit=0 --speed=9600 --word=8 --parity=no --stop=1 #terminal --timeout=10 serial console terminal serial console
title SuSE Linux 8.2 Kernel 2.4.20 kernel (hd0,2)/boot/vmlinuz root=/dev/hda3 vga=0x31a splash=silent showopts initrd (hd0,2)/boot/initrd
title (Remote) SuSE Linux 8.2 Kernel 2.4.20 kernel (hd0,2)/boot/vmlinuz root=/dev/hda3 console=tty0 console=ttyS0,9600n8 initrd (hd0,2)/boot/initrd
title Debian Linux testing/unstable Kernel 2.2.20 kernel (hd0,1)/boot/vmlinuz-2.2.20 root=/dev/hda2 splash=silent vga=0x31a
title (Remote) Debian Linux testing/unstable Kernel 2.2.20 kernel (hd0,1)/boot/vmlinuz-2.2.20 root=/dev/hda2 console=tty0 console=ttyS0,9600n8
title floppy root (fd0) chainloader +1
title failsafe kernel (hd0,2)/boot/vmlinuz.shipped root=/dev/hda3 showopts ide=nodma apm=of f acpi=off vga=normal nosmp noapic maxcpus=0 3 initrd (hd0,2)/boot/initrd.shipped
title L4Linux -+- Hello World kernel (hd0,2)/denny/Dresden/rmgr -sigma0 modaddr 0x02000000 module (hd0,2)/denny/Dresden/main -nokdb -nowait -comspeed 9600 -comport 1 module (hd0,2)/denny/Dresden/sigma0 module (hd0,2)/denny/Dresden/glinux root=/dev/hda3 module (hd0,2)/denny/Dresden/hello
title L4Linux-------------------><8------------------------
Apols I have not gone the netboot road, as "all"! my boxes are totally different there are too many risks for cross compiling, I compile for the OS and box where it loads from.
Host OS is SuSE8.2 with linux22 compiled under 2.95.3 and l4 + the rest under 3.2 (i.e. reverted), all compiles terminated OK, all libraries & dependencies found to the best of my ability.
The same error has stopped me for some 24 hours; I have been round the houses tidying up all I can find here so I await your advice with eagerness.
In the meantime, to get a bit nearer, I have the Debian system ready for a similar assault when I have my energy restored...
TIA David Denny
On Wed, 27 Aug 2003 21:58:22 +0100 David Denny (DD) wrote:
DD> booting l4linux stops with: DD> DD> KDB: thread_schedule: param_word bits 16-19 must be 0. Fix your bindings!
This is caused by a change in the thread-schedule binding. Formerly the binding didn't correctly set bits 16-19 in the param word to zero as demanded by the L4 spec. and the kernel now no longer tolerates incorrect parameters.
The bindings have already been fixed in CVS. However, this requires that you check out the new bindings (l4/pkg/l4sys) and recompile/relink the programs which used the old bindings.
Please look at the kernel debugger output to see which task inhibits this behaviour to see which package you need to recompile.
If you have trouble figuring out which task is the culprit, then send in the last lines of screen output at the time of the stop.
Regards, -Udo.
On Wed Aug 27, 2003 at 23:42:51 +0200, Udo Steinberg wrote:
The bindings have already been fixed in CVS. However, this requires that
Remote CVS has not been updated yet due to other changes. We hope to get this working by tomorrow or Friday. I can supply patches if there's immediate interest.
Adam
On Wed, Aug 27, 2003 at 11:54:25PM +0200, Adam Lackorzynski wrote:
On Wed Aug 27, 2003 at 23:42:51 +0200, Udo Steinberg wrote:
The bindings have already been fixed in CVS. However, this requires that
Remote CVS has not been updated yet due to other changes. We hope to get this working by tomorrow or Friday. I can supply patches if there's immediate interest.
NP Adam, I can wait.. I'll also check Udo's suggestion & prepare my other platform then I'll be ready when CVS is fixed (I hope)
Kind regards all David
l4-hackers@os.inf.tu-dresden.de