Segfault on reboot/Shutdown

[ozsouth]

I've found that any kernel after 5.8 segfaults upon reboot/shutdown on my laptops. At first I thought I'd fouled up kernel compiling, but now I find all 5.9+ kernels do the same. This happens on both my i3-5005u (8gb ram) & celeron n3350 (4gb ram). Have tested in Xenialpup64-7.5, Bionicpup64-8.0 & ScPup64-20.06. Tried both grub2 & syslinux bootloaders. Tried with & without microcode. Tried reducing accessable ram to half. Screen photo attached in case someone has a suggestion.

[taersh]

Watching some of the latest developments I suspect GNU/Linux is already on its way to be developed into train wrecks.

[mikewalsh]

Hm. Can't say as I'm surprised. Things are steadily going downhill ever since Linus stepped down, as was to be expected.... Nobody is, or ever will be, as fussy & conscientious as that man was. For too many, "near enough is good enough".

Is it the same with the 6-series, Oz?

Mike.

[rockedge]

I will run some tests as well.

[peebee]

Hi @ozsouth
Can you post your hardware details? From PupSysInfo -> Sys-Specs -> Base Report
?
Anything unusual about your setup?

I notice you don't use grub4dos .... have you tried that? Shouldn't affect reboot/shutdown though lol.
What kernel boot switches are you using?

Thanks.

[ozsouth]

@taersh - worrying, isn't it?
@mikewalsh - I don't have any 6.0s, but since tested slacko7-64, fossapup64, lxpup32-19.03 - same result.
@rockedge appreciated.
@peebee - have pm'd info to you. I think my hardware is fairly common. I didn't think grub4dos was compatible with gpt.

Generally, I'm not hearing of others with issues, and 5.4 kernels no issue, so I'm stumped.

[ozsouth]

Seems to be generally a problem with HP laptops - have had it happen on 2 I have access to (i3-5005u & Celeron 1000M), whereas Lenovo & Acer laptops with same puppies are fine. Have now seen other users with issues on HPs with kernels after 5.8. Can't (easily) see why HP specifically.

[mikewalsh]

@ozsouth:-

Oz, is this just the laptops.....or d'you think it encompasses the desktops, too? I'd be curious to see what happens with a k5.9+ kernel on this Pavilion midi-tower of mine. It's around 18 months since manufacture, I would guess; 9th-gen Intel (Pentium 'Gold' G5400). Can try with Xenialpup64 7.5, Bionicpup64 8.0 (only use this one for testing), or Fossapup64 9.5.

Do you have any package I can experiment with?

Mike.

[ozsouth]

@mikewalsh - here are 3 from 3 different puppians (peebee, me, rockedge). Nothing wrong with the kernel packages - I believe is a linux/HP issue. NOTE: specifically for @mikewalsh to test - first 2 need fdrv, last has one. Last 2 built for bionic/fossa 64bit.

https://archive.org/download/Puppy_Linu ... 64.tar.bz2
https://www.mediafire.com/file/k5jrhi28 ... r.bz2/file
https://archive.org/download/Puppy_Linu ... 11.tar.bz2

[rockedge]

I have not had a segfault or reboot/shutdown problem on any of the desktops I have tested the kernels on.
No HP among them though in desktop form. I do not have any HP laptops I can test on.

[mikewalsh]

@ozsouth :-

Oz; sorry to have to report this, but I'll echo what rockedge has said above. Looks like it's either HP laptops in general (or a particular chipset).....or it may be summat specific to your machine, I'm afraid. All runs as sweet as a nut on this HP Pavilion desktop of mine.

Bionicpup64 running the k5.9.14 kernel:-

.....and the k5.10.17 kernel (both of these are on my Bionic64 WINE AppImage "test" Pup; no installed Nvidia driver to worry about):-

And here's Fossapup64 running the k5.11.4 real-time kernel:-

No segfaults in sight. Sorry an' all that..... Curiously, pSync wasn't syncing the clock with this one (for some reason), though that WAS the only "glitch" I encountered. Everything else was working fine.

Mike.

[ozsouth]

@mikewalsh - thanks for testing. I have had this happen on 3 HP laptops with different pups & kernels.

[Eastler_Dart]

hm, crazy.

You should peek the place, at which that happens.
A good place should be /tmp/xerrs.log, but that is gone after the crash
So, try to change your system, to write xerrs.log on a hdd, so that the file
already exists after reboot.

In the file /usr/bin/xwin (script, editable with Editor/Geany) is:

Code: Select all

 if [ -f /var/local/xwin_disable_xerrs_log_flag ] ; then
	LOGFILE_X='/dev/null'
else
	LOGFILE_X='/tmp/xerrs.log'
fi

if the file /var/local/xwin_disable_xerrs_log_flag exists, delete/rename it
change in the line LOGFILE_X='/tmp/xerrs.log'
the position for xerrs.log to a (mounted!) hdd/Usb-place.

reboot -> crash -> boot new, look at that xerrs.log, which are the at least done actions.
That should be goot hints, where the error occours.

Hope it helps, Eastler

[wiak]

Probably not helpful, but just commenting that I always use an old HP Elitebook 2530p intel core2duo laptop from circa 2008 for my main development work. I've never had any particular trouble with it no matter which Pup I've booted up (though I haven't tried all kernel combinations).
I'm currently using WDL_Arch64 with kernel 5.11.6-arch1-1

[Eastler_Dart]

I hope, I had understand all right.
My thoughts are, you boot up, all ok, you reboot from the running system, nothing is ok, it crashes.

Thats why I think, when you switch on and boot, your Cpu and Kernelparameters/drivers
starts with standard values. But the new Kernel in combination with a puppy
changes one/some of that to a bad value when running.
With that changed values a reboot ist not possible.
Thats why i recommend to check xerrs.log, /var/log/messages and /var/log/Xorg.0.log,
to get hints, what happend at last, when crashed.
The difficult in that is, to get the content of that files after a crash.

Hardware-defects are not a really possible reason, earlier Puppy seems to boot/reboot clean,
so it must be in software. Maybe simply a wrong kerneldriver for your hardware,
loaded from puppy at shutdown (ACPI? Green-functions or something else).

whish you good luck, Eastler

[ozsouth]

I have the answer for my 5.8+ kernel crashes - I need to blacklist snd_hda_codec_realtek.
Done by appending kernel line in grub.cfg or syslinux.cfg thus: modprobe.blacklist=snd_hda_codec_realtek
OR by including adding to /etc/modprobe.d/blacklist.conf: blacklist snd_hda_codec_realtek