Is there some serious astroturfing going on with the N100/N150, or am I just jaded?

I have a bunch of old intel atom boards laying around. The Intel Compute Stick (TM) burnt out its flash root drive in a few months. The C2000 board I had burnt out the clock pin to drive the bios. I have a Clover Trail with a PowerVR GPU (I thought I was getting an intel GPU because it was branded Intel Graphics or similar, but nope!) that lost Windows support very quickly after launch, and has no GPU drivers for any other OS.

Instead of being fooled 4 times in a row, I looked into using an N150 for a NAS, but this time I held off a bit until after launch so I could research it first.

Lo-and-behold, they all have crazy PCIe / memory subsystem data corruption issues. I guess there are some chicken bits for the OS developers to set if the kernel can stay up long enough after boot without a panic.

Why would anyone buy this for a NAS / embedded use case?

▲

tredre3 2 hours ago | parent | next [-]

> I looked into using an N150 for a NAS [...] Lo-and-behold, they all have crazy PCIe / memory subsystem data corruption issues.

Source? I've never had a single problem with PCIE on N100/N150/N200.

I have had a ton of issues with drive corruption on the pi, both via USB3 and PCIE.

▲

hedora an hour ago | parent [-]

https://www.phoronix.com/news/Linux-6.4-Lands-PCID-INVLPG

https://forum.opnsense.org/index.php?topic=48343.0

	▲	adrian_b 32 minutes ago \| parent \| next [-]
		All CPUs from all vendors have tons of bugs like this, which are mitigated in the operating system kernels, e.g. in the Linux kernel. I am pretty certain that the Linux kernel must also contain specific code for various quirks of all Arm CPUs that have been used in the various Raspberry Pi models. Intel had indeed several bugs that were more ugly than usual in their recent CPU models, like also MONITOR not working correctly in Lunar Lake, but even so, Intel still has better documentation for their CPU bugs than most vendors of Arm-based CPUs. In any case, the bug that you linked was solved in the kernel years ago and it affects a privileged instruction that cannot be used in user programs. It does not have any direct relationship with memory and PCIe corruption. Memory corruption can occur inside the operating kernel only in certain circumstances, when the kernel changes the mapping of global memory pages and then writes the new pages, but the writes go to the old pages. However, this could happen only until 3 years ago, before the bug was known.
	▲	kllrnohj 23 minutes ago \| parent \| prev [-]
		so a single 3 year old errata for the n100 that was long since patched?

▲

utternerd an hour ago | parent | prev [-]

I've been running an N100 for 3 years with a 5 bay external enclosure over USB 3.2 Gen 2 and ZFS, and have not had any issues. It is pretty phenomenal, pulls about the same power, and costs around the same as an RPi 5 but provides substantially more compute and throughput.