On Mon, Sep 28, 2020 at 12:04 PM Dmitry Vyukov wrote:
>
> On Mon, Sep 28, 2020 at 11:31 AM Arend Van Spriel
> wrote:
> >
> > On 9/27/2020 10:47 AM, Dmitry Vyukov wrote:
> > > On Sun, Sep 27, 2020 at 10:38 AM syzbot
> > > wrote:
> > >>
> > >> Hello,
> > >>
> > >> syzbot found the following issue
On 9/28/2020 12:04 PM, Dmitry Vyukov wrote:
On Mon, Sep 28, 2020 at 11:31 AM Arend Van Spriel
wrote:
On 9/27/2020 10:47 AM, Dmitry Vyukov wrote:
On Sun, Sep 27, 2020 at 10:38 AM syzbot
wrote:
Hello,
syzbot found the following issue on:
HEAD commit:748d1c8a Merge branch 'devlink-Use-n
On Mon, Sep 28, 2020 at 11:31 AM Arend Van Spriel
wrote:
>
> On 9/27/2020 10:47 AM, Dmitry Vyukov wrote:
> > On Sun, Sep 27, 2020 at 10:38 AM syzbot
> > wrote:
> >>
> >> Hello,
> >>
> >> syzbot found the following issue on:
> >>
> >> HEAD commit:748d1c8a Merge branch
> >> 'devlink-Use-nla_po
On 9/27/2020 10:47 AM, Dmitry Vyukov wrote:
On Sun, Sep 27, 2020 at 10:38 AM syzbot
wrote:
Hello,
syzbot found the following issue on:
HEAD commit:748d1c8a Merge branch 'devlink-Use-nla_policy-to-validate-..
git tree: net-next
console output: https://syzkaller.appspot.com/x/log.txt
; Reported-by: syzbot+3640e696903873858...@syzkaller.appspotmail.com
>
> [ cut here ]
> WARNING: CPU: 1
>
>
> ---
> This report is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engine
x the issue, please add the following tag to the commit:
Reported-by: syzbot+3640e696903873858...@syzkaller.appspotmail.com
[ cut here ]
WARNING: CPU: 1
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about s
process.
Regards
Chris
[ OK ] Started Various fixups to make systemd work better on Debian.
[ 3.635568] [ cut here ]
[ 3.640597] WARNING: CPU: 1 PID: 166 at
kernel/locking/lockdep.c:3326 __lock_acquire+0x58c/0x1cf0
[ 3.649480] DEBUG_LOCKS_WARN_ON(class_idx
Hi,
have a reproachable kernel crash oops after update to 4.9.234
IMX6DL boot process.
Regards
Chris
[ OK ] Started Various fixups to make systemd work better on Debian.
[3.635568] [ cut here ]
[3.640597] WARNING: CPU: 1 PID: 166 at kernel/locking/lockdep.c
On 06/08, Alexei Starovoitov wrote:
On Mon, Jun 8, 2020 at 6:05 AM Christoph Hellwig wrote:
>
> On Mon, Jun 08, 2020 at 09:45:49AM +0200, Vegard Nossum wrote:
> > Just a test case.
> >
> > Allowing the kernel to allocate an unbounded amount of memory on
behalf
> > of userspace is an easy DOS.
On Mon, Jun 8, 2020 at 6:05 AM Christoph Hellwig wrote:
>
> On Mon, Jun 08, 2020 at 09:45:49AM +0200, Vegard Nossum wrote:
> > Just a test case.
> >
> > Allowing the kernel to allocate an unbounded amount of memory on behalf
> > of userspace is an easy DOS.
> >
> > All the length checks were alrea
On Mon, Jun 08, 2020 at 09:45:49AM +0200, Vegard Nossum wrote:
> Just a test case.
>
> Allowing the kernel to allocate an unbounded amount of memory on behalf
> of userspace is an easy DOS.
>
> All the length checks were already in there, e.g.
>
> static int cmm_timeout_handler(struct ctl_table *c
On 2020-06-08 08:51, Christoph Hellwig wrote:
On Thu, Jun 04, 2020 at 10:22:21PM +0200, Vegard Nossum wrote:
It's easy to reproduce by just doing
read(open("/proc/sys/vm/swappiness", O_RDONLY), 0, 512UL * 1024 * 1024
* 1024);
or so. Reverting the commit fixes the issue for me.
Yes, do
On Thu, Jun 04, 2020 at 10:22:21PM +0200, Vegard Nossum wrote:
> It's easy to reproduce by just doing
>
> read(open("/proc/sys/vm/swappiness", O_RDONLY), 0, 512UL * 1024 * 1024
> * 1024);
>
> or so. Reverting the commit fixes the issue for me.
Yes, doing giant allocations will fail and trace.
regression for me:
------------[ cut here ]
WARNING: CPU: 1 PID: 52 at mm/page_alloc.c:4826
__alloc_pages_nodemask+0x1cd/0x2a0
CPU: 1 PID: 52 Comm: init Not tainted 5.7.0+ #218
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
Ubuntu-1.8.2-1ubuntu1 04/01/2014
RIP: 0010:__alloc_p
On Tue, May 14, 2019 at 09:54:46PM +0200, Matteo Croce wrote:
> Hi Roman,
>
> yes, this one fixes it.
>
> --
> Matteo Croce
> per aspera ad upstream
Thank you for the confirmation!
The patch will be merged upstream soon.
Thanks!
Hi Roman,
yes, this one fixes it.
--
Matteo Croce
per aspera ad upstream
; root@debian64:~# strace true
> execve("/bin/true", ["true"], 0x7ffd444fdfb0 /* 18 vars */) = 0
> [..]
> exit_group(0) = ?
> [5.394349] WARNING: CPU: 1 PID: 228 at kernel/cgroup/cgroup.c:5929
> cgroup_exit+0xed/0x100
> [5.394606] CPU:
Hi,
I have the following splat when a ptraced process exits:
root@debian64:~# strace true
execve("/bin/true", ["true"], 0x7ffd444fdfb0 /* 18 vars */) = 0
[..]
exit_group(0) = ?
[ 5.394349] WARNING: CPU: 1 PID: 228 at kernel/cgroup/cgroup.c:59
On Fri, Jul 13, 2018 at 12:32:41PM +0800, Rong Chen wrote:
> Thanks, it's fixed with the patch.
Ingo, could you merge?
---
Subject: watchdog/softlockup: Fix cpu_stop_queue_work double-queue
From: Peter Zijlstra
Date: Wed, 11 Jul 2018 14:34:36 +0200
When scheduling is delayed for longer than the
2: errno=-5 IO failure
>>> [ 438.336415] BTRFS: error (device dm-0) in
>>> btrfs_run_delayed_refs:3070: errno=-5 IO failure
>>> [ 438.345590] BTRFS error (device dm-0): pending csums is 1028096
>>> [ 438.369254] BTRFS error (device dm-0): cleaner transaction attac
alloc count 98304
[ 438.385166] WARNING: CPU: 1 PID: 14674 at fs/btrfs/disk-io.c:3675
free_fs_root+0xc2/0xd0 [btrfs]
[ 438.396562] Modules linked in: dm_snapshot dm_thin_pool dm_persistent_data
dm_bio_prison dm_bufio dm_flakey dm_mod netconsole btrfs xor zstd_decompress
zstd_compress xxhash rai
ailure
> [ 438.345590] BTRFS error (device dm-0): pending csums is 1028096
> [ 438.369254] BTRFS error (device dm-0): cleaner transaction attach returned
> -30
> [ 438.377674] BTRFS info (device dm-0): at unmount delalloc count 98304
> [ 438.385166] WARNING: CPU: 1 PID: 14674 at
Hi,
this just happened on an i686 machine of mine:
[ cut here ]
WARNING: CPU: 1 PID: 1384 at lib/iov_iter.c:695 copy_page_to_iter+0x240/0x3b0
Modules linked in: xfs algif_skcipher af_alg uas nfsv4 dns_resolver nfs
nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject
Op 30-11-17 om 14:15 schreef Fengguang Wu:
> Hello,
>
> This happens in mainline kernel v4.15-rc1 on LENOVO IdeaPad U410.
> It at least dates back to v4.11 .
>
> It occurs in 72 out of 72 boots.
Can I get a boot log with drm.debug=0x1f? I don't have enough information to
see what's going on. :)
~
Hi Fengguang,
Fengguang Wu writes:
> It looks linus/master and linux-next still has this issue.
I sent a fix to net-next before it closes but it hasn't been picked.
Now that it's in the net tree, I'm sending an alternative fix right now.
Thank for the note!
Vivien
dition has a typo.
>
>
> I am still seeing this with commit 711aab1dbb32 (vfs: constify path argument
> to kernel_read_file_from_path), which is the latest from Linus’ master
> branch.
>
> ```
> [0.004000] [ cut here ]
> [0.004000] WARNING: CPU: 1
0.004000] [ cut here ]
[0.004000] WARNING: CPU: 1 PID: 0 at arch/x86/mm/tlb.c:257
initialize_tlbstate_and_flush+0x120/0x130
[0.004000] Modules linked in:
[0.004000] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.13.0+ #132
[0.004000] Hardware name: LENOVO 63633
On Thu, 14 Sep 2017, Andy Lutomirski wrote:
On Wed, Sep 13, 2017 at 5:59 AM, Thomas Voegtle wrote:
On Sun, 10 Sep 2017, Andy Lutomirski wrote:
On Sat, Sep 9, 2017 at 11:48 PM, Paul Menzel
wrote:
Dear Linux folks,
With Linux built from commit 4dfc2788033d (Merge tag
'iommu-updates-v4.14'
On Wed, Sep 13, 2017 at 5:59 AM, Thomas Voegtle wrote:
> On Sun, 10 Sep 2017, Andy Lutomirski wrote:
>
>> On Sat, Sep 9, 2017 at 11:48 PM, Paul Menzel
>> wrote:
>>>
>>> Dear Linux folks,
>>>
>>>
>>> With Linux built from commit 4dfc2788033d (Merge tag
>>> 'iommu-updates-v4.14'
>>> of git://git.ke
On 09/13/2017 02:44 PM, Linus Torvalds wrote:
> On Wed, Sep 13, 2017 at 9:26 AM, Linus Torvalds
> wrote:
>> Yes, ths fix should be percolating up from the x86 tip tree later
>> today, I'm hoping.
>
> Ok, this should all be ok in current -git now.
Confirmed, no more warnings with current -git. No
On Wed, Sep 13, 2017 at 9:26 AM, Linus Torvalds
wrote:
> Yes, ths fix should be percolating up from the x86 tip tree later
> today, I'm hoping.
Ok, this should all be ok in current -git now.
Linus "knock wood" Torvalds
On 09/13/2017 10:26 AM, Linus Torvalds wrote:
> On Wed, Sep 13, 2017 at 9:11 AM, Jens Axboe wrote:
>>
>> I get this new warning when I suspend/resume my gen4 x1 laptop running
>> current -git. Looks like this commit is the problematic one:
>
> Yes, ths fix should be percolating up from the x86 ti
On Wed, Sep 13, 2017 at 9:11 AM, Jens Axboe wrote:
>
> I get this new warning when I suspend/resume my gen4 x1 laptop running
> current -git. Looks like this commit is the problematic one:
Yes, ths fix should be percolating up from the x86 tip tree later
today, I'm hoping. In the meantime, things
and resume
Full trace:
[13570.177554] x86: Booting SMP configuration:
[13570.177558] smpboot: Booting Node 0 Processor 1 APIC 0x2
[13570.186919] [ cut here ]
[13570.186942] WARNING: CPU: 1 PID: 0 at arch/x86/mm/tlb.c:245
initialize_tlbstate_and_flush+0x6a/0x100
[13570.186945
On Sun, 10 Sep 2017, Andy Lutomirski wrote:
On Sat, Sep 9, 2017 at 11:48 PM, Paul Menzel wrote:
Dear Linux folks,
With Linux built from commit 4dfc2788033d (Merge tag 'iommu-updates-v4.14'
of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu), I get the
warning below on a Lenovo X60t
On Sat, Sep 9, 2017 at 11:48 PM, Paul Menzel wrote:
> Dear Linux folks,
>
>
> With Linux built from commit 4dfc2788033d (Merge tag 'iommu-updates-v4.14'
> of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu), I get the
> warning below on a Lenovo X60t with a 32-bit CPU.
Indeed. I sent a
---[ cut here ]
[ 0.004000] WARNING: CPU: 1 PID: 0 at arch/x86/mm/tlb.c:237
initialize_tlbstate_and_flush+0x120/0x130
[0.004000] Modules linked in:
[0.004000] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.13.0+ #126
[0.004000] Hardware name: LENOVO 636338U/636338U, BIOS CBET4000
to negative value (-537001984)
[ cut here ]----
WARNING: CPU: 1 PID: 72688 at fs/super.c:1244 mount_fs+0x200/0x220
Modules linked in: cramfs iptable_mangle ipt_MASQUERADE
nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4
nf_defrag_ipv4 xt_conntr
4_cpu --smt=off
>
> With above command a WARN_ON(1) is triggered from stop_wd_on_cpu
> function in file arch/powerpc/kernel/watchdog.c at line 314
>
> static int stop_wd_on_cpu(unsigned int cpu)
> {
> if (!cpumask_test_cpu(cpu, &wd_cpus_enabled)) {
> >>>
d_cpus_enabled)) {
>>> WARN_ON(1);
return 0;
}
$ dmesg
WARNING: CPU: 1 PID: 13 at arch/powerpc/kernel/watchdog.c:314
stop_wd_on_cpu+0x54/0xf0
Modules linked in: iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4
iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4
xt
here ]
[ 703.002355] WARNING: CPU: 1 PID: 1248 at fs/dcache.c:1445
umount_check+0x81/0x90
[ 703.002357] Modules linked in:
[ 703.002363] CPU: 1 PID: 1248 Comm: zdtm_ct Not tainted 4.11.0-rc1+ #1
[ 703.002365] Hardware name: Google Google Compute Engine/Google
Compute Engine, BIOS Google 01/01
Hello,
We run CRIU tests on linux-next periodically and here is a new bug:
[ 430.017231] BUG: Dentry 8e4ab9a7b6c0{i=41b2e,n=default} still
in use (1) [unmount of proc proc]
[ 430.027843] [ cut here ]
[ 430.027854] WARNING: CPU: 1 PID: 24110 at fs/dcache.c:1445
On 02/21, Ye Xiaolong wrote:
>Hi, fengguang
>On 02/20, Thomas Gleixner wrote:
>>On Tue, 21 Feb 2017, Fengguang Wu wrote:
>>
>>> Hi Marc,
>>>
>>> FYI here is another bisect result. The attached reproduce-* script can
>>> be used to reproduce the bug.
>>
>>Again. This is a problem in the calling cod
Hi, fengguang
On 02/20, Thomas Gleixner wrote:
>On Tue, 21 Feb 2017, Fengguang Wu wrote:
>
>> Hi Marc,
>>
>> FYI here is another bisect result. The attached reproduce-* script can
>> be used to reproduce the bug.
>
>Again. This is a problem in the calling code The WARN_ON merily shows the
>wreckag
On Mon, Feb 20, 2017 at 06:07:57PM -0800, Thomas Gleixner wrote:
On Tue, 21 Feb 2017, Fengguang Wu wrote:
Hi Marc,
FYI here is another bisect result. The attached reproduce-* script can
be used to reproduce the bug.
Again. This is a problem in the calling code The WARN_ON merily shows the
wr
On Tue, 21 Feb 2017, Fengguang Wu wrote:
> Hi Marc,
>
> FYI here is another bisect result. The attached reproduce-* script can
> be used to reproduce the bug.
Again. This is a problem in the calling code The WARN_ON merily shows the
wreckage in the caller. Marc sent you a patch already...
> [
* Mike Galbraith wrote:
> On Tue, 2017-01-31 at 09:54 +0100, Ingo Molnar wrote:
>
> > > Fast ain't gonna happen, 5bf728f02218 bricked.
> >
> > :-/
> >
> > Next point would be f9a42e0d58cf I suspect, to establish that Linus's
> > latest
> > kernel is fine. That means it's in one of the ~200
On Tue, 2017-01-31 at 09:54 +0100, Ingo Molnar wrote:
> > Fast ain't gonna happen, 5bf728f02218 bricked.
>
> :-/
>
> Next point would be f9a42e0d58cf I suspect, to establish that Linus's latest
> kernel is fine. That means it's in one of the ~200 -tip commits - should be
> bisectable in 8-10 s
0x3
> > > > > [ 75.359056] smpboot: CPU 3 is now offline
> > > > > [ 75.415505] smpboot: CPU 4 is now offline
> > > > > [ 75.479985] smpboot: CPU 5 is now offline
> > > > > [ 75.550674] [ cut here ]
> > >
t; [ 75.415505] smpboot: CPU 4 is now offline
> > > > [ 75.479985] smpboot: CPU 5 is now offline
> > > > [ 75.550674] [ cut here ]
> > > > [ 75.550678] WARNING: CPU: 1 PID: 15 at kernel/sched/sched.h:804
> > > > assert_clock_upda
On Tue, 2017-01-31 at 08:45 +0100, Ingo Molnar wrote:
> * Mike Galbraith wrote:
>
> > On Tue, 2017-01-31 at 08:28 +0100, Ingo Molnar wrote:
> > > * Mike Galbraith wrote:
> >
> > > > Weeell, I'll have to take your word for it, as tip g35669bb7fd46 grew
> > > > an early boot brick problem.
> > >
* Mike Galbraith wrote:
> On Tue, 2017-01-31 at 08:28 +0100, Ingo Molnar wrote:
> > * Mike Galbraith wrote:
>
> > > Weeell, I'll have to take your word for it, as tip g35669bb7fd46 grew
> > > an early boot brick problem.
> >
> > That's bad - could you perhaps try to bisect it? All recently qu
On Tue, 2017-01-31 at 08:28 +0100, Ingo Molnar wrote:
> * Mike Galbraith wrote:
> > Weeell, I'll have to take your word for it, as tip g35669bb7fd46 grew
> > an early boot brick problem.
>
> That's bad - could you perhaps try to bisect it? All recently queued up
> patches
> that could cause su
Processor 4 APIC 0x1
> > > [ 75.310698] smpboot: Booting Node 0 Processor 5 APIC 0x3
> > > [ 75.359056] smpboot: CPU 3 is now offline
> > > [ 75.415505] smpboot: CPU 4 is now offline
> > > [ 75.479985] smpboot: CPU 5 is now offline
> > > [
rocessor 5 APIC 0x3
> > [ 75.359056] smpboot: CPU 3 is now offline
> > [ 75.415505] smpboot: CPU 4 is now offline
> > [ 75.479985] smpboot: CPU 5 is now offline
> > [ 75.550674] [ cut here ]
> > [ 75.550678] WARNING: CPU: 1
PU 4 is now offline
> [ 75.479985] smpboot: CPU 5 is now offline
> [ 75.550674] [ cut here ]----
> [ 75.550678] WARNING: CPU: 1 PID: 15 at kernel/sched/sched.h:804
> assert_clock_updated.isra.62.part.63+0x25/0x27
> [ 75.550679] rq->clock_update_flags <
here ]
[ 75.550678] WARNING: CPU: 1 PID: 15 at kernel/sched/sched.h:804
assert_clock_updated.isra.62.part.63+0x25/0x27
[ 75.550679] rq->clock_update_flags < RQCF_ACT_SKIP
[ 75.550679] Modules linked in: ebtable_filter(E) ebtables(E) fuse(E)
nf_log_ipv6(E) xt_pkttype(E) x
RNING: CPU: 1 PID: 1 at drivers/gpu/drm/drm_crtc.c:5776
drm_mode_config_cleanup+0x1a8/0x1c0
[9.944982] CPU: 1 PID: 1 Comm: swapper/0 Not tainted
4.8.0-rc4-3-gbea5b15 #1
[9.945612] 00200286 00200286 92e5fde8 9382d4e4 946e08d4 92e5fe00
93642829
[9.946316] 1690 8d4
Lemme add the usual suspects. I see also fuse in the splat, + Miklos.
This is rc7 + tip/master.
[ 8837.520731] [ cut here ]
[ 8837.520739] WARNING: CPU: 1 PID: 22073 at kernel/locking/mutex-debug.c:41
debug_mutex_wake_waiter+0x7c/0x160
[ 8837.520740] DEBUG_LOCKS_WARN_ON
mappings: passed, no W+X pages found.
On failure it prints a warning and a count of the failed pages:
[ cut here ]
WARNING: CPU: 1 PID: 1 at arch/x86/mm/dump_pagetables.c:226
note_page+0x610/0x7b0()
x86/mm: Found insecure W+X mapping at address
| 1 |
+---+++
[1.185876] xor: measuring software checksum speed
[1.188092] kworker/u4:0 (19) used greatest stack depth: 13440 bytes left
[1.189789] [ cut here ]
[1.191115] WARNING: CPU: 1 PID: 0 at kernel
On Sun, Apr 24, 2016 at 12:42:55AM +0200, Peter Zijlstra wrote:
> Doth the below fixeth thingies?
It doth. Thanks!
Tested-by: Borislav Petkov
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
72] perf: AMD IBS detected (0x07ff)
> [0.761340] [ cut here ]--------
> [0.761571] WARNING: CPU: 1 PID: 1 at kernel/events/core.c:7825
> perf_pmu_register+0x385/0x390
> [0.761909] Modules linked in:
> [0.762093] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.6
On Sat, 2016-04-16 at 17:43 +0200, Borislav Petkov wrote:
> On Fri, Apr 15, 2016 at 04:16:02AM +, Grumbach, Emmanuel wrote:
> > [1]
> > https://git.kernel.org/cgit/linux/kernel/git/iwlwifi/backport-iwlwi
> > fi.git/
>
> It is very strange to pull from this repo, git fetch is doing
> something
On Fri, Apr 15, 2016 at 04:16:02AM +, Grumbach, Emmanuel wrote:
> [1] https://git.kernel.org/cgit/linux/kernel/git/iwlwifi/backport-iwlwi
> fi.git/
It is very strange to pull from this repo, git fetch is doing something
for a while now without any forward progress.
In any case, 4.5 is bad too
k.
> ...
> [ 661.142657] [ cut here ]------------
> [ 661.142816] WARNING: CPU: 1 PID: 2485 at
> drivers/net/wireless/intel/iwlwifi/pcie/trans.c:1752
> iwl_trans_pcie_grab_nic_access+0x110/0x120 [iwlwifi]
> [ 661.143231] Timeout waiting for hardware access (CSR_GP_CNTRL
> 0xff
ue 2 stuck for 1 ms.
[ 661.124748] iwlwifi :02:00.0: Current SW read_ptr 59 write_ptr 63
[ 661.142657] [ cut here ]
[ 661.142816] WARNING: CPU: 1 PID: 2485 at
drivers/net/wireless/intel/iwlwifi/pcie/trans.c:1752
iwl_trans_pcie_grab_nic_access+0x110/0x12
On Thu, Jan 21, 2016 at 01:16:41PM +0800, kernel test robot wrote:
> [ 18.469193] [ cut here ]
> [ 18.470790] WARNING: CPU: 1 PID: 645 at kernel/sched/rt.c:1161
> dequeue_rt_stack+0x2a1/0x300()
> [ 18.474113] Modules linked in: rpcsec_gss_krb5 auth_
Hi Sasha,
> While fuzzing with trinity inside a KVM tools guest, running the latest -next
> kernel, I've hit the following warning:
>
> [ 1153.249127] WARNING: CPU: 1 PID: 25657 at include/net/sock.h:586
> bt_sock_unlink+0x1c7/0x220()
> [ 1153.250162] Modules linked in:
On Tue, 3 Nov 2015, Grygorii Strashko wrote:
> On 11/03/2015 03:46 PM, Sebastian Andrzej Siewior wrote:
> > On 11/02/2015 08:30 PM, Grygorii Strashko wrote:
> >> On -RT above code will generate warnings, because
> >> driver_xx_hw_irq_handler()
> >> will be forced threaded (by default) and, as resu
On 11/03/2015 03:46 PM, Sebastian Andrzej Siewior wrote:
> On 11/02/2015 08:30 PM, Grygorii Strashko wrote:
>> On -RT above code will generate warnings, because driver_xx_hw_irq_handler()
>> will be forced threaded (by default) and, as result, generic_handle_irq()
>> will be called with IRQs enable
On 11/02/2015 08:30 PM, Grygorii Strashko wrote:
> On -RT above code will generate warnings, because driver_xx_hw_irq_handler()
> will be forced threaded (by default) and, as result, generic_handle_irq()
> will be called with IRQs enabled. To W/A this issue generic_handle_irq() can
> be surrounded
()
|-or- handle_edge_irq()
|-handle_irq_event()
|-handle_irq_event_percpu()
===
"WARNING: CPU: 1 PID: 82 at kernel/irq/handle.c:150
handle_irq_event_percpu+0x14c/0x174()
irq 460 handler irq_default_primary_handler+0x0/0x14 enabled inter
Use generic_handle_irq_rt_wa() to W/A below backtrace, which is
triggered because dra7xx_pcie_msi_irq_handler() forced to be
threaded on -RT:
[ cut here ]
WARNING: CPU: 1 PID: 82 at kernel/irq/handle.c:150
handle_irq_event_percpu+0x14c/0x174()
irq 460 handler
-07.cgz-x86_64-acpi-redef-e8de7ec5cc871dacba9149fe6b5aacc545baef2c-20151031-105622-1k6mt59-0.yaml&loadavg=0.68
0.16 0.05 1/118
817&start_time=1446232943&end_time=1446232944&version=/lkp/lkp/.src-20151030-185949&
-q -O /dev/null
[ 25.953285] WARNING: CPU: 1 PID: 699 at in
link becomes ready
[ 36.269136] iwlwifi :03:00.0: L1 Enabled - LTR Disabled
[ 39.673321] [ cut here ]
[ 39.673335] WARNING: CPU: 1 PID: 2914 at drivers/gpu/drm/drm_atomic.c:889
drm_atomic_get_property+0x244/0x2d0()
[ 39.673338] Modules linked in: msr cpufreq_powe
Again, the problem with the display, the screen (when logging into gnome shell)
is flying from right to left and generates oops
---
Sep 12 11:30:42 AMILO-V3405 kernel: [ 62.208427] WARNING: CPU: 1 PID: 1676 at
drivers/gpu/drm/drm_atomic.c:491 drm_atomic_check_only+0x48f/0x5f0 [drm]()
Sep 12
poma writes:
>> Ref.
>> https://bugzilla.redhat.com/show_bug.cgi?id=1252167
>> https://bugzilla.kernel.org/show_bug.cgi?id=102631
>>
>
> You guys are really something.
Hi Poma,
I understand your frustration!
I got involved via the other thread which didn't mention your bug report
anywh
On 08/21/2015 03:21 AM, poma wrote:
On 10.08.2015 23:26, poma wrote:
[ cut here ]
WARNING: CPU: 1 PID: 813 at kernel/module.c:291
module_assert_mutex_or_preempt+0x49/0x90()
Modules linked in: mxl5007t af9013 ... dvb_usb_af9015(+) ... dvb_usb_v2
dvb_core rc_core
On 10.08.2015 23:26, poma wrote:
>
> [ cut here ]----
> WARNING: CPU: 1 PID: 813 at kernel/module.c:291
> module_assert_mutex_or_preempt+0x49/0x90()
> Modules linked in: mxl5007t af9013 ... dvb_usb_af9015(+) ... dvb_usb_v2
> dvb_core rc_core ...
>
[ cut here ]
WARNING: CPU: 1 PID: 813 at kernel/module.c:291
module_assert_mutex_or_preempt+0x49/0x90()
Modules linked in: mxl5007t af9013 ... dvb_usb_af9015(+) ... dvb_usb_v2
dvb_core rc_core ...
CPU: 1 PID: 813 Comm: systemd-udevd Not tainted
4.2.0-0.rc6.git0.1.fc24
H... Okay so someone is holding a lock on the structure that is being
freed. Has nothing to do with slab allocation.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/ma
On Fri, 7 Aug 2015, Fengguang Wu wrote:
> [ 31.664489] WARNING: CPU: 1 PID: 1 at lib/debugobjects.c:263
> debug_print_object+0xfe/0x11d()
> [ 31.675198] ODEBUG: free active (active state 0) object type: work_struct
> hint: power_supply_changed_work+0x0/0x1f7
Ok this is slab
0 | 1 |
+++++
[ 31.661955] power_supply test_ac: POWER_SUPPLY_NAME=test_ac
[ 31.663026] device: 'test_ac': power_supply_dev_release
[ 31.663799] [ cut here ]--------
[ 31.664489] WARNING: CPU: 1 PID: 1 at lib/debugobjects.c:263
debu
At a Gentoo Linux hardened amd64 desktop I got this trace after upgrading from
4.0.8 :
Jul 27 14:01:13 t44 kernel: [0.34] [ cut here ]
Jul 27 14:01:13 t44 kernel: [0.344453] WARNING: CPU: 1 PID: 1 at
arch/x86/mm/ioremap.c:202 __ioremap_caller+0x26f/0x3b0
On Wed, Jul 08, 2015 at 11:32:13AM +0100, Mel Gorman wrote:
> From: Nicolai Stange
> Subject: Re: [PATCH] mm/page_alloc: deferred meminit: replace rwsem with
> completion
>
> Commit 0e1cc95b4cc7
> ("mm: meminit: finish initialisation of struct pages before basic setup")
> introduced a rwsem to
On Tue, Jul 07, 2015 at 10:27:58PM +0800, kernel test robot wrote:
> Greetings,
>
> 0day kernel testing robot got the below dmesg and the first bad commit is
>
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
>
> commit 0e1cc95b4cc7293bb7b39175035e7f7e45c90977
> Author:
On Fri, Jun 26, 2015 at 11:29 PM, Fengguang Wu wrote:
> Ah it has been reported, sorry for the duplicated report!
No problem. It was a good catch -- this bug seems to be quite
dependent on kernel config.
--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the bo
encrypted registered
[ 10.370264] debug: unmapping init [mem 0x857c1000-0x85837fff]
[ 10.374694] [ cut here ]
[ 10.375581] WARNING: CPU: 1 PID: 1 at kernel/locking/lockdep.c:2595
trace_hardirqs_on_caller+0x186/0x1e0()
[ 10.387711] DEBUG_LOCKS_WARN_ON(!irqs_disabled
Huang Ying writes:
> FYI, we noticed the below changes on
>
> git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git
> for-testing
> commit 3668622c537df68d542cf29e98c05527080e302a ("proc: Allow creating
> permanently empty directories.")
Thank you for reporting this.
I cor
t;
>>>> with next-20141231 I am seeing this call-trace:
>>>>
>>>> [ 88.028632] [ cut here ]
>>>> [ 88.028643] WARNING: CPU: 1 PID: 2539 at kernel/sched/core.c:7303
>>>> __might_sleep+0xbd/0xd0()
>&g
|
>>>>> > | backtrace:SyS_write | 0
>>>>> > | 2 |
>>>>> > | backtrace:populate_rootfs| 0
>>>>> > | 2 |
>>>>> > | backtrace:kernel_init_freeable | 0
&g
| backtrace:kernel_init_freeable | 0
>>>> >| 2 |
>>>> > | WARNING:at_kernel/sched/core.c:#__might_sleep() | 0
>>>> >| 10 |
>>>> > | backtrace:nfs41_callba
| 0
>>> > | 2 |
>>> > | backtrace:kernel_init_freeable | 0
>>> > | 2 |
>>> > | WARNING:at_kernel/sched/core.c:#__might_sleep() | 0
>>> > | 10
ernel_init_freeable | 0
>> > | 2 |
>> > | WARNING:at_kernel/sched/core.c:#__might_sleep() | 0
>> > | 10 |
>> > | backtrace:nfs41_callback_svc | 0
>> > | 10 |
>> > +-
|
> > +----------+----++
> >
> >
> > [ 12.520894] Key type id_resolver registered
> > [ 12.522364] Key type id_legacy registered
> > [ 12.530530] [ cut here ]---
On Sat, Jan 24, 2015 at 08:36:08PM -0800, Fengguang Wu wrote:
> [ 17.687075] Freeing unused kernel memory: 1716K (c190d000 - c1aba000)
> [ 17.808897] random: init urandom read with 5 bits of entropy available
> [ 17.828360] [ cut here ]
> [ 17.828989]
;>>
>>> [ 88.028632] ------------[ cut here ]
>>> [ 88.028643] WARNING: CPU: 1 PID: 2539 at kernel/sched/core.c:7303
>>> __might_sleep+0xbd/0xd0()
>>> [ 88.028646] do not call blocking ops when !TASK_RUNNING; state=1
>>> set at [] prepa
Hi Sedat,
On Sun, Jan 4, 2015 at 7:42 AM, Sedat Dilek wrote:
> On Thu, Jan 1, 2015 at 11:28 AM, Sedat Dilek wrote:
>> Hi,
>>
>> with next-20141231 I am seeing this call-trace:
>>
>> [ 88.028632] [ cut here ]--------
>> [ 88.028643] WA
On Thu, Jan 1, 2015 at 11:28 AM, Sedat Dilek wrote:
> Hi,
>
> with next-20141231 I am seeing this call-trace:
>
> [ 88.028632] [ cut here ]
> [ 88.028643] WARNING: CPU: 1 PID: 2539 at kernel/sched/core.c:7303
> __might_sleep+0xbd/0xd0()
> [
1 - 100 of 213 matches
Mail list logo
