On Thu, Nov 06, 2008 at 06:32:32PM -0800, Jay Lan wrote:
> IA64 kdump kernel failed to initialize /proc/vmcore in 2.6.28-rc2.
> A bug was introduced in this patch commit:
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=d9a9855d0b06ca6d6cc92596fedcc03f8512e062
>
>
IA64 kdump kernel failed to initialize /proc/vmcore in 2.6.28-rc2.
A bug was introduced in this patch commit:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=d9a9855d0b06ca6d6cc92596fedcc03f8512e062
The problem was that the call to reserve_elfcorehdr() should be pla
On Fri, 7 Nov 2008, Matthew Garrett wrote:
> On Thu, Nov 06, 2008 at 07:30:43PM -0600, Robert Hancock wrote:
>
> > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=8fd145917fb62368a9b80db59562c20576238f5a
> >
> > This patch ignores the RESET_REG_SUP flag and just tri
On Thu, Nov 06, 2008 at 07:30:43PM -0600, Robert Hancock wrote:
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=8fd145917fb62368a9b80db59562c20576238f5a
>
> This patch ignores the RESET_REG_SUP flag and just tries using the reset
> register anyway if it thinks it's
Matthew Garrett wrote:
> On Fri, Nov 07, 2008 at 09:01:19AM +0800, Zhao Yakui wrote:
>
>> With the help of KVM I find that the windows will be rebooted by writing
>> RESET_VALUE to RESET_REG I/O port if the RESET_REG_SUP bit is not
>> zero(It indicates whether ACPI reboot is supported).
>> IMO may
On Fri, Nov 07, 2008 at 09:01:19AM +0800, Zhao Yakui wrote:
> With the help of KVM I find that the windows will be rebooted by writing
> RESET_VALUE to RESET_REG I/O port if the RESET_REG_SUP bit is not
> zero(It indicates whether ACPI reboot is supported).
> IMO maybe the ACPI reboot is the first
On Fri, 2008-11-07 at 06:17 +0800, Len Brown wrote:
>
> > > My expectation is that with the ACPI default, our problem
> > > is working around a finite list of old machines that don't work;
> > > while with the default KBD, our problem is working around
> > > a potentially unbounded list of yet to
On Thu, Nov 06, 2008 at 05:17:25PM -0500, Len Brown wrote:
> > Does Windows default to using the ACPI method now?
>
> That is my guess, based on the fact that we've seen
> newer machines that don't reboot w/o using the ACPI reset reg.
We've seen machines that won't reboot for a variety of reasons
> > My expectation is that with the ACPI default, our problem
> > is working around a finite list of old machines that don't work;
> > while with the default KBD, our problem is working around
> > a potentially unbounded list of yet to be shipped machines
> > who may only be tested and work using
On Thu, Nov 06, 2008 at 02:50:06PM -0500, Len Brown wrote:
> My expectation is that with the ACPI default, our problem
> is working around a finite list of old machines that don't work;
> while with the default KBD, our problem is working around
> a potentially unbounded list of yet to be shipped
[I had to trim direct recipients as my provider would refuse deliver
claiming it is spam]
On Thursday 06 November 2008, Ingo Molnar wrote:
>
> * Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> > > Andrey Borzenkov's patch, for example, adds a new DMI entry
> > > because reboot=acpi breaks his keyboa
> > This reverts commit c7ffa6c26277b403920e2255d10df849bd613380.
I agree that the 2.6.27 default was changed to ACPI for the wrong reason.
However, I think it was the right thing to do,
and if you didn't propose it, I would.
My expectation is that with the ACPI default, our problem
is working
Hi!
> > > --- /dev/null
> > > +++ b/arch/x86/kernel/virtext.c
> > > @@ -0,0 +1,89 @@
> > > +/* Core CPU virtualization extensions handling
> > > + *
> > > + * This should carry the code for handling CPU virtualization extensions
> > > + * that needs to live in the kernel core.
> > > + *
> > > + *
On Thu, Nov 06, 2008 at 12:30:51PM +0200, Avi Kivity wrote:
> Eric W. Biederman wrote:
>>
>>> If you want to be extra simple and safe, remove kvm from the equation.
>>> Make the
>>> disabling code part of kdump/emergency_restart and only rely on the
>>> convention
>>> that cr3.vmxe == vmxon.
>>>
Eric W. Biederman wrote:
> If there are a number of problems with reboot and reset
> I'm wondering if we should investigate using an
> outb to port 0x92. With the right bit set you can trigger
> a toggle of the reset line on many motherboards.
>
Most likely that's what the ACPI reset describes
Ingo Molnar <[EMAIL PROTECTED]> writes:
> * Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
>> > Andrey Borzenkov's patch, for example, adds a new DMI entry
>> > because reboot=acpi breaks his keyboard (even without KVM, I
>> > guess). Andrey, was that the case?
>>
>> hm, IIRC the problem was KVM in h
On Wed, Nov 05, 2008 at 11:27:32PM +0100, Pavel Machek wrote:
> On Wed 2008-11-05 17:56:52, Eduardo Habkost wrote:
> > This patch adds an interface to set a function that can be used to
> > disable virtualization extensions on the CPU on emergency cases, such
> > as on kdump or emergency reboot.
>
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > Andrey Borzenkov's patch, for example, adds a new DMI entry
> > because reboot=acpi breaks his keyboard (even without KVM, I
> > guess). Andrey, was that the case?
>
> hm, IIRC the problem was KVM in his case too.
actually, Andrey's problem seems t
* Eduardo Habkost <[EMAIL PROTECTED]> wrote:
> On Thu, Nov 06, 2008 at 08:14:45AM +0100, Ingo Molnar wrote:
> >
> > * Eduardo Habkost <[EMAIL PROTECTED]> wrote:
> >
> > > This reverts commit c7ffa6c26277b403920e2255d10df849bd613380.
> > >
> > > Now that we have the hooks to disable virtualizat
On Thu, Nov 06, 2008 at 08:14:45AM +0100, Ingo Molnar wrote:
>
> * Eduardo Habkost <[EMAIL PROTECTED]> wrote:
>
> > This reverts commit c7ffa6c26277b403920e2255d10df849bd613380.
> >
> > Now that we have the hooks to disable virtualization on
> > emergency_restart(), we can get back to the BOOT_K
On Thu, Nov 06, 2008 at 11:49:57AM +0200, Avi Kivity wrote:
> Ingo Molnar wrote:
>> general ack for the x86 bits, but i'm not sure whether we should be
>> pushing this upstream so late in the cycle. If we do it in the next
>> cycle then it's best we do it in the x86 tree, the KVM impact seems
Eric W. Biederman wrote:
>
>> If you want to be extra simple and safe, remove kvm from the equation. Make
>> the
>> disabling code part of kdump/emergency_restart and only rely on the
>> convention
>> that cr3.vmxe == vmxon.
>>
> Convention?
>
There is a de-facto convention supported by
Avi Kivity <[EMAIL PROTECTED]> writes:
> Eduardo Habkost wrote:
>> We could move the set_virt_disable_func() calls to vmx.c and svm.c (on
>> hardware_setup/hardware_unsetup). One could argue that it is sort of a
>> coincidence that we need the code for both vmx and svm.
>>
>
> I don't share this f
Vivek Goyal wrote:
> Is there a way we can prevent any other module from using virt disable
> callback incase kvm is not loaded?
>
We can inline the kvm specific code (which will make it useful for other
hypervisors, and remove the hook).
--
error compiling committee.c: too many arguments t
Ingo Molnar wrote:
> general ack for the x86 bits, but i'm not sure whether we should be
> pushing this upstream so late in the cycle. If we do it in the next
> cycle then it's best we do it in the x86 tree, the KVM impact seems
> much smaller than the general x86 impact.
>
It certainly does
Eduardo Habkost wrote:
> We could move the set_virt_disable_func() calls to vmx.c and svm.c (on
> hardware_setup/hardware_unsetup). One could argue that it is sort of a
> coincidence that we need the code for both vmx and svm.
>
I don't share this fear of function calls, but perhaps that's due
Eric W. Biederman wrote:
>>
>> +r = set_virt_disable_func(crash_hardware_disable);
>>
>
> Can we make this say:
> set_virt_disable_func(kvm_x86_ops->crash_hardware_disable);
>
> So we can avoid going through 2 levels of function pointers?
> I find that a little scary in code that might b
27 matches
Mail list logo
