[SOLVED] SW kernel-5.10.37 breaks 5.10.x compatibility to date

rdsherman · 05-19-2021, 07:47 PM

Just installed shiny new 5.10.38 generic. It does exactly what 5.10.1-36 does... it works as usual.

Clearly, there is a big bad bug lurking inside 5.10.37!

Nevertheless, all is well again.

ZhaoLin1457 · 05-20-2021, 01:42 AM

Quote:

Originally Posted by rdsherman

Just installed shiny new 5.10.38 generic. It does exactly what 5.10.1-36 does... it works as usual.

Clearly, there is a big bad bug lurking inside 5.10.37!

Nevertheless, all is well again.

Then, how about you to mark this thread as [SOLVED] ?

derekn13 · 05-20-2021, 02:10 AM

Yup, 5.10.38 works again for me too.

I have no idea what was going on with .37. I use the huge kernel with an initrd, so it wasn't an initrd problem. Guess it was just a random kernel glitch that got fixed.

hazel · 05-20-2021, 03:58 AM

So why did it work for me?

ZhaoLin1457 · 05-20-2021, 06:30 AM

Quote:

Originally Posted by hazel

So why did it work for me?

Different hardware.

NonNonBa · 05-20-2021, 08:05 AM

Hi,

I confirm the 5.10 kernel has a weird behavior. On my dell latitude, using the generic kernel (with .36 as well with .38) causes the boot process to stall for a long minute here (in bold):

Code:

[    1.116876] ata5: SATA max UDMA/133 abar m2048@0xfed1c800 port 0xfed1cb00 irq 27
[    1.116945] ata6: SATA max UDMA/133 abar m2048@0xfed1c800 port 0xfed1cb80 irq 27
[    1.118293] scsi host6: pata_legacy
[    1.118397] ata7: PATA max PIO4 cmd 0x1f0 ctl 0x3f6 irq 14
[    1.186861] random: fast init done
[    1.582098] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[    1.678088] clocksource: timekeeping watchdog on CPU0: Marking clocksource 'tsc-early' as unstable because the skew is too large:
[    1.678166] clocksource:                       'hpet' wd_now: 483f5636 wd_last: e0db05 mask: ffffffff
[    1.678244] clocksource:                       'tsc-early' cs_now: 4d1a8a093 cs_last: 489753ad3 mask: ffffffffffffffff
[    1.678317] tsc: Marking TSC unstable due to clocksource watchdog
[    1.678453] clocksource: Switched to clocksource hpet
[    1.872373] ata1.00: ATA-8: WDC WD2500BEVS-22UST0, 01.01A01, max UDMA/133
[    1.872434] ata1.00: 488397168 sectors, multi 0: LBA48 NCQ (depth 32), AA
[    1.873443] ata1.00: configured for UDMA/133

With the huge kernel, I get the same dmesg log but everything goes smoothy. I've tried to use the generic 5.4 I use on my 14.2, generating the initrd the same way I do for the 5.10, and everything is fine. I don't see where this can come from.

Petri Kaukasoina · 05-20-2021, 08:55 AM

Quote:

Originally Posted by NonNonBa

Hi,
On my dell latitude, using the generic kernel (with .36 as well with .38) causes the boot process to stall for a long minute here (in bold):

Does it help if you append 'clocksource=hpet' to the kernel command line?

rdsherman · 05-20-2021, 09:08 AM

Quote:

Originally Posted by ZhaoLin1457

Then, how about you to mark this thread as [SOLVED] ?

Thread closed!

hazel · 05-20-2021, 09:58 AM

On my Lenovo system, the kernel uses tsc as its timer because it says:

Code:

[    0.006854] ACPI: HPET 0x00000000993A1E70 000038 (v01 LENOVO TC-03    00001000 AMI. 00000005)
[    0.037926] x86/hpet: Will disable the HPET for this platform because it's not reliable

Is that why I haven't had this problem?

NakedRider · 05-20-2021, 10:27 AM

Quote:

Originally Posted by dr.s

No need to re-install, just download the kernel that worked for you and run upgradepkg

https://slackware.uk/cumulative/slac...t/slackware64/

Thank you very much for your reply.

NonNonBa · 05-20-2021, 11:52 AM

Quote:

Originally Posted by Petri Kaukasoina

Does it help if you append 'clocksource=hpet' to the kernel command line?

Indeed it helps, thanks a lot!

I've given a try to the 5.12 and got the same issue. My hardware is 8 years old, and in two decades it's the first time I can remember I have to play with the kernel command line to boot fine. And I still don't understand why the huge kernel has no problem, but well, it does the trick.

Quote:

Originally Posted by hazel

On my Lenovo system, the kernel uses tsc as its timer because it says:

Code:

[    0.006854] ACPI: HPET 0x00000000993A1E70 000038 (v01 LENOVO TC-03    00001000 AMI. 00000005)
[    0.037926] x86/hpet: Will disable the HPET for this platform because it's not reliable

Is that why I haven't had this problem?

Probably not as I have precisely to use HPET. But I'm finally not sure my issue is so much related to the OP's one. Maybe my hardware also, which for example hasn't been able to reboot reliably for years now.

volkerdi · 05-20-2021, 09:54 PM

Glad to hear the latest kernel has improved the situation!