Re: Trouble with new marvell_nand driver on PXA3xx

[Miquel Raynal <miquel.raynal@bootlin.com>]

Hi Daniel,

Daniel Mack <daniel@zonque.org> wrote on Mon, 24 Sep 2018 08:45:44
+0200:

> Hi Miquel,
> 
> I'm having issues using the new marvell_nand driver on a PXA3xx based platform. My test does a ubiformat on the chip, then creates a volume, mounts it and runs bonnie++ on the file system. After some time (usually less than half a minute), the driver spits out a warning like the one below, and eventually the UBI layer bails out, which leads to a r/o remount and (possibly) file system corruptions.
> 
> FWIW, this is the test script I'm using:
> 
>  > #!/bin/sh
>  >
>  > UBIDEV=0
>  > UBIMTD=3
>  >
>  > umount /mnt
>  > ubidetach /dev/ubi_ctrl -d $UBIDEV
>  > ubiformat -y /dev/mtd$UBIMTD
>  > ubiattach /dev/ubi_ctrl -d $UBIDEV -m $UBIMTD
>  > ubimkvol /dev/ubi$UBIDEV -N test -m
>  > mount -t ubifs ubi0:test /mnt
>  > bonnie\+\+ -d /mnt -u 0:0  
> 
> 
> The legacy pxa3xx_nand driver didn't have this issue, but my system was also running a much older kernel with that. I'm currently still struggling to resurrect the old code, but I'm running into "Wait time out!!!" conditions immediately right now. Not sure what's going on.
> 
> Interestingly, I can't seem to reproduce the bug with any of the mtd kernel tests, I've tried all of them, several times, and all succeed. So a file system test that includes the UBI/UBIFS layers seems to trigger different things in the driver than the the tests that operate on the mtd device directly.
> 
> I'v also tried this with and without the keep-config DT property, but that didn't change anything.
> 
> Could you try my script on some other device that runs the new driver and see if you can reproduce? If bonnie++ is unavailable, extracting a bigger tarball a couple of times will also trigger the bug at some point.
> 
> Meanwhile, I can start poking around in the driver. I'd be grateful for a hint on where to start.
> 

Interesting, thanks for the feedback.

Right now I have no idea of what happens, but you might want to add a
dump_stack() at the "Timeout waiting for RB signal" error to see what
path in the driver failed.

You might also try with and without DMA?

I'll try to take the time this week to check if it is pxa-related by
testing this on an armada board.

Thanks,
Miquèl