Re: Adding disk firmware programming capability to camcontrol
On Tue, Nov 22, 2011 at 03:47:41PM +, Nima Misaghian wrote: We have added firmware download command to atacontrol at work, for which I have attached a patch against 8.2 to this email. The format of the command is similar to the camcontrol counterpart: atacontrol fwdownload device_name path_to_image_file But ultimately we would like to add the support to program ATA/SATA disks to camcontrol as well. I've cleaned up the patch slightly and added the fwdownload details to the man page. The most recent patch is here: http://people.freebsd.org/~emaste/atacontrol.diff I expect this to get committed in the next couple of days, with the intent of MFCing it to older branches which do not use ATA-CAM. The final goal is to get camcontrol to grow the ability to update ATA disks as well via ATA-CAM. -Ed ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
RE: Adding disk firmware programming capability to camcontrol
Hi, Sorry for the late reply. As I mentioned in the man page, the fwdownload command currently only supports SCSI disks. fwdownload: Program firmware of the named SCSI device using the image file provided. We have added firmware download command to atacontrol at work, for which I have attached a patch against 8.2 to this email. The format of the command is similar to the camcontrol counterpart: atacontrol fwdownload device_name path_to_image_file But ultimately we would like to add the support to program ATA/SATA disks to camcontrol as well. Nima Misaghian nmisagh...@sandvine.com -Original Message- From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd- curr...@freebsd.org] On Behalf Of Pegasus Mc Cleaft Sent: Sunday, November 20, 2011 9:55 AM To: freebsd-current@freebsd.org Cc: an...@albsmeier.net; Nima Misaghian Subject: Re: Adding disk firmware programming capability to camcontrol Hi Nima, I have tried your latest patch against current, but I am having difficulty getting it to work. I was wondering, is this feature limited to SCSI drives? I have been trying it against my SATA drives but it looks like it is failing on issuing a TUR. IE: feathers# camcontrol fwdownload ada5 -f JP0NB3MA.BD -s -v Running in simulation mode camcontrol: Device is not ready (pass5:ahcich4:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (pass5:ahcich4:0:0:0): CAM status: CCB request was invalid Firmware download failed I have tried issuing a TUR to all my drives to see if it was controller or drive specific, but all of them return the same error (The drives are Seagate, Hitachi and WD). What am I doing wrong? Ta Peg ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current- unsubscr...@freebsd.org atacontrol.diff Description: atacontrol.diff ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Adding disk firmware programming capability to camcontrol
Hi Nima, I have tried your latest patch against current, but I am having difficulty getting it to work. I was wondering, is this feature limited to SCSI drives? I have been trying it against my SATA drives but it looks like it is failing on issuing a TUR. IE: feathers# camcontrol fwdownload ada5 -f JP0NB3MA.BD -s -v Running in simulation mode camcontrol: Device is not ready (pass5:ahcich4:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (pass5:ahcich4:0:0:0): CAM status: CCB request was invalid Firmware download failed I have tried issuing a TUR to all my drives to see if it was controller or drive specific, but all of them return the same error (The drives are Seagate, Hitachi and WD). What am I doing wrong? Ta Peg ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Adding disk firmware programming capability to camcontrol
on 20/11/2011 16:54 Pegasus Mc Cleaft said the following: Hi Nima, I have tried your latest patch against current, but I am having difficulty getting it to work. I was wondering, is this feature limited to SCSI drives? I have been trying it against my SATA drives but it looks like it is failing on issuing a TUR. IE: feathers# camcontrol fwdownload ada5 -f JP0NB3MA.BD -s -v Running in simulation mode camcontrol: Device is not ready (pass5:ahcich4:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (pass5:ahcich4:0:0:0): CAM status: CCB request was invalid Firmware download failed I have tried issuing a TUR to all my drives to see if it was controller or drive specific, but all of them return the same error (The drives are Seagate, Hitachi and WD). What am I doing wrong? You are sending SCSI commands to a (S)ATA drive. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Adding disk firmware programming capability to camcontrol
On Sunday 20 November 2011 15:24:41 Andriy Gapon wrote: I have tried issuing a TUR to all my drives to see if it was controller or drive specific, but all of them return the same error (The drives are Seagate, Hitachi and WD). What am I doing wrong? You are sending SCSI commands to a (S)ATA drive. Ah... Bummer... I thought that might be the issue. I had kind of hoped that the code would also handle the ATA drives as well, but still this will be a great feature to have in camcontrol as it is. Thanks Peg ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Adding disk firmware programming capability to camcontrol
On Sun, Nov 20, 2011 at 7:44 AM, Pegasus Mc Cleaft k...@mthelicon.com wrote: On Sunday 20 November 2011 15:24:41 Andriy Gapon wrote: I have tried issuing a TUR to all my drives to see if it was controller or drive specific, but all of them return the same error (The drives are Seagate, Hitachi and WD). What am I doing wrong? You are sending SCSI commands to a (S)ATA drive. Ah... Bummer... I thought that might be the issue. I had kind of hoped that the code would also handle the ATA drives as well, but still this will be a great feature to have in camcontrol as it is. Enhancements will need to be added to pass through the right commands from CAM_ATA to the ata layer. Cheers, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
RE: Adding disk firmware programming capability to camcontrol
I have updated the patch according to feedbacks I received. The main modification was to warn the user and ask for confirmation before downloading a firmware image. A -y option has been added that suppresses the confirmation-- the same as the one for the format command. The new patch is against HEAD and could be downloaded from: http://people.freebsd.org/~emaste/patches/fwdownload.diff Reviews/suggestions are greatly appreciated. Nima Misaghian nmisagh...@sandvine.com -Original Message- From: crodr...@gmail.com [mailto:crodr...@gmail.com] On Behalf Of Craig Rodrigues Sent: Thursday, November 03, 2011 10:06 PM To: Nima Misaghian Cc: freebsd-current@freebsd.org Subject: Re: Adding disk firmware programming capability to camcontrol On Fri, Oct 28, 2011 at 1:47 PM, Nima Misaghian nmisagh...@sandvine.com wrote: Hi, I have got code developed by Andre Albsmeier that is capable of programming firmware of hard drives from several vendors and turned it into a camcontrol command. +1 I took a look at your patch and it looks great. I have worked on a storage product before where there was a requirement to reprogram the firmware of hard drives. On tha product, proprietary Windows tools had to be used. It would have been nice to be able to use camcontrol in FreeBSD. I think the patch is fine in its current form. Very few regular users need to reprogram hard drive firmware. It is a special administrative operation. -- Craig Rodrigues rodr...@crodrigues.org fwdownload.diff Description: fwdownload.diff ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Adding disk firmware programming capability to camcontrol
On Thu, Nov 03, 2011 at 07:05:54PM -0700, Craig Rodrigues wrote: On Fri, Oct 28, 2011 at 1:47 PM, Nima Misaghian nmisagh...@sandvine.com wrote: Hi, I have got code developed by Andre Albsmeier that is capable of programming firmware of hard drives from several vendors and ?turned it into a camcontrol command. ... I think the patch is fine in its current form. Very few regular users need to reprogram hard drive firmware. It is a special administrative operation. Thanks for reviewing. I discussed it with Ken Merry off-list and he mentioned the format command, which has a similar requirement. It has a -y flag to confirm the operation from the command line, and prompts for confirmation if the flag is not provided. Mirroring that behaviour sounds reasonable to me; we'll update the patch with that change before it gets committed. -Ed ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
RE: Adding disk firmware programming capability to camcontrol
On 29 Oct 2011 00:38, Pegasus Mc Cleaft k...@mthelicon.com wrote: The linux hdparm program is so paranoid about this that you have to use extra arguments like --yes-really-destroy-my-disk-drive to do this. I concur. Loudly. The ability to brick your hardware is just too large to not make people go through the I tell you three times dance. It's not like people will do this often enough that the pain will be fatal. And if it is, they ought to be bright enough to know how to automate the process. --lyndon Hi Lyndon and group, I tend to disagree that there should be such argument antics employed to protect an operation such as this. Being root should be the only protection needed (of course, that's only my opinion). I don’t want to have to look up in a man page what magic token I need to add to prove to the utility that I understand the consequences of what I am about to do. I personally wouldn't mind a simple Are you sure? if the magic token is not added on the command line, however. To me, the only difference between borking a drive because of bad firmware and typing rm -rf * from root is about £40. You still lose at least a day rebuilding/restoring everything. You clearly haven't bought a hard drive recently. Chris ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
RE: Adding disk firmware programming capability to camcontrol
To me, the only difference between borking a drive because of bad firmware and typing rm -rf * from root is about £40. You still lose at least a day rebuilding/restoring everything. You clearly haven't bought a hard drive recently. Chris Laughs! Yea, trust karma to insert my foot into my mouth when I open it to speak 8-) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
RE: Adding disk firmware programming capability to camcontrol
On 4 Nov 2011 16:33, Pegasus Mc Cleaft k...@mthelicon.com wrote: To me, the only difference between borking a drive because of bad firmware and typing rm -rf * from root is about £40. You still lose at least a day rebuilding/restoring everything. You clearly haven't bought a hard drive recently. Chris Laughs! Yea, trust karma to insert my foot into my mouth when I open it to speak 8-) Never mind ;) I do take issue with this viewpoint however; in documentation this is the difference between Caution (you may lose data) and Warning (you may break your hardware). Why should the software be inconsistent with the hardware? I think an option *specifically for this task* would be useful as confirmation. I'm really sorry for bikeshedding; the code and idea is excellent, but I feel this issue is important! Chris ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Adding disk firmware programming capability to camcontrol
On Fri, Oct 28, 2011 at 1:47 PM, Nima Misaghian nmisagh...@sandvine.com wrote: Hi, I have got code developed by Andre Albsmeier that is capable of programming firmware of hard drives from several vendors and turned it into a camcontrol command. +1 I took a look at your patch and it looks great. I have worked on a storage product before where there was a requirement to reprogram the firmware of hard drives. On tha product, proprietary Windows tools had to be used. It would have been nice to be able to use camcontrol in FreeBSD. I think the patch is fine in its current form. Very few regular users need to reprogram hard drive firmware. It is a special administrative operation. -- Craig Rodrigues rodr...@crodrigues.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Adding disk firmware programming capability to camcontrol
On Fri, Oct 28, 2011 at 1:47 PM, Nima Misaghian nmisagh...@sandvine.com wrote: Hi, I have got code developed by Andre Albsmeier that is capable of programming firmware of hard drives from several vendors and turned it into a camcontrol command. The posted patch (against RELENG_8_2) basically adds the following new command to camcontrol: camcontrol fwdownload [device id] [generic args] -f fw_image [-s] I would appreciate it if FreeBSD experts in this area of code would take the time to review this patch. This is awesome! I'm not a CAM expert, but I'll definitely take a look it this weekend. -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Adding disk firmware programming capability to camcontrol
This is a good idea, except that it makes me really really nervous. I do not believe that fw downloads are generic enough to encapsulate. I've used camcontrol recently to tunnel an ATA command through mpt2 that does an ATA DOWNLOAD FW (mode 7), but that is only because it is a specific drive that I've validated works correctly. The linux hdparm program is so paranoid about this that you have to use extra arguments like --yes-really-destroy-my-disk-drive to do this. I'm very very nervous about putting it into camcontrol. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Adding disk firmware programming capability to camcontrol
The linux hdparm program is so paranoid about this that you have to use extra arguments like --yes-really-destroy-my-disk-drive to do this. I concur. Loudly. The ability to brick your hardware is just too large to not make people go through the I tell you three times dance. It's not like people will do this often enough that the pain will be fatal. And if it is, they ought to be bright enough to know how to automate the process. --lyndon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
RE: Adding disk firmware programming capability to camcontrol
The linux hdparm program is so paranoid about this that you have to use extra arguments like --yes-really-destroy-my-disk-drive to do this. I concur. Loudly. The ability to brick your hardware is just too large to not make people go through the I tell you three times dance. It's not like people will do this often enough that the pain will be fatal. And if it is, they ought to be bright enough to know how to automate the process. --lyndon Hi Lyndon and group, I tend to disagree that there should be such argument antics employed to protect an operation such as this. Being root should be the only protection needed (of course, that's only my opinion). I dont want to have to look up in a man page what magic token I need to add to prove to the utility that I understand the consequences of what I am about to do. I personally wouldn't mind a simple Are you sure? if the magic token is not added on the command line, however. To me, the only difference between borking a drive because of bad firmware and typing rm -rf * from root is about £40. You still lose at least a day rebuilding/restoring everything. IMHO Peg ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Adding disk firmware programming capability to camcontrol
On 10/28/11 3:43 PM, Lyndon Nerenberg (VE6BBM/VE7TFX) wrote: The linux hdparm program is so paranoid about this that you have to use extra arguments like --yes-really-destroy-my-disk-drive to do this. I concur. Loudly. The ability to brick your hardware is just too large to not make people go through the I tell you three times dance. It's not like people will do this often enough that the pain will be fatal. And if it is, they ought to be bright enough to know how to automate the process. Camcontrol is used pretty much exclusively by people who should understand the risks. and you have to be root. Unix's job is to reliably and efficiently deliver the bullet to your foot should you so desire. Put in some of these safety belts and add it I think.. --lyndon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Adding disk firmware programming capability to camcontrol
On Fri, Oct 28, 2011 at 4:37 PM, Pegasus Mc Cleaft k...@mthelicon.com wrote: The linux hdparm program is so paranoid about this that you have to use extra arguments like --yes-really-destroy-my-disk-drive to do this. I concur. Loudly. The ability to brick your hardware is just too large to not make people go through the I tell you three times dance. It's not like people will do this often enough that the pain will be fatal. And if it is, they ought to be bright enough to know how to automate the process. --lyndon Hi Lyndon and group, I tend to disagree that there should be such argument antics employed to protect an operation such as this. Being root should be the only protection needed (of course, that's only my opinion). I don’t want to have to look up in a man page what magic token I need to add to prove to the utility that I understand the consequences of what I am about to do. I personally wouldn't mind a simple Are you sure? if the magic token is not added on the command line, however. To me, the only difference between borking a drive because of bad firmware and typing rm -rf * from root is about £40. You still lose at least a day rebuilding/restoring everything. Unfortunately not backs up their systems on a regular basis. Having an interactive prompt with a loud warning like many vendor tools provide today with a non-interactive override option is sufficient. That being said, camcontrol doesn't understand the concept of interactive vs non-interactive use, so it seems like its design would need to be redone if you go this route. Thanks, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
