From owner-freebsd-current@FreeBSD.ORG Wed Jun 11 00:08:02 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D9DEE37B401; Wed, 11 Jun 2003 00:08:02 -0700 (PDT) Received: from puffin.mail.pas.earthlink.net (puffin.mail.pas.earthlink.net [207.217.120.139]) by mx1.FreeBSD.org (Postfix) with ESMTP id 46CC643FD7; Wed, 11 Jun 2003 00:07:58 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from user-38lc0s4.dialup.mindspring.com ([209.86.3.132] helo=mindspring.com) by puffin.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19Pzi7-0005Si-00; Wed, 11 Jun 2003 00:07:57 -0700 Message-ID: <3EE6D4ED.DD389240@mindspring.com> Date: Wed, 11 Jun 2003 00:06:21 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Orion Hodson References: <200306101644.h5AGiawR066527@puma.icir.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4576274699084f752bd8379639a240944a2d4e88014a4647c350badd9bab72f9c350badd9bab72f9c cc: current@freebsd.org Subject: Re: Correct PCI suspend and resume operations [ was Re: cirrus ich3 doesn't work after suspend to disk ] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2003 07:08:03 -0000 Orion Hodson wrote: > It looks like the pci configuration space state has been lost during > the suspend and resume. This may be because the bus has removed power > from the devices attached to it on suspend. > > I've been through a cross section of drivers this morning and some > explicitly save and restore the PCI configuration state space and > others don't. The former seems like the safest path in most cases. > AFAICT, we don't common code for handling this and maybe there should > be some rather than have each driver replicate this behaviour. I like this idea; are there driver-specific bits, or can it all be done at a higher level? If it can't, at least a means of recording the space the driver looks at or touches might be the ticket... -- Terry