-
Notifications
You must be signed in to change notification settings - Fork 41
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
Dsi #17
Open
ljia5
wants to merge
26
commits into
projectceladon:main
Choose a base branch
from
ljia5:dsi
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Dsi #17
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Change-Id: I6a89e81ca93cabd8a35848ebe61c2a29ad928738 Tracked-On: Signed-off-by: Zhi Jin <[email protected]>
Remove Android.mk as redefine errors are seen when multiple kernels projects are used in the Android build. Signed-off-by: Jeevaka Prabu Badrappan <[email protected]>
This driver is required if you want to use Bluetooth devices with USB interface to support SCO. Tracked-On: OAM-91225 Signed-off-by: Aiswarya Cyriac <[email protected]>
In some of the C922 camera devices, we find that GET_DEF request is not implemented for video probe and commit controls. These cameras crash when this request is received. Hence, add this quirk for C922 cameras. Tracked-On: OAM-91289 Signed-off-by: saranya <[email protected]>
removing the duplicacy of snd_card_free_when_closed() function which is called inside btusb_sco_disconnect() function. Tracked-On: OAM-95334 Signed-off-by: Prabhat Chand Pandey [email protected]
Intel Bluetooth adapter is not exiting the loopback mode on bluetooth socket closure. So, when bluetooth socket is opened again, bluetooth is not working. As per Bluetooth core specification, bluetooth adapter should exit loop back mode on hci reset. Add HCI quirk reset to make sure adapter exits loopback mode on bluetooth socket closure. Tracked-On: OAM-96067 Signed-off-by: Jeevaka Prabu Badrappan <[email protected]> Signed-off-by: Amrita Raju <[email protected]>
Freezing of process abort when a client is waiting uninterruptibly for a response. This happens when system is entering to suspend and trying to freeze all the processes and at that moment freezing aborts which leads to suspend failure. So instead of wait_event_killable() use wait_event_freezable() Signed-off-by: Kaushlendra Kumar <[email protected]>
Adding vendor command support for querying driver & firmware version. Tracked-On: OAM-94267 Signed-off-by: Jeevaka Prabu Badrappan <[email protected]> Signed-off-by: Amrita Raju <[email protected]>
L4_PAGE_OFFSET is a constant value, so don't warn about absolute relocations. Tracked-On: OAM-95581 Signed-off-by: Sami Tolvanen <[email protected]> Signed-off-by: Jeevaka Prabu Badrappan <[email protected]>
Found the deadlock issue most likely caused by thread scheduling, the problem is like: 1, thread a call i915_active_acquire_barrier function, and will call take_preallocated_barriers which is used to delete all list nodes with llist_del_all 2, hw irq is raised up, thread a is scheduled out 3, thread b seems has higher priority and is scheduled in, i915_gem_do_execbuffer->i915_active_acquire_preallocate_barrier function is called, there is following code: while (!llist_empty(&ref->preallocated_barriers)) cond_resched(); ref->preallocated_barriers is not empty, then will call cond_resched. While due to CONFIG_PREEMPT is defined, cond_resched is defined as "return 0;" It means thread b will busy wait and will not relinquish CPU. From log, we didn't see thread a get chance to be scheduled in. The result is thread b is busy waiting on ref->preallocated_barriers, dead-lock happened. At end, when rcu_cpu_stall_timeout is reached, rcu stall is detected and pop up the kernel error. Fix this issue by replacing cond_resched with usleep_range, to let thread b relinquished CPU on its own. Signed-off-by: feijiang1 <[email protected]>
Tracked-On: OAM-95316 Signed-off-by: yaravapa <[email protected]>
Tracked-On: OAM-99194 Signed-off-by: Aiswarya Cyriac <[email protected]>
Tracked-On: OAM-100635 Signed-off-by: Aiswarya Cyriac <[email protected]>
Sometimes power button does not wake up the systemm, we get suspends event right after that. here Android needs to see KEY_POWER at resume. Otherwise, its opportunistic suspend will kick in shortly. However, other OS such as Ubuntu doesn't like KEY_POWER at resume. So add a knob "/sys/module/button/parameters/key_power_at_resume" for users to select. Tracked-On: OAM-101964 Signed-off-by: Kaushlendra Kumar <[email protected]>
Whenever VM goes for suspend if there are any active VSOCK connections used to communicate with host respective vsock connections were unable to resume as freeze and restore functionality was not implemented i virtio driver. This change will fix VSOCK reconnect in case of Suspend and Resume In freeze case: Change will reset all connected sockets when the devic disappears and flush all device writes and interrupts and also delete virtqueues and flush outstanding callbacks if any. In Restore case: Change will initialize all the necessary parameter to make the virtio device ready Tracked-On: OAM-100107 Signed-off-by: Stefano Garzarella <[email protected] Signed-off-by: Vilas R K <[email protected]> Signed-off-by: Bharat Panda <[email protected]>
Intel Bluetooth adapter is not exiting the loopback mode on bluetooth socket closure. So, when bluetooth socket is opened again, bluetooth is not working. As per Bluetooth core specification, bluetooth adapter should exit loop back mode on hci reset. Add HCI quirk reset to make sure adapter exits loopback mode on bluetooth socket closure. Tracked-On: OAM-102732 Signed-off-by: Suresh, Prashanth <[email protected]>
add intel ipu6 driver revert old virtual channel api in v4l2 add sensor driver for IVI Change-Id: Ia1d3f444ffebfa8925131e54405c088a9989c0d9 Tracked-On: OAM-104898 Signed-off-by: Wang Yating <[email protected]>
Disable instruction prefetch for performance improvement on kernel 5.15.71. Change-Id: I11e1a50412fa9d27cab635c79da1ee1ab2059022 Tracked-On: OAM-105269 Signed-off-by: Ben Lin <[email protected]>
Add hkr camera driver Tracked-On: OAM-104898 Signed-off-by: Wang Yating <[email protected]>
[Changes] Fix HKR capture fps issue remove unused IPU driver files upgrade isx031 sensor driver Tracked-On: OAM-105409 Signed-off-by: Wang Yating <[email protected]>
[Changes] use ktime_get_ns() mark stream timestamp Tracked-On: OAM-105432 Signed-off-by: Wang Yating <[email protected]>
Change-Id: I516132585bab97d74ec3893f83382da7e246745c Tracked-On: OAM-104032 Signed-off-by: Jeevaka Prabu Badrappan <[email protected]>
Signed-off-by: Ankit Nautiyal <[email protected]>
GuC provides engine_id and last_switch_in ticks for an active context in the pphwsp. The context image provides a 32 bit total ticks which is the accumulated by the context (a.k.a. context[CTX_TIMESTAMP]). This information is used to calculate the context busyness as follows: If the engine_id is valid, then busyness is the sum of accumulated total ticks and active ticks. Active ticks is calculated with current gt time as reference. If engine_id is invalid, busyness is equal to accumulated total ticks. Since KMD (CPU) retrieves busyness data from 2 sources - GPU and GuC, a potential race was highlighted in an earlier review that can lead to double accounting of busyness. While the solution to this is a wip, busyness is still usable for platforms running GuC submission. Signed-off-by: John Harrison <[email protected]> Signed-off-by: Umesh Nerlige Ramappa <[email protected]>
sysopenci
pushed a commit
that referenced
this pull request
Dec 6, 2023
commit 0b0747d507bffb827e40fc0f9fb5883fffc23477 upstream. The following processes run into a deadlock. CPU 41 was waiting for CPU 29 to handle a CSD request while holding spinlock "crashdump_lock", but CPU 29 was hung by that spinlock with IRQs disabled. PID: 17360 TASK: ffff95c1090c5c40 CPU: 41 COMMAND: "mrdiagd" !# 0 [ffffb80edbf37b58] __read_once_size at ffffffff9b871a40 include/linux/compiler.h:185:0 !# 1 [ffffb80edbf37b58] atomic_read at ffffffff9b871a40 arch/x86/include/asm/atomic.h:27:0 !# 2 [ffffb80edbf37b58] dump_stack at ffffffff9b871a40 lib/dump_stack.c:54:0 # 3 [ffffb80edbf37b78] csd_lock_wait_toolong at ffffffff9b131ad5 kernel/smp.c:364:0 # 4 [ffffb80edbf37b78] __csd_lock_wait at ffffffff9b131ad5 kernel/smp.c:384:0 # 5 [ffffb80edbf37bf8] csd_lock_wait at ffffffff9b13267a kernel/smp.c:394:0 # 6 [ffffb80edbf37bf8] smp_call_function_many at ffffffff9b13267a kernel/smp.c:843:0 # 7 [ffffb80edbf37c50] smp_call_function at ffffffff9b13279d kernel/smp.c:867:0 # 8 [ffffb80edbf37c50] on_each_cpu at ffffffff9b13279d kernel/smp.c:976:0 # 9 [ffffb80edbf37c78] flush_tlb_kernel_range at ffffffff9b085c4b arch/x86/mm/tlb.c:742:0 #10 [ffffb80edbf37cb8] __purge_vmap_area_lazy at ffffffff9b23a1e0 mm/vmalloc.c:701:0 #11 [ffffb80edbf37ce0] try_purge_vmap_area_lazy at ffffffff9b23a2cc mm/vmalloc.c:722:0 #12 [ffffb80edbf37ce0] free_vmap_area_noflush at ffffffff9b23a2cc mm/vmalloc.c:754:0 #13 [ffffb80edbf37cf8] free_unmap_vmap_area at ffffffff9b23bb3b mm/vmalloc.c:764:0 #14 [ffffb80edbf37cf8] remove_vm_area at ffffffff9b23bb3b mm/vmalloc.c:1509:0 #15 [ffffb80edbf37d18] __vunmap at ffffffff9b23bb8a mm/vmalloc.c:1537:0 #16 [ffffb80edbf37d40] vfree at ffffffff9b23bc85 mm/vmalloc.c:1612:0 #17 [ffffb80edbf37d58] megasas_free_host_crash_buffer [megaraid_sas] at ffffffffc020b7f2 drivers/scsi/megaraid/megaraid_sas_fusion.c:3932:0 #18 [ffffb80edbf37d80] fw_crash_state_store [megaraid_sas] at ffffffffc01f804d drivers/scsi/megaraid/megaraid_sas_base.c:3291:0 #19 [ffffb80edbf37dc0] dev_attr_store at ffffffff9b56dd7b drivers/base/core.c:758:0 #20 [ffffb80edbf37dd0] sysfs_kf_write at ffffffff9b326acf fs/sysfs/file.c:144:0 #21 [ffffb80edbf37de0] kernfs_fop_write at ffffffff9b325fd4 fs/kernfs/file.c:316:0 #22 [ffffb80edbf37e20] __vfs_write at ffffffff9b29418a fs/read_write.c:480:0 #23 [ffffb80edbf37ea8] vfs_write at ffffffff9b294462 fs/read_write.c:544:0 #24 [ffffb80edbf37ee8] SYSC_write at ffffffff9b2946ec fs/read_write.c:590:0 #25 [ffffb80edbf37ee8] SyS_write at ffffffff9b2946ec fs/read_write.c:582:0 #26 [ffffb80edbf37f30] do_syscall_64 at ffffffff9b003ca9 arch/x86/entry/common.c:298:0 #27 [ffffb80edbf37f58] entry_SYSCALL_64 at ffffffff9ba001b1 arch/x86/entry/entry_64.S:238:0 PID: 17355 TASK: ffff95c1090c3d80 CPU: 29 COMMAND: "mrdiagd" !# 0 [ffffb80f2d3c7d30] __read_once_size at ffffffff9b0f2ab0 include/linux/compiler.h:185:0 !# 1 [ffffb80f2d3c7d30] native_queued_spin_lock_slowpath at ffffffff9b0f2ab0 kernel/locking/qspinlock.c:368:0 # 2 [ffffb80f2d3c7d58] pv_queued_spin_lock_slowpath at ffffffff9b0f244b arch/x86/include/asm/paravirt.h:674:0 # 3 [ffffb80f2d3c7d58] queued_spin_lock_slowpath at ffffffff9b0f244b arch/x86/include/asm/qspinlock.h:53:0 # 4 [ffffb80f2d3c7d68] queued_spin_lock at ffffffff9b8961a6 include/asm-generic/qspinlock.h:90:0 # 5 [ffffb80f2d3c7d68] do_raw_spin_lock_flags at ffffffff9b8961a6 include/linux/spinlock.h:173:0 # 6 [ffffb80f2d3c7d68] __raw_spin_lock_irqsave at ffffffff9b8961a6 include/linux/spinlock_api_smp.h:122:0 # 7 [ffffb80f2d3c7d68] _raw_spin_lock_irqsave at ffffffff9b8961a6 kernel/locking/spinlock.c:160:0 # 8 [ffffb80f2d3c7d88] fw_crash_buffer_store [megaraid_sas] at ffffffffc01f8129 drivers/scsi/megaraid/megaraid_sas_base.c:3205:0 # 9 [ffffb80f2d3c7dc0] dev_attr_store at ffffffff9b56dd7b drivers/base/core.c:758:0 #10 [ffffb80f2d3c7dd0] sysfs_kf_write at ffffffff9b326acf fs/sysfs/file.c:144:0 #11 [ffffb80f2d3c7de0] kernfs_fop_write at ffffffff9b325fd4 fs/kernfs/file.c:316:0 #12 [ffffb80f2d3c7e20] __vfs_write at ffffffff9b29418a fs/read_write.c:480:0 #13 [ffffb80f2d3c7ea8] vfs_write at ffffffff9b294462 fs/read_write.c:544:0 #14 [ffffb80f2d3c7ee8] SYSC_write at ffffffff9b2946ec fs/read_write.c:590:0 #15 [ffffb80f2d3c7ee8] SyS_write at ffffffff9b2946ec fs/read_write.c:582:0 #16 [ffffb80f2d3c7f30] do_syscall_64 at ffffffff9b003ca9 arch/x86/entry/common.c:298:0 #17 [ffffb80f2d3c7f58] entry_SYSCALL_64 at ffffffff9ba001b1 arch/x86/entry/entry_64.S:238:0 The lock is used to synchronize different sysfs operations, it doesn't protect any resource that will be touched by an interrupt. Consequently it's not required to disable IRQs. Replace the spinlock with a mutex to fix the deadlock. Signed-off-by: Junxiao Bi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Mike Christie <[email protected]> Cc: [email protected] Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
sysopenci
pushed a commit
that referenced
this pull request
Dec 6, 2023
[ Upstream commit a154f5f643c6ecddd44847217a7a3845b4350003 ] The following call trace shows a deadlock issue due to recursive locking of mutex "device_mutex". First lock acquire is in target_for_each_device() and second in target_free_device(). PID: 148266 TASK: ffff8be21ffb5d00 CPU: 10 COMMAND: "iscsi_ttx" #0 [ffffa2bfc9ec3b18] __schedule at ffffffffa8060e7f #1 [ffffa2bfc9ec3ba0] schedule at ffffffffa8061224 #2 [ffffa2bfc9ec3bb8] schedule_preempt_disabled at ffffffffa80615ee #3 [ffffa2bfc9ec3bc8] __mutex_lock at ffffffffa8062fd7 #4 [ffffa2bfc9ec3c40] __mutex_lock_slowpath at ffffffffa80631d3 #5 [ffffa2bfc9ec3c50] mutex_lock at ffffffffa806320c #6 [ffffa2bfc9ec3c68] target_free_device at ffffffffc0935998 [target_core_mod] #7 [ffffa2bfc9ec3c90] target_core_dev_release at ffffffffc092f975 [target_core_mod] #8 [ffffa2bfc9ec3ca0] config_item_put at ffffffffa79d250f #9 [ffffa2bfc9ec3cd0] config_item_put at ffffffffa79d2583 #10 [ffffa2bfc9ec3ce0] target_devices_idr_iter at ffffffffc0933f3a [target_core_mod] #11 [ffffa2bfc9ec3d00] idr_for_each at ffffffffa803f6fc #12 [ffffa2bfc9ec3d60] target_for_each_device at ffffffffc0935670 [target_core_mod] #13 [ffffa2bfc9ec3d98] transport_deregister_session at ffffffffc0946408 [target_core_mod] #14 [ffffa2bfc9ec3dc8] iscsit_close_session at ffffffffc09a44a6 [iscsi_target_mod] #15 [ffffa2bfc9ec3df0] iscsit_close_connection at ffffffffc09a4a88 [iscsi_target_mod] #16 [ffffa2bfc9ec3df8] finish_task_switch at ffffffffa76e5d07 #17 [ffffa2bfc9ec3e78] iscsit_take_action_for_connection_exit at ffffffffc0991c23 [iscsi_target_mod] #18 [ffffa2bfc9ec3ea0] iscsi_target_tx_thread at ffffffffc09a403b [iscsi_target_mod] #19 [ffffa2bfc9ec3f08] kthread at ffffffffa76d8080 #20 [ffffa2bfc9ec3f50] ret_from_fork at ffffffffa8200364 Fixes: 36d4cb4 ("scsi: target: Avoid that EXTENDED COPY commands trigger lock inversion") Signed-off-by: Junxiao Bi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Mike Christie <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
JeevakaPrabu
pushed a commit
that referenced
this pull request
Jun 20, 2024
[ Upstream commit f8bbc07ac535593139c875ffa19af924b1084540 ] vhost_worker will call tun call backs to receive packets. If too many illegal packets arrives, tun_do_read will keep dumping packet contents. When console is enabled, it will costs much more cpu time to dump packet and soft lockup will be detected. net_ratelimit mechanism can be used to limit the dumping rate. PID: 33036 TASK: ffff949da6f20000 CPU: 23 COMMAND: "vhost-32980" #0 [fffffe00003fce50] crash_nmi_callback at ffffffff89249253 #1 [fffffe00003fce58] nmi_handle at ffffffff89225fa3 #2 [fffffe00003fceb0] default_do_nmi at ffffffff8922642e #3 [fffffe00003fced0] do_nmi at ffffffff8922660d #4 [fffffe00003fcef0] end_repeat_nmi at ffffffff89c01663 [exception RIP: io_serial_in+20] RIP: ffffffff89792594 RSP: ffffa655314979e8 RFLAGS: 00000002 RAX: ffffffff89792500 RBX: ffffffff8af428a0 RCX: 0000000000000000 RDX: 00000000000003fd RSI: 0000000000000005 RDI: ffffffff8af428a0 RBP: 0000000000002710 R8: 0000000000000004 R9: 000000000000000f R10: 0000000000000000 R11: ffffffff8acbf64f R12: 0000000000000020 R13: ffffffff8acbf698 R14: 0000000000000058 R15: 0000000000000000 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #5 [ffffa655314979e8] io_serial_in at ffffffff89792594 #6 [ffffa655314979e8] wait_for_xmitr at ffffffff89793470 #7 [ffffa65531497a08] serial8250_console_putchar at ffffffff897934f6 #8 [ffffa65531497a20] uart_console_write at ffffffff8978b605 #9 [ffffa65531497a48] serial8250_console_write at ffffffff89796558 #10 [ffffa65531497ac8] console_unlock at ffffffff89316124 #11 [ffffa65531497b10] vprintk_emit at ffffffff89317c07 #12 [ffffa65531497b68] printk at ffffffff89318306 #13 [ffffa65531497bc8] print_hex_dump at ffffffff89650765 #14 [ffffa65531497ca8] tun_do_read at ffffffffc0b06c27 [tun] #15 [ffffa65531497d38] tun_recvmsg at ffffffffc0b06e34 [tun] #16 [ffffa65531497d68] handle_rx at ffffffffc0c5d682 [vhost_net] #17 [ffffa65531497ed0] vhost_worker at ffffffffc0c644dc [vhost] #18 [ffffa65531497f10] kthread at ffffffff892d2e72 #19 [ffffa65531497f50] ret_from_fork at ffffffff89c0022f Fixes: ef3db4a ("tun: avoid BUG, dump packet on GSO errors") Signed-off-by: Lei Chen <[email protected]> Reviewed-by: Willem de Bruijn <[email protected]> Acked-by: Jason Wang <[email protected]> Reviewed-by: Eric Dumazet <[email protected]> Acked-by: Michael S. Tsirkin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[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
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.