TX1 Orbitty Carrier SD card troubles

I’m using TX1 with Orbitty Carrier. When downloading a file to a 128GB Samsung microSDXC UHS-I card, download fails. “dmesg” shows “Buffer I/O error on device” and “SD status: invalid allocation unit size”. The SD card is formatted to ext4 and default allocation unit size 512b, works on other devices. The same happens with a similar 128GB microSDXC UHS-I card. However with a 16GB SDHC UHS-I Kingston card with the same formatting, the download completes without a problem. Also i had no problems with SDXC cards with TX1 Devkit, however no luck with Orbitty.
The system recognizes and allows to format the SD card.“fsck” returns no errors.

Linux version: Ubuntu 16.04 LTS 64-bit

Drivers installed:
Module Size Used by
bnep 14896 2
bcmdhd 7465032 0
cfg80211 452899 1 bcmdhd
bluedroid_pm 11420 0

Card slot:
microSD Molex WM19093 series

The SD cards are formatted as follows:
Partition Type: Linux
Contents: Ext4(version 1.0)

Could there be a SD card size limit, UHS-I compatibility issue or some other reason for the SDXC card to not work?

Arvids

What was your partition tool? I’m thinking possibly you need GPT (though not necessarily…this is a guess). If it is GPT then “sudo gdisk -l /dev/whatever_the_sd_is” should show valid GPT partitions.

sudo gdisk shows valit partitions. I tried formatting with Gparted, Disks and some windows tools as well. I also tried to make a smaller parttion (64GB, 16GB) on the SDXC card, but those don’t work either.

After that I do not know of any simple tests other than tests to ignore formatting and just see if raw access works. One way would be to use dd to read the entire SD card, throwing away what is read into “/dev/null” and monitoring dmesg while doing so. So for example, without mounting the SD card, a read might go something like this:

sudo dd if=/dev/whichever_device of=/dev/null bs=512

That would probably take a bit of time. If it fails, then there may be something on dmesg specific to the device without interference from file system drivers (no file system is involved, it simplifies things).

If you don’t mind overwriting and losing an SD card’s content, then you can do the same thing for writing to it:

sudo dd if=/dev/zero of=/dev/whichever_device bs=512

The important thing about the above is that those tests will be purely about read and write without any other software (like file systems) getting in the way.

The manufacturer suggested formatting the card to exFAT and using fuse-exfat
and exfat-utils, but even with that i’m still getting the

"SD status: invalid allocation unit size"

when mounting and

"Buffer I/O error on device"

when writing to the card.

Do the dd commands work? dd will be agnostic of any partition or file system formatting type.

Write and read were successful
250179584+0 records in
250179584+0 records out
128091947008 bytes (128GB, 119 GiB) copied

Going to reflush TX1 with Ubuntu 14.04

At least you can know the raw hardware controller read/write was working correctly due to dd working without error (though you might double check dmesg output while doing the dd testing). So any driver layered above this is suspect (including ext4 file system and end-user application).

How could i check if my drivers fully support SD card reading in all formats? Or how couldi find what i’m missing?

I am using:
Module Size Used by
rfcomm 66118 0
bnep 14896 2
bcmdhd 7465032 0
cfg80211 452899 1 bcmdhd
bluedroid_pm 11420 0

If you try to mount a partition and don’t name the file system type it should just work; while doing so dmesg should report the file system type it mounted as. Unknown file system would be the result of not having a driver for that file system type…there would be no possibility of seeing the buffer errors if the file system type were not supported because no mount would have ever occurred. So…just try to manually mount a partition and you’ll know.

If you are referring not to file system format, but instead to the different standards of SD cards, then dd would have answered that…dd cannot work on an unsupported SD card type.

Because dd had worked, but you still have buffer errors, I think there is a driver error somewhere in the mix which is at fault (though it could still be a matter of that SD card misbehaving…which would be the case of a driver not handling the misbehaving SD card gracefully). I’m guessing someone at NVIDIA would need that particular model of SD card to debug the issue.