-
Notifications
You must be signed in to change notification settings - Fork 105
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Dots pattern on IMX398 (OP5 + OP5T) in HAL3 RAW #16
Comments
Bump |
jgcaap
pushed a commit
to NewRom/android_kernel_oneplus_msm8998
that referenced
this issue
Feb 27, 2018
commit efdab99 upstream. syzkaller reported: WARNING: CPU: 0 PID: 12927 at arch/x86/kernel/traps.c:780 do_debug+0x222/0x250 CPU: 0 PID: 12927 Comm: syz-executor Tainted: G OE 4.15.0-rc2+ OnePlusOSS#16 RIP: 0010:do_debug+0x222/0x250 Call Trace: <#DB> debug+0x3e/0x70 RIP: 0010:copy_user_enhanced_fast_string+0x10/0x20 </#DB> _copy_from_user+0x5b/0x90 SyS_timer_create+0x33/0x80 entry_SYSCALL_64_fastpath+0x23/0x9a The testcase sets a watchpoint (with perf_event_open) on a buffer that is passed to timer_create() as the struct sigevent argument. In timer_create(), copy_from_user()'s rep movsb triggers the BP. The testcase also sets the debug registers for the guest. However, KVM only restores host debug registers when the host has active watchpoints, which triggers a race condition when running the testcase with multiple threads. The guest's DR6.BS bit can escape to the host before another thread invokes timer_create(), and do_debug() complains. The fix is to respect do_debug()'s dr6 invariant when leaving KVM. Reported-by: Dmitry Vyukov <[email protected]> Cc: Paolo Bonzini <[email protected]> Cc: Radim Krčmář <[email protected]> Cc: David Hildenbrand <[email protected]> Cc: Dmitry Vyukov <[email protected]> Reviewed-by: David Hildenbrand <[email protected]> Signed-off-by: Wanpeng Li <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]> Signed-off-by: Radim Krčmář <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
jgcaap
pushed a commit
to NewRom/android_kernel_oneplus_msm8998
that referenced
this issue
Feb 27, 2018
[ Upstream commit 5811767 ] According to LS1021A RM, the value of PAL can be set so that the start of the IP header in the receive data buffer is aligned to a 32-bit boundary. Normally, setting PAL = 2 provides minimal padding to ensure such alignment of the IP header. However every incoming packet's 8-byte time stamp will be inserted into the packet data buffer as padding alignment bytes when hardware time stamping is enabled. So we set the padding 8+2 here to avoid the flooded alignment faults: root@128:~# cat /proc/cpu/alignment User: 0 System: 17539 (inet_gro_receive+0x114/0x2c0) Skipped: 0 Half: 0 Word: 0 DWord: 0 Multi: 17539 User faults: 2 (fixup) Also shown when exception report enablement CPU: 0 PID: 161 Comm: irq/66-eth1_g0_ Not tainted 4.1.21-rt13-WR8.0.0.0_preempt-rt OnePlusOSS#16 Hardware name: Freescale LS1021A [<8001b420>] (unwind_backtrace) from [<8001476c>] (show_stack+0x20/0x24) [<8001476c>] (show_stack) from [<807cfb48>] (dump_stack+0x94/0xac) [<807cfb48>] (dump_stack) from [<80025d70>] (do_alignment+0x720/0x958) [<80025d70>] (do_alignment) from [<80009224>] (do_DataAbort+0x40/0xbc) [<80009224>] (do_DataAbort) from [<80015398>] (__dabt_svc+0x38/0x60) Exception stack(0x86ad1cc0 to 0x86ad1d08) 1cc0: f9b3e080 86b3d072 2d78d287 00000000 866816c0 86b3d05e 86e785d0 00000000 1ce0: 00000011 0000000e 80840ab0 86ad1d3c 86ad1d08 86ad1d08 806d7fc0 806d806c 1d00: 40070013 ffffffff [<80015398>] (__dabt_svc) from [<806d806c>] (inet_gro_receive+0x114/0x2c0) [<806d806c>] (inet_gro_receive) from [<80660eec>] (dev_gro_receive+0x21c/0x3c0) [<80660eec>] (dev_gro_receive) from [<8066133c>] (napi_gro_receive+0x44/0x17c) [<8066133c>] (napi_gro_receive) from [<804f0538>] (gfar_clean_rx_ring+0x39c/0x7d4) [<804f0538>] (gfar_clean_rx_ring) from [<804f0bf4>] (gfar_poll_rx_sq+0x58/0xe0) [<804f0bf4>] (gfar_poll_rx_sq) from [<80660b10>] (net_rx_action+0x27c/0x43c) [<80660b10>] (net_rx_action) from [<80033638>] (do_current_softirqs+0x1e0/0x3dc) [<80033638>] (do_current_softirqs) from [<800338c4>] (__local_bh_enable+0x90/0xa8) [<800338c4>] (__local_bh_enable) from [<8008025c>] (irq_forced_thread_fn+0x70/0x84) [<8008025c>] (irq_forced_thread_fn) from [<800805e8>] (irq_thread+0x16c/0x244) [<800805e8>] (irq_thread) from [<8004e490>] (kthread+0xe8/0x104) [<8004e490>] (kthread) from [<8000fda8>] (ret_from_fork+0x14/0x2c) Signed-off-by: Zumeng Chen <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
arter97
pushed a commit
to arter97/android_kernel_oneplus_msm8998
that referenced
this issue
May 14, 2019
[ Upstream commit 42dfa45 ] Using gcc's ASan, Changbin reports: ================================================================= ==7494==ERROR: LeakSanitizer: detected memory leaks Direct leak of 48 byte(s) in 1 object(s) allocated from: #0 0x7f0333a89138 in calloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xee138) #1 0x5625e5330a5e in zalloc util/util.h:23 #2 0x5625e5330a9b in perf_counts__new util/counts.c:10 OnePlusOSS#3 0x5625e5330ca0 in perf_evsel__alloc_counts util/counts.c:47 OnePlusOSS#4 0x5625e520d8e5 in __perf_evsel__read_on_cpu util/evsel.c:1505 OnePlusOSS#5 0x5625e517a985 in perf_evsel__read_on_cpu /home/work/linux/tools/perf/util/evsel.h:347 OnePlusOSS#6 0x5625e517ad1a in test__openat_syscall_event tests/openat-syscall.c:47 OnePlusOSS#7 0x5625e51528e6 in run_test tests/builtin-test.c:358 OnePlusOSS#8 0x5625e5152baf in test_and_print tests/builtin-test.c:388 OnePlusOSS#9 0x5625e51543fe in __cmd_test tests/builtin-test.c:583 OnePlusOSS#10 0x5625e515572f in cmd_test tests/builtin-test.c:722 OnePlusOSS#11 0x5625e51c3fb8 in run_builtin /home/changbin/work/linux/tools/perf/perf.c:302 OnePlusOSS#12 0x5625e51c44f7 in handle_internal_command /home/changbin/work/linux/tools/perf/perf.c:354 OnePlusOSS#13 0x5625e51c48fb in run_argv /home/changbin/work/linux/tools/perf/perf.c:398 OnePlusOSS#14 0x5625e51c5069 in main /home/changbin/work/linux/tools/perf/perf.c:520 OnePlusOSS#15 0x7f033214d09a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2409a) Indirect leak of 72 byte(s) in 1 object(s) allocated from: #0 0x7f0333a89138 in calloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xee138) #1 0x5625e532560d in zalloc util/util.h:23 #2 0x5625e532566b in xyarray__new util/xyarray.c:10 OnePlusOSS#3 0x5625e5330aba in perf_counts__new util/counts.c:15 OnePlusOSS#4 0x5625e5330ca0 in perf_evsel__alloc_counts util/counts.c:47 OnePlusOSS#5 0x5625e520d8e5 in __perf_evsel__read_on_cpu util/evsel.c:1505 OnePlusOSS#6 0x5625e517a985 in perf_evsel__read_on_cpu /home/work/linux/tools/perf/util/evsel.h:347 OnePlusOSS#7 0x5625e517ad1a in test__openat_syscall_event tests/openat-syscall.c:47 OnePlusOSS#8 0x5625e51528e6 in run_test tests/builtin-test.c:358 OnePlusOSS#9 0x5625e5152baf in test_and_print tests/builtin-test.c:388 OnePlusOSS#10 0x5625e51543fe in __cmd_test tests/builtin-test.c:583 OnePlusOSS#11 0x5625e515572f in cmd_test tests/builtin-test.c:722 OnePlusOSS#12 0x5625e51c3fb8 in run_builtin /home/changbin/work/linux/tools/perf/perf.c:302 OnePlusOSS#13 0x5625e51c44f7 in handle_internal_command /home/changbin/work/linux/tools/perf/perf.c:354 OnePlusOSS#14 0x5625e51c48fb in run_argv /home/changbin/work/linux/tools/perf/perf.c:398 OnePlusOSS#15 0x5625e51c5069 in main /home/changbin/work/linux/tools/perf/perf.c:520 OnePlusOSS#16 0x7f033214d09a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2409a) His patch took care of evsel->prev_raw_counts, but the above backtraces are about evsel->counts, so fix that instead. Reported-by: Changbin Du <[email protected]> Cc: Alexei Starovoitov <[email protected]> Cc: Daniel Borkmann <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Steven Rostedt (VMware) <[email protected]> Link: https://lkml.kernel.org/n/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When Camera2 API is used (HAL3), a RAW picture taken with OP5 and OP5T has a dots pattern. But when you take with HAL1 (Oneplus stock camera), RAW picture hasn't dots pattern.
What I found in logs:
The mct_stream_start_link (raw stream with is_secure 0) is different :
The axi_src: IDEAL_RAW is only mentionned when HAL1 is used.
RAW image from HAL1
RAW image from HAL3
The text was updated successfully, but these errors were encountered: