On 4/8/06, Matt Thomas <matt@3am-software.com> wrote:
> Rahul Kulkarni wrote:
> > Thanks much in advance for all you replies. appreciate it.
> >
> > Hmm..If I understand this right..since the USERSR is valid during a
> > copy{in,out} a buggy sysem call / ioctl can potentially corrupt user
> > space though highly improbable.
> >
> > I'm debugging a condition where a byte gets corrupted in the user
> > space, (extremely hard to reproduce) and after pouring over user space
> > code now trying to rule out home grown system calls/ioctls since the
> > user process does make a bunch of system calls/ioctls.
>
> in random processes, or in one particular process?
>
> > I'm thinking ways of to generate a DSI/exception to catch/rule out
> > bugs of the above type ..can you think of  any?
>
> Yep.  But it depends on how the bug is manifesting itself.

RK>>>Its in random processes, code asserts (post mortem) since it sees
a bad byte after 2-3 days of tests. Its the libraries or the kernel.
But I want to rule out the kernel (homegrown syscall/ioctls).
painfully isolating the libs one by one, mprotect slows down the whole
thing and reproducibility is an issue so using mprotect (4k) is ruled
out. How do you catch a bad byte?


>
> > Is there a way to BAT map only the first 256 MB of the physical memory
> > and move the copy{in,out} operations to that area?  If yes, what are
> > the other implications?
>
> No.

>
> > Is it mandatory to BAT map the complete physical memory for certain PPC=
  MMU's?
>
> Basically, yes.
>
> --
> Matt Thomas                     email: matt@3am-software.com
> 3am Software Foundry              www: http://3am-software.com/bio/matt/
> Cupertino, CA              disclaimer: I avow all knowledge of this messa=
ge.
>