[Aboriginal] Failures with qemu-1.6

Tue Oct 15 20:52:52 PDT 2013

On 10/01/2013 06:34:40 AM, Patrick Lauer wrote:
> Testing 1.2.5 on amd64 (Gentoo) with qemu 1.6.0 the mips64, sh4,  
> armv6l
> and sparc targets fail to pass the smoketest.

mips64: there's more than one type of 64 bit mips, and the one I  
implemented was obsolete and has bit-rotted badly. I never got it 100%  
working in the first place because when i got the kernel booted, it was  
broken:

   http://landley.net/notes-2011.html#17-09-2011

Once upon a time there were 64 bit mips workstations something like a  
decade ago, and the company making them stopped doing it. (Might have  
been silicon graphics? I don't remember.) More recently they've  
reintroduced 64 bit support to mips but did it in a different way, and  
I haven't done the research to see how to configure that. (It's a bit  
like the mips-r4k vs "mips32" thing. the old r4k stuff is limited to  
256 megs physical memory, the mips32 stuff isn't, but I haven't done  
the research on a kernel config and board emulation and so on. So many  
weird little variants of each architecture...)

Fixing mips64 again is on my todo list, but what I really want to do is  
switch it to the _current_ variant (one people might actually _use_)  
and I don't have an example of that. Need to dig through debian and  
such to see if they have an image I can get qemu to run...

sh4: Two problems:

1) the serial port's broken in qemu, my patch for that _finally_ went  
upstream but wasn't in 1.6.0. (It might be in 1.6.1?)

http://lists.nongnu.org/archive/html/qemu-devel/2013-10/msg00628.html

2) The board qemu emulates for sh4 only has 64 megs physical memory  
(hardwired), and modern gcc isn't particularly happy with less than 256  
megs. It can just about build hello world and thus pass the smoketest,  
but if you try to do the linux from scratch build it won't make it very  
far. (I need to hack up qemu and the kernel to add another 196 megs of  
physical memory via the discontigmem stuff. It's on the todo list...)

Until then, even when it's working it isn't very useful.

armv6l: um, works for me here? Ah, I have 1.5.1 in the $PATH. So the  
system image is working fine, this sounds like a qemu problem. I'll add  
it to the heap...

> In a way I'm not really surprised how fragile things are, but ...  
> sigh :)

Everything breaks every release. Alas, you're seeing targets I didn't  
put enough effort into before release. (Sparc32 isn't properly  
supported by uClibc, the long term fix is to switch to musl and make  
sparc work properly there. I only got it working for dynamic linking at  
_all_ fairly recently, and then it broke again...) sh4 isn't quite  
properly supported by qemu (insufficient memory in board emulation).  
armv6l is redundant for my purposes (armv5l is the pentium of arm,  
armv6l mostly added SMP support which qemu doesn't emulate and which  
doesn't affect userspace anyway; armv7l is the next big step), and  
mips64 never worked right in the first place and needs a redo.

But you're right, I should fix all of 'em. I've gotten a bit lax  
lately, so much else to do...

> armv6l seems to have a problem with the virtual sound hardware in  
> qemu:
> 
> system-image-armv6l $ ./run-emulator.sh
> Uncompressing Linux... done, booting the kernel.
> ALSA lib
> /chroot/build/portage/media-libs/alsa-lib-1.0.27.2/work/alsa-lib-1.0.27.2/src/pcm/pcm.c:7843:(snd_pcm_recover)
> underrun occurred
> 
> sparc seems to have a problem in the compiler:
> 
> (sparc:1) /home # df
> Filesystem      1K-blocks       Used Available Use% Mounted on
> /home               54032          0     54032   0% /home
> /tmp                54032          0     54032   0% /tmp
> dev                 53984          0     53984   0% /dev
> /dev/root           28416      28416         0  100% /
> (sparc:1) /home # gcc -s /usr/src/thread-hello2.c -lpthread -o  
> /tmp/hello
> /tmp/hello
> exit
> (sparc:1) /home # /tmp/hello
> 
> /tmp/hello: symbol '__gcc_personality_v0': can't handle reloc type  
> 0x17
> (sparc:1) /home # exit

I think it's actually in libc, but yeah. I had it working at one point.  
Grr...

> mips64 seems to have invalid executables:
> 
> 9pnet: Installing 9P2000 support
> drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
> VFS: Mounted root (squashfs filesystem) readonly on device 3:0.
> Freeing YAMON memory: 956k freed
> Freeing unused kernel memory: 172K (ffffffff80475000 -  
> ffffffff804a0000)
> Kernel panic - not syncing: Attempted to kill init!  
> exitcode=0x0000000a

I need to bisect and see which package upgrade broke it. (Either the  
kernel .config or uClibc, almost certainly...)

> sh4 kernel-oopses at boot:
> 
> ------------[ cut here ]------------
> WARNING: at 8c144a00 [verbose debug info unavailable]
> 
> CPU: 0 PID: 1 Comm: swapper Not tainted 3.11.0 #1

Warning? Warning _what_? What's the error message?

> task: 8fc2c000 ti: 8fc2e000 task.ti: 8fc2e000
> PC  : 8c144a00 SP  : 8fc2fe64 SR  : 40008000 TEA : 00000000
> R0  : 00000034 R1  : 00000000 R2  : 40008000 R3  : 00000000
> R4  : 00000000 R5  : 8c278e04 R6  : 00000002 R7  : 00001aac
> R8  : 8c255d50 R9  : 8c24b280 R10 : 8fd5c480 R11 : 8c143bf4
> R12 : 8fd5c4fc R13 : 00000000 R14 : 00000000
> MACH: 00000000 MACL: 0000005b GBR : 00000000 PR  : 8c144a00
> 
> Call trace:
>  [<8c14d2d0>] 0x8c14d2d0
>  [<8c0125e0>] 0x8c0125e0
>  [<8c146d0a>] 0x8c146d0a
>  [<8c0125e0>] 0x8c0125e0
>  [<8c147060>] 0x8c147060
>  [<8c14701c>] 0x8c14701c
>  [<8c145a78>] 0x8c145a78
>  [<8c145834>] 0x8c145834
>  [<8c1463fc>] 0x8c1463fc
>  [<8c147338>] 0x8c147338
>  [<8c268094>] 0x8c268094
>  [<8c26809e>] 0x8c26809e
>  [<8c268094>] 0x8c268094
>  [<8c25d14e>] 0x8c25d14e
>  [<8c0adc60>] 0x8c0adc60
>  [<8c032e2a>] 0x8c032e2a
>  [<8c25d5a4>] 0x8c25d5a4
>  [<8c25d0c0>] 0x8c25d0c0
>  [<8c25d5b4>] 0x8c25d5b4
>  [<8c25d0c0>] 0x8c25d0c0
>  [<8c1f4c46>] 0x8c1f4c46
>  [<8c0125e0>] 0x8c0125e0
>  [<8c03b3ac>] 0x8c03b3ac
>  [<8c0171e8>] 0x8c0171e8
>  [<8c03b3ac>] 0x8c03b3ac
>  [<8c1f4c3c>] 0x8c1f4c3c
> 
> ---[ end trace 3132d0e6181e7e96 ]---
> Uniform Multi-Platform E-IDE driver
> 
> and later just fails to start init:
> 
> Type exit when done.
> (sh4:1) /home # sd 0:0:0:0: [sda] Synchronizing SCSI cache
> reboot: Restarting system

So you get a shell prompt, and the shell prompt gets EOF. Is this the  
interactive behavior, or is this smoketest.sh dying because serial init  
consumed all input resetting the emulated chip and discarding its  
buffered I/O?

See "smoketest needs a rewrite".

I note that for the script that generates the screenshots page (which I  
don't think I remembered to run for the most recent releae, actually),  
it does a horrible thing like:

(sleep 10; echo $PARTONE; sleep 5; echo $PARTTWO) | qemu

The _sad_ part is with a couple targets, if you feed it too much data  
it discards everything that won't fit in the buffer. So you have to  
chop the input into small enough chunks. Again, the control-image stuff  
is more reliable than scripting the emulator from outside. When you  
have a /dev/hdc, of course...

> Unauthorized access
> qemu: fatal: Trying to execute code outside RAM or ROM at 0xa0000000

Sigh. that part's normal, sh4 doesn't reset properly and thus panics on  
the way out. Dunno if that's kernel or qemu, I'm guessing qemu. (It  
tries to jump to a ROM to perform the reset, and the ROM isn't there.)

Either way it exits, so it's a purely cosmetic issue.

Rob
 1381895572.0