Re: New Debian sparc64 test kernel for stack corruption issue
Hi Adrian!
sorry for the delay, but $DAYJOB and actual coding in GNUSstep do take
over on system hacking...
John Paul Adrian Glaubitz wrote:
I have not seen that crash on any of my machines, so I'm really
wondering where it comes from.
I remember we had some testing about the issue on Niagara T1... I should
dig in bast conversations.
Take in consideration that on this sytem my sweet spot for kernel is:
6.12.38+deb13-sparc64-smp
Would you be able to bisect this?
Not immediatly. Do you mean by cloing out git of kernel.org?
Or can I test various ready deb files already archived?
Issue could be in code as well as some configuration changes.
I can test some of the available kernels.. I think some are yours some
debians.
Can I distinguish them with the "deb" ? There is also the issue that my
boot partition can hold a finite number of kernels, so I need to
uninstall some. I had more, but I removed some to make place for your
lates tones.
Of course, it is easy if there are just .deb files to be
uninstalled/reinstalled.
For a ballpark of the issue, I have:
6.8.12-sparc64-smp - > works
6.12.38+deb13-sparc64-smp -> works
6.12+unreleased-sparc64-smp -> doesn't work (where does this kernel come
from??)
6.16.12+deb14-sparc64-smp -> doesn't work
and of course, your kernel doesn't work either.
Out of curiosity, can you try reinstalling the openssh-server package?
# apt install --reinstall openssh-server
This causes crashes for me with certain kernels on UltraSPARC III.
On the Ultra IIe I just tried:
Preconfiguring packages ...
(Reading database ... 56583 files and directories currently installed.)
Preparing to unpack .../openssh-server_1%3a10.2p1-2_sparc64.deb ...
Unpacking openssh-server (1:10.2p1-2) over (1:10.2p1-2) ...
Setting up openssh-server (1:10.2p1-2) ...
ssh.socket is a disabled or a static unit not running, not starting it.
multix@debian-sparc64:~$
no kernel crash. I previously, diligently, installed also a telnetd
server so i can access the system beyond serial console in case of ssh
issues!
(It is safe, not NAT'd out of my LAN anyway)
We can look into this later, this is not a kernel but a bootloader problem.
Do you think it is GRUB? IIRC it affects also the Ultra2. I did not test
this kernel, because old Ultra (and SparcStation) cases are becoming
brittle due to PC+ABS cristallization... and to my sadness also the
Netra T1 Panel during this deep test process (I tested also OpenBSD and
NetBSD which now I have fully functional instead of older Solaris, a
quite nice comparison). I also exchanged most of NVRAM chips, I got a
couple of NOS of more recent manufacture. Unfortunately one did not work
or anyway somehow cooked.... need to check that. It made things quite
more convenient.
Would be nice to look at it, but if it is so "separate thread" from the
kernel stuff then. I am unsure how the mapping of SCSI targets is going
on there.
Riccardo
Reply to: