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).
@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…
@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
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 ?
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 ?
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.
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 ?
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 and sometime its not enough
my recommendation to use ssd from WD blue series which have low power consumption
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
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).
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…
and sometime its not enough