X-MimeOLE: Produced By Microsoft Exchange V6.5
Received: by onstor-exch02.onstor.net 
	id <01C87A63.84D2B3DA@onstor-exch02.onstor.net>; Thu, 28 Feb 2008 16:42:02 -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: concrete info on CF status problem
Date: Thu, 28 Feb 2008 16:42:02 -0700
Message-ID: <BB375AF679D4A34E9CA8DFA650E2B04E089F185F@onstor-exch02.onstor.net>
In-Reply-To: <20080225140859.55145d81@ripper.onstor.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: concrete info on CF status problem
Thread-Index: Ach3+wV95fFrXxdzRGKA3dXkPOwNlQCZVKoQ
References: <20080225140859.55145d81@ripper.onstor.net>
From: "Brian Stark" <brian.stark@onstor.com>
To: "Andy Sharp" <andy.sharp@onstor.com>
Cc: "Warren Gale" <warren.gale@onstor.com>

OK, I've verified the following:

- Stop in PROM, eject a card, see both the PCI hardware interrupt with
the scope and the ExCA status-change interrupt reg (reg 4, bit 3),
status-change interrupt reg is clear on the next read
- Boot Linux, eject a card, see the PCI hardware interrupt with the
scope, do *not* see the ExCA status-change interrupt reg (reg 4, bit 3)
after doing a read with the 'cat /sys/devices' command.

This is the case on both the old board and new board. =20

After seeing this, my theory was that the 1125 is reading the ExCA
registers after a card is ejected, which would then clear the
status-change interrupt at reg 4, bit 3.  Sure enough, when I hook up an
analyzer, I see a PCI cycle from the 1125 that is doing just that -- a
read to reg 4 -- after the card is ejected.  This read clears the
interrupt, which is why I don't see the interrupt when I then do the
'cat /sys/devices' command.

So, the interrupts are happening and the 1125 is polling the interrupt
status after a card is ejected or inserted, but then it appears the
interrupt status is somehow lost by the kernel.  Don't hate me for
saying this, but me thinks there's a bug in the kernel.

Call me if you have any questions on this. =20

=20

> -----Original Message-----
> From: Andy Sharp=20
> Sent: Monday, February 25, 2008 2:09 PM
> To: Brian Stark
> Cc: Warren Gale
> Subject: concrete info on CF status problem
>=20
> Hi Brian,
>=20
> I've finished researching the CF problem on recent build=20
> runs.  It seems that neither the EXCA CSC register (offset 4)=20
> nor the CSC interrupt are getting through.  One may be=20
> causing the other, but I have no way of determining that. =20
> The CSC register simply stays zero all the time, which is why=20
> polling doesn't work either.
>=20
> Is it possible some change to the PCI setup code in the PROM=20
> could be causing this? I'm not even close to an expert on=20
> this part so I'm just throwing out ideas....
>=20
> FYI, you can look at the device registers from a running=20
> cougar.  At the bash prompt, the command
>=20
> # cat /sys/devices/pci0000\:00/0000\:00\:07.0/yenta_registers
>=20
> will dump the registers for slot 0.  Change the 7.0 to 7.1=20
> for the second slot.
>=20
> Cheers,
>=20
> a
>=20
