[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: flash-kernel puts QNAP on its knees




On Sun, Aug 9, 2015 at 2:11 AM, Luca De Feo <luca.defeo@polytechnique.edu> 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 debian-arm-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: [🔎] CAMLx2CqT+2fzfa9_Bc0fXLAJ1wJ+yQuJvUThJwN48kGJTJhJxg@mail.gmail.com" rel="noreferrer" target="_blank">https://lists.debian.org/[🔎] CAMLx2CqT+2fzfa9_Bc0fXLAJ1wJ+yQuJvUThJwN48kGJTJhJxg@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/

Reply to: