Versatile QEMU broken in -next

Versatile QEMU broken in -next

[Linus Walleij]

After some hours trying to boot the -next tree on
Versatile PB in QEMU, I git-bisected until I found
that one of these commits breaks Versatile for QEMU
(it just hangs, following quoting git bisect):

There are only 'skip'ped commits left to test.
The first bad commit could be any of:
7813a88b9edca512fe753be1f9a575a3e28b5929
e9a0579b23600c0445675866935c753f7ed11f2d
4207503eec1a8556b3400059058ec408424da222
a0b6419dd2585a88d08d786d44e2ee30b96d8720
e150fb3f218dced597a138c1ee2d773d8ef7dea3
f6b1158d63d6fd8af7cf33b6ba46ba39c462a192
1f4eb371383774415f372396741c3ae48fc66de2
82a3290b6002fc89a965748f90fcba545e3c1c21
7b7e81a1a2b13a2c6ff03174491b20c6c9779eee
e44149eac96c3862c0d8a8e94a3b558e24b37df4
608d8fcf7eb7fc467ecc41b26bfc6294fc9afcb0
8863e0e4f10a71e0ea053e6aae77af3aec8c68ad
2e655a0c01c3a1b8d668f89bd89fb69e373d8952
8952b5244b52e7a44311ddaf9d614a96702931ed
f2b431ef83dc81bb633359b11d97639f04ebb212
We cannot bisect more!

The above cannot be drilled down since these
commits don't compile.

Notice: I have no Versatile board, so I cannot know
if it breaks on the actual hardware. I only know it
breaks in QEMU. I don't know why though.

I guess these all work nicely on a real board, so
I suspect it's a case of "QEMU needs to emulate
better", no real bug on real hardware.

Yours,
Linus Walleij

Versatile QEMU broken in -next

[Russell King - ARM Linux]

On Sun, May 02, 2010 at 03:01:48AM +0200, Linus Walleij wrote:
> After some hours trying to boot the -next tree on
> Versatile PB in QEMU, I git-bisected until I found
> that one of these commits breaks Versatile for QEMU
> (it just hangs, following quoting git bisect):
> 
>...
> f2b431ef83dc81bb633359b11d97639f04ebb212
> We cannot bisect more!

The above is the commit range from 2e655a0 to f2b431e.  Moving 2e655a0
after f2b431e results in the intermediate commits building - the
new commit range (when it eventually gets through linux-next) will be
da7ba95 .. e606a94.

The commit which breaks qemu is e388771 (or in the tree you have, 8863e0e)
and is very subtle.  We used to write the reload register with the control
register set to zero, only because the clock event code calls us with
CLOCK_EVT_MODE_SHUTDOWN immediately before CLOCK_EVT_MODE_PERIODIC.

After the commit, we always set the control register to have IE (interrupt
enable) and 32-bit modes set and everything else disabled, before writing
the reload register.  This is more correct; it is undefined whether
32/16-bit mode affects the size of the value loaded into the counter
register when the load register is written (or subsequent reloads.)

This works on real hardware.  It seems QEMU doesn't like having the load
register written the IE and 32-bit enabled and decides to never generate
an interrupt (this is impossible for real hardware to achieve with periodic
mode selected).

Therefore, QEMU's SP804 timer implementation is buggy.

Versatile QEMU broken in -next

[Rabin Vincent]

On Sun, May 02, 2010 at 03:01:48AM +0200, Linus Walleij wrote:
> Notice: I have no Versatile board, so I cannot know
> if it breaks on the actual hardware. I only know it
> breaks in QEMU. I don't know why though.
> 
> I guess these all work nicely on a real board, so
> I suspect it's a case of "QEMU needs to emulate
> better", no real bug on real hardware.

http://www.mail-archive.com/qemu-devel at nongnu.org/msg30785.html

Rabin

Versatile QEMU broken in -next

[Linus Walleij]

2010/5/2 Rabin Vincent <rabin@rab.in>:

> On Sun, May 02, 2010 at 03:01:48AM +0200, Linus Walleij wrote:
>> Notice: I have no Versatile board, so I cannot know
>> if it breaks on the actual hardware. I only know it
>> breaks in QEMU. I don't know why though.
>>
>> I guess these all work nicely on a real board, so
>> I suspect it's a case of "QEMU needs to emulate
>> better", no real bug on real hardware.
>
> http://www.mail-archive.com/qemu-devel at nongnu.org/msg30785.html

Hey that's swift action Rabin, thanks a lot!

Yours,
Linus Walleij