Port-sparc archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: NetBSD 5.0 and SPARCstation 5 not a lucky combination
> Could the lack of wscons to manage the sparc graphics devices be
> triggering the kind of unserialized register setting that der Mouse
> described as a possible cause of this effect?
Not directly, because that means that the kernel isn't scribbling on
the framebuffer to draw console text; rather, it's punting to the PROM
output routines. At least, unless RASTERCONSOLE still exists and
you're using it.
However, I don't know how much the PROM output routines expect to own
the machine when they're entered. If they expect to be entered with
interrupts disabled but aren't, that might account for it.
...hmm, that, actually, could explain the cross-platform nature of
this, how it's being observed across multiple machines (LX, SS5, SS20)
and even multiple framebuffer architectures (cg6, cg14). Maybe try
wscons (or RASTERCONSOLE, if that still exists) and see if it makes any
difference.
While it's strictly armchair quarterbacking at this point, my
front-runner theory is now incorrect locking, or broken disabling of
interrupts, or some such, when calling out to the PROM routines for
console output.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse%rodents-montreal.org@localhost
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Home |
Main Index |
Thread Index |
Old Index