quoted
A clean patch against XFree 4.0 would help to decide if I just missed some
more cache flush magic or if it's a real atydb bug.
I suspect it is the latter as Kevin Puetz has reported a similar problem with
Mach64 on the debian-powerpc list. The server locked the machine in
fbdevHWModeInit(). If you could rebuild libfbdevhw.a with DEBUG defined (in
fbdevhw.c), we might get more valuable information from the log.
Sounds like the very bug I'm chasing. It chokes on the FBIOPUT_VSCREENINFO
ioctl. The mode in question is reported as:
xfree init mode: 64902 1024 1064 1200 1344 768 771 777 806
fbdev init mode: 15407 1024 40 136 144 768 3 6 29 16 0:0:0
with the only thing that seems fishy the 0:0:0 as the res:blue:green
length values.
I'm going to disable the ioctl and see where it barfs after that.
Michael
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Michael Schmitz wrote:
quoted
quoted
A clean patch against XFree 4.0 would help to decide if I just missed some
more cache flush magic or if it's a real atydb bug.
I suspect it is the latter as Kevin Puetz has reported a similar problem with
Mach64 on the debian-powerpc list. The server locked the machine in
fbdevHWModeInit(). If you could rebuild libfbdevhw.a with DEBUG defined (in
fbdevhw.c), we might get more valuable information from the log.
Sounds like the very bug I'm chasing. It chokes on the FBIOPUT_VSCREENINFO
ioctl. The mode in question is reported as:
xfree init mode: 64902 1024 1064 1200 1344 768 771 777 806
fbdev init mode: 15407 1024 40 136 144 768 3 6 29 16 0:0:0
with the only thing that seems fishy the 0:0:0 as the res:blue:green
length values.
If it's for 16 bpp, this might be the problem.
Have you tried with several depths? (15, 8, 24, 32, ???)
Michel
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
quoted
xfree init mode: 64902 1024 1064 1200 1344 768 771 777 806
fbdev init mode: 15407 1024 40 136 144 768 3 6 29 16 0:0:0
with the only thing that seems fishy the 0:0:0 as the res:blue:green
length values.
If it's for 16 bpp, this might be the problem.
Have you tried with several depths? (15, 8, 24, 32, ???)
I've tried 8, 16 and 32 so far; with 32, already X -probeonly fails. Just
tried 24 and it also fails ...
Ignoring (and not fixing) the PCI conflicts gets noticed by the server
and makes probe/start fail. Back to the drawing board.
Michael
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/