paging problem with ide-cs driver

paging problem with ide-cs driver

[Andrew Sharp]

I'm having a problem with paging through the ide-cs driver.  As best
I can tell right now, the kernel thinks the data is present and valid
when it actually isn't.  This is lmo 2.6.22.3, on a sibyte 1125H, but
I had the same problem with 2.6.20.something on an R9k based machine.

I can make a filesystem (ext3) on the CF card, mount it, read and write
to it.  But I can't chroot to it, can't set LD_LIBRARY_PATH to it,
can't use it as the root filesystem.

The chroot failure is the most telling.  When I try to chroot to it, I
get various segfault, bus error, illegal instruction, etc.  But if I
continue to try it, after 10-12 tries, it succeeds.  This tells me
that the data eventually arrives, it's just that the kernel tries to
use a page before the data is valid.

Before I dive into this, does any of this ring a bell for anyone?
I'm using the ide-cs driver, TI yenta cardbus adapter driver, and sibyte
everything else.

I can provide kernel output if anyone is interested in that.  But there
isn't any kernel output when the failure occurs, the thread just dies
with one of the various mentioned errors.

coolcat:~# cat /etc/fstab
proc /proc proc defaults 0 0
10.0.0.42:/var/nfsroot/cougar / nfs defaults 0 0
tmpfs /tmp tmpfs defaults,size=12m 0 0
coolcat:~# chroot /mnt
Illegal instruction
coolcat:~# chroot /mnt
Illegal instruction
coolcat:~# chroot /mnt
Segmentation fault
coolcat:~# chroot /mnt
Segmentation fault
coolcat:~# chroot /mnt
Illegal instruction
coolcat:~# chroot /mnt
Illegal instruction
coolcat:~# chroot /mnt
Illegal instruction
coolcat:~# chroot /mnt
Segmentation fault
coolcat:~# chroot /mnt
Segmentation fault
coolcat:~# chroot /mnt
coolcat:/# 
coolcat:/# cat /etc/fstab
Segmentation fault
coolcat:/# cat /etc/fstab
proc /proc proc defaults 0 0
/dev/hda2 / ext3 defaults 0 0
tmpfs /tmp tmpfs defaults,size=12m 0 0
coolcat:/# exit

Re: paging problem with ide-cs driver

[Alan Cox]

> Before I dive into this, does any of this ring a bell for anyone?
> I'm using the ide-cs driver, TI yenta cardbus adapter driver, and sibyte
> everything else.

That has cache coherency painted all over it in bright flashing letters.

Can you build and try the libata drivers and the libata pata_pcmcia
driver. The two are essentially the same at the hardware management level
but go up via different stacks which should give clues depending on
how/if the libata one fails in comparison.

Re: paging problem with ide-cs driver

[Andrew Sharp]

On Tue, 9 Oct 2007 22:05:30 +0100 Alan Cox <alan@lxorguk.ukuu.org.uk>
wrote:

> > Before I dive into this, does any of this ring a bell for anyone?
> > I'm using the ide-cs driver, TI yenta cardbus adapter driver, and
> > sibyte everything else.
> 
> That has cache coherency painted all over it in bright flashing
> letters.
> 
> Can you build and try the libata drivers and the libata pata_pcmcia
> driver. The two are essentially the same at the hardware management
> level but go up via different stacks which should give clues
> depending on how/if the libata one fails in comparison.
> 

OK, went and tried that, same results.

a

Re: paging problem with ide-cs driver

[Ralf Baechle]

On Tue, Oct 09, 2007 at 10:05:30PM +0100, Alan Cox wrote:

> > Before I dive into this, does any of this ring a bell for anyone?
> > I'm using the ide-cs driver, TI yenta cardbus adapter driver, and sibyte
> > everything else.
> 
> That has cache coherency painted all over it in bright flashing letters.

The Sibyte SOCs have hardware cache coherency and physically indeded
D-caches which makes I/O pretty much a nobrainer.

I-cache coherency is the thing that really needs babysitting on Sibyte
and the Sibyte I-caches are of a somewhat rare kind by being VIVT plus
an additional address space tag.  Mostly because of code duplication
the Sibyte cachecode has its nice damp and dark corner where it did
bitrot away for a while.  Thiemo and I recently found the standard
R4000 cache code to work more reliable for Sibyte so we're getting rid
of it for 2.6.24.  The patch is in 06e523e89ec0322c4abcf41533d5380dfcd81f73.
It can easily be backported to older kernels so I suggest trying this
one.

(As collateral damage 06e523e89ec0322c4abcf41533d5380dfcd81f73 breaks
support for pass 1 BCM1250 parts.  But it seems I'm the last one with one
of those ...)

  Ralf