[16254] in Athena Bugs
Re: sun4 8.2.9: mtools
daemon@ATHENA.MIT.EDU (John Hawkinson)
Fri Aug 28 18:28:26 1998
Date: Fri, 28 Aug 1998 18:28:23 -0400 (EDT)
To: bugs@MIT.EDU
Cc: bug-mtools@MIT.EDU, "Jonathan P. Brasher" <freakboy@MIT.EDU>
In-Reply-To: "[16252] in Athena Bugs"
From: John Hawkinson <jhawk@MIT.EDU>
| This happens even if the .mcwd file is about a day old. I doubt this is of any
| consequence, but the following also appears at the same time in the Console
| window:
|
| 13:54 WARNING: /iommu@0,10000000/sbus@0,10001000/espdma@4,8400000/esp@4,8800000/sd@5,0 (sd5):
| 13:54 Error for Command: mode sense Error Level: Informational
| 13:54 Requested Block: 0 Error Block: 0
| 13:54 Vendor: IOMEGA Serial Number: 05/19/97
| 13:54 Sense Key: Unit Attention
| 13:54 ASC: 0x28 (medium may have changed), ASCQ: 0x0, FRU: 0x0
|
This happens if the device isn't happy about being mode sensed, and the mode
sense is done. The OS assumes that the application didn't expect the mode sense
to fail (or, that the mode sense was not initiated by an application, so the user
really wants to know!).
Since mtools is doing a sense explicitly, it really wants to trap the error
itself, and it checks the return value from the uscsi ioctl (see
http://www.sun.com/developers/driver/wps/uscsi/uscsi.html for nominal
documentation). As such, I suspect the following untested patch
should solve this problem:
*** /afs/athena.mit.edu/system/mtools/src/mtools-3.6.local/scsi.c Tue Nov 18 16:41:46 1997
--- scsi.c Fri Aug 28 18:23:30 1998
*************** int scsi_cmd(int fd, unsigned char *cdb,
*** 106,121 ****
--- 106,122 ----
switch (mode) {
case SCSI_IO_READ:
uscsi_cmd.uscsi_flags = USCSI_READ;
break;
case SCSI_IO_WRITE:
uscsi_cmd.uscsi_flags = USCSI_WRITE;
break;
}
+ uscsi_cmd.uscsi_flags |= USCSI_SILENT;
if (ioctl(fd, USCSICMD, &uscsi_cmd) == -1) {
perror("scsi_io");
return -1;
}
if(uscsi_cmd.uscsi_status) {
errno = 0;
--jhawk
