Joe Schofield propounded certain bytes, to wit:
| Has anyone experienced OSR5.0.0 locking up/panic during heavy disk IO?
| I have one OSR5.0.0 machine and one OSR3.2v4.2 machines, both have
| Adaptec 2940 cards, and with only SCSI hard drives. I have multiple
| applications which run well in OSR3.2.v4.2, but cause a lockup or
| panic (I've had both) in OSR5.0.0. Has anyone had this problem? If
| so, which patch seemed to help? I have most if not all of the patches
| installed for OSR5.0.0. If anyone has had this problem, then switched
| to OSR5.0.2, did it help? I am also in the process of switching from
| Linux to OSR5.0.2 as a news server, and if this is the case, I am not
| going to even think of replacing my Linux box!
You *might* be facing the problem in this TA:
Non-Corollary system gets "WARNING: ip: spinning on PCB Fxxxxxxx" messages.
KEYWORDS: ip: spinning on PCB net100 openserver networking supplement release
1.0 v5 5.0.0 5.0.2 console ERGREF E130167 us-ip-spin tcp_reaper tcp reap
RELEASE: SCO OpenServer Enterprise System Release 5.0.0, 5.0.2
SCO OpenServer Desktop System Release 5.0.0, 5.0.2
SCO Networking Supplement Release 1.0.0
PROBLEM: The message "WARNING: ip: spinning on PCB Fxxxxxxx" scrolls on
the console and all user processes hang. Eventually, error log
overflow messages will also appear.
This can happen on both SCO OpenServer 5.0.2 and SCO OpenServer
5.0.0 systems with the SCO Networking Supplement 1.0.0 installed.
The same symptoms can appear on SCO OpenServer Release 5.0.0 systems
with SCO SMP (Symmetrical Multiprocessing) Release 5.0.0 on Corollary
Architecture machines for a different reason.
See IT os/2793, "Corollary system gets 'WARNING: IP:spinning on
PCB Fxxxxxxx' messages" for information on this related issue.
CAUSE: This is caused by a problem with the tcp_reaper() routine in the
tcp driver shipped with the above products.
SOLUTION: This problem has been reported to SCO Engineering.
When it happens here, everything locks up tight as a drum, and I cannot
even switch screens back to the console device (tty01).
I finally attached a terminal to COM1 and put SYSTTY=1 in /etc/default/boot
to make that the console, where I could see the error message scrolling
indefinitely. Fortunately (ha!), it's a * enough bug that it
does not (have time to?) write to /usr/adm/messages or /usr/adm/syslog,
otherwise you'd be faced with a filled-up root filesystem.
I have no idea when a patch will forthcome...
[PS: what's the sco.scounix newsgroup to which you cross-posted, another