Re: patch to get latest XFree 4.0 snapshot (xf3918) to workonppcwithr128

--- Michael Schmitz <schmitz@opal.biophys.uni-duesseldorf.de> wrote:

quoted

quoted

I'll get back to poking around in there as soon as I can figure out how
to see the kernel messages (i.e. how to switch back to the text console
fast enough, or never let the X server switch to VT 7 in the first
place).

A remote machine might be handy...

That's what I'm using already. But the kernel messages that otherwise
appear on the text screen won't get redirected to a remote machine.
Nothing ever ends up in the syslog, anyway. I guess the klogd/syslogd
combo is too slow in this case.

Can't you use kgdb?

quoted

BTW I've just discovered that the fbdev driver sets the weight explicitly
to {0,0,0}... now I'm (really ;) confused.

So was I.

Wonder what the intention and effect(s) are. Alan?

quoted

quoted

I guess it all boils down to PCI messups.

How do you come to this conclusion? Why should it influence ioctls?

Because these ioctls will, ultimately, write to the card again? If the X
server actually messes with the PCI bridges, the card might no longer be
mapped?

Can the X server mess with atyfb's mappings?

I admit that I understand next to nothing about PCI, or how the X server
uses PCI. Makes it a bit harder to spot the flaky code :-)

Same goes for me :-/

Anyway, the X server appears to complete screen init OK but I never
actually get to see the cross hatch pattern.

Not very astonishing without the FBIOPUTSCREEN ioctl, is it?

What _do_ you see if anything?


Michel

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/