I don't know if anyone else is experiencing anything like this, but I am getting a blank screen after booting Sculpt 20.11 on my ThinkPad L380 Yoga. The mouse pointer does display (and move), so the system is alive, but Leitzentrale never appears.
20.08 worked fine. FWIW, I built a version from Master last week, but that has the same result.
Is this a known issue? Is there anything I can reconfigure, etc.?
Thanks!
Hello,
On 04.01.21 02:40, John J. Karcher wrote:
I don't know if anyone else is experiencing anything like this, but I am getting a blank screen after booting Sculpt 20.11 on my ThinkPad L380 Yoga. The mouse pointer does display (and move), so the system is alive, but Leitzentrale never appears.
20.08 worked fine. FWIW, I built a version from Master last week, but that has the same result.
Is this a known issue? Is there anything I can reconfigure, etc.?
No, it is not an known issue. I tried 20.11 master and could not encounter the described behavior.
To tackle your issue you may either try
a) to get serial output of the machine - potentially the log messages tell us the reason. If you have a Intel AMT capable machine, [0] helps to setup everything. b) use the report_dump mechanism [1], to write the log messages to the USB stick during boot instead via serial line. c) use git bisect between 20.08 to 20.11 to find the offending commit.
If you need further help or information with one of the steps please ask.
[0] http://genodians.org/chelmuth/2019-01-16-test-machine [1] https://genode.org/documentation/articles/sculpt-vc#Sculpt_as_a_hardware-pro...
Cheers,
On 1/4/21 9:43 AM, Alexander Boettcher wrote:
Hello,
On 04.01.21 02:40, John J. Karcher wrote:
I don't know if anyone else is experiencing anything like this, but I am getting a blank screen after booting Sculpt 20.11 on my ThinkPad L380 Yoga. The mouse pointer does display (and move), so the system is alive, but Leitzentrale never appears.
20.08 worked fine. FWIW, I built a version from Master last week, but that has the same result.
Is this a known issue? Is there anything I can reconfigure, etc.?
No, it is not an known issue. I tried 20.11 master and could not encounter the described behavior.
To tackle your issue you may either try
a) to get serial output of the machine - potentially the log messages tell us the reason. If you have a Intel AMT capable machine, [0] helps to setup everything. b) use the report_dump mechanism [1], to write the log messages to the USB stick during boot instead via serial line. c) use git bisect between 20.08 to 20.11 to find the offending commit.
If you need further help or information with one of the steps please ask.
[0] http://genodians.org/chelmuth/2019-01-16-test-machine [1] https://genode.org/documentation/articles/sculpt-vc#Sculpt_as_a_hardware-pro...
Thanks for the suggestions! I decided to try option B, since I've done it before, and the others are more involved. But I'm having trouble, and I'm not sure where I'm going wrong.
I've built (Nova) Sculpt ISO and IMG images several times, both from the "20.11" label and current master, and tested in VirtualBox and on AMD hardware, with the same results.
1. The "VERSION" file reports "20.09".
2. Trying to fetch some of the depots, including "genodelabs", looks for version "20.09", and results in "unavailable" errors.
Does anyone have any thoughts on this?
Thanks!
John J. Karcher devuser@alternateapproach.com
Hi John,
I'm no Sculpt expert and probably you will receive more comprehensive answer later but:
"John J. Karcher" devuser@alternateapproach.com writes:
I've built (Nova) Sculpt ISO and IMG images several times, both from the "20.11" label and current master, and tested in VirtualBox and on AMD hardware, with the same results.
- The "VERSION" file reports "20.09".
This number seems to come from repos/gems/run/sculpt.run. There was no published Sculpt release with that revision and according to news section on genode.org the last one was 20.08.
- Trying to fetch some of the depots, including "genodelabs", looks
for version "20.09", and results in "unavailable" errors.
genodelabs depot index files are at https://depot.genode.org/genodelabs/index/ and there's no index file for version 20.09.
Does anyone have any thoughts on this?
You can try to change version number in sculpt.run and maybe you will have luck that it will work but I would assume that Christian Helmut did not made this change by accident and there are some incompatibilities introduced.
I think that if you really want latest version you may have to compile software by yourself.
I hope this will help you.
Tomasz Gajewski
Tomasz Gajewski tomga@wp.pl writes:
One correction
I think that if you really want latest version you may have to compile software by yourself.
Possibly you will find software you need in "unofficial" repositories of people from Genode team. Almost all of them have some 20.09 index files with software they provide.
Tomasz Gajewski
Hello,
let me try to clear up the confusion about the Sculpt versioning.
Between any two official Sculpt versions, ABI breakage must be expected. For this reason, we increase the Sculpt version shortly after a Sculpt release so that a developer who publishes a package for testing purposes won't accidentally offer it for the latest official Sculpt release.
In contrast to Sculpt's official version 20.08, the unofficial version 20.09 does not refer to an actual version, but to an arbitrary in-between-two-versions state that is only meaningful for testing. Usually, when testing and running the staging version of Sculpt, one has to publish pkg/sculpt-installation packages under the developer's name to get a usable Sculpt system. In order to make the packages installable in Sculpt, one also needs to have a pubkey and download file located in <genode-dir>/depot/<user>/.
Unfortunately, the building and publishing of the pkg/sculpt-installation package is quite time consuming (e.g., building qt5, virtualbox, etc.). So it may be beneficial to temporarily remove these big packages from repos/gems/recipes/pkg/sculpt-installation/archives.
Fortunately, ABI breakage does not happen all the time. So Thomasz' suggestion to try the index of the other developers is certainly a good idea to try first.
Cheers Norman
Thanks Tomasz and Norman for the helpful information about Sculpt versioning. (I'm still having trouble getting "report_dump" running properly, but I'm still working on that.)
In my efforts to compare 20.08 with later versions, I stumbled across a message in the log file when booting the "sculpt-20-08-b.img" image from the website that may give a clue about the USB problem on this laptop. The "usb_drv" component finds the various devices that are attached, but then it gives this message:
[core] Warning: unresolvable exception 13, pd 'init -> drivers -> usb_drv', thread 'ep', cpu 0, ip=0x1005afc sp=40bfe7c0 bp=0x1410a450 no signal handler
That is that last message from "usb_drv", and the USB stick is not recognized by Leitzentrale.
I realize this isn't much to go on, but can anyone suggest where I might add more log messages to narrow it down? Or any other ideas?
Thanks!
John J. Karcher devuser@alternateapproach.com
Hello John,
thanks for your efforts to pin down the issue. It's unfortunate that usb_drv just dies on your Yoga because it's essential for report_dump to work.
On Tue, Jan 19, 2021 at 22:28:33 CET, John J. Karcher wrote:
[core] Warning: unresolvable exception 13, pd 'init -> drivers -> usb_drv', thread 'ep', cpu 0, ip=0x1005afc sp=40bfe7c0 bp=0x1410a450 no signal handler
This message tells us that usb_drv raised a General Protection Fault, which can have many (fatal) reasons in the driver [1]. In the past, the cause was often misaligned pointer (incl. the stack pointer) in combination with FPU/SSE instructions, but it would be a wild guess in your case and also does not help to pin down the location in code.
Could you share some more information about the hardware specs of the Yoga? For example with a Live Linux
sudo lspci -vvvnn sudo lsusb -vvv sudo lshw -sanitize
Also, I suggest to move the bug hunt to a dedicated issue on GitHub [2].
[1] https://en.wikipedia.org/wiki/General_protection_fault [2] https://github.com/genodelabs/genode/issues/new
Regards
On 1/20/21 4:26 AM, Christian Helmuth wrote:
Hello John,
thanks for your efforts to pin down the issue. It's unfortunate that usb_drv just dies on your Yoga because it's essential for report_dump to work.
On Tue, Jan 19, 2021 at 22:28:33 CET, John J. Karcher wrote:
[core] Warning: unresolvable exception 13, pd 'init -> drivers -> usb_drv', thread 'ep', cpu 0, ip=0x1005afc sp=40bfe7c0 bp=0x1410a450 no signal handler
This message tells us that usb_drv raised a General Protection Fault, which can have many (fatal) reasons in the driver [1]. In the past, the cause was often misaligned pointer (incl. the stack pointer) in combination with FPU/SSE instructions, but it would be a wild guess in your case and also does not help to pin down the location in code.
Could you share some more information about the hardware specs of the Yoga? For example with a Live Linux
sudo lspci -vvvnn sudo lsusb -vvv sudo lshw -sanitize
Also, I suggest to move the bug hunt to a dedicated issue on GitHub [2].
Added as ticket #3997, with the above command outputs attached.
Thanks!
John J. Karcher devuser@alternateapproach.com
-
Alexander Boettcher -
Christian Helmuth -
John J. Karcher -
Norman Feske -
Tomasz Gajewski