AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:<20070322122046.73eb86a9@ripper.onstor.net>
CFG:
PT:0
S:andy.sharp@onstor.com
RQ:
SSV:onstor-exch02.onstor.net
NSV:
SSH:
R:<brian.stark@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	BB375AF679D4A34E9CA8DFA650E2B04E02F12A2E@onstor-exch02.onstor.net
X-Sylpheed-End-Special-Headers: 1
Date: Thu, 22 Mar 2007 12:21:43 -0700
From: Andrew Sharp <andy.sharp@onstor.com>
To: "Brian Stark" <brian.stark@onstor.com>
Subject: Re: what is PCI error 0x200000?
Message-ID: <20070322122143.3d8118a0@ripper.onstor.net>
In-Reply-To: <BB375AF679D4A34E9CA8DFA650E2B04E02F12A2E@onstor-exch02.onstor.net>
References: <20070321185116.7b53b5f8@ripper.onstor.net>
	<BB375AF679D4A34E9CA8DFA650E2B04E02F12A2E@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

On Thu, 22 Mar 2007 12:10:57 -0700 "Brian Stark"
<brian.stark@onstor.com> wrote:

> Andy,
> 
> Where is the PCI error being read from?  If this is a register in the
> Marvell or the Intel bridge for PCI status, it may have something to
> do with the National Semi base addresses being off.  It could be a
> master abort, signaling that nothing is responding to accesses to
> 0x19020000 or 0x19021000.  I confirmed at the PROM prompt that
> accesses to these bases returns 0xffffffff, which is commonly seen
> when master aborts occur.
> 
> If it's from the National, I'll have to look at the datasheet.  As you
> said, it could have something to do with Marvell memory if the
> descriptor ring hasn't been located there.
> 
> The reads from the Marvell registers for the PCI1 mapping look good.
> It also looks like the vendor id and device id is being read properly
> from the Nat Semi MACs.
> 
> I'd say let's get the base addresses for the National MAC fixed up and
> see if the PCI error goes away.

It doesn't.  It comes from the interrupt status register of the natsemi.

I think it was actually "working" with the "wrong" addresses, because
the PCI subsystem in the kernel was reprogramming the addresses.  It
takes a different code path when you just let the scanning do
everything.  But I got things working according to the memory map
document, and the result is the same.

I also got the cirrus part working (the driver needed some porting).
I'm troubled, however, that no PCMCIA IDE driver is claiming the CF
cards.  This is the relevant output:

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

And the kernel is then nailed by the watchdog.  It's waiting for a response
on the network which isn't ever going to come.

Give me a call when you have some time to chat, I need to talk more about
the memory and stuff.

Cheers,

a

