taking picture with selfie cam just hangs

Preview works but hitting taking an image just shows the spinner endlessly.

This is on the byzantium version with 5.11.15pureos1. I deliberately did no debugging since the question was if we want to ship it.

@martin.kepplinger if this is a driver issue and you can't reproduce let me know and i'll add some kernel logs.

it hangs similarly when trying to switch to the big cam for me, this way: https://source.puri.sm/-/snippets/924 and as capturing frames using v4l2-ctl works, I at least don't think it's a driver issue. I think @angus.ainslie already recorded logs though, which wouldn't hurt to collect here of course.

I'm basing my accusation based on the fact that the selfie cam hangs a lot in unexplained ways: taking a picture, failing to switch, succeeding in switching. Those have in common the streamoff, streamon sequence. The big camera doesn't have the same problem, and there's more divergence between them on the kernel side than userspace.

Here's the logs megapixels.txt

changed the description

added 1 camera labels

removed 1 label

taking photos using megapixels, set_stream calls:

• big cam: stop, start, stop start
• selfie cam: stop, start (only once)

the on_frame() callback isn't being called for the selfie cam when taking a photo

it's registered normally though

Strace shows a separate thread polling on the fd:

[pid 544910] poll([{fd=10, events=POLLIN}, {fd=11, events=POLLIN}], 2, -1 <unfinished ...>
[pid 544910] <... poll resumed>)        = 1 ([{fd=11, revents=POLLIN}])

My L5 is dead right now, but it probably means the camera device never wakes up the poll.

Tracked where the poll goes on the kernel side in normal circumstances:

=> vb2_poll (ffff800008f28670)
=> vb2_fop_poll (ffff800008f28924)
=> v4l2_poll (ffff800008eca2d4)
=> do_sys_poll (ffff8000102bc374)
=> __arm64_sys_ppoll (ffff8000102bd4ec)
=> el0_svc_common.constprop.2 (ffff8000100258fc)
=> do_el0_svc (ffff8000100259bc)
=> el0_svc (ffff800010b6a46c)
=> el0_sync_handler (ffff800010b6a9d8)
=> el0_sync (ffff800010011d14)

Digging deeper, the flowing stream does this in a loop:

1. frame_done
2. qbuf
3. prepare
4. queue
5. poll
6. dqbuf

      megapixels-1960  [003]    85.594811: function:             v4l2_poll
      megapixels-1960  [003]    85.594838: function:             mx6s_vidioc_dqbuf
          <idle>-0     [000]    85.608121: function:             mx6s_csi_irq_handler
          <idle>-0     [000]    85.623495: function:             mx6s_csi_irq_handler
          <idle>-0     [000]    85.623502: function:                mx6s_csi_frame_done.constprop.21
      megapixels-1960  [003]    85.636808: function:             mx6s_vidioc_qbuf
      megapixels-1960  [003]    85.636819: function:             mx6s_videobuf_prepare
      megapixels-1960  [003]    85.636825: function:             mx6s_videobuf_queue
      megapixels-1960  [003]    85.636862: function:             v4l2_poll
      megapixels-1960  [003]    85.636883: function:             mx6s_vidioc_dqbuf
      megapixels-1958  [000]    85.639973: function:             mx6s_csi_irq_handler
      megapixels-1958  [000]    85.655491: function:             mx6s_csi_irq_handler
      megapixels-1958  [000]    85.655498: function:                mx6s_csi_frame_done.constprop.21
      megapixels-1958  [000]    85.671970: function:             mx6s_csi_irq_handler
      megapixels-1960  [003]    85.676036: function:             mx6s_vidioc_qbuf
      megapixels-1960  [003]    85.676046: function:             mx6s_videobuf_prepare
      megapixels-1960  [003]    85.676050: function:             mx6s_videobuf_queue
      megapixels-1960  [003]    85.676078: function:             v4l2_poll

The stuck stream starts the same as the flowing one:

[init skipped]
      megapixels-4989  [002]   527.559833: function:             mx6s_videobuf_queue
      megapixels-4989  [002]   527.559835: function:             mx6s_start_streaming
      megapixels-4989  [002]   527.606153: function:             hi846_set_stream
      megapixels-4989  [001]   527.719443: function:             mx6s_vidioc_g_ctrl
      megapixels-4989  [001]   527.719457: function:             mx6s_vidioc_g_ctrl
      megapixels-4989  [001]   527.719463: function:             mx6s_vidioc_g_ctrl
      megapixels-4989  [001]   527.719466: function:             mx6s_vidioc_g_ctrl
      megapixels-4989  [001]   527.719472: function:             mx6s_vidioc_g_ctrl
      megapixels-4989  [001]   527.719545: function:             v4l2_poll
      megapixels-4989  [001]   527.719558: function:             v4l2_poll

But then it stops. What's expected is an interrupt and another poll:

          single-5020  [000]   527.730587: function:             mx6s_csi_irq_handler
          single-5020  [000]   527.762583: function:             mx6s_csi_irq_handler
 systemd-coredum-5032  [000]   527.794578: function:             mx6s_csi_irq_handler
 systemd-coredum-5032  [000]   527.826573: function:             mx6s_csi_irq_handler
 systemd-coredum-5032  [000]   527.842088: function:             mx6s_csi_irq_handler
 systemd-coredum-5032  [000]   527.858569: function:             mx6s_csi_irq_handler
 systemd-coredum-5032  [000]   527.874083: function:             mx6s_csi_irq_handler
 systemd-coredum-5032  [000]   527.890565: function:             mx6s_csi_irq_handler
 systemd-coredum-5032  [000]   527.906091: function:             mx6s_csi_irq_handler
 systemd-coredum-5032  [000]   527.906096: function:                mx6s_csi_frame_done.constprop.21
      megapixels-4989  [001]   527.906665: function:             v4l2_poll
      megapixels-4989  [001]   527.906717: function:             mx6s_vidioc_dqbuf

There's nothing in dmesg, but I didn't turn on any debugging.

The log is very similar to the situation where I switch away from selfie and back. It's hung 100% of the time.

mentioned in issue #321 (closed)

mentioned in merge request !389 (merged)

closed with merge request !389 (merged)

For the record, on Birch with a hacked up module (no ability to change reset pin voltage), it still hangs.

It does not hang if Megapixels is restarted, which makes me suspect that there's still some problem there. However, getting another hacked up Birch might be difficult.

mentioned in issue #324