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