From: John H. <jo...@ha...> - 2013-04-05 03:27:46
|
I'm debugging smartctl 6.1 on freebsd using the -r ioctl command. We've got mfi devices and in os_freebsd.c at line 965 there is a test for mfi devices and if the test on line 968 succeeds set_err is called with ENOSYS and the message ATA return descriptor not supported by controller firmware is logged. Nothing seems to ever reset 'set_err' so every subsequent ioctl, even if it succeeds, prints out that same message. Is this a 'bug'? 964: // mfi SAT layer is known to be buggy 965: if(!strcmp("mfi",m_camdev->sim_name)) { 966: if (iop->cmnd[0] == SAT_ATA_PASSTHROUGH_12 || iop->cmnd[0] == SAT_ATA_PASSTHROUGH_16) { 967: // Controller does not return ATA output registers in SAT sense data 968: if (iop->cmnd[2] & (1 << 5)) // chk_cond 969: return set_err(ENOSYS, "ATA return descriptor not supported by controller firmware"); 970: } Thanks. ---john. |
From: Alex S. <ml...@os...> - 2013-04-05 09:06:50
|
Hi, This is done before actual call is done and is workaround to avoid sending mentioned commands to the devices on mfi controller. It is known to be buggy and this workaround are required to prevent RAID disk from degradation. On 04/05/2013 05:27 AM, John Haskey wrote: > I'm debugging smartctl 6.1 on freebsd using the -r ioctl command. > > We've got mfi devices and in os_freebsd.c at line 965 there is a test for > mfi devices and if the test on line 968 succeeds set_err is called with > ENOSYS and the message > > ATA return descriptor not supported by controller firmware > > is logged. > > Nothing seems to ever reset 'set_err' so every subsequent ioctl, even if > it succeeds, prints out that same message. > > Is this a 'bug'? > > 964: // mfi SAT layer is known to be buggy > 965: if(!strcmp("mfi",m_camdev->sim_name)) { > 966: if (iop->cmnd[0] == SAT_ATA_PASSTHROUGH_12 || iop->cmnd[0] == SAT_ATA_PASSTHROUGH_16) { > 967: // Controller does not return ATA output registers in SAT sense data > 968: if (iop->cmnd[2] & (1 << 5)) // chk_cond > 969: return set_err(ENOSYS, "ATA return descriptor not supported by controller firmware"); > 970: } > > Thanks. > > ---john. > > ------------------------------------------------------------------------------ > Minimize network downtime and maximize team effectiveness. > Reduce network management and security costs.Learn how to hire > the most talented Cisco Certified professionals. Visit the > Employer Resources Portal > http://www.cisco.com/web/learning/employer_resources/index.html > _______________________________________________ > Smartmontools-support mailing list > Sma...@li... > https://lists.sourceforge.net/lists/listinfo/smartmontools-support > |
From: John H. <jo...@ha...> - 2013-04-05 09:54:51
|
I understand what the code is doing. The question is why does every ioctl after the one that is skipped report the same error? Look at this abridged output here: http://haskey.com/johnh/misc/smart6_abridged.txt The fourth reported ioctl gets the ATA return descriptor not supported message and then so does every ioctl following it. ---john. On Fri, 5 Apr 2013, Alex Samorukov wrote: > Hi, > > This is done before actual call is done and is workaround to avoid sending > mentioned commands to the devices on mfi controller. It is known to be buggy > and this workaround are required to prevent RAID disk from degradation. > > > On 04/05/2013 05:27 AM, John Haskey wrote: >> I'm debugging smartctl 6.1 on freebsd using the -r ioctl command. >> >> We've got mfi devices and in os_freebsd.c at line 965 there is a test for >> mfi devices and if the test on line 968 succeeds set_err is called with >> ENOSYS and the message >> >> ATA return descriptor not supported by controller firmware >> >> is logged. >> >> Nothing seems to ever reset 'set_err' so every subsequent ioctl, even if >> it succeeds, prints out that same message. >> >> Is this a 'bug'? >> >> 964: // mfi SAT layer is known to be buggy >> 965: if(!strcmp("mfi",m_camdev->sim_name)) { >> 966: if (iop->cmnd[0] == SAT_ATA_PASSTHROUGH_12 || iop->cmnd[0] == >> SAT_ATA_PASSTHROUGH_16) { >> 967: // Controller does not return ATA output registers in SAT sense >> data >> 968: if (iop->cmnd[2] & (1 << 5)) // chk_cond >> 969: return set_err(ENOSYS, "ATA return descriptor not supported by >> controller firmware"); >> 970: } >> >> Thanks. >> >> ---john. >> >> >> ------------------------------------------------------------------------------ >> Minimize network downtime and maximize team effectiveness. >> Reduce network management and security costs.Learn how to hire >> the most talented Cisco Certified professionals. Visit the >> Employer Resources Portal >> http://www.cisco.com/web/learning/employer_resources/index.html >> _______________________________________________ >> Smartmontools-support mailing list >> Sma...@li... >> https://lists.sourceforge.net/lists/listinfo/smartmontools-support >> > |
From: Alex S. <ml...@os...> - 2013-04-05 11:06:06
|
On 04/05/2013 11:54 AM, John Haskey wrote: > > I understand what the code is doing. The question is why does every > ioctl after the one that is skipped report the same error? Look at > this abridged output here: > > http://haskey.com/johnh/misc/smart6_abridged.txt > > The fourth reported ioctl gets the ATA return descriptor not supported > message and then so does every ioctl following it. It should not affect actual output, because return code is 0. I will fix this bogus message, but i don’t think that it may cause any real issues. |
From: John H. <jo...@ha...> - 2013-04-05 11:44:36
|
On Fri, 5 Apr 2013, Alex Samorukov wrote: > On 04/05/2013 11:54 AM, John Haskey wrote: >> >> I understand what the code is doing. The question is why does every >> ioctl after the one that is skipped report the same error? Look at >> this abridged output here: >> >> http://haskey.com/johnh/misc/smart6_abridged.txt >> >> The fourth reported ioctl gets the ATA return descriptor not supported >> message and then so does every ioctl following it. > It should not affect actual output, because return code is 0. I will fix > this bogus message, but i don?t think that it may cause any real issues. > Thanks! I'm getting closer to figuring out where my array is getting broken. After a certain command in a certain situation (not entirely clear just yet) the drive being tested starts generating command timeouts and is removed from the array. ---john. |
From: Alex S. <ml...@os...> - 2013-04-05 12:11:27
|
On 04/05/2013 01:44 PM, John Haskey wrote: > >>> http://haskey.com/johnh/misc/smart6_abridged.txt >>> >>> The fourth reported ioctl gets the ATA return descriptor not supported >>> message and then so does every ioctl following it. >> It should not affect actual output, because return code is 0. I will fix >> this bogus message, but i don?t think that it may cause any real issues. >> > > Thanks! I'm getting closer to figuring out where my array is getting > broken. After a certain command in a certain situation (not entirely > clear just yet) the drive being tested starts generating command > timeouts and is removed from the array. > I personally would recommend to send bugreport to lsi/3ware, because it is not smartmontools bug. |
From: John H. <jo...@ha...> - 2013-04-05 19:06:55
|
On Fri, 5 Apr 2013, Alex Samorukov wrote: > I personally would recommend to send bugreport to lsi/3ware, because it is > not smartmontools bug. > Agreed, but I need to figure out how to avoid the issue as we nned to check our drives regardless. Thanks again! ---john. |
From: John H. <jo...@ha...> - 2013-04-06 04:15:32
|
On Fri, 5 Apr 2013, Alex Samorukov wrote: > I personally would recommend to send bugreport to lsi/3ware, because it is > not smartmontools bug. What I'm trying to track down is why does smartmontools 5.39 'work' but 6.0 and above cause the array to break? We need 6.0 for ssd support for our new platform but we also need 6.0 to work on the existing stuff. Don't want to support two versions in the field. ---john. |
From: Alex S. <ml...@os...> - 2013-04-06 18:35:39
|
On 04/06/2013 06:15 AM, John Haskey wrote: > > > On Fri, 5 Apr 2013, Alex Samorukov wrote: > >> I personally would recommend to send bugreport to lsi/3ware, because >> it is not smartmontools bug. > > What I'm trying to track down is why does smartmontools 5.39 'work' > but 6.0 and above cause the array to break? We need 6.0 for ssd > support for our new platform but we also need 6.0 to work on the > existing stuff. Don't want to support two versions in the field. > > ---john. > It works for me on such controllers with FreeBSD and 3ware/LSI. I dont think that smart`ctl -a could make any harm if you have recent firmware installed. |