Bug 471235

I've tried it with 2 usb sticks (/dev/sdb and /dev/sdc) and it "works" for me:

smartd version 5.38 [x86_64-unknown-linux-gnu] Copyright (C) 2002-8 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

Opened configuration file /etc/smartd.conf
Configuration file /etc/smartd.conf was parsed, found DEVICESCAN, scanning devices
glob(3) found no matches for pattern /dev/hd[a-t]
glob(3) aborted matching pattern /dev/discs/disc*
Problem creating device name scan list
Device: /dev/sda, opened
Device /dev/sda: using '-d sat' for ATA disk behind SAT layer.
Device: /dev/sda, opened
Device: /dev/sda, found in smartd database.
Device: /dev/sda, is SMART capable. Adding to "monitor" list.
Device: /dev/sdb, opened
scsiModePageOffset: response length too short, resp_len=4 offset=4 bd_len=0
Device: /dev/sdb, Bad IEC (SMART) mode page, err=5, skip device
Unable to register SCSI device /dev/sdb at line 23 of file /etc/smartd.conf
Device: /dev/sdc, opened
Device: /dev/sdc, Bad IEC (SMART) mode page, err=5, skip device
Unable to register SCSI device /dev/sdc at line 23 of file /etc/smartd.conf
Monitoring 0 ATA and 1 SCSI devices

------------
can you post here some information about the usb stick, you've used?

also output of smartctl -a /dev/<your_usb_stick> would be useful

It's a 8GB SanDisk Cruzer, currently containing a Fedora-10-Preview i386 DVD iso. Machine is a Medion E1210 netbook (An MSI Wind U100 variant).

# smartctl -a /dev/sdc
smartctl version 5.38 [i386-redhat-linux-gnu] Copyright (C) 2002-8 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

Device: SanDisk  Cruzer           Version: 7.01
Serial number: u
Device type: disk
Local Time is: Sat Nov 15 04:23:20 2008 CET
Device supports SMART and is Enabled
Temperature Warning Disabled or Not Supported
SMART Health Status: OK
Read defect list: asked for grown list but didn't get it

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

# lspci
00:00.0 Host bridge: Intel Corporation Mobile 945GME Express Memory Controller Hub (rev 03)
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GME Express Integrated Graphics Controller (rev 03)
00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03)
00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 02)
00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 02)
00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 (rev 02)
00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 (rev 02)
00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 (rev 02)
00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 (rev 02)
00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #4 (rev 02)
00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2)
00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 02)
00:1f.2 SATA controller: Intel Corporation 82801GBM/GHM (ICH7 Family) SATA AHCI Controller (rev 02)
01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8101E PCI Express Fast Ethernet controller (rev 02)
02:00.0 Network controller: RaLink Device 0781

# lsusb
Bus 001 Device 003: ID 0bda:0158 Realtek Semiconductor Corp. Mass Stroage Device
Bus 001 Device 002: ID 0781:5151 SanDisk Corp. Cruzer Micro 256/512MB Flash Drive
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub


Finally, I haven't experienced smartd notifying root since the incident above.

However, I am finding log messages similar to this one upon each reboot with the usb-stick plugged in (which I interpret as smartd trying to work on the usb-stick):

Nov 14 19:16:30 gunvald smartd[2594]: smartd version 5.38 [i386-redhat-linux-gnu] Copyright (C) 2002-8 Bruce Allen
Nov 14 19:16:30 gunvald smartd[2594]: Home page is http://smartmontools.sourceforge.net/#012
Nov 14 19:16:30 gunvald smartd[2594]: Opened configuration file /etc/smartd.conf
Nov 14 19:16:30 gunvald smartd[2594]: Configuration file /etc/smartd.conf was parsed, found DEVICESCAN, scanning devices
Nov 14 19:16:30 gunvald smartd[2594]: Problem creating device name scan list
Nov 14 19:16:30 gunvald smartd[2594]: Device: /dev/sda, opened
Nov 14 19:16:30 gunvald smartd[2594]: Device /dev/sda: using '-d sat' for ATA disk behind SAT layer.
Nov 14 19:16:30 gunvald smartd[2594]: Device: /dev/sda, opened
Nov 14 19:16:30 gunvald smartd[2594]: Device: /dev/sda, not found in smartd database.
Nov 14 19:16:30 gunvald smartd[2594]: Device: /dev/sda, is SMART capable. Adding to "monitor" list.
Nov 14 19:16:30 gunvald smartd[2594]: Device: /dev/sdb, opened
Nov 14 19:16:30 gunvald smartd[2594]: Device: /dev/sdb, Bad IEC (SMART) mode page, err=5, skip device
Nov 14 19:16:30 gunvald smartd[2594]: Device: /dev/sdc, opened
Nov 14 19:16:30 gunvald smartd[2594]: Device: /dev/sdc, is SMART capable. Adding to "monitor" list.
Nov 14 19:16:30 gunvald smartd[2594]: Monitoring 0 ATA and 2 SCSI devices
Nov 14 19:16:30 gunvald smartd[2596]: smartd has fork()ed into background mode. New PID=2596.

This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

I was trying to reproduce this with my usb sticks but with no success, so I've been digging through the source code. Line "... /dev/sdc, is SMART capable" is result of a test. Smartd sends simple SMART command and checks if answer is correct, so SMART capable = device understands to SMART commands. 

Your stick says it knows these commands, this "foreign language", but don't know answers to most of the questions (commands). So, as far as I can tell, this is unusual (usb sticks should  not a bug, just your usb stick support something from SMART and so is detected as SMART capable. 

From smartmontools page:
> The current USB mass storage specification is based 
> on a version of SCSI (SPC-2) that can't support SAT.
> But some chips manufacturers implement proprietary 
> SCSI commands that allow ATA pass through (similiar
> like for SAT).


Anyway, thanks for reporting this
Michal

(In reply to comment #5)
> From smartmontools page:
> > The current USB mass storage specification is based 
> > on a version of SCSI (SPC-2) that can't support SAT.
> > But some chips manufacturers implement proprietary 
> > SCSI commands that allow ATA pass through (similiar
> > like for SAT).
OK, this would be an explaination.

Anyway (may-be this non-sense), I am leaning towards another suspicion:

This machine seems to have some emulation (?) built-in into its BIOS to access USB devices in different ways, seemingly as "floppies", "harddrives" or "mass-storage".

I haven't yet tried to investigate, but I would not want to exclude if this might be related to this issue. [The usb stick had contained a raw CD/DVD-iso dump at the time this issue had occured (dd if=<xxx>.iso of=<usb-stick>)].

If this suspicion holds, I would expect this issue to be reproducable with different types/brands of usb-sticks on this machine.

Sounds interesting... if you can, please try this with different usb sticks

even this is unusual behaviour, it's not a bug. closing for clean-up

(In reply to comment #8)
> even this is unusual behaviour, it's not a bug. closing for clean-up
You must be kidding - smartd scanning usbsticks definitely is broken behavior. Whether it's smartd's fault is a different question.

Reopening.

No, I'm not kidding. As I've already written: smartd doesn't care what type of device is it, it just sends S.M.A.R.T. command and if it gets correct answer, it starts using it.

(In reply to comment #6)
> This machine seems to have some emulation (?) built-in into its BIOS to access
> USB devices in different ways, seemingly as "floppies", "harddrives" or
> "mass-storage".

Please try other usbsticks, if it's dependent on the emulation, you've mentioned. I've tried, but failed to reproduce it with a few usb sticks. Let me know, what you've find out.

This bug has needinfo state without any reply for almost five months, it will be closed next week.

Refreshing. Bug is still present in FC10 and also reproducable with F11.

Yes, there is no change for this, so it should be still reproducible. Needinfo status was because of last paragraph in comment #10. Please provide requested info. Thanks

This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

needinfo over two months, closing bug

because simple smartmontools principle is: try to send S.M.A.R.T. command, if device sends correct answer treat the device as S.M.A.R.T. capable. This is obviously not smartmontools bug when device sends correct answers.

(In reply to comment #15)
> needinfo over two months, closing bug
> 
> because simple smartmontools principle is: try to send S.M.A.R.T. command, if
> device sends correct answer treat the device as S.M.A.R.T. capable. This is
> obviously not smartmontools bug when device sends correct answers.  

Your tool not being able to treat my USB stick correctly is not your tool's fault? Pardon, this is laughable ...

(In reply to comment #16)
> (In reply to comment #15)
> > needinfo over two months, closing bug
> > 
> > because simple smartmontools principle is: try to send S.M.A.R.T. command, if
> > device sends correct answer treat the device as S.M.A.R.T. capable. This is
> > obviously not smartmontools bug when device sends correct answers.  
> 
> Your tool not being able to treat my USB stick correctly is not your tool's
> fault? Pardon, this is laughable ...  

no, it's the same as blaming windows app it can't recognize it's running under wine and not in real windows environment. If something other cheats it's not smartmontools fault. Also if something/usb stick responds to S.M.A.R.T. commands there's no reason why not use them. Even for flash memory information about reallocated sectors, because cells are dying, is valuable.

(In reply to comment #17)
> no, it's the same as blaming windows app it can't recognize it's running under
> wine and not in real windows environment.
Bullshit - It's an ordinary usb stick and you've got do deal with it, whether you like it or not.

If you can't (which is what you are saying) your tool is mal-designed and not suitable for the purpose it is trying to solve.

Probably, smartmontools's broken design didn't show up before all devices got labeled as /dev/sdX and were separatable by name.