I have a little more to report on the 2.0.32 lockups I've been
experiancing. I finally got a clue and turned off screen blanking, so the
next time we got a lockup I could see any messages that were on the screen.
And sure enough there were messages on the screen:
IRQ DEADLOCK DETECTED BY CPU 1
IRQ DEADLOCK DETECTED BY CPU 0
Looks like the SMP deadlock stuff isn't working, at least not in my case.
I will upgrade the tulip driver to the latest tomorrow and we will see if
that changes anything. None of the uniprocessor machines we have with the
tulips and 2.0.32 are locking up so I suspect it's a SMP thing. I trust the
SCSI subsystems weren't also tweaked since 2.0.30 or so as well.
Again the system is a clean 2.0.32 SMP kernel running on a dual PPro 200Mhz
system w/ 192MB ram, 1 IDE boot drive with Triton DMA enabled (I've tried it
disabled, no difference), 3 SCSI disks on one ncr53c810 and 7 CD-ROMs on a
second ncr53c810, 2 8 port cyclades 8Yo serial port boards, a DEC tulip
ethernet card @ 100Mbps and a S3virge/DX video board.
And again the hard drive light is rarely on when I go to reset it, so I'm
thinking its not caused by the HD. Doing "make -j" on the kernel doesn't
seem to phase the system after it's freshly rebooted. It seems to take some
time before it's ready to die.
And my filesystems are still in tip-top shape. =)
- Steve
.------------------------------------------------. # * # # # # # #
| Steve Baker | Barely Working | # ## # # # # #
| ice@mama.indstate.edu | System Administrator | # # # # # # # #
| Red-Hat Rulz! | Will work for hardware | # # # ## # # # #
`-- SYS-ADMIN FOR HIRE, HAVE UNIX, WILL TRAVEL --' #### # # # ## # #