NetBSD-Users archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Booting arguments for NetBSD under qemu
Hello,
On Wed, 23 Apr 2014 15:39:42 +0100
David Brownlee <abs%absd.org@localhost> wrote:
> On 23 April 2014 11:32, Michael <macallan%netbsd.org@localhost> wrote:
> > Hello,
> >
> > On Mon, 21 Apr 2014 19:32:19 +0100
> > David Brownlee <abs%absd.org@localhost> wrote:
> >
> >> tcx0 at sbus0 slot 3 offset 0x800000 level 5 (ipl 9) (8bit only
> >> TCX)tcx0: SUNW,tcx, 1024 x 768, id 0, rev 0, sense 0system[0]: trap
> >> 0x29: pc=0xf00abe2c sfsr=0xb6 sfva=0x8fc
> >> cpu0: data fault: pc=0xf00abe2c addr=0x8fc
> >> sfsr=0xb6<PERR=0x0,LVL=0x0,AT=0x5,FT=0x5,FAV,OW>
> >> panic: kernel fault
> >
> > That's the TCX's hardware cursor position register. Looks like qemu
> > doesn't actually emulate that part of TCX.
>
> The system boots fine when qemu is run "not -nographic", though it
> attaches genfb so the tcx specific hardware is not touched...
> presumably it might be expected to panic if someone runs X in that
> case?
No, the xf86-video-suntcx driver won't attach without the kernel driver.
> Should NetBSD be attaching tcx0 rather then genfb0 in the "not -nographic"?
If in the "not -nographics" everything works, why not?
> >> So an immediate workaround to enable running NetBSD-6.x would be to
> >> update to qemu-2.0.0 and use "-vga cg3", meanwhile someone can have a
> >> poke at NetBSD and see why -nographic and emulated tcx have issues...
> >> :)
> >
> > See above. A proper workaround would be to either add the missing bits
> > to qemu or find a way for our tcx driver to detect qemu and skip the
> > hardware that's not actually emulated.
>
> Would the output of "ofctl -p" give any clues (attached). This is from
> a "not -nographic" run from a HEAD kernel.
Actually the diff between "-nographics" and "not -nographics" would be more
interesting.
have fun
Michael
Home |
Main Index |
Thread Index |
Old Index