This repository has been archived by the owner on Aug 12, 2023. It is now read-only.
The camera does not start #2
Comments
|
which branch cm-12.1 or cm-13.0 cm-11.0 |
|
cm-13.0 |
|
And can I take part in yours with Mukul Soni development with CyanogenMod 13.0? I built my own ROM :) I'll be very happy. I can attract help of members of the forum from site 4pda.ru. |
|
you can join this org but not the @mukulsoni 's one as he have his own tree 👍 |
aapav01
pushed a commit
that referenced
this issue
Feb 12, 2016
The first ESV2 parts that were sent to us from QCOM are not screened to ensure that they only operate at 1.2GHz and below. This is a workaround by forcing all units with speed bin #2 efuse using freq table 1p2 therefore operating at no higher than 1.2GHz. Change-Id: I9d23c62b00e44c5aaedac516d068671f48041c9f Signed-off-by: Peng Liu <[email protected]> Reviewed-on: http://gerrit.pcs.mot.com/551207 SLT-Approved: Slta Waiver <[email protected]> Tested-by: Jira Key <[email protected]> Reviewed-by: Check Patch <[email protected]> Reviewed-by: Klocwork kwcheck <[email protected]> Reviewed-by: Srinivas Sripathi <[email protected]> Reviewed-by: Jeffrey Carlyle <[email protected]> Submit-Approved: Jira Key <[email protected]>
aapav01
pushed a commit
that referenced
this issue
Feb 13, 2016
The first ESV2 parts that were sent to us from QCOM are not screened to ensure that they only operate at 1.2GHz and below. This is a workaround by forcing all units with speed bin #2 efuse using freq table 1p2 therefore operating at no higher than 1.2GHz. Change-Id: I9d23c62b00e44c5aaedac516d068671f48041c9f Signed-off-by: Peng Liu <[email protected]> Reviewed-on: http://gerrit.pcs.mot.com/551207 SLT-Approved: Slta Waiver <[email protected]> Tested-by: Jira Key <[email protected]> Reviewed-by: Check Patch <[email protected]> Reviewed-by: Klocwork kwcheck <[email protected]> Reviewed-by: Srinivas Sripathi <[email protected]> Reviewed-by: Jeffrey Carlyle <[email protected]> Submit-Approved: Jira Key <[email protected]>
aapav01
pushed a commit
that referenced
this issue
Apr 11, 2016
Otherwise, we can get mismatched largest extent information. One example is: 1. mount f2fs w/ extent_cache 2. make a small extent 3. umount 4. mount f2fs w/o extent_cache 5. update the largest extent 6. umount 7. mount f2fs w/ extent_cache 8. get the old extent made by #2 Signed-off-by: Jaegeuk Kim <[email protected]>
aghontpi
added a commit
to aghontpi/android_kernel_samsung_ms013g
that referenced
this issue
May 15, 2016
Change-Id: Ic82114a7dc9b479c6d8ebebb6e09738718cd98c5
neonkat
pushed a commit
to neonkat/android_kernel_samsung_ms013g
that referenced
this issue
Jun 25, 2016
commit a1cbcaa9ea87b87a96b9fc465951dcf36e459ca2 upstream. The sched_clock_remote() implementation has the following inatomicity problem on 32bit systems when accessing the remote scd->clock, which is a 64bit value. CPU0 CPU1 sched_clock_local() sched_clock_remote(CPU0) ... remote_clock = scd[CPU0]->clock read_low32bit(scd[CPU0]->clock) cmpxchg64(scd->clock,...) read_high32bit(scd[CPU0]->clock) While the update of scd->clock is using an atomic64 mechanism, the readout on the remote cpu is not, which can cause completely bogus readouts. It is a quite rare problem, because it requires the update to hit the narrow race window between the low/high readout and the update must go across the 32bit boundary. The resulting misbehaviour is, that CPU1 will see the sched_clock on CPU1 ~4 seconds ahead of it's own and update CPU1s sched_clock value to this bogus timestamp. This stays that way due to the clamping implementation for about 4 seconds until the synchronization with CLOCK_MONOTONIC undoes the problem. The issue is hard to observe, because it might only result in a less accurate SCHED_OTHER timeslicing behaviour. To create observable damage on realtime scheduling classes, it is necessary that the bogus update of CPU1 sched_clock happens in the context of an realtime thread, which then gets charged 4 seconds of RT runtime, which results in the RT throttler mechanism to trigger and prevent scheduling of RT tasks for a little less than 4 seconds. So this is quite unlikely as well. The issue was quite hard to decode as the reproduction time is between 2 days and 3 weeks and intrusive tracing makes it less likely, but the following trace recorded with trace_clock=global, which uses sched_clock_local(), gave the final hint: <idle>-0 0d..30 400269.477150: hrtimer_cancel: hrtimer=0xf7061e80 <idle>-0 0d..30 400269.477151: hrtimer_start: hrtimer=0xf7061e80 ... irq/20-S-587 1d..32 400273.772118: sched_wakeup: comm= ... target_cpu=0 <idle>-0 0dN.30 400273.772118: hrtimer_cancel: hrtimer=0xf7061e80 What happens is that CPU0 goes idle and invokes sched_clock_idle_sleep_event() which invokes sched_clock_local() and CPU1 runs a remote wakeup for CPU0 at the same time, which invokes sched_remote_clock(). The time jump gets propagated to CPU0 via sched_remote_clock() and stays stale on both cores for ~4 seconds. There are only two other possibilities, which could cause a stale sched clock: 1) ktime_get() which reads out CLOCK_MONOTONIC returns a sporadic wrong value. 2) sched_clock() which reads the TSC returns a sporadic wrong value. MSM8226-Samsung#1 can be excluded because sched_clock would continue to increase for one jiffy and then go stale. MSM8226-Samsung#2 can be excluded because it would not make the clock jump forward. It would just result in a stale sched_clock for one jiffy. After quite some brain twisting and finding the same pattern on other traces, sched_clock_remote() remained the only place which could cause such a problem and as explained above it's indeed racy on 32bit systems. So while on 64bit systems the readout is atomic, we need to verify the remote readout on 32bit machines. We need to protect the local->clock readout in sched_clock_remote() on 32bit as well because an NMI could hit between the low and the high readout, call sched_clock_local() and modify local->clock. Thanks to Siegfried Wulsch for bearing with my debug requests and going through the tedious tasks of running a bunch of reproducer systems to generate the debug information which let me decode the issue. Reported-by: Siegfried Wulsch <[email protected]> Acked-by: Peter Zijlstra <[email protected]> Cc: Steven Rostedt <[email protected]> Link: http://lkml.kernel.org/r/alpine.LFD.2.02.1304051544160.21884@ionos Signed-off-by: Thomas Gleixner <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
01-04 20:42:36.390 249 774 E mm-camera-intf: mm_camera_open: opened, break out while loop
01-04 20:42:36.390 249 774 E mm-camera-intf: mm_camera_open: cannot open control fd of '/dev/video2' (Connection timed out)
01-04 20:42:36.390 249 774 E mm-camera-intf: mm_camera_socket_create: socket_fd =17
01-04 20:42:36.390 249 774 E mm-camera-intf: mm_camera_socket_create: value of rc=-1
01-04 20:42:36.390 249 774 E mm-camera-intf: mm_camera_socket_create: socket_fd=-1 No such file or directory
01-04 20:42:36.412 249 774 E mm-camera-intf: mm_camera_socket_create: socket_fd =17
01-04 20:42:36.412 249 774 E mm-camera-intf: mm_camera_socket_create: value of rc=-1
01-04 20:42:36.412 249 774 E mm-camera-intf: mm_camera_socket_create: socket_fd=-1 No such file or directory
01-04 20:42:36.412 249 774 E mm-camera-intf: mm_camera_open: cannot open domain socket fd of '/dev/video2'(No such file or directory)
01-04 20:42:36.412 249 774 E mm-camera-intf: camera_open: mm_camera_open err = -1
01-04 20:42:36.412 249 774 E QCamera2HWI: initCapabilities: camera_open failed
01-04 20:42:36.412 249 774 W QCamera2HWI: getCapabilities : __dbg: init capabilities rc = -2147483648, :0
01-04 20:42:36.412 249 774 E QCamera2Factory: [getCameraInfo] __dbg: getCapabilities failed
01-04 20:42:36.412 249 774 W QCamera2Factory: getCameraInfo: X
01-04 20:42:36.417 4286 4286 E CAM2PORT_AndCamAgntImp: Exception while creating CameraDeviceInfo
01-04 20:42:36.417 4286 4286 E CAM2PORT_AndCamAgntImp: java.lang.RuntimeException: Fail to get camera info
01-04 20:42:36.417 4286 4286 E CAM2PORT_AndCamAgntImp: at android.hardware.Camera._getCameraInfo(Native Method)
01-04 20:42:36.417 4286 4286 E CAM2PORT_AndCamAgntImp: at android.hardware.Camera.getCameraInfo(Camera.java:244)
01-04 20:42:36.417 4286 4286 E CAM2PORT_AndCamAgntImp: at com.android.ex.camera2.portability.AndroidCameraAgentImpl$AndroidCameraDeviceInfo.create(AndroidCameraAgentImpl.java:151)
01-04 20:42:36.417 4286 4286 E CAM2PORT_AndCamAgntImp: at com.android.ex.camera2.portability.AndroidCameraAgentImpl.getCameraDeviceInfo(AndroidCameraAgentImpl.java:99)
01-04 20:42:36.417 4286 4286 E CAM2PORT_AndCamAgntImp: at com.android.camera.app.CameraController.(CameraController.java:93)
01-04 20:42:36.417 4286 4286 E CAM2PORT_AndCamAgntImp: at com.android.camera.CameraActivity.onCreateTasks(CameraActivity.java:1480)
01-04 20:42:36.417 4286 4286 E CAM2PORT_AndCamAgntImp: at com.android.camera.util.QuickActivity.onCreate(QuickActivity.java:114)
01-04 20:42:36.417 4286 4286 E CAM2PORT_AndCamAgntImp: at android.app.Activity.performCreate(Activity.java:6237)
01-04 20:42:36.417 4286 4286 E CAM2PORT_AndCamAgntImp: at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1108)
01-04 20:42:36.417 4286 4286 E CAM2PORT_AndCamAgntImp: at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2403)
01-04 20:42:36.417 4286 4286 E CAM2PORT_AndCamAgntImp: at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2520)
01-04 20:42:36.417 4286 4286 E CAM2PORT_AndCamAgntImp: at android.app.ActivityThread.-wrap11(ActivityThread.java)
01-04 20:42:36.417 4286 4286 E CAM2PORT_AndCamAgntImp: at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1363)
01-04 20:42:36.417 4286 4286 E CAM2PORT_AndCamAgntImp: at android.os.Handler.dispatchMessage(Handler.java:102)
01-04 20:42:36.417 4286 4286 E CAM2PORT_AndCamAgntImp: at android.os.Looper.loop(Looper.java:148)
01-04 20:42:36.417 4286 4286 E CAM2PORT_AndCamAgntImp: at android.app.ActivityThread.main(ActivityThread.java:5466)
01-04 20:42:36.417 4286 4286 E CAM2PORT_AndCamAgntImp: at java.lang.reflect.Method.invoke(Native Method)
01-04 20:42:36.417 4286 4286 E CAM2PORT_AndCamAgntImp: at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:726)
01-04 20:42:36.417 4286 4286 E CAM2PORT_AndCamAgntImp: at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:616)
01-04 20:42:36.417 4286 4286 W CAM_CameraActivity: Camera open failure: GETTING_CAMERA_INFO
01-04 20:42:36.418 4286 4286 E CAM_FatalErrorHandler: Handling Camera Open Failure:
01-04 20:42:36.418 4286 4286 E CAM_FatalErrorHandler: java.lang.Exception
01-04 20:42:36.418 4286 4286 E CAM_FatalErrorHandler: at com.android.camera.FatalErrorHandlerImpl.onCameraOpenFailure(FatalErrorHandlerImpl.java:52)
01-04 20:42:36.418 4286 4286 E CAM_FatalErrorHandler: at com.android.camera.CameraActivity.onDeviceOpenFailure(CameraActivity.java:553)
01-04 20:42:36.418 4286 4286 E CAM_FatalErrorHandler: at com.android.camera.app.CameraController.(CameraController.java:95)
01-04 20:42:36.418 4286 4286 E CAM_FatalErrorHandler: at com.android.camera.CameraActivity.onCreateTasks(CameraActivity.java:1480)
01-04 20:42:36.418 4286 4286 E CAM_FatalErrorHandler: at com.android.camera.util.QuickActivity.onCreate(QuickActivity.java:114)
01-04 20:42:36.418 4286 4286 E CAM_FatalErrorHandler: at android.app.Activity.performCreate(Activity.java:6237)
01-04 20:42:36.418 4286 4286 E CAM_FatalErrorHandler: at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1108)
01-04 20:42:36.418 4286 4286 E CAM_FatalErrorHandler: at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2403)
01-04 20:42:36.418 4286 4286 E CAM_FatalErrorHandler: at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2520)
01-04 20:42:36.418 4286 4286 E CAM_FatalErrorHandler: at android.app.ActivityThread.-wrap11(ActivityThread.java)
01-04 20:42:36.418 4286 4286 E CAM_FatalErrorHandler: at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1363)
01-04 20:42:36.418 4286 4286 E CAM_FatalErrorHandler: at android.os.Handler.dispatchMessage(Handler.java:102)
01-04 20:42:36.418 4286 4286 E CAM_FatalErrorHandler: at android.os.Looper.loop(Looper.java:148)
01-04 20:42:36.418 4286 4286 E CAM_FatalErrorHandler: at android.app.ActivityThread.main(ActivityThread.java:5466)
01-04 20:42:36.418 4286 4286 E CAM_FatalErrorHandler: at java.lang.reflect.Method.invoke(Native Method)
01-04 20:42:36.418 4286 4286 E CAM_FatalErrorHandler: at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:726)
01-04 20:42:36.418 4286 4286 E CAM_FatalErrorHandler: at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:616)
01-04 20:42:36.423 249 1151 W QCamera2Factory: getCameraInfo: E, camera_id = 0
#1-04 20:42:36.423 249 1151 E mm-camera-intf: mm_camera_open: begin
How can I fix it?
The text was updated successfully, but these errors were encountered: