Re: ATA TRIM?

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

[Replying to two messages at once here, both from the same person]

[First message]
>> printf("TRIM %s: calling exec\n",device_xname(wd->sc_dev));
>>                           rv = wd->atabus->ata_exec_command(wd->drvp,&cmd);
>> printf("TRIM %s: returned %d\n",device_xname(wd->sc_dev),rv);
>>                           return(0);

> ata_exec_command() will start the command, but, the completion of it
> is usually signalled by an interrupt.  Presumably, the 9.2
> ATA-related code takes care of this as ata_exec_command() takes a
> `xfer' parameter rather than a bare command struct.  How does 5.2
> wait for ATA command completion?

I will have to dig into that more.  It does seem to be waiting, in that
the call does not return until the thirty seconds specified in the
timeout field have elapsed.  (It then takes about another 30s before
printing the cache-flush timeout message and returning to userland.)

Since the data on the device is still there afterwards, I don't think
it's just a question of not correctly handling completion.  If it were,
I'd expect the operation to work in the sense of dropping the blocks
described by the argument values.

[Other message]
>>        case ATAIOCTRIM:
>>                         { unsigned char rq[512];
>>                           struct ata_command cmd;
...
>>                           rv = wd->atabus->ata_exec_command(wd->drvp,&cmd);
>> printf("TRIM %s: returned %d\n",device_xname(wd->sc_dev),rv);
>>                           return(0);
>>                         }

> Ah, shouldn't `cmd' be allocated memory rather than being a
> locally-scoped variable?

Why?  cmd.flags specifies AT_WAIT, and as I remarked above it is indeed
waiting, so cmd, on the kernel stack, should outlive the I/O attempt.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B