On Sat, Jun 01, 2013 at 08:01:59PM +0900, Linus Torvalds wrote:
> On Fri, 31 May 2013, Matthew Garrett wrote:
> >
> > I agree that a revert is probably the right thing to do here, but the
> > original patch was there to permit a more accurate calculation of the
> > amount of nvram in use, not to
On Fri, 31 May 2013, Matthew Garrett wrote:
>
> I agree that a revert is probably the right thing to do here, but the
> original patch was there to permit a more accurate calculation of the
> amount of nvram in use, not to provide additional debug information.
> Reverting it is going to diffe
On Fri, May 31, 2013 at 11:20:59PM -0500, Russ Anderson wrote:
> And when QueryVariableInfo reports insufficient space, don't write
> and everything is fine.
And then installs fail, which is why we implemented this additional
code.
> But when QueryVariableInfo reports insufficient space and you
On Sat, Jun 01, 2013 at 01:03:11AM +0100, Matthew Garrett wrote:
> On Fri, May 31, 2013 at 05:57:31PM -0500, Russ Anderson wrote:
> > On Fri, May 31, 2013 at 05:28:16PM +0100, Matthew Garrett wrote:
> > > If nvram becaomes full, some
> > > systems crash du
On Fri, May 31, 2013 at 05:57:31PM -0500, Russ Anderson wrote:
> On Fri, May 31, 2013 at 05:28:16PM +0100, Matthew Garrett wrote:
> > If nvram becaomes full, some
> > systems crash during firmware initialisation. So we can't let nvram
> > become full. The
On Fri, 31 May 2013, Russ Anderson wrote:
> OK. I get nvram looks full due to lack of garbage collection
> on some systems. Does QueryVariableInfo (at runtime) tell you
> it is full? Is the problem that it says it is full when it
> is not, or does not tell you it is full when it is?
We are try
On 05/31/2013 03:57 PM, Russ Anderson wrote:
>
>>> Which means the previous patch(es) that caused the bricking should
>>> get pulled, too.
>>
>> There are no patches that cause the bricking.
>
> I thought that was the problem you were trying to avoid.
>
There are no *patches* that cause the bri
On Fri, May 31, 2013 at 05:28:16PM +0100, Matthew Garrett wrote:
> On Fri, May 31, 2013 at 10:43:49AM -0500, Russ Anderson wrote:
>
> > When did writing EFI variables to nvram become necessary to boot on
> > UEFI? And if it is necessary, why is it that only linux boot loaders
> > that use EFI st
On Fri, 2013-05-31 at 17:28 +0100, Matthew Garrett wrote:
> On Fri, May 31, 2013 at 10:43:49AM -0500, Russ Anderson wrote:
>
> > When did writing EFI variables to nvram become necessary to boot on
> > UEFI? And if it is necessary, why is it that only linux boot loaders
> > that use EFI stubs (ge
On Fri, May 31, 2013 at 10:43:49AM -0500, Russ Anderson wrote:
> When did writing EFI variables to nvram become necessary to boot on
> UEFI? And if it is necessary, why is it that only linux boot loaders
> that use EFI stubs (generally grub2) need it? The current kernel
> boots using EFI/grub
On Fri, May 31, 2013 at 03:48:26PM +0100, Matthew Garrett wrote:
> On Fri, May 31, 2013 at 07:42:37AM -0700, James Bottomley wrote:
> > On Fri, 2013-05-31 at 15:34 +0100, Matthew Garrett wrote:
> > > I agree that a revert is probably the right thing to do here, but the
> > > original patch was the
On Fri, May 31, 2013 at 07:42:37AM -0700, James Bottomley wrote:
> On Fri, 2013-05-31 at 15:34 +0100, Matthew Garrett wrote:
> > I agree that a revert is probably the right thing to do here, but the
> > original patch was there to permit a more accurate calculation of the
> > amount of nvram in u
On 05/31/2013 07:42 AM, James Bottomley wrote:
>
> The only ones that are broken are the Samsung ones. Samsung claims to
> have fixed their UEFI firmware, so we could refer any problems to them.
>
> The signature of the Samsung failure, which this is guarding against is
> that the laptop gets br
On Fri, 2013-05-31 at 15:34 +0100, Matthew Garrett wrote:
> On Fri, May 31, 2013 at 02:43:56PM +0200, Ingo Molnar wrote:
>
> > 4) The revert is easy, and the functionality the original patch provided
> >was a marginal increase in debug output to begin with...
>
> I agree that a revert is prob
On 05/29/2013 01:16 PM, Russ Anderson wrote:
>
> To be more specific (now that I've dug through the code), grub2 (used
> by rhel7) uses EFI boot stubs. grub and elilo apparently do not use
> EFI boot stubs, so they don't hit the problem (at least on my test
> systems).
>
Grub2 *can* use the EFI
On Fri, May 31, 2013 at 02:43:56PM +0200, Ingo Molnar wrote:
> 4) The revert is easy, and the functionality the original patch provided
>was a marginal increase in debug output to begin with...
I agree that a revert is probably the right thing to do here, but the
original patch was there to
* Borislav Petkov wrote:
> On Fri, May 31, 2013 at 01:06:09PM +0200, Jiri Kosina wrote:
> >
> > (*) If one would be naive enough, he'd believe that the pressure
> > should be put on the BIOS writers instead of OS to fix the bug :)
>
> Oh, definitely pressure on BIOS dudes. If they're in violat
On Fri, May 31, 2013 at 01:06:09PM +0200, Jiri Kosina wrote:
> (*) If one would be naive enough, he'd believe that the pressure
> should be put on the BIOS writers instead of OS to fix the bug :)
Oh, definitely pressure on BIOS dudes. If they're in violation of the
spec and they still can fix it i
On Fri, May 31, 2013 at 7:40 AM, Ingo Molnar wrote:
>
> * Jiri Kosina wrote:
>
>> On Fri, 31 May 2013, Ingo Molnar wrote:
>>
>> > > Unfortunately that means that you can as well throw the patch away
>> > > completely.
>> > >
>> > > The sole point is to run the QueryVariableInfo() from the boot
>>
* Jiri Kosina wrote:
> On Fri, 31 May 2013, Ingo Molnar wrote:
>
> > > Unfortunately that means that you can as well throw the patch away
> > > completely.
> > >
> > > The sole point is to run the QueryVariableInfo() from the boot
> > > environment, in order to obtain more accurate informatio
On Fri, 31 May 2013, Ingo Molnar wrote:
> So this change needs to be reverted or fixed.
I don't think anyone is arguing against that.
My remark was purely to describe the current status quo and help to
understand what exactly is happening, i.e.:
- QueryVariableInfo() should be a valid thing to
* Jiri Kosina wrote:
> On Thu, 30 May 2013, Russ Anderson wrote:
>
> > > > > > Yes, but this call is clearly happening way before
> > > > > > ExitBootServices() --
> > > > > > see the surrounding code, see for example this in efi_main():
> > > > > >
> > > > > > [ ... snip ... ]
> > > > > >
* Russ Anderson wrote:
> On Thu, May 30, 2013 at 10:32:09PM +, Matthew Garrett wrote:
> > On Thu, 2013-05-30 at 17:28 -0500, Russ Anderson wrote:
> > > On Thu, May 30, 2013 at 10:21:53PM +, Matthew Garrett wrote:
> > > > On Thu, 2013-05-30 at 17:17 -0500, Russ Anderson wrote:
> > > >
>
於 四，2013-05-30 於 21:17 -0500，Russ Anderson 提到：
> On Fri, May 31, 2013 at 12:30:43AM +0200, Jiri Kosina wrote:
> > On Thu, 30 May 2013, Russ Anderson wrote:
> >
> > > > > That's a great idea. This patch moves the QueryVariableInfo()
> > > > > call from bootime to runtime, in efi_late_init(). The
On Thu, May 30, 2013 at 10:32:09PM +, Matthew Garrett wrote:
> On Thu, 2013-05-30 at 17:28 -0500, Russ Anderson wrote:
> > On Thu, May 30, 2013 at 10:21:53PM +, Matthew Garrett wrote:
> > > On Thu, 2013-05-30 at 17:17 -0500, Russ Anderson wrote:
> > >
> > > > That's a great idea. This pat
On Fri, May 31, 2013 at 12:30:43AM +0200, Jiri Kosina wrote:
> On Thu, 30 May 2013, Russ Anderson wrote:
>
> > > > That's a great idea. This patch moves the QueryVariableInfo()
> > > > call from bootime to runtime, in efi_late_init(). The attached
> > > > patch is consistent with the UEFI spec a
On Thu, 2013-05-30 at 17:28 -0500, Russ Anderson wrote:
> On Thu, May 30, 2013 at 10:21:53PM +, Matthew Garrett wrote:
> > On Thu, 2013-05-30 at 17:17 -0500, Russ Anderson wrote:
> >
> > > That's a great idea. This patch moves the QueryVariableInfo()
> > > call from bootime to runtime, in efi
On Thu, 30 May 2013, Russ Anderson wrote:
> > > That's a great idea. This patch moves the QueryVariableInfo()
> > > call from bootime to runtime, in efi_late_init(). The attached
> > > patch is consistent with the UEFI spec and avoids the problem.
> >
> > No, that defeats the entire point of th
On Thu, May 30, 2013 at 10:21:53PM +, Matthew Garrett wrote:
> On Thu, 2013-05-30 at 17:17 -0500, Russ Anderson wrote:
>
> > That's a great idea. This patch moves the QueryVariableInfo()
> > call from bootime to runtime, in efi_late_init(). The attached
> > patch is consistent with the UEFI
On Thu, 30 May 2013, Russ Anderson wrote:
> > > > > Yes, but this call is clearly happening way before ExitBootServices()
> > > > > --
> > > > > see the surrounding code, see for example this in efi_main():
> > > > >
> > > > > [ ... snip ... ]
> > > > > setup_efi_vars(boot_params);
> > >
On Thu, 2013-05-30 at 17:17 -0500, Russ Anderson wrote:
> That's a great idea. This patch moves the QueryVariableInfo()
> call from bootime to runtime, in efi_late_init(). The attached
> patch is consistent with the UEFI spec and avoids the problem.
No, that defeats the entire point of the orig
On Thu, May 30, 2013 at 10:16:12AM +0800, joeyli wrote:
> 於 四，2013-05-30 於 00:53 +0200，Jiri Kosina 提到：
> > On Wed, 29 May 2013, Russ Anderson wrote:
> >
> > > > Yes, but this call is clearly happening way before ExitBootServices()
> > > > --
> > > > see the surrounding code, see for example this
於 三，2013-05-29 於 17:46 -0500，Russ Anderson 提到：
> On Thu, May 30, 2013 at 12:22:13AM +0200, Jiri Kosina wrote:
> > On Wed, 29 May 2013, Russ Anderson wrote:
> >
> > > > What appears to be happening is that your the EFI runtime services code
> > > > is calling into the EFI boot services code, which
於 四，2013-05-30 於 00:53 +0200，Jiri Kosina 提到：
> On Wed, 29 May 2013, Russ Anderson wrote:
>
> > > Yes, but this call is clearly happening way before ExitBootServices() --
> > > see the surrounding code, see for example this in efi_main():
> > >
> > > [ ... snip ... ]
> > > setup_efi_vars(boot_p
On Wed, 29 May 2013, Russ Anderson wrote:
> > Yes, but this call is clearly happening way before ExitBootServices() --
> > see the surrounding code, see for example this in efi_main():
> >
> > [ ... snip ... ]
> > setup_efi_vars(boot_params);
> >
> > setup_efi_pci(boot_params);
> >
> >
On Thu, May 30, 2013 at 12:22:13AM +0200, Jiri Kosina wrote:
> On Wed, 29 May 2013, Russ Anderson wrote:
>
> > > What appears to be happening is that your the EFI runtime services code
> > > is calling into the EFI boot services code, which is definitely a bug in
> > > your firmware because we're
On Wed, 29 May 2013, Russ Anderson wrote:
> > What appears to be happening is that your the EFI runtime services code
> > is calling into the EFI boot services code, which is definitely a bug in
> > your firmware because we're at runtime, but we've seen other machines
> > that do similar things so
On Fri, May 24, 2013 at 08:43:31AM +0100, Matt Fleming wrote:
> On Thu, 23 May, at 03:32:34PM, Russ Anderson wrote:
> >efi: mem127: type=4, attr=0xf,
> > range=[0x6bb22000-0x7ca9c000) (271MB)
>
> EFI_BOOT_SERVICES_CODE
>
> >efi: mem133: type=5, attr=0x800f,
>
On Fri, May 24, 2013 at 08:45:44AM +0100, Matt Fleming wrote:
> On Thu, 23 May, at 05:23:21PM, Russ Anderson wrote:
> > Interesting data point. The failure is on a rhel7/grub2 root.
> > The identical kernel on a rhel6/grub root boots. So maybe
> > grub2 brings out the failure? I suspect Fedora19
On Fri, 24 May, at 03:05:39PM, Russ Anderson wrote:
> One of the BIOS guys will build a debug bios next week to help see
> what is going on in the query_variable_info() call.
That would be incredibly useful, thanks.
--
Matt Fleming, Intel Open Source Technology Center
--
To unsubscribe from this
On Fri, 24 May, at 03:49:38PM, Russ Anderson wrote:
> Why does the kernel still try to create /sys/firmware/efivars/
> entries in the original failure even though efi_call_phys4()
> failed? Or does it always try to create those entries
> and GetNextVariable() blows up in the original failure
> but
* Matt Fleming wrote:
> What appears to be happening is that your the EFI runtime services code
> is calling into the EFI boot services code, which is definitely a bug in
> your firmware because we're at runtime, but we've seen other machines
> that do similar things so we usually handle it j
On Mon, May 27, 2013 at 12:27:12PM +0800, joeyli wrote:
> Hi Dave,
>
> 於 五，2013-05-24 於 17:05 -0400，Dave Jones 提到：
> > On Fri, May 24, 2013 at 12:02:15PM -0500, Russ Anderson wrote:
> > > On Fri, May 24, 2013 at 11:11:11AM -0500, Robin Holt wrote:
> > > > Russ,
> > > >
> > > > Can we open a
於 一，2013-05-27 於 12:27 +0800，joeyli 提到：
> Hi Dave,
>
> 於 五，2013-05-24 於 17:05 -0400，Dave Jones 提到：
> > On Fri, May 24, 2013 at 12:02:15PM -0500, Russ Anderson wrote:
> > > On Fri, May 24, 2013 at 11:11:11AM -0500, Robin Holt wrote:
> > > > Russ,
> > > >
> > > > Can we open a bug for the BIOS
Hi Dave,
於 五，2013-05-24 於 17:05 -0400，Dave Jones 提到：
> On Fri, May 24, 2013 at 12:02:15PM -0500, Russ Anderson wrote:
> > On Fri, May 24, 2013 at 11:11:11AM -0500, Robin Holt wrote:
> > > Russ,
> > >
> > > Can we open a bug for the BIOS folks and see if we can get this
> addressed?
> >
>
On Fri, May 24, 2013 at 12:02:15PM -0500, Russ Anderson wrote:
> On Fri, May 24, 2013 at 11:11:11AM -0500, Robin Holt wrote:
> > Russ,
> >
> > Can we open a bug for the BIOS folks and see if we can get this addressed?
>
> I already talked with them. It is not in an area that we
> normally
On Fri, May 24, 2013 at 08:11:01PM +, Matthew Garrett wrote:
> On Fri, 2013-05-24 at 15:05 -0500, Russ Anderson wrote:
>
> > One other data point is if the query_variable_info call is hacked to
> > remove one of the EFI flags (ie comment out EFI_VARIABLE_BOOTSERVICE_ACCESS)
> > the efi_call_ph
On Fri, 2013-05-24 at 15:05 -0500, Russ Anderson wrote:
> One other data point is if the query_variable_info call is hacked to
> remove one of the EFI flags (ie comment out EFI_VARIABLE_BOOTSERVICE_ACCESS)
> the efi_call_phys4() call fails with EFI_INVALID_PARAMETER and
> the system boots. Of cou
On Fri, May 24, 2013 at 08:43:31AM +0100, Matt Fleming wrote:
> On Thu, 23 May, at 03:32:34PM, Russ Anderson wrote:
> >efi: mem127: type=4, attr=0xf,
> > range=[0x6bb22000-0x7ca9c000) (271MB)
>
> EFI_BOOT_SERVICES_CODE
>
> >efi: mem133: type=5, attr=0x800f,
>
On Fri, May 24, 2013 at 11:11:11AM -0500, Robin Holt wrote:
> Russ,
>
> Can we open a bug for the BIOS folks and see if we can get this addressed?
I already talked with them. It is not in an area that we
normally change, so if there is a bug may be in the Intel
reference code. More investigatio
Russ,
Can we open a bug for the BIOS folks and see if we can get this addressed?
Robin
On Fri, May 24, 2013 at 08:43:31AM +0100, Matt Fleming wrote:
> On Thu, 23 May, at 03:32:34PM, Russ Anderson wrote:
> >efi: mem127: type=4, attr=0xf,
> > range=[0x6bb22000-0x7ca9c000) (271
On Fri, 24 May, at 01:09:11PM, Borislav Petkov wrote:
> What do you mean, map boot time functions 1:1 too?
Yep, that's what I meant.
--
Matt Fleming, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord.
On Fri, May 24, 2013 at 08:43:31AM +0100, Matt Fleming wrote:
> What appears to be happening is that your the EFI runtime services
> code is calling into the EFI boot services code, which is definitely
> a bug in your firmware because we're at runtime, but we've seen
> other machines that do simila
On Thu, 23 May, at 05:23:21PM, Russ Anderson wrote:
> Interesting data point. The failure is on a rhel7/grub2 root.
> The identical kernel on a rhel6/grub root boots. So maybe
> grub2 brings out the failure? I suspect Fedora19/grub2 on
> EFI should hit the problem (for someone looking to reprodu
On Thu, 23 May, at 03:32:34PM, Russ Anderson wrote:
>efi: mem127: type=4, attr=0xf,
> range=[0x6bb22000-0x7ca9c000) (271MB)
EFI_BOOT_SERVICES_CODE
>efi: mem133: type=5, attr=0x800f,
> range=[0x7daff000-0x7dbff000) (1MB)
EFI_RUNTIME_SERVICES_C
On Thu, May 23, 2013 at 12:58:01PM +0100, Matt Fleming wrote:
> On Wed, 22 May, at 11:27:47AM, Russ Anderson wrote:
> > [6.062157] EFI Variables Facility v0.08 2004-May-17
> > [6.067731] BUG: unable to handle kernel paging request at
> > 7ca95b10
> > [6.075519] IP: [] 0x880
On Thu, May 23, 2013 at 12:58:01PM +0100, Matt Fleming wrote:
> On Wed, 22 May, at 11:27:47AM, Russ Anderson wrote:
> > [6.062157] EFI Variables Facility v0.08 2004-May-17
> > [6.067731] BUG: unable to handle kernel paging request at
> > 7ca95b10
> > [6.075519] IP: [] 0x880
On Wed, 22 May, at 11:27:47AM, Russ Anderson wrote:
> [6.062157] EFI Variables Facility v0.08 2004-May-17
> [6.067731] BUG: unable to handle kernel paging request at 7ca95b10
> [6.075519] IP: [] 0x88007dbf213f
This is a bit of a head scratcher. Could you paste the EFI memma
Linux crashes on boot on SGI UV systems. git bisect tracked it
down to commit cc5a080c5d40c36089bb08a8a16fa3fc7047fe0f. Undoing
that patch fixes the problem.
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=cc5a080c5d40c36089bb08a8a16fa3fc7047fe0f
59 matches
Mail list logo
