9600 maturity?

9600 maturity?

[Dan Bethe]

Hi all.  I am considering getting a Powermac 9600 with a single 200 MHz 604e to
replace my 8500 as a production server.  I can't find any info so far on the
maturity of Linux's support of the 9600.  I read that a while back there were
SMP problems, video problems, and problems with some types of PCI cards in the
2nd PCI bus (the lower three slots).  The PCI problem was also had on MacOS at
some point in time, so I wonder if they worked around it with something like a
System Enabler and I wonder if such knowledge is incorporated into Linux.

Can anyone confirm whether Linux support of the 9600 is at least as rock solid
as that of the 8500?  I need it to be all around ideal or else it's not good
enough.  Or give ideas on where to search for it other than the mailing lists
at lists.linuxppc.org and lists.yellowdoglinux.com?  Google shows nothing so
far.

Thanks to all who contribute to that hardware family.... well, and to anything
else too  :}

=====
Ambassador Communication Services -=- http://ambcomm.com
   Managed Teleconferencing and Transcription Services


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

Re: 9600 maturity?

[Tony 'Nicoya' Mantler]

At 2:43 AM -0500 4/15/02, Dan Bethe wrote:
>Hi all.  I am considering getting a Powermac 9600 with a single 200 MHz
>604e to
>replace my 8500 as a production server.  I can't find any info so far on the
>maturity of Linux's support of the 9600.  I read that a while back there were
>SMP problems, video problems, and problems with some types of PCI cards in the
>2nd PCI bus (the lower three slots).  The PCI problem was also had on MacOS at
>some point in time, so I wonder if they worked around it with something like a
>System Enabler and I wonder if such knowledge is incorporated into Linux.
>
>Can anyone confirm whether Linux support of the 9600 is at least as rock solid
>as that of the 8500?  I need it to be all around ideal or else it's not good
>enough.  Or give ideas on where to search for it other than the mailing lists
>at lists.linuxppc.org and lists.yellowdoglinux.com?  Google shows nothing so
>far.
>
>Thanks to all who contribute to that hardware family.... well, and to anything
>else too  :}

I've not had too much trouble with my 9600/200mp. I haven't used it much
since early 2.4, mind you (got enough other unix boxes on my desktop), but
it worked pretty well at the time. The only rub with the SMP was that if
MacOS 9 got ahold of the second CPU, linux would fail to grab it when it
booted. I solved it by booting from an 8.1 boot floppy, but that obviously
won't be a problem for you.

I haven't had much trouble with the PCI. I'm running a Promise Ultra66 and
a 21143 ethernet card in the top slots, and the standard IMSTT video in the
bottom. (though I'm looking to replace that with a Radeon7000 PCI - IMSTT
is kinda slow by modern standards)


I'd definatley pick a 9600 to run linux on over an 8500 - if for no other
reason than it having the very cool flip&fold case. 8)


Cheers - Tony 'Nicoya' Mantler :)


--
Tony "Nicoya" Mantler - Renaissance Nerd Extraordinaire - nicoya@apia.dhs.org
Winnipeg, Manitoba, Canada           --           http://nicoya.feline.pp.se/


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

Re: 9600 maturity?

[Dan Bethe]

> I've not had too much trouble with my 9600/200mp. I haven't used it much
> since early 2.4, mind you (got enough other unix boxes on my desktop), but

Not too much?  Does that mean you can beat the crap out of all subsystems 24/7
with no hardware failure?  :)  Like a 'make -j20' on the kernel src with
several concurrent 'badblocks'?

> I haven't had much trouble with the PCI. I'm running a Promise Ultra66 and

Not much?  Does that mean it was reliable, or just sticky to configure?

> I'd definatley pick a 9600 to run linux on over an 8500 - if for no other
> reason than it having the very cool flip&fold case. 8)

Yeah that's a chief factor.  Does the flip&fold give easy access to RAM and
cache, unlike the 8500?  Do you happen to know how the internal cooling
compares between the 8500 and 9600?  I have several internal hard drives and
cards.

Thanks, Tony!  :)

=====
Ambassador Communication Services -=- http://ambcomm.com
   Managed Teleconferencing and Transcription Services


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

Re: 9600 maturity?

[Tony 'Nicoya' Mantler]

At 5:41 AM -0500 4/15/02, Dan Bethe wrote:
>> I've not had too much trouble with my 9600/200mp. I haven't used it much
>> since early 2.4, mind you (got enough other unix boxes on my desktop), but
>
>Not too much?  Does that mean you can beat the crap out of all subsystems 24/7
>with no hardware failure?  :)  Like a 'make -j20' on the kernel src with
>several concurrent 'badblocks'?

I think I could crash it by trying to use 'hdparm' on the IDE-connected
drives, but I don't recall anything else that would make it puke.

Most of the fuss I ran into was just getting a kernel with the right
patches to talk to all the Promise card, and figuring out why the heck SMP
wouldn't work.


>> I haven't had much trouble with the PCI. I'm running a Promise Ultra66 and
>
>Not much?  Does that mean it was reliable, or just sticky to configure?

Well, when I was linuxing my 9600, it was around the time of the PCI code
being in a state of a whole lot of flux, trying to handle 3+ busses per
machine and resorting board resources. I think (hope) that work has been
basically finnished and integrated now, so I wouldn't expect nearly as much
trouble now.

Nothing in linux is ever exactly 100% though. I recently had a heck of a
headache trying to get the AC97 sound in my l33t athlon working - had to
hack and patch the kernel to death, and while I eventually got it mostly
working, Quake3 still won't talk to it.


>> I'd definatley pick a 9600 to run linux on over an 8500 - if for no other
>> reason than it having the very cool flip&fold case. 8)
>
>Yeah that's a chief factor.  Does the flip&fold give easy access to RAM and
>cache, unlike the 8500?  Do you happen to know how the internal cooling
>compares between the 8500 and 9600?  I have several internal hard drives and
>cards.
[...]

Yes! The case gives amazingly easy access to all the internal guts. The PCI
cards, drives and all can be accessed by removing the left side of the
case, which pops off with just one latch. The ram and cpu can be accessed
by further unplugging the power cord, and lifting up on the very convinient
translucent blue handle to fold the drivecage/powersupply out of the way.

Replacing the ram on an 8100 (which I had to do at one point. Never tried
in an 8500, but I understand it's very similar) is like trying to do a root
canal from the butt-end in comparison.

The cooling is rather sophisticated and intricate. The air is channeled in
such a way that it flows in from around the edges of the motherboard, and
also in from around the front of the drive bays. The air enters from the
bottom, rear, and lower-right side of the case, and exits in the back
(powersupply) and in the lower-left (removable panel) by the encouragement
of two temperature-controlled 120mm fans.

The air temperature in this room can exceed 30c at times, and I've never
had a thermal-related failure in the system. Even with dual-cpus and a
bunch of drives it runs much cooler than my SGI Indigo2 (R10k@195,
MaxIMPACT gfx. it eats plenty of power). That said, the cooling system
should be easily capable of sucking out the whole 390 watts (or 560 watts
for 300/350MHz) of heat that the powersupply can deliver.


Anyways, some things you might consider adding to a 9600 should you pick
one up:

#1: Ram. With 12 dimm slots, it can take a gig and a half of 5 volt 168-pin
FPM or EDO, though maxing it out might be expensive. Remember to install in
matched pairs to take advantage of interleaving.

#2: Faster HD controller. QLogic cards are pretty sweet, Adaptec cards will
do in a pinch, and Promise cards seem to work nice if you've got a taste
for cheap IDE gigs. The PCI bus has a measured max throughput of 80MB/s per
bus, so you might as well put it to good use.

#3: Newer video. Radeon7000 PCI is a good choice. This obviously isn't a
factor when the system is to be used as a server though.


All in all, you should be very happy with your new 9600 in linux.

Cheers - Tony 'Nicoya' Mantler :)


--
Tony "Nicoya" Mantler - Renaissance Nerd Extraordinaire - nicoya@apia.dhs.org
Winnipeg, Manitoba, Canada           --           http://nicoya.feline.pp.se/


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

ATI 7000 and dual-monitor X? (was Re: 9600 maturity?)

[Stefan Jeglinski]

>#3: Newer video. Radeon7000 PCI is a good choice. This obviously isn't a
>factor when the system is to be used as a server though.

http://www.ati.com/shopati/promotions/maccombo/index.html

Seems like the 7000 would be a nice addition to spruce up my old
9500/G3 workhorse. It would free up 2 slots as I now have a Twin
Turbo, an ixTV, and an old Matrox card in there now.

1. Is the Radeon 7000 supported in XFree86? Rather, the real question
is, does anyone know of any gotchas trying to run it in accelerated
mode?

2. What about the included USB TV - any hope for that working in X?

3. What is the status of dual monitors in XFree86? Last I remember,
it could be made to work but only with fbdev - that running dual
accelerated monitors was not really working.


Stefan Jeglinski

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

Re: ATI 7000 and dual-monitor X? (was Re: 9600 maturity?)

[Ani Joshi]

On Mon, 15 Apr 2002, Stefan Jeglinski wrote:

> http://www.ati.com/shopati/promotions/maccombo/index.html
>
> Seems like the 7000 would be a nice addition to spruce up my old
> 9500/G3 workhorse. It would free up 2 slots as I now have a Twin
> Turbo, an ixTV, and an old Matrox card in there now.
>
> 1. Is the Radeon 7000 supported in XFree86? Rather, the real question
> is, does anyone know of any gotchas trying to run it in accelerated
> mode?

ATI tends to make new cards which are really just newer revisions of older
ASICs.  For example, the Radeon 7200 is realy just a regular radeon with
64meg DDR (and perhaps higher clocks).  So its highly possible that the
7000 is a radeon VE (considering its dualhead).  If so, then it is
supported.  Even if it isn't, adding support should be very trivial as it
contains the same 1st generation Radeon ASIC.

> 2. What about the included USB TV - any hope for that working in X?

No idea on that one.

> 3. What is the status of dual monitors in XFree86? Last I remember,
> it could be made to work but only with fbdev - that running dual
> accelerated monitors was not really working.

Dualhead (accelerated) should work fine.



ani


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

Re: ATI 7000 and dual-monitor X? (was Re: 9600 maturity?)

[Tony 'Nicoya' Mantler]

At 2:27 PM -0500 4/15/02, Ani Joshi wrote:
>On Mon, 15 Apr 2002, Stefan Jeglinski wrote:
>
[...]
>> 1. Is the Radeon 7000 supported in XFree86? Rather, the real question
>> is, does anyone know of any gotchas trying to run it in accelerated
>> mode?
>
>ATI tends to make new cards which are really just newer revisions of older
>ASICs.  For example, the Radeon 7200 is realy just a regular radeon with
>64meg DDR (and perhaps higher clocks).  So its highly possible that the
>7000 is a radeon VE (considering its dualhead).  If so, then it is
>supported.  Even if it isn't, adding support should be very trivial as it
>contains the same 1st generation Radeon ASIC.
[...]

In the PC version, the Radeon7000 is exactly identical to the RadeonVE,
except it only has analog VGA out, no DVI (I happen to have one in my l33t
athlon). This makes things extra confusing, since the Radeon7000 Mac
Edition actually does have a DVI connector and TV-out.

I'm pretty sure that the entire Radeon, RadeonVE and Radeon 7*00 series are
based on the same R100 chip, with different clocks, connectors, ram, and
features enabled. The Radeon8500, on the other hand, has the newer R200
chip, and I think an R300 'Radeon9500' is in the works.

You'll have to remember, though, that even with the nice internal
performance of the Radeon7000, running two displays on one 32/33 PCI card
will definatley be pushing the bandwidth limits, so performance may not be
100%.


Cheers - Tony 'Nicoya' Mantler :)


--
Tony "Nicoya" Mantler - Renaissance Nerd Extraordinaire - nicoya@apia.dhs.org
Winnipeg, Manitoba, Canada           --           http://nicoya.feline.pp.se/


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

Re: ATI 7000 and dual-monitor X? (was Re: 9600 maturity?)

[Olaf Hering]

On Mon, Apr 15, Ani Joshi wrote:

>
> On Mon, 15 Apr 2002, Stefan Jeglinski wrote:
>
> > http://www.ati.com/shopati/promotions/maccombo/index.html
> >
> > Seems like the 7000 would be a nice addition to spruce up my old
> > 9500/G3 workhorse. It would free up 2 slots as I now have a Twin
> > Turbo, an ixTV, and an old Matrox card in there now.
> >
> > 1. Is the Radeon 7000 supported in XFree86? Rather, the real question
> > is, does anyone know of any gotchas trying to run it in accelerated
> > mode?
>
> ATI tends to make new cards which are really just newer revisions of older
> ASICs.  For example, the Radeon 7200 is realy just a regular radeon with
> 64meg DDR (and perhaps higher clocks).  So its highly possible that the
> 7000 is a radeon VE (considering its dualhead).  If so, then it is
> supported.  Even if it isn't, adding support should be very trivial as it
> contains the same 1st generation Radeon ASIC.

It is a VE, but I have one report where it fails on a 9600, after
loading vgahw.a or something like that. Maybe it must go into another
slot or the guy has to boot without video=ofonly.
More details later..



Gruss Olaf

--
 $ man clone

BUGS
       Main feature not yet implemented...

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

Re: ATI 7000 and dual-monitor X? (was Re: 9600 maturity?)

[Michel Lanners]

On  16 Apr, this message from Olaf Hering echoed through cyberspace:
>> > 1. Is the Radeon 7000 supported in XFree86? Rather, the real question
>> > is, does anyone know of any gotchas trying to run it in accelerated
>> > mode?
>>
>> ATI tends to make new cards which are really just newer revisions of older
>> ASICs.  For example, the Radeon 7200 is realy just a regular radeon with
>> 64meg DDR (and perhaps higher clocks).  So its highly possible that the
>> 7000 is a radeon VE (considering its dualhead).  If so, then it is
>> supported.  Even if it isn't, adding support should be very trivial as it
>> contains the same 1st generation Radeon ASIC.
>
> It is a VE, but I have one report where it fails on a 9600, after
> loading vgahw.a or something like that. Maybe it must go into another
> slot or the guy has to boot without video=ofonly.

Loading vgahw.a? Hmmm, that looks suspiciously like problem accessing
legacy hardcoded VGA ports on the second bus (which as Ben explains
doesn't support that).

Can somebody please teach XFree to leave those VGA ports alone on PPC?
Are they of _any_ use on any PPC machine?

Cheers

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: ATI 7000 and dual-monitor X? (was Re: 9600 maturity?)

[Geert Uytterhoeven]

On Wed, 17 Apr 2002, Michel Lanners wrote:
> On  16 Apr, this message from Olaf Hering echoed through cyberspace:
> >> > 1. Is the Radeon 7000 supported in XFree86? Rather, the real question
> >> > is, does anyone know of any gotchas trying to run it in accelerated
> >> > mode?
> >>
> >> ATI tends to make new cards which are really just newer revisions of older
> >> ASICs.  For example, the Radeon 7200 is realy just a regular radeon with
> >> 64meg DDR (and perhaps higher clocks).  So its highly possible that the
> >> 7000 is a radeon VE (considering its dualhead).  If so, then it is
> >> supported.  Even if it isn't, adding support should be very trivial as it
> >> contains the same 1st generation Radeon ASIC.
> >
> > It is a VE, but I have one report where it fails on a 9600, after
> > loading vgahw.a or something like that. Maybe it must go into another
> > slot or the guy has to boot without video=ofonly.
>
> Loading vgahw.a? Hmmm, that looks suspiciously like problem accessing
> legacy hardcoded VGA ports on the second bus (which as Ben explains
> doesn't support that).
>
> Can somebody please teach XFree to leave those VGA ports alone on PPC?
> Are they of _any_ use on any PPC machine?

Any PPC \not \in PowerMac?

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: ATI 7000 and dual-monitor X? (was Re: 9600 maturity?)

[Ani Joshi]

On Wed, 17 Apr 2002, Michel Lanners wrote:

> Can somebody please teach XFree to leave those VGA ports alone on PPC?
> Are they of _any_ use on any PPC machine?

Yes, they are of use on Macs (I assume you meant pmacs instead of PPC,
cause LOTS of ppc's use vga).  How else would u program a VGA card on a
mac without use of the VGA ports?  The solution is for XFree86 to bang the
proper IO space when there are multiple busses, this is being worked on.


ani


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

Re: ATI 7000 and dual-monitor X? (was Re: 9600 maturity?)

[Michel Lanners]

> On Wed, 17 Apr 2002, Michel Lanners wrote:
>
>> Can somebody please teach XFree to leave those VGA ports alone on PPC?
>> Are they of _any_ use on any PPC machine?
>
> Yes, they are of use on Macs (I assume you meant pmacs instead of PPC,
> cause LOTS of ppc's use vga).  How else would u program a VGA card on a
> mac without use of the VGA ports?  The solution is for XFree86 to bang the
> proper IO space when there are multiple busses, this is being worked on.
>
>
> ani

> Any PPC \not \in PowerMac?
>
> Gr{oetje,eeting}s,
>
> 						Geert

Hrmpff... Should have switched on brain before hitting 'reply'. Putting
hand in mouth and shutting up :-[

Cheers

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: ATI 7000 and dual-monitor X? (was Re: 9600 maturity?)

[Ani Joshi]

On Tue, 16 Apr 2002, Olaf Hering wrote:

> It is a VE, but I have one report where it fails on a 9600, after
> loading vgahw.a or something like that. Maybe it must go into another
> slot or the guy has to boot without video=ofonly.
> More details later..


This is most likely the perennial multiple PCI bus ISA IO problem in
userland that plagues many Macs.  I won't go into the discussion again of
why this is a problem, as this has been discussed here many times (see old
posts about this problem on G4's), but a quick solution may be to put the
card in the 1st slot, or whichever slot corresponds to the io_base
syscall.  I have never used a 9600 so ask around which slot this is.

Also, have you tried radeonfb?


ani


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

Re: ATI 7000 and dual-monitor X? (was Re: 9600 maturity?)

[benh]

>> It is a VE, but I have one report where it fails on a 9600, after
>> loading vgahw.a or something like that. Maybe it must go into another
>> slot or the guy has to boot without video=ofonly.
>> More details later..
>
>
>This is most likely the perennial multiple PCI bus ISA IO problem in
>userland that plagues many Macs.  I won't go into the discussion again of
>why this is a problem, as this has been discussed here many times (see old
>posts about this problem on G4's), but a quick solution may be to put the
>card in the 1st slot, or whichever slot corresponds to the io_base
>syscall.  I have never used a 9600 so ask around which slot this is.
>
>Also, have you tried radeonfb?

Note that the issue can be worse on older Macs. Newer ones can actually
issue low-addresses IOs on each bus, older ones (dual Bandit ones), afaik,
can't. The second bus is physically mapped after the first one on these.

The PCI domain patch should, ultimately, fix the problem for machine that
can issue those IOs (that is mostly uninorth based machines).

Ben.


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

Re: ATI 7000 and dual-monitor X? (was Re: 9600 maturity?)

[Olaf Hering]

On Tue, Apr 16, Ani Joshi wrote:

>
>
> On Tue, 16 Apr 2002, Olaf Hering wrote:
>
> > It is a VE, but I have one report where it fails on a 9600, after
> > loading vgahw.a or something like that. Maybe it must go into another
> > slot or the guy has to boot without video=ofonly.
> > More details later..
>
>
> This is most likely the perennial multiple PCI bus ISA IO problem in
> userland that plagues many Macs.  I won't go into the discussion again of
> why this is a problem, as this has been discussed here many times (see old
> posts about this problem on G4's), but a quick solution may be to put the
> card in the 1st slot, or whichever slot corresponds to the io_base
> syscall.  I have never used a 9600 so ask around which slot this is.
>
> Also, have you tried radeonfb?

That was the culprit. He had to boot with video=ofonly. I will try to
get some info why it fails.
Maybe another slot or a newer kernel, or both.


Gruss Olaf

--
 $ man clone

BUGS
       Main feature not yet implemented...

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

Re: 9600 maturity?

[Michel Lanners]

Hey all,

On  15 Apr, this message from Tony 'Nicoya' Mantler echoed through cyberspace:
>
> At 5:41 AM -0500 4/15/02, Dan Bethe wrote:
>>> I've not had too much trouble with my 9600/200mp. I haven't used it much
>>> since early 2.4, mind you (got enough other unix boxes on my desktop), but
>>
>>Not too much?  Does that mean you can beat the crap out of all subsystems 24/7
>>with no hardware failure?  :)  Like a 'make -j20' on the kernel src with
>>several concurrent 'badblocks'?
>
> I think I could crash it by trying to use 'hdparm' on the IDE-connected
> drives, but I don't recall anything else that would make it puke.

Yeah, hdparm -I crashed my 7600 with Promise too, at one time at least.
Didn't use it recently, though, since I know what's on the bus ;-)

> Most of the fuss I ran into was just getting a kernel with the right
> patches to talk to all the Promise card, and figuring out why the heck SMP
> wouldn't work.

Both problems are resolved for 2.4 kernels.

>>> I haven't had much trouble with the PCI. I'm running a Promise Ultra66 and
>>
>>Not much?  Does that mean it was reliable, or just sticky to configure?
>
> Well, when I was linuxing my 9600, it was around the time of the PCI code
> being in a state of a whole lot of flux, trying to handle 3+ busses per
> machine and resorting board resources. I think (hope) that work has been
> basically finnished and integrated now, so I wouldn't expect nearly as much
> trouble now.

No, 2.4 kernels should have solid PCI even in the presence of multiple
host bridges (which was the problem on the dual-bandit 9x00). The only
potentially remaining problem could be access to IO space on the second
bus. Ben, can you comment?

> Anyways, some things you might consider adding to a 9600 should you pick
> one up:
>
> #1: Ram. With 12 dimm slots, it can take a gig and a half of 5 volt 168-pin
> FPM or EDO, though maxing it out might be expensive. Remember to install in
> matched pairs to take advantage of interleaving.

To be sure, I have a tool on my homepage that checks the
hammerhead (memory controler) configuration for interleaving.

> #2: Faster HD controller. QLogic cards are pretty sweet, Adaptec cards will
> do in a pinch, and Promise cards seem to work nice if you've got a taste
> for cheap IDE gigs. The PCI bus has a measured max throughput of 80MB/s per
> bus, so you might as well put it to good use.

To take into account here: bootability. If you need a bootable
additional controler, than that limits your choices. Promise' are not
bootable; but there apparently is a MacOS version from some OEM that has
an OF ROM instead of the PC BIOS ROM. Don't know if it's
Linux-supported, though.

> #3: Newer video. Radeon7000 PCI is a good choice. This obviously isn't a
> factor when the system is to be used as a server though.

Yeah, according to all reports, the original IMS TwinTurbo cards are
problematic.

Chees

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: 9600 maturity?

[Benjamin Herrenschmidt]

>No, 2.4 kernels should have solid PCI even in the presence of multiple
>host bridges (which was the problem on the dual-bandit 9x00). The only
>potentially remaining problem could be access to IO space on the second
>bus. Ben, can you comment?

I can't. I would love having someone try this in details and tell me ;)

I suspect the second bandit can only produce "high" IO addresses (thus
precenting use of legacy stuff).


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

Re: 9600 maturity?

[Michel Lanners]

'Morning,

On  15 Apr, this message from Benjamin Herrenschmidt echoed through cyberspace:
>>No, 2.4 kernels should have solid PCI even in the presence of multiple
>>host bridges (which was the problem on the dual-bandit 9x00). The only
>>potentially remaining problem could be access to IO space on the second
>>bus. Ben, can you comment?
>
> I can't. I would love having someone try this in details and tell me ;)
>
> I suspect the second bandit can only produce "high" IO addresses (thus
> precenting use of legacy stuff).

But is there something in place now in the PCI code to handle the IO
space of multiple host bridges now? When I was working on the chaos PCI
code, you had plans to implement that part...

IIRC, you wanted to move both IO spaces into a continous segment and
provide some way to find the ber-bus base of IO space...

Cheers

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: 9600 maturity?

[benh]

>
>But is there something in place now in the PCI code to handle the IO
>space of multiple host bridges now? When I was working on the chaos PCI
>code, you had plans to implement that part...
>
>IIRC, you wanted to move both IO spaces into a continous segment and
>provide some way to find the ber-bus base of IO space...

it is implemented in 2.4, but a bit differently. Each host has it's own
IO space ioremapped separately. One is picked up as the "primary" IO space
and gets all 0-based IOs (basically it's where _IO_BASE points to).
Then, IO resources of PCI devies on other busses are fixed up by the
kernel to be offseted by (io_bus_virt - _IO_BASE) (that is the virtual
address of the IO space of this bus minus the virtual address of IO space
of the primary bus), thus allowing inx/outx functions to work.

That means though that there isn't a convenient way to access fixed
(ie. legacy) IO locations on other busses, except by using platform
specific routines to find out the real bus virtual IO base. But at
least, IO resources provided by BARs will work on other busses provided
that the driver uses the pci_dev->resource fields properly.

However, I haven't yet verified if it works properly for busses like
bandit that don's issue a 0-based (bus view) IO range, but an "offseted"
one like it is, I think, the case for second bandit. On UniNorth, each
host has a 0 based 0...16Mb IO space.

Ben.


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

Re: 9600 maturity?

[Jeff Walther]

At 21:14 +0200 04/15/2002, Michel Lanners wrote:

>To take into account here: bootability. If you need a bootable
>additional controler, than that limits your choices. Promise' are not
>bootable; but there apparently is a MacOS version from some OEM that has
>an OF ROM instead of the PC BIOS ROM. Don't know if it's
>Linux-supported, though.

The name of the card is the VST UltraTech/66.  I don't know if it is
Linux-supported either.  OWC has it for about $50 and there is a
firmware update from OWC that adds OSX support in case that is
relevant for Linux.

The VST card is the Promise card with a few resistors moved and
different firmware installed and the 66 MHz oscillator removed.

I don't believe it contains a PPB instantiated in the single IC on
the board.  However, it triggers the PPB hierarchy problem in
PowerSurge machines with almost exactly the same symptoms as a PCI
card with an on-board PPB.   I don't know if it's possible that the
Mac firmware for the card somehow makes it look enough like a PPB
bearing card to trigger the OF bug, but that is my current guess.
Anyway, this card won't work in the lower slots of the Umax S900 if
there is another PCI card present in the lower four slots which has
on-board firmware--with a couple of exceptions.

Jeff Walther

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

Re: 9600 maturity?

[Jeff Walther]

At 00:43 -0700 04/15/2002, Dan Bethe wrote:

>Hi all.  I am considering getting a Powermac 9600 with a single 200
>MHz 604e to
>replace my 8500 as a production server.  I can't find any info so far on the
>maturity of Linux's support of the 9600.

If Linux support for PCI-PCI Bridges is acceptable (I have no idea
myself) you might consider the Umax S900.  It has six PCI slots, but
four of them are behind a PCI-PCI Bridge built into the motherboard.
The advantage of the S900 is that the architecture is basically that
of an 8500/7500.

Architecturally, the x500 machines are all very similar.   The 9500
has two Bandit chips on the CPU/memory bus instead of one, and that
can create CPU bus arbitration problems.  The 7500/8500 has only one
Bandit chip, but they add a CHAOS video bridge chip to the CPU bus.
The S900 has no CHAOS and only one Bandit.  Then it sacrifices its
third PCI slot in order to connect the upstream side of a DEC 21052
PCI-PCI Bridge and hangs four more PCI slots off of the PPB.

I have found that any PCI card which has its own PPB hangs the
machine (with a few exceptions) in the lower four slots.  i.e. if you
create a hierarchy of two PPBs Apple's PCI implementation bails.

Jeff Walther

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

Re: 9600 maturity?

[benh]

>I have found that any PCI card which has its own PPB hangs the
>machine (with a few exceptions) in the lower four slots.  i.e. if you
>create a hierarchy of two PPBs Apple's PCI implementation bails.
>
>Jeff Walther

Yes, this is a known bug of older OFs, though an OF patch is floating
around to fix it (dunno how to find it though).

Note that recent 2.4 kernels may be able to work around OF bugs here.

Ben.


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

PPB Bug in PowerSurge: was: 9600 maturity

[Jeff Walther]

At 06:01 +0100 04/15/2002, benh@kernel.crashing.org wrote:

>>I have found that any PCI card which has its own PPB hangs the
>>machine (with a few exceptions) in the lower four slots.  i.e. if you
>>create a hierarchy of two PPBs Apple's PCI implementation bails.
>>
>>Jeff Walther
>
>Yes, this is a known bug of older OFs, though an OF patch is floating
>around to fix it (dunno how to find it though).
>
>Note that recent 2.4 kernels may be able to work around OF bugs here.

Thank you for that information, Ben.  I'm really more of a MacOS guy
and subscribed to these lists out of an interest in low level
hardware issues.  There doesn't seem to be any other forum that
discusses hardware specifically, so you guys (and other Linux/Darwin
lists) who sometimes must program to the hardware are the next best
thing.

Do you have suggestions on where I might begin a hunt for such an OF
patch?  I assume this is something that one could load in NVRAM under
any OS that will take care of the bug until the next time the NVRAM
is reset?

There is an email list (SuperMacs) at lowendmac.com of Umax users and
this is an issue that has been a big pain for most of us because our
lower four slots are behind one PPB.  Any device that adds another
creates a problem.    It became especially acute with the
introduction of the FW/USB cards.

I didn't know it was an Apple bug when I first ran into the problem
and figured it could be a problem with OF or the Bandit or the DEC
21052 chip.  So I replaced the DEC 21052 with the Intel 21152AB, the
Intel 21152BA, the TI PCI2550, and the Hint HB1-SE33P.  After all
those PPBs had the same symptoms I was convinced it was an Apple
problem.  I was willing to entertain the notion that all the older
PPBs might have the same bug, especially because the Intel is the
descendant of the DEC, but the Hint is a relatively new design.

If someone knows how to patch the OF in the ROM for the PowerSurge I
can get the patched ROM code written into Flash Memory chips that are
pin compatible with the Mask ROMs on the PowerSurge machines.  If
anyone is actually interested in this, it would probably be best to
use the Kansas ROM code as the base.  I've but Kansas ROMs in the
clones (Umax and PCC PTP) and in 7500/8500 machines and it works fine
and eliminates the speculative processing issue with G3 processors.
The Kansas ROM works with any PowerSurge machine as far as I can
tell.  Unfortunately, it doesn't solve the PPB problem.  :-(

Jeff Walther

P.S.  Apologies for veering off topic for the list.

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

Re: PPB Bug in PowerSurge: was: 9600 maturity

[benh]

>Thank you for that information, Ben.  I'm really more of a MacOS guy
>and subscribed to these lists out of an interest in low level
>hardware issues.  There doesn't seem to be any other forum that
>discusses hardware specifically, so you guys (and other Linux/Darwin
>lists) who sometimes must program to the hardware are the next best
>thing.
>
>Do you have suggestions on where I might begin a hunt for such an OF
>patch?  I assume this is something that one could load in NVRAM under
>any OS that will take care of the bug until the next time the NVRAM
>is reset?

Yes. DTS provides one for some machines (for example the 6400) if you
ask. Some PCI card vendors with a pci<->pci bridge on their card need
it.


Ben.


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

Re: PPB Bug in PowerSurge: was: 9600 maturity

[Jeff Walther]

At 08:57 +0100 04/15/2002, benh@kernel.crashing.org wrote:

>>Do you have suggestions on where I might begin a hunt for such an OF
>>patch?  I assume this is something that one could load in NVRAM under
>>any OS that will take care of the bug until the next time the NVRAM
>>is reset?
>
>Yes. DTS provides one for some machines (for example the 6400) if you
>ask. Some PCI card vendors with a pci<->pci bridge on their card need
>it.

I suspect I'm going to feel silly for needing to ask this, but how do
I contact DTS and what does it stand for?

I was aware that there was a patch for the 6400.   Does that same
patch solve the multi-level PPB problem in PowerSurge as well?

Thank you again.  I'm ecstatic to have received this info from you.
I wasn't expecting to ever get any info on this issue.  Most people
don't seem to know about it, or aren't willing to discuss it, maybe.

Jeff Walther


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

Re: PPB Bug in PowerSurge: was: 9600 maturity

[Benjamin Herrenschmidt]

>
>I suspect I'm going to feel silly for needing to ask this, but how do
>I contact DTS and what does it stand for?
>
>I was aware that there was a patch for the 6400.   Does that same
>patch solve the multi-level PPB problem in PowerSurge as well?

I'm not sure, I may have been confused by those 2 issues ;)

>Thank you again.  I'm ecstatic to have received this info from you.
>I wasn't expecting to ever get any info on this issue.  Most people
>don't seem to know about it, or aren't willing to discuss it, maybe.

Well, DTS is Apple's Developer Technical Support. Did you try
contacting them ? (You may need a registerd Apple devel. account
for this though).

Ben.


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