megaraid_sas takes 1+ seconds to load while waiting for firmware:
[2.822603] megaraid_sas :03:00.0: Waiting for FW to come to ready state
[3.871003] megaraid_sas :03:00.0: FW now in Ready state
This is due to the following loop in megasas_transition_to_ready(), which
waits a minimum of 1
When the HARDWARE_ERROR/0x3e/0x1 case is triggered, the logical volume is
offlined.
When reading the kernel log, the reason why the device got offlined isn't
reported to the user.
This situation makes difficult for admins to estimate the root cause of the
issue they analize.
Reading this part o
[...]
> 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
On Fri, 2019-03-01 at 15:58 +0100, Erwan Velu wrote:
> + dev_err_ratelimited(&ctrl_info->pci_dev-
> >dev, "received 'logical unit failure' from controller for scsi
> %d:%d:%d:%d\n",
> + ctrl_info-
> >scsi_host->host_no, device-
Le 01/03/2019 à 16:26, James Bottomley a écrit :
> [...]
> Shouldn't this be a variant of sdev/scmd_printk? Otherwise it tells
> you what disk in the array terms is the problem but not what device in
> your actual system is affected.
Hey James,
My initial take on that was that pqi_take_device_o
On Fri, 2019-03-01 at 15:43 +, Erwan Velu wrote:
> Le 01/03/2019 à 16:26, James Bottomley a écrit :
> > [...]
> > Shouldn't this be a variant of sdev/scmd_printk? Otherwise it
> > tells
> > you what disk in the array terms is the problem but not what device
> > in
> > your actual system is aff
Le 01/03/2019 à 16:56, James Bottomley a écrit :
> [...]
> I was thinking just
>
> if (printk_ratelimit())
> scmd_printk(KERN_ERR, scmd, "received 'logical unit failure' from
> controller for scsi %d:%d:%d:%d\n", ...
>
> That will give all the necessary information
I'm pretty new to this a
When the HARDWARE_ERROR/0x3e/0x1 case is triggered, the logical volume is
offlined.
When reading the kernel log, the reason why the device got offlined isn't
reported to the user.
This situation makes difficult for admins to estimate the root cause of the
issue they analize.
Reading this part o
On 02/28/2019 01:28 PM, Cathy Avery wrote:
> genlmsg_multicast_allns now returns the correct statuses when a
> message is sent to a listener. However in the case of adding a
> device we want to wait for the listener otherwise we may miss the
> the device during startup.
>
> Signed-off-by: Cathy Av
The product_id and revision attributes will allow for the modification
of the T10 Model and Revision strings returned in inquiry responses.
Its value can be viewed and modified via the ConfigFS path at:
target/core/$backstore/$name/wwn/product_id
target/core/$backstore/$name/wwn/revision
Signed-o
10 matches
Mail list logo
