Hi Norman
I've been testing the USB driver in the RaspberryPI assigning priorities to each processes, but continue losing events. I have also tried changing the top value of cnt, but still the same result. I will continue doing some independent tests of the driver, mouse, keyboard and network independently. If you have any other suggestions?
Best regards
Hi Reinier,
I have checked the kernel warning about USB's irq, using base_hw and base_foc, and have noted (per 8000 need_trigger_sof calls): (base_hw) - kicked 5, filtered aproximatelly 7600 and triggered aproximatelly 250 IRQs (base_foc) - kicked 3, filtered aproximatelly 7700 and triggered aproximatelly 140 IRQs There is a big difference in the triggered and filtered irqs. Any idea or suggestion??
SOF interrupts are filtered unless the USB driver explicitly calls 'schedule_sof_interrupt' and thereby propagates the next frame-to-deliver via the GUID scratch register to the kernel. If, for some reason, the USB driver is not scheduled timely enough, it might miss the scheduling of a frame. This can happen if the USB driver runs concurrently with another program that consumes a lot of CPU time. In such a scenario, the scheduling of the USB driver depends on the scheduler of the kernel. Since Fiasco.OC has a different scheduler than base-hw, the effect ultimately depends on the kernel. One way to work around it is to run the USB driver at a high priority. I.e., by assigning a priority of "-1" to all components except for the USB and timer drivers. For an example of how to use priorities in Genode, please have a look at the gems/run/wm.run script. Look out for the 'prio_levels' and 'priority' attributes.
Note that this is just a guess. If the effect also occurs when not running a CPU hungry program besides the USB driver, the guess is most likely wrong.
I don't understand the use of cnt variable (need_trigger_sof). Why use 160 as counter top??
This mechanism ensures that an interrupt is delivered every now and then
- even if the USB driver has not scheduled a frame. There are 8000 IRQs
coming in per second. With the value of 160, an interrupt is forwarded to the USB driver every 20 milliseconds, which appeared to me as a low-enough rate to have a negligible effect on the system's performance.
I'm waiting fix this problem to upload the patch to GitHub. I have tested the USB driver using two versions of Fiasco.OC, the default Fiasco.OC version (https://github.com/ssumpf/foc.git) and a more recently version (https://github.com/skalk/foc.git), but have the same problem.
Furthermore I have tested succesfully the support of Genode with Fiasco.OC as microkernel for RaspberryPI using the autopilot tests: (util_mmio,ldso,timer,lwip,rm_fault,rom_blk,tar_rom,noux,libc_ffat,libc_vfs,timed_semaphore,signal,sub_rm,python,thread_join,failsafe,noux_tool_chain_auto, seoul-auto,resource_request,xml_generator,blk_cache,rump_ext2,thread,pthread, netperf_lwip, netperf_lwip_usb30, netperf_lwip_bridge, netperf_lxip, netperf_lxip_usb30, netperf_lxip_bridge) Now I'm trying to test l4linux and other more complex examples.
Hi Reinier,
I've been testing the USB driver in the RaspberryPI assigning priorities to each processes, but continue losing events. I have also tried changing the top value of cnt, but still the same result. I will continue doing some independent tests of the driver, mouse, keyboard and network independently. If you have any other suggestions?
admittedly, I am (almost) running out of ideas. The last resort would be to use Genode's tracing mechanism [1] to obtain a trace of interrupts as received by the USB driver along with information about the state of the USB driver. I would then compare the trace generated with base-hw against the trace generated with base-foc.
Unfortunately, employing the tracing mechanism requires a bit of labor on your side. You will need to develop a so-called trace monitor that assigns a tracing policy to the threads of interest (the ones living in the USB driver) and captures the tracing data. You can find a simple example at os/run/trace.run.
BTW, the tracing framework played an instrumental role for bringing the Rpi USB driver to Genode in the first place. Without it, I certainly would not have succeeded.
[1] http://genode.org/documentation/release-notes/13.08#Light-weight_event_traci...
Best regards Norman
Hi Norman
I will try the tracing machanism to test the USB driver. Is there public the trace monitor version used to bring up the Rpi USB driver on base_hw?
Best regards
On 05/04/2015 04:55 AM, Norman Feske wrote:
Hi Reinier,
I've been testing the USB driver in the RaspberryPI assigning priorities to each processes, but continue losing events. I have also tried changing the top value of cnt, but still the same result. I will continue doing some independent tests of the driver, mouse, keyboard and network independently. If you have any other suggestions?
admittedly, I am (almost) running out of ideas. The last resort would be to use Genode's tracing mechanism [1] to obtain a trace of interrupts as received by the USB driver along with information about the state of the USB driver. I would then compare the trace generated with base-hw against the trace generated with base-foc.
Unfortunately, employing the tracing mechanism requires a bit of labor on your side. You will need to develop a so-called trace monitor that assigns a tracing policy to the threads of interest (the ones living in the USB driver) and captures the tracing data. You can find a simple example at os/run/trace.run.
BTW, the tracing framework played an instrumental role for bringing the Rpi USB driver to Genode in the first place. Without it, I certainly would not have succeeded.
[1] http://genode.org/documentation/release-notes/13.08#Light-weight_event_traci...
Best regards Norman
Hi Reinier,
I will try the tracing machanism to test the USB driver. Is there public the trace monitor version used to bring up the Rpi USB driver on base_hw?
I just went through my old branches and un-buried the attached patch.
Note that it is just a hack I developed for debugging a specific problem (the interaction of the kernel's scheduling with IRQ latencies of the USB driver). Even though it won't be immediately useful for your problem (I even doubt that the patch applies to the current version of Genode), it may still be useful for pointing you to the right places.
Cheers Norman
Hi Norman
Thanks, I was reviewing the patch and trying to bring up it on Genode15.02. I have used the patch and the trace example. It works, but have a problem using the Dwc_otg struct. When remove the usage of the struct to access to USB registers, the monitor works fine, but when try to use the struct it fails. First i'm trying to test it on base_hw and later on base_foc. This the serial output when i try it on the hardware, and the patch adapted to Genode15.02
Genode 15.02-241-g1a3b4ff <local changes> int main(): --- create local services --- int main(): --- start init --- int main(): transferred 252 MB to init int main(): --- init created, waiting for exit condition --- [init] Could not open ROM session for module "ld.lib.so" [init -> platform_drv] --- Raspberry Pi platform driver --- no RM attachment (faulter 219090 with IP 8255b0 attempts to read from address 20980014) init -> timer -> timeout_scheduler: unresolved pagefault at ip=8255b0 core -> pager_activation: cannot submit unknown signal context 0 [init -> trace-usb_drv] --- trace-usb_drv started --- [init -> usb_drv] Services::Services(): Could not read screen resolution in config node [init -> usb_drv] Services::Services(): No <storage> config node found - not starting the USB Storage (Block) service [init -> usb_drv] Services::Services(): No <nic> config node found - not starting the USB Nic (Network) service [init -> usb_drv] Services::Services(): No <raw> config node found - not starting external USB service [init -> usb_drv] Enabled UHCI (USB 1.0/1.1) support [init -> usb_drv] Enabled EHCI (USB 2.0) support [init -> usb_drv] Enabled XHCI (USB 3.0) support
Is there any wrong with the patch and the struct Dwc_otg?
Best regards
On 05/06/2015 05:13 AM, Norman Feske wrote:
Hi Reinier,
I will try the tracing machanism to test the USB driver. Is there public the trace monitor version used to bring up the Rpi USB driver on base_hw?
I just went through my old branches and un-buried the attached patch.
Note that it is just a hack I developed for debugging a specific problem (the interaction of the kernel's scheduling with IRQ latencies of the USB driver). Even though it won't be immediately useful for your problem (I even doubt that the patch applies to the current version of Genode), it may still be useful for pointing you to the right places.
Cheers Norman
One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hi Reinier,
Is there any wrong with the patch and the struct Dwc_otg?
the sole purpose of the struct is the access to one of the USB host-controller registers that was of particular interest for me. For illustrating the tracing facility, it is not really important. The important part is the implementation of the trace monitor.
Anyway, if you want to fix the problem, please have a look at the struct Usb_dwc_otg in base-hw/src/core/include/spec/rpi/pic.h, which does the same thing: It makes the host-controller registers visible within core.
Good luck Norman
-
Norman Feske -
Reinier Millo Sánchez