From: Andre B. <and...@er...> - 2006-03-27 15:50:06
|
>Greetings! >Here is the patch for CCISS support in smartctl. Have tested this on a >2.4.26 kernel. Find the diff below. > >diff -Naur smartmontools-5.33/cciss_ioctl.h smartmontools-5.33a/cciss_ioct= l.h >--- smartmontools-5.33/cciss_ioctl.h 1969-12-31 17:00:00.000000000 -0700 >+++ smartmontools-5.33a/cciss_ioctl.h 2005-07-09 14:49:06.000000000 -0600 >@@ -0,0 +1,211 @@ -- snip Hi. I've been browsing the cvs, and I cant see any commits on the CCISS patch. Does anyone know if there is any plans to include this patch to HEAD? I'll take this patch for a spin on 2.4.31 :) /andr=E9 |
From: Bruce A. <ba...@gr...> - 2003-01-17 21:50:33
|
Hi Greg, > Sorry to bother you, but I'd like to ask you one more question. In fact you found a bug in smartctl. I just looked at the code, and while smartctl *should* return bit 6 set if there are errors recorded in the ATA error log, it doesn't. I'm copying your mail to the smartmontools mailing list, so there's a record of this. I just fixed the code in CVS. If you want to test a corrected version of the code, please download the development version from CVS following the instructions at http://smartmontools.sourceforge.net/, or alternatively wait until the next official release after 5.1-1. > I have a drive which I believe is about to fail [1] but for which > smartctl is still returning a zero return code. Does this mean that > the drive has not yet exceeded its threshold values? If so, will > smartctl eventually return a nonzero return code? No, it's just a plain and simple bug. As the man page says: RETURN VALUES The return values of smartctl are defined by a bitmask. <SNIP> Bit 6: The device error log contains records of errors. I forgot to code this. My apologies. It's fixed now. Cheers, Bruce > [1] Usually when this happens, the disk doesn't last for much longer: > > Jan 17 15:02:55 server kernel: hda: drive_cmd: error=0x04 { > DriveStatusError } > Jan 17 15:02:55 server kernel: hda: drive_cmd: status=0x51 { DriveReady > SeekComplete Error } > Jan 17 15:02:55 server kernel: hda: drive_cmd: error=0x04 { > DriveStatusError } > > thanks, -g > > On Tue, 14 Jan 2003, Bruce Allen wrote: > > > Hi Greg, > > > > I am assuming that this is an ATA error (from the ATA error log) NOT a > > self-test error from the self-test error log. > > > > In this case the error is completely harmless. It's probably because > > the hard disk/ATA/UDMA parameters were set wrong at some point when the > > disk was only a few hours old and someone was experimenting with it. > > > > The only time to be concerned about ATA error log entries is when you > > have hundreds or thousands of them in a short time. This is often caused > > by cabling/IDE chipset problems. > > > > You can reset the error count by re-installing/upgrading the disk > > firmware. I think IBM has utilities for doing this, but have not done > > it myself. > > > > Cheers, > > Bruce > > > > > > I suspect that the error is completely har > > > > > Date: Tue, 14 Jan 2003 16:20:07 -0500 (EST) > > > From: Gregory Goddard <ggo...@uf...> > > > X-X-Sender: gr...@ns... > > > To: Bruce Allen <ba...@gr...> > > > Subject: Re: [Fwd: Re: Request for 4 TB RAID fileserver] > > > MIME-Version: 1.0 > > > X-Scanned-By: NERDC Open Systems Group > > (http://open-systems.ufl.edu/services/virus-scan/) > > > > > > > > > Bruce, > > > > > > Is it your experience that if a disk shows a single error, it will fail? > > > > > > I've got an IBM Deathstar reporting via smartctl that it saw one error at > > > disk power-on lifetime: 5 hours. It's been good for over 6 months now and > > > hasn't shown any other signs of problems. > > > > > > Is there a way to reset the error count? > > > > > > -g > > > > > > On Thu, 24 Oct 2002, Bruce Allen wrote: > > > > > > > Dear IVDGL facilities group: > > > > > > > > I've recently done some work to understand why we have had a number of ATA > > > > disks failing on our cluster. As a result, I've written a new version of > > > > the smartd and smartctl programs, which can be used to check the status of > > > > SMART (Self-Monitoring and Reliablity Testing) enabled disks. Most modern > > > > ATA disks support this. The code can be gotten from > > > > http://smartmontools.sourceforge.net/ > > > > > > > > A good way to monitor disks on a cluster is to periodicaly run smartctl > > > > in silent mode on all the nodes > > > > smartctl -qa /dev/hda > > > > and monitor the exit status. If it's nonzero, a SMART problem has been > > > > detected with the disk, and you should investigate further. > > > > > > > > I also recommend, about once per week, doing > > > > smartctl -X /dev/hda > > > > This runs the SMART extended disk self-test routine, which generally takes > > > > about an hour and has little or no effect on system performance. > > > > > > > > Cheers, > > > > Bruce > > > > > > > |
From: Bruce A. <ba...@gr...> - 2004-03-11 15:50:32
|
Ed, The drive in question doesn't support Auto Offline data collection. It is not part of the ATA standard, though it was part of the SFF-8035i standard. Some vendors support Auto Offline data collection for backwards compatibility (IBM, Maxtor, Samsung, and perhaps others). Other vendors don't support it (eg, Toshiba). In any case, the new '-s' option to smartd allows users to do regularly scheduled Offline data collection if they want. Bruce On Thu, 11 Mar 2004, Eduard Martinescu wrote: > Anyone have any clue why this may be happening? I don't THINK that is > the FreeBSD code, but I could be wrong. > > Ed > > -----Forwarded Message----- > > From: Evren Yurtesen <yur...@is...> > To: Eduard Martinescu <mar...@ro...> > Cc: fre...@fr... > Subject: Re: smartmontools startup script problem > Date: Thu, 11 Mar 2004 11:19:04 +0200 > > Here is the problem, I cant enable auto offline data collection every 4 > hours. > > proxy:/usr/local/etc#smartctl -c /dev/ad0 > smartctl version 5.30 Copyright (C) 2002-4 Bruce Allen > Home page is http://smartmontools.sourceforge.net/ > > The SMART RETURN STATUS return value (smartmontools -H option/Directive) > can not be retrieved with this version of ATAng, please do not rely on > this value > === START OF READ SMART DATA SECTION === > General SMART Values: > Offline data collection status: (0x00) Offline data collection activity was > never started. > Auto Offline Data Collection: > Disabled. > Self-test execution status: ( 0) The previous self-test routine > completed > without error or no self-test > has ever > been run. > Total time to complete Offline > data collection: ( 900) seconds. > Offline data collection > capabilities: (0x1b) SMART execute Offline immediate. > Auto Offline data collection > on/off support. > Suspend Offline collection upon new > command. > Offline surface scan supported. > Self-test supported. > No Conveyance Self-test supported. > No Selective Self-test supported. > SMART capabilities: (0x0003) Saves SMART data before entering > power-saving mode. > Supports SMART auto save timer. > Error logging capability: (0x01) Error logging supported. > No General Purpose Logging support. > Short self-test routine > recommended polling time: ( 1) minutes. > Extended self-test routine > recommended polling time: ( 15) minutes. > > proxy:/usr/local/etc#smartctl -o on /dev/ad0 > smartctl version 5.30 Copyright (C) 2002-4 Bruce Allen > Home page is http://smartmontools.sourceforge.net/ > > === START OF ENABLE/DISABLE COMMANDS SECTION === > The SMART RETURN STATUS return value (smartmontools -H option/Directive) > can not be retrieved with this version of ATAng, please do not rely on > this value > SMART Automatic Offline Testing Enabled every four hours. > > proxy:/usr/local/etc#smartctl -c /dev/ad0 > smartctl version 5.30 Copyright (C) 2002-4 Bruce Allen > Home page is http://smartmontools.sourceforge.net/ > > The SMART RETURN STATUS return value (smartmontools -H option/Directive) > can not be retrieved with this version of ATAng, please do not rely on > this value > === START OF READ SMART DATA SECTION === > General SMART Values: > Offline data collection status: (0x00) Offline data collection activity was > never started. > Auto Offline Data Collection: > Disabled. > Self-test execution status: ( 0) The previous self-test routine > completed > without error or no self-test > has ever > been run. > Total time to complete Offline > data collection: ( 900) seconds. > Offline data collection > capabilities: (0x1b) SMART execute Offline immediate. > Auto Offline data collection > on/off support. > Suspend Offline collection upon new > command. > Offline surface scan supported. > Self-test supported. > No Conveyance Self-test supported. > No Selective Self-test supported. > SMART capabilities: (0x0003) Saves SMART data before entering > power-saving mode. > Supports SMART auto save timer. > Error logging capability: (0x01) Error logging supported. > No General Purpose Logging support. > Short self-test routine > recommended polling time: ( 1) minutes. > Extended self-test routine > recommended polling time: ( 15) minutes. > > proxy:/usr/local/etc# > > Eduard Martinescu wrote: > > > Ports was just recently updated to 5.30 (I submitted the patch a couple > > of days ago, and I recall seeing the PR closed). I haven't actually > > tried to setup periodic offline tests. Send me an email with your > > command line, and I will attempt to duplicate. > > > > Ed > > On Wed, 2004-03-10 at 11:51, Evren Yurtesen wrote: > > > > > >>Hi, > >> > >>It is ok. I also think that the never version of smartmontools have a > >>lot of nice features, like doing long offline tests etc. periodically. > >> > >>Will you update the freebsd port? > >> > >>I dont know if this is a FreeBSD issue but I am not able to activate > >>periodic 4hour offline tests in my drives.? do you have such problem? > >> > >>Evren > >> > >>Eduard Martinescu wrote: > >> > >> > >>>Evren, > >>>Sorry it took so long for me to get back to you. I guess I never > >>>noticed any issues because /usr/local/sbin is on the default path for > >>>ROOT for my system. I can look at making a change to include the full > >>>path to the command for a future release of smartmontools. > >>> > >>>Ed > >>>On Sun, 2004-02-29 at 19:41, Evren Yurtesen wrote: > >>> > >>> > >>> > >>>>Hi, > >>>> > >>>>This smartmontools startup script doesnt function properly in my > >>>>5.2-current machine. I fixed the problem by defining the whole path to > >>>>smartd inside the script. Is this normal or something wrong with my > >>>>system? how can I get the paths working at boot time? or should this be > >>>>fixed in the port? > >>>> > >>>>Evren > >>> > >>> > > > -- > Eduard Martinescu <mar...@ro...> > |
From: Sergey S. <sha...@us...> - 2006-04-09 15:44:53
|
On Mon, Mar 27, 2006 at 05:49:41PM +0200, Andre Bergei wrote: >I've been browsing the cvs, and I cant see any commits on the CCISS >patch. Does anyone know if there is any plans to include this patch to >HEAD? I'm inclined to commit it as is, with slight changes that I've mentioned=20 earlier. --=20 Sergey Svishchev |
From: Guido G. <ag...@si...> - 2006-04-10 14:52:23
Attachments:
cciss.diff
|
Hi, On Sun, Apr 09, 2006 at 07:44:44PM +0400, Sergey Svishchev wrote: > On Mon, Mar 27, 2006 at 05:49:41PM +0200, Andre Bergei wrote: > > >I've been browsing the cvs, and I cant see any commits on the CCISS > >patch. Does anyone know if there is any plans to include this patch to > >HEAD? > > I'm inclined to commit it as is, with slight changes that I've mentioned > earlier. that would be nice, if've put your changes together and tested things on 2.6.16. The attached patch should apply to current CVS with reasonable offsets. Cheers, -- Guido |
From: Bruce A. <ba...@gr...> - 2006-04-11 21:15:05
|
Guido, Sergey, If you have (1) tested these patches, and (2) Doug Gilbert has no objections, and (3) user visible changes are DOCUMENTED in the man pages, then then you are welcome to apply the patches to smartmontools CVS if you wish. Cheers, Bruce On Mon, 10 Apr 2006, Guido Guenther wrote: > Hi, > On Sun, Apr 09, 2006 at 07:44:44PM +0400, Sergey Svishchev wrote: >> On Mon, Mar 27, 2006 at 05:49:41PM +0200, Andre Bergei wrote: >> >>> I've been browsing the cvs, and I cant see any commits on the CCISS >>> patch. Does anyone know if there is any plans to include this patch to >>> HEAD? >> >> I'm inclined to commit it as is, with slight changes that I've mentioned >> earlier. > that would be nice, if've put your changes together and tested things on > 2.6.16. The attached patch should apply to current CVS with reasonable > offsets. > Cheers, > -- Guido > |
From: Guido G. <ag...@si...> - 2006-04-12 07:30:16
|
Hi Bruce, On Tue, Apr 11, 2006 at 04:14:54PM -0500, Bruce Allen wrote: > Guido, Sergey, >=20 > If you have >=20 > (1) tested these patches, and > (2) Doug Gilbert has no objections, and > (3) user visible changes are DOCUMENTED in the man pages, then At least smartd will need to be updated too will send a new patch later with also updated documentation. Cheers, -- Guido |
From: Guido G. <ag...@si...> - 2006-04-12 09:54:40
Attachments:
smartmontools-cciss.diff
|
Hi Bruce, On Tue, Apr 11, 2006 at 04:14:54PM -0500, Bruce Allen wrote: > (1) tested these patches, and > (2) Doug Gilbert has no objections, and > (3) user visible changes are DOCUMENTED in the man pages, then Attached is an updated version that also supports smartd not only smartctl. I'll give it some more testing and wait for Doug's comments. Cheers, -- Guido |
From: Douglas G. <do...@to...> - 2006-04-12 20:23:55
|
Guido Guenther wrote: > Hi Bruce, > On Tue, Apr 11, 2006 at 04:14:54PM -0500, Bruce Allen wrote: > >>(1) tested these patches, and >>(2) Doug Gilbert has no objections, and >>(3) user visible changes are DOCUMENTED in the man pages, then > > Attached is an updated version that also supports smartd not only > smartctl. I'll give it some more testing and wait for Doug's comments. Guido, Still trying to get my head around what is happening here. If the cciss support is linux only then shouldn't the (passthrough) changes be isolated to os_linux.c or perhaps os_generic.c ? <snip> > diff -rN -u old-smartmontools-cciss/scsicmds.c new-smartmontools-cciss/scsicmds.c > --- old-smartmontools-cciss/scsicmds.c 2006-02-28 17:38:26.000000000 +0100 > +++ new-smartmontools-cciss/scsicmds.c 2006-04-12 11:17:53.000000000 +0200 > @@ -53,6 +53,26 @@ > /* for passing global control variables */ > extern smartmonctrl *con; > > +// Check and call the right interface. May be when the do_generic_scsi_cmd_io interface is better > +// we can take off this crude way of calling the right interface > + > +static int do_generic_scsi_cmd_io(int dev_fd, struct scsi_cmnd_io * iop, int report) > +{ > + switch(con->controller_type) > + { > + case CONTROLLER_CCISS: > + return cciss_io_interface(dev_fd, con->controller_port-1, iop, report); > + // not reached > + break; > + default: > + return do_generic_scsi_cmd_io(dev_fd, iop, report); > + // not reached > + break; > + } > +} That looks like infinite recursion when con->controller_type!=CONTROLLER_CCISS > - status = do_scsi_cmnd_io(device, &io_hdr, con->reportscsiioctl); > + status = do_generic_scsi_cmd_io(device, &io_hdr, con->reportscsiioctl); So many changes like this?? do_scsi_cmnd_io() is meant to be generic. The replacement function takes the same 3 arguments; I'm not understanding something... Doug Gilbert |
From: Bruce A. <ba...@gr...> - 2006-04-13 13:56:41
|
>> Still trying to get my head around what is happening here. >> If the cciss support is linux only then shouldn't the (passthrough) >> changes be isolated to os_linux.c or perhaps os_generic.c ? > Yes probably. Does any other os have the ioctl passthroughs for cciss, > Freebsd maybe? If so I'll stick it into os_generic.c otherwise into > os_linux.c. I'll wait for comments on that, I won't get around to fix > this before next week anyway since I'm away during the next couple of > days. Please DON'T put this in os_generic.c. That file exists ONLY to act as a TEMPLATE for developers who want to port smartmontools to a new platform. The only time the code in it is EVER called is when smartmontools is built on an unsupported platform. Perhaps it should be called os_unsupported.c or os_template.c Sorry for shouting.... Cheers, Bruce |
From: Douglas G. <do...@to...> - 2006-04-13 17:36:16
|
Bruce Allen wrote: >>> Still trying to get my head around what is happening here. >>> If the cciss support is linux only then shouldn't the (passthrough) >>> changes be isolated to os_linux.c or perhaps os_generic.c ? > > >> Yes probably. Does any other os have the ioctl passthroughs for cciss, >> Freebsd maybe? If so I'll stick it into os_generic.c otherwise into >> os_linux.c. I'll wait for comments on that, I won't get around to fix >> this before next week anyway since I'm away during the next couple of >> days. > > > Please DON'T put this in os_generic.c. That file exists ONLY to act as > a TEMPLATE for developers who want to port smartmontools to a new > platform. The only time the code in it is EVER called is when > smartmontools is built on an unsupported platform. Perhaps it should be > called os_unsupported.c or os_template.c > > Sorry for shouting.... Bruce, Well I feel the same way about what is being proposed for scsicmds.[hc] . Those files should not be touched by this proposed addition. I'm in the process of rolling a new version of the patch, it will compile but I have no hardware to test it on. Do you want this in 5.36 ? Doug Gilbert |
From: Guido G. <ag...@si...> - 2006-04-13 17:44:27
|
On Thu, Apr 13, 2006 at 01:35:56PM -0400, Douglas Gilbert wrote: > Bruce Allen wrote: > >>> Still trying to get my head around what is happening here. > >>> If the cciss support is linux only then shouldn't the (passthrough) > >>> changes be isolated to os_linux.c or perhaps os_generic.c ? > >=20 > >=20 > >> Yes probably. Does any other os have the ioctl passthroughs for cciss, > >> Freebsd maybe? If so I'll stick it into os_generic.c otherwise into > >> os_linux.c. I'll wait for comments on that, I won't get around to fix > >> this before next week anyway since I'm away during the next couple of > >> days. > >=20 > >=20 > > Please DON'T put this in os_generic.c. That file exists ONLY to act as > > a TEMPLATE for developers who want to port smartmontools to a new > > platform. The only time the code in it is EVER called is when > > smartmontools is built on an unsupported platform. Perhaps it should be > > called os_unsupported.c or os_template.c > >=20 > > Sorry for shouting.... >=20 > Bruce, > Well I feel the same way about what is being proposed > for scsicmds.[hc] . Those files should not be touched > by this proposed addition. I'm in the process of rolling > a new version of the patch, it will compile but I have > no hardware to test it on. Not a problem. I can test this on cciss hardware and I'm certainly glad if you split things out of scsimcds.hc. Cheers, -- Guido |
From: Douglas G. <do...@to...> - 2006-04-13 18:44:24
Attachments:
smartmontools-cciss-3.diff
|
Guido Guenther wrote: > On Thu, Apr 13, 2006 at 01:35:56PM -0400, Douglas Gilbert wrote: > >>Bruce Allen wrote: >> >>>>>Still trying to get my head around what is happening here. >>>>>If the cciss support is linux only then shouldn't the (passthrough) >>>>>changes be isolated to os_linux.c or perhaps os_generic.c ? >>> >>> >>>>Yes probably. Does any other os have the ioctl passthroughs for cciss, >>>>Freebsd maybe? If so I'll stick it into os_generic.c otherwise into >>>>os_linux.c. I'll wait for comments on that, I won't get around to fix >>>>this before next week anyway since I'm away during the next couple of >>>>days. >>> >>> >>>Please DON'T put this in os_generic.c. That file exists ONLY to act as >>>a TEMPLATE for developers who want to port smartmontools to a new >>>platform. The only time the code in it is EVER called is when >>>smartmontools is built on an unsupported platform. Perhaps it should be >>>called os_unsupported.c or os_template.c >>> >>>Sorry for shouting.... >> >>Bruce, >>Well I feel the same way about what is being proposed >>for scsicmds.[hc] . Those files should not be touched >>by this proposed addition. I'm in the process of rolling >>a new version of the patch, it will compile but I have >>no hardware to test it on. > > Not a problem. I can test this on cciss hardware and I'm certainly glad > if you split things out of scsimcds.hc. Guido, Could you try the attached? It is against the latest CVS (i.e. "smartmontools release 5.37 dated 2006/04/12 at 17:39:01 UTC"). I changed the '#include "cciss_ioctl.h"' to '#include <linux/cciss_ioctl.h>' as the former failed to compile on my machine. Perhaps we need some automake magic to hide all the stuff that depends on that header if and when the header is not found. Doug Gilbert |
From: Guido G. <ag...@si...> - 2006-04-13 19:15:31
|
Hi Dough, On Thu, Apr 13, 2006 at 02:43:49PM -0400, Douglas Gilbert wrote: > diff -dur old-smartmontools-cciss/os_linux.c new-smartmontools-cciss/os_linux.c > --- old-smartmontools-cciss/os_linux.c 2006-04-12 16:01:05.000000000 -0400 > +++ new-smartmontools-cciss/os_linux.c 2006-04-13 14:21:16.000000000 -0400 > +int do_scsi_cmnd_io(int dev_fd, struct scsi_cmnd_io * iop, int report) > +{ > + switch(con->controller_type) > + { > + case CONTROLLER_CCISS: > + return cciss_io_interface(dev_fd, con->controller_port-1, iop, report); > + // not reached > + break; > + default: > + return do_normal_scsi_cmnd_io(dev_fd, iop, report); > + // not reached > + break; > + } > +} > + > + So you basically moved things into os_linux.c, right? I won't be able to test this soon since I'm mostly travelling the next two weeks and won't have net access to such a machine, I'll check things after that. Anyways, since it won't break anything besides (possibly) cciss I'd say go ahead an commit, I'll fix things up when I'm back then. Cheers, -- Guido |
From: Guido G. <ag...@si...> - 2006-04-27 11:01:42
|
Hi Doug, On Thu, Apr 13, 2006 at 02:43:49PM -0400, Douglas Gilbert wrote: > Guido, > Could you try the attached? It is against the latest > CVS (i.e. "smartmontools release 5.37 dated 2006/04/12 > at 17:39:01 UTC"). >=20 > I changed the '#include "cciss_ioctl.h"' to > '#include <linux/cciss_ioctl.h>' as the former failed > to compile on my machine. Perhaps we need some automake > magic to hide all the stuff that depends on that header > if and when the header is not found. Just tested it and it looks fine. Please apply. Cheers, -- Guido |
From: Bruce A. <ba...@gr...> - 2006-04-13 19:02:36
|
> Bruce, > Well I feel the same way about what is being proposed > for scsicmds.[hc] . Those files should not be touched > by this proposed addition. I'm in the process of rolling > a new version of the patch, it will compile but I have > no hardware to test it on. > > Do you want this in 5.36 ? Too late -- but I'd be happy to release 5.37 quite quickly if you want to "get this out there". My various release scripts are all working correctly so I can do this fast. Cheers, Bruce |
From: Alexander M. <mav@FreeBSD.org> - 2009-10-06 15:54:50
|
> What we have now: Currently we are guessing devices by name in the > smartctl. In smartd autoscan we are adding all devices (with some > exceptions, of course) returned by CAM and ATA enumerators. To detect > USB devices i added simple device detection routine. Also, yesterday, i > committed submitted code for the adaX devices. I have no AHCI > controllers around (my old sata controller exports itself only in pata > compatibility mode), so this code is untested by me. I think such > devices will fail with autodetection in smartd. Also problem is that > user may use "smartctl /dev/passX" command where name guessing will 100% > fail :) > > To solve this, I tried to look in the FreeBSD CAM sources to see best > way for detection device type. I found that we are able to get the > transport type (XPI,SAS,FC,USB(valid only from > FBSD7),ISCSI,PPB,ATA,SATA) using XPT_PATH_INQ ioctl request to the > device descriptor. Also it is possible to get device protocol > (SCSI/ATA/ATAPI), protocol (ATA/ATAPI/SCSI). This way we are able to > detect device type (btw, atapicam sets wrong XPORT_SPI/PROTO_SCSI). > Also this way we are able to detect device type by parsing > sim_vid/hba_vid values. You should use device protocol for determining correct device type. You should use ATA SMART commands for PROTO_ATA devices and SCSI equivalent for PROTO_SCSI and PROTO_ATAPI devices. Transport type should not be important for you. atapicam reports devices as SCSI, but it reports only ATAPI devices, not ATA disks, so there is no problem for you. > I will try to replace parse_ata_chan_dev() and related code with new, > using ATAPI and CAM device type detections. First of all i want to > rewrite get_usb_id function with XPT_PATH_INQ, because this way we will > not need to scan all devices and code will be much easer. > > I will need testers with adaX devices (FreeBSD8 with ahci driver) to > test the ada autodetection, please write me if you want to help. I would like to review result code and I can test it if you need. Also I have code in FreeBSD Perforce repository, wrapping legacy ata(4) subsystem, turning it into real ATA CAM SIM, same as ahci. Wrapper is not finished, but it is mostly working and could be suitable for your tests. If you wish, I can generate diff against HEAD. -- Alexander Motin |
From: Alex S. <ml...@os...> - 2009-10-06 16:10:46
|
Alexander Motin wrote: >> You should use device protocol for determining correct device type. You >> should use ATA SMART commands for PROTO_ATA devices and SCSI equivalent >> for PROTO_SCSI and PROTO_ATAPI devices. Transport type should not be >> important for you. >> atapicam reports devices as SCSI, but it reports only ATAPI devices, not >> ATA disks, so there is no problem for you. >> I already implemented this (protocol based detection for the CAM). Also current code autodetects USB connected devices using cam, but i`m doing it not via transport type, because it is available only starting from FreeBSD7. > >> I will try to replace parse_ata_chan_dev() and related code with new, >> using ATAPI and CAM device type detections. First of all i want to >> rewrite get_usb_id function with XPT_PATH_INQ, because this way we will >> not need to scan all devices and code will be much easer. >> >> I will need testers with adaX devices (FreeBSD8 with ahci driver) to >> test the ada autodetection, please write me if you want to help. >> > > I would like to review result code and I can test it if you need. Also I > have code in FreeBSD Perforce repository, wrapping legacy ata(4) > subsystem, turning it into real ATA CAM SIM, same as ahci. Wrapper is > not finished, but it is mostly working and could be suitable for your > tests. If you wish, I can generate diff against HEAD. > code is already committed to the SVN, and of course, testing is welcome, because i have only very limited number of devices (mostly ATA and SATA, 2 USB drives). Now everything but 3ware should work correctly, i will fix 3ware in a days. And yes, it is interesting for me to test this new cam<->ata code. |
From: Alexander M. <mav@FreeBSD.org> - 2009-10-06 16:53:42
|
Alex Samorukov wrote: >> I would like to review result code and I can test it if you need. Also I >> have code in FreeBSD Perforce repository, wrapping legacy ata(4) >> subsystem, turning it into real ATA CAM SIM, same as ahci. Wrapper is >> not finished, but it is mostly working and could be suitable for your >> tests. If you wish, I can generate diff against HEAD. >> > code is already committed to the SVN, and of course, testing is welcome, > because i have only very limited number of devices (mostly ATA and SATA, > 2 USB drives). Now everything but 3ware should work correctly, i will > fix 3ware in a days. And yes, it is interesting for me to test this new > cam<->ata code. Here is hottest diff against HEAD: http://people.freebsd.org/~mav/cam-ata.20091006.patch To enable wrapper you should add options ATA_CAM into your kernel configuration. Without it, ata(4) will work as before. -- Alexander Motin |
From: Alex S. <ml...@os...> - 2009-10-06 19:22:34
|
Alexander Motin wrote: > >> code is already committed to the SVN, and of course, testing is welcome, >> because i have only very limited number of devices (mostly ATA and SATA, >> 2 USB drives). Now everything but 3ware should work correctly, i will >> fix 3ware in a days. And yes, it is interesting for me to test this new >> cam<->ata code. >> > > Here is hottest diff against HEAD: > http://people.freebsd.org/~mav/cam-ata.20091006.patch > > To enable wrapper you should add > options ATA_CAM > into your kernel configuration. Without it, ata(4) will work as before. > I tried to test your patch. After upgrading kernel i found that my old VIA PCI SATA addon card is now listed as ada0, and first integrated IDE - as ada1, etc. Before devices were numbered in a different way (not a problem, of course). Trying to run smartctl on such devices cause system hangup with "interrupt storm". I only upgraded kernel and libcam (base system is 8-RC1), so possibly problem is somewhere in broken abi. |
From: Andriy G. <av...@ic...> - 2009-10-07 12:48:26
|
Alex, thank you for committing and greatly enhancing ada-related code! I've tested the latest code from svn with ahci driver and everything I tried did work correctly. I tried 'smartctl -a /dev/adaX' and 'smartd -d' with config file with DEVICESCAN in it. -- Andriy Gapon |
From: Alex S. <ml...@os...> - 2009-10-07 14:10:47
|
Andriy Gapon wrote: > Alex, > > thank you for committing and greatly enhancing ada-related code! > I've tested the latest code from svn with ahci driver and everything I tried did > work correctly. > I tried 'smartctl -a /dev/adaX' and 'smartd -d' with config file with DEVICESCAN > in it. > > Great news, thank you for your patches and testing (i have no ada devices around). Today i finished reorganization of os_freebsd.cpp, i hope that source code is now much more readable and easy to maintain. BTW, somebody now when smartmontools package 5.39(RC?) will be released? |
From: Alexander M. <mav@FreeBSD.org> - 2009-10-09 10:31:40
|
Alex Samorukov wrote: > Alexander Motin wrote: >> >>> code is already committed to the SVN, and of course, testing is welcome, >>> because i have only very limited number of devices (mostly ATA and SATA, >>> 2 USB drives). Now everything but 3ware should work correctly, i will >>> fix 3ware in a days. And yes, it is interesting for me to test this new >>> cam<->ata code. >>> >> >> Here is hottest diff against HEAD: >> http://people.freebsd.org/~mav/cam-ata.20091006.patch >> >> To enable wrapper you should add >> options ATA_CAM >> into your kernel configuration. Without it, ata(4) will work as before. >> > I tried to test your patch. After upgrading kernel i found that my old > VIA PCI SATA addon card is now listed as ada0, and first integrated IDE > - as ada1, etc. Before devices were numbered in a different way (not a > problem, of course). Trying to run smartctl on such devices cause system > hangup with "interrupt storm". I only upgraded kernel and libcam (base > system is 8-RC1), so possibly problem is somewhere in broken abi. There was triple error: 1. You are using extremely short command timeout. CAM uses timeouts in milliseconds and you are submitting value 600 there. 2. ata(4) uses timeouts in seconds and conversion was done without proper rounding. 3. there was bug in wrapper in timeout handling, which caused crash. After I have fixed two last bugs, smartctl now works for me on SATA and PATA drives connected via ata(4) wrapper. I have uploaded updated patch. You should also fix timeout there, or it will cause many problems in future. -- Alexander Motin |
From: Andriy G. <av...@ic...> - 2009-10-09 10:48:17
|
on 09/10/2009 13:31 Alexander Motin said the following: > > There was triple error: > 1. You are using extremely short command timeout. CAM uses timeouts in > milliseconds and you are submitting value 600 there. > 2. ata(4) uses timeouts in seconds and conversion was done without > proper rounding. > 3. there was bug in wrapper in timeout handling, which caused crash. > > After I have fixed two last bugs, smartctl now works for me on SATA and > PATA drives connected via ata(4) wrapper. I have uploaded updated patch. > > You should also fix timeout there, or it will cause many problems in future. > Alexander, thanks a lot for this! BTW, Alex, here is tiny patch that fixes one logical error and couple of style deviations: Index: os_freebsd.cpp =================================================================== --- os_freebsd.cpp (revision 2951) +++ os_freebsd.cpp (working copy) @@ -227,7 +227,7 @@ { int failed = 0; // close device, if open - if (get_fd()) + if (is_open()) failed=::close(get_fd()); set_fd(-1); @@ -252,7 +252,7 @@ protected: virtual int ata_command_interface(smart_command_set command, int select, char * data); - virtual int do_cmd(struct ata_ioc_request* request); + virtual int do_cmd(struct ata_ioc_request* request); }; freebsd_ata_device::freebsd_ata_device(smart_interface * intf, const char * dev_name, const char * req_type) @@ -282,7 +282,7 @@ int m_fd; struct cam_device *m_camdev; - virtual int do_cmd( struct ata_ioc_request* request); + virtual int do_cmd( struct ata_ioc_request* request); }; bool freebsd_atacam_device::open(){ -- Andriy Gapon |
From: Alex S. <ml...@os...> - 2009-10-09 12:08:51
|
Andriy Gapon wrote: > > BTW, Alex, here is tiny patch that fixes one logical error and couple of style > deviations: > Committed, thanks! Please, next time submit patches in attachment or using but tracker, it`s annoying to apply them manually :) |