[OpenBIOS] [PATCH 0/3] sparc64 cleanups v1

Blue Swirl blauwirbel at gmail.com
Thu May 27 22:42:56 CEST 2010


On Thu, May 27, 2010 at 4:57 PM, Mark Cave-Ayland
<mark.cave-ayland at siriusit.co.uk> wrote:
> Blue Swirl wrote:
>
>> On Tue, May 25, 2010 at 12:12 PM, Igor V. Kovalenko
>> <igor.v.kovalenko at gmail.com> wrote:
>>>
>>> One code cleanup and another pci host bridge remap change,
>>> the latter requires qemu update with patch already posted to qemu list.
>>>
>>> v0->v1: added missing patch moving asi.h to arch includes
>>
>> Thanks, applied all.
>
> Whilst updating to OpenBIOS SVN and qemu git head to test these patches,
> I've found a regression with qemu-system-sparc64 and
> debian-504-sparc-netinst.iso. Rather than getting to the end of the kernel
> boot and being unable to mount the root filesystem, instead I now get the
> following fatal trap message:
>
>
> [   42.493402] Console: switching to mono PROM 128x96
> [   63.440200] [drm] Initialized drm 1.1.0 20060810
> [   63.542123] su: probe of ffe2dea0 failed with error -12
> [   63.690331] brd: module loaded
> [   63.787034] loop: module loaded
> [   63.863989] Uniform Multi-Platform E-IDE driver
> [   63.961215] ide: Assuming 33MHz system bus speed for PIO modes; override
> with idebus=xx
> [   64.115119] mice: PS/2 mouse device common for all mice
> [   64.234482] usbcore: registered new interface driver usbhid
> [   64.359397] usbhid: v2.6:USB HID core driver
> [   64.462167] TCP cubic registered
> [   64.539714] NET: Registered protocol family 17
> [   64.642969] registered taskstats version 1
> [   64.737822] drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
> qemu: fatal: Trap 0x0068 while trap level (5) >= MAXTL (5), Error state
> pc: 0000000000424d18  npc: 0000000000424d1c
> General Registers:
> %g0-3: 0000000000000000 0000000008000000 0000000000004000 0000000000000002
> %g4-7: 00000000000003ff 0000000000000001 0000000000000020 0000000000004000
>
> Current Register Window:
> %o0-3: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> %o4-7: 0000000000000000 0000000000000000 00000000fffd3ef0 0000000000000000
> %l0-3: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> %l4-7: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> %i0-3: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> %i4-7: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
>
> Floating Point Registers:
> %f00: 000000000.000000 000000000.000000 000000000.000000 000000000.000000
> %f04: 000000000.000000 000000000.000000 000000000.000000 000000000.000000
> %f08: 000000000.000000 000000000.000000 000000000.000000 000000000.000000
> %f12: 000000000.000000 000000000.000000 000000000.000000 000000000.000000
> %f16: 000000000.000000 000000000.000000 000000000.000000 000000000.000000
> %f20: 000000000.000000 000000000.000000 000000000.000000 000000000.000000
> %f24: 000000000.000000 000000000.000000 000000000.000000 000000000.000000
> %f28: 000000000.000000 000000000.000000 000000000.000000 000000000.000000
> %f32: 000000000.000000 000000000.000000 000000000.000000 000000000.000000
> %f36: 000000000.000000 000000000.000000 000000000.000000 000000000.000000
> %f40: 000000000.000000 000000000.000000 000000000.000000 000000000.000000
> %f44: 000000000.000000 000000000.000000 000000000.000000 000000000.000000
> %f48: 000000000.000000 000000000.000000 000000000.000000 000000000.000000
> %f52: 000000000.000000 000000000.000000 000000000.000000 000000000.000000
> %f56: 000000000.000000 000000000.000000 000000000.000000 000000000.000000
> %f60: 000000000.000000 000000000.000000 000000000.000000 000000000.000000
> pstate: 00000414 ccr: 00 (icc: ---- xcc: ----) asi: 82 tl: 5 pil: 0
> cansave: 6 canrestore: 0 otherwin: 0 wstate: 2 cleanwin: 0 cwp: 7
> fsr: 0000000000000000 y: 0000000000000000 fprs: 0000000000000000
> Aborted
>
>
> Digging deeper, it seems that this was something that was introduced earlier
> than the last set of patches. Reverting to OpenBIOS SVN r777 and using 'git
> bisect', I can identify the offending commit in qemu git as
> 2aae2b8e0abd58e76d616bcbe93c6966d06d0188 "sparc64: fix pstate privilege
> bits". Does that help at all?

Yes, bisection results are usually very helpful, thanks.

I think the problem is that previously psrs was always 1 and PSR_HYPV
always set, so maximally permissive MMU_HYPV_INDEX was always selected
by cpu_mmu_index (bug!). Also because PSR_HYPV is no longer set, some
checks in translate.c indicate privilege violations.

The logic was previously such that if the CPU does not have a
hypervisor mode, for compatibility, supervisor mode would also select
hypervisor mode (or at least that was my intention and probably Igor
wasn't aware of this, sorry). Now that they are separate, CPUs without
hypervisor mode must be handled differently. Perhaps this commit
should be reverted, the fix won't be so trivial.

The lesson here is also that subtle assumptions like this should be documented.



More information about the OpenBIOS mailing list