X-MimeOLE: Produced By Microsoft Exchange V6.5
Received: by onstor-exch02.onstor.net 
	id <01C76CC4.BA00584D@onstor-exch02.onstor.net>; Thu, 22 Mar 2007 13:57:39 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-class: urn:content-classes:message
Subject: RE: what is PCI error 0x200000?
Date: Thu, 22 Mar 2007 13:57:39 -0700
Message-ID: <BB375AF679D4A34E9CA8DFA650E2B04E02F12B51@onstor-exch02.onstor.net>
In-Reply-To: <20070322122143.3d8118a0@ripper.onstor.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: what is PCI error 0x200000?
Thread-Index: Acdst1M9IFCX1dMjSgawx4TzbFoM8QADU8mw
References: <20070321185116.7b53b5f8@ripper.onstor.net><BB375AF679D4A34E9CA8DFA650E2B04E02F12A2E@onstor-exch02.onstor.net> <20070322122143.3d8118a0@ripper.onstor.net>
From: "Brian Stark" <brian.stark@onstor.com>
To: "Andy Sharp" <andy.sharp@onstor.com>

Andy,

Left you a message on your extension.  Give me a call at 408-963-2426.


Brian
=20

> -----Original Message-----
> From: Andy Sharp=20
> Sent: Thursday, March 22, 2007 12:22 PM
> To: Brian Stark
> Subject: Re: what is PCI error 0x200000?
>=20
> On Thu, 22 Mar 2007 12:10:57 -0700 "Brian Stark"
> <brian.stark@onstor.com> wrote:
>=20
> > Andy,
> >=20
> > Where is the PCI error being read from?  If this is a=20
> register in the=20
> > Marvell or the Intel bridge for PCI status, it may have=20
> something to=20
> > do with the National Semi base addresses being off.  It could be a=20
> > master abort, signaling that nothing is responding to accesses to=20
> > 0x19020000 or 0x19021000.  I confirmed at the PROM prompt that=20
> > accesses to these bases returns 0xffffffff, which is commonly seen=20
> > when master aborts occur.
> >=20
> > If it's from the National, I'll have to look at the=20
> datasheet.  As you=20
> > said, it could have something to do with Marvell memory if the=20
> > descriptor ring hasn't been located there.
> >=20
> > The reads from the Marvell registers for the PCI1 mapping look good.
> > It also looks like the vendor id and device id is being=20
> read properly=20
> > from the Nat Semi MACs.
> >=20
> > I'd say let's get the base addresses for the National MAC=20
> fixed up and=20
> > see if the PCI error goes away.
>=20
> It doesn't.  It comes from the interrupt status register of=20
> the natsemi.
>=20
> I think it was actually "working" with the "wrong" addresses,=20
> because the PCI subsystem in the kernel was reprogramming the=20
> addresses.  It takes a different code path when you just let=20
> the scanning do everything.  But I got things working=20
> according to the memory map document, and the result is the same.
>=20
> I also got the cirrus part working (the driver needed some porting).
> I'm troubled, however, that no PCMCIA IDE driver is claiming=20
> the CF cards.  This is the relevant output:
>=20
> pd6729: Cirrus PD6729 PCI to PCMCIA Bridge at 0x18000000 on irq 10
> pd6729: PCI card interrupts, PCI status changes
> pccard: PCMCIA card inserted into slot 0
> pccard: PCMCIA card inserted into slot 1
>=20
> And the kernel is then nailed by the watchdog.  It's waiting=20
> for a response on the network which isn't ever going to come.
>=20
> Give me a call when you have some time to chat, I need to=20
> talk more about the memory and stuff.
>=20
> Cheers,
>=20
> a
>=20
>=20
