Re: [Qemu-devel] [Qemu-ppc] [PATCH] Revert "Update OpenBIOS images"

[Alexander Graf]

On 14.02.2013, at 01:01, Mark Cave-Ayland wrote:

> On 13/02/13 23:45, Alexander Graf wrote:
> 
>>> The release is basically done. I don't think we have time for any fix 
>>> beyond reverting the commit. And I'd rather have it reverted, since we 
>>> regress heavily against 1.3 with the updated OpenBIOS.
>> 
>> [12:43am]aliguori:agraf, i can wait until the very start (7am my time) of 
>> tomorrow morning to tag -rc2 if you think having a little more time would be 
>> helpful here
>> [12:43am]agraf:aliguori: but to me a regression weighs more than missing bug 
>> fixes
>> [12:43am]agraf:aliguori: if mark can debug this down within that time, would 
>> that work for you?
>> [12:43am]aliguori:agraf, yes
>> 
>> Mark, do you think you could narrow this down within the next few hours? Or 
>> rather - would you like to give it a try?
> 
> Hmmmm if I had to guess which patch may stop quik from booting then I'd go 
> with this one: 
> http://git.qemu.org/?p=openbios.git;a=commit;h=3caf41bf4a0f9ef7c8b294aca69fbe3366aec21b.

Nope, that's not the one. Reverting it doesn't help.

OpenBIOS gets stuck because it accesses an illegal instruction at a very odd 
address:

(gdb) x /10i 0x03e0014
0x3e0014:       lfdu    f23,5483(r10)
0x3e0018:       lhau    r7,-19710(r11)
0x3e001c:       andi.   r3,r24,19569
0x3e0020:       stmw    r19,-15465(r26)
0x3e0024:       bdzt-   4*cr3+so,0x3dbf20
0x3e0028:       lfqu    f14,-9471(r10)
0x3e002c:       .long 0x4f1bbde8
0x3e0030:       stwu    r1,-25243(r3)
0x3e0034:       addis   r9,r3,17526
0x3e0038:       lha     r19,3371(r26)

This almost looks as if it's jumping into some data section - maybe forth 
bytecode or so.


> 
> Unfortunately at the moment I can't build qemu master after git pull (even 
> with a make distclean) as I get the following compile error:
> 
> cc -I. -I/home/build/src/qemu/git/qemu 
> -I/home/build/src/qemu/git/qemu/include -Werror -fPIE -DPIE -m64 
> -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes 
> -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes 
> -fno-strict-aliasing  -fstack-protector-all -Wendif-labels 
> -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security 
> -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration 
> -Wold-style-definition -Wtype-limits -I/usr/include/p11-kit-1     
> -I/usr/include/libpng12 -I/usr/include/pixman-1   -Iutil -Iutil -pthread 
> -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include   -I 
> qga/qapi-generated -MMD -MP -MT util/acl.o -MF util/acl.d -O2 
> -D_FORTIFY_SOURCE=2 -g  -c -o util/acl.o util/acl.c
> util/hbitmap.c: In function ‘hbitmap_iter_skip_words’:
> util/hbitmap.c:137:5: error: implicit declaration of function 
> ‘trace_hbitmap_iter_skip_words’ [-Werror=implicit-function-declaration]
> util/hbitmap.c:137:5: error: nested extern declaration of 
> ‘trace_hbitmap_iter_skip_words’ [-Werror=nested-externs]
> util/hbitmap.c: In function ‘hbitmap_set’:
> util/hbitmap.c:270:5: error: implicit declaration of function 
> ‘trace_hbitmap_set’ [-Werror=implicit-function-declaration]
> util/hbitmap.c:270:5: error: nested extern declaration of ‘trace_hbitmap_set’ 
> [-Werror=nested-externs]
> util/hbitmap.c: In function ‘hbitmap_reset’:
> util/hbitmap.c:350:5: error: implicit declaration of function 
> ‘trace_hbitmap_reset’ [-Werror=implicit-function-declaration]
> util/hbitmap.c:350:5: error: nested extern declaration of 
> ‘trace_hbitmap_reset’ [-Werror=nested-externs]
> cc1: all warnings being treated as errors
> make: *** [util/hbitmap.o] Error 1
> make: *** Waiting for unfinished jobs....
> 
> On the basis of that, it's unlikely to get fixed by 7am tomorrow morning but 
> I am still happy to make debugging this a priority.

Does a fresh checkout work? If that takes too long you probably want to remove 
the generated trace header files. Tracing is a constant pain point when you 
track the QEMU git.


Alex