From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M1mIl-0002TI-Rs for qemu-devel@nongnu.org; Wed, 06 May 2009 14:57:07 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M1mIl-0002T1-9m for qemu-devel@nongnu.org; Wed, 06 May 2009 14:57:07 -0400 Received: from [199.232.76.173] (port=47228 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M1mIl-0002Ss-2U for qemu-devel@nongnu.org; Wed, 06 May 2009 14:57:07 -0400 Received: from fg-out-1718.google.com ([72.14.220.153]:33108) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1M1mIk-0002oi-88 for qemu-devel@nongnu.org; Wed, 06 May 2009 14:57:06 -0400 Received: by fg-out-1718.google.com with SMTP id l27so1283218fgb.8 for ; Wed, 06 May 2009 11:57:04 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <3c2bf46d0905051637n519c4637u2d1e77c1049a1df3@mail.gmail.com> References: <3c2bf46d0905041456j66ab4d92m633ca366afac8f61@mail.gmail.com> <3c2bf46d0905051637n519c4637u2d1e77c1049a1df3@mail.gmail.com> Date: Wed, 6 May 2009 21:57:04 +0300 Message-ID: Subject: Re: [Qemu-devel] SPARC kernel oops with logging From: Blue Swirl Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gabriel Southern Cc: qemu-devel@nongnu.org On 5/6/09, Gabriel Southern wrote: > 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, > >> > >> When I run qemu-system-sparc with -d in_asm,out_asm the Linux kernel > >> crashes when it tries to initialize the hard drive. The same hard > >> drive image boots perfectly if I do not include the logging options. > >> The error messages that I receive are shown below. I'm wondering if > >> the logging is causing some type of acknowledgment to be delayed and > >> this is causing a SCSI operation to timeout. I've also attached log > >> of the complete console output in case anyone would find it useful. > >> If anyone has ideas about the cause or a possible solution please let > >> me know. > > > > The lines in qemu.log near the crash could be interesting too. > > > >> %G: ffffffff 04000fe0 00000000 044000e0 f0115c18 49ff53a9 f3274000 00000000 > > > > %g0 not equal to zero? > > > >> %O: f3249400 00000000 f3275a20 f3249484 f3249484 0000000c f3275980 fe62f204 > >> RPC: > > > > I guess this means that the call to fe62f000 came from fe62f204, which > > is in the same page. Strange. > > > >> %L: 040000e0 fe6362e8 fe6363cc 00000004 00000008 00000000 00000000 0000000a > >> %I: f3249400 00000000 00000000 00000000 00000000 f9828000 f32759e8 fe635528 > >> Caller[fe635528]: scsi_probe_and_add_lun+0x40/0x9f4 [scsi_mod] > >> Caller[fe63641c]: __scsi_scan_target+0xa8/0x5a8 [scsi_mod] > >> Caller[fe63696c]: scsi_scan_channel+0x50/0x74 [scsi_mod] > >> Caller[fe636a1c]: scsi_scan_host_selected+0x8c/0xd8 [scsi_mod] > >> Caller[fe61ec80]: esp_sbus_probe+0x9f4/0xae8 [esp] > >> Caller[f001ba48]: of_device_probe+0x58/0x74 > >> Caller[f01176b4]: driver_probe_device+0x60/0xb8 > >> Caller[f0117814]: __driver_attach+0x70/0xc4 > >> Caller[f0116f9c]: bus_for_each_dev+0x40/0x74 > >> Caller[f0116bec]: bus_add_driver+0x6c/0x134 > >> Caller[f004c86c]: sys_init_module+0x1610/0x1778 > >> Caller[f0011634]: syscall_is_too_hard+0x3c/0x40 > >> Caller[000133b4]: 0x133bc > >> > >> > > > I think this patch should fix the problem. Sparc disassembler wants to check previous addresses for some stuff and this may actually cause faults if the address is close to page start, because of the function used for the memory access. Signed-off-by: Blue Swirl --- disas.c | 5 +---- 1 files changed, 1 insertions(+), 4 deletions(-) diff --git a/disas.c b/disas.c index 37f7433..6ed31e3 100644 --- a/disas.c +++ b/disas.c @@ -33,10 +33,7 @@ target_read_memory (bfd_vma memaddr, int length, struct disassemble_info *info) { - int i; - for(i = 0; i < length; i++) { - myaddr[i] = ldub_code(memaddr + i); - } + cpu_memory_rw_debug(cpu_single_env, memaddr, myaddr, length, 0); return 0; } -- 1.6.2.4