beige g3 rage II xf4.0.1 and miBoot

Just to add one more data point (as if another were needed :).  I
tried switching from BootX to miBoot on the rev. a beige g3 minitower.
It boots fine but then can't run xf 4.0.1 at all, even with the fbdev
driver and a single Screen/Device pair.  The symptom is the same as
using ati drivers in a BootX boot: no errors in the log, no core file,
just an endlessly ringing bell and a hosed linux that I have to
three-finger reboot (I can't get to a console and or connect via ssh
to shut it down cleanly).

I plan to try quik-booting as soon as I can figure out the boot-device
syntax for ide drives (I've only configured quik-booting on scsi up
til now).

--
rshapiro@bbn.com


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

On Thu, 28 Sep 2000, R Shapiro wrote:

Just to add one more data point (as if another were needed :).  I
tried switching from BootX to miBoot on the rev. a beige g3 minitower.
It boots fine but then can't run xf 4.0.1 at all, even with the fbdev
driver and a single Screen/Device pair.  The symptom is the same as
using ati drivers in a BootX boot: no errors in the log, no core file,
just an endlessly ringing bell and a hosed linux that I have to
three-finger reboot (I can't get to a console and or connect via ssh
to shut it down cleanly).

  Probably a missmatch between the fbdev device and BusID, xfree
disables the device used by fbdev with bad results.

 Kostas

PS> Any ideas why writing to a disabled pci device in ppc crashes
the machine but not the x86 ones ? Is this something that can be fixed
in the kernel or an arch thing ?


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

On Thu, 28 Sep 2000, Kostas Gewrgiou wrote:

PS> Any ideas why writing to a disabled pci device in ppc crashes
the machine but not the x86 ones ? Is this something that can be fixed
in the kernel or an arch thing ?

Usually the behavior on non-responding addresses can be configured in the host
bridge.

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/

On  28 Sep, this message from Kostas Gewrgiou echoed through cyberspace:

PS> Any ideas why writing to a disabled pci device in ppc crashes
the machine but not the x86 ones ? Is this something that can be fixed
in the kernel or an arch thing ?

Accessing config registers or device resources?

Accessing config registers should work ok, if not, there's something
_really_ wrong somewhere.

Accessing resources that are not enabled, yes, you get a machine check,
because the device will not answer your accesses, so the bus will hit a
timeout, which will be signaled to the processor (was that a PCI master
abort?), in a way that the processor will throw a machine check
exception.

And that machine check exception is not recovered from (would that even
be possible?), hence a plain old kernel panic.

Michel

-------------------------------------------------------------------------
Michel Lanners                 |  " Read Philosophy.  Study Art.
23, Rue Paul Henkes            |    Ask Questions.  Make Mistakes.
L-1710 Luxembourg              |
email   mlan@cpu.lu            |
http://www.cpu.lu/~mlan        |                     Learn Always. "


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

And that machine check exception is not recovered from (would that even
be possible?), hence a plain old kernel panic.

I have code that make it oops instead. It's in the linuxppc_2_5 bk tree,
but I beleive it need some refinements. (Currently, it tries too hard to
oops instead of panic'ing).

Ben.

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

PS> Any ideas why writing to a disabled pci device in ppc crashes
the machine but not the x86 ones ? Is this something that can be fixed
in the kernel or an arch thing ?

Because it happens by the framebuffer driver (kernel space).

	Michael


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

Michael Schmitz wrote:

quoted

PS> Any ideas why writing to a disabled pci device in ppc crashes
the machine but not the x86 ones ? Is this something that can be fixed
in the kernel or an arch thing ?

Because it happens by the framebuffer driver (kernel space).

And it doesn't with x86? :)


Michel


--
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86 and The DRI Project

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

Accessing resources that are not enabled, yes, you get a machine check,
because the device will not answer your accesses, so the bus will hit a
timeout, which will be signaled to the processor (was that a PCI master
abort?), in a way that the processor will throw a machine check
exception.

And that machine check exception is not recovered from (would that even
be possible?), hence a plain old kernel panic.

If you do the access protected by something as used by copy_from/to_user
it should be possible to catch the exception (assuming a machine check
will initiate the same exception processing as a bus error does. I'm no
PPC expert :-)

	Michael


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

quoted

Because it happens by the framebuffer driver (kernel space).

And it doesn't with x86? :)

Did you try with a framebuffer (vesafb for instance) on x86, and the
UseFBDev option? Did anyone ever try?

Hint: it'll happen in the setcolreg framebuffer routine. If it just won't
happen on a comparable setup on x86, I'd suspect x86 fbdev drivers access
these card functions via the IO region whereas PPC uses the MMIO region
(dirty-aliased to VRAM).

	Michael


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

On Fri, 29 Sep 2000, Michael Schmitz wrote:

quoted

quoted

Because it happens by the framebuffer driver (kernel space).

And it doesn't with x86? :)

Did you try with a framebuffer (vesafb for instance) on x86, and the
UseFBDev option? Did anyone ever try?

Yeap i tried it with aty128fb (long time ago), without busID set everything
works you don't get anything in the screen, no panics/locks as in the ppc
side.

 Kostas


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

quoted

Did you try with a framebuffer (vesafb for instance) on x86, and the
UseFBDev option? Did anyone ever try?

Yeap i tried it with aty128fb (long time ago), without busID set everything
works you don't get anything in the screen, no panics/locks as in the ppc
side.

Which isn't exactly the same because the problem only manifests with
conflicting PCI resources set up before the kernel starts. And that -so
far- only happened with some Mach64 based Macs.

aty128fb not having any problem doesn't prove atyfb can't have these
problems on Intel, too.

	Michael


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

Michael Schmitz wrote:

quoted

quoted

Did you try with a framebuffer (vesafb for instance) on x86, and the
UseFBDev option? Did anyone ever try?

Yeap i tried it with aty128fb (long time ago), without busID set
everything works you don't get anything in the screen, no panics/locks as
in the ppc side.

Which isn't exactly the same because the problem only manifests with
conflicting PCI resources set up before the kernel starts. And that -so
far- only happened with some Mach64 based Macs.

aty128fb not having any problem doesn't prove atyfb can't have these
problems on Intel, too.

AFAIK Kostas was talking about the problem that if you don't specify the bus
ID when using an fbdev driver, X disables the graphics chip because no driver
claims it. And he wondered why this locks the machine on PPC while it only
makes the server fail on i386. Right, Kostas?


Michel


--
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86 and The DRI Project

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

quoted

Which isn't exactly the same because the problem only manifests with
conflicting PCI resources set up before the kernel starts. And that -so
far- only happened with some Mach64 based Macs.

aty128fb not having any problem doesn't prove atyfb can't have these
problems on Intel, too.

AFAIK Kostas was talking about the problem that if you don't specify the bus
ID when using an fbdev driver, X disables the graphics chip because no driver
claims it. And he wondered why this locks the machine on PPC while it only
makes the server fail on i386. Right, Kostas?

My answer would be similar - with UseFBDev, the X server handles color
maps and mode switching via the kernel driver (at least for mach64,
didn't check r128). A failed PCI access in a kernel driver results in a
panic on PPC (machine check). It may be caught and handled by a signal on
x86 (simple bus error?).

	Michael


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