Hi.I saw "no match for command buffer" interrupt storms when I was fixing up aic7xxx for S3. The problem was due to not reprogramming the address of our SCB's on resume. Needed to tell the card the base address for all the DMA structures.
On Wed, 2004-08-11 at 23:13, Nathan Bryant wrote:
ACPI S1 and S4/swsusp are untested, but I think there should be no
regressions with S1. To do S1 properly, we probably need to tell the
drive to spin down, and I don't know what the SCSI command is for
that... For S4, the call to scsi_device_quiesce might pose a problem for
the subsequent state dump to disk. But I'm not sure swsusp ever worked
for SCSI.
I tried it on an OSDL machine and could suspend (suspend 2), but only
resume as far as copying back the original kernel. The problem then
looked to me like it was request ids not matching what the drive was
expecting (but I'm ignorant of scsi, so might be completely wrong
there).
Right, though you also need to get the host adapter's struct device, if you're not already doing so, that is. Many IDE host drivers don't bother with suspend/resume callbacks at the pci_driver level, but SCSI needs callbacks because the BIOS usually doesn't handle things for us.answer is NO. For purposes of not suspending the drivers, I haven't looked into how swsusp would see which host adapter owns which drive, but some of the required information seems to be present in sysfs.
With my 'device tree' code, I'm getting the struct dev of the device
we're using via the struct block_device in the swap_info struct.