#17264 closed bug (fixed)
fix unpackaged hierarchy for kerneldrivers (etc) to load/publish -before- app-server start (UEFI hardware)
Reported by: | rudolfc | Owned by: | nobody |
---|---|---|---|
Priority: | normal | Milestone: | R1/beta6 |
Component: | System/Kernel | Version: | R1/beta3 |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | All |
Description (last modified by )
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.
Change History (27)
comment:1 by , 3 years ago
comment:5 by , 3 years ago
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.)
comment:6 by , 3 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
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!
Update:
comment:7 by , 3 years ago
Description: | modified (diff) |
---|---|
Resolution: | fixed |
Status: | closed → reopened |
Summary: | fix unpackaged hierarchy for kerneldrivers (etc) to load/publish -before- app-server start → fix unpackaged hierarchy for kerneldrivers (etc) to load/publish -before- app-server start (UEFI hardware) |
comment:8 by , 3 years ago
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.
comment:9 by , 3 years ago
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.
comment:10 by , 2 months ago
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.
comment:11 by , 2 months ago
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
comment:12 by , 2 months ago
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--) {
comment:14 by , 2 months ago
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?
comment:15 by , 2 months ago
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.
comment:16 by , 2 months ago
@rudolfc you can try a test build here: https://haiku.movingborders.es/testbuild/I728365f069071f109c79e647d6a33cd24f68ce0e/1/hrev58274/x86_gcc2h/
comment:17 by , 2 months ago
Milestone: | Unscheduled → R1/beta6 |
---|---|
Resolution: | → fixed |
Status: | reopened → closed |
Fix merged in hrev58275.
comment:18 by , 2 months ago
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 :-)
follow-up: 22 comment:19 by , 2 months ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
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.
comment:20 by , 2 months ago
In this case, blacklisting the packaged driver could probably help though.
comment:21 by , 2 months ago
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.
comment:22 by , 2 months ago
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 :-)
comment:23 by , 2 months ago
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.
comment:24 by , 2 months ago
Would be very nice if this item could be solved, thank you for your efforts! :-)
comment:26 by , 2 months ago
Component: | - General → System/Kernel |
---|---|
Resolution: | → fixed |
Status: | reopened → closed |
fixed in hrev58281
comment:27 by , 2 months ago
Confirmed that both the user kerneldriver and accelerant are now running :-) Nice!
In case of a regression, could bisecting help to find the triggering commit?