HDMI corruption on NVMe write in Ubuntu & 5.7 kernel

I have a VIM3 with a Gigabyte NVMe SSD:

khadas@khadas:~$ lspci
00:00.0 PCI bridge: Synopsys, Inc. DWC_usb3 / PCIe bridge (rev 01)
01:00.0 Non-Volatile memory controller: Phison Electronics Corporation Device 5013 (rev 01)
khadas@khadas:~$ fdisk -l /dev/nvme0n1
Disk /dev/nvme0n1: 119.25 GiB, 128035676160 bytes, 250069680 sectors
Disk model: GIGABYTE GP-GSM2NE3128GNTD

I am running VIM3_Ubuntu-server-focal_Linux-5.7-rc7_arm64_SD-USB_V0.9-20200530.7z, booted from an SD Card and updated to 5.7.0 via apt. I have erased the eMMC to get this working reliably, after suffering an issue of USB keyboard not working.

The SSD appears to work, however when I write data to the SSD, there is transient corruption of the HDMI display output on the text console. The display returns to normal as soon as the write activity ceases. Read activity does not cause the same problem (i.e. the display remains uncorrupted).

Any significant write activity causes this, but to give a concrete test case:
dd if=/dev/zero of=/mnt/test bs=1048576 count=1024
(where /dev/nvme0n1p1 is mounted on /mnt with a BTRFS filesystem).

(As I’m running the server image, I haven’t tried this on a GUI. I don’t know if the same display issues occur at other HDMI resolutions. As it happens, this won’t be a showstopper for me as the VIM3 will run headless, but I thought I should report the issue for other users benefit).

1 Like

I’m not sure why SSD will effect the HDMI display? Can you take a video of this?

@Motacilla There are a lot of problems with the images made on 20200530 due to a bug in the rootfs partition, and a lot of people have faced the same problem as you did…
you can try a newer build of the mainline image, where this problem has been eradicated…

You can download a recent build form here…
Ubuntu Kernel 5.7 Firmware package

@numbqq I kindly request you to please update the images on the Khadas website, the bug has been patched but the Firmware containing the bug is still cause menace till date, Thank you

Could you tell me what is the bug?

You can use apt update && apt upgrade .... to upgrade to the latest system.

I can’t recollect exactly where the first trace of it was seen, but I remember you pointed it out for me and said, it was related to the rootfs partition or something, and immediately the next day the bug was gone…

Maybe going through the patches of that day might help finding it ?

Update:
This same person had that problem…

You can download a recent build form here…
Ubuntu Kernel 5.7 Firmware package

Thanks, but I get 404 for that URL. I can’t see a “suites” folder under github.com/ZephyrLabs/fenix/ at all. Possibly a permissions problem?

Oh, I am sorry, It seems to permit people only if they have a Github account, and are logged in…
Do you have one ? or shall I upload to cloud for you to download ?

@Motacilla you can also get the file here…
Ubuntu 5.7 Linux firmware

OK, thanks. I’ve logged into github and it’s now downloading. It will be a few hours or tomorrow before I have time to test it I’m afraid, I’ll try to let you know as soon as I can.

1 Like

Ok, please take your time to test and tell us the results of this firmware…

Good day!

I reported the same issue here:

I did not find this problem to be kernel-specific, however my board ceased working soon after reporting this issue, ending a few weeks of unreliability and stress with the VIM3L. Note that I’ve still not been contacted or advised about RMA.

@mzb69 I realised we never asked you about the firmware and kernel version you were using…
I can provide you a Up-to date image, are you willing to run it ?

@mzb69 please try these Images, and tell me if it works…
VIM3L_Ubuntu-server-focal_Linux-4.9_arm64_EMMC_V0.9.3-200827

VIM3L_Ubuntu-server-focal_Linux-5.9-rc2_arm64_SD-USB_V0.9.3-200827.img

*please note you need to login to github to be able to download these images, Thank you
also the mainline kernel has been updated from 5.7 to 5.9…

I’ve now tried the image you kindly supplied yesterday. Unfortunately, the HDMI corruption issue still exists.

See https://imgur.com/a/8mWGJ9b for a video of the issue.

Edit: I should add – the display is absolutely stable when there is no SSD write activity. I suspect that the second burst of corruption after the command completes is when OS buffers are flushed to the disk… actually, I can confirm that by adding conv=fsync to the dd command.

i think its power supply problem!!!
plz show power requirement for your ssd
some ssd nvme - need 10W some only 5-7W + sure your VIM device need something :wink: and sometime its not enough

my recommendation to use ssd from WD blue series which have low power consumption

1 Like

as @hyphop said, it is highly suspected to be a power issue…
but other than that, is your keyboard and mouse stable ?

i have same issues but in my situation - its was full reset when i try read data in maximal speed from NVME - but this problem disappear on another nvme WD blue series

its same problem for VIM and Edge - need good power supply :wink:

Interesting theory… I’m powering the device via a Anker 30W USB-C PD charger and a Nimaso cable that’s rated for 60W. Swapping that for my Dell laptop USB-C PD PSU (rated for 130W), the issue still occurs. If it is power, then I suspect the issue is on the VIM3 not with the PSU.

That said, the drive specification says:
Power Consumption (Active) Avg. read : 2.2W ; Write : 1.7W

…which does lead me to wonder why I see the issue on write, but not read. (I can confirm this with an 8GB file, much larger than RAM, so definitely coming from disk).

Yes, thanks. The USB issue is resolved at least.

1 Like

That is good to hear…

But regarding the SSD, That is kind of a mixed thing as you have to think of it from an electrical engineering standpoint…

for example…
The VIM3 only sips about 4.5-5W of power in Normal usage… but it won’t boot unless you give it 10W bare minimum…

so you have to be able to provide more that it takes…
also don’t forget to take into account that it creates a huge spike in current when starting up or doing tasks…

But you provide more than ample power to the device… perhaps, if you tried to give power via the VIN port, maybe you could ease the power draw ?
as I think there are limitations to the physical device and how much power it is able to draw maximum…