T.R | Title | User | Personal Name | Date | Lines |
---|
981.1 | | KITCHE::schott | Eric R. Schott USG Product Management | Fri Jan 17 1997 13:55 | 3 |
981.2 | | DECWET::MARTIN | | Fri Jan 17 1997 17:07 | 22 |
981.3 | New runaway process (steel BL7) | DECWET::MARIER | | Tue Jan 21 1997 09:47 | 17 |
981.4 | More info | DECWET::MARIER | | Tue Jan 21 1997 09:48 | 1 |
981.5 | I've had 2 run aways today - v4.0b | UNIFIX::HARRIS | Juggling has its ups and downs | Thu Feb 13 1997 13:57 | 14 |
| I've had 2 run away advfsd processes today.
The first happened this morning, so I forced a system crash will full
crash dumps enabled. Crash dumps are available upon request.
The 2nd run away advfsd process is still running and if a responsible
individual wants to look at the live system, arrangements can be made.
The /var/opt/advfsd/logs/advfsd file gives the same "DECthreads
bugcheck" messages as were reported in .0 and .3.
I will file a QAR.
Bob Harris
|
981.6 | QAR 51532 | UNIFIX::HARRIS | Juggling has its ups and downs | Thu Feb 13 1997 14:30 | 0 |
981.7 | when will the patch available ? | HGOSPS::IVANCHENG | | Sun Mar 16 1997 21:58 | 20 |
| Hi,
From : QAR 51532
>
>I am updating the state of this QAR to AK to reflect that a fix is in
>hand in our local sources. This QAR will be closed when we do our next
>code drop to a mainline release.
>
>-Mary S.
> 21-Feb-1997
Our customers also encountered this problem, is there the patch available
now ? If no, when will the patch available ?
Thanks.
Rgds,
Ivan Cheng
|
981.8 | I suggest an IPMT case be created to get a patch | UNIFIX::HARRIS | Juggling has its ups and downs | Mon Mar 17 1997 05:16 | 12 |
| > Our customers also encountered this problem, is there the patch
> available now ? If no, when will the patch available ?
Generally for a problem such as this, an IPMT case is required to get a
patch created. A QAR only aids in getting the fix into the next
release.
If you have a customer with this problem, I suggest you create an IPMT
case for that customer and cross reference the QAR # to make it easier
for the USEG engineer to find the fix for back porting.
Bob Harris
|
981.9 | we get 40 - 60% cpu usage | DYOSW5::WILDER | Does virtual reality get swapped? | Thu Mar 20 1997 04:05 | 18 |
| Well, my customer is at 4.0B with the patches through 022797. They
don't get 100% cpu utilization, but they DO get 40 - 60% cpu usage. Is
this normal for a quiet system?
Now, we do have LSM and disks.ignore. The advfs log does NOT show
threads messages, but it does show freeing memory messages.
Is 40 - 60% cpu usage (they have 4 cpus, and this usage is on cpu0)
REALLY normal? If so, just what in the heck is advfsd doing when the
system is idle (no applications running)? The system is an 8200 - 2 of
them in a TruCluster Production Server (memory channel) config. They
both have similar cpu usage.
Thanks,
/jim
BTW, we forced a crash dump if it would be useful.
|
981.10 | advfsd is in an infinite loop | UNIFIX::HARRIS | Juggling has its ups and downs | Thu Mar 20 1997 10:44 | 10 |
| If your problem is anything like QAR 51532, then advfsd is caught in a
loop in the pthreads library not doing a whole lot of anything.
As was suggested in a prior reply, if you need this as a patch for a
customer, then it is suggested that you file an IPMT/CLD case so that
the Steel fix will be backported to prior versions of Digital UNIX. I
would suggest mentioning QAR 51532 in your IPMT case to help USEG
identify the patch you want backported.
Bob Harris
|
981.11 | | DECWET::MARTIN | | Thu Mar 20 1997 10:51 | 5 |
| Sounds like it's probably fairly normal, unfortunately.
I'm about to post a reply in note 187 detailing some tuning tips for advfsd.
--Ken
|