Post, Mark K writes: > > >From the VM console, you can start a CP instruction trace. That will give > you some idea if anything is happening at all. One thing that might make > your debugging a little more bearable is to write your new kernel out to a > different minidisk, and IPL from that. Then, you don't need to fiddle > around with zipl constantly, just re-IPL from your "old sysres" volume.
Thanks for your help...that let me figure out that it was actually looping on a spinlock. The problem was that the debugging code I inserted in the "number()" function that is called, by, e.g. printk, used the GCC __builtin_frame_address(0) to get, I thought, the current stack ptr. Unfortunately, that builtin just returns %r11, which is pretty useless, and caused my debugging code to always "BUG()", which happens to call printk, hence the spinlock deadlock. Anyway, I rewrote my debugging code in asm and use %r15 as the stack frame ptr, as God intended, and now things are better. However, I am "stopping" in my debug code by executing an instruction defined as ".long 0x00000000", which is what BUG() does. Unfortunately, that seems to cause a trap, and the trap handler tries to do a printk, so by the time I can look at things, the registers I'm interested in are all gone. So...a long-winded explanation to get to the question...How can I halt the VM guest from some embedded asm code without causing a trap? For instance, I could pull the asm halt code out of cpcmd, if I could figure out what diagnose instruction to use, but I can't find any docs for diagnose (other than its model specific, which isn't too helpful). Thanks for any more help... -- Rick > -----Original Message----- > From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Rick > Kissel > Sent: Thursday, August 12, 2004 9:23 AM > To: [EMAIL PROTECTED] > Subject: Can't reboot rebuilt RHEL3 U3 on s390 VM > > > I'm debugging a stack overflow and I added some debugging code to vsprinf.c > in the kernel source tree (under /usr/src/linux-2.4.21-17.EL) on my RHEL3 U3 > beta VM guest and did: > > make mrproper > cp configs/kernel-2.4.21-s390.config .config > make oldconfig dep image install > > When I rebooted (i.e. ipl'd b91) my VM guest, the rebuilt kernel did not > start, instead I got the original kernel I had started with. I checked > /etc/zipl.conf and saw that rebuilding the kernel added a stanza for the new > kernel ([2.4.21-17.ELcus]) but it hadn't changed the "default=" target, > which was still set to "linux". I changed that to be the new stanza that > was added and re-ran zipl. This seemed to go OK, but then when I rebooted, > the guest just "hung". That is, after the "ipl b91", nothing happened on > the console. I don't really know VM well enough to tell if it was looping, > or waiting for something, or what. If I boot another image, mount the b91 > disk, and put zipl.conf back the way it was, run zipl again on that disk, > and then reboot, the original linux image comes up fine. Can you give me > any pointers on what I'm doing wrong or what I might try? > > -- Thanks, Rick > > P.S. - Here's my zipl.conf (after the rebuild and after my edit to set > default): > > [defaultboot] > target = /boot > default = 2.4.21-0809.ELc > > [2.4.21-0809.ELc] > target=/boot > image=/boot/vmlinuz-2.4.21-0809.ELcustom > ramdisk=/boot/initrd-2.4.21-0809.ELcustom.img > parameters="root=LABEL=/" > > [linux] > target=/boot > image=/boot/vmlinuz-2.4.21-17.EL > ramdisk=/boot/initrd-2.4.21-17.EL.img > parameters="root=LABEL=/" > > And here's my /boot after the rebuild (and install): > > total 11364 > drwxr-xr-x 3 root root 4096 Aug 9 15:42 . > drwxr-xr-x 24 root root 4096 Aug 10 08:40 .. > lrwxrwxrwx 1 root root 23 Aug 9 15:42 System.map -> > System.map-2.4.21-17.EL > -rw-r--r-- 1 root root 271377 Aug 9 15:29 > System.map-2.4.21-0809.ELcustom > -rw-r--r-- 1 root root 273459 Jul 8 19:39 > System.map-2.4.21-17.EL > -rw------- 1 root root 66048 Aug 10 08:19 bootmap > -rw-r--r-- 1 root root 48808 Jul 8 19:39 config-2.4.21-17.EL > drwxr-xr-x 2 root root 4096 Aug 2 13:49 grub > -rw-r--r-- 1 root root 681914 Aug 9 15:29 > initrd-2.4.21-0809.ELcustom.img > -rw-r--r-- 1 root root 681494 Aug 2 13:52 > initrd-2.4.21-17.EL.img > -rw-r--r-- 1 root root 331 Aug 2 13:52 kernel.h > -rw-r--r-- 1 root root 23108 Sep 11 2003 message > -rw-r--r-- 1 root root 21282 Sep 11 2003 message.ja > -rw-r--r-- 1 root root 1200 Jun 24 13:11 tape0 > -rwxr-xr-x 1 root root 3179824 Jul 8 19:40 vmlinux-2.4.21-17.EL > lrwxrwxrwx 1 root root 28 Aug 9 15:29 vmlinuz -> > vmlinuz-2.4.21-0809.ELcustom > -rw-r--r-- 1 root root 3153152 Aug 9 15:29 > vmlinuz-2.4.21-0809.ELcustom > -rwxr-xr-x 1 root root 3161344 Jul 8 19:39 vmlinuz-2.4.21-17.EL > > ---------------------------------------------------------------------- > For LINUX-390 subscribe / signoff / archive access instructions, send email > to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit > http://www.marist.edu/htbin/wlvindex?LINUX-390 > > ---------------------------------------------------------------------- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit > http://www.marist.edu/htbin/wlvindex?LINUX-390 > ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
