From: Zhang Rui <rui.zhang@intel.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
LKML <linux-kernel@vger.kernel.org>, linux-x86 <x86@kernel.org>,
Len Brown <len.brown@intel.com>,
"Chen, Yu C" <yu.c.chen@intel.com>
Subject: Re: Regression: unable to boot after commit bd9240a18edf ("x86/apic: Add TSC_DEADLINE quirk due to errata") - Surface Pro 4 SKL
Date: Tue, 19 Dec 2017 23:42:41 +0800 [thread overview]
Message-ID: <1513698161.2745.14.camel@intel.com> (raw)
In-Reply-To: <20171219152307.ugmlynst574wsdne@hirez.programming.kicks-ass.net>
On Tue, 2017-12-19 at 16:23 +0100, Peter Zijlstra wrote:
> On Tue, Dec 19, 2017 at 06:48:24PM +0800, Zhang Rui wrote:
> >
> > On Mon, 2017-12-18 at 21:28 +0100, Peter Zijlstra wrote:
> > >
> > > Hi, can you see if this makes you Surface boot?
> > >
> > No, it does not boot.
> So I'm confused on the lapic calibration.
>
> That stuff uses global_clock_event, which is initially the i8253
> (PIT),
> but because !PIC this thing won't be there either on your platform.
>
> Then we initialize I/O APIC, and your machine has:
>
> [ 0.000000] IOAPIC[0]: apic_id 2, version 32, address 0xfec00000,
> GSI 0-119
> [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl
> dfl)
> [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high
> level)
> [ 0.000000] ACPI: IRQ0 used by override.
> [ 0.000000] ACPI: IRQ9 used by override.
>
> So your ACPI table has an override for IRQ2 and routes it to IRQ0.
>
> Then we initialize HPET, and we _always_ do hpet_enable_legacy_int(),
> which sets the LegacyRouting bit.
Right.
> The HPET document says:
>
> If the ENABLE_CNF bit and the LEG_RT_CNF bit are both set, then the
> interrupts will be routed as follows:
>
> Timer 0 will be routed to IRQ0 in Non-APIC or IRQ2 in the I/O
> APIC
But AFAICS, the HPET emulated timer interrupts goes to IRQ0 on all the
machines I have tested, but on this MS Surface Pro 4, there is no irq 0
row in /proc/interrupts.
$ cat /proc/interrupts
CPU0 CPU1 CPU2 CPU3
8: 0 1 0 0 IR-IO-APIC 8-
edge rtc0
9: 476 144 4573 132 IR-IO-APIC 9-
fasteoi acpi
14: 0 0 0 0 IR-IO-APIC 14-
edge INT344B:00
16: 646 4971 63574 3973 IR-IO-APIC 16-
fasteoi idma64.0, MRVL_PCIE, i2c_designware.0
17: 0 0 0 0 IR-IO-APIC 17-
fasteoi idma64.1, i2c_designware.1
18: 0 0 0 0 IR-IO-APIC 18-
fasteoi idma64.2, i2c_designware.2
19: 0 0 0 0 IR-IO-APIC 19-
fasteoi idma64.3, i2c_designware.3
Maybe I need to check if IRQ0 is overridden on other platforms, if no,
registering to IRQ2 for HPET Timer 0 could help in this case?
> Timer 1 will be routed to IRQ8 in Non-APIC or IRQ8 in the I/O
> APIC
> Timer 2-n will be routed as per the routing in the timer n config
> registers.
>
> If the LegacyReplacement Route bit is set, the individual routing
> bits
> for timers 0 and 1 (APIC or FSB) will have no impact.
>
> And then we set global_clock_event to &hpet_clockevent.
Yes, I can confirm this.
>
> At this point that _SHOULD_ work afaict, even without actual PIC
> present.
so IOAPIC is ready when we calibrating Lapic timer?
>
> Sometime after that we call into calibrate_APIC_clock() -- because
> !TSC_DEADLINE -- and this is where you get stuck, because
> global_clock_event is not in fact delivering interrupts.
right.
>
> Thomas may have more clue, we'll have to wait for him to have a
> time-slot available.
okay.
thanks,
rui
next prev parent reply other threads:[~2017-12-19 15:42 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-28 2:08 Regression: unable to boot after commit bd9240a18edf ("x86/apic: Add TSC_DEADLINE quirk due to errata") - Surface Pro 4 SKL Zhang Rui
2017-11-28 8:14 ` Peter Zijlstra
2017-11-28 8:22 ` Zhang Rui
2017-11-28 9:34 ` Thomas Gleixner
2017-11-28 10:59 ` Zhang Rui
2017-11-28 12:36 ` Peter Zijlstra
2017-11-29 14:44 ` Zhang Rui
2017-12-18 20:28 ` Peter Zijlstra
2017-12-19 10:48 ` Zhang Rui
2017-12-19 13:15 ` Peter Zijlstra
2017-12-19 15:23 ` Zhang Rui
2017-12-19 15:23 ` Peter Zijlstra
2017-12-19 15:31 ` Peter Zijlstra
2017-12-19 15:43 ` Zhang Rui
2017-12-19 15:42 ` Zhang Rui [this message]
2017-12-19 16:01 ` Peter Zijlstra
2017-12-19 17:23 ` Peter Zijlstra
2017-12-20 14:08 ` Zhang Rui
2017-12-20 14:48 ` Peter Zijlstra
2017-11-28 9:35 ` Peter Zijlstra
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=1513698161.2745.14.camel@intel.com \
--to=rui.zhang@intel.com \
--cc=len.brown@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
--cc=yu.c.chen@intel.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.