Raspbian crashes when creating filesystem

#1

just received my sata hat and top hat. No 10 pin cable included, thank you Grrr
brand new SSD, Brand new SD card, flashed the latest Raspbian Buster. installed sata hat on Raspberry Pi 4B. Using the Pi Foundations power supply for the Pi4. Booted up, configured raspbian, installed the script for the sata hat and rebooted. Boots up, red lights flash across all 4 sata sockets then sata1, with the 64GB SSD has the blue light on. fdisk -l shows it as /dev/sda
partition the disk, write the partition, and get the offset error posted in another thread. ran fdisk again and made the start block 65536. no more error. Write the partition, done
try to run mkfs, and it starts, after about 10 seconds of nothing I get a kernel oops and it never comes back. I can ssh in and see status showing the drive, but fdisk -l shows nothing, There is a kernel crash, and there are a TON of DMA errors…

here is the Terminal output:
root@raspberrypi:/home# mkfs.ext4 /dev/sda1
mke2fs 1.44.5 (15-Dec-2018)
Creating filesystem with 15630336 4k blocks and 3915216 inodes
Filesystem UUID: 2f9b5a62-5ca1-422e-879d-c2449e48b370
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424

Allocating group tables: done
Writing inode tables: done
Creating journal (65536 blocks): done
Writing superblocks and filesystem accounting information:
Message from syslogd@raspberrypi at Jan 23 12:50:17 …
kernel:[ 313.131451] Internal error: Oops: 96000146 [#1] PREEMPT SMP

Message from syslogd@raspberrypi at Jan 23 12:50:17 …
kernel:[ 313.131556] Process scsi_eh_0 (pid: 593, stack limit = 0x00000000253d574b)

Message from syslogd@raspberrypi at Jan 23 12:50:17 …
kernel:[ 313.131870] Code: d1000443 ea03003f 8a230021 54000040 (d50b7e21)

#2

Power supply is not enough, please replace with 18W or above, preferably 30W or above. We are equipped with a power supply of 45W.

1 Like
#3

And powered through the SATA HAT not the Raspberry Pi.

1 Like
#4

Using the 5V 30A rail of a PC supply. No issues with anything dropping due to voltage.
24 hours to run makefs on 1 64G SSD (Brand New) is an issue.
After looking at the logs, it appears to be the issue mentioned here:
https://www.raspberrypi.org/forums/viewtopic.php?t=245931

The USB to SATA chip doesn’t support UAS and has to be set to use “storage quirks” in the cmdline.txt file to get around it… which slows access to somewhere between USB3.0 and USB2.0 speeds…
These are the errors that repeat about every minute…:

[ 501.594683] usbcore: registered new interface driver usb-storage
[ 501.599729] scsi host6: uas
[ 501.599800] usbcore: registered new interface driver uas
…
[ 573.203294] sd 6:0:0:0: [sda] tag#29 uas_eh_abort_handler 0 uas-tag 9 inflight: CMD OUT
[ 573.203302] sd 6:0:0:0: [sda] tag#29 CDB: Write(10) 2a 00 00 4f a0 00 00 04 00 00
[ 573.205063] sd 6:0:0:0: [sda] tag#28 uas_eh_abort_handler 0 uas-tag 10 inflight: CMD OUT
[ 573.205070] sd 6:0:0:0: [sda] tag#28 CDB: Write(10) 2a 00 00 4f a4 00 00 04 00 00
[ 573.208537] sd 6:0:0:0: [sda] tag#27 uas_eh_abort_handler 0 uas-tag 6 inflight: CMD OUT
…
[ 573.269992] scsi host6: uas_eh_device_reset_handler start
[ 573.393710] usb 2-4: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd
[ 573.414256] scsi host6: uas_eh_device_reset_handler success

I will add the storage quirks entry when I get home and give it a try and update.

#5

that was the issue. Once I added the storage-quirks in cmdline.txt, rebooted, the errors are gone and it works… with a USB3 to SATA adapter that didn’t have the quirks I was getting about 330MB/Sec transfers… with the SATA HAT and the quirks on, I get 143…

[ 13.857133] usb 2-1: new SuperSpeed Gen 1 USB device number 2 using xhci_hcd
[ 13.888353] usb 2-1: New USB device found, idVendor=1058, idProduct=0a10, bcdDevice=80.34
[ 13.888368] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=5
[ 13.888381] usb 2-1: Product: Go To Final Lap
[ 13.888394] usb 2-1: SerialNumber: 1234567890123
[ 13.894996] usb 2-1: UAS is blacklisted for this device, using usb-storage instead
[ 13.895095] usb 2-1: UAS is blacklisted for this device, using usb-storage instead
[ 13.895110] usb-storage 2-1:1.0: USB Mass Storage device detected
[ 13.895805] usb-storage 2-1:1.0: Quirks match for vid 1058 pid 0a10: 800000
[ 13.895928] scsi host0: usb-storage 2-1:1.0
[ 14.957497] scsi 0:0:0:0: Direct-Access ACASIS 8034 PQ: 0 ANSI: 6
[ 14.958678] sd 0:0:0:0: [sda] 156301488 512-byte logical blocks: (80.0 GB/74.5 GiB)
[ 14.960723] sd 0:0:0:0: [sda] Write Protect is off
[ 14.960740] sd 0:0:0:0: [sda] Mode Sense: 47 00 10 08
[ 14.967928] sd 0:0:0:0: [sda] No Caching mode page found
[ 14.967943] sd 0:0:0:0: [sda] Assuming drive cache: write through
[ 14.972959] sd 0:0:0:0: Attached scsi generic sg0 type 0
[ 14.977372] sda: sda1
[ 14.980597] sd 0:0:0:0: [sda] Attached SCSI disk

root@raspberrypi:~# hdparm -Tt /dev/sda1

/dev/sda1:
Timing cached reads: 1812 MB in 2.00 seconds = 906.20 MB/sec
Timing buffered disk reads: 448 MB in 3.11 seconds = 143.92 MB/sec

#6

Hi 5ft24,

What kind of hard drive do you have? Please tell me the model number.

#7

I used 3 different SSD drives. Transcend SSD370 64G, Apacer APS25AF7128G 128G, and PNY 69D03700 80G, and a brand new standard 3.5" HD, Seagate Barracuda ST4000DM004 4TB
According to the xHCI driver authors at the raspberry pi site, it isn’t the drive. It is the USB to SATA chip that causes this issue because the chip doesn’t fully support DMA scatter-Gather operations. the USB quirks entry on the Pi forces the xHCI driver to just use mass storage mode instead of true full SATA mode. What I don’t know is if this can be fixed by a firmware update to the USB to SATA chip on the SATA HAT or if it would require a different chip. The issue only occurs on the Pi4B because DMA Scatter-Gather isn’t used in USB2.0 to SATA chips

#8

Crash while creating a file system on each hard drive?

#9

When I tested it, and when I used it every day, I didn’t see the problem.

#10

I was running 64 bit kernel in raspbian. Once I went back to 32 bit kernel, the issue disappeared.

1 Like
#11

Thanks for your feedback.