Re: Kernel panic not printing a call trace?

2021-05-13 Thread John Paul Adrian Glaubitz
On 5/13/21 4:49 AM, Rich wrote: > I'm mostly curious about whether anyone knows why the Call Trace might > be empty - I see the message about corrupted stack end above it, but > from what I can see online, plenty of people get that message and a > call trace printout below it (...on other

Kernel panic not printing a call trace?

2021-05-12 Thread Rich
Hi all, So, I got my earlier system running sparc64 using a terrible method (from inside the existing sparc install, mount -o remount,ro /; nc -l | dd of=/dev/sda [...] an image generated in a VM, reboot and pray), but now I'm doing the thing I actually wanted a sparc64 system for (testing a

Re: Re: Network installing a Netra T1?

2021-05-10 Thread Hermann . Lauer
Hello Rich, > > On 5/9/21 3:24 PM, Rich wrote: > > > I tried just handing it vmlinux from > > > https://cdimage.debian.org/cdimage/ports/debian-installer/2021-04-17/sparc64/debian-installer-images_20210415_sparc64.tar.gz > > > over TFTP, but that just dies with "fast Data Access MMU Miss" before

Re: Network installing a Netra T1?

2021-05-09 Thread Rich
bHi Adrian! On Sun, May 9, 2021 at 9:26 AM John Paul Adrian Glaubitz wrote: > > Hello Rich! > > On 5/9/21 3:24 PM, Rich wrote: > > I tried just handing it vmlinux from > > https://cdimage.debian.org/cdimage/ports/debian-installer/2021-04-17/sparc64/debian-installer-images_20210415_sparc64.tar.gz

Re: Network installing a Netra T1?

2021-05-09 Thread John Paul Adrian Glaubitz
Hello Rich! On 5/9/21 3:24 PM, Rich wrote: > I tried just handing it vmlinux from > https://cdimage.debian.org/cdimage/ports/debian-installer/2021-04-17/sparc64/debian-installer-images_20210415_sparc64.tar.gz > over TFTP, but that just dies with "fast Data Access MMU Miss" before > ever

Network installing a Netra T1?

2021-05-09 Thread Rich
Hi! (Forgive me if this is well-answered somewhere, but I did some searching, and did not come upon it.) I have a Netra T1 running the old Debian sparc port. I wanted to reinstall it with the sparc64 port, but it does not have a cdrom, and I do not seem to grasp how to netboot the Debian

Re: Update Debian Ports installation images 2021-04-14

2021-04-26 Thread Dennis Clarke
On 4/19/21 08:31, John Paul Adrian Glaubitz wrote: > On 4/19/21 2:13 PM, Dennis Clarke wrote: >> I have done some testing with an old Netra server and everything seems >> fine with the exception of gdb which is broken. Seems to be fixed for >> the gdb 10.2 release which is coming any day real

Re: Update Debian Ports installation images 2021-04-14

2021-04-19 Thread John Paul Adrian Glaubitz
On 4/19/21 2:13 PM, Dennis Clarke wrote: > I have done some testing with an old Netra server and everything seems > fine with the exception of gdb which is broken. Seems to be fixed for > the gdb 10.2 release which is coming any day real soon now : > > Bug 27750 - local variables have wrong

Re: Update Debian Ports installation images 2021-04-14

2021-04-19 Thread Dennis Clarke
On 4/14/21 5:07 PM, John Paul Adrian Glaubitz wrote: > Hello! > > I just uploaded updated Debian Ports installation images that were > created today and ship with the latest Debian unstable kernel (5.10) > and all other packages updated to their latest version in Debian > unstable. > > If you

Update Debian Ports installation images 2021-04-14

2021-04-14 Thread John Paul Adrian Glaubitz
Hello! I just uploaded updated Debian Ports installation images that were created today and ship with the latest Debian unstable kernel (5.10) and all other packages updated to their latest version in Debian unstable. If you test these images, please let me know if you run into any issues.

Re: 5.10.0-4-sparc64-smp #1 Debian 5.10.19-1 crashes on T2000

2021-04-01 Thread Riccardo Mottola
Hi Anatoly! Anatoly Pugachev wrote: > current grub2 version does not support compressed image kernels, do > the following: > > gzip -dc /boot/vmlinuz-5.12.0-rc5+ > /boot/vmlinux-5.12.0-rc5+ > rm /boot/vmlinuz-5.12.0-rc5+ > update-grub > > and reboot oh yes, that was it. Finally, I could boot my

Re: 5.10.0-4-sparc64-smp #1 Debian 5.10.19-1 crashes on T2000

2021-04-01 Thread Anatoly Pugachev
On Thu, Apr 1, 2021 at 2:40 PM Riccardo Mottola wrote: > multix@narya:~/code/linux-stable$ time sudo make install > sh ./arch/sparc/boot/install.sh 5.12.0-rc5+ arch/sparc/boot/zImage \ > System.map "/boot" > run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 5.12.0-rc5+ >

Re: Re: 5.10.0-4-sparc64-smp #1 Debian 5.10.19-1 crashes on T2000

2021-04-01 Thread Hermann Lauer
Hi Riccardo, On Thu, Apr 01, 2021 at 01:43:29PM +0200, Riccardo Mottola wrote: > > Yep, in your kernel config set: > > CONFIG_SYSTEM_TRUSTED_KEYS="" > > thanks, that was it! Now the kernel build great! > Do I need to do somethings special? > > make install > make modules_install sorry, don't

Re: 5.10.0-4-sparc64-smp #1 Debian 5.10.19-1 crashes on T2000

2021-04-01 Thread Riccardo Mottola
Hhi Hermann, hermann.la...@uni-heidelberg.de wrote: > Yep, in your kernel config set: > CONFIG_SYSTEM_TRUSTED_KEYS="" thanks, that was it! Now the kernel build Do I need to do somethings special? make install make modules_install Which shows: multix@narya:~/code/linux-stable$ time sudo make

Re: 5.10.0-4-sparc64-smp #1 Debian 5.10.19-1 crashes on T2000

2021-04-01 Thread Anatoly Pugachev
On Thu, Apr 1, 2021 at 12:59 PM Riccardo Mottola wrote: > > This seems to only happen when the machines do a long run with high > > workload and seemingly not when i just power them off again for night > > with no high workload. > > I have a limited experience and can only share that the kernel I

Re: 5.10.0-4-sparc64-smp #1 Debian 5.10.19-1 crashes on T2000

2021-04-01 Thread Riccardo Mottola
Hi Connor, Connor McLaughlan wrote: > can anyone possible give a list of known stable kernel versions for > SPARC machines? (is there a difference necessary between > architectures/old vs. newer machines? sun4u/sun4v)? > > Also this instability manifests such that the machine is crashing > during

Re: Re: 5.10.0-4-sparc64-smp #1 Debian 5.10.19-1 crashes on T2000

2021-03-29 Thread Hermann . Lauer
Hi Riccardo, On Sat, Mar 27, 2021 at 01:16:11PM -0600, Stan Johnson wrote: > > I took the config out of /boot/config of a good kernel, updated it with > > "make oldconfig" > > > > During compilation I see: > > > >   CC  init/init_task.o > > make[1]: *** No rule to make target > >

Re: 5.10.0-4-sparc64-smp #1 Debian 5.10.19-1 crashes on T2000

2021-03-27 Thread Stan Johnson
Hi Riccardo, On 3/26/21 6:21 PM, Riccardo Mottola wrote: > Hi, > ... > > I cloned linux stable. It took 60 minutes... > > I took the config out of /boot/config of a good kernel, updated it with > "make oldconfig" > > During compilation I see: > >   CC  init/init_task.o > make[1]: *** No

Re: 5.10.0-4-sparc64-smp #1 Debian 5.10.19-1 crashes on T2000

2021-03-26 Thread Riccardo Mottola
Hi, I was unable to "hack" for some days due to day-job. I have seen Frank and others have done a great deal. Still, I wanted to try my own compilation, as a first attempt and also to build and be able to check eventual patches myself. On 3/11/21 11:56 PM, Gregor Riepl wrote: You should

Re: Regression in 028abd92 for Sun UltraSPARC T1

2021-03-25 Thread Christoph Hellwig
I have to admit I'm completely lost at this point. This new trace looks totally strange to me, and I'm pretty sure whatever symptoms you see are due to different alignments / code sections etc just triggered by the removal, we need help from the real sparc experts.

Re: Regression in 028abd92 for Sun UltraSPARC T1

2021-03-24 Thread Frank Scheiner
On 24.03.21 17:33, Frank Scheiner wrote: On 24.03.21 17:10, Christoph Hellwig wrote: On Wed, Mar 24, 2021 at 04:58:39PM +0100, Frank Scheiner wrote: [   20.090279] [<006c6494>] sys_mount+0x114/0x1e0 [   20.090338] [<006c6454>] sys_mount+0xd4/0x1e0 [   20.090499]

Re: Regression in 028abd92 for Sun UltraSPARC T1

2021-03-24 Thread Frank Scheiner
On 24.03.21 17:10, Christoph Hellwig wrote: On Wed, Mar 24, 2021 at 04:58:39PM +0100, Frank Scheiner wrote: [ 20.090279] [<006c6494>] sys_mount+0x114/0x1e0 [ 20.090338] [<006c6454>] sys_mount+0xd4/0x1e0 [ 20.090499] [<00406274>] linux_sparc_syscall+0x34/0x44 [

Re: Regression in 028abd92 for Sun UltraSPARC T1

2021-03-24 Thread Christoph Hellwig
On Wed, Mar 24, 2021 at 04:58:39PM +0100, Frank Scheiner wrote: > [ 20.090279] [<006c6494>] sys_mount+0x114/0x1e0 > [ 20.090338] [<006c6454>] sys_mount+0xd4/0x1e0 > [ 20.090499] [<00406274>] linux_sparc_syscall+0x34/0x44 > [ 20.090697] Disabling lock debugging due

Re: Regression in 028abd92 for Sun UltraSPARC T1

2021-03-24 Thread Frank Scheiner
On 24.03.21 16:22, Jan Engelhardt wrote: On Wednesday 2021-03-24 14:57, Frank Scheiner wrote: (gdb) l *(sys_mount+0x114/0x1e0) 0x6c6380 is in __se_sys_mount (fs/namespace.c:3390). /0x1e0 does not normally belong there. Just l *(sys_mount+0x114) I guess this comes from my log

Re: Regression in 028abd92 for Sun UltraSPARC T1

2021-03-24 Thread Jan Engelhardt
On Wednesday 2021-03-24 14:57, Frank Scheiner wrote: > (gdb) l *(sys_mount+0x114/0x1e0) > 0x6c6380 is in __se_sys_mount (fs/namespace.c:3390). /0x1e0 does not normally belong there. Just l *(sys_mount+0x114)

Re: Regression in 028abd92 for Sun UltraSPARC T1

2021-03-24 Thread Frank Scheiner
On 24.03.21 09:28, Christoph Hellwig wrote: On Tue, Mar 23, 2021 at 11:17:41PM +0100, Frank Scheiner wrote: 028abd9222df0cf5855dab5014a5ebaf06f90565 ...is broken on my T1000. As I don't know how big attachments can be on this list, I put the logs on pastebin. A log for 028abd9222df is here:

Re: Regression in 028abd92 for Sun UltraSPARC T1

2021-03-24 Thread Frank Scheiner
On 24.03.21 14:24, Anatoly Pugachev wrote: On Wed, Mar 24, 2021 at 4:19 PM Frank Scheiner wrote: On 24.03.21 14:16, John Paul Adrian Glaubitz wrote: On 3/24/21 2:09 PM, Frank Scheiner wrote:> Kernel sources are not available on the T1000. If need be, where do they need to exist and how

Re: Regression in 028abd92 for Sun UltraSPARC T1

2021-03-24 Thread Anatoly Pugachev
On Wed, Mar 24, 2021 at 4:19 PM Frank Scheiner wrote: > On 24.03.21 14:16, John Paul Adrian Glaubitz wrote: > > On 3/24/21 2:09 PM, Frank Scheiner wrote:> Kernel sources are not available > > on the T1000. > >> > >> If need be, where do they need to exist and how should the directory be > >>

Re: Regression in 028abd92 for Sun UltraSPARC T1

2021-03-24 Thread Frank Scheiner
On 24.03.21 14:16, John Paul Adrian Glaubitz wrote: On 3/24/21 2:09 PM, Frank Scheiner wrote:> Kernel sources are not available on the T1000. If need be, where do they need to exist and how should the directory be named - `/usr/src/[...]`? Try installing "linux-source" and the "-dbg"

Re: Regression in 028abd92 for Sun UltraSPARC T1

2021-03-24 Thread John Paul Adrian Glaubitz
On 3/24/21 2:09 PM, Frank Scheiner wrote:> Kernel sources are not available on the T1000. > > If need be, where do they need to exist and how should the directory be > named - `/usr/src/[...]`? Try installing "linux-source" and the "-dbg" package for your Debian kernel. Adrian -- .''`.

Re: Regression in 028abd92 for Sun UltraSPARC T1

2021-03-24 Thread Frank Scheiner
On 24.03.21 09:28, Christoph Hellwig wrote: On Tue, Mar 23, 2021 at 11:17:41PM +0100, Frank Scheiner wrote: 028abd9222df0cf5855dab5014a5ebaf06f90565 ...is broken on my T1000. As I don't know how big attachments can be on this list, I put the logs on pastebin. A log for 028abd9222df is

Re: Regression in 028abd92 for Sun UltraSPARC T1

2021-03-24 Thread John Paul Adrian Glaubitz
Hello Frank! On 3/24/21 1:30 PM, Frank Scheiner wrote: > Sorry, but I can't install `gdb` on my T1000 ATM, because it depends on > "libpython3.8" for sparc64 (see [1]) and "libpython3.9" for the other > architectures, but "libpython3.8" is actually not available for sparc64, > "libpython3.9" is

Re: Regression in 028abd92 for Sun UltraSPARC T1

2021-03-24 Thread Frank Scheiner
On 24.03.21 13:42, Anatoly Pugachev wrote: On Wed, Mar 24, 2021 at 3:31 PM Frank Scheiner wrote: Sorry, but I can't install `gdb` on my T1000 ATM, because it depends on "libpython3.8" for sparc64 (see [1]) and "libpython3.9" for the other architectures, but "libpython3.8" is actually not

Re: Regression in 028abd92 for Sun UltraSPARC T1

2021-03-24 Thread Anatoly Pugachev
On Wed, Mar 24, 2021 at 3:31 PM Frank Scheiner wrote: > Sorry, but I can't install `gdb` on my T1000 ATM, because it depends on > "libpython3.8" for sparc64 (see [1]) and "libpython3.9" for the other > architectures, but "libpython3.8" is actually not available for sparc64, > "libpython3.9" is

Re: Regression in 028abd92 for Sun UltraSPARC T1

2021-03-24 Thread Frank Scheiner
On 24.03.21 09:28, Christoph Hellwig wrote: On Tue, Mar 23, 2021 at 11:17:41PM +0100, Frank Scheiner wrote: 028abd9222df0cf5855dab5014a5ebaf06f90565 ...is broken on my T1000. As I don't know how big attachments can be on this list, I put the logs on pastebin. A log for 028abd9222df is here:

Re: Regression in 028abd92 for Sun UltraSPARC T1

2021-03-24 Thread Christoph Hellwig
On Tue, Mar 23, 2021 at 11:17:41PM +0100, Frank Scheiner wrote: > 028abd9222df0cf5855dab5014a5ebaf06f90565 > > ...is broken on my T1000. > > As I don't know how big attachments can be on this list, I put the logs > on pastebin. > > A log for 028abd9222df is here: > > https://pastebin.com/ApPYsMcu

Re: Regression in 028abd92 for Sun UltraSPARC T1

2021-03-23 Thread Frank Scheiner
On 23.03.21 17:57, Christoph Hellwig wrote:> Frank, can you double check that commit 67e306c6906137020267eb9bbdbc127034da3627 really still works, and only 028abd9222df0cf5855dab5014a5ebaf06f90565 broke your setup? So I manually checked out both 67e306c6906137020267eb9bbdbc127034da3627 and

Re: Regression in 028abd92 for Sun UltraSPARC T1

2021-03-23 Thread Frank Scheiner
On 23.03.21 17:57, Christoph Hellwig wrote: On Tue, Mar 23, 2021 at 05:50:59PM +0100, Jan Engelhardt wrote: Some participants in the discussion over at the debian-sparc list mentioned "NFS" and "Invalid argument", which is something I know just too well from iptables. NFS is a filesystem that

Re: Regression in 028abd92 for Sun UltraSPARC T1

2021-03-23 Thread Christoph Hellwig
On Tue, Mar 23, 2021 at 05:50:59PM +0100, Jan Engelhardt wrote: > Some participants in the discussion over at the debian-sparc list mentioned > "NFS" and "Invalid argument", which is something I know just too well from > iptables. NFS is a filesystem that uses an extra data blob (5th argument to

Re: 5.10.0-4-sparc64-smp #1 Debian 5.10.19-1 crashes on T2000

2021-03-23 Thread Frank Scheiner
Hi, On 23.03.21 17:30, Connor McLaughlan wrote: Hi, can anyone possible give a list of known stable kernel versions for SPARC machines? (is there a difference necessary between architectures/old vs. newer machines? sun4u/sun4v)? Also this instability manifests such that the machine is

Re: Regression in 028abd92 for Sun UltraSPARC T1

2021-03-23 Thread Jan Engelhardt
On Monday 2021-03-22 22:55, Frank Scheiner wrote: >>> Riccardo Mottola first recognized a problem with 5.10.x kernels on his >>> Sun T2000 with UltraSPARC T1 (details in [this thread]). I could verify >>> the problem also on my Sun T1000 and it looks like this specific issue >>> breaks the

Re: 5.10.0-4-sparc64-smp #1 Debian 5.10.19-1 crashes on T2000

2021-03-23 Thread Connor McLaughlan
Hi, can anyone possible give a list of known stable kernel versions for SPARC machines? (is there a difference necessary between architectures/old vs. newer machines? sun4u/sun4v)? Also this instability manifests such that the machine is crashing during high workload? (halting? rebooting?) I

Re: 5.10.0-4-sparc64-smp #1 Debian 5.10.19-1 crashes on T2000

2021-03-23 Thread Frank Scheiner
Hi Jan, On 23.03.21 16:36, Jan Engelhardt wrote: On Tuesday 2021-03-23 16:29, Frank Scheiner wrote: ``` [...] Begin: Retrying nfs mount ... [ 41.753937] NFS: mount program didn't pass remote address mount: Invalid argument I seem to recall that NFS is one of those filesystems that (a)

Re: 5.10.0-4-sparc64-smp #1 Debian 5.10.19-1 crashes on T2000

2021-03-23 Thread Jan Engelhardt
On Tuesday 2021-03-23 16:29, Frank Scheiner wrote: >> >> while I was able to "install" correctly using a slightly older ISO, I >> get not a bootable system. The kernel appears to crash very early during >> boot. > > From my current testing it looks like "UltraSPARC IIIi"s are also > affected by

Re: 5.10.0-4-sparc64-smp #1 Debian 5.10.19-1 crashes on T2000

2021-03-23 Thread Frank Scheiner
Hi all, On 09.03.21 13:23, Riccardo Mottola wrote: Hi all, while I was able to "install" correctly using a slightly older ISO, I get not a bootable system. The kernel appears to crash very early during boot. Anybody else has this issue?   Booting `Debian GNU/Linux' Loading Linux

Re: Regression in 028abd92 for Sun UltraSPARC T1

2021-03-22 Thread Frank Scheiner
Hi, On 22.03.21 22:48, John Paul Adrian Glaubitz wrote: On 3/22/21 10:30 PM, Frank Scheiner wrote: Riccardo Mottola first recognized a problem with 5.10.x kernels on his Sun T2000 with UltraSPARC T1 (details in [this thread]). I could verify the problem also on my Sun T1000 and it looks like

Re: Regression in 028abd92 for Sun UltraSPARC T1

2021-03-22 Thread John Paul Adrian Glaubitz
Hello! On 3/22/21 10:30 PM, Frank Scheiner wrote: > Riccardo Mottola first recognized a problem with 5.10.x kernels on his > Sun T2000 with UltraSPARC T1 (details in [this thread]). I could verify > the problem also on my Sun T1000 and it looks like this specific issue > breaks the mounting of

Regression in 028abd92 for Sun UltraSPARC T1

2021-03-22 Thread Frank Scheiner
Dear all, Riccardo Mottola first recognized a problem with 5.10.x kernels on his Sun T2000 with UltraSPARC T1 (details in [this thread]). I could verify the problem also on my Sun T1000 and it looks like this specific issue breaks the mounting of the root FS or maybe mounting file systems at

Re: 5.10.0-4-sparc64-smp #1 Debian 5.10.19-1 crashes on T2000

2021-03-17 Thread Frank Scheiner
Hi Adrian, On 17.03.21 13:39, John Paul Adrian Glaubitz wrote: On 3/17/21 1:22 PM, Frank Scheiner wrote: ``` johndoe@x4270:~/git-projects/torvalds/linux$ git bisect bad 028abd9222df0cf5855dab5014a5ebaf06f90565 is the first bad commit [...] Did you verify that reverting this commit or - if

Re: 5.10.0-4-sparc64-smp #1 Debian 5.10.19-1 crashes on T2000

2021-03-17 Thread John Paul Adrian Glaubitz
Hi Frank! On 3/17/21 1:22 PM, Frank Scheiner wrote: > Hi Adrian, Riccardo > > so I'm finished with bisecting and it points to the following commit as > first bad commit: > > ``` > johndoe@x4270:~/git-projects/torvalds/linux$ git bisect bad > 028abd9222df0cf5855dab5014a5ebaf06f90565 is the first

Re: 5.10.0-4-sparc64-smp #1 Debian 5.10.19-1 crashes on T2000

2021-03-17 Thread Frank Scheiner
Hi Adrian, Riccardo so I'm finished with bisecting and it points to the following commit as first bad commit: ``` johndoe@x4270:~/git-projects/torvalds/linux$ git bisect bad 028abd9222df0cf5855dab5014a5ebaf06f90565 is the first bad commit commit 028abd9222df0cf5855dab5014a5ebaf06f90565 Author:

Re: 5.10.0-4-sparc64-smp #1 Debian 5.10.19-1 crashes on T2000

2021-03-16 Thread Frank Scheiner
Hi Adrian, On 16.03.21 14:27, John Paul Adrian Glaubitz wrote: Hello Frank! On 3/16/21 2:07 PM, Frank Scheiner wrote: After a first cross compile run, I can confirm that 5.10-rc1 is also broken on my T1000. I'll take this version (parent commit: 33def8498fdde180023444b08e12b72a9efed41d) as

Re: 5.10.0-4-sparc64-smp #1 Debian 5.10.19-1 crashes on T2000

2021-03-16 Thread John Paul Adrian Glaubitz
Hello Frank! On 3/16/21 2:07 PM, Frank Scheiner wrote: > After a first cross compile run, I can confirm that 5.10-rc1 is also > broken on my T1000. I'll take this version (parent commit: > 33def8498fdde180023444b08e12b72a9efed41d) as "bad". But taking v5.9 as > good means more than 5000 commits

Re: 5.10.0-4-sparc64-smp #1 Debian 5.10.19-1 crashes on T2000

2021-03-16 Thread Frank Scheiner
Hi again, On 16.03.21 14:07, Frank Scheiner wrote: @Adrian: After a first cross compile run, I can confirm that 5.10-rc1 is also broken on my T1000. I'll take this version (parent commit: 33def8498fdde180023444b08e12b72a9efed41d) as "bad". But taking v5.9 as good means more than 5000 commits in

Re: 5.10.0-4-sparc64-smp #1 Debian 5.10.19-1 crashes on T2000

2021-03-16 Thread Frank Scheiner
Hi Riccardo, Adrian, so I did some testing yesterday and also see your problem on my T1000. Because of some kernel command line misconfiguration, my machine at first couldn't find its root FS as it tried to use a non-existent NIC. This lead to a lot of kernel oopses (I assume at least one per

Re: update-grub and then grub-mkconfig leads to the watchdog: BUG: soft lockup

2021-03-15 Thread Dennis Clarke
On 3/15/21 9:38 AM, John Paul Adrian Glaubitz wrote: > Hello! > > On 3/15/21 10:34 AM, Anatoly Pugachev wrote: >>> + /usr/sbin/grub-probe --target=device / >>> + GRUB_DEVICE=/dev/sda2 >>> + /usr/sbin/grub-probe --device /dev/sda2 --target=fs_uuid >>> [ 1330.951329] watchdog: BUG: soft lockup -

Re: watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [systemd:1]

2021-03-15 Thread Anatoly Pugachev
On Fri, Mar 12, 2021 at 5:27 PM Dennis Clarke wrote: > > > I have seen this for a few months now. The old old netra machine will > run just fine endlessly but if I attempt to perform a package update > then I am always assured to see : > > > ceres# apt-get update > Get:1

Re: update-grub and then grub-mkconfig leads to the watchdog: BUG: soft lockup

2021-03-15 Thread John Paul Adrian Glaubitz
Hello! On 3/15/21 10:34 AM, Anatoly Pugachev wrote: >> + /usr/sbin/grub-probe --target=device / >> + GRUB_DEVICE=/dev/sda2 >> + /usr/sbin/grub-probe --device /dev/sda2 --target=fs_uuid >> [ 1330.951329] watchdog: BUG: soft lockup - CPU#0 stuck for 22s! >> [grub-probe:443] >> [ 1331.046350]

Re: update-grub and then grub-mkconfig leads to the watchdog: BUG: soft lockup

2021-03-15 Thread Anatoly Pugachev
On Mon, Mar 15, 2021 at 4:59 AM Dennis Clarke wrote: > > > While digging around here I saw that update-grub will lead to a lockup > every time. So I simply changed /usr/sbin/grub-mkconfig script to > allow me to see everything that happens. > > That gets me to : > > /usr/sbin/grub-probe

update-grub and then grub-mkconfig leads to the watchdog: BUG: soft lockup

2021-03-14 Thread Dennis Clarke
While digging around here I saw that update-grub will lead to a lockup every time. So I simply changed /usr/sbin/grub-mkconfig script to allow me to see everything that happens. That gets me to : /usr/sbin/grub-probe --device /dev/sda2 --target=fs_uuid which falls to pieces perfectly :

Re: watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [systemd:1]

2021-03-14 Thread Dennis Clarke
On 3/14/21 5:52 PM, John Paul Adrian Glaubitz wrote: > On 3/14/21 6:48 PM, Frank Scheiner wrote: >>> So, if, for example, you want to verify that the memory is okay, you should >>> run >>> a memtest program. >> >> ...the built-in (memory) diagnostics of Sun machines are pretty >> thorough. This

Re: watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [systemd:1]

2021-03-14 Thread John Paul Adrian Glaubitz
On 3/14/21 6:48 PM, Frank Scheiner wrote: >> So, if, for example, you want to verify that the memory is okay, you should >> run >> a memtest program. > > ...the built-in (memory) diagnostics of Sun machines are pretty > thorough. This is not a PC. :-) I doubt that the hardware runs a thorough

Re: watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [systemd:1]

2021-03-14 Thread Frank Scheiner
On 14.03.21 18:21, John Paul Adrian Glaubitz wrote: On 3/14/21 5:55 PM, Mike Tremaine wrote: Let’s assume it’s not hardware, Dennis has posted the tests and states the machine ran Sol10 fine. The fact that Solaris runs fine can be an indicator the hardware is okay, but it's not a proper

Re: watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [systemd:1]

2021-03-14 Thread John Paul Adrian Glaubitz
On 3/14/21 5:55 PM, Mike Tremaine wrote: > Let’s assume it’s not hardware, Dennis has posted the tests and states > the machine ran Sol10 fine. The fact that Solaris runs fine can be an indicator the hardware is okay, but it's not a proper verification that it's actually the case. For example,

Re: watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [systemd:1]

2021-03-14 Thread Mike Tremaine
Let’s assume it’s not hardware, Dennis has posted the tests and states the machine ran Sol10 fine. My only ideas are 1) Try using apt to update some individual packages to see if that even works. Try dash and bash and whatever but avoid Systemd and any related libraries. 2a) If those succeed

Re: watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [systemd:1]

2021-03-13 Thread Frank Scheiner
Hi Dennis, On 13.03.21 20:21, Dennis Clarke wrote: On 3/13/21 5:29 PM, Mike Tremaine wrote: On Mar 12, 2021, at 5:56 AM, Dennis Clarke wrote: [...] I did sent a BRK to the serial port and that drops us into the firmware "ok" prompt. There is a failed fan but in fact the fan is entirely not

Re: watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [systemd:1]

2021-03-13 Thread Dennis Clarke
On 3/13/21 5:29 PM, Mike Tremaine wrote: >> On Mar 12, 2021, at 5:56 AM, >> Dennis Clarke wrote: >> >> I have seen this for a few months now. The old old netra machine will >> run just fine endlessly but if I attempt to perform a package update >> then I am always assured to see : > What kernel

Re: watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [systemd:1]

2021-03-13 Thread Mike Tremaine
ADDED: I wonder if it’s systemd specifically that causes this for you based on the console output. I have this in dmesg which matches the start of your output. [Mar13 09:26] systemd[1]: systemd 247.3-3 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP

Re: watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [systemd:1]

2021-03-13 Thread Mike Tremaine
> On Mar 12, 2021, at 5:56 AM, Dennis Clarke wrote: > > > I have seen this for a few months now. The old old netra machine will > run just fine endlessly but if I attempt to perform a package update > then I am always assured to see : > > What kernel are you on? I do not have a Netra handy

watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [systemd:1]

2021-03-12 Thread Dennis Clarke
I have seen this for a few months now. The old old netra machine will run just fine endlessly but if I attempt to perform a package update then I am always assured to see : ceres# apt-get update Get:1 http://deb.debian.org/debian-ports sid InRelease [55.3 kB] Get:2

Re: 5.10.0-4-sparc64-smp #1 Debian 5.10.19-1 crashes on T2000

2021-03-12 Thread Jan Engelhardt
On Thursday 2021-03-11 23:43, Frank Scheiner wrote: >> >> Do you know if I can via serial-console reset the system? > > Reset from the serial console might work via the kernel with the [magic > system request] functionality. > > [magic system request]: >

Re: 5.10.0-4-sparc64-smp #1 Debian 5.10.19-1 crashes on T2000

2021-03-11 Thread Gregor Riepl
> How should I proceed? Which kernel sources? > > https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s-common-official > > > is 4.3 correct for me? 4.6 ? You should clone the upstream Git repo, otherwise bisecting will be much more difficult. I think these instructions

Re: 5.10.0-4-sparc64-smp #1 Debian 5.10.19-1 crashes on T2000

2021-03-11 Thread Frank Scheiner
Hi Riccardo, On 11.03.21 23:03, Riccardo Mottola wrote: Hi Frank! I suppose the Niagara CPU gives the kernel issue From [1] I assume T2 CPUs are not affected, but yeah, the issue could be that selective that it only affects the very first generation. [1]:

Re: 5.10.0-4-sparc64-smp #1 Debian 5.10.19-1 crashes on T2000

2021-03-11 Thread Gregor Riepl
> Do you know if I can via serial-console reset the system? > I tried sending a break on the serial console, but the errors just keep > running. > Break is received, since I see it as SC Alert, but I am not put into the > console, maybe there is some further trick on these newer machine? I am >

Re: 5.10.0-4-sparc64-smp #1 Debian 5.10.19-1 crashes on T2000

2021-03-11 Thread Riccardo Mottola
Hi Adrian John Paul Adrian Glaubitz wrote: Well, that doesn't really help you though. You want to find the commit in question, just the range isn't enough to solve the issue. Well, a little bit it helped, it is something early in the 5.10 series. Also I have now an apparently working kernel

Re: 5.10.0-4-sparc64-smp #1 Debian 5.10.19-1 crashes on T2000

2021-03-11 Thread Riccardo Mottola
Hi Frank! I suppose the Niagara CPU gives the kernel issue Frank Scheiner wrote: If I remember there was a repository with many snapshots of different versions, already as package, which one can test quickly. That way we can restrict breakage range without git bisect. Do you have a link? I

Re: 5.10.0-4-sparc64-smp #1 Debian 5.10.19-1 crashes on T2000

2021-03-10 Thread John Paul Adrian Glaubitz
On 3/10/21 10:17 AM, Riccardo Mottola wrote: > If I remember there was a repository with many snapshots of different > versions, > already as package, which one can test quickly. That way we can restrict > breakage > range without git bisect. Well, that doesn't really help you though. You want

Re: 5.10.0-4-sparc64-smp #1 Debian 5.10.19-1 crashes on T2000

2021-03-10 Thread Frank Scheiner
Hi Riccardo, On 10.03.21 10:17, Riccardo Mottola wrote: Frank Scheiner wrote: We have an older UltraSPARC IIIi that has issues with newer kernels, but usually only after longer operation and the issue might be related to the bug that was just fixed recently by Rob Gardner. Which kernel

Re: 5.10.0-4-sparc64-smp #1 Debian 5.10.19-1 crashes on T2000

2021-03-10 Thread Riccardo Mottola
Hi Frank, Frank Scheiner wrote: We have an older UltraSPARC IIIi that has issues with newer kernels, but usually only after longer operation and the issue might be related to the bug that was just fixed recently by Rob Gardner. Which kernel version will have this bug (which one?) fixed,

Re: 5.10.0-4-sparc64-smp #1 Debian 5.10.19-1 crashes on T2000

2021-03-09 Thread John Paul Adrian Glaubitz
On 3/9/21 11:20 PM, John Paul Adrian Glaubitz wrote: >> Which kernel version will have this bug (which one?) fixed, 5.11.x? I >> can also check with one of my UltraSPARC IIIi powered systems, too, next >> week. > > I have not uploaded that kernel yet, I have it built locally, PR here [1]. The

Re: 5.10.0-4-sparc64-smp #1 Debian 5.10.19-1 crashes on T2000

2021-03-09 Thread John Paul Adrian Glaubitz
On 3/9/21 10:18 PM, Frank Scheiner wrote: >> The oldest buildd we are running is a T5120 and that's a T2. > > And these don't show the problems Riccardo's T1 powered T2000 has? No, the machine runs stable. >> We have an older UltraSPARC IIIi that has issues with newer kernels, but >> usually

Re: 5.10.0-4-sparc64-smp #1 Debian 5.10.19-1 crashes on T2000

2021-03-09 Thread Frank Scheiner
On 09.03.21 22:09, John Paul Adrian Glaubitz wrote: On 3/9/21 9:38 PM, Frank Scheiner wrote: I have a T1000 with which I could try to reproduce Riccardo's issues. Hardware wise they should be pretty similar. As the T1000 doesn't have a CDROM, I'll try to netboot a few newer kernels and report

Re: 5.10.0-4-sparc64-smp #1 Debian 5.10.19-1 crashes on T2000

2021-03-09 Thread John Paul Adrian Glaubitz
On 3/9/21 9:38 PM, Frank Scheiner wrote: > I have a T1000 with which I could try to reproduce Riccardo's issues. > Hardware wise they should be pretty similar. As the T1000 doesn't have a > CDROM, I'll try to netboot a few newer kernels and report my findings. > Will take me until next week

Re: 5.10.0-4-sparc64-smp #1 Debian 5.10.19-1 crashes on T2000

2021-03-09 Thread Frank Scheiner
Hi guys, On 09.03.21 18:31, John Paul Adrian Glaubitz wrote: Hi! On 3/9/21 6:26 PM, Riccardo Mottola wrote: John Paul Adrian Glaubitz wrote: while I was able to "install" correctly using a slightly older ISO, I get not a bootable system. The kernel appears to crash very early during boot.

Re: 5.10.0-4-sparc64-smp #1 Debian 5.10.19-1 crashes on T2000

2021-03-09 Thread John Paul Adrian Glaubitz
Hi! On 3/9/21 6:26 PM, Riccardo Mottola wrote: > John Paul Adrian Glaubitz wrote: >>> while I was able to "install" correctly using a slightly older ISO, I get >>> not a bootable >>> system. The kernel appears to crash very early during boot. >> I think this is more likely a hardware issue. We

Re: 5.10.0-4-sparc64-smp #1 Debian 5.10.19-1 crashes on T2000

2021-03-09 Thread Riccardo Mottola
Hi, John Paul Adrian Glaubitz wrote: while I was able to "install" correctly using a slightly older ISO, I get not a bootable system. The kernel appears to crash very early during boot. I think this is more likely a hardware issue. We haven't seen any machines crashing that early. Please

Re: getting a working install ISOs on a T2000

2021-03-09 Thread Riccardo Mottola
Hi Adrian the world is small between SPARC and PPC :) John Paul Adrian Glaubitz wrote: 2020-11-16 -> this one worked! (but system is unbootable due to crash, of that in a second mail) This sounds like a hardware problem. The newer images should all work on sparc64 with a few images that

Re: 5.10.0-4-sparc64-smp #1 Debian 5.10.19-1 crashes on T2000

2021-03-09 Thread John Paul Adrian Glaubitz
Hello Riccardo! On 3/9/21 1:23 PM, Riccardo Mottola wrote: > while I was able to "install" correctly using a slightly older ISO, I get not > a bootable > system. The kernel appears to crash very early during boot. I think this is more likely a hardware issue. We haven't seen any machines

5.10.0-4-sparc64-smp #1 Debian 5.10.19-1 crashes on T2000

2021-03-09 Thread Riccardo Mottola
Hi all, while I was able to "install" correctly using a slightly older ISO, I get not a bootable system. The kernel appears to crash very early during boot. Anybody else has this issue? Booting `Debian GNU/Linux' Loading Linux 5.10.0-4-sparc64-smp ... Loading initial ramdisk ... [

Re: getting a working install ISOs on a T2000

2021-03-09 Thread John Paul Adrian Glaubitz
Hello! On 3/9/21 12:28 PM, Riccardo Mottola wrote: > I tried hard installing Debian/sparc64, it was not easy at all and haven't > concluded. > > The T2000 I started from had Linux already installed, with an older 4.x > series kernel, > I'd guess not updated since 3 years. It was working and

getting a working install ISOs on a T2000

2021-03-09 Thread Riccardo Mottola
Hi, I tried hard installing Debian/sparc64, it was not easy at all and haven't concluded. The T2000 I started from had Linux already installed, with an older 4.x series kernel, I'd guess not updated since 3 years. It was working and was configured with SILO. I tried updating but the boot

Re: Newer kernels fail to boot on a U450?

2021-03-01 Thread Mark Cave-Ayland
On 28/02/2021 19:27, Frank Scheiner wrote: Hi Mark, On 24.02.21 14:01, Mark Cave-Ayland wrote: On 24/02/2021 12:29, Frank Scheiner wrote: On 24.02.21 12:14, Mark Cave-Ayland wrote: Next time you have the U450 fired up, I'd be interested to find out if it is possible to boot directly from

New Year Greetings!

2021-02-28 Thread Cherry
Hi Debian-sparc, Happy Chinese New Year! We’ve back to work, and ready to serve you all the time, thanks. Have a nice day! Thanks Regards, Cherry Hu |Sales Manager SHENZHEN PLUXLED LIGHTING CO., LIMITED. 4F,Building 4, Huafeng

Re: Newer kernels fail to boot on a U450?

2021-02-28 Thread Frank Scheiner
Hi Mark, On 24.02.21 14:01, Mark Cave-Ayland wrote: On 24/02/2021 12:29, Frank Scheiner wrote: On 24.02.21 12:14, Mark Cave-Ayland wrote: Next time you have the U450 fired up, I'd be interested to find out if it is possible to boot directly from the latest debian ports CDROM for comparison.

Re: Newer kernels fail to boot on a U450?

2021-02-24 Thread Frank Scheiner
Hi Mark, On 24.02.21 14:01, Mark Cave-Ayland wrote: On 24/02/2021 12:29, Frank Scheiner wrote: On 24.02.21 12:14, Mark Cave-Ayland wrote: Thanks for the information! Do you have a display on your U450 at all? No, access was/is via serial console. The U450 we were trying to rescue was

Re: Newer kernels fail to boot on a U450?

2021-02-24 Thread Mark Cave-Ayland
On 24/02/2021 12:29, Frank Scheiner wrote: Hi Mark, On 24.02.21 12:14, Mark Cave-Ayland wrote: [...] I then asked them to work backwards through a collection of historical debian-ports ISOs that I own until we found one that would boot. The results were as follows:

Re: Newer kernels fail to boot on a U450?

2021-02-24 Thread John Paul Adrian Glaubitz
Hi Frank! On 2/24/21 1:43 PM, Frank Scheiner wrote: >> There is a stability issue on newer kernels on older hardware that is >> currently >> being debugged though [1]. > > Didn't know of that thread. I wonder if this could be the reason for the > crashes on my v480 and v490, though they

Re: Newer kernels fail to boot on a U450?

2021-02-24 Thread Frank Scheiner
Hi Adrian, On 24.02.21 13:04, John Paul Adrian Glaubitz wrote: Hi Mark! On 2/24/21 12:14 PM, Mark Cave-Ayland wrote: Do people still run newer kernels on older hardware? If there is interest, I may be able to get some more diagnostic information. In particular I'd be curious to know if Oracle

Re: Newer kernels fail to boot on a U450?

2021-02-24 Thread Frank Scheiner
Hi Mark, On 24.02.21 12:14, Mark Cave-Ayland wrote: [...] I then asked them to work backwards through a collection of historical debian-ports ISOs that I own until we found one that would boot. The results were as follows: debian-10.0.0-sparc64-NETINST-1.iso (kernel 5.9.0-1-sparc64, grub) -

Re: Newer kernels fail to boot on a U450?

2021-02-24 Thread John Paul Adrian Glaubitz
Hi Mark! On 2/24/21 12:14 PM, Mark Cave-Ayland wrote: > Do people still run newer kernels on older hardware? If there is interest, > I may be able to get some more diagnostic information. In particular I'd be > curious to know if Oracle do any routine testing of newer kernels on machines > such

<    2   3   4   5   6   7   8   9   10   11   >