Back with some update: Am 29.06.2013 14:04, schrieb Martin Waschbüsch:
> Now, since everything works fine whenever I switch back to the QNAP > firmware, this does not look like a straightforward hardware fault. > However, I just don't know how to start debugging this. > > If anyone could give me some advice as to what I am missing or what > else I could try, please let me know. Doing some more testing, I noticed that one difference betwen the TS-410 and TS-412 I own is this: Delay between spinup of drives is noticably longer for the TS-412. So, I thought that maybe the QNAP kernel waits longer for all drives / ports to be ready than the debian one, which would explain why things work running wnap firmware, but not with debian. Only one way to find out! In the most recent GPL code package from QNAP that I could find here: (http://sourceforge.net/projects/qosgpl/) there is a version 3.4.6 kernel tree. The file drivers/ata/sata_mv.c contains some changes that seem to point in that same direction: -- snip -- #define DRV_NAME "sata_mv" #define DRV_VERSION "1.28" //Patch by QNAP: delay SATA disk initialization #if defined(CONFIG_MACH_QNAPTS) #define QMV_SATA_INIT_DELAY_PHASE 5000 //milliseconds #endif //////////////////////////////////////////////////////////////// -- snip -- And further down where the ports are initialized: -- snip -- #if defined(CONFIG_MACH_QNAPTS) // 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); } #endif ///////////////////////////////////////////// -- snip -- To test this, I patched the driver from debian's linux-source-3.2 accordingly and am re-compiling the kernel as we speak. I'll be back with results on that... Martin -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51d128b5.8020...@waschbuesch.de
