Hi,
for some time now I've been thinking about upgrading:) my day-to-day operating system from bare metal Linux to Sculpt. My Dell XPS 13 (9350) doesn't boot out of the box and I didn't had the time to investigate. Now the cool new report_dump gives me a chance to easily spot problems when using Sculpt on my laptop.
So I prepared "Sculpt as a hardware-probing instrument" as described in the release notes [1]. But it seems like the XPS doesn't boot far enough as no reports are dumped...
I suspected there's probably an issue related to the XPS' display resolution of 3200 x 1800. After all it's clearly been declared in Sculpts hardware requirements [2], that displays with a higher resolution than 2560 x 1440 "are not expected to work". I tried to artificially restrict the resolution to FHD [3]. The internal display still doesn't work, but when an external monitor is connected via an USB-C dock or adapter (!), the Leitzentrale is displayed and the report_dump subsystem dumps reports to the flash memory.
Using Leitzentrale, I then updated config/fb_drv to enable the internal display with it's native resolution. All screens go blank, but now I have a log to share [4] (the reconfiguration of the fb_drv happens after line 500)
So far my very first experiences with Sculpt on the Dell XPS 13. And here some related questions:
1. What do you think about the idea to generally restrict the resolution of the initial fb_drv configuration to the maximum resolution supported by Sculpt (instead of that of the connected display(s), which may break Sculpt), similar to [3]? This would also help if, for example, an external 4K TV is connected during boot.
2. On Sculpt, most/all? internal displays report only their native resolution. On the XPS this is 3200 x 1800 and I can't force a lower resolution. Although under Linux, xrandr reports a bunch of supported resolutions from 3200 x 1800 down to 640 x 360. Does the intel_fb_drv under Genode intentionally reports and supports only the native resolution?
3. Should I create an issue regarding [4] on GitHub?
4. Instead of installing Sculpt directly on my current laptop I consider to buy a new XPS 13 (9370). It has a Killer 1435 wireless module featuring a Qualcomm Atheros QCA6174A chip which seems to be supported on Linux by the ath10k module... Has someone any experience (or assumptions) whether there's a chance that it will work on Sculpt (right now or in the near future)?
Cheers, Roman
[1] https://genode.org/documentation/release-notes/18.08 [2] https://genode.org/documentation/articles/sculpt-tc [3] https://github.com/rite/genode/commit/ba65d4307e892320b791b52cdccca1d421694f... [4] https://gist.github.com/rite/1e5602c9ed55a810fe9306475e3962c0#file-log-L501
I'm not familiar with the display issue, but I can tell you that the wireless module you're talking about using isn't going to work. For now, the only WiFi driver that has been ported is iwlwifi.
On Wed, Sep 5, 2018 at 10:51 AM Roman Iten roman.iten@gapfruit.com wrote:
Hi,
for some time now I've been thinking about upgrading:) my day-to-day operating system from bare metal Linux to Sculpt. My Dell XPS 13 (9350) doesn't boot out of the box and I didn't had the time to investigate. Now the cool new report_dump gives me a chance to easily spot problems when using Sculpt on my laptop.
So I prepared "Sculpt as a hardware-probing instrument" as described in the release notes [1]. But it seems like the XPS doesn't boot far enough as no reports are dumped...
I suspected there's probably an issue related to the XPS' display resolution of 3200 x 1800. After all it's clearly been declared in Sculpts hardware requirements [2], that displays with a higher resolution than 2560 x 1440 "are not expected to work". I tried to artificially restrict the resolution to FHD [3]. The internal display still doesn't work, but when an external monitor is connected via an USB-C dock or adapter (!), the Leitzentrale is displayed and the report_dump subsystem dumps reports to the flash memory.
Using Leitzentrale, I then updated config/fb_drv to enable the internal display with it's native resolution. All screens go blank, but now I have a log to share [4] (the reconfiguration of the fb_drv happens after line 500)
So far my very first experiences with Sculpt on the Dell XPS 13. And here some related questions:
- What do you think about the idea to generally restrict the resolution
of the initial fb_drv configuration to the maximum resolution supported by Sculpt (instead of that of the connected display(s), which may break Sculpt), similar to [3]? This would also help if, for example, an external 4K TV is connected during boot.
- On Sculpt, most/all? internal displays report only their native
resolution. On the XPS this is 3200 x 1800 and I can't force a lower resolution. Although under Linux, xrandr reports a bunch of supported resolutions from 3200 x 1800 down to 640 x 360. Does the intel_fb_drv under Genode intentionally reports and supports only the native resolution?
Should I create an issue regarding [4] on GitHub?
Instead of installing Sculpt directly on my current laptop I consider
to buy a new XPS 13 (9370). It has a Killer 1435 wireless module featuring a Qualcomm Atheros QCA6174A chip which seems to be supported on Linux by the ath10k module... Has someone any experience (or assumptions) whether there's a chance that it will work on Sculpt (right now or in the near future)?
Cheers, Roman
[1] https://genode.org/documentation/release-notes/18.08 [2] https://genode.org/documentation/articles/sculpt-tc [3]
https://github.com/rite/genode/commit/ba65d4307e892320b791b52cdccca1d421694f... [4] https://gist.github.com/rite/1e5602c9ed55a810fe9306475e3962c0#file-log-L501
Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Hi,
I have a XPS 15 (9550) - so I guess a somewhat similar device. I encountered the same (or similar) issues. I didn't get as far as trying an external display, so I can't say anything about that.
Is there a reason why higher resolutions than 2560x1440 aren't supported?
As stated in another mail there is no support for other wifi devices except iwlwifi (afaict) or possibly usb attached nics so far.
If I can get the display issue resolved, I'd put some time into porting the wifi driver...
WKR Hinnerk
On Wed, Sep 05, 2018 at 06:51:07PM +0200, Roman Iten wrote:
Hi,
for some time now I've been thinking about upgrading:) my day-to-day operating system from bare metal Linux to Sculpt. My Dell XPS 13 (9350) doesn't boot out of the box and I didn't had the time to investigate. Now the cool new report_dump gives me a chance to easily spot problems when using Sculpt on my laptop.
So I prepared "Sculpt as a hardware-probing instrument" as described in the release notes [1]. But it seems like the XPS doesn't boot far enough as no reports are dumped...
I suspected there's probably an issue related to the XPS' display resolution of 3200 x 1800. After all it's clearly been declared in Sculpts hardware requirements [2], that displays with a higher resolution than 2560 x 1440 "are not expected to work". I tried to artificially restrict the resolution to FHD [3]. The internal display still doesn't work, but when an external monitor is connected via an USB-C dock or adapter (!), the Leitzentrale is displayed and the report_dump subsystem dumps reports to the flash memory.
Using Leitzentrale, I then updated config/fb_drv to enable the internal display with it's native resolution. All screens go blank, but now I have a log to share [4] (the reconfiguration of the fb_drv happens after line 500)
So far my very first experiences with Sculpt on the Dell XPS 13. And here some related questions:
- What do you think about the idea to generally restrict the resolution
of the initial fb_drv configuration to the maximum resolution supported by Sculpt (instead of that of the connected display(s), which may break Sculpt), similar to [3]? This would also help if, for example, an external 4K TV is connected during boot.
- On Sculpt, most/all? internal displays report only their native
resolution. On the XPS this is 3200 x 1800 and I can't force a lower resolution. Although under Linux, xrandr reports a bunch of supported resolutions from 3200 x 1800 down to 640 x 360. Does the intel_fb_drv under Genode intentionally reports and supports only the native resolution?
Should I create an issue regarding [4] on GitHub?
Instead of installing Sculpt directly on my current laptop I consider
to buy a new XPS 13 (9370). It has a Killer 1435 wireless module featuring a Qualcomm Atheros QCA6174A chip which seems to be supported on Linux by the ath10k module... Has someone any experience (or assumptions) whether there's a chance that it will work on Sculpt (right now or in the near future)?
Cheers, Roman
[1] https://genode.org/documentation/release-notes/18.08 [2] https://genode.org/documentation/articles/sculpt-tc [3] https://github.com/rite/genode/commit/ba65d4307e892320b791b52cdccca1d421694f... [4] https://gist.github.com/rite/1e5602c9ed55a810fe9306475e3962c0#file-log-L501
Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Hi Roman,
thanks for the interesting experience report. I'm particularly delighted about the success story of the report-dump mechanism!
[4]
https://gist.github.com/rite/1e5602c9ed55a810fe9306475e3962c0#file-log-L501
From the data, I can immediately spot two problems:
* On your machine, both the AHCI and NVMe drivers are started within the [drivers -> dynamic] subsystem. This ultimately exhausts the RAM quota of this subsystem. Instead of the designated 8 MiB, the NVMe driver only receives the remaining 2 MiB. Hence, the first lifesign we see from the driver is the plea for more resources:
[drivers -> dynamic -> nvme_drv] resource_request: ram_quota=4M, cap_quota=0
I suspect that the blocking NVMe driver is the reason sculpt could not reach the deploy stage (for executing the report-dump pkg).
* The RAM quota assigned to the intel_fb driver does not suffice for the allocation of the frame buffer for your big resolution. From the log (and from the drivers/dynamic/state), we can see that the driver requests an additional 11 MiB of RAM.
Both problems can be addressed by increasing the respective RAM quotas.
1. Increase the RAM quota of the drivers subsystem [1] from 66 MiB to, let's say, 100 MiB. This gives the drivers subsystem an additional 34 MiB to work with, which should already resolve the NVMe issue.
2. Tweak the driver manager's quota assignment for the intel_fb driver, increasing the RAM quota by at least 12 MiB [2].
3. Make sure to integrate the tweaked version of the driver manager in a new Sculpt image, e.g., by adding the following line to the sculpt.run file [3] and specifying the 'driver_manager' as boot module.
build { app/driver_manager }
append boot_modules { driver_manager }
If these steps solve the issue for you, there is still the chance that other components (like [leitzentrale -> nit_fader]) exceed their assigned quotas. Please look out for resource requests in the log.
The current quota assignments are quite conservative to facilitate the test-driving Sculpt in Qemu. Once you succeeded in bringing up the system, I'd appreciate you sharing your quota assignments so we can adjust Sculpt accordingly (within reasonable bounds).
[1] https://github.com/genodelabs/genode/blob/master/repos/gems/run/sculpt.run#L... [2] https://github.com/genodelabs/genode/blob/master/repos/gems/src/app/driver_m... [2] https://github.com/genodelabs/genode/blob/master/repos/gems/run/sculpt.run#L...
Good luck!
Norman
I made some progress on booting Genode on my XPS 15: adding you and Romans changes (to limit the resolution to 1920 width), I am able to boot it until I get a black screen and a usable cursor (at least after increasing the different RAM quotas). After that nothing really happens. I don't have easily access to a supported device so sadly I am unable to perform the necessary configurations for sculpt as a hardware-probing instrument. Do you have any hints on what I may tweak to get the boot continuing?
WKR Hinnerk
On Thu, Sep 06, 2018 at 10:45:59AM +0200, Norman Feske wrote:
Hi Roman,
thanks for the interesting experience report. I'm particularly delighted about the success story of the report-dump mechanism!
[4]
https://gist.github.com/rite/1e5602c9ed55a810fe9306475e3962c0#file-log-L501
From the data, I can immediately spot two problems:
On your machine, both the AHCI and NVMe drivers are started within the [drivers -> dynamic] subsystem. This ultimately exhausts the RAM quota of this subsystem. Instead of the designated 8 MiB, the NVMe driver only receives the remaining 2 MiB. Hence, the first lifesign we see from the driver is the plea for more resources:
[drivers -> dynamic -> nvme_drv] resource_request: ram_quota=4M,
cap_quota=0
I suspect that the blocking NVMe driver is the reason sculpt could not reach the deploy stage (for executing the report-dump pkg).
- The RAM quota assigned to the intel_fb driver does not suffice for the allocation of the frame buffer for your big resolution. From the log (and from the drivers/dynamic/state), we can see that the driver requests an additional 11 MiB of RAM.
Both problems can be addressed by increasing the respective RAM quotas.
Increase the RAM quota of the drivers subsystem [1] from 66 MiB to, let's say, 100 MiB. This gives the drivers subsystem an additional 34 MiB to work with, which should already resolve the NVMe issue.
Tweak the driver manager's quota assignment for the intel_fb driver, increasing the RAM quota by at least 12 MiB [2].
Make sure to integrate the tweaked version of the driver manager in a new Sculpt image, e.g., by adding the following line to the sculpt.run file [3] and specifying the 'driver_manager' as boot module.
build { app/driver_manager }
append boot_modules { driver_manager }
If these steps solve the issue for you, there is still the chance that other components (like [leitzentrale -> nit_fader]) exceed their assigned quotas. Please look out for resource requests in the log.
The current quota assignments are quite conservative to facilitate the test-driving Sculpt in Qemu. Once you succeeded in bringing up the system, I'd appreciate you sharing your quota assignments so we can adjust Sculpt accordingly (within reasonable bounds).
[1] https://github.com/genodelabs/genode/blob/master/repos/gems/run/sculpt.run#L... [2] https://github.com/genodelabs/genode/blob/master/repos/gems/src/app/driver_m... [2] https://github.com/genodelabs/genode/blob/master/repos/gems/run/sculpt.run#L...
Good luck!
Norman
-- Dr.-Ing. Norman Feske Genode Labs
https://www.genode-labs.com · https://genode.org
Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
On 09/06/2018 06:19 PM, Hinnerk van Bruinehsen wrote:
I made some progress on booting Genode on my XPS 15: adding you and Romans changes (to limit the resolution to 1920 width), I am able to boot it until I get a black screen and a usable cursor (at least after increasing the different RAM quotas). After that nothing really happens. I don't have easily access to a supported device so sadly I am unable to perform the necessary configurations for sculpt as a hardware-probing instrument. Do you have any hints on what I may tweak to get the boot continuing?
You can run Sculpt in VirtualBox, which should allow you to modify the installation on the USB stick, to create the hardware-probing instrument. (I'm going to do this soon, myself.)
Quick note: Because of a bug in the 18.08 code, use the "PS/2 Mouse" pointing device for the guest VM, instead of one of the USB pointing devices.
Hello Hinnerk
On 07.09.2018 00:19, Hinnerk van Bruinehsen wrote:
I made some progress on booting Genode on my XPS 15: adding you and Romans changes (to limit the resolution to 1920 width), I am able to boot it until I get a black screen and a usable cursor (at least after increasing the different RAM quotas). After that nothing really happens. I don't have easily access to a supported device so sadly I am unable to perform the necessary configurations for sculpt as a hardware-probing instrument. Do you have any hints on what I may tweak to get the boot continuing?
WKR Hinnerk
What you could do is to expand the third partition of the USB-Stick with gparted on a Linux partition and then copy the depot directory to the /depot on your stick. After this create a /config/18.08 directory on your USB-Stick. Then copy the launcher sub directory from genode/repos/gems/sculpt/ to this config directory. Then you need to create the file /config/18.08/deploy on the USB-Stick. Copy the content of the manual_deploy_config variable in the file genode/repos/gems/run/sculpt.run in to this file, set x86_64 as the arch and enable the start node for report_dump.
I used this method before, when I was in a location with no internet connection.
Best regards, Pirmin
Thanks everyone for your support!
On 9/5/18 9:44 PM, Hinnerk van Bruinehsen wrote:
If I can get the display issue resolved, I'd put some time into porting the wifi driver...
Great!
On 9/6/18 10:45 AM, Norman Feske wrote:
Both problems can be addressed by increasing the respective RAM quotas.
I updated the quotas accordingly [1]. With the resolution limitation to 1920 still in place, the resource requests are gone and as far as I can tell everything looks reasonable - except the page fault [2].
Another observation is that if the resolution limitation is in place, when I now update the fb_drv configuration to enable the internal display with its native resolution, it shows the following screen [3] (it's the photograph that's blurry, not the display ;). Please note the cursor is usable across the whole screen. I thought this might be a side effect of the resolution limitation, removed it and booted again. But when I remove the resolution limitation, report_dump doesn't work.
On 9/6/18 11:13 AM, Christian Helmuth wrote:
We had an offline discussion about this topic some weeks ago and as far as I can remember the effort to enable ath10k should be reasonable. This does not mean its quite some work esp. on the debugging side if the added driver's requirements exceed the currently provided emulation environment. Maybe you can join forces with Hinnerk in the debugging phase at least. Please feel free to open a feature issue on GitHub for the developments as I'm aware of at least one other potential user (who's not me).
I don't have any experiences in porting Linux drivers to Genode so I can't contribute substantially. But if testing/logs are required, I'm very eager to help! I feel I'm in good hands and will get an XPS 13 9370 :)
Cheers, Roman
[1] https://github.com/rite/genode/commit/e7bbca769ba9603d8e748bc01563ed13f21dcb...
[2] https://gist.github.com/rite/25fb91c4727b7941d24cddcda963013a#file-log-L400
[3] https://www.dropbox.com/s/3gemafhr6mrov1s/sculpt_xps13.png?dl=0
Hi
I updated the quotas accordingly [1]. With the resolution limitation to 1920 still in place, the resource requests are gone and as far as I can tell everything looks reasonable - except the page fault [2].
I tried the same quotas without the resolution limitation on a device with a FHD display. After booting Sculpt, I connected an external 4K monitor. The moment I enable it with its native resolution, all screens go black and intel_fb_drv logs the following error [1]:
Error: cap reference counting error - one counter of cap range 49155+1 has been already zero.
Any ideas where to look next?
Thanks, Roman
[1] https://gist.github.com/rite/18e260e0f859c5fe05c1834f923c382e#file-intel_fb_...
Hi,
On 9/12/18 6:04 PM, Roman Iten wrote:
I updated the quotas accordingly [1]. With the resolution limitation to 1920 still in place, the resource requests are gone and as far as I can tell everything looks reasonable - except the page fault [2].
I tried the same quotas without the resolution limitation on a device with a FHD display. After booting Sculpt, I connected an external 4K monitor. The moment I enable it with its native resolution, all screens go black and intel_fb_drv logs the following error [1]:
Error: cap reference counting error - one counter of cap range 49155+1 has been already zero.
This is a warning and probably is caused by a double free of some structure containing a capability. You would have need to instrument the driver to catch the bug.
Nevertheless, your actually issue is the resource_request for memory at the end of your log.
Alex
Hi
After some try-and-error and tweaking I succeeded in booting Sculpt and inspecting the system. I made an issue on GitHub with the quota assignments [1]. The chosen RAM quotas not only support the XPS' resolution of 3200x1800 but resolutions up to 4K UHD (3840x2160) instead.
I didn't tried more complex runtimes like vbox though.
Cheers, Roman
Hi
On 9/14/18 6:46 PM, Roman Iten wrote:
I didn't tried more complex runtimes like vbox though.
This weekend, I intended to begin sculpting my system. I spent some time bisecting the commit history because every time I pressed F12 the system froze (pointer, log, report_dump, ...). Long story short I eventually realized that not F12 key caused the freeze, but the key combination FN+F12 (FN-Lock, toggled by FN+Esc, happend to be enabled...)
So it turns out that at least pressing FN+F8 (toggle? display), FN+F11 (decrease brightness) and FN+F12 (increase brightness) render the system unusable.
Do you have some suggestions how to debug the problem?
Cheers, Roman
Hi,
On 08.10.2018 22:21, Roman Iten wrote:
This weekend, I intended to begin sculpting my system. I spent some time bisecting the commit history because every time I pressed F12 the system froze (pointer, log, report_dump, ...). Long story short I eventually realized that not F12 key caused the freeze, but the key combination FN+F12 (FN-Lock, toggled by FN+Esc, happend to be enabled...)
So it turns out that at least pressing FN+F8 (toggle? display), FN+F11 (decrease brightness) and FN+F12 (increase brightness) render the system unusable.
Do you have some suggestions how to debug the problem?
does it happen with or without acpica as app running ?
Cheers,
Alex.
On 10/9/18 1:50 PM, Alexander Boettcher wrote:
So it turns out that at least pressing FN+F8 (toggle? display), FN+F11 (decrease brightness) and FN+F12 (increase brightness) render the system unusable.
does it happen with or without acpica as app running ?
It happens in both cases: with vanilla sculpt where no app is running as well as with acpica running.
On 09.10.2018 15:03, Roman Iten wrote:
On 10/9/18 1:50 PM, Alexander Boettcher wrote:
So it turns out that at least pressing FN+F8 (toggle? display), FN+F11 (decrease brightness) and FN+F12 (increase brightness) render the system unusable.
does it happen with or without acpica as app running ?
It happens in both cases: with vanilla sculpt where no app is running as well as with acpica running.
I suspect your embedded controller together with ACPI irq handling, but it is just guessing.
I presume you don't have serial output available?
May you please try some simple (non graphical) run scenario (usb_hid). If this also already get stuck when you press your keys, can you please setup the nova spinner setup for the nova kernel, see [0]. You will have to boot in non-UEFI mode (either USB or if not working try via PXE).
Does some running spinner get stuck or become running at a high speed ?
If you need VGA text console output from Genode's side, you may try to adjust my outdated commit of [1] - or maybe (never used it myself) try to use [3] as mentioned in [2].
Good luck,
Alex.
[0] https://lists.genode.org/pipermail/users/2018-October/006392.html [1] https://github.com/alex-ab/genode/commits/experimental_vga_console_16_08 [2] https://github.com/genodelabs/genode/issues/2880 [3] https://github.com/jklmnn/genode-trabant/tree/vga_scrolling/src/drivers/vga_...
Hi
On 10/10/18 11:11 AM, Alexander Boettcher wrote:
I suspect your embedded controller together with ACPI irq handling, but it is just guessing.
The freeze occurs on the XPS 13 9350 but not on the newer model 9370. And now that I know how to avoid the problem, it isn't a very pressing issue for me anymore. But if you suspect other devices might have a similar problem, I'm in for helping investigate.
I presume you don't have serial output available?
No, unfortunately I haven't.
May you please try some simple (non graphical) run scenario (usb_hid). If this also already get stuck when you press your keys, can you please setup the nova spinner setup for the nova kernel, see [0]. You will have to boot in non-UEFI mode (either USB or if not working try via PXE).
The usb_hid run scenario doesn't get stuck when booting in non-UEFI mode. I'm using the very convenient vga_log_drv (thanks to Johannes Kliemann!) the get an impression of the liveliness of the system - for reference see [1] and [2].
Out of curiosity I also tried to boot Sculpt in non-UEFI mode. The system doesn't freeze when pressing FN+F11/F12 but the display brightness decreases/increases instead.
So I guess the next step is to boot in UEFI mode with VGA log output enabled and setup the nova spinner?
Cheers, Roman
[1] https://github.com/rite/genode/tree/18.08-debug-xps-fn-freeze [2] https://github.com/rite/genode-trabant/tree/vga_log
Hi Roman,
The usb_hid run scenario doesn't get stuck when booting in non-UEFI mode. I'm using the very convenient vga_log_drv (thanks to Johannes Kliemann!) the get an impression of the liveliness of the system - for reference see [1] and [2].
I'm happy someone benefits from my work :) Just some notes, I've seen you already fixed the broken include path I thought I fixed it already but apparently I didn't seem to have pushed it. Aside from that I was planning to unify my current feature branches into my genode-trabant/master and to adapt the code to the current state of the Ada runtime available in Genode (I didn't touch this driver for some time so I have to update myself about its current state). Furthermore I plan to document it a little more in this process.
I also found that with the current genode/master Nova seems to boot-loop when the debug commit is applied. I opened an issue [1] about this, but it seems that it still works with your version of 18.08.
Out of curiosity I also tried to boot Sculpt in non-UEFI mode. The system doesn't freeze when pressing FN+F11/F12 but the display brightness decreases/increases instead.
So I guess the next step is to boot in UEFI mode with VGA log output enabled and setup the nova spinner?
Afaik the vga_log_drv is not available on UEFI since the Multiboot2 framebuffer info is filled with UEFIs UGA/GOP framebuffer. You'd need to use the boot_fb with a terminal log then.
Regards, Johannes
On 11.10.2018 14:59, Roman Iten wrote:
On 10/10/18 11:11 AM, Alexander Boettcher wrote:
I suspect your embedded controller together with ACPI irq handling, but it is just guessing.
The freeze occurs on the XPS 13 9350 but not on the newer model 9370. And now that I know how to avoid the problem, it isn't a very pressing issue for me anymore. But if you suspect other devices might have a similar problem, I'm in for helping investigate.
Well, without any debug output... If you manage to provide it, we may continue - otherwise I would spend my/your time more gainful.
I presume you don't have serial output available?
No, unfortunately I haven't.
May you please try some simple (non graphical) run scenario (usb_hid). If this also already get stuck when you press your keys, can you please setup the nova spinner setup for the nova kernel, see [0]. You will have to boot in non-UEFI mode (either USB or if not working try via PXE).
The usb_hid run scenario doesn't get stuck when booting in non-UEFI mode. I'm using the very convenient vga_log_drv (thanks to Johannes Kliemann!) the get an impression of the liveliness of the system - for reference see [1] and [2].
I hoped you can reproduce it without UEFI - well in this case I have no good suggestions.
Out of curiosity I also tried to boot Sculpt in non-UEFI mode. The system doesn't freeze when pressing FN+F11/F12 but the display brightness decreases/increases instead.
So I guess the next step is to boot in UEFI mode with VGA log output enabled and setup the nova spinner?
AFAIK, there is no support for VGA text console by UEFI booted systems, so probably this is a dead end.
Cheers,
Hello Roman,
I like your delightful Sculpt story ;-)
On Wed, Sep 05, 2018 at 06:51:07PM +0200, Roman Iten wrote:
- On Sculpt, most/all? internal displays report only their native
resolution. On the XPS this is 3200 x 1800 and I can't force a lower resolution. Although under Linux, xrandr reports a bunch of supported resolutions from 3200 x 1800 down to 640 x 360. Does the intel_fb_drv under Genode intentionally reports and supports only the native resolution?
From my experience current laptop panels do not support display
resolutions beyond the factory setting. The illusion of a range of display resolutions provided by the Linux drivers (and also the VGABIOS) is implemented by setting up some hardware scaler which converts the pixels from the used resolution to the native one. Our driver port does not initialize this feature yet.
- Instead of installing Sculpt directly on my current laptop I consider
to buy a new XPS 13 (9370). It has a Killer 1435 wireless module featuring a Qualcomm Atheros QCA6174A chip which seems to be supported on Linux by the ath10k module... Has someone any experience (or assumptions) whether there's a chance that it will work on Sculpt (right now or in the near future)?
We had an offline discussion about this topic some weeks ago and as far as I can remember the effort to enable ath10k should be reasonable. This does not mean its quite some work esp. on the debugging side if the added driver's requirements exceed the currently provided emulation environment. Maybe you can join forces with Hinnerk in the debugging phase at least. Please feel free to open a feature issue on GitHub for the developments as I'm aware of at least one other potential user (who's not me).
Greets
Hello,
it would be nice if the users of the Dell XPS could drop me a note (off-list is fine) about the exact configuration of their systems and the state of the support on Genode, i.e. which devices are working or not and other relevent information (like the ACPI issues) so I can add the systems to my HCL.
Regards,
-
Alexander Boettcher -
Christian Helmuth -
Hinnerk van Bruinehsen -
Johannes Kliemann -
John J. Karcher -
Josef Söntgen -
Nobody III -
Norman Feske -
Pirmin Duss -
Roman Iten