mxc_v4l2_capture sometimes not being modprobed

Submitted by Otavio Salvador on June 5, 2014, 6:38 p.m.

Details

Message ID CAP9ODKpDt6K-0zdA3RfJXm2y4UnH=k-K_uYhNOa+UPJsK+nD-g@mail.gmail.com
State Not Applicable, archived
Delegated to: Otavio Salvador
Headers show

Commit Message

Otavio Salvador June 5, 2014, 6:38 p.m.
On Thu, Jun 5, 2014 at 3:23 PM, John Weber <rjohnweber@gmail.com> wrote:
>
> On 6/5/14, 1:17 PM, Otavio Salvador wrote:
>>
>> On Thu, Jun 5, 2014 at 3:14 PM, John Weber <rjohnweber@gmail.com> wrote:
>>>
>>> On 6/5/14, 1:08 PM, Otavio Salvador wrote:
>>>>
>>>> On Thu, Jun 5, 2014 at 3:05 PM, John Weber <rjohnweber@gmail.com> wrote:
>>>>>
>>>>> On 6/5/14, 12:34 PM, Otavio Salvador wrote:
>>>>>>
>>>>>> On Mon, May 26, 2014 at 12:42 AM, John Weber <rjohnweber@gmail.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> meta-freescalers:
>>>>>>>
>>>>>>> I'm seeing a behavior that I can't easily explain.  I'm not seeing
>>>>>>> the
>>>>>>> mxc_v4l2_capture drivers and dependent ipu drivers being
>>>>>>> automatically
>>>>>>> modprobed on Wandboard during a majority of system startups (but not
>>>>>>> all).
>>>>>>> I was under the impression that this should be done by udev, but for
>>>>>>> some
>>>>>>> reason it seems to either fail or is skipped.
>>>>>>>
>>>>>>> I can force the driver to be loaded at startup by adding the name of
>>>>>>> the
>>>>>>> driver in a line in /etc/modules.  This works to load the driver
>>>>>>> every
>>>>>>> time
>>>>>>> at startup, but I'm fairly certain that this is not the most ideal
>>>>>>> approach
>>>>>>> because (A) I have to write a recipe to make the change to
>>>>>>> /etc/modules
>>>>>>> and
>>>>>>> (B) it does not explain why the driver load works sometimes, but not
>>>>>>> all
>>>>>>> of
>>>>>>> the time.
>>>>>>>
>>>>>>> Any ideas?
>>>>>>
>>>>>> Does this happens with 3.0.35 and 3.10.17?
>>>>>>
>>>>> I did notice it on both kernels.  From what I've been able to gather
>>>>> after
>>>>> sending this email, the modules load at first boot on a freshly burned
>>>>> rootfs (that hasn't been postinst'd).  After that, SW and HW resets and
>>>>> POR
>>>>> to not result in loaded mxc_v4l2_capture module or its dependencies.  I
>>>>> do
>>>>> have other modules loaded, however, all the time - the ov5640_mipi
>>>>> driver
>>>>> and the Broadcom WLAN drivers load without fail.
>>>>>
>>>>> I suspect it could be a sequencing problem, but adding the line to
>>>>> /etc/modules fixes it.
>>>>
>>>> Are you using udev-cache?
>>>>
>>> I believe so:
>>> root@wandboard-dual:/etc# find . -name *udev-cache*
>>> ./rcS.d/S36udev-cache
>>> ./default/udev-cache
>>> ./init.d/udev-cache
>>
>> Disable it in default, please, and check if it helps.
>>
> That did it.  Thanks!  Not sure how to fix the problem though.

Well ... I need a coffee ...

Ok ... it seems we have a timing issue but it is related to the device settling.

Please apply following change in the udev init script:

Patch hide | download patch | download mbox

--- a/meta/recipes-core/udev/udev/init
+++ b/meta/recipes-core/udev/udev/init
@@ -103,7 +103,7 @@  case "$1" in
     udevadm control --env=STARTUP=1
     if [ "$not_first_boot" != "" ];then
             udevadm trigger --action=add --subsystem-nomatch=tty
--subsystem-nomatch=mem --subsystem-nomatch=vc
--subsystem-nomatch=vtconsole --subsystem-nomatch=misc
--subsystem-nomatch=dcon -
-            (udevadm settle --timeout=3; udevadm control --env=STARTUP=)&
+            (udevadm settle; udevadm control --env=STARTUP=)&
     else
             udevadm trigger --action=add
             udevadm settle

Comments

John Weber June 5, 2014, 7:10 p.m.
On 6/5/14, 1:38 PM, Otavio Salvador wrote:
> On Thu, Jun 5, 2014 at 3:23 PM, John Weber <rjohnweber@gmail.com> wrote:
>> On 6/5/14, 1:17 PM, Otavio Salvador wrote:
>>> On Thu, Jun 5, 2014 at 3:14 PM, John Weber <rjohnweber@gmail.com> wrote:
>>>> On 6/5/14, 1:08 PM, Otavio Salvador wrote:
>>>>> On Thu, Jun 5, 2014 at 3:05 PM, John Weber <rjohnweber@gmail.com> wrote:
>>>>>> On 6/5/14, 12:34 PM, Otavio Salvador wrote:
>>>>>>> On Mon, May 26, 2014 at 12:42 AM, John Weber <rjohnweber@gmail.com>
>>>>>>> wrote:
>>>>>>>> meta-freescalers:
>>>>>>>>
>>>>>>>> I'm seeing a behavior that I can't easily explain.  I'm not seeing
>>>>>>>> the
>>>>>>>> mxc_v4l2_capture drivers and dependent ipu drivers being
>>>>>>>> automatically
>>>>>>>> modprobed on Wandboard during a majority of system startups (but not
>>>>>>>> all).
>>>>>>>> I was under the impression that this should be done by udev, but for
>>>>>>>> some
>>>>>>>> reason it seems to either fail or is skipped.
>>>>>>>>
>>>>>>>> I can force the driver to be loaded at startup by adding the name of
>>>>>>>> the
>>>>>>>> driver in a line in /etc/modules.  This works to load the driver
>>>>>>>> every
>>>>>>>> time
>>>>>>>> at startup, but I'm fairly certain that this is not the most ideal
>>>>>>>> approach
>>>>>>>> because (A) I have to write a recipe to make the change to
>>>>>>>> /etc/modules
>>>>>>>> and
>>>>>>>> (B) it does not explain why the driver load works sometimes, but not
>>>>>>>> all
>>>>>>>> of
>>>>>>>> the time.
>>>>>>>>
>>>>>>>> Any ideas?
>>>>>>> Does this happens with 3.0.35 and 3.10.17?
>>>>>>>
>>>>>> I did notice it on both kernels.  From what I've been able to gather
>>>>>> after
>>>>>> sending this email, the modules load at first boot on a freshly burned
>>>>>> rootfs (that hasn't been postinst'd).  After that, SW and HW resets and
>>>>>> POR
>>>>>> to not result in loaded mxc_v4l2_capture module or its dependencies.  I
>>>>>> do
>>>>>> have other modules loaded, however, all the time - the ov5640_mipi
>>>>>> driver
>>>>>> and the Broadcom WLAN drivers load without fail.
>>>>>>
>>>>>> I suspect it could be a sequencing problem, but adding the line to
>>>>>> /etc/modules fixes it.
>>>>> Are you using udev-cache?
>>>>>
>>>> I believe so:
>>>> root@wandboard-dual:/etc# find . -name *udev-cache*
>>>> ./rcS.d/S36udev-cache
>>>> ./default/udev-cache
>>>> ./init.d/udev-cache
>>> Disable it in default, please, and check if it helps.
>>>
>> That did it.  Thanks!  Not sure how to fix the problem though.
> Well ... I need a coffee ...
>
> Ok ... it seems we have a timing issue but it is related to the device settling.
>
> Please apply following change in the udev init script:
>
> --- a/meta/recipes-core/udev/udev/init
> +++ b/meta/recipes-core/udev/udev/init
> @@ -103,7 +103,7 @@ case "$1" in
>       udevadm control --env=STARTUP=1
>       if [ "$not_first_boot" != "" ];then
>               udevadm trigger --action=add --subsystem-nomatch=tty
> --subsystem-nomatch=mem --subsystem-nomatch=vc
> --subsystem-nomatch=vtconsole --subsystem-nomatch=misc
> --subsystem-nomatch=dcon -
> -            (udevadm settle --timeout=3; udevadm control --env=STARTUP=)&
> +            (udevadm settle; udevadm control --env=STARTUP=)&
>       else
>               udevadm trigger --action=add
>               udevadm settle
>
>
Nope - that doesn't help the problem.  The udevadm trigger line above includes 
"--subsystem-nomatch=platform" and if I remove that while keeping everything 
else the same, it works fine.

I'd be interested to know if anyone else sees the same problem on other machines?

John
Otavio Salvador June 5, 2014, 7:34 p.m.
On Thu, Jun 5, 2014 at 4:10 PM, John Weber <rjohnweber@gmail.com> wrote:
>
> On 6/5/14, 1:38 PM, Otavio Salvador wrote:
>>
>> On Thu, Jun 5, 2014 at 3:23 PM, John Weber <rjohnweber@gmail.com> wrote:
>>>
>>> On 6/5/14, 1:17 PM, Otavio Salvador wrote:
>>>>
>>>> On Thu, Jun 5, 2014 at 3:14 PM, John Weber <rjohnweber@gmail.com> wrote:
>>>>>
>>>>> On 6/5/14, 1:08 PM, Otavio Salvador wrote:
>>>>>>
>>>>>> On Thu, Jun 5, 2014 at 3:05 PM, John Weber <rjohnweber@gmail.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> On 6/5/14, 12:34 PM, Otavio Salvador wrote:
>>>>>>>>
>>>>>>>> On Mon, May 26, 2014 at 12:42 AM, John Weber <rjohnweber@gmail.com>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> meta-freescalers:
>>>>>>>>>
>>>>>>>>> I'm seeing a behavior that I can't easily explain.  I'm not seeing
>>>>>>>>> the
>>>>>>>>> mxc_v4l2_capture drivers and dependent ipu drivers being
>>>>>>>>> automatically
>>>>>>>>> modprobed on Wandboard during a majority of system startups (but
>>>>>>>>> not
>>>>>>>>> all).
>>>>>>>>> I was under the impression that this should be done by udev, but
>>>>>>>>> for
>>>>>>>>> some
>>>>>>>>> reason it seems to either fail or is skipped.
>>>>>>>>>
>>>>>>>>> I can force the driver to be loaded at startup by adding the name
>>>>>>>>> of
>>>>>>>>> the
>>>>>>>>> driver in a line in /etc/modules.  This works to load the driver
>>>>>>>>> every
>>>>>>>>> time
>>>>>>>>> at startup, but I'm fairly certain that this is not the most ideal
>>>>>>>>> approach
>>>>>>>>> because (A) I have to write a recipe to make the change to
>>>>>>>>> /etc/modules
>>>>>>>>> and
>>>>>>>>> (B) it does not explain why the driver load works sometimes, but
>>>>>>>>> not
>>>>>>>>> all
>>>>>>>>> of
>>>>>>>>> the time.
>>>>>>>>>
>>>>>>>>> Any ideas?
>>>>>>>>
>>>>>>>> Does this happens with 3.0.35 and 3.10.17?
>>>>>>>>
>>>>>>> I did notice it on both kernels.  From what I've been able to gather
>>>>>>> after
>>>>>>> sending this email, the modules load at first boot on a freshly
>>>>>>> burned
>>>>>>> rootfs (that hasn't been postinst'd).  After that, SW and HW resets
>>>>>>> and
>>>>>>> POR
>>>>>>> to not result in loaded mxc_v4l2_capture module or its dependencies.
>>>>>>> I
>>>>>>> do
>>>>>>> have other modules loaded, however, all the time - the ov5640_mipi
>>>>>>> driver
>>>>>>> and the Broadcom WLAN drivers load without fail.
>>>>>>>
>>>>>>> I suspect it could be a sequencing problem, but adding the line to
>>>>>>> /etc/modules fixes it.
>>>>>>
>>>>>> Are you using udev-cache?
>>>>>>
>>>>> I believe so:
>>>>> root@wandboard-dual:/etc# find . -name *udev-cache*
>>>>> ./rcS.d/S36udev-cache
>>>>> ./default/udev-cache
>>>>> ./init.d/udev-cache
>>>>
>>>> Disable it in default, please, and check if it helps.
>>>>
>>> That did it.  Thanks!  Not sure how to fix the problem though.
>>
>> Well ... I need a coffee ...
>>
>> Ok ... it seems we have a timing issue but it is related to the device
>> settling.
>>
>> Please apply following change in the udev init script:
>>
>> --- a/meta/recipes-core/udev/udev/init
>> +++ b/meta/recipes-core/udev/udev/init
>> @@ -103,7 +103,7 @@ case "$1" in
>>       udevadm control --env=STARTUP=1
>>       if [ "$not_first_boot" != "" ];then
>>               udevadm trigger --action=add --subsystem-nomatch=tty
>> --subsystem-nomatch=mem --subsystem-nomatch=vc
>> --subsystem-nomatch=vtconsole --subsystem-nomatch=misc
>> --subsystem-nomatch=dcon -
>> -            (udevadm settle --timeout=3; udevadm control --env=STARTUP=)&
>> +            (udevadm settle; udevadm control --env=STARTUP=)&
>>       else
>>               udevadm trigger --action=add
>>               udevadm settle
>>
>>
> Nope - that doesn't help the problem.  The udevadm trigger line above
> includes "--subsystem-nomatch=platform" and if I remove that while keeping
> everything else the same, it works fine.

It kind of makes sense to me; if you keep the platform skip and remove
the background & job, does it work?

> I'd be interested to know if anyone else sees the same problem on other
> machines?

I bet it is not machine dependent.
John Weber June 5, 2014, 8:30 p.m.
On 6/5/14, 2:34 PM, Otavio Salvador wrote:
> On Thu, Jun 5, 2014 at 4:10 PM, John Weber <rjohnweber@gmail.com> wrote:
>> On 6/5/14, 1:38 PM, Otavio Salvador wrote:
>>> On Thu, Jun 5, 2014 at 3:23 PM, John Weber <rjohnweber@gmail.com> wrote:
>>>> On 6/5/14, 1:17 PM, Otavio Salvador wrote:
>>>>> On Thu, Jun 5, 2014 at 3:14 PM, John Weber <rjohnweber@gmail.com> wrote:
>>>>>> On 6/5/14, 1:08 PM, Otavio Salvador wrote:
>>>>>>> On Thu, Jun 5, 2014 at 3:05 PM, John Weber <rjohnweber@gmail.com>
>>>>>>> wrote:
>>>>>>>> On 6/5/14, 12:34 PM, Otavio Salvador wrote:
>>>>>>>>> On Mon, May 26, 2014 at 12:42 AM, John Weber <rjohnweber@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>> meta-freescalers:
>>>>>>>>>>
>>>>>>>>>> I'm seeing a behavior that I can't easily explain.  I'm not seeing
>>>>>>>>>> the
>>>>>>>>>> mxc_v4l2_capture drivers and dependent ipu drivers being
>>>>>>>>>> automatically
>>>>>>>>>> modprobed on Wandboard during a majority of system startups (but
>>>>>>>>>> not
>>>>>>>>>> all).
>>>>>>>>>> I was under the impression that this should be done by udev, but
>>>>>>>>>> for
>>>>>>>>>> some
>>>>>>>>>> reason it seems to either fail or is skipped.
>>>>>>>>>>
>>>>>>>>>> I can force the driver to be loaded at startup by adding the name
>>>>>>>>>> of
>>>>>>>>>> the
>>>>>>>>>> driver in a line in /etc/modules.  This works to load the driver
>>>>>>>>>> every
>>>>>>>>>> time
>>>>>>>>>> at startup, but I'm fairly certain that this is not the most ideal
>>>>>>>>>> approach
>>>>>>>>>> because (A) I have to write a recipe to make the change to
>>>>>>>>>> /etc/modules
>>>>>>>>>> and
>>>>>>>>>> (B) it does not explain why the driver load works sometimes, but
>>>>>>>>>> not
>>>>>>>>>> all
>>>>>>>>>> of
>>>>>>>>>> the time.
>>>>>>>>>>
>>>>>>>>>> Any ideas?
>>>>>>>>> Does this happens with 3.0.35 and 3.10.17?
>>>>>>>>>
>>>>>>>> I did notice it on both kernels.  From what I've been able to gather
>>>>>>>> after
>>>>>>>> sending this email, the modules load at first boot on a freshly
>>>>>>>> burned
>>>>>>>> rootfs (that hasn't been postinst'd).  After that, SW and HW resets
>>>>>>>> and
>>>>>>>> POR
>>>>>>>> to not result in loaded mxc_v4l2_capture module or its dependencies.
>>>>>>>> I
>>>>>>>> do
>>>>>>>> have other modules loaded, however, all the time - the ov5640_mipi
>>>>>>>> driver
>>>>>>>> and the Broadcom WLAN drivers load without fail.
>>>>>>>>
>>>>>>>> I suspect it could be a sequencing problem, but adding the line to
>>>>>>>> /etc/modules fixes it.
>>>>>>> Are you using udev-cache?
>>>>>>>
>>>>>> I believe so:
>>>>>> root@wandboard-dual:/etc# find . -name *udev-cache*
>>>>>> ./rcS.d/S36udev-cache
>>>>>> ./default/udev-cache
>>>>>> ./init.d/udev-cache
>>>>> Disable it in default, please, and check if it helps.
>>>>>
>>>> That did it.  Thanks!  Not sure how to fix the problem though.
>>> Well ... I need a coffee ...
>>>
>>> Ok ... it seems we have a timing issue but it is related to the device
>>> settling.
>>>
>>> Please apply following change in the udev init script:
>>>
>>> --- a/meta/recipes-core/udev/udev/init
>>> +++ b/meta/recipes-core/udev/udev/init
>>> @@ -103,7 +103,7 @@ case "$1" in
>>>        udevadm control --env=STARTUP=1
>>>        if [ "$not_first_boot" != "" ];then
>>>                udevadm trigger --action=add --subsystem-nomatch=tty
>>> --subsystem-nomatch=mem --subsystem-nomatch=vc
>>> --subsystem-nomatch=vtconsole --subsystem-nomatch=misc
>>> --subsystem-nomatch=dcon -
>>> -            (udevadm settle --timeout=3; udevadm control --env=STARTUP=)&
>>> +            (udevadm settle; udevadm control --env=STARTUP=)&
>>>        else
>>>                udevadm trigger --action=add
>>>                udevadm settle
>>>
>>>
>> Nope - that doesn't help the problem.  The udevadm trigger line above
>> includes "--subsystem-nomatch=platform" and if I remove that while keeping
>> everything else the same, it works fine.
> It kind of makes sense to me; if you keep the platform skip and remove
> the background & job, does it work?
If you mean, remove the timeout=3 on the udevadm settle, no.  If I keep the 
platform skip, it does not work at all.

>> I'd be interested to know if anyone else sees the same problem on other
>> machines?
> I bet it is not machine dependent.
>
I think you're right, but as far as I know the only other entity that could 
confirm this would be Boundary Devices.  Eric - do you see this same issue when 
connecting your camera to Nitrogen6x?

John
Eric Nelson June 5, 2014, 8:33 p.m.
Hi all,

On 06/05/2014 01:30 PM, John Weber wrote:
> 
> On 6/5/14, 2:34 PM, Otavio Salvador wrote:
>> On Thu, Jun 5, 2014 at 4:10 PM, John Weber <rjohnweber@gmail.com> wrote:
>>> On 6/5/14, 1:38 PM, Otavio Salvador wrote:
>>>> On Thu, Jun 5, 2014 at 3:23 PM, John Weber <rjohnweber@gmail.com>
>>>> wrote:
>>>>> On 6/5/14, 1:17 PM, Otavio Salvador wrote:
>>>>>> On Thu, Jun 5, 2014 at 3:14 PM, John Weber <rjohnweber@gmail.com>
>>>>>> wrote:
>>>>>>> On 6/5/14, 1:08 PM, Otavio Salvador wrote:
>>>>>>>> On Thu, Jun 5, 2014 at 3:05 PM, John Weber <rjohnweber@gmail.com>
>>>>>>>> wrote:
>>>>>>>>> On 6/5/14, 12:34 PM, Otavio Salvador wrote:
>>>>>>>>>> On Mon, May 26, 2014 at 12:42 AM, John Weber
>>>>>>>>>> <rjohnweber@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>> meta-freescalers:
>>>>>>>>>>>
>>>>
>>>> <snip>
>>>>
>>>> Please apply following change in the udev init script:
>>>>
>>>> --- a/meta/recipes-core/udev/udev/init
>>>> +++ b/meta/recipes-core/udev/udev/init
>>>> @@ -103,7 +103,7 @@ case "$1" in
>>>>        udevadm control --env=STARTUP=1
>>>>        if [ "$not_first_boot" != "" ];then
>>>>                udevadm trigger --action=add --subsystem-nomatch=tty
>>>> --subsystem-nomatch=mem --subsystem-nomatch=vc
>>>> --subsystem-nomatch=vtconsole --subsystem-nomatch=misc
>>>> --subsystem-nomatch=dcon -
>>>> -            (udevadm settle --timeout=3; udevadm control
>>>> --env=STARTUP=)&
>>>> +            (udevadm settle; udevadm control --env=STARTUP=)&
>>>>        else
>>>>                udevadm trigger --action=add
>>>>                udevadm settle
>>>>
>>>>
>>> Nope - that doesn't help the problem.  The udevadm trigger line above
>>> includes "--subsystem-nomatch=platform" and if I remove that while
>>> keeping
>>> everything else the same, it works fine.
>> It kind of makes sense to me; if you keep the platform skip and remove
>> the background & job, does it work?
> If you mean, remove the timeout=3 on the udevadm settle, no.  If I keep
> the platform skip, it does not work at all.
> 
>>> I'd be interested to know if anyone else sees the same problem on other
>>> machines?
>> I bet it is not machine dependent.
>>
> I think you're right, but as far as I know the only other entity that
> could confirm this would be Boundary Devices.  Eric - do you see this
> same issue when connecting your camera to Nitrogen6x?
> 

I've kinda followed this thread, but I'm kinda buried and it will take
a day or two for me to confirm or deny this.

Regards,


Eric
John Weber June 5, 2014, 8:40 p.m.
On 6/5/14, 3:33 PM, Eric Nelson wrote:
> Hi all,
>
> On 06/05/2014 01:30 PM, John Weber wrote:
>> On 6/5/14, 2:34 PM, Otavio Salvador wrote:
>>> On Thu, Jun 5, 2014 at 4:10 PM, John Weber <rjohnweber@gmail.com> wrote:
>>>> On 6/5/14, 1:38 PM, Otavio Salvador wrote:
>>>>> On Thu, Jun 5, 2014 at 3:23 PM, John Weber <rjohnweber@gmail.com>
>>>>> wrote:
>>>>>> On 6/5/14, 1:17 PM, Otavio Salvador wrote:
>>>>>>> On Thu, Jun 5, 2014 at 3:14 PM, John Weber <rjohnweber@gmail.com>
>>>>>>> wrote:
>>>>>>>> On 6/5/14, 1:08 PM, Otavio Salvador wrote:
>>>>>>>>> On Thu, Jun 5, 2014 at 3:05 PM, John Weber <rjohnweber@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>> On 6/5/14, 12:34 PM, Otavio Salvador wrote:
>>>>>>>>>>> On Mon, May 26, 2014 at 12:42 AM, John Weber
>>>>>>>>>>> <rjohnweber@gmail.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>> meta-freescalers:
>>>>>>>>>>>>
>>>>> <snip>
>>>>>
>>>>> Please apply following change in the udev init script:
>>>>>
>>>>> --- a/meta/recipes-core/udev/udev/init
>>>>> +++ b/meta/recipes-core/udev/udev/init
>>>>> @@ -103,7 +103,7 @@ case "$1" in
>>>>>         udevadm control --env=STARTUP=1
>>>>>         if [ "$not_first_boot" != "" ];then
>>>>>                 udevadm trigger --action=add --subsystem-nomatch=tty
>>>>> --subsystem-nomatch=mem --subsystem-nomatch=vc
>>>>> --subsystem-nomatch=vtconsole --subsystem-nomatch=misc
>>>>> --subsystem-nomatch=dcon -
>>>>> -            (udevadm settle --timeout=3; udevadm control
>>>>> --env=STARTUP=)&
>>>>> +            (udevadm settle; udevadm control --env=STARTUP=)&
>>>>>         else
>>>>>                 udevadm trigger --action=add
>>>>>                 udevadm settle
>>>>>
>>>>>
>>>> Nope - that doesn't help the problem.  The udevadm trigger line above
>>>> includes "--subsystem-nomatch=platform" and if I remove that while
>>>> keeping
>>>> everything else the same, it works fine.
>>> It kind of makes sense to me; if you keep the platform skip and remove
>>> the background & job, does it work?
>> If you mean, remove the timeout=3 on the udevadm settle, no.  If I keep
>> the platform skip, it does not work at all.
>>
>>>> I'd be interested to know if anyone else sees the same problem on other
>>>> machines?
>>> I bet it is not machine dependent.
>>>
>> I think you're right, but as far as I know the only other entity that
>> could confirm this would be Boundary Devices.  Eric - do you see this
>> same issue when connecting your camera to Nitrogen6x?
>>
> I've kinda followed this thread, but I'm kinda buried and it will take
> a day or two for me to confirm or deny this.
>
> Regards,
>
>
> Eric
>
Thanks Eric.  It just occurred to me that it could be confirmed on the SDB or 
SDP as well.
Eric Nelson June 6, 2014, 11:10 p.m.
Hi John,

On 06/05/2014 01:33 PM, Eric Nelson wrote:
> On 06/05/2014 01:30 PM, John Weber wrote:
>>
>> <snip>
>>
>> I think you're right, but as far as I know the only other entity that
>> could confirm this would be Boundary Devices.  Eric - do you see this
>> same issue when connecting your camera to Nitrogen6x?
>>
> 
> I've kinda followed this thread, but I'm kinda buried and it will take
> a day or two for me to confirm or deny this.
> 

I just tested across a dozen assorted reboots/resets/power-cycles
and didn't see the issue with an OV5642 parallel camera and 3.10.17.

I **don't** have udev-cache configured.

Regards,


Eric
John Weber June 8, 2014, 3:51 p.m.
Thanks Eric,

On 6/6/14, 6:10 PM, Eric Nelson wrote:
> Hi John,
>
> On 06/05/2014 01:33 PM, Eric Nelson wrote:
>> On 06/05/2014 01:30 PM, John Weber wrote:
>>> <snip>
>>>
>>> I think you're right, but as far as I know the only other entity that
>>> could confirm this would be Boundary Devices.  Eric - do you see this
>>> same issue when connecting your camera to Nitrogen6x?
>>>
>> I've kinda followed this thread, but I'm kinda buried and it will take
>> a day or two for me to confirm or deny this.
>>
> I just tested across a dozen assorted reboots/resets/power-cycles
> and didn't see the issue with an OV5642 parallel camera and 3.10.17.
>
> I **don't** have udev-cache configured.
I suspect that we will need to disable it on Wandboard as well.
>
> Regards,
>
>
> Eric
Otavio Salvador June 9, 2014, 1:51 p.m.
On Sun, Jun 8, 2014 at 12:51 PM, John Weber <rjohnweber@gmail.com> wrote:
> On 6/6/14, 6:10 PM, Eric Nelson wrote:
>> On 06/05/2014 01:33 PM, Eric Nelson wrote:
>>> On 06/05/2014 01:30 PM, John Weber wrote:
>>>>
>>>> <snip>
>>>>
>>>> I think you're right, but as far as I know the only other entity that
>>>> could confirm this would be Boundary Devices.  Eric - do you see this
>>>> same issue when connecting your camera to Nitrogen6x?
>>>>
>>> I've kinda followed this thread, but I'm kinda buried and it will take
>>> a day or two for me to confirm or deny this.
>>>
>> I just tested across a dozen assorted reboots/resets/power-cycles
>> and didn't see the issue with an OV5642 parallel camera and 3.10.17.
>>
>> I **don't** have udev-cache configured.
>
> I suspect that we will need to disable it on Wandboard as well.

This is not a good fix.

I added a patch, for OE-Core/Poky, attached; please confirm it fixes it.