Re: New test kernel - second attempt
Hi Adrian,
John Paul Adrian Glaubitz wrote:
I can therefore only recommend to verify your hardware first and address
any issues with empty NVRAM batteries which may lead to incorrect NVRAM
contents. We have had one user reporting stability issues resolved after
resetting the SP on his T5240, see [1].
So, it's really not too far fetched to think your problems may indicate
a problem with your hardware. That's why you have to make sure everything
is working properly, including the NVRAM.
Actually, on heavy-stress NetBSD choked! it never did in the past years.
so time to look at it.
Could be... one never knows. Today I spent time with the Netra T1 to get
it back on track. I got two new RAM sticks. The Battery hack I did
Friday seems to hold quite well, content remains stored, RTC worked over
the weekend.
What I rembered is that I did not "set-defaults" before working on it...
content seemed good to boot, for safety, I redid it.
I discovered that Not all RAM DIMMS combinations were good and that a
NVRAM reset even improved things, very strange, but that it is.
Things like two new DIMMS did not work as "upper" two slots, but left
alone in the first two slots were fine. But old DIMMs put in upper
resulted in a stable system with NetBSD. I stress tested it and for sure
enough I used enough RAM as well as I let diag run at boot. Good thing,
also, the reliable system I need as NFS server and lots of things is back.
I ordered some new NVRAM chips though, we shall see how new ney will be
and if it is worth changing my hacked one. Also I want to improve my
hack with a battery holder in the future.
All variants of the UltraSPARC I and II CPUs use the same assembler
optimizations in the Linux kernel. There is no code optimized specifically
for UltraSPARC II or even variants of it.
Sure, there are no specific compiler optimizations, but I wonder if they
are really the same and what could change in the machines.
In theory, just cache sizes, CPU speed.. and possibly other minor things
(e.g. if one board accepts 1GB modules, the other only 512MB ones, sure
some details differ).
Strong of an apparently goot Netra T1 with NetBSD 10.1, I tried the
linux disk again.
I stressed the old kernel a bit:
6.1.0-9-sparc64 #1 Debian 6.1.27-1 (2023-05-08) sparc64 GNU/Linux
And this time also on the Netra T1 it proves good: I recovered
filesystem journal, I can run apt-get upgrade, install things.
Regenerated ramdisk, etc Definitely "hold" this kernel version for
future safety.
Minor new kernel to test plus your 6.17 kernel, which choked on fsck /
journal replay (but now fixed with 6.1 kernel).
Newly installed mainline kernel:
Loading Linux 6.16.8+deb14-sparc64 ...
/dev/sda2: clean, 43801/1011840 files, 1131402/4047104 blocks
[FAILED] Failed to mount boot.mount - /bo
ot.
[DEPEND] Dependency failed for local-fs.target - Local File Systems.
You are in emergency mode. After logging in, type "journalctl -xb" to view
system logs, "systemctl reboot" to reboot, or "exit"
to continue bootup.
Enter root password for system maintenance
(or press Control-D to continue):
reboot 6.1 - comes up clean!
Loading Linux 6.17.0-rc5+ ...
Loading initial ramdisk ...
/dev/sda2: clean, 43801/1011840 files, 1131402/4047104 blocks
[FAILED] Failed to mount boot.mount - /bo
ot.
[DEPEND] Dependency failed for local-fs.target - Local File Systems.
You are in emergency mode. After logging in, type "journalctl -xb" to view
system logs, "systemctl reboot" to reboot, or "exit"
to continue boEnter root password for system maintenance
(or press Control-D to continue):
Another reboot into 6.1 - all fine!
Now, a bit more confident about my hardware, I would say stock 6.16 and
your 6.17 do have issues on the T1 200 with IIe
Riccardo
Reply to: