Re: [Qemu-ppc] Booting Lubuntu 16.04 on qemu-system-ppc produces errors

[BALATON Zoltan]

On Tue, 9 Jul 2019, Andrew Randrianasulu wrote:
> (gdb) run qemu-system-ppc -M mac99,via=pmu -L ../queue-vga/pc-bios -cdrom 
> /mnt/sdb1/PPC-img/lubuntu-16.04-desktop-powerpc.iso -m 512  -display sdl,gl=on 
> -vga std -d guest_errors,unimp -boot d -cpu G4 -g 1024x768x24 -device ES1370
> Starting program: /dev/shm/qemu/ppc-softmmu/qemu-system-ppc qemu-system-ppc -M 
> mac99,via=pmu -L ../queue-vga/pc-bios -cdrom 
> /mnt/sdb1/PPC-img/lubuntu-16.04-desktop-powerpc.iso -m 512  -display sdl,gl=on 
> -vga std -d guest_errors,unimp -boot d -cpu G4 -g 1024x768x24 -device ES1370
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/libthread_db.so.1".
> [New Thread 0xf560cb40 (LWP 19193)]
> qemu-system-ppc: qemu-system-ppc: Could not open 'qemu-system-ppc': No such 
> file or directory
> [Thread 0xf560cb40 (LWP 19193) exited]
> [Inferior 1 (process 19189) exited with code 01]
> (gdb) run  -M mac99,via=pmu -L ../queue-vga/pc-bios -cdrom 
> /mnt/sdb1/PPC-img/lubuntu-16.04-desktop-powerpc.iso -m 512  -display sdl,gl=on 
> -vga std -d guest_errors,unimp -boot d -cpu G4 -g 1024x768x24 -device ES1370
> Starting program: /dev/shm/qemu/ppc-softmmu/qemu-system-ppc -M mac99,via=pmu -L 
> ../queue-vga/pc-bios -cdrom /mnt/sdb1/PPC-img/lubuntu-16.04-desktop-powerpc.iso 
> -m 512  -display sdl,gl=on -vga std -d guest_errors,unimp -boot d -cpu G4 -g 
> 1024x768x24 -device ES1370
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/libthread_db.so.1".
> [New Thread 0xf560cb40 (LWP 19200)]
> [New Thread 0xf4c1ab40 (LWP 19201)]
> [New Thread 0xec1b7b40 (LWP 19202)]
> [New Thread 0xc5962b40 (LWP 19204)]
> [Thread 0xf4c1ab40 (LWP 19201) exited]
> [New Thread 0xf4c1ab40 (LWP 19219)]
>
> Thread 4 "qemu-system-ppc" received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0xec1b7b40 (LWP 19202)]
> 0xf290e844 in code_gen_buffer ()
> (gdb) bt full
> #0  0xffffffff in code_gen_buffer ()
> #1  0x567054ee in cpu_exec (itb=<optimized out>, cpu=<optimized out>) at 
> /dev/shm/qemu/accel/tcg/cpu-exec.c:173

This seems to crash in TCG which I don't know how to debug and looks not 
related to any of my patches. Hopefully someone on the list can help. I 
wonder if this is related to recent AltiVec optimisations that went on for 
the last two releases. Maybe you could try earlier release (4.0.0 and 
3.1.0) and if that works could try to bisect (although since there were 
some bugs in previous versions things might fail differently or not work 
with those versions so this may make bisecting difficult).

> > > this booted up to (corrupted colors, but this was using fbdev X driver) LXde 
> > > desktop.
> >
> > The corrupted colors are because some mismatch with frame buffer
> > endianness. This iso uses 15 bpp mode. Reverting commit a38127414
> > (ati-vga: Fix frame buffer endianness for big endian target) fixes this
> > but that breaks MorphOS Rage128 driver so one of these is probably wrong
> > (and Linux, or OpenBIOS if it uses open firmware console is more likely to
> > be wrong here).
>
> Colors are fine with -vga std, but probably just any other card on different 
> endiannes host/gues combination will give some fanky color

QEMU vga device has some assumptions about endianness and sets frame 
buffer to big endian if emulating big endian machine:

https://git.qemu.org/?p=qemu.git;a=blob;f=hw/display/vga.c;h=910a23c12ef720a0cd9b14ce2b81e3c300015508;hb=HEAD#l2224

I don't know why is that but this is wrong for ati-vga which is always 
little endian (like PCI devices in general, unless accessing frame buffer 
over a big endian aperture window) so this is what commit a38127414 
overrides for ati-vga but leaves VGA behaviour unchanged as I don't know 
why was that added and if correct or not (but if Linux has same 
assumptions only being tested on QEMU it might work but not sure it works 
on real hardware).

> I  booted same Lubuntu and swicthed it via xorg.conf to 24 bpp - transparancy 
> (?) becomes intensive blue and offset all other colors..

If guest puts image in big endian to frame buffer but it's really little 
endian then all colors will be off in all direct color depths other than 8 
bit which stores only one byte per pixel and uses indexed color so there 
won't be endianness problem. So this is not surprising after finding that 
15 bpp is also wrong. Then 32 and 24 bpps would likely have same problem.

> Note, if you want to have r128 driver in LiveCD you better to update it (sudo 
> apt update), and then choose r128-hwe
> (it will require new xorg-core, so make sure toadd input-evdev, because 
> removing old xserver will remove drivers too).
>
> Unfortunately, none of tested 8, 16, 24 bpp X variations (with r128 driver and 
> UseFBDev option, and acceleration ON)
> resulted in image on screen. X and some fxce programs started up (via startx), 
> but screen was black, not even cursor was  visible :/

No idea why but instead of trying to update and fix this image I'd rather 
test with something known to work on real hardware to avoid chasing bugs 
in guest code.

> > Or maybe they access the frame buffer differently as the
> > card has support for big-endian aperture which may not be emulated
> > correctly yet. I think this should be checked on a real PowerMac3,1 to see
> > which of these isos actually work on real hardware to make sure we're
> > testing with correct guest code.
>
> Unfortunately, I have no real ppc machine :/

Again hope someone on the list might have a PowerMac3,1 and some time to 
test these isos to know which one works and which has also problem on real 
hardware. I've found hints that Debian (and so distros based on it) may 
have problems:

https://wiki.debian.org/PowerPC/FAQ#How_do_I_get_graphics_working.3F

and the bug referenced for Rage128 specifically mentions Rage 128 PRO Mac 
and PC versions so there could also be bugs in guest code which makes it 
difficult to test emulation with that.

Regards,
BALATON Zoltan