Unfortunately not much information is provided and likely root causes are not discussed. Nevertheless, installation of the 32-bit release is recommended for devices which have been marked as “32-bit Only” in their certified models list.
Hoping this post is remembered by the developers if/when graphics issues arise later in the path toward R1/R2.
My intent was to leave a note if someone in the near future encounters an issue with graphics in Haiku 32-bit on a system with a 6th Generation (or later) Intel CPU while that issue is not encountered in Haiku 64-bit.
The only detail from the situation with CloudReady is that the issue with the 32-bit built appears encountered only on systems with integrated graphics. Systems with discrete graphics do not appear to be affected.
While I know 32 bit x86 is getting long in the tooth, I wouldn’t like to see support disappear yet. My favourite haiku machine is a thinkpad x31: It’s portable, built like a tank, and with 2GB of RAM, a supported wifi card and an SSD it is capable enough, and most importantly it has radeon graphics that supports dual monitors under haiku. With dual monitor support, in some sense it has better driver support than any other haiku machine I own, so I hope that we don’t see 32 bit disappear form haiku before other machines gain similar driver (and hopefully appserver, eventually) functionality.
Without any extra information I would assume a bug in Linux drivers, not in the hardware. In the case of Haiku, we use PAE already and our kernel has no problem managing 64bit addresses for things like DMA and other hardware access. So I don’t see anything that could prevent the graphics card to work in 32bit mode (the graphics card does not care what mode the CPU currently is in - that would make no sense).
So, probably nothing to worry about for us. Let’s rather focus on UEFI boot support, for BIOS may actually disappear long before 32bit support in CPUs.