• Borislav Petkov's avatar
    ide-tape: fix handling of postponed rqs · 6f3848ac
    Borislav Petkov authored
    ide-tape used to hit
    [   58.614854] ide-tape: ht0: BUG: Two DSC requests queued!
    due to the fact that another rq was being issued while the driver was
    waiting for DSC to get set for the device executing ATAPI commands which
    set the DSC to 1 to indicate completion.
    Here's a sample output of that case:
    issue REZERO_UNIT
    [  143.088505] ide-tape: ide_tape_issue_pc: retry #0, cmd: 0x01
    [  143.095122] ide: Enter ide_pc_intr - interrupt handler
    [  143.096118] ide: Packet command completed, 0 bytes transferred
    [  143.106319] ide-tape: ide_tape_callback: cmd: 0x1, dsc: 1, err: 0
    [  143.112601] ide-tape: idetape_postpone_request: cmd: 0x1, dsc_poll_freq: 2000
    we stall the ide-tape queue here waiting for DSC
    [  143.119936] ide-tape: ide_tape_read_position: enter
    [  145.119019] ide-tape: idetape_do_request: sector: 4294967295, nr_sectors: 0
    and issue the new READ_POSITION rq and hit the check.
    [  145.126247] ide-tape: ht0: BUG: Two DSC requests queued!
    [  145.131748] ide-tape: ide_tape_read_position: BOP - No
    [  145.137059] ide-tape: ide_tape_read_position: EOP - No
    Also, ->postponed_rq used to point to that postponed request. To make
    things worse, in certain circumstances the rq it was pointing to got
    replaced unterneath it by swiftly reusing the same rq from the mempool
    of the block layer practically confusing stuff even more.
    However, we don't need to keep a pointer to that rq but simply wait for
    DSC to be set first before issuing the follow-up request in the drive's
    queue. In order to do that, we make idetape_do_request() first check the
    DSC and if not set, we stall the drive queue giving the other device on
    that IDE channel a chance.
    Signed-off-by: default avatarBorislav Petkov <petkovbb@gmail.com>
    Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
ide-tape.c 54.3 KB