Re: [PATCH 4.11 049/150] efi/bgrt: Skip efi_bgrt_init() in case of non-EFI boot

[Maniaxx]

On 12.06.2017 at 17:24 wrote Greg Kroah-Hartman:
> 4.11-stable review patch.  If anyone has any objections, please let me know.
> 
> --
> 
> From: Dave Young 
> 
> commit 7425826f4f7ac60f2538b06a7f0a5d1006405159 upstream.
> 
> Sabrina Dubroca reported an early panic:
> 
>   BUG: unable to handle kernel paging request at ff240001
>   IP: efi_bgrt_init+0xdc/0x134
> 
>   [...]
> 
>   ---[ end Kernel panic - not syncing: Attempted to kill the idle task!
> 
> ... which was introduced by:
> 
>   7b0a911478c7 ("efi/x86: Move the EFI BGRT init code to early init code")
> 
> The cause is that on this machine the firmware provides the EFI ACPI BGRT
> table even on legacy non-EFI bootups - which table should be EFI only.
> 
> The garbage BGRT data causes the efi_bgrt_init() panic.
> 
> Add a check to skip efi_bgrt_init() in case non-EFI bootup to work around
> this firmware bug.
> 
> Tested-by: Sabrina Dubroca 
> Signed-off-by: Dave Young 
> Signed-off-by: Ard Biesheuvel 
> Signed-off-by: Matt Fleming 
> Cc: Linus Torvalds 
> Cc: Peter Zijlstra 
> Cc: Thomas Gleixner 
> Cc: linux-efi@vger.kernel.org
> Fixes: 7b0a911478c7 ("efi/x86: Move the EFI BGRT init code to early init 
> code")
> Link: http://lkml.kernel.org/r/20170526113652.21339-6-m...@codeblueprint.co.uk
> [ Rewrote the changelog to be more readable. ]
> Signed-off-by: Ingo Molnar 
> Signed-off-by: Greg Kroah-Hartman 
> 
> ---
>  arch/x86/platform/efi/efi-bgrt.c |3 +++
>  1 file changed, 3 insertions(+)
> 
> --- a/arch/x86/platform/efi/efi-bgrt.c
> +++ b/arch/x86/platform/efi/efi-bgrt.c
> @@ -36,6 +36,9 @@ void __init efi_bgrt_init(struct acpi_ta
>   if (acpi_disabled)
>   return;
>  
> + if (!efi_enabled(EFI_BOOT))
> + return;
> +
>   if (table->length < sizeof(bgrt_tab)) {
>   pr_notice("Ignoring BGRT: invalid length %u (expected %zu)\n",
>  table->length, sizeof(bgrt_tab));
> 
> 
> 

The patch is ok but it only fixes BIOS systems.
To fix the regression above (commit 7b0a911478c7) for EFI systems 
it needs this patch as well:
commit 792ef14df5c585c19b2831673a077504a09e5203 master
(efi: Fix boot panic because of invalid BGRT image address)
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4.11 049/150] efi/bgrt: Skip efi_bgrt_init() in case of non-EFI boot

[Maniaxx]

On 12.06.2017 at 17:24 wrote Greg Kroah-Hartman:
> 4.11-stable review patch.  If anyone has any objections, please let me know.
> 
> --
> 
> From: Dave Young 
> 
> commit 7425826f4f7ac60f2538b06a7f0a5d1006405159 upstream.
> 
> Sabrina Dubroca reported an early panic:
> 
>   BUG: unable to handle kernel paging request at ff240001
>   IP: efi_bgrt_init+0xdc/0x134
> 
>   [...]
> 
>   ---[ end Kernel panic - not syncing: Attempted to kill the idle task!
> 
> ... which was introduced by:
> 
>   7b0a911478c7 ("efi/x86: Move the EFI BGRT init code to early init code")
> 
> The cause is that on this machine the firmware provides the EFI ACPI BGRT
> table even on legacy non-EFI bootups - which table should be EFI only.
> 
> The garbage BGRT data causes the efi_bgrt_init() panic.
> 
> Add a check to skip efi_bgrt_init() in case non-EFI bootup to work around
> this firmware bug.
> 
> Tested-by: Sabrina Dubroca 
> Signed-off-by: Dave Young 
> Signed-off-by: Ard Biesheuvel 
> Signed-off-by: Matt Fleming 
> Cc: Linus Torvalds 
> Cc: Peter Zijlstra 
> Cc: Thomas Gleixner 
> Cc: linux-...@vger.kernel.org
> Fixes: 7b0a911478c7 ("efi/x86: Move the EFI BGRT init code to early init 
> code")
> Link: http://lkml.kernel.org/r/20170526113652.21339-6-m...@codeblueprint.co.uk
> [ Rewrote the changelog to be more readable. ]
> Signed-off-by: Ingo Molnar 
> Signed-off-by: Greg Kroah-Hartman 
> 
> ---
>  arch/x86/platform/efi/efi-bgrt.c |3 +++
>  1 file changed, 3 insertions(+)
> 
> --- a/arch/x86/platform/efi/efi-bgrt.c
> +++ b/arch/x86/platform/efi/efi-bgrt.c
> @@ -36,6 +36,9 @@ void __init efi_bgrt_init(struct acpi_ta
>   if (acpi_disabled)
>   return;
>  
> + if (!efi_enabled(EFI_BOOT))
> + return;
> +
>   if (table->length < sizeof(bgrt_tab)) {
>   pr_notice("Ignoring BGRT: invalid length %u (expected %zu)\n",
>  table->length, sizeof(bgrt_tab));
> 
> 
> 

The patch is ok but it only fixes BIOS systems.
To fix the regression above (commit 7b0a911478c7) for EFI systems 
it needs this patch as well:
commit 792ef14df5c585c19b2831673a077504a09e5203 master
(efi: Fix boot panic because of invalid BGRT image address)

Re: [PATCH 4.11 049/150] efi/bgrt: Skip efi_bgrt_init() in case of non-EFI boot

[Maniaxx]

On 12.06.2017 at 17:24 wrote Greg Kroah-Hartman:
> 4.11-stable review patch.  If anyone has any objections, please let me know.
> 
> --
> 
> From: Dave Young 
> 
> commit 7425826f4f7ac60f2538b06a7f0a5d1006405159 upstream.
> 
> Sabrina Dubroca reported an early panic:
> 
>   BUG: unable to handle kernel paging request at ff240001
>   IP: efi_bgrt_init+0xdc/0x134
> 
>   [...]
> 
>   ---[ end Kernel panic - not syncing: Attempted to kill the idle task!
> 
> ... which was introduced by:
> 
>   7b0a911478c7 ("efi/x86: Move the EFI BGRT init code to early init code")
> 
> The cause is that on this machine the firmware provides the EFI ACPI BGRT
> table even on legacy non-EFI bootups - which table should be EFI only.
> 
> The garbage BGRT data causes the efi_bgrt_init() panic.
> 
> Add a check to skip efi_bgrt_init() in case non-EFI bootup to work around
> this firmware bug.
> 
> Tested-by: Sabrina Dubroca 
> Signed-off-by: Dave Young 
> Signed-off-by: Ard Biesheuvel 
> Signed-off-by: Matt Fleming 
> Cc: Linus Torvalds 
> Cc: Peter Zijlstra 
> Cc: Thomas Gleixner 
> Cc: linux-...@vger.kernel.org
> Fixes: 7b0a911478c7 ("efi/x86: Move the EFI BGRT init code to early init 
> code")
> Link: http://lkml.kernel.org/r/20170526113652.21339-6-m...@codeblueprint.co.uk
> [ Rewrote the changelog to be more readable. ]
> Signed-off-by: Ingo Molnar 
> Signed-off-by: Greg Kroah-Hartman 
> 
> ---
>  arch/x86/platform/efi/efi-bgrt.c |3 +++
>  1 file changed, 3 insertions(+)
> 
> --- a/arch/x86/platform/efi/efi-bgrt.c
> +++ b/arch/x86/platform/efi/efi-bgrt.c
> @@ -36,6 +36,9 @@ void __init efi_bgrt_init(struct acpi_ta
>   if (acpi_disabled)
>   return;
>  
> + if (!efi_enabled(EFI_BOOT))
> + return;
> +
>   if (table->length < sizeof(bgrt_tab)) {
>   pr_notice("Ignoring BGRT: invalid length %u (expected %zu)\n",
>  table->length, sizeof(bgrt_tab));
> 
> 
> 

The patch is ok but it only fixes BIOS systems.
To fix the regression above (commit 7b0a911478c7) for EFI systems 
it needs this patch as well:
commit 792ef14df5c585c19b2831673a077504a09e5203 master
(efi: Fix boot panic because of invalid BGRT image address)

Re: [PATCH] x86/efi: fix boot panic because of invalid bgrt image address

[Maniaxx]

On 08.06.2017 at 07:38 wrote Dave Young:
> Maniaxx, can you verify it on your machine? It passed my test with
> an emulation of your wrong address.

Works. Bails out properly on 4.12.0-rc4-gb29794ec95c6.

[0.00] efi_bgrt: Ignoring BGRT: invalid image address

Re: [PATCH] x86/efi: fix boot panic because of invalid bgrt image address

[Maniaxx]

On 08.06.2017 at 07:38 wrote Dave Young:
> Maniaxx, can you verify it on your machine? It passed my test with
> an emulation of your wrong address.

Works. Bails out properly on 4.12.0-rc4-gb29794ec95c6.

[0.00] efi_bgrt: Ignoring BGRT: invalid image address

Re: PROBLEM: Kernel panic on EFI BGRT early init code (kernel 4.11/4.12rc2) [regression]

[Maniaxx]

On 01.06.2017 at 03:57 wrote Dave Young:
> This means the efi_bgrt_init failed out originally before the early init BGRT
> patch. Checking the code the only difference is current code we have no
> below code:
> 
> status = acpi_get_table("BGRT", 0,
> (struct acpi_table_header **)_tab);
> if (ACPI_FAILURE(status))
> return;
> 
> So probably acpi_get_table has some more sanity checking and it failed
> early. Can you add a printk before above return to confirm it? Just test
> the old kernel without early init BGRT patch.

Doesn't fail early. I can see the printk.

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: PROBLEM: Kernel panic on EFI BGRT early init code (kernel 4.11/4.12rc2) [regression]

[Maniaxx]

On 27.05.2017 at 07:34 wrote Dave Young:
>> Can you double check it works before the commit of below? 
linux-git-4.10rc5.r115.gc4c39c70c5fe is fine (1 commit back)
linux-git-4.10rc5.r116.g7b0a911478c7 is not (early init BGRT patch)

>> If machine
>> boots fine then check /sys/firmware/acpi/bgrt/image see if it exists or
>> not. 
Not sure. /sys/firmware/acpi/bgrt/ doesn't exist here but i have
/sys/firmware/acpi/tables/ that contains all tables. BGRT is 60 bytes
and holds the same binary content as pr_info hex_dump (in dmesg log below).

>> if you can manange to save full kernel log it would be also helpful.
Here is a log of linux-git-4.10rc5.r115.gc4c39c70c5fe with Sabrina
Dubroca's test code applied:
https://pastebin.com/ZkBNejrC

This is how i applied the patch. I hope its correct:
https://pastebin.com/see6V0Bk

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: v4.3.0.4 not working on SSE1 CPUs anymore

[Maniaxx]

On 08.08.2014 at 22:25 wrote Robinson Tryon:
 Maniaxx -- Did this problem start with LO 4.3? (I believe that we
 switched to Visual Studio 2012 by LO 4.0 or 4.1) 
Yes, i'm running 4.2.6.2 at the moment.

I just ask for it if its really no big deal like setting a compiler flag
or something. I probably can live with v4.2.x for some time.

The AthlonXPs were indeed a very successful (if not the most successful)
series of AMD CPUs and they are still powerful enough to run most
applications on Windows7.

If its too much hassle just forget about it. I don't want to slow anyone
down.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[no subject]

[Maniaxx]

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

v4.3.0.4 not working on SSE1 CPUs anymore

[Maniaxx]

Hallo,
LibreOffice v4.3.0.4 doesn't work on SSE1 CPUs anymore. Tested on AMD
AthlonXP (AMD K7) with Windows7 32Bit. Previous version was v4.1.0 that
worked properly.

Exception code is c01d (illegal instruction). Probably thrown by
SSE2 instruction (or higher) that the K7 doesn't understand (it supports
MMX, Extended 3DNow, SSE, PowerNow!).

This can usually be fixed by limiting the compiler (GCC) to SSE
instruction set.

Can you fix that?

Regards
-Maniaxx

Crash report:
  Problemereignisname:APPCRASH
  Anwendungsname:soffice.bin
  Anwendungsversion:4.3.0.4
  Anwendungszeitstempel:53d3e2db
  Fehlermodulname:sal3.dll
  Fehlermodulversion:4.3.0.4
  Fehlermodulzeitstempel:53d201f6
  Ausnahmecode:c01d
  Ausnahmeoffset:000268d5
  Betriebsystemversion:6.1.7601.2.1.0.256.1
  Gebietsschema-ID:1031

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [pygame] move problems

[maniaxx]

hi,

K_UP has the value 273 and pygame.key.get_pressed() returns a tuple where the 
n'th value is 1 if the n'th key was pressed.
This should work:

if key[K_UP]:
.

 this code is in my main game loop

 key = pygame.key.get_pressed() #create a key index

 if K_UP in key: #check if the up arrow is pressed
 redcar.speed = (0, -2)
 else:
 redcar.speed = (0, 0)

 redcar.rect = redcar.rect.move(redcar.speed) #move redcar by speed

 but pressing the up arrow doesn't move the sprite.