Hello,
according to your log the acpi driver is dying (look for red messages):
[init - acpi - pci_drv] BDF start 0, functions: 0x1, physical base
0xe000
[init - vesa_drv] Could not open file config
[init - vesa_drv] Could not obtain config file
[init - acpi] ACPI table format is
Hi,
On 04/27/2013 10:51 AM, yuqing wang wrote:
Hi,
I used the foc_x86_32 platform to try part_blk run script ,there was a
error.
[init - atapi_drv] 5 and below: yes enabled: yes
[init - atapi_drv] PRD base at 002f9000 (physical) at 2000 (virtual)
[init - atapi_drv] Device initialized!
Sorry, this should be give some part to process P2. Anyhow, is the
answer to use Rm_session and its dataspace method?
Daniel
On Mon, 2013-04-29 at 18:59 -0700, Daniel Waddington wrote:
Hi,
If a process P has a dataspace (RAM) which it acquired from 'core', is
there a way for it to split the
Hi Daniel,
Sorry, this should be give some part to process P2. Anyhow, is the
answer to use Rm_session and its dataspace method?
this would indeed work. But this solution comes at the cost of
maintaining one RM session per dataspace. Depending on your use case,
this might be quite expensive.
Hi Norman,
As always, thanks for your guidance and quick feedback. For our current
purpose the overhead of using RM session is OK since the application
itself manages large chunks of memory. The alias API would be really
nice though.
Best,
Daniel
On Tue, 2013-04-30 at 18:18 +0200, Norman
One last issue in doing this... I create the sub_rm and test it in the
creating process, this works fine. When I try to send out the
Dataspace_capability (as either ref or ptr) for the sub_rm through RPC
to another process, then I get an invalid capability on the recv side
(as determined by
OK, fixed it. The Rm_connection object was being destroyed and as a
result invalidating the cap before it got marshaled.
Daniel
On Tue, 2013-04-30 at 12:34 -0700, Daniel Waddington wrote:
One last issue in doing this... I create the sub_rm and test it in the
creating process, this works
