related the recent reboot issue
> reported in https://lkml.org/lkml/2018/7/1/836 since the symptoms are
> exactly the same.
The problem in that case turned out to be https://lkml.org/lkml/2018/7/4/723
which was fixed by d503ac531a.
--Benjamin Gilbert
. So if you ask
> for a build log you would see it.
In our case, the package is presumably passing LDFLAGS="" to override the
LDFLAGS environment variable already set by the packaging system. This has
worked for years without a problem.
--Benjamin Gilbert
; > > > 2018-07-01 23:32 GMT+02:00 Benjamin Gilbert :
> > > > > On Sun, Jul 01, 2018 at 05:15:59PM -0400, Benjamin Gilbert wrote:
> > > > >> 4.17 kernels built with the CoreOS Container Linux toolchain and
> > > > >> kconfig,
> > &g
core-os.net/bgilbert/4.17/vmlinux-4.17.3-coreos
https://users.developer.core-os.net/bgilbert/4.17/System.map
--Benjamin Gilbert
the commit is reverted.
--Benjamin Gilbert
On Sun, Jul 01, 2018 at 05:15:59PM -0400, Benjamin Gilbert wrote:
> 4.17 kernels built with the CoreOS Container Linux toolchain and kconfig,
> up to and including 4.17.3, fail to boot on AMD64 running in (at least)
> QEMU/KVM. No messages are shown post-GRUB; the VM instantl
5620a0d1aacd ("firmware: delete in-kernel firmware") left behind several
config options which no longer do anything. Remove them and fix up
documentation.
Benjamin Gilbert (3):
USB: serial: keyspan: Drop firmware Kconfig options
firmware: Drop FIRMWARE_IN_KERNEL Kconfig option
It doesn't actually do anything. Merge its help text into
EXTRA_FIRMWARE.
Fixes: 5620a0d1aacd ("firmware: delete in-kernel firmware")
Fixes: 0946b2fb38fd ("firmware: cleanup FIRMWARE_IN_KERNEL message")
Signed-off-by: Benjamin Gilbert
Cc: Greg Kroah-Hartman
Cc: Robin
We've removed the option, so stop talking about it.
Signed-off-by: Benjamin Gilbert
Cc: Borislav Petkov
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: H. Peter Anvin
---
Documentation/driver-api/firmware/built-in-fw.rst | 7 +--
Documentation/x86/microcode.txt | 5 ++---
The USB_SERIAL_KEYSPAN_* firmware options no longer do anything.
Fixes: 5620a0d1aacd ("firmware: delete in-kernel firmware")
Signed-off-by: Benjamin Gilbert
Cc: Greg Kroah-Hartman
Cc: Johan Hovold
---
arch/mips/configs/rm200_defconfig | 9
arch/powerpc/configs/c2k_defconf
On Thu, Jan 04, 2018 at 02:10:44PM -0800, tip-bot for Thomas Gleixner wrote:
> + BUILD_BUG_ON)(vaddr_end != CPU_ENTRY_AREA_BASE);
^^
Note typo.
--Benjamin Gilbert
27; features.
>
> Just look at the insanity of comment above the vaddr_end ifdef maze.
>
> Benjamin, can you test the patch below please?
Seems to work!
Thanks,
--Benjamin Gilbert
On Wed, Jan 03, 2018 at 05:37:42PM -0800, Benjamin Gilbert wrote:
> I was caught by the fact that 4.14.11 has PAGE_TABLE_ISOLATION default y
> but 4.15-rc6 doesn't. Retesting.
It turns out that 4.15-rc6 has the same problem as 4.14.11.
--Benjamin Gilbert
current_kernel attached. I have not seen any crashes with
free_ldt_pgtables() stubbed out.
--Benjamin Gilbert
current_kernel.gz
Description: application/gzip
On Wed, Jan 03, 2018 at 04:33:03PM -0800, Benjamin Gilbert wrote:
> I haven't been able to reproduce this on 4.15-rc6.
This is bad data. I was caught by the fact that 4.14.11 has
PAGE_TABLE_ISOLATION default y but 4.15-rc6 doesn't. Retesting.
--Benjamin Gilbert
from 1 to 7 GB.
--Benjamin Gilbert
On Wed, Jan 03, 2018 at 10:20:16AM +0100, Greg Kroah-Hartman wrote:
> Ick, not good, any chance you can test 4.15-rc6 to verify that the issue
> is also there (or not)?
I haven't been able to reproduce this on 4.15-rc6.
--Benjamin Gilbert
On Wed, Jan 03, 2018 at 11:34:46PM +0100, Thomas Gleixner wrote:
> Can you please send me your .config and a full dmesg ?
I've attached a serial log from a local QEMU. I can rerun with a higher
loglevel if need be.
--Benjamin Gilbert
config-4.14.11.gz
Description: applicat
On Wed, Jan 03, 2018 at 04:48:33PM +0100, Ingo Molnar wrote:
> first please test the latest WIP.x86/pti branch which has a couple of fixes.
I'm still seeing the problem with that branch (3ffdeb1a02be, plus a couple
of local patches which shouldn't affect the resulting binary).
--Benjamin Gilbert
blk_congestion_wait() doesn't exist anymore, but there's still a stub
in blkdev.h for the !CONFIG_BLOCK case. Kill it.
Signed-off-by: Benjamin Gilbert <[EMAIL PROTECTED]>
---
include/linux/blkdev.h |5 -
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git
Add optimized implementation of the SHA-1 hash function for x86_64, ported
from the x86 implementation in Nettle (which is LGPLed).
The code has been tested with tcrypt and the NIST test vectors.
Signed-off-by: Benjamin Gilbert <[EMAIL PROTECTED]>
---
arch/x86_64/kernel/x8664_ksyms.c
left this situation alone
since I'm not familiar with the ARM code, but a !ARM condition could be
added to CONFIG_SHA1_GENERIC if it makes sense.
The code has been tested with tcrypt and the NIST test vectors.
Signed-off-by: Benjamin Gilbert <[EMAIL PROTECTED]>
---
arch/i386/kernel/i38
Benjamin Gilbert wrote:
Jan Engelhardt wrote:
UTF-8 please. Hint: it should most likely be an รถ.
Whoops, I had thought I had gotten that right. I'll get updates for
parts 2 and 3 sent out on Monday.
I'm sending the corrected parts 2 and 3 as replies to this email. The
UTF-8
Andi Kleen wrote:
Benjamin Gilbert <[EMAIL PROTECTED]> writes:
+#define EXPAND(i) \
+ movlOFFSET(i % 16)(DATA), TMP; \
+ xorlOFFSET((i + 2) % 16)(DATA), TMP;\
Such overlapping memory ac
ill reasonably compact; only 20 of the 80 rounds are written out
long-hand.
I got this code from Nettle, originally, and I never looked at the SHA-1
round structure very closely. I'll give that approach a try.
Thanks
--Benjamin Gilbert
-
To unsubscribe from this list: send the line "u
iff;h=374f167dfb97c1785515a0c41e32a66b414859a8
With. I just tried 2.6.11 (the oldest that will boot) on the Pentium IV
box and got 3.7 MB/s, so if it's a regression it's been around for a while.
--Benjamin Gilbert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a me
Matt Mackall wrote:
On Sat, Jun 09, 2007 at 08:33:25PM -0400, Benjamin Gilbert wrote:
It's not just the loop unrolling; it's the register allocation and
spilling. For comparison, I built SHATransform() from the
drivers/char/random.c in 2.6.11, using gcc 3.3.5 with -O2 and
SHA_CODE
Jan Engelhardt wrote:
On Jun 8 2007 17:42, Benjamin Gilbert wrote:
@@ -0,0 +1,299 @@
+/*
+ * x86-optimized SHA1 hash algorithm (i486 and above)
+ *
+ * Originally from Nettle
+ * Ported from M4 to cpp by Benjamin Gilbert <[EMAIL PROTECTED]>
+ *
+ * Copyright (C) 2004, Niels M?ller
+ * Cop
56 28 22 21%
1981921024 28 21 25%
2081924096 27 21 22%
2181928192 27 21 22%
The improvement isn't as good, but it's still noticeable.
--Benjamin Gilbert
-
To unsubscribe from this list: send the line &qu
left this situation alone
since I'm not familiar with the ARM code, but a !ARM condition could be
added to CONFIG_SHA1_GENERIC if it makes sense.
The code has been tested with tcrypt and the NIST test vectors.
Signed-off-by: Benjamin Gilbert <[EMAIL PROTECTED]>
---
arch/i386/kernel/i38
Add optimized implementation of the SHA-1 hash function for x86_64, ported
from the x86 implementation in Nettle (which is LGPLed).
The code has been tested with tcrypt and the NIST test vectors.
Signed-off-by: Benjamin Gilbert <[EMAIL PROTECTED]>
---
arch/x86_64/kernel/x8664_ksyms.c
oes from 3.7 MB/s
to 5.6 MB/s with the patches; on the Core 2, it increases from 5.5 MB/s to
8.1 MB/s.
Signed-off-by: Benjamin Gilbert <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTE
longer needs to
reimplement sha_init() in assembly
Signed-off-by: Benjamin Gilbert <[EMAIL PROTECTED]>
---
arch/arm/lib/sha1.S | 16
arch/s390/crypto/sha1_s390.c |6 +-
drivers/crypto/padlock-sha.c |8 ++--
include/linux/cryptohash.h
in case CPU_DOWN_PREPARED failed.
Also the slab cache code hasn't been changed to make use of the of the
new CPU_LOCK_[ACQUIRE|RELEASE] stuff. I'm going to send patches in reply
to this mail.
2.6.20-rc3-mm1 plus your patches fixes it for me.
Thanks
--Benjamin Gilbert
-
To unsubscribe
stack+0x16/0x18
[] debug_check_no_locks_held+0x80/0x86
[] do_exit+0x6bf/0x6f5
[] sys_exit_group+0x0/0x11
[] sys_exit_group+0xf/0x11
[] syscall_call+0x7/0xb
===
If I can provide any other information to help track this down, please let
me know.
--Benj
35 matches
Mail list logo
