All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oliver Paukstadt <pstadt@sourcentral.org>
To: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: Carsten Otte <cotte@de.ibm.com>,
	kvm@vger.kernel.org, Martin Schwidefsky <schwidefsky@de.ibm.com>
Subject: Re: [RFC] kvm-s390: userspace snapshot
Date: Thu, 12 Jun 2008 07:39:08 +0200	[thread overview]
Message-ID: <1213249148.18768.15.camel@nerve> (raw)
In-Reply-To: <200806120014.36551.borntraeger@de.ibm.com>

On Thu, 2008-06-12 at 00:14 +0200, Christian Borntraeger wrote:

> Ok, I got an idea.
> Does that patch fix the handle_should_not_happen PANIC?
> 
Patch does not fit, because my code contains
 vcpu->arch.sie_block->gmsor = 0x000000000000;
so I changed this before I applied the patch.
The console patch you mentioned was applied too.

Now I am able to get the kernel running a little further:
[...]
PID hash table entries: 256 (order: 8, 2048 bytes)
console [hvc0] enabled
sclp vt220 tty driver: could not register vt220 - sclp_register returned
-5
list_del corruption. prev->next should be 00000000003d72a8, but was
0000000000000000
------------[ cut here ]------------
kernel BUG at lib/list_debug.c:67!
illegal operation: 0001 [#1] SMP 
Modules linked in:
CPU: 0 Not tainted 2.6.26-rc5-guest-20080609-01433-gdf4245d-dirty #2
Process swapper (pid: 0, task: 00000000003ada00, ksp: 00000000003e8000)
Krnl PSW : 0400000180000000 0000000000198c64 (list_del+0x50/0xb8)
           R:0 T:1 IO:0 EX:0 Key:0 M:0 W:0 P:0 AS:0 CC:0 PM:0 EA:3
Krnl GPRS: 0000000000000479 00000000003b2c28 0000000000000058
0000000000000001
           0000000000041246 0000000000000000 00000000003e8594
0000000000414000
           00000000003a2000 0000000000005000 00000000003d72a8
0000000000454418
           00000000003d72a8 00000000002bd820 0000000000198c60
00000000003e7dd8
Krnl Code: 0000000000198c54: e34040000004       lg      %r4,0(%r4)
           0000000000198c5a: c0e5fff542cf       brasl   %r14,411f8
           0000000000198c60: a7f40001           brc     15,198c62
          >0000000000198c64: e310c0000004       lg      %r1,0(%r12)
           0000000000198c6a: b904003c           lgr     %r3,%r12
           0000000000198c6e: c020000be1b9       larl    %r2,314fe0
           0000000000198c74: e3c010080020       cg      %r12,8(%r1)
           0000000000198c7a: a784000a           brc     8,198c8e
Call Trace:
([<0000000000198c60>] list_del+0x4c/0xb8)
 [<00000000001e9a72>] sclp_unregister+0x3a/0x5c
 [<0000000000401410>] __sclp_vt220_cleanup+0x98/0xb4
 [<0000000000401594>] __sclp_vt220_init+0x168/0x17c
 [<00000000004016e8>] sclp_vt220_con_init+0x3c/0x60
 [<00000000003fddd0>] console_init+0x48/0x60
 [<00000000003e8bd0>] start_kernel+0x37c/0x4c4
 [<0000000000012020>] _ehead+0x20/0x80
Last Breaking-Event-Address:
 [<0000000000000000>] 0x0
 <4>---[ end trace 31fd0ba7d8756001 ]---
Kernel panic - not syncing: Attempted to kill the idle task!

Looks like the sclp_vt220 stuff has a problem to unregister an
unitialized nonexistant console.

kuli.log reports some unknown diags and instructions, but I guess this
is the runtime feature detection:

launch_cpu_ipl: starting guest (ipl)
run_cpu: cpu 0: activated, running work...
handle_diag: cpu 0: unknown diagnose 9c at addr 3f136c, sending prog 1
enter_pgmcheck: cpu: 0: sending program check 1
handle_diag: cpu 0: unknown diagnose 260 at addr 3f1048, sending prog 1
enter_pgmcheck: cpu: 0: sending program check 1
handle_priv: cpu 0: unknown privileged instruction b216 at addr
400200180000000, sending prog 1
enter_pgmcheck: cpu: 0: sending program check 1
sclp_service_call: cpu 0: unknown sclp service call 0x780005, sccb
0x452000,addr 0x1e8780
sclp_service_call: cpu 0: unknown sclp service call 0x780005, sccb
0x452000,addr 0x1e8780
handle_waitpsw: cpu 0: entered disabled wait PSW at 1f312

Regards,
Oliver Paukstadt


  reply	other threads:[~2008-06-12  5:39 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-06 15:54 [RFC] kvm-s390: userspace snapshot Carsten Otte
2008-06-10  5:55 ` Oliver Paukstadt
2008-06-11 14:35   ` Christian Borntraeger
2008-06-11 20:53     ` Oliver Paukstadt
2008-06-11 22:14       ` Christian Borntraeger
2008-06-12  5:39         ` Oliver Paukstadt [this message]
2008-06-12 14:14           ` Christian Borntraeger
2008-06-12 19:56             ` Oliver Paukstadt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1213249148.18768.15.camel@nerve \
    --to=pstadt@sourcentral.org \
    --cc=borntraeger@de.ibm.com \
    --cc=cotte@de.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=schwidefsky@de.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.