On Tue, 2014-04-29 at 23:07 +0200, Jan Kara wrote:
> On Tue 29-04-14 11:38:04, Andy Shevchenko wrote:
> > On Mon, 2014-04-28 at 21:24 +0200, Jan Kara wrote:
> > > On Mon 28-04-14 14:14:39, Steven Rostedt wrote:
> > > > On Mon, 28 Apr 2014 19:51:39 +0200
> > > > Jan Kara wrote:
> > > >
> > > > >
On Tue, 2014-04-29 at 23:07 +0200, Jan Kara wrote:
On Tue 29-04-14 11:38:04, Andy Shevchenko wrote:
On Mon, 2014-04-28 at 21:24 +0200, Jan Kara wrote:
On Mon 28-04-14 14:14:39, Steven Rostedt wrote:
On Mon, 28 Apr 2014 19:51:39 +0200
Jan Kara j...@suse.cz wrote:
On Mon
On Tue 29-04-14 11:38:04, Andy Shevchenko wrote:
> On Mon, 2014-04-28 at 21:24 +0200, Jan Kara wrote:
> > On Mon 28-04-14 14:14:39, Steven Rostedt wrote:
> > > On Mon, 28 Apr 2014 19:51:39 +0200
> > > Jan Kara wrote:
> > >
> > > > On Mon 28-04-14 13:43:31, Steven Rostedt wrote:
> > > > > Things
On Mon, 28 Apr 2014 19:51:39 +0200
Jan Kara wrote:
> On Mon 28-04-14 13:43:31, Steven Rostedt wrote:
> > Things have changed with regard to printk() in linux-next. Now it
> > appears that lockdep is going haywire over it. I don't understand the
> > exact reason for the lockdep_off() and
Peter,
Things have changed with regard to printk() in linux-next. Now it
appears that lockdep is going haywire over it. I don't understand the
exact reason for the lockdep_off() and lockdep_on() logic that is in
printk(), but it obviously seems to be causing issues with the new
changes.
Care to
On Mon, 2014-04-28 at 21:24 +0200, Jan Kara wrote:
> On Mon 28-04-14 14:14:39, Steven Rostedt wrote:
> > On Mon, 28 Apr 2014 19:51:39 +0200
> > Jan Kara wrote:
> >
> > > On Mon 28-04-14 13:43:31, Steven Rostedt wrote:
> > > > Things have changed with regard to printk() in linux-next. Now it
> >
On Mon, 2014-04-28 at 21:24 +0200, Jan Kara wrote:
On Mon 28-04-14 14:14:39, Steven Rostedt wrote:
On Mon, 28 Apr 2014 19:51:39 +0200
Jan Kara j...@suse.cz wrote:
On Mon 28-04-14 13:43:31, Steven Rostedt wrote:
Things have changed with regard to printk() in linux-next. Now it
Peter,
Things have changed with regard to printk() in linux-next. Now it
appears that lockdep is going haywire over it. I don't understand the
exact reason for the lockdep_off() and lockdep_on() logic that is in
printk(), but it obviously seems to be causing issues with the new
changes.
Care to
On Mon, 28 Apr 2014 19:51:39 +0200
Jan Kara j...@suse.cz wrote:
On Mon 28-04-14 13:43:31, Steven Rostedt wrote:
Things have changed with regard to printk() in linux-next. Now it
appears that lockdep is going haywire over it. I don't understand the
exact reason for the lockdep_off() and
On Tue 29-04-14 11:38:04, Andy Shevchenko wrote:
On Mon, 2014-04-28 at 21:24 +0200, Jan Kara wrote:
On Mon 28-04-14 14:14:39, Steven Rostedt wrote:
On Mon, 28 Apr 2014 19:51:39 +0200
Jan Kara j...@suse.cz wrote:
On Mon 28-04-14 13:43:31, Steven Rostedt wrote:
Things have
On Mon 28-04-14 15:36:42, Steven Rostedt wrote:
> On Mon, 28 Apr 2014 21:24:16 +0200
> Jan Kara wrote:
>
>
> > So I had a look and we are missing mutex_release() in
> > console_trylock_for_printk() if we don't have a console to print to.
> > Attached patch should fix the problem.
> >
>
>
On Mon 28-04-14 13:43:31, Steven Rostedt wrote:
> Things have changed with regard to printk() in linux-next. Now it
> appears that lockdep is going haywire over it. I don't understand the
> exact reason for the lockdep_off() and lockdep_on() logic that is in
> printk(), but it obviously seems to
On Mon, 28 Apr 2014 21:24:16 +0200
Jan Kara wrote:
> So I had a look and we are missing mutex_release() in
> console_trylock_for_printk() if we don't have a console to print to.
> Attached patch should fix the problem.
>
Note, your patch changes the logic a bit. It causes the
On Mon, Apr 28, 2014 at 01:43:31PM -0400, Steven Rostedt wrote:
>
> Peter,
>
> Things have changed with regard to printk() in linux-next. Now it
> appears that lockdep is going haywire over it. I don't understand the
> exact reason for the lockdep_off() and lockdep_on() logic that is in
>
On Mon 28-04-14 14:14:39, Steven Rostedt wrote:
> On Mon, 28 Apr 2014 19:51:39 +0200
> Jan Kara wrote:
>
> > On Mon 28-04-14 13:43:31, Steven Rostedt wrote:
> > > Things have changed with regard to printk() in linux-next. Now it
> > > appears that lockdep is going haywire over it. I don't
Hei!
During weekend the linux-next was being broken by introducing a lockdep
warning in the console code
[0.00] BIOS-e820: [mem 0xe000-0x]
reserved
[0.00]
[0.00] =
[0.00] [ INFO: possible
Hei!
During weekend the linux-next was being broken by introducing a lockdep
warning in the console code
[0.00] BIOS-e820: [mem 0xe000-0x]
reserved
[0.00]
[0.00] =
[0.00] [ INFO: possible
On Mon 28-04-14 14:14:39, Steven Rostedt wrote:
On Mon, 28 Apr 2014 19:51:39 +0200
Jan Kara j...@suse.cz wrote:
On Mon 28-04-14 13:43:31, Steven Rostedt wrote:
Things have changed with regard to printk() in linux-next. Now it
appears that lockdep is going haywire over it. I don't
On Mon, Apr 28, 2014 at 01:43:31PM -0400, Steven Rostedt wrote:
Peter,
Things have changed with regard to printk() in linux-next. Now it
appears that lockdep is going haywire over it. I don't understand the
exact reason for the lockdep_off() and lockdep_on() logic that is in
printk(), but
On Mon, 28 Apr 2014 21:24:16 +0200
Jan Kara j...@suse.cz wrote:
So I had a look and we are missing mutex_release() in
console_trylock_for_printk() if we don't have a console to print to.
Attached patch should fix the problem.
Note, your patch changes the logic a bit. It causes the
On Mon 28-04-14 13:43:31, Steven Rostedt wrote:
Things have changed with regard to printk() in linux-next. Now it
appears that lockdep is going haywire over it. I don't understand the
exact reason for the lockdep_off() and lockdep_on() logic that is in
printk(), but it obviously seems to be
On Mon 28-04-14 15:36:42, Steven Rostedt wrote:
On Mon, 28 Apr 2014 21:24:16 +0200
Jan Kara j...@suse.cz wrote:
So I had a look and we are missing mutex_release() in
console_trylock_for_printk() if we don't have a console to print to.
Attached patch should fix the problem.
22 matches
Mail list logo
