Messages in this thread | | | Date | Fri, 7 Mar 1997 12:14:02 -0800 | From | Michael Thomas <> | Subject | HP Surestore tape again |
| |
Ugh. I posted a while ago about my new Surestore scsi tape drive. I'm running 2.0.26 with a Buslogics 956 controller with two disks (Seagate and Quantum) and a Toshiba CD ROM. I think I've pretty much exhausted the possibilities of hardware issues:
1) Both ends of the bus are now properly terminated.
2) I've taken the CD ROM off and just used both disk drives and the tape.
3) I can recompile kernels with no problem and haven't had any other hint of faulty hardware, so intermittent hardware seems somewhat unlikely.
4) Parity is being check everywhere.
5) I suppose it's possible that addition of the tape is over taxing the power supply, but I sort of doubt that a 220W supply would be having a problem keeping up with all of this.
The thing about this is that the entire thing does stink of some sort of kernel bug. The general symptom is that while backing up (find+cpio), the disk is getting torched. It's not always consistant, but the mode I've seen most seems to be where ll_blk_rw.c/make_request is noticing that the block being requested is bigger than the drive. Generally, they are completely bogus numbers. Given that ll_rw_block() is called all over the place, it's not clear who it is that's calling it with the bogus block number. However, one interesting thing is that the the buffer_head being supplied seems sane in other respects -- it's just bh->rsector and bh->b_blocknr which are toasted. I've also caught in the kernel messages complaints about directory entries as well. I've fsck'ed my disk several times (many out of necessity) and although I've found that there are holes in fsck (files with huge sizes which can't be rm'd and can only be killed with debugfs) my file system *seems* to be intact now, yet I get errors when I backup to the tape, but not when I send it to /dev/null. To me, it almost seems that SCSI is once in a while getting mixed up -- that a write destined for the tape is getting confused with a write destined for the disk. Maybe it's more generic than that, but writing the wrong data to the disk would certainly cause a lot of hardship along the lines of what I'm seeing. Though less frequently, I'm also seeing other processes get toasted when I'm doing my backups: this could indicate that data being paged in is getting hosed. The problem is that I'm not quite sure how to proceed from here. I've looked over the tape driver, and it's pretty simple minded: "statically" allocated buffers, no tricky double buffering schemes, seemingly standard calls to the scsi code. The code doesn't seem to be accidentally overwriting anything that I can tell, and the fact that it's specific elements of structures that are getting nuked makes it less likely that it's just an adjacent memory kind of issue. I've also limited some of the options with the tape driver to not do write behind etc, to the same result. Are there any other hints that the SCSI code or anything in that path have been having similar problems? Does anybody have a suggestion as to what sort of debugging code I could add to try to isolate where the general vicinity of the problem is? -- Michael Thomas (mike@mtcc.com http://www.mtcc.com/~mike/) "I dunno, that's an awful lot of money." Beavis
| |