beige g3 rage II xf4.0.1 and miBoot

beige g3 rage II xf4.0.1 and miBoot

[R Shapiro]

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/

Re: beige g3 rage II xf4.0.1 and miBoot

[Kostas Gewrgiou]

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/

Re: beige g3 rage II xf4.0.1 and miBoot

[Geert Uytterhoeven]

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/

Re: beige g3 rage II xf4.0.1 and miBoot

[Michel Lanners]

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/

Re: beige g3 rage II xf4.0.1 and miBoot

[Benjamin Herrenschmidt]

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

Re: beige g3 rage II xf4.0.1 and miBoot

[Michael Schmitz]

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

Re: beige g3 rage II xf4.0.1 and miBoot

[Michael Schmitz]

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

Re: beige g3 rage II xf4.0.1 and miBoot

[Michel Dänzer]

Michael Schmitz 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 ?
>
> 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/

Re: beige g3 rage II xf4.0.1 and miBoot

[Michael Schmitz]

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

Re: beige g3 rage II xf4.0.1 and miBoot

[Kostas Gewrgiou]

On Fri, 29 Sep 2000, Michael Schmitz wrote:

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

Re: beige g3 rage II xf4.0.1 and miBoot

[Michael Schmitz]

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

Re: beige g3 rage II xf4.0.1 and miBoot

[Michel Dänzer]

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

Re: beige g3 rage II xf4.0.1 and miBoot

[Michael Schmitz]

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

Re: beige g3 rage II xf4.0.1 and miBoot

[Claus]

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


when you're in OF a 'devalias' should do it
or check /proc/device-tree/aliases/

mine internal IDE wants
boot-device = ata0/ata-disk@0:x (x=root in hex,)
boot-file = /boot/vmlinux (+ kernel options)



		Claus

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

Re: beige g3 rage II xf4.0.1 and miBoot

[R Shapiro]

Claus writes:
 > when you're in OF a 'devalias' should do it

It says the internal ide is /pci/mac-io/ide@20000.  Making this the
boot-device causes an instantaneous DEFAULT-CATCH.

I ran quik 1.3.1 in linux beforehand, with a reasonable quik.conf.
I'd rather have used the MacOS quik - that's always worked better for
me on other machines that boot this way.  But in this case it says
it's unable to write to the ide drive.  That was MacOS quik 1.3 - if
there's a 1.3.1 version for MacOS, I couldn't find it.


 > boot-device = ata0/ata-disk@0:x (x=root in hex,)

OF is "unable to open" any variant of this I could come up with.

Thanks anyway, but I guess this machine is stuck with BootX.

--
rshapiro@bbn.com


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

Re: beige g3 rage II xf4.0.1 and miBoot

[Timothy A. Seufert]

At 5:59 PM -0400 9/28/00, R Shapiro wrote:

>  > boot-device = ata0/ata-disk@0:x (x=root in hex,)
>
>OF is "unable to open" any variant of this I could come up with.
>
>Thanks anyway, but I guess this machine is stuck with BootX.

It's been a while, but I did have quik based booting working on a
beige G3 at one time.  And I think several others did too.

The issue is that there are nasty bugs in the beige G3's firmware
which prevent it from reliably accessing hard drives, or accessing
them at all.

I don't remember the exact details, but the fix involved using the
"System Disk" utility from MacOS X server (and/or its predecessors)
to get OF patches installed into NVRAM.  These patches fix OF so that
it can reliably access disks to load a first stage booter.  I think
all I had to do was open System Disk, enter its raw OF variables
window, configure boot-device etc. for quik, and exit System Disk.

Note that the current System Disk version included with MacOS X has
eliminated the OF settings window; it now attempts to be completely
point&click, so it's less useful in that regard.  But you might be
able to use it in conjunction with the old Boot Variables utility to
get the job done.

   Tim Seufert

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

Re: beige g3 rage II xf4.0.1 and miBoot

[Ethan Benson]

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

On Thu, Sep 28, 2000 at 11:03:52AM -0400, R Shapiro wrote:
> 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).

just a note i have added some support for finding OpenFirmware paths
on oldworld powermacs to ofpath which is included in ybin.

-- 
Ethan Benson
http://www.alaska.net/~erbenson/

[-- Attachment #2: Type: application/pgp-signature, Size: 0 bytes --]