Hi Bart,
i'm getting the following when the S.M.A.R.T. daemon starts during boot (verbose
printk added by me):
...
[ 29.974243] ide_cmd_ioctl: args[0]: 0xec, args[1]: 0x0, args[2]: 0x0 args[3]: 0x1
[ 30.052422] ide_cmd_ioctl: args[0]: 0xb0, args[1]: 0x1, args[2]: 0xd8 args[3]: 0x0
[ 30.361782] ide_cmd_ioctl: args[0]: 0xb0, args[1]: 0x0, args[2]: 0xd0 args[3]: 0x1
[ 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
[ 30.516510] hda: status error: status=0x58 { DriveReady SeekComplete DataRequest }
[ 30.517423] ide: failed opcode was: unknown
[ 30.517730] hda: drive not ready for command
[ 30.517793] ide_cmd_ioctl: args[0]: 0xb0, args[1]: 0x6, args[2]: 0xd5 args[3]: 0x1
[ 30.551903] ide_cmd_ioctl: args[0]: 0xb0, args[1]: 0x1, args[2]: 0xd5 args[3]: 0x1
[ 30.585392] ide_cmd_ioctl: args[0]: 0xec, args[1]: 0x0, args[2]: 0x0 args[3]: 0x1
[ 30.605220] ide_cmd_ioctl: args[0]: 0xb0, args[1]: 0x1, args[2]: 0xd8 args[3]: 0x0
[ 30.850747] ide_cmd_ioctl: args[0]: 0xb0, args[1]: 0x0, args[2]: 0xd0 args[3]: 0x1
[ 31.000050] ide_cmd_ioctl: args[0]: 0xb0, args[1]: 0x1, args[2]: 0xd1 args[3]: 0x1
[ 31.087848] hdb: task_no_data_intr: status=0x58 { DriveReady SeekComplete DataRequest }
[ 31.088124] ide: failed opcode was: 0xb0
[ 31.088409] ide_cmd_ioctl: args[0]: 0xb0, args[1]: 0x6, args[2]: 0xd5 args[3]: 0x1
[ 31.101375] hdb: status error: status=0x58 { DriveReady SeekComplete DataRequest }
[ 31.101681] ide: failed opcode was: 0xb0
[ 31.101775] hdb: drive not ready for command
[ 31.101964] ide_cmd_ioctl: args[0]: 0xb0, args[1]: 0x1, args[2]: 0xd5 args[3]: 0x1
[ 31.128299] hdb: status error: status=0x58 { DriveReady SeekComplete DataRequest }
[ 31.128571] ide: failed opcode was: 0xb0
[ 31.128669] hdb: drive not ready for command
[ 31.144786] hdb: status error: status=0x58 { DriveReady SeekComplete DataRequest }
[ 31.145060] ide: failed opcode was: 0xea
[ 31.145166] hdb: drive not ready for command
[ 31.599369] hdc: No disk in drive
[ 32.105234] ide_cmd_ioctl: args[0]: 0xa1, args[1]: 0x0, args[2]: 0x0 args[3]: 0x1
[ 32.162295] ide_cmd_ioctl: args[0]: 0xec, args[1]: 0x0, args[2]: 0x0 args[3]: 0x1
[ 32.168927] ide_cmd_ioctl: args[0]: 0xb0, args[1]: 0x1, args[2]: 0xd8 args[3]: 0x0
[ 32.339912] ide_cmd_ioctl: args[0]: 0xb0, args[1]: 0x0, args[2]: 0xd0 args[3]: 0x1
[ 32.439278] ide_cmd_ioctl: args[0]: 0xb0, args[1]: 0x1, args[2]: 0xd1 args[3]: 0x1
[ 32.491542] hdd: task_no_data_intr: status=0x58 { DriveReady SeekComplete DataRequest }
[ 32.491820] ide: failed opcode was: 0xb0
[ 32.492105] ide_cmd_ioctl: args[0]: 0xb0, args[1]: 0x6, args[2]: 0xd5 args[3]: 0x1
[ 32.492247] hdd: status error: status=0x58 { DriveReady SeekComplete DataRequest }
[ 32.492531] ide: failed opcode was: 0xb0
[ 32.492629] hdd: drive not ready for command
[ 32.493059] ide_cmd_ioctl: args[0]: 0xb0, args[1]: 0x1, args[2]: 0xd5 args[3]: 0x1
[ 32.493175] hdd: status error: status=0x58 { DriveReady SeekComplete DataRequest }
[ 32.493454] ide: failed opcode was: 0xb0
[ 32.493551] hdd: drive not ready for command
[ 32.494440] hdd: status error: status=0x58 { DriveReady SeekComplete DataRequest }
[ 32.494733] ide: failed opcode was: 0xea
[ 32.494850] hdd: drive not ready for command
[ 32.614821] ide_cmd_ioctl: args[0]: 0xb0, args[1]: 0x0, args[2]: 0xd0 args[3]: 0x1
[ 32.752564] ide_cmd_ioctl: args[0]: 0xb0, args[1]: 0x6, args[2]: 0xd5 args[3]: 0x1
[ 32.815267] ide_cmd_ioctl: args[0]: 0xb0, args[1]: 0x1, args[2]: 0xd5 args[3]: 0x1
[ 32.875133] hdb: status error: status=0x58 { DriveReady SeekComplete DataRequest }
[ 32.875443] ide: failed opcode was: 0xb0
[ 32.875559] hdb: drive not ready for command
[ 32.875991] ide_cmd_ioctl: args[0]: 0xb0, args[1]: 0x0, args[2]: 0xd0 args[3]: 0x1
[ 32.889735] hdb: status error: status=0x58 { DriveReady SeekComplete DataRequest }
[ 32.890006] ide: failed opcode was: 0xb0
[ 32.890100] hdb: drive not ready for command
[ 32.890453] ide_cmd_ioctl: args[0]: 0xb0, args[1]: 0x6, args[2]: 0xd5 args[3]: 0x1
[ 32.891249] hdb: status error: status=0x58 { DriveReady SeekComplete DataRequest }
[ 32.891260] ide: failed opcode was: 0xb0
[ 32.891278] hdb: drive not ready for command
[ 32.891625] ide_cmd_ioctl: args[0]: 0xb0, args[1]: 0x1, args[2]: 0xd5 args[3]: 0x1
[ 32.904268] hdb: status error: status=0x58 { DriveReady SeekComplete DataRequest }
[ 32.904579] ide: failed opcode was: 0xb0
[ 32.904704] hdb: drive not ready for command
[ 32.916044] hdb: status error: status=0x58 { DriveReady SeekComplete DataRequest }
[ 32.916317] ide: failed opcode was: 0xea
[ 32.916417] hdb: drive not ready for command
[ 32.916519] hdd: status error: status=0x58 { DriveReady SeekComplete DataRequest }
[ 32.916762] ide: failed opcode was: 0xb0
[ 32.916875] hdd: drive not ready for command
[ 32.916959] ide_cmd_ioctl: args[0]: 0xb0, args[1]: 0x0, args[2]: 0xd0 args[3]: 0x1
[ 32.917071] hdd: status error: status=0x58 { DriveReady SeekComplete DataRequest }
[ 32.917313] ide: failed opcode was: 0xb0
[ 32.917419] hdd: drive not ready for command
[ 32.917507] ide_cmd_ioctl: args[0]: 0xb0, args[1]: 0x6, args[2]: 0xd5 args[3]: 0x1
[ 32.917618] hdd: status error: status=0x58 { DriveReady SeekComplete DataRequest }
[ 32.917864] ide: failed opcode was: 0xb0
[ 32.917971] hdd: drive not ready for command
[ 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.
--
Regards/Gru?,
Boris.
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.
Bart
On Mon, Jul 28, 2008 at 4:44 PM, Bartlomiej Zolnierkiewicz
<[email protected]> 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...
--
Regards/Gru?,
Boris
On Monday 28 July 2008, Boris Petkov wrote:
> On Mon, Jul 28, 2008 at 4:44 PM, Bartlomiej Zolnierkiewicz
> <[email protected]> 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
If we're going to continue to keep drivers/ide on life-support,
then perhaps one should just add SG_IO::ATA_16 support into it
and leave the "legacy" ioctls alone.
I've done this for linux-2.2.xx (really!), and the patch was rather
tiny indeed -- and that custom kernel now supports all of the fancy
ioctl() needs of hdparm-8.9 and smartctl.
Perhaps a similar patch for drivers/ide ?
Here's my 2.2.xx hack for perusal:
http://empeg-hijack.sourceforge.net/patches/relative/v489-v490.patch.gz
It won't work on current kernels, of course, but perhaps something similar would.
Cheers
On Monday 28 July 2008, Mark Lord wrote:
> If we're going to continue to keep drivers/ide on life-support,
> then perhaps one should just add SG_IO::ATA_16 support into it
> and leave the "legacy" ioctls alone.
I was actually hoping that somebody will came with this idea (+ patch)
after we unified all separate taskfile execution code-paths and added
struct ide_taskfile (the code is now much more similiar to libata then
it is to old IDE one).
> I've done this for linux-2.2.xx (really!), and the patch was rather
> tiny indeed -- and that custom kernel now supports all of the fancy
> ioctl() needs of hdparm-8.9 and smartctl.
>
> Perhaps a similar patch for drivers/ide ?
>
> Here's my 2.2.xx hack for perusal:
> http://empeg-hijack.sourceforge.net/patches/relative/v489-v490.patch.gz
>
> It won't work on current kernels, of course, but perhaps something similar would.
Thanks, your 2.2.x patch proves the idea well but we need something
more similar to the current libata code for 2.6.x (the resulting patch
should be both smaller and the easier to make than old IDE backport).
Bart