mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Borislav Petkov <bp@amd64.org>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>,
	Manoj Iyer <manoj.iyer@canonical.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Rafael J. Wysocki" <rjw@sisk.pl>,
	"Herrmann3, Andreas" <Andreas.Herrmann3@amd.com>
Subject: Re: [PATCH] Quirk to fix suspend/resume on Lenovo Edge 11,13,14,15
Date: Thu, 13 Jan 2011 23:55:58 +0100 (CET)	[thread overview]
Message-ID: <alpine.LFD.2.00.1101132353210.2678@localhost6.localdomain6> (raw)
In-Reply-To: <20110113214841.GC4081@aftab>

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

  reply	other threads:[~2011-01-13 22:56 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-13 16:02 [PATCH 0/1] " Manoj Iyer
2011-01-13 16:02 ` [PATCH] " Manoj Iyer
2011-01-13 16:46   ` Matthew Garrett
2011-01-13 17:10     ` Thomas Gleixner
2011-01-13 17:22       ` Borislav Petkov
2011-01-13 17:33         ` Manoj Iyer
2011-01-13 17:55           ` Borislav Petkov
2011-01-13 18:11             ` Manoj Iyer
2011-01-13 18:30               ` Borislav Petkov
2011-01-13 18:51                 ` Thomas Gleixner
2011-01-13 18:58                   ` Matthew Garrett
2011-01-13 19:07                     ` Borislav Petkov
2011-01-13 19:13                       ` Thomas Gleixner
2011-01-13 19:28                         ` Borislav Petkov
2011-01-13 19:41                           ` Thomas Gleixner
2011-01-13 20:33                             ` Manoj Iyer
2011-01-13 21:12                               ` Manoj Iyer
2011-01-13 21:40                                 ` Thomas Gleixner
2011-01-13 21:48                                   ` Manoj Iyer
2011-01-13 22:40                                     ` Thomas Gleixner
2011-01-13 21:09                             ` Borislav Petkov
2011-01-13 21:30                               ` Thomas Gleixner
2011-01-13 21:48                                 ` Borislav Petkov
2011-01-13 22:55                                   ` Thomas Gleixner [this message]
2011-01-14 19:55                                     ` Manoj Iyer
2011-01-14 21:41                                       ` Borislav Petkov
2011-01-28 17:59                                       ` Andreas Herrmann
2011-01-31 16:44                                         ` Manoj Iyer
2011-01-31 17:54                                           ` Manoj Iyer
2011-01-13 19:11                     ` Thomas Gleixner
2011-01-13 18:57                 ` Manoj Iyer
2011-01-13 17:39       ` Matthew Garrett
     [not found]         ` <AANLkTimk_Y4Q_cxg1SJxZiTT2gT9ywr5UGmsqPqwmeCy@mail.gmail.com>
2011-01-13 17:56           ` Matthew Garrett

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LFD.2.00.1101132353210.2678@localhost6.localdomain6 \
    --to=tglx@linutronix.de \
    --cc=Andreas.Herrmann3@amd.com \
    --cc=bp@amd64.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=manoj.iyer@canonical.com \
    --cc=mjg59@srcf.ucam.org \
    --cc=rjw@sisk.pl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®