Thanks. I guess I would like people to point me in the right direction at least so I know what to try and so I know that I'm not getting ignored. As for your suggestion, it doesn't change anything. Note that rump_fs works with usb_drv just fine. There seems to be something wrong with part_blk interacting with hardware drivers. Is there any safe (non-writing) Block test that I can try on my computer? Also, can part_blk_ahci be tested on some of the test machines over there?
On Wed, Jan 7, 2015 at 11:05 PM, Norman Feske <norman.feske@...1...> wrote:
Hi Ben,
please don't feel offended when a particular post of your's does not receive immediate attention. Most of the regular developers want to give profound advice rather than shooting in the blue. For coming up with a good advise, however, one must take some time to investigate. This is particularly the case for assisting with practical troubleshooting, which often requires experimentation. Given the fact that each of us works quite intensively on topics different from your's, it is not always possible to prioritize your questions over the current line of work. Sometimes, a meaningful response may take some days. Should a question remain unanswered for a week, a wake-up message from your side is appreciated. ;-)
On 01/06/2015 02:55 AM, Nobody III wrote:
I have been experimenting with things related to my issue when using part_blk with ahci, and I have found that it works fine in both QEMU and Virtualbox. However, when I combine part_blk with usb_drv, I encounter what appears to be the exact same problem, but it only occurs on some of the kernels. The scenario works bug-free on okl4 and fiasco, but freezes on foc and nova. Note that other servers such as rump_fs work just fine with the usb driver, so the problem isn't a simple driver failure. I've attached the run script for the usb and part_blk scenario. I hope this helps fix my AHCI issue (which only occurs on real hardware) as well.
Good that you could draw the line between these kernels. In fact, OKL4 and L4/Fiasco solely rely on the legacy PIC (programmable interrupt controller) whereas Fiasco.OC and NOVA use the APIC. When using the APIC however, the interrupt numbers found in the PCI devices do not correspond to the numbers used (by the kernel and core's IRQ service) to program the interrupt controller. The numbers must be translated according to the information found in the ACPI tables. For this reason, drivers must use the IRQ service provided by the ACPI server instead of the IRQ service provided by core.
In your run script, the default route prefers parent services over child services. Hence, when the USB driver opens an IRQ session, it gets routed to core's IRQ service. The driver looks up the IRQ number of the USB host controller by looking into the controller's PCI configuration space and then opens an IRQ session at core with the untranslated number. Eventually, the driver listens to the wrong interrupt. Try equipping the USB driver with the following route:
<route> <service name="IRQ"> <child name="acpi" /> </service> <any-service> <parent /> <any-child /> </any-service> </route>
This way, IRQ session requests from the USB driver will go to the ACPI server, which applies the necessary translation of interrupt numbers. Under the hood, the ACPI server opens an IRQ session at core, but using the translated number. For more information, there is a README file for the ACPI driver:
https://github.com/genodelabs/genode/blob/master/repos/os/src/drivers/acpi/R...
Cheers Norman
-- Dr.-Ing. Norman Feske Genode Labs
http://www.genode-labs.com · http://genode.org
Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main