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"

[Bryan Wu]

Forward to ARM and Tegra mail list.


---------- Forwarded message ----------
From: Bryan Wu <cooloney-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
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-qxv4g6HH51o@public.gmane.org, Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>,
"linux-next-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-next-u79uwXL29TY76Z2rM5mHXA@public.gmane.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?

----
Uncompressing Linux... done, booting the kernel.
[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Initializing cgroup subsys cpuacct
[    0.000000] Linux version 3.9.0-rc8-09782-ga6df01a
(roc@roc-HP-desktop) (gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-1ubuntu1)
) #20 SMP PREEMPT Mon Apr 29 10:09:07 PDT 2013
[    0.000000] CPU: ARMv7 Processor [412fc099] revision 9 (ARMv7), cr=10c5387d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
instruction cache
[    0.000000] Machine: NVIDIA Tegra30 (Flattened Device Tree), model:
NVIDIA Tegra30 Beaver evaluation board
[    0.000000] bootconsole [earlycon0] enabled
[    0.000000] cma: CMA: reserved 16 MiB at ae800000
[    0.000000] Memory policy: ECC disabled, Data cache writealloc
[    0.000000] On node 0 totalpages: 524032
[    0.000000] free_area_init_node: node 0, pgdat c070b7c0,
node_mem_map c075c000
[    0.000000]   Normal zone: 1520 pages used for memmap
[    0.000000]   Normal zone: 0 pages reserved
[    0.000000]   Normal zone: 194560 pages, LIFO batch:31
[    0.000000]   HighMem zone: 2574 pages used for memmap
[    0.000000]   HighMem zone: 329472 pages, LIFO batch:31
[    0.000000] fuse_speedo_calib: ATE prog ver 3.3
[    0.000000] Tegra30: CPU Speedo ID 5, Soc Speedo ID 2
[    0.000000] Tegra Revision: A03 SKU: 128 CPU Process: 4 Core Process: 0
[    0.000000] L310 cache controller enabled
[    0.000000] l2x0: 8 ways, CACHE_ID 0x410000c7, AUX_CTRL 0x7e480001,
Cache size: 1048576 B
[    0.000000] PERCPU: Embedded 8 pages/cpu @c176e000 s9280 r8192 d15296 u32768
[    0.000000] pcpu-alloc: s9280 r8192 d15296 u32768 alloc=8*4096
[    0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.
Total pages: 522512
[    0.000000] Kernel command line: console=ttyS0,115200n8
root=/dev/mmcblk0p1 loglevel=8 rootwait rw earlyprintk
[    0.000000] PID hash table entries: 4096 (order: 2, 16384 bytes)
[    0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
[    0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
[    0.000000] Memory: 2047MB = 2047MB total
[    0.000000] Memory: 2054764k/2054764k available, 41364k reserved,
1317888K highmem
[    0.000000] Virtual kernel memory layout:
[    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
[    0.000000]     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
[    0.000000]     vmalloc : 0xf0000000 - 0xff000000   ( 240 MB)
[    0.000000]     lowmem  : 0xc0000000 - 0xef800000   ( 760 MB)
[    0.000000]     pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
[    0.000000]     modules : 0xbf000000 - 0xbfe00000   (  14 MB)
[    0.000000]       .text : 0xc0008000 - 0xc0695268   (6709 kB)
[    0.000000]       .init : 0xc0696000 - 0xc06c8440   ( 202 kB)
[    0.000000]       .data : 0xc06ca000 - 0xc070d020   ( 269 kB)
[    0.000000]        .bss : 0xc070d020 - 0xc075bb88   ( 315 kB)
[    0.000000] Preemptible hierarchical RCU implementation.
[    0.000000] NR_IRQS:16 nr_irqs:16 16
[    0.000000] sched_clock: 32 bits at 1000kHz, resolution 1000ns,
wraps every 4294967ms
[    0.000000] Console: colour dummy device 80x30
[    0.005231] Calibrating delay loop... 1993.93 BogoMIPS (lpj=9969664)
[    0.062959] pid_max: default: 32768 minimum: 301
[    0.068223] Mount-cache hash table entries: 512
[    0.083957] Initializing cgroup subsys debug
[    0.088428] Initializing cgroup subsys freezer
[    0.093220] CPU: Testing write buffer coherency: ok
[    0.098680] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
[    0.104632] Setting up static identity map for 0xc04d9dc8 - 0xc04d9e4c
[    0.166265] CPU1: Booted secondary processor
[    0.224635] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
[    0.246245] CPU2: Booted secondary processor
[    0.304634] CPU2: thread -1, cpu 2, socket 0, mpidr 80000002
[    0.326206] CPU3: Booted secondary processor
[    0.384634] CPU3: thread -1, cpu 3, socket 0, mpidr 80000003
[    0.384730] Brought up 4 CPUs
[    0.418869] SMP: Total of 4 processors activated (7975.73 BogoMIPS).
[    0.425471] CPU: All CPU(s) started in SVC mode.
[    0.431323] devtmpfs: initialized
[    0.449863] pinctrl core: initialized pinctrl subsystem
[    0.455839] regulator-dummy: no parameters
[    0.461447] NET: Registered protocol family 16
[    0.469728] DMA: preallocated 256 KiB pool for atomic coherent allocations
[    0.487314] No ATAGs?
[    0.489478] hw-breakpoint: found 5 (+1 reserved) breakpoint and 1
watchpoint registers.
[    0.498053] hw-breakpoint: maximum watchpoint size is 4 bytes.
----
System hangs here, no output at all.

Any suggestions are welcome, I can test that on my hardware.
Thanks,
-Bryan

Re: 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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> 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-qxv4g6HH51o@public.gmane.org, Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Cc: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>,
> "linux-next-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-next-u79uwXL29TY76Z2rM5mHXA@public.gmane.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?

Re: 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-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> wrote:
> On 04/29/13 12:41, Bryan Wu wrote:
>>
>> Forward to ARM and Tegra mail list.
>>
>> ---------- Forwarded message ----------
>> From: Bryan Wu <cooloney-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> 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-qxv4g6HH51o@public.gmane.org, Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>> Cc: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>,
>> "linux-next-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-next-u79uwXL29TY76Z2rM5mHXA@public.gmane.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

Re: 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-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.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

Re: 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@st.com, Linus Walleij <linus.walleij@linaro.org>
> >Cc: Stephen Warren <swarren@wwwdotorg.org>,
> >"linux-next@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@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: 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-sclMFOaUSTBWk0Htik3J/w@public.gmane.org> wrote:

> same issue on at91sam9g45ek

Is it working with mainline (Torvalds) HEAD?

Yours,
Linus Walleij

Re: 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

Re: 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-sclMFOaUSTBWk0Htik3J/w@public.gmane.org> 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

Re: 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.

Re: 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-sclMFOaUSTBWk0Htik3J/w@public.gmane.org> 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

Re: 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-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> On Sun, May 5, 2013 at 10:22 PM, Jean-Christophe PLAGNIOL-VILLARD
> <plagnioj-sclMFOaUSTBWk0Htik3J/w@public.gmane.org> 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

Re: 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

Re: 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-sclMFOaUSTBWk0Htik3J/w@public.gmane.org> 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.

Re: 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-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org> 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

Re: 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-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> On Mon, May 6, 2013 at 9:54 PM, Russell King - ARM Linux
> <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org> 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.

Re: 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-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org> wrote:
> On Mon, May 6, 2013 at 9:12 PM, Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>> On Mon, May 6, 2013 at 9:54 PM, Russell King - ARM Linux
>> <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org> 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

Re: 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-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org> wrote:
> On Thu, May 9, 2013 at 6:25 AM, Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org> wrote:
>> On Mon, May 6, 2013 at 9:12 PM, Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.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

Re: 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

Re: 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-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org> wrote:
>> On Thu, May 9, 2013 at 6:25 AM, Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org> wrote:
>>> On Mon, May 6, 2013 at 9:12 PM, Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.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-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

Re: 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@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> > 
> 

Re: 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-sclMFOaUSTBWk0Htik3J/w@public.gmane.org> 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.

Re: 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-sclMFOaUSTBWk0Htik3J/w@public.gmane.org> 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.

Re: 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-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.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-sclMFOaUSTBWk0Htik3J/w@public.gmane.org> 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

Re: 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