Re: 2.6.23-mm1 tg3 wake-on-lan oddity...

[Valdis . Kletnieks]

On Tue, 27 Nov 2007 13:34:57 PST, Michael Chan said:

> Ideally, the BIOS should modify the NVRAM's setting when it is changed.
> We will talk to Dell to get their opinion on this as this is very
> confusing to the user.

That would certainly explain what I'm seeing, and I can certainly wait
if the answer is indeed "Buggy BIOS, fixed in D820 A08 or A09 or whenever".
(If Dell cares, I'm at BIOS A07 already).

In the meantime, I just stuck an 'ethtool -s eth0 wol d' in /etc/rc.local
until a proper fix shows up.


pgp9JdH9SLzg5.pgp
Description: PGP signature

Re: 2.6.23-mm1 tg3 wake-on-lan oddity...

[Michael Chan]

On Tue, 2007-11-27 at 01:35 -0800, [EMAIL PROTECTED] wrote:

> 
> Issue:
> 
> I (for unrelated reasons) run powertop, and it suggests I conserve power
> by doing 'ethtool -s eth0 wol d'.  I look at it, and think that it's daft,
> because (a) the Dell factory default is WOL disabled and (b) if it wasn't
> the default, I'd have *set* it to disabled, and (c) I even went back and
> rebooted and checked the BIOS setting - disabled. Nonetheless:
> 
> # ethtool eth0 | grep Wake
> Supports Wake-on: g
> Wake-on: g
> 
> Is this expected behavior?

What's happening is that there are 2 WoL settings: one in the BIOS and
one in the NIC's NVRAM.  For WoL to work, I think both settings have to
be enabled.  Apparently in this case, when you turn off WoL in the BIOS,
the NVRAM's WoL setting is unchanged, and will be seen by tg3 as
enabled.

Ideally, the BIOS should modify the NVRAM's setting when it is changed.
We will talk to Dell to get their opinion on this as this is very
confusing to the user.

Thanks.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-mm1 tg3 wake-on-lan oddity...

[Valdis . Kletnieks]

On Tue, 27 Nov 2007 08:04:28 PST, Michael Chan said:
> [EMAIL PROTECTED] wrote:
> 
> > (a) the Dell factory default is WOL disabled and (b)
> > if it wasn't
> > the default, I'd have *set* it to disabled, and (c) I even
> > went back and
> > rebooted and checked the BIOS setting - disabled. Nonetheless:
> >
> > # ethtool eth0 | grep Wake
> > Supports Wake-on: g
> > Wake-on: g
> >
> > Is this expected behavior?
> >
> 
> The new tg3 is supposed to follow the WoL setting in the
> NVRAM, so this is not expected.  We'll have to look into
> this.

Any info that would help?  printk's to stick in tg3.c?  Dumping the
relevant bytes of NVRAM? etc?


pgphBCOmCjmo6.pgp
Description: PGP signature

Re: 2.6.23-mm1 tg3 wake-on-lan oddity...

[Michael Chan]

[EMAIL PROTECTED] wrote:

> (a) the Dell factory default is WOL disabled and (b) 
> if it wasn't
> the default, I'd have *set* it to disabled, and (c) I even 
> went back and
> rebooted and checked the BIOS setting - disabled. Nonetheless:
> 
> # ethtool eth0 | grep Wake
> Supports Wake-on: g
> Wake-on: g
> 
> Is this expected behavior?
> 

The new tg3 is supposed to follow the WoL setting in the
NVRAM, so this is not expected.  We'll have to look into
this.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-mm1 tg3 wake-on-lan oddity...

[Michael Chan]

[EMAIL PROTECTED] wrote:

 (a) the Dell factory default is WOL disabled and (b) 
 if it wasn't
 the default, I'd have *set* it to disabled, and (c) I even 
 went back and
 rebooted and checked the BIOS setting - disabled. Nonetheless:
 
 # ethtool eth0 | grep Wake
 Supports Wake-on: g
 Wake-on: g
 
 Is this expected behavior?
 

The new tg3 is supposed to follow the WoL setting in the
NVRAM, so this is not expected.  We'll have to look into
this.

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-mm1 tg3 wake-on-lan oddity...

[Valdis . Kletnieks]

On Tue, 27 Nov 2007 08:04:28 PST, Michael Chan said:
 [EMAIL PROTECTED] wrote:
 
  (a) the Dell factory default is WOL disabled and (b)
  if it wasn't
  the default, I'd have *set* it to disabled, and (c) I even
  went back and
  rebooted and checked the BIOS setting - disabled. Nonetheless:
 
  # ethtool eth0 | grep Wake
  Supports Wake-on: g
  Wake-on: g
 
  Is this expected behavior?
 
 
 The new tg3 is supposed to follow the WoL setting in the
 NVRAM, so this is not expected.  We'll have to look into
 this.

Any info that would help?  printk's to stick in tg3.c?  Dumping the
relevant bytes of NVRAM? etc?


pgphBCOmCjmo6.pgp
Description: PGP signature

Re: 2.6.23-mm1 tg3 wake-on-lan oddity...

[Michael Chan]

On Tue, 2007-11-27 at 01:35 -0800, [EMAIL PROTECTED] wrote:

 
 Issue:
 
 I (for unrelated reasons) run powertop, and it suggests I conserve power
 by doing 'ethtool -s eth0 wol d'.  I look at it, and think that it's daft,
 because (a) the Dell factory default is WOL disabled and (b) if it wasn't
 the default, I'd have *set* it to disabled, and (c) I even went back and
 rebooted and checked the BIOS setting - disabled. Nonetheless:
 
 # ethtool eth0 | grep Wake
 Supports Wake-on: g
 Wake-on: g
 
 Is this expected behavior?

What's happening is that there are 2 WoL settings: one in the BIOS and
one in the NIC's NVRAM.  For WoL to work, I think both settings have to
be enabled.  Apparently in this case, when you turn off WoL in the BIOS,
the NVRAM's WoL setting is unchanged, and will be seen by tg3 as
enabled.

Ideally, the BIOS should modify the NVRAM's setting when it is changed.
We will talk to Dell to get their opinion on this as this is very
confusing to the user.

Thanks.

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-mm1 tg3 wake-on-lan oddity...

[Valdis . Kletnieks]

On Tue, 27 Nov 2007 13:34:57 PST, Michael Chan said:

 Ideally, the BIOS should modify the NVRAM's setting when it is changed.
 We will talk to Dell to get their opinion on this as this is very
 confusing to the user.

That would certainly explain what I'm seeing, and I can certainly wait
if the answer is indeed Buggy BIOS, fixed in D820 A08 or A09 or whenever.
(If Dell cares, I'm at BIOS A07 already).

In the meantime, I just stuck an 'ethtool -s eth0 wol d' in /etc/rc.local
until a proper fix shows up.


pgp9JdH9SLzg5.pgp
Description: PGP signature

Re: 2.6.23-mm1 breaks C-state support on Intel T7200 x86_64

[mark gross]

On Fri, Nov 09, 2007 at 03:24:44PM -0500, [EMAIL PROTECTED] wrote:
> On Thu, 08 Nov 2007 14:30:07 PST, Mark Gross said:
> 
> > wing patch fixes up the cpuidle / pm-qos integration.
> > 
> > I suspect that this is folded into another mm patch but it should fix
> > C-state issue identified.
> 
> Confirming that patch left my CPUs mostly in C3 again. Thanks.
> 
> I'll have to let Mark and Andrew figure out this code's status in the -mm 
> queue.

I checked on this last week, I'm pretty sure its in Andrew's current
tree.

Thanks again for looking at this.

--mgross
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-mm1 breaks C-state support on Intel T7200 x86_64

[mark gross]

On Fri, Nov 09, 2007 at 03:24:44PM -0500, [EMAIL PROTECTED] wrote:
 On Thu, 08 Nov 2007 14:30:07 PST, Mark Gross said:
 
  wing patch fixes up the cpuidle / pm-qos integration.
  
  I suspect that this is folded into another mm patch but it should fix
  C-state issue identified.
 
 Confirming that patch left my CPUs mostly in C3 again. Thanks.
 
 I'll have to let Mark and Andrew figure out this code's status in the -mm 
 queue.

I checked on this last week, I'm pretty sure its in Andrew's current
tree.

Thanks again for looking at this.

--mgross
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-mm1 breaks C-state support on Intel T7200 x86_64

[Valdis . Kletnieks]

On Thu, 08 Nov 2007 14:30:07 PST, Mark Gross said:

> wing patch fixes up the cpuidle / pm-qos integration.
> 
> I suspect that this is folded into another mm patch but it should fix
> C-state issue identified.

Confirming that patch left my CPUs mostly in C3 again. Thanks.

I'll have to let Mark and Andrew figure out this code's status in the -mm queue.


pgpZo8oTI96Vn.pgp
Description: PGP signature

Re: 2.6.23-mm1 breaks C-state support on Intel T7200 x86_64

[Valdis . Kletnieks]

On Thu, 08 Nov 2007 14:30:07 PST, Mark Gross said:

 wing patch fixes up the cpuidle / pm-qos integration.
 
 I suspect that this is folded into another mm patch but it should fix
 C-state issue identified.

Confirming that patch left my CPUs mostly in C3 again. Thanks.

I'll have to let Mark and Andrew figure out this code's status in the -mm queue.


pgpZo8oTI96Vn.pgp
Description: PGP signature

Re: 2.6.23-mm1 breaks C-state support on Intel T7200 x86_64

[Mark Gross]

On Thu, Nov 08, 2007 at 12:19:44PM -0500, [EMAIL PROTECTED] wrote:
> (Sorry for not reporting this sooner - I haven't been running off battery
> much in the last 3 weeks, so I didn't notice it till now...)
> 
> Dell Latitude D820 laptop, T7200 Core2 Duo CPU, x86_64 kernel.
> 
> As reported by 'powertop' on a basically idle machine:
> 
> 2.6.23-mm1:
> 
> CnAvg residency   P-states (frequencies)
> C0 (cpu running)(100.0%)2.00 Ghz 0.8%
> C10.0ms ( 0.0%) 1.67 Ghz 0.0%
> C20.0ms ( 0.0%) 1333 Mhz 0.0%
> C30.0ms ( 0.0%) 1000 Mhz99.2%
> 
> 2.6.23-rc8-mm2:
> 
> CnAvg residency   P-states (frequencies)
> C0 (cpu running)( 0.3%) 2.00 Ghz 0.0%
> C10.0ms ( 0.0%) 1.67 Ghz 0.0%
> C20.0ms ( 0.0%) 1333 Mhz 0.0%
> C3   31.5ms (99.7%) 1000 Mhz   100.0%
> 
> In addition, the ACPI power estimate reported about 25 watts for 23-mm1,
> but only 21 watts for -rc8-mm2, a significant regression.
> 
> I bisected this down to this set of patches:
> 
> pm-qos-infrastructure-and-interface.patch
> pm-qos-infrastructure-and-interface-fix.patch
> pm-qos-infrastructure-and-interface-vs-git-acpi.patch
> pm-qos-infrastructure-and-interface-vs-git-acpi-2.patch
> latencyc-use-qos-infrastructure.patch
> 
> The patch says:
> 
>   To register the default pm_qos target for the specific parameter, the
>   process must open one of /dev/[cpu_dma_latency, network_latency,
>   network_throughput]
> 
>   As long as the device node is held open that process has a registered
>   requirement on the parameter.  The name of the requirement is
>   "process_" derived from the current->pid from within the open system
>   call.
> 
> I shouldn't have to have a process open a /dev/file, write a number, and then
> stay around forever so the file doesn't close in order to get the same 
> behavior
> I was getting by default before.  What needs to happen to get this to not
> be a behavior regression/change?
> 
> 
> 
> 

wing patch fixes up the cpuidle / pm-qos integration.

I suspect that this is folded into another mm patch but it should fix
C-state issue identified.

--mgross



Signed-off-by: mark gross <[EMAIL PROTECTED]>

-

Index: linux-2.6.23-mm1/drivers/cpuidle/cpuidle.c
===
--- linux-2.6.23-mm1.orig/drivers/cpuidle/cpuidle.c 2007-11-08 
13:09:53.0 -0800
+++ linux-2.6.23-mm1/drivers/cpuidle/cpuidle.c  2007-11-08 13:25:13.0 
-0800
@@ -268,7 +268,7 @@
 
 static inline void latency_notifier_init(struct notifier_block *n)
 {
-pm_qos_add_notifier(PM_QOS_CPUIDLE, n);
+   pm_qos_add_notifier(PM_QOS_CPU_DMA_LATENCY, n);
 }
 
 #else /* CONFIG_SMP */
Index: linux-2.6.23-mm1/drivers/cpuidle/governors/ladder.c
===
--- linux-2.6.23-mm1.orig/drivers/cpuidle/governors/ladder.c2007-11-08 
13:09:53.0 -0800
+++ linux-2.6.23-mm1/drivers/cpuidle/governors/ladder.c 2007-11-08 
13:11:30.0 -0800
@@ -82,7 +82,7 @@
if (last_idx < dev->state_count - 1 &&
last_residency > last_state->threshold.promotion_time &&
dev->states[last_idx + 1].exit_latency <=
-   pm_qos_requirement(PM_QOS_CPUIDLE)) {
+   pm_qos_requirement(PM_QOS_CPU_DMA_LATENCY)) {
last_state->stats.promotion_count++;
last_state->stats.demotion_count = 0;
if (last_state->stats.promotion_count >= 
last_state->threshold.promotion_count) {
Index: linux-2.6.23-mm1/drivers/cpuidle/governors/menu.c
===
--- linux-2.6.23-mm1.orig/drivers/cpuidle/governors/menu.c  2007-11-08 
13:12:11.0 -0800
+++ linux-2.6.23-mm1/drivers/cpuidle/governors/menu.c   2007-11-08 
13:24:03.0 -0800
@@ -48,7 +48,8 @@
break;
if (s->target_residency > data->predicted_us)
break;
-   if (s->exit_latency > pm_qos_requirement(PM_QOS_CPUIDLE))
+   if (s->exit_latency >
+   pm_qos_requirement(PM_QOS_CPU_DMA_LATENCY))
break;
}
 
Index: linux-2.6.23-mm1/include/linux/pm_qos_params.h
===
--- linux-2.6.23-mm1.orig/include/linux/pm_qos_params.h 2007-11-08 
13:09:53.0 -0800
+++ linux-2.6.23-mm1/include/linux/pm_qos_params.h  2007-11-08 
13:14:05.0 -0800
@@ -6,23 +6,12 @@
 #include 
 #include 
 
-struct requirement_list {
-   struct list_head list;
-   union {
-   s32 value;
-   s32 usec;
-   s32 kbps;
-   };
-   char *name;
-};
-
 #define PM_QOS_RESERVED 0
 #define 

Re: 2.6.23-mm1 breaks C-state support on Intel T7200 x86_64

[Andrew Morton]

> On Thu, 8 Nov 2007 12:03:52 -0800 Mark Gross <[EMAIL PROTECTED]> wrote:
> ...
> > >   call.
> > > 
> > > I shouldn't have to have a process open a /dev/file, write a number, and 
> > > then
> > > stay around forever so the file doesn't close in order to get the same 
> > > behavior
> > > I was getting by default before.  What needs to happen to get this to not
> > > be a behavior regression/change?
> > > 
> > 
> > That's a great report, thanks.  Over to you, Mark ;)
> > 
> > btw, I also have a note here that these patches caused Rafael to see an
> > smp_call_function() inside local_irq_save().  Did that get fixed?
> 
> Ah, I see the problem.  I think I posted a fix to this.  The problem is
> that what's in the mm1 tree has a parameter PM_QOS_IDLE that needed to
> be PM_QOS_CPU_DMA_LATENCY. 

That doesn't ring a bell.

> I'm not sure what's in the current MM tree at this point so I can't say
> its been fixed.  Is there an easy way from me to see what's currently in
> MM?  

Not terribly. 
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/broken-out-2007-11-06-02-32.tar.gz
is from two days ago.

> FWIW I think I fixed this when I fixed up Rafael's issue.  Would you
> like me to send out a re-fresh patch against 2.6.23-mm1?

sure.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-mm1 breaks C-state support on Intel T7200 x86_64

[Mark Gross]

On Thu, Nov 08, 2007 at 10:02:12AM -0800, Andrew Morton wrote:
> > On Thu, 08 Nov 2007 12:19:44 -0500 [EMAIL PROTECTED] wrote:
> > (Sorry for not reporting this sooner - I haven't been running off battery
> > much in the last 3 weeks, so I didn't notice it till now...)
> > 
> > Dell Latitude D820 laptop, T7200 Core2 Duo CPU, x86_64 kernel.
> > 
> > As reported by 'powertop' on a basically idle machine:
> > 
> > 2.6.23-mm1:
> > 
> > CnAvg residency   P-states (frequencies)
> > C0 (cpu running)(100.0%)2.00 Ghz 0.8%
> > C10.0ms ( 0.0%) 1.67 Ghz 0.0%
> > C20.0ms ( 0.0%) 1333 Mhz 0.0%
> > C30.0ms ( 0.0%) 1000 Mhz99.2%
> > 
> > 2.6.23-rc8-mm2:
> > 
> > CnAvg residency   P-states (frequencies)
> > C0 (cpu running)( 0.3%) 2.00 Ghz 0.0%
> > C10.0ms ( 0.0%) 1.67 Ghz 0.0%
> > C20.0ms ( 0.0%) 1333 Mhz 0.0%
> > C3   31.5ms (99.7%) 1000 Mhz   100.0%
> > 
> > In addition, the ACPI power estimate reported about 25 watts for 23-mm1,
> > but only 21 watts for -rc8-mm2, a significant regression.
> > 
> > I bisected this down to this set of patches:
> > 
> > pm-qos-infrastructure-and-interface.patch
> > pm-qos-infrastructure-and-interface-fix.patch
> > pm-qos-infrastructure-and-interface-vs-git-acpi.patch
> > pm-qos-infrastructure-and-interface-vs-git-acpi-2.patch
> > latencyc-use-qos-infrastructure.patch
> > 
> > The patch says:
> > 
> >   To register the default pm_qos target for the specific parameter, the
> >   process must open one of /dev/[cpu_dma_latency, network_latency,
> >   network_throughput]
> > 
> >   As long as the device node is held open that process has a registered
> >   requirement on the parameter.  The name of the requirement is
> >   "process_" derived from the current->pid from within the open system
> >   call.
> > 
> > I shouldn't have to have a process open a /dev/file, write a number, and 
> > then
> > stay around forever so the file doesn't close in order to get the same 
> > behavior
> > I was getting by default before.  What needs to happen to get this to not
> > be a behavior regression/change?
> > 
> 
> That's a great report, thanks.  Over to you, Mark ;)
> 
> btw, I also have a note here that these patches caused Rafael to see an
> smp_call_function() inside local_irq_save().  Did that get fixed?

Ah, I see the problem.  I think I posted a fix to this.  The problem is
that what's in the mm1 tree has a parameter PM_QOS_IDLE that needed to
be PM_QOS_CPU_DMA_LATENCY. 

I'm not sure what's in the current MM tree at this point so I can't say
its been fixed.  Is there an easy way from me to see what's currently in
MM?  

FWIW I think I fixed this when I fixed up Rafael's issue.  Would you
like me to send out a re-fresh patch against 2.6.23-mm1?

--mgross

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-mm1 breaks C-state support on Intel T7200 x86_64

[Mark Gross]

On Thu, Nov 08, 2007 at 12:19:44PM -0500, [EMAIL PROTECTED] wrote:
> (Sorry for not reporting this sooner - I haven't been running off battery
> much in the last 3 weeks, so I didn't notice it till now...)
> 
> Dell Latitude D820 laptop, T7200 Core2 Duo CPU, x86_64 kernel.
> 
> As reported by 'powertop' on a basically idle machine:
> 
> 2.6.23-mm1:
> 
> CnAvg residency   P-states (frequencies)
> C0 (cpu running)(100.0%)2.00 Ghz 0.8%
> C10.0ms ( 0.0%) 1.67 Ghz 0.0%
> C20.0ms ( 0.0%) 1333 Mhz 0.0%
> C30.0ms ( 0.0%) 1000 Mhz99.2%
> 
> 2.6.23-rc8-mm2:
> 
> CnAvg residency   P-states (frequencies)
> C0 (cpu running)( 0.3%) 2.00 Ghz 0.0%
> C10.0ms ( 0.0%) 1.67 Ghz 0.0%
> C20.0ms ( 0.0%) 1333 Mhz 0.0%
> C3   31.5ms (99.7%) 1000 Mhz   100.0%
> 
> In addition, the ACPI power estimate reported about 25 watts for 23-mm1,
> but only 21 watts for -rc8-mm2, a significant regression.

well, thats because you burn less watts if you get into C3.  

> 
> I bisected this down to this set of patches:
> 
> pm-qos-infrastructure-and-interface.patch
> pm-qos-infrastructure-and-interface-fix.patch
> pm-qos-infrastructure-and-interface-vs-git-acpi.patch
> pm-qos-infrastructure-and-interface-vs-git-acpi-2.patch
> latencyc-use-qos-infrastructure.patch

yipes!  I'll look at it right away.  It looks like an integration issue
with CPU-IDLE patches (those control the C-state entry).  I'll get it
fixed up.

> 
> The patch says:
> 
>   To register the default pm_qos target for the specific parameter, the
>   process must open one of /dev/[cpu_dma_latency, network_latency,
>   network_throughput]
> 
>   As long as the device node is held open that process has a registered
>   requirement on the parameter.  The name of the requirement is
>   "process_" derived from the current->pid from within the open system
>   call.
> 
> I shouldn't have to have a process open a /dev/file, write a number, and then
> stay around forever so the file doesn't close in order to get the same 
> behavior
> I was getting by default before.  What needs to happen to get this to not
> be a behavior regression/change?
>
you won't have such a process (at least I highly doubt you do)  I need
to fix this.  Thanks for taking the time to bisect it and reporting it to me!

--mgross
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-mm1 breaks C-state support on Intel T7200 x86_64

[Andrew Morton]

> On Thu, 08 Nov 2007 12:19:44 -0500 [EMAIL PROTECTED] wrote:
> (Sorry for not reporting this sooner - I haven't been running off battery
> much in the last 3 weeks, so I didn't notice it till now...)
> 
> Dell Latitude D820 laptop, T7200 Core2 Duo CPU, x86_64 kernel.
> 
> As reported by 'powertop' on a basically idle machine:
> 
> 2.6.23-mm1:
> 
> CnAvg residency   P-states (frequencies)
> C0 (cpu running)(100.0%)2.00 Ghz 0.8%
> C10.0ms ( 0.0%) 1.67 Ghz 0.0%
> C20.0ms ( 0.0%) 1333 Mhz 0.0%
> C30.0ms ( 0.0%) 1000 Mhz99.2%
> 
> 2.6.23-rc8-mm2:
> 
> CnAvg residency   P-states (frequencies)
> C0 (cpu running)( 0.3%) 2.00 Ghz 0.0%
> C10.0ms ( 0.0%) 1.67 Ghz 0.0%
> C20.0ms ( 0.0%) 1333 Mhz 0.0%
> C3   31.5ms (99.7%) 1000 Mhz   100.0%
> 
> In addition, the ACPI power estimate reported about 25 watts for 23-mm1,
> but only 21 watts for -rc8-mm2, a significant regression.
> 
> I bisected this down to this set of patches:
> 
> pm-qos-infrastructure-and-interface.patch
> pm-qos-infrastructure-and-interface-fix.patch
> pm-qos-infrastructure-and-interface-vs-git-acpi.patch
> pm-qos-infrastructure-and-interface-vs-git-acpi-2.patch
> latencyc-use-qos-infrastructure.patch
> 
> The patch says:
> 
>   To register the default pm_qos target for the specific parameter, the
>   process must open one of /dev/[cpu_dma_latency, network_latency,
>   network_throughput]
> 
>   As long as the device node is held open that process has a registered
>   requirement on the parameter.  The name of the requirement is
>   "process_" derived from the current->pid from within the open system
>   call.
> 
> I shouldn't have to have a process open a /dev/file, write a number, and then
> stay around forever so the file doesn't close in order to get the same 
> behavior
> I was getting by default before.  What needs to happen to get this to not
> be a behavior regression/change?
> 

That's a great report, thanks.  Over to you, Mark ;)

btw, I also have a note here that these patches caused Rafael to see an
smp_call_function() inside local_irq_save().  Did that get fixed?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-mm1 breaks C-state support on Intel T7200 x86_64

[Andrew Morton]

 On Thu, 08 Nov 2007 12:19:44 -0500 [EMAIL PROTECTED] wrote:
 (Sorry for not reporting this sooner - I haven't been running off battery
 much in the last 3 weeks, so I didn't notice it till now...)
 
 Dell Latitude D820 laptop, T7200 Core2 Duo CPU, x86_64 kernel.
 
 As reported by 'powertop' on a basically idle machine:
 
 2.6.23-mm1:
 
 CnAvg residency   P-states (frequencies)
 C0 (cpu running)(100.0%)2.00 Ghz 0.8%
 C10.0ms ( 0.0%) 1.67 Ghz 0.0%
 C20.0ms ( 0.0%) 1333 Mhz 0.0%
 C30.0ms ( 0.0%) 1000 Mhz99.2%
 
 2.6.23-rc8-mm2:
 
 CnAvg residency   P-states (frequencies)
 C0 (cpu running)( 0.3%) 2.00 Ghz 0.0%
 C10.0ms ( 0.0%) 1.67 Ghz 0.0%
 C20.0ms ( 0.0%) 1333 Mhz 0.0%
 C3   31.5ms (99.7%) 1000 Mhz   100.0%
 
 In addition, the ACPI power estimate reported about 25 watts for 23-mm1,
 but only 21 watts for -rc8-mm2, a significant regression.
 
 I bisected this down to this set of patches:
 
 pm-qos-infrastructure-and-interface.patch
 pm-qos-infrastructure-and-interface-fix.patch
 pm-qos-infrastructure-and-interface-vs-git-acpi.patch
 pm-qos-infrastructure-and-interface-vs-git-acpi-2.patch
 latencyc-use-qos-infrastructure.patch
 
 The patch says:
 
   To register the default pm_qos target for the specific parameter, the
   process must open one of /dev/[cpu_dma_latency, network_latency,
   network_throughput]
 
   As long as the device node is held open that process has a registered
   requirement on the parameter.  The name of the requirement is
   process_PID derived from the current-pid from within the open system
   call.
 
 I shouldn't have to have a process open a /dev/file, write a number, and then
 stay around forever so the file doesn't close in order to get the same 
 behavior
 I was getting by default before.  What needs to happen to get this to not
 be a behavior regression/change?
 

That's a great report, thanks.  Over to you, Mark ;)

btw, I also have a note here that these patches caused Rafael to see an
smp_call_function() inside local_irq_save().  Did that get fixed?
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-mm1 breaks C-state support on Intel T7200 x86_64

[Mark Gross]

On Thu, Nov 08, 2007 at 12:19:44PM -0500, [EMAIL PROTECTED] wrote:
 (Sorry for not reporting this sooner - I haven't been running off battery
 much in the last 3 weeks, so I didn't notice it till now...)
 
 Dell Latitude D820 laptop, T7200 Core2 Duo CPU, x86_64 kernel.
 
 As reported by 'powertop' on a basically idle machine:
 
 2.6.23-mm1:
 
 CnAvg residency   P-states (frequencies)
 C0 (cpu running)(100.0%)2.00 Ghz 0.8%
 C10.0ms ( 0.0%) 1.67 Ghz 0.0%
 C20.0ms ( 0.0%) 1333 Mhz 0.0%
 C30.0ms ( 0.0%) 1000 Mhz99.2%
 
 2.6.23-rc8-mm2:
 
 CnAvg residency   P-states (frequencies)
 C0 (cpu running)( 0.3%) 2.00 Ghz 0.0%
 C10.0ms ( 0.0%) 1.67 Ghz 0.0%
 C20.0ms ( 0.0%) 1333 Mhz 0.0%
 C3   31.5ms (99.7%) 1000 Mhz   100.0%
 
 In addition, the ACPI power estimate reported about 25 watts for 23-mm1,
 but only 21 watts for -rc8-mm2, a significant regression.

well, thats because you burn less watts if you get into C3.  

 
 I bisected this down to this set of patches:
 
 pm-qos-infrastructure-and-interface.patch
 pm-qos-infrastructure-and-interface-fix.patch
 pm-qos-infrastructure-and-interface-vs-git-acpi.patch
 pm-qos-infrastructure-and-interface-vs-git-acpi-2.patch
 latencyc-use-qos-infrastructure.patch

yipes!  I'll look at it right away.  It looks like an integration issue
with CPU-IDLE patches (those control the C-state entry).  I'll get it
fixed up.

 
 The patch says:
 
   To register the default pm_qos target for the specific parameter, the
   process must open one of /dev/[cpu_dma_latency, network_latency,
   network_throughput]
 
   As long as the device node is held open that process has a registered
   requirement on the parameter.  The name of the requirement is
   process_PID derived from the current-pid from within the open system
   call.
 
 I shouldn't have to have a process open a /dev/file, write a number, and then
 stay around forever so the file doesn't close in order to get the same 
 behavior
 I was getting by default before.  What needs to happen to get this to not
 be a behavior regression/change?

you won't have such a process (at least I highly doubt you do)  I need
to fix this.  Thanks for taking the time to bisect it and reporting it to me!

--mgross
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-mm1 breaks C-state support on Intel T7200 x86_64

[Andrew Morton]

 On Thu, 8 Nov 2007 12:03:52 -0800 Mark Gross [EMAIL PROTECTED] wrote:
 ...
 call.
   
   I shouldn't have to have a process open a /dev/file, write a number, and 
   then
   stay around forever so the file doesn't close in order to get the same 
   behavior
   I was getting by default before.  What needs to happen to get this to not
   be a behavior regression/change?
   
  
  That's a great report, thanks.  Over to you, Mark ;)
  
  btw, I also have a note here that these patches caused Rafael to see an
  smp_call_function() inside local_irq_save().  Did that get fixed?
 
 Ah, I see the problem.  I think I posted a fix to this.  The problem is
 that what's in the mm1 tree has a parameter PM_QOS_IDLE that needed to
 be PM_QOS_CPU_DMA_LATENCY. 

That doesn't ring a bell.

 I'm not sure what's in the current MM tree at this point so I can't say
 its been fixed.  Is there an easy way from me to see what's currently in
 MM?  

Not terribly. 
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/broken-out-2007-11-06-02-32.tar.gz
is from two days ago.

 FWIW I think I fixed this when I fixed up Rafael's issue.  Would you
 like me to send out a re-fresh patch against 2.6.23-mm1?

sure.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-mm1 breaks C-state support on Intel T7200 x86_64

[Mark Gross]

On Thu, Nov 08, 2007 at 10:02:12AM -0800, Andrew Morton wrote:
  On Thu, 08 Nov 2007 12:19:44 -0500 [EMAIL PROTECTED] wrote:
  (Sorry for not reporting this sooner - I haven't been running off battery
  much in the last 3 weeks, so I didn't notice it till now...)
  
  Dell Latitude D820 laptop, T7200 Core2 Duo CPU, x86_64 kernel.
  
  As reported by 'powertop' on a basically idle machine:
  
  2.6.23-mm1:
  
  CnAvg residency   P-states (frequencies)
  C0 (cpu running)(100.0%)2.00 Ghz 0.8%
  C10.0ms ( 0.0%) 1.67 Ghz 0.0%
  C20.0ms ( 0.0%) 1333 Mhz 0.0%
  C30.0ms ( 0.0%) 1000 Mhz99.2%
  
  2.6.23-rc8-mm2:
  
  CnAvg residency   P-states (frequencies)
  C0 (cpu running)( 0.3%) 2.00 Ghz 0.0%
  C10.0ms ( 0.0%) 1.67 Ghz 0.0%
  C20.0ms ( 0.0%) 1333 Mhz 0.0%
  C3   31.5ms (99.7%) 1000 Mhz   100.0%
  
  In addition, the ACPI power estimate reported about 25 watts for 23-mm1,
  but only 21 watts for -rc8-mm2, a significant regression.
  
  I bisected this down to this set of patches:
  
  pm-qos-infrastructure-and-interface.patch
  pm-qos-infrastructure-and-interface-fix.patch
  pm-qos-infrastructure-and-interface-vs-git-acpi.patch
  pm-qos-infrastructure-and-interface-vs-git-acpi-2.patch
  latencyc-use-qos-infrastructure.patch
  
  The patch says:
  
To register the default pm_qos target for the specific parameter, the
process must open one of /dev/[cpu_dma_latency, network_latency,
network_throughput]
  
As long as the device node is held open that process has a registered
requirement on the parameter.  The name of the requirement is
process_PID derived from the current-pid from within the open system
call.
  
  I shouldn't have to have a process open a /dev/file, write a number, and 
  then
  stay around forever so the file doesn't close in order to get the same 
  behavior
  I was getting by default before.  What needs to happen to get this to not
  be a behavior regression/change?
  
 
 That's a great report, thanks.  Over to you, Mark ;)
 
 btw, I also have a note here that these patches caused Rafael to see an
 smp_call_function() inside local_irq_save().  Did that get fixed?

Ah, I see the problem.  I think I posted a fix to this.  The problem is
that what's in the mm1 tree has a parameter PM_QOS_IDLE that needed to
be PM_QOS_CPU_DMA_LATENCY. 

I'm not sure what's in the current MM tree at this point so I can't say
its been fixed.  Is there an easy way from me to see what's currently in
MM?  

FWIW I think I fixed this when I fixed up Rafael's issue.  Would you
like me to send out a re-fresh patch against 2.6.23-mm1?

--mgross

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-mm1 breaks C-state support on Intel T7200 x86_64

[Mark Gross]

On Thu, Nov 08, 2007 at 12:19:44PM -0500, [EMAIL PROTECTED] wrote:
 (Sorry for not reporting this sooner - I haven't been running off battery
 much in the last 3 weeks, so I didn't notice it till now...)
 
 Dell Latitude D820 laptop, T7200 Core2 Duo CPU, x86_64 kernel.
 
 As reported by 'powertop' on a basically idle machine:
 
 2.6.23-mm1:
 
 CnAvg residency   P-states (frequencies)
 C0 (cpu running)(100.0%)2.00 Ghz 0.8%
 C10.0ms ( 0.0%) 1.67 Ghz 0.0%
 C20.0ms ( 0.0%) 1333 Mhz 0.0%
 C30.0ms ( 0.0%) 1000 Mhz99.2%
 
 2.6.23-rc8-mm2:
 
 CnAvg residency   P-states (frequencies)
 C0 (cpu running)( 0.3%) 2.00 Ghz 0.0%
 C10.0ms ( 0.0%) 1.67 Ghz 0.0%
 C20.0ms ( 0.0%) 1333 Mhz 0.0%
 C3   31.5ms (99.7%) 1000 Mhz   100.0%
 
 In addition, the ACPI power estimate reported about 25 watts for 23-mm1,
 but only 21 watts for -rc8-mm2, a significant regression.
 
 I bisected this down to this set of patches:
 
 pm-qos-infrastructure-and-interface.patch
 pm-qos-infrastructure-and-interface-fix.patch
 pm-qos-infrastructure-and-interface-vs-git-acpi.patch
 pm-qos-infrastructure-and-interface-vs-git-acpi-2.patch
 latencyc-use-qos-infrastructure.patch
 
 The patch says:
 
   To register the default pm_qos target for the specific parameter, the
   process must open one of /dev/[cpu_dma_latency, network_latency,
   network_throughput]
 
   As long as the device node is held open that process has a registered
   requirement on the parameter.  The name of the requirement is
   process_PID derived from the current-pid from within the open system
   call.
 
 I shouldn't have to have a process open a /dev/file, write a number, and then
 stay around forever so the file doesn't close in order to get the same 
 behavior
 I was getting by default before.  What needs to happen to get this to not
 be a behavior regression/change?
 
 
 
 

wing patch fixes up the cpuidle / pm-qos integration.

I suspect that this is folded into another mm patch but it should fix
C-state issue identified.

--mgross



Signed-off-by: mark gross [EMAIL PROTECTED]

-

Index: linux-2.6.23-mm1/drivers/cpuidle/cpuidle.c
===
--- linux-2.6.23-mm1.orig/drivers/cpuidle/cpuidle.c 2007-11-08 
13:09:53.0 -0800
+++ linux-2.6.23-mm1/drivers/cpuidle/cpuidle.c  2007-11-08 13:25:13.0 
-0800
@@ -268,7 +268,7 @@
 
 static inline void latency_notifier_init(struct notifier_block *n)
 {
-pm_qos_add_notifier(PM_QOS_CPUIDLE, n);
+   pm_qos_add_notifier(PM_QOS_CPU_DMA_LATENCY, n);
 }
 
 #else /* CONFIG_SMP */
Index: linux-2.6.23-mm1/drivers/cpuidle/governors/ladder.c
===
--- linux-2.6.23-mm1.orig/drivers/cpuidle/governors/ladder.c2007-11-08 
13:09:53.0 -0800
+++ linux-2.6.23-mm1/drivers/cpuidle/governors/ladder.c 2007-11-08 
13:11:30.0 -0800
@@ -82,7 +82,7 @@
if (last_idx  dev-state_count - 1 
last_residency  last_state-threshold.promotion_time 
dev-states[last_idx + 1].exit_latency =
-   pm_qos_requirement(PM_QOS_CPUIDLE)) {
+   pm_qos_requirement(PM_QOS_CPU_DMA_LATENCY)) {
last_state-stats.promotion_count++;
last_state-stats.demotion_count = 0;
if (last_state-stats.promotion_count = 
last_state-threshold.promotion_count) {
Index: linux-2.6.23-mm1/drivers/cpuidle/governors/menu.c
===
--- linux-2.6.23-mm1.orig/drivers/cpuidle/governors/menu.c  2007-11-08 
13:12:11.0 -0800
+++ linux-2.6.23-mm1/drivers/cpuidle/governors/menu.c   2007-11-08 
13:24:03.0 -0800
@@ -48,7 +48,8 @@
break;
if (s-target_residency  data-predicted_us)
break;
-   if (s-exit_latency  pm_qos_requirement(PM_QOS_CPUIDLE))
+   if (s-exit_latency 
+   pm_qos_requirement(PM_QOS_CPU_DMA_LATENCY))
break;
}
 
Index: linux-2.6.23-mm1/include/linux/pm_qos_params.h
===
--- linux-2.6.23-mm1.orig/include/linux/pm_qos_params.h 2007-11-08 
13:09:53.0 -0800
+++ linux-2.6.23-mm1/include/linux/pm_qos_params.h  2007-11-08 
13:14:05.0 -0800
@@ -6,23 +6,12 @@
 #include linux/notifier.h
 #include linux/miscdevice.h
 
-struct requirement_list {
-   struct list_head list;
-   union {
-   s32 value;
-   s32 usec;
-   s32 kbps;
-   };
-   char *name;
-};
-
 #define PM_QOS_RESERVED 0
 #define PM_QOS_CPU_DMA_LATENCY 1
 #define PM_QOS_NETWORK_LATENCY 

Re: [2.6.23-mm1] CONFIG_LOCALVERSION handling broken

[Sam Ravnborg]

On Sat, Oct 27, 2007 at 05:19:24PM +0200, Tilman Schmidt wrote:
> /me wrote:
> 
> > [EMAIL PROTECTED]:~/kernel/linux-2.6.23-mm1-work> make 
> > include/config/kernel.release
> > [EMAIL PROTECTED]:~/kernel/linux-2.6.23-mm1-work> cat 
> > include/config/kernel.release
> > 2.6.23-mm1-testing
> > [EMAIL PROTECTED]:~/kernel/linux-2.6.23-mm1-work> make
> > [...]
> > [EMAIL PROTECTED]:~/kernel/linux-2.6.23-mm1-work> cat 
> > include/config/kernel.release
> > 2.6.23-mm1
> [...]
> > I'll just skip this -mm release and wait for 2.6.24-rc1, hoping
> > it won't have the same problem.
> 
> 2.6.24-rc1 is fine, so the issue can be closed.

Thanks for reporting back,

Sam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [2.6.23-mm1] CONFIG_LOCALVERSION handling broken

[Tilman Schmidt]

/me wrote:

> [EMAIL PROTECTED]:~/kernel/linux-2.6.23-mm1-work> make 
> include/config/kernel.release
> [EMAIL PROTECTED]:~/kernel/linux-2.6.23-mm1-work> cat 
> include/config/kernel.release
> 2.6.23-mm1-testing
> [EMAIL PROTECTED]:~/kernel/linux-2.6.23-mm1-work> make
> [...]
> [EMAIL PROTECTED]:~/kernel/linux-2.6.23-mm1-work> cat 
> include/config/kernel.release
> 2.6.23-mm1
[...]
> I'll just skip this -mm release and wait for 2.6.24-rc1, hoping
> it won't have the same problem.

2.6.24-rc1 is fine, so the issue can be closed.

T.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [2.6.23-mm1] CONFIG_LOCALVERSION handling broken

[Tilman Schmidt]

/me wrote:

 [EMAIL PROTECTED]:~/kernel/linux-2.6.23-mm1-work make 
 include/config/kernel.release
 [EMAIL PROTECTED]:~/kernel/linux-2.6.23-mm1-work cat 
 include/config/kernel.release
 2.6.23-mm1-testing
 [EMAIL PROTECTED]:~/kernel/linux-2.6.23-mm1-work make
 [...]
 [EMAIL PROTECTED]:~/kernel/linux-2.6.23-mm1-work cat 
 include/config/kernel.release
 2.6.23-mm1
[...]
 I'll just skip this -mm release and wait for 2.6.24-rc1, hoping
 it won't have the same problem.

2.6.24-rc1 is fine, so the issue can be closed.

T.

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [2.6.23-mm1] CONFIG_LOCALVERSION handling broken

[Sam Ravnborg]

On Sat, Oct 27, 2007 at 05:19:24PM +0200, Tilman Schmidt wrote:
 /me wrote:
 
  [EMAIL PROTECTED]:~/kernel/linux-2.6.23-mm1-work make 
  include/config/kernel.release
  [EMAIL PROTECTED]:~/kernel/linux-2.6.23-mm1-work cat 
  include/config/kernel.release
  2.6.23-mm1-testing
  [EMAIL PROTECTED]:~/kernel/linux-2.6.23-mm1-work make
  [...]
  [EMAIL PROTECTED]:~/kernel/linux-2.6.23-mm1-work cat 
  include/config/kernel.release
  2.6.23-mm1
 [...]
  I'll just skip this -mm release and wait for 2.6.24-rc1, hoping
  it won't have the same problem.
 
 2.6.24-rc1 is fine, so the issue can be closed.

Thanks for reporting back,

Sam
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-mm1 - regression- PowerPC link failure at arch/powerpc/kernel/head_64.o

[Stephen Rothwell]

On Sun, 21 Oct 2007 12:12:38 +0530 Kamalesh Babulal <[EMAIL PROTECTED]> wrote:
>
> After the bisecting, i found that the patch git-net.patch is the cause for 
> the link failure.

The actual cause is my patch to mark some things in head_64.S as
init_refok.  I have a test patch which I will tidy up and post soon.
However, even with that fixed, I am running into a linker bug which Alan
Modra is looking into.

-- 
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/


pgpm17QhI2kKn.pgp
Description: PGP signature

Re: 2.6.23-mm1 - regression- PowerPC link failure at arch/powerpc/kernel/head_64.o

[Stephen Rothwell]

On Sun, 21 Oct 2007 12:12:38 +0530 Kamalesh Babulal [EMAIL PROTECTED] wrote:

 After the bisecting, i found that the patch git-net.patch is the cause for 
 the link failure.

The actual cause is my patch to mark some things in head_64.S as
init_refok.  I have a test patch which I will tidy up and post soon.
However, even with that fixed, I am running into a linker bug which Alan
Modra is looking into.

-- 
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/


pgpm17QhI2kKn.pgp
Description: PGP signature

Re: 2.6.23-mm1 - autofs broken

[Dave Hansen]

On Sat, 2007-10-20 at 10:56 -0400, Rik van Riel wrote:
> I just tried it.  In the latest git tree, autofs still works.
> 
> The regression is in -mm only.

Andrew,

Rik tracked it down to an interaction with futexes from the pid
namespace code.  I believe r/o bind mounts are innocent for now.

-- Dave

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-mm1 - autofs broken

[Rik van Riel]

On Mon, 22 Oct 2007 11:45:19 +0800
Ian Kent <[EMAIL PROTECTED]> wrote:

> > Oct 20 00:38:52 kenny automount[2293]: cache_readlock: mapent cache
> > rwlock lock failed
> 
> This is quite strange, normally it should never fail and, in all the
> time version 5 has been available the maximum number of read locks has
> never been exceeded.
> 
> Is there anything unusual going on like a server down causing autofs
> to issue a number of mounts that are all waiting to time out?

Not that I know.  If I reboot the system into 2.6.23 or 2.6.23-git,
things work just fine though.  That makes me think the server is not
the issue.
 
> > Oct 20 00:38:52 kenny automount[2293]: unexpected pthreads error:
> > 11 at 65 in cache.c
> 
> Mmm .. if this is a genuine autofs issue maybe I need to handle EAGAIN
> returns but that would mean blocking which probably isn't good and I'd
> rather not if we can avoid it.

I do not know if this an autofs issue or the result of something
else in 2.6.23-mm1.

> > I am not sure if this is due to autofs changes or changes in some
> > other code that was merged.  If you can think of any suspicious
> > change that I should test, please let me know.
> > 
> 
> Is there anything in the log, an autofs4 kernel trace perhaps?

Nope, the only two lines that I found in the log are above...

Nothing in dmesg either.

-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-mm1 - autofs broken

[Rik van Riel]

On Mon, 22 Oct 2007 11:45:19 +0800
Ian Kent [EMAIL PROTECTED] wrote:

  Oct 20 00:38:52 kenny automount[2293]: cache_readlock: mapent cache
  rwlock lock failed
 
 This is quite strange, normally it should never fail and, in all the
 time version 5 has been available the maximum number of read locks has
 never been exceeded.
 
 Is there anything unusual going on like a server down causing autofs
 to issue a number of mounts that are all waiting to time out?

Not that I know.  If I reboot the system into 2.6.23 or 2.6.23-git,
things work just fine though.  That makes me think the server is not
the issue.
 
  Oct 20 00:38:52 kenny automount[2293]: unexpected pthreads error:
  11 at 65 in cache.c
 
 Mmm .. if this is a genuine autofs issue maybe I need to handle EAGAIN
 returns but that would mean blocking which probably isn't good and I'd
 rather not if we can avoid it.

I do not know if this an autofs issue or the result of something
else in 2.6.23-mm1.

  I am not sure if this is due to autofs changes or changes in some
  other code that was merged.  If you can think of any suspicious
  change that I should test, please let me know.
  
 
 Is there anything in the log, an autofs4 kernel trace perhaps?

Nope, the only two lines that I found in the log are above...

Nothing in dmesg either.

-- 
Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it. - Brian W. Kernighan
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-mm1 - autofs broken

[Dave Hansen]

On Sat, 2007-10-20 at 10:56 -0400, Rik van Riel wrote:
 I just tried it.  In the latest git tree, autofs still works.
 
 The regression is in -mm only.

Andrew,

Rik tracked it down to an interaction with futexes from the pid
namespace code.  I believe r/o bind mounts are innocent for now.

-- Dave

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-mm1 - autofs broken

[Ian Kent]

On Sat, 2007-10-20 at 01:13 -0400, Rik van Riel wrote:
> On Thu, 11 Oct 2007 21:31:26 -0700
> Andrew Morton <[EMAIL PROTECTED]> wrote:
> 
> > 
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm1/
> > 
> > - I've been largely avoiding applying anything since rc8-mm2 in an
> > attempt to stabilise things for the 2.6.23 merge.
> 
> Between rc8-mm2 and 2.6.23-mm1, autofs stopped working in the
> -mm kernel.
> 
> Instead of mounting my home directory, I get these messages in
> /var/log/messages:
> 
> Oct 20 00:38:52 kenny automount[2293]: cache_readlock: mapent cache
> rwlock lock failed

This is quite strange, normally it should never fail and, in all the
time version 5 has been available the maximum number of read locks has
never been exceeded.

Is there anything unusual going on like a server down causing autofs to
issue a number of mounts that are all waiting to time out?

> Oct 20 00:38:52 kenny automount[2293]: unexpected pthreads error: 11 at
> 65 in cache.c

Mmm .. if this is a genuine autofs issue maybe I need to handle EAGAIN
returns but that would mean blocking which probably isn't good and I'd
rather not if we can avoid it.

> 
> I am not sure if this is due to autofs changes or changes in some other
> code that was merged.  If you can think of any suspicious change that
> I should test, please let me know.
> 

Is there anything in the log, an autofs4 kernel trace perhaps?

Ian

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: mysqld prevents s2ram [Re: 2.6.23-mm1]

[Rafael J. Wysocki]

On Sunday, 21 October 2007 11:58, Pavel Machek wrote:
> Hi!
> 
> > On Thu, Oct 11, 2007 at 09:31:26PM -0700, Andrew Morton wrote:
> > > 
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm1/
> > 
> > Ok, now that it boots let's go for more.
> > 
> > I cannot suspend if mysqld is running. mysql isn't atually doing
> > anything useful anyway.
> 
> I believe this is known and rafael already has a fix somewhere. The
> "guilty" patch already hit mainline, not sure about the "fix" patch.

The fix has not been merged yet, but
freezer-use-wait-queue-instead-of-busy-looping.patch has been dropped for
another reason.

The mysqld problem seems to have been caused by another patch, though, and the
fix is appended.

Greetings,
Rafael


---
From: Rafael J. Wysocki <[EMAIL PROTECTED]>

Do not allow processes to clear their TIF_SIGPENDING if TIF_FREEZE is set,
so that they will not race with the freezer (like mysqld, for example).

Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
---
 kernel/signal.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux-2.6.23-mm1/kernel/signal.c
===
--- linux-2.6.23-mm1.orig/kernel/signal.c
+++ linux-2.6.23-mm1/kernel/signal.c
@@ -124,7 +124,7 @@ void recalc_sigpending_and_wake(struct t
 
 void recalc_sigpending(void)
 {
-   if (!recalc_sigpending_tsk(current))
+   if (!recalc_sigpending_tsk(current) && !freezing(current))
clear_thread_flag(TIF_SIGPENDING);
 
 }
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: mysqld prevents s2ram [Re: 2.6.23-mm1]

[Pavel Machek]

Hi!

> On Thu, Oct 11, 2007 at 09:31:26PM -0700, Andrew Morton wrote:
> > 
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm1/
> 
> Ok, now that it boots let's go for more.
> 
> I cannot suspend if mysqld is running. mysql isn't atually doing
> anything useful anyway.

I believe this is known and rafael already has a fix somewhere. The
"guilty" patch already hit mainline, not sure about the "fix" patch.

Pavel


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-mm1 - regression- PowerPC link failure at arch/powerpc/kernel/head_64.o

[Kamalesh Babulal]

Kamalesh Babulal wrote:
> Andrew Morton wrote:
>> On Tue, 16 Oct 2007 12:48:48 +0530 Kamalesh Babulal <[EMAIL PROTECTED]> 
>> wrote:
>>
>>> Hi Andrew,
>>>
>>> The link failure while compiling the kernel with allyesconfig over the 
>>> lpar, 
>>> which was seen in 2.6.23-rc8-mm2 (http://lkml.org/lkml/2007/9/30/2) is 
>>> still 
>>> seen in 2.6.23-mm1, the link failure is
>>>
>>> ld: arch/powerpc/kernel/head_64.o(.text+0x80c8): sibling call optimization 
>>> to `.text.init.refok' does not allow automatic multiple TOCs; recompile 
>>> with -mminimal-toc or -fno-optimize-sibling-calls, or make 
>>> `.text.init.refok' extern
>>> ld: arch/powerpc/kernel/head_64.o(.text+0x8160): sibling call optimization 
>>> to `.text.init.refok' does not allow automatic multiple TOCs; recompile 
>>> with -mminimal-toc or -fno-optimize-sibling-calls, or make 
>>> `.text.init.refok' extern
>>> ld: arch/powerpc/kernel/head_64.o(.text+0x81c4): sibling call optimization 
>>> to `.text.init.refok' does not allow automatic multiple TOCs; recompile 
>>> with -mminimal-toc or -fno-optimize-sibling-calls, or make 
>>> `.text.init.refok' extern
>>> ld: final link failed: Bad value
>>> make: *** [.tmp_vmlinux1] Error 1
>>>
>>> # gcc -v
>>> Using built-in specs.
>>> Target: powerpc64-suse-linux
>>> Configured with: ../configure --enable-threads=posix --prefix=/usr 
>>> --with-local-prefix=/usr/local --infodir=/usr/share/info 
>>> --mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib 
>>> --enable-languages=c,c++,objc,fortran,obj-c++,java,ada 
>>> --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.1.2 
>>> --enable-ssp --disable-libssp --disable-libgcj --with-slibdir=/lib 
>>> --with-system-zlib --enable-shared --enable-__cxa_atexit 
>>> --enable-libstdcxx-allocator=new --program-suffix=-4.1 
>>> --enable-version-specific-runtime-libs --without-system-libunwind 
>>> --with-cpu=default32 --enable-secureplt --with-long-double-128 
>>> --host=powerpc64-suse-linux
>>> Thread model: posix
>>> gcc version 4.1.2 20061115 (prerelease) (SUSE Linux)
>>>
>>> ld -v
>>> GNU ld version 2.17.50.0.5 20060927 (SUSE Linux)
>>>
>>>
>>> Anything I can provide to help diagnose this?
>>>
>> Did we work out which patch is causing this?
>> -
> Hi Andrew,
> No, we did not work out on which patch is causing this ! I will try a bisect 
> to find the patch causing this issue.
> 
Hi Andrew,

After the bisecting, i found that the patch git-net.patch is the cause for the 
link failure.

-- 
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: mysqld prevents s2ram [Re: 2.6.23-mm1]

[Mattia Dongili]

On Sun, Oct 21, 2007 at 02:58:17PM +0900, Mattia Dongili wrote:
> On Thu, Oct 11, 2007 at 09:31:26PM -0700, Andrew Morton wrote:
> > 
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm1/
> 
> Ok, now that it boots let's go for more.
> 
> I cannot suspend if mysqld is running. mysql isn't atually doing
> anything useful anyway.
...
> As suggested in a different post I'll try reverting
> freezer-use-wait-queue-instead-of-busy-looping.patch and re-test

great, that was the guilty patch in fact.

-- 
mattia
:wq!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: mysqld prevents s2ram [Re: 2.6.23-mm1]

[Mattia Dongili]

On Sun, Oct 21, 2007 at 02:58:17PM +0900, Mattia Dongili wrote:
 On Thu, Oct 11, 2007 at 09:31:26PM -0700, Andrew Morton wrote:
  
  ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm1/
 
 Ok, now that it boots let's go for more.
 
 I cannot suspend if mysqld is running. mysql isn't atually doing
 anything useful anyway.
...
 As suggested in a different post I'll try reverting
 freezer-use-wait-queue-instead-of-busy-looping.patch and re-test

great, that was the guilty patch in fact.

-- 
mattia
:wq!
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-mm1 - regression- PowerPC link failure at arch/powerpc/kernel/head_64.o

[Kamalesh Babulal]

Kamalesh Babulal wrote:
 Andrew Morton wrote:
 On Tue, 16 Oct 2007 12:48:48 +0530 Kamalesh Babulal [EMAIL PROTECTED] 
 wrote:

 Hi Andrew,

 The link failure while compiling the kernel with allyesconfig over the 
 lpar, 
 which was seen in 2.6.23-rc8-mm2 (http://lkml.org/lkml/2007/9/30/2) is 
 still 
 seen in 2.6.23-mm1, the link failure is

 ld: arch/powerpc/kernel/head_64.o(.text+0x80c8): sibling call optimization 
 to `.text.init.refok' does not allow automatic multiple TOCs; recompile 
 with -mminimal-toc or -fno-optimize-sibling-calls, or make 
 `.text.init.refok' extern
 ld: arch/powerpc/kernel/head_64.o(.text+0x8160): sibling call optimization 
 to `.text.init.refok' does not allow automatic multiple TOCs; recompile 
 with -mminimal-toc or -fno-optimize-sibling-calls, or make 
 `.text.init.refok' extern
 ld: arch/powerpc/kernel/head_64.o(.text+0x81c4): sibling call optimization 
 to `.text.init.refok' does not allow automatic multiple TOCs; recompile 
 with -mminimal-toc or -fno-optimize-sibling-calls, or make 
 `.text.init.refok' extern
 ld: final link failed: Bad value
 make: *** [.tmp_vmlinux1] Error 1

 # gcc -v
 Using built-in specs.
 Target: powerpc64-suse-linux
 Configured with: ../configure --enable-threads=posix --prefix=/usr 
 --with-local-prefix=/usr/local --infodir=/usr/share/info 
 --mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib 
 --enable-languages=c,c++,objc,fortran,obj-c++,java,ada 
 --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.1.2 
 --enable-ssp --disable-libssp --disable-libgcj --with-slibdir=/lib 
 --with-system-zlib --enable-shared --enable-__cxa_atexit 
 --enable-libstdcxx-allocator=new --program-suffix=-4.1 
 --enable-version-specific-runtime-libs --without-system-libunwind 
 --with-cpu=default32 --enable-secureplt --with-long-double-128 
 --host=powerpc64-suse-linux
 Thread model: posix
 gcc version 4.1.2 20061115 (prerelease) (SUSE Linux)

 ld -v
 GNU ld version 2.17.50.0.5 20060927 (SUSE Linux)


 Anything I can provide to help diagnose this?

 Did we work out which patch is causing this?
 -
 Hi Andrew,
 No, we did not work out on which patch is causing this ! I will try a bisect 
 to find the patch causing this issue.
 
Hi Andrew,

After the bisecting, i found that the patch git-net.patch is the cause for the 
link failure.

-- 
Thanks  Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: mysqld prevents s2ram [Re: 2.6.23-mm1]

[Pavel Machek]

Hi!

 On Thu, Oct 11, 2007 at 09:31:26PM -0700, Andrew Morton wrote:
  
  ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm1/
 
 Ok, now that it boots let's go for more.
 
 I cannot suspend if mysqld is running. mysql isn't atually doing
 anything useful anyway.

I believe this is known and rafael already has a fix somewhere. The
guilty patch already hit mainline, not sure about the fix patch.

Pavel


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: mysqld prevents s2ram [Re: 2.6.23-mm1]

[Rafael J. Wysocki]

On Sunday, 21 October 2007 11:58, Pavel Machek wrote:
 Hi!
 
  On Thu, Oct 11, 2007 at 09:31:26PM -0700, Andrew Morton wrote:
   
   ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm1/
  
  Ok, now that it boots let's go for more.
  
  I cannot suspend if mysqld is running. mysql isn't atually doing
  anything useful anyway.
 
 I believe this is known and rafael already has a fix somewhere. The
 guilty patch already hit mainline, not sure about the fix patch.

The fix has not been merged yet, but
freezer-use-wait-queue-instead-of-busy-looping.patch has been dropped for
another reason.

The mysqld problem seems to have been caused by another patch, though, and the
fix is appended.

Greetings,
Rafael


---
From: Rafael J. Wysocki [EMAIL PROTECTED]

Do not allow processes to clear their TIF_SIGPENDING if TIF_FREEZE is set,
so that they will not race with the freezer (like mysqld, for example).

Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
---
 kernel/signal.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux-2.6.23-mm1/kernel/signal.c
===
--- linux-2.6.23-mm1.orig/kernel/signal.c
+++ linux-2.6.23-mm1/kernel/signal.c
@@ -124,7 +124,7 @@ void recalc_sigpending_and_wake(struct t
 
 void recalc_sigpending(void)
 {
-   if (!recalc_sigpending_tsk(current))
+   if (!recalc_sigpending_tsk(current)  !freezing(current))
clear_thread_flag(TIF_SIGPENDING);
 
 }
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-mm1 - autofs broken

[Ian Kent]

On Sat, 2007-10-20 at 01:13 -0400, Rik van Riel wrote:
 On Thu, 11 Oct 2007 21:31:26 -0700
 Andrew Morton [EMAIL PROTECTED] wrote:
 
  
  ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm1/
  
  - I've been largely avoiding applying anything since rc8-mm2 in an
  attempt to stabilise things for the 2.6.23 merge.
 
 Between rc8-mm2 and 2.6.23-mm1, autofs stopped working in the
 -mm kernel.
 
 Instead of mounting my home directory, I get these messages in
 /var/log/messages:
 
 Oct 20 00:38:52 kenny automount[2293]: cache_readlock: mapent cache
 rwlock lock failed

This is quite strange, normally it should never fail and, in all the
time version 5 has been available the maximum number of read locks has
never been exceeded.

Is there anything unusual going on like a server down causing autofs to
issue a number of mounts that are all waiting to time out?

 Oct 20 00:38:52 kenny automount[2293]: unexpected pthreads error: 11 at
 65 in cache.c

Mmm .. if this is a genuine autofs issue maybe I need to handle EAGAIN
returns but that would mean blocking which probably isn't good and I'd
rather not if we can avoid it.

 
 I am not sure if this is due to autofs changes or changes in some other
 code that was merged.  If you can think of any suspicious change that
 I should test, please let me know.
 

Is there anything in the log, an autofs4 kernel trace perhaps?

Ian

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

mysqld prevents s2ram [Re: 2.6.23-mm1]

[Mattia Dongili]

On Thu, Oct 11, 2007 at 09:31:26PM -0700, Andrew Morton wrote:
> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm1/

Ok, now that it boots let's go for more.

I cannot suspend if mysqld is running. mysql isn't atually doing
anything useful anyway.
This is the failed suspend tasks dump of mysql:
[0.00] Linux version 2.6.23-mm1-1 ([EMAIL PROTECTED]) (gcc version 
4.2.1 (Debian 4.2.1-3)) #5 SMP PREEMPT Sun Oct 21 13:50:54 JST 2007
...
[  271.736214] PM: Preparing system for mem sleep
[  271.738185] Freezing user space processes ... 
[  291.918090] Freezing of tasks failed after 20.19 seconds (1 tasks refusing 
to freeze):
[  291.918156]   taskPC stack   pid father
...
[  292.043105]  ===
[  292.043175] mysqld_safe   D c03d40c0 0  2393  1
[  292.043343]c26b3eac 0082 c03d0eb0 c03d40c0 c011a850 c011a843 
c2626aa0 c2626bd4 
[  292.043803]c17fd0c0  c26b3e88 c26cc380 c26b3ea8 c011b83a 
c26b3ea0  
[  292.044322]08104d08   08104d08  c26b3eb8 
c0141de0 c26b3fb8 
[  292.044843] Call Trace:
[  292.044969]  [] refrigerator+0xcf/0xdb
[  292.045091]  [] get_signal_to_deliver+0x33/0x414
[  292.045214]  [] do_notify_resume+0x81/0x61e
[  292.045335]  [] work_notifysig+0x13/0x19
[  292.045456]  ===
[  292.045524] mysqldD c03d40c0 0  2430   2393
[  292.045692]c25d0eac 0086 c03d0eb0 c03d40c0 c0119eb5  
c1c98550 c1c98684 
[  292.046184]c18060c0 0001 c25d0e88 c2603000 c25d0ea8 c011b83a 
c25d0ea0  
[  292.046705]     c25d0eb8 
c0141de0 c25d0fb8 
[  292.047272] Call Trace:
[  292.049112]  [] refrigerator+0xcf/0xdb
[  292.049234]  [] get_signal_to_deliver+0x33/0x414
[  292.049357]  [] do_notify_resume+0x81/0x61e
[  292.049477]  [] work_notifysig+0x13/0x19
[  292.049598]  ===
[  292.049666] mysqldD c03d40c0 0  2433   2393
[  292.049834]c3000eac 0086 c03d0eb0 c03d40c0   
c1c98aa0 c1c98bd4 
[  292.050306]c17fd0c0  c3000e88 c2603000 c3000ea8 c011b83a 
c3000ea0  
[  292.050827] 0001   0001 c3000eb8 
c0141de0 c3000fb8 
[  292.051353] Call Trace:
[  292.051479]  [] refrigerator+0xcf/0xdb
[  292.051599]  [] get_signal_to_deliver+0x33/0x414
[  292.051721]  [] do_notify_resume+0x81/0x61e
[  292.051842]  [] work_notifysig+0x13/0x19
[  292.051962]  ===
[  292.052031] mysqldD c03d40c0 0  2434   2393
[  292.052198]c27b6eac 0086 c03d0eb0 c03d40c0 c02d95a9 c27b6e8c 
c1d76aa0 c1d76bd4 
[  292.052660]c17fd0c0  c27b6e88 c2603000 c27b6ea8 c011b83a 
c27b6ea0  
[  292.053179] 0007   0007 c27b6eb8 
c0141de0 c27b6fb8 
[  292.053699] Call Trace:
[  292.053825]  [] refrigerator+0xcf/0xdb
[  292.053958]  [] get_signal_to_deliver+0x33/0x414
[  292.054081]  [] do_notify_resume+0x81/0x61e
[  292.054203]  [] work_notifysig+0x13/0x19
[  292.054323]  ===
[  292.054392] mysqldD c03d40c0 0  2435   2393
[  292.054560]c26b2eac 0086 c03d0eb0 c03d40c0 c0119eb5  
c1c42ff0 c1c43124 
[  292.055028]c18060c0 0001 c26b2e88 c2603000 c26b2ea8 c011b83a 
c26b2ea0  
[  292.055548] 0013   0013 c26b2eb8 
c0141de0 c26b2fb8 
[  292.056087] Call Trace:
[  292.056214]  [] refrigerator+0xcf/0xdb
[  292.056335]  [] get_signal_to_deliver+0x33/0x414
[  292.056458]  [] do_notify_resume+0x81/0x61e
[  292.056579]  [] work_notifysig+0x13/0x19
[  292.056700]  ===
[  292.056769] mysqldD c03d40c0 0  2436   2393
[  292.056937]c2776eac 0086 c03d0eb0 c03d40c0 c02d95a9 c2776e8c 
c26a7a90 c26a7bc4 
[  292.057398]c17fd0c0  c2776e88 c2603000 c2776ea8 c011b83a 
c2776ea0  
[  292.057930] 0003   0003 c2776eb8 
c0141de0 c2776fb8 
[  292.058450] Call Trace:
[  292.058576]  [] refrigerator+0xcf/0xdb
[  292.058696]  [] get_signal_to_deliver+0x33/0x414
[  292.058819]  [] do_notify_resume+0x81/0x61e
[  292.058945]  [] work_notifysig+0x13/0x19
[  292.059065]  ===
[  292.059134] mysqldD c03d40c0 0  2438   2393
[  292.059301]c254deac 0086 c03d0eb0 c03d40c0   
c1c9fa90 c1c9fbc4 
[  292.059762]c18060c0 0001 c254de88 c2603000 c254dea8 c011b83a 
c254dea0  
[  292.060281] b3435390   b3435390 c254deb8 
c0141de0 c254dfb8 
[  292.060801] Call Trace:
[  292.060927]  [] refrigerator+0xcf/0xdb
[  292.061047]  [] get_signal_to_deliver+0x33/0x414
[  292.061169]  [] do_notify_resume+0x81/0x61e
[  292.061290]  [] work_notifysig+0x13/0x19
[  292.061411]  ===
[  292.061479] mysqldD 

Re: oops in lbmIODone, fails to boot [Re: 2.6.23-mm1]

[Mattia Dongili]

On Sat, Oct 20, 2007 at 07:18:26AM -0500, Dave Kleikamp wrote:
> On Fri, 2007-10-19 at 22:34 -0700, Andrew Morton wrote:
> > On Sat, 20 Oct 2007 13:57:54 +0900 Mattia Dongili <[EMAIL PROTECTED]> wrote:
> > 
> > > On Thu, Oct 11, 2007 at 09:31:26PM -0700, Andrew Morton wrote:
> > > > 
> > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm1/
> > > 
> > > Hey there!!
> > > fails to boot here with this friendly oops:
> > > http://oioio.altervista.org/linux/dsc01702.jpg
> > > 
> > > .config: http://oioio.altervista.org/linux/config-2.6.23-mm1-1
> > > 
> > > 2.6.23-rc8-mm2 booted ok but had other problems I haven't reported yet
> > > (no s2ram with mysql running and some net WARNING).
> > > Let's see if .23-mm1 still has those first.
> > > 
> > > I'm adding Cc: linux-scsi
> > > 
> > > PS: I'll hardly be able to bisect in the next days... :P
> > 
> > That looks like a Jens and Dave production to me.
> 
> Yes, and it's been fixed:
> http://git.kernel.org/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=8d8fe64237646fdd2c2de2722ec4189a5999119d

thanks this fixes it
-- 
mattia
:wq!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-mm1 - autofs broken

[Rik van Riel]

On Sat, 20 Oct 2007 01:54:45 -0400
Rik van Riel <[EMAIL PROTECTED]> wrote:

> On Sat, 20 Oct 2007 01:54:04 -0400
> Rik van Riel <[EMAIL PROTECTED]> wrote:
> 
> > On Fri, 19 Oct 2007 22:39:00 -0700
> > Andrew Morton <[EMAIL PROTECTED]> wrote:
> > 
> > > On Sat, 20 Oct 2007 01:13:10 -0400 Rik van Riel <[EMAIL PROTECTED]>
> > > wrote:
> > > 
> > > > On Thu, 11 Oct 2007 21:31:26 -0700
> > > > Andrew Morton <[EMAIL PROTECTED]> wrote:
> > > > 
> > > > > 
> > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm1/
> > > > > 
> > > > > - I've been largely avoiding applying anything since rc8-mm2
> > > > > in an attempt to stabilise things for the 2.6.23 merge.
> > > > 
> > > > Between rc8-mm2 and 2.6.23-mm1, autofs stopped working in the
> > > > -mm kernel.
> > > > 
> > > > Instead of mounting my home directory, I get these messages in
> > > > /var/log/messages:
> > > > 
> > > > Oct 20 00:38:52 kenny automount[2293]: cache_readlock: mapent
> > > > cache rwlock lock failed
> > > > Oct 20 00:38:52 kenny automount[2293]: unexpected pthreads
> > > > error: 11 at 65 in cache.c
> > > > 
> > > > I am not sure if this is due to autofs changes or changes in
> > > > some other code that was merged.  If you can think of any
> > > > suspicious change that I should test, please let me know.
> > > 
> > > I don't think anything changed in autofs in that period.  I'd be
> > > suspecting the r-o-bind-mounts patches, but they didn't change
> > > much in that time either.
> > > 
> > > Does current mainline work OK?  If so, pretty much the only thing
> > > in that area left unmerged is r-o-bind-mounts and hch's exportfs
> > > stuff.
> > 
> > Yes, 2.6.23 mainline works fine.
> 
> Let me clarify: 2.6.23 vanilla works.
> 
> I have not yet tried the latest 2.6.23+ git tree.

I just tried it.  In the latest git tree, autofs still works.

The regression is in -mm only.

-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

oops in lbmIODone, fails to boot [Re: 2.6.23-mm1]

[Mattia Dongili]

On Thu, Oct 11, 2007 at 09:31:26PM -0700, Andrew Morton wrote:
> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm1/

Hey there!!
fails to boot here with this friendly oops:
http://oioio.altervista.org/linux/dsc01702.jpg

.config: http://oioio.altervista.org/linux/config-2.6.23-mm1-1

2.6.23-rc8-mm2 booted ok but had other problems I haven't reported yet
(no s2ram with mysql running and some net WARNING).
Let's see if .23-mm1 still has those first.

I'm adding Cc: linux-scsi

PS: I'll hardly be able to bisect in the next days... :P
-- 
mattia
:wq!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: oops in lbmIODone, fails to boot [Re: 2.6.23-mm1]

[Dave Kleikamp]

On Fri, 2007-10-19 at 22:34 -0700, Andrew Morton wrote:
> On Sat, 20 Oct 2007 13:57:54 +0900 Mattia Dongili <[EMAIL PROTECTED]> wrote:
> 
> > On Thu, Oct 11, 2007 at 09:31:26PM -0700, Andrew Morton wrote:
> > > 
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm1/
> > 
> > Hey there!!
> > fails to boot here with this friendly oops:
> > http://oioio.altervista.org/linux/dsc01702.jpg
> > 
> > .config: http://oioio.altervista.org/linux/config-2.6.23-mm1-1
> > 
> > 2.6.23-rc8-mm2 booted ok but had other problems I haven't reported yet
> > (no s2ram with mysql running and some net WARNING).
> > Let's see if .23-mm1 still has those first.
> > 
> > I'm adding Cc: linux-scsi
> > 
> > PS: I'll hardly be able to bisect in the next days... :P
> 
> That looks like a Jens and Dave production to me.

Yes, and it's been fixed:
http://git.kernel.org/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=8d8fe64237646fdd2c2de2722ec4189a5999119d

See also: http://lkml.org/lkml/2007/10/13/174

Thanks,
Shaggy
-- 
David Kleikamp
IBM Linux Technology Center

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-mm1 - autofs broken

[Rik van Riel]

On Sat, 20 Oct 2007 01:54:04 -0400
Rik van Riel <[EMAIL PROTECTED]> wrote:

> On Fri, 19 Oct 2007 22:39:00 -0700
> Andrew Morton <[EMAIL PROTECTED]> wrote:
> 
> > On Sat, 20 Oct 2007 01:13:10 -0400 Rik van Riel <[EMAIL PROTECTED]>
> > wrote:
> > 
> > > On Thu, 11 Oct 2007 21:31:26 -0700
> > > Andrew Morton <[EMAIL PROTECTED]> wrote:
> > > 
> > > > 
> > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm1/
> > > > 
> > > > - I've been largely avoiding applying anything since rc8-mm2 in
> > > > an attempt to stabilise things for the 2.6.23 merge.
> > > 
> > > Between rc8-mm2 and 2.6.23-mm1, autofs stopped working in the
> > > -mm kernel.
> > > 
> > > Instead of mounting my home directory, I get these messages in
> > > /var/log/messages:
> > > 
> > > Oct 20 00:38:52 kenny automount[2293]: cache_readlock: mapent
> > > cache rwlock lock failed
> > > Oct 20 00:38:52 kenny automount[2293]: unexpected pthreads error:
> > > 11 at 65 in cache.c
> > > 
> > > I am not sure if this is due to autofs changes or changes in some
> > > other code that was merged.  If you can think of any suspicious
> > > change that I should test, please let me know.
> > 
> > I don't think anything changed in autofs in that period.  I'd be
> > suspecting the r-o-bind-mounts patches, but they didn't change much
> > in that time either.
> > 
> > Does current mainline work OK?  If so, pretty much the only thing in
> > that area left unmerged is r-o-bind-mounts and hch's exportfs stuff.
> 
> Yes, 2.6.23 mainline works fine.

Let me clarify: 2.6.23 vanilla works.

I have not yet tried the latest 2.6.23+ git tree.

-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-mm1 - autofs broken

[Rik van Riel]

On Sat, 20 Oct 2007 01:54:04 -0400
Rik van Riel [EMAIL PROTECTED] wrote:

 On Fri, 19 Oct 2007 22:39:00 -0700
 Andrew Morton [EMAIL PROTECTED] wrote:
 
  On Sat, 20 Oct 2007 01:13:10 -0400 Rik van Riel [EMAIL PROTECTED]
  wrote:
  
   On Thu, 11 Oct 2007 21:31:26 -0700
   Andrew Morton [EMAIL PROTECTED] wrote:
   

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm1/

- I've been largely avoiding applying anything since rc8-mm2 in
an attempt to stabilise things for the 2.6.23 merge.
   
   Between rc8-mm2 and 2.6.23-mm1, autofs stopped working in the
   -mm kernel.
   
   Instead of mounting my home directory, I get these messages in
   /var/log/messages:
   
   Oct 20 00:38:52 kenny automount[2293]: cache_readlock: mapent
   cache rwlock lock failed
   Oct 20 00:38:52 kenny automount[2293]: unexpected pthreads error:
   11 at 65 in cache.c
   
   I am not sure if this is due to autofs changes or changes in some
   other code that was merged.  If you can think of any suspicious
   change that I should test, please let me know.
  
  I don't think anything changed in autofs in that period.  I'd be
  suspecting the r-o-bind-mounts patches, but they didn't change much
  in that time either.
  
  Does current mainline work OK?  If so, pretty much the only thing in
  that area left unmerged is r-o-bind-mounts and hch's exportfs stuff.
 
 Yes, 2.6.23 mainline works fine.

Let me clarify: 2.6.23 vanilla works.

I have not yet tried the latest 2.6.23+ git tree.

-- 
Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it. - Brian W. Kernighan
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: oops in lbmIODone, fails to boot [Re: 2.6.23-mm1]

[Dave Kleikamp]

On Fri, 2007-10-19 at 22:34 -0700, Andrew Morton wrote:
 On Sat, 20 Oct 2007 13:57:54 +0900 Mattia Dongili [EMAIL PROTECTED] wrote:
 
  On Thu, Oct 11, 2007 at 09:31:26PM -0700, Andrew Morton wrote:
   
   ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm1/
  
  Hey there!!
  fails to boot here with this friendly oops:
  http://oioio.altervista.org/linux/dsc01702.jpg
  
  .config: http://oioio.altervista.org/linux/config-2.6.23-mm1-1
  
  2.6.23-rc8-mm2 booted ok but had other problems I haven't reported yet
  (no s2ram with mysql running and some net WARNING).
  Let's see if .23-mm1 still has those first.
  
  I'm adding Cc: linux-scsi
  
  PS: I'll hardly be able to bisect in the next days... :P
 
 That looks like a Jens and Dave production to me.

Yes, and it's been fixed:
http://git.kernel.org/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=8d8fe64237646fdd2c2de2722ec4189a5999119d

See also: http://lkml.org/lkml/2007/10/13/174

Thanks,
Shaggy
-- 
David Kleikamp
IBM Linux Technology Center

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

oops in lbmIODone, fails to boot [Re: 2.6.23-mm1]

[Mattia Dongili]

On Thu, Oct 11, 2007 at 09:31:26PM -0700, Andrew Morton wrote:
 
 ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm1/

Hey there!!
fails to boot here with this friendly oops:
http://oioio.altervista.org/linux/dsc01702.jpg

.config: http://oioio.altervista.org/linux/config-2.6.23-mm1-1

2.6.23-rc8-mm2 booted ok but had other problems I haven't reported yet
(no s2ram with mysql running and some net WARNING).
Let's see if .23-mm1 still has those first.

I'm adding Cc: linux-scsi

PS: I'll hardly be able to bisect in the next days... :P
-- 
mattia
:wq!
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-mm1 - autofs broken

[Rik van Riel]

On Sat, 20 Oct 2007 01:54:45 -0400
Rik van Riel [EMAIL PROTECTED] wrote:

 On Sat, 20 Oct 2007 01:54:04 -0400
 Rik van Riel [EMAIL PROTECTED] wrote:
 
  On Fri, 19 Oct 2007 22:39:00 -0700
  Andrew Morton [EMAIL PROTECTED] wrote:
  
   On Sat, 20 Oct 2007 01:13:10 -0400 Rik van Riel [EMAIL PROTECTED]
   wrote:
   
On Thu, 11 Oct 2007 21:31:26 -0700
Andrew Morton [EMAIL PROTECTED] wrote:

 
 ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm1/
 
 - I've been largely avoiding applying anything since rc8-mm2
 in an attempt to stabilise things for the 2.6.23 merge.

Between rc8-mm2 and 2.6.23-mm1, autofs stopped working in the
-mm kernel.

Instead of mounting my home directory, I get these messages in
/var/log/messages:

Oct 20 00:38:52 kenny automount[2293]: cache_readlock: mapent
cache rwlock lock failed
Oct 20 00:38:52 kenny automount[2293]: unexpected pthreads
error: 11 at 65 in cache.c

I am not sure if this is due to autofs changes or changes in
some other code that was merged.  If you can think of any
suspicious change that I should test, please let me know.
   
   I don't think anything changed in autofs in that period.  I'd be
   suspecting the r-o-bind-mounts patches, but they didn't change
   much in that time either.
   
   Does current mainline work OK?  If so, pretty much the only thing
   in that area left unmerged is r-o-bind-mounts and hch's exportfs
   stuff.
  
  Yes, 2.6.23 mainline works fine.
 
 Let me clarify: 2.6.23 vanilla works.
 
 I have not yet tried the latest 2.6.23+ git tree.

I just tried it.  In the latest git tree, autofs still works.

The regression is in -mm only.

-- 
Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it. - Brian W. Kernighan
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: oops in lbmIODone, fails to boot [Re: 2.6.23-mm1]

[Mattia Dongili]

On Sat, Oct 20, 2007 at 07:18:26AM -0500, Dave Kleikamp wrote:
 On Fri, 2007-10-19 at 22:34 -0700, Andrew Morton wrote:
  On Sat, 20 Oct 2007 13:57:54 +0900 Mattia Dongili [EMAIL PROTECTED] wrote:
  
   On Thu, Oct 11, 2007 at 09:31:26PM -0700, Andrew Morton wrote:

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm1/
   
   Hey there!!
   fails to boot here with this friendly oops:
   http://oioio.altervista.org/linux/dsc01702.jpg
   
   .config: http://oioio.altervista.org/linux/config-2.6.23-mm1-1
   
   2.6.23-rc8-mm2 booted ok but had other problems I haven't reported yet
   (no s2ram with mysql running and some net WARNING).
   Let's see if .23-mm1 still has those first.
   
   I'm adding Cc: linux-scsi
   
   PS: I'll hardly be able to bisect in the next days... :P
  
  That looks like a Jens and Dave production to me.
 
 Yes, and it's been fixed:
 http://git.kernel.org/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=8d8fe64237646fdd2c2de2722ec4189a5999119d

thanks this fixes it
-- 
mattia
:wq!
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

mysqld prevents s2ram [Re: 2.6.23-mm1]

[Mattia Dongili]

On Thu, Oct 11, 2007 at 09:31:26PM -0700, Andrew Morton wrote:
 
 ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm1/

Ok, now that it boots let's go for more.

I cannot suspend if mysqld is running. mysql isn't atually doing
anything useful anyway.
This is the failed suspend tasks dump of mysql:
[0.00] Linux version 2.6.23-mm1-1 ([EMAIL PROTECTED]) (gcc version 
4.2.1 (Debian 4.2.1-3)) #5 SMP PREEMPT Sun Oct 21 13:50:54 JST 2007
...
[  271.736214] PM: Preparing system for mem sleep
[  271.738185] Freezing user space processes ... 
[  291.918090] Freezing of tasks failed after 20.19 seconds (1 tasks refusing 
to freeze):
[  291.918156]   taskPC stack   pid father
...
[  292.043105]  ===
[  292.043175] mysqld_safe   D c03d40c0 0  2393  1
[  292.043343]c26b3eac 0082 c03d0eb0 c03d40c0 c011a850 c011a843 
c2626aa0 c2626bd4 
[  292.043803]c17fd0c0  c26b3e88 c26cc380 c26b3ea8 c011b83a 
c26b3ea0  
[  292.044322]08104d08   08104d08  c26b3eb8 
c0141de0 c26b3fb8 
[  292.044843] Call Trace:
[  292.044969]  [c0141de0] refrigerator+0xcf/0xdb
[  292.045091]  [c012b4d2] get_signal_to_deliver+0x33/0x414
[  292.045214]  [c01034e8] do_notify_resume+0x81/0x61e
[  292.045335]  [c0103f06] work_notifysig+0x13/0x19
[  292.045456]  ===
[  292.045524] mysqldD c03d40c0 0  2430   2393
[  292.045692]c25d0eac 0086 c03d0eb0 c03d40c0 c0119eb5  
c1c98550 c1c98684 
[  292.046184]c18060c0 0001 c25d0e88 c2603000 c25d0ea8 c011b83a 
c25d0ea0  
[  292.046705]     c25d0eb8 
c0141de0 c25d0fb8 
[  292.047272] Call Trace:
[  292.049112]  [c0141de0] refrigerator+0xcf/0xdb
[  292.049234]  [c012b4d2] get_signal_to_deliver+0x33/0x414
[  292.049357]  [c01034e8] do_notify_resume+0x81/0x61e
[  292.049477]  [c0103f06] work_notifysig+0x13/0x19
[  292.049598]  ===
[  292.049666] mysqldD c03d40c0 0  2433   2393
[  292.049834]c3000eac 0086 c03d0eb0 c03d40c0   
c1c98aa0 c1c98bd4 
[  292.050306]c17fd0c0  c3000e88 c2603000 c3000ea8 c011b83a 
c3000ea0  
[  292.050827] 0001   0001 c3000eb8 
c0141de0 c3000fb8 
[  292.051353] Call Trace:
[  292.051479]  [c0141de0] refrigerator+0xcf/0xdb
[  292.051599]  [c012b4d2] get_signal_to_deliver+0x33/0x414
[  292.051721]  [c01034e8] do_notify_resume+0x81/0x61e
[  292.051842]  [c0103f06] work_notifysig+0x13/0x19
[  292.051962]  ===
[  292.052031] mysqldD c03d40c0 0  2434   2393
[  292.052198]c27b6eac 0086 c03d0eb0 c03d40c0 c02d95a9 c27b6e8c 
c1d76aa0 c1d76bd4 
[  292.052660]c17fd0c0  c27b6e88 c2603000 c27b6ea8 c011b83a 
c27b6ea0  
[  292.053179] 0007   0007 c27b6eb8 
c0141de0 c27b6fb8 
[  292.053699] Call Trace:
[  292.053825]  [c0141de0] refrigerator+0xcf/0xdb
[  292.053958]  [c012b4d2] get_signal_to_deliver+0x33/0x414
[  292.054081]  [c01034e8] do_notify_resume+0x81/0x61e
[  292.054203]  [c0103f06] work_notifysig+0x13/0x19
[  292.054323]  ===
[  292.054392] mysqldD c03d40c0 0  2435   2393
[  292.054560]c26b2eac 0086 c03d0eb0 c03d40c0 c0119eb5  
c1c42ff0 c1c43124 
[  292.055028]c18060c0 0001 c26b2e88 c2603000 c26b2ea8 c011b83a 
c26b2ea0  
[  292.055548] 0013   0013 c26b2eb8 
c0141de0 c26b2fb8 
[  292.056087] Call Trace:
[  292.056214]  [c0141de0] refrigerator+0xcf/0xdb
[  292.056335]  [c012b4d2] get_signal_to_deliver+0x33/0x414
[  292.056458]  [c01034e8] do_notify_resume+0x81/0x61e
[  292.056579]  [c0103f06] work_notifysig+0x13/0x19
[  292.056700]  ===
[  292.056769] mysqldD c03d40c0 0  2436   2393
[  292.056937]c2776eac 0086 c03d0eb0 c03d40c0 c02d95a9 c2776e8c 
c26a7a90 c26a7bc4 
[  292.057398]c17fd0c0  c2776e88 c2603000 c2776ea8 c011b83a 
c2776ea0  
[  292.057930] 0003   0003 c2776eb8 
c0141de0 c2776fb8 
[  292.058450] Call Trace:
[  292.058576]  [c0141de0] refrigerator+0xcf/0xdb
[  292.058696]  [c012b4d2] get_signal_to_deliver+0x33/0x414
[  292.058819]  [c01034e8] do_notify_resume+0x81/0x61e
[  292.058945]  [c0103f06] work_notifysig+0x13/0x19
[  292.059065]  ===
[  292.059134] mysqldD c03d40c0 0  2438   2393
[  292.059301]c254deac 0086 c03d0eb0 c03d40c0   
c1c9fa90 c1c9fbc4 
[  292.059762]c18060c0 0001 c254de88 c2603000 c254dea8 c011b83a 
c254dea0  
[  292.060281] b3435390   b3435390 c254deb8 
c0141de0 c254dfb8 
[  292.060801] Call Trace:
[  292.060927]  [c0141de0] refrigerator+0xcf/0xdb
[  292.061047]  

Re: 2.6.23-mm1 - autofs broken

[Rik van Riel]

On Fri, 19 Oct 2007 22:39:00 -0700
Andrew Morton <[EMAIL PROTECTED]> wrote:

> On Sat, 20 Oct 2007 01:13:10 -0400 Rik van Riel <[EMAIL PROTECTED]>
> wrote:
> 
> > On Thu, 11 Oct 2007 21:31:26 -0700
> > Andrew Morton <[EMAIL PROTECTED]> wrote:
> > 
> > > 
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm1/
> > > 
> > > - I've been largely avoiding applying anything since rc8-mm2 in an
> > > attempt to stabilise things for the 2.6.23 merge.
> > 
> > Between rc8-mm2 and 2.6.23-mm1, autofs stopped working in the
> > -mm kernel.
> > 
> > Instead of mounting my home directory, I get these messages in
> > /var/log/messages:
> > 
> > Oct 20 00:38:52 kenny automount[2293]: cache_readlock: mapent cache
> > rwlock lock failed
> > Oct 20 00:38:52 kenny automount[2293]: unexpected pthreads error:
> > 11 at 65 in cache.c
> > 
> > I am not sure if this is due to autofs changes or changes in some
> > other code that was merged.  If you can think of any suspicious
> > change that I should test, please let me know.
> 
> I don't think anything changed in autofs in that period.  I'd be
> suspecting the r-o-bind-mounts patches, but they didn't change much
> in that time either.
> 
> Does current mainline work OK?  If so, pretty much the only thing in
> that area left unmerged is r-o-bind-mounts and hch's exportfs stuff.

Yes, 2.6.23 mainline works fine.

-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-mm1 - autofs broken

[Andrew Morton]

On Sat, 20 Oct 2007 01:13:10 -0400 Rik van Riel <[EMAIL PROTECTED]> wrote:

> On Thu, 11 Oct 2007 21:31:26 -0700
> Andrew Morton <[EMAIL PROTECTED]> wrote:
> 
> > 
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm1/
> > 
> > - I've been largely avoiding applying anything since rc8-mm2 in an
> > attempt to stabilise things for the 2.6.23 merge.
> 
> Between rc8-mm2 and 2.6.23-mm1, autofs stopped working in the
> -mm kernel.
> 
> Instead of mounting my home directory, I get these messages in
> /var/log/messages:
> 
> Oct 20 00:38:52 kenny automount[2293]: cache_readlock: mapent cache
> rwlock lock failed
> Oct 20 00:38:52 kenny automount[2293]: unexpected pthreads error: 11 at
> 65 in cache.c
> 
> I am not sure if this is due to autofs changes or changes in some other
> code that was merged.  If you can think of any suspicious change that
> I should test, please let me know.

I don't think anything changed in autofs in that period.  I'd be suspecting
the r-o-bind-mounts patches, but they didn't change much in that time
either.

Does current mainline work OK?  If so, pretty much the only thing in that
area left unmerged is r-o-bind-mounts and hch's exportfs stuff.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: oops in lbmIODone, fails to boot [Re: 2.6.23-mm1]

[Andrew Morton]

On Sat, 20 Oct 2007 13:57:54 +0900 Mattia Dongili <[EMAIL PROTECTED]> wrote:

> On Thu, Oct 11, 2007 at 09:31:26PM -0700, Andrew Morton wrote:
> > 
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm1/
> 
> Hey there!!
> fails to boot here with this friendly oops:
> http://oioio.altervista.org/linux/dsc01702.jpg
> 
> .config: http://oioio.altervista.org/linux/config-2.6.23-mm1-1
> 
> 2.6.23-rc8-mm2 booted ok but had other problems I haven't reported yet
> (no s2ram with mysql running and some net WARNING).
> Let's see if .23-mm1 still has those first.
> 
> I'm adding Cc: linux-scsi
> 
> PS: I'll hardly be able to bisect in the next days... :P

That looks like a Jens and Dave production to me.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-mm1 - autofs broken

[Rik van Riel]

On Thu, 11 Oct 2007 21:31:26 -0700
Andrew Morton <[EMAIL PROTECTED]> wrote:

> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm1/
> 
> - I've been largely avoiding applying anything since rc8-mm2 in an
> attempt to stabilise things for the 2.6.23 merge.

Between rc8-mm2 and 2.6.23-mm1, autofs stopped working in the
-mm kernel.

Instead of mounting my home directory, I get these messages in
/var/log/messages:

Oct 20 00:38:52 kenny automount[2293]: cache_readlock: mapent cache
rwlock lock failed
Oct 20 00:38:52 kenny automount[2293]: unexpected pthreads error: 11 at
65 in cache.c

I am not sure if this is due to autofs changes or changes in some other
code that was merged.  If you can think of any suspicious change that
I should test, please let me know.

-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-mm1 - list_add corruption in cgroup

[Paul Menage]

On 10/17/07, Cedric Le Goater <[EMAIL PROTECTED]> wrote:
> Hello !
>
> While polling the contents of a cgroup task file, I caught the
> following corruption. Is there a known race (and a fix) or should
> I start digging ?
>
>  list_add corruption. next->prev should be prev (80a3f338), but was 
> 00200200. (next=810103dcbe90).
> [ cut here ]
> kernel BUG at /home/legoater/linux/2.6.23-mm1/lib/list_debug.c:27!
> invalid opcode:  [1] SMP
> last sysfs file: /devices/pci:00/:00:1e.0/:01:01.0/local_cpus
> CPU 3
> Modules linked in: ipt_REJECT iptable_filter autofs4 nfs lockd sunrpc tg3 sg 
> joydev ext3 jbd ehci_hcd ohci_hcd uhci_hcd
> Pid: 2441, comm: bash Not tainted 2.6.23-mm1 #4
> RIP: 0010:[]  [] __list_add+0x27/0x5b
> RSP: 0018:810103d87dd8  EFLAGS: 00010296
> RAX: 0079 RBX: 810105033040 RCX: 0079
> RDX: 810103d960c0 RSI: 0001 RDI: 0096
> RBP: 810103d87dd8 R08: 0002 R09: 810008123780
> R10:  R11: 810103d87a98 R12: 
> R13: 810105033040 R14: 810104c11ac0 R15: 
> FS:  7f4e273556f0() GS:81010011a840() knlGS:
> CS:  0010 DS:  ES:  CR0: 8005003b
> CR2: 006ca2f8 CR3: 000103d82000 CR4: 06e0
> DR0:  DR1:  DR2: 
> DR3:  DR6: 0ff0 DR7: 0400
> Process bash (pid: 2441, threadinfo 810103d86000, task 810103d960c0)
> last branch before last exception/interrupt
>  from  [] printk+0x68/0x69
>  to  [] __list_add+0x27/0x5b
> Stack:  810103d87de8 80308d1a 810103d87e08 802606bf
>  810103d87e08  810103d87ea8 80233dca
>  810103ddf340 7f4e27355780  810103d87f58
> Call Trace:
>  [] list_add+0xc/0xe
>  [] cgroup_post_fork+0x41/0x52
>  [] copy_process+0x12d0/0x143a
>  [] tracesys+0xdc/0xe1
>  [] do_fork+0x76/0x203
>  [] audit_syscall_entry+0x148/0x17e
>  [] tracesys+0xdc/0xe1
>  [] sys_clone+0x23/0x25
>  [] ptregscall_common+0x67/0xb0

This is a crash on

list_add(>cg_list, >cgroups->tasks);

in cgroup_post_fork(). So it looks like child->cgroups->tasks.next is
a deleted list element. But there are no places that modify that list
outside of write_lock(_set_lock) as far as I can see, so I'm a bit
confused as to what the problem could be. I'll try to reproduce this.

Paul
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-mm1

[Jiri Kosina]

On Wed, 17 Oct 2007, KAMEZAWA Hiroyuki wrote:

> > hm, I guess this is probably due to pie-randomization patch, right? 
> > (could you please try reverting it, to see whether things get back to 
> > normal).
> Maybe this can be fix.

Andrew,

below is a fixed version with patch from Kamezawa Hiroyuki incorporated. 
It fixes the small regression Kamezawa found just at the time you sent 
merge request for this patch to Linus -- that ia32 ELF binaires on x86_64 
were able to allocate only about 2/3 of memory they were able to allocate 
without this patch. Apart from this fix, the patch is the same as it has 
been in -mm tree for quite some time.

It'd be great if it could make it for 2.6.24, if feasible. Thanks.


From: Jiri Kosina <[EMAIL PROTECTED]>
Subject: PIE executable randomization

This patch is using mmap()'s randomization functionality in such a way
that it maps the main executable of (specially compiled/linked -pie/-fpie)
ET_DYN binaries onto a random address (in cases in which mmap() is allowed
to perform a randomization).

The code has been extraced from Ingo's exec-shield patch
http://people.redhat.com/mingo/exec-shield/

[EMAIL PROTECTED]: fix used-uninitialsied warning]
[EMAIL PROTECTED]: fixed ia32 ELF on x86_64 handling]
Signed-off-by: Jiri Kosina <[EMAIL PROTECTED]>

diff --git a/arch/ia64/ia32/binfmt_elf32.c b/arch/ia64/ia32/binfmt_elf32.c
index f6ae3ec..3db699b 100644
--- a/arch/ia64/ia32/binfmt_elf32.c
+++ b/arch/ia64/ia32/binfmt_elf32.c
@@ -226,7 +226,7 @@ elf32_set_personality (void)
 }
 
 static unsigned long
-elf32_map (struct file *filep, unsigned long addr, struct elf_phdr *eppnt, int 
prot, int type)
+elf32_map (struct file *filep, unsigned long addr, struct elf_phdr *eppnt, int 
prot, int type, unsigned long unused)
 {
unsigned long pgoff = (eppnt->p_vaddr) & ~IA32_PAGE_MASK;
 
diff --git a/arch/x86/kernel/sys_x86_64.c b/arch/x86/kernel/sys_x86_64.c
index 907942e..95485e6 100644
--- a/arch/x86/kernel/sys_x86_64.c
+++ b/arch/x86/kernel/sys_x86_64.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -65,6 +66,7 @@ static void find_start_end(unsigned long flags, unsigned long 
*begin,
   unsigned long *end)
 {
if (!test_thread_flag(TIF_IA32) && (flags & MAP_32BIT)) {
+   unsigned long new_begin;
/* This is usually used needed to map code in small
   model, so it needs to be in the first 31bit. Limit
   it to that.  This means we need to move the
@@ -74,6 +76,11 @@ static void find_start_end(unsigned long flags, unsigned 
long *begin,
   of playground for now. -AK */ 
*begin = 0x4000; 
*end = 0x8000;  
+   if (current->flags & PF_RANDOMIZE) {
+   new_begin = randomize_range(*begin, *begin + 
0x0200, 0);
+   if (new_begin)
+   *begin = new_begin;
+   }
} else {
*begin = TASK_UNMAPPED_BASE;
*end = TASK_SIZE; 
@@ -143,6 +150,97 @@ full_search:
}
 }
 
+
+unsigned long
+arch_get_unmapped_area_topdown(struct file *filp, const unsigned long addr0,
+ const unsigned long len, const unsigned long pgoff,
+ const unsigned long flags)
+{
+   struct vm_area_struct *vma;
+   struct mm_struct *mm = current->mm;
+   unsigned long addr = addr0;
+
+   /* requested length too big for entire address space */
+   if (len > TASK_SIZE)
+   return -ENOMEM;
+
+   if (flags & MAP_FIXED)
+   return addr;
+
+   /* for MAP_32BIT mappings we force the legact mmap base */
+   if (!test_thread_flag(TIF_IA32) && (flags & MAP_32BIT))
+   goto bottomup;
+
+   /* requesting a specific address */
+   if (addr) {
+   addr = PAGE_ALIGN(addr);
+   vma = find_vma(mm, addr);
+   if (TASK_SIZE - len >= addr &&
+   (!vma || addr + len <= vma->vm_start))
+   return addr;
+   }
+
+   /* check if free_area_cache is useful for us */
+   if (len <= mm->cached_hole_size) {
+   mm->cached_hole_size = 0;
+   mm->free_area_cache = mm->mmap_base;
+   }
+
+   /* either no address requested or can't fit in requested address hole */
+   addr = mm->free_area_cache;
+
+   /* make sure it can fit in the remaining address space */
+   if (addr > len) {
+   vma = find_vma(mm, addr-len);
+   if (!vma || addr <= vma->vm_start)
+   /* remember the address as a hint for next time */
+   return (mm->free_area_cache = addr-len);
+   }
+
+   if (mm->mmap_base < len)
+   goto bottomup;
+
+   addr = mm->mmap_base-len;
+
+   do {
+   /*
+ 

Re: 2.6.23-mm1 s390 driver problem

[Martin Schwidefsky]

On Fri, 2007-10-19 at 13:17 +0200, Cedric Le Goater wrote:
> > please cc netdev on network issues.
> 
> yes.
> 
> >> Bringing up interface eth0:  Ý cut here ¨ 
> >> Kernel BUG at 0002 Ýverbose debug info unavailable¨ 
> >> illegal operation: 0001 Ý#1¨ 
> > 
> > that's a network issue ;)
> > 
> >> 002b3352 gives : include/linux/netdevice.h:819
> >>
> > 
> > I have a feeling that we fixed this.  But there's no BUG at 2.6.23-mm1's
> > include/linux/netdevice.h:819.  
> 
> but dev->header_ops is bogus. right ?
> 
> > How about setting CONFIG_DEBUG_BUGVERBOSE=y?
> 
> it is set :(

This is definitly a problem with the header_ops in the qeth network
driver. I've asked our network team to take care of it. Stay tuned..

-- 
blue skies,
  Martin.

"Reality continues to ruin my life." - Calvin.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-mm1 s390 driver problem

[Cedric Le Goater]

>> that helped going a little further in the boot process but we then have 
>> a network issue when bringing the network interface up :
> 
> please cc netdev on network issues.

yes.

>> Bringing up interface eth0:  Ý cut here ¨ 
>> Kernel BUG at 0002 Ýverbose debug info unavailable¨ 
>> illegal operation: 0001 Ý#1¨ 
>> Modules linked in: 
>> CPU:0Not tainted 
>> Process ip (pid: 1167, task: 01d46038, ksp: 025efb28) 
>> Krnl PSW : 070420018000 0002 (0x2) 
>>R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:0 CC:2 PM:0 EA:3 
>> Krnl GPRS:   0241f600 01c8d
>>86dd 01eb6d70  01c8d
>>01eb6d40 003abc28 01eb6d00 025ef
>>0241f600 003b6d18 002b33d2 025ef
>> Krnl Code:>0002:    unknown 
>>0004:    unknown 
>>0006:    unknown 
>>0008:    unknown 
>>000a:    unknown 
>>000c:    unknown 
>>000e:    unknown 
>>0010:    unknown 
>> Call Trace: 
>> (Ý<002b3352>¨ neigh_connected_output+0x76/0x138) 
>>  Ý<00325402>¨ ip6_output2+0x2da/0x470 
>>  Ý<00326ea6>¨ ip6_output+0x816/0x1064 
>>  Ý<00338e46>¨ __ndisc_send+0x416/0x6a8 
>>  Ý<00339330>¨ ndisc_send_rs+0x58/0x68 
>>  Ý<0032cbf4>¨ addrconf_dad_completed+0xbc/0x100 
>>  Ý<0032d2de>¨ addrconf_dad_start+0xa2/0x14c 
>>  Ý<0032d408>¨ addrconf_add_linklocal+0x80/0xa8 
>>  Ý<0032fa7e>¨ addrconf_notify+0x2de/0x8d4 
>>  Ý<00383990>¨ notifier_call_chain+0x5c/0x98 
>>  Ý<00063bca>¨ __raw_notifier_call_chain+0x26/0x34 
>>  Ý<00063c06>¨ raw_notifier_call_chain+0x2e/0x3c 
>>  Ý<002aa54c>¨ call_netdevice_notifiers+0x34/0x44 
>>  Ý<002ad1aa>¨ dev_open+0x9e/0xe0 
>>  Ý<002ad80a>¨ dev_change_flags+0x9e/0x1cc 
>>  Ý<00302c74>¨ devinet_ioctl+0x650/0x73c 
>>  Ý<003050ba>¨ inet_ioctl+0xde/0xf4 
>>  Ý<0029a8d0>¨ sock_ioctl+0x1cc/0x2dc 
>>  Ý<000cb844>¨ do_ioctl+0xb8/0xcc 
>>  Ý<000cb8f2>¨ vfs_ioctl+0x9a/0x3ec 
>>  Ý<000cbc96>¨ sys_ioctl+0x52/0x7c 
>>  Ý<00022484>¨ sysc_noemu+0x10/0x16 
>>  Ý<0210df12>¨ 0x210df12 
> 
> that's a network issue ;)
> 
>> 002b3352 gives : include/linux/netdevice.h:819
>>
> 
> I have a feeling that we fixed this.  But there's no BUG at 2.6.23-mm1's
> include/linux/netdevice.h:819.  

but dev->header_ops is bogus. right ?

> How about setting CONFIG_DEBUG_BUGVERBOSE=y?

it is set :(

C.
 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-mm1 s390 driver problem

[Cedric Le Goater]

Martin Schwidefsky wrote:
> On Fri, 2007-10-19 at 11:16 +0200, Cedric Le Goater wrote:
>>> This is the vmlinux.lds.S problem. The cleanup patch from Sam Ravnborg
>>> moved the __initramfs_start and __initramfs_end symbols into
>>> the .init.ramfs section. This is in itself not a problem, but it
>>> surfaced a bug: there is no *(.init.initramfs), that needs to be
>>> *(init.ramfs). I corrected this in the upstream patch but 2.6.23-mm1 has
>>> the older one that still causes the "Cannot open root device". For
>>> 2.6.23-mm1 use the patch below.
>>>
>> thanks martin, 
>>
>> that helped going a little further in the boot process but we then have 
>> a network issue when bringing the network interface up :
> 
> See http://marc.info/?l=linux-kernel=119270398931208=2

hmm, that doesn't fix the oops.

/me looking.

Thanks,

C.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-mm1 s390 driver problem

[Andrew Morton]

On Fri, 19 Oct 2007 11:16:16 +0200 Cedric Le Goater <[EMAIL PROTECTED]> wrote:

> Martin Schwidefsky wrote:
> > On Thu, 2007-10-18 at 15:31 -0500, Serge E. Hallyn wrote:
> >> Quoting Christian Borntraeger ([EMAIL PROTECTED]):
> >>> Am Donnerstag, 18. Oktober 2007 schrieb Serge E. Hallyn:
>  Sigh, well this turned out less informative than I'd liked.
>  After bisecting 2.6.23 to 2.6.23-mm1, I found that
>  git-s390.patch is the one breaking my s390 boot :(
>  (Frown bc it's a conglomeration of patches0
> 
>  Symptom is:
>   "Cannot open root device "dasdd2" or unknown-block(94,14)"
>  even though dasdd2 appeared to be found earlier in the boot.  I also
>  get
> >>> Can you post the full console output from IPL to the unsuccessful end?
> >> Yeah, sorry, appended below.
> >>
> >> I had thought that the line
> >>sysctl table check failed: /sunrpc/transports .7249.14 Missing strategy
> >> meant that the fix referenced in http://lkml.org/lkml/2007/10/11/48
> >> would fix it, but it appeared to have no effect.
> > 
> > This is the vmlinux.lds.S problem. The cleanup patch from Sam Ravnborg
> > moved the __initramfs_start and __initramfs_end symbols into
> > the .init.ramfs section. This is in itself not a problem, but it
> > surfaced a bug: there is no *(.init.initramfs), that needs to be
> > *(init.ramfs). I corrected this in the upstream patch but 2.6.23-mm1 has
> > the older one that still causes the "Cannot open root device". For
> > 2.6.23-mm1 use the patch below.
> > 
> 
> thanks martin, 
> 
> that helped going a little further in the boot process but we then have 
> a network issue when bringing the network interface up :

please cc netdev on network issues.

> Bringing up interface eth0:  Ý cut here ¨ 
> Kernel BUG at 0002 Ýverbose debug info unavailable¨ 
> illegal operation: 0001 Ý#1¨ 
> Modules linked in: 
> CPU:0Not tainted 
> Process ip (pid: 1167, task: 01d46038, ksp: 025efb28) 
> Krnl PSW : 070420018000 0002 (0x2) 
>R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:0 CC:2 PM:0 EA:3 
> Krnl GPRS:   0241f600 01c8d
>86dd 01eb6d70  01c8d
>01eb6d40 003abc28 01eb6d00 025ef
>0241f600 003b6d18 002b33d2 025ef
> Krnl Code:>0002:    unknown 
>0004:    unknown 
>0006:    unknown 
>0008:    unknown 
>000a:    unknown 
>000c:    unknown 
>000e:    unknown 
>0010:    unknown 
> Call Trace: 
> (Ý<002b3352>¨ neigh_connected_output+0x76/0x138) 
>  Ý<00325402>¨ ip6_output2+0x2da/0x470 
>  Ý<00326ea6>¨ ip6_output+0x816/0x1064 
>  Ý<00338e46>¨ __ndisc_send+0x416/0x6a8 
>  Ý<00339330>¨ ndisc_send_rs+0x58/0x68 
>  Ý<0032cbf4>¨ addrconf_dad_completed+0xbc/0x100 
>  Ý<0032d2de>¨ addrconf_dad_start+0xa2/0x14c 
>  Ý<0032d408>¨ addrconf_add_linklocal+0x80/0xa8 
>  Ý<0032fa7e>¨ addrconf_notify+0x2de/0x8d4 
>  Ý<00383990>¨ notifier_call_chain+0x5c/0x98 
>  Ý<00063bca>¨ __raw_notifier_call_chain+0x26/0x34 
>  Ý<00063c06>¨ raw_notifier_call_chain+0x2e/0x3c 
>  Ý<002aa54c>¨ call_netdevice_notifiers+0x34/0x44 
>  Ý<002ad1aa>¨ dev_open+0x9e/0xe0 
>  Ý<002ad80a>¨ dev_change_flags+0x9e/0x1cc 
>  Ý<00302c74>¨ devinet_ioctl+0x650/0x73c 
>  Ý<003050ba>¨ inet_ioctl+0xde/0xf4 
>  Ý<0029a8d0>¨ sock_ioctl+0x1cc/0x2dc 
>  Ý<000cb844>¨ do_ioctl+0xb8/0xcc 
>  Ý<000cb8f2>¨ vfs_ioctl+0x9a/0x3ec 
>  Ý<000cbc96>¨ sys_ioctl+0x52/0x7c 
>  Ý<00022484>¨ sysc_noemu+0x10/0x16 
>  Ý<0210df12>¨ 0x210df12 

that's a network issue ;)

> 002b3352 gives : include/linux/netdevice.h:819
> 

I have a feeling that we fixed this.  But there's no BUG at 2.6.23-mm1's
include/linux/netdevice.h:819.  How about setting
CONFIG_DEBUG_BUGVERBOSE=y?


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-mm1 s390 driver problem

[Martin Schwidefsky]

On Fri, 2007-10-19 at 11:16 +0200, Cedric Le Goater wrote:
> > This is the vmlinux.lds.S problem. The cleanup patch from Sam Ravnborg
> > moved the __initramfs_start and __initramfs_end symbols into
> > the .init.ramfs section. This is in itself not a problem, but it
> > surfaced a bug: there is no *(.init.initramfs), that needs to be
> > *(init.ramfs). I corrected this in the upstream patch but 2.6.23-mm1 has
> > the older one that still causes the "Cannot open root device". For
> > 2.6.23-mm1 use the patch below.
> > 
> 
> thanks martin, 
> 
> that helped going a little further in the boot process but we then have 
> a network issue when bringing the network interface up :

See http://marc.info/?l=linux-kernel=119270398931208=2
 
-- 
blue skies,
  Martin.

"Reality continues to ruin my life." - Calvin.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-mm1 s390 driver problem

[Cedric Le Goater]

Martin Schwidefsky wrote:
> On Thu, 2007-10-18 at 15:31 -0500, Serge E. Hallyn wrote:
>> Quoting Christian Borntraeger ([EMAIL PROTECTED]):
>>> Am Donnerstag, 18. Oktober 2007 schrieb Serge E. Hallyn:
 Sigh, well this turned out less informative than I'd liked.
 After bisecting 2.6.23 to 2.6.23-mm1, I found that
 git-s390.patch is the one breaking my s390 boot :(
 (Frown bc it's a conglomeration of patches0

 Symptom is:
"Cannot open root device "dasdd2" or unknown-block(94,14)"
 even though dasdd2 appeared to be found earlier in the boot.  I also
 get
>>> Can you post the full console output from IPL to the unsuccessful end?
>> Yeah, sorry, appended below.
>>
>> I had thought that the line
>>  sysctl table check failed: /sunrpc/transports .7249.14 Missing strategy
>> meant that the fix referenced in http://lkml.org/lkml/2007/10/11/48
>> would fix it, but it appeared to have no effect.
> 
> This is the vmlinux.lds.S problem. The cleanup patch from Sam Ravnborg
> moved the __initramfs_start and __initramfs_end symbols into
> the .init.ramfs section. This is in itself not a problem, but it
> surfaced a bug: there is no *(.init.initramfs), that needs to be
> *(init.ramfs). I corrected this in the upstream patch but 2.6.23-mm1 has
> the older one that still causes the "Cannot open root device". For
> 2.6.23-mm1 use the patch below.
> 

thanks martin, 

that helped going a little further in the boot process but we then have 
a network issue when bringing the network interface up :

Bringing up interface eth0:  Ý cut here ¨ 
Kernel BUG at 0002 Ýverbose debug info unavailable¨ 
illegal operation: 0001 Ý#1¨ 
Modules linked in: 
CPU:0Not tainted 
Process ip (pid: 1167, task: 01d46038, ksp: 025efb28) 
Krnl PSW : 070420018000 0002 (0x2) 
   R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:0 CC:2 PM:0 EA:3 
Krnl GPRS:   0241f600 01c8d
   86dd 01eb6d70  01c8d
   01eb6d40 003abc28 01eb6d00 025ef
   0241f600 003b6d18 002b33d2 025ef
Krnl Code:>0002:    unknown 
   0004:    unknown 
   0006:    unknown 
   0008:    unknown 
   000a:    unknown 
   000c:    unknown 
   000e:    unknown 
   0010:    unknown 
Call Trace: 
(Ý<002b3352>¨ neigh_connected_output+0x76/0x138) 
 Ý<00325402>¨ ip6_output2+0x2da/0x470 
 Ý<00326ea6>¨ ip6_output+0x816/0x1064 
 Ý<00338e46>¨ __ndisc_send+0x416/0x6a8 
 Ý<00339330>¨ ndisc_send_rs+0x58/0x68 
 Ý<0032cbf4>¨ addrconf_dad_completed+0xbc/0x100 
 Ý<0032d2de>¨ addrconf_dad_start+0xa2/0x14c 
 Ý<0032d408>¨ addrconf_add_linklocal+0x80/0xa8 
 Ý<0032fa7e>¨ addrconf_notify+0x2de/0x8d4 
 Ý<00383990>¨ notifier_call_chain+0x5c/0x98 
 Ý<00063bca>¨ __raw_notifier_call_chain+0x26/0x34 
 Ý<00063c06>¨ raw_notifier_call_chain+0x2e/0x3c 
 Ý<002aa54c>¨ call_netdevice_notifiers+0x34/0x44 
 Ý<002ad1aa>¨ dev_open+0x9e/0xe0 
 Ý<002ad80a>¨ dev_change_flags+0x9e/0x1cc 
 Ý<00302c74>¨ devinet_ioctl+0x650/0x73c 
 Ý<003050ba>¨ inet_ioctl+0xde/0xf4 
 Ý<0029a8d0>¨ sock_ioctl+0x1cc/0x2dc 
 Ý<000cb844>¨ do_ioctl+0xb8/0xcc 
 Ý<000cb8f2>¨ vfs_ioctl+0x9a/0x3ec 
 Ý<000cbc96>¨ sys_ioctl+0x52/0x7c 
 Ý<00022484>¨ sysc_noemu+0x10/0x16 
 Ý<0210df12>¨ 0x210df12 

002b3352 gives : include/linux/netdevice.h:819

C. 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

PIE randomization (was Re: 2.6.23-mm1)

[Jiri Kosina]

On Wed, 17 Oct 2007, KAMEZAWA Hiroyuki wrote:

> > yes, this looks correct to me. Did you verify that it makes the 
> > problem you are seeing go away?
> yes. I confirmed this works well.

Thanks a lot, it works flawlessly. I will rebase the patch after 
2.6.24-rc1 is released and will send it to Andrew's queue, hopefully for 
2.6.25.

Thanks!

-- 
Jiri Kosina
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-mm1 s390 driver problem

[Martin Schwidefsky]

On Thu, 2007-10-18 at 15:31 -0500, Serge E. Hallyn wrote:
> Quoting Christian Borntraeger ([EMAIL PROTECTED]):
> > Am Donnerstag, 18. Oktober 2007 schrieb Serge E. Hallyn:
> > > Sigh, well this turned out less informative than I'd liked.
> > > After bisecting 2.6.23 to 2.6.23-mm1, I found that
> > > git-s390.patch is the one breaking my s390 boot :(
> > > (Frown bc it's a conglomeration of patches0
> > > 
> > > Symptom is:
> > >   "Cannot open root device "dasdd2" or unknown-block(94,14)"
> > > even though dasdd2 appeared to be found earlier in the boot.  I also
> > > get
> > 
> > Can you post the full console output from IPL to the unsuccessful end?
> 
> Yeah, sorry, appended below.
> 
> I had thought that the line
>   sysctl table check failed: /sunrpc/transports .7249.14 Missing strategy
> meant that the fix referenced in http://lkml.org/lkml/2007/10/11/48
> would fix it, but it appeared to have no effect.

This is the vmlinux.lds.S problem. The cleanup patch from Sam Ravnborg
moved the __initramfs_start and __initramfs_end symbols into
the .init.ramfs section. This is in itself not a problem, but it
surfaced a bug: there is no *(.init.initramfs), that needs to be
*(init.ramfs). I corrected this in the upstream patch but 2.6.23-mm1 has
the older one that still causes the "Cannot open root device". For
2.6.23-mm1 use the patch below.

-- 
blue skies,
  Martin.

"Reality continues to ruin my life." - Calvin.

---
diff -urpN linux-2.6/arch/s390/kernel/vmlinux.lds.S 
linux-2.6-patched/arch/s390/kernel/vmlinux.lds.S
--- linux-2.6/arch/s390/kernel/vmlinux.lds.S2007-10-19 09:41:57.0 
+0200
+++ linux-2.6-patched/arch/s390/kernel/vmlinux.lds.S2007-10-19 
09:42:29.0 +0200
@@ -128,7 +128,7 @@ SECTIONS
. = ALIGN(0x100);
.init.ramfs : {
__initramfs_start = .;
-   *(.init.initramfs)
+   *(.init.ramfs)
. = ALIGN(2);
__initramfs_end = .;
}


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-mm1 s390 driver problem

[Cedric Le Goater]

Martin Schwidefsky wrote:
 On Fri, 2007-10-19 at 11:16 +0200, Cedric Le Goater wrote:
 This is the vmlinux.lds.S problem. The cleanup patch from Sam Ravnborg
 moved the __initramfs_start and __initramfs_end symbols into
 the .init.ramfs section. This is in itself not a problem, but it
 surfaced a bug: there is no *(.init.initramfs), that needs to be
 *(init.ramfs). I corrected this in the upstream patch but 2.6.23-mm1 has
 the older one that still causes the Cannot open root device. For
 2.6.23-mm1 use the patch below.

 thanks martin, 

 that helped going a little further in the boot process but we then have 
 a network issue when bringing the network interface up :
 
 See http://marc.info/?l=linux-kernelm=119270398931208w=2

hmm, that doesn't fix the oops.

/me looking.

Thanks,

C.


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-mm1 - list_add corruption in cgroup

[Paul Menage]

On 10/17/07, Cedric Le Goater [EMAIL PROTECTED] wrote:
 Hello !

 While polling the contents of a cgroup task file, I caught the
 following corruption. Is there a known race (and a fix) or should
 I start digging ?

  list_add corruption. next-prev should be prev (80a3f338), but was 
 00200200. (next=810103dcbe90).
 [ cut here ]
 kernel BUG at /home/legoater/linux/2.6.23-mm1/lib/list_debug.c:27!
 invalid opcode:  [1] SMP
 last sysfs file: /devices/pci:00/:00:1e.0/:01:01.0/local_cpus
 CPU 3
 Modules linked in: ipt_REJECT iptable_filter autofs4 nfs lockd sunrpc tg3 sg 
 joydev ext3 jbd ehci_hcd ohci_hcd uhci_hcd
 Pid: 2441, comm: bash Not tainted 2.6.23-mm1 #4
 RIP: 0010:[80308cda]  [80308cda] __list_add+0x27/0x5b
 RSP: 0018:810103d87dd8  EFLAGS: 00010296
 RAX: 0079 RBX: 810105033040 RCX: 0079
 RDX: 810103d960c0 RSI: 0001 RDI: 0096
 RBP: 810103d87dd8 R08: 0002 R09: 810008123780
 R10:  R11: 810103d87a98 R12: 
 R13: 810105033040 R14: 810104c11ac0 R15: 
 FS:  7f4e273556f0() GS:81010011a840() knlGS:
 CS:  0010 DS:  ES:  CR0: 8005003b
 CR2: 006ca2f8 CR3: 000103d82000 CR4: 06e0
 DR0:  DR1:  DR2: 
 DR3:  DR6: 0ff0 DR7: 0400
 Process bash (pid: 2441, threadinfo 810103d86000, task 810103d960c0)
 last branch before last exception/interrupt
  from  [80235885] printk+0x68/0x69
  to  [80308cda] __list_add+0x27/0x5b
 Stack:  810103d87de8 80308d1a 810103d87e08 802606bf
  810103d87e08  810103d87ea8 80233dca
  810103ddf340 7f4e27355780  810103d87f58
 Call Trace:
  [80308d1a] list_add+0xc/0xe
  [802606bf] cgroup_post_fork+0x41/0x52
  [80233dca] copy_process+0x12d0/0x143a
  [8020b9b5] tracesys+0xdc/0xe1
  [80234095] do_fork+0x76/0x203
  [802679cc] audit_syscall_entry+0x148/0x17e
  [8020b9b5] tracesys+0xdc/0xe1
  [80209dd5] sys_clone+0x23/0x25
  [8020bb67] ptregscall_common+0x67/0xb0

This is a crash on

list_add(child-cg_list, child-cgroups-tasks);

in cgroup_post_fork(). So it looks like child-cgroups-tasks.next is
a deleted list element. But there are no places that modify that list
outside of write_lock(css_set_lock) as far as I can see, so I'm a bit
confused as to what the problem could be. I'll try to reproduce this.

Paul
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-mm1

[Jiri Kosina]

On Wed, 17 Oct 2007, KAMEZAWA Hiroyuki wrote:

  hm, I guess this is probably due to pie-randomization patch, right? 
  (could you please try reverting it, to see whether things get back to 
  normal).
 Maybe this can be fix.

Andrew,

below is a fixed version with patch from Kamezawa Hiroyuki incorporated. 
It fixes the small regression Kamezawa found just at the time you sent 
merge request for this patch to Linus -- that ia32 ELF binaires on x86_64 
were able to allocate only about 2/3 of memory they were able to allocate 
without this patch. Apart from this fix, the patch is the same as it has 
been in -mm tree for quite some time.

It'd be great if it could make it for 2.6.24, if feasible. Thanks.


From: Jiri Kosina [EMAIL PROTECTED]
Subject: PIE executable randomization

This patch is using mmap()'s randomization functionality in such a way
that it maps the main executable of (specially compiled/linked -pie/-fpie)
ET_DYN binaries onto a random address (in cases in which mmap() is allowed
to perform a randomization).

The code has been extraced from Ingo's exec-shield patch
http://people.redhat.com/mingo/exec-shield/

[EMAIL PROTECTED]: fix used-uninitialsied warning]
[EMAIL PROTECTED]: fixed ia32 ELF on x86_64 handling]
Signed-off-by: Jiri Kosina [EMAIL PROTECTED]

diff --git a/arch/ia64/ia32/binfmt_elf32.c b/arch/ia64/ia32/binfmt_elf32.c
index f6ae3ec..3db699b 100644
--- a/arch/ia64/ia32/binfmt_elf32.c
+++ b/arch/ia64/ia32/binfmt_elf32.c
@@ -226,7 +226,7 @@ elf32_set_personality (void)
 }
 
 static unsigned long
-elf32_map (struct file *filep, unsigned long addr, struct elf_phdr *eppnt, int 
prot, int type)
+elf32_map (struct file *filep, unsigned long addr, struct elf_phdr *eppnt, int 
prot, int type, unsigned long unused)
 {
unsigned long pgoff = (eppnt-p_vaddr)  ~IA32_PAGE_MASK;
 
diff --git a/arch/x86/kernel/sys_x86_64.c b/arch/x86/kernel/sys_x86_64.c
index 907942e..95485e6 100644
--- a/arch/x86/kernel/sys_x86_64.c
+++ b/arch/x86/kernel/sys_x86_64.c
@@ -12,6 +12,7 @@
 #include linux/file.h
 #include linux/utsname.h
 #include linux/personality.h
+#include linux/random.h
 
 #include asm/uaccess.h
 #include asm/ia32.h
@@ -65,6 +66,7 @@ static void find_start_end(unsigned long flags, unsigned long 
*begin,
   unsigned long *end)
 {
if (!test_thread_flag(TIF_IA32)  (flags  MAP_32BIT)) {
+   unsigned long new_begin;
/* This is usually used needed to map code in small
   model, so it needs to be in the first 31bit. Limit
   it to that.  This means we need to move the
@@ -74,6 +76,11 @@ static void find_start_end(unsigned long flags, unsigned 
long *begin,
   of playground for now. -AK */ 
*begin = 0x4000; 
*end = 0x8000;  
+   if (current-flags  PF_RANDOMIZE) {
+   new_begin = randomize_range(*begin, *begin + 
0x0200, 0);
+   if (new_begin)
+   *begin = new_begin;
+   }
} else {
*begin = TASK_UNMAPPED_BASE;
*end = TASK_SIZE; 
@@ -143,6 +150,97 @@ full_search:
}
 }
 
+
+unsigned long
+arch_get_unmapped_area_topdown(struct file *filp, const unsigned long addr0,
+ const unsigned long len, const unsigned long pgoff,
+ const unsigned long flags)
+{
+   struct vm_area_struct *vma;
+   struct mm_struct *mm = current-mm;
+   unsigned long addr = addr0;
+
+   /* requested length too big for entire address space */
+   if (len  TASK_SIZE)
+   return -ENOMEM;
+
+   if (flags  MAP_FIXED)
+   return addr;
+
+   /* for MAP_32BIT mappings we force the legact mmap base */
+   if (!test_thread_flag(TIF_IA32)  (flags  MAP_32BIT))
+   goto bottomup;
+
+   /* requesting a specific address */
+   if (addr) {
+   addr = PAGE_ALIGN(addr);
+   vma = find_vma(mm, addr);
+   if (TASK_SIZE - len = addr 
+   (!vma || addr + len = vma-vm_start))
+   return addr;
+   }
+
+   /* check if free_area_cache is useful for us */
+   if (len = mm-cached_hole_size) {
+   mm-cached_hole_size = 0;
+   mm-free_area_cache = mm-mmap_base;
+   }
+
+   /* either no address requested or can't fit in requested address hole */
+   addr = mm-free_area_cache;
+
+   /* make sure it can fit in the remaining address space */
+   if (addr  len) {
+   vma = find_vma(mm, addr-len);
+   if (!vma || addr = vma-vm_start)
+   /* remember the address as a hint for next time */
+   return (mm-free_area_cache = addr-len);
+   }
+
+   if (mm-mmap_base  len)
+   goto bottomup;
+
+   addr = mm-mmap_base-len;
+
+

Re: 2.6.23-mm1 - autofs broken

[Rik van Riel]

On Thu, 11 Oct 2007 21:31:26 -0700
Andrew Morton [EMAIL PROTECTED] wrote:

 
 ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm1/
 
 - I've been largely avoiding applying anything since rc8-mm2 in an
 attempt to stabilise things for the 2.6.23 merge.

Between rc8-mm2 and 2.6.23-mm1, autofs stopped working in the
-mm kernel.

Instead of mounting my home directory, I get these messages in
/var/log/messages:

Oct 20 00:38:52 kenny automount[2293]: cache_readlock: mapent cache
rwlock lock failed
Oct 20 00:38:52 kenny automount[2293]: unexpected pthreads error: 11 at
65 in cache.c

I am not sure if this is due to autofs changes or changes in some other
code that was merged.  If you can think of any suspicious change that
I should test, please let me know.

-- 
Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it. - Brian W. Kernighan
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-mm1 s390 driver problem

[Martin Schwidefsky]

On Fri, 2007-10-19 at 13:17 +0200, Cedric Le Goater wrote:
  please cc netdev on network issues.
 
 yes.
 
  Bringing up interface eth0:  Ý cut here ¨ 
  Kernel BUG at 0002 Ýverbose debug info unavailable¨ 
  illegal operation: 0001 Ý#1¨ 
  
  that's a network issue ;)
  
  002b3352 gives : include/linux/netdevice.h:819
 
  
  I have a feeling that we fixed this.  But there's no BUG at 2.6.23-mm1's
  include/linux/netdevice.h:819.  
 
 but dev-header_ops is bogus. right ?
 
  How about setting CONFIG_DEBUG_BUGVERBOSE=y?
 
 it is set :(

This is definitly a problem with the header_ops in the qeth network
driver. I've asked our network team to take care of it. Stay tuned..

-- 
blue skies,
  Martin.

Reality continues to ruin my life. - Calvin.


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-mm1 s390 driver problem

[Andrew Morton]

On Fri, 19 Oct 2007 11:16:16 +0200 Cedric Le Goater [EMAIL PROTECTED] wrote:

 Martin Schwidefsky wrote:
  On Thu, 2007-10-18 at 15:31 -0500, Serge E. Hallyn wrote:
  Quoting Christian Borntraeger ([EMAIL PROTECTED]):
  Am Donnerstag, 18. Oktober 2007 schrieb Serge E. Hallyn:
  Sigh, well this turned out less informative than I'd liked.
  After bisecting 2.6.23 to 2.6.23-mm1, I found that
  git-s390.patch is the one breaking my s390 boot :(
  (Frown bc it's a conglomeration of patches0
 
  Symptom is:
   Cannot open root device dasdd2 or unknown-block(94,14)
  even though dasdd2 appeared to be found earlier in the boot.  I also
  get
  Can you post the full console output from IPL to the unsuccessful end?
  Yeah, sorry, appended below.
 
  I had thought that the line
 sysctl table check failed: /sunrpc/transports .7249.14 Missing strategy
  meant that the fix referenced in http://lkml.org/lkml/2007/10/11/48
  would fix it, but it appeared to have no effect.
  
  This is the vmlinux.lds.S problem. The cleanup patch from Sam Ravnborg
  moved the __initramfs_start and __initramfs_end symbols into
  the .init.ramfs section. This is in itself not a problem, but it
  surfaced a bug: there is no *(.init.initramfs), that needs to be
  *(init.ramfs). I corrected this in the upstream patch but 2.6.23-mm1 has
  the older one that still causes the Cannot open root device. For
  2.6.23-mm1 use the patch below.
  
 
 thanks martin, 
 
 that helped going a little further in the boot process but we then have 
 a network issue when bringing the network interface up :

please cc netdev on network issues.

 Bringing up interface eth0:  Ý cut here ¨ 
 Kernel BUG at 0002 Ýverbose debug info unavailable¨ 
 illegal operation: 0001 Ý#1¨ 
 Modules linked in: 
 CPU:0Not tainted 
 Process ip (pid: 1167, task: 01d46038, ksp: 025efb28) 
 Krnl PSW : 070420018000 0002 (0x2) 
R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:0 CC:2 PM:0 EA:3 
 Krnl GPRS:   0241f600 01c8d
86dd 01eb6d70  01c8d
01eb6d40 003abc28 01eb6d00 025ef
0241f600 003b6d18 002b33d2 025ef
 Krnl Code:0002:    unknown 
0004:    unknown 
0006:    unknown 
0008:    unknown 
000a:    unknown 
000c:    unknown 
000e:    unknown 
0010:    unknown 
 Call Trace: 
 (Ý002b3352¨ neigh_connected_output+0x76/0x138) 
  Ý00325402¨ ip6_output2+0x2da/0x470 
  Ý00326ea6¨ ip6_output+0x816/0x1064 
  Ý00338e46¨ __ndisc_send+0x416/0x6a8 
  Ý00339330¨ ndisc_send_rs+0x58/0x68 
  Ý0032cbf4¨ addrconf_dad_completed+0xbc/0x100 
  Ý0032d2de¨ addrconf_dad_start+0xa2/0x14c 
  Ý0032d408¨ addrconf_add_linklocal+0x80/0xa8 
  Ý0032fa7e¨ addrconf_notify+0x2de/0x8d4 
  Ý00383990¨ notifier_call_chain+0x5c/0x98 
  Ý00063bca¨ __raw_notifier_call_chain+0x26/0x34 
  Ý00063c06¨ raw_notifier_call_chain+0x2e/0x3c 
  Ý002aa54c¨ call_netdevice_notifiers+0x34/0x44 
  Ý002ad1aa¨ dev_open+0x9e/0xe0 
  Ý002ad80a¨ dev_change_flags+0x9e/0x1cc 
  Ý00302c74¨ devinet_ioctl+0x650/0x73c 
  Ý003050ba¨ inet_ioctl+0xde/0xf4 
  Ý0029a8d0¨ sock_ioctl+0x1cc/0x2dc 
  Ý000cb844¨ do_ioctl+0xb8/0xcc 
  Ý000cb8f2¨ vfs_ioctl+0x9a/0x3ec 
  Ý000cbc96¨ sys_ioctl+0x52/0x7c 
  Ý00022484¨ sysc_noemu+0x10/0x16 
  Ý0210df12¨ 0x210df12 

that's a network issue ;)

 002b3352 gives : include/linux/netdevice.h:819
 

I have a feeling that we fixed this.  But there's no BUG at 2.6.23-mm1's
include/linux/netdevice.h:819.  How about setting
CONFIG_DEBUG_BUGVERBOSE=y?


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-mm1 s390 driver problem

[Martin Schwidefsky]

On Fri, 2007-10-19 at 11:16 +0200, Cedric Le Goater wrote:
  This is the vmlinux.lds.S problem. The cleanup patch from Sam Ravnborg
  moved the __initramfs_start and __initramfs_end symbols into
  the .init.ramfs section. This is in itself not a problem, but it
  surfaced a bug: there is no *(.init.initramfs), that needs to be
  *(init.ramfs). I corrected this in the upstream patch but 2.6.23-mm1 has
  the older one that still causes the Cannot open root device. For
  2.6.23-mm1 use the patch below.
  
 
 thanks martin, 
 
 that helped going a little further in the boot process but we then have 
 a network issue when bringing the network interface up :

See http://marc.info/?l=linux-kernelm=119270398931208w=2
 
-- 
blue skies,
  Martin.

Reality continues to ruin my life. - Calvin.


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-mm1 s390 driver problem

[Cedric Le Goater]

Martin Schwidefsky wrote:
 On Thu, 2007-10-18 at 15:31 -0500, Serge E. Hallyn wrote:
 Quoting Christian Borntraeger ([EMAIL PROTECTED]):
 Am Donnerstag, 18. Oktober 2007 schrieb Serge E. Hallyn:
 Sigh, well this turned out less informative than I'd liked.
 After bisecting 2.6.23 to 2.6.23-mm1, I found that
 git-s390.patch is the one breaking my s390 boot :(
 (Frown bc it's a conglomeration of patches0

 Symptom is:
Cannot open root device dasdd2 or unknown-block(94,14)
 even though dasdd2 appeared to be found earlier in the boot.  I also
 get
 Can you post the full console output from IPL to the unsuccessful end?
 Yeah, sorry, appended below.

 I had thought that the line
  sysctl table check failed: /sunrpc/transports .7249.14 Missing strategy
 meant that the fix referenced in http://lkml.org/lkml/2007/10/11/48
 would fix it, but it appeared to have no effect.
 
 This is the vmlinux.lds.S problem. The cleanup patch from Sam Ravnborg
 moved the __initramfs_start and __initramfs_end symbols into
 the .init.ramfs section. This is in itself not a problem, but it
 surfaced a bug: there is no *(.init.initramfs), that needs to be
 *(init.ramfs). I corrected this in the upstream patch but 2.6.23-mm1 has
 the older one that still causes the Cannot open root device. For
 2.6.23-mm1 use the patch below.
 

thanks martin, 

that helped going a little further in the boot process but we then have 
a network issue when bringing the network interface up :

Bringing up interface eth0:  Ý cut here ¨ 
Kernel BUG at 0002 Ýverbose debug info unavailable¨ 
illegal operation: 0001 Ý#1¨ 
Modules linked in: 
CPU:0Not tainted 
Process ip (pid: 1167, task: 01d46038, ksp: 025efb28) 
Krnl PSW : 070420018000 0002 (0x2) 
   R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:0 CC:2 PM:0 EA:3 
Krnl GPRS:   0241f600 01c8d
   86dd 01eb6d70  01c8d
   01eb6d40 003abc28 01eb6d00 025ef
   0241f600 003b6d18 002b33d2 025ef
Krnl Code:0002:    unknown 
   0004:    unknown 
   0006:    unknown 
   0008:    unknown 
   000a:    unknown 
   000c:    unknown 
   000e:    unknown 
   0010:    unknown 
Call Trace: 
(Ý002b3352¨ neigh_connected_output+0x76/0x138) 
 Ý00325402¨ ip6_output2+0x2da/0x470 
 Ý00326ea6¨ ip6_output+0x816/0x1064 
 Ý00338e46¨ __ndisc_send+0x416/0x6a8 
 Ý00339330¨ ndisc_send_rs+0x58/0x68 
 Ý0032cbf4¨ addrconf_dad_completed+0xbc/0x100 
 Ý0032d2de¨ addrconf_dad_start+0xa2/0x14c 
 Ý0032d408¨ addrconf_add_linklocal+0x80/0xa8 
 Ý0032fa7e¨ addrconf_notify+0x2de/0x8d4 
 Ý00383990¨ notifier_call_chain+0x5c/0x98 
 Ý00063bca¨ __raw_notifier_call_chain+0x26/0x34 
 Ý00063c06¨ raw_notifier_call_chain+0x2e/0x3c 
 Ý002aa54c¨ call_netdevice_notifiers+0x34/0x44 
 Ý002ad1aa¨ dev_open+0x9e/0xe0 
 Ý002ad80a¨ dev_change_flags+0x9e/0x1cc 
 Ý00302c74¨ devinet_ioctl+0x650/0x73c 
 Ý003050ba¨ inet_ioctl+0xde/0xf4 
 Ý0029a8d0¨ sock_ioctl+0x1cc/0x2dc 
 Ý000cb844¨ do_ioctl+0xb8/0xcc 
 Ý000cb8f2¨ vfs_ioctl+0x9a/0x3ec 
 Ý000cbc96¨ sys_ioctl+0x52/0x7c 
 Ý00022484¨ sysc_noemu+0x10/0x16 
 Ý0210df12¨ 0x210df12 

002b3352 gives : include/linux/netdevice.h:819

C. 
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

PIE randomization (was Re: 2.6.23-mm1)

[Jiri Kosina]

On Wed, 17 Oct 2007, KAMEZAWA Hiroyuki wrote:

  yes, this looks correct to me. Did you verify that it makes the 
  problem you are seeing go away?
 yes. I confirmed this works well.

Thanks a lot, it works flawlessly. I will rebase the patch after 
2.6.24-rc1 is released and will send it to Andrew's queue, hopefully for 
2.6.25.

Thanks!

-- 
Jiri Kosina
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-mm1 s390 driver problem

[Cedric Le Goater]

 that helped going a little further in the boot process but we then have 
 a network issue when bringing the network interface up :
 
 please cc netdev on network issues.

yes.

 Bringing up interface eth0:  Ý cut here ¨ 
 Kernel BUG at 0002 Ýverbose debug info unavailable¨ 
 illegal operation: 0001 Ý#1¨ 
 Modules linked in: 
 CPU:0Not tainted 
 Process ip (pid: 1167, task: 01d46038, ksp: 025efb28) 
 Krnl PSW : 070420018000 0002 (0x2) 
R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:0 CC:2 PM:0 EA:3 
 Krnl GPRS:   0241f600 01c8d
86dd 01eb6d70  01c8d
01eb6d40 003abc28 01eb6d00 025ef
0241f600 003b6d18 002b33d2 025ef
 Krnl Code:0002:    unknown 
0004:    unknown 
0006:    unknown 
0008:    unknown 
000a:    unknown 
000c:    unknown 
000e:    unknown 
0010:    unknown 
 Call Trace: 
 (Ý002b3352¨ neigh_connected_output+0x76/0x138) 
  Ý00325402¨ ip6_output2+0x2da/0x470 
  Ý00326ea6¨ ip6_output+0x816/0x1064 
  Ý00338e46¨ __ndisc_send+0x416/0x6a8 
  Ý00339330¨ ndisc_send_rs+0x58/0x68 
  Ý0032cbf4¨ addrconf_dad_completed+0xbc/0x100 
  Ý0032d2de¨ addrconf_dad_start+0xa2/0x14c 
  Ý0032d408¨ addrconf_add_linklocal+0x80/0xa8 
  Ý0032fa7e¨ addrconf_notify+0x2de/0x8d4 
  Ý00383990¨ notifier_call_chain+0x5c/0x98 
  Ý00063bca¨ __raw_notifier_call_chain+0x26/0x34 
  Ý00063c06¨ raw_notifier_call_chain+0x2e/0x3c 
  Ý002aa54c¨ call_netdevice_notifiers+0x34/0x44 
  Ý002ad1aa¨ dev_open+0x9e/0xe0 
  Ý002ad80a¨ dev_change_flags+0x9e/0x1cc 
  Ý00302c74¨ devinet_ioctl+0x650/0x73c 
  Ý003050ba¨ inet_ioctl+0xde/0xf4 
  Ý0029a8d0¨ sock_ioctl+0x1cc/0x2dc 
  Ý000cb844¨ do_ioctl+0xb8/0xcc 
  Ý000cb8f2¨ vfs_ioctl+0x9a/0x3ec 
  Ý000cbc96¨ sys_ioctl+0x52/0x7c 
  Ý00022484¨ sysc_noemu+0x10/0x16 
  Ý0210df12¨ 0x210df12 
 
 that's a network issue ;)
 
 002b3352 gives : include/linux/netdevice.h:819

 
 I have a feeling that we fixed this.  But there's no BUG at 2.6.23-mm1's
 include/linux/netdevice.h:819.  

but dev-header_ops is bogus. right ?

 How about setting CONFIG_DEBUG_BUGVERBOSE=y?

it is set :(

C.
 

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-mm1 s390 driver problem

[Martin Schwidefsky]

On Thu, 2007-10-18 at 15:31 -0500, Serge E. Hallyn wrote:
 Quoting Christian Borntraeger ([EMAIL PROTECTED]):
  Am Donnerstag, 18. Oktober 2007 schrieb Serge E. Hallyn:
   Sigh, well this turned out less informative than I'd liked.
   After bisecting 2.6.23 to 2.6.23-mm1, I found that
   git-s390.patch is the one breaking my s390 boot :(
   (Frown bc it's a conglomeration of patches0
   
   Symptom is:
 Cannot open root device dasdd2 or unknown-block(94,14)
   even though dasdd2 appeared to be found earlier in the boot.  I also
   get
  
  Can you post the full console output from IPL to the unsuccessful end?
 
 Yeah, sorry, appended below.
 
 I had thought that the line
   sysctl table check failed: /sunrpc/transports .7249.14 Missing strategy
 meant that the fix referenced in http://lkml.org/lkml/2007/10/11/48
 would fix it, but it appeared to have no effect.

This is the vmlinux.lds.S problem. The cleanup patch from Sam Ravnborg
moved the __initramfs_start and __initramfs_end symbols into
the .init.ramfs section. This is in itself not a problem, but it
surfaced a bug: there is no *(.init.initramfs), that needs to be
*(init.ramfs). I corrected this in the upstream patch but 2.6.23-mm1 has
the older one that still causes the Cannot open root device. For
2.6.23-mm1 use the patch below.

-- 
blue skies,
  Martin.

Reality continues to ruin my life. - Calvin.

---
diff -urpN linux-2.6/arch/s390/kernel/vmlinux.lds.S 
linux-2.6-patched/arch/s390/kernel/vmlinux.lds.S
--- linux-2.6/arch/s390/kernel/vmlinux.lds.S2007-10-19 09:41:57.0 
+0200
+++ linux-2.6-patched/arch/s390/kernel/vmlinux.lds.S2007-10-19 
09:42:29.0 +0200
@@ -128,7 +128,7 @@ SECTIONS
. = ALIGN(0x100);
.init.ramfs : {
__initramfs_start = .;
-   *(.init.initramfs)
+   *(.init.ramfs)
. = ALIGN(2);
__initramfs_end = .;
}


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-mm1 - autofs broken

[Andrew Morton]

On Sat, 20 Oct 2007 01:13:10 -0400 Rik van Riel [EMAIL PROTECTED] wrote:

 On Thu, 11 Oct 2007 21:31:26 -0700
 Andrew Morton [EMAIL PROTECTED] wrote:
 
  
  ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm1/
  
  - I've been largely avoiding applying anything since rc8-mm2 in an
  attempt to stabilise things for the 2.6.23 merge.
 
 Between rc8-mm2 and 2.6.23-mm1, autofs stopped working in the
 -mm kernel.
 
 Instead of mounting my home directory, I get these messages in
 /var/log/messages:
 
 Oct 20 00:38:52 kenny automount[2293]: cache_readlock: mapent cache
 rwlock lock failed
 Oct 20 00:38:52 kenny automount[2293]: unexpected pthreads error: 11 at
 65 in cache.c
 
 I am not sure if this is due to autofs changes or changes in some other
 code that was merged.  If you can think of any suspicious change that
 I should test, please let me know.

I don't think anything changed in autofs in that period.  I'd be suspecting
the r-o-bind-mounts patches, but they didn't change much in that time
either.

Does current mainline work OK?  If so, pretty much the only thing in that
area left unmerged is r-o-bind-mounts and hch's exportfs stuff.

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: oops in lbmIODone, fails to boot [Re: 2.6.23-mm1]

[Andrew Morton]

On Sat, 20 Oct 2007 13:57:54 +0900 Mattia Dongili [EMAIL PROTECTED] wrote:

 On Thu, Oct 11, 2007 at 09:31:26PM -0700, Andrew Morton wrote:
  
  ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm1/
 
 Hey there!!
 fails to boot here with this friendly oops:
 http://oioio.altervista.org/linux/dsc01702.jpg
 
 .config: http://oioio.altervista.org/linux/config-2.6.23-mm1-1
 
 2.6.23-rc8-mm2 booted ok but had other problems I haven't reported yet
 (no s2ram with mysql running and some net WARNING).
 Let's see if .23-mm1 still has those first.
 
 I'm adding Cc: linux-scsi
 
 PS: I'll hardly be able to bisect in the next days... :P

That looks like a Jens and Dave production to me.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-mm1 - autofs broken

[Rik van Riel]

On Fri, 19 Oct 2007 22:39:00 -0700
Andrew Morton [EMAIL PROTECTED] wrote:

 On Sat, 20 Oct 2007 01:13:10 -0400 Rik van Riel [EMAIL PROTECTED]
 wrote:
 
  On Thu, 11 Oct 2007 21:31:26 -0700
  Andrew Morton [EMAIL PROTECTED] wrote:
  
   
   ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm1/
   
   - I've been largely avoiding applying anything since rc8-mm2 in an
   attempt to stabilise things for the 2.6.23 merge.
  
  Between rc8-mm2 and 2.6.23-mm1, autofs stopped working in the
  -mm kernel.
  
  Instead of mounting my home directory, I get these messages in
  /var/log/messages:
  
  Oct 20 00:38:52 kenny automount[2293]: cache_readlock: mapent cache
  rwlock lock failed
  Oct 20 00:38:52 kenny automount[2293]: unexpected pthreads error:
  11 at 65 in cache.c
  
  I am not sure if this is due to autofs changes or changes in some
  other code that was merged.  If you can think of any suspicious
  change that I should test, please let me know.
 
 I don't think anything changed in autofs in that period.  I'd be
 suspecting the r-o-bind-mounts patches, but they didn't change much
 in that time either.
 
 Does current mainline work OK?  If so, pretty much the only thing in
 that area left unmerged is r-o-bind-mounts and hch's exportfs stuff.

Yes, 2.6.23 mainline works fine.

-- 
Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it. - Brian W. Kernighan
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-mm1 s390 driver problem

[Serge E. Hallyn]

Quoting Christian Borntraeger ([EMAIL PROTECTED]):
> Am Donnerstag, 18. Oktober 2007 schrieb Serge E. Hallyn:
> > Sigh, well this turned out less informative than I'd liked.
> > After bisecting 2.6.23 to 2.6.23-mm1, I found that
> > git-s390.patch is the one breaking my s390 boot :(
> > (Frown bc it's a conglomeration of patches0
> > 
> > Symptom is:
> > "Cannot open root device "dasdd2" or unknown-block(94,14)"
> > even though dasdd2 appeared to be found earlier in the boot.  I also
> > get
> 
> Can you post the full console output from IPL to the unsuccessful end?

Yeah, sorry, appended below.

I had thought that the line
sysctl table check failed: /sunrpc/transports .7249.14 Missing strategy
meant that the fix referenced in http://lkml.org/lkml/2007/10/11/48
would fix it, but it appeared to have no effect.

thanks,
-serge




Linux version 2.6.23-mm1-g7692ccd6 ([EMAIL PROTECTED]) (gcc version 3.
4.2 20040907 (Red Hat 3.4.2-1)) #314 SMP PREEMPT Thu Oct 18 16:27:04 EDT 2007
We are running under VM (64 bit mode)
Detected 2 CPU's
Boot cpu address  0
Zone PFN ranges:
  DMA 0 ->   524288
  Normal 524288 ->   524288
Movable zone start PFN for each node
early_node_mapÝ1¨ active PFN ranges
0:0 ->65535
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 63872
Kernel command line: dasd=0.0.0201,0.0.0202,0.0.0250,0.0.0251 mem=256M root=/dev
/dasdd2 ro   noinitrd
PID hash table entries: 1024 (order: 10, 8192 bytes)
console ÝttyS0¨ enabled
Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
... MAX_LOCKDEP_SUBCLASSES:8
... MAX_LOCK_DEPTH:  30
... MAX_LOCKDEP_KEYS:2048
... CLASSHASH_SIZE:   1024
... MAX_LOCKDEP_ENTRIES: 8192
... MAX_LOCKDEP_CHAINS:  16384
... CHAINHASH_SIZE:  8192
 memory used by lock dependency info: 1712 kB
 per task-struct memory footprint: 2160 bytes
Dentry cache hash table entries: 32768 (order: 6, 262144 bytes)
Inode-cache hash table entries: 16384 (order: 5, 131072 bytes)
Memory: 243712k/262144k available (3217k kernel code, 0k reserved, 1651k data, 5
76k init)
Write protected kernel read-only data: 0x12000 - 0x477fff
Mount-cache hash table entries: 256
cpu 0 phys_idx=0 vers=FF ident=0210BC machine=2084 unused=8000
cpu 1 phys_idx=1 vers=FF ident=0210BC machine=2084 unused=8000
Brought up 2 CPUs
net_namespace: 152 bytes
NET: Registered protocol family 16
debug: Initialization complete
SCSI subsystem initialized
INFO: trying to register non-static key.
the code is fine but needs lockdep annotation.
turning off the locking correctness validator.
fffe 0002  015afc10
   015afb88 003c09d6 003c09d6 00014ef2
    0002 00486040 
    000d 015afb70 015afbe8
   00329368 00014ef2 015afb70 015afbc0
Call Trace:
(Ý<00014e24>¨ show_trace+0x9c/0xd0)
 Ý<00014f10>¨ show_stack+0xb8/0xc8
 Ý<00014f4e>¨ dump_stack+0x2e/0x3c
 Ý<0005c3d4>¨ __lock_acquire+0x21c/0x1010
 Ý<0005d4f0>¨ lock_acquire+0x98/0xc0
 Ý<000499e2>¨ run_workqueue+0x13e/0x240
 Ý<00049ba4>¨ worker_thread+0xc0/0xd8
 Ý<0004faf0>¨ kthread+0x68/0xa0
 Ý<00018f66>¨ kernel_thread_starter+0x6/0xc
 Ý<00018f60>¨ kernel_thread_starter+0x0/0xc

INFO: lockdep is turned off.
Time: tod clocksource has been installed.
NET: Registered protocol family 2
IP route cache hash table entries: 2048 (order: 2, 16384 bytes)
TCP established hash table entries: 8192 (order: 7, 589824 bytes)
TCP bind hash table entries: 8192 (order: 7, 589824 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
TCP reno registered
audit: initializing netlink socket (disabled)
audit(1192739358.161:1): initialized
Installing knfsd (copyright (C) 1996 [EMAIL PROTECTED]).
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
loop: module loaded
nbd: registered device at major 43
Ethernet Channel Bonding Driver: v3.1.3 (June 13, 2007)
bonding: Warning: either miimon or arp_interval and arp_ip_target module paramet
ers must be specified, otherwise bonding will not detect link failures! see bond
ing.txt for details.
Equalizer2002: Simon Janes ([EMAIL PROTECTED]) and David S. Miller ([EMAIL 
PROTECTED]
)
tun: Universal TUN/TAP device driver, 1.6
tun: (C) 1999-2004 Max Krasnyansky <[EMAIL PROTECTED]>
st: Version 20070203, fixed bufsize 32768, s/g segs 256
md: linear personality registered for level -1
md: raid0 personality registered for level 0
md: 

Re: 2.6.23-mm1 s390 driver problem

[Christian Borntraeger]

Am Donnerstag, 18. Oktober 2007 schrieb Serge E. Hallyn:
> Sigh, well this turned out less informative than I'd liked.
> After bisecting 2.6.23 to 2.6.23-mm1, I found that
> git-s390.patch is the one breaking my s390 boot :(
> (Frown bc it's a conglomeration of patches0
> 
> Symptom is:
>   "Cannot open root device "dasdd2" or unknown-block(94,14)"
> even though dasdd2 appeared to be found earlier in the boot.  I also
> get

Can you post the full console output from IPL to the unsuccessful end?

Thanks

Christian
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-mm1 - list_add corruption in cgroup

[Paul Menage]

On 10/17/07, Cedric Le Goater <[EMAIL PROTECTED]> wrote:
> Hello !
>
> While polling the contents of a cgroup task file, I caught the
> following corruption. Is there a known race (and a fix) or should
> I start digging ?

Not a known race, no. Sorry, didn't have time to look at this
yesterday since I was out of the office all day; I'll try to get a
chance today.

Paul

>
> the program running in the cgroup is fork/exec intensive:
>
>  while (1) {
> int i, s;
>
> for (i = 0; i < count; i++)
> if (fork() == 0)
> execlp("/bin/true", "true", 0);
>
> for (i = 0; i < count; i++)
> wait();
> }
>
> Thanks for any insights,
>
> C.
>
>
>
>  list_add corruption. next->prev should be prev (80a3f338), but was 
> 00200200. (next=810103dcbe90).
> [ cut here ]
> kernel BUG at /home/legoater/linux/2.6.23-mm1/lib/list_debug.c:27!
> invalid opcode:  [1] SMP
> last sysfs file: /devices/pci:00/:00:1e.0/:01:01.0/local_cpus
> CPU 3
> Modules linked in: ipt_REJECT iptable_filter autofs4 nfs lockd sunrpc tg3 sg 
> joydev ext3 jbd ehci_hcd ohci_hcd uhci_hcd
> Pid: 2441, comm: bash Not tainted 2.6.23-mm1 #4
> RIP: 0010:[]  [] __list_add+0x27/0x5b
> RSP: 0018:810103d87dd8  EFLAGS: 00010296
> RAX: 0079 RBX: 810105033040 RCX: 0079
> RDX: 810103d960c0 RSI: 0001 RDI: 0096
> RBP: 810103d87dd8 R08: 0002 R09: 810008123780
> R10:  R11: 810103d87a98 R12: 
> R13: 810105033040 R14: 810104c11ac0 R15: 
> FS:  7f4e273556f0() GS:81010011a840() knlGS:
> CS:  0010 DS:  ES:  CR0: 8005003b
> CR2: 006ca2f8 CR3: 000103d82000 CR4: 06e0
> DR0:  DR1:  DR2: 
> DR3:  DR6: 0ff0 DR7: 0400
> Process bash (pid: 2441, threadinfo 810103d86000, task 810103d960c0)
> last branch before last exception/interrupt
>  from  [] printk+0x68/0x69
>  to  [] __list_add+0x27/0x5b
> Stack:  810103d87de8 80308d1a 810103d87e08 802606bf
>  810103d87e08  810103d87ea8 80233dca
>  810103ddf340 7f4e27355780  810103d87f58
> Call Trace:
>  [] list_add+0xc/0xe
>  [] cgroup_post_fork+0x41/0x52
>  [] copy_process+0x12d0/0x143a
>  [] tracesys+0xdc/0xe1
>  [] do_fork+0x76/0x203
>  [] audit_syscall_entry+0x148/0x17e
>  [] tracesys+0xdc/0xe1
>  [] sys_clone+0x23/0x25
>  [] ptregscall_common+0x67/0xb0
>
> INFO: lockdep is turned off.
>
> Code: 0f 0b eb fe 4c 8b 00 49 39 f0 74 18 48 89 c1 4c 89 c2 48 c7
> RIP  [] __list_add+0x27/0x5b
>  RSP 
> BUG: soft lockup - CPU#1 stuck for 11s! [true:2030]
> CPU 1:
> Modules linked in: ipt_REJECT iptable_filter autofs4 nfs lockd sunrpc tg3 sg 
> joydev ext3 jbd ehci_hcd ohci_hcd uhci_hcd
> Pid: 2030, comm: true Tainted: G  D 2.6.23-mm1 #4
> RIP: 0010:[]  [] 
> __write_lock_failed+0xf/0x20
> RSP: 0018:81010513be80  EFLAGS: 0287
> RAX: 0001 RBX: 81010513be98 RCX: 807d8d60
> RDX: 0037 RSI: 0037 RDI: 805beac0
> RBP: 81010289e040 R08:  R09: 
> R10: 8026072c R11: 81010513be08 R12: 81000812c300
> R13: 81010289e040 R14: 81010513a000 R15: 810087acb000
> FS:  () GS:8101000560c0() knlGS:
> CS:  0010 DS:  ES:  CR0: 8005003b
> CR2: 7f8171b028b0 CR3: 00201000 CR4: 06e0
> DR0:  DR1:  DR2: 
> DR3:  DR6: 0ff0 DR7: 0400
>
> Call Trace:
>  [] _raw_write_lock+0x6c/0x8b
>  [] cgroup_exit+0x5c/0xc3
>  [] _write_lock+0x2d/0x31
>  [] cgroup_exit+0x5c/0xc3
>  [] do_exit+0x2a0/0x7a5
>  [] sys_exit_group+0x0/0x14
>  [] sys_exit_group+0x12/0x14
>  [] tracesys+0xdc/0xe1
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-mm1 - powerpc - Build fails at arch/powerpc/boot/inflate.o

[Kamalesh Babulal]

Paul Mackerras wrote:
> Kamalesh Babulal writes:
> 
>> The kernel build fails on the power box
>>
>>   INSTALL vdso64.so
>>
>>   INSTALL vdso32.so
>>
>>   BOOTCC  arch/powerpc/boot/inflate.o
>>
>> arch/powerpc/boot/inflate.c:920:19: error: errno.h: No such file or directory
> 
> This problem is fixed by d4faaecbcc6d9ea4f7c05f6de6af98e2336a4afb in
> Linus' tree.
> 
> Paul.
> -
Hi Paul,
Thanks, we tried it out over the 2.6.23-mm1 and the patch fixes the build 
failure.

-- 
Thanks & Regards,
Kamalesh Babulal,
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-mm1 - powerpc - Build fails at arch/powerpc/boot/inflate.o

[Paul Mackerras]

Kamalesh Babulal writes:

> The kernel build fails on the power box
> 
>   INSTALL vdso64.so
> 
>   INSTALL vdso32.so
> 
>   BOOTCC  arch/powerpc/boot/inflate.o
> 
> arch/powerpc/boot/inflate.c:920:19: error: errno.h: No such file or directory

This problem is fixed by d4faaecbcc6d9ea4f7c05f6de6af98e2336a4afb in
Linus' tree.

Paul.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-mm1 - powerpc - Build fails at arch/powerpc/boot/inflate.o

[Paul Mackerras]

Kamalesh Babulal writes:

 The kernel build fails on the power box
 
   INSTALL vdso64.so
 
   INSTALL vdso32.so
 
   BOOTCC  arch/powerpc/boot/inflate.o
 
 arch/powerpc/boot/inflate.c:920:19: error: errno.h: No such file or directory

This problem is fixed by d4faaecbcc6d9ea4f7c05f6de6af98e2336a4afb in
Linus' tree.

Paul.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-mm1 - powerpc - Build fails at arch/powerpc/boot/inflate.o

[Kamalesh Babulal]

Paul Mackerras wrote:
 Kamalesh Babulal writes:
 
 The kernel build fails on the power box

   INSTALL vdso64.so

   INSTALL vdso32.so

   BOOTCC  arch/powerpc/boot/inflate.o

 arch/powerpc/boot/inflate.c:920:19: error: errno.h: No such file or directory
 
 This problem is fixed by d4faaecbcc6d9ea4f7c05f6de6af98e2336a4afb in
 Linus' tree.
 
 Paul.
 -
Hi Paul,
Thanks, we tried it out over the 2.6.23-mm1 and the patch fixes the build 
failure.

-- 
Thanks  Regards,
Kamalesh Babulal,
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-mm1 - list_add corruption in cgroup

[Paul Menage]

On 10/17/07, Cedric Le Goater [EMAIL PROTECTED] wrote:
 Hello !

 While polling the contents of a cgroup task file, I caught the
 following corruption. Is there a known race (and a fix) or should
 I start digging ?

Not a known race, no. Sorry, didn't have time to look at this
yesterday since I was out of the office all day; I'll try to get a
chance today.

Paul


 the program running in the cgroup is fork/exec intensive:

  while (1) {
 int i, s;

 for (i = 0; i  count; i++)
 if (fork() == 0)
 execlp(/bin/true, true, 0);

 for (i = 0; i  count; i++)
 wait(s);
 }

 Thanks for any insights,

 C.



  list_add corruption. next-prev should be prev (80a3f338), but was 
 00200200. (next=810103dcbe90).
 [ cut here ]
 kernel BUG at /home/legoater/linux/2.6.23-mm1/lib/list_debug.c:27!
 invalid opcode:  [1] SMP
 last sysfs file: /devices/pci:00/:00:1e.0/:01:01.0/local_cpus
 CPU 3
 Modules linked in: ipt_REJECT iptable_filter autofs4 nfs lockd sunrpc tg3 sg 
 joydev ext3 jbd ehci_hcd ohci_hcd uhci_hcd
 Pid: 2441, comm: bash Not tainted 2.6.23-mm1 #4
 RIP: 0010:[80308cda]  [80308cda] __list_add+0x27/0x5b
 RSP: 0018:810103d87dd8  EFLAGS: 00010296
 RAX: 0079 RBX: 810105033040 RCX: 0079
 RDX: 810103d960c0 RSI: 0001 RDI: 0096
 RBP: 810103d87dd8 R08: 0002 R09: 810008123780
 R10:  R11: 810103d87a98 R12: 
 R13: 810105033040 R14: 810104c11ac0 R15: 
 FS:  7f4e273556f0() GS:81010011a840() knlGS:
 CS:  0010 DS:  ES:  CR0: 8005003b
 CR2: 006ca2f8 CR3: 000103d82000 CR4: 06e0
 DR0:  DR1:  DR2: 
 DR3:  DR6: 0ff0 DR7: 0400
 Process bash (pid: 2441, threadinfo 810103d86000, task 810103d960c0)
 last branch before last exception/interrupt
  from  [80235885] printk+0x68/0x69
  to  [80308cda] __list_add+0x27/0x5b
 Stack:  810103d87de8 80308d1a 810103d87e08 802606bf
  810103d87e08  810103d87ea8 80233dca
  810103ddf340 7f4e27355780  810103d87f58
 Call Trace:
  [80308d1a] list_add+0xc/0xe
  [802606bf] cgroup_post_fork+0x41/0x52
  [80233dca] copy_process+0x12d0/0x143a
  [8020b9b5] tracesys+0xdc/0xe1
  [80234095] do_fork+0x76/0x203
  [802679cc] audit_syscall_entry+0x148/0x17e
  [8020b9b5] tracesys+0xdc/0xe1
  [80209dd5] sys_clone+0x23/0x25
  [8020bb67] ptregscall_common+0x67/0xb0

 INFO: lockdep is turned off.

 Code: 0f 0b eb fe 4c 8b 00 49 39 f0 74 18 48 89 c1 4c 89 c2 48 c7
 RIP  [80308cda] __list_add+0x27/0x5b
  RSP 810103d87dd8
 BUG: soft lockup - CPU#1 stuck for 11s! [true:2030]
 CPU 1:
 Modules linked in: ipt_REJECT iptable_filter autofs4 nfs lockd sunrpc tg3 sg 
 joydev ext3 jbd ehci_hcd ohci_hcd uhci_hcd
 Pid: 2030, comm: true Tainted: G  D 2.6.23-mm1 #4
 RIP: 0010:[80306baf]  [80306baf] 
 __write_lock_failed+0xf/0x20
 RSP: 0018:81010513be80  EFLAGS: 0287
 RAX: 0001 RBX: 81010513be98 RCX: 807d8d60
 RDX: 0037 RSI: 0037 RDI: 805beac0
 RBP: 81010289e040 R08:  R09: 
 R10: 8026072c R11: 81010513be08 R12: 81000812c300
 R13: 81010289e040 R14: 81010513a000 R15: 810087acb000
 FS:  () GS:8101000560c0() knlGS:
 CS:  0010 DS:  ES:  CR0: 8005003b
 CR2: 7f8171b028b0 CR3: 00201000 CR4: 06e0
 DR0:  DR1:  DR2: 
 DR3:  DR6: 0ff0 DR7: 0400

 Call Trace:
  [80308a1d] _raw_write_lock+0x6c/0x8b
  [8026072c] cgroup_exit+0x5c/0xc3
  [80474803] _write_lock+0x2d/0x31
  [8026072c] cgroup_exit+0x5c/0xc3
  [802383c1] do_exit+0x2a0/0x7a5
  [80238955] sys_exit_group+0x0/0x14
  [80238967] sys_exit_group+0x12/0x14
  [8020b9b5] tracesys+0xdc/0xe1

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-mm1 s390 driver problem

[Christian Borntraeger]

Am Donnerstag, 18. Oktober 2007 schrieb Serge E. Hallyn:
 Sigh, well this turned out less informative than I'd liked.
 After bisecting 2.6.23 to 2.6.23-mm1, I found that
 git-s390.patch is the one breaking my s390 boot :(
 (Frown bc it's a conglomeration of patches0
 
 Symptom is:
   Cannot open root device dasdd2 or unknown-block(94,14)
 even though dasdd2 appeared to be found earlier in the boot.  I also
 get

Can you post the full console output from IPL to the unsuccessful end?

Thanks

Christian
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-mm1 s390 driver problem

[Serge E. Hallyn]

Quoting Christian Borntraeger ([EMAIL PROTECTED]):
 Am Donnerstag, 18. Oktober 2007 schrieb Serge E. Hallyn:
  Sigh, well this turned out less informative than I'd liked.
  After bisecting 2.6.23 to 2.6.23-mm1, I found that
  git-s390.patch is the one breaking my s390 boot :(
  (Frown bc it's a conglomeration of patches0
  
  Symptom is:
  Cannot open root device dasdd2 or unknown-block(94,14)
  even though dasdd2 appeared to be found earlier in the boot.  I also
  get
 
 Can you post the full console output from IPL to the unsuccessful end?

Yeah, sorry, appended below.

I had thought that the line
sysctl table check failed: /sunrpc/transports .7249.14 Missing strategy
meant that the fix referenced in http://lkml.org/lkml/2007/10/11/48
would fix it, but it appeared to have no effect.

thanks,
-serge




Linux version 2.6.23-mm1-g7692ccd6 ([EMAIL PROTECTED]) (gcc version 3.
4.2 20040907 (Red Hat 3.4.2-1)) #314 SMP PREEMPT Thu Oct 18 16:27:04 EDT 2007
We are running under VM (64 bit mode)
Detected 2 CPU's
Boot cpu address  0
Zone PFN ranges:
  DMA 0 -   524288
  Normal 524288 -   524288
Movable zone start PFN for each node
early_node_mapÝ1¨ active PFN ranges
0:0 -65535
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 63872
Kernel command line: dasd=0.0.0201,0.0.0202,0.0.0250,0.0.0251 mem=256M root=/dev
/dasdd2 ro   noinitrd
PID hash table entries: 1024 (order: 10, 8192 bytes)
console ÝttyS0¨ enabled
Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
... MAX_LOCKDEP_SUBCLASSES:8
... MAX_LOCK_DEPTH:  30
... MAX_LOCKDEP_KEYS:2048
... CLASSHASH_SIZE:   1024
... MAX_LOCKDEP_ENTRIES: 8192
... MAX_LOCKDEP_CHAINS:  16384
... CHAINHASH_SIZE:  8192
 memory used by lock dependency info: 1712 kB
 per task-struct memory footprint: 2160 bytes
Dentry cache hash table entries: 32768 (order: 6, 262144 bytes)
Inode-cache hash table entries: 16384 (order: 5, 131072 bytes)
Memory: 243712k/262144k available (3217k kernel code, 0k reserved, 1651k data, 5
76k init)
Write protected kernel read-only data: 0x12000 - 0x477fff
Mount-cache hash table entries: 256
cpu 0 phys_idx=0 vers=FF ident=0210BC machine=2084 unused=8000
cpu 1 phys_idx=1 vers=FF ident=0210BC machine=2084 unused=8000
Brought up 2 CPUs
net_namespace: 152 bytes
NET: Registered protocol family 16
debug: Initialization complete
SCSI subsystem initialized
INFO: trying to register non-static key.
the code is fine but needs lockdep annotation.
turning off the locking correctness validator.
fffe 0002  015afc10
   015afb88 003c09d6 003c09d6 00014ef2
    0002 00486040 
    000d 015afb70 015afbe8
   00329368 00014ef2 015afb70 015afbc0
Call Trace:
(Ý00014e24¨ show_trace+0x9c/0xd0)
 Ý00014f10¨ show_stack+0xb8/0xc8
 Ý00014f4e¨ dump_stack+0x2e/0x3c
 Ý0005c3d4¨ __lock_acquire+0x21c/0x1010
 Ý0005d4f0¨ lock_acquire+0x98/0xc0
 Ý000499e2¨ run_workqueue+0x13e/0x240
 Ý00049ba4¨ worker_thread+0xc0/0xd8
 Ý0004faf0¨ kthread+0x68/0xa0
 Ý00018f66¨ kernel_thread_starter+0x6/0xc
 Ý00018f60¨ kernel_thread_starter+0x0/0xc

INFO: lockdep is turned off.
Time: tod clocksource has been installed.
NET: Registered protocol family 2
IP route cache hash table entries: 2048 (order: 2, 16384 bytes)
TCP established hash table entries: 8192 (order: 7, 589824 bytes)
TCP bind hash table entries: 8192 (order: 7, 589824 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
TCP reno registered
audit: initializing netlink socket (disabled)
audit(1192739358.161:1): initialized
Installing knfsd (copyright (C) 1996 [EMAIL PROTECTED]).
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
loop: module loaded
nbd: registered device at major 43
Ethernet Channel Bonding Driver: v3.1.3 (June 13, 2007)
bonding: Warning: either miimon or arp_interval and arp_ip_target module paramet
ers must be specified, otherwise bonding will not detect link failures! see bond
ing.txt for details.
Equalizer2002: Simon Janes ([EMAIL PROTECTED]) and David S. Miller ([EMAIL 
PROTECTED]
)
tun: Universal TUN/TAP device driver, 1.6
tun: (C) 1999-2004 Max Krasnyansky [EMAIL PROTECTED]
st: Version 20070203, fixed bufsize 32768, s/g segs 256
md: linear personality registered for level -1
md: raid0 personality registered for level 0
md: raid1 personality registered for level 1
md: 

Re: 2.6.23-mm1 - build failure with advansys

[Matthew Wilcox]

On Thu, Oct 18, 2007 at 10:07:54AM +1000, Paul Mackerras wrote:
> The correct fix is to make advansys depend on CONFIG_VIRT_TO_BUS, or
> alternatively fix advansys.c properly by making it use the interfaces
> described in Documentation/DMA-mapping.txt (or the equivalent scsi
> helpers).

If you look at the git logs, you'll notice there's some progress towards
this.  It's already the case for the narrow boards.  I have a patch to
rip it all out for the wide boards, but there's clearly a bug because it
crashes my parisc machine.  Works fine on x86 though.  I can't work on
it this week because I'm travelling and the parisc machine with remote
power died on me last week.

I think I already suggested a temporary CONFIG_VIRT_TO_BUS dependency to
akpm last week.

-- 
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-mm1 - build failure with advansys

[Paul Mackerras]

Andrew Morton writes:

> On Sat, 13 Oct 2007 10:14:22 +0530 Kamalesh Babulal <[EMAIL PROTECTED]> wrote:

> > The functions virt_to_bus and bus_to_virt are begin defined between ifdef 
> > CONFIG_PPC32
> > but when i compile allyesconfig with ppc64 box,i get this error. This patch 
> > removes the
> > ifdef.

Which is totally bogus, because virt_to_bus/bus_to_virt only work on
systems without an IOMMU.  Most if not all ppc64 systems have one or
more IOMMUs.  This patch is nacked.

The correct fix is to make advansys depend on CONFIG_VIRT_TO_BUS, or
alternatively fix advansys.c properly by making it use the interfaces
described in Documentation/DMA-mapping.txt (or the equivalent scsi
helpers).

> Please copy the powerpc developers on powerpc patches.

Definitely.

Paul.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [2.6.23-mm1] CONFIG_LOCALVERSION handling broken

[Tilman Schmidt]

Am 14.10.2007 00:11 schrieb Tilman Schmidt:
> CONFIG_LOCALVERSION="-testing"
[...]
> has worked fine for all of 2.6.23{-rc?{,-mm?},}. For 2.6.23-mm1
> [there is] "make modules_install" installing the
> modules into /lib/modules/2.6.23-mm1 instead of
> /lib/modules/2.6.23-mm1-testing, and "make install" passing
> "2.6.23-mm1" without the "-testing" suffix to the install.sh
> script, but mkinitrd [...] looks for modules in
> /lib/modules/2.6.23-mm1-testing, so initrd creation fails.

I have investigated a bit more, and stumbled on this:

[EMAIL PROTECTED]:~/kernel/linux-2.6.23-mm1-work> make 
include/config/kernel.release
[EMAIL PROTECTED]:~/kernel/linux-2.6.23-mm1-work> cat 
include/config/kernel.release
2.6.23-mm1-testing
[EMAIL PROTECTED]:~/kernel/linux-2.6.23-mm1-work> make
  Using ARCH=i386 CROSS_COMPILE=
  CHK include/linux/version.h
  CHK include/linux/utsrelease.h
[...]
Kernel: arch/i386/boot/bzImage is ready  (#1)
  Building modules, stage 2.
  MODPOST 1085 modules
[EMAIL PROTECTED]:~/kernel/linux-2.6.23-mm1-work> cat 
include/config/kernel.release
2.6.23-mm1
[EMAIL PROTECTED]:~/kernel/linux-2.6.23-mm1-work>

Hmmm. "Curiouser and curiouser", said Alice.

So the content of the file include/config/kernel.release generated
by "make" varies depending on whether I ask "make" to create just
that file, or an entire kernel!? That runs against everything I
ever learned about "make"!

My ability to comprehend the inner workings of Kbuild ends here.
I'll just skip this -mm release and wait for 2.6.24-rc1, hoping
it won't have the same problem.

-- 
Tilman Schmidt  E-Mail: [EMAIL PROTECTED]
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)



signature.asc
Description: OpenPGP digital signature

Re: [2.6.23-mm1] CONFIG_LOCALVERSION handling broken

[Sam Ravnborg]

On Sun, Oct 14, 2007 at 12:11:52AM +0200, Tilman Schmidt wrote:
> Something seems to be amiss with CONFIG_LOCALVERSION handling.
> 
> I am routinely building with
> CONFIG_LOCALVERSION="-testing"
> CONFIG_LOCALVERSION_AUTO=y
> My usual sequence of "make ; sudo make modules_install install"
> has worked fine for all of 2.6.23{-rc?{,-mm?},}. For 2.6.23-mm1
> it fails with:
> 
> [EMAIL PROTECTED]:~/kernel/linux-2.6.23-mm1-work> sudo make modules_install 
> install
> root's password:
>   INSTALL arch/i386/crypto/aes-i586.ko
> [...]
>   INSTALL sound/usb/usx2y/snd-usb-usx2y.ko
> if [ -r System.map -a -x /sbin/depmod ]; then /sbin/depmod -ae -F System.map  
> 2.6.23-mm1; fi
> sh /home/ts/kernel/linux-2.6.23-mm1-work/arch/i386/boot/install.sh 2.6.23-mm1 
> arch/i386/boot/bzImage System.map "/boot"
> Root device:/dev/system/root (mounted on / as ext3)
> Module list:processor thermal ahci pata_marvell aic7xxx fan jbd ext3 
> dm_mod edd dm-mod dm-snapshot (xennet xenblk dm-mod dm-snapshot)
> 
> Kernel image:   /boot/vmlinuz-2.6.23-mm1
> Initrd image:   /boot/initrd-2.6.23-mm1
> No modules found for kernel 2.6.23-mm1-testing
> [EMAIL PROTECTED]:~/kernel/linux-2.6.23-mm1-work>
> 
> That is, both "make modules_install" and "make install" omit
> the "-testing" suffix, "make modules_install" installing the
> modules into /lib/modules/2.6.23-mm1 instead of
> /lib/modules/2.6.23-mm1-testing, and "make install" passing
> "2.6.23-mm1" without the "-testing" suffix to the install.sh
> script, but mkinitrd suddenly rediscovers the real kernel
> version string and consequently looks for modules in
> /lib/modules/2.6.23-mm1-testing, so initrd creation fails.
> 
> Ideas?
Nope...

I have just tried it out with latest -linus tree and I see no bugs.
Note that all kbuild fixes are in latest -linus except for
a few things that are postponed.

I will keep it in mind but nor persuade it further for now.

Sam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] static initialization and blocking notification for pm_qos... was Re: 2.6.23-mm1

[Mark Gross]

On Fri, Oct 12, 2007 at 11:32:40PM +0200, Rafael J. Wysocki wrote:
> On Friday, 12 October 2007 06:31, Andrew Morton wrote:
> > 
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm1/
> > 
> > - I've been largely avoiding applying anything since rc8-mm2 in an attempt
> >   to stabilise things for the 2.6.23 merge.
> > 
> >   But that didn't stop all the subsystem maintainers from going nuts, with
> >   the usual accuracy.  We're up to a 37MB diff now, but it seems to be 
> > working
> >   a bit better.
> 
> I get many traces similar to the one below from it (w/ hotfixes):
> 
> WARNING: at /home/rafael/src/mm/linux-2.6.23-mm1/arch/x86_64/kernel/smp.c:397 
> smp_call_function_mask()
> 
> Call Trace:
>  [] smp_call_function_mask+0x4b/0x82
>  [] smp_call_function+0x23/0x25
>  [] :processor:acpi_processor_latency_notify+0x19/0x20
>  [] notifier_call_chain+0x33/0x65
>  [] __srcu_notifier_call_chain+0x4b/0x69
>  [] pm_qos_add_requirement+0x24/0xd2
>  [] srcu_notifier_call_chain+0xf/0x11
>  [] update_target+0x71/0x76
>  [] pm_qos_add_requirement+0xa9/0xd2
>  [] :snd_pcm:snd_pcm_hw_params+0x349/0x382
>  [] kmem_cache_alloc+0x8a/0xbc
>  [] :snd_pcm:snd_pcm_hw_params_user+0x50/0x87
>  [] :snd_pcm:snd_pcm_common_ioctl1+0x1ae/0xd4f
>  [] :snd_pcm:snd_pcm_open+0xd6/0x1f2
>  [] cache_alloc_debugcheck_after+0x11a/0x199
>  [] remove_wait_queue+0x40/0x45
>  [] :snd_pcm:snd_pcm_open+0x13e/0x1f2
>  [] default_wake_function+0x0/0xf
>  [] prio_tree_insert+0x18c/0x231
>  [] vma_prio_tree_insert+0x23/0x39
>  [] vma_link+0xdd/0x10b
>  [] :snd_pcm:snd_pcm_playback_ioctl1+0x24d/0x26a
>  [] :snd_pcm:snd_pcm_playback_ioctl+0x2e/0x36
>  [] do_ioctl+0x2a/0x77
>  [] vfs_ioctl+0x251/0x26e
>  [] sys_ioctl+0x57/0x7b
>  [] system_call+0x7e/0x83
> 
> Full dmesg attached.
>


ubject: [PATCH] static initialization and blocking notification for pm_qos... 
was Re: 2.6.23-mm1

please try this patch and let me know if the warnings go away.  (I have
not been able to reproduce your issue.)

The following is a patch to update the pm_qos code in the mm1 tree.  It
removes the PM_QOS_CPUIDLE parameter (replacing it with
PM_CPU_DMA_LATENCY), It changes the notifications from srcu to blocking
in hopes of fixing the WARNS reported by xxx, and it changes the
initialization to me largely static to avoid initialization race with
cpu-idle.

I think we will have to re-visit the static vrs dynamic initialization
and this init race in a while to support pm_qos parameters per power
domain (i.e. per cpu-socket) based on platform information (ACPI) but
for now lets see if this fixes the warning's reported.

Thanks,

Signed-off-by: mark gross <[EMAIL PROTECTED]>


Binary files linux-2.6.23-mm1/arch/x86_64/ia32/vsyscall-syscall.so.dbg and 
linux-2.6.23-mm1-pmqos/arch/x86_64/ia32/vsyscall-syscall.so.dbg differ
Binary files linux-2.6.23-mm1/arch/x86_64/ia32/vsyscall-sysenter.so.dbg and 
linux-2.6.23-mm1-pmqos/arch/x86_64/ia32/vsyscall-sysenter.so.dbg differ
Binary files linux-2.6.23-mm1/arch/x86_64/vdso/vdso.so.dbg and 
linux-2.6.23-mm1-pmqos/arch/x86_64/vdso/vdso.so.dbg differ
diff -urN -X linux-2.6.23-mm1/Documentation/dontdiff 
linux-2.6.23-mm1/drivers/cpuidle/cpuidle.c 
linux-2.6.23-mm1-pmqos/drivers/cpuidle/cpuidle.c
--- linux-2.6.23-mm1/drivers/cpuidle/cpuidle.c  2007-10-16 15:03:30.0 
-0700
+++ linux-2.6.23-mm1-pmqos/drivers/cpuidle/cpuidle.c2007-10-17 
09:26:21.0 -0700
@@ -268,7 +268,7 @@
 
 static inline void latency_notifier_init(struct notifier_block *n)
 {
-pm_qos_add_notifier(PM_QOS_CPUIDLE, n);
+pm_qos_add_notifier(PM_QOS_CPU_DMA_LATENCY, n);
 }
 
 #else /* CONFIG_SMP */
diff -urN -X linux-2.6.23-mm1/Documentation/dontdiff 
linux-2.6.23-mm1/drivers/cpuidle/governors/ladder.c 
linux-2.6.23-mm1-pmqos/drivers/cpuidle/governors/ladder.c
--- linux-2.6.23-mm1/drivers/cpuidle/governors/ladder.c 2007-10-16 
15:03:30.0 -0700
+++ linux-2.6.23-mm1-pmqos/drivers/cpuidle/governors/ladder.c   2007-10-17 
09:26:21.0 -0700
@@ -82,7 +82,7 @@
if (last_idx < dev->state_count - 1 &&
last_residency > last_state->threshold.promotion_time &&
dev->states[last_idx + 1].exit_latency <=
-   pm_qos_requirement(PM_QOS_CPUIDLE)) {
+   pm_qos_requirement(PM_QOS_CPU_DMA_LATENCY)) {
last_state->stats.promotion_count++;
last_state->stats.demotion_count = 0;
if (last_state->stats.promotion_count >= 
last_state->threshold.promotion_count) {
diff -urN -X linux-2.6.23-mm1/Documentation/dontdiff 
linux-2.6.23-mm1/drivers/cpuidle/governors/menu.c 
linux-2.6.23-mm1-pmqos/drivers/cpuidle/governors/menu.c
--- linux-2.6.23-mm1/drivers/cpuidle/governors/menu.c   2007

Re: 2.6.23-mm1 - list_add corruption in cgroup

[Cedric Le Goater]

Hello !

While polling the contents of a cgroup task file, I caught the 
following corruption. Is there a known race (and a fix) or should 
I start digging ? 

the program running in the cgroup is fork/exec intensive:

 while (1) {
int i, s;

for (i = 0; i < count; i++)
if (fork() == 0) 
execlp("/bin/true", "true", 0);

for (i = 0; i < count; i++) 
wait();
}

Thanks for any insights, 

C. 



 list_add corruption. next->prev should be prev (80a3f338), but was 
00200200. (next=810103dcbe90).
[ cut here ]
kernel BUG at /home/legoater/linux/2.6.23-mm1/lib/list_debug.c:27!
invalid opcode:  [1] SMP 
last sysfs file: /devices/pci:00/:00:1e.0/:01:01.0/local_cpus
CPU 3 
Modules linked in: ipt_REJECT iptable_filter autofs4 nfs lockd sunrpc tg3 sg 
joydev ext3 jbd ehci_hcd ohci_hcd uhci_hcd
Pid: 2441, comm: bash Not tainted 2.6.23-mm1 #4
RIP: 0010:[]  [] __list_add+0x27/0x5b
RSP: 0018:810103d87dd8  EFLAGS: 00010296
RAX: 0079 RBX: 810105033040 RCX: 0079
RDX: 810103d960c0 RSI: 0001 RDI: 0096
RBP: 810103d87dd8 R08: 0002 R09: 810008123780
R10:  R11: 810103d87a98 R12: 
R13: 810105033040 R14: 810104c11ac0 R15: 
FS:  7f4e273556f0() GS:81010011a840() knlGS:
CS:  0010 DS:  ES:  CR0: 8005003b
CR2: 006ca2f8 CR3: 000103d82000 CR4: 06e0
DR0:  DR1:  DR2: 
DR3:  DR6: 0ff0 DR7: 0400
Process bash (pid: 2441, threadinfo 810103d86000, task 810103d960c0)
last branch before last exception/interrupt
 from  [] printk+0x68/0x69
 to  [] __list_add+0x27/0x5b
Stack:  810103d87de8 80308d1a 810103d87e08 802606bf
 810103d87e08  810103d87ea8 80233dca
 810103ddf340 7f4e27355780  810103d87f58
Call Trace:
 [] list_add+0xc/0xe
 [] cgroup_post_fork+0x41/0x52
 [] copy_process+0x12d0/0x143a
 [] tracesys+0xdc/0xe1
 [] do_fork+0x76/0x203
 [] audit_syscall_entry+0x148/0x17e
 [] tracesys+0xdc/0xe1
 [] sys_clone+0x23/0x25
 [] ptregscall_common+0x67/0xb0

INFO: lockdep is turned off.

Code: 0f 0b eb fe 4c 8b 00 49 39 f0 74 18 48 89 c1 4c 89 c2 48 c7 
RIP  [] __list_add+0x27/0x5b
 RSP 
BUG: soft lockup - CPU#1 stuck for 11s! [true:2030]
CPU 1:
Modules linked in: ipt_REJECT iptable_filter autofs4 nfs lockd sunrpc tg3 sg 
joydev ext3 jbd ehci_hcd ohci_hcd uhci_hcd
Pid: 2030, comm: true Tainted: G  D 2.6.23-mm1 #4
RIP: 0010:[]  [] 
__write_lock_failed+0xf/0x20
RSP: 0018:81010513be80  EFLAGS: 0287
RAX: 0001 RBX: 81010513be98 RCX: 807d8d60
RDX: 0037 RSI: 0037 RDI: 805beac0
RBP: 81010289e040 R08:  R09: 
R10: 8026072c R11: 81010513be08 R12: 81000812c300
R13: 81010289e040 R14: 81010513a000 R15: 810087acb000
FS:  () GS:8101000560c0() knlGS:
CS:  0010 DS:  ES:  CR0: 8005003b
CR2: 7f8171b028b0 CR3: 00201000 CR4: 06e0
DR0:  DR1:  DR2: 
DR3:  DR6: 0ff0 DR7: 0400

Call Trace:
 [] _raw_write_lock+0x6c/0x8b
 [] cgroup_exit+0x5c/0xc3
 [] _write_lock+0x2d/0x31
 [] cgroup_exit+0x5c/0xc3
 [] do_exit+0x2a0/0x7a5
 [] sys_exit_group+0x0/0x14
 [] sys_exit_group+0x12/0x14
 [] tracesys+0xdc/0xe1
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-mm1: BUG in reiserfs_delete_xattrs

[Jeff Mahoney]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Christoph Hellwig wrote:
> On Mon, Oct 15, 2007 at 02:31:03PM -0400, Jeff Mahoney wrote:
>> Here's a patch I worked up the other night that kills off struct file
>> completely from the xattr code. I've tested it locally.
> 
> Looks like a merge of Dave's and my patch :)
> 
> ACK from me, I don't care whether it's one or two patches.

Yeah, it probably is. I did it from scratch since it was my mess, and
the patches I saw were against -mm.

*shrug* Likewise, I don't care if it's one or two.

- -Jeff

- --
Jeff Mahoney
SUSE Labs
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.4-svn0 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFHFiJHLPWxlyuTD7IRAojqAJwKS+eL1yCtUVHzBSFUxjjkW6KgPwCcDRUE
Q1V7tCPcT9h0a8ahVmYn+ms=
=5kMt
-END PGP SIGNATURE-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-mm1

[KAMEZAWA Hiroyuki]

On Wed, 17 Oct 2007 13:42:04 +0200 (CEST)
Jiri Kosina <[EMAIL PROTECTED]> wrote:

> On Wed, 17 Oct 2007, KAMEZAWA Hiroyuki wrote:
> 
> > > Oh well, this causes more trouble that I have ever imagined ... I will 
> > > look into it, thanks a lot for the report. Andrew, please drop this 
> > > one again, I will fix it up.
> > Maybe this can be fix.
> 
> Hi Kame,
> 
> yes, this looks correct to me. Did you verify that it makes the problem 
> you are seeing go away?
> 
yes. I confirmed this works well.

-Kame
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/