> + * If we are in an interrupt, it should be safe to issue
> + * SETFEATURES manually, since there shouldn't be any requests in
> + * flight.
There may be error recovery going on from a timeout on another processor.
I don't see how your code protects against that (and the old code
+ * If we are in an interrupt, it should be safe to issue
+ * SETFEATURES manually, since there shouldn't be any requests in
+ * flight.
There may be error recovery going on from a timeout on another processor.
I don't see how your code protects against that (and the old code is
On Wednesday 21 February 2007 02:21, Suleiman Souhlal wrote:
> Use ide_wait_cmd() in ide_config_drive_speed() if the drive has been
> initialized and we're not in an interrupt, to avoid changing the
> xfer speed while requests are in flight.
Many devices have problems with SETFEATURES_XFER if
Use ide_wait_cmd() in ide_config_drive_speed() if the drive has been
initialized and we're not in an interrupt, to avoid changing the
xfer speed while requests are in flight.
An easy way to trigger the problem is to dd the disk while doing
while :; do hdparm -d 1 /dev/hdc> /dev/null; done
While
Use ide_wait_cmd() in ide_config_drive_speed() if the drive has been
initialized and we're not in an interrupt, to avoid changing the
xfer speed while requests are in flight.
An easy way to trigger the problem is to dd the disk while doing
while :; do hdparm -d 1 /dev/hdc /dev/null; done
While
On Wednesday 21 February 2007 02:21, Suleiman Souhlal wrote:
Use ide_wait_cmd() in ide_config_drive_speed() if the drive has been
initialized and we're not in an interrupt, to avoid changing the
xfer speed while requests are in flight.
Many devices have problems with SETFEATURES_XFER if the
6 matches
Mail list logo
