testing kernel v6.1.1 on bare metal 32-bit x86

glennmcc · 12-26-2022, 04:27 PM

As requested by Patrick in...
http://mirrors.kernel.org/slackware/.../ChangeLog.txt

A-OK here on this machine.

Welcome to Linux 6.1.1 i686 (tty1)

glennmc-test login: root
Password:
Last login: Mon Dec 26 17:01:40 on tty1
Linux 6.1.1.

root@glennmc-test:~# uname -a
Linux glennmc-test.net 6.1.1 #1 PREEMPT_DYNAMIC Sun Dec 25 12:12:48 CST 2022 i686 Pentium II (Klamath) GenuineIntel GNU/Linux

marav · 12-27-2022, 10:24 AM

@LuckyCyborg

I'm surprised you don't have such a box in your garage

glennmcc · 12-27-2022, 02:13 PM

Why would it be in the garage ?

It's sitting right here in the computer room
in operation with its normal OS of Slackware-14.0

As you may recall, that same machine runs (or rather crawls), ;-)
a full install of slackware-15.0

https://www.linuxquestions.org/quest...ne-4175709646/

keithpeter · 12-27-2022, 02:47 PM

OK on a Thinkpad X60 laptop (32 bit only) as below

Code:

bash-5.2$ uname -a
Linux X60.mokapot.org 6.1.1-smp #1
 SMP PREEMPT_DYNAMIC Sun Dec 25 12:55:29 CST 2022 
i686 Genuine Intel(R) CPU           
T2400  @ 1.83GHz GenuineIntel GNU/Linux
bash-5.2$

Installed Slackware current 32bit from the iso at

http://www.slackware.no/

Then upgradepkg in the Testing/linux-6.1.x directory, then did mkinitrd...

Code:

mkinitrd -c -k 6.1.1-smp -m ext4 -f ext4 -r /dev/sda2

Not sure how to just use huge-smp as I think there is always an initrd.gz these days?

glennmcc · 12-27-2022, 10:58 PM

Nope... the huge kernels do not use an initrd

Install the huge kernel instead of the generic one
and modify your boot loader (lilo or grub),
so that it does not attempt to load an initrd but rather only the kernel.

Here's a section of /etc/lilo.conf on one of my slackware64-15.0 systems....

# Start LILO global section
lba32
boot = /dev/sda
map=/boot/map
append=" vt.default_utf8=0"
prompt
timeout = 50
vga = 858
# End LILO global section
#
# Linux bootable partition config begins
image = /boot/vmlinuz
root = /dev/sda1
label = SlackWare64
read-only # Partitions should be mounted read-only for checking
# Linux bootable partition config ends
#
______________________________________________________________________________

As we see, when the huge kernel is installed, vmlinuz becomes a symlink to the huge kernel.

ls -l /boot

lrwxrwxrwx 1 root root 20 Nov 29 22:21 vmlinuz -> vmlinuz-huge-5.15.80
lrwxrwxrwx 1 root root 20 Nov 29 22:21 vmlinuz-huge -> vmlinuz-huge-5.15.80
-rw-r--r-- 1 root root 11585536 Nov 27 14:54 vmlinuz-huge-5.15.80

keithpeter · 12-28-2022, 01:19 AM

Thanks for taking the time to reply.

Quote:

Originally Posted by glennmcc

As we see, when the huge kernel is installed, vmlinuz becomes a symlink to the huge kernel.

Code:

ls -l /boot

lrwxrwxrwx 1 root root       20 Nov 29 22:21 vmlinuz -> vmlinuz-huge-5.15.80
lrwxrwxrwx 1 root root       20 Nov 29 22:21 vmlinuz-huge -> vmlinuz-huge-5.15.80
-rw-r--r-- 1 root root 11585536 Nov 27 14:54 vmlinuz-huge-5.15.80

Aha so I originally installed all the kernels in the linux6.1.* directory instead of just the huge-smp one. I'm assuming the symlinks got changed. This install is just for testing (and to have a look at xfce 4.18 which looks nice). Below is the /etc/lilo.conf section

Code:

# Linux bootable partition config begins
image = /boot/vmlinuz-generic-smp
  initrd = /boot/initrd.gz
  root = /dev/sda2
  label = Linux611
  read-only
image = /boot/vmlinuz-huge-smp-6.1.1-smp
  root = /dev/sda2
  label = Huge611
  read-only
# Linux bootable partition config ends

Huge611 boots fine and does not install any modules according to the boot dialog.

oily · 12-31-2022, 09:03 PM

I've tried the 32 bit 6.1.1 kernel on two machines and have spent most of the day isolating an issue when mounting optical media. I've tried 32 bit -current on two machines:

HP Compaq DC7600: Pentium 4 HT 531, 3GB RAM, SATA HDD, PATA optical drive
Compaq AP550 Workstation: Dual Pentium III 1GHz, 2GB RAM, SCSI HDD, PATA optical drives

At this point in time I've only tested with the huge kernels. Using the 6.1.1 SMP kernel things seem to work OK. However, when running the non-SMP kernel, if I try to mount optical media too soon after closing the drive drawer I get a segmentation fault after a delay, the mount fails and the drive gets stuck in some indeterminate state in which I can't eject either using the drive button or the eject command. In this state, when I try to reboot or shut down, the system gets stuck at "The system is going down for reboot NOW!" and won't go any further even when left for a long time. At this point I'm still able to switch consoles with alt-F?, but can't do anything else with the keyboard. The only way out is a hard power cycle.

I can't reproduce this issue with the SMP kernel, nor under Slackware 14.2 or 15.0. I've tried this with a few drives to exclude a drive fault, and with both manufactured and writable CDs and DVDs, both in good and bad condition, to exclude these as possible faults. The poor condition and writable media seem more prone to it, but I think it's just because it takes longer for the media to be 'seen'. Even with the non-SMP kernel, if I wait until I can hear the drive go through the initial seek and then spin up, then I seem to be able to mount the media reliably. The other point to note is that it only seems to happen with the first mount after booting. If there's already been a successful mount on the drive after booting, then I can't reproduce the fault when changing media.

I've attached the output from dmesg from both machines after the segmentation fault.

glennmcc · 01-01-2023, 07:12 PM

I see that the slackware-current repository now has kernel v6.1.2

Perhaps give it a try to see if the same problem exists.

oily · 01-02-2023, 06:21 AM

I've tried both 6.1.2 huge kernels on the AP550 only (limited spare time), and can now reproduce the problem on both the non-SMP and SMP kernels, so if anything the problem is now worse. dmesg outputs attached. Unfortunately I won't have access to the PCs used for test for a few weeks now, but I'll see if I can dig up another PC for further testing at home.

glennmcc · 01-07-2023, 10:51 PM

http://mirrors.kernel.org/slackware/.../ChangeLog.txt

Slackware(64)-current is now upgraded to the 6.1.4 kernel.

root@glennmcc-server:~# uname -a
Linux glennmcc-server.net 6.1.4 #1 SMP PREEMPT_DYNAMIC Sat Jan 7 13:29:21 CST 2023 x86_64 Pentium(R) Dual-Core CPU E6600 @ 3.06GHz GenuineIntel GNU/Linux

dodoLQ · 01-08-2023, 04:07 AM

Test OK here on my P4 Northwood (kernel 6.1.3-smp). Palemoon launched too (compiled under 15.0)

oily · 01-12-2023, 07:41 PM

I've put a minimal installation of today's version of -current on an old Packard Bell with a 533MHz Katmai PIII processor and 192MB of RAM this evening and can't reproduce the optical media mounting problems I experienced with the other two machines, with either the SMP or non-SMP kernels. I should be able to retest with the first two machines in about a week's time.

oily · 01-22-2023, 07:30 PM

I've had a chance to retest on the AP550 again today after bringing the installation up to today's -current, and unfortunately the same issue remains as per the attached dmesg outputs, with no change in symptoms. It was tested with the SMP and non-SMP 6.1.7 huge kernels.

oily · 06-25-2023, 02:11 PM

In case it's any use, I've dragged the AP550 out and updated all packages, and with 6.1.35 I can't reproduce the issues with mounting optical drives now. Does anyone still use 32 bit machines for real work now? Although I own a few, they're not put to any 'real' work, so wouldn't really be affected if the 32 bit version was dropped.

glennmcc · 06-25-2023, 07:55 PM

Quote:

Originally Posted by oily

In case it's any use, I've dragged the AP550 out and updated all packages, and with 6.1.35 I can't reproduce the issues with mounting optical drives now. Does anyone still use 32 bit machines for real work now? Although I own a few, they're not put to any 'real' work, so wouldn't really be affected if the 32 bit version was dropped.

My only 32bit machine is a circa 1997 P-II 266Mhz with 512MB of RAM
running slackware-14.0 which as you point-out is not actually used for any 'real work'.