Hi, I just upgraded from 15.02 to 15.11 and ran my base-hw based os and applications, which have been running for some time on 15.02. The changes made during the update were to the directory structure required by the "platform" changes and gpio driver changes to accomodate the removal of the wait_for_irq method.
immediately after init starts I get a "quota execeeded"mesage:
Starting kernel ...
kernel initialized Genode 15.11 <local changes> int main(): --- create local services --- int main(): --- start init --- int main(): transferred 501 MB to init int main(): --- init created, waiting for exit condition --- Quota exceeded! amount=12288, size=12288, consumed=12288 [init -> uart_drv] int main(int, char**): --- OMAP3 UART driver started --- [init -> ctrl_module] --- Beaglebone Control Module Server --- [init -> platform_drv] --- bbb platform driver running --- [init -> pwm_drv] --- am33xx pwm driver --- . , ,
No changes have been made to available ram constants in board_base so I'm confused as to what caused this message to be generated. Did I miss a change to how quota's are requested and managed?
Any help would be greatly appreciated Bob
Hello Bob,
Am 02.12.2015 um 15:17 schrieb Bob Stewart:
I just upgraded from 15.02 to 15.11 and ran my base-hw based os andapplications, which have been running for some time on 15.02. The changes made during the update were to the directory structure required by the "platform" changes and gpio driver changes to accomodate the removal of the wait_for_irq method.
It's nice to hear that you already got your hands on the new release :)
immediately after init starts I get a "quota execeeded"mesage:
Starting kernel ...
kernel initialized Genode 15.11 <local changes> int main(): --- create local services --- int main(): --- start init --- int main(): transferred 501 MB to init int main(): --- init created, waiting for exit condition --- Quota exceeded! amount=12288, size=12288, consumed=12288 [init -> uart_drv] int main(int, char**): --- OMAP3 UART driver started --- [init -> ctrl_module] --- Beaglebone Control Module Server --- [init -> platform_drv] --- bbb platform driver running --- [init -> pwm_drv] --- am33xx pwm driver --- . , ,
No changes have been made to available ram constants in board_base so I'm confused as to what caused this message to be generated. Did I miss a change to how quota's are requested and managed?
Since 15.05, the accounting of quota on base-hw got much more comprehensive. Most notably, for the costs of PD related things like the page tables [1] or the local representations of capabilities [2] a component must now pay via quota. I assume that your "Quota exceeded" is printed by the Allocator_guard [3] (Otherwise it could only be a 'loader' server component which is unlikely).
The basic sessions (say those of the Genode environment) are given an initial amount of quota. This amount is a guess on how much is needed to bring the component up. If this quota does not suffice, the session asks the parent to upgrade it by using some of the components slack quota. If its slack quota isn't sufficient for that, the component still may ask its parent to donate some more. So, the quota you assign to a component via the init configuration is the guaranteed minimum the component receives. Init may or may not - depending from what is left after starting all children and saving some quota for itself - hand in more quota to components if they ask for.
During these mechanisms, the Allocator_guard is the one that applies given quota limits to allocations by wrapping the background allocator. That said, the warning indicates that you've reached a limit but it does not necessarily indicate a problem as, in return, your scenario may be able to relax the limit.
And even more, there are places in Genode where reaching the limit is expected. My favourite explanation in your case is the upgrade_pd_session_quota function that triggers such behaviour. It is, for example, called when receiving capabilities in IPC and not having enough PD quota to create local references [4]. It results in a call of Capability_space::upgrade_slab in core [5]. This function currently allocates as much additional SLAB blocks as possible and, by doing so, always triggers the warning. The reason for this is that it's hard to measure how much additional blocks are needed at this point. Maybe you could give it a try and test if this is responsible for your warning.
If so, the warning is no problem and I wonder whether your scenario runs properly apart from it. It would also be interesting to know whether you've sent the complete log output (what is the meaning of the point and the commas?). Please note that we're already planning to change output behaviour on reaching quota limits as it provides little information and can obviously be misleading.
Cheers, Martin
[1] Commit cc58b11 hw: replace page table allocator with static one [2] Commit e081554 hw: kernel backed capabilities (Fix #1443) [3] repos/base/include/base/allocator_guard.h [4] repos/base-hw/src/base/ipc/ipc.cc [5] repos/base-hw/src/core/platform_pd.cc
Hi Martin, thanks for your detailed and excellent explanation of what has changed with quota accounting. I'll assume the "quota exceeded" message is simply informational for now while I tackle an an apparent IO mapping issue.
The scenario I run includes sdcard, gpio, gp timers, uarts, i2c, and PWM drivers and vfs is also in there. All of this, with my modified base-hw kernel, appears to be running as it does in 15.02 with the exception of the PWM driver. The log from the 15.11 implementation shows nothing exceptional (attached) and is practically identical to what is output on 15.02. Running my PWM driver in verbose mode shows that data received from sensors on the i2c bus and from a manual input controller is being correctly received, processed, and sent to the PWM driver. The PWM does some signal conditioning and writes updated duty cycle values to an IO register from which the SoC's pwm subsystem sends the modified pulse to an IO pin. That pin is attached to a motor ESC which provides the power to drive the motor. The motor never receives the pulse. So, presumably, there is an issue with IO mapping and the signal is not going to the correct register location. I notice in the 5.11 release notes that there have been changes in the area of memory mapped IO, so I'm starting to explore that avenue. I have not touched the PWM driver code in more than a year so I doubt that the problem is there.
Bob
On 12/03/2015 04:27 AM, Martin Stein wrote:
Hello Bob,
Am 02.12.2015 um 15:17 schrieb Bob Stewart:
I just upgraded from 15.02 to 15.11 and ran my base-hw based os andapplications, which have been running for some time on 15.02. The changes made during the update were to the directory structure required by the "platform" changes and gpio driver changes to accomodate the removal of the wait_for_irq method.
It's nice to hear that you already got your hands on the new release :)
immediately after init starts I get a "quota execeeded"mesage:
Starting kernel ...
kernel initialized Genode 15.11 <local changes> int main(): --- create local services --- int main(): --- start init --- int main(): transferred 501 MB to init int main(): --- init created, waiting for exit condition --- Quota exceeded! amount=12288, size=12288, consumed=12288 [init -> uart_drv] int main(int, char**): --- OMAP3 UART driver started --- [init -> ctrl_module] --- Beaglebone Control Module Server --- [init -> platform_drv] --- bbb platform driver running --- [init -> pwm_drv] --- am33xx pwm driver --- . , ,
No changes have been made to available ram constants in board_base so I'm confused as to what caused this message to be generated. Did I miss a change to how quota's are requested and managed?
Since 15.05, the accounting of quota on base-hw got much more comprehensive. Most notably, for the costs of PD related things like the page tables [1] or the local representations of capabilities [2] a component must now pay via quota. I assume that your "Quota exceeded" is printed by the Allocator_guard [3] (Otherwise it could only be a 'loader' server component which is unlikely).
The basic sessions (say those of the Genode environment) are given an initial amount of quota. This amount is a guess on how much is needed to bring the component up. If this quota does not suffice, the session asks the parent to upgrade it by using some of the components slack quota. If its slack quota isn't sufficient for that, the component still may ask its parent to donate some more. So, the quota you assign to a component via the init configuration is the guaranteed minimum the component receives. Init may or may not - depending from what is left after starting all children and saving some quota for itself - hand in more quota to components if they ask for.
During these mechanisms, the Allocator_guard is the one that applies given quota limits to allocations by wrapping the background allocator. That said, the warning indicates that you've reached a limit but it does not necessarily indicate a problem as, in return, your scenario may be able to relax the limit.
And even more, there are places in Genode where reaching the limit is expected. My favourite explanation in your case is the upgrade_pd_session_quota function that triggers such behaviour. It is, for example, called when receiving capabilities in IPC and not having enough PD quota to create local references [4]. It results in a call of Capability_space::upgrade_slab in core [5]. This function currently allocates as much additional SLAB blocks as possible and, by doing so, always triggers the warning. The reason for this is that it's hard to measure how much additional blocks are needed at this point. Maybe you could give it a try and test if this is responsible for your warning.
If so, the warning is no problem and I wonder whether your scenario runs properly apart from it. It would also be interesting to know whether you've sent the complete log output (what is the meaning of the point and the commas?). Please note that we're already planning to change output behaviour on reaching quota limits as it provides little information and can obviously be misleading.
Cheers, Martin
[1] Commit cc58b11 hw: replace page table allocator with static one [2] Commit e081554 hw: kernel backed capabilities (Fix #1443) [3] repos/base/include/base/allocator_guard.h [4] repos/base-hw/src/base/ipc/ipc.cc [5] repos/base-hw/src/core/platform_pd.cc
Go from Idea to Many App Stores Faster with Intel(R) XDK Give your users amazing mobile app experiences with Intel(R) XDK. Use one codebase in this all-in-one HTML5 development environment. Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs. http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140 _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hi Bob,
Am 03.12.2015 um 13:37 schrieb Bob Stewart:
The scenario I run includes sdcard, gpio, gp timers, uarts, i2c, and PWM drivers and vfs is also in there. All of this, with my modified base-hw kernel, appears to be running as it does in 15.02 with the exception of the PWM driver. The log from the 15.11 implementation shows nothing exceptional (attached) and is practically identical to what is output on
While reading this, it came to my mind that somewhere around the beginning of the year, interrupt semantics have changed on base-hw. In the past, an IRQ session, once opened, directly started handling interrupts. Today, the handling, and therefore also the reception, of interrupts doesn't start until an initial 'Irq_session::irq_ack' call. I know, its a shot in the dark. But just to be sure you may check whether your drivers already send this initial ack.
15.02. Running my PWM driver in verbose mode shows that data received from sensors on the i2c bus and from a manual input controller is being correctly received, processed, and sent to the PWM driver. The PWM does some signal conditioning and writes updated duty cycle values to an IO register from which the SoC's pwm subsystem sends the modified pulse to an IO pin. That pin is attached to a motor ESC which provides the power to drive the motor. The motor never receives the pulse. So, presumably,
My first intention is, that this could also be a bad GPIO configuration. However, with the information I have this can only be a vague guess. Can you share your source code including the run script that you're using? Most comfortable would be an on-line git branch :)
there is an issue with IO mapping and the signal is not going to the correct register location. I notice in the 5.11 release notes that there have been changes in the area of memory mapped IO, so I'm starting to
Sorry, I'm afraid that I do not know which changes you mean. Could you please go in more detail?
explore that avenue. I have not touched the PWM driver code in more than a year so I doubt that the problem is there.
Cheers, Martin
Thanks for following up on this Martin.
I did notice the changes to interrupt handling and updated my drivers accordingly, including the initial ack...interrupts are working well in my 15.11 code.
The io mapping changes I was referring to were in Attached_io_mem_dataspace where sub page handling is apparently is now managed at the byte and not page level. After reading the notes I realized that all the device registers in my platform start on a 4K boundary and also end on one. So that idea went nowhere!
I put a 'scope on several of the pins outputting the PWM signal. To my surprise the pulses were present and their width did change correctly as the driver code altered the duty cycle values, identical to the behavior on 15.02. The compiler did change between 15.02 and 15.11 and this leads me to think I may have some poor code design in my pwm device driver causing a race condition during the set up of the pwm subsystem or the pwm channels...a timing change due to the different compiled code could expose such an issue. My current belief is that the ESC is being reset after set up or because of some wrong sequence during set up. The ESC's emit audible tones when they receive initial pulses after power on and there are differences between the tones emitted between the 15.02 version and 15.11.
I'm ok with sharing my code but I think the hardware is needed to really debug this issue. Every other piece of code in this scenario works as it did in 15.02 including gpio output to status leds and pwm inputs on gpio pins.
I'll keep you posted as I progress.
Bob Sent from my android device.
-----Original Message----- From: Martin Stein <martin.stein@...1...> To: Genode OS Framework Mailing List genode-main@lists.sourceforge.net Sent: Sat, 05 Dec 2015 10:10 AM Subject: Re: Upgrade to 15.11 from 15.02 results in quota exceded message
Hi Bob,
Am 03.12.2015 um 13:37 schrieb Bob Stewart:
The scenario I run includes sdcard, gpio, gp timers, uarts, i2c, and PWM drivers and vfs is also in there. All of this, with my modified base-hw kernel, appears to be running as it does in 15.02 with the exception of the PWM driver. The log from the 15.11 implementation shows nothing exceptional (attached) and is practically identical to what is output on
While reading this, it came to my mind that somewhere around the beginning of the year, interrupt semantics have changed on base-hw. In the past, an IRQ session, once opened, directly started handling interrupts. Today, the handling, and therefore also the reception, of interrupts doesn't start until an initial 'Irq_session::irq_ack' call. I know, its a shot in the dark. But just to be sure you may check whether your drivers already send this initial ack.
15.02. Running my PWM driver in verbose mode shows that data received from sensors on the i2c bus and from a manual input controller is being correctly received, processed, and sent to the PWM driver. The PWM does some signal conditioning and writes updated duty cycle values to an IO register from which the SoC's pwm subsystem sends the modified pulse to an IO pin. That pin is attached to a motor ESC which provides the power to drive the motor. The motor never receives the pulse. So, presumably,
My first intention is, that this could also be a bad GPIO configuration. However, with the information I have this can only be a vague guess. Can you share your source code including the run script that you're using? Most comfortable would be an on-line git branch :)
there is an issue with IO mapping and the signal is not going to the correct register location. I notice in the 5.11 release notes that there have been changes in the area of memory mapped IO, so I'm starting to
Sorry, I'm afraid that I do not know which changes you mean. Could you please go in more detail?
explore that avenue. I have not touched the PWM driver code in more than a year so I doubt that the problem is there.
Cheers, Martin
------------------------------------------------------------------------------ Go from Idea to Many App Stores Faster with Intel(R) XDK Give your users amazing mobile app experiences with Intel(R) XDK. Use one codebase in this all-in-one HTML5 development environment. Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs. http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140 _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
The issue with the pwm driver was due to the changes in Attached_io_mem_dataspace introduced in 15.11.
On the AM335x there are three pwm subsystems whose registers do start on page boundaries and are page sized. Additionally, however, there are three modules within each subsystem each taking up 128 bytes for their registers. (I'd forgotten this fact until i re-read the code i wrote over a year ago.) One of these modules is the ePWM which controls the output of PWM pulses on an io pin. My pwm driver accesses both a subsystem and its ePWM module. In 15.02 I mapped the ePWM registers using the modules address (and the subsystem size, incorrectly) and used offsets to the ePWM module register starting at the subsystems start address. This worked because the actual register space made accessible was the full subsystems page. In 15.11 giving Attached_io_mem_dataspace object constructor the address of the module (and the module size) gives access starting at the module registers. Using the module register offsets used in 15.02 will now be wrong as they are based on the subsystem registers starting address. The correction is simply to zero-base the module register offsets and set the correct size, the module size.
Now everything in my scenario works on 15.11.
Thanks for the help, Martin.
Bob
Sent from my android device.
-----Original Message----- From: robjsstewart@...196... To: Genode OS Framework Mailing List genode-main@lists.sourceforge.net Sent: Sat, 05 Dec 2015 11:50 AM Subject: Re: Upgrade to 15.11 from 15.02 results in quota exceded message
Thanks for following up on this Martin.
I did notice the changes to interrupt handling and updated my drivers accordingly, including the initial ack...interrupts are working well in my 15.11 code.
The io mapping changes I was referring to were in Attached_io_mem_dataspace where sub page handling is apparently is now managed at the byte and not page level. After reading the notes I realized that all the device registers in my platform start on a 4K boundary and also end on one. So that idea went nowhere!
I put a 'scope on several of the pins outputting the PWM signal. To my surprise the pulses were present and their width did change correctly as the driver code altered the duty cycle values, identical to the behavior on 15.02. The compiler did change between 15.02 and 15.11 and this leads me to think I may have some poor code design in my pwm device driver causing a race condition during the set up of the pwm subsystem or the pwm channels...a timing change due to the different compiled code could expose such an issue. My current belief is that the ESC is being reset after set up or because of some wrong sequence during set up. The ESC's emit audible tones when they receive initial pulses after power on and there are differences between the tones emitted between the 15.02 version and 15.11.
I'm ok with sharing my code but I think the hardware is needed to really debug this issue. Every other piece of code in this scenario works as it did in 15.02 including gpio output to status leds and pwm inputs on gpio pins.
I'll keep you posted as I progress.
Bob Sent from my android device.
-----Original Message----- From: Martin Stein <martin.stein@...1...> To: Genode OS Framework Mailing List genode-main@lists.sourceforge.net Sent: Sat, 05 Dec 2015 10:10 AM Subject: Re: Upgrade to 15.11 from 15.02 results in quota exceded message
Hi Bob,
Am 03.12.2015 um 13:37 schrieb Bob Stewart:
The scenario I run includes sdcard, gpio, gp timers, uarts, i2c, and PWM drivers and vfs is also in there. All of this, with my modified base-hw kernel, appears to be running as it does in 15.02 with the exception of the PWM driver. The log from the 15.11 implementation shows nothing exceptional (attached) and is practically identical to what is output on
While reading this, it came to my mind that somewhere around the beginning of the year, interrupt semantics have changed on base-hw. In the past, an IRQ session, once opened, directly started handling interrupts. Today, the handling, and therefore also the reception, of interrupts doesn't start until an initial 'Irq_session::irq_ack' call. I know, its a shot in the dark. But just to be sure you may check whether your drivers already send this initial ack.
15.02. Running my PWM driver in verbose mode shows that data received from sensors on the i2c bus and from a manual input controller is being correctly received, processed, and sent to the PWM driver. The PWM does some signal conditioning and writes updated duty cycle values to an IO register from which the SoC's pwm subsystem sends the modified pulse to an IO pin. That pin is attached to a motor ESC which provides the power to drive the motor. The motor never receives the pulse. So, presumably,
My first intention is, that this could also be a bad GPIO configuration. However, with the information I have this can only be a vague guess. Can you share your source code including the run script that you're using? Most comfortable would be an on-line git branch :)
there is an issue with IO mapping and the signal is not going to the correct register location. I notice in the 5.11 release notes that there have been changes in the area of memory mapped IO, so I'm starting to
Sorry, I'm afraid that I do not know which changes you mean. Could you please go in more detail?
explore that avenue. I have not touched the PWM driver code in more than a year so I doubt that the problem is there.
Cheers, Martin
------------------------------------------------------------------------------ Go from Idea to Many App Stores Faster with Intel(R) XDK Give your users amazing mobile app experiences with Intel(R) XDK. Use one codebase in this all-in-one HTML5 development environment. Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs. http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140 _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
-
unknown＠example.com -
Bob Stewart -
Martin Stein