Hyperion Entertainment Message Boards

So it looks like this is all in vain. For whatever reason my system is now in a state of wreckage and ruin. Working fine last night. Today it's totally broken.

Booted all my Linux volumes and none are working now. Keep getting SATA errors misclassification errors. Now all it does it keep resetting the link. Did the SMART test and memory test wreck the system? It was working fine before I did all these tests. Ubuntu Xenial booted up but then the desktop went faulty and these SATA errors started appearing in the terminal. Wouldn't even reset itself.

Rebooted to OS4. Edited the drive on MediaToolbox. Perfectly fine, no problems. Reboot to Linux. SATA errors. Shut off. Wait. Turn on. Still SATA errors. CFE fine, OS4 fine. Linux broken. I don't get it. These X1000 machines are too complicated!

Maybe a SATA cable issue or an issue with the coin cell (button cell).

xeno74 wrote: Tue Feb 25, 2025 4:57 am Maybe a SATA cable issue or an issue with the coin cell (button cell).

Well, I opened up the case, blew out some dust and checked connections. Nothing looked amiss but pulled power and data cables then refitted. I've got clipped cables on SATA for a while now to keep it solid. But it is tight for space so using right angled plugs may help. Then I closed it up.

Turned on and suddenly Linux is booting again. Why it only affected Linux I have no idea. My HDD has only OS4 but it too is another SATA device. I've realised that CFE gave no issues because it only looks at unit 0 and 1. The SSD is last unit. Before I checked cables the drive went missing in OS4 as well. But it did act strange in Linux after working again. It kept doing box selection on one desktop. Rebooted and all Linux volumes then started working normally again.

So now the last I've tested is 6.14 RC3. Which is now booting fully. 6.14 RC4 is installed and ready to boot. The only caveat is that the cell errors are still in dmesg. Despite my recent trouble, I still suspect there is some bug in kernel code, causing the missing cell problems. Since I have some kernels that work fine while others have a missing cells crash. I'm trying to understand the connections in the device map causing it. In the meantime I have found when it was introduced and why. According to this the PASemi Nemo device tree should be compliant but my tree is not!

https://gbmc.googlesource.com/linux/+/0 ... 3e8%5E%21/

Hypex wrote: Tue Feb 25, 2025 1:24 pm https://gbmc.googlesource.com/linux/+/0 ... 3e8%5E%21/

Interesting. Thanks for posting it.

Maybe we should add our Nemo board to the excluded list.

Or maybe add the missing properties to the device tree during the boot. (fixup_device_tree_pasemi();)

You could report this to Michael Ellerman and to Rob Herring if you like.

Alternative download link for the RC4: linux-image-6.14.0-rc4-X1000_e5500.tar.gz (xenosoft.de)



Please test the kernels.

xeno74 wrote: Tue Feb 25, 2025 2:50 pm You could report this to Michael Ellerman and to Rob Herring if you like.

I was thinking about this. But as I'm the only known one who currently has the issue I wanted to make sure it wasn't some fault caused by my system. I've raised issues in the past (on OS4) and found I was only one who had some issue, because I had an apparent rare hardware combination that caused it, which no one else had so it couldn't be tested and confirmed.

So, I need to track down more info, such as what kernel release it first occurred and what kernel you had compiled to correlate with it. And, I expect to submit a device tree, with what cell sizes it should have. After looking it up I've found other people, such as those working for Samsung, also faced the same issue. The code gives a warning, but it ends up worse, since it technically causes a crash. It's not a kernel panic, and recovers, but it's clearly some kind of core dump in the log.

In the meantime, I've booted and tested 6.14 RC4. On both an Ubuntu Mate install and my new Fresh Fienix. Worked fine in use. I finally created a new Fienix volume for testing using the live image. Unfortunately, Disks utility doesn't support GZ images, only XZ. Which I find strange as GZ is in more common use, so would have been convenient to use as direct image file. So I had to jump through hoops unpacking the live image to a partition, because on all my Ubuntu's I kept getting errors unpacking the image to a folder. I ended up downloading it again on my laptop, unpacking to a USB HDD, then imaging that file (more slowly) to a partition back on the X1000. I suspect it's a 64-bit GZ error as the file came up as 3GB, but it's double that. Even on my laptop (with Mint) the GZ unpack size is still wrong, even though it works, so it looks like an old issue they still haven't fixed on recent x64 builds of the Archive Manager.

Hypex wrote: Wed Feb 26, 2025 2:00 pm I was thinking about this. But as I'm the only known one who currently has the issue I wanted to make sure it wasn't some fault caused by my system.

I'll look if my X1000 has the same output with the missing dtb properties on boot up.

Hypex wrote: Wed Feb 26, 2025 2:00 pm In the meantime, I've booted and tested 6.14 RC4. On both an Ubuntu Mate install and my new Fresh Fienix. Worked fine in use.

Great! Thank you very much for testing the RC4.

Hi
I have testet debian 64 with vmlinux-6.14_rc4 and boot is ok

By the way, my x1000 also has the same output with missing dtb properties

Have a nice day

musa wrote: Thu Feb 27, 2025 9:28 am Hi
I have testet debian 64 with vmlinux-6.14_rc4 and boot is ok

By the way, my x1000 also has the same output with missing dtb properties

Have a nice day

Thanks a lot for testing!

@Hypex
I don't have really much knowledge about patching the dtb during the boot.

Maybe this can help but I am not sure if it is correct:
What do you think?

Hi All,

I created a patch because of the missing properties today.

After that, I compiled a new RC4 with this patch.

Download: v6.14.0-rc4-2

Please test this kernel.

If it boots then please post the output of dtc -I dtb /sys/firmware/fdt.

Thanks,
Christian