On Sun, Aug 9, 2015 at 2:11 AM, Luca De Feo <[email protected]>
wrote:
> Hello,
>
> I have Debian stretch running on a QNAP TS-412, and I am having
> serious problems lately with updates.
>
> When flash-kernel is triggered by update-initramfs, the ssh connection
> becomes laggy. First time it happened, I was kicked out, and any
> successive attempts to ssh failed with a "Broken pipe" immediately
> after accepting the password.
>
> The second time I was luckier: I got back into my shell, but the root
> fs had been remounted read-only. The last output I have from
> flash-kernel before being cut out is
>
> kirkwood-qnap: machine: QNAP TS419 family
> DTB: kirkwood-ts419-6281.dtb
> Installing kirkwood-ts419-6281.dtb into /boot/dtbs
> /4.0.0-2-kirkwood/kirkwood-ts419-6281.dtb
> Taking backup of kirkwood-ts419-6281.dtb.
> Installing new kirkwood-ts419-6281.dtb.
> flash-kernel: installing version 4.0.0-2-kirkwood
> flash-kernel: appending
> /usr/lib/linux-image-4.0.0-2-kirkwood/kirkwood-ts419-6281.dtb to
> kernel
> Generating kernel u-boot image... done.
> Flashing kernel (using 2076902/2097152 bytes)... done.
> Flashing initramfs (using 4604898/9437184 bytes)...
>
> The last lines in syslog before the ro remount are
>
> Aug 9 01:28:38 debian kernel: [ 231.740207] ata4.00: exception
> Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
> Aug 9 01:28:38 debian kernel: [ 231.824648] ata4.00: failed
> command: FLUSH CACHE EXT
> Aug 9 01:28:38 debian kernel: [ 231.884124] ata4.00: cmd
> ea/00:00:00:00:00/00:00:00:00:00/a0 tag 27
> Aug 9 01:28:38 debian kernel: [ 231.884124] res
> 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
> Aug 9 01:28:38 debian kernel: [ 232.047750] ata4.00: status: { DRDY }
> Aug 9 01:28:38 debian kernel: [ 232.091592] ata4: hard resetting link
> Aug 9 01:28:39 debian kernel: [ 232.877725] ata4: SATA link up
> 3.0 Gbps (SStatus 123 SControl 300)
> Aug 9 01:28:45 debian kernel: [ 238.110920] ata4.00: qc timeout (cmd
> 0xec)
> Aug 9 01:28:45 debian kernel: [ 238.159972] ata4.00: failed to
> IDENTIFY (I/O error, err_mask=0x4)
> Aug 9 01:28:45 debian kernel: [ 238.232969] ata4.00:
> revalidation failed (errno=-5)
> Aug 9 01:28:45 debian kernel: [ 238.291407] ata4: hard resetting link
> Aug 9 01:28:45 debian kernel: [ 239.017033] ata4: SATA link up
> 3.0 Gbps (SStatus 123 SControl 300)
> Aug 9 01:28:56 debian kernel: [ 249.175319] ata4.00: qc timeout (cmd
> 0xec)
> Aug 9 01:28:56 debian kernel: [ 249.224367] ata4.00: failed to
> IDENTIFY (I/O error, err_mask=0x4)
> Aug 9 01:28:56 debian kernel: [ 249.297361] ata4.00:
> revalidation failed (errno=-5)
> Aug 9 01:28:56 debian kernel: [ 249.355799] ata4: limiting SATA
> link speed to 1.5 Gbps
> Aug 9 01:28:56 debian kernel: [ 249.417357] ata4: hard resetting link
> Aug 9 01:28:57 debian kernel: [ 250.581397] ata4: SATA link up
> 1.5 Gbps (SStatus 113 SControl 310)
>
> ata4 is the disk that contains my root fs.
>
> Rebooting restores the system to a normal state
>
> Any help appreciated.
>
> Thanks,
> Luca
>
>
> --
> To UNSUBSCRIBE, email to [email protected]
> with a subject of "unsubscribe". Trouble? Contact
> [email protected]
> Archive:
> https://lists.debian.org/camlx2cqt+2fzfa9_bc0fxlaj1wj+yqujvuthjwn48kgjtjh...@mail.gmail.com
>
>
Hi Luca,
I have experienced the exactly same problem with my QNAP TS-212P since the
upgrade to kernel 4.0, but haven't reported this upstream due to lack of
time. In fact, using the older kernels the device would also stall during
the flashing operation, but likely due to more relaxed sata timeouts it was
capable to finish without remounting the system read-only.
This is just a hunch, but perhaps a part of the problem is because
flash-kernel simply cats the image to mtdblock, which is not the
recommended way to deal with flash storage [1].
When I have more time, I'd like to try flashcp from mtd-utils and see if
the deadlock still occurs. If it does, it's likely a kernel bug somewhere
in handling flash storage.
Best regards,
Jan
1. http://free-electrons.com/blog/managing-flash-storage-with-linux/
