On 27 May 2014 19:45, Dave Hansen wrote:
>
> I don't think this is quite right. pfn_valid() tells us whether we have
> a 'struct page' there or not. *BUT*, it does not tell us whether it is
> RAM that we can actually address and than can be freed in to the buddy
> allocator.
>
> I think
On 27 May 2014 19:45, Dave Hansen dave.han...@intel.com wrote:
I don't think this is quite right. pfn_valid() tells us whether we have
a 'struct page' there or not. *BUT*, it does not tell us whether it is
RAM that we can actually address and than can be freed in to the buddy
allocator.
I
On 2 June 2014 11:31, Catalin Marinas wrote:
> This patch fixes a few compiler warning in the efi code for unused
> variable, discarding const qualifier and wrong pointer type:
>
> drivers/firmware/efi/fdt.c|66 col 22| warning: unused variable ‘name’
> [-Wunused-variable]
>
On 2 June 2014 11:31, Catalin Marinas catalin.mari...@arm.com wrote:
This patch fixes a few compiler warning in the efi code for unused
variable, discarding const qualifier and wrong pointer type:
drivers/firmware/efi/fdt.c|66 col 22| warning: unused variable ‘name’
[-Wunused-variable]
On 29 May 2014 13:59, Vivek Goyal wrote:
>
> Only second kernel boots with "noefi" and this parameter is appened by
> kexec-tools to second kernel command line. So first kernel will still
> boot *without noefi* and kexec-tools wil think that this system support
> booting second kernel with UEFI
On 28 May 2014 20:04, Vivek Goyal wrote:
> On Wed, May 28, 2014 at 10:51:04AM -0500, Alex Thorlton wrote:
>
> [..]
>> A side note, though: We're going to have to figure out some way to
>> determine whether or not to apply the old_map quirk on during boot
>> anyway, so if it's easiest for you to
On 28 May 2014 15:51, Vivek Goyal wrote:
> On Wed, May 28, 2014 at 10:09:35AM +0800, Dave Young wrote:
>
> [..]
>> > I've only vaguely been following along with the other thread, so please
>> > summarise everything again in your patch. Particularly, I need answers
>> > to the following questions,
On 28 May 2014 15:51, Vivek Goyal vgo...@redhat.com wrote:
On Wed, May 28, 2014 at 10:09:35AM +0800, Dave Young wrote:
[..]
I've only vaguely been following along with the other thread, so please
summarise everything again in your patch. Particularly, I need answers
to the following
On 28 May 2014 20:04, Vivek Goyal vgo...@redhat.com wrote:
On Wed, May 28, 2014 at 10:51:04AM -0500, Alex Thorlton wrote:
[..]
A side note, though: We're going to have to figure out some way to
determine whether or not to apply the old_map quirk on during boot
anyway, so if it's easiest for
On 29 May 2014 13:59, Vivek Goyal vgo...@redhat.com wrote:
Only second kernel boots with noefi and this parameter is appened by
kexec-tools to second kernel command line. So first kernel will still
boot *without noefi* and kexec-tools wil think that this system support
booting second kernel
On 27 May 2014 04:00, Dave Young wrote:
> On 05/26/14 at 04:39pm, Dave Young wrote:
>>
>> For efi=old_map and any old_map quirks like SGI UV in current
>> tree kexec/kdump will fail because it depends on the new 1:1 mapping.
>>
>> Thus export the mapping method to sysfs so kexec tools can switch
On 27 May 2014 04:00, Dave Young dyo...@redhat.com wrote:
On 05/26/14 at 04:39pm, Dave Young wrote:
For efi=old_map and any old_map quirks like SGI UV in current
tree kexec/kdump will fail because it depends on the new 1:1 mapping.
Thus export the mapping method to sysfs so kexec tools can
On 7 April 2014 21:42, Andi Kleen wrote:
>
> This sounds like the UEFI boot corrupts some memory?
Hmpf, yeah. I'll take a look in the morning.
Thomas, you mention you're running in a 32-bit vm earlier in this
thread. Any chance you're using ovmf because that would make it much
easier to track
On 7 April 2014 21:42, Andi Kleen a...@linux.intel.com wrote:
This sounds like the UEFI boot corrupts some memory?
Hmpf, yeah. I'll take a look in the morning.
Thomas, you mention you're running in a 32-bit vm earlier in this
thread. Any chance you're using ovmf because that would make it much
On 4 October 2013 16:46, Seiji Aguchi wrote:
> Are there anyone who can review this bugfix?
Sorry I haven't got to it yet (or the previous version). It is on my TODO list.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
On 4 October 2013 16:46, Seiji Aguchi seiji.agu...@hds.com wrote:
Are there anyone who can review this bugfix?
Sorry I haven't got to it yet (or the previous version). It is on my TODO list.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to
On 1 August 2013 21:26, H. Peter Anvin wrote:
> Matt, I assume you're picking this up once the missing bits are plugged
> in, right?
Yep, that was my plan.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More
On 1 August 2013 21:26, H. Peter Anvin h...@zytor.com wrote:
Matt, I assume you're picking this up once the missing bits are plugged
in, right?
Yep, that was my plan.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
On 17 July 2013 01:32, H. Peter Anvin wrote:
> On 07/10/2013 04:39 AM, Fleming, Matt wrote:
>> On 10 July 2013 12:34, Maarten Lankhorst
>> wrote:
>>> Hey,
>>>
>>> It seems that in the merge window my macbook pro stopped working at some
>>> poi
On 17 July 2013 01:32, H. Peter Anvin h...@zytor.com wrote:
On 07/10/2013 04:39 AM, Fleming, Matt wrote:
On 10 July 2013 12:34, Maarten Lankhorst
maarten.lankho...@canonical.com wrote:
Hey,
It seems that in the merge window my macbook pro stopped working at some
point. I looked
On 10 July 2013 12:34, Maarten Lankhorst
wrote:
> Hey,
>
> It seems that in the merge window my macbook pro stopped working at some
> point. I looked for suspicious
> efi related commits, and found that reverting commit
> 1acba98f810a14b1255e34bc620594f83de37e36 worked,
> letting my macbook pro
On 10 July 2013 12:34, Maarten Lankhorst
maarten.lankho...@canonical.com wrote:
Hey,
It seems that in the merge window my macbook pro stopped working at some
point. I looked for suspicious
efi related commits, and found that reverting commit
1acba98f810a14b1255e34bc620594f83de37e36 worked,
On 21 June 2013 00:43, Tony Luck wrote:
> Oops - pasted in old e-mail address for Boris
Applied, thanks Tony.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
On 21 June 2013 00:43, Tony Luck tony.l...@gmail.com wrote:
Oops - pasted in old e-mail address for Boris
Applied, thanks Tony.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at
On 4 June 2013 04:35, joeyli wrote:
> 於 一，2013-06-03 於 16:31 +，Matthew Garrett 提到：
>> On Tue, 2013-06-04 at 00:13 +0800, joeyli wrote:
>>
>> > Oliver raised a question for if power fails between that succesful
>> > attempt and the deletion?
>>
>> It's a pretty tiny window, but sure. Making
On 4 June 2013 04:35, joeyli j...@suse.com wrote:
於 一，2013-06-03 於 16:31 +，Matthew Garrett 提到：
On Tue, 2013-06-04 at 00:13 +0800, joeyli wrote:
Oliver raised a question for if power fails between that succesful
attempt and the deletion?
It's a pretty tiny window, but sure. Making sure
On 26 April 2013 15:28, Seiji Aguchi wrote:
> Matt,
>
> I built a tip tree With CONFIG_EFIVAR_FS=y.
> But, I can't see any entries in the directory of /sys/firmware/efi/efivarfs...
>
> I'm not sure if it is a problem.
> Just let you know.
Did you mount the efivarfs file system there?
--
To
On 26 April 2013 15:28, Seiji Aguchi seiji.agu...@hds.com wrote:
Matt,
I built a tip tree With CONFIG_EFIVAR_FS=y.
But, I can't see any entries in the directory of /sys/firmware/efi/efivarfs...
I'm not sure if it is a problem.
Just let you know.
Did you mount the efivarfs file system
28 matches
Mail list logo
