Bug 110269 - smartd don't skip Iomega SCSI ZIP drives
smartd don't skip Iomega SCSI ZIP drives
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: kernel-utils (Show other bugs)
3
All Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
Brian Brock
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-11-17 14:12 EST by Peter Bieringer
Modified: 2015-01-04 17:03 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-12-08 17:11:11 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
smartd.log with medium in ZIP drive (9.21 KB, text/plain)
2003-11-17 16:42 EST, Peter Bieringer
no flags Details
smartd.log without medium in ZIP drive (8.96 KB, text/plain)
2003-11-17 16:43 EST, Peter Bieringer
no flags Details
kernel.log after fresh booting (28.50 KB, text/plain)
2003-11-26 02:46 EST, Peter Bieringer
no flags Details

  None (edit)
Description Peter Bieringer 2003-11-17 14:12:48 EST
Description of problem:
Having a SCSI ZIP drive installed (no medium inserted), smartd do not
skip this drive.


Version-Release number of selected component (if applicable):
smartd version 5.21

How reproducible:
Always

Steps to Reproduce:
1. Install Iomega SCSI ZIP
2. Boot PC
    

Actual Results:  smartd reports on boot screen:

Starting smartd: sdb: Unit Not Ready, sense:
Current 00:00: sense key Not Ready
Additional sense indicates Medium not present
sdb : READ CAPACITY failed.
sdb : status = 1, message = 00, host = 0, driver = 08
Current sd00:00: sense key Not Ready
Additional sense indicates Medium not present
sdb : block size assumed to be 512 bytes, disk size 1GB.
sdb: Write Protect is off
 I/O error: dev 08:10, sector 0
 unable to read partition table
                       

Expected Results:  More smarter smartd, which skip SCSI ZIP drives -
makes imho not so much sense monitoring such drives.
Comment 1 Arjan van de Ven 2003-11-17 14:14:26 EST
the default config doesn/t scan /dev/sdb afaics.. if you tell it to do
sdb can you blame it for doing it ? ;)
Comment 2 Peter Bieringer 2003-11-17 14:41:43 EST
I've enabled only option: DEVICESCAN
So I wish that smartd would skip such drives...

Comment 3 Bruce Allen 2003-11-17 16:23:32 EST
I don't know how Iomega has done their SCSI implementation. But
at least in principle, the 'medium' can support error monitoring. So
if there was a disk in this device, it might offer some SMART
functionality, for monitoring the error rate of the disks.

I have a question - what does smartd do after seeing this device.  
Does it:
  -- register it for monitoring
  -- die?
  -- not register it for monitoring, then go on to
     scan /dev/sdc?

Could you post the syslog output as an attachment?

Comment 4 Peter Bieringer 2003-11-17 16:42:52 EST
Created attachment 96028 [details]
smartd.log with medium in ZIP drive
Comment 5 Peter Bieringer 2003-11-17 16:43:37 EST
Created attachment 96029 [details]
smartd.log without medium in ZIP drive
Comment 6 Peter Bieringer 2003-11-17 16:45:21 EST
in both cases, smartd skips the drive.

In "with medium" case it looks like that the ZIP drive don't support
any information:

Nov 17 22:39:40 worker smartd[10377]: Device: /dev/sda, opened
Nov 17 22:39:40 worker smartd[10377]: Device: /dev/sda, is SMART
capable. Adding to "monitor" list.
Nov 17 22:39:40 worker smartd[10377]: Device: /dev/sdb, opened
Nov 17 22:39:40 worker smartd[10377]: Device: /dev/sdb, Fetch of IEC
(SMART) mode page failed, err=3, skip device
Comment 7 Bruce Allen 2003-11-17 16:55:19 EST
It looks as if smartd is behaving as it should (with no medium
present):

Nov 17 22:37:58 worker smartd[9869]: Device: /dev/sdb, opened 
Nov 17 22:37:58 worker smartd[9869]: Device: /dev/sdb, NOT READY
(media absent, spun down); skip 
Nov 17 22:37:58 worker smartd[9869]: Unable to register SCSI device
/dev/sdb at line 19 of file /etc/smartd.conf 

So I don't think this is a bug - smartd is behaving as I would
hope and expect.

As previously, you can prevent such messages by either creating
/etc/smartd.conf entries for each drive.

By the way, in your original report, the boot screen messages
are mostly from the kernel, not from smartd. 
Comment 8 Peter Bieringer 2003-11-17 17:26:40 EST
You're right with the kernel message.

But from a "stupid users point of view" such message will confuse me.
Is there no way to detect that the drive is a SCSI ZIP drive (perhaps
same for an IDE one - but I do not have one here), such kind of drive
is on smartd's internal skip-list and therefore automatically skipped
(regardless whether a medium was inserted).
Comment 9 Peter Bieringer 2003-11-24 02:37:41 EST
smartd also not recognize USB storage tokens, which are already
plugged-in on boot. Looks like it this stops further booting until the
token was removed (but I don't wait too long for a timeout).

Kernel reports:

Nov 24 00:03:17 host kernel: usb-uhci.c: interrupt, status 3, frame# 1612
Nov 24 00:03:52 host kernel: usb-uhci.c: interrupt, status 3, frame# 67
Nov 24 00:03:52 host kernel: usb.c: USB disconnect on device
00:11.2-1.1 address 4
Nov 24 00:03:57 host kernel: usb-storage: host_reset() requested but
not implemented
Nov 24 00:04:07 host kernel: scsi: device set offline - command error
recover failed: host 2 channel 0 id 0 lun 0

This confuses the box a little bit, also it looks like smartd request
some commands on "usb-storage" which aren't implemented...

# cat /proc/scsi/usb-storage-0/2
   Host scsi2: usb-storage
       Vendor:
      Product: PenDrive Pro
Serial Number: 07230E0B005C
     Protocol: Transparent SCSI
    Transport: Bulk
         GUID: 0d7d0120000007230e0b005c
     Attached: Yes

# cat /proc/scsi/scsi
Attached devices:
Host: scsi0 Channel: 00 Id: 04 Lun: 00
  Vendor: IOMEGA   Model: ZIP 100          Rev: J.03
  Type:   Direct-Access                    ANSI SCSI revision: 02
Host: scsi2 Channel: 00 Id: 00 Lun: 00
  Vendor:          Model: PenDrive Pro     Rev: 1.06
  Type:   Direct-Access                    ANSI SCSI revision: 02


# smartctl -i /dev/sdc
smartctl version 5.21 Copyright (C) 2002-3 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

Device:          PenDrive Pro     Version: 1.06
Device type: disk
Local Time is: Mon Nov 24 08:37:07 2003 CET
Device supports SMART and is Enabled
Temperature Warning Disabled or Not Supported

# smartctl -a /dev/sdc
smartctl version 5.21 Copyright (C) 2002-3 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

Device:          PenDrive Pro     Version: 1.06
Device type: disk
Local Time is: Mon Nov 24 08:37:50 2003 CET
Device supports SMART and is Enabled
Temperature Warning Disabled or Not Supported
SMART Health Status: OK

Device does not support Error Counter logging
Device does not support Self Test logging

Don't know whether monitoring this device makes much sense.
Comment 10 Bruce Allen 2003-11-24 04:02:00 EST
The latest test release (5.25) should be more sensible for these
badly-conforming non-SCSI USB devices.

smartctl output for these USB devices should make more sense, and
smartd should skip registering them.

Could you please download the smartmontools 5.25 release from
http://sourceforge.net/project/showfiles.php?group_id=64297
and see if it behaves more gracefully?

None of these devices can be monitored, but I agree that it's better
if they don't hang either smartctl or smartd.
Comment 11 Peter Bieringer 2003-11-25 15:56:30 EST
Ok, 5.25 on this machine helps. If now the ZIP drive issue would be
fixed, I'd be very happy.
Comment 12 Peter Bieringer 2003-11-25 15:58:13 EST
BTW: forgotten one thing:

on starting of "smartd", following line would be displayed at all:

Nov 25 21:24:53 server kernel: usb-uhci.c: interrupt, status 3, frame# 154

Don't know whether this is ok or not.
Comment 13 Bruce Allen 2003-11-26 01:26:27 EST
I'n afraid that there is NO fix for the ZIP drive issue.  It's possible
for such drives to provide SMART data (associated with the media, not
with the drive).  But your particular Iomega device doesn't do this,
and so smartd won't monitor it.  So smartd is behaving as it should in
this case: it look for SMART capability, fails to find it, skips the
device, and moves on.

Thanks very much for checking that 5.25 behaves better with the
little USB pen drives.
Comment 14 Peter Bieringer 2003-11-26 02:46:38 EST
Created attachment 96204 [details]
kernel.log after fresh booting

It looks like that it is different whether system is clean started or only
smartd is restarted. Unfortunately I do not the clean-start yesterday, but
today. And the hang issue in case of USB token was plugged-in still exists.

I've attached my kernel log, here some of for me strange lines, all caused by
smartd afais.

Is it good that smartd tries USB devices at all for monitoring?



Nov 26 08:32:29 server kernel: usbdevfs: USBDEVFS_CONTROL failed dev 4 rqt 128
rq 6 len 18 ret -110
Nov 26 08:32:29 server kernel: usb_control/bulk_msg: timeout

Nov 26 08:32:31 server kernel: usb-uhci.c: interrupt, status 3, frame# 250
Nov 26 08:33:21 server kernel: usb-uhci.c: interrupt, status 3, frame# 1187
Nov 26 08:33:21 server kernel: usb-uhci.c: ENXIO 80000200, flags 0, urb
f3c3f240, burb f7dddb40
Nov 26 08:33:21 server kernel: usb-uhci.c: ENXIO 80000200, flags 0, urb
f3c3f240, burb f7dddb40
Nov 26 08:33:21 server kernel: hub.c: cannot disable port 1 of hub 2 (err = -6)

Nov 26 08:33:21 server kernel: usb.c: USB disconnect on device 00:11.2-1.1
address 4

Nov 26 08:33:26 server kernel: usb-storage: host_reset() requested but not
implemented
Nov 26 08:33:36 server kernel: scsi: device set offline - command error recover
failed: host 2 channel 0 id 0 lun 0
Comment 15 Bruce Allen 2003-11-26 02:54:52 EST
I'm a bit confused at this point, because I don't understand the
relationship between:

(1) clean system boot and starting smartd when system is up and
    running.  Could this difference be because in one case you
    are using version 5.21 and in the other case version 5.25?

(2) if problem occurs with Pen Drives and/or Zip drive

(3) if the hang problem is the kernel/system or just the smartd
    process.

(4) how the kernel error logs above relate to smartd/smartctl
    (since smartd/smartctl don't appear in the transcript above)

(5) if smartctl also has the hang/kernel error problem.

Could you please try and clarify these points for me?

Thanks,
    Bruce
Comment 16 Peter Bieringer 2003-11-26 03:20:59 EST
1) the hanging issue looks like the same for 5.21 and 5.25

2) hanging is caused by PenDrive

3) it can be the kernel, but caused by smartd. Looks like smartd
issues some commands on the usb-storage module, which aren't
implemented and/or causing trouble

4) the kernel log entries are caused by smartd

5) have to check

I will today or tomorrow evening (MET) run some more tests, first
removing the ZIP drive, second boot without smartd autostart, save
logs and third boot with smartd autostart, save logs, create a diff.
Comment 17 Bruce Allen 2003-11-26 03:44:40 EST
Thanks for the quick reply.  I look forward to seeing the results
of the additional testing.

Note: for your reporting/testing, please use ONLY 5.25.
Some additional remarks/questions:

(1) is the PenDrive hang in both smartd AND smartctl -a?

(2) Please use the -r ioctl,3 option/Directive to generate
    a detailed report so I can see where the hang takes place.
    If smartctl hangs, use
    smartctl -a -r ioctl,3 /dev/sd?

    and if smartd hangs put -r ioctl,3 into /etc/smartd.conf

(3) attach the syslog output or smartctl output around the
    relevant device.

Cheers,
   Bruce
Comment 18 Peter Bieringer 2003-12-04 14:20:28 EST
So, I've played around and track down the problem.

1) the hang issue is only a timeout issue, not caused by smartd, looks
like caused by starting USB, caused by a post-install command in
/etc/modules.conf. This was inserted by admin (me) on migrating from
RH7 to FC1 (looks like this line isn't necessary at all now in FC1).

## USB
alias usb-controller usb-uhci
alias usb-controller1 ehci-hcd
post-install usb-uhci modprobe usb-storage  <-- Problem

FYI, this results in following kernel log entries:

Dec  4 19:55:22 worker kernel: inserting floppy driver for
2.4.22-1.2115.nptl
Dec  4 19:55:22 worker kernel: Floppy drive(s): fd0 is 1.44M
Dec  4 19:55:22 worker kernel: FDC 0 is a post-1991 82077
Dec  4 19:55:22 worker kernel: usb_control/bulk_msg: timeout
Dec  4 19:55:22 worker kernel: usbdevfs: USBDEVFS_CONTROL failed dev 4
rqt 128 rq 6 len 18 ret -110
Dec  4 19:55:22 worker kernel: usb_control/bulk_msg: timeout
Dec  4 19:55:22 worker kernel: usbdevfs: USBDEVFS_CONTROL failed dev 4
rqt 128 rq 6 len 18 ret -110
Dec  4 19:55:22 worker kernel: usb_control/bulk_msg: timeout
Dec  4 19:55:22 worker kernel: usbdevfs: USBDEVFS_CONTROL failed dev 4
rqt 128 rq 6 len 18 ret -110
Dec  4 19:55:22 worker kernel: usb_control/bulk_msg: timeout

...many more lines

Dec  4 19:55:45 worker kernel: usb_control/bulk_msg: timeout
Dec  4 19:55:45 worker last message repeated 2 times
Dec  4 19:55:45 worker kernel: usb-uhci.c: interrupt, status 2, frame#
1440
Dec  4 19:55:46 worker kernel: hub.c: USB device not accepting new
address (error=-110)
Dec  4 19:55:46 worker kernel: usb-storage: host_reset() requested but
not implemented
Dec  4 19:55:46 worker kernel: scsi: device set offline - command
error recover failed: host 2 channel 0 id 0 lun 0
Dec  4 19:55:46 worker kernel: SCSI disk error : host 2 channel 0 id 0
lun 0 return code = 6050000
Dec  4 19:55:47 worker kernel:  I/O error: dev 08:10, sector 124920
Dec  4 19:55:47 worker kernel:  I/O error: dev 08:10, sector 124922
Dec  4 19:55:47 worker kernel: usb-uhci.c: interrupt, status 3, frame# 55
Dec  4 19:55:47 worker kernel:  sdb: I/O error: dev 08:10, sector 24
Dec  4 19:55:47 worker kernel:  I/O error: dev 08:10, sector 0
Dec  4 19:55:47 worker kernel: Device busy for revalidation (usage=6)
Dec  4 19:55:47 worker kernel:  I/O error: dev 08:10, sector 0
Dec  4 19:55:47 worker kernel:  I/O error: dev 08:10, sector 0
Dec  4 19:55:47 worker kernel:  unable to read partition table

Not very nice...more very strange.
Ok, solved by removing the post-install line


2) Issue relating to smartd is the case of removing the USB pendrive:

ec  4 20:10:54 worker kernel: usb.c: USB disconnect on device
00:11.2-1.1 address 4
Dec  4 20:10:55 worker kernel: sdb: Unit Not Ready, sense:
Dec  4 20:10:55 worker kernel: Info fld=0xa00 (nonstd), Current 00:00:
sense key Not Ready
Dec  4 20:10:55 worker kernel: sdb : READ CAPACITY failed.
Dec  4 20:10:55 worker kernel: sdb : status = 1, message = 00, host =
0, driver = 08
Dec  4 20:10:55 worker kernel: Info fld=0xa00 (nonstd), Current
sd00:00: sense key Not Ready
Dec  4 20:10:55 worker kernel: sdb : block size assumed to be 512
bytes, disk size 1GB.
Dec  4 20:10:55 worker kernel: sdb: test WP failed, assume Write Enabled
Dec  4 20:10:55 worker kernel:  sdb: I/O error: dev 08:10, sector 0
Dec  4 20:10:55 worker kernel:  I/O error: dev 08:10, sector 0
Dec  4 20:10:55 worker kernel:  unable to read partition table
Dec  4 20:10:55 worker kernel: sdb: Unit Not Ready, sense:
Dec  4 20:10:55 worker kernel: Info fld=0xa00 (nonstd), Current 00:00:
sense key Not Ready
Dec  4 20:10:55 worker kernel: sdb : READ CAPACITY failed.
Dec  4 20:10:55 worker kernel: sdb : status = 1, message = 00, host =
0, driver = 08
Dec  4 20:10:55 worker kernel: Info fld=0xa00 (nonstd), Current
sd00:00: sense key Not Ready
Dec  4 20:10:55 worker kernel: sdb : block size assumed to be 512
bytes, disk size 1GB.
Dec  4 20:10:55 worker kernel: sdb: test WP failed, assume Write Enabled
Dec  4 20:10:55 worker kernel:  sdb: I/O error: dev 08:10, sector 0
Dec  4 20:10:55 worker kernel:  I/O error: dev 08:10, sector 0
Dec  4 20:10:55 worker kernel:  unable to read partition table
Dec  4 20:10:55 worker kernel:  I/O error: dev 08:10, sector 0
Dec  4 20:10:55 worker kernel:  I/O error: dev 08:10, sector 0
Dec  4 20:10:56 worker kernel: sdb: Unit Not Ready, sense:
Dec  4 20:10:56 worker kernel: Info fld=0xa00 (nonstd), Current 00:00:
sense key Not Ready
Dec  4 20:10:56 worker kernel: sdb : READ CAPACITY failed.
Dec  4 20:10:56 worker kernel: sdb : status = 1, message = 00, host =
0, driver = 08
Dec  4 20:10:56 worker kernel: Info fld=0xa00 (nonstd), Current
sd00:00: sense key Not Ready
Dec  4 20:10:56 worker kernel: sdb : block size assumed to be 512
bytes, disk size 1GB.
Dec  4 20:10:56 worker kernel: sdb: test WP failed, assume Write Enabled
Dec  4 20:10:56 worker kernel:  sdb: I/O error: dev 08:10, sector 0
Dec  4 20:10:56 worker kernel:  I/O error: dev 08:10, sector 0
Dec  4 20:10:56 worker kernel:  unable to read partition table
Dec  4 20:10:57 worker kernel: sdb: Unit Not Ready, sense:
Dec  4 20:10:57 worker kernel: Info fld=0xa00 (nonstd), Current 00:00:
sense key Not Ready
Dec  4 20:10:57 worker kernel: sdb : READ CAPACITY failed.
Dec  4 20:10:57 worker kernel: sdb : status = 1, message = 00, host =
0, driver = 08
Dec  4 20:10:57 worker kernel: Info fld=0xa00 (nonstd), Current
sd00:00: sense key Not Ready
Dec  4 20:10:57 worker kernel: sdb : block size assumed to be 512
bytes, disk size 1GB.
Dec  4 20:10:57 worker kernel: sdb: test WP failed, assume Write Enabled
Dec  4 20:10:57 worker kernel:  sdb: I/O error: dev 08:10, sector 0
Dec  4 20:10:57 worker kernel:  I/O error: dev 08:10, sector 0
Dec  4 20:10:57 worker kernel:  unable to read partition table


Not so well.
Comment 19 Bruce Allen 2003-12-05 06:01:34 EST
As you say, issue (1) is not related to smartd.  I don't think that
issue (2) is related either.  First, all of these messages are
from the kernel, not from smartd.  Second, if the messages are occuring
because smartd is trying to access a device that doesn't exist, then
again something is wrong with the kernel, because 
    int fd = open(pathname, O_RDWR | O_NONBLOCK);
should return <0 in this case, and smartd should then ignore
the device.

Are you sure that the messages in case (2) are related to smartd?
If so, then for some reason the open() call above is returning
a non-negative value even though the device no longer exists...
Comment 20 Peter Bieringer 2003-12-06 07:23:02 EST
I digged again into and found the reason: /sbin/hotplug causes this
message, it's not smartd related...

An issue for the hotplug maintainers?
Comment 21 Dave Jones 2004-11-27 00:35:36 EST
still problematic in FC3 ?
Comment 22 Peter Bieringer 2004-12-08 17:07:41 EST
No, it's much better now (/dev/sdc is the ZIP drive):

Dec  8 23:01:00 worker smartd[4673]: Device: /dev/sdc, opened
Dec  8 23:01:00 worker smartd[4673]: Device: /dev/sdc, NOT READY (media absent,
spun down); skip

BTW: looks like here something needs to be fixed next time:
Dec  8 23:01:00 worker kernel: program smartd is using a deprecated SCSI ioctl,
please convert it to SG_IO

Linux 2.6.9-1.6_FC2 #1 Thu Nov 18 22:03:19 EST 2004 i686 athlon i386 GNU/Linux

Note You need to log in before you can comment on or make changes to this bug.