[TUHS] Re: kernel boots kernel in 1977

Bakul Shah wrote in <D4467141-6023-4166-B318-33D15D314F5D(a)iitbombay.org>: |> 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>: ... |>|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 ... |> I do not know whether the flag is still needed... |> |> KEXEC_ARGS="--append=\"rtw88_pci.disable_aspm=1 rc.hostname=kent\"" | |I don't see how "it is worse". Ok, yes, binary blobs of some firmware may make the pager out of you, which is definetely worse than having "free" drivers on top of them which fail to perform proper initialization. (..i am not a kernel hacker, but the fix could have been 44492e70adc8086c42d3745d21d591657a427f04, (rtw88: pci: Power cycle device during shutdown, 2020-09-29), "platform firmware may not properly power manage the device during shutdown[.] putting the device to D3 can workaround the issue". + pci_set_power_state(pdev, PCI_D3hot); And so many quirks, everywhere.) --End of <D4467141-6023-4166-B318-33D15D314F5D(a)iitbombay.org> --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)