Re: Xfree86-4.0.1, Lombard, Mach64 driver, X-server Crash

Re: Xfree86-4.0.1, Lombard, Mach64 driver, X-server Crash

[Jon Erick Ween]

Benjamin Herrenschmidt <bh40@calva.net> wrote:
>>Here's a copy of my XF86Config file.
>>
>>Two other minor nuisances:
>>
>>Since using yaboot, my console cursor has disappeared. Is this an OF or a

>>yaboot problem? It's very hard to navigate in vi to edit anything
(.config
>>files for one thing) without a cursor!
>
>Completely ? Or does it appear with different colors depending on the VC
>you are on ? I've seen such bug appear here or there but never took the
>time to track it down...

No colors, no blinking no nothing, just blackness,- apart from the text
that prints out nicely. So, as long as you don't have to go back and insert
(in an editor, eg) things work OK. But, to edit a Config file to get it
back, I don't know exactly what to do. All this is in an attempt to get
XF86-4 to work, so I don't have a GUI "fall-back" ;->


>I suspect an atyfb problem ;)

I had no problem with my 2.2.17 kernel build booting from BootX. atyfb is
generic, right?

>
>>Also, I can't figure out how to uninstall BootX. Throwing it away under
>>MacOS doesn't seem to help.
>
>Remove the bootx extension that is in your MacOS Extensions folder. it
>should appear near the top of the list when vieweing them by name.
>
>Ben.
>


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

Re: Xfree86-4.0.1, Lombard, Mach64 driver, X-server Crash

[Jon Erick Ween]

Michael Schmitz <schmitz@mail.biophys.uni-duesseldorf.de> wrote:
>> I tried the changes you suggested, no difference. (I couldn't figure out

>> what you meant by "layout at the end.", was there more to the email that

>> didn't get through?)
>
>I meant move the first section (server layout IIRC) to the end of the
>file. Nothing complicated.

OK, I'll try this.

>> But, honestly, I can't see why these changes should influence whether or
not
>> the Xserver detects the video device. That seems to be the main problem.

>> It's looking for a particular device at a particular memory address
>> (presumably specified by the "ati" driver file) and is not finding it. I

>
>Neither do I, and it works perfectly for me ...
>
>I can send you my config if nothing else helps.

Well, I recompiled the server and reinstalled. Now it doesn't exit with an
error, it just hangs, requiring a hard reboot. Looking at the XFree86.0.log
file it seems to be hanging on the ati probe step, suggesting that it finds
the device finally. Previous lines inform of reassigning pci memory
overlaps, but there are no errors. Maybe if I tried your config file and
modified for my ati driver?

Jon


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

Xfree86-4.0.1, Lombard, Mach64 driver, X-server Crash

[Jon Erick Ween]

>> Can anyone tell me if there are any problems with overlapping memory
>> assignments for the ATY Mach64 chip on a Lombard PB? I'm having trouble
>> getting my 4.0.1 Xserver to detect the device although the system seems to
>> detect the chip alright at bootup. I've been through the Xpert list at
>> XFree86 and we've groud to a halt.

>With a 2.2 kernel:
>You need to use yaboot, or fix up the overlapping PCI resources allocated
>by OF or MacOS yourself when using BootX. I've posted a diff to
>debian-powerpc that  remaps the MMIO region outside the VRAM region,
>without any sanity checks to make sure that region hadn't been mapped
>previously. It's a hack, and won't ever make it into the official kernel.
>
>With 2.3:
>Use Geert's PCI resource allocation patch, posted here a couple of months
>back. Might be in 2.4.0pre already. Or, again, use yaboot.

>BTW: in my case, the X server had no problem _detecting_ the chip, but
>helpfully removed the PCI mapping for the VRAM region. The resulting
>invalid access to MMIO registers aliased at the end of the VRAM region
>(that's where atyfb puts them) crashed the kernel hard. If you get away
>without a kernel crash, your problem might be different. Using yaboot
>instead of BootX is a good idea nonetheless.

OK, I've switched from BootX to Yboot using a stable 2.2.17 kernel and the
most recent XF86-4.0.1 and ati driver sources I can find. I seem to get
different PCI assignments to the ATI chip on boot-up (looking at dmesg
compared with using BootX) but the X-server still doesn't detect the chip
with "startx" or "XFree86" and exits with a "device not found" and "no
screens" error. Any further suggestions?

Thanks

Jon

--
Jon Erik Ween, MD

Cognitive and Cerebrovascular Neurology

Assistant Professor
Loma Linda University School of Medicine

Director, Stroke Program
Loma Linda University Medical Center


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

Re: Xfree86-4.0.1, Lombard, Mach64 driver, X-server Crash

[Olaf Hering]

On Wed, Sep 27, Jon Erick Ween wrote:

> OK, I've switched from BootX to Yboot using a stable 2.2.17 kernel and the
> most recent XF86-4.0.1 and ati driver sources I can find. I seem to get
> different PCI assignments to the ATI chip on boot-up (looking at dmesg
> compared with using BootX) but the X-server still doesn't detect the chip
> with "startx" or "XFree86" and exits with a "device not found" and "no
> screens" error. Any further suggestions?

There is a Modes line in the screen section, use a generic mode.
Don't specify a Modes section.

It could look like that:

Section "Screen"
  DefaultDepth  24
  SubSection "Display"
    Depth       24
    Modes       "1024x768"
  EndSubSection
  Device        "Device[0]"
  Identifier    "Screen[0]"
  Monitor       "Monitor[0]"
EndSection
Section "Device"
  BoardName     "mycard"
  BusID         "0:16:0"
  Driver        "ati"
  Identifier    "Device[0]"
  Option        "sw_cursor"
  VendorName    "ATI"
EndSection


Gruss Olaf

--
 $ man clone

BUGS
       Main feature not yet implemented...

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

Re: Xfree86-4.0.1, Lombard, Mach64 driver, X-server Crash

[Michael Schmitz]

> > OK, I've switched from BootX to Yboot using a stable 2.2.17 kernel and the
> > most recent XF86-4.0.1 and ati driver sources I can find. I seem to get
> > different PCI assignments to the ATI chip on boot-up (looking at dmesg
> > compared with using BootX) but the X-server still doesn't detect the chip
> > with "startx" or "XFree86" and exits with a "device not found" and "no
> > screens" error. Any further suggestions?
>
> There is a Modes line in the screen section, use a generic mode.
> Don't specify a Modes section.

It's probably just some error in the device section (the server doesn't
complain about 'no valid modes found' but 'no device found'.

Need to see your XF86Config's device section.

	Michael


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

Re: Xfree86-4.0.1, Lombard, Mach64 driver, X-server Crash

[Jon Erick Ween]

[-- Attachment #1: Type: text/plain, Size: 1415 bytes --]

Here's a copy of my XF86Config file.

Two other minor nuisances:

Since using yaboot, my console cursor has disappeared. Is this an OF or a
yaboot problem? It's very hard to navigate in vi to edit anything (.config
files for one thing) without a cursor!

Also, I can't figure out how to uninstall BootX. Throwing it away under
MacOS doesn't seem to help.

Any suggestions?

Thanks

Jon

> From: Michael Schmitz <schmitz@mail.biophys.uni-duesseldorf.de>
> Date: Wed, 27 Sep 2000 20:17:02 +0200 (CEST)
> To: Olaf Hering <olh@suse.de>
> Cc: Jon Erick Ween <jween@som.llu.edu> , linuxppc-dev@lists.linuxppc.org
> Subject: Re: Xfree86-4.0.1, Lombard, Mach64 driver, X-server Crash
>
>>> OK, I've switched from BootX to Yboot using a stable 2.2.17 kernel and the
>>> most recent XF86-4.0.1 and ati driver sources I can find. I seem to get
>>> different PCI assignments to the ATI chip on boot-up (looking at dmesg
>>> compared with using BootX) but the X-server still doesn't detect the chip
>>> with "startx" or "XFree86" and exits with a "device not found" and "no
>>> screens" error. Any further suggestions?
>>
>> There is a Modes line in the screen section, use a generic mode.
>> Don't specify a Modes section.
>
> It's probably just some error in the device section (the server doesn't
> complain about 'no valid modes found' but 'no device found'.
>
> Need to see your XF86Config's device section.
>
> Michael
>


[-- Attachment #2: XF86Config --]
[-- Type: audio/wav, Size: 1605 bytes --]

Re: Xfree86-4.0.1, Lombard, Mach64 driver, X-server Crash

[Michael Schmitz]

> Since using yaboot, my console cursor has disappeared. Is this an OF or a
> yaboot problem? It's very hard to navigate in vi to edit anything (.config
> files for one thing) without a cursor!

Happens to me occasionally, but it also happened during console switching
or some other console operation (rarely). Don't thing it's yaboot related.

> Also, I can't figure out how to uninstall BootX. Throwing it away under
> MacOS doesn't seem to help.

Throw away the extension not only the control panel app.

The config was attached as audio - trying hard to listen ...

	Michael


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

Re: Xfree86-4.0.1, Lombard, Mach64 driver, X-server Crash

[Michael Schmitz]

> Here's a copy of my XF86Config file.

Only differences I can see:

I don't use HwCursor, and I use ShadowFB off in the device section.

I use mode lines as returned by fbset -x in the monitor section.

Plus I don't use the empty Files section (fontpath there at least).

Order shouldn't matter I hope, otherwise try the layout at the end.

	Michael


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

Re: Xfree86-4.0.1, Lombard, Mach64 driver, X-server Crash

[Jon Erick Ween]

Michael

I tried the changes you suggested, no difference. (I couldn't figure out
what you meant by "layout at the end.", was there more to the email that
didn't get through?)

But, honestly, I can't see why these changes should influence whether or not
the Xserver detects the video device. That seems to be the main problem.
It's looking for a particular device at a particular memory address
(presumably specified by the "ati" driver file) and is not finding it. I
thought switching from BootX to yaboot would fix this, but it hasn't. (I
thought I recompiled everything under a yaboot startup, assuming this would
fix the device name and memory specifications in the finished driver, but
maybe not. I'll do this again in any case, just to be sure.)

Do you have any other suggestions?
--
Jon Erik Ween, MD

Cognitive and Cerebrovascular Neurology

Assistant Professor
Loma Linda University School of Medicine

Director, Stroke Program
Loma Linda University Medical Center

> From: Michael Schmitz <schmitz@zirkon.biophys.uni-duesseldorf.de>
> Date: Wed, 27 Sep 2000 21:21:44 +0200 (CEST)
> To: Jon Erick Ween <jween@som.llu.edu>
> Cc: Michael Schmitz <schmitz@opal.biophys.uni-duesseldorf.de> , Olaf Hering
> <olh@suse.de>, linuxppc-dev@lists.linuxppc.org
> Subject: Re: Xfree86-4.0.1, Lombard, Mach64 driver, X-server Crash
>
>> Here's a copy of my XF86Config file.
>
> Only differences I can see:
>
> I don't use HwCursor, and I use ShadowFB off in the device section.
>
> I use mode lines as returned by fbset -x in the monitor section.
>
> Plus I don't use the empty Files section (fontpath there at least).
>
> Order shouldn't matter I hope, otherwise try the layout at the end.
>
> Michael
>


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

Re: Xfree86-4.0.1, Lombard, Mach64 driver, X-server Crash

[Michael Schmitz]

> I tried the changes you suggested, no difference. (I couldn't figure out
> what you meant by "layout at the end.", was there more to the email that
> didn't get through?)

I meant move the first section (server layout IIRC) to the end of the
file. Nothing complicated.

> But, honestly, I can't see why these changes should influence whether or not
> the Xserver detects the video device. That seems to be the main problem.
> It's looking for a particular device at a particular memory address
> (presumably specified by the "ati" driver file) and is not finding it. I

Neither do I, and it works perfectly for me ...

I can send you my config if nothing else helps.

	Michael


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

Re: Xfree86-4.0.1, Lombard, Mach64 driver, X-server Crash

[Benjamin Herrenschmidt]

>Here's a copy of my XF86Config file.
>
>Two other minor nuisances:
>
>Since using yaboot, my console cursor has disappeared. Is this an OF or a
>yaboot problem? It's very hard to navigate in vi to edit anything (.config
>files for one thing) without a cursor!

Completely ? Or does it appear with different colors depending on the VC
you are on ? I've seen such bug appear here or there but never took the
time to track it down...

I suspect an atyfb problem ;)

>Also, I can't figure out how to uninstall BootX. Throwing it away under
>MacOS doesn't seem to help.

Remove the bootx extension that is in your MacOS Extensions folder. it
should appear near the top of the list when vieweing them by name.

Ben.

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

Re: Xfree86-4.0.1, Lombard, Mach64 driver, X-server Crash

[Takashi Oe]

On Wed, 27 Sep 2000, Benjamin Herrenschmidt wrote:

> >Here's a copy of my XF86Config file.
> >
> >Two other minor nuisances:
> >
> >Since using yaboot, my console cursor has disappeared. Is this an OF or a
> >yaboot problem? It's very hard to navigate in vi to edit anything (.config
> >files for one thing) without a cursor!
>
> Completely ? Or does it appear with different colors depending on the VC
> you are on ? I've seen such bug appear here or there but never took the
> time to track it down...
>
> I suspect an atyfb problem ;)

I think this is more of a generic fb device layer problem or a combination
of driver bug and upper layer bug.  Or I totally don't understand how
fbcon works.

My understanding is this:
Video console uses 16 colors, and it only initializes the cmap
corresponding to those 16 colors.  The other entries in cmap are up to
each individual fb driver or undefined as far as console is concerned.
For software cursor, driver specific (struct display_switch *)ops->revc()
is used to make the cursor blink.  For the generic fbcon_cfb{16,32}_revc,
it xors each pixel with masks 0xffff (depth 16) or 0xffffffff (depth 32).
For controlfb which I am very familiar with, the "correct" masks are
0x3def for 555 and 0x0f0f0f0f for 8888.  That is, only 4 LSBs or low 16
for each red, green, and blue are xor'ed since cmap entries corresponding
to higher bits are undefined as far as fbcon support is concerned.


Takashi Oe


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

Re: Xfree86-4.0.1, Lombard, Mach64 driver, X-server Crash

[Geert Uytterhoeven]

On Wed, 27 Sep 2000, Takashi Oe wrote:
> On Wed, 27 Sep 2000, Benjamin Herrenschmidt wrote:
> > >Here's a copy of my XF86Config file.
> > >Two other minor nuisances:
> > >
> > >Since using yaboot, my console cursor has disappeared. Is this an OF or a
> > >yaboot problem? It's very hard to navigate in vi to edit anything (.config
> > >files for one thing) without a cursor!
> >
> > Completely ? Or does it appear with different colors depending on the VC
> > you are on ? I've seen such bug appear here or there but never took the
> > time to track it down...
> >
> > I suspect an atyfb problem ;)
>
> I think this is more of a generic fb device layer problem or a combination
> of driver bug and upper layer bug.  Or I totally don't understand how
> fbcon works.
>
> My understanding is this:
> Video console uses 16 colors, and it only initializes the cmap
> corresponding to those 16 colors.  The other entries in cmap are up to
> each individual fb driver or undefined as far as console is concerned.
> For software cursor, driver specific (struct display_switch *)ops->revc()
> is used to make the cursor blink.  For the generic fbcon_cfb{16,32}_revc,
> it xors each pixel with masks 0xffff (depth 16) or 0xffffffff (depth 32).
> For controlfb which I am very familiar with, the "correct" masks are
> 0x3def for 555 and 0x0f0f0f0f for 8888.  That is, only 4 LSBs or low 16
> for each red, green, and blue are xor'ed since cmap entries corresponding
> to higher bits are undefined as far as fbcon support is concerned.

In 2.5.x, we'll have a user-defined xor mask for the cursor as the 17th entry
in the dispsw_data array.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


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

Re: Xfree86-4.0.1, Lombard, Mach64 driver, X-server Crash

[Takashi Oe]

On Thu, 28 Sep 2000, Geert Uytterhoeven wrote:

> > My understanding is this:
> > Video console uses 16 colors, and it only initializes the cmap
> > corresponding to those 16 colors.  The other entries in cmap are up to
> > each individual fb driver or undefined as far as console is concerned.
> > For software cursor, driver specific (struct display_switch *)ops->revc()
> > is used to make the cursor blink.  For the generic fbcon_cfb{16,32}_revc,
> > it xors each pixel with masks 0xffff (depth 16) or 0xffffffff (depth 32).
> > For controlfb which I am very familiar with, the "correct" masks are
> > 0x3def for 555 and 0x0f0f0f0f for 8888.  That is, only 4 LSBs or low 16
> > for each red, green, and blue are xor'ed since cmap entries corresponding
> > to higher bits are undefined as far as fbcon support is concerned.
>
> In 2.5.x, we'll have a user-defined xor mask for the cursor as the 17th entry
> in the dispsw_data array.

Can we put it for 2.4?  As far as I can see, the actual size of
dispsw_data matters only between fb driver and fbcon-cfbxx.c, and the
changes required for each driver seem to be rather small.  Besides,
controlfb is not the only one which will benefit from this change.


Takashi Oe


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

Re: Xfree86-4.0.1, Lombard, Mach64 driver, X-server Crash

[Geert Uytterhoeven]

On Thu, 28 Sep 2000, Takashi Oe wrote:
> On Thu, 28 Sep 2000, Geert Uytterhoeven wrote:
> > > My understanding is this:
> > > Video console uses 16 colors, and it only initializes the cmap
> > > corresponding to those 16 colors.  The other entries in cmap are up to
> > > each individual fb driver or undefined as far as console is concerned.
> > > For software cursor, driver specific (struct display_switch *)ops->revc()
> > > is used to make the cursor blink.  For the generic fbcon_cfb{16,32}_revc,
> > > it xors each pixel with masks 0xffff (depth 16) or 0xffffffff (depth 32).
> > > For controlfb which I am very familiar with, the "correct" masks are
> > > 0x3def for 555 and 0x0f0f0f0f for 8888.  That is, only 4 LSBs or low 16
> > > for each red, green, and blue are xor'ed since cmap entries corresponding
> > > to higher bits are undefined as far as fbcon support is concerned.
> >
> > In 2.5.x, we'll have a user-defined xor mask for the cursor as the 17th entry
> > in the dispsw_data array.
>
> Can we put it for 2.4?  As far as I can see, the actual size of
> dispsw_data matters only between fb driver and fbcon-cfbxx.c, and the
> changes required for each driver seem to be rather small.  Besides,
> controlfb is not the only one which will benefit from this change.

That's true. Personally, I see no problems with it if someone's willing to
write the patch for _all_ drivers at once. The real 2.4.0 is still a long way
to go, I think, and the impact of the required changes is known quite well.

The main thing we need to be careful about is that the xor mask is different
for truecolor and directcolor visuals: truecolor needs an `all ones' mask,
while directcolor needs `15' for each color component (drivers that incorrectly
report a directcolor instead of truecolor visual will easily be identified).

  - Affected fbcon low level drivers:

      o fbcon-cfb16.c
      o fbcon-cfb24.c
      o fbcon-cfb32.c

  - Affected frame buffer device drivers:

      o acornfb.c
      o atafb.c
      o aty128fb.c
      o atyfb.c
      o chipsfb.c
      o clgenfb.c
      o controlfb.c
      o creatorfb.c
      o cyber2000fb.c
      o fm2fb.c
      o hgafb.c
      o hitfb.c
      o igafb.c
      o imsttfb.c
      o macfb.c
      o matrox/matroxfb_accel.c
      o matrox/matroxfb_crtc2.c
      o offb.c
      o platinumfb.c
      o pm2fb.c
      o q40fb.c
      o riva/fbdev.c
      o sgivwfb.c
      o sisfb.c
      o skeletonfb.c
      o tdfxfb.c
      o tgafb.c
      o valkyriefb.c
      o vesafb.c
      o vfb.c
      o virgefb.c

Not that bad, only about 1/4 of all files...

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


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

Re: Xfree86-4.0.1, Lombard, Mach64 driver, X-server Crash

[Takashi Oe]

On Fri, 29 Sep 2000, Geert Uytterhoeven wrote:

> > > In 2.5.x, we'll have a user-defined xor mask for the cursor as the 17th entry
> > > in the dispsw_data array.
> >
> > Can we put it for 2.4?  As far as I can see, the actual size of
> > dispsw_data matters only between fb driver and fbcon-cfbxx.c, and the
> > changes required for each driver seem to be rather small.  Besides,
> > controlfb is not the only one which will benefit from this change.
>
> That's true. Personally, I see no problems with it if someone's willing to
> write the patch for _all_ drivers at once. The real 2.4.0 is still a long way
> to go, I think, and the impact of the required changes is known quite well.

Good!  I'll work on it.  Only a few allocate memory for dispsw_data
dynamically, the changes should be trivial for most.

> The main thing we need to be careful about is that the xor mask is different
> for truecolor and directcolor visuals: truecolor needs an `all ones' mask,
> while directcolor needs `15' for each color component (drivers that incorrectly
> report a directcolor instead of truecolor visual will easily be identified).

I don't know how it will work out for atyfb, but we'll see...


Takashi Oe


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

Re: Xfree86-4.0.1, Lombard, Mach64 driver, X-server Crash

[Geert Uytterhoeven]

On Fri, 29 Sep 2000, Takashi Oe wrote:
> On Fri, 29 Sep 2000, Geert Uytterhoeven wrote:
> > > > In 2.5.x, we'll have a user-defined xor mask for the cursor as the 17th entry
> > > > in the dispsw_data array.
> > >
> > > Can we put it for 2.4?  As far as I can see, the actual size of
> > > dispsw_data matters only between fb driver and fbcon-cfbxx.c, and the
> > > changes required for each driver seem to be rather small.  Besides,
> > > controlfb is not the only one which will benefit from this change.
> >
> > That's true. Personally, I see no problems with it if someone's willing to
> > write the patch for _all_ drivers at once. The real 2.4.0 is still a long way
> > to go, I think, and the impact of the required changes is known quite well.
>
> Good!  I'll work on it.  Only a few allocate memory for dispsw_data
> dynamically, the changes should be trivial for most.
>
> > The main thing we need to be careful about is that the xor mask is different
> > for truecolor and directcolor visuals: truecolor needs an `all ones' mask,
> > while directcolor needs `15' for each color component (drivers that incorrectly
> > report a directcolor instead of truecolor visual will easily be identified).
>
> I don't know how it will work out for atyfb, but we'll see...

Atyfb is directcolor. Grep fro VISUAL_ to find out :-)

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


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