Re: HEADS UP: PCI Chnages

> From: John Baldwin <jhb_at_FreeBSD.org>
> Date: Fri, 23 Apr 2004 11:18:11 -0400
> 
> 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=F8ren!
> >
> > 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 find 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, this 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.  Are you
> using ACPI?  The non-ACPI case I know doesn't do this yet.

Well, I am at a loss to say exactly what did it, but I have now run for
several hours after a resume on Friday, Saturday and today with no
problems running a system updated on Friday morning (-7). I'm pretty
sure that my previous system updated on 5/3 had the problem and looking
at commits between the two, I don't see a clear candidate. In any case,
I think it's fixed.

The display shut-off problem is also fixed with your DPMS patches. Will
this be committed any time soon?

The instant wake-up problem after the first suspend/resume remains, but
Nate posted that he had resolved the problem with a hack to a new import
of ACPI code, so I expect that this will go away before too 5.3.

The remaining problem is that the sound does not reset properly after
resume. Warner's PCI power stuff had it fixed for a couple of days, but
it broke again after he backed out part of the patch. I'm going to try
building a kernel without pcm and try unloading the driver before
suspending and reloading after resume and see how that does.

In any case, it looks like the weird loss of IRQ11 is gone. (Of course,
it might just be teasing me.) Cleanly suspending and resuming are getting
so close (at least on my laptop) that I can almost taste it. :-)

Thanks so much for your efforts to et this all working. It is so nice to
actually see my screen turn off when I suspend (even if I can only do it
once).
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman_at_es.net			Phone: +1 510 486-8634