tip/master broken with x2apic and kexec [Kernel]

Prev: Staging: wlan-ng: fix checkpatch warnings in hfa384x.h
Next: isdn: autoconvert trivial BKL users to private mutex

From: Yinghai Lu on 12 Jul 2010 23:10

tip/master:
system1: BIOS enabled x2apic, first kernel boot well, and when kexec second kernel will cause system instant reboot.

system2: BIOS not enable x2apic, first kernel boot well and enable x2apic, and kexec second kernel well. but when kexec third kernel will case system instant reboot.

linus' tree is ok.

but for system2 if boot with nox2apic ,intr-remaping off, iommu off, the kexec loop test will pass.

the problem looks start in recent two or three weeks.

Any idea?

bisecting will take a while, because the system post take a while everytime.

Thanks

Yinghai Lu
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

From: Yinghai Lu on 12 Jul 2010 23:40

On 07/12/2010 07:59 PM, Yinghai Lu wrote:
> tip/master:
> system1: BIOS enabled x2apic, first kernel boot well, and when kexec second kernel will cause system instant reboot.
>
> system2: BIOS not enable x2apic, first kernel boot well and enable x2apic, and kexec second kernel well. but when kexec third kernel will case system instant reboot.
>
> linus' tree is ok.
>
> but for system2 if boot with nox2apic ,intr-remaping off, iommu off, the kexec loop test will pass.
>
> the problem looks start in recent two or three weeks.
>

offending patch is

commit 83a7a2ad2a9173dcabc05df0f01d1d85b7ba1c2c
Author: H. Peter Anvin <hpa(a)linux.intel.com>
Date: Thu Jun 10 00:10:43 2010 +0000

x86, alternatives: Use 16-bit numbers for cpufeature index

We already have cpufeature indicies above 255, so use a 16-bit number
for the alternatives index. This consumes a padding field and so
doesn't add any size, but it means that abusing the padding field to
create assembly errors on overflow no longer works. We can retain the
test simply by redirecting it to the .discard section, however.

[ v3: updated to include open-coded locations ]

Signed-off-by: H. Peter Anvin <hpa(a)linux.intel.com>
LKML-Reference: <tip-f88731e3068f9d1392ba71cc9f50f035d26a0d4f(a)git.kernel.org>
Signed-off-by: H. Peter Anvin <hpa(a)zytor.com>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

From: H. Peter Anvin on 13 Jul 2010 02:50

On 07/12/2010 08:29 PM, Yinghai Lu wrote:
>
> offending patch is
>
> commit 83a7a2ad2a9173dcabc05df0f01d1d85b7ba1c2c
> Author: H. Peter Anvin<hpa(a)linux.intel.com>
> Date: Thu Jun 10 00:10:43 2010 +0000
>
> x86, alternatives: Use 16-bit numbers for cpufeature index
>
> We already have cpufeature indicies above 255, so use a 16-bit number
> for the alternatives index. This consumes a padding field and so
> doesn't add any size, but it means that abusing the padding field to
> create assembly errors on overflow no longer works. We can retain the
> test simply by redirecting it to the .discard section, however.
>
> [ v3: updated to include open-coded locations ]
>
> Signed-off-by: H. Peter Anvin<hpa(a)linux.intel.com>
> LKML-Reference:<tip-f88731e3068f9d1392ba71cc9f50f035d26a0d4f(a)git.kernel.org>
> Signed-off-by: H. Peter Anvin<hpa(a)zytor.com>
>

Oh, good grief, what the hell is wrong with it this time...

-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

From: H. Peter Anvin on 13 Jul 2010 18:10

From: Yinghai Lu on 13 Jul 2010 19:40

On 07/13/2010 03:00 PM, H. Peter Anvin wrote:
> On 07/12/2010 07:59 PM, Yinghai Lu wrote:
>> tip/master:
>> system1: BIOS enabled x2apic, first kernel boot well, and when kexec second kernel will cause system instant reboot.
>>
>> system2: BIOS not enable x2apic, first kernel boot well and enable x2apic, and kexec second kernel well. but when kexec third kernel will case system instant reboot.
>>
>> linus' tree is ok.
>>
>> but for system2 if boot with nox2apic ,intr-remaping off, iommu off, the kexec loop test will pass.
>>
>> the problem looks start in recent two or three weeks.
>>
>> Any idea?
>>
>> bisecting will take a while, because the system post take a while everytime.
>>
>> Thanks
>>
>> Yinghai Lu
>
> OK, I found the bug... if you could test out the patch which will be
> sent out shortly I would very much appreciate it.

not sure if your patch is the offending one now.

kL: kernel from linus tree
kT1: kernel from tip
kT2: kernel from tip with reverting your patch

BIOS-->kL ---> kL ---> kL....always working
BIOS-->kT1 ---> kT1 ---> kT1 : between second one and third one system reset instant...
BIOS-->kT2 ---> kT2 ---> kT2 : between second one and third one system reset instant...

BIOS-->kL ---> kL ---> kL ---> then kT1 ---> kT1 .... always working
BIOS-->kL ---> kL ---> kL ---> then kT2 ---> kT2 .... always working

looks like first kernel and second one can not be kernel from tip.

Yinghai
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

| Next | Last
Pages: 1 2 3
Prev: Staging: wlan-ng: fix checkpatch warnings in hfa384x.h
Next: isdn: autoconvert trivial BKL users to private mutex