I found some mention of this in messages from this list, but not a
complete patch. I changed ppc_icache_flush to only flush one cache line
(removed the add 32 to r3; repeat flush stuff) and applied the patch to
the loader I found on the list. That results in no more sig4 or sig11
during module loads but I still get the Lombard to lock up during real
server startup. The screen base and size used to map the video memory is
OK (i.e. taken from the kernel atyfb driver, right aperture and all) but
it hangs after that. I'll keep digging.
.....
quoted
Try the fbdev driver with the BusID. (Mach is only minimally accelerated ATM
anyway)
Adding the BusID results in the PCI warnings, no change otherwise. The
server never uses fb_open_pci anyways.
Without the BusID line the XServer will disable the pci memory/io
for the card, it doesn't matter if fbdev_open_pci is used or not.
What probably happens is that even with the BusID defined the xserver
still disables your card.
The PCI warnings that you get most likely will tell us where the problem
is, can you send the logfile over ?
Kostas
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michael Schmitz <hidden> Date: 2000-03-13 13:05:19
Without the BusID line the XServer will disable the pci memory/io
for the card, it doesn't matter if fbdev_open_pci is used or not.
What probably happens is that even with the BusID defined the xserver
still disables your card.
We'll see if that's a problem; right now it hangs earlier.
The PCI warnings that you get most likely will tell us where the problem
is, can you send the logfile over ?
Relevant log excerpt:
(II) Loading /usr/X11R6/lib/modules/linux/libfbdevhw.a
(II) Module fbdevhw: vendor="The XFree86 Project"
compiled for 4.0, module version = 0.0.1
(II) FBDev(1): using default device
(**) FBDev(1): claimed PCI slot 0:17:0
(WW) ****INVALID MEM ALLOCATION**** b: 0x81000000 e: 0x81ffffff correcting
own
[0] -1 0x81fff000 - 0x81ffffff (0x1000) MXB
[1] -1 0x00000c00 - 0x00000cff (0x100) IXB
(WW) ****INVALID IO ALLOCATION**** b: 0xc00 e: 0xcff correcting
(**) FBDev(0): Depth 16, (--) framebuffer bpp 16
(==) FBDev(0): RGB weight 565
(==) FBDev(0): Default visual is TrueColor
(==) FBDev(0): Using gamma correction (1.0, 1.0, 1.0)
(II) FBDev(0): Hardware: ATY Mach64 (vidmem: 8184k)
Michael
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Without the BusID line the XServer will disable the pci memory/io
for the card, it doesn't matter if fbdev_open_pci is used or not.
What probably happens is that even with the BusID defined the xserver
still disables your card.
We'll see if that's a problem; right now it hangs earlier.
Earlier than what ? The Xserver does its pci magic (badly in this
case it seems) very early, by the time you reach fbdevHWModeInit
its already done.
quoted
The PCI warnings that you get most likely will tell us where the problem
is, can you send the logfile over ?
Relevant log excerpt:
(II) Loading /usr/X11R6/lib/modules/linux/libfbdevhw.a
(II) Module fbdevhw: vendor="The XFree86 Project"
compiled for 4.0, module version = 0.0.1
(II) FBDev(1): using default device
(**) FBDev(1): claimed PCI slot 0:17:0
(WW) ****INVALID MEM ALLOCATION**** b: 0x81000000 e: 0x81ffffff correcting
own
[0] -1 0x81fff000 - 0x81ffffff (0x1000) MXB
[1] -1 0x00000c00 - 0x00000cff (0x100) IXB
(WW) ****INVALID IO ALLOCATION**** b: 0xc00 e: 0xcff correcting
Here is the problem, for some reason the xserver doesn't like
the pci mem/io mappings for the card and "corrects" them :(
Kostas
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michael Schmitz <hidden> Date: 2000-03-13 17:02:42
quoted
We'll see if that's a problem; right now it hangs earlier.
Earlier than what ? The Xserver does its pci magic (badly in this
case it seems) very early, by the time you reach fbdevHWModeInit
its already done.
Earlier than screen init. fbScreenInit is what I get stuck at after
bypassing the ioctl.
quoted
quoted
The PCI warnings that you get most likely will tell us where the problem
is, can you send the logfile over ?
Relevant log excerpt:
(II) Loading /usr/X11R6/lib/modules/linux/libfbdevhw.a
(II) Module fbdevhw: vendor="The XFree86 Project"
compiled for 4.0, module version = 0.0.1
(II) FBDev(1): using default device
(**) FBDev(1): claimed PCI slot 0:17:0
(WW) ****INVALID MEM ALLOCATION**** b: 0x81000000 e: 0x81ffffff correcting
own
[0] -1 0x81fff000 - 0x81ffffff (0x1000) MXB
[1] -1 0x00000c00 - 0x00000cff (0x100) IXB
(WW) ****INVALID IO ALLOCATION**** b: 0xc00 e: 0xcff correcting
Here is the problem, for some reason the xserver doesn't like
the pci mem/io mappings for the card and "corrects" them :(
The PCI mappings should not prevent the fb ioctls from working. Anyway I
can try to mess with the code to leave the mapping untouched.
There's a lot more going on: in 32 bit mode the X server complains about
invalid weight (000) and refuses to probe OK. In 16 bit mode some part of
the server assumes 565 bit weighting but the kernel code only ever sees
000. I'm a bit confused here. In 8 bit mode, I get the X server to print a
message like:
fbdev trace: FBDevScreenInit: before screeninit8/16/32
fbdevHW: fbScreenInit: before fbSetupScreen < my trace message
This should not happen!
An unresolved function was called!
That's in programs/Xserver/fb/fbscreen.c. fbSetupScreen ought to print
another message on entry but that never happens. fbSetupScreen is defined
in the very same source file. Funny.
Michael
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michel D�nzer <hidden> Date: 2000-03-14 10:58:18
Michael Schmitz wrote:
There's a lot more going on: in 32 bit mode the X server complains about
invalid weight (000) and refuses to probe OK. In 16 bit mode some part of
the server assumes 565 bit weighting but the kernel code only ever sees
000.
I don't know for sure, but I guess the fbdev driver gets the weight from
atyfb? That would strongly point to a bug there.
I'm a bit confused here. In 8 bit mode, I get the X server to print a
message like:
fbdev trace: FBDevScreenInit: before screeninit8/16/32
fbdevHW: fbScreenInit: before fbSetupScreen < my trace message
This should not happen!
An unresolved function was called!
That's in programs/Xserver/fb/fbscreen.c. fbSetupScreen ought to print
another message on entry but that never happens. fbSetupScreen is defined
in the very same source file. Funny.
Indeed... Looks like fbSetupScreen is the unresolved function, or is there an
earlier warning about unresolved symbols?
Michel
--
Columbus had a fourth ship. It sailed over the edge.
______________________________________________________________________________
Michel Dänzer /// mdaenzer@earthling.net
__ /// AmigaOS/Linux(Debian/PPC)
Student of computer science at the \\\/// Team *AMIGA* ICQ #: 5675698
Swiss Federal Institute of Technology \\\/ AUGS member #163 IRC: CoOpER
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/