sun4m cgfourteen sx wscons issues

[v***@bubbleverse.eu]

Hi there,

i'm trying to get NetBSD-current running on a sparcstation 20 with cgfourteen framebuffer and sx vsimm module. According to this[1] there was some work done arround last year to support the sx.

I haven't tried X yet, but wscons isn't useable. It seems that every second glyph is missing on the screen and scrolling doesn't work.

In OBP the video mode is set to r1280x1024x76m(output-device screen:r1280x1024x76m). The Monitor i have attached tells me, both in OBP and in wscons, that the mode is set correctly. OBP Version is 2.19.
The kernel log doesn't show anything unusual AFAIK, but i attached it anyway. On SunOS everything looks normal, so i guess a hardware issue can be ruled out.

As i'm new to NetBSD, i don't really know where to start investigating this issue, so i would be thankful for some clues.

- Victor

[1]: https://blog.netbsd.org/tnf/entry/sx_support_added

[Michael]

Hello,

On Fri, 11 Apr 2014 23:33:56 +0200

Post by v***@bubbleverse.eu
i'm trying to get NetBSD-current running on a sparcstation 20 with cgfourteen framebuffer and sx vsimm module. According to this[1] there was some work done arround last year to support the sx.
I haven't tried X yet, but wscons isn't useable. It seems that every second glyph is missing on the screen and scrolling doesn't work.

This is odd, last time I tried ( that was a few months ago ) it worked just fine.
Your log shows an 8MB VSIMM, which is what I'm using. Does this happen
with a non-MP kernel as well? ( just to rule it out, right now I can't
really think of anything that could cause this )

Hmm. All drawing is done through the SX, so if some glyphs show up
we're at least feeding it correctly and it's scribbling into actual
video memory. I assume the kernel is a stock GENERIC.MP from netbsd.org?
Any chance you could send me a picture?

I also never tried it with SuperSPARC modules ( I have an SM71 here
somewhere ), maybe the MBus stalling needs extra work there ( SX is
supposed to stall the bus when its pipeline is full, that would explain
why the scrolling doesn't work but then I'd expect partially drawn
glyphs, at least with fonts taller than 8 pixels )
Does it manage to clear the screen on attach?

have fun
Michael

[Michael]

Hello,

thanks for the pictures!

I just tested different video modes by setting output-device to screen:mode in OBP. With r1024x768x60, r1024x768x70, scrolling works. With r1280x1024x66 and r1280x1024x76m it doesn't.

Mine's in r1280x1024x66 since that's the monitor's native resolution.
Let me see if I can reproduce the problem, or at least find any
significant differences between your hardware and mine ( my SS20 has
hypersparc CPUs, more memory and a bunch of SBus cards, but none of
that should have any impact. There are different cg14 variants though,
I wonder if any of those need special treatment somewhere )

Is your VSIMM actually an 8MB one or did the driver misdetect it? I've
got one of each but I don't think I messed with the 4MB module lately.

Thank you for your help so far and the fast reply.

I wrote the code, I want to know what's going on.

Also, it might be worth to just start X and see if it produces similar
patterns. It should detect the cg14/sx without a config file, switch to
24bit etc.

One more thing, what happens when you try switching virtual consoles in
a mode where scrolling works right? ( Stop-F1..F5 )

have fun
Michael

[v***@bubbleverse.eu]

On Sat, 12 Apr 2014 08:32:52 -0400

Post by Michael
Mine's in r1280x1024x66 since that's the monitor's native resolution.
Let me see if I can reproduce the problem, or at least find any
significant differences between your hardware and mine ( my SS20 has
hypersparc CPUs, more memory and a bunch of SBus cards, but none of
that should have any impact. There are different cg14 variants though,
I wonder if any of those need special treatment somewhere )

Could a different version of OBP have any impact?

Post by Michael
Is your VSIMM actually an 8MB one or did the driver misdetect it? I've
got one of each but I don't think I messed with the 4MB module lately.

Yep, it's a 8MB module.

Post by Michael
Also, it might be worth to just start X and see if it produces similar
patterns. It should detect the cg14/sx without a config file, switch to
24bit etc.

X starts as it should and looks as it should, as long i'm not moving anything. When i move windows or text scrolls in a window, sometimes the window decorations disappear(in twm), the content of the windows disappear or do not update and sometimes vertical line patterns appear. When scrolling text in xterm, it seems to be more reliable to scroll whole pages than single lines. Xorg.log doesn't say unusual things, i attached it.

Post by Michael
One more thing, what happens when you try switching virtual consoles in
a mode where scrolling works right? ( Stop-F1..F5 )

Switching virtual consoles works. Regardless of the video mode, every second glyph is missing.

In a mode where scrolling works, i get an login screen that is otherwise empty(when i switched to a vt with a getty running on).

With a mode where scrolling doesn't work, the screen is full of text of the previous virtual console or with parts of the X screen(strangely magnified - i guess, thats because the X screen has 24 bit color and the console 8?).

Switching to a virtual console with X screen results in a clean-looking X screen.

- Victor

PS: Ths mailinglist didn't like the mail with the images so i uploaded them here:
Loading Image...
Loading Image...
Loading Image...

[Michael]

Hello,

On Sat, 12 Apr 2014 17:04:57 +0200

Post by v***@bubbleverse.eu
On Sat, 12 Apr 2014 08:32:52 -0400

Post by Michael
Mine's in r1280x1024x66 since that's the monitor's native resolution.
Let me see if I can reproduce the problem, or at least find any
significant differences between your hardware and mine ( my SS20 has
hypersparc CPUs, more memory and a bunch of SBus cards, but none of
that should have any impact. There are different cg14 variants though,
I wonder if any of those need special treatment somewhere )

Could a different version of OBP have any impact?

It shouldn't.

Post by v***@bubbleverse.eu
Switching virtual consoles works. Regardless of the video mode, every second glyph is missing.

So the blank columns stay blank and stay where they are?

I just booted my ss20, it's running in r1280x1024x66, no problems whatsoever.
The kernel it's been running is here: ftp://ftp.netbsd.org/pub/NetBSD/misc/macallan/sparc/netbsd.poteen.gz
Please try it, if it works at least I know there's something I overlooked when committing the code.

have fun
Michael

[v***@bubbleverse.eu]

On Mon, 14 Apr 2014 08:28:09 -0400

Post by Michael

Post by v***@bubbleverse.eu
Switching virtual consoles works. Regardless of the video mode, every second glyph is missing.

So the blank columns stay blank and stay where they are?

When using the videomodes r1024x768x*, yes.

Post by Michael
I just booted my ss20, it's running in r1280x1024x66, no problems whatsoever.
The kernel it's been running is here: ftp://ftp.netbsd.org/pub/NetBSD/misc/macallan/sparc/netbsd.poteen.gz
Please try it, if it works at least I know there's something I overlooked when committing the code.

Same issues with that kernel.

- Victor

[Michael]

Hello,

On Tue, 15 Apr 2014 18:14:42 +0200

Post by v***@bubbleverse.eu
On Mon, 14 Apr 2014 08:28:09 -0400

Post by Michael

Post by v***@bubbleverse.eu
Switching virtual consoles works. Regardless of the video mode, every second glyph is missing.

So the blank columns stay blank and stay where they are?

When using the videomodes r1024x768x*, yes.

Post by Michael
I just booted my ss20, it's running in r1280x1024x66, no problems whatsoever.
The kernel it's been running is here: ftp://ftp.netbsd.org/pub/NetBSD/misc/macallan/sparc/netbsd.poteen.gz
Please try it, if it works at least I know there's something I overlooked when committing the code.

Same issues with that kernel.

This is getting weird.
Please send me the ofctl -p output for that machine ( it's just a dump of the device tree with properties )

have fun
Michael

[v***@bubbleverse.eu]

Hi,

On Tue, 15 Apr 2014 18:29:17 -0400

Post by Michael
Please send me the ofctl -p output for that machine ( it's just a dump of the device tree with properties )

Output is attached. The cgfourteen entry doesn't seem to have a version key, but maybe you'll still find differences to your machine.

- Victor

[Michael]

Hello,

On Wed, 16 Apr 2014 18:17:36 +0200

Post by v***@bubbleverse.eu
On Tue, 15 Apr 2014 18:29:17 -0400

Post by Michael
Please send me the ofctl -p output for that machine ( it's just a dump of the device tree with properties )

Output is attached. The cgfourteen entry doesn't seem to have a version key, but maybe you'll still find differences to your machine.

Unfortunately, I didn't find anything. My OBP version is different from
yours ( mine's 2.25 ). Either way, uploaded two kernel images:
ftp://ftp.netbsd.org/pub/NetBSD/misc/macallan/sparc/netbsd.poteen.gz
this one does a little more explicit hardware setup ( on the cg14 side
) instead of relying on OBP.
ftp://ftp.netbsd.org/pub/NetBSD/misc/macallan/sparc/netbsd.poteen.no_sx.gz
same thing, without sx. Just to see if the issues you're seeing are
caused by the cg14 or by the acceleration code. I'm fairly sure it's
the latter but since I can't reproduce it I have to make sure.

have fun
Michael

[v***@bubbleverse.eu]

Hi,

On Thu, 17 Apr 2014 17:03:43 -0400

Post by Michael
ftp://ftp.netbsd.org/pub/NetBSD/misc/macallan/sparc/netbsd.poteen.gz
this one does a little more explicit hardware setup ( on the cg14 side
) instead of relying on OBP.

Same symptoms as before. However there is an interesting new line in dmesg:
sx0: architecture rev. 27 chip rev. 0

Post by Michael
ftp://ftp.netbsd.org/pub/NetBSD/misc/macallan/sparc/netbsd.poteen.no_sx.gz
same thing, without sx. Just to see if the issues you're seeing are
caused by the cg14 or by the acceleration code. I'm fairly sure it's
the latter but since I can't reproduce it I have to make sure.

That one panics and gives me a "db>" prompt. Output is attached. I didn't upload a core dump, because i have no swap partition, and in hope you could make sense of the debuggers bt. Tell me if a coredump is necessary.

Another thing: Wscons doesn't come up on the screen when i set output-device and input-device to a serial port in OBP. Instead the screen shows a checkerboard pattern. I guess that at least the first part is normal behaviour but i thought i'd mention it.

- Victor

[Michael]

Hello,

On Fri, 18 Apr 2014 17:46:55 +0200

Post by v***@bubbleverse.eu
On Thu, 17 Apr 2014 17:03:43 -0400

Post by Michael
ftp://ftp.netbsd.org/pub/NetBSD/misc/macallan/sparc/netbsd.poteen.gz
this one does a little more explicit hardware setup ( on the cg14 side
) instead of relying on OBP.

sx0: architecture rev. 27 chip rev. 0

Ok, mine is rev. 25. Finally something that's different. That gives me an idea, let me cook up another kernel...

Post by v***@bubbleverse.eu

Post by Michael
ftp://ftp.netbsd.org/pub/NetBSD/misc/macallan/sparc/netbsd.poteen.no_sx.gz
same thing, without sx. Just to see if the issues you're seeing are
caused by the cg14 or by the acceleration code. I'm fairly sure it's
the latter but since I can't reproduce it I have to make sure.

That one panics and gives me a "db>" prompt. Output is attached. I didn't upload a core dump, because i have no swap partition,
and in hope you could make sense of the debuggers bt. Tell me if a coredump is necessary.

That's a bug I need to fix. Probably a typo.

Post by v***@bubbleverse.eu
Another thing: Wscons doesn't come up on the screen when i set output-device and input-device to a serial port in OBP.
Instead the screen shows a checkerboard pattern. I guess that at least the first part is normal behaviour but i thought i'd
mention it.

I never tested that ( never got around to get the right cables )
OBP probably skips some setup steps that our driver relies on if it's not the console.

have fun
Michael

[Michael]

Hello,

On Fri, 18 Apr 2014 17:46:55 +0200

Post by v***@bubbleverse.eu
On Thu, 17 Apr 2014 17:03:43 -0400

Post by Michael
ftp://ftp.netbsd.org/pub/NetBSD/misc/macallan/sparc/netbsd.poteen.gz
this one does a little more explicit hardware setup ( on the cg14 side
) instead of relying on OBP.

sx0: architecture rev. 27 chip rev. 0

I uploaded a new kernel with a possible fix:
ftp://ftp.netbsd.org/pub/NetBSD/misc/macallan/sparc/netbsd.poteen.gz

Background: SX instructions that reference memory are written to a
special address space with the same offset as the physical address they
reference, so one 32bit write transports effectively two 32bit values.
According to the manual the lower 3 bit of the address are ignored and
have to be added as an offset to the instruction itself.
On mine ( a rev. 25 ) that's exactly what happens, yours seems to
ignore instructions written to addresses that aren't 64bit aligned,
which would explain why every other column of characters is missing -
the font is 12 pixels wide. I bet you'd see either all or no characters
missing with an 8 bit wide font.
The new kernel just explicitly zeroes those bits.

have fun
Michael

[v***@bubbleverse.eu]

Hi,

On Wed, 23 Apr 2014 04:27:06 -0400

Post by Michael
ftp://ftp.netbsd.org/pub/NetBSD/misc/macallan/sparc/netbsd.poteen.gz
Background: SX instructions that reference memory are written to a
special address space with the same offset as the physical address they
reference, so one 32bit write transports effectively two 32bit values.
According to the manual the lower 3 bit of the address are ignored and
have to be added as an offset to the instruction itself.
On mine ( a rev. 25 ) that's exactly what happens, yours seems to
ignore instructions written to addresses that aren't 64bit aligned,
which would explain why every other column of characters is missing -
the font is 12 pixels wide. I bet you'd see either all or no characters
missing with an 8 bit wide font.
The new kernel just explicitly zeroes those bits.

My attempts to set a different font failed:
# wsfontload -N test -e ibm -w 8 -h 8 -v /usr/share/wscons/fonts/vt220l.808
# wsconsctl -dw font=test
wsconsctl: WSDISPLAYIO_SFONT: Invalid argument

However, the kernel you uploaded produces a correctly working wscons screen. X isn't working correctly yet, so i guess the xf86-video-suncg14 driver needs similar changes.

Is the manual you are refering to available to the public?

- Victor

[Michael]

Hello,

On Wed, 23 Apr 2014 17:26:29 +0200

Post by v***@bubbleverse.eu
On Wed, 23 Apr 2014 04:27:06 -0400

Post by Michael
ftp://ftp.netbsd.org/pub/NetBSD/misc/macallan/sparc/netbsd.poteen.gz
Background: SX instructions that reference memory are written to a
special address space with the same offset as the physical address they
reference, so one 32bit write transports effectively two 32bit values.
According to the manual the lower 3 bit of the address are ignored and
have to be added as an offset to the instruction itself.
On mine ( a rev. 25 ) that's exactly what happens, yours seems to
ignore instructions written to addresses that aren't 64bit aligned,
which would explain why every other column of characters is missing -
the font is 12 pixels wide. I bet you'd see either all or no characters
missing with an 8 bit wide font.
The new kernel just explicitly zeroes those bits.

# wsfontload -N test -e ibm -w 8 -h 8 -v /usr/share/wscons/fonts/vt220l.808
# wsconsctl -dw font=test
wsconsctl: WSDISPLAYIO_SFONT: Invalid argument

Yeah, few drivers actually implement that. Some day I'll have to look into it.

Post by v***@bubbleverse.eu
However, the kernel you uploaded produces a correctly working wscons
screen. X isn't working correctly yet, so i guess the
xf86-video-suncg14 driver needs similar changes.

I'm sure it does - zeroing those bits is additional work which on my
hardware isn't necessary so I very likely skipped it in most cases.

Post by v***@bubbleverse.eu
Is the manual you are refering to available to the public?

Unfortunately it's not. Registers and most of the instructions are
documented in sys/arch/sparc/dev/sxreg.h though.

have fun
Michael

[Michael]

Hello,

On Wed, 23 Apr 2014 17:26:29 +0200

Post by v***@bubbleverse.eu
However, the kernel you uploaded produces a correctly working wscons
screen. X isn't working correctly yet, so i guess the
xf86-video-suncg14 driver needs similar changes.

I finally got around to hack up the Xorg driver:
ftp://ftp.netbsd.org/pub/NetBSD/misc/macallan/sparc/suncg14_drv.so.1.gz

Please give it a try.

If it works properly please enable Xrender acceleration ( Option
"XRender" "true" in the Device section ) and run x11perf -aaftext.
I'm curious if there are any performance differences between r25 and
r27 SX.
Xrender support isn't complete, just enough to draw icons, anti-aliased
text etc. in gtk2 and QT3 applications. What's missing is mostly stuff
like transformations and some mask operations.

have fun
Michael

[v***@bubbleverse.eu]

Hi,

On Sun, 27 Apr 2014 10:04:50 -0400

Post by Michael
ftp://ftp.netbsd.org/pub/NetBSD/misc/macallan/sparc/suncg14_drv.so.1.gz
Please give it a try.
If it works properly please enable Xrender acceleration ( Option
"XRender" "true" in the Device section ) and run x11perf -aaftext.
I'm curious if there are any performance differences between r25 and
r27 SX.

It does work indeed. x11perf -aaftext says the following:
without xrender:
Sync time adjustment is 1.7279 msecs.

24000 reps @ 0.2883 msec ( 3470.0/sec): Char in 80-char aa line (Courier 12)
24000 reps @ 0.2882 msec ( 3470.0/sec): Char in 80-char aa line (Courier 12)
24000 reps @ 0.3069 msec ( 3260.0/sec): Char in 80-char aa line (Courier 12)
24000 reps @ 0.2880 msec ( 3470.0/sec): Char in 80-char aa line (Courier 12)
24000 reps @ 0.2898 msec ( 3450.0/sec): Char in 80-char aa line (Courier 12)
120000 trep @ 0.2923 msec ( 3420.0/sec): Char in 80-char aa line (Courier 12)

with xrender:
Sync time adjustment is 1.8104 msecs.

48000 reps @ 0.1042 msec ( 9590.0/sec): Char in 80-char aa line (Courier 12)
48000 reps @ 0.1043 msec ( 9590.0/sec): Char in 80-char aa line (Courier 12)
48000 reps @ 0.1132 msec ( 8840.0/sec): Char in 80-char aa line (Courier 12)
48000 reps @ 0.1043 msec ( 9590.0/sec): Char in 80-char aa line (Courier 12)
48000 reps @ 0.1063 msec ( 9410.0/sec): Char in 80-char aa line (Courier 12)
240000 trep @ 0.1064 msec ( 9390.0/sec): Char in 80-char aa line (Courier 12)

That's with the non-smp kernel you compiled. The userland is NetBSD 6.99.26(except for the suncg14_drv.so.1). The video mode is r1280x1024x66. If i'm reading that correctly, the improvement i'm seeing isn't quite as distinct as the one you wrote about in your blog entry[1]. Maybe that's because of the slower cpu, yet, during the test with xrender enabled, not all cpu time was used.

Currently i'm building a smp kernel and as soon you commited the changes to the suncg14 x11 driver, an up-to-date userland will follow. Ultimately i'll be on the watch for a cheap hypersparc module. Maybe one of these factors will make a difference in the benchmark.

Nevertheless, NetBSD is now perfectly useable on that machine for me. Thanks for the work you spent on that.

- Victor

[1]: https://blog.netbsd.org/tnf/entry/sx_support_added

[Michael]

Hello,

On Mon, 28 Apr 2014 06:19:37 +0200

Post by v***@bubbleverse.eu
On Sun, 27 Apr 2014 10:04:50 -0400

Post by Michael
ftp://ftp.netbsd.org/pub/NetBSD/misc/macallan/sparc/suncg14_drv.so.1.gz
Please give it a try.
If it works properly please enable Xrender acceleration ( Option
"XRender" "true" in the Device section ) and run x11perf -aaftext.
I'm curious if there are any performance differences between r25 and
r27 SX.

Sync time adjustment is 1.7279 msecs.
Sync time adjustment is 1.8104 msecs.
That's with the non-smp kernel you compiled. The userland is NetBSD
6.99.26(except for the suncg14_drv.so.1). The video mode is
r1280x1024x66. If i'm reading that correctly, the improvement i'm
seeing isn't quite as distinct as the one you wrote about in your blog
entry[1]. Maybe that's because of the slower cpu, yet, during the test
with xrender enabled, not all cpu time was used.

That's odd, font rendering should be mostly done by the SX, only
completely opaque and completely transparent pixels are handled by the
CPU ( Because in those cases we can either skip them entirely or just
draw the source pixel unmodified, without all those time consuming
multiplications. Maybe I'm underestimating SX's multipliers though.)
Then again, that's the majority. Maybe I should let SX handle them in
order to avoid CPU access to uncached video memory.

Post by v***@bubbleverse.eu
Currently i'm building a smp kernel and as soon you commited the
changes to the suncg14 x11 driver, an up-to-date userland will follow.
Ultimately i'll be on the watch for a cheap hypersparc module. Maybe
one of these factors will make a difference in the benchmark.

I've got two 125MHz ones, anything faster seems to get ridiculously
expensive. SMP is unstable on HyperSPARCs though, we're not sure why.

Post by v***@bubbleverse.eu
Nevertheless, NetBSD is now perfectly useable on that machine for me.
Thanks for the work you spent on that.

You're welcome, and thanks for testing & feedback.

have fun
Michael

[v***@bubbleverse.eu]

On Fri, 11 Apr 2014 21:24:23 -0400

Post by Michael
This is odd, last time I tried ( that was a few months ago ) it worked just fine.

It's no regression then, because i've tried netbsd-current somewhen in the middle of 2013 with the same problem but no time to look at it.

Post by Michael
Your log shows an 8MB VSIMM, which is what I'm using. Does this happen
with a non-MP kernel as well? ( just to rule it out, right now I can't
really think of anything that could cause this )

Non-mp GENERIC makes no difference.

Post by Michael
Hmm. All drawing is done through the SX, so if some glyphs show up
we're at least feeding it correctly and it's scribbling into actual
video memory. I assume the kernel is a stock GENERIC.MP from netbsd.org?
Any chance you could send me a picture?

It's the GENERIC.MP from netbsd.org's cvs HEAD.

I attached 3 images. The first shows the screen just after bootup, the second shows the screen after scrolling up or down completely, on the last one i scrolled half up.

Post by Michael
Does it manage to clear the screen on attach?

Yes.

I just tested different video modes by setting output-device to screen:mode in OBP. With r1024x768x60, r1024x768x70, scrolling works. With r1280x1024x66 and r1280x1024x76m it doesn't.

Thank you for your help so far and the fast reply.

- Victor