Re: [PATCH] SCSI midlayer power management

[Pavel Machek <pavel@suse.cz>]

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!