Hello Sculpt users,
we entered the testing phase for the upcoming Sculpt 23.10. Before the final release, we like to invite early adopters to give our release candidate a try and report back experiences (or issues) with their use cases.
The current candidate is RC4 and can be retrieved via the "System -> Update" dialog in entry https://depot.genode.org/chelmuth of your current Sculpt installation. Alternatively, you may download the image from the following URL.
https://depot.genode.org/chelmuth/image/sculpt-pc-2023-10-10.img.xz
Happy Sculpting
Christian
Hello Christian
On 10/10/23 11:24, Christian Helmuth wrote:
Hello Sculpt users,
we entered the testing phase for the upcoming Sculpt 23.10. Before the final release, we like to invite early adopters to give our release candidate a try and report back experiences (or issues) with their use cases.
The current candidate is RC4 and can be retrieved via the "System -> Update" dialog in entry https://depot.genode.org/chelmuth of your current Sculpt installation. Alternatively, you may download the image from the following URL.
https://depot.genode.org/chelmuth/image/sculpt-pc-2023-10-10.img.xz
I did give the image a quick try on my i7 11700 desktop.
When I try to activate the wired network I get the following output:
[init -> nic_drv] time-clocksource: dde_counter: mask: 0xffffffffffffff max_cycles: 0x1d854df40, max_idle_ns: 3526361616960 ns [init -> nic_drv] time-clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns [init -> nic_drv] time-clocksource: Switched to clocksource dde_counter [init -> nic_drv] e1000-e1000_main: Intel(R) PRO/1000 Network Driver [init -> nic_drv] e1000-e1000_main: Copyright (c) 1999-2006 Intel Corporation. [init -> nic_drv] e1000e-netdev: Intel(R) PRO/1000 Network Driver [init -> nic_drv] e1000e-netdev: Copyright(c) 1999 - 2015 Intel Corporation. [init -> nic_drv] realtek-r8169_main 07:00.0 eth0: RTL8168e/8111e, 08:be:ac:22:6c:52, XID 2c2, IRQ 21 [init -> nic_drv] realtek-r8169_main 07:00.0 eth0: jumbo features [frames: 9194 bytes, tx checksumming: ko] [init -> nic_drv] sched_clock: Marking stable (135525000, 255074000)->(417182000, -26583000) [init -> nic_drv] realtek-r8169_main 07:00.0: Unable to load firmware rtl_nic/rtl8168e-2.fw (-1) [init -> nic_drv] RTL8211DN Gigabit Ethernet r8169-0-0:00: attached PHY driver (mii_bus:phy_addr=r8169-0-0:00, irq=MAC) [init -> nic_drv] realtek-r8169_main 07:00.0 eth0: No native access to PCI extended config space, falling back to CSI [init -> nic_drv] Error: Function pcie_capability_clear_and_set_word not implemented yet! [init -> nic_drv] Backtrace follows: Error: illegal READ at address 0xfffffffffffa77b8 by pager_object: pd='init -> nic_drv' thread='ep' ip=0x10a8330
The card is plugged to one of the PCIe ports, as the onboard controller is an Intel IGC 2.5GB adapter.
Linux reports (`lspci -vv`): 07:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06) Subsystem: Realtek Semiconductor Co., Ltd. Device 0123 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 19 Region 0: I/O ports at 3000 [size=256] Region 2: Memory at 6010904000 (64-bit, prefetchable) [size=4K] Region 4: Memory at 6010900000 (64-bit, prefetchable) [size=16K] Capabilities: <access denied> Kernel driver in use: r8169 Kernel modules: r8169
dmesg: [ 1.535318] r8169 0000:07:00.0: enabling device (0000 -> 0003) [ 1.535415] r8169 0000:07:00.0: can't disable ASPM; OS doesn't have ASPM control [ 1.537162] r8169 0000:07:00.0 eth0: RTL8168e/8111e, 08:be:ac:22:6c:52, XID 2c2, IRQ 153 [ 1.537165] r8169 0000:07:00.0 eth0: jumbo features [frames: 9194 bytes, tx checksumming: ko] [ 4.922396] r8169 0000:07:00.0 enp7s0: renamed from eth0 [ 14.174715] RTL8211DN Gigabit Ethernet r8169-0-700:00: attached PHY driver (mii_bus:phy_addr=r8169-0-700:00, irq=MAC) [ 14.461989] r8169 0000:07:00.0 enp7s0: Link is Down [ 17.257971] r8169 0000:07:00.0 enp7s0: Link is Up - 1Gbps/Full - flow control rx/tx
I will check on the week end if the card works with an older sculpt version, as I never have used it with sculpt. My main use case up until now was to do iPXE-boot with it while testing the driver for the Intel IGC nic.
Regards, Pirmin
Hello Pirmin,
On Wed, Oct 11, 2023 at 19:00:27 CEST, Pirmin Duss wrote:
[init -> nic_drv] realtek-r8169_main 07:00.0 eth0: No native access to PCI extended config space, falling back to CSI [init -> nic_drv] Error: Function pcie_capability_clear_and_set_word not implemented yet! [init -> nic_drv] Backtrace follows: Error: illegal READ at address 0xfffffffffffa77b8 by pager_object: pd='init -> nic_drv' thread='ep' ip=0x10a8330
[...]
I will check on the week end if the card works with an older sculpt version, as I never have used it with sculpt. My main use case up until now was to do iPXE-boot with it while testing the driver for the Intel IGC nic.
Note that the "illegal READ" stems from the attempt to backtrace the stack without frame pointer but the driver would stop anyway because of the "Function pcie_capability_clear_and_set_word not implemented".
I implemented pcie_capability relevant dummy functions on my sculpt_23_10 this morning and published an updated RC6 at the following URL.
https://depot.genode.org/chelmuth/image/sculpt-pc-2023-10-12.img.xz
Maybe you have more luck with the new image. If not, keep us updated here.
The card is plugged to one of the PCIe ports, as the onboard controller is an Intel IGC 2.5GB adapter.
Did you make any progress with the IGC driver developments you started beginning of 2023? Maybe adding the approp. driver to pc_nic_drv is a less elaborate option now.
Greets
Hello Christian
On 2023-10-12 13:53, Christian Helmuth wrote:
https://depot.genode.org/chelmuth/image/sculpt-pc-2023-10-12.img.xz
Maybe you have more luck with the new image. If not, keep us updated here.
With the new version of the image, nic_router gets the expected dynamic IP-address assigned.
The card is plugged to one of the PCIe ports, as the onboard controller is an Intel IGC 2.5GB adapter.
Did you make any progress with the IGC driver developments you started beginning of 2023? Maybe adding the approp. driver to pc_nic_drv is a less elaborate option now.
Yes I did make progress, I had updated it up to 23.08 and started testing it.
I was actually thinking about integrating the driver in to pc_nic_drv, last week, when I was debugging why the Linux side of the driver endlessly restarts. I will give this definitively a try, and will keep you updated.
Regards, Pirmin
On Thu, Oct 12, 2023 at 16:32:07 CEST, Pirmin Duss wrote:
With the new version of the image, nic_router gets the expected dynamic IP-address assigned.
That's great news!
Happy Sculpting
Hi Chris,
I ran the correct version this time, wifi still have issues :
[runtime -> wifi_drv] iwlwifi 00:14.3: no suitable firmware found![0m [runtime -> wifi_drv] iwlwifi 00:14.3: minimum version required: iwlwifi-QuZ-a0-jf-b0-39[0m [runtime -> wifi_drv] iwlwifi 00:14.3: maximum version supported: iwlwifi-QuZ-a0-jf-b0-72[0m
Hello Johnny,
On Thu, Oct 19, 2023 at 04:28:33 CEST, Johnny Nunez wrote:
[runtime -> wifi_drv] iwlwifi 00:14.3: no suitable firmware found![0m [runtime -> wifi_drv] iwlwifi 00:14.3: minimum version required: iwlwifi-QuZ-a0-jf-b0-39[0m [runtime -> wifi_drv] iwlwifi 00:14.3: maximum version supported: iwlwifi-QuZ-a0-jf-b0-72[0m
It seems iwlwifi-QuZ-a0-jf-b0 is currently not part of our firmware collection [1] and, thus, not supported. We will look into this.
Meanwhile, could you please send information about your WiFi device (product name, PCI IDs from Linux "sudo lspci -vvvnn -s 00:14.3", maybe notebook model if applicable)?
[1] https://github.com/cnuke/dde_linux_firmware
Regards
On 10/10/23 05:24, Christian Helmuth wrote:
Hello Sculpt users,
we entered the testing phase for the upcoming Sculpt 23.10. Before the final release, we like to invite early adopters to give our release candidate a try and report back experiences (or issues) with their use cases.
The current candidate is RC4 and can be retrieved via the "System -> Update" dialog in entry https://depot.genode.org/chelmuth of your current Sculpt installation. Alternatively, you may download the image from the following URL.
https://depot.genode.org/chelmuth/image/sculpt-pc-2023-10-10.img.xz
Happy Sculpting
Christian
Thanks for this opportunity, Christian!
I've taken it for a quick spin, and didn't notice any problems. I'm going to try some more advanced things - is there anything in particular we should be looking out for?
(BTW, I've said it before and I'll say it again, I love the update mechanism!)
Thanks!
John J. Karcher devuser@alternateapproach.com
Hello John,
On Fri, Oct 20, 2023 at 06:38:51 CEST, John J. Karcher wrote:
I've taken it for a quick spin, and didn't notice any problems. I'm going to try some more advanced things
- is there anything in particular we should be looking out for?
I'm running RC8 from 2023-10-19 (available via the system update) currently, in which we address some GUI and networking issues. So, it would be great if you keep a wary eye on these aspects while using Sculpt.
Thanks for your support and Happy Sculpting
Dear Christian,
Hurray for the Sculpt 23.10 RC!
we entered the testing phase for the upcoming Sculpt 23.10. Before the final release, we like to invite early adopters to give our release candidate a try and report back experiences (or issues) with their use cases.
This morning, I tested version 2023-10-19 on my Razer Blade 15 (2018). First, the update went smoothly, and I haven't experienced issues with networking. After duplicating my 'vbox6-block' PKG locally and adjusting the archives list to yours 'chelmuth/pkg/vbox6/2023-10-19/archives', my work's VM booted flawlessly. =)
However, I have one minor issue. When plugging more than one USB input device, any USB input devices connected become unresponsive. That includes the built-in keyboard. Unfortunately, the built-in trackpad does not work for unrelated reasons, so I have no other choices but
to reboot the device.
Here are the scenario and logs - First, a USB mouse is already plugged in. - I connected a USB stick (to store logs and access it later; the issue appears regardless of the presence of a USB stick) - Then, I connected the external USB keyboard. Both the internal and external USB keyboard and mouse become unresponsive. - A resource request appears. - I unplugged and re-plugged the external keyboard, but the USB input devices are still unresponsive.
--- sculpt.log [runtime -> usb-3-7.drv] Found USB device: SanDisk (Ultra Luxe) block size: 512 count: 60088320 [runtime] child "usb-3-7.drv" announces service "Block" [runtime -> usb-3-7.part_block] GPT Partition 1: LBA 40 (101 blocks) type: '21686148-6449-6e6f-744e-656564454649' name: 'BIOSBOOT' [runtime -> usb-3-7.part_block] GPT Partition 2: LBA 141 (3811 blocks) type: 'c12a7328-f81f-11d2-ba4b-00a0c93ec93b' name: 'GRUB2' [runtime -> usb-3-7.part_block] GPT Partition 3: LBA 4096 (60084190 blocks) type: '0fc63daf-8483-4772-8e79-3d69d8477de4' name: 'GENODE' [runtime] child "usb-3-7.part_block" announces service "Block" [runtime -> usb-3-7.3.fs] rump: /genode: file system not clean; please fsck(8) [runtime] child "usb-3-7.3.fs" announces service "File_system" [drivers -> usb_drv] usb 3-3: new full-speed USB device number 9 using xhci_hcd [drivers -> usb_drv] usb 3-3: usbfs: process 21 () did not claim interface 0 before use [drivers -> usb_hid_drv] input: HID 1532:0257 as /devices/usb-3-9/0-0:1.0/0003:1532:0257.000A/input/input22 [drivers -> usb_hid_drv] Connected device: input22 (HID 1532:0257 at usb-usbbus-0/input0) [drivers -> usb_hid_drv] hid-generic 0003:1532:0257.000A: input: USB HID v1.11 Keyboard [HID 1532:0257] on usb-usbbus-0/input0 [drivers -> usb_drv] usb 3-3: usbfs: process 21 () did not claim interface 1 before use [drivers -> usb_hid_drv] input: HID 1532:0257 Keyboard as /devices/usb-3-9/0-0:1.1/0003:1532:0257.000B/input/input23 [drivers -> usb_hid_drv] Connected device: input23 (HID 1532:0257 Keyboard at usb-usbbus-0/input1) [drivers -> usb_hid_drv] input: HID 1532:0257 as /devices/usb-3-9/0-0:1.1/0003:1532:0257.000B/input/input24 [drivers -> usb_hid_drv] Connected device: input24 (HID 1532:0257 at usb-usbbus-0/input1)[0m [drivers -> usb_hid_drv] hid-generic 0003:1532:0257.000B: input: USB HID v1.11 Keyboard [HID 1532:0257] on usb-usbbus-0/input1 [drivers -> usb_drv] usb 3-3: usbfs: process 21 () did not claim interface 2 before use [drivers -> usb_hid_drv] input: HID 1532:0257 as /devices/usb-3-9/0-0:1.2/0003:1532:0257.000C/input/input25 [drivers -> usb_hid_drv] Connected device: input25 (HID 1532:0257 at usb-usbbus-0/input2) [drivers -> usb_hid_drv] hid-generic 0003:1532:0257.000C: input: USB HID v1.11 Mouse [HID 1532:0257] on usb-usbbus-0/input2 [drivers -> usb_drv] usb 3-3: usbfs: process 21 () did not claim interface 3 before use [drivers -> usb_hid_drv] input: HID 1532:0257 Consumer Control as /devices/usb-3-9/0-0:1.3/0003:1532:0257.000D/input/input26 [drivers] child "usb_hid_drv" requests resources: cap_quota=3 [drivers -> usb_drv] usb 3-3: USB disconnect, device number 9 [drivers -> usb_drv] usb 3-3: new full-speed USB device number 10 using xhci_hcd [drivers -> usb_drv] usb 3-3: USB disconnect, device number 10 ---
Currently, using only the external USB mouse and the internal, but less preferred, 'AZERTY' keyboard is fine by me!
Cheers, Alice
On Fri, Oct 20, 2023 at 09:54:40 CEST, Alice wrote:
However, I have one minor issue. When plugging more than one USB input device, any USB input devices connected become unresponsive. That includes the built-in keyboard. Unfortunately, the built-in trackpad does not work for unrelated reasons, so I have no other choices but
to reboot the device.
[...]
[drivers -> usb_drv] usb 3-3: new full-speed USB device number 9 using xhci_hcd [drivers -> usb_drv] usb 3-3: usbfs: process 21 () did not claim interface 0 before use [drivers -> usb_hid_drv] input: HID 1532:0257 as /devices/usb-3-9/0-0:1.0/0003:1532:0257.000A/input/input22 [drivers -> usb_hid_drv] Connected device: input22 (HID 1532:0257 at usb-usbbus-0/input0) [drivers -> usb_hid_drv] hid-generic 0003:1532:0257.000A: input: USB HID v1.11 Keyboard [HID 1532:0257] on usb-usbbus-0/input0 [drivers -> usb_drv] usb 3-3: usbfs: process 21 () did not claim interface 1 before use [drivers -> usb_hid_drv] input: HID 1532:0257 Keyboard as /devices/usb-3-9/0-0:1.1/0003:1532:0257.000B/input/input23 [drivers -> usb_hid_drv] Connected device: input23 (HID 1532:0257 Keyboard at usb-usbbus-0/input1) [drivers -> usb_hid_drv] input: HID 1532:0257 as /devices/usb-3-9/0-0:1.1/0003:1532:0257.000B/input/input24 [drivers -> usb_hid_drv] Connected device: input24 (HID 1532:0257 at usb-usbbus-0/input1)[0m [drivers -> usb_hid_drv] hid-generic 0003:1532:0257.000B: input: USB HID v1.11 Keyboard [HID 1532:0257] on usb-usbbus-0/input1 [drivers -> usb_drv] usb 3-3: usbfs: process 21 () did not claim interface 2 before use [drivers -> usb_hid_drv] input: HID 1532:0257 as /devices/usb-3-9/0-0:1.2/0003:1532:0257.000C/input/input25 [drivers -> usb_hid_drv] Connected device: input25 (HID 1532:0257 at usb-usbbus-0/input2) [drivers -> usb_hid_drv] hid-generic 0003:1532:0257.000C: input: USB HID v1.11 Mouse [HID 1532:0257] on usb-usbbus-0/input2 [drivers -> usb_drv] usb 3-3: usbfs: process 21 () did not claim interface 3 before use [drivers -> usb_hid_drv] input: HID 1532:0257 Consumer Control as /devices/usb-3-9/0-0:1.3/0003:1532:0257.000D/input/input26 [drivers] child "usb_hid_drv" requests resources: cap_quota=3 [drivers -> usb_drv] usb 3-3: USB disconnect, device number 9 [drivers -> usb_drv] usb 3-3: new full-speed USB device number 10 using xhci_hcd [drivers -> usb_drv] usb 3-3: USB disconnect, device number 10
The issue is with the usb_hid_drv and, for this reason, usb_drv and also USB storage are not affected. The upcoming Sculpt release utilizes the new USB HID driver, which seems to have increased resource demands (capabilities in this case). As the drivers subsystem builds on a static init runtime the resource request is not automatically solved.
I increased the cap quota for usb_hid_drv and published a new RC image based on the current staging branch. Note, RC9 is just an image update, no depot archives changed from RC8.
Regards
On 10/20/23 08:32, Christian Helmuth wrote:
The upcoming Sculpt release utilizes the new USB HID driver, which seems to have increased resource demands (capabilities in this case). As the drivers subsystem builds on a static init runtime the resource request is not automatically solved.
I increased the cap quota for usb_hid_drv and published a new RC image based on the current staging branch. Note, RC9 is just an image update, no depot archives changed from RC8.
Interesting. Is there any chance that the updated USB HID driver would enable Wacom touchscreen and pen support? On my ThinkPad Yoga, touching the screen or using the pen still doesn't work, but locks out all future mouse clicks, using version 2023.10.10.
Has anyone else tried this?
Thanks!
John J. Karcher devuser@alternateapproach.com
Hello John,
On Fri, Oct 20, 2023 at 19:58:51 CEST, John J. Karcher wrote:
Interesting. Is there any chance that the updated USB HID driver would enable Wacom touchscreen and pen support? On my ThinkPad Yoga, touching the screen or using the pen still doesn't work, but locks out all future mouse clicks, using version 2023.10.10.
We did not address USB touchscreen support in the updated HID driver, but disabled absolute motion handling for now. I do not have a Wacom device at hand but my ELAN touchscreen reports BTN_LEFT press/release on touch and logs dropped events.
Dropping unsupported Event[1/2] device=HID 04f3:2269 Touchscreen type=ABS code=X value=2212
For some reason, the Linux driver code seems to interpret your Wacom events differently and confuses the input handling. You may have a look at it with the event filter <log> feature.
1. Copy /config/managed/event_filter to /config/ 2. Find line <input name="usb"/> in /config/event_filter 3. Change to <log prefix="USB "><input name="usb"/></log> 4. Examine /report/log for the reported input events
Regards
On 10/23/23 02:44, Christian Helmuth wrote:
Hello John,
On Fri, Oct 20, 2023 at 19:58:51 CEST, John J. Karcher wrote:
Interesting. Is there any chance that the updated USB HID driver would enable Wacom touchscreen and pen support? On my ThinkPad Yoga, touching the screen or using the pen still doesn't work, but locks out all future mouse clicks, using version 2023.10.10.
We did not address USB touchscreen support in the updated HID driver, but disabled absolute motion handling for now. I do not have a Wacom device at hand but my ELAN touchscreen reports BTN_LEFT press/release on touch and logs dropped events.
Dropping unsupported Event[1/2] device=HID 04f3:2269 Touchscreen type=ABS code=X value=2212
For some reason, the Linux driver code seems to interpret your Wacom events differently and confuses the input handling. You may have a look at it with the event filter <log> feature.
- Copy /config/managed/event_filter to /config/
- Find line <input name="usb"/> in /config/event_filter
- Change to <log prefix="USB "><input name="usb"/></log>
- Examine /report/log for the reported input events
Thanks for the detailed instructions! Sorry for taking so long to respond to this.
I noticed Norman's mention of your efforts to add touchscreen support in the "What's new in Sculpt OS 23.10" Genodians article, and I've been testing using your depot. I have attached some relevant lines from the log, using both finger and pen.
There are quite a few dropped events, and both the pen and touch seem to confuse Nitpicker, because no further button clicks are registered until rebooting. Fortunately the keyboard continues to work, which is how I could save the log file. :^)
I would love to continue testing this as you continue. (Now that I know how to do it, I will respond faster.) I will keep an eye on your depot - please let me know how I can best help!
Thanks!
John J. Karcher devuser@alternateapproach.com
Hi John,
On Fri, Nov 17, 2023 at 07:36:03 CET, John J. Karcher wrote:
[core] [init -> drivers -> usb_hid_drv] Dropping unsupported Event[1/3] device=HID 056a:5158 Stylus type=ABS code=X value=14535 [core] [init -> drivers -> usb_hid_drv] Dropping unsupported Event[2/3] device=HID 056a:5158 Stylus type=ABS code=Y value=10427 [core] [init -> drivers -> usb_hid_drv] Dropping unsupported Event[1/3] device=HID 056a:5158 Stylus type=ABS code=X value=14552 [core] [init -> drivers -> usb_hid_drv] Dropping unsupported Event[2/3] device=HID 056a:5158 Stylus type=ABS code=Y value=10397
Unfortunately, we not yet support ABS mode events in DDE Linux as we concentrated on multi-touch mode touchpads. I wonder why your touchscreen is not driven in the latter mode, but this may be because the stylus is used.
Do you know of any EFI/BIOS mode settings for the touchscreen/stylus that may help? If not, we had to enable ABS mode in the USB HID driver for graphics tables/stylus devices. Would you mind to send all report/log entries prefixed with [init -> drivers -> usb_hid_drv]?
[core] [init -> drivers -> event_filter] USB event #5 PRESS BTN_LEFT 65534 key count: 2 [core] [init -> drivers -> event_filter] USB event #6 RELEASE BTN_LEFT key count: 1 [core] [init -> drivers -> event_filter] USB event #7 RELEASE BTN_TOOL_PEN key count: 0 [core] [init -> drivers -> event_filter] USB event #8 PRESS BTN_LEFT 65534 key count: 1 [core] [init -> drivers -> event_filter] USB event #9 PRESS BTN_0 65534 key count: 2 [core] [init -> drivers -> event_filter] USB event #10 RELEASE BTN_LEFT key count: 1 [core] [init -> drivers -> event_filter] USB event #11 PRESS BTN_LEFT 65534 key count: 2 [core] [init -> drivers -> event_filter] USB event #12 RELEASE BTN_LEFT key count: 1
This shows the stylus reports BTN_TOOL_PEN and BTN_0, which may cause the confusion in nitpicker . For robustness, you may insert the following options into /config/event_filter into the <remap> node where <key> nodes are defined.
<ignore-key name="BTN_0"/> <ignore-key name="BTN_TOOL_PEN"/>
Regards