*SOLVED* sparc64 SunBlade 1000: irrecoverable deferred error trap
Hello, this thread is related to the thread http://forum.openvz.org/index.php?t=tree&goto=10057& #msg_10057. It is separated, because of that thread became too big and its subject changed dramatically. So, the current problem is that OpenVZ 028test015 kernl crashes with the following error: kernel panic -- not syncing, irrecoverable deferred error trap Look at this thread: http://mailgate.supereva.com/linux/linux.debian.ports.sparc/ msg18150.html Seems, that 2.6.18 vanilla/debian kernel has the same problem. zszhu, can you please check it by installing 2.6.18 kernel on your node and if it crashes too, please install 2.6.19/2.6.20 and check, do they work properly. The thing is that we need to find out is this problem fixed and if it is, in which kernel it is fixed. With this knowledge in hand we'll be able to back-port required patch. Thanks, Vasily
Re: sparc64 SunBlade 1000: irrecoverable deferred error trap
Perhaps this patch will help you: http://www.spinics.net/lists/sparclinux/msg00681.html Please try and report.
After download http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.18.tar .bz2 kernel, patch this http://download.openvz.org/kernel/devel/028test010.1/patches /patch-ovz028test010.1-combined.gz and http://www.spinics.net/lists/sparclinux/msg00681.html, make-kpkg, install header and image, reboot, woo, no kernel panic, great. but it showed mount error: mount: mounting /dev/sda1 on /root failed : no such device ........... all FSs failed to be mounted. I am going to re-do the whole process and pay attentation of the FS confiure setup. Do you have any suggestions on this issue? Thanks Sam
OK I will file a bug so openvz kernel will include that patch. I suggest to find out what SCSI controller do you have, and set the appropriate kernel config entries to =y (i.e. the driver should be built into the kernel). Alternative approach is building the driver as a module and creating an initrd image. This is more complex, so the first way is preferrable.
initrd is required anyway due to udev :/ so building as modules can be better on ubuntu.
dev wrote on Tue, 20 February 2007 19:35 initrd is required anyway due to udev :/ so building as modules can be better on ubuntu. Perhaps it is required in case of Debian/Ubunty, but generally it's a false assumption -- my Gentoo notebook runs udevd and boots fine without initrd.