DeskPi Pro bad SATA controller?

Equipment, Tools & Supplies
, ,
21

Hi @tcbetka

Thanks again for your suggestions.

I would have to put the SSD back into the case and wait for a crash to be able to inspect the kernel logs. I might just try that if things get desperate.

The ASMedia Technology ASM1051E SATA 6Gb/s bridge that is detected using lsusb is with the SSD connected externally with the StarTech SATA to USB3 adapter. It ought to be easy for me to do a shutdown, disconnect the external SSD, reboot from a microSD card and run lsusb again to see the identity of the internal chipset. Perhaps that internal chipset is what is being identified as:

Bus 003 Device 003: ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter

Just for the sake of completeness, the SSD is a Kingston A400 120GB (SA400S37/120G) which is one that I have seen recommended in this rather useful guide:

I have a busy work day tomorrow and will report back when I can find the time.

22

LOL… Well, we certainly can’t help you debug a problem in a given system, when you’re not actually using said system.

If you’re interested in pursuing this issue further, in terms of why things lock up when your Pi is in the DeskPi case (along with that SSD), then you’ll have to put it back into the configuration that it was in when you experienced the problem. Then we can figure it out from there.

TB

23

The SSD is now back in the DeskPi Pro case. I now just need to wait until it crashes to see what dmesg might reveal.

lsusb reveals that the SATA chipset that’s fitted to the the case is:

ASMedia Technology Inc. ASM1153 SATA 3Gb/s bridge

24

That’s the (allegedly) good SATA/USB controller. It’s the JMicron unit that people have complained about, from what I saw in the forums while researching my issue.

Yeah, I think you’re sort of stuck until it freezes up again. Problem is (like you said), if it’s entirely frozen you won’t be able to access the thing to run dmesg. However you should still be able to have a look at the various logs to see if there was a hint of an issue right before it froze up.

TB

25

i have olso problems with usb and hdmi
but on the deskpi site ,there is a solution
they will resent a new pcb board
i hope that we olso get the new board

this is the message

The new updated PCB Boards fixes following problems:

  1. The problem with USB booting — identifying SSDs
  2. WiFi interference issues
  3. HDMI display problem
  4. Compatibility issues of Wireless key & mouse

Resent List:

  1. USB adapter
  2. Daughter Board
  3. T-shaped isolation foam
  4. U-shaped support frame

Please kindly keep patience, you will receive your new PCB Boards soon

i hope digi-key is helping us with this

26

Update on my experience:

Previously, my Pi would crash once or twice a day with the white disk-activity light flashing furiously when installed in the DeskPi Pro case. I have also posted my experience (also as leicray) on another forum hoping for guidance from there too: DeskPi GitHub site It might be useful to read through that thread to understand the sequence of events and to see the experiences of other users.

The best advice on this forum was to keep trying with the Pi in the DeskPi Pro case and wait for a crash and then take a look at the contents of the kernel log just before the crash: /var/log/kern.log in the hope that might reveal something useful.

Before we get to that, it took nearly three days this time before it crashed again. Luckily, I had a a terminal window open on the desktop this time. However, some commands worked within the terminal, but others did not. For example I was able to cat the contents of kern.log but could not save it, as nano would not load and redirecting to output from cat to a file would not work either.

At this point, I could not connect to the pi using ssh or VNC. In addition, the desktop was frozen apart from the open terminal. It’s probably best to say that the pi was only just alive at this point.

The content of kern.log shortly before the “crash” is:

pi@raspberrypi:~ $ uptime
13:12:00 up 2 days, 21:16, 2 users, load average: 13.02, 10.45, 9.56
pi@raspberrypi:~ $ cat /var/log/kern.log
May 3 11:46:09 raspberrypi kernel: [244220.207312] xhci_hcd 0000:01:00.0: WARN Cannot submit Set TR Deq Ptr
May 3 11:46:09 raspberrypi kernel: [244220.207325] xhci_hcd 0000:01:00.0: A Set TR Deq Ptr command is pending.
May 3 11:46:09 raspberrypi kernel: [244220.358262] usb 2-1: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd
pi@raspberrypi:~

There are ten virtual bonus points on offer for anybody who can guess how I did capture the content of kern.log and it was not by copying manually from the screen to a plain text file.

The good news is that the UK supplier (PiHut) has issued an RMA number and provided a pre-paid return label. In an ideal world, I would like to have a working case, but there is clearly something very wrong even with the revised board.

Any additional comments or encouragement would be most gratefully accepted.

2 Likes
27

today i called with support service in holland and they told me that we do not get the new pcb boad
if we want the new board than we have to call deskpi
this is not oke
if someone else has a better reaction from the support.service than i like to know

28

That’s not how support for a defective item is supposed to work in EU countries. If it’s exactly like the situation in the UK, your statutory consumer rights are against the retailer – the company that sold you the product – not the manufacturer. If the item is found to be defective within 30 days of purchase, your are entitled to a replacement or a refund from the retailer. I would caution against a replacement at present as evidence is mounting that the revised board still does not work as intended. I suggest that you take a look at the support forum on GitHub:

https://github.com/DeskPi-Team/deskpi/issues/38

29

i did thanks for youre answer