T.R | Title | User | Personal Name | Date | Lines |
---|
1244.1 | | NETCAD::STEFANI | | Thu Jan 16 1997 14:33 | 34 |
1244.2 | How to Escalate? | MSDOA::JDICKERSON | | Thu Jan 16 1997 17:06 | 11 |
1244.3 | | NETCAD::FERGUSON | | Fri Jan 17 1997 09:44 | 9 |
1244.4 | | NETCAD::STEFANI | | Mon Jan 20 1997 11:33 | 13 |
1244.5 | NT4 SP2 doesn't see DE435 | UTROP1::utodhcp-198-112-228.uto.dec.com::STOEKENBROEK | Rob Stoekenbroek@UTO | Tue Jan 21 1997 05:50 | 10 |
1244.6 | | NETCAD::FERGUSON | | Tue Jan 21 1997 10:31 | 6 |
1244.7 | Old Driver Better? | MSDOA::JDICKERSON | | Mon Jan 27 1997 13:52 | 18 |
| Would love to report to Microsoft. The customer's scenario is that the
Alpha "hangs" every 7-9 days. We now have a Sniffer@ onsite with a Rube
Goldberg setup for triggering a stop. Basically, a client workstation
is doing continuous "net view"'s to the Server. When the client can no
longer detect the server( hopefully, at "hang time"), the client will
start a ping from himself to another workstation on the lan. At the
detection of traffic between these two the sniffer will stop capturing.
Ron Branch at mail.dec.com is available for consulting on these and
other issues.
We have now run successfully 14 days without a "hang".
We attribute this to a different driver. It is an older driver. It is
almost half the size of the driver on the Microsoft dist. 4.0 cdrom.
The driver we are using was installed on Mon. nite Jan. 13. The sniffer
has not yet triggered and we are cautiously optimistic.
|
1244.8 | Call off the dogs | MSDOA::JDICKERSON | | Fri Jan 31 1997 14:05 | 4 |
| Thanks for all the suggestions. Haven't gotten info back on them, but
have found out through NT engineering that this problem has been
reported on 3 other customer sites and they were looking for a
work-around. Now they have it.
|
1244.9 | Only Workaround | SNOFS1::ELEFTHERIOU | | Mon Feb 03 1997 19:37 | 7 |
| Is the only workaround to which you refer the use of the previous
driver?
Many thanks,
Harry E.
CSC-Sydney.
|
1244.10 | is there a de435.sys? | VMSNET::DMCFARLAND | still TurboMom[tm]... | Tue Feb 04 1997 13:21 | 7 |
| In note 1255, there is a discussion about the DE450.SYS driver which
can replace the dc21x4.sys generic driver on the DE450 PCI card. Is
there a DE435.SYS driver for the DE435 which would work in lieu of
the dc21x4.sys?
Diane
|
1244.11 | DC21X4.SYS only driver for DE435 | NETCAD::HILLER | | Tue Feb 04 1997 13:43 | 7 |
| Sorry,
The only driver available for the DE435 is the DC21X4.SYS driver.
We have not done our own driver for that adapter.
-Brent
|
1244.12 | 10-4 | VMSNET::DMCFARLAND | still TurboMom[tm]... | Wed Feb 05 1997 15:21 | 6 |
| Brent,
That's exactly what I needed to know. Thanx for the info.
di
|
1244.13 | Driver file size | MSDOA::JDICKERSON | | Thu Feb 06 1997 11:30 | 12 |
| The file size for the driver that is not hanging is:
dc21x4.sys 44,544
It is available in the de435 "release" area of
http://ftp.digital.com/pub/DEC/adapters
I understand the "interim" area has newer drivers, but unofficially
(per an NT support engineer I talked to), the driver in the interim
area did not fix the customer hangs at another site.
22 days now without a hang. (previous customer record- 9 days)
|
1244.14 | one or both? | JUGHED::JOHN | | Fri Feb 14 1997 08:26 | 5 |
| Is this just a 435 on Alpha problem?
or is it also a problem on Intel with the 435?
Thanks
ted john
|
1244.15 | Final Solution | MSDOA::JDICKERSON | | Wed Mar 26 1997 12:39 | 19 |
| Final Update from Engineering (C.A.P.E. #71WB12497)
1. The problem only happens on Alphaserver 1000a
2. Digital engineering will not fix it- Not cost effective
3. Cost effective solution from engineering- A1000a's will now
ship with DE500 and not DE435. Swap field problems with DE500.
4. Digital engineering has notified Microsoft that our fix will be to
ship DE500's instead of DE435's in the future. So, Microsoft has
agreed to stop looking for a solution.
******Whatever it Takes ;)****
This is final resolution. No more noting will I answer.
Joel Dickerson
|
1244.16 | Formal Path for Elevating to Microsoft | CSC32::BINGHAM | Scott Bingham �� Windows NT / BackOffice Team, USCSC | Thu Apr 17 1997 18:17 | 60 |
| Hello Joel et al,
This is water under the bridge, but maybe I can
help for next time, or maybe it will help for somebody
else.
Each country or region has a designated number of
people who are authorized to make elevations to Microsoft,
under our ASC (Authorized Service Center) agreement with
Microsoft -- part of the AEC Alliance. For USA-based
field people, your formal elevation path is via the USCSC.
In the USA, You have two ways to access this path:
1. You can call us directly as Mary Jo
suggested.
2. You can log an elevation against
Windows NT software in IPMT or CLD or
CAPE, which will come to me and my
team.
(People outside of the USA who wish to elevate to
Microsoft should do so through their Country Support.
Please do NOT use a Digital elevation process as it will
come to me instead of going to your local Country Support
people.)
In this particular technical issue, the problem
was brought to my attention by the customer Cerner in St
Louis. We did some testing and elevated the issue to NPB
on 5 Dec 1996, via IPMT case CFS.47233. I did *not*
elevate it to Microsoft because the newest drivers from
Digital, available from NPB via our website, also
exhibited the same problem.
In general -- if a person from the field refers a
problem to me -- will I elevate it to Microsoft? Of
course -- as long as you have a cohesive, credible, and
complete problem statement. It is my job to make that
assessment -- I would be called on the carpet if I failed
to do so. In the IPMT system, we play the role of
engineering; if you have elevated a problem to us via the
formal support mechanism, and it gets ignored, I assure
you that I will have high-level people on my tail. :-)
Please do not let whatever bad history you've had
with the CSC prevent you from using us for elevations to
Microsoft. We're overworked, like you, but we're your
formal path, and we do care about Digital's future, and
we've staked our careers on Windows NT.
Thanks,
_Scott
For cross reference, these IPMT cases were associated with
this issue:
CFS.47233
CFS.50008
|
1244.17 | | CSC32::BINGHAM | Scott Bingham �� Windows NT / BackOffice Team, USCSC | Thu Apr 17 1997 18:22 | 7 |
| PS: I assume, but have not seen in print, that this `solution' also
means that NPB engineering will take back `failing' DE435a and DE450s
under warranty when they're replaced with DE500s on this particular
platform. ;-)
Thanks again,
_Scott
|
1244.18 | Maybe make a separate one time kit, even? | ALFSS2::CHURCHE_J | Nothing endures but change | Fri Apr 18 1997 15:48 | 12 |
|
re .3
I think that this notes discussion may show that there is now a need
to put the NT drivers back into the de435 kit...could you put them
back?
Thanks,
jeanette
NT Support/CSC
|