Re: [PATCH] scsi: smartpqi_init: Reporting 'logical unit failure'

[...] > Be careful printing errors per-IO; you could get thousands of them if things > go bad. > The block layer print_req_error() uses printk_ratelimited(KERN_ERR) for that > reason, > and the SCSI layer scsi_io_completion_action() maintains a ratelimit on its > own. > > The dev_err_ratelimited

RE: [PATCH] scsi: smartpqi_init: Reporting 'logical unit failure'

> -Original Message- > From: linux-kernel-ow...@vger.kernel.org > [mailto:linux-kernel-ow...@vger.kernel.org] On Behalf Of > Erwan Velu > Sent: Wednesday, February 27, 2019 10:32 AM > Subject: [PATCH] scsi: smartpqi_init: Reporting 'logical unit failure' &

Re: [PATCH] scsi: smartpqi_init: Reporting 'logical unit failure'

Hey, That makes me wonder why the 0x3e / 0x2 isn't handled here aka 3E/02 DZTPROMAEBKVF TIMEOUT ON LOGICAL UNIT Is it possible the controller send to the kernel this kind of message, if so shouldn't we handle it here ? Erwan, Le 27/02/2019 à 17:31, Erwan Velu a écrit : > When this HARDWARE_ER

[PATCH] scsi: smartpqi_init: Reporting 'logical unit failure'

When this HARDWARE_ERROR/0x3e/0x1 case is triggered, the logical volume is offlined. When reading the kernel log, the cause why the device got offlined isn't reported to the user. This situation makes difficult for admins to estimate _why_ the volume got offlined. Reading this part of the code m