Proc 1
IIC bus Status (01) error
Proc 2
Fan1 Status ??? OK
Fan2 Status ??? OK
3.3V ??? OK
Vccp1 ??? OK
3.3V ??? OK
5.0V ??? OK
12.0V ??? OK
Temperature ??? 38.00
Temp Hyst ??? 75.00
Temp Pos ??? 80.00
/* Below: With CPU's Swapped Around */
P00>>>show power
Processor Module Information
Proc 1 Proc 2
Fan1 Status OK OK
Fan2 Status OK OK
3.3V OK OK
Vccp1 OK OK
3.3V OK OK
5.0V OK OK
12.0V OK OK
Temperature 34.00 35.00
Temp Hyst 75.00 75.00
Temp Pos 80.00 80.00
From the way things look, 1 processor is one its way out and I wanted
to find another before it goes completely. I've gone through this sort
of thing a few years ago with a UP2000 750MHz that was a bit skitzo
when running SMP. Now I don’t' remember seeing this error with my
UP2000 750MHz but it's making me nervous. I've read, the DS20e has a
similar error and that you're supposed to ignore it, I don’t know if
that's the case with the UP2000+.
I've seen a couple on eBay but I'm not about to pay "crack cocaine"
prices for a CPU. Does anyone happen to have a 833MHz 4MB cache CPU
(possible 2 if they have them) that they're willing to part with?
Recap:
1) Receiving " IIC bus Status (01) error" on 1 CPU, when CPU's are
swapped the error disappears... is this "normal"
2) If this is NOT normal, does anyone have a 833MHz, possibly 2, CPU's
that they're willing to part with for a price?
Laters,
Will L G
What's a UP2000+?
Hans
A UP2000 plus a + sign.
It is a motherboard originally manufactured by Alpha Processor Inc.
(API), now Microway Inc.
See, e.g.:
http://www.microway.com/alpha/mwnsup2000.html
http://en.wikipedia.org/wiki/DEC_Alpha
Regards,
Nathan
Given the interest of the OP in answering my question, I'd hesitate to
look into these things any further.
I've only been exposed to Alpha cpu's packaged by DEC etc, and then
only those that run VMS or coerced somewhat to do so.
Anyway, these beasts are sold into the *nix market apparently.
Hans
Is there a newer firmware for that system?
Usually it fixes odd behaviour.
(snip...)
It may not be the CPU. I have a UP2000+ here that has been growing
progressively flakier over time. I tried a pair of the 833Mhz. 21264B CPUs
and it would not even POST. Went back to a pair of 700Mz. 2MB 21264A.
Then tried upgrading the memory to 2GB. Worked fine for a month or so, then
started refusing to POST until I pulled out more and more of the added SIMMs.
I'm down to 512MB now and it (mostly) works with that in it.
From my experience in the VLSI manufacturing field, I would guess that one or
more of the interface ASICs is succumbing to electromigration. Don't expect
this thing to be alive much longer.
Steve
Sorry about that, I thought you were being funny or something... my
bad. Will L G
Thanks for that tip, I didn't know that. I thought it might have been
related to the Slot B cartridge itself, that the I2C was going bad or
something then I started having doubts when I realized that the error
may be coming from the board itself.
I could user newer 264DP srms, they work but the onboard SCSI will be
disabled? So I do have an alternative.
>> Is there a newer firmware for that system?
>> Usually it fixes odd behaviour.
>
> I could user newer 264DP srms, they work but the onboard SCSI will be
> disabled? So I do have an alternative.
That's the first I've heard of such a thing. Do you know this from first-hand
experience? If so, I would appreciate a pointer to the appropriate version.
Or, it might be the motherboard. My UP2000 motherboard died in a
somewhat similar manner just a couple of months after the end of
the 3-year warranty. Fortunately, I had used a credit card to
buy the machine, so the credit card company picked up the repair
tab. The motherboard came back with apparently one new chip
in the I/O area and a few blue wires.
--
Robert Riches
spamt...@jacob21819.net
(Yes, that is one of my email addresses.)
Are you sure that it isn't the power supply that's giving out? I
wouldn't rule out a flaky motherboard design (having seen the
reliability of API CS20s), but the PSU might be something to consider.
Symptoms match.
b.r.,
Marc
Actually a lot of UP2000's were actually shipped with the 264DP (DS20
series) srm installed. It's basically the same board except for the
onboard Adaptec SCSI chipset. I did it once in an attempt to get
around the "UP2000 > NO LIKEY > Video Card" issue. I was trying to get
a Radeon 7500 vidcard up and working. Didn't work but the board ran
fine, it gave me the impression the failure to initialize video cards
was actually a hardware issue and not a software issue as API stated.
You see a similar issue with the UP1500. With the UP1500, they
followed the AGP standard to the letter (for a change) and when
manufacturers changed the voltage settings on AGP 8x cards, API didn't
bother to follow suite. So the UP1500 is particular to which cards it
will and can run but nowhere near as bad at the UP2000 series.
This is Will Givens, I remember you told me about that. You sent it
info repairs and, if my memory is correct, the board worked fine
despite some failed power traces.
I wondered that as well but I haven't used the PSU all that much and
it's practically new despite being about 3yo. I think I used it for a
month or so and then boxed it away.
When I bought the UP2000+ w/2x833MHz processors, one processor did
have a burnt smell to it when I opened the bag... that was the one
that was acting up. That's what made me think that the slot b may be
at fault. Then I decided to open a couple of old 750Mhz slot b's and
noticed that the cpu's were literally burned out! No other visual
damage. Then I began to wonder why they burned out and began to think
it may be a design flaw in the motherboard chipset (I2C perhaps) or
the thermal paste degraded. So when I read Steve's post, it meshed
with what I was thinking.
Here are some pics of the 750Mhz CPU's and you'll see what I mean. The
'scorching' appears to be confined to the CPU and heat transfer plate
(for the lack of a better name.)
http://i287.photobucket.com/albums/ll154/DiskMan1984/API%20UP2000%20750Mhz/IMAG0137.jpg
http://i287.photobucket.com/albums/ll154/DiskMan1984/API%20UP2000%20750Mhz/IMAG0136.jpg
http://i287.photobucket.com/albums/ll154/DiskMan1984/API%20UP2000%20750Mhz/IMAG0134.jpg
> When I bought the UP2000+ w/2x833MHz processors, one processor did
> have a burnt smell to it when I opened the bag... that was the one
> that was acting up. That's what made me think that the slot b may be
> at fault. Then I decided to open a couple of old 750Mhz slot b's and
> noticed that the cpu's were literally burned out! No other visual
> damage. Then I began to wonder why they burned out and began to think
> it may be a design flaw in the motherboard chipset (I2C perhaps) or
> the thermal paste degraded. So when I read Steve's post, it meshed
> with what I was thinking.
Well, electromigration is quite a different issue. You would be unlikely to
see anything amiss. At the device level, unbalanced current flow in a VLSI
chip tends to literally cause metal atoms to move away from the middle of a
conductor (thus "migration"). The resulting increase in resistance plays
havoc with drive capacity (fanout) and timing, eventually leading to a
complete failure.
EM is arguably the number one cause for early failure of comsumer electronics
(CD players, TVs, etc.) where time-to-market and production costs dominate
over thorough life-cycle modeling. It can strike anywhere, though, and the
symptoms of my decaying UP2000+ fit perfectly.
Steve
No problem. I own several different Alpha models and had never heard
of a UP2000/UP2000+.
I did use one of the early AXP based boards sent to vendors in, what,
1994 or so.
A company that sold DEC gear got one and wanted to run VMS on it.
I understand that the UP2000 is a more modern EV6 based variant,
without VMS support.
Hans
I think the 264DP series also includes an onboard Adaptec
SCSI, but I'm not sure that SRM can use it.
Dennis
--
"It is rather for us to be here dedicated to the great task remaining before us
[...] that government of the people, by the people, for the people, shall not
perish from the earth."
> You see a similar issue with the UP1500. With the UP1500, they
> followed the AGP standard to the letter (for a change) and when
> manufacturers changed the voltage settings on AGP 8x cards, API didn't
> bother to follow suite. So the UP1500 is particular to which cards it
> will and can run but nowhere near as bad at the UP2000 series
AGP 3.0 spec has been released in 2002, the UP1500 in 2001. Find
anything fishy with your statement? And for the record: If you had paid
some attention to the troubles UP1500 owners went through in trying to
get AGP speeds on Linux, you would have known that API *didn't* adhere
to the AGP specs.
Also, video cards not supported by SRM are not hardware limitations.
Just sayin'.
I have an old Intel Celery 500mhz released in 2000 and it works FINE
with later video cards? Just saying ;-) In fact I gave it away to a
friend of mine just looking for something to surf the internet with
and she thinks it's the bomb, except that it takes a while to boot
*lol*
It does, the UP2000 used the Adaptec AIC-7891 chipset while the 264DP
used Adaptec AIC-7895. I guess the differences were enough to prevent
it from working.
http://www.alphalinux.org/archives/axp-list/May1999/0602.html
http://www.alphalinux.org/archives/axp-list/May1999/0595.html
There's also the fact that they force-disabled the DP264's onboard
SCSI in SRM.
sigh.
I see you still haven't lost the art form of replying with some
amazingly irrelevant statement while still presenting it as if it's
exactly what the other person needed to hear to fully comprehend your
logic.
Really though, the UP1500's AGP will never work like a regular AGP,
because it fundamentally can't. (Not that what I'm going to tell you
has anything to do with SRM's ability to initialize AGP video cards,
but just disproves your silly statements about following the spec "to
the letter")
Take a quote from Ivan Kokshaysky, maybe the only guy to try to
actually try to program it,
"""
There is quite fundamental conflict between the Alpha architecture and
x86 AGP implementation - Alpha is entirely cache coherent by design,
while x86 AGP is not (I mean native AGP DMA transactions, not a PCI
over AGP). There are no such things as non-cacheable mappings or
software support for cache flushing/invalidation on Alpha, so x86 AGP
code won't work on Nautilus.
"""
http://alphalinux.org/wiki/index.php/UP1500
It's like this because it would have been a ton of work for anything
else. When DEC/Compaq/HP designed the Marvel and Titan systems and
their chipsets, they had the flexibility to implement what they
needed, unrestricted by a drop-in AMD chipset. Take another quote from
Ivan: "they are sort of AGP extension of traditional Alpha PCI IOMMU
and are fully cache coherent."
Don't bother repeating that around, because inevitably it'll get
mangled into some anecdote about your old 500 MHz Celeron system again.