Re: IDE S.M.A.R.T. ioctl errors

[Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>]

On Monday 28 July 2008, Boris Petkov wrote:
> On Mon, Jul 28, 2008 at 4:44 PM, Bartlomiej Zolnierkiewicz
> <bzolnier@gmail.com> wrote:
> >
> > Hi,
> >
> > On Monday 28 July 2008, Borislav Petkov wrote:
> >
> > [...]
> >
> >> [   32.918048] ide_cmd_ioctl: args[0]: 0xb0, args[1]: 0x1, args[2]: 0xd5 args[3]: 0x1
> >> [   32.918164] hdd: status error: status=0x58 { DriveReady SeekComplete DataRequest }
> >> [   32.918392] ide: failed opcode was: 0xb0
> >> [   32.918491] hdd: drive not ready for command
> >> [   32.918618] hdd: status error: status=0x58 { DriveReady SeekComplete DataRequest }
> >> [   32.918844] ide: failed opcode was: 0xea
> >> [   32.918949] hdd: drive not ready for command
> >> ...
> >>
> >> and this is "caused" by
> >> ide-use-correct-data-phase-for-smart-read-data-log-in-ide_cmd_ioctl.patch. This
> >> happens, IMHO, because when you do ATA_CMD_SMART from userspace ioctl, one of
> >> the cases is that the tf->feature flags have values which are inconsistent with
> >> the ATA/ATAPI v.7 spec (6.54.5 SMART READ DATA):
> >>
> >> "If the device does not support this command, if SMART is disabled, or if the
> >> values in the Features, LBA Mid, or LBA High registers are invalid, the device
> >> shall return command aborted."
> >>
> >> For example this one:
> >>
> >> [   30.499581] ide_cmd_ioctl: args[0]: 0xb0, args[1]: 0x1, args[2]: 0xd1 args[3]: 0x1
> >> [   30.516111] hda: task_no_data_intr: status=0x58 { DriveReady SeekComplete DataRequest }
> >> [   30.516387] ide: failed opcode was: 0xb0
> >>
> >> However, the case with the SMART_READ_LOG looks correct above: args[2] = 0xd5
> >> which is the tf->feature flag, cmd = 0xb0 (ATA_CMD_SMART). This one fails too, though.
> >
> > Thanks for spotting it.
> >
> > It seems that ide_cmd_ioctl() ->data_phase change is not as obvious as
> > I previously thought.  Since the patch is quite low-prio (it prepares
> > the code for future changes) I just dropped it until we learn more about
> > the underlying issues.
> 
> How about aborting the ioctl in all those cases when the relevant
> registers above contain invalid values
> according to the spec? It sounds a pretty sane thing to do...

Dunno, either userspace is doing something really stupid currently
w.r.t. SMART (which I doubt but maybe it really is) or spec doesn't
really meet reality in SMART's case.

Thanks,
Bart