PowerMac G4 booting from memstick image

[Mark Millard]

On 2021-Apr-19, at 18:42, Brandon Bergren <bdragon at FreeBSD.org> wrote:

>> . . .
>>> On Apr 19, 2021, at 20:46 , Mark Millard <marklmi at yahoo.com> wrote:
>>> 
>>> 
>>> 
>>> On 2021-Apr-19, at 16:34, Mehul Sanghvi <mehul.sanghvi at gmail.com> wrote:
>>> 
>>>> . . .
>>> 
>>>> As I understand it 13.0 handles SMP on the G4 better, and since I have a G$ with 2 CPUs, that would be better anyway.
>>> 
>>> . . .
>>> 
>>> Unfortunately, the FreeBSD 32-bit kernel that covers PowerMacs (G3/G4)
>>> slowly zeros out pages of user processes that it should not touch.
>>> This ends up causing some processes to crash and probably other, less
>>> obvious, issues. It is not a reliable environment. To my knowledge,
>>> this area is not under active development currently but the basic
>>> issue of what type of thing is missing was identified some time back.
>>> (The 64-bit kernel that covers G5s does not have this problem.)
> 
> I still haven't been able to reproduce this on G3/G4, but definitely concur that there is a page zeroing issue when attempting to use the 32 bit kernel on a G5 (which has a different MMU -- the kernel interacts with it via bridge mode compatibility. I've tried several times to figure out what the heck is going on but failed every time.)

A) Build the system with jemalloc's debugging/internal-
   valdiation enabled (world). Running the system that
   results explicitly notices unexpected zeros much
   earlier than the otherwise indirect consequences of
   them do.

B) Just leaving the system operating with background processes
   running but basically idle eventually gets process
   cores from the unexpected zeros. It helps to have a
   machine that can be left that way instead of needing to
   be put to other uses. Time to failure varied.

I've had the problem shown on both types of G4s and the G3,
every non-G5 PowerMac that I currently have access to that
has ever managed to boot FreeBSD. (I've access to one that
never has, despite MacOSX and various Linux boots.)

FYI: My context is still based on:

merge-base: 7381bbee29df959e88ec59866cf2878263e7f3b2
merge-base: CommitDate: 2021-03-12 20:29:42 +0000
7381bbee29df (freebsd/main, freebsd/HEAD, pure-src, main) cam: Run all XPT_ASYNC ccbs in a dedicated thread
n245444 (--first-parent --count for merge-base)

It may be a while before I'd update if such is required
for any testing that I might eventually do.

As I remember, last I tied I still could not run 32-bit
FreeBSD on the G5s that I tried at the time. (Now both
basically dead. For the one of the pair that sort of
works, if things go very well, I can boot before the G5
overheats. Then it might idle for a while.) Now there is
only the 1 core per socket G5 left that can operate for
a sustained time with a load --and it seems to be having
other problems at times.

> By the way, I *FINALLY* figured out what is going on with moused freaking out. It ended up being an oversight in forking that lead to floating point registers getting out of sync.
> My current in-testing patch is http://drop.rtk0.net/fork_rework_3.patch -- will be submitting it soon once I finish my local testing.

Cool.

> This issue actually affects ppc64 as well and has probably been the source of some mystery crashes when forking.

Again cool.

But my lack of mouse connection/use means I've probably not
seen the problem.

>>> There is more, but the above two are fairly major items out of the
>>> overall list.
>>> 
>>> These issues are not unique to 13.0+ as far as I know. Using 12.x
>>> likely would not avoid them.
> 
> IMO 13 is in better shape than 12.x. I am currently dogfooding it on a G4 PowerBook on a daily basis and will be continuing to fix issues here and there that have been cropping up.
> 



===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)