Hello, On Wed, 23 Apr 2014 15:39:42 +0100 David Brownlee <[email protected]> wrote:
> On 23 April 2014 11:32, Michael <[email protected]> wrote: > > Hello, > > > > On Mon, 21 Apr 2014 19:32:19 +0100 > > David Brownlee <[email protected]> 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
