Hello, sorry for the delay.
2014-10-29, 20:36:03 +0100, Peter Zijlstra wrote:
> On Wed, Oct 29, 2014 at 07:33:00PM +0100, Thomas Gleixner wrote:
> > Yuck. No. You are just papering over the problem.
> >
> > What happens if you add 'threadirqs' to the kernel command line? Or if
> > the interrupt
Hello, sorry for the delay.
2014-10-29, 20:36:03 +0100, Peter Zijlstra wrote:
On Wed, Oct 29, 2014 at 07:33:00PM +0100, Thomas Gleixner wrote:
Yuck. No. You are just papering over the problem.
What happens if you add 'threadirqs' to the kernel command line? Or if
the interrupt line is
Hello,
[adding Jeremiah Mahler to CC]
2014-11-27, 14:53:47 +1100, Stephen Rothwell wrote:
> Hi Jens,
>
> Today's linux-next merge of the block tree got a conflict in
> fs/fs-writeback.c between commit ef7fdf5e8c87 ("vfs: add support for a
> lazytime mount option") from the ext4 tree and commit
Hello,
[adding Jeremiah Mahler to CC]
2014-11-27, 14:53:47 +1100, Stephen Rothwell wrote:
Hi Jens,
Today's linux-next merge of the block tree got a conflict in
fs/fs-writeback.c between commit ef7fdf5e8c87 (vfs: add support for a
lazytime mount option) from the ext4 tree and commit
commit e22b886a8a43b ("sched/wait: Add might_sleep() checks") included
in today's linux-next added a check that fires on e1000 with netpoll:
BUG: sleeping function called from invalid context at kernel/irq/manage.c:104
in_atomic(): 1, irqs_disabled(): 1, pid: 1, name: systemd
no locks held by
commit e22b886a8a43b (sched/wait: Add might_sleep() checks) included
in today's linux-next added a check that fires on e1000 with netpoll:
BUG: sleeping function called from invalid context at kernel/irq/manage.c:104
in_atomic(): 1, irqs_disabled(): 1, pid: 1, name: systemd
no locks held by
Hello,
2014-08-24, 23:56:03 +0900, Akinobu Mita wrote:
> Replace memblock_find_in_range() and memblock_reserve() with
> memblock_alloc_range().
>
> Signed-off-by: Akinobu Mita
> Cc: linux...@kvack.org
This patch is included in linux-next, and when I boot next-20140901,
on a 32-bit build, I get
(), ipv6_sock_mc_drop(), ipv6_sock_mc_close() before
calling ipv6_dev_mc_inc/dec.
This patch moves ASSERT_RTNL() up a level in the call stack.
Signed-off-by: Cong Wang
Signed-off-by: Sabrina Dubroca
Reported-by: Tommi Rantala
---
As was said earlier, this should go in stable.
v2:
- based on net
- keep
(), ipv6_sock_mc_drop(), ipv6_sock_mc_close() before
calling ipv6_dev_mc_inc/dec.
This patch moves ASSERT_RTNL() up a level in the call stack.
Signed-off-by: Cong Wang xiyou.wangc...@gmail.com
Signed-off-by: Sabrina Dubroca s...@queasysnail.net
Reported-by: Tommi Rantala tt.rant...@gmail.com
---
As was said
Hello,
2014-08-24, 23:56:03 +0900, Akinobu Mita wrote:
Replace memblock_find_in_range() and memblock_reserve() with
memblock_alloc_range().
Signed-off-by: Akinobu Mita akinobu.m...@gmail.com
Cc: linux...@kvack.org
This patch is included in linux-next, and when I boot next-20140901,
on a
(), ipv6_sock_mc_drop(), ipv6_sock_mc_close() before
calling ipv6_dev_mc_inc/dec.
This patch moves ASSERT_RTNL() up a level in the call stack.
Signed-off-by: Cong Wang
Signed-off-by: Sabrina Dubroca
Reported-by: Tommi Rantala
---
I included Cong's Signed-off-by for the first part of the patch,
I hope
(), ipv6_sock_mc_drop(), ipv6_sock_mc_close() before
calling ipv6_dev_mc_inc/dec.
This patch moves ASSERT_RTNL() up a level in the call stack.
Signed-off-by: Cong Wang xiyou.wangc...@gmail.com
Signed-off-by: Sabrina Dubroca s...@queasysnail.net
Reported-by: Tommi Rantala tt.rant...@gmail.com
---
I included
2014-08-30, 12:58:21 +0200, Sabrina Dubroca wrote:
>- pndisc_constructor, called from pneigh_lookup -- pneigh_lookup
> has ASSERT_RTNL(), but pneigh_lookup is called from ip6_forward and
> ndisc_recv_na
Ah, these have creat = 0, so it's fine. I missed that earlie
Hello,
2014-08-30, 03:51:29 +0200, Hannes Frederic Sowa wrote:
> Hi Sabrina,
>
> [...]
>
> Sorry, just had time to look at this.
>
> The reason is not to have list corruption but that the calls down to
> ndo_set_rx_mode expect rtnl to be locked by the drivers. Filter lists
> are locked by
2014-08-29, 15:54:48 -0700, Cong Wang wrote:
> [...]
>
> You are absolutely right here.
>
> Can I have your Signed-off-by and Tested-by before sending the patch
> formally?
>
> Thanks!
Sure:
Signed-off-by: Sabrina Dubroca
Tested-by: Sabrina Dubroca
Thanks,
--
S
2014-08-29, 15:54:48 -0700, Cong Wang wrote:
[...]
You are absolutely right here.
Can I have your Signed-off-by and Tested-by before sending the patch
formally?
Thanks!
Sure:
Signed-off-by: Sabrina Dubroca s...@queasysnail.net
Tested-by: Sabrina Dubroca s...@queasysnail.net
Thanks
Hello,
2014-08-30, 03:51:29 +0200, Hannes Frederic Sowa wrote:
Hi Sabrina,
[...]
Sorry, just had time to look at this.
The reason is not to have list corruption but that the calls down to
ndo_set_rx_mode expect rtnl to be locked by the drivers. Filter lists
are locked by
2014-08-30, 12:58:21 +0200, Sabrina Dubroca wrote:
- pndisc_constructor, called from pneigh_lookup -- pneigh_lookup
has ASSERT_RTNL(), but pneigh_lookup is called from ip6_forward and
ndisc_recv_na
Ah, these have creat = 0, so it's fine. I missed that earlier.
Sorry for the noise
2014-08-29, 11:14:48 -0700, Cong Wang wrote:
> On Fri, Aug 29, 2014 at 8:26 AM, Tommi Rantala wrote:
> > [ 77.297196] RTNL: assertion failed at net/ipv6/addrconf.c (1699)
> > [ 77.298080] CPU: 0 PID: 4842 Comm: trinity-main Not tainted 3.17.0-rc2+
> > #30
> > [ 77.299039] Hardware name:
2014-08-29, 11:14:48 -0700, Cong Wang wrote:
On Fri, Aug 29, 2014 at 8:26 AM, Tommi Rantala tt.rant...@gmail.com wrote:
[ 77.297196] RTNL: assertion failed at net/ipv6/addrconf.c (1699)
[ 77.298080] CPU: 0 PID: 4842 Comm: trinity-main Not tainted 3.17.0-rc2+
#30
[ 77.299039]
Hello,
While fuzzing with trinity on next-20140827, I ran into this:
[ 2059.161014] BUG: sleeping function called from invalid context at
arch/x86/mm/fault.c:1177
[ 2059.162968] in_atomic(): 0, irqs_disabled(): 1, pid: 3225, name: trinity-c0
[ 2059.163142] INFO: lockdep is turned off.
[
Hello,
While fuzzing with trinity on next-20140827, I ran into this:
[ 2059.161014] BUG: sleeping function called from invalid context at
arch/x86/mm/fault.c:1177
[ 2059.162968] in_atomic(): 0, irqs_disabled(): 1, pid: 3225, name: trinity-c0
[ 2059.163142] INFO: lockdep is turned off.
[
2014-08-26, 22:02:08 +0200, Sabrina Dubroca wrote:
> [...]
>
> Tested-by: Sabrina Dubroca
Forgot to mention, this applies to both versions of the patch.
--
Sabrina
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord
but the same
> tree with this patch on top of it boots without warning. Soo...
>
> Tested-By: Valdis Kletnieks
Same for me.
Tested-by: Sabrina Dubroca
Thanks,
--
Sabrina
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to maj
ad address
APM_level = 128
Signed-off-by: Sabrina Dubroca
Fixes: 2cada584b200 ("block: cleanup error handling in sg_io")
---
block/scsi_ioctl.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/block/scsi_ioctl.c b/block/scsi_ioctl.c
index 5dd477bfb4bc..9b8eaeca6a79 100644
--- a/bloc
Hello,
Since next-20140823:
# hdparm -B 200 /dev/sda
/dev/sda:
setting Advanced Power Management level to 0xc8 (200)
HDIO_DRIVE_CMD failed: Bad address
APM_level = 128
It looks like before commit 2cada584b200 ("block: cleanup error
handling in sg_io"), we had ret = 0 before entering
Hello,
Since next-20140823:
# hdparm -B 200 /dev/sda
/dev/sda:
setting Advanced Power Management level to 0xc8 (200)
HDIO_DRIVE_CMD failed: Bad address
APM_level = 128
It looks like before commit 2cada584b200 (block: cleanup error
handling in sg_io), we had ret = 0 before entering
APM_level = 128
Signed-off-by: Sabrina Dubroca s...@queasysnail.net
Fixes: 2cada584b200 (block: cleanup error handling in sg_io)
---
block/scsi_ioctl.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/block/scsi_ioctl.c b/block/scsi_ioctl.c
index 5dd477bfb4bc..9b8eaeca6a79 100644
--- a/block
Kletnieks valdis.kletni...@vt.edu
Same for me.
Tested-by: Sabrina Dubroca s...@queasysnail.net
Thanks,
--
Sabrina
--
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
2014-08-26, 22:02:08 +0200, Sabrina Dubroca wrote:
[...]
Tested-by: Sabrina Dubroca s...@queasysnail.net
Forgot to mention, this applies to both versions of the patch.
--
Sabrina
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord
2014-08-19, 13:06:07 -0400, valdis.kletni...@vt.edu wrote:
> On Sat, 16 Aug 2014 20:27:01 -0700, Hugh Dickins said:
> > Can we safely revert your 8b37e1bef5a6 ("leds: convert blink timer to
> > workqueue"), or have there been other changes which now depend upon it?
>
> I suspect there's something
Hello,
2014-08-21, 18:08:09 +0200, Radim Krčmář wrote:
> Tracepoint for dynamic PLE window, fired on every potential change.
>
> Signed-off-by: Radim Krčmář
> ---
> arch/x86/kvm/trace.h | 30 ++
> arch/x86/kvm/vmx.c | 10 --
> arch/x86/kvm/x86.c | 1 +
>
Hello,
2014-08-21, 18:08:09 +0200, Radim Krčmář wrote:
Tracepoint for dynamic PLE window, fired on every potential change.
Signed-off-by: Radim Krčmář rkrc...@redhat.com
---
arch/x86/kvm/trace.h | 30 ++
arch/x86/kvm/vmx.c | 10 --
arch/x86/kvm/x86.c
2014-08-19, 13:06:07 -0400, valdis.kletni...@vt.edu wrote:
On Sat, 16 Aug 2014 20:27:01 -0700, Hugh Dickins said:
Can we safely revert your 8b37e1bef5a6 (leds: convert blink timer to
workqueue), or have there been other changes which now depend upon it?
I suspect there's something else
gt; [] bus_for_each_dev+0x47/0x80
> [] driver_attach+0x1e/0x20
> [] ? __device_attach+0x40/0x40
> [] bus_add_driver+0x157/0x230
> [] driver_register+0x59/0xe0
> ...
>
> Fix this by checking chip->dev pointer against NULL first. Also we can now
> remove redundant c
().
Reported-by: Sabrina Dubroca s...@queasysnail.net
Signed-off-by: Mika Westerberg mika.westerb...@linux.intel.com
---
Sabrina,
Can you please re-test this and provide your tested-by? I changed the patch
a bit to remove redundant checks. Just to be sure that I don't accidentally
break something
2014-03-25, 09:25:30 +0200, Mika Westerberg wrote:
> On Mon, Mar 24, 2014 at 07:31:11PM +0100, Sabrina Dubroca wrote:
> > > Actually gpiolib seems to handle ->dev as optional. Can you try this patch
> > > instead? Thanks.
> > >
> > > diff --git a/drivers/
2014-03-25, 09:25:30 +0200, Mika Westerberg wrote:
On Mon, Mar 24, 2014 at 07:31:11PM +0100, Sabrina Dubroca wrote:
Actually gpiolib seems to handle -dev as optional. Can you try this patch
instead? Thanks.
diff --git a/drivers/gpio/gpiolib-acpi.c b/drivers/gpio/gpiolib-acpi.c
2014-03-24, 20:11:12 +0200, Mika Westerberg wrote:
> On Mon, Mar 24, 2014 at 08:00:33PM +0200, Mika Westerberg wrote:
> > On Mon, Mar 24, 2014 at 04:49:44PM +0100, Sabrina Dubroca wrote:
> > > Hi,
> > >
> > > With next-20140324, I get the BUG below w
2014-03-24, 20:11:12 +0200, Mika Westerberg wrote:
On Mon, Mar 24, 2014 at 08:00:33PM +0200, Mika Westerberg wrote:
On Mon, Mar 24, 2014 at 04:49:44PM +0100, Sabrina Dubroca wrote:
Hi,
With next-20140324, I get the BUG below when I modprobe ssb.
I bisected it to aa92b6f689ac
Hi,
2014-03-18, 00:50:04 +, Zheng, Lv wrote:
> Hi, Sabrina and Valdis
>
> Could you give this patch a try to see if this patch is working?
>
> Thanks and best regards
> -Lv
I applied the two patches. The laptop boots and there is no ACPI
error in the logs, both with auto-serialization
Hi,
2014-03-18, 00:50:04 +, Zheng, Lv wrote:
Hi, Sabrina and Valdis
Could you give this patch a try to see if this patch is working?
Thanks and best regards
-Lv
I applied the two patches. The laptop boots and there is no ACPI
error in the logs, both with auto-serialization enabled
Hi,
2014-03-14, 12:05:01 -0400, Valdis Kletnieks wrote:
> Surprisingly enough, this hasn't seemed to have bitten many Linux people yet,
> Google only finds a BSD thread (where the same ACPICA code is in use):
>
> http://comments.gmane.org/gmane.os.dragonfly-bsd.user/1817
I was about to report
Hi,
2014-03-14, 12:05:01 -0400, Valdis Kletnieks wrote:
Surprisingly enough, this hasn't seemed to have bitten many Linux people yet,
Google only finds a BSD thread (where the same ACPICA code is in use):
http://comments.gmane.org/gmane.os.dragonfly-bsd.user/1817
I was about to report the
2014-02-05, 14:50:18 +1000, Dave Airlie wrote:
> On Wed, Feb 5, 2014 at 8:53 AM, Sabrina Dubroca wrote:
> > 2014-02-04, 13:20:54 +1000, Dave Airlie wrote:
> >> On Tue, Feb 4, 2014 at 1:34 AM, Sabrina Dubroca
> >> wrote:
> >> > When I boot 3.14-rc1 in q
2014-02-05, 14:50:18 +1000, Dave Airlie wrote:
On Wed, Feb 5, 2014 at 8:53 AM, Sabrina Dubroca s...@queasysnail.net wrote:
2014-02-04, 13:20:54 +1000, Dave Airlie wrote:
On Tue, Feb 4, 2014 at 1:34 AM, Sabrina Dubroca s...@queasysnail.net
wrote:
When I boot 3.14-rc1 in qemu, I get
2014-02-04, 13:20:54 +1000, Dave Airlie wrote:
> On Tue, Feb 4, 2014 at 1:34 AM, Sabrina Dubroca wrote:
> > When I boot 3.14-rc1 in qemu, I get the trace below. The console stops
> > updating and I don't get a login prompt. I can login, but I can't see
> > what I'm doing. I c
2014-02-04, 13:20:54 +1000, Dave Airlie wrote:
On Tue, Feb 4, 2014 at 1:34 AM, Sabrina Dubroca s...@queasysnail.net wrote:
When I boot 3.14-rc1 in qemu, I get the trace below. The console stops
updating and I don't get a login prompt. I can login, but I can't see
what I'm doing. I can login
] [] x86_64_start_reservations+0x2a/0x2c
[1.749470] [] x86_64_start_kernel+0x169/0x178
[1.749471] ---[ end trace d478ba7c30908d4d ]---
--
Sabrina Dubroca
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kerne
] [81ae296f] ? repair_env_string+0x5c/0x5c
[1.749469] [81ae25f6] x86_64_start_reservations+0x2a/0x2c
[1.749470] [81ae2761] x86_64_start_kernel+0x169/0x178
[1.749471] ---[ end trace d478ba7c30908d4d ]---
--
Sabrina Dubroca
--
To unsubscribe from this list: send
2014-01-18, 13:44:51 +0100, Peter Zijlstra wrote:
> On Sat, Jan 18, 2014 at 10:46:06AM +0100, Mike Galbraith wrote:
> >
> > I hope it doesn't look quite like that, next-20140117 is -ENOBOOT on
> > Q6600 box. See below for an alternative.
>
> Urgh, I see, we call the idle arch_cpu_idle()
2014-01-18, 13:44:51 +0100, Peter Zijlstra wrote:
On Sat, Jan 18, 2014 at 10:46:06AM +0100, Mike Galbraith wrote:
I hope it doesn't look quite like that, next-20140117 is -ENOBOOT on
Q6600 box. See below for an alternative.
Urgh, I see, we call the idle arch_cpu_idle() callback with
101 - 152 of 152 matches
Mail list logo