Re: svn commit: r278473 - in head/sys: amd64/amd64 amd64/include amd64/vmm contrib/dev/acpica/include i386/i386 i386/include x86/acpica x86/include x86/x86 x86/xen
I'll follow this up with the machine dmesg and such, but transcribed from the laptop hang with -HEAD as of this morning + your patch in this thread (with DELAY, debugging) and some of my debugging: ... native_start_all_aps: cpu=1, apic_id=1 start_ap: calling ipi_startup(1, 158) LAPIC write 30 c500; mode=1, inited=0 LAPIC write 30 8500; mode=1 inited=1 (hang) -a ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r278473 - in head/sys: amd64/amd64 amd64/include amd64/vmm contrib/dev/acpica/include i386/i386 i386/include x86/acpica x86/include x86/x86 x86/xen
Cool, I can get this done today. -a ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r278473 - in head/sys: amd64/amd64 amd64/include amd64/vmm contrib/dev/acpica/include i386/i386 i386/include x86/acpica x86/include x86/x86 x86/xen
On Thu, Feb 26, 2015 at 05:26:26PM -0800, Adrian Chadd wrote:
> On 26 February 2015 at 17:17, Peter Grehan wrote:
> >> Anyway - I have that model laptop, it hangs after calling
> >> ipi_startup() to the first AP with x2apic enabled. What can I do to
> >> continue debugging?
> >
> >
> > Please provide the info that Kostik requested here, try out the patch, and
> > wait for the timezone in Ukraine to be a little more reasonable for a reply.
> >
> > http://docs.FreeBSD.org/cgi/mid.cgi?20150216174658.GI34251
>
> Hi,
>
> That patch is already in -HEAD; I'm already running it and no, it
> doesn't help. The details are the same as what koop provided.
>
> > Use the workaround of setting hw.x2apic_enable=0 in the loader to fall back
> > to stock APIC mode.
>
> Yup - I'm using it to at least boot the laptop to get debugging output.
>
Sigh.
I need verbose dmesg output of the successfull boot, acpidump -t output,
and report what happen when you are trying to boot with the following
patch, without x2apic knob disabling x2apic.
The patch below increases the time wait for the AP init.
diff --git a/sys/amd64/amd64/mp_machdep.c b/sys/amd64/amd64/mp_machdep.c
index b767691..9d33ca5 100644
--- a/sys/amd64/amd64/mp_machdep.c
+++ b/sys/amd64/amd64/mp_machdep.c
@@ -569,6 +569,7 @@ cpu_mp_start(void)
/* Start each Application Processor */
init_ops.start_all_aps();
+printf("start_all_aps finished\n");
set_interrupt_apic_ids();
}
@@ -973,6 +974,7 @@ native_start_all_aps(void)
bootSTK = (char *)bootstacks[cpu] + KSTACK_PAGES * PAGE_SIZE -
8;
bootAP = cpu;
+printf("cpu %d start\n", cpu);
/* attempt to start the Application Processor */
if (!start_ap(apic_id)) {
/* restore the warmstart vector */
@@ -981,6 +983,7 @@ native_start_all_aps(void)
}
CPU_SET(cpu, &all_cpus);/* record AP in CPU map */
+printf("cpu %d done\n", cpu);
}
/* restore the warmstart vector */
@@ -1083,6 +1086,7 @@ ipi_startup(int apic_id, int vector)
lapic_ipi_raw(APIC_DEST_DESTFLD | APIC_TRIGMOD_LEVEL |
APIC_LEVEL_ASSERT | APIC_DESTMODE_PHY | APIC_DELMODE_INIT, apic_id);
lapic_ipi_wait(20);
+ DELAY(200);
/* Explicitly deassert the INIT IPI. */
lapic_ipi_raw(APIC_DEST_DESTFLD | APIC_TRIGMOD_LEVEL |
@@ -1105,7 +1109,7 @@ ipi_startup(int apic_id, int vector)
if (!lapic_ipi_wait(20))
panic("Failed to deliver first STARTUP IPI to APIC %d",
apic_id);
- DELAY(200); /* wait ~200uS */
+ DELAY(400); /* wait ~200uS */
/*
* finally we do a 2nd STARTUP IPI: this 2nd STARTUP IPI should run IF
@@ -1120,7 +1124,7 @@ ipi_startup(int apic_id, int vector)
panic("Failed to deliver second STARTUP IPI to APIC %d",
apic_id);
- DELAY(200); /* wait ~200uS */
+ DELAY(400); /* wait ~200uS */
}
/*
diff --git a/sys/x86/x86/local_apic.c b/sys/x86/x86/local_apic.c
index 1b66674..dffb639 100644
--- a/sys/x86/x86/local_apic.c
+++ b/sys/x86/x86/local_apic.c
@@ -165,11 +165,25 @@ static struct eventtimer lapic_et;
SYSCTL_NODE(_hw, OID_AUTO, apic, CTLFLAG_RD, 0, "APIC options");
SYSCTL_INT(_hw_apic, OID_AUTO, x2apic_mode, CTLFLAG_RD, &x2apic_mode, 0, "");
+static int x2apic_inited;
+static void
+lapic_report(int read, int reg, int val)
+{
+
+ if (!IS_BSP())
+ return;
+ if (read)
+ printf("lapic read %x; %d %d\n", reg, x2apic_mode,
x2apic_inited);
+ else
+ printf("lapic write %x %x; %d %d\n", reg, val,x2apic_mode,
x2apic_inited);
+}
+
static uint32_t
lapic_read32(enum LAPIC_REGISTERS reg)
{
uint32_t res;
+lapic_report(1, reg, 0);
if (x2apic_mode) {
res = rdmsr32(MSR_APIC_000 + reg);
} else {
@@ -182,6 +196,7 @@ static void
lapic_write32(enum LAPIC_REGISTERS reg, uint32_t val)
{
+lapic_report(0, reg, val);
if (x2apic_mode) {
mfence();
wrmsr(MSR_APIC_000 + reg, val);
@@ -194,6 +209,7 @@ static void
lapic_write32_nofence(enum LAPIC_REGISTERS reg, uint32_t val)
{
+lapic_report(0, reg, val);
if (x2apic_mode) {
wrmsr(MSR_APIC_000 + reg, val);
} else {
@@ -207,6 +223,7 @@ lapic_read_icr(void)
uint64_t v;
uint32_t vhi, vlo;
+lapic_report(1, LAPIC_ICR_LO, 0);
if (x2apic_mode) {
v = rdmsr(MSR_APIC_000 + LAPIC_ICR_LO);
} else {
@@ -221,6 +238,7 @@ static uint64_t
lapic_read_icr_lo(void)
{
+lapic_report(1, LAPIC_ICR_LO, 0);
return (lapic_read32(LAPIC_ICR_LO));
}
@@ -229,6 +247,7 @@ lapic_write_icr(uint32_t vhi, uint32_t vlo)
{
uint64_t v;
+lapic_report(0, LAPIC_ICR_LO, vlo);
if (x2apic_mode) {
v = ((uint64_t)vhi
Re: svn commit: r278473 - in head/sys: amd64/amd64 amd64/include amd64/vmm contrib/dev/acpica/include i386/i386 i386/include x86/acpica x86/include x86/x86 x86/xen
On 26 February 2015 at 17:17, Peter Grehan wrote: >> Anyway - I have that model laptop, it hangs after calling >> ipi_startup() to the first AP with x2apic enabled. What can I do to >> continue debugging? > > > Please provide the info that Kostik requested here, try out the patch, and > wait for the timezone in Ukraine to be a little more reasonable for a reply. > > http://docs.FreeBSD.org/cgi/mid.cgi?20150216174658.GI34251 Hi, That patch is already in -HEAD; I'm already running it and no, it doesn't help. The details are the same as what koop provided. > Use the workaround of setting hw.x2apic_enable=0 in the loader to fall back > to stock APIC mode. Yup - I'm using it to at least boot the laptop to get debugging output. -adrian ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r278473 - in head/sys: amd64/amd64 amd64/include amd64/vmm contrib/dev/acpica/include i386/i386 i386/include x86/acpica x86/include x86/x86 x86/xen
Anyway - I have that model laptop, it hangs after calling ipi_startup() to the first AP with x2apic enabled. What can I do to continue debugging? Please provide the info that Kostik requested here, try out the patch, and wait for the timezone in Ukraine to be a little more reasonable for a reply. http://docs.FreeBSD.org/cgi/mid.cgi?20150216174658.GI34251 Use the workaround of setting hw.x2apic_enable=0 in the loader to fall back to stock APIC mode. later, Peter. ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r278473 - in head/sys: amd64/amd64 amd64/include amd64/vmm contrib/dev/acpica/include i386/i386 i386/include x86/acpica x86/include x86/x86 x86/xen
On 26 February 2015 at 15:13, Peter Grehan wrote: >> Koop did provide feedback shortly after Kib asked him to provide >> information and test a patch. There wasn't a response from kib or >> anyone else until I reported the same bug. > > > http://docs.FreeBSD.org/cgi/mid.cgi?20150219200900.GH34251 So some other discussion may have occured off-list; I can't see that. Anyway - I have that model laptop, it hangs after calling ipi_startup() to the first AP with x2apic enabled. What can I do to continue debugging? -a ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r278473 - in head/sys: amd64/amd64 amd64/include amd64/vmm contrib/dev/acpica/include i386/i386 i386/include x86/acpica x86/include x86/x86 x86/xen
Koop did provide feedback shortly after Kib asked him to provide information and test a patch. There wasn't a response from kib or anyone else until I reported the same bug. http://docs.FreeBSD.org/cgi/mid.cgi?20150219200900.GH34251 later, Peter. ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r278473 - in head/sys: amd64/amd64 amd64/include amd64/vmm contrib/dev/acpica/include i386/i386 i386/include x86/acpica x86/include x86/x86 x86/xen
Peter, Koop did provide feedback shortly after Kib asked him to provide information and test a patch. There wasn't a response from kib or anyone else until I reported the same bug. -adrian ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r278473 - in head/sys: amd64/amd64 amd64/include amd64/vmm contrib/dev/acpica/include i386/i386 i386/include x86/acpica x86/include x86/x86 x86/xen
I'm not suggesting anything is backed out. I'm suggesting that we just disable it until it's fixed. Both Kostik and Neel gave their reasons for keeping it enabled. I'm adding to that. >That way we don't end up with other >people complaining that things hang the way that they do and then >assume FreeBSD is just plain broken and give up. If you really thought that you would be helping to get your rare outlier fixed instead of demanding 24-hour turnaround and unilateral reverting of functionality. That's all I'm going to say on this. later, Peter. ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r278473 - in head/sys: amd64/amd64 amd64/include amd64/vmm contrib/dev/acpica/include i386/i386 i386/include x86/acpica x86/include x86/x86 x86/xen
On 26 February 2015 at 12:36, Peter Grehan wrote: >> This has been reported by more than one person, it's been a couple of >> weeks, it's an actual regression, and there's no specific solution in >> sight. > > > It's been reported by you and one other, with no feedback from the other > person despite requests for more information, and there would be a specific > solution if those with an impacted system offered to help out. > >> I'm happy to test solutions, but stalling on reverting a regression >> reported by people running -HEAD is irresponsible. > > > Reported by 2 people, 2 weeks apart. > > Even more irresponsible to threaten to back out someone else's fix without > even offering to help diagnose when there is a simple workaround available. I'm not suggesting anything is backed out. I'm suggesting that we just disable it until it's fixed. That way we don't end up with other people complaining that things hang the way that they do and then assume FreeBSD is just plain broken and give up. -adrian ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r278473 - in head/sys: amd64/amd64 amd64/include amd64/vmm contrib/dev/acpica/include i386/i386 i386/include x86/acpica x86/include x86/x86 x86/xen
This has been reported by more than one person, it's been a couple of weeks, it's an actual regression, and there's no specific solution in sight. It's been reported by you and one other, with no feedback from the other person despite requests for more information, and there would be a specific solution if those with an impacted system offered to help out. I'm happy to test solutions, but stalling on reverting a regression reported by people running -HEAD is irresponsible. Reported by 2 people, 2 weeks apart. Even more irresponsible to threaten to back out someone else's fix without even offering to help diagnose when there is a simple workaround available. later, Peter. ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r278473 - in head/sys: amd64/amd64 amd64/include amd64/vmm contrib/dev/acpica/include i386/i386 i386/include x86/acpica x86/include x86/x86 x86/xen
On 26 February 2015 at 12:17, Peter Grehan wrote: >> I'm going to set the x2apic_disable=0 by default in 24 hours so people >> have time to fix this without it impacting the functionality of -HEAD >> by default. > > What gives you the right to make this decision ? This has been reported by more than one person, it's been a couple of weeks, it's an actual regression, and there's no specific solution in sight. I'm happy to test solutions, but stalling on reverting a regression reported by people running -HEAD is irresponsible. So, no, I don't have any specific "right" over anyone else, but everyone here has the /responsibility/ to keep things working. -adrian ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r278473 - in head/sys: amd64/amd64 amd64/include amd64/vmm contrib/dev/acpica/include i386/i386 i386/include x86/acpica x86/include x86/x86 x86/xen
I'm going to set the x2apic_disable=0 by default in 24 hours so people have time to fix this without it impacting the functionality of -HEAD by default. What gives you the right to make this decision ? later, Peter. ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r278473 - in head/sys: amd64/amd64 amd64/include amd64/vmm contrib/dev/acpica/include i386/i386 i386/include x86/acpica x86/include x86/x86 x86/xen
Kib, This just broke on my sandybridge laptop. It hung during obot at the same place. I'm going to set the x2apic_disable=0 by default in 24 hours so people have time to fix this without it impacting the functionality of -HEAD by default. Thanks, -adrian ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r278473 - in head/sys: amd64/amd64 amd64/include amd64/vmm contrib/dev/acpica/include i386/i386 i386/include x86/acpica x86/include x86/x86 x86/xen
On 16-2-2015 18:46, Konstantin Belousov wrote: On Mon, Feb 16, 2015 at 03:21:04PM +0100, Koop Mast wrote: On 9-2-2015 22:00, Konstantin Belousov wrote: Author: kib Date: Mon Feb 9 21:00:56 2015 New Revision: 278473 URL: https://svnweb.freebsd.org/changeset/base/278473 Log: Add x2APIC support. Enable it by default if CPU is capable. The hw.x2apic_enable tunable allows disabling it from the loader prompt. Hi Konstantin, This commit broke my Sandybridge laptop. If x2APIC is enabled the kernel freezes after the "ACPI APIC Table: <_ASUS_ NoteBook>" line is printed. I can't get much information out of it since I couldn't get into the kernel debugger nor has the machine a serial cable. Can you provide e.g. a photo of the machine screen with the hang boot, of the same kernel you used for the dmesg log below ? Also, please provide the output of acpidump -t. https://people.freebsd.org/~kwm/x2apic/acpidump.txt https://people.freebsd.org/~kwm/x2apic/x2apic-boot.jpg The patch below didn't seem to have any noticable effect. -Koop I did notice that "x2APIC" is listed in the CPU Features2 list, but for the cpu's it reports "x2APIC: 0". I don't know if this has to do with disabled x2APIC or some hardware/bios issue? x2APIC tag for the LAPIC reports appear when cpu declares support for x2APIC mode, like in your case. The 0/1 indicates the final value used by kernel, i.e. 0 means disabled, by user override (your case), by BIOS request, or due to detection of incompatible hypervisor. -Koop Verbose dmesg with x2APIC disabled: https://people.freebsd.org/~kwm/dmesg-x2apic.txt Also, please try the following patch. Only the local_apic.c chunk could matter for you. diff --git a/sys/amd64/amd64/mp_machdep.c b/sys/amd64/amd64/mp_machdep.c index 13c3d43..b767691 100644 --- a/sys/amd64/amd64/mp_machdep.c +++ b/sys/amd64/amd64/mp_machdep.c @@ -1507,6 +1507,7 @@ cpususpend_handler(void) vmm_resume_p(); /* Resume MCA and local APIC */ + lapic_xapic_mode(); mca_resume(); lapic_setup(0); diff --git a/sys/i386/i386/mp_machdep.c b/sys/i386/i386/mp_machdep.c index 32b9540..a80de54 100644 --- a/sys/i386/i386/mp_machdep.c +++ b/sys/i386/i386/mp_machdep.c @@ -1555,6 +1555,7 @@ cpususpend_handler(void) cpu_ops.cpu_resume(); /* Resume MCA and local APIC */ + lapic_xapic_mode(); mca_resume(); lapic_setup(0); diff --git a/sys/x86/acpica/acpi_wakeup.c b/sys/x86/acpica/acpi_wakeup.c index 74522be..e652419 100644 --- a/sys/x86/acpica/acpi_wakeup.c +++ b/sys/x86/acpica/acpi_wakeup.c @@ -270,6 +270,7 @@ acpi_wakeup_machdep(struct acpi_softc *sc, int state, int sleep_result, initializecpu(); PCPU_SET(switchtime, 0); PCPU_SET(switchticks, ticks); + lapic_xapic_mode(); #ifdef SMP if (!CPU_EMPTY(&suspcpus)) acpi_wakeup_cpus(sc); diff --git a/sys/x86/x86/local_apic.c b/sys/x86/x86/local_apic.c index 1809fa6..1b66674 100644 --- a/sys/x86/x86/local_apic.c +++ b/sys/x86/x86/local_apic.c @@ -527,7 +527,6 @@ native_lapic_xapic_mode(void) saveintr = intr_disable(); if (x2apic_mode) native_lapic_enable_x2apic(); - native_lapic_disable(); intr_restore(saveintr); } ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r278473 - in head/sys: amd64/amd64 amd64/include amd64/vmm contrib/dev/acpica/include i386/i386 i386/include x86/acpica x86/include x86/x86 x86/xen
On Mon, Feb 16, 2015 at 03:21:04PM +0100, Koop Mast wrote: > On 9-2-2015 22:00, Konstantin Belousov wrote: > > Author: kib > > Date: Mon Feb 9 21:00:56 2015 > > New Revision: 278473 > > URL: https://svnweb.freebsd.org/changeset/base/278473 > > > > Log: > >Add x2APIC support. Enable it by default if CPU is capable. The > >hw.x2apic_enable tunable allows disabling it from the loader prompt. > > Hi Konstantin, > > This commit broke my Sandybridge laptop. If x2APIC is enabled the kernel > freezes after the > "ACPI APIC Table: <_ASUS_ NoteBook>" line is printed. I can't get much > information out of it since I couldn't get into the kernel debugger nor > has the machine a serial cable. Can you provide e.g. a photo of the machine screen with the hang boot, of the same kernel you used for the dmesg log below ? Also, please provide the output of acpidump -t. > > I did notice that "x2APIC" is listed in the CPU Features2 list, but for > the cpu's it reports "x2APIC: 0". I don't know if this has to do with > disabled x2APIC or some hardware/bios issue? x2APIC tag for the LAPIC reports appear when cpu declares support for x2APIC mode, like in your case. The 0/1 indicates the final value used by kernel, i.e. 0 means disabled, by user override (your case), by BIOS request, or due to detection of incompatible hypervisor. > > -Koop > > Verbose dmesg with x2APIC disabled: > https://people.freebsd.org/~kwm/dmesg-x2apic.txt Also, please try the following patch. Only the local_apic.c chunk could matter for you. diff --git a/sys/amd64/amd64/mp_machdep.c b/sys/amd64/amd64/mp_machdep.c index 13c3d43..b767691 100644 --- a/sys/amd64/amd64/mp_machdep.c +++ b/sys/amd64/amd64/mp_machdep.c @@ -1507,6 +1507,7 @@ cpususpend_handler(void) vmm_resume_p(); /* Resume MCA and local APIC */ + lapic_xapic_mode(); mca_resume(); lapic_setup(0); diff --git a/sys/i386/i386/mp_machdep.c b/sys/i386/i386/mp_machdep.c index 32b9540..a80de54 100644 --- a/sys/i386/i386/mp_machdep.c +++ b/sys/i386/i386/mp_machdep.c @@ -1555,6 +1555,7 @@ cpususpend_handler(void) cpu_ops.cpu_resume(); /* Resume MCA and local APIC */ + lapic_xapic_mode(); mca_resume(); lapic_setup(0); diff --git a/sys/x86/acpica/acpi_wakeup.c b/sys/x86/acpica/acpi_wakeup.c index 74522be..e652419 100644 --- a/sys/x86/acpica/acpi_wakeup.c +++ b/sys/x86/acpica/acpi_wakeup.c @@ -270,6 +270,7 @@ acpi_wakeup_machdep(struct acpi_softc *sc, int state, int sleep_result, initializecpu(); PCPU_SET(switchtime, 0); PCPU_SET(switchticks, ticks); + lapic_xapic_mode(); #ifdef SMP if (!CPU_EMPTY(&suspcpus)) acpi_wakeup_cpus(sc); diff --git a/sys/x86/x86/local_apic.c b/sys/x86/x86/local_apic.c index 1809fa6..1b66674 100644 --- a/sys/x86/x86/local_apic.c +++ b/sys/x86/x86/local_apic.c @@ -527,7 +527,6 @@ native_lapic_xapic_mode(void) saveintr = intr_disable(); if (x2apic_mode) native_lapic_enable_x2apic(); - native_lapic_disable(); intr_restore(saveintr); } ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r278473 - in head/sys: amd64/amd64 amd64/include amd64/vmm contrib/dev/acpica/include i386/i386 i386/include x86/acpica x86/include x86/x86 x86/xen
On 9-2-2015 22:00, Konstantin Belousov wrote: Author: kib Date: Mon Feb 9 21:00:56 2015 New Revision: 278473 URL: https://svnweb.freebsd.org/changeset/base/278473 Log: Add x2APIC support. Enable it by default if CPU is capable. The hw.x2apic_enable tunable allows disabling it from the loader prompt. Hi Konstantin, This commit broke my Sandybridge laptop. If x2APIC is enabled the kernel freezes after the "ACPI APIC Table: <_ASUS_ NoteBook>" line is printed. I can't get much information out of it since I couldn't get into the kernel debugger nor has the machine a serial cable. I did notice that "x2APIC" is listed in the CPU Features2 list, but for the cpu's it reports "x2APIC: 0". I don't know if this has to do with disabled x2APIC or some hardware/bios issue? -Koop Verbose dmesg with x2APIC disabled: https://people.freebsd.org/~kwm/dmesg-x2apic.txt ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r278473 - in head/sys: amd64/amd64 amd64/include amd64/vmm contrib/dev/acpica/include i386/i386 i386/include x86/acpica x86/include x86/x86 x86/xen
On Feb 11, 2015, at 08:55 AM, Konstantin Belousov wrote: Ok, https://lkml.org/lkml/2013/1/17/552 Patch is below. Please, users of VMWare, test it. Fixed the problem for me on VMware Fusion 6.0.5. ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r278473 - in head/sys: amd64/amd64 amd64/include amd64/vmm contrib/dev/acpica/include i386/i386 i386/include x86/acpica x86/include x86/x86 x86/xen
On Wed, Feb 11, 2015 at 10:20:03AM -0500, John Baldwin wrote:
> On Wednesday, February 11, 2015 10:32:00 AM Konstantin Belousov wrote:
> > On Wed, Feb 11, 2015 at 12:43:39AM +, Rui Paulo wrote:
> > > On Feb 09, 2015, at 01:01 PM, Konstantin Belousov
> > > wrote:
> > >
> > > Author: kib
> > > Date: Mon Feb 9 21:00:56 2015
> > > New Revision: 278473
> > > URL: https://svnweb.freebsd.org/changeset/base/278473
> > >
> > > Log:
> > > Add x2APIC support. Enable it by default if CPU is capable. The
> > > hw.x2apic_enable tunable allows disabling it from the loader prompt.
> > >
> > > This breaks VMware Fusion when the host CPU has x2APIC support. In
> > > my case, mpt(4) was unable to receive interrupts and USB was similarly
> > > broken. It's possible that this is a VMware bug, but you might want to
> > > avoid turning this on when running under the VMware hypervisor.
> >
> > Neel pointed this out to me when the patch was reviewed.
> > He told me that x2APIC does not work in Fusion 5.x, while it seems
> > to be fixed in 7.x.
> > https://communities.vmware.com/message/2173695?tstart=0
> >
> > Upon further discussion with Neel and Peter, it was suggested that we
> > enable enable x2APIC unconditionally, which seems what is done for
> > Linux benchmarks.
> >
> > Is vmware 5.x is used while there is already at least version 7.x ?
> > I have no idea about vmware product nomenclature and lifecycle.
>
> I believe we can ask vmware what version it is when we notice we are running
> under it (which we already detect for TSC purposes). We could quirk for that
> case, or even just disable for VM_GUEST_VMWARE for now.
>
Ok, https://lkml.org/lkml/2013/1/17/552
Patch is below. Please, users of VMWare, test it.
diff --git a/sys/x86/acpica/madt.c b/sys/x86/acpica/madt.c
index f20b735..c3df686 100644
--- a/sys/x86/acpica/madt.c
+++ b/sys/x86/acpica/madt.c
@@ -31,6 +31,7 @@ __FBSDID("$FreeBSD$");
#include
#include
#include
+#include
#include
#include
#include
@@ -40,6 +41,7 @@ __FBSDID("$FreeBSD$");
#include
#include
#include
+#include
#include
#include
@@ -130,6 +132,7 @@ madt_setup_local(void)
{
ACPI_TABLE_DMAR *dmartbl;
vm_paddr_t dmartbl_physaddr;
+ u_int p[4];
madt = pmap_mapbios(madt_physaddr, madt_length);
if ((cpu_feature2 & CPUID2_X2APIC) != 0) {
@@ -146,6 +149,16 @@ madt_setup_local(void)
}
acpi_unmap_table(dmartbl);
}
+ if (vm_guest == VM_GUEST_VMWARE) {
+ vmware_hvcall(VMW_HVCMD_GETVCPU_INFO, p);
+ if ((p[0] & VMW_VCPUINFO_VCPU_RESERVED) != 0 ||
+ (p[0] & VMW_VCPUINFO_LEGACY_X2APIC) == 0) {
+ x2apic_mode = 0;
+ if (bootverbose)
+ printf(
+ "x2APIC available but disabled inside VMWare without intr
redirection\n");
+ }
+ }
TUNABLE_INT_FETCH("hw.x2apic_enable", &x2apic_mode);
}
diff --git a/sys/x86/include/vmware.h b/sys/x86/include/vmware.h
index c72f48d..d3d7e2d 100644
--- a/sys/x86/include/vmware.h
+++ b/sys/x86/include/vmware.h
@@ -31,8 +31,13 @@
#defineVMW_HVMAGIC 0x564d5868
#defineVMW_HVPORT 0x5658
+
#defineVMW_HVCMD_GETVERSION10
#defineVMW_HVCMD_GETHZ 45
+#defineVMW_HVCMD_GETVCPU_INFO 68
+
+#defineVMW_VCPUINFO_LEGACY_X2APIC (1 << 3)
+#defineVMW_VCPUINFO_VCPU_RESERVED (1 << 31)
static __inline void
vmware_hvcall(u_int cmd, u_int *p)
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r278473 - in head/sys: amd64/amd64 amd64/include amd64/vmm contrib/dev/acpica/include i386/i386 i386/include x86/acpica x86/include x86/x86 x86/xen
On Wed, Feb 11, 2015 at 9:20 AM, John Baldwin wrote: > On Wednesday, February 11, 2015 10:32:00 AM Konstantin Belousov wrote: > > On Wed, Feb 11, 2015 at 12:43:39AM +, Rui Paulo wrote: > > > On Feb 09, 2015, at 01:01 PM, Konstantin Belousov > wrote: > > > > > > Author: kib > > > Date: Mon Feb 9 21:00:56 2015 > > > New Revision: 278473 > > > URL: https://svnweb.freebsd.org/changeset/base/278473 > > > > > > Log: > > > Add x2APIC support. Enable it by default if CPU is capable. The > > > hw.x2apic_enable tunable allows disabling it from the loader prompt. > > > > > > This breaks VMware Fusion when the host CPU has x2APIC support. In > > > my case, mpt(4) was unable to receive interrupts and USB was similarly > > > broken. It's possible that this is a VMware bug, but you might want to > > > avoid turning this on when running under the VMware hypervisor. > > > > Neel pointed this out to me when the patch was reviewed. > > He told me that x2APIC does not work in Fusion 5.x, while it seems > > to be fixed in 7.x. > > https://communities.vmware.com/message/2173695?tstart=0 > > > > Upon further discussion with Neel and Peter, it was suggested that we > > enable enable x2APIC unconditionally, which seems what is done for > > Linux benchmarks. > > > > Is vmware 5.x is used while there is already at least version 7.x ? > > I have no idea about vmware product nomenclature and lifecycle. > > I believe we can ask vmware what version it is when we notice we are > running > under it (which we already detect for TSC purposes). We could quirk for > that > case, or even just disable for VM_GUEST_VMWARE for now. > > I'm not too familiar with this stuff, but is this Linux commit [1] relevant? If so, it might be something nice to wrap into my projects/paravirt branch (I've been extremely busy recently, but I hope to get the review comments addressed and merge it into HEAD soon). [1] - https://lkml.org/lkml/2013/1/17/552 -- > John Baldwin > > ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r278473 - in head/sys: amd64/amd64 amd64/include amd64/vmm contrib/dev/acpica/include i386/i386 i386/include x86/acpica x86/include x86/x86 x86/xen
On Wednesday, February 11, 2015 10:32:00 AM Konstantin Belousov wrote: > On Wed, Feb 11, 2015 at 12:43:39AM +, Rui Paulo wrote: > > On Feb 09, 2015, at 01:01 PM, Konstantin Belousov wrote: > > > > Author: kib > > Date: Mon Feb 9 21:00:56 2015 > > New Revision: 278473 > > URL: https://svnweb.freebsd.org/changeset/base/278473 > > > > Log: > > Add x2APIC support. Enable it by default if CPU is capable. The > > hw.x2apic_enable tunable allows disabling it from the loader prompt. > > > > This breaks VMware Fusion when the host CPU has x2APIC support. In > > my case, mpt(4) was unable to receive interrupts and USB was similarly > > broken. It's possible that this is a VMware bug, but you might want to > > avoid turning this on when running under the VMware hypervisor. > > Neel pointed this out to me when the patch was reviewed. > He told me that x2APIC does not work in Fusion 5.x, while it seems > to be fixed in 7.x. > https://communities.vmware.com/message/2173695?tstart=0 > > Upon further discussion with Neel and Peter, it was suggested that we > enable enable x2APIC unconditionally, which seems what is done for > Linux benchmarks. > > Is vmware 5.x is used while there is already at least version 7.x ? > I have no idea about vmware product nomenclature and lifecycle. I believe we can ask vmware what version it is when we notice we are running under it (which we already detect for TSC purposes). We could quirk for that case, or even just disable for VM_GUEST_VMWARE for now. -- John Baldwin ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r278473 - in head/sys: amd64/amd64 amd64/include amd64/vmm contrib/dev/acpica/include i386/i386 i386/include x86/acpica x86/include x86/x86 x86/xen
On Wed, Feb 11, 2015 at 12:43:39AM +, Rui Paulo wrote: > On Feb 09, 2015, at 01:01 PM, Konstantin Belousov wrote: > > Author: kib > Date: Mon Feb 9 21:00:56 2015 > New Revision: 278473 > URL: https://svnweb.freebsd.org/changeset/base/278473 > > Log: > Add x2APIC support. Enable it by default if CPU is capable. The > hw.x2apic_enable tunable allows disabling it from the loader prompt. > > This breaks VMware Fusion when the host CPU has x2APIC support. In > my case, mpt(4) was unable to receive interrupts and USB was similarly > broken. It's possible that this is a VMware bug, but you might want to > avoid turning this on when running under the VMware hypervisor. Neel pointed this out to me when the patch was reviewed. He told me that x2APIC does not work in Fusion 5.x, while it seems to be fixed in 7.x. https://communities.vmware.com/message/2173695?tstart=0 Upon further discussion with Neel and Peter, it was suggested that we enable enable x2APIC unconditionally, which seems what is done for Linux benchmarks. Is vmware 5.x is used while there is already at least version 7.x ? I have no idea about vmware product nomenclature and lifecycle. ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r278473 - in head/sys: amd64/amd64 amd64/include amd64/vmm contrib/dev/acpica/include i386/i386 i386/include x86/acpica x86/include x86/x86 x86/xen
On Feb 09, 2015, at 01:01 PM, Konstantin Belousov wrote: Author: kib Date: Mon Feb 9 21:00:56 2015 New Revision: 278473 URL: https://svnweb.freebsd.org/changeset/base/278473 Log: Add x2APIC support. Enable it by default if CPU is capable. The hw.x2apic_enable tunable allows disabling it from the loader prompt. This breaks VMware Fusion when the host CPU has x2APIC support. In my case, mpt(4) was unable to receive interrupts and USB was similarly broken. It's possible that this is a VMware bug, but you might want to avoid turning this on when running under the VMware hypervisor. ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r278473 - in head/sys: amd64/amd64 amd64/include amd64/vmm contrib/dev/acpica/include i386/i386 i386/include x86/acpica x86/include x86/x86 x86/xen
Author: kib Date: Mon Feb 9 21:00:56 2015 New Revision: 278473 URL: https://svnweb.freebsd.org/changeset/base/278473 Log: Add x2APIC support. Enable it by default if CPU is capable. The hw.x2apic_enable tunable allows disabling it from the loader prompt. To closely repeat effects of the uncached memory ops when accessing registers in the xAPIC mode, the x2APIC writes to MSRs are preceeded by mfence, except for the EOI notifications. This is probably too strict, only ICR writes to send IPI require serialization to ensure that other CPUs see the previous actions when IPI is delivered. This may be changed later. In vmm justreturn IPI handler, call doreti_iret instead of doing iretd inline, to handle corner conditions. Note that the patch only switches LAPICs into x2APIC mode. It does not enables FreeBSD to support > 255 CPUs, which requires parsing x2APIC MADT entries and doing interrupts remapping, but is the required step on the way. Reviewed by: neel Tested by:pho (real hardware), neel (on bhyve) Discussed with: jhb, grehan Sponsored by: The FreeBSD Foundation MFC after:2 months Modified: head/sys/amd64/amd64/apic_vector.S head/sys/amd64/amd64/genassym.c head/sys/amd64/amd64/mp_machdep.c head/sys/amd64/include/cpufunc.h head/sys/amd64/vmm/vmm_support.S head/sys/contrib/dev/acpica/include/actbl2.h head/sys/i386/i386/apic_vector.s head/sys/i386/i386/genassym.c head/sys/i386/i386/mp_machdep.c head/sys/i386/include/cpufunc.h head/sys/x86/acpica/madt.c head/sys/x86/include/apicreg.h head/sys/x86/include/apicvar.h head/sys/x86/include/specialreg.h head/sys/x86/x86/io_apic.c head/sys/x86/x86/local_apic.c head/sys/x86/xen/xen_apic.c Modified: head/sys/amd64/amd64/apic_vector.S == --- head/sys/amd64/amd64/apic_vector.S Mon Feb 9 19:28:11 2015 (r278472) +++ head/sys/amd64/amd64/apic_vector.S Mon Feb 9 21:00:56 2015 (r278473) @@ -39,6 +39,7 @@ #include "opt_smp.h" #include +#include #include #include "assym.s" @@ -49,6 +50,22 @@ #define LK #endif + .text + SUPERALIGN_TEXT + /* End Of Interrupt to APIC */ +as_lapic_eoi: + cmpl$0,x2apic_mode + jne 1f + movqlapic_map,%rax + movl$0,LA_EOI(%rax) + ret +1: + movl$MSR_APIC_EOI,%ecx + xorl%eax,%eax + xorl%edx,%edx + wrmsr + ret + /* * I/O Interrupt Entry Point. Rather than having one entry point for * each interrupt source, we use one entry point for each 32-bit word @@ -62,15 +79,22 @@ IDTVEC(vec_name) ; \ PUSH_FRAME ;\ FAKE_MCOUNT(TF_RIP(%rsp)) ; \ - movqlapic, %rdx ; /* pointer to local APIC */ \ + cmpl$0,x2apic_mode ;\ + je 1f ;\ + movl$(MSR_APIC_ISR0 + index),%ecx ; \ + rdmsr ; \ + jmp 2f ;\ +1: ; \ + movqlapic_map, %rdx ; /* pointer to local APIC */ \ movlLA_ISR + 16 * (index)(%rdx), %eax ; /* load ISR */ \ +2: ; \ bsrl%eax, %eax ;/* index of highest set bit in ISR */ \ - jz 1f ;\ + jz 3f ;\ addl$(32 * index),%eax ;\ movq%rsp, %rsi ; \ movl%eax, %edi ;/* pass the IRQ */ \ calllapic_handle_intr ; \ -1: ; \ +3: ; \ MEXITCOUNT ;\ jmp doreti @@ -160,8 +184,7 @@ IDTVEC(xen_intr_upcall) SUPERALIGN_TEXT invltlb_ret: - movqlapic, %rax - movl$0, LA_EOI(%rax)/* End Of Interrupt to APIC */ + callas_lapic_eoi POP_FRAME jmp doreti_iret @@ -228,8 +251,7 @@ IDTVEC(invlcache) IDTVEC(ipi_intr_bitmap_handler) PUSH_FRAME - movqlapic, %rdx - movl$0, LA_EOI(%rdx)/* End Of Interrupt to APIC */ + callas_lapic_eoi FAKE_MCOUNT(TF_RIP(%rsp)) @@ -245,8 +267,7 @@ IDTVEC(ipi_intr_bitma
