From owner-freebsd-current@FreeBSD.ORG Mon Apr 26 13:17:58 2004 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 3EE3F16A4CE for ; Mon, 26 Apr 2004 13:17:58 -0700 (PDT) Received: from mail4.speakeasy.net (mail4.speakeasy.net [216.254.0.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0E06C43D62 for ; Mon, 26 Apr 2004 13:17:58 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 22027 invoked from network); 26 Apr 2004 20:17:57 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 26 Apr 2004 20:17:57 -0000 Received: from 10.50.40.205 (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i3QKHiZD078512; Mon, 26 Apr 2004 16:17:54 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: Nate Lawson Date: Mon, 26 Apr 2004 16:10:50 -0400 User-Agent: KMail/1.6 References: <20040422163451.C1D365D07@ptavv.es.net> <20040423.144322.115909342.imp@bsdimp.com> <20040423140023.S53535@root.org> In-Reply-To: <20040423140023.S53535@root.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <200404261610.51000.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: freebsd-current@FreeBSD.org cc: "M. Warner Losh" Subject: Re: HEADS UP: PCI Chnages 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: Mon, 26 Apr 2004 20:17:58 -0000 On Friday 23 April 2004 05:01 pm, Nate Lawson wrote: > On Fri, 23 Apr 2004, M. Warner Losh wrote: > > In message: <200404231118.11833.jhb@FreeBSD.org> > > > > John Baldwin writes: > > : On Thursday 22 April 2004 12:34 pm, Kevin Oberman wrote: > > : > Well, things seem to have deteriorated slightly with Warner's recent > > : > PCI changes (backing out much of the PCI power stuff). > > : > > > : > 1. I have both my hard disks and floppies. Thanks Warner and S=F8re= n! > > : > > > : > 2. USB still works and recovers after a resume! > > : > > > : > 3. Sound is again playing too fast after resume. ICH audio is > > : > reverting to its native speed. With the PCI power stuff in there, it > > : > worked just fine. (It was nice while it lasted.) I suspect this will > > : > return when Warner gets a few rough edges off of the PCI code. > > : > > > : > 4. After a resume, the shared PCI interrupt stops being delivered > > : > after a LONG time interval. I've had it fail in 10 minutes, but it = is > > : > more likely to die after about an hour. It always dies in under 2 > > : > hours. > > : > > > : > vmstat -i looks completely normal except that the count for irq 11 > > : > never increases. All other interrupts and devices are fine. Is this= a > > : > locking problem? Should I put WITNESS back in my kernel? I can't fi= nd > > : > any sign of any significant resource being exhausted. If you ignore > > : > the fact that all devices on irq 11 are dead, the system continues = to > > : > run just fine. X is alive and the box seems completely normal. (Of > > : > course, USB, the network cards, and sound are completely gone.) > > : > System has neither SMP or APIC in the kernel. > > : > > > : > I'd love to track this down. I have no idea how common it is, > > : > either. Since most people running CURRENT are not using suspend on > > : > their laptops because of various problems except to test things, th= is > > : > might not have shown up for most people. (Or, it might be unique to > > : > the IBM T30.) > > : > > > : > Thanks, > > : > > : We probably just need to reprogram the PCI link devices on resume. A= re > > : you using ACPI? The non-ACPI case I know doesn't do this yet. > > > > We aren't doing that at the moment. I have some changes in my tree, > > but there are issues with ndis not working quite right yet :-( > > I thought that was enabled in the ACPI-PCI bridge driver. At least my > latest version seems to do it (added by iwasaki@ a while ago). Did you > disable that again? Or are your comments just for the !acpi case? Well, the ACPI PCI just reroutes everyone's interrupt. It's not the cleane= st=20 way to do it. What should happen is that the bridge driver should ask the= =20 link devices to reprogram themselves if need be. For the !ACPI case, I pla= n=20 to add a pir0 child of pcib0 that will reroute all the links on resume. =2D-=20 John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" =3D http://www.FreeBSD.org