Messages in this thread |  | | | Date | Fri, 14 Jan 2011 13:55:30 -0600 | | Subject | Re: [PATCH] Quirk to fix suspend/resume on Lenovo Edge 11,13,14,15 | | From | Manoj Iyer <> |
| |
Borislav,
Any more thoughts on this one ?
Many Thanks Manoj
On Thu, Jan 13, 2011 at 4:55 PM, Thomas Gleixner <tglx@linutronix.de> wrote: > On Thu, 13 Jan 2011, Borislav Petkov wrote: >> On Thu, Jan 13, 2011 at 04:30:43PM -0500, Thomas Gleixner wrote: >> > The more interesting info is there in Manoj's logs: >> > >> > [ 0.036455] ..TIMER: vector=0x30 apic1=0 pin1=0 apic2=-1 pin2=-1 >> > [ 0.040000] ..MP-BIOS bug: 8254 timer not connected to IO-APIC >> > [ 0.040000] ...trying to set up timer (IRQ0) through the 8259A ... >> > [ 0.040000] ..... (found apic 0 pin 0) ... >> > [ 0.080021] ....... works. >> > >> > versus >> > >> > [ 0.036460] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1 >> > >> > So the "working" state is using "apic 0 pin 0" while the non working >> > state is using "vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1". >> > >> > Something changes across suspend/resume which makes the BIOS >> > advertised routing work with PIT but not with HPET. Further why does >> > the apic 0/0 solution found by the kernel (when ignoring BIOS) works >> > always (except that we don't know whether the "nohpet" case works as >> > well, but I bet it does). >> >> Yes, it does. With "nohpet" we use PIT and PIT obviously works. > > No. We have no prove that acpi_skip_timer_override and nohpet work > together :) > >> > So we are back to the question I raised above: What changes and even >> > more interesting what changes after the HPET expires - which we know >> > for sure that it must happen as otherwise we wont get a HPET interrupt >> > after the 32bit wraparound. >> > >> > We need answers to these questions before applying any >> > patch/workaround/quirk or whatever. >> >> Well, this is easily answered in the theoretical sense, without the >> actual details :): >> >> 1. HPET gets reinitialized first >> 2. Something programs it >> 3. Timer expires but timer IRQ routing is still wrong and "Something" >> doesn't get its IRQ. >> 4. Timer IRQ routing gets "fixed" as part of the resume path. >> >> ... we end up waiting for the counter to wraparound and get an IRQ which >> gets delivered this time. >> >> Does that make sense at all? > > Yes, that's what I figured, but we need some explanation WHY this is > "working" magically. Once we have that we can fix the issue at hand > w/o applying random quirks. > > Thanks, > > tglx >
-- --manjo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |