Microphone is quiet when in speakerphone mode #3
Labels
Comments
AndreiLux
changed the title
|
Tried N910U version. Only bug I found is this one. When you blow directly into the microphone on speaker mode that noise goes through to other person but normal talking doesn't. Haven't found any other issues yet. Thanks for the kernel mate |
|
Hi, this is also happening to me with stock 4.4.4 rom on my SM910H, if i found anything else i'll reply, thanks. |
|
I have confirmed this bug for 910C on 13.7 also. |
AndreiLux
pushed a commit
that referenced
this issue
Apr 11, 2015
commit 03bd4e1 upstream. The following bug can be triggered by hot adding and removing a large number of xen domain0's vcpus repeatedly: BUG: unable to handle kernel NULL pointer dereference at 0000000000000004 IP: [..] find_busiest_group PGD 5a9d5067 PUD 13067 PMD 0 Oops: 0000 [#3] SMP [...] Call Trace: load_balance ? _raw_spin_unlock_irqrestore idle_balance __schedule schedule schedule_timeout ? lock_timer_base schedule_timeout_uninterruptible msleep lock_device_hotplug_sysfs online_store dev_attr_store sysfs_write_file vfs_write SyS_write system_call_fastpath Last level cache shared mask is built during CPU up and the build_sched_domain() routine takes advantage of it to setup the sched domain CPU topology. However, llc_shared_mask is not released during CPU disable, which leads to an invalid sched domainCPU topology. This patch fix it by releasing the llc_shared_mask correctly during CPU disable. Yasuaki also reported that this can happen on real hardware: https://lkml.org/lkml/2014/7/22/1018 His case is here: == Here is an example on my system. My system has 4 sockets and each socket has 15 cores and HT is enabled. In this case, each core of sockes is numbered as follows: | CPU# Socket#0 | 0-14 , 60-74 Socket#1 | 15-29, 75-89 Socket#2 | 30-44, 90-104 Socket#3 | 45-59, 105-119 Then llc_shared_mask of CPU#30 has 0x3fff80000001fffc0000000. It means that last level cache of Socket#2 is shared with CPU#30-44 and 90-104. When hot-removing socket#2 and #3, each core of sockets is numbered as follows: | CPU# Socket#0 | 0-14 , 60-74 Socket#1 | 15-29, 75-89 But llc_shared_mask is not cleared. So llc_shared_mask of CPU#30 remains having 0x3fff80000001fffc0000000. After that, when hot-adding socket#2 and #3, each core of sockets is numbered as follows: | CPU# Socket#0 | 0-14 , 60-74 Socket#1 | 15-29, 75-89 Socket#2 | 30-59 Socket#3 | 90-119 Then llc_shared_mask of CPU#30 becomes 0x3fff8000fffffffc0000000. It means that last level cache of Socket#2 is shared with CPU#30-59 and 90-104. So the mask has the wrong value. Signed-off-by: Wanpeng Li <wanpeng.li@linux.intel.com> Tested-by: Linn Crosetto <linn@hp.com> Reviewed-by: Borislav Petkov <bp@suse.de> Reviewed-by: Toshi Kani <toshi.kani@hp.com> Reviewed-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com> Cc: David Rientjes <rientjes@google.com> Cc: Prarit Bhargava <prarit@redhat.com> Cc: Steven Rostedt <srostedt@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/r/1411547885-48165-1-git-send-email-wanpeng.li@linux.intel.com Signed-off-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
AndreiLux
pushed a commit
that referenced
this issue
Apr 11, 2015
commit db93facfb0ef542aa5d8079e47580b3e669a4d82 upstream. This patch is to fix two deadlock cases. Deadlock 1: CPU #1 pinctrl_register-> pinctrl_get -> create_pinctrl (Holding lock pinctrl_maps_mutex) -> get_pinctrl_dev_from_devname (Trying to acquire lock pinctrldev_list_mutex) CPU #0 pinctrl_unregister (Holding lock pinctrldev_list_mutex) -> pinctrl_put ->> pinctrl_free -> pinctrl_dt_free_maps -> pinctrl_unregister_map (Trying to acquire lock pinctrl_maps_mutex) Simply to say CPU#1 is holding lock A and trying to acquire lock B, CPU#0 is holding lock B and trying to acquire lock A. Deadlock 2: CPU #3 pinctrl_register-> pinctrl_get -> create_pinctrl (Holding lock pinctrl_maps_mutex) -> get_pinctrl_dev_from_devname (Trying to acquire lock pinctrldev_list_mutex) CPU #2 pinctrl_unregister (Holding lock pctldev->mutex) -> pinctrl_put ->> pinctrl_free -> pinctrl_dt_free_maps -> pinctrl_unregister_map (Trying to acquire lock pinctrl_maps_mutex) CPU #0 tegra_gpio_request (Holding lock pinctrldev_list_mutex) -> pinctrl_get_device_gpio_range (Trying to acquire lock pctldev->mutex) Simply to say CPU#3 is holding lock A and trying to acquire lock D, CPU#2 is holding lock B and trying to acquire lock A, CPU#0 is holding lock D and trying to acquire lock B. Signed-off-by: Jim Lin <jilin@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
AndreiLux
pushed a commit
that referenced
this issue
Apr 11, 2015
commit ce7514526742c0898b837d4395f515b79dfb5a12 upstream. It is possible for ata_sff_flush_pio_task() to set ap->hsm_task_state to HSM_ST_IDLE in between the time __ata_sff_port_intr() checks for HSM_ST_IDLE and before it calls ata_sff_hsm_move() causing ata_sff_hsm_move() to BUG(). This problem is hard to reproduce making this patch hard to verify, but this fix will prevent the race. I have not been able to reproduce the problem, but here is a crash dump from a 2.6.32 kernel. On examining the ata port's state, its hsm_task_state field has a value of HSM_ST_IDLE: crash> struct ata_port.hsm_task_state ffff881c1121c000 hsm_task_state = 0 Normally, this should not be possible as ata_sff_hsm_move() was called from ata_sff_host_intr(), which checks hsm_task_state and won't call ata_sff_hsm_move() if it has a HSM_ST_IDLE value. PID: 11053 TASK: ffff8816e846cae0 CPU: 0 COMMAND: "sshd" #0 [ffff88008ba03960] machine_kexec at ffffffff81038f3b #1 [ffff88008ba039c0] crash_kexec at ffffffff810c5d92 #2 [ffff88008ba03a90] oops_end at ffffffff8152b510 #3 [ffff88008ba03ac0] die at ffffffff81010e0b #4 [ffff88008ba03af0] do_trap at ffffffff8152ad74 #5 [ffff88008ba03b50] do_invalid_op at ffffffff8100cf95 #6 [ffff88008ba03bf0] invalid_op at ffffffff8100bf9b [exception RIP: ata_sff_hsm_move+317] RIP: ffffffff813a77ad RSP: ffff88008ba03ca0 RFLAGS: 00010097 RAX: 0000000000000000 RBX: ffff881c1121dc60 RCX: 0000000000000000 RDX: ffff881c1121dd10 RSI: ffff881c1121dc60 RDI: ffff881c1121c000 RBP: ffff88008ba03d00 R8: 0000000000000000 R9: 000000000000002e R10: 000000000001003f R11: 000000000000009b R12: ffff881c1121c000 R13: 0000000000000000 R14: 0000000000000050 R15: ffff881c1121dd78 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #7 [ffff88008ba03d08] ata_sff_host_intr at ffffffff813a7fbd #8 [ffff88008ba03d38] ata_sff_interrupt at ffffffff813a821e #9 [ffff88008ba03d78] handle_IRQ_event at ffffffff810e6ec0
AndreiLux
pushed a commit
that referenced
this issue
Apr 11, 2015
When founding a component that has orphan connections, we should validate if it match the newly added device. If it does not match, only then should the @still_orphan flag should be set. The tested result as follows. pre: /sys/bus/coresight/devices # echo 1 > e3c42000.etb/enable_sink /sys/bus/coresight/devices # echo 1 > e3c7c000.ptm/enable_source [ 15.527692] Unable to handle kernel NULL pointer dereference at virtual address 00000124 [ 15.555142] pgd = c2294000 [ 15.564226] [00000124] *pgd=3d393831, *pte=00000000, *ppte=00000000 [ 15.585391] Internal error: Oops: 817 [#1] PREEMPT SMP ARM [ 15.603807] CPU: 0 PID: 144 Comm: sh Not tainted 3.17.0-rc1-12634-g1222fe0-dirty #3 [ 15.629490] task: ed3803c0 ti: c213a000 task.ti: c213a000 [ 15.647627] PC is at coresight_build_paths+0x1c/0x314 [ 15.664579] LR is at coresight_build_paths+0x6c/0x314 [ 15.681526] pc : [<c02da20c>] lr : [<c02da25c>] psr: 20000013 [ 15.681526] sp : c213be88 ip : c02da800 fp : 00000000 [ 15.720023] r10: 00000002 r9 : ed13250c r8 : 00000001 [ 15.737549] r7 : c213bee8 r6 : ffffffea r5 : 00000000 r4 : 00000124 [ 15.759446] r3 : ed216f24 r2 : 00000001 r1 : c213bee8 r0 : 00000000 [ 15.781346] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user post: /sys/bus/coresight/devices # echo 1 > e3c42000.etb/enable_sink /sys/bus/coresight/devices # echo 1 > e3c7c000.ptm/enable_source [ 59.934255] coresight-etb10 e3c42000.etb: ETB enabled [ 59.951317] coresight-replicator replicator0: REPLICATOR enabled [ 59.971581] coresight-funnel e3c41000.funnel: FUNNEL inport 0 enabled [ 59.993334] coresight-etm3x e3c7c000.ptm: ETM tracing enabled Signed-off-by: Kaixu Xia <xiakaixu@huawei.com> Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit 22394bc58543639e5135f19eee2b03d14e4a9b66) Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hello! Everything works fantastically with the kernel, except when on a conversation using the loudspeakers of the device. In this case, the other part doesn't hear me. I was on Samsungviet Rom, changed to Sweet ROM, fresh install, no other sound mods. Thanks and congratulations!
The text was updated successfully, but these errors were encountered: