X-MimeOLE: Produced By Microsoft Exchange V6.5
Received: by onstor-exch02.onstor.net 
	id <01C82627.C66ED37D@onstor-exch02.onstor.net>; Tue, 13 Nov 2007 11:02:45 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-class: urn:content-classes:message
Subject: RE: idea on cksseg problem
Date: Tue, 13 Nov 2007 11:02:45 -0800
Message-ID: <BB375AF679D4A34E9CA8DFA650E2B04E068837F3@onstor-exch02.onstor.net>
In-Reply-To: <20071112171348.7482b1b5@ripper.onstor.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: idea on cksseg problem
Thread-Index: AcglknKmQykoYlX9QiixKLM7hCPUhAAjkJOg
References: <20071105111450.1389cc29@ripper.onstor.net><BB375AF679D4A34E9CA8DFA650E2B04E0A4470@onstor-exch02.onstor.net> <20071112171348.7482b1b5@ripper.onstor.net>
From: "Brian Stark" <brian.stark@onstor.com>
To: "Andy Sharp" <andy.sharp@onstor.com>,
	"Rick Lund" <rick.lund@onstor.com>
Cc: "Maxim Kozlovsky" <maxim.kozlovsky@onstor.com>

SSC-PROM> cp0 sr
C0_SR =3D 0x204000e0
SSC-PROM>
SSC-PROM> m c0000000
XTLB Miss Exception:
   EPC =3D 0x80800580
   BADVADDR =3D 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 =3D 0xc0000000, phys =3D 0x0, size =3D 0x1000000,
uncached
SSC-PROM>
SSC-PROM> m ffffffffc0000000
c0000000 00000000 .


Works like a champ...


=20

> -----Original Message-----
> From: Andy Sharp=20
> Sent: Monday, November 12, 2007 5:14 PM
> To: Rick Lund
> Cc: Brian Stark; Maxim Kozlovsky
> Subject: Re: idea on cksseg problem
>=20
> I'm hard pressed right at the moment to think of what else it=20
> might be, however, Brian told me today that you guys are=20
> getting a TLB exception these days when you try to access=20
> 0xffffffffc0000000.  That would suggest to me that it should=20
> be working now and all I have to do is try it on a new-ish=20
> prom.  The CFE is, however, 32 bits, correct?  And this=20
> address being defacto mapped to the memory controller doesn't=20
> happen in 32 bit mode.  Then again maybe you have a 64-bit CFE.
>=20
> Cheers,
>=20
> a
>=20
> On Mon, 5 Nov 2007 11:37:19 -0800 "Rick Lund" <rick.lund@onstor.com>
> wrote:
>=20
> > We are using the CFE draminit code, which as I remember, only=20
> > initializes the memory ranges for the amount of memory which=20
> > physically exists.  I will check the CS settings, but I don't think=20
> > this is the problem. -Rick
> >=20
> > ________________________________
> >=20
> > From: Andy Sharp
> > Sent: Mon 11/5/2007 11:14 AM
> > To: Brian Stark
> > Cc: Rick Lund; Maxim Kozlovsky
> > Subject: idea on cksseg problem
> >=20
> >=20
> >=20
> > I am forming a theory on why we vapor lock when accessing cksseg0=20
> > address -- we aren't being selective enough on what addresses are=20
> > mapped/configured to memory banks.  We need to make sure that we=20
> > 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=20
> configured to go to=20
> > the memory controller when we shouldn't, causing vapor lock=20
> whenever=20
> > we access it.
> >=20
> > Does this make any sense to anyone?  Causing any bells to ring?
> >=20
> > Cheers,
> >=20
> > a
> >=20
> > PS There is a good reference to this on page 137 of the 1250 User=20
> > Manual (that's the PDF page number, page 109 of the=20
> internal document=20
> > numbering).
> >=20
> >=20
>=20
