fix unpackaged hierarchy for kerneldrivers (etc) to load/publish -before- app-server start (UEFI hardware)

[rudolfc]

On UEFI systems the unpackaged driver hierarchy won’t work at all, no matter if 32 or 64bit, no matter if UEFI or legacy setup, for app_server: since the drivers there are published too late for it to find them at it's scanning time.

In order to test drivers the only way I can get it done is by using a fully unpacked system and update the system hierarchy directly.

[korli]

In case of a regression, could bisecting help to find the triggering commit?

[beaglejoe]

Probably not UEFI changes if it affects 32bit.

[rudolfc]

Hopefully Waddlesplash can tell a bit more about this?

See: ​https://discuss.haiku-os.org/t/improving-the-intel-extreme-driver-was-graphics-on-dell-laptop-in-vesa-mode-only/10583/185

[X512]

Maybe blacklisting packaged driver will help?

[rudolfc]

Tried that, does not help. This is certainly not the problem. The problem is exactly as I described in the description of the ticket.. (I modified app_server to double check this, when it scans /dev/ hierarchy, the non-packaged drivers are not yet published there.)

[rudolfc]

From the looks of it this is solved somewhere down the (time)line. Currently I am testing with the intel_extreme driver via the unpackaged hierarchy on recent nightlies, so I'll close this ticket.

Thanks!

[rudolfc]

I think earlier there indeed also was a problem temporary on older legacy hardware, but that works these days. I now have a Z170 mainboard from ASUSTEK that is UEFI, where its impossible to use the unpackaged hierarchy for app_server as is mentioned in the description.

I tested 32bit and 64bit USB and hardrive fresh installs, I tested using UEFI boot and compatibility boot, I tested hd with uefi layout and old layout for partitions.

Nogo, never.

[rudolfc]

Oh BTW: on 32bit ACPI will hang the boot process around the time the desktop appears. (blue screen with fixed cursor, or not even yet a blue screen, but a black screen (icons lighted up and disappeared nicely).

So the 32bit tests were with disabled ACPI support in the kernel settings.

[rudolfc]

Just tested on a Toshiba Tecra M5, 32bit only machine with nvidia graphics. problem still persists. I think this is a non-UEFI legacy system. Kernel driver is loaded, but app_server does not start nvidia accelerant, instead it remains using the VESA driver. Probably still the kernel driver is not published at the time app_server is scanning.

[korli]

hi rudolfc, I think a reason could be that the DirectoryIterator in legacy_drivers.cpp uses a Stack to hold the various paths, pushed then poped, so the system add-ons are always tried first, because the system add-ons is the last added. You can try yourself to reverse the list at ​https://github.com/haiku/haiku/blob/master/src/system/kernel/device_manager/legacy_drivers.cpp#L259

[korli]

Alternatively just reverse the loop at ​https://github.com/haiku/haiku/blob/master/src/system/kernel/device_manager/legacy_drivers.cpp#L949

for (uint32 i = (sizeof(kDriverPaths) / sizeof(kDriverPaths[0])) - 1; i >= 0; i--) {

[korli]

Proposed change: ​https://review.haiku-os.org/c/haiku/+/8498

[rudolfc]

Sounds interesting to test indeed. I'd have to create a full image to install and test I am guessing: unfortunately that does not work over here (32bit), the compile crashes for image-raw in tmp/ccxHXDtn.s line 894 etc with errors (first unbalanced parenthesis in operand 1), right after PushGameSound.o was generated. Done on a clean system, 32bit haiku, with dual compiler specified as indicated on the website (without cross compiler is a nogo either on Beta 5).

Or can I just compile device manager and place in in the user hierarchy? BTW You did see my old message https://dev.haiku-os.org/ticket/17264#comment:5 , just to be sure? Does your reasoning hold with that in mind as well?

[bipolar]

rudulfc: maybe you're facing #18935? try calling ./configure again, but adding CC=gcc-x86 in front.

Also, instead of a full image, you can do jam -q -j4 @nightly-raw haiku.hpkg, and then just install/update that package via pkgman.

[korli]

@rudolfc you can try a test build here: ​https://haiku.movingborders.es/testbuild/I728365f069071f109c79e647d6a33cd24f68ce0e/1/hrev58274/x86_gcc2h/

[waddlesplash]

Fix merged in hrev58275.

[rudolfc]

Thanks a lot for all of this! OK, tested the testbuild from korli: both the kerneldriver and accelerant are loaded from non-packaged. I have tweaked versions of the nvidia driver in non-packaged to give me a comment that it's them, and not the versions in system (because in this rev system also supports this card, at least nicely on external monitor):

• accelerant runs from non-packaged.
• kernel driver keeps persisting from system, although the first kerneldriver to be loaded -is- the unpackaged version, it is still not used.

Looks like a partial fix therefore, still a very nice one :-)

[korli]

hey rudolfc, trying to understand. You mean the unpackaged version is loaded first, then unloaded, then the system one is loaded? Are you on nightly otherwise? If yes you can update and try directly there.

[korli]

In this case, blacklisting the packaged driver could probably help though.

[rudolfc]

Agreed. As is known I assume however, on BeOS R5/Dano user hierarchy always has precedence, unless blocked by disabling user add-ons at boot. I was using this feature a lot while developing the nvidia driver those days. On Haiku there has been a lot of extra effort needed to keep developing the way I did back then because of this problem, and packaging / read only system folders didn't make it easier as well, mildly said. I have no problem with that, it's kind of neat, but it means it is more or less essential that the unpacked user hierarchy has precedence, from where I am looking.

[rudolfc]

Replying to korli:

hey rudolfc, trying to understand. You mean the unpackaged version is loaded first, then unloaded, then the system one is loaded? Are you on nightly otherwise? If yes you can update and try directly there.

I was running your test iso, and a patched driver version in user. Yes, looks like it. The user version is never actually openend for use, as mapping the register area never occured (I had a syslog comment added there). I could see it was loaded first as that is written in syslog, via the mentioned path the driver was found, followed by the system version. I think I saw a 'reloaded' note somewhere later during boot, but the use of the kerneldriver thereafter then showed it was the system version running.

(BTW also the laptop panel programming works, if enabled via the driver specific settings file :-)

[korli]

Will try with one driver in system and one in non-packaged later today. It's well possible that when the system one is found, it replaces the non-packaged one. There is normally a priority to avoid this, something is misbehaving.

[rudolfc]

Would be very nice if this item could be solved, thank you for your efforts! :-)

[korli]

Should be solved with ​https://review.haiku-os.org/c/haiku/+/8500

[korli]

fixed in hrev58281

[rudolfc]

Confirmed that both the user kerneldriver and accelerant are now running :-) Nice!