Project

General

Profile

Bug #3167

kernel panic in apix:apic_timer_init

Added by Michael Keller about 8 years ago. Updated over 3 years ago.

Status:
Closed
Priority:
Normal
Category:
-
Start date:
2012-09-08
Due date:
% Done:

100%

Estimated time:
Difficulty:
Medium
Tags:
needs-triage
Gerrit CR:

Description

HW: IBM x3100 M4 (Xeon E3-1220, C202 chipset)
SW: OI 151a5 + latest updates

when enabling "extended APIC" in bios the system hangs while booting. 100% reproducable.


Files

apic.txt (63.1 KB) apic.txt Michael Keller, 2012-09-08 01:52 AM
#1

Updated by Rich Lowe about 8 years ago

  • Assignee set to Robert Mustacchi
#2

Updated by Robert Mustacchi about 8 years ago

I've seen something similar to this on a bit of questionable hardware and have some ideas for the fix. Basically, the problem here is that while bringing up the boot CPU we assume that the bios always starts us in local apic mode. However, in this case the bios actually started the apic in x2apic mode. We don't detect that and appropriately swap over our function pointers to use the new programming model. This means that when we try to program the apic to do calibration, nothing happens. We do a good number of pit ticks, but no apic interrupts have come in and we blow up. There are two things that we should do here:

1) Make so if we actually get zero apic ticks that we panic right away because this means we have bad hardware (real or virtualized)
2) We need to properly detect what mode the bios has put the apic into on boot up, either local apic or x2apic, and set the mode appropriately.

#3

Updated by Dustin Marquess about 4 years ago

I'm seeing this exact thing on my Lenovo RD450 machines also when x2APIC is enabled in the CMOS.

#4

Updated by Robert Mustacchi over 3 years ago

Note from Hans:

This can be fixed by switching the register access method in apix_probe() when we detect that the apic is already in x2apic mode. The pcplusmp module has the same problem, but here we should just fail the probe instead of using pcplusmp to drive the x2apic. That could only happen in case someone deliberately set apix_enable=0.

What this fix doesn't address is the apparent dependency of x2apic on VT-d for interrupt remapping. For that reason switching back to local apic mode would be preferable, but then startup of secondary CPUs fails. Switching back to local apic mode after waking up the other CPUs and then recreating the whole apic and interrupt setup doesn't seem viable.

#5

Updated by Electric Monk over 3 years ago

  • Status changed from New to Closed
  • % Done changed from 0 to 100

git commit a51869cd883cf8c992f8920c767bb4b5939f3006

commit  a51869cd883cf8c992f8920c767bb4b5939f3006
Author: Hans Rosenfeld <hans.rosenfeld@joyent.com>
Date:   2017-06-29T23:12:29.000Z

    3167 kernel panic in apix:apic_timer_init
    Reviewed by: Robert Mustacchi <rm@joyent.com>
    Reviewed by: Jerry Jelinek <jerry.jelinek@joyent.com>
    Reviewed by: Toomas Soome <tsoome@me.com>
    Reviewed by: Gordon Ross <gordon.w.ross@gmail.com>
    Approved by: Richard Lowe <richlowe@richlowe.net>

Also available in: Atom PDF