kernel: 4.19.83, 5.3.11, 5.4.3 reports wrongly SSD disk capacity (130PB instead of 512GB) #3388
Comments
|
This is likely an upstream kernel bug fixed sometime between the 4.19 release and 5.4 release.
|
|
In the meantime I've tried from 5.3.11 from https://github.com/raspberrypi/linux/tree/rpi-5.3.y branch and it behaves exactly in the same way as 4.19.83.
I can try 5.4.y, but is it in pair with 5.3.y? I don't see a fix for #3332 in 5.4.y? |
|
The fix in that commit is specific to dwc_otg, which isn't used in host mode on Pi 4. An xhci controller provides USB host functionality. 5.4 should work well enough to replicate the test. |
The oldest one I can run now on my PC is: and that one is working fine: When I compiled 5.4.3 from 0f100bc then it's working wrongly: First time (after boot) disk was attached: Second time when disk was attached: The pattern when attaching the disk for the So, based on above it looks like it's RPi related rather than generic upstream kernel issue? |
dwrobel
changed the title
|
Just a guess, this looks like some kind of integer overflow. |
I compiled 5.4.3 from 0f100bc for It looks like the number of logical blocks is somehow random (excluding the aforementioned pattern when 4294902016 is being reported initially): |
I also got access to the quite old PC laptop powered by 32-bit i686 PAE kernel:
and when attaching a disk it works as expected (proper capacity is reported). So, I assume that could give us a hint that the code could run also fine on the 32-bit kernel version without an issue. |
|
I think these buffer I/O errors are related to this issue. |
IMHO those are related to wrongly reported capacity of the disk.
Yes, the I/O errors appears only on the RPI(s) on PC there are no errors.
Please have a look at the initial log from my PC #3388 (comment) for complete log from the 5.4.5 kernel and more details from lsusb for
|
|
I see in the wireshark dump that the value from dmesg line (when attaching a disk for the first time):
appears in the USB packet (in the form off-by-one):
wireshark packet (101) dump: Converting:
into hex: doesn't look like the value is fully random. |
Or those errors cause the capacity to be wrongly reported. Here is the prove that reading from the drive on PC do not produce any I/O errors: The same doesn't work at all on the RPI4:
Long story short the "TOSHIBA THNSNK512GCS8 SA" is the original disk from my Laptop which I used for last two years without any single issue. As the space run out I bought a new 1TB disk for my PC and had plans to use the "TOSHIBA THNSNK512GCS8 SA" with one of my RPi4(s). On the other hand, on the RPi4, I used the controller "ASMT1153e" with the "IR-SSDPR -S25A-120" disk as a root filesystem for a few months. That machine constantly runs openhab/graphana/influxdb and was used for building many packages using So I have quite well tested:
Now it appears that on the RPi4 (and so far only on that platform) the combination: Based on above I'm rather reluctant to blame either "ASMT1153e" controller or "TOSHIBA THNSNK512GCS8 SA" disk. |
|
I experience a similar behavior you have posted in your last comment. Did you finally come to a conclusion what has caused the errors and you could you fix it @dwrobel? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
While attaching SSD disk through the USB 3.0 controller to the RPi4 or RPi3B+ they reports the wrong size of the disk capacity and as a result they can't read properly disk partition layout.
dmesg excerpt while connecting to the RPi4 (kernel 4.19.83):
I don't have access to other types of RPi(s) to test them.
However, when I'm connecting the same disk, using the same USB controller, to the x86_64 based PC machine (kernel 5.4.5) the relevant dmesg excerpt looks like the following:
When I'm connecting a different SSD disk (GOODRAM 120 GB) using the same USB controller to both RPi4B and RPi3B+ then everything is working fine (dmesg excerpt from RPi4B):
More information about RPi4:
lsusb output:
lsusb -v for 174c:55aa ASMedia controller:
rpi-eeprom output:
The text was updated successfully, but these errors were encountered: