* Re: [PATCH] scsi: devinfo: Add BLIST_NO_RSOC for Promise VTrak E310f
[not found] ` <f5f2c2d0-382e-4032-a5a4-c82aac3a4b80@gmail.com>
@ 2026-05-13 11:54 ` Xose Vazquez Perez
0 siblings, 0 replies; 2+ messages in thread
From: Xose Vazquez Perez @ 2026-05-13 11:54 UTC (permalink / raw)
To: Alexander Perlis, James E.J. Bottomley, Martin K. Petersen,
Nikkos Svoboda
Cc: SCSI ML
On 5/13/26 1:08 PM, Xose Vazquez Perez wrote:
> On 5/13/26 1:12 AM, Alexander Perlis wrote:
>
>> The extremely slow boots reported July 2014 in
>> [Bug 79901](https://bugzilla.kernel.org/show_bug.cgi?id=79901)
>> for Promise VTrak E610f 3U 16-bay FC RAID enclosure occur also with
>> the Promise VTrak E310f 2U 12-bay FC RAID enclosure. The 2014
>> [patch](https://bugzilla.kernel.org/attachment.cgi?id=144101&action=diff)
>> added support for the BLIST_NO_RSOC flag and specified that flag for the
>> Promise VTrak E610f. This current patch simply adds the E310f to that same
>> list. (My workaround has been to include
>> scsi_mod.dev_flags=Promise:\"VTrak E310f\":0x20000040
>> among my kernel boot parameters.)
>>
>> One curiosity is the additional BLIST_SPARSELUN flag. This was also in
>> the 2014 patch for the E610f, and was already in place for *all* Promise
>> devices since 2007 due to commit
>> e0b2e597d5dd ("[SCSI] stex: fix id mapping issue")
>> which added the line
>> {"Promise", "", NULL, BLIST_SPARSELUN}
>> The 2007 commit message talks of issues with SuperTrak EX (stex) but
>> the added line did not limit itself to that particular device family.
>> The current patch for E310F, like the 2014 patch for E610f, adds
>> BLIST_NO_RSOC while preserving BLIST_SPARSELUN from 2007.
>>
>> Signed-off-by: Alexander Perlis <aperlis@math.lsu.edu>
>> Suggested-by: Nikkos Svoboda <nsvoboda@math.lsu.edu>
>> ---
>> drivers/scsi/scsi_devinfo.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/scsi/scsi_devinfo.c b/drivers/scsi/scsi_devinfo.c
>> index 68a992494b12..c6defe1c3152 100644
>> --- a/drivers/scsi/scsi_devinfo.c
>> +++ b/drivers/scsi/scsi_devinfo.c
>> @@ -218,6 +218,7 @@ static struct {
>> {"PIONEER", "CD-ROM DRM-602X", NULL, BLIST_FORCELUN | BLIST_SINGLELUN},
>> {"PIONEER", "CD-ROM DRM-604X", NULL, BLIST_FORCELUN | BLIST_SINGLELUN},
>> {"PIONEER", "CD-ROM DRM-624X", NULL, BLIST_FORCELUN | BLIST_SINGLELUN},
>> + {"Promise", "VTrak E310f", NULL, BLIST_SPARSELUN | BLIST_NO_RSOC},
>> {"Promise", "VTrak E610f", NULL, BLIST_SPARSELUN | BLIST_NO_RSOC},
>> {"Promise", "", NULL, BLIST_SPARSELUN},
>> {"QEMU", "QEMU CD-ROM", NULL, BLIST_SKIP_VPD_PAGES},
>
>
> Regarding the Promise VTrak family, the Ex10 series models all share the
> same hardware base and firmware:
>
> Firmware SR2.8(3.36.0000.02) for PROMISE VTrak Ex10 series models:
> E610fD - 3U, 16 bays, FC, dual controller
> E610fS - 3U, 16 bays, FC, single controller
> E610sD - 3U, 16 bays, SAS, dual controller
> E610sS - 3U, 16 bays, SAS, single controller
> E310fD - 2U, 12 bays, FC, dual controller
> E310fS - 2U, 12 bays, FC, dual controller
> E310sD - 2U, 12 bays, SAS, dual controller
> E310sS - 2U, 12 bays, SAS, single controller
>
> Instead of adding each specific model, it might be more efficient to use a
> broader match string to cover the entire family, as they all exhibit the
> same behavior.
>
> I would suggest consolidating these entries. For example:
> - {"Promise", "VTrak E610f", NULL, BLIST_SPARSELUN | BLIST_NO_RSOC},
> + {"Promise", "VTrak E310", NULL, BLIST_SPARSELUN | BLIST_NO_RSOC},
> + {"Promise", "VTrak E610", NULL, BLIST_SPARSELUN | BLIST_NO_RSOC},
>
> This would cover all variants.
^ permalink raw reply [flat|nested] 2+ messages in thread