Autor Tema: Nuevo kernel candidato 3.10.11  (Leído 2312 veces)

0 Usuarios y 1 Visitante están viendo este tema.

Desconectado USUARIONUEVO

  • Moderador
  • *
  • Mensajes: 14444
Nuevo kernel candidato 3.10.11
« en: 09-09-2013, 08:10 (Lunes) »
Como sospechaba los kerneles 3.10.9 & 3.10.10  tenian problemas de gestion de memoria , lo cual creba corrupcion de la misma al querer arrancar varias veces seguidas ( reboot )  CON PAE


commit 7c886152ed0b4fdfc4412f0a28ad68500b552660
Author: Yinghai Lu <yinghai@kernel.org>
Date:   Mon Aug 12 16:43:24 2013 -0700

    x86/mm: Fix boot crash with DEBUG_PAGE_ALLOC=y and more than 512G RAM
    
    commit 527bf129f9a780e11b251cf2467dc30118a57d16 upstream.
    
    Dave Hansen reported that systems between 500G and 600G RAM
    crash early if DEBUG_PAGEALLOC is selected.
    
     > [    0.000000] init_memory_mapping: [mem 0x00000000-0x000fffff]
     > [    0.000000]  [mem 0x00000000-0x000fffff] page 4k
     > [    0.000000] BRK [0x02086000, 0x02086fff] PGTABLE
     > [    0.000000] BRK [0x02087000, 0x02087fff] PGTABLE
     > [    0.000000] BRK [0x02088000, 0x02088fff] PGTABLE
     > [    0.000000] init_memory_mapping: [mem 0xe80ee00000-0xe80effffff]
     > [    0.000000]  [mem 0xe80ee00000-0xe80effffff] page 4k
     > [    0.000000] BRK [0x02089000, 0x02089fff] PGTABLE
     > [    0.000000] BRK [0x0208a000, 0x0208afff] PGTABLE
     > [    0.000000] Kernel panic - not syncing: alloc_low_page: ran out of memory
    
    It turns out that we missed increasing needed pages in BRK to
    mapping initial 2M and [0,1M) when we switched to use the #PF
    handler to set memory mappings:
    
     > commit 8170e6bed465b4b0c7687f93e9948aca4358a33b
     > Author: H. Peter Anvin <hpa@zytor.com>
     > Date:   Thu Jan 24 12:19:52 2013 -0800
     >
     >     x86, 64bit: Use a #PF handler to materialize early mappings on demand
    
    Before that, we had the maping from [0,512M) in head_64.S, and we
    can spare two pages [0-1M).  After that change, we can not reuse
    pages anymore.
    
    When we have more than 512M ram, we need an extra page for pgd page
    with [512G, 1024g).
    
    Increase pages in BRK for page table to solve the boot crash.
    
    Reported-by: Dave Hansen <dave.hansen@intel.com>
    Bisected-by: Dave Hansen <dave.hansen@intel.com>
    Tested-by: Dave Hansen <dave.hansen@intel.com>
    Signed-off-by: Yinghai Lu <yinghai@kernel.org>
    Link: http://lkml.kernel.org/r/1376351004-4015-1-git-send-email-yinghai@kernel.org
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 344033d4079c22c92581675d7416c748d9d8201b
Author: Trond Myklebust <Trond.Myklebust@netapp.com>
Date:   Wed Aug 28 13:35:13 2013 -0400

    SUNRPC: Fix memory corruption issue on 32-bit highmem systems
    
    commit 347e2233b7667e336d9f671f1a52dfa3f0416e2c upstream.
    
    Some architectures, such as ARM-32 do not return the same base address
    when you call kmap_atomic() twice on the same page.
    This causes problems for the memmove() call in the XDR helper routine
    "_shift_data_right_pages()", since it defeats the detection of
    overlapping memory ranges, and has been seen to corrupt memory.
    
    The fix is to distinguish between the case where we're doing an
    inter-page copy or not. In the former case of we know that the memory
    ranges cannot possibly overlap, so we can additionally micro-optimise
    by replacing memmove() with memcpy().
    
    Reported-by: Mark Young <MYoung@nvidia.com>
    Reported-by: Matt Craighead <mcraighead@nvidia.com>
    Cc: Bruce Fields <bfields@fieldses.org>
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Tested-by: Matt Craighead <mcraighead@nvidia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>


« Última modificación: 09-09-2013, 08:12 (Lunes) por USUARIONUEVO »

Desconectado USUARIONUEVO

  • Moderador
  • *
  • Mensajes: 14444
Re: Nuevo kernel candidato 3.10.11
« Respuesta #1 en: 09-09-2013, 08:12 (Lunes) »
Sigue presente el bug de los asus        ( pero tengo patch ).
Los drivers wifi   ( tengo parches ).
Añadire id de buffalo.
Metere el patch BFS de con kolivas.


 ;)

alist3r

  • Visitante
Re: Nuevo kernel candidato 3.10.11
« Respuesta #2 en: 09-09-2013, 11:51 (Lunes) »
el primer bug que comentas no te afecta (supermáquinas con mucha ram), pero el segundo si que creo que te pega en toda la boca.

aunque no ha sido confirmado en maquinas x86, pero es sumamente probable que por ahí ande.

los parches, de momento podrás ir haciendo una buena temporada, y muchos de ellos pasarán a producción, seguro.

el tema bfs, es probarlo y decidir si la relacion sacrificio/beneficio te interesa.

los atheros de la serie 10k estan en constante cambio y corrección, no te paso los parches porque son demasiado profundos. actualmente presentan problemas de inicialización en ciertos dominios regulatorios y problemas de calibración de la potencia de transmisión (vamos, un cacao)

esperad un poco que pronto pasaran versiones mas estables a mainline.

« Última modificación: 09-09-2013, 11:54 (Lunes) por alister »

Desconectado USUARIONUEVO

  • Moderador
  • *
  • Mensajes: 14444
Re: Nuevo kernel candidato 3.10.11
« Respuesta #3 en: 09-09-2013, 12:20 (Lunes) »
La iso que postee hoy ya lleva los BFS , y todo parcheado de fabula.


Lo de los asus , acabara pr entrar en la 3.10 si finalmente es longterm , por que en el 3.11 esta parcheado...es cuestión de releases.

Lo del wifi ,seguro que NO , se parchean drivers pero el comportamiento es el mismo ya que se hacen cambios sobre driver ,epro no sobre ..por llamarlo de alguna manera "stack" ... si hay X función seguirá igual siempre, solo van adaptando/parcheando los drivers y ajustando.

Entran funciones nuevas en ramas siguientes SIEMPRE, por que meten un stack mas nuevo , solo por eso.

alist3r

  • Visitante
Re: Nuevo kernel candidato 3.10.11
« Respuesta #4 en: 09-09-2013, 13:41 (Lunes) »
ah.. ves? al final no te ha costado tanto.
el último reject que te quedaba era una chorrada como la copa de un pino.

lo que comentas del stack, así es. de hecho el desarrollo del kernel tiene lugar en varios repositorios separados que se dedeican cada uno a una cosa. luego se abre una "merge window", y se empiezan a incorporar en masa todos los cambios de estos repos pequeños contra el repo principal. algo asi como un periodo de sincronización. eso es lo que veras en muchas ocasiones en los commits:
 "merging branch xxxx"
esos commits son un acumulado enorme de parches y codigo nuevo, ya testados y validados.