> Doing so will create havoc on sequential devices, such as tape drives. If
> your system simply suspends, then all is well. Any data that isn't flushed
> yet is buffered inside the tapedrive. But when the system resumes and resets
> the SCSI bus, it will cause all data in the tape drive to be lost, and for
> most tape systems it will also re-position them at LBOT. Any running
> tar/dump/whatever tape process would not survive such a suspend-resume
> cycle.
>
Well, why reset the scsi bus on resume then?
That seems unnecessary. At suspend time the devices simply
don't get more requests. (Except perhaps spin-down
requests for disks.) Then nothing much happens. Eventually
the system wakes up, and requests appear again. First spin-up
requests, then ordinary io.
Quite a few scsi bioses have an option for not resetting
the bus when booting. Less delay, and necessary for those
few with a shared scsi bus. Seems a reset won't be
necessary for suspend/resume either, which is supposed to
be a lighter operation than a reboot.
If your scsi adapter don't support this - it isn't
suspend/resume compatible the way I see it.
Helge Hafting
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/