Re: [Qemu-devel] SPARC kernel oops with logging

[Blue Swirl]

On 5/6/09, Gabriel Southern <address@hidden> 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 <address@hidden> wrote:
>  > On 5/5/09, Gabriel Southern <address@hidden> 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: <scsi_device_lookup_by_target+0x44/0x74 [scsi_mod]>
>  >
>  > 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 <address@hidden>
---
 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