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

[Gabriel Southern <gabriel.southern@gmail.com>]

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 <blauwirbel@gmail.com> wrote:
> On 5/5/09, Gabriel Southern <gabriel.southern@gmail.com> 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
>>
>>
>