PTI makes my 2 32 bit laptops unstable. I have lubuntu 18.04 installed on both and they both started having trouble after the linux-image upgrade from 4.15.0-46/47 to 4.15.0-50/51. They either fail to boot without locking up or fail to shut down cleanly. I rarely get any useful logs or messages on the screen, although if the machines do boot without locking up, I have seen messages like this when they fail to shut down:
watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [systemd:1]
I did manage to recover some BUGs with call traces from kern.log when I tried the ubuntu mainline kernel build, 4.19.31-041931-generic #201903231635. Here are typical BUG stmts:
Apr 22 10:16:04 mikedell kernel: [ 43.339955] BUG: unable to handle kernel NULL pointer dereference at 00000008
Apr 22 10:16:04 mikedell kernel: [ 43.484957] BUG: unable to handle kernel paging request at eef4817c
Unfortunately, I think it's the only kernel that's given me this much info. I'd be happy to share the full call traces I have captured if anyone is interested.
Neither laptop has a serial port and I'm not a kernel developer, so I don't feel I've got the means to properly diagnose the problem. Howver, I have since found that when I compile the kernel from:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/
and change only one config parameter, CONFIG_PAGE_TABLE_ISOLATION, the kernel with the param enabled is unstable, but the kernel with the param disabled is stable. I have found this to be the case with kernels 4.19.50 and 5.1.9.
The two laptops are:
Dell Inspiron B130 with an Intel Celeron M 1.50GHz (family: 0x6, model: 0xd, stepping: 0x8)
IBM Thinkpad R51 1836HAU with Intel Pentium M processor 725 (1.6 GHz)
The Thinkpad's Pentium M 725 is a Dothan processor that supports PAE, but lies about it, so it requires the forcepae kernel parameter. The Dell's Celeron M does not requre the forcepae parameter.
I've been trying to figure out if this is a known problem. THere's so little love for 32 bt hardware these days. Then I saw this bug report and thought it might be a good place to start.
Should I post this info on the linux-kernel mailing list?
PTI makes my 2 32 bit laptops unstable. I have lubuntu 18.04 installed on both and they both started having trouble after the linux-image upgrade from 4.15.0-46/47 to 4.15.0-50/51. They either fail to boot without locking up or fail to shut down cleanly. I rarely get any useful logs or messages on the screen, although if the machines do boot without locking up, I have seen messages like this when they fail to shut down:
watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [systemd:1]
I did manage to recover some BUGs with call traces from kern.log when I tried the ubuntu mainline kernel build, 4.19.31- 041931- generic #201903231635. Here are typical BUG stmts:
Apr 22 10:16:04 mikedell kernel: [ 43.339955] BUG: unable to handle kernel NULL pointer dereference at 00000008
Apr 22 10:16:04 mikedell kernel: [ 43.484957] BUG: unable to handle kernel paging request at eef4817c
Unfortunately, I think it's the only kernel that's given me this much info. I'd be happy to share the full call traces I have captured if anyone is interested.
Neither laptop has a serial port and I'm not a kernel developer, so I don't feel I've got the means to properly diagnose the problem. Howver, I have since found that when I compile the kernel from: kernel. org/pub/ scm/linux/ kernel/ git/stable/ linux.git/ PAGE_TABLE_ ISOLATION, the kernel with the param enabled is unstable, but the kernel with the param disabled is stable. I have found this to be the case with kernels 4.19.50 and 5.1.9.
git://git.
and change only one config parameter, CONFIG_
The two laptops are:
Dell Inspiron B130 with an Intel Celeron M 1.50GHz (family: 0x6, model: 0xd, stepping: 0x8)
IBM Thinkpad R51 1836HAU with Intel Pentium M processor 725 (1.6 GHz)
The Thinkpad's Pentium M 725 is a Dothan processor that supports PAE, but lies about it, so it requires the forcepae kernel parameter. The Dell's Celeron M does not requre the forcepae parameter.
I've been trying to figure out if this is a known problem. THere's so little love for 32 bt hardware these days. Then I saw this bug report and thought it might be a good place to start.
Should I post this info on the linux-kernel mailing list?