From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pavel Machek Subject: Re: [PATCH] SCSI midlayer power management Date: Thu, 12 Aug 2004 09:43:04 +0200 Sender: linux-scsi-owner@vger.kernel.org Message-ID: <20040812074304.GD29466@elf.ucw.cz> References: <4119611D.60401@optonline.net> <20040811080935.GA26098@elf.ucw.cz> <411A1B72.1010302@optonline.net> <1092262602.3553.14.camel@laptop.cunninghams> <411AA24C.6050303@optonline.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from gprs214-50.eurotel.cz ([160.218.214.50]:21636 "EHLO amd.ucw.cz") by vger.kernel.org with ESMTP id S268439AbUHLHn3 (ORCPT ); Thu, 12 Aug 2004 03:43:29 -0400 Content-Disposition: inline In-Reply-To: <411AA24C.6050303@optonline.net> List-Id: linux-scsi@vger.kernel.org To: Nathan Bryant Cc: ncunningham@linuxmail.org, 'James Bottomley' , Linux SCSI Reflector , Linux Kernel Mailing List , jgarzik@pobox.com 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!