* Re: linux-next: ftrace tree build warnings
From: Steven Rostedt @ 2008-11-25 2:44 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, linux-next,
Alan Cox
In-Reply-To: <20081125133828.8f9b49df.sfr@canb.auug.org.au>
On Tue, 2008-11-25 at 13:38 +1100, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next build (x86_64 allmodconfig) produced lots of these
> warnings:
>
> include/linux/tty.h:330: warning: '______f' is static but declared in inline function 'tty_kref_get' which is not static
>
> Caused by commit 2bcd521a684cc94befbe2ce7d5b613c841b0d304 ("trace:
> profile all if conditionals"). Something needs to be done about
> this ... maybe tty_kref_get needs to be "static inline" instead of
> "extern inline"?
>
Is there a way to suppress this warning here? Since we are only
profiling, if it complies fine, then it should not be an issue.
Looking at the uses of this function, is there any reason that it is not
"static inline"?
-- Steve
^ permalink raw reply
* linux-next: ftrace tree build warnings
From: Stephen Rothwell @ 2008-11-25 2:38 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin
Cc: linux-next, Steven Rostedt, Alan Cox
[-- Attachment #1: Type: text/plain, Size: 549 bytes --]
Hi all,
Today's linux-next build (x86_64 allmodconfig) produced lots of these
warnings:
include/linux/tty.h:330: warning: '______f' is static but declared in inline function 'tty_kref_get' which is not static
Caused by commit 2bcd521a684cc94befbe2ce7d5b613c841b0d304 ("trace:
profile all if conditionals"). Something needs to be done about
this ... maybe tty_kref_get needs to be "static inline" instead of
"extern inline"?
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: next-20081119: general protection fault: get_next_timer_interrupt()
From: malahal @ 2008-11-25 2:08 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Thomas Gleixner, Mike Anderson, James Bottomley,
Alexander Beregalov, LKML, linux-next, Ingo Molnar, linux-scsi,
David Miller, Jens Axboe
In-Reply-To: <20081125115710.6c249f32.sfr@canb.auug.org.au>
Stephen Rothwell [sfr@canb.auug.org.au] wrote:
> > The block timer code calls del_timer(), should it call del_timer_sync()?
> > It is possible although unlikely that you are hitting del_timer_sync vs
> > del_timer problem in the block timeout code. Can only be seen on SMP
> > systems though!
>
> Is this still a problem in next-20081121? In that tree, the block commit
> "block: leave the request timeout timer running even on an empty list"
> was changed to add this:
>
> diff --git a/block/blk-core.c b/block/blk-core.c
> index 04267d6..44f547c 100644
> --- a/block/blk-core.c
> +++ b/block/blk-core.c
> @@ -391,6 +391,7 @@ EXPORT_SYMBOL(blk_stop_queue);
> void blk_sync_queue(struct request_queue *q)
> {
> del_timer_sync(&q->unplug_timer);
> + del_timer_sync(&q->timeout);
> kblockd_flush_work(&q->unplug_work);
> }
> EXPORT_SYMBOL(blk_sync_queue);
I was looking at the Linux tree. Clearly same problem doesn't exist with
the above commit! I wonder why kblockd_flush_work() is called after the
del_timer_sync(). It makes sense to cancel the work and then shutdown
the timer(s). I doubt if you are running into this problem though.
-Malahal.
^ permalink raw reply
* Re: userns tree ready
From: James Morris @ 2008-11-25 1:05 UTC (permalink / raw)
To: Serge E. Hallyn; +Cc: Stephen Rothwell, David Howells, linux-next
In-Reply-To: <20081125001651.GA10661@us.ibm.com>
On Mon, 24 Nov 2008, Serge E. Hallyn wrote:
> Hi Stephen,
>
> I've created a new userns tree - although the patches are completely
> unchanged from before they were pulled along with David's patches.
> They apply fine either right after James' security-next tree or at
> the end of linux-next. The tree is at
>
> git://git.kernel.org/pub/scm/linux/kernel/git/sergeh/userns-2.6#next
>
> like before, and is based on James's security-next tree.
I can merge this into my tree, although if it breaks, I'll need help from
you to fix it.
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* Re: linux-next: manual merge of the 4xx tree
From: Josh Boyer @ 2008-11-25 1:04 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, Grant Likely, paulus, ppc-dev, benh
In-Reply-To: <20081125115021.b4782240.sfr@canb.auug.org.au>
On Tue, 25 Nov 2008 11:50:21 +1100
Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Josh,
>
> Today's linux-next merge of the 4xx tree got a conflict in
> arch/powerpc/configs/ppc44x_defconfig between commit
> c8d698849e135780738c2cb08f07f06eda982a8c ("powerpc/virtex: Update
> defconfigs") from the powerpc-merge tree and commit
> 867b71f3da64eb917c23cfd8babcd1c4fc0ba7fd ("powerpc/44x: update
> ppc44x_defconfig") from the 4xx tree.
Sigh.
> I fixed it up (by setting CONFIG_GPIO_XILINX to y as is done in the
> former). I can carry this fix until either your tree is merged by Paul or
> you do a merge against the powerpc-merge tree (or Linus' tree after he
> takes Paul's tree).
I tend to rebase my next branch off of Paul's next branch, so if he
updates his tomorrow I can just do that and we will all be happy. If
that isn't done by my afternoon time, I'll fix it up myself. There's
no reason you should have to carry an extra patch. linux-next is hard
enough :)
josh
^ permalink raw reply
* Re: userns tree ready
From: Stephen Rothwell @ 2008-11-25 0:58 UTC (permalink / raw)
To: Serge E. Hallyn; +Cc: David Howells, linux-next
In-Reply-To: <20081125001651.GA10661@us.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 645 bytes --]
Hi Serge,
On Mon, 24 Nov 2008 18:16:51 -0600 "Serge E. Hallyn" <serue@us.ibm.com> wrote:
>
> I've created a new userns tree - although the patches are completely
> unchanged from before they were pulled along with David's patches.
> They apply fine either right after James' security-next tree or at
> the end of linux-next. The tree is at
>
> git://git.kernel.org/pub/scm/linux/kernel/git/sergeh/userns-2.6#next
>
> like before, and is based on James's security-next tree.
Thanks for that, I will merge it in today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: next-20081119: general protection fault: get_next_timer_interrupt()
From: Stephen Rothwell @ 2008-11-25 0:57 UTC (permalink / raw)
To: malahal
Cc: Thomas Gleixner, Mike Anderson, James Bottomley,
Alexander Beregalov, LKML, linux-next, Ingo Molnar, linux-scsi,
David Miller, Jens Axboe
In-Reply-To: <20081125000902.GA24251@us.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1786 bytes --]
On Mon, 24 Nov 2008 16:09:02 -0800 malahal@us.ibm.com wrote:
>
> Thomas Gleixner [tglx@linutronix.de] wrote:
> > On Mon, 24 Nov 2008, Mike Anderson wrote:
> > > Thomas Gleixner <tglx@linutronix.de> wrote:
> > > > Yeah, block could it be as well. Jens, Mike ?
> > >
> > > I added a comment to bug 12020 on Thursday about a few other systems that
> > > where seeing the signature shown in bug 12020. It appeared from debug that
> > > there where a few paths that where adding timers for requests that where
> > > not expected.
> > >
> > > http://bugzilla.kernel.org/show_bug.cgi?id=12020
> > >
> > > It would be good to know if the debug patch below effects your problem as while.
> > >
> > > If it does we need to investigated a solution to resolve not adding a
> > > timer for these requests.
>
> The block timer code calls del_timer(), should it call del_timer_sync()?
> It is possible although unlikely that you are hitting del_timer_sync vs
> del_timer problem in the block timeout code. Can only be seen on SMP
> systems though!
Is this still a problem in next-20081121? In that tree, the block commit
"block: leave the request timeout timer running even on an empty list"
was changed to add this:
diff --git a/block/blk-core.c b/block/blk-core.c
index 04267d6..44f547c 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -391,6 +391,7 @@ EXPORT_SYMBOL(blk_stop_queue);
void blk_sync_queue(struct request_queue *q)
{
del_timer_sync(&q->unplug_timer);
+ del_timer_sync(&q->timeout);
kblockd_flush_work(&q->unplug_work);
}
EXPORT_SYMBOL(blk_sync_queue);
After I spent some time bisecting a boot failure in PowerPC.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply related
* linux-next: manual merge of the 4xx tree
From: Stephen Rothwell @ 2008-11-25 0:50 UTC (permalink / raw)
To: Josh Boyer; +Cc: linux-next, Grant Likely, paulus, ppc-dev, benh
[-- Attachment #1: Type: text/plain, Size: 696 bytes --]
Hi Josh,
Today's linux-next merge of the 4xx tree got a conflict in
arch/powerpc/configs/ppc44x_defconfig between commit
c8d698849e135780738c2cb08f07f06eda982a8c ("powerpc/virtex: Update
defconfigs") from the powerpc-merge tree and commit
867b71f3da64eb917c23cfd8babcd1c4fc0ba7fd ("powerpc/44x: update
ppc44x_defconfig") from the 4xx tree.
I fixed it up (by setting CONFIG_GPIO_XILINX to y as is done in the
former). I can carry this fix until either your tree is merged by Paul or
you do a merge against the powerpc-merge tree (or Linus' tree after he
takes Paul's tree).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* userns tree ready
From: Serge E. Hallyn @ 2008-11-25 0:16 UTC (permalink / raw)
To: Stephen Rothwell, David Howells, linux-next
Hi Stephen,
I've created a new userns tree - although the patches are completely
unchanged from before they were pulled along with David's patches.
They apply fine either right after James' security-next tree or at
the end of linux-next. The tree is at
git://git.kernel.org/pub/scm/linux/kernel/git/sergeh/userns-2.6#next
like before, and is based on James's security-next tree.
thanks,
-serge
^ permalink raw reply
* Re: next-20081119: general protection fault: get_next_timer_interrupt()
From: malahal @ 2008-11-25 0:09 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Mike Anderson, James Bottomley, Alexander Beregalov, LKML,
linux-next, Ingo Molnar, linux-scsi, David Miller, Jens Axboe
In-Reply-To: <alpine.LFD.2.00.0811242327130.3235@localhost.localdomain>
Thomas Gleixner [tglx@linutronix.de] wrote:
> On Mon, 24 Nov 2008, Mike Anderson wrote:
> > Thomas Gleixner <tglx@linutronix.de> wrote:
> > > Yeah, block could it be as well. Jens, Mike ?
> >
> > I added a comment to bug 12020 on Thursday about a few other systems that
> > where seeing the signature shown in bug 12020. It appeared from debug that
> > there where a few paths that where adding timers for requests that where
> > not expected.
> >
> > http://bugzilla.kernel.org/show_bug.cgi?id=12020
> >
> > It would be good to know if the debug patch below effects your problem as while.
> >
> > If it does we need to investigated a solution to resolve not adding a
> > timer for these requests.
The block timer code calls del_timer(), should it call del_timer_sync()?
It is possible although unlikely that you are hitting del_timer_sync vs
del_timer problem in the block timeout code. Can only be seen on SMP
systems though!
--Malahal.
^ permalink raw reply
* Re: next-20081119: general protection fault: get_next_timer_interrupt()
From: malahal @ 2008-11-24 23:42 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Mike Anderson, James Bottomley, Alexander Beregalov, LKML,
linux-next, Ingo Molnar, linux-scsi, David Miller, Jens Axboe
In-Reply-To: <alpine.LFD.2.00.0811242327130.3235@localhost.localdomain>
Thomas Gleixner [tglx@linutronix.de] wrote:
> > where seeing the signature shown in bug 12020. It appeared from debug that
> > there where a few paths that where adding timers for requests that where
> > not expected.
> >
> > http://bugzilla.kernel.org/show_bug.cgi?id=12020
> >
> > It would be good to know if the debug patch below effects your problem as while.
> >
> > If it does we need to investigated a solution to resolve not adding a
> > timer for these requests.
>
> Wrong.
>
> The problem is not a timer which is armed in the first place.
No, this could be a problem if such a timer is not dis-armed! As fas as
I know, the queue timer will be dis-armed in end_that_request_last() if
needed. Do we know end_that_request_last() gets called for every request
queued?
> The problem is an armed timer which is not canceled before the data
> structure which contains it is freed.
>
> So not arming the timer will probably prevent this particular scan
> problem, but it does not solve the general wreckage of freeing a data
> structure with a possibly armed timer in it.
>
> You need to fix the code path which frees the data structure which
> contains the timer and cancel the timer _before_ freeing the data
> structure.
Agreed but the timer is armed when a request is sent and is dis-armed
when it is completed. Essentially there should NOT be any active
timer(s) when you try to free the request queue. In other words, the
code which frees the data structure (request queue) is correct and there
is no need to cancel the timer there!
--Malahal.
^ permalink raw reply
* Re: next-20081119: general protection fault: get_next_timer_interrupt()
From: Thomas Gleixner @ 2008-11-24 22:33 UTC (permalink / raw)
To: Mike Anderson
Cc: James Bottomley, Alexander Beregalov, LKML, linux-next,
Ingo Molnar, linux-scsi, David Miller, Jens Axboe
In-Reply-To: <20081124213517.GA25898@linux.vnet.ibm.com>
On Mon, 24 Nov 2008, Mike Anderson wrote:
> Thomas Gleixner <tglx@linutronix.de> wrote:
> > Yeah, block could it be as well. Jens, Mike ?
>
> I added a comment to bug 12020 on Thursday about a few other systems that
> where seeing the signature shown in bug 12020. It appeared from debug that
> there where a few paths that where adding timers for requests that where
> not expected.
>
> http://bugzilla.kernel.org/show_bug.cgi?id=12020
>
> It would be good to know if the debug patch below effects your problem as while.
>
> If it does we need to investigated a solution to resolve not adding a
> timer for these requests.
Wrong.
The problem is not a timer which is armed in the first place.
The problem is an armed timer which is not canceled before the data
structure which contains it is freed.
So not arming the timer will probably prevent this particular scan
problem, but it does not solve the general wreckage of freeing a data
structure with a possibly armed timer in it.
You need to fix the code path which frees the data structure which
contains the timer and cancel the timer _before_ freeing the data
structure.
Thanks,
tglx
^ permalink raw reply
* Re: linux-next: net tree build failure
From: Sam Ravnborg @ 2008-11-24 22:12 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Stephen Rothwell, David Miller, linux-next
In-Reply-To: <20081124135251.51196003@extreme>
On Mon, Nov 24, 2008 at 01:52:51PM -0800, Stephen Hemminger wrote:
> On Mon, 24 Nov 2008 22:00:28 +0100
> Sam Ravnborg <sam@ravnborg.org> wrote:
>
> > On Mon, Nov 24, 2008 at 04:38:44PM +1100, Stephen Rothwell wrote:
> > > On Sun, 23 Nov 2008 21:23:39 -0800 (PST) David Miller <davem@davemloft.net> wrote:
> > > >
> > > > Probably it didn't build for some obscure reason a long time
> > > > ago. I'll try to get it turned back on, but better is to
> > > > bring it in via drivers/Kconfig don't you think? :-)
> > >
> > > Only if you test build all the other architectures that currently don't
> > > include it. :-)
> >
> > Stephen, could I ask you to try to do so?
> > You have the infrastructure to do it.
> >
> > I would love to see any simplification of the nightmare
> > of Kconfig files we have.
> >
> >
> > I have only: arm, x86, sparc sparc64, alpha here so that
> > does not give any decent enough coverage.
> >
> > And my current Linux box is a Pentium 850 MHz so it would take
> > forever...
> >
> > Sam
>
> I will try and run 'make all modconfig' on x86, I don't have volunteer
> time to do cross build of all architectures. But isn't the purpose
> of linux-next to find/fix these things. If linux-net has to be perfect
> every minute then there is no purpose in having it.
Hi Stephen - it was Stepehn Rothwell I had in mind when I wrote the above :-)
Anyway - I can see that only "cris m68k parisc s390 sparc sparc64 um" lacks
the include of drivers/scsi/pcmcia/Kconfig.
So I will try to add it to drivers/Kconfig in my tree and see it -next
blows up. I will wait until next -next as I want to see my current
pending patches there in a clean run first.
Sam
>
^ permalink raw reply
* Re: linux-next: net tree build failure
From: Stephen Hemminger @ 2008-11-24 21:52 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: Stephen Rothwell, David Miller, linux-next
In-Reply-To: <20081124210028.GA32585@uranus.ravnborg.org>
On Mon, 24 Nov 2008 22:00:28 +0100
Sam Ravnborg <sam@ravnborg.org> wrote:
> On Mon, Nov 24, 2008 at 04:38:44PM +1100, Stephen Rothwell wrote:
> > On Sun, 23 Nov 2008 21:23:39 -0800 (PST) David Miller <davem@davemloft.net> wrote:
> > >
> > > Probably it didn't build for some obscure reason a long time
> > > ago. I'll try to get it turned back on, but better is to
> > > bring it in via drivers/Kconfig don't you think? :-)
> >
> > Only if you test build all the other architectures that currently don't
> > include it. :-)
>
> Stephen, could I ask you to try to do so?
> You have the infrastructure to do it.
>
> I would love to see any simplification of the nightmare
> of Kconfig files we have.
>
>
> I have only: arm, x86, sparc sparc64, alpha here so that
> does not give any decent enough coverage.
>
> And my current Linux box is a Pentium 850 MHz so it would take
> forever...
>
> Sam
I will try and run 'make all modconfig' on x86, I don't have volunteer
time to do cross build of all architectures. But isn't the purpose
of linux-next to find/fix these things. If linux-net has to be perfect
every minute then there is no purpose in having it.
^ permalink raw reply
* Re: next-20081119: general protection fault: get_next_timer_interrupt()
From: Mike Anderson @ 2008-11-24 21:35 UTC (permalink / raw)
To: Thomas Gleixner
Cc: James Bottomley, Alexander Beregalov, LKML, linux-next,
Ingo Molnar, linux-scsi, David Miller, Jens Axboe
In-Reply-To: <alpine.LFD.2.00.0811242018370.3235@localhost.localdomain>
Thomas Gleixner <tglx@linutronix.de> wrote:
> > Well, not sure. Most likely candidate is the new block timer code.
> > What seems to be happening is that the queue is being released with
> > either an outstanding request (refcounting problem) or ticking timer
> > with no work (block timer problem). The way scanning works is that we
> > create a request queue for each device we probe and then delete it again
> > if nothing appears after the bus settle time. The argument against
> > this is that it should show up on every scanned bus. However, these are
> > getting rarer; I was just about to write that I hadn't seen it when I
> > remembered that all my SCSI testing systems are currently running
> > hotplug reporting busses (i.e. don't do scanning). However,
> > fortunately, I've also booted voyager recently which does use parallel
> > SCSI and doesn't see this either, so it could also be megaraid_sas
> > specific.
>
> Yeah, block could it be as well. Jens, Mike ?
I added a comment to bug 12020 on Thursday about a few other systems that
where seeing the signature shown in bug 12020. It appeared from debug that
there where a few paths that where adding timers for requests that where
not expected.
http://bugzilla.kernel.org/show_bug.cgi?id=12020
It would be good to know if the debug patch below effects your problem as while.
If it does we need to investigated a solution to resolve not adding a
timer for these requests.
-andmike
--
Michael Anderson
andmike@linux.vnet.ibm.com
blk: blk_add_timer debug patch
[DEBUG] Debug only patch.
Debug patch to blk_add_timer to not start timer for request that do not
have the REQ_STARTED flag set.
Signed-off-by: Mike Anderson <andmike@linux.vnet.ibm.com>
---
block/blk-timeout.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/block/blk-timeout.c b/block/blk-timeout.c
index 69185ea..4389391 100644
--- a/block/blk-timeout.c
+++ b/block/blk-timeout.c
@@ -177,6 +177,9 @@ void blk_add_timer(struct request *req)
BUG_ON(!list_empty(&req->timeout_list));
BUG_ON(test_bit(REQ_ATOM_COMPLETE, &req->atomic_flags));
+ if (!(req->cmd_flags & REQ_STARTED))
+ return;
+
if (req->timeout)
req->deadline = jiffies + req->timeout;
else {
--
1.5.6.5
^ permalink raw reply related
* Re: linux-next: net tree build failure
From: Sam Ravnborg @ 2008-11-24 21:00 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: David Miller, linux-next, shemminger
In-Reply-To: <20081124163844.004469a6.sfr@canb.auug.org.au>
On Mon, Nov 24, 2008 at 04:38:44PM +1100, Stephen Rothwell wrote:
> On Sun, 23 Nov 2008 21:23:39 -0800 (PST) David Miller <davem@davemloft.net> wrote:
> >
> > Probably it didn't build for some obscure reason a long time
> > ago. I'll try to get it turned back on, but better is to
> > bring it in via drivers/Kconfig don't you think? :-)
>
> Only if you test build all the other architectures that currently don't
> include it. :-)
Stephen, could I ask you to try to do so?
You have the infrastructure to do it.
I would love to see any simplification of the nightmare
of Kconfig files we have.
I have only: arm, x86, sparc sparc64, alpha here so that
does not give any decent enough coverage.
And my current Linux box is a Pentium 850 MHz so it would take
forever...
Sam
^ permalink raw reply
* Re: next-20081119: general protection fault: get_next_timer_interrupt()
From: Thomas Gleixner @ 2008-11-24 19:31 UTC (permalink / raw)
To: James Bottomley
Cc: Alexander Beregalov, LKML, linux-next, Ingo Molnar, linux-scsi,
David Miller, Jens Axboe, Mike Anderson
In-Reply-To: <1227554117.25499.46.camel@localhost.localdomain>
On Mon, 24 Nov 2008, James Bottomley wrote:
> On Mon, 2008-11-24 at 18:43 +0100, Thomas Gleixner wrote:
> > > scsi0 : LSI SAS based MegaRAID driver
> > > Driver 'sd' needs updating - please use bus_type methods
> > > scsi 0:0:0:0: Direct-Access ATA SAMSUNG HE160HJ 0-24 PQ: 0 ANSI: 5
> > > ------------[ cut here ]------------
> > > WARNING: at lib/debugobjects.c:215 debug_print_object+0x4f/0x57()
> > > ODEBUG: free active object type: timer_list
> >
> > That's the cause for your boot crash. The scsi/blk code is freeing a
> > page which contains an active timer, so the timer code references gone
> > memory. You triggered it because DEBUG_PAGEALLOC unmaps the page when
> > it's freed.
> >
> > James, or other scsi experts please.
>
> Well, not sure. Most likely candidate is the new block timer code.
> What seems to be happening is that the queue is being released with
> either an outstanding request (refcounting problem) or ticking timer
> with no work (block timer problem). The way scanning works is that we
> create a request queue for each device we probe and then delete it again
> if nothing appears after the bus settle time. The argument against
> this is that it should show up on every scanned bus. However, these are
> getting rarer; I was just about to write that I hadn't seen it when I
> remembered that all my SCSI testing systems are currently running
> hotplug reporting busses (i.e. don't do scanning). However,
> fortunately, I've also booted voyager recently which does use parallel
> SCSI and doesn't see this either, so it could also be megaraid_sas
> specific.
Yeah, block could it be as well. Jens, Mike ?
One note about not seeing it: We have had such bugs before where the
page was freed but not touched and the timer survived w/o tripping the
system over. Alexander noticed because of DEBUG_PAGEALLOC and you can
also see it by enabling debugobjects, which will give you the nice
backtrace.
CONFIG_DEBUG_OBJECTS=y
CONFIG_DEBUG_OBJECTS_FREE=y
CONFIG_DEBUG_OBJECTS_TIMERS=Y
and add "debug_objects" to the kernel command line.
> Could you turn on SCSI logging so we can see the sequences. Probably
> since this is boot time, just enable all logging:
>
> echo 0xffffffff > /sys/module/scsi_mod/parameters/scsi_logging_level
>
> (kernel must be compiled with CONFIG_SCSI_LOGGING=y
>
> James
>
>
^ permalink raw reply
* Re: next-20081119: general protection fault: get_next_timer_interrupt()
From: James Bottomley @ 2008-11-24 19:15 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Alexander Beregalov, LKML, linux-next, Ingo Molnar, linux-scsi,
David Miller
In-Reply-To: <alpine.LFD.2.00.0811241816120.3301@localhost.localdomain>
On Mon, 2008-11-24 at 18:43 +0100, Thomas Gleixner wrote:
> > scsi0 : LSI SAS based MegaRAID driver
> > Driver 'sd' needs updating - please use bus_type methods
> > scsi 0:0:0:0: Direct-Access ATA SAMSUNG HE160HJ 0-24 PQ: 0 ANSI: 5
> > ------------[ cut here ]------------
> > WARNING: at lib/debugobjects.c:215 debug_print_object+0x4f/0x57()
> > ODEBUG: free active object type: timer_list
>
> That's the cause for your boot crash. The scsi/blk code is freeing a
> page which contains an active timer, so the timer code references gone
> memory. You triggered it because DEBUG_PAGEALLOC unmaps the page when
> it's freed.
>
> James, or other scsi experts please.
>
> > Modules linked in:
> > Pid: 580, comm: scsi_scan_0 Tainted: G W 2.6.28-rc5-next-20081119 #9
> > Call Trace:
> > [<ffffffff80236b28>] warn_slowpath+0xae/0xd5
> > [<ffffffff8037f9e8>] ? debug_check_no_obj_freed+0x75/0x1c8
> > [<ffffffff8037f8b1>] debug_print_object+0x4f/0x57
> > [<ffffffff8037fa0f>] debug_check_no_obj_freed+0x9c/0x1c8
> > [<ffffffff8029c7b2>] kmem_cache_free+0x64/0xc0
> > [<ffffffff8036a6e0>] ? blk_release_queue+0x61/0x66
> > [<ffffffff8036a6e0>] blk_release_queue+0x61/0x66
> > [<ffffffff803760f2>] kobject_release+0x52/0x68
> > [<ffffffff803760a0>] ? kobject_release+0x0/0x68
> > [<ffffffff80376ec5>] kref_put+0x43/0x4f
> > [<ffffffff80375ffa>] kobject_put+0x47/0x4b
> > [<ffffffff80368c53>] blk_cleanup_queue+0x57/0x5c
> > [<ffffffff803f8729>] scsi_free_queue+0x9/0xb
> > [<ffffffff803fd3c7>] scsi_device_dev_release_usercontext+0xdc/0x127
> > [<ffffffff803fd2eb>] ? scsi_device_dev_release_usercontext+0x0/0x127
> > [<ffffffff802472a8>] execute_in_process_context+0x2a/0x70
> > [<ffffffff803fd2e9>] scsi_device_dev_release+0x17/0x19
> > [<ffffffff803e03e0>] device_release+0x43/0x68
> > [<ffffffff803760f2>] kobject_release+0x52/0x68
> > [<ffffffff803760a0>] ? kobject_release+0x0/0x68
> > [<ffffffff80376ec5>] kref_put+0x43/0x4f
> > [<ffffffff80375ffa>] kobject_put+0x47/0x4b
> > [<ffffffff803dfd36>] put_device+0x15/0x17
> > [<ffffffff803fa772>] scsi_destroy_sdev+0x48/0x4c
> > [<ffffffff803fba05>] scsi_probe_and_add_lun+0xb5d/0xb81
> > [<ffffffff803faaba>] ? scsi_alloc_target+0x22b/0x267
> > [<ffffffff803fbcb0>] __scsi_scan_target+0x9d/0x598
> > [<ffffffff8025767c>] ? trace_hardirqs_on_caller+0x1f/0x153
> > [<ffffffff804e39a9>] ? __mutex_lock_common+0x371/0x3be
> > [<ffffffff803fc2d9>] ? scsi_scan_host_selected+0xb6/0x133
> > [<ffffffff8025767c>] ? trace_hardirqs_on_caller+0x1f/0x153
> > [<ffffffff803fc2d9>] ? scsi_scan_host_selected+0xb6/0x133
> > [<ffffffff803fc1fd>] scsi_scan_channel+0x52/0x78
> > [<ffffffff803fc314>] scsi_scan_host_selected+0xf1/0x133
> > [<ffffffff803fc3c6>] ? do_scan_async+0x0/0x127
> > [<ffffffff803fc3c1>] do_scsi_scan_host+0x6b/0x70
> > [<ffffffff803fc3c6>] ? do_scan_async+0x0/0x127
> > [<ffffffff803fc3dd>] do_scan_async+0x17/0x127
> > [<ffffffff803fc3c6>] ? do_scan_async+0x0/0x127
> > [<ffffffff80249d5d>] kthread+0x49/0x76
> > [<ffffffff8020c899>] child_rip+0xa/0x11
> > [<ffffffff8020bd88>] ? restore_args+0x0/0x30
> > [<ffffffff80249d14>] ? kthread+0x0/0x76
> > [<ffffffff8020c88f>] ? child_rip+0x0/0x11
> > ---[ end trace 4eaa2a86a8e2da22 ]---
Well, not sure. Most likely candidate is the new block timer code.
What seems to be happening is that the queue is being released with
either an outstanding request (refcounting problem) or ticking timer
with no work (block timer problem). The way scanning works is that we
create a request queue for each device we probe and then delete it again
if nothing appears after the bus settle time. The argument against
this is that it should show up on every scanned bus. However, these are
getting rarer; I was just about to write that I hadn't seen it when I
remembered that all my SCSI testing systems are currently running
hotplug reporting busses (i.e. don't do scanning). However,
fortunately, I've also booted voyager recently which does use parallel
SCSI and doesn't see this either, so it could also be megaraid_sas
specific.
Could you turn on SCSI logging so we can see the sequences. Probably
since this is boot time, just enable all logging:
echo 0xffffffff > /sys/module/scsi_mod/parameters/scsi_logging_level
(kernel must be compiled with CONFIG_SCSI_LOGGING=y
James
^ permalink raw reply
* Re: next-20081119: general protection fault: get_next_timer_interrupt()
From: Thomas Gleixner @ 2008-11-24 17:43 UTC (permalink / raw)
To: Alexander Beregalov
Cc: LKML, linux-next, Ingo Molnar, linux-scsi, James.Bottomley,
David Miller
In-Reply-To: <a4423d670811210250t6b75645evd9646ffb07745867@mail.gmail.com>
Alexander,
On Fri, 21 Nov 2008, Alexander Beregalov wrote:
> 2008/11/20 Thomas Gleixner <tglx@linutronix.de>:
> > Alexander,
> >
> > On Wed, 19 Nov 2008, Alexander Beregalov wrote:
> >>
> >> It is 4way X86_64
> >> The kernel does not boot.
> >
> >> RIP: 0010:[<ffffffff80240061>] [<ffffffff80240061>]
> >> get_next_timer_interrupt+0x11b/0x1f0
> >
> > Can you please enable:
> >
> > CONFIG_DEBUG_OBJECTS=y
> > CONFIG_DEBUG_OBJECTS_FREE=y
> > CONFIG_DEBUG_OBJECTS_TIMERS=Y
> >
> > and add "debug_objects" to the kernel command line ?
>
> I added these options:
Thanks.
> hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0
> hpet0: 3 comparators, 64-bit 14.318180 MHz counter
> ODEBUG: object is on stack, but not annotated
ok, that's homework for me.
> scsi0 : LSI SAS based MegaRAID driver
> Driver 'sd' needs updating - please use bus_type methods
> scsi 0:0:0:0: Direct-Access ATA SAMSUNG HE160HJ 0-24 PQ: 0 ANSI: 5
> ------------[ cut here ]------------
> WARNING: at lib/debugobjects.c:215 debug_print_object+0x4f/0x57()
> ODEBUG: free active object type: timer_list
That's the cause for your boot crash. The scsi/blk code is freeing a
page which contains an active timer, so the timer code references gone
memory. You triggered it because DEBUG_PAGEALLOC unmaps the page when
it's freed.
James, or other scsi experts please.
> Modules linked in:
> Pid: 580, comm: scsi_scan_0 Tainted: G W 2.6.28-rc5-next-20081119 #9
> Call Trace:
> [<ffffffff80236b28>] warn_slowpath+0xae/0xd5
> [<ffffffff8037f9e8>] ? debug_check_no_obj_freed+0x75/0x1c8
> [<ffffffff8037f8b1>] debug_print_object+0x4f/0x57
> [<ffffffff8037fa0f>] debug_check_no_obj_freed+0x9c/0x1c8
> [<ffffffff8029c7b2>] kmem_cache_free+0x64/0xc0
> [<ffffffff8036a6e0>] ? blk_release_queue+0x61/0x66
> [<ffffffff8036a6e0>] blk_release_queue+0x61/0x66
> [<ffffffff803760f2>] kobject_release+0x52/0x68
> [<ffffffff803760a0>] ? kobject_release+0x0/0x68
> [<ffffffff80376ec5>] kref_put+0x43/0x4f
> [<ffffffff80375ffa>] kobject_put+0x47/0x4b
> [<ffffffff80368c53>] blk_cleanup_queue+0x57/0x5c
> [<ffffffff803f8729>] scsi_free_queue+0x9/0xb
> [<ffffffff803fd3c7>] scsi_device_dev_release_usercontext+0xdc/0x127
> [<ffffffff803fd2eb>] ? scsi_device_dev_release_usercontext+0x0/0x127
> [<ffffffff802472a8>] execute_in_process_context+0x2a/0x70
> [<ffffffff803fd2e9>] scsi_device_dev_release+0x17/0x19
> [<ffffffff803e03e0>] device_release+0x43/0x68
> [<ffffffff803760f2>] kobject_release+0x52/0x68
> [<ffffffff803760a0>] ? kobject_release+0x0/0x68
> [<ffffffff80376ec5>] kref_put+0x43/0x4f
> [<ffffffff80375ffa>] kobject_put+0x47/0x4b
> [<ffffffff803dfd36>] put_device+0x15/0x17
> [<ffffffff803fa772>] scsi_destroy_sdev+0x48/0x4c
> [<ffffffff803fba05>] scsi_probe_and_add_lun+0xb5d/0xb81
> [<ffffffff803faaba>] ? scsi_alloc_target+0x22b/0x267
> [<ffffffff803fbcb0>] __scsi_scan_target+0x9d/0x598
> [<ffffffff8025767c>] ? trace_hardirqs_on_caller+0x1f/0x153
> [<ffffffff804e39a9>] ? __mutex_lock_common+0x371/0x3be
> [<ffffffff803fc2d9>] ? scsi_scan_host_selected+0xb6/0x133
> [<ffffffff8025767c>] ? trace_hardirqs_on_caller+0x1f/0x153
> [<ffffffff803fc2d9>] ? scsi_scan_host_selected+0xb6/0x133
> [<ffffffff803fc1fd>] scsi_scan_channel+0x52/0x78
> [<ffffffff803fc314>] scsi_scan_host_selected+0xf1/0x133
> [<ffffffff803fc3c6>] ? do_scan_async+0x0/0x127
> [<ffffffff803fc3c1>] do_scsi_scan_host+0x6b/0x70
> [<ffffffff803fc3c6>] ? do_scan_async+0x0/0x127
> [<ffffffff803fc3dd>] do_scan_async+0x17/0x127
> [<ffffffff803fc3c6>] ? do_scan_async+0x0/0x127
> [<ffffffff80249d5d>] kthread+0x49/0x76
> [<ffffffff8020c899>] child_rip+0xa/0x11
> [<ffffffff8020bd88>] ? restore_args+0x0/0x30
> [<ffffffff80249d14>] ? kthread+0x0/0x76
> [<ffffffff8020c88f>] ? child_rip+0x0/0x11
> ---[ end trace 4eaa2a86a8e2da22 ]---
> <...>
> ata2: port disabled. ignoring.
> scsi: waiting for bus probes to complete ...
> WARNING: at lib/debugobjects.c:215 debug_print_object+0x4f/0x57()
> ODEBUG: free active object type: timer_list
Same as above.
> BUG: using smp_processor_id() in preemptible [00000000] code: init-early.sh/741
> caller is sock_prot_inuse_add+0x24/0x42
> Pid: 741, comm: init-early.sh Tainted: G W 2.6.28-rc5-next-20081119 #9
> Call Trace:
> [<ffffffff8037f622>] debug_smp_processor_id+0xca/0xe0
> [<ffffffff8046ab5b>] sock_prot_inuse_add+0x24/0x42
> [<ffffffff804bb124>] unix_create1+0x161/0x176
> [<ffffffff804bb196>] unix_create+0x5d/0x68
> [<ffffffff80469368>] __sock_create+0x114/0x17e
> [<ffffffff80469420>] sock_create+0x2d/0x2f
> [<ffffffff80469623>] sys_socket+0x29/0x5c
> [<ffffffff8020b74b>] system_call_fastpath+0x16/0x1b
Dave ???
Thanks,
tglx
^ permalink raw reply
* Re: linux-next: rr tree build failure
From: Rusty Russell @ 2008-11-24 17:07 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, Mike Travis
In-Reply-To: <20081124143158.6de384f8.sfr@canb.auug.org.au>
On Monday 24 November 2008 14:01:58 Stephen Rothwell wrote:
> Hi Rusty,
>
> Today's linux-next build (powerpc ppc64_defconfig) failed like this:
>
> arch/powerpc/kernel/irq.c: In function 'fixup_irqs':
> arch/powerpc/kernel/irq.c:240: error: incompatible type for argument 2 of
> 'irq_desc[irq].chip->set_affinity' arch/powerpc/sysdev/mpic.c: In function
> 'mpic_alloc':
Not sure how these got through. I did another sweep.
Thanks,
Rusty.
^ permalink raw reply
* Re: [alsa-devel] [PATCH] Remove unused variable from tlv320aic23 codec
From: Takashi Iwai @ 2008-11-24 13:24 UTC (permalink / raw)
To: Richard A. Holden III
Cc: linux-next, alsa-devel, Mark Brown, linux-kernel, Liam Girdwood
In-Reply-To: <1227204203-32112-3-git-send-email-aciddeath@gmail.com>
At Thu, 20 Nov 2008 11:03:23 -0700,
Richard A. Holden III wrote:
>
> Remove codec var from tlv320aic23_set_dai_sysclk, it is assigned to
> but never read.
>
> Signed-off-by: Richard A. Holden III <aciddeath@gmail.com>
>
> Cc: Jaroslav Kysela <perex@perex.cz>
> Cc: Takashi Iwai <tiwai@suse.de>
> Cc: Liam Girdwood <lrg@slimlogic.co.uk>
> Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
> Cc: alsa-devel@alsa-project.org
> ---
> sound/soc/codecs/tlv320aic23.c | 2 --
> 1 files changed, 0 insertions(+), 2 deletions(-)
This is already fixed in the upstream, but pretty differently.
Takashi
> diff --git a/sound/soc/codecs/tlv320aic23.c b/sound/soc/codecs/tlv320aic23.c
> index 44308da..45395d0 100644
> --- a/sound/soc/codecs/tlv320aic23.c
> +++ b/sound/soc/codecs/tlv320aic23.c
> @@ -421,8 +421,6 @@ static int tlv320aic23_set_dai_fmt(struct snd_soc_dai *codec_dai,
> static int tlv320aic23_set_dai_sysclk(struct snd_soc_dai *codec_dai,
> int clk_id, unsigned int freq, int dir)
> {
> - struct snd_soc_codec *codec = codec_dai->codec;
> -
> switch (freq) {
> case 12000000:
> return 0;
> --
> 1.5.6.4
>
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>
^ permalink raw reply
* Re: linux-next: ttydev tree build failure
From: Alan Cox @ 2008-11-24 9:59 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next
In-Reply-To: <20081124161314.a61de8e9.sfr@canb.auug.org.au>
On Mon, 24 Nov 2008 16:13:14 +1100
Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Alan,
>
> I have dropped the ttydev tree for today due to unresolved build issues on
> m68k caused by a bad conversion of drivers/char/vme_scc.c in
I've not gone a viable m68k build tree or time to work on what is
basically a dead port. I will change policy to fit linux-next. That is
old obscure serial ports will not be updated but marked as broken and
then deleted if nobody is willing to maintain them.
Alan
^ permalink raw reply
* Re: linux-next: build warning
From: Stephen Rothwell @ 2008-11-24 9:14 UTC (permalink / raw)
To: NeilBrown; +Cc: linux-next, Cheng Renquan, Andrew Morton
In-Reply-To: <c102bd10dc67100b000665a13846f114.squirrel@neil.brown.name>
[-- Attachment #1: Type: text/plain, Size: 289 bytes --]
Hi Neil,
On Mon, 24 Nov 2008 18:53:46 +1100 (EST) "NeilBrown" <neilb@suse.de> wrote:
>
> Thanks. That's now fixed in my tree - you should see happiness tomorrow.
Thanks.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: linux-next: build warning
From: NeilBrown @ 2008-11-24 7:53 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, Cheng Renquan, Andrew Morton
In-Reply-To: <20081124173823.cb6a22cf.sfr@canb.auug.org.au>
On Mon, November 24, 2008 5:38 pm, Stephen Rothwell wrote:
> Hi Neil,
>
> Today's linux-next build (i386 defconfig) produced these warnings:
>
> drivers/md/md.c: In function 'print_sb_1':
> drivers/md/md.c:1678: warning: left shift count >= width of type
> drivers/md/md.c:1702: warning: left shift count >= width of type
>
> Caused by commit 8a11632aeb9ad49bbda3e2c6978b207c6aff1aa8 ("md: need
> another print_sb for mdp_superblock_1").
Thanks. That's now fixed in my tree - you should see happiness tomorrow.
NeilBrown
^ permalink raw reply
* linux-next: proc tree build failure
From: Stephen Rothwell @ 2008-11-24 7:15 UTC (permalink / raw)
To: Alexey Dobriyan; +Cc: linux-next, Ken Chen, Ingo Molnar, David S. Miller
[-- Attachment #1: Type: text/plain, Size: 465 bytes --]
Hi Alexey,
Today's linux-next build (sparc64 allmodconfig) failed like this:
fs/proc/base.c:362: undefined reference to `save_stack_trace_tsk'
It has been failing like this for some time.
Caused by commit 788ff43b53179f3af8677d59c87104aff1f75bde ("proc:
add /proc/*/stack") which has been fixed up for MIPS, but needs another
fix for Sparc.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox