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

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

[Michael Schmitz]

> > 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/

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

[Michel Dänzer]

Michael Schmitz wrote:
>
> > > 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/

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

[Michael Schmitz]

> > 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/

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

[Michael Schmitz]

> > 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.

> > > 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/

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

[Michel Dänzer]

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/

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

[Michael Schmitz]

> > Do you use BackingStore? If yes, can you try leaving it off?
>
> Nope, and that's not where it hangs anyway. I just didn't get all of the
> server output in that case (fflush (stderr) isn't sufficient).
> Now I can't get beyond xf86HandleColormaps(). Another ioctl that barfs on
> me, perhaps. I guess it all boils down to PCI messups.

After bypassing xf86HandleColormaps()  get all the way through the screen
init (including FBDevRefreshArea calls that appear to be writing to video
memory without choking), only to hang a couple of seconds after. I'll dig
into the kernel ioctl problems now - there will be the cause of the
colormap failures as well.

	Michael


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

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

[Michel Danzer]

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

> > > Possibly; I've also seen the X server convert XFree mode lines into
> > > fbdev timings, thereby overwriting the 565 with 000. Doesn't hurt for
16
> > > bits, only for 32 bits.
> >
> > Doesn't hurt for probing, but maybe for the ioctl?
>
> The ioctl has been disabled long time ago.

I meant when you hadn't disabled it. It hung there at the time, right? Now a
hang in an ioctl is a kernel bug, or am I missing something?


> 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...


> Now I can't get beyond xf86HandleColormaps(). Another ioctl that barfs on
> me, perhaps.

Well possible, FBIOPUTCMAP in fbdevHWLoadPalette.

I don't understand the code there...

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


> I guess it all boils down to PCI messups.

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


Michel

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

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

[Michael Schmitz]

> > > Doesn't hurt for probing, but maybe for the ioctl?
> >
> > The ioctl has been disabled long time ago.
>
> I meant when you hadn't disabled it. It hung there at the time, right? Now a
> hang in an ioctl is a kernel bug, or am I missing something?

No, you're right :-)

> > 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.

> > Now I can't get beyond xf86HandleColormaps(). Another ioctl that barfs on
> > me, perhaps.
>
> Well possible, FBIOPUTCMAP in fbdevHWLoadPalette.

Probably. I'll have to trace all these ioctls as soon as I can keep the X
server from switching consoles.

> I don't understand the code there...

The cmap only passes the pointers to the color values. fb_set_cmap does
get_user on those so it should be OK. Don't ask me why X sets each entry
separately though (on some braindead Mac video cards this means you have
to start setting the cmap from entry 0 until you hit the right one, each
time).

> 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.

> > 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?
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 :-)

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

	Michael


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

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

[Kostas Gewrgiou]

On Wed, 15 Mar 2000, Michael Schmitz wrote:

>
> > > 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?
> 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 :-)
>
> Anyway, the X server appears to complete screen init OK but I never
> actually get to see the cross hatch pattern.


  The X server has played with the cards mappings, since it believed the
old ones were wrong. atyfb will still try to access the card in the old
location and thats what gives you the hard locks.

  The question is why the X server doesn't like the old mappings ?
If you can send me the /var/log/XFree86.0.log and lspci output i'll
forward it in the xfree devel list and see what answers we can get from
there.

  Kostas


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

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

[Michel Danzer]

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

> > > 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?


> > 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?


> > > 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/

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

[Michael Schmitz]

> > > Weird. Are you sure the `81fff000' is not caused by some fixup routine
> > > that changed the unassigned `fffff000' into `81fff000'?
> >
> > What part of the kernel would do that kind of fixup?
>
> *_fixup in arch/ppc/kernel/*_pci.c

The only function in pmac_pci.c does no such thing. Next question: how
would I modify the bus mappings from aty_init?

	Michael


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