Subject: Xmacppc fun.
To: None <port-macppc@netbsd.org>
From: gabriel rosenkoetter <gr@eclipsed.net>
List: port-macppc
Date: 08/26/2001 19:30:37
So, in hopes of tracking this palette bug down, I've been doing my
damndest to get a crash dump of it. Removing DDB options from the
kernel entirely just causes the machine to reboot (still without
making any kind of crash dump on its own, which I'm not even clear
it necessarily should be doing; is this actually a kernel panic or
not?) when the error crops up. So I added option TRAP_PANICWAIT back
in since it's entirely undocumented and sounds interesting. While I
was there, I decided to go ahead and build with debugging symbols
in. And, for the hell of it, to boot of the unstripped kernel
afterwards.

Lo and behold, I now have a macppc machine that functions just fine
as an 8bit Xserver. I can ssh over here to my i386 machine and run
massively graphical applications with nary a hitch (well, the fact
that I'm X forwarding a web browser and the gimp over the 6500's
10BaseT is kind of sluggish, but whatever). It even reverses the
palette of the outside world when it runs into a program that
insists its own (I used pkgsrc/games/rollemup as a sample, but
anything should work).

So, I'm puzzled by a few things:

1. Why should changing the presence of debugging symbols in the
kernel make the X server (entirely a separate block of code, not
recompiled at all) behave differently?

2. Accepting that the hang up has been in the kernel's dealing with
the video driver all along rather than actually in Xmacppc's color
map code, why should the mere addition of debugging symbols change
things?

3. Would I be sane to suggest that this sounds like an optimization
problem with gcc for PowerPC?

4. ... or is it far more likely that the bug is still there but much
more difficult to tickle due to slight timing or memory address
differences by having the kernel include some extra bloat?

Any suggestions welcomed.

As tempting as it is to just recompile kernels with debugging
symbols on macppc machines whose consoles I plan to use, I don't
think I will. Rather, I'll go back to a kernel I know crashes,
switch the console over to being ttya, and dig a laptop out to get
access to ddb.

-- 
       ~ g r @ eclipsed.net