[TUHS] Re: kernel boots kernel in 1977

On Sep 19, 2024, at 5:20 PM, Steffen Nurpmeso <steffen(a)sdaoden.eu> wrote: Bakul Shah via TUHS wrote in <3B4CF41C-3D88-471D-B5E7-6F06C772F5E7(a)iitbombay.org>: |Forget "rings". Unix needs only two states from hardware. |Forget virtualization for now as well. | |The kernel runs in the supervisor state, the user code in the |unprivileged state where it can't execute or see certain |instructions or processor state or peripherals and must make |system calls for controlled access to the same. | |In addition Unix has the "root" user that can access much more |but it too must go through the system call interface. | |A "warm reboot" system call would simply arrange things so that |the new kernel image is copied in the right place and control |will eventually pass to it. | |It is not so simple these days as the hardware is much more |complex and often requires vendor provided firmware assist |to properly initialize the system before control gets passed |to an OS kernel but no change in the protection model is |required for a kernel to kernel handoff. It seems to me it is worse. The Linux driver of my WLAN chip would (i have forgotten the condition, but anyhow) leave the chip in some false state, and it could not be overcome except by booting into the (minimzed as much as possible: 31.4G) by-default installed Windows, up to the login screen, by then it would have been fixed. This was with the RTW88 driver, it was ok iirc in 4.19, which had another one. Somewhere i have found someone saying one has to pass an argument, i asked for documentation i think even via bugzilla, but nothing ever happened. But it worked (and the driver became better, and i think firmware also, both "a bit"), and now it is luckily stable again for some years. I do not know whether the flag is still needed... KEXEC_ARGS="--append=\"rtw88_pci.disable_aspm=1 rc.hostname=kent\""