Hi,
James Carlson wrote:
>Andrew Pattison writes:
>
>
>>It's got dual 20.4GB hard disks and 1GB of memory. It also has a quad
>>ethernet card installed, which I didn't know about until it arrived!
>>
>>What chipset is the IDE controller?
>>
>>
>
>I believe it's CMD646U, driven by uata. How is that important?
>
>
It doesn't hurt to _know_ which exact chipset one is using.
For example in order to answer both of the following two frequently
asked questions:
* max supported hdd size ? --> (120GB)
* fastest possible transfer mode ? --> (no UDMA, only PIO4 or such)
I'm not even sure, whether or not the cmd646 did support UDMA33 in
hardware [chances are], anyways: Its Solaris_sparc driver does not.
I think, putting such an obsolete chip as the 646 into the U5/U10
systems has not been the wisest marketing decision back then. Why didn't
they prefer the equally cheap cmd/sil0649, back in 1997/98??
Or maybe replaced it later in the design phase when new cpus and system
boards came out until 2000? SUNW imho hurt itself by that. Was the aim
to direct all potential customers to capable U60 and U80 boxes??
I'm afraid many of those, who once paid $5k for a loaded U10 "featuring"
a thing like the cmd646 may have moved away to somewhere else, rather
than to a real computer like the U60 or U80.
But those mistakes are fortunately things of the past.
I am happy to see SUNW handling things like that completely different
and much more customer friendly now (I myself am customer and should be
allowed to judge.)
There is a very interesting aspect concerning the U5/U10 versus cmd64x
matter: Newer Solaris_sparc releases explicitly do support the faster
cmd/sil0649
( to check, do:
# grep -n 649 /etc/driver_aliases
43:uata "pci1095,649" )
And there were cmd649/sil0649 pci boards made by a couple of vendors
(including former CMD themselves [is now Sil], until 2005 SIIG and until
recently SUNIX). So a U5/U10 user has the following options to work
around the painful cmd646 bottleneck:
* adding a bootable SCSI pci board and hdd (The U5/U10 didn't
artficically disable booting from SCSI by removing SCSI boot support
from its corresponding ieee1275_OBP image, if I remember correctly / in
contrast to the recent SB1500 box I believe)
* adding such a cmd649/sil0649 based pci board for non-bootable 120GB
"data" hdds
But, and that is what I referred to when I said "intersting aspect", you
could do something else: You could add one of the rare 649 pci boards,
identifying themselves with a pci id which identifies them as IDE
controllers, rather than RAID devices (I need to look for the exact pci
id's). And those boards noramally have jumper JP0, that controls whther
to identify as IDE or as RAID. Boards with JP0 unset (or was it the
other way around?) and therefore identifying thmeselves as IDE devices
are recognized by the U5/U10's OBP and you can create convenient
nvalias'es and boot of those fast controllers !!!
And therefore completely work around the poor performing cmd646, from A
to Z !!
The fast 649 chips also have no problem to deal with current DVD burners.
Just the reduction of the necessary boot time had been literally immense
on my old U10_440MHz: It booted Solaris 10 circa three times as fast, as
before.
Contact me, if you need such a rare flavour of those 649 pci boards, I
still have one or two manuf. in 1999 by cmd and they should do the job.
It has btw also been possible to create a certain nvedit script, which
made a "normal" (no JP0, always identifying as RAID) cmd649 board
bootable on sparc (faking its pci id)
It once had been reported to NetBSD's mailing list, in 2003. But one
would also have to patch certain parts of Solaris as I figured out,
because one would get a "cannot mount root fs" error otherwise.
So I wouldn't recommend that procedure at all (unstable!) but it is
interesting to know.
Summary:
Alternative 0) Continue to use the slow on-board cmd646 for everything
1) Use it only for booting up and use a "normal"
cmd649 controller for un-bootable data hdds
2) Find one of the "special" cmd/sil649 based
controllers featuring JP0, make it bootable by (un)setting JP0
3) See sunsolve for compatible SCSI controlellers
(should be bootable on U5/U10's OBP)
Interesting matter, but with Solaris 10/11 you got even more options:
For un-bootable data hdd's (and DVD burners etc.) you can now add a
supported USB2.0, ieee1394[a/b] or combo controller.
That's doesn't only give you high throughput rates, but also breaks the
128GB/("137GB") barrier! At least anything up to 500GB should be
properly addressed.
You might be interested in format's "-e" option, rather than in rmformat
and friends.
And well, even a few SATA controllers should be supported now (of course
without boot support on the U5/U10 platform).
"NewSUNW" and opensolaris give you so much more options now.
SPARC is not dead on the desktop!
--
Martin Bochnig
_______________________________________________
opensolaris-discuss mailing list
[email protected]
