From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M1UCE-0008Na-1A for qemu-devel@nongnu.org; Tue, 05 May 2009 19:37:10 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M1UC9-0008NO-E5 for qemu-devel@nongnu.org; Tue, 05 May 2009 19:37:09 -0400 Received: from [199.232.76.173] (port=36484 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M1UC9-0008NL-Aw for qemu-devel@nongnu.org; Tue, 05 May 2009 19:37:05 -0400 Received: from mail-qy0-f111.google.com ([209.85.221.111]:34817) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1M1UC8-00058F-V9 for qemu-devel@nongnu.org; Tue, 05 May 2009 19:37:05 -0400 Received: by qyk9 with SMTP id 9so8632111qyk.4 for ; Tue, 05 May 2009 16:37:04 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <3c2bf46d0905041456j66ab4d92m633ca366afac8f61@mail.gmail.com> Date: Tue, 5 May 2009 16:37:03 -0700 Message-ID: <3c2bf46d0905051637n519c4637u2d1e77c1049a1df3@mail.gmail.com> Subject: Re: [Qemu-devel] SPARC kernel oops with logging From: Gabriel Southern Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: qemu-devel@nongnu.org I was logging the in_asm and out_asm, but I'm not sure what part of the log corresponds to when the kernel oops occurs. If anyone has any suggestions on what I should look for I will try to post it to the mailing list. I think that the problem is related to logging in_asm. I tried various other combinations of logging options, and the VM runs fine for any logging option except in_asm (and it also fails with only in_asm logging). If anyone else wants to look at the problem, I think it is easy to duplicate. In order to rule out problems with what I am working on, I downloaded the debian_etch_sparc_small.qcow.gz image from here: http://people.debian.org/~aurel32/qemu/sparc/ and I compiled the latest qemu from the git repository. When I included the -d in_asm option the kernel had the same error every time it boots. On Tue, May 5, 2009 at 8:29 AM, Blue Swirl wrote: > On 5/5/09, Gabriel Southern wrote: >> Hi, >> >> =A0When I run qemu-system-sparc with -d in_asm,out_asm the Linux kernel >> =A0crashes when it tries to initialize the hard drive. =A0The same hard >> =A0drive image boots perfectly if I do not include the logging options. >> =A0The error messages that I receive are shown below. =A0I'm wondering i= f >> =A0the logging is causing some type of acknowledgment to be delayed and >> =A0this is causing a SCSI operation to timeout. =A0I've also attached lo= g >> =A0of the complete console output in case anyone would find it useful. >> =A0If anyone has ideas about the cause or a possible solution please let >> =A0me know. > > The lines in qemu.log near the crash could be interesting too. > >> =A0%G: ffffffff 04000fe0 =A000000000 044000e0 =A0f0115c18 49ff53a9 =A0f3= 274000 00000000 > > %g0 not equal to zero? > >> =A0%O: f3249400 00000000 =A0f3275a20 f3249484 =A0f3249484 0000000c =A0f3= 275980 fe62f204 >> =A0RPC: > > I guess this means that the call to fe62f000 came from fe62f204, which > is in the same page. Strange. > >> =A0%L: 040000e0 fe6362e8 =A0fe6363cc 00000004 =A000000008 00000000 =A000= 000000 0000000a >> =A0%I: f3249400 00000000 =A000000000 00000000 =A000000000 f9828000 =A0f3= 2759e8 fe635528 >> =A0Caller[fe635528]: scsi_probe_and_add_lun+0x40/0x9f4 [scsi_mod] >> =A0Caller[fe63641c]: __scsi_scan_target+0xa8/0x5a8 [scsi_mod] >> =A0Caller[fe63696c]: scsi_scan_channel+0x50/0x74 [scsi_mod] >> =A0Caller[fe636a1c]: scsi_scan_host_selected+0x8c/0xd8 [scsi_mod] >> =A0Caller[fe61ec80]: esp_sbus_probe+0x9f4/0xae8 [esp] >> =A0Caller[f001ba48]: of_device_probe+0x58/0x74 >> =A0Caller[f01176b4]: driver_probe_device+0x60/0xb8 >> =A0Caller[f0117814]: __driver_attach+0x70/0xc4 >> =A0Caller[f0116f9c]: bus_for_each_dev+0x40/0x74 >> =A0Caller[f0116bec]: bus_add_driver+0x6c/0x134 >> =A0Caller[f004c86c]: sys_init_module+0x1610/0x1778 >> =A0Caller[f0011634]: syscall_is_too_hard+0x3c/0x40 >> =A0Caller[000133b4]: 0x133bc >> >> >