* [Qemu-devel] Re: [OpenBIOS] [PATCH 0/3] sparc64 cleanups v1
[not found] ` <AANLkTik2dc9regcA_9ADT_K7-sKCXLXED5Av9i3cjjEE@mail.gmail.com>
@ 2010-05-27 16:57 ` Mark Cave-Ayland
2010-05-27 20:42 ` Blue Swirl
2010-05-28 4:31 ` Igor Kovalenko
0 siblings, 2 replies; 6+ messages in thread
From: Mark Cave-Ayland @ 2010-05-27 16:57 UTC (permalink / raw)
To: The OpenBIOS Mailinglist, qemu-devel, Igor Kovalenko
Blue Swirl wrote:
> On Tue, May 25, 2010 at 12:12 PM, Igor V. Kovalenko
> <igor.v.kovalenko@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?
ATB,
Mark.
--
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk
t: +44 870 608 0063
Sirius Labs: http://www.siriusit.co.uk/labs
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Qemu-devel] Re: [OpenBIOS] [PATCH 0/3] sparc64 cleanups v1
2010-05-27 16:57 ` [Qemu-devel] Re: [OpenBIOS] [PATCH 0/3] sparc64 cleanups v1 Mark Cave-Ayland
@ 2010-05-27 20:42 ` Blue Swirl
2010-05-28 3:13 ` Igor Kovalenko
2010-05-28 4:31 ` Igor Kovalenko
1 sibling, 1 reply; 6+ messages in thread
From: Blue Swirl @ 2010-05-27 20:42 UTC (permalink / raw)
To: The OpenBIOS Mailinglist; +Cc: qemu-devel
On Thu, May 27, 2010 at 4:57 PM, Mark Cave-Ayland
<mark.cave-ayland@siriusit.co.uk> wrote:
> Blue Swirl wrote:
>
>> On Tue, May 25, 2010 at 12:12 PM, Igor V. Kovalenko
>> <igor.v.kovalenko@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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Qemu-devel] Re: [OpenBIOS] [PATCH 0/3] sparc64 cleanups v1
2010-05-27 20:42 ` Blue Swirl
@ 2010-05-28 3:13 ` Igor Kovalenko
0 siblings, 0 replies; 6+ messages in thread
From: Igor Kovalenko @ 2010-05-28 3:13 UTC (permalink / raw)
To: Blue Swirl; +Cc: The OpenBIOS Mailinglist, qemu-devel
On Fri, May 28, 2010 at 12:42 AM, Blue Swirl <blauwirbel@gmail.com> wrote:
> On Thu, May 27, 2010 at 4:57 PM, Mark Cave-Ayland
> <mark.cave-ayland@siriusit.co.uk> wrote:
>> Blue Swirl wrote:
>>
>>> On Tue, May 25, 2010 at 12:12 PM, Igor V. Kovalenko
>>> <igor.v.kovalenko@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.
I'll take a look at this issue.
>
> The lesson here is also that subtle assumptions like this should be documented.
>
--
Kind regards,
Igor V. Kovalenko
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Qemu-devel] Re: [OpenBIOS] [PATCH 0/3] sparc64 cleanups v1
2010-05-27 16:57 ` [Qemu-devel] Re: [OpenBIOS] [PATCH 0/3] sparc64 cleanups v1 Mark Cave-Ayland
2010-05-27 20:42 ` Blue Swirl
@ 2010-05-28 4:31 ` Igor Kovalenko
2010-05-28 8:43 ` Mark Cave-Ayland
1 sibling, 1 reply; 6+ messages in thread
From: Igor Kovalenko @ 2010-05-28 4:31 UTC (permalink / raw)
To: Mark Cave-Ayland; +Cc: The OpenBIOS Mailinglist, qemu-devel
On Thu, May 27, 2010 at 8:57 PM, Mark Cave-Ayland
<mark.cave-ayland@siriusit.co.uk> wrote:
> Blue Swirl wrote:
>
>> On Tue, May 25, 2010 at 12:12 PM, Igor V. Kovalenko
>> <igor.v.kovalenko@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?
With many debian iso images I consistently get scrolling blanks after
the following line on qemu video console:
io sched cfq registered (default)
Please share your qemu command line, and installer prompt input if any.
--
Kind regards,
Igor V. Kovalenko
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Qemu-devel] Re: [OpenBIOS] [PATCH 0/3] sparc64 cleanups v1
2010-05-28 4:31 ` Igor Kovalenko
@ 2010-05-28 8:43 ` Mark Cave-Ayland
2010-05-28 9:03 ` Igor Kovalenko
0 siblings, 1 reply; 6+ messages in thread
From: Mark Cave-Ayland @ 2010-05-28 8:43 UTC (permalink / raw)
To: Igor Kovalenko; +Cc: The OpenBIOS Mailinglist, qemu-devel
Igor Kovalenko wrote:
> With many debian iso images I consistently get scrolling blanks after
> the following line on qemu video console:
>
> io sched cfq registered (default)
>
> Please share your qemu command line, and installer prompt input if any.
Yeah, I do too. I originally thought that the Debian kernel was broken,
but if you leave it long enough then it does proceed to the end. My
guess is that there is a bug in the OpenBIOS console which is obscuring
the output.
The first part of the boot below happens reasonably quickly; then like
you the console puts out lots of junk before it returns:
OpenBIOS for Sparc64
Configuration device id QEMU version 1 machine id 0
kernel cmdline
CPUs: 1 x SUNW,UltraSPARC-IIi
UUID: 00000000-0000-0000-0000-000000000000
Welcome to OpenBIOS v1.0 built on May 28 2010 08:24
Type 'help' for detailed information
[sparc64] Booting file 'cdrom' with parameters ''
Not a bootable ELF image
Not a Linux kernel image
Loading a.out image...
Loaded 7680 bytes
entry point is 0x4000
Jumping to entry point 0000000000004000 for type 0000000000000005...
switching to new context: entry point 0x4000 stack 0x00000000ffe02b51
SILO Version 1.4.13
\
Welcome to Debian GNU/Linux lenny!
This is a Debian installation CDROM, built on 20100201-16:54.
Keep it once you have installed your system, as you can boot from it
to repair the system on your hard disk if that ever becomes necessary.
WARNING: You should completely back up all of your hard disks before
proceeding. The installation procedure can completely and irreversibly
erase them! If you haven't made backups yet, remove the rescue CD from
the drive and press L1-A to get back to the OpenBoot prompt.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted
by applicable law.
[ ENTER - Boot install ] [ Type "expert" - Boot into expert mode ]
[ Type "rescue" - Boot into rescue mode ]
boot:
Allocated 8 Megs of memory at 0x40000000 for kernel
Loaded kernel version 2.6.26
Loading initial ramdisk (4312781 bytes at 0xC00000 phys, 0x40C00000 virt)...
|
[ 0.000000] PROMLIB: Sun IEEE Boot Prom 'OBP 3.10.24 1999/01/01 01:01'
[ 0.000000] PROMLIB: Root node compatible: sun4u
[ 0.000000] Initializing cgroup subsys cpu
[ 0.000000] Linux version 2.6.26-2-sparc64 (Debian 2.6.26-21)
(dannf@debian.org) (gcc version 4.1.3 20080704 (prerelease) (Debian
4.1.2-25)) #1 Tue Jan 12 22:16:05 UTC 2010
[ 0.000000] console [earlyprom0] enabled
[ 0.000000] ARCH: SUN4U
[ 0.000000] Ethernet address: 52:54:00:12:34:56
[ 0.000000] Kernel: Using 1 locked TLB entries for main kernel image.
[ 0.000000] Remapping the kernel... done.
[ 0.000000] OF stdout device is: /pci@1fe,0/ebus@3/su
[ 0.000000] PROM: Built device tree with 32655 bytes of memory.
[ 0.000000] Top of RAM: 0x7e80000, Total RAM: 0x7e80000
[ 0.000000] Memory hole size: 0MB
[ 0.000000] [0000000200000000-fffff80000800000] page_structs=131072
node=0 entry=0/0
[ 0.000000] [0000000200000000-fffff80001400000] page_structs=131072
node=0 entry=1/0
[ 0.000000] Zone PFN ranges:
[ 0.000000] Normal 0 -> 16192
[ 0.000000] Movable zone start PFN for each node
[ 0.000000] early_node_map[1] active PFN ranges
[ 0.000000] 0: 0 -> 16192
[ 0.000000] Booting Linux...
[ 0.000000] Built 1 zonelists in Zone order, mobility grouping on.
Total pages: 16081
[ 0.000000] Kernel command line:
[ 0.000000] PID hash table entries: 512 (order: 9, 4096 bytes)
[ 0.000000] clocksource: mult[a0000] shift[16]
[ 0.000000] clockevent: mult[19999999] shift[32]
[ 11.273908] Console: colour dummy device 80x25
[ 11.339826] console handover: boot [earlyprom0] -> real [tty0]
.... the console then prints blocks along the RHS of the screen for
about 60s on my Intel Core 2 1.83GHz before returning...
[ 40.450573] Console: switching to mono PROM 128x96
[ 60.624138] [drm] Initialized drm 1.1.0 20060810
[ 60.725621] ffe2df18: ttyS0 at MMIO 0x1fe020003f8 (irq = 0) is a 16550A
[ 60.849637] Console: ttyS0 (SU)
[ 60.931684] console [ttyS0] enabled
[ 0.000000] PROMLIB: Sun IEEE Boot Prom 'OBP 3.10.24 1999/01/01 01:01'
[ 0.000000] PROMLIB: Root node compatible: sun4u .24 1999/01/01 01:01'
[ 0.000000] Initializing cgroup subsys cpu sun4u
[ 0.000000] Linux version 2.6.26-2-sparc64 (Debian 2.6.26-21)
(dannf@debian.org) (gcc version 4.1.3 20080704 (prerelease) (Deeebian
4.1.2-25)) #1 Tue Jan 12 22:16:05 U
bian 4.1.2-25)) #1 Tue Jan 12 22:16:05 UTC 2010
[ 0.000000] console [earlyprom0] enabled 4 (Debian 2.6.26-21)
(dannf@debian.org) (gcc version 4.1.3 20080704 (prerelease) (De
[ 0.000000] ARCH: SUN4U lyprom0] enabled
[ 0.000000] Ethernet address: 52:54:00:12:34:56
[ 0.000000] Kernel: Using 1 locked TLB entries for main kernel image.
[ 0.000000] Remapping the kernel... done. ries for main kernel image.
[ 0.000000] OF stdout device is: /pci@1fe,0/ebus@3/su
[ 0.000000] PROM: Built device tree with 32655 bytes of memory.
[ 0.000000] Top of RAM: 0x7e80000, Total RAM: 0x7e80000 memory.
0.000000] [0000000200000000-fffff80000800000] page_structs=131072
node=0 entry=0/0
0.000000] Zone PFN ranges: -fffff80001400000] page_structs=131072
node=0 entry=1/0
0.000000] Movable zone start PFN for each node
0.000000] 0: 0 -> 16192 ranges
0.000000] Built 1 zonelists in Zone order, mobility grouping on.
Total pages: 16081
0.000000] PID hash table entries: 512 (order: 9, 4096 bytes)
0.000000] clockevent: mult[19999999] shift[32]
10.861313] console handover: boot [earlyprom0] -> real [tty0]
10.943240] Inode-cache hash table entries: 8192 (order: 3, 65536
bytes)es)
11.052494] Calibrating delay using timer specific routine.. 203.38
BogoMIPS (lpj=406760)00000000,0000000007e80000]
11.057509] SELinux: Disabled at boot.zed
11.058937] Mount-cache hash table entries: 512
11.073067] Initializing cgroup subsys cpuacct
11.107516] net_namespace: 1208 bytess devices
11.160324] PCI: Probing for controllers.ly 16
11.166356] /pci@1f,0: PCI IO[1fe02000000] MEM[1ff00000000]
11.182694] ebus0: [fdthree] [su] [kb_ps2]
11.218962] usbcore: registered new interface driver hubfs
11.256772] NET: Registered protocol family 2iver usb
11.305741] TCP established hash table entries: 4096 (order: 3,
65536 bytes)
11.307073] TCP: Hash tables configured (established 4096 bind 4096))
[ 11.307399] TCP reno registerednfigured (established 4096 bind 4096)
[ 11.317930] NET: Registered protocol family 1
[ 11.329393] checking if image is initramfs... it is
[ 19.232833] Freeing initrd memory: 4211k freedit is
[ 19.241377] audit: initializing netlink socket (disabled)
[ 19.242582] type=2000 audit(8.292:1): initializedisabled)
[ 19.246130] Total HugeTLB memory allocated, 0ized
[ 19.250809] VFS: Disk quotas dquot_6.5.1ed, 0
[ 19.251650] Dquot-cache hash table entries: 1024 (order 0, 8192 bytes)
[ 19.254760] msgmni has been set to 228ries: 1024 (order 0, 8192 bytes)
[ 19.258260] Block layer SCSI generic (bsg) driver version 0.4 loaded
(major 253)
[ 19.258713] io scheduler noop registeredg) driver version 0.4 loaded
(major 253)
[ 19.258713] io scheduler noop registered
[ 19.258943] io scheduler anticipatory registered
[ 19.258943] io scheduler anticipatory registered
[ 19.259135] io scheduler deadline registered
[ 19.259135] io scheduler deadline registered
[ 19.259503] io scheduler cfq registered (default)
[ 19.259503] io scheduler cfq registered (default)
[ 40.450573] Console: switching to mono PROM 128x96
[ 40.450573] Console: switching to mono PROM 128x96
[ 60.624138] [drm] Initialized drm 1.1.0 20060810
[ 60.624138] [drm] Initialized drm 1.1.0 20060810
[ 60.725621] ffe2df18: ttyS0 at MMIO 0x1fe020003f8 (irq = 0) is a 16550A
[ 60.725621] ffe2df18: ttyS0 at MMIO 0x1fe020003f8 (irq = 0) is a 16550A
[ 60.849637] Console: ttyS0 (SU)
[ 60.849637] Console: ttyS0 (SU)
[ 60.931684] console [ttyS0] enabled
[ 60.931684] console [ttyS0] enabled
[ 68.952023] brd: module loaded
[ 68.952023] brd: module loaded
[ 69.074597] loop: module loaded
[ 69.074597] loop: module loaded
[ 69.185675] Uniform Multi-Platform E-IDE driver
[ 69.185675] Uniform Multi-Platform E-IDE driver
[ 69.315268] ide: Assuming 33MHz system bus speed for PIO modes;
override with idebus=xx
[ 69.315268] ide: Assuming 33MHz system bus speed for PIO modes;
override with idebus=xx
[ 69.500789] mice: PS/2 mouse device common for all mice
[ 69.500789] mice: PS/2 mouse device common for all mice
[ 69.646046] usbcore: registered new interface driver usbhid
[ 69.646046] usbcore: registered new interface driver usbhid
[ 69.793655] usbhid: v2.6:USB HID core driver
[ 69.793655] usbhid: v2.6:USB HID core driver
[ 69.928176] TCP cubic registered
[ 69.928176] TCP cubic registered
[ 70.038642] NET: Registered protocol family 17
[ 70.038642] NET: Registered protocol family 17
[ 70.172972] registered taskstats version 1
[ 70.172972] registered taskstats version 1
[ 70.297926] drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
[ 70.297926] drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
[ 70.482657] su: Cannot register IRQ 0
[ 70.482657] su: Cannot register IRQ 0
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: 00000000000003fe 0000000000000001 0000000000000020 0000000000004000
Current Register Window:
%o0-3: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
%o4-7: 0000000000000000 0000000000000000 00000000ffb29ef0 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
It looks like your latest set of OpenBIOS patches has helped with the
serial port, since before these the buffered portion (i.e. the part that
I imagine is supposed to appear at the time when the blocks are being
drawn on the console) never used to appear. Not quite sure why some of
the entries are duplicated though.
Finally, the command line I am using is:
./qemu-system-sparc64 -cdrom debian-504-sparc-netinst.iso -nographic -boot d
HTH,
Mark.
--
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk
t: +44 870 608 0063
Sirius Labs: http://www.siriusit.co.uk/labs
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Qemu-devel] Re: [OpenBIOS] [PATCH 0/3] sparc64 cleanups v1
2010-05-28 8:43 ` Mark Cave-Ayland
@ 2010-05-28 9:03 ` Igor Kovalenko
0 siblings, 0 replies; 6+ messages in thread
From: Igor Kovalenko @ 2010-05-28 9:03 UTC (permalink / raw)
To: Mark Cave-Ayland; +Cc: The OpenBIOS Mailinglist, qemu-devel
On Fri, May 28, 2010 at 12:43 PM, Mark Cave-Ayland
<mark.cave-ayland@siriusit.co.uk> wrote:
> Igor Kovalenko wrote:
>
>> With many debian iso images I consistently get scrolling blanks after
>> the following line on qemu video console:
>>
>> io sched cfq registered (default)
>>
>> Please share your qemu command line, and installer prompt input if any.
>
> Yeah, I do too. I originally thought that the Debian kernel was broken, but
> if you leave it long enough then it does proceed to the end. My guess is
> that there is a bug in the OpenBIOS console which is obscuring the output.
I allowed it to scroll and now I can confirm it would crash with tl=5.
Last insn is ldda with ASI=0x24 (Nucleus quad LDD 128 bit atomic)
IN:
0x0000000000424d18: ldda [ %g1 ] (36), %g4
0x0000000000424d1c: cmp %g4, %g6
0x0000000000424d20: bne,pn %xcc, 0x4076c0
0x0000000000424d24: mov 2, %g3
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
Well, not sure how it worked before. Related code in helper_ld_asi() states:
case 0x24: // Nucleus quad LDD 128 bit atomic
case 0x2c: // Nucleus quad LDD 128 bit atomic LE
// Only ldda allowed
raise_exception(TT_ILL_INSN);
return 0;
HelenOS also uses quad ldd when configured with TSB for memory management.
I guess that atomic quad ldd deserves to be implemented. I'll see if
it is not hard.
--
Kind regards,
Igor V. Kovalenko
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2010-05-28 9:03 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20100525121143.19347.27207.stgit@skyserv>
[not found] ` <AANLkTik2dc9regcA_9ADT_K7-sKCXLXED5Av9i3cjjEE@mail.gmail.com>
2010-05-27 16:57 ` [Qemu-devel] Re: [OpenBIOS] [PATCH 0/3] sparc64 cleanups v1 Mark Cave-Ayland
2010-05-27 20:42 ` Blue Swirl
2010-05-28 3:13 ` Igor Kovalenko
2010-05-28 4:31 ` Igor Kovalenko
2010-05-28 8:43 ` Mark Cave-Ayland
2010-05-28 9:03 ` Igor Kovalenko
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).