On Sat, Aug 04, 2007 at 12:31:28PM +1000, Benjamin Herrenschmidt wrote:
>
> Paulus stuff is likely to be unrelated to your bug. Also, whatever blurb
> you pasted in this email is totally incomprehensible due to total lack
> of context.
Sorry. Mike Strosaker nailed it; its a nutty hypervisor bug.
On Fri, 2007-08-03 at 14:32 -0500, Linas Vepstas wrote:
> On Fri, Aug 03, 2007 at 06:58:51PM +1000, Paul Mackerras wrote:
> > The code for mapping special 4k pages on kernels using a 64kB base
> > page size was missing the code for doing the RPN (real page number)
> > manipulation when inserting th
Linas Vepstas wrote:
> 3:mon> d c77b21e0
> c77b21e0 e0008004b224 067410090080 |...$.t..|
>
> Well, howdy doody, there's the value that should have been in r3
>
> c77b21f0 c4008e00 49424d00 |IBM.|
>
> IBM ???
>
> c000
On Fri, Aug 03, 2007 at 06:58:51PM +1000, Paul Mackerras wrote:
> The code for mapping special 4k pages on kernels using a 64kB base
> page size was missing the code for doing the RPN (real page number)
> manipulation when inserting the hardware PTE in the secondary hash
> bucket. It needs the sam
On Fri, 2007-08-03 at 18:58 +1000, Paul Mackerras wrote:
> The code for mapping special 4k pages on kernels using a 64kB base
> page size was missing the code for doing the RPN (real page number)
> manipulation when inserting the hardware PTE in the secondary hash
> bucket. It needs the same code
The code for mapping special 4k pages on kernels using a 64kB base
page size was missing the code for doing the RPN (real page number)
manipulation when inserting the hardware PTE in the secondary hash
bucket. It needs the same code as has already been added to the
code that inserts the HPTE in th
