On Sat, Apr 13, 2013 at 4:59 AM, Terry Hsu wrote:
>
> On Fri, Apr 12, 2013 at 1:14 AM, Terry Hsu wrote:
>>
>> okay so I looked into the faultinfo structure and was able to obtain the
>> faulting address, error code, and trap number(?). From my understanding the
>> error code is the bottom 3 bits
On Fri, Apr 12, 2013 at 1:14 AM, Terry Hsu wrote:
> okay so I looked into the faultinfo structure and was able to obtain the
> faulting address, error code, and trap number(?). From my understanding the
> error code is the bottom 3 bits of the exception code. But I see error code
> "20" sometimes
Do you know which functions are used by UML to write the to be fixed
address into SKAS stub? In the handle_page_fault(), the stub mapping is
never referenced. I print out vm area (in find_vma()) if the address cover
by the stub mapping is referenced, and it prints nothing there.
I want to know whe
okay so I looked into the faultinfo structure and was able to obtain the
faulting address, error code, and trap number(?). From my understanding the
error code is the bottom 3 bits of the exception code. But I see error code
"20" sometimes and do not what it means.
I am now looking at how the speci
In the unmodified kernel, I did not see the kernel call mmap (which in turn
calls mmap_region) to install the mapping for the faulting page in child
task. The child task does not have the UML invoked mmap to install
mapping. So I could not examine the parameters passed to mmap neither the
return va
On Thu, Apr 11, 2013 at 10:14 PM, Terry Hsu wrote:
> The page fault loop for the same address happens in my UML. But for both my
> UML and the mainline (I am using 3.7.1) kernel, the addresses that trigger
> the page fault (in the child thread) are covered by certain vm areas. I use
> gdb to trace
The page fault loop for the same address happens in my UML. But for both my
UML and the mainline (I am using 3.7.1) kernel, the addresses that trigger
the page fault (in the child thread) are covered by certain vm areas. I use
gdb to trace the function call and notice that mmap_region() is never
ca
On Thu, Apr 11, 2013 at 6:15 AM, Terry Hsu wrote:
> Hi Richard, thanks for replying. I did go back to see the code and try to
> understand what exactly is going on in UML, but still no luck.
>
> The faulted address is covered by one of the vm areas of the task, so it
> passed the vma sanity check
Hi Richard, thanks for replying. I did go back to see the code and try to
understand what exactly is going on in UML, but still no luck.
The faulted address is covered by one of the vm areas of the task, so it
passed the vma sanity check at the beginning of handle_page_fault(). I
print out the PTE
On Sun, Apr 7, 2013 at 8:30 PM, Peter Butler wrote:
> Here's one more example, still the same setup, but this time crashing at
> the same place as the original bug report. (BUG: failure at
> block/blk-core.c:2978/blk_flush_plug_list()!) See below for output.
>
> BTW my host setup is Linux Mint 14:
Here's one more example, still the same setup, but this time crashing at
the same place as the original bug report. (BUG: failure at
block/blk-core.c:2978/blk_flush_plug_list()!) See below for output.
BTW my host setup is Linux Mint 14:
Linux ufo 3.5.0-17-generic #28-Ubuntu SMP Tue Oct 9 19:31:23
On Sat, Apr 6, 2013 at 9:23 PM, Terry Hsu wrote:
> Is there any available resource that explains how user-mode-linux maps the
> pages of a task in UML to the host kernel?
The code...? ;)
UML receives a SIGEGV on the host side if a page is not mapped.
The SIGEGV handler then installs the mapping u
12 matches
Mail list logo
