SS20 Desktop: Kernel Issues

Over the past few weeks I’ve been continuing my work trying to get the latest NetBSD working on my Sparcstation 20. The system has been hanging and I’d had trouble working out why, so I turned to reading as much as I could to see if I could find any clues. I found in the mailing list someone suggesting that not all SCSI drives are co-operative with the on board controller when running a MP (multi-processor) kernel on later versions, so I looked through my collection of SCA drives to see if I had a different model I could try. I found I had an IBM Ultrastar disk that is around 18G in size, so I swapped the Fujitsu drive (model MAJ3182MC) out for it. Surprisingly this made my system behave much better, it would install, and run on the uni-processor kernel with no issues at all where the fujitsu drives seemed to cause the system to hang frequently under disk access.

However booting with a MP kernel still would hang within about 20 minutes or during disk access, so it was at this point I joined the mailing list to ask others what I could do to resolve the issue. The people on the list are quite friendly and have been very helpful in trouble shooting. It seems that there are some kernel bugs related to MP that are present in 7.1 that are at least partially resolved in more recent versions of the kernel. Like most open source OS’s the current stable release is behind by a version or two from where the developers are currently working. It seems that there is some possibility of the fix being back-ported to 7.1, I tested out a patched MP kernel that was greatly improved in this respect. It still hung, but after a much longer period of time, and only when provoked by a specific program. Feedback from the mailing list also seems to indicate that choosing not to use the on board SCSI is another way that I could work around the problem.

So I now have multiple options for running my system. I could switch to using a single processor, I’d have the option of either a 60Mhz SuperSparc (currently installed with a dual 50Mhz module) or 75Mhz Ross HyperSparc, and everything should work well. Alternatively I could acquire an SBus SCSI card to connect my hard drives, or forgo a local disk entirely by using networking booting and a NFS share, both avoiding having to use the on board SCSI. Finally I could use the system as it is now with the patched 7.1 kernel, it worked well enough that this is quite feasible. I’m leaning towards booting the machine over the network at the moment.

In the short term with Christmas approaching, I’ll be putting the project aside until I have more time in the new year.

5 Responses to “SS20 Desktop: Kernel Issues”

  1. 1 V
    December 16, 2017 at 5:14 am

    Hi. Can you tell me please about a game name of Soleau ? It is about the player hidding from securities cameras ingame trying to get out.

    • December 16, 2017 at 2:14 pm

      Um I guessing you intended to post this here… but anyhow I don’t remember a game that had that as a feature. There are a lot of soleau games (31 published) so you should take a look on their website, or on the classic dos games website to see if you can find it.

      • 3 V
        December 21, 2017 at 6:29 pm

        Thanks. It was like ballon challenge, but the player whas moving inside the terrain and hides behind blicks or the upper and lower blocks wich moves only straight will go to you if you are in site. A small box shows the action when the player is captured.

  2. March 22, 2018 at 5:17 am

    SMP support for sun4m got broken in NetBSD 5.0 (worked fine in 2.0, 3.0 and 4.0.2), due to the large-scale kernel reorganisation done for 5.0. At the time, I waited very patiently, monitoring the port-sparc mailing-list, as it seemed that a re-fix would make it into 6.0 (developer conversations around 5.99 seemed to have pinpointed the two major causes of trouble), but 6.0 didn’t fly SMP either, at which point I gave up :-(.

    One of the problem areas was a newly revealed race-condition in the SBus-esp-controller driver which effected SMP HyperSPARC systems, which is probably where the advice to avoid the on-board SCSI comes from. However, that particular issue *would not* effect SMP SuperSPARC, thus that particular piece of advice just might be bogus for your situation. Quite apart from that, there were several other sun4m-SMP-bugs in the 5.x and 6.x kernels, anyway.

    If your patience is wearing thin, you might want to take a closer look at NetBSD 4.x, or even OpenBSD (peripheral device support is not as broad, but SuperSPARC SMP appears to be rock-solid). Failing that, it might be time to (sigh) return to Solaris (avoid 2.5 if using HyperSPARC, there is a performance-hit there; 2.6 has a fixed page-coloring algorithm which doesn’t unnecessarily penalise HyperSPARC).

    PS: there were no 75MHz HyperSPARCs – there were 40MHz (half a dozen Ross-internal test modules manufactured, only one left surviving as of 2001), 55, 66, 72, 80 (very rare), 90, 100, 110, 125, 133, 142, 150, 166 (rare), 180 and 200MHz. In my experience, in terms of sufficient-speed-without-tendency-to-overheat in an SS10, the 133MHz single-CPU modules are the dogs’ doodads, although in the somewhat roomier SS20 (!), a 150 or 200 would probably be OK.

    • March 22, 2018 at 7:40 am

      You’re right, I thought the module I have is 75Mhz, turns out it’s actually 90Mhz. I bought a single module quite some time ago to try out, it might be worth running it as a single processor over the three CPUs I currently have installed. Currently I have two 50Mhz and a 60Mhz SuperSPARC. I wonder if the smaller cache size on the HyperSPARC module will make much performance difference?

      I used to run NetBSD 4.x on it before and I can confirm that it worked flawlessly, I used to use it as a http/svn/openvpn server for quite a while before I got a framebuffer, mouse and keyboard. The problem with the older version is of course building packages etc for it. I spose if you’re happy using old versions of everything it would work perfectly fine.

      I think this bug is related to the esp on board device, as a patch they provided to try out did improve things quite a bit, and every bit of testing I did seemed to indicate the disks were the culprit. At one stage I had to change the model of drive I was using as the fujitsu drives I had would even crash the system with a uni-processor kernel. Clearly the esp driver needs work, and it seems many others on the mailing list aren’t using the on-board SCSI, perhaps to avoid issues. With workloads that don’t involve much disk access the system works much better.

      Unfortunately I haven’t got a copy of Solaris, I wouldn’t mind trying it out as I had only ever really used it on big machines at uni as an end user. I used to do my programming assignments in java on them. OpenBSD is an option I suppose, but I wasn’t that impressed when I tried it out on another of my sun machines, but it could be worth a shot.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Enter your email address to follow this blog and receive notifications of new posts by email.

Mister G Kids

A daily comic about real stuff little kids say in school. By Matt Gajdoš

Random Battles: my life long level grind

completing every RPG, ever.

Gough's Tech Zone

Reversing the mindless enslavement of humans by technology.

Retrocosm's Vintage Computing, Tech & Scale RC Blog

Random mutterings on retro computing, old technology, some new, plus radio controlled scale modelling.


retro computing and gaming plus a little more

Retrocomputing with 90's SPARC

21st-Century computing, the hard way

%d bloggers like this: