Fwd: Tegra 30 System hangs because of commit "pinctrl: move subsystem mutex to pinctrl_dev struct"

Fwd: Tegra 30 System hangs because of commit "pinctrl: move subsystem mutex to pinctrl_dev struct"

[Stephen Warren]

On 04/29/13 12:41, Bryan Wu wrote:
> Forward to ARM and Tegra mail list.
>
> ---------- Forwarded message ----------
> From: Bryan Wu <cooloney@gmail.com>
> Date: Mon, Apr 29, 2013 at 11:15 AM
> Subject: Tegra 30 System hangs because of commit "pinctrl: move
> subsystem mutex to pinctrl_dev struct"
> To: patrice.chotard at st.com, Linus Walleij <linus.walleij@linaro.org>
> Cc: Stephen Warren <swarren@wwwdotorg.org>,
> "linux-next at vger.kernel.org" <linux-next@vger.kernel.org>
>
>
> Hi Patrice and Linus,
>
> I'm running linux-next on my Tegra 30 system everyday. But since
> next-20130426 release, the linux-next kernel will hang on my Tegra 30
> boards like Cardhu and Beaver.
>
> After some bisect and comparing to next-20130424, I found the commit
> "pinctrl: move subsystem mutex to pinctrl_dev struct" introduced this
> issue. If I simply revert this patch in next-20130429, system boots up
> as before.
>
> Could you please help to check this?

I would suggest simply dropping or reverting this patch; I had pointed 
out a long time ago that it was unlikely to be correct.

My guess/suspicion is a recursive lock attempt during processing hogs 
during pinctrl device registration, or perhaps during dt->map 
conversion. Bryan, are you able to confirm this?

Fwd: Tegra 30 System hangs because of commit "pinctrl: move subsystem mutex to pinctrl_dev struct"

[Bryan Wu]

On Mon, Apr 29, 2013 at 12:59 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 04/29/13 12:41, Bryan Wu wrote:
>>
>> Forward to ARM and Tegra mail list.
>>
>> ---------- Forwarded message ----------
>> From: Bryan Wu <cooloney@gmail.com>
>> Date: Mon, Apr 29, 2013 at 11:15 AM
>> Subject: Tegra 30 System hangs because of commit "pinctrl: move
>> subsystem mutex to pinctrl_dev struct"
>> To: patrice.chotard at st.com, Linus Walleij <linus.walleij@linaro.org>
>> Cc: Stephen Warren <swarren@wwwdotorg.org>,
>> "linux-next at vger.kernel.org" <linux-next@vger.kernel.org>
>>
>>
>> Hi Patrice and Linus,
>>
>> I'm running linux-next on my Tegra 30 system everyday. But since
>> next-20130426 release, the linux-next kernel will hang on my Tegra 30
>> boards like Cardhu and Beaver.
>>
>> After some bisect and comparing to next-20130424, I found the commit
>> "pinctrl: move subsystem mutex to pinctrl_dev struct" introduced this
>> issue. If I simply revert this patch in next-20130429, system boots up
>> as before.
>>
>> Could you please help to check this?
>
>
> I would suggest simply dropping or reverting this patch; I had pointed out a
> long time ago that it was unlikely to be correct.
>
> My guess/suspicion is a recursive lock attempt during processing hogs during
> pinctrl device registration, or perhaps during dt->map conversion. Bryan,
> are you able to confirm this?

Oh, no worries now. It was fixed in pinctrl for-next branch. I guess
linux-next will be update soon.

I will keep testing this when new linux-next is out.

-Bryan

Fwd: Tegra 30 System hangs because of commit "pinctrl: move subsystem mutex to pinctrl_dev struct"

[Linus Walleij]

On Mon, Apr 29, 2013 at 9:59 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:

> I would suggest simply dropping or reverting this patch; I had pointed out a
> long time ago that it was unlikely to be correct.
>
> My guess/suspicion is a recursive lock attempt during processing hogs during
> pinctrl device registration, or perhaps during dt->map conversion. Bryan,
> are you able to confirm this?

This was not the case at all, it was an mutex_unlock misspelled as
mutex_lock()... totally unrecursive dual locking :-)

I did test the patch quite extensively, albeit not on a system using
DT to populate the pinctrl tables so I missed this, mea culpa.

I really want to get rid of the big pinctrl lock and make this more
fine-granular, and that is why the patch is being pushed, bear
with me.

Yours,
Linus Walleij

Fwd: Tegra 30 System hangs because of commit "pinctrl: move subsystem mutex to pinctrl_dev struct"

[Jean-Christophe PLAGNIOL-VILLARD]

On 13:59 Mon 29 Apr     , Stephen Warren wrote:
> On 04/29/13 12:41, Bryan Wu wrote:
> >Forward to ARM and Tegra mail list.
> >
> >---------- Forwarded message ----------
> >From: Bryan Wu <cooloney@gmail.com>
> >Date: Mon, Apr 29, 2013 at 11:15 AM
> >Subject: Tegra 30 System hangs because of commit "pinctrl: move
> >subsystem mutex to pinctrl_dev struct"
> >To: patrice.chotard at st.com, Linus Walleij <linus.walleij@linaro.org>
> >Cc: Stephen Warren <swarren@wwwdotorg.org>,
> >"linux-next at vger.kernel.org" <linux-next@vger.kernel.org>
> >
> >
> >Hi Patrice and Linus,
> >
> >I'm running linux-next on my Tegra 30 system everyday. But since
> >next-20130426 release, the linux-next kernel will hang on my Tegra 30
> >boards like Cardhu and Beaver.
> >
> >After some bisect and comparing to next-20130424, I found the commit
> >"pinctrl: move subsystem mutex to pinctrl_dev struct" introduced this
> >issue. If I simply revert this patch in next-20130429, system boots up
> >as before.
> >
> >Could you please help to check this?
> 
> I would suggest simply dropping or reverting this patch; I had
> pointed out a long time ago that it was unlikely to be correct.
> 
> My guess/suspicion is a recursive lock attempt during processing
> hogs during pinctrl device registration, or perhaps during dt->map
> conversion. Bryan, are you able to confirm this?

same issue on at91sam9g45ek

revert it

Best Regards,
J.
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Fwd: Tegra 30 System hangs because of commit "pinctrl: move subsystem mutex to pinctrl_dev struct"

[Linus Walleij]

On Sat, May 4, 2013 at 3:30 PM, Jean-Christophe PLAGNIOL-VILLARD
<plagnioj@jcrosoft.com> wrote:

> same issue on at91sam9g45ek

Is it working with mainline (Torvalds) HEAD?

Yours,
Linus Walleij

Fwd: Tegra 30 System hangs because of commit "pinctrl: move subsystem mutex to pinctrl_dev struct"

[Jean-Christophe PLAGNIOL-VILLARD]

On 22:52 Sat 04 May     , Linus Walleij wrote:
> On Sat, May 4, 2013 at 3:30 PM, Jean-Christophe PLAGNIOL-VILLARD
> <plagnioj@jcrosoft.com> wrote:
> 
> > same issue on at91sam9g45ek
> 
> Is it working with mainline (Torvalds) HEAD?
now yes

Best Regards,
J.
> 
> Yours,
> Linus Walleij

Fwd: Tegra 30 System hangs because of commit "pinctrl: move subsystem mutex to pinctrl_dev struct"

[Linus Walleij]

On Sun, May 5, 2013 at 1:28 PM, Jean-Christophe PLAGNIOL-VILLARD
<plagnioj@jcrosoft.com> wrote:
> On 22:52 Sat 04 May     , Linus Walleij wrote:
>> On Sat, May 4, 2013 at 3:30 PM, Jean-Christophe PLAGNIOL-VILLARD

>> > same issue on at91sam9g45ek
>>
>> Is it working with mainline (Torvalds) HEAD?
>
> now yes

Thanks! I had some panic there for a while :-)

Yours,
Linus Walleij

Fwd: Tegra 30 System hangs because of commit "pinctrl: move subsystem mutex to pinctrl_dev struct"

[Jean-Christophe PLAGNIOL-VILLARD]

On 21:57 Sun 05 May     , Linus Walleij wrote:
> On Sun, May 5, 2013 at 1:28 PM, Jean-Christophe PLAGNIOL-VILLARD
> <plagnioj@jcrosoft.com> wrote:
> > On 22:52 Sat 04 May     , Linus Walleij wrote:
> >> On Sat, May 4, 2013 at 3:30 PM, Jean-Christophe PLAGNIOL-VILLARD
> 
> >> > same issue on at91sam9g45ek
> >>
> >> Is it working with mainline (Torvalds) HEAD?
> >
> > now yes
> 
> Thanks! I had some panic there for a while :-)

I was thinking to put a jenkins to test Linus HEAD all the time
And with some automatic test one some hw

to detect it more quick

Best Regards,
J.

Fwd: Tegra 30 System hangs because of commit "pinctrl: move subsystem mutex to pinctrl_dev struct"

[Linus Walleij]

On Sun, May 5, 2013 at 10:22 PM, Jean-Christophe PLAGNIOL-VILLARD
<plagnioj@jcrosoft.com> wrote:

> I was thinking to put a jenkins to test Linus HEAD all the time
> And with some automatic test one some hw
>
> to detect it more quick

Hm yeah, I think I need a broader diversity of testsystems too ... I have this
nice Chromebook so I thought if I could get a mainline kernel running on
it I'd have a bigger coverage as well.

Yours,
Linus Walleij

Fwd: Tegra 30 System hangs because of commit "pinctrl: move subsystem mutex to pinctrl_dev struct"

[Bryan Wu]

On Mon, May 6, 2013 at 12:29 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Sun, May 5, 2013 at 10:22 PM, Jean-Christophe PLAGNIOL-VILLARD
> <plagnioj@jcrosoft.com> wrote:
>
>> I was thinking to put a jenkins to test Linus HEAD all the time
>> And with some automatic test one some hw
>>
>> to detect it more quick
>
> Hm yeah, I think I need a broader diversity of testsystems too ... I have this
> nice Chromebook so I thought if I could get a mainline kernel running on
> it I'd have a bigger coverage as well.
>

I think Stephen are working on bring up linux-next daily build and QA
testing on Tegra hardware. This should be quite helpful.

Thanks,
-Bryan

Fwd: Tegra 30 System hangs because of commit "pinctrl: move subsystem mutex to pinctrl_dev struct"

[Jean-Christophe PLAGNIOL-VILLARD]

On 21:29 Mon 06 May     , Linus Walleij wrote:
> On Sun, May 5, 2013 at 10:22 PM, Jean-Christophe PLAGNIOL-VILLARD
> <plagnioj@jcrosoft.com> wrote:
> 
> > I was thinking to put a jenkins to test Linus HEAD all the time
> > And with some automatic test one some hw
> >
> > to detect it more quick
> 
> Hm yeah, I think I need a broader diversity of testsystems too ... I have this
> nice Chromebook so I thought if I could get a mainline kernel running on
> it I'd have a bigger coverage as well.

Maybe we could all work together to setup such automatic testing tool

I mean all vendors

Best Regards,
J.
> 
> Yours,
> Linus Walleij

Fwd: Tegra 30 System hangs because of commit "pinctrl: move subsystem mutex to pinctrl_dev struct"

[Russell King - ARM Linux]

On Mon, May 06, 2013 at 09:41:22PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 21:29 Mon 06 May     , Linus Walleij wrote:
> > On Sun, May 5, 2013 at 10:22 PM, Jean-Christophe PLAGNIOL-VILLARD
> > <plagnioj@jcrosoft.com> wrote:
> > 
> > > I was thinking to put a jenkins to test Linus HEAD all the time
> > > And with some automatic test one some hw
> > >
> > > to detect it more quick
> > 
> > Hm yeah, I think I need a broader diversity of testsystems too ... I have this
> > nice Chromebook so I thought if I could get a mainline kernel running on
> > it I'd have a bigger coverage as well.
> 
> Maybe we could all work together to setup such automatic testing tool
> 
> I mean all vendors

Don't bother.  We had one, Simtec's Vince Sanders gave us the build side.
No one was interested.  No one took any notice of it.  I have one for a
limited number of platforms - it even boots the resulting kernels on real
hardware.  The only person who looks at it is me.  Again, just one person,
so little value.

And that same thing will appy to anything else setup by anyone else.

It's a good idea, but it only really works if people can be bothered to
derive value from it by checking the results.

My conclusion is that build and boot test systems just don't work in an
open source environment as no one actively checks the results.  Why would
they - maintainers already have enough to do with reading 6500+ emails a
month on mailing lists.  Why bother going to look at a website as well
which might give even more work.

Fwd: Tegra 30 System hangs because of commit "pinctrl: move subsystem mutex to pinctrl_dev struct"

[Linus Walleij]

On Mon, May 6, 2013 at 9:54 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:

> My conclusion is that build and boot test systems just don't work in an
> open source environment as no one actively checks the results.  Why would
> they - maintainers already have enough to do with reading 6500+ emails a
> month on mailing lists.  Why bother going to look at a website as well
> which might give even more work.

Point taken. I was in a discussion some time back with Greg and some
other people and we concluded that unless the system mails you when
something breaks it won't make a difference. And it mustn't flood you,
just be very precise.

Actually the autobuilder at kernel.org helped me out but then stopped
building my trees at some point, but that was nice and the same thing
doing boots would be great.

(However I did go in and fix a few build errors in linux-next after
reading on Rothwells autobuilder kisskb some time ... but it was more
a few-off thing.)

Yours,
Linus Walleij

Fwd: Tegra 30 System hangs because of commit "pinctrl: move subsystem mutex to pinctrl_dev struct"

[Grant Likely]

On Mon, May 6, 2013 at 9:12 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Mon, May 6, 2013 at 9:54 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
>
>> My conclusion is that build and boot test systems just don't work in an
>> open source environment as no one actively checks the results.  Why would
>> they - maintainers already have enough to do with reading 6500+ emails a
>> month on mailing lists.  Why bother going to look at a website as well
>> which might give even more work.
>
> Point taken. I was in a discussion some time back with Greg and some
> other people and we concluded that unless the system mails you when
> something breaks it won't make a difference. And it mustn't flood you,
> just be very precise.
>
> Actually the autobuilder at kernel.org helped me out but then stopped
> building my trees at some point, but that was nice and the same thing
> doing boots would be great.

+1 on what has already been stated on this thread; An autobuilder does
work if it emails you when something breaks without spamming you. I've
also found the 0day build tester actually effective. It has caught
things that I've missed and I immediately was able to go an fix.

g.

Fwd: Tegra 30 System hangs because of commit "pinctrl: move subsystem mutex to pinctrl_dev struct"

[Olof Johansson]

On Thu, May 9, 2013 at 6:25 AM, Grant Likely <grant.likely@secretlab.ca> wrote:
> On Mon, May 6, 2013 at 9:12 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
>> On Mon, May 6, 2013 at 9:54 PM, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>>
>>> My conclusion is that build and boot test systems just don't work in an
>>> open source environment as no one actively checks the results.  Why would
>>> they - maintainers already have enough to do with reading 6500+ emails a
>>> month on mailing lists.  Why bother going to look at a website as well
>>> which might give even more work.
>>
>> Point taken. I was in a discussion some time back with Greg and some
>> other people and we concluded that unless the system mails you when
>> something breaks it won't make a difference. And it mustn't flood you,
>> just be very precise.
>>
>> Actually the autobuilder at kernel.org helped me out but then stopped
>> building my trees at some point, but that was nice and the same thing
>> doing boots would be great.
>
> +1 on what has already been stated on this thread; An autobuilder does
> work if it emails you when something breaks without spamming you. I've
> also found the 0day build tester actually effective. It has caught
> things that I've missed and I immediately was able to go an fix.

Yes, a builder is quite useful. Several of us do our own builds as well.

When it comes to boot coverage, I'm not sure how successful a central
approach would be. It's something where I think Linaro could
contribute a lot for their member platforms, but I haven't seen much
engagement there yet.

Beyond there, I'd say the expectation is that each maintainer should
keep an eye on their own platforms. They _should_ try building and
booting linux-next on their platforms, to catch regressions early. And
definitely around now, I'd like to see people boot mainline on their
platforms to make sure we haven't added any severe regressions in the
3.10 merge window, etc. Some people are really good at this, others
less so.

What's the old saying, you can lead a horse to water but you can't
make him drink? You can build a boot test cluster but you can't make
anyone pay attention to it. :(

-Olof

Fwd: Tegra 30 System hangs because of commit "pinctrl: move subsystem mutex to pinctrl_dev struct"

[Fathi Boudra]

On 9 May 2013 19:13, Olof Johansson <olof@lixom.net> wrote:
> On Thu, May 9, 2013 at 6:25 AM, Grant Likely <grant.likely@secretlab.ca> wrote:
>> On Mon, May 6, 2013 at 9:12 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
>>> On Mon, May 6, 2013 at 9:54 PM, Russell King - ARM Linux
> Yes, a builder is quite useful. Several of us do our own builds as well.
>
> When it comes to boot coverage, I'm not sure how successful a central
> approach would be. It's something where I think Linaro could
> contribute a lot for their member platforms, but I haven't seen much
> engagement there yet.

My previous post was lost. Sorry to repost..

We've got a jenkins instance doing daily builds on various trees and
boot testing on the few boards we've got in the lab:
https://ci.linaro.org/jenkins/view/kernel-ci/

But it hasn't attracted much interest so far... It's been here since a year.

> Beyond there, I'd say the expectation is that each maintainer should
> keep an eye on their own platforms. They _should_ try building and
> booting linux-next on their platforms, to catch regressions early. And
> definitely around now, I'd like to see people boot mainline on their
> platforms to make sure we haven't added any severe regressions in the
> 3.10 merge window, etc. Some people are really good at this, others
> less so.
>
> What's the old saying, you can lead a horse to water but you can't
> make him drink? You can build a boot test cluster but you can't make
> anyone pay attention to it. :(
>
> -Olof

Cheers,

Fathi

Fwd: Tegra 30 System hangs because of commit "pinctrl: move subsystem mutex to pinctrl_dev struct"

[Jean-Christophe PLAGNIOL-VILLARD]

Hi,

	so we need to consolidate I'll send a proposition during the day

Best Regards,
J.
On 20:51 Thu 09 May     , Fathi Boudra wrote:
> On 9 May 2013 19:13, Olof Johansson <olof@lixom.net> wrote:
> > On Thu, May 9, 2013 at 6:25 AM, Grant Likely <grant.likely@secretlab.ca> wrote:
> >> On Mon, May 6, 2013 at 9:12 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> >>> On Mon, May 6, 2013 at 9:54 PM, Russell King - ARM Linux
> > Yes, a builder is quite useful. Several of us do our own builds as well.
> >
> > When it comes to boot coverage, I'm not sure how successful a central
> > approach would be. It's something where I think Linaro could
> > contribute a lot for their member platforms, but I haven't seen much
> > engagement there yet.
> 
> My previous post was lost. Sorry to repost..
> 
> We've got a jenkins instance doing daily builds on various trees and
> boot testing on the few boards we've got in the lab:
> https://ci.linaro.org/jenkins/view/kernel-ci/
> 
> But it hasn't attracted much interest so far... It's been here since a year.
> 
> > Beyond there, I'd say the expectation is that each maintainer should
> > keep an eye on their own platforms. They _should_ try building and
> > booting linux-next on their platforms, to catch regressions early. And
> > definitely around now, I'd like to see people boot mainline on their
> > platforms to make sure we haven't added any severe regressions in the
> > 3.10 merge window, etc. Some people are really good at this, others
> > less so.
> >
> > What's the old saying, you can lead a horse to water but you can't
> > make him drink? You can build a boot test cluster but you can't make
> > anyone pay attention to it. :(
> >
> > -Olof
> 
> Cheers,
> 
> Fathi

Fwd: Tegra 30 System hangs because of commit "pinctrl: move subsystem mutex to pinctrl_dev struct"

[Rob Herring]

On 05/09/2013 12:51 PM, Fathi Boudra wrote:
> On 9 May 2013 19:13, Olof Johansson <olof@lixom.net> wrote:
>> On Thu, May 9, 2013 at 6:25 AM, Grant Likely <grant.likely@secretlab.ca> wrote:
>>> On Mon, May 6, 2013 at 9:12 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
>>>> On Mon, May 6, 2013 at 9:54 PM, Russell King - ARM Linux
>> Yes, a builder is quite useful. Several of us do our own builds as well.
>>
>> When it comes to boot coverage, I'm not sure how successful a central
>> approach would be. It's something where I think Linaro could
>> contribute a lot for their member platforms, but I haven't seen much
>> engagement there yet.
> 
> My previous post was lost. Sorry to repost..
> 
> We've got a jenkins instance doing daily builds on various trees and
> boot testing on the few boards we've got in the lab:
> https://ci.linaro.org/jenkins/view/kernel-ci/
> 
> But it hasn't attracted much interest so far... It's been here since a year.

Perhaps because there is no useful information there that I can find.
Where does it say what failed in the build? I see no artifacts or useful
console output.

It seems it was designed with Linaro's needs in mind and not kernel
maintainers' needs.

Rob

> 
>> Beyond there, I'd say the expectation is that each maintainer should
>> keep an eye on their own platforms. They _should_ try building and
>> booting linux-next on their platforms, to catch regressions early. And
>> definitely around now, I'd like to see people boot mainline on their
>> platforms to make sure we haven't added any severe regressions in the
>> 3.10 merge window, etc. Some people are really good at this, others
>> less so.
>>
>> What's the old saying, you can lead a horse to water but you can't
>> make him drink? You can build a boot test cluster but you can't make
>> anyone pay attention to it. :(
>>
>> -Olof
> 
> Cheers,
> 
> Fathi
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

Fwd: Tegra 30 System hangs because of commit "pinctrl: move subsystem mutex to pinctrl_dev struct"

[Jean-Christophe PLAGNIOL-VILLARD]

On 15:39 Tue 14 May     , Rob Herring wrote:
> On 05/09/2013 12:51 PM, Fathi Boudra wrote:
> > On 9 May 2013 19:13, Olof Johansson <olof@lixom.net> wrote:
> >> On Thu, May 9, 2013 at 6:25 AM, Grant Likely <grant.likely@secretlab.ca> wrote:
> >>> On Mon, May 6, 2013 at 9:12 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> >>>> On Mon, May 6, 2013 at 9:54 PM, Russell King - ARM Linux
> >> Yes, a builder is quite useful. Several of us do our own builds as well.
> >>
> >> When it comes to boot coverage, I'm not sure how successful a central
> >> approach would be. It's something where I think Linaro could
> >> contribute a lot for their member platforms, but I haven't seen much
> >> engagement there yet.
> > 
> > My previous post was lost. Sorry to repost..
> > 
> > We've got a jenkins instance doing daily builds on various trees and
> > boot testing on the few boards we've got in the lab:
> > https://ci.linaro.org/jenkins/view/kernel-ci/
> > 
> > But it hasn't attracted much interest so far... It's been here since a year.
> 
> Perhaps because there is no useful information there that I can find.
> Where does it say what failed in the build? I see no artifacts or useful
> console output.
> 
> It seems it was designed with Linaro's needs in mind and not kernel
> maintainers' needs.

I was discussing with Fabo and Get in mind to create a Jenkins on kernel.org
for on our needs (maintainer's)

That will allow any one to add more hw for boot testing

Best Regards,
J.
> 
> Rob
> 
> > 
> >> Beyond there, I'd say the expectation is that each maintainer should
> >> keep an eye on their own platforms. They _should_ try building and
> >> booting linux-next on their platforms, to catch regressions early. And
> >> definitely around now, I'd like to see people boot mainline on their
> >> platforms to make sure we haven't added any severe regressions in the
> >> 3.10 merge window, etc. Some people are really good at this, others
> >> less so.
> >>
> >> What's the old saying, you can lead a horse to water but you can't
> >> make him drink? You can build a boot test cluster but you can't make
> >> anyone pay attention to it. :(
> >>
> >> -Olof
> > 
> > Cheers,
> > 
> > Fathi
> > 
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> > 
> 

Fwd: Tegra 30 System hangs because of commit "pinctrl: move subsystem mutex to pinctrl_dev struct"

[Stephen Warren]

On 05/06/2013 01:54 PM, Russell King - ARM Linux wrote:
> On Mon, May 06, 2013 at 09:41:22PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
>> On 21:29 Mon 06 May     , Linus Walleij wrote:
>>> On Sun, May 5, 2013 at 10:22 PM, Jean-Christophe PLAGNIOL-VILLARD
>>> <plagnioj@jcrosoft.com> wrote:
>>>
>>>> I was thinking to put a jenkins to test Linus HEAD all the time
>>>> And with some automatic test one some hw
>>>>
>>>> to detect it more quick
...
> My conclusion is that build and boot test systems just don't work in an
> open source environment as no one actively checks the results.  Why would
> they - maintainers already have enough to do with reading 6500+ emails a
> month on mailing lists.  Why bother going to look at a website as well
> which might give even more work.

Couldn't such a system email people pro-actively, so nobody had to do
any manual checking? The kisskb(?) build system does that, as does the
"zero day build system" thing from Intel, and I find them quite useful.
Personally, I do the build/test checks manually myself, so if an
automated system were to do it, it'd save me work rather than give me
more work.

Fwd: Tegra 30 System hangs because of commit "pinctrl: move subsystem mutex to pinctrl_dev struct"

[Jean-Christophe PLAGNIOL-VILLARD]

On 14:14 Mon 06 May     , Stephen Warren wrote:
> On 05/06/2013 01:54 PM, Russell King - ARM Linux wrote:
> > On Mon, May 06, 2013 at 09:41:22PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> >> On 21:29 Mon 06 May     , Linus Walleij wrote:
> >>> On Sun, May 5, 2013 at 10:22 PM, Jean-Christophe PLAGNIOL-VILLARD
> >>> <plagnioj@jcrosoft.com> wrote:
> >>>
> >>>> I was thinking to put a jenkins to test Linus HEAD all the time
> >>>> And with some automatic test one some hw
> >>>>
> >>>> to detect it more quick
> ...
> > My conclusion is that build and boot test systems just don't work in an
> > open source environment as no one actively checks the results.  Why would
> > they - maintainers already have enough to do with reading 6500+ emails a
> > month on mailing lists.  Why bother going to look at a website as well
> > which might give even more work.
> 
> Couldn't such a system email people pro-actively, so nobody had to do
> any manual checking? The kisskb(?) build system does that, as does the
> "zero day build system" thing from Intel, and I find them quite useful.
> Personally, I do the build/test checks manually myself, so if an
> automated system were to do it, it'd save me work rather than give me
> more work.

I've one on at91 but not on all HW but as Russell I need to check manualy

and yes I agreewe should have such automatic tool could be easly be integrated
in Jenkins and send automatic emails

It's really a shamge that no-one is intrested in such tools. I will all save a
huge amount of time of boring basic testing

Best Regards,
J.

Fwd: Tegra 30 System hangs because of commit "pinctrl: move subsystem mutex to pinctrl_dev struct"

[Bryan Wu]

On Mon, May 6, 2013 at 1:14 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 05/06/2013 01:54 PM, Russell King - ARM Linux wrote:
>> On Mon, May 06, 2013 at 09:41:22PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
>>> On 21:29 Mon 06 May     , Linus Walleij wrote:
>>>> On Sun, May 5, 2013 at 10:22 PM, Jean-Christophe PLAGNIOL-VILLARD
>>>> <plagnioj@jcrosoft.com> wrote:
>>>>
>>>>> I was thinking to put a jenkins to test Linus HEAD all the time
>>>>> And with some automatic test one some hw
>>>>>
>>>>> to detect it more quick
> ...
>> My conclusion is that build and boot test systems just don't work in an
>> open source environment as no one actively checks the results.  Why would
>> they - maintainers already have enough to do with reading 6500+ emails a
>> month on mailing lists.  Why bother going to look at a website as well
>> which might give even more work.
>
> Couldn't such a system email people pro-actively, so nobody had to do
> any manual checking? The kisskb(?) build system does that, as does the
> "zero day build system" thing from Intel, and I find them quite useful.
> Personally, I do the build/test checks manually myself, so if an
> automated system were to do it, it'd save me work rather than give me
> more work.

Yes, this 0day build system rocks. It will pull in specific branches
in maintainer branch and do building/automatic code checking like
smack/boot testing. If they find any issues, they will send out emails
directly to the authors and SoB persons. We just need to add our ARM
into to their system for such building/booting test.

So for this issue, it should be very easy to find and email to the author.

Thanks,
-Bryan

Fwd: Tegra 30 System hangs because of commit "pinctrl: move subsystem mutex to pinctrl_dev struct"

[Jean-Christophe PLAGNIOL-VILLARD]

On 20:54 Mon 06 May     , Russell King - ARM Linux wrote:
> On Mon, May 06, 2013 at 09:41:22PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > On 21:29 Mon 06 May     , Linus Walleij wrote:
> > > On Sun, May 5, 2013 at 10:22 PM, Jean-Christophe PLAGNIOL-VILLARD
> > > <plagnioj@jcrosoft.com> wrote:
> > > 
> > > > I was thinking to put a jenkins to test Linus HEAD all the time
> > > > And with some automatic test one some hw
> > > >
> > > > to detect it more quick
> > > 
> > > Hm yeah, I think I need a broader diversity of testsystems too ... I have this
> > > nice Chromebook so I thought if I could get a mainline kernel running on
> > > it I'd have a bigger coverage as well.
> > 
> > Maybe we could all work together to setup such automatic testing tool
> > 
> > I mean all vendors
> 
> Don't bother.  We had one, Simtec's Vince Sanders gave us the build side.
> No one was interested.  No one took any notice of it.  I have one for a
> limited number of platforms - it even boots the resulting kernels on real
> hardware.  The only person who looks at it is me.  Again, just one person,
> so little value.

Could you push the build failled on the arm ML or a specific ML

I'm really intresting I hate to brake platform support specialy yours
> 
> And that same thing will appy to anything else setup by anyone else.
> 
> It's a good idea, but it only really works if people can be bothered to
> derive value from it by checking the results.
We can have enforce policy if some brake something again and agian we can do
as Greg did for one of the Linaro dev. Force the patch to be double check by a
senior Maintainter.

And I think it will help Maintainer (Specially subsystem) to detect runtime
bug when applying code they can not test

So I really hope we could change this and make it work

Maybe as you rsaid it will not work but I'm willing to try one more time