FreeBSD 9 camcontrol Bug?

Leander

Leander

Hi fellows,

FreeBSD's camcontrol shows every harddrive's status as in Standby - even though it's not. Additionally S.M.A.R.T. btchs arround - since it relays on camcontrol information (correct me if I'm wrong) is that a bug or a new feature? ;)
See original Post for reprducing.
Tests from the original Post were done with FreeBSD 9 BETA2 - but I just checked it with 9 BETA3 as well and it's still present. Does anyone know more about that issue? Or can someone reproduce that?

Regards
 
It doesn't quite sound like this, and should not have happened with BETA2. But if you had newer source, it's worth trying a rebuild of world, kernel, and any ports that use CAM like smartmontools.
 
Hi wblock@,

It doesn't quite sound like this
Click to expand...
right, cause error:
Code: 
FreeBSD [~]# smartctl --nocheck standby -i --format=brief -A /dev/ada0
smartctl 5.41 2011-06-09 r3365 [FreeBSD 9.0-BETA3 i386] (local build)
Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net

error sending CAMIOCOMMAND ioctl: Inappropriate ioctl for device
Unable to get CAM device list
/dev/ada0: Unable to detect device type
Smartctl: please specify device type with the -d option.

Use smartctl -h to get a usage summary
did not show up with BETA2. But on BETA2 camcontrol gave wrong reports about running disks as if they would be in standby.
Code: 
camcontrol cmd ada0 -a "E5 00 00 00 00 00 00 00 00 00 00 00" -r -
50 00 00 00 00 00 00 00 00 00 00

[...] and should not have happened with BETA2
Click to expand...
The problem of BETA2 was that ALL requested drives were reported as currently in standby. smartctl as well as camcontrol reported that drives are in standby - which wasn't true for any of them:
Code: 
smartctl --nocheck standby -i --format=brief -A /dev/ada0
smartctl 5.41 2011-06-09 r3365 [FreeBSD 9.0-BETA2 i386] (local build)
Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net

Device is in STANDBY mode, exit(2)


But now since I freshly installed BETA3, I get following error again (as our buddy got in 9.0-RC1)

Feel free to reproduce:
Code: 
FreeBSD [~]# uname -a FreeBSD FreeBSD.TLD 9.0-BETA3 FreeBSD 9.0-BETA3 #0: Sat Sep 24 20:46:57 UTC 2011     root@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  i386

FreeBSD [~]# mount
/dev/gpt/RootFS on / (ufs, local, journaled soft-updates, acls)
devfs on /dev (devfs, local, multilabel)
devfs on /var/named/dev (devfs, local, multilabel)
/dev/md0 on /tmp (ufs, local)
devfs on /var/db/dhcpd/dev (devfs, local, multilabel)



FreeBSD [~]# glabel status
                                      Name  Status  Components
gptid/2fed8e3d-f4f9-11e0-beaf-000fa30711f1     N/A  ada0p1
                                gpt/RootFS     N/A  ada0p2



FreeBSD [~]# camcontrol cmd ada0 -a "E5 00 00 00 00 00 00 00 00 00 00 00" -r -
50 00 00 00 00 00 00 00 00 00 00



FreeBSD [~]# smartctl --nocheck standby -i --format=brief -A /dev/ada0
smartctl 5.41 2011-06-09 r3365 [FreeBSD 9.0-BETA3 i386] (local build)
Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net

error sending CAMIOCOMMAND ioctl: Inappropriate ioctl for device
Unable to get CAM device list
/dev/ada0: Unable to detect device type
Smartctl: please specify device type with the -d option.

Use smartctl -h to get a usage summary

Decoding hex code:
Code: 
Value of the next to last hex code: Description
00h: Device is in Standby mode.
40h: Device is in NV Cache Power Mode and the spindle is spun down or spinning down.
41h: device is in NV Cache Power Mode and the spindle is spun up or spinning up.
80h: Device is in Idle mode.
FFh: Device is in Active mode or Idle mode.

... unforunately I have 00 in second last hex value pair ;(


S.M.A.R.T. or better said smartctl was compiled out of latest ports +plus+ latest tests were done on official 9 BETA3.
 
Was this ever resolved?
I am getting it in 9.0 RELEASE with ad(4) devices

Code: 
[root@nas ~]# uname -a
FreeBSD nas 9.0-RELEASE-p3 FreeBSD 9.0-RELEASE-p3 #0: Tue Jun 12 02:52:29 UTC 2012
[email]root@amd64-builder.daemonology.net[/email]:/usr/obj/usr/src/sys/GENERIC  amd64

===============DA device=========================
Code: 
[[root@nas ~]# camcontrol stop da0
Unit stopped successfully

[root@nas ~]# smartctl -n standby -H /dev/da0
smartctl 5.43 2012-06-30 r3573 [FreeBSD 9.0-RELEASE-p3 amd64] (local build)
Copyright (C) 2002-12 by Bruce Allen, [url]http://smartmontools.sourceforge.net[/url]

Device is in STANDBY mode, exit(2)

[root@nas ~]# camcontrol start da0
Unit started successfully

[root@nas ~]# smartctl -n standby -H /dev/da0
smartctl 5.43 2012-06-30 r3573 [FreeBSD 9.0-RELEASE-p3 amd64] (local build)
Copyright (C) 2002-12 by Bruce Allen, [url]http://smartmontools.sourceforge.net[/url]

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

=================AD device=======================
Code: 
[root@nas ~]# camcontrol standby ada0

[root@nas ~]# smartctl -n standby -H /dev/ada0
smartctl 5.43 2012-06-30 r3573 [FreeBSD 9.0-RELEASE-p3 amd64] (local build)
Copyright (C) 2002-12 by Bruce Allen, [url]http://smartmontools.sourceforge.net[/url]

Device is in STANDBY mode, exit(2)

[root@nas ~]# camcontrol idle ada0

[root@nas ~]# smartctl -n standby -H /dev/ada0
smartctl 5.43 2012-06-30 r3573 [FreeBSD 9.0-RELEASE-p3 amd64] (local build)
Copyright (C) 2002-12 by Bruce Allen, [url]http://smartmontools.sourceforge.net[/url]

Device is in STANDBY mode, exit(2)
 
I not not so sure that is a bug.

Depending on how your drive is attached will depend on what commands you can send it.

eg

ada (ATA Direct Access device driver) = identify, idle, standby
da (SCSI Direct Access device driver) = inquiry, start, stop

Check the man page for camcontrol as to which driver can accept which commands

My issue here is the command is working, but it's not returning the correct state of the disk. for the ada driver. (da works fine)
So it's probably a bug in the ada driver rather than camcontrol or smartctl.
 
It should probably be a doc bug then. The man page does not straight out say this command is used with this driver and that command is used with that driver. Although looking at it, it does say the inquiry command sends the SCSI command to the device while the identify command sends the ATA identify command to the device.

Maybe they should merge the commands so that it will send the appropriate command based on what the underlying driver is. Then you wouldn't have to worry about it.
 
You must log in or register to reply here.
Back
Top