On 5/17/21 12:36 PM, Robin Cremer wrote: >>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/sparc?id=e5e8b80d352ec999d2bba3ea584f541c83f4ca3f > I'm using the latest version from the repositories: >> 5.10.0-6-sparc64-smp #1 SMP Debian 5.10.28-1 (2021-04-09) sparc64 GNU/Linux > The commit you mention seems to be in 5.12 and 5.13-rc2? > Is there a pre-built SMP-image for this or do I have to set up building > myself?
The commit has been backported to the 5.10.x series which is an LTS kernel: > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/arch/sparc?h=linux-5.10.y&id=f2b38f03a3f71c30c77a4516b26c8bea13cc08ce > Running on the v215 was a real nightmare yesterday. They will be stable for > hours, but > certain actions (in one occurence executing dmesg (!), apt-get installing > nfs-common, > some mounts systemd tries) crashed both of the boxes with various errors, > most of them the > dreaded line with "p Try to use a 4.19 kernel from snapshot.debian.org, these are known to run more stable on the older machines. Any machine older than T2 seem to have some issues with the more recent kernels. If you have the possibility to bisect the issue, that would be great. I do have such older machines myself but currently no possibility to set them up for bisecting. On the newer CPUs (>= SPARC T2), the kernel runs stable. Dave Miller (the Linux SPARC maintainer) uses a T5 himself for testing. > Retrying the dpkg-reconfigure as well. After the systemd-unit for - I think - > rpcbind was activated > during package configuration, both boxes crashed about 4-6 times, I had to > reset from OBP. > After a few tries, installation went through, then. Now I can mount nfs... > The hours I spent in the rescue mode of the current installation CD without > any trouble made me suspect > that non-SMP-kernels are "more stable". I'm currently running the SMP variant > with "maxcpus=1", that > seems stable so far... But as with any other sporadic issue, that's hard to > tell with a way to reliably > trigger the errors... I think these issues have started to show up sometime after 4.19 but only on the older machines. So, chances are you can bisect the issue. > On a not entirely unrelated note: > Are there any news on functioning netboot images? The last post I could find > points to images from April '17 > on your webspace, which were, according to the ML, not bootable because of > the size. I don't have the time and resources at the moment to work on netboot. I'm not just maintaining the sparc64 port in Debian but also many of the other unofficial ports such as 32-bit PowerPC. So far, netboot has not been a top priority so I haven't worked on it yet. Additional support is always welcome. > At least I can't boot them either. > If there is no more recent version, I'll try to build something myself - are > there any pointers on how to go > about this? Minimal OS or the netinstaller in an .img would be preferred. You just have to build the debian-installer package on sparc64 using sbuild and as a result, you will get the tarball containing the netboot and cdrom images. > I think that would help in quick testing, as I have multiple other systems > with Cheetah (UltraSPARC III, III CU > and IIIi) I'd like to try provoking the panics on. Also, some older > (UltraSPARC IIi and IIe+) systems are waiting > for recent Debian :-) For these machines, I would recommend installing a regular release, then downgrading the kernel to 4.19, then bi-sect using a cross-compiled kernel if you have a working reproducer. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
