list of ethtool self tests.")
Signed-off-by: Petr Oros
---
.../net/ethernet/emulex/benet/be_ethtool.c| 28 +++
1 file changed, 22 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/emulex/benet/be_ethtool.c
b/drivers/net/ethernet/emulex/benet/be_ethto
Certain cards in conjunction with certain switches need a little more
time for link setup that results in ethtool link test failure after
offline test. Patch adds a loop that waits for a link setup finish.
Signed-off-by: Petr Oros
---
.../net/ethernet/emulex/benet/be_ethtool.c| 28
Borislav Petkov píše v Pá 26. 01. 2018 v 15:49 +0100:
> On Fri, Jan 26, 2018 at 02:50:00PM +0100, Petr Oros wrote:
> > But what in production? Edit boot params, restart server, grep
> > /proc/cpuinfo and
> > restart again? Why i can not read it just from dmesg?
>
Borislav Petkov píše v Pá 26. 01. 2018 v 15:49 +0100:
> On Fri, Jan 26, 2018 at 02:50:00PM +0100, Petr Oros wrote:
> > But what in production? Edit boot params, restart server, grep
> > /proc/cpuinfo and
> > restart again? Why i can not read it just from dmesg?
>
Borislav Petkov píše v Pá 26. 01. 2018 v 12:58 +0100:
> On Fri, Jan 26, 2018 at 12:45:35PM +0100, Petr Oros wrote:
> > During time of facing the Spectre vulnerability and the requirement of
> > handling
> > different microcode updates, it has shown, that it would be useful t
Borislav Petkov píše v Pá 26. 01. 2018 v 12:58 +0100:
> On Fri, Jan 26, 2018 at 12:45:35PM +0100, Petr Oros wrote:
> > During time of facing the Spectre vulnerability and the requirement of
> > handling
> > different microcode updates, it has shown, that it would be useful t
Borislav Petkov píše v Pá 26. 01. 2018 v 11:41 +0100:
> On Fri, Jan 26, 2018 at 11:34:50AM +0100, Petr Oros wrote:
> > When kernel do early microcode update, code printing only
> > new microcode version. But in this case we no have chance
> > to check which version
Borislav Petkov píše v Pá 26. 01. 2018 v 11:41 +0100:
> On Fri, Jan 26, 2018 at 11:34:50AM +0100, Petr Oros wrote:
> > When kernel do early microcode update, code printing only
> > new microcode version. But in this case we no have chance
> > to check which version
When kernel do early microcode update, code printing only
new microcode version. But in this case we no have chance
to check which version was in cpu from BIOS vendor.
Patch add this info into output message.
Signed-off-by: Petr Oros <po...@redhat.com>
---
arch/x86/kernel/cpu/mic
When kernel do early microcode update, code printing only
new microcode version. But in this case we no have chance
to check which version was in cpu from BIOS vendor.
Patch add this info into output message.
Signed-off-by: Petr Oros
---
arch/x86/kernel/cpu/microcode/intel.c | 27
Matt Fleming píše v Wed 21. 12. 2016 v 22:30 +:
> On Wed, 21 Dec, at 02:11:38PM, Petr Oros wrote:
> >
> > Booting on EFI with ESRT table has been stop since commit:
> > 8e80632 efi/esrt: Use efi_mem_reserve() and avoid a kmalloc()
> >
> >
Matt Fleming píše v Wed 21. 12. 2016 v 22:30 +:
> On Wed, 21 Dec, at 02:11:38PM, Petr Oros wrote:
> >
> > Booting on EFI with ESRT table has been stop since commit:
> > 8e80632 efi/esrt: Use efi_mem_reserve() and avoid a kmalloc()
> >
> >
on EFI_PAGE_SIZE. If memory not aligned, efi_memmap_insert
just return and let efi.memmap in inconsistent state.
This breaking boot.
Tested in my machine, which stop booting
after upgrade to 4.9
Signed-off-by: Petr Oros <po...@redhat.com>
---
arch/x86/platform/efi/quirks.c | 2 +-
1 file chan
on EFI_PAGE_SIZE. If memory not aligned, efi_memmap_insert
just return and let efi.memmap in inconsistent state.
This breaking boot.
Tested in my machine, which stop booting
after upgrade to 4.9
Signed-off-by: Petr Oros
---
arch/x86/platform/efi/quirks.c | 2 +-
1 file changed, 1 insertion(+), 1
The formula to calculate "CommitLimit" value mentioned in kernel documentation
is incorrect.
Right formula is: CommitLimit = ([total RAM pages] - [total huge TLB pages]) *
overcommit_ratio / 100 + [total swap pages]
Signed-off-by: Petr Oros
---
Documentation/filesystems/proc.txt
The formula to calculate CommitLimit value mentioned in kernel documentation
is incorrect.
Right formula is: CommitLimit = ([total RAM pages] - [total huge TLB pages]) *
overcommit_ratio / 100 + [total swap pages]
Signed-off-by: Petr Oros po...@redhat.com
---
Documentation/filesystems/proc.txt
16 matches
Mail list logo
