[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] Fixing sh4 serial abort

From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH] Fixing sh4 serial abort
Date: Fri, 27 Jul 2012 18:28:15 +0100

On 27 July 2012 18:16, Rob Landley <address@hidden> wrote:
> On 07/27/2012 09:32 AM, Peter Maydell wrote:
>> On 27 July 2012 14:45, Rob Landley <address@hidden> wrote:
>>> I.E. sci_getreg(port, SCFCR) move to before checking whether or not
>>> we'll ever possibly use the result. SCFCR is 0x18 and QEMU calls abort()
>>> on an attempt to read from an unimplemented register.
>>> I can patch the kernel to work around this (and probably will for this
>>> release), but the _proper_ fix is to get qemu not to abort on a register
>>> read that works fine if it just returns 0.
>> The thing this analysis is missing is any examination of the question
>> "what is the hardware we are modelling documented to do?".
> Given that 3.3, 3.4, and 3.5 kernels have already shipped with this, I'm
> guessing "not immediately crash"?

I said "documented", not "what it happens to do in practice".

> Then again I can't really criticize sh4 for multiple kernel releases not
> working under qemu and nobody noticing when _arm_ currenty has a similar
> problem. The arm versatile board's scsi emulation was broken by linux
> commit 4d5fc58dbe34 in 3.4 (yanking the versatile's mach/io.h when the
> default one breaks PCI), and then before _that_ got reverted (in commit
> 9b0f7e399238c6) this commit went in:
> commit 1bc39ac5dab265b76ce6e20d6c85f900539fd190
> Author: Russell King <address@hidden>
> Date:   Sat Mar 10 11:32:34 2012 +0000
>     ARM: PCI: versatile: fix PCI interrupt setup
>     This is at odds with the documentation in the file; it says pin 1 on
>     slots 24,25,26,27 map to IRQs 27,28,29,30, but the function will
>     always be entered with slot=0 due to the lack of swizzle function.
>     Fix this function to behave as the comments say, and use the
>     standard PCI swizzle.
>     Signed-off-by: Russell King <address@hidden>
> So the arm maintainer noticed a place where the code didn't match the
> documentation, changed the code to match the docs, and result doesn't
> work under qemu's versatile board emulation. But at least 3.5 doesn't
> work for a _different_ reason than 3.4 didn't work, so there's that.

PCI on versatilepb is hopelessly broken -- the only thing the kernel
code does (or did) is work on QEMU. Arnd Bergmann had some kernel
patches which fixed all that so it worked on hardware, but they never
got applied. It looks like Russell has now belatedly noticed a
subset of that wrongness.

> I hadn't reported this one yet because I still haven't root caused it,
> just bisected to find the break. I know reverting the IRQ assignment
> line in 3.5 doesn't fix it, which implies the "swizzle" bit is to blame
> (which seems ot have something to do with PCI bridges), and thus calling
> the default function instead of calling no function breaks qemu's
> versatile board emulation.

1. Find Arnd's kernel patches and see what of them still need to
be applied (http://comments.gmane.org/gmane.linux.ports.arm.kernel/93393)
2. Get kernel working on real hardware
3. Submit qemu patches to fix our versatilepb PCI emulation to
match hardware

If you like you can do 3 first and I'll happily apply those patches
regardless of whether anybody cares to fix the kernel.

I'm afraid I don't have a great deal of time for versatilepb
emulation fixes because it's an incredibly ancient devboard.
vexpress breakage will get more attention from me (though I
don't habitually test new kernels on qemu so I won't necessarily
notice bugs unless my attention is drawn to them.)

-- PMM

reply via email to

[Prev in Thread] Current Thread [Next in Thread]