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