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.
> RASTERCONSOLE is what's set up in GENERIC for NetBSD/sparc 5.0.

Oh, that makes it more interesting.  Then the console _is_ talking
directly to the framebuffer.

_Lack of_ wscons is unlikely to cause problems, it seems to me.  wscons
combined with RASTERCONSOLE, I don't know what that would do; I haven't
looked at sparc wscons at all.  I wonder if the other observed cases
were all using RASTERCONSOLE?  If it's on by default, quite likely so;
perhaps that's where the bug is.

> Perhaps the next step is shutting that off, and seeing if the problem
> persists.

That would be an interesting datapoint.  With no wscons and no
REASTERCONSOLE, console display _should_ go through the PROM callbacks,
AIUI; if _that_ misbehaves, it's probably what someone suggested about
scrolling or other copies going on, though I have trouble imagining
what would be doing it - something would have to be drawing on the
framebuffer, which shouldn't be happening with just text-console I/O
going on.

/~\ 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