Bug#714959: linux-image-3.2.0-4-kirkwood mdraid array fails to assemble b/c drives are not yet ready (sata_mv)
Copying various Kirkwood upstream kernel people: we received some bug
reports in Debian on SATA timing issues on boot on QNAP devices.
Apparently QNAP put in an mdelay hack in their kernel to make it work.
Below is Martin Waschbuesch's report and you can find some more
information at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=714959
Is this a known issue?
* Martin Waschbuesch <martin@waschbuesch.de> [2013-07-04 19:12]:
> Package: src:linux
> Version: 3.2.46-1
> Severity: normal
> Tags: upstream patch
>
> Dear Maintainer,
>
> On my QNAP TS-412, after a clean install of Wheezy, the kernel fails to bring up all sata ports (using Marvell 88SX7042 via sata_mv driver) before md/raid tries to assemble the array.
> The same disks/array work in a different model (TS-410) and the drives/array from said TS-410 also fail in my TS-412.
> At the same time, using the original QNAP firmware, everything works as expected.
> The only discernable differences between the devices that I could find (they share the exact same SoC and SATA Model ID and revision), apart from the core clock speed, is that the TS-412 shows some sort of spin-up delay / staggering behaviour while the TS-410 does not.
> Now, having had a look at the most recent GPL code package from QNAP that I could find here:
> http://sourceforge.net/projects/qosgpl/
> I found that they have a version 3.4.6 kernel tree.
> The file drivers/ata/sata_mv.c contains some changes regarding the delay while initializing the hardware.
> Using this as a blueprint, I patched the linux-image-3.2.0-4 source file accordingly.
> The resulting kernel works for me: The delay ensures that all drives are up and the raid array comes up.
>
> I discussed this with others on debian-arm@lists.debian.org and while we agree that this kind of patch is a mere band-aid, we wanted to point out that there may be some issue concerning timing/delays with this kernel module.
>
> Maybe there is a more elegant / targeted approach to solving this?
...
> #define DRV_VERSION "1.28"
>
> +//Patch by QNAP: delay SATA disk initialization
> +#define QMV_SATA_INIT_DELAY_PHASE 5000 //milliseconds
> +////////////////////////////////////////////////////////////////
> +
> /*
> * module options
> */
> @@ -4329,7 +4333,11 @@
> struct ata_port *ap = host->ports[port];
> void __iomem *port_mmio = mv_port_base(hpriv->base, port);
> unsigned int offset = port_mmio - hpriv->base;
> -
> + // marvell 7042 port 2 port 3 will power on by order every 5 sec
> + if( (port==2) || (port == 3) ){
> + printk("Wait %d seconds to initialize scsi %d.\n",QMV_SATA_INIT_DELAY_PHASE/1000,port);
> + mdelay(QMV_SATA_INIT_DELAY_PHASE);
> + }
> ata_port_pbar_desc(ap, MV_PRIMARY_BAR, -1, "mmio");
> ata_port_pbar_desc(ap, MV_PRIMARY_BAR, offset, "port");
> }
--
Martin Michlmayr
http://www.cyrius.com/
Reply to: