kenton@space.mit.edu (Kenton C. Phillips) (04/24/91)
We're having problems with an HP 1GB (HP-97549S) disk drive on a Sparcstation 1+, running SunOS 4.1.1. The system crashes with SCSI errors, and can be made to do so consistently by issuing a command such as 'chmod 666 *' in a directory with several hundred files. (However, 'echo *' doesn't have a problem---it lists those hundreds of files.) It has occured to me that chmod (also chown) might have a problem handling a huge number of files, but that shouldn't crash the system, and it certainly shouldn't generate SCSI bus errors. It seems more likely that the numerous fast disk accesses made by the chmod process are exciting a bug. We've replaced the CPU board on the sparc 1+. We've sent the disk back to the vendor, to verify that it works. We've put it on a sparc 1 (SunOS 4.0.3, with a re-made filesystem, of course), and it works fine. The disk has the 9049 PROM in it, which is supposed to rectify some earlier problems with the HP drives. We have identical drives on other systems (an SLC and an IPC, both 4.1.1) with no problems. We've had field engineers in, who couldn't find what was wrong. Here are some logged error messages (sd1 is the HP disk; sd0, sd2 are internal Quantum 105's): > esp0: No command for reconnect of Target 1 Lun 0 > esp0: polled command timeout > State=UNKNOWN Last State=RESEL > Latched stat=0x17<XZERO,MSG,CD,IO> intr=0xc<FCMP,RESEL> fifo 0x0 > last msg out: <unknown msg 0xff>; last msg in: IDENTIFY > DMA csr=0x80000000 > addr=fff14030 last=fff12030 last_count=2000 > Cmd dump for Target 1 Lun 0: > cdb=[ ] > pkt_state 0x0 pkt_flags 0x9 pkt_statistics 0x0 > cmd_flags=0x100 cmd_timeout 0 > Mapped Dma Space: > Base = 0x0 Count = 0x0 > Transfer History: > Base = 0x0 Count = 0x0 > panic: polled command timeout > syncing file systems... [1] 1 [1] 1 [1] 1 [1] 1 [1] 1 [1] 1 [1] 1 [1] 1 [1] > 1 [1] 1 [1] 1 [1] 1 [1] 1 [1] 1 [1] 1 [1] 1 [1] 1 [1] 1 [1] 1 give up! Does anyone have any suggestions? It's gotten to the point where defenestration seems like a reasonable option. Thanks in advance for any information. Kenton C. Phillips Computer Systems Manager MIT Center for Space Research kenton@space.mit.edu