The following coommand
ip route add default dev enp4s0 src 5.9.158.75 table 1
at a stable hardened Gentoo server
Linux mr-fox 5.10.17 #18 SMP Wed Feb 17 12:59:16 CET 2021 x86_64
Intel(R) Xeon(R) CPU E5-1650 v3 @ 3.50GHz GenuineIntel GNU/Linux
with 2 ip addresses
On 12/30/20 10:05 AM, Toralf Förster wrote:
On 12/29/20 11:55 PM, Randy Dunlap wrote:
No, this is wrong. 'size' in this case is the size of the read.
And it's zero. Is this fixed by commit
3644e2d2dda78e21edd8f5415b6d7ab03f5f54f3
Toralf, can you test with 5.11-rc1 (or later)?
thanks.
My
On 12/29/20 11:55 PM, Randy Dunlap wrote:
No, this is wrong. 'size' in this case is the size of the read.
And it's zero. Is this fixed by commit
3644e2d2dda78e21edd8f5415b6d7ab03f5f54f3
Toralf, can you test with 5.11-rc1 (or later)?
thanks.
My plan was to apply that commit on top of the
On 12/29/20 9:00 PM, Randy Dunlap wrote:
Hi Toralf,
Do you want either or both of your
Reported-by: and Tested-by: on the patch?
thanks.
-- ~Randy
The first is enough, for a Tested-by: was the time frame too short IMO.
--
Toralf
On 12/23/20 2:50 AM, Randy Dunlap wrote:
What motivates this change? Is there any reason to think this can
happen?
Spotted in the wild:
I run 2 hardened Gentoo systems, a server and a desktop.
I patched the server with this:
mr-fox ~ # cat ubsan.patch
--- linux-5.10.1.orig/mm/readahead.c
On 12/20/20 2:09 AM, Randy Dunlap wrote:
On 12/18/20 2:20 AM, Toralf Förster wrote:
On 12/18/20 7:54 AM, Randy Dunlap wrote:
Hi,
[adding linux-mm]
On 12/16/20 1:54 AM, Toralf Förster wrote:
Hi,
I got this recently at this hardened Gentoo Linux server:
Linux mr-fox 5.10.1 #1 SMP Tue Dec 15
On 12/18/20 7:54 AM, Randy Dunlap wrote:
Hi,
[adding linux-mm]
On 12/16/20 1:54 AM, Toralf Förster wrote:
Hi,
I got this recently at this hardened Gentoo Linux server:
Linux mr-fox 5.10.1 #1 SMP Tue Dec 15 22:09:42 CET 2020 x86_64 Intel(R)
Xeon(R) CPU E5-1650 v3 @ 3.50GHz GenuineIntel GNU
Hi,
I got this recently at this hardened Gentoo Linux server:
Linux mr-fox 5.10.1 #1 SMP Tue Dec 15 22:09:42 CET 2020 x86_64 Intel(R)
Xeon(R) CPU E5-1650 v3 @ 3.50GHz GenuineIntel GNU/Linux
Dec 15 23:31:51 mr-fox kernel: [ 1974.206972]
I do wonder about this value:
# grep ^9 /sys/fs/cgroup/memory/*/*/memory.memsw.limit_in_bytes
/sys/fs/cgroup/memory/tinderbox/17.1_developer-20200531-193248/memory.memsw.limit_in_bytes:9223372036854771712
On 5/30/20 7:10 PM, Konstantin Ryabitsev wrote:
> (and the fact that you were seeing it in the first
> place suggests that you should update your openssl library, see
>
On 5/30/20 3:07 PM, Toralf Förster wrote:
> :-( :
>
> $ export GIT_TRACE=1
>
> $ git pull
> 15:07:08.488836 git.c:439 trace: built-in: git pull
> 15:07:08.504295 run-command.c:663 trace: run_command: git fetch
> --update-head-ok
> 15:07:08.506481 gi
:-( :
$ export GIT_TRACE=1
$ git pull
15:07:08.488836 git.c:439 trace: built-in: git pull
15:07:08.504295 run-command.c:663 trace: run_command: git fetch
--update-head-ok
15:07:08.506481 git.c:439 trace: built-in: git fetch
--update-head-ok
15:07:08.516608
May I ask you to clarify why
https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/diff/queue-5.2/net-ipv4-fib_trie-avoid-cryptic-ternary-expressions.patch?id=e1b76013997246a0d14b7443acbb393577d2a1e8
speaks about a ternary operator, whereas the diff shows a changed #define?
At a server (hardened stable Gentoo) I do usually do see values around 15,000
for that measure.
But 1 or 2 times per day that value gives a spike of 300,000 (or up to
1,500,000) over a 1 minute or so.
I do wonder how I can drill down the root cause for those spikes?
--
Toralf
PGP C4EACDDE
at my docked ThinkPad T440s.
I'm just curious what this does mean?
...
sched_clock: Marking stable (765790894, 14019108)->(786693847, -6883845)
registered taskstats version 1
Loading compiled-in X.509 certificates
alg: No test for pkcs1pad(rsa,sha1) (pkcs1pad(rsa-generic,sha1))
Loaded X.509 cert
On 14.05.19 20:14, Jonathan Corbet wrote:
> On Tue, 14 May 2019 19:48:12 +0200
> Toralf Förster wrote:
>
>> But this link is mentioned in dmesg of 5.1.2
>
> It works for me. I think you just needed to wait for the relevant commit
> to make it upstream and the docs to be
But this link is mentioned in dmesg of 5.1.2
--
Toralf
PGP C4EACDDE 0076E94E
Hi
On Fri, Feb 08, 2019 at 08:44:32PM -0800, Mark D Rustad wrote:
> On Feb 8, 2019, at 2:54 AM, Greg KH wrote:
>
> > diff --git a/Documentation/networking/ip-sysctl.txt
> > b/Documentation/networking/ip-sysctl.txt
> > index 2ea4c45cf1c8..7c229f59016f 100644
> > ---
Got at a stable hardened Gentoo this splat (BTW - no chance to get 4.19.0 nor
4.19.1 up and running at this headless server for longer than 1-2 minutes - it
dies w/o any further log message)
Oct 22 22:24:58 mr-fox kernel:
==
Oct
Got at a stable hardened Gentoo this splat (BTW - no chance to get 4.19.0 nor
4.19.1 up and running at this headless server for longer than 1-2 minutes - it
dies w/o any further log message)
Oct 22 22:24:58 mr-fox kernel:
==
Oct
At a stable hardened Gentoo Linxu I observed with 4.18.17 at a headless server:
Nov 4 18:13:27 mr-fox kernel: sd 1:0:0:0: [sdb] Attached SCSI disk
Nov 4 18:13:27 mr-fox kernel: EXT4-fs (sda4): mounted filesystem with ordered
data mode. Opts: (null)
Nov 4 18:13:27 mr-fox kernel: VFS: Mounted
At a stable hardened Gentoo Linxu I observed with 4.18.17 at a headless server:
Nov 4 18:13:27 mr-fox kernel: sd 1:0:0:0: [sdb] Attached SCSI disk
Nov 4 18:13:27 mr-fox kernel: EXT4-fs (sda4): mounted filesystem with ordered
data mode. Opts: (null)
Nov 4 18:13:27 mr-fox kernel: VFS: Mounted
I'm trying to get a new system and running with kernel 4.18.12, but run
into an APIC error as seen in [1].
It is a new system, never tried older kernels till now.
The kernel command line "noapic" doesn't help, now I do wonder what else
I can do.
The same kernel config was fine for 2 years with
I'm trying to get a new system and running with kernel 4.18.12, but run
into an APIC error as seen in [1].
It is a new system, never tried older kernels till now.
The kernel command line "noapic" doesn't help, now I do wonder what else
I can do.
The same kernel config was fine for 2 years with
IIRC in the past I couldn't boot a remote system if that kernel config were
unset.
But I do wonder if I do need that option nowadays?
--
Toralf
PGP C4EACDDE 0076E94E
IIRC in the past I couldn't boot a remote system if that kernel config were
unset.
But I do wonder if I do need that option nowadays?
--
Toralf
PGP C4EACDDE 0076E94E
Got this at a chroot image at a stable hardened Gentoo Linux :
BuildKernel with randconfig
HOSTCC scripts/basic/fixdep
HOSTCC scripts/kconfig/conf.o
YACCscripts/kconfig/zconf.tab.c
LEX scripts/kconfig/zconf.lex.c
HOSTCC scripts/kconfig/zconf.tab.o
HOSTLD
Got this at a chroot image at a stable hardened Gentoo Linux :
BuildKernel with randconfig
HOSTCC scripts/basic/fixdep
HOSTCC scripts/kconfig/conf.o
YACCscripts/kconfig/zconf.tab.c
LEX scripts/kconfig/zconf.lex.c
HOSTCC scripts/kconfig/zconf.tab.o
HOSTLD
The attached dmesg contains non printable chars 0x01 33 around "ACPI BIOS Error
(bug): Could not resolve" which is a new issue compared to the dmesg of 4.17.2
System is a stable hardened Gentoo Linux at a ThinkPad T440s.
--
Toralf
PGP C4EACDDE 0076E94E
dmesg-4.17.3
Description: Binary data
The attached dmesg contains non printable chars 0x01 33 around "ACPI BIOS Error
(bug): Could not resolve" which is a new issue compared to the dmesg of 4.17.2
System is a stable hardened Gentoo Linux at a ThinkPad T440s.
--
Toralf
PGP C4EACDDE 0076E94E
dmesg-4.17.3
Description: Binary data
Got this at a stable Gentoo hardened Linux server today and do wonder how to
react on it:
Feb 5 17:33:41 mr-fox kernel: [102822.981295] capability: warning:
`capget-54cLBXW7' uses 32-bit capabilities (legacy support in use)
Feb 5 17:33:50 mr-fox kernel: [102831.276626] perf: interrupt took
Got this at a stable Gentoo hardened Linux server today and do wonder how to
react on it:
Feb 5 17:33:41 mr-fox kernel: [102822.981295] capability: warning:
`capget-54cLBXW7' uses 32-bit capabilities (legacy support in use)
Feb 5 17:33:50 mr-fox kernel: [102831.276626] perf: interrupt took
It differs from the statement made at
https://www.kernel.org/category/releases.html
--
Toralf
PGP C4EACDDE 0076E94E
It differs from the statement made at
https://www.kernel.org/category/releases.html
--
Toralf
PGP C4EACDDE 0076E94E
On 12/30/2017 02:13 AM, Alexander Tsoy wrote:
> You are right, It's due to fstack-check enabled in gentoo's gcc spec.
> "-fstack-check=no" in KBUILD_CFLAGS fixed this problem for me. =/
This made the issue go away :
diff --git a/Makefile b/Makefile
index ac8c441866b7..11a12947c550 100644
---
On 12/30/2017 02:13 AM, Alexander Tsoy wrote:
> You are right, It's due to fstack-check enabled in gentoo's gcc spec.
> "-fstack-check=no" in KBUILD_CFLAGS fixed this problem for me. =/
This made the issue go away :
diff --git a/Makefile b/Makefile
index ac8c441866b7..11a12947c550 100644
---
On 12/30/2017 04:49 AM, Josh Poimboeuf wrote:
> Alexander, would you mind reproducing again with the below patch? It
> should still fail, but this time it should hopefully show another
> RIP/RSP/EFLAGS instead of the "do_double_fault+0xb/0x140" line.
I applied that too on top of
On 12/30/2017 04:49 AM, Josh Poimboeuf wrote:
> Alexander, would you mind reproducing again with the below patch? It
> should still fail, but this time it should hopefully show another
> RIP/RSP/EFLAGS instead of the "do_double_fault+0xb/0x140" line.
I applied that too on top of
On 12/30/2017 10:14 AM, Alexander Tsoy wrote:
> Yes, and only in hardened profile, so most users don't have -fstack-
> check by default. :)
Indeed, I do run hardened Gentoo only.
--
Toralf
PGP C4EACDDE 0076E94E
On 12/30/2017 10:14 AM, Alexander Tsoy wrote:
> Yes, and only in hardened profile, so most users don't have -fstack-
> check by default. :)
Indeed, I do run hardened Gentoo only.
--
Toralf
PGP C4EACDDE 0076E94E
On 12/30/2017 01:10 AM, Andy Lutomirski wrote:
> Toralf, can you send the complete output of:
>
> objdump -dr arch/x86/kernel/traps.o
>
> From the build tree of a nonworking kernel?
I attached it.
FWIW:
tfoerste@t44 ~/devel/linux $ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
On 12/30/2017 01:10 AM, Andy Lutomirski wrote:
> Toralf, can you send the complete output of:
>
> objdump -dr arch/x86/kernel/traps.o
>
> From the build tree of a nonworking kernel?
I attached it.
FWIW:
tfoerste@t44 ~/devel/linux $ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
On 12/29/2017 11:53 PM, Linus Torvalds wrote:
> So just change the
>
> #ifdef CONFIG_X86_ESPFIX64
>
> into a
>
> #if 0
>
> and see if instead of the RCU stall after 20 seconds, you get an
> immediate double fault error report instead?
well, 3 IMG_20171230_0008* should show the results
On 12/29/2017 11:53 PM, Linus Torvalds wrote:
> So just change the
>
> #ifdef CONFIG_X86_ESPFIX64
>
> into a
>
> #if 0
>
> and see if instead of the RCU stall after 20 seconds, you get an
> immediate double fault error report instead?
well, 3 IMG_20171230_0008* should show the results
On 12/29/2017 10:17 PM, Linus Torvalds wrote:
> On Fri, Dec 29, 2017 at 1:02 PM, Toralf Förster <toralf.foers...@gmx.de>
> wrote:
>> On 12/29/2017 09:12 PM, Linus Torvalds wrote:
>>> instead, and see if that makes a difference, that would narrow down
>>> the
On 12/29/2017 10:17 PM, Linus Torvalds wrote:
> On Fri, Dec 29, 2017 at 1:02 PM, Toralf Förster
> wrote:
>> On 12/29/2017 09:12 PM, Linus Torvalds wrote:
>>> instead, and see if that makes a difference, that would narrow down
>>> the possi
On 12/29/2017 09:12 PM, Linus Torvalds wrote:
> instead, and see if that makes a difference, that would narrow down
> the possible root cause of this problem.
not at this ThinkPad T440s (didn't test at the server with an i7-3930).
Boot stops just at:
tsc: Refined TSC clocksource
On 12/29/2017 09:12 PM, Linus Torvalds wrote:
> instead, and see if that makes a difference, that would narrow down
> the possible root cause of this problem.
not at this ThinkPad T440s (didn't test at the server with an i7-3930).
Boot stops just at:
tsc: Refined TSC clocksource
On 12/29/2017 04:48 PM, Alexander Tsoy wrote:
> В Пт, 29/12/2017 в 12:14 +0100, Toralf Förster пишет:
>> I can confirm now, that that kernel breaks both a desktop (an
>> ThinkPad T440s i5) and a headless server (i3930) setup. For the
>> server the attached .config works fi
On 12/29/2017 04:48 PM, Alexander Tsoy wrote:
> В Пт, 29/12/2017 в 12:14 +0100, Toralf Förster пишет:
>> I can confirm now, that that kernel breaks both a desktop (an
>> ThinkPad T440s i5) and a headless server (i3930) setup. For the
>> server the attached .config works fi
On 12/29/2017 02:33 PM, Sebastian Gottschall wrote:
> bootlog?
>
nothing in any logs, hang happens very early in the boot process
--
Toralf
PGP C4EACDDE 0076E94E
On 12/29/2017 02:33 PM, Sebastian Gottschall wrote:
> bootlog?
>
nothing in any logs, hang happens very early in the boot process
--
Toralf
PGP C4EACDDE 0076E94E
I can confirm now, that that kernel breaks both a desktop (an ThinkPad T440s
i5) and a headless server (i3930) setup. For the server the attached .config
works fine but switching from CONFIG_GENERIC_CPU to CONFIG_MCORE2 legt them
hang at boot w/op any messages. Similar picture at the desktop.
I can confirm now, that that kernel breaks both a desktop (an ThinkPad T440s
i5) and a headless server (i3930) setup. For the server the attached .config
works fine but switching from CONFIG_GENERIC_CPU to CONFIG_MCORE2 legt them
hang at boot w/op any messages. Similar picture at the desktop.
On 12/26/2017 10:16 PM, Ozgur wrote:
> You compile the kernel right? So, system is boot but not the network respond?
>
> Regards
Yes, I compile was fine the kernel (tried both new "kernel unwinder" kernel
options", made a distclean before).
All, what I can tell is in moment, it looks like that
On 12/26/2017 10:16 PM, Ozgur wrote:
> You compile the kernel right? So, system is boot but not the network respond?
>
> Regards
Yes, I compile was fine the kernel (tried both new "kernel unwinder" kernel
options", made a distclean before).
All, what I can tell is in moment, it looks like that
at a headless server: Intel(R) Core(TM) i7-3930K CPU @ 3.20GHz, stable hardened
Gentoo Linux
The hang does occur before any log message is written.
A ping command shows, that the server does reboot and dies after 20 pings are
received.
The .config is attached
FWIW I'm surprised a little bit
at a headless server: Intel(R) Core(TM) i7-3930K CPU @ 3.20GHz, stable hardened
Gentoo Linux
The hang does occur before any log message is written.
A ping command shows, that the server does reboot and dies after 20 pings are
received.
The .config is attached
FWIW I'm surprised a little bit
Hello,
toray I realized this warning at a hardened stable Gentoo Linux server :
Nov 3 23:57:49 mr-fox kernel: [109232.200147] refcount_t: underflow;
use-after-free.
Nov 3 23:57:49 mr-fox kernel: [109232.200160] [ cut here
]
Nov 3 23:57:49 mr-fox kernel:
Hello,
toray I realized this warning at a hardened stable Gentoo Linux server :
Nov 3 23:57:49 mr-fox kernel: [109232.200147] refcount_t: underflow;
use-after-free.
Nov 3 23:57:49 mr-fox kernel: [109232.200160] [ cut here
]
Nov 3 23:57:49 mr-fox kernel:
Hello,
got this today at a stable Gentoo Linux with recent kernel :
Nov 1 05:29:46 mr-fox kernel: [231282.542520]
Nov 1 05:29:46 mr-fox kernel: [231282.542523] UBSAN: Undefined behaviour in
Hello,
got this today at a stable Gentoo Linux with recent kernel :
Nov 1 05:29:46 mr-fox kernel: [231282.542520]
Nov 1 05:29:46 mr-fox kernel: [231282.542523] UBSAN: Undefined behaviour in
I catched the following UBSAN spew at a stable Gentoo Linux server with
hardened tool chain (.config attached) :
FWIW - The lines before the UBSAN might be completely unrelated - I'm unsure.
They do come from the build bot [1] I do run at that machine for Gentoo.
Sep 6 02:18:43 mr-fox kernel:
I catched the following UBSAN spew at a stable Gentoo Linux server with
hardened tool chain (.config attached) :
FWIW - The lines before the UBSAN might be completely unrelated - I'm unsure.
They do come from the build bot [1] I do run at that machine for Gentoo.
Sep 6 02:18:43 mr-fox kernel:
Got that at a hardened Gentoo Linux server with 4.12.0 (for the first time) at
a BTRFS logical volume occuping about 4/9 of a 5 TB volume group after an
uptime of about 2 days :
Had issues with processes accessing files at that volume now too.
Jul 6 15:33:53 mr-fox kernel: [158695.417132]
Got that at a hardened Gentoo Linux server with 4.12.0 (for the first time) at
a BTRFS logical volume occuping about 4/9 of a 5 TB volume group after an
uptime of about 2 days :
Had issues with processes accessing files at that volume now too.
Jul 6 15:33:53 mr-fox kernel: [158695.417132]
Whilst I'm wondering about missing kern.log entries of my server for about 13
hours within last night I stumbled over this :
May 1 05:53:19 mr-fox kernel: [63395.062218]
May 1 05:53:19 mr-fox kernel:
Whilst I'm wondering about missing kern.log entries of my server for about 13
hours within last night I stumbled over this :
May 1 05:53:19 mr-fox kernel: [63395.062218]
May 1 05:53:19 mr-fox kernel:
On 11/26/2016 02:16 PM, Pavel Machek wrote:
> Any chance to try 4.9?
> Pavel
sure - 4.9-rc6 is fine, both undocked and docked system allows hibernating
--
Toralf
PGP: C4EACDDE 0076E94E
On 11/26/2016 02:16 PM, Pavel Machek wrote:
> Any chance to try 4.9?
> Pavel
sure - 4.9-rc6 is fine, both undocked and docked system allows hibernating
--
Toralf
PGP: C4EACDDE 0076E94E
Whilst 4.7.10 is fine, the current 4.8.10 kernel spews that message in
dmesg during boot and later can't be undocked any longer - the vt7
display then will stay black forever.
Switching to another vt works fine FWIW.
Update: attached dmesg
--
Toralf
PGP: C4EACDDE 0076E94E
Linux version
Whilst 4.7.10 is fine, the current 4.8.10 kernel spews that message in
dmesg during boot and later can't be undocked any longer - the vt7
display then will stay black forever.
Switching to another vt works fine FWIW.
Update: attached dmesg
--
Toralf
PGP: C4EACDDE 0076E94E
Linux version
Whilst 4.7.10 is fine, the current 4.8.10 kernel spews that message in dmesg
during boot and later can't be undocked any longer - the vt7 display then will
stay black forever.
Switching to another vt works fine FWIW.
--
Toralf
PGP: C4EACDDE 0076E94E
Whilst 4.7.10 is fine, the current 4.8.10 kernel spews that message in dmesg
during boot and later can't be undocked any longer - the vt7 display then will
stay black forever.
Switching to another vt works fine FWIW.
--
Toralf
PGP: C4EACDDE 0076E94E
I do wonder about this new dmesg entry at a ThinkdPad T440s since 4.6.5:
amd_nb: Cannot enumerate AMD northbridges
--
Toralf
PGP: C4EACDDE 0076E94E
I do wonder about this new dmesg entry at a ThinkdPad T440s since 4.6.5:
amd_nb: Cannot enumerate AMD northbridges
--
Toralf
PGP: C4EACDDE 0076E94E
This is a hardened stable Gentoo Linux ThinkPad T440s.
After wakeup from s2disk the console stays at line "clocksource: tsc: mask:"
forever.
FWIW (and maby completely unrelated) I do wonder why since that version I do
have a dmesg line :
amd_nb: Cannot enumerate AMD northbridges
The
This is a hardened stable Gentoo Linux ThinkPad T440s.
After wakeup from s2disk the console stays at line "clocksource: tsc: mask:"
forever.
FWIW (and maby completely unrelated) I do wonder why since that version I do
have a dmesg line :
amd_nb: Cannot enumerate AMD northbridges
The
On 09/14/2016 02:49 PM, Theodore Ts'o wrote:
> What does "keyctl list @s" display? And what hapens if you try to
> rerun the add_key command? You should see something like this:
# keyctl list @s
1 key in keyring:
84804552: --alswrv 0 65534 keyring: _uid.0
A rerun of add_key won't help,
On 09/14/2016 02:49 PM, Theodore Ts'o wrote:
> What does "keyctl list @s" display? And what hapens if you try to
> rerun the add_key command? You should see something like this:
# keyctl list @s
1 key in keyring:
84804552: --alswrv 0 65534 keyring: _uid.0
A rerun of add_key won't help,
I do run a hardened stable Gentoo Linux server w/ kernel 4.7.3-ahrdened-r1
where I use an ext4fs directory /var/lib/tor in the following way :
scp ~/.cryptoSalt user@host:/tmp
cat /tmp/.cryptoPass | ssh user@host 'sudo -u tor e4crypt add_key -S
$(cat /tmp/.cryptoSalt)
I do run a hardened stable Gentoo Linux server w/ kernel 4.7.3-ahrdened-r1
where I use an ext4fs directory /var/lib/tor in the following way :
scp ~/.cryptoSalt user@host:/tmp
cat /tmp/.cryptoPass | ssh user@host 'sudo -u tor e4crypt add_key -S
$(cat /tmp/.cryptoSalt)
On 08/25/2016 08:31 PM, Toralf Förster wrote:
> Aug 25 20:28:27 t44 kernel: DVB: registering new adapter (Terratec Cinergy T
> USB XXS (HD)/ T3)
> Aug 25 20:28:27 t44 kernel: DVB: Unable to find symbol dib7000p_attach()
> Aug 25 20:28:27 t44 kernel: dvb-usb: no frontend was attached
On 08/25/2016 08:31 PM, Toralf Förster wrote:
> Aug 25 20:28:27 t44 kernel: DVB: registering new adapter (Terratec Cinergy T
> USB XXS (HD)/ T3)
> Aug 25 20:28:27 t44 kernel: DVB: Unable to find symbol dib7000p_attach()
> Aug 25 20:28:27 t44 kernel: dvb-usb: no frontend was attached
The dmesg now prints:
amd_nb: Cannot enumerate AMD northbridges
which is completely unexpected here at a non-AMD system (dmesg attaached).
--
Toralf
PGP: C4EACDDE 0076E94E, OTR: 420E74C8 30246EE7
Linux version 4.6.5-hardened (root@t44) (gcc version 4.9.3 (Gentoo Hardened
4.9.3 p1.5,
The dmesg now prints:
amd_nb: Cannot enumerate AMD northbridges
which is completely unexpected here at a non-AMD system (dmesg attaached).
--
Toralf
PGP: C4EACDDE 0076E94E, OTR: 420E74C8 30246EE7
Linux version 4.6.5-hardened (root@t44) (gcc version 4.9.3 (Gentoo Hardened
4.9.3 p1.5,
While reading the comment to 19ced623d :
"The hash buffer is really HASH_BLOCK_SIZE bytes, someone
must have thought that memmove takes n*u32 words by mistake.
Tests work as good/bad as before after this patch.
"
I was just curious why the tests doesn't fail now and since when the
While reading the comment to 19ced623d :
"The hash buffer is really HASH_BLOCK_SIZE bytes, someone
must have thought that memmove takes n*u32 words by mistake.
Tests work as good/bad as before after this patch.
"
I was just curious why the tests doesn't fail now and since when the
otherwise the monitor is just black, although the docked ThinkPad T440s wakes
up fine iand is up and running.
(system: i5, i915, current kernel and older kernel versions of a 64 bit
hardened Gentoo linux).
Just to help to improve the kernel (if it is a kernel issue).
--
Toralf
PGP: C4EACDDE
otherwise the monitor is just black, although the docked ThinkPad T440s wakes
up fine iand is up and running.
(system: i5, i915, current kernel and older kernel versions of a 64 bit
hardened Gentoo linux).
Just to help to improve the kernel (if it is a kernel issue).
--
Toralf
PGP: C4EACDDE
This is a ThinkPad T440s with a stable 64bit hardened Gentoo.
If it is docked then the described behaviour happens.
I do run latest kernel, former kernel versions show the same behaviour.
All other functionality of the resumed system is fine, so it is just the
monitor which needs an extra kick.
This is a ThinkPad T440s with a stable 64bit hardened Gentoo.
If it is docked then the described behaviour happens.
I do run latest kernel, former kernel versions show the same behaviour.
All other functionality of the resumed system is fine, so it is just the
monitor which needs an extra kick.
On 06/16/2016 11:14 AM, Henrique de Moraes Holschuh wrote:
> Did you try setting the BIOS to "highest performance" mode even while on
> battery?
ough - that was it - *head smack*
> BTW: update the BIOS of the T440s if you haven't done so already, AFAIK
did it
Thx Henrique for the answer
--
On 06/16/2016 11:14 AM, Henrique de Moraes Holschuh wrote:
> Did you try setting the BIOS to "highest performance" mode even while on
> battery?
ough - that was it - *head smack*
> BTW: update the BIOS of the T440s if you haven't done so already, AFAIK
did it
Thx Henrique for the answer
--
This diff is reliable depending whether the T440s is docked (right) or not
(left) :
Linux t44 4.5.7-hardened-r2 #1 SMP Wed Jun 15 23:39:10 CEST 2016 x86_64
Intel(R) Core(TM) i5-4300U CPU @ 1.90GHz GenuineIntel GNU/Linux
215c215
avx : 23504.000
This diff is reliable depending whether the T440s is docked (right) or not
(left) :
Linux t44 4.5.7-hardened-r2 #1 SMP Wed Jun 15 23:39:10 CEST 2016 x86_64
Intel(R) Core(TM) i5-4300U CPU @ 1.90GHz GenuineIntel GNU/Linux
215c215
avx : 23504.000
Toralf Förster:
> Got this at a 32 bit KVM during boot :
and later while fuzzying with trinity :
Apr 14 15:44:56 n22kvm-clone kernel:
Apr 14 15:44:56 n22kvm-clone kernel: UBSAN: Undefined behaviour in
./arch/
Toralf Förster:
> Got this at a 32 bit KVM during boot :
and later while fuzzying with trinity :
Apr 14 15:44:56 n22kvm-clone kernel:
Apr 14 15:44:56 n22kvm-clone kernel: UBSAN: Undefined behaviour in
./arch/
Got this at a 32 bit KVM during boot :
Apr 14 15:40:24 n22kvm-clone kernel:
Apr 14 15:40:24 n22kvm-clone kernel: UBSAN: Undefined behaviour in
./arch/x86/include/asm/atomic.h:156:2
Apr 14 15:40:24 n22kvm-clone
Got this at a 32 bit KVM during boot :
Apr 14 15:40:24 n22kvm-clone kernel:
Apr 14 15:40:24 n22kvm-clone kernel: UBSAN: Undefined behaviour in
./arch/x86/include/asm/atomic.h:156:2
Apr 14 15:40:24 n22kvm-clone
1 - 100 of 604 matches
Mail list logo
