] BUG: unable to handle kernel NULL pointer dereference
at 0030
[2.394613] IP: [811f9834] add_disk+0x88/0x3ff
[2.395490] PGD 375b1067 PUD 375b2067 PMD 0
[2.396371] Oops: [#2] PREEMPT SMP
[2.397150] Modules linked in: sr_mod(+) atkbd cdrom mii thermal
On Thu, Sep 18, 2014 at 09:17:51PM +0800, Fengguang Wu wrote:
> Hi Paul,
>
> > > > > plymouth-upstart-bridge: ply-event-loop.c:497: ply_event_loop_new:
> > > > > Assertion `loop->epoll_fd >= 0' failed.
> > > > > /etc/lsb-base-logging.sh: line 5: 2580 Aborted
> > > > > plymouth
On Thu, Sep 18, 2014 at 09:17:51PM +0800, Fengguang Wu wrote:
Hi Paul,
plymouth-upstart-bridge: ply-event-loop.c:497: ply_event_loop_new:
Assertion `loop-epoll_fd = 0' failed.
/etc/lsb-base-logging.sh: line 5: 2580 Aborted
plymouth --ping /dev/null 21
Hi Paul,
> > > > plymouth-upstart-bridge: ply-event-loop.c:497: ply_event_loop_new:
> > > > Assertion `loop->epoll_fd >= 0' failed.
> > > > /etc/lsb-base-logging.sh: line 5: 2580 Aborted
> > > > plymouth --ping > /dev/null 2>&1
> > > > /etc/lsb-base-logging.sh: line 5: 2585
Hi Paul,
plymouth-upstart-bridge: ply-event-loop.c:497: ply_event_loop_new:
Assertion `loop-epoll_fd = 0' failed.
/etc/lsb-base-logging.sh: line 5: 2580 Aborted
plymouth --ping /dev/null 21
/etc/lsb-base-logging.sh: line 5: 2585 Aborted
On Thu, Sep 04, 2014 at 09:04:28AM -0700, Paul E. McKenney wrote:
> On Thu, Sep 04, 2014 at 08:38:45PM +0800, Fengguang Wu wrote:
> > On Tue, Sep 02, 2014 at 10:16:57AM -0700, Paul E. McKenney wrote:
> > > On Tue, Sep 02, 2014 at 11:55:58AM -0500, Christoph Lameter wrote:
> > > > On Tue, 2 Sep
On Fri, Sep 12, 2014 at 05:38:37PM -0700, Paul E. McKenney wrote:
> On Sat, Sep 13, 2014 at 08:20:05AM +0800, Fengguang Wu wrote:
> > On Fri, Sep 12, 2014 at 12:26:59PM -0700, Paul E. McKenney wrote:
> > > On Fri, Sep 12, 2014 at 02:19:57PM -0500, Christoph Lameter wrote:
> > > > On Fri, 12 Sep
On Fri, Sep 12, 2014 at 05:38:37PM -0700, Paul E. McKenney wrote:
On Sat, Sep 13, 2014 at 08:20:05AM +0800, Fengguang Wu wrote:
On Fri, Sep 12, 2014 at 12:26:59PM -0700, Paul E. McKenney wrote:
On Fri, Sep 12, 2014 at 02:19:57PM -0500, Christoph Lameter wrote:
On Fri, 12 Sep 2014, Paul
On Thu, Sep 04, 2014 at 09:04:28AM -0700, Paul E. McKenney wrote:
On Thu, Sep 04, 2014 at 08:38:45PM +0800, Fengguang Wu wrote:
On Tue, Sep 02, 2014 at 10:16:57AM -0700, Paul E. McKenney wrote:
On Tue, Sep 02, 2014 at 11:55:58AM -0500, Christoph Lameter wrote:
On Tue, 2 Sep 2014, Paul E.
On Sat, Sep 13, 2014 at 08:20:05AM +0800, Fengguang Wu wrote:
> On Fri, Sep 12, 2014 at 12:26:59PM -0700, Paul E. McKenney wrote:
> > On Fri, Sep 12, 2014 at 02:19:57PM -0500, Christoph Lameter wrote:
> > > On Fri, 12 Sep 2014, Paul E. McKenney wrote:
> > >
> > > > So, I am not seeing this
On Fri, Sep 12, 2014 at 12:26:59PM -0700, Paul E. McKenney wrote:
> On Fri, Sep 12, 2014 at 02:19:57PM -0500, Christoph Lameter wrote:
> > On Fri, 12 Sep 2014, Paul E. McKenney wrote:
> >
> > > So, I am not seeing this failure in my testing, but my best guess is
> > > that the problem is due to
in the thread, it really is
not clear how this change is triggering the bug.
The tracer testing triggers this bug which is a corrupt stack and we
see no force_quiescent_state() in the back trace. So may be this is
exposing a bug somewhere else? Not really sure how to look at this.
> [0.42
On Fri, Sep 12, 2014 at 02:19:57PM -0500, Christoph Lameter wrote:
> On Fri, 12 Sep 2014, Paul E. McKenney wrote:
>
> > So, I am not seeing this failure in my testing, but my best guess is
> > that the problem is due to the fact that force_quiescent_state() is
> > sometimes invoked with
On Fri, 12 Sep 2014, Paul E. McKenney wrote:
> So, I am not seeing this failure in my testing, but my best guess is
> that the problem is due to the fact that force_quiescent_state() is
> sometimes invoked with preemption enabled, which breaks __this_cpu_read()
> though perhaps with very low
:unable_to_handle_kernel_paging_request| 0
> | 0 | 586|
> | EIP_is_at_spin_dump | 0
> | 0 | 586|
> | backtrace:init_irqsoff_tracer | 0
> | 0 | 10 |
> +---+-
|
+---++++
[0.317670] Testing tracer wakeup_dl: ret = 0
[0.420620] PASSED
[0.420978] Testing tracer branch:
[0.421701] BUG: unable to handle kernel NULL pointer dereference at
00da
[0.422857] IP: [c1061074] update_curr
On Fri, 12 Sep 2014, Paul E. McKenney wrote:
So, I am not seeing this failure in my testing, but my best guess is
that the problem is due to the fact that force_quiescent_state() is
sometimes invoked with preemption enabled, which breaks __this_cpu_read()
though perhaps with very low
On Fri, Sep 12, 2014 at 02:19:57PM -0500, Christoph Lameter wrote:
On Fri, 12 Sep 2014, Paul E. McKenney wrote:
So, I am not seeing this failure in my testing, but my best guess is
that the problem is due to the fact that force_quiescent_state() is
sometimes invoked with preemption
kernel NULL pointer dereference at
00da
[0.422857] IP: [c1061074] update_curr+0x1a3/0x2c3
[0.423639] *pdpt = *pde = f000ff53f000ff53
[0.424000] Thread overran stack, or stack corrupted
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
On Fri, Sep 12, 2014 at 12:26:59PM -0700, Paul E. McKenney wrote:
On Fri, Sep 12, 2014 at 02:19:57PM -0500, Christoph Lameter wrote:
On Fri, 12 Sep 2014, Paul E. McKenney wrote:
So, I am not seeing this failure in my testing, but my best guess is
that the problem is due to the fact
On Sat, Sep 13, 2014 at 08:20:05AM +0800, Fengguang Wu wrote:
On Fri, Sep 12, 2014 at 12:26:59PM -0700, Paul E. McKenney wrote:
On Fri, Sep 12, 2014 at 02:19:57PM -0500, Christoph Lameter wrote:
On Fri, 12 Sep 2014, Paul E. McKenney wrote:
So, I am not seeing this failure in my
On Thu, Sep 04, 2014 at 08:38:45PM +0800, Fengguang Wu wrote:
> On Tue, Sep 02, 2014 at 10:16:57AM -0700, Paul E. McKenney wrote:
> > On Tue, Sep 02, 2014 at 11:55:58AM -0500, Christoph Lameter wrote:
> > > On Tue, 2 Sep 2014, Paul E. McKenney wrote:
> > >
> > > > Added by ac1bea85781e
On Tue, Sep 02, 2014 at 10:16:57AM -0700, Paul E. McKenney wrote:
> On Tue, Sep 02, 2014 at 11:55:58AM -0500, Christoph Lameter wrote:
> > On Tue, 2 Sep 2014, Paul E. McKenney wrote:
> >
> > > Added by ac1bea85781e (sched,rcu: Make cond_resched() report RCU quiescent
> > > states), removed by
On Tue, Sep 02, 2014 at 10:16:57AM -0700, Paul E. McKenney wrote:
On Tue, Sep 02, 2014 at 11:55:58AM -0500, Christoph Lameter wrote:
On Tue, 2 Sep 2014, Paul E. McKenney wrote:
Added by ac1bea85781e (sched,rcu: Make cond_resched() report RCU quiescent
states), removed by 4a81e8328d379
On Thu, Sep 04, 2014 at 08:38:45PM +0800, Fengguang Wu wrote:
On Tue, Sep 02, 2014 at 10:16:57AM -0700, Paul E. McKenney wrote:
On Tue, Sep 02, 2014 at 11:55:58AM -0500, Christoph Lameter wrote:
On Tue, 2 Sep 2014, Paul E. McKenney wrote:
Added by ac1bea85781e (sched,rcu: Make
On Tue, Sep 02, 2014 at 11:55:58AM -0500, Christoph Lameter wrote:
> On Tue, 2 Sep 2014, Paul E. McKenney wrote:
>
> > Added by ac1bea85781e (sched,rcu: Make cond_resched() report RCU quiescent
> > states), removed by 4a81e8328d379 (rcu: Reduce overhead of cond_resched()
> > checks for RCU). So,
On Tue, 2 Sep 2014, Paul E. McKenney wrote:
> Added by ac1bea85781e (sched,rcu: Make cond_resched() report RCU quiescent
> states), removed by 4a81e8328d379 (rcu: Reduce overhead of cond_resched()
> checks for RCU). So, as you say, no effect on contemporary kernels.
Well not sure what to make
On Tue, Sep 02, 2014 at 11:00:12AM -0500, Christoph Lameter wrote:
> On Tue, 2 Sep 2014, Paul E. McKenney wrote:
>
> > Before this commit, raw_cpu_add_return() didn't build. The commit
> > didn't affect anything else.
> >
> > So I don't understand how anything could work before this commit and
>
On Tue, 2 Sep 2014, Paul E. McKenney wrote:
> Before this commit, raw_cpu_add_return() didn't build. The commit
> didn't affect anything else.
>
> So I don't understand how anything could work before this commit and
> be broken after it. Enlightenment?
Where is that raw_cpu_add_return
On Tue, 2 Sep 2014, Paul E. McKenney wrote:
Before this commit, raw_cpu_add_return() didn't build. The commit
didn't affect anything else.
So I don't understand how anything could work before this commit and
be broken after it. Enlightenment?
Where is that raw_cpu_add_return statement?
On Tue, Sep 02, 2014 at 11:00:12AM -0500, Christoph Lameter wrote:
On Tue, 2 Sep 2014, Paul E. McKenney wrote:
Before this commit, raw_cpu_add_return() didn't build. The commit
didn't affect anything else.
So I don't understand how anything could work before this commit and
be broken
On Tue, 2 Sep 2014, Paul E. McKenney wrote:
Added by ac1bea85781e (sched,rcu: Make cond_resched() report RCU quiescent
states), removed by 4a81e8328d379 (rcu: Reduce overhead of cond_resched()
checks for RCU). So, as you say, no effect on contemporary kernels.
Well not sure what to make out
On Tue, Sep 02, 2014 at 11:55:58AM -0500, Christoph Lameter wrote:
On Tue, 2 Sep 2014, Paul E. McKenney wrote:
Added by ac1bea85781e (sched,rcu: Make cond_resched() report RCU quiescent
states), removed by 4a81e8328d379 (rcu: Reduce overhead of cond_resched()
checks for RCU). So, as you
: [ 17.746702] ---[ end trace 6f2e0c38c2108a74
]---
Sep 1 18:46:11 n22kvm kernel: [ 17.746823] BUG: unable to handle kernel NULL
pointer dereference at 0038
Sep 1 18:46:11 n22kvm kernel: [ 17.747798] IP: []
cgroup_put+0x9/0x80
Sep 1 18:46:11 n22kvm kernel: [ 17.747798] *pde =
Sep
: [ 17.746692] [c114934d] SyS_write+0x4d/0xa0
Sep 1 18:46:11 n22kvm kernel: [ 17.746699] [c16f656b]
sysenter_do_call+0x12/0x12
Sep 1 18:46:11 n22kvm kernel: [ 17.746702] ---[ end trace 6f2e0c38c2108a74
]---
Sep 1 18:46:11 n22kvm kernel: [ 17.746823] BUG: unable to handle kernel NULL
pointer
> [ 2.779708] BIOS EDD facility v0.16 2004-Jun-25, 0 devices found
> [2.780171] EDD information not available.
> [2.780575] BUG: unable to handle kernel NULL pointer dereference at
> 0038
> [2.781133] IP: [] kernfs_find_ns+0xd/0xe4
> [2.781518] *pde =
found
[2.780171] EDD information not available.
[2.780575] BUG: unable to handle kernel NULL pointer dereference at
0038
[2.781133] IP: [b10e6578] kernfs_find_ns+0xd/0xe4
[2.781518] *pde =
[2.781747] Oops: [#1] PREEMPT
[2.782037] Modules linked
--++
>
> [ 12.405859] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
> [ 12.406471] ohci-pci: OHCI PCI platform driver
> [ 12.406906] ohci-platform: OHCI generic platform driver
> [ 12.407510] BUG: unable to handle kernel NULL pointer dereference at
] ohci-pci: OHCI PCI platform driver
[ 12.406906] ohci-platform: OHCI generic platform driver
[ 12.407510] BUG: unable to handle kernel NULL pointer dereference at
(null)
[ 12.408218] IP: [81968843] setup_test_skip64+0x183/0x270
[ 12.408781] PGD 0
[ 12.409010] Oops
9.185399] aer :00:02.0:pcie02: service driver aer loaded
[9.191430] aer :00:03.0:pcie02: service driver aer loaded
[9.197460] aer :00:04.0:pcie02: service driver aer loaded
[9.203486] BUG: unable to handle kernel NULL pointer dereference at
(null)
[9.
:00:02.0:pcie02: service driver aer loaded
[9.191430] aer :00:03.0:pcie02: service driver aer loaded
[9.197460] aer :00:04.0:pcie02: service driver aer loaded
[9.203486] BUG: unable to handle kernel NULL pointer dereference at
(null)
[9.211673] IP
On Sat, Aug 16, 2014 at 07:08:51AM +0100, Fengguang Wu wrote:
> Greetings,
>
> 0day kernel testing robot got the below dmesg and the first bad commit is
>
> git://git.linaro.org/people/cdall/linux-kvm-arm apm_linux_v3.16-rc1
> commit 6f99bc949b1c90ff342a7d44ac4122322a7ccb78
> Author: Liviu
On Sat, Aug 16, 2014 at 07:08:51AM +0100, Fengguang Wu wrote:
Greetings,
0day kernel testing robot got the below dmesg and the first bad commit is
git://git.linaro.org/people/cdall/linux-kvm-arm apm_linux_v3.16-rc1
commit 6f99bc949b1c90ff342a7d44ac4122322a7ccb78
Author: Liviu Dudau
at is the host CPU?
> >> >
> >> > The host CPU is E5-2680, Sandy Bridge-EP.
> >> >
> >> I thought this problem had already be mentioned a while back.
> >>
> >> See https://lkml.org/lkml/2014/3/6/685
> >> And https://lkml.org/l
e back.
>>
>> See https://lkml.org/lkml/2014/3/6/685
>> And https://lkml.org/lkml/2014/4/23/512
>>
>> So what you are telling here is that those two fixes never made it or
>> that you are
>> running an older kernel.
>
> I just checked linux-next and find t
checked linux-next and find that the bug in rapl_pmu_init() has
been fixed. linux-next happen to have the same BUG: unable to handle
kernel NULL pointer dereference message but at another function
validate_chain().. Attached is the dmesg in linux-next.
Sorry for the noise!
Is it fixed
here is that those two fixes never made it or
that you are
running an older kernel.
I just checked linux-next and find that the bug in rapl_pmu_init() has
been fixed. linux-next happen to have the same BUG: unable to handle
kernel NULL pointer dereference message but at another function
fixes never made it or
> that you are
> running an older kernel.
I just checked linux-next and find that the bug in rapl_pmu_init() has
been fixed. linux-next happen to have the same "BUG: unable to handle
kernel NULL pointer dereference" message but at another function
validate_chain
e= | 0 |
>> > 132| 2 |
>> > | backtrace:rapl_pmu_init | 0 |
>> > 132| |
>> > | backtrace:kernel_init_freeable| 0 |
>> > 132| 2 |
>> > | B
On Wed, Jul 30, 2014 at 08:39:33PM +0800, Fengguang Wu wrote:
> It's from this git tree:
>
> git://people.freedesktop.org/~dvdhrm/linux fops
David, please make sure things touching VFS code go through
linux-fsdevel and the proper trees. In the current form this gets a
strong NAK.
--
To
On Wed, Jul 30, 2014 at 04:14:20AM -0700, Christoph Hellwig wrote:
> On Wed, Jul 30, 2014 at 12:12:35PM +0800, Fengguang Wu wrote:
> > Greetings,
> >
> > 0day kernel testing robot got the below dmesg and the first bad commit is
>
> Where is this coming from? Bloating struct file for device
On Wed, Jul 30, 2014 at 12:12:35PM +0800, Fengguang Wu wrote:
> Greetings,
>
> 0day kernel testing robot got the below dmesg and the first bad commit is
Where is this coming from? Bloating struct file for device specific
stuff really isn't acceptable anyway.
--
To unsubscribe from this list:
On Wed, Jul 30, 2014 at 12:12:35PM +0800, Fengguang Wu wrote:
Greetings,
0day kernel testing robot got the below dmesg and the first bad commit is
Where is this coming from? Bloating struct file for device specific
stuff really isn't acceptable anyway.
--
To unsubscribe from this list: send
On Wed, Jul 30, 2014 at 04:14:20AM -0700, Christoph Hellwig wrote:
On Wed, Jul 30, 2014 at 12:12:35PM +0800, Fengguang Wu wrote:
Greetings,
0day kernel testing robot got the below dmesg and the first bad commit is
Where is this coming from? Bloating struct file for device specific
On Wed, Jul 30, 2014 at 08:39:33PM +0800, Fengguang Wu wrote:
It's from this git tree:
git://people.freedesktop.org/~dvdhrm/linux fops
David, please make sure things touching VFS code go through
linux-fsdevel and the proper trees. In the current form this gets a
strong NAK.
--
To unsubscribe
] Unpacking initramfs...
[0.732188] Freeing initrd memory: 3276K (d3cbd000 - d3ff)
[0.733895] BUG: unable to handle kernel NULL pointer dereference at
0028
[0.735603] IP: [c09b20cb] rapl_pmu_init+0x11e/0x139
[0.736012] *pdpt = *pde = f000ff53f000ff53
-next happen to have the same BUG: unable to handle
kernel NULL pointer dereference message but at another function
validate_chain().. Attached is the dmesg in linux-next.
Sorry for the noise!
Thanks,
Fengguang
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
commit
e_chain | 0 |
> > 0 | 2 |
> > | backtrace:free_reserved_area | 0 |
> > 0 | 2 |
> > | backtrace:free_init_pages | 0
late_rootfs | 0 | 0
> | 2 |
> +-------+++---+
>
> [0.613305] PCI: CLS 0 bytes, default 64
> [0.614699] Unpacking initramfs...
&g
] Unpacking initramfs...
[0.732188] Freeing initrd memory: 3276K (d3cbd000 - d3ff)
[0.733895] BUG: unable to handle kernel NULL pointer dereference at
0028
[0.735603] IP: [c09b20cb] rapl_pmu_init+0x11e/0x139
[0.736012] *pdpt = *pde = f000ff53f000ff53
] Freeing initrd memory: 3276K (d3cbd000 - d3ff)
[0.733895] BUG: unable to handle kernel NULL pointer dereference at
0028
[0.735603] IP: [c09b20cb] rapl_pmu_init+0x11e/0x139
[0.736012] *pdpt = *pde = f000ff53f000ff53
[0.736012] Oops: [#1
On 07/14/2014 02:53 PM, Kees Cook wrote:
> Hi,
>
> On Sat, Jul 5, 2014 at 7:23 PM, Fengguang Wu wrote:
>> Hi Kees,
>>
>> This bug is a bit old (and not very reproducible), however it's still
>> showing up in the upstream and linux-next trees.
>
> I'm still unable to reproduce this. It feels
Hi,
On Sat, Jul 5, 2014 at 7:23 PM, Fengguang Wu wrote:
> Hi Kees,
>
> This bug is a bit old (and not very reproducible), however it's still
> showing up in the upstream and linux-next trees.
I'm still unable to reproduce this. It feels like it's something
specific to the qemu loader, maybe?
Hi,
On Sat, Jul 5, 2014 at 7:23 PM, Fengguang Wu fengguang...@intel.com wrote:
Hi Kees,
This bug is a bit old (and not very reproducible), however it's still
showing up in the upstream and linux-next trees.
I'm still unable to reproduce this. It feels like it's something
specific to the qemu
On 07/14/2014 02:53 PM, Kees Cook wrote:
Hi,
On Sat, Jul 5, 2014 at 7:23 PM, Fengguang Wu fengguang...@intel.com wrote:
Hi Kees,
This bug is a bit old (and not very reproducible), however it's still
showing up in the upstream and linux-next trees.
I'm still unable to reproduce this. It
031] sda: unknown partition table
> [ 1010.598052] sd 2:0:0:0: [sda] Attached SCSI disk
> [ 1012.893125] sd 2:0:0:0: [sda] Synchronizing SCSI cache
> [ 1012.895934] BUG: unable to handle kernel NULL pointer dereference at
> 0028
> [ 1012.896336] IP: [] blk_throtl_drain+0x30/
table
[ 1010.598052] sd 2:0:0:0: [sda] Attached SCSI disk
[ 1012.893125] sd 2:0:0:0: [sda] Synchronizing SCSI cache
[ 1012.895934] BUG: unable to handle kernel NULL pointer dereference at
0028
[ 1012.896336] IP: [813cf880] blk_throtl_drain+0x30/0x150
I tried to revert my patch
Hi,
On 07/08/2014 10:59 AM, Aaron Lu wrote:
>
> [ 1010.593031] sda: unknown partition table
> [ 1010.598052] sd 2:0:0:0: [sda] Attached SCSI disk
> [ 1012.893125] sd 2:0:0:0: [sda] Synchronizing SCSI cache
> [ 1012.895934] BUG: unable to handle kernel NULL poin
Hi,
On 07/08/2014 10:59 AM, Aaron Lu wrote:
[ 1010.593031] sda: unknown partition table
[ 1010.598052] sd 2:0:0:0: [sda] Attached SCSI disk
[ 1012.893125] sd 2:0:0:0: [sda] Synchronizing SCSI cache
[ 1012.895934] BUG: unable to handle kernel NULL pointer dereference at
0028
4-fs (dm-0): mounted filesystem with ordered data mode. Opts:
acl,user_xattr
[ 522.368967] EXT4-fs (dm-0): recovery complete
[ 522.415305] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts:
acl,user_xattr
[ 523.030685] BUG: unable to handle kernel NULL pointer dereference at
00
): mounted filesystem with ordered data mode. Opts:
acl,user_xattr
[ 522.368967] EXT4-fs (dm-0): recovery complete
[ 522.415305] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts:
acl,user_xattr
[ 523.030685] BUG: unable to handle kernel NULL pointer dereference at
0028
| 5
|
+--+++
[ 5703.793032] sda: unknown partition table
[ 5703.798102] sd 2:0:0:0: [sda] Attached SCSI disk
[ 5706.076059] sd 2:0:0:0: [sda] Synchronizing SCSI cache
[ 5706.078586] BUG: unable to handle kernel NULL pointer d
|
+--+++
[ 5703.793032] sda: unknown partition table
[ 5703.798102] sd 2:0:0:0: [sda] Attached SCSI disk
[ 5706.076059] sd 2:0:0:0: [sda] Synchronizing SCSI cache
[ 5706.078586] BUG: unable to handle kernel NULL pointer dereference
On Tue, Jun 24, 2014 at 12:01:22PM +0800, Jet Chen wrote:
> Hi Tejun,
>
> we noticed the below changes on
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tj/misc.git review-mq-percpu_ref
> commit c924ec35e72ce0d6c289b858d323f7eb3f5076a5 ("block, blk-mq: draining
> can't be skipped even if
On Tue, Jun 24, 2014 at 12:01:22PM +0800, Jet Chen wrote:
Hi Tejun,
we noticed the below changes on
git://git.kernel.org/pub/scm/linux/kernel/git/tj/misc.git review-mq-percpu_ref
commit c924ec35e72ce0d6c289b858d323f7eb3f5076a5 (block, blk-mq: draining
can't be skipped even if
|
> 0 | 20 |
> | backtrace:kernel_init_freeable |
> 0 | 20 |
> ++++
>
>
> [0.180030]prefetch64-sse: 137.000 MB/sec
> [0.220055]generic_sse: 132.000 MB/sec
>
|
++++
[0.180030]prefetch64-sse: 137.000 MB/sec
[0.220055]generic_sse: 132.000 MB/sec
[0.220691] xor: using function: prefetch64-sse (137.000 MB/sec)
[0.222565] BUG: unable to handle kernel NULL pointer dereference
at (null
Hello,
On Wed, 11 Jun 2014, Jet Chen wrote:
> On 06/11/2014 01:59 PM, Julian Anastasov wrote:
> >
> > At first look, it is strange but I think the reason
> > is the missing CONFIG_SYSCTL. ip_vs_control_net_cleanup
> > fails at ip_vs_stop_estimator(net, >tot_stats)
> > because it is
Hello,
On Thu, 12 Jun 2014, Simon Horman wrote:
> Thanks, Julian, should I take this one?
> I'm assuming this problem has been present for quite a number of releases.
I'll post new version with extended comments.
Regards
--
Julian Anastasov
--
To unsubscribe from this list:
Hello,
On Thu, 12 Jun 2014, Simon Horman wrote:
Thanks, Julian, should I take this one?
I'm assuming this problem has been present for quite a number of releases.
I'll post new version with extended comments.
Regards
--
Julian Anastasov j...@ssi.bg
--
To unsubscribe from
Hello,
On Wed, 11 Jun 2014, Jet Chen wrote:
On 06/11/2014 01:59 PM, Julian Anastasov wrote:
At first look, it is strange but I think the reason
is the missing CONFIG_SYSCTL. ip_vs_control_net_cleanup
fails at ip_vs_stop_estimator(net, ipvs-tot_stats)
because it is called
up_net | 4 |
> >> +---++
> >>
> >>
> >> [child0:2725] process_vm_readv (347) returned ENOSYS, marking as inactive.
> >> [child0:2725] uid changed! Was: 0, now -
[child0:2725] process_vm_readv (347) returned ENOSYS, marking as inactive.
>> [child0:2725] uid changed! Was: 0, now -788547075
>> Bailing main loop. Exit reason: UID changed.
>> [ 12.182233] BUG: unable to handle kernel NULL pointer dereference at
>> 00
47075
> Bailing main loop. Exit reason: UID changed.
> [ 12.182233] BUG: unable to handle kernel NULL pointer dereference at
> 0004
> [ 12.183011] IP: [<4c2f6567>] ip_vs_stop_estimator+0x20/0x3e
> [ 12.183011] *pdpt = *pde = f000ff53f000ff53 [
>
: unable to handle kernel NULL pointer dereference at
0004
[ 12.183011] IP: [4c2f6567] ip_vs_stop_estimator+0x20/0x3e
[ 12.183011] *pdpt = *pde = f000ff53f000ff53 [
12.183011] Oops: 0002 [#1] DEBUG_PAGEALLOC
[ 12.183011] Modules linked in:
[ 12.183011] CPU: 0 PID: 57
reason: UID changed.
[ 12.182233] BUG: unable to handle kernel NULL pointer dereference at
0004
[ 12.183011] IP: [4c2f6567] ip_vs_stop_estimator+0x20/0x3e
[ 12.183011] *pdpt = *pde = f000ff53f000ff53 [
12.183011] Oops: 0002 [#1] DEBUG_PAGEALLOC
[ 12.183011
as inactive.
[child0:2725] uid changed! Was: 0, now -788547075
Bailing main loop. Exit reason: UID changed.
[ 12.182233] BUG: unable to handle kernel NULL pointer dereference at
0004
[ 12.183011] IP: [4c2f6567] ip_vs_stop_estimator+0x20/0x3e
[ 12.183011] *pdpt = *pde
On 05/13/2014 09:43 AM, Marc Kleine-Budde wrote:
> On 05/13/2014 07:14 AM, Oliver Hartkopp wrote:
>> Hello Jet,
>>
>> this is likely not CAN related, as
>>
>> # CONFIG_CAN is not set
>>
>> and all the CAN changes introduced by Marc's merge are not even compiled in
>> your setup.
>>
>> So I assume
On 05/13/2014 07:14 AM, Oliver Hartkopp wrote:
> Hello Jet,
>
> this is likely not CAN related, as
>
> # CONFIG_CAN is not set
>
> and all the CAN changes introduced by Marc's merge are not even compiled in
> your setup.
>
> So I assume the issue somewhere in the netlink or ipv6 stuff (see
On 05/13/2014 07:14 AM, Oliver Hartkopp wrote:
Hello Jet,
this is likely not CAN related, as
# CONFIG_CAN is not set
and all the CAN changes introduced by Marc's merge are not even compiled in
your setup.
So I assume the issue somewhere in the netlink or ipv6 stuff (see commit at
On 05/13/2014 09:43 AM, Marc Kleine-Budde wrote:
On 05/13/2014 07:14 AM, Oliver Hartkopp wrote:
Hello Jet,
this is likely not CAN related, as
# CONFIG_CAN is not set
and all the CAN changes introduced by Marc's merge are not even compiled in
your setup.
So I assume the issue somewhere
Hello Jet,
this is likely not CAN related, as
# CONFIG_CAN is not set
and all the CAN changes introduced by Marc's merge are not even compiled in
your setup.
So I assume the issue somewhere in the netlink or ipv6 stuff (see commit at
the end.
Best regards,
Oliver
On 13.05.2014 04:52, Jet
Hello Jet,
this is likely not CAN related, as
# CONFIG_CAN is not set
and all the CAN changes introduced by Marc's merge are not even compiled in
your setup.
So I assume the issue somewhere in the netlink or ipv6 stuff (see commit at
the end.
Best regards,
Oliver
On 13.05.2014 04:52, Jet
On 04/28/2014 07:34 PM, Paolo Bonzini wrote:
> Il 28/04/2014 11:54, Jet Chen ha scritto:
>> We noticed the below kernel BUG on
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
What commit?
>> This one,
>>
>>
Il 28/04/2014 11:54, Jet Chen ha scritto:
>> We noticed the below kernel BUG on
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
>
> What commit?
>
This one,
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
commit
On 04/28/2014 05:33 PM, Paolo Bonzini wrote:
> Il 14/04/2014 09:49, Jet Chen ha scritto:
>> Hi Paolo,
>>
>> We noticed the below kernel BUG on
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
>
> What commit?
>
This one,
Il 14/04/2014 09:49, Jet Chen ha scritto:
Hi Paolo,
We noticed the below kernel BUG on
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
What commit?
Paolo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Il 14/04/2014 09:49, Jet Chen ha scritto:
Hi Paolo,
We noticed the below kernel BUG on
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
What commit?
Paolo
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to
On 04/28/2014 05:33 PM, Paolo Bonzini wrote:
Il 14/04/2014 09:49, Jet Chen ha scritto:
Hi Paolo,
We noticed the below kernel BUG on
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
What commit?
This one,
Il 28/04/2014 11:54, Jet Chen ha scritto:
We noticed the below kernel BUG on
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
What commit?
This one,
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
commit
901 - 1000 of 1433 matches
Mail list logo
