On 28.02.2018 15:25, Alexander Boettcher wrote:
On 28.02.2018 00:58, Valery V. Sedletski via genode-main wrote:
The ACPI table named ATKG seems to cause also trouble on other Linux machines according to my search results. Maybe you can apply the latest BIOS update to that machine, since the root cause of the issue are wrong ACPI tables provided by the BIOS vendor. Another way we can try is to make our ACPI parser more robust and just skip the table.
Try to uncomment in
repos/os/src/drivers/acpi/acpi.cc
after the "checksum mismatch for" message the "throw" (line ~450). Cross fingers, maybe you have luck and you get further.
You have to re-create the drivers package by invoking:
tool/depot/create genodelabs/pkg/drivers_interactive-pc UPDATE_VERSIONS=1 FORCE=1
Additionally, you may send me directly (not to the mailing list) the dumped ACPI tables, so I may have a look.
Yes, I will try creating ACPI tables dump later.
[2] https://pastebin.mozilla.org/9078740 [3] https://pastebin.mozilla.org/9078741 [init -> drivers -> fb_drv] resource_request: ram_quota=0, cap_quota=4 [init -> drivers] child "fb_drv" requests resources: ram_quota=0,
cap_quota 4
Increase the "caps" value by some minor value for the fb_drv start element in
repos/os/recipes/raw/drivers_interactive-pc/drivers.config
and re-create the interactive driver package (as shown above).
Yes, I increased caps quota for fb_drv now, and commented "throw" out in acpi.cc, this helped! Also, I rebuilt both drivers_interactive-pc and drivers_managed-pc. The first one is required by noux_bash.run, and the second one is required by sculpt.run. Now noux_bash works like a charm on Asus machine, on both Fiasco.OC and NOVA kernels. ;-) The BIOS seems to be updated in the service center, where this machine was some months ago, though, I can check this. Yes, the ACPI table seems to be broken.
On Athlon 64 machine, noux_bash now starts ok with NOVA kernel, but still the "No RM attachment" problem on Fiasco.OC kernel. I'll check the exact source line later.
So, noux_bash mostly works now, but still the same problems with Sculpt, as previously. I updated sources to the latest level, but this didn't helped. The only difference now is that Sculpt does not try running in QEMU automatically, but only binaries are created. Also, I added the <config verbose="yes"... to "init" parameters. Now it shows service announcements and resource reservations. But I still don't see any failed resource requests or any other errors, except for the usual
[init] [31mError: RAM preservation exceeds available memory[0m[0m [init] [34mWarning: runtime: assigned RAM exceeds available RAM[0m[0m
Maybe, there are some other useful parameters for more details than verbose="yes" I don't know about? The log with verbose="yes" is here: [1]
Oops, I forgot about these messages:
[init] [34mWarning: specified quota exceeds available quota, proceeding with a quota of 3424667716[0m[0m [init] [34mWarning: runtime: assigned caps (50000) exceed available caps (1381)[0m[0m
Maybe, I'll need to increase caps quota for "init" somehow. (Is it not given all available caps in the system?). But still, In QEMU and on Real machine with NOVA kernel this message is missing, and it stops booting on the same messages.
Another problem with Sculpt that fb_drv causes my FullHD monitor to go out of sync on an attempt to set up the 1024x768 mode, if I'll wait until when Nitpicker is started. However, with noux_bash the 1024x768@...64... mode is set up correctly.
[init -> drivers -> usb_drv] dev_info: new low-speed USB device number
2 using uhci_hcd
no RM attachment (READ pf_addr=0x18 pf_ip=0xa15ef from pager_object:
pd='init -> drivers -> usb_drv' thread='ep')
Try adding the ohci attribute to the usb driver component, since you're running on a AMD machine in repos/os/recipes/raw/drivers_interactive-pc/drivers.config, e.g.:
<config uhci="yes" ehci="yes" ohci="yes" xhci="yes"> <hid/> </config>
(rebuild the package as noted above.)
No, this machine has no OHCI controllers, so this is not needed. It has 1) an integrated USB chip, which has 4 UHCI and 1 EHCI controllers 2) a PCI extension USB board, having 1 EHCI and 2 UHCI controllers. Both are based on VIA chipset (Motherboard is Abit AV8 "Third Eye" based on K8T800Pro chipset, and an external VIA6202 USB controller).
If this does not help, try first with the simple run script usb_hid.run in repos/dde_linux. Use objdump to find out which source line the instruction pointer belongs to.
Cheers,
Ok, will try that soon.
[1] https://pastebin.mozilla.org/9078851 Sculpt on Genode/Fiasco.OC (Athlon 64 machine)
WBR,
valery