Patchwork mxc_v4l2_capture sometimes not being modprobed

login
register
mail settings
Submitter Otavio Salvador
Date June 5, 2014, 6:38 p.m.
Message ID <CAP9ODKpDt6K-0zdA3RfJXm2y4UnH=k-K_uYhNOa+UPJsK+nD-g@mail.gmail.com>
Download mbox | patch
Permalink /patch/73321/
State Not Applicable
Delegated to: Otavio Salvador
Headers show

Comments

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

Patch

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