AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:<20071114113120.70229dff@ripper.onstor.net>
CFG:
PT:0
S:andy.sharp@onstor.com
RQ:
SSV:onstor-exch02.onstor.net
NSV:
SSH:
R:<brian.stark@onstor.com>,<rick.lund@onstor.com>,<maxim.kozlovsky@onstor.com>
MAID:1
X-Sylpheed-Privacy-System:
X-Sylpheed-Sign:0
SCF:#mh/Mailbox/sent
RMID:#imap/andys@onstor.net@onstor-exch02.onstor.net/INBOX	0	BB375AF679D4A34E9CA8DFA650E2B04E068837F3@onstor-exch02.onstor.net
X-Sylpheed-End-Special-Headers: 1
Date: Wed, 14 Nov 2007 11:31:27 -0800
From: Andrew Sharp <andy.sharp@onstor.com>
To: "Brian Stark" <brian.stark@onstor.com>
Cc: "Rick Lund" <rick.lund@onstor.com>, "Maxim Kozlovsky"
 <maxim.kozlovsky@onstor.com>
Subject: Re: idea on cksseg problem
Message-ID: <20071114113127.4d61ef7d@ripper.onstor.net>
In-Reply-To: <BB375AF679D4A34E9CA8DFA650E2B04E068837F3@onstor-exch02.onstor.net>
References: <20071105111450.1389cc29@ripper.onstor.net>
	<BB375AF679D4A34E9CA8DFA650E2B04E0A4470@onstor-exch02.onstor.net>
	<20071112171348.7482b1b5@ripper.onstor.net>
	<BB375AF679D4A34E9CA8DFA650E2B04E068837F3@onstor-exch02.onstor.net>
Organization: Onstor
X-Mailer: Sylpheed-Claws 2.6.0 (GTK+ 2.8.20; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Problem solved.  It was a kernel bug. </duck>  Turns out it was a
problem with the EKPI instruction.

On Tue, 13 Nov 2007 11:02:45 -0800 "Brian Stark"
<brian.stark@onstor.com> wrote:

> SSC-PROM> cp0 sr
> C0_SR = 0x204000e0
> SSC-PROM>
> SSC-PROM> m c0000000
> XTLB Miss Exception:
>    EPC = 0x80800580
>    BADVADDR = 0xC0000000
> 
> PMON TLBL exception
> EPC:      0xffffffff80800580
> RA:       0xffffffffbfc002e0
> Cause:    a0008008
> BadVaddr: 0xffffffffc0000000
> Autoreboot set "off", stopping in debug mode
> 
> 
> From the cp0 sr command, we are running 64-bit kernel, supervisor, and
> user.  And then the access to 0xc0000000 bombs with a TLB exception.
> 
> So here's what we did next -- setup a TLB entry pointing to physical 0
> and then access it:
> 
> SSC-PROM> tlb 11 ffffffffc0000000 0 1000000 uncached
> setting tlb 11, virt = 0xc0000000, phys = 0x0, size = 0x1000000,
> uncached
> SSC-PROM>
> SSC-PROM> m ffffffffc0000000
> c0000000 00000000 .
> 
> 
> Works like a champ...
> 
> 
>  
> 
> > -----Original Message-----
> > From: Andy Sharp 
> > Sent: Monday, November 12, 2007 5:14 PM
> > To: Rick Lund
> > Cc: Brian Stark; Maxim Kozlovsky
> > Subject: Re: idea on cksseg problem
> > 
> > I'm hard pressed right at the moment to think of what else it 
> > might be, however, Brian told me today that you guys are 
> > getting a TLB exception these days when you try to access 
> > 0xffffffffc0000000.  That would suggest to me that it should 
> > be working now and all I have to do is try it on a new-ish 
> > prom.  The CFE is, however, 32 bits, correct?  And this 
> > address being defacto mapped to the memory controller doesn't 
> > happen in 32 bit mode.  Then again maybe you have a 64-bit CFE.
> > 
> > Cheers,
> > 
> > a
> > 
> > On Mon, 5 Nov 2007 11:37:19 -0800 "Rick Lund" <rick.lund@onstor.com>
> > wrote:
> > 
> > > We are using the CFE draminit code, which as I remember, only 
> > > initializes the memory ranges for the amount of memory which 
> > > physically exists.  I will check the CS settings, but I don't
> > > think this is the problem. -Rick
> > > 
> > > ________________________________
> > > 
> > > From: Andy Sharp
> > > Sent: Mon 11/5/2007 11:14 AM
> > > To: Brian Stark
> > > Cc: Rick Lund; Maxim Kozlovsky
> > > Subject: idea on cksseg problem
> > > 
> > > 
> > > 
> > > I am forming a theory on why we vapor lock when accessing cksseg0 
> > > address -- we aren't being selective enough on what addresses are 
> > > mapped/configured to memory banks.  We need to make sure that we 
> > > map/configure only those addresses that have actual physical
> > > memory. I suspect we are letting the default configuration take
> > > place, which is specified in the 1250 manual.   We don't have any
> > > memory at 0xc000.0000 but perhaps we have that address range 
> > configured to go to 
> > > the memory controller when we shouldn't, causing vapor lock 
> > whenever 
> > > we access it.
> > > 
> > > Does this make any sense to anyone?  Causing any bells to ring?
> > > 
> > > Cheers,
> > > 
> > > a
> > > 
> > > PS There is a good reference to this on page 137 of the 1250 User 
> > > Manual (that's the PDF page number, page 109 of the 
> > internal document 
> > > numbering).
> > > 
> > > 
> > 
