Re: [PATCH] scsi: devinfo: Add BLIST_NO_RSOC for Promise VTrak E310f

[Xose Vazquez Perez <xose.vazquez@gmail.com>]

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.