Date: Thu, 9 May 2024 06:18:26 +0200
From: Peter Schneider <pschneider1968@...glemail.com>
To: "Martin K. Petersen" <martin.petersen@...cle.com>
Cc: linux-scsi@...r.kernel.org, stable@...r.kernel.org,
 linux-kernel@...r.kernel.org, regressions@...mhuis.info,
 regressions@...ts.linux.dev
Subject: Re: Kernel 6.8.4 regression: aacraid controller not initialized any
 more, system boot hangs

Am 09.05.2024 um 04:12 schrieb Peter Schneider:

 > Hi Martin,
 >
 > Am 09.05.2024 um 03:38 schrieb Martin K. Petersen:
 >  >
 >  > Hi Peter!
 >  >
 >  > Thanks for the detailed bug report.
 >
 > Thanks that you are looking into the issue! I thought I'd be also CC'ing the relevant
 > regressions tracker+mailing list. For reference, my original message can be found here:
 >
 > https://lore.kernel.org/all/eec6ebbf-061b-4a7b-96dc-ea748aa4d035@googlemail.com/
 >
 > [...]
 >
 >  > Can you please send me the output of:
 >  >
 >  > # sg_vpd -a /dev/sda
 >  > # sg_readcap -l /dev/sda
 >  >
 >  > where sda is one of the aacraid volumes.
 >
 >
 > Here you go... sda is the 1TiB RAID1 array, sdb is the 5TiB RAID5 array.
 >
 >
 > root@...us:~# uname -r
 > 6.5.13-5-pve
 > root@...us:~# sg_vpd -a /dev/sda
 > Supported VPD pages VPD page:
 >    Supported VPD pages [sv]
 >    Unit serial number [sn]
 >    Device identification [di]
 >
 > Unit serial number VPD page:
 >    Unit serial number: 50C0B82D
 >
 > Device Identification VPD page:
 >    Addressed logical unit:
 >      designator type: T10 vendor identification,  code set: ASCII
 >        vendor id: ADAPTEC
 >        vendor specific: ARRAY           50C0B82D
 >      designator type: EUI-64 based,  code set: Binary
 >        0x2db8c05000d00000
 > root@...us:~# sg_readcap -l /dev/sda
 > Read Capacity results:
 >     Protection: prot_en=0, p_type=0, p_i_exponent=0
 >     Logical block provisioning: lbpme=0, lbprz=0
 >     Last LBA=1998565375 (0x771fafff), Number of logical blocks=1998565376
 >     Logical block length=512 bytes
 >     Logical blocks per physical block exponent=0
 >     Lowest aligned LBA=0
 > Hence:
 >     Device size: 1023265472512 bytes, 975862.0 MiB, 1023.27 GB
 > root@...us:~# sg_vpd -a /dev/sdb
 > Supported VPD pages VPD page:
 >    Supported VPD pages [sv]
 >    Unit serial number [sn]
 >    Device identification [di]
 >
 > Unit serial number VPD page:
 >    Unit serial number: 8718162D
 >
 > Device Identification VPD page:
 >    Addressed logical unit:
 >      designator type: T10 vendor identification,  code set: ASCII
 >        vendor id: ADAPTEC
 >        vendor specific: ARRAY           8718162D
 >      designator type: EUI-64 based,  code set: Binary
 >        0x2d16188700d00000
 > root@...us:~# sg_readcap -l /dev/sdb
 > Read Capacity results:
 >     Protection: prot_en=0, p_type=0, p_i_exponent=0
 >     Logical block provisioning: lbpme=0, lbprz=0
 >     Last LBA=9762222079 (0x245dfafff), Number of logical blocks=9762222080
 >     Logical block length=512 bytes
 >     Logical blocks per physical block exponent=0
 >     Lowest aligned LBA=0
 > Hence:
 >     Device size: 4998257704960 bytes, 4766710.0 MiB, 4998.26 GB, 5.00 TB
 >
 >
 > Beste Grüße,
 > Peter Schneider
 >


I just found something else which looks interesting and might or might not be related to 
the regression. To get the requested diagnostic output you asked for, I obviously booted 
into the working kernel version 6.5.13-5-pve, see above. Out of curiousity, I used these 
commands also onto my other drives, sdc (PVE installation and root device) and sdf (my 
storage for VM ISO installation images). These are both older Micron M4 SATA SSD drives.

Turns out, these drives seem to have a buggy firmware. They don't return all the VPD pages 
they advertise. Querying for the advertised VPD page=0xb7 gives "sg_vpd failed: Illegal 
request", please see below... Is this a smoking gun? They both were previously used by me 
in a Windows box for ~2 years, till I replaced them and put them aside. Then in 2015 I 
recycled them for use in my newly built server machine. Before original use in the 
mentioned Windows box, I upgraded their firmware to 0309, because the factory firmware had 
known issues with Windows.

In 2015, I didn't care to look again for a newer firmware. But there is one, 070h, here:

https://www.crucial.de/support/ssd-support/m4-25-inch-support

and in the release notes

https://content.crucial.com/content/dam/crucial/ssd-products/m4/documents/crucial-m4-firmware-update-070h-en.pdf

there is mention of a potential device hang during power up being fixed with FW 070h.

Do you think I should try to apply this FW upgrade, to see if
- this fixes the below issue of advertised VPD page not being returned
- this could probably fix the whole regression issue with the Adaptec controller not 
initialized any more with your kernel patch b5fc07a5fb56216a49e6c1d0b172d5464d99a89b ?

Or is this just guesswork? I mean, in the dmesg output, the Adaptec controller is 
initialized BEFORE sdc and sdd. I don't know...





root@...us:~# sg_vpd -a /dev/sdc
Supported VPD pages VPD page:
   Supported VPD pages [sv]
   Unit serial number [sn]
   Device identification [di]
   ATA information (SAT) [ai]
   Block limits (SBC) [bl]
   Block device characteristics (SBC) [bdc]
   Logical block provisioning (SBC) [lbpv]
   Concurrent positioning ranges [cpr]

Unit serial number VPD page:
   Unit serial number: 000000001141031B85A2

Device Identification VPD page:
   Addressed logical unit:
     designator type: vendor specific [0x0],  code set: ASCII
       vendor specific: 000000001141031B85A2
     designator type: T10 vendor identification,  code set: ASCII
       vendor id: ATA
       vendor specific: M4-CT256M4SSD2                          000000001141031B85A2
     designator type: NAA,  code set: Binary
       0x500a0751031b85a2

ATA information VPD page:
   SAT Vendor identification: linux
   SAT Product identification: libata
   SAT Product revision level: 3.00
   Device signature indicates SATA transport
   Command code: 0xec
   ATA command IDENTIFY DEVICE response summary:
     model: M4-CT256M4SSD2
     serial number: 000000001141031B85A2
     firmware revision: 0309

Block limits VPD page (SBC):
   Write same non-zero (WSNZ): 0
   Maximum compare and write length: 0 blocks [Command not implemented]
   Optimal transfer length granularity: 1 blocks
   Maximum transfer length: 0 blocks [not reported]
   Optimal transfer length: 0 blocks [not reported]
   Maximum prefetch transfer length: 0 blocks [ignored]
   Maximum unmap LBA count: 0 [Unmap command not implemented]
   Maximum unmap block descriptor count: 0 [Unmap command not implemented]
   Optimal unmap granularity: 1 blocks
   Unmap granularity alignment valid: false
   Unmap granularity alignment: 0 [invalid]
   Maximum write same length: 0x3fffc0 blocks
   Maximum atomic transfer length: 0 blocks [not reported]
   Atomic alignment: 0 [unaligned atomic writes permitted]
   Atomic transfer length granularity: 0 [no granularity requirement
   Maximum atomic transfer length with atomic boundary: 0 blocks [not reported]
   Maximum atomic boundary size: 0 blocks [can only write atomic 1 block]

Block device characteristics VPD page (SBC):
   Non-rotating medium (e.g. solid state)
   Product type: Not specified
   WABEREQ=0
   WACEREQ=0
   Nominal form factor: 2.5 inch
   ZONED=0
   RBWZ=0
   BOCS=0
   FUAB=0
   VBULS=0
   DEPOPULATION_TIME=0 (seconds)

Logical block provisioning VPD page (SBC):
   Unmap command supported (LBPU): 0
   Write same (16) with unmap bit supported (LBPWS): 1
   Write same (10) with unmap bit supported (LBPWS10): 0
   Logical block provisioning read zeros (LBPRZ): 0
   Anchored LBAs supported (ANC_SUP): 0
   Threshold exponent: 0 [threshold sets not supported]
   Descriptor present (DP): 0
   Minimum percentage: 0 [not reported]
   Provisioning type: 0 (not known or fully provisioned)
   Threshold percentage: 0 [percentages not supported]

VPD page=0xb7
fetching VPD page failed: Illegal request
sg_vpd failed: Illegal request
root@...us:~# sg_vpd -a /dev/sdf
Supported VPD pages VPD page:
   Supported VPD pages [sv]
   Unit serial number [sn]
   Device identification [di]
   ATA information (SAT) [ai]
   Block limits (SBC) [bl]
   Block device characteristics (SBC) [bdc]
   Logical block provisioning (SBC) [lbpv]
   Concurrent positioning ranges [cpr]

Unit serial number VPD page:
   Unit serial number: 00000000120103285ED2

Device Identification VPD page:
   Addressed logical unit:
     designator type: vendor specific [0x0],  code set: ASCII
       vendor specific: 00000000120103285ED2
     designator type: T10 vendor identification,  code set: ASCII
       vendor id: ATA
       vendor specific: M4-CT256M4SSD2                          00000000120103285ED2
     designator type: NAA,  code set: Binary
       0x500a075103285ed2

ATA information VPD page:
   SAT Vendor identification: linux
   SAT Product identification: libata
   SAT Product revision level: 3.00
   Device signature indicates SATA transport
   Command code: 0xec
   ATA command IDENTIFY DEVICE response summary:
     model: M4-CT256M4SSD2
     serial number: 00000000120103285ED2
     firmware revision: 0309

Block limits VPD page (SBC):
   Write same non-zero (WSNZ): 0
   Maximum compare and write length: 0 blocks [Command not implemented]
   Optimal transfer length granularity: 1 blocks
   Maximum transfer length: 0 blocks [not reported]
   Optimal transfer length: 0 blocks [not reported]
   Maximum prefetch transfer length: 0 blocks [ignored]
   Maximum unmap LBA count: 0 [Unmap command not implemented]
   Maximum unmap block descriptor count: 0 [Unmap command not implemented]
   Optimal unmap granularity: 1 blocks
   Unmap granularity alignment valid: false
   Unmap granularity alignment: 0 [invalid]
   Maximum write same length: 0x3fffc0 blocks
   Maximum atomic transfer length: 0 blocks [not reported]
   Atomic alignment: 0 [unaligned atomic writes permitted]
   Atomic transfer length granularity: 0 [no granularity requirement
   Maximum atomic transfer length with atomic boundary: 0 blocks [not reported]
   Maximum atomic boundary size: 0 blocks [can only write atomic 1 block]

Block device characteristics VPD page (SBC):
   Non-rotating medium (e.g. solid state)
   Product type: Not specified
   WABEREQ=0
   WACEREQ=0
   Nominal form factor: 2.5 inch
   ZONED=0
   RBWZ=0
   BOCS=0
   FUAB=0
   VBULS=0
   DEPOPULATION_TIME=0 (seconds)

Logical block provisioning VPD page (SBC):
   Unmap command supported (LBPU): 0
   Write same (16) with unmap bit supported (LBPWS): 1
   Write same (10) with unmap bit supported (LBPWS10): 0
   Logical block provisioning read zeros (LBPRZ): 0
   Anchored LBAs supported (ANC_SUP): 0
   Threshold exponent: 0 [threshold sets not supported]
   Descriptor present (DP): 0
   Minimum percentage: 0 [not reported]
   Provisioning type: 0 (not known or fully provisioned)
   Threshold percentage: 0 [percentages not supported]

VPD page=0xb7
fetching VPD page failed: Illegal request
sg_vpd failed: Illegal request
root@...us:~# man sg_vpd





Beste Grüße,
Peter Schneider

-- 
Climb the mountain not to plant your flag, but to embrace the challenge,
enjoy the air and behold the view. Climb it so you can see the world,
not so the world can see you.                    -- David McCullough Jr.

OpenPGP:  0xA3828BD796CCE11A8CADE8866E3A92C92C3FF244
Download: https://www.peters-netzplatz.de/download/pschneider1968_pub.asc
https://keys.mailvelope.com/pks/lookup?op=get&search=pschneider1968@googlemail.com
https://keys.mailvelope.com/pks/lookup?op=get&search=pschneider1968@gmail.com


Download attachment "OpenPGP_signature.asc" of type "application/pgp-signature" (237 bytes)

Powered by blists - more mailing lists