I already noted how to do that above: Haiku nightly lags considerably since 19/07/2024 - #26 by waddlesplash
I did that as I replied above😉
But it didn’t seem to have any effect…
If you are trying to build a full image it will always try to build the bootloaders. That change only helps if you are building only haiku.hpkg haiku_devel.hpkg.
The error you get building haiku_devel.hpkg probably indicates another error happened further up in the build log. Or, if it persists, just delete the .../packaging/packages directory and start over.
1 Like
Ok let me try that.
So there is no way to just build a compatible boot loader? I thought since there’s is an x86_64 only build there had to be a way to specify the arch of the boot loader as well…
Regarding the package build: do I install them like normal Haiku packages and they live as overlay in the packagefs tree? Can I switch between snapshots and uninstall them like normal packages?
The BIOS loader must be compiled for 32-bit no matter what. The EFI loader will be 64-bit of course, but the BIOS loader will always be compiled for a full system image.
You can install the packages by doing pkgman install path/to/built/haiku.hpkg ..., which will create a transaction and a state just like normal.
1 Like
ok succeeded! Seems I was just missing the tags and overlooked the error that required packages which took my improvised hrev could not be resolved, thanks @madmax for the hint!
Oc I had to specify both packages haiku and haiku_devel together with pkgman install so it resolves dependencies correctly, just adding this detail for interested readers or the future me.
Now rebooting and keeping fingers crossed…
Update: everything worked fine and I couldn’t reproduce any lags @waddlesplash, so I consider this fixed, thanks a lot! (I checked I am using WalterOS hrev…+dirty).
I don’t expect this version to lag either; the point of the patch was to expose any potential problems that would’ve caused lags as assertion-failure KDLs instead.
If you don’t get any lags with this patch, please try reinstating the original change on top of it, like so:
@@ -409,18 +449,17 @@ cancel_timer(timer* event)
// invalidate CPU field
event->cpu = 0xffff;
// If on the current CPU, also reset the hardware timer.
- // FIXME: Theoretically we should be able to skip this if (previous == NULL).
- // But it seems adding that causes problems on some systems, possibly due to
- // some other bug. For now, just reset the hardware timer on every cancellation.
- if (cpu == smp_get_current_cpu()) {
+ if (cpu == smp_get_current_cpu() && previous == NULL) {
1 Like
Oh I see, that makes sense, as you cannot really check for lags and assert they’re not there😊
Will try this patch tomorrow then.
Update 28.8.2024: the patch now shows the lags again, but I couldn’t really find a pattern there. I could grab a KDL screenshot which shows many timers on a lag, does this help or should I try again?
Well, both those do show the problem: most of the timers in these lists should have been fired by now, but they haven’t been. If this is a build with the extra asserts, I don’t know what could’ve gone wrong here, because if none of the asserts fired that probably means the timer was set correctly but then it just never fired…
Seems like a firmware or CPU issue, maybe ACPI related?
Yes it’s your timer test branch with the patch applied.
I guess we have to leave that little overhead in, as it doesn’t seem to affect performance or resource usage anyway.
Well, it definitely does affect performance at least in a small way as resetting the hardware timer does take some overhead, and on hypervisors requires VM exits…
Does anything change if you run with ACPI disabled?
2 Likes
Did you get a chance to test with ACPI disabled?
I would also be interested to see if anything is different after hrev58111 (with the extra asserts patch and with the optimization.) If it isn’t, you should probably open a ticket and attach a syslog at this point.
sorry for the lack of updates, I had trouble uninstalling the experimental Haiku packages and then was quite happy with latest nightlies, needed to do some progress on SEN again… ,-)
I’m on nightly hrev58097 as of today - do you mean the timer patch will be integrated into the next build?
I’ll try the latest timer-asserts build now and let you know asap.
ok just tested with the “dirty” local packages from your branch (Walter hrev57996+1+diry), disabling ACPI in the boot menu makes it even worse, lots of fishy things going on with USB, see syslog at the end.
Had to plug the mouse into a different port because it stopped working (yes after my internal also my external touchpad died, so I got a new shiny Cherry USB mouse:), keyboard stopped working for a while, then back to normal, intermittent hangs.
Now after rebooting without any special options, it took a while and the mouse was not immediately working, but the things looked normal, with one exception:
Mouse clicks are sometimes ignored, giving the impression the system hangs, but using the keyboard shows the system is alive and well. Here I see nothing in syslog, only dozens of slab memore manager messages like
KERN: slab memory manager: created area 0xffffff8001801000 (17265)
which is normal, right?
Here’s the syslog with ACPI disabled:
KERN: usb xhci 1: transfer error on slot 1 endpoint 3: USB transaction
KERN: usb hub 7: port 2: new device connected
KERN: usb error hub 7: new device on a port that is already in use
KERN: acpi: ACPI disabled
KERN: loading dependent module bus_managers/acpi/v1 of busses/i2c/pch_i2c/acpi/driver_v1 failed!
KERN: acpi: ACPI disabled
KERN: loading dependent module bus_managers/acpi/v1 of busses/i2c/pch_i2c/pci/driver_v1 failed!
KERN: acpi: ACPI disabled
KERN: loading dependent module bus_managers/acpi/v1 of drivers/power/acpi_button/driver_v1 failed!
KERN: usb_hid: none of the possible usages for the collection are set
Last message repeated 1 time
KERN: usb error xhci 1: cancel queued transfers: halted endpoint, reset!
KERN: usb xhci 1: cancel queued transfers (0) for pipe 0xffffffff83029300 (0)
KERN: usb xhci 1: KERN: cancel queued transfers (0) for pipe 0xffffffff8327eb90 (1)
KERN: Mouse device exiting, Device not ready
USER 'KS': Notify of added/removed/started/stopped device
Last message repeated 1 time
KERN: usb xhci 1: cancel queued transfers (0) for pipe 0xffffffff83029300 (0)
Last message repeated 1 time
KERN: usb_audio:01.07.895:init_driver::ver.0.0.5
USER 'KS': Notify of added/removed/started/stopped device
Last message repeated 1 time
KERN: usb_hid: keyboard device unhandled control 0x00002710
KERN: acpi: ACPI disabled
KERN: loading dependent module bus_managers/acpi/v1 of busses/i2c/pch_i2c/acpi/driver_v1 failed!
KERN: acpi: ACPI disabled
KERN: loading dependent module bus_managers/acpi/v1 of busses/i2c/pch_i2c/pci/driver_v1 failed!
KERN: acpi: ACPI disabled
KERN: loading dependent module bus_managers/acpi/v1 of busses/i2c/pch_i2c/acpi/driver_v1 failed!
KERN: acpi: ACPI disabled
KERN: loading dependent module bus_managers/acpi/v1 of busses/i2c/pch_i2c/pci/driver_v1 failed!
Looks like USB isn’t working correctly indeed. That might be expected with ACPI disabled, though.
Yes.