Re: [PATCH] SCSI midlayer power management

Pavel Machek
2004-08-12T07:43:38Z

Hi!

> >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).
> >
> >
> 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.
>
> Just to speculate about what would be required for swsusp: you probably
> need to be using a SCSI LLD that properly implements pci suspend/resume,
> which implies you need to make sure the card's DMA state machine is
> flushed and idle before suspend completes. I've got a patch that fixes
> this much up for aic7xxx. And my other midlayer-level patch may also
> help... What happens during resume is interesting. I think maybe the
> problem is not what the drive is expecting, but what the card's state
> engine is expecting when it tries to map commands to command buffers in
> DMA space. Maybe you need to suspend the LLD from the context of the
> kernel that is doing the image load, and then resume from the context of
> the kernel that was just loaded.

Ideally, suspended driver should have no state at all. Like if I send
card to suspend with 2.6.8, and when I send it to suspend in 2.6.11,
it should be in same state.

> Sounds like this is why Pavel is asking about DMA. So he'll need to
> manage calling the host adapter's suspend callbacks, not just
> generic_scsi_suspend. DMA base addresses are likely to change when you
> load the new kernel image

sysfs should call host adapter's suspend callbacks... It should work
today.
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!