john@chook.ua.oz.au (John Warburton) (07/26/90)
Hello encore users, well , I have just had a wonderful experience installing UMAX 4.3, and still here to tell the tale :-) As soon as it was up, I noticed that every now and again, commands would take longer than normal to execute. This was very random, since the next time I typed the command, it would work straight away. Now that the machine is up in multi-user mode, the problem has reared its head again. Commands are just randomly put on hold for a few seconds and are then executed. We can sometimes get a glimpse of the process when it is waiting, using 'ps', with a STAT of S - a semaphore wait. It has become a problem since it affects all processes, even nfs ones. If these hang for any amount of time, the client machine that has directories on our multimax nfs mounted, will give us the message : nfs server medusa not responding which consequently slows down the client machine. So, now we have two machines that aren't running properly. Has anyone seen this problem, and is there a fix for it?? Thanks for any help JOhn John Warburton Phone : +61 8 228 5583 Department of Computer Science Telex : UNIVAD AA89141 University of Adelaide Fax : +61 8 223 1206 GPO Box 498 Adelaide SA 5001 ACSnet : john@cs.ua.oz
ran@crl.dec.com (Randy Osborne) (07/26/90)
In article <1201@sirius.ucs.adelaide.edu.au>, john@chook.ua.oz.au (John Warburton) writes: |> |> Now that the machine is up in multi-user mode, the problem has reared |> its head again. Commands are just randomly put on hold for a few seconds and |> are then executed. We can sometimes get a glimpse of the process when it is |> waiting, using 'ps', with a STAT of S - a semaphore wait. |> Please post any responses to the net. Randy Osborne
john@chook.ua.oz (John Warburton) (08/02/90)
From article <1201@sirius.ucs.adelaide.edu.au>, by john@chook.ua.oz.au (John Warburton): > > Now that the machine is up in multi-user mode, the problem has reared > its head again. Commands are just randomly put on hold for a few seconds and > are then executed. We can sometimes get a glimpse of the process when it is > waiting, using 'ps', with a STAT of S - a semaphore wait. > well, well, well, what can I say........ The problem has been fixed - by replacing the root disk!!?! We had been getting these disk errors on the root disk rather sporadically. We ignored it for the first couple of days, but as the semaphore wait problem escalated, we looked anywhere for a possible cause. Well, we just replaced the disk a couple of hours ago, and response time has been blissfuly fast! We had root disk problems the last time we upgraded the operating system. Maybe with the next set of distribution tapes for an upgrade, they should include a new Wren V for just this sort of thing :-) John John Warburton Phone : +61 8 228 5583 Department of Computer Science Telex : UNIVAD AA89141 University of Adelaide Fax : +61 8 223 1206 GPO Box 498 Adelaide SA 5001 ACSnet : john@cs.ua.oz