Skip to content
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.

Sign up for GitHub

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

Jump to bottom

4k playback issue #10

Open
kundaria opened this issue Mar 19, 2018 · 6 comments
Open

4k playback issue #10

kundaria opened this issue Mar 19, 2018 · 6 comments

Comments

@kundaria
Copy link

media player crash when i try to play H.264 or H.265 30fps videos
@jamess-huang
Copy link
Contributor

Hi,
May I know your image version ? and what command or application do you use to play the videos.
It will help us to check, if you can provide the detail step,

@kundaria
Copy link
Author

kundaria commented Mar 21, 2018 •
edited
Loading

i am trying to play
Format : H.265/HEVC
Resolution : 3840x1604
Frame Rate : 23.976 fps
Bit Rate : 16.604 Mbps
Bit Depth : 10 bit

@jamess-huang
Copy link
Contributor

May I know what application do you use to play the video? or if you play the video over the terminal, please give us the command, thanks.

@kundaria
Copy link
Author

i am using default media player which comes preinstalled with tinker os 2.0.4

@jamess-huang
Copy link
Contributor

jamess-huang commented Apr 2, 2018 •
edited by TinkerTeam
Loading

Hi
We will try the v2.0.4 image, in the meantime, could you help to test the v2.0.5 image ?
http://dlcdnet.asus.com/pub/ASUS/mb/Linux/TInker_Board/2GB/20180222-tinker-board-linaro-stretch-alip-v2.0.5.img.zip

@jamess-huang
Copy link
Contributor

jamess-huang commented Apr 2, 2018 •
edited
Loading

Hi
We have tried many videos which have the similar SPEC of you provided with image v2.0.4.
Unfortunately, we cannot duplicate the same issue with you.
Can you just provide your test video to us?

NOTE : The videos we tried can be downloaded at the below link
http://jell.yfish.us/

jamess-huang pushed a commit that referenced this issue Apr 13, 2018
@svaidy @gregkh
cpuidle: Validate cpu_dev in cpuidle_add_sysfs()
125325f 
[ Upstream commit ad0a45fd9c14feebd000b6e84189d0edff265170 ]

If a given cpu is not in cpu_present and cpu hotplug
is disabled, arch can skip setting up the cpu_dev.

Arch cpuidle driver should pass correct cpu mask
for registration, but failing to do so by the driver
causes error to propagate and crash like this:

[   30.076045] Unable to handle kernel paging request for data at address 0x00000048
[   30.076100] Faulting instruction address: 0xc0000000007b2f30
cpu 0x4d: Vector: 300 (Data Access) at [c000003feb18b670]
    pc: c0000000007b2f30: kobject_get+0x20/0x70
    lr: c0000000007b3c94: kobject_add_internal+0x54/0x3f0
    sp: c000003feb18b8f0
   msr: 9000000000009033
   dar: 48
 dsisr: 40000000
  current = 0xc000003fd2ed8300
  paca    = 0xc00000000fbab500   softe: 0        irq_happened: 0x01
    pid   = 1, comm = swapper/0
Linux version 4.11.0-rc2-svaidy+ (sv@sagarika) (gcc version 6.2.0
20161005 (Ubuntu 6.2.0-5ubuntu12) ) #10 SMP Sun Mar 19 00:08:09 IST 2017
enter ? for help
[c000003feb18b960] c0000000007b3c94 kobject_add_internal+0x54/0x3f0
[c000003feb18b9f0] c0000000007b43a4 kobject_init_and_add+0x64/0xa0
[c000003feb18ba70] c000000000e284f4 cpuidle_add_sysfs+0xb4/0x130
[c000003feb18baf0] c000000000e26038 cpuidle_register_device+0x118/0x1c0
[c000003feb18bb30] c000000000e26c48 cpuidle_register+0x78/0x120
[c000003feb18bbc0] c00000000168fd9c powernv_processor_idle_init+0x110/0x1c4
[c000003feb18bc40] c00000000000cff8 do_one_initcall+0x68/0x1d0
[c000003feb18bd00] c0000000016242f4 kernel_init_freeable+0x280/0x360
[c000003feb18bdc0] c00000000000d864 kernel_init+0x24/0x160
[c000003feb18be30] c00000000000b4e8 ret_from_kernel_thread+0x5c/0x74

Validating cpu_dev fixes the crash and reports correct error message like:

[   30.163506] Failed to register cpuidle device for cpu136
[   30.173329] Registration of powernv driver failed.

Signed-off-by: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
[ rjw: Comment massage ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bauuuuu pushed a commit to Bauuuuu/debian_kernel that referenced this issue Dec 5, 2018
@gregkh
RDS: IB: Fix null pointer issue
c9eb334 
[ Upstream commit 2c0aa08631b86a4678dbc93b9caa5248014b4458 ]

Scenario:
1. Port down and do fail over
2. Ap do rds_bind syscall

PID: 47039  TASK: ffff89887e2fe640  CPU: 47  COMMAND: "kworker/u:6"
 #0 [ffff898e35f159f0] machine_kexec at ffffffff8103abf9
 TinkerBoard#1 [ffff898e35f15a60] crash_kexec at ffffffff810b96e3
 TinkerBoard#2 [ffff898e35f15b30] oops_end at ffffffff8150f518
 TinkerBoard#3 [ffff898e35f15b60] no_context at ffffffff8104854c
 TinkerBoard#4 [ffff898e35f15ba0] __bad_area_nosemaphore at ffffffff81048675
 TinkerBoard#5 [ffff898e35f15bf0] bad_area_nosemaphore at ffffffff810487d3
 TinkerBoard#6 [ffff898e35f15c00] do_page_fault at ffffffff815120b8
 TinkerBoard#7 [ffff898e35f15d10] page_fault at ffffffff8150ea95
    [exception RIP: unknown or invalid address]
    RIP: 0000000000000000  RSP: ffff898e35f15dc8  RFLAGS: 00010282
    RAX: 00000000fffffffe  RBX: ffff889b77f6fc00  RCX:ffffffff81c99d88
    RDX: 0000000000000000  RSI: ffff896019ee08e8  RDI:ffff889b77f6fc00
    RBP: ffff898e35f15df0   R8: ffff896019ee08c8  R9:0000000000000000
    R10: 0000000000000400  R11: 0000000000000000  R12:ffff896019ee08c0
    R13: ffff889b77f6fe68  R14: ffffffff81c99d80  R15: ffffffffa022a1e0
    ORIG_RAX: ffffffffffffffff  CS: 0010 SS: 0018
 TinkerBoard#8 [ffff898e35f15dc8] cma_ndev_work_handler at ffffffffa022a228 [rdma_cm]
 TinkerBoard#9 [ffff898e35f15df8] process_one_work at ffffffff8108a7c6
 TinkerBoard#10 [ffff898e35f15e58] worker_thread at ffffffff8108bda0
 TinkerBoard#11 [ffff898e35f15ee8] kthread at ffffffff81090fe6

PID: 45659  TASK: ffff880d313d2500  CPU: 31  COMMAND: "oracle_45659_ap"
 #0 [ffff881024ccfc98] __schedule at ffffffff8150bac4
 TinkerBoard#1 [ffff881024ccfd40] schedule at ffffffff8150c2cf
 TinkerBoard#2 [ffff881024ccfd50] __mutex_lock_slowpath at ffffffff8150cee7
 TinkerBoard#3 [ffff881024ccfdc0] mutex_lock at ffffffff8150cdeb
 TinkerBoard#4 [ffff881024ccfde0] rdma_destroy_id at ffffffffa022a027 [rdma_cm]
 TinkerBoard#5 [ffff881024ccfe10] rds_ib_laddr_check at ffffffffa0357857 [rds_rdma]
 TinkerBoard#6 [ffff881024ccfe50] rds_trans_get_preferred at ffffffffa0324c2a [rds]
 TinkerBoard#7 [ffff881024ccfe80] rds_bind at ffffffffa031d690 [rds]
 TinkerBoard#8 [ffff881024ccfeb0] sys_bind at ffffffff8142a670

PID: 45659                          PID: 47039
rds_ib_laddr_check
  /* create id_priv with a null event_handler */
  rdma_create_id
  rdma_bind_addr
    cma_acquire_dev
      /* add id_priv to cma_dev->id_list */
      cma_attach_to_dev
                                    cma_ndev_work_handler
                                      /* event_hanlder is null */
                                      id_priv->id.event_handler

Signed-off-by: Guanglei Li <guanglei.li@oracle.com>
Signed-off-by: Honglei Wang <honglei.wang@oracle.com>
Reviewed-by: Junxiao Bi <junxiao.bi@oracle.com>
Reviewed-by: Yanjun Zhu <yanjun.zhu@oracle.com>
Reviewed-by: Leon Romanovsky <leonro@mellanox.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
Acked-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bauuuuu pushed a commit to Bauuuuu/debian_kernel that referenced this issue Dec 5, 2018
@maurizio-lombardi @gregkh
cdrom: do not call check_disk_change() inside cdrom_open()
5e69983 
[ Upstream commit 2bbea6e117357d17842114c65e9a9cf2d13ae8a3 ]

when mounting an ISO filesystem sometimes (very rarely)
the system hangs because of a race condition between two tasks.

PID: 6766   TASK: ffff88007b2a6dd0  CPU: 0   COMMAND: "mount"
 #0 [ffff880078447ae0] __schedule at ffffffff8168d605
 TinkerBoard#1 [ffff880078447b48] schedule_preempt_disabled at ffffffff8168ed49
 TinkerBoard#2 [ffff880078447b58] __mutex_lock_slowpath at ffffffff8168c995
 TinkerBoard#3 [ffff880078447bb8] mutex_lock at ffffffff8168bdef
 TinkerBoard#4 [ffff880078447bd0] sr_block_ioctl at ffffffffa00b6818 [sr_mod]
 TinkerBoard#5 [ffff880078447c10] blkdev_ioctl at ffffffff812fea50
 TinkerBoard#6 [ffff880078447c70] ioctl_by_bdev at ffffffff8123a8b3
 TinkerBoard#7 [ffff880078447c90] isofs_fill_super at ffffffffa04fb1e1 [isofs]
 TinkerBoard#8 [ffff880078447da8] mount_bdev at ffffffff81202570
 TinkerBoard#9 [ffff880078447e18] isofs_mount at ffffffffa04f9828 [isofs]
TinkerBoard#10 [ffff880078447e28] mount_fs at ffffffff81202d09
TinkerBoard#11 [ffff880078447e70] vfs_kern_mount at ffffffff8121ea8f
TinkerBoard#12 [ffff880078447ea8] do_mount at ffffffff81220fee
TinkerBoard#13 [ffff880078447f28] sys_mount at ffffffff812218d6
TinkerBoard#14 [ffff880078447f80] system_call_fastpath at ffffffff81698c49
    RIP: 00007fd9ea914e9a  RSP: 00007ffd5d9bf648  RFLAGS: 00010246
    RAX: 00000000000000a5  RBX: ffffffff81698c49  RCX: 0000000000000010
    RDX: 00007fd9ec2bc210  RSI: 00007fd9ec2bc290  RDI: 00007fd9ec2bcf30
    RBP: 0000000000000000   R8: 0000000000000000   R9: 0000000000000010
    R10: 00000000c0ed0001  R11: 0000000000000206  R12: 00007fd9ec2bc040
    R13: 00007fd9eb6b2380  R14: 00007fd9ec2bc210  R15: 00007fd9ec2bcf30
    ORIG_RAX: 00000000000000a5  CS: 0033  SS: 002b

This task was trying to mount the cdrom.  It allocated and configured a
super_block struct and owned the write-lock for the super_block->s_umount
rwsem. While exclusively owning the s_umount lock, it called
sr_block_ioctl and waited to acquire the global sr_mutex lock.

PID: 6785   TASK: ffff880078720fb0  CPU: 0   COMMAND: "systemd-udevd"
 #0 [ffff880078417898] __schedule at ffffffff8168d605
 TinkerBoard#1 [ffff880078417900] schedule at ffffffff8168dc59
 TinkerBoard#2 [ffff880078417910] rwsem_down_read_failed at ffffffff8168f605
 TinkerBoard#3 [ffff880078417980] call_rwsem_down_read_failed at ffffffff81328838
 TinkerBoard#4 [ffff8800784179d0] down_read at ffffffff8168cde0
 TinkerBoard#5 [ffff8800784179e8] get_super at ffffffff81201cc7
 TinkerBoard#6 [ffff880078417a10] __invalidate_device at ffffffff8123a8de
 TinkerBoard#7 [ffff880078417a40] flush_disk at ffffffff8123a94b
 TinkerBoard#8 [ffff880078417a88] check_disk_change at ffffffff8123ab50
 TinkerBoard#9 [ffff880078417ab0] cdrom_open at ffffffffa00a29e1 [cdrom]
TinkerBoard#10 [ffff880078417b68] sr_block_open at ffffffffa00b6f9b [sr_mod]
TinkerBoard#11 [ffff880078417b98] __blkdev_get at ffffffff8123ba86
TinkerBoard#12 [ffff880078417bf0] blkdev_get at ffffffff8123bd65
TinkerBoard#13 [ffff880078417c78] blkdev_open at ffffffff8123bf9b
TinkerBoard#14 [ffff880078417c90] do_dentry_open at ffffffff811fc7f7
TinkerBoard#15 [ffff880078417cd8] vfs_open at ffffffff811fc9cf
TinkerBoard#16 [ffff880078417d00] do_last at ffffffff8120d53d
TinkerBoard#17 [ffff880078417db0] path_openat at ffffffff8120e6b2
TinkerBoard#18 [ffff880078417e48] do_filp_open at ffffffff8121082b
TinkerBoard#19 [ffff880078417f18] do_sys_open at ffffffff811fdd33
TinkerBoard#20 [ffff880078417f70] sys_open at ffffffff811fde4e
TinkerBoard#21 [ffff880078417f80] system_call_fastpath at ffffffff81698c49
    RIP: 00007f29438b0c20  RSP: 00007ffc76624b78  RFLAGS: 00010246
    RAX: 0000000000000002  RBX: ffffffff81698c49  RCX: 0000000000000000
    RDX: 00007f2944a5fa70  RSI: 00000000000a0800  RDI: 00007f2944a5fa70
    RBP: 00007f2944a5f540   R8: 0000000000000000   R9: 0000000000000020
    R10: 00007f2943614c40  R11: 0000000000000246  R12: ffffffff811fde4e
    R13: ffff880078417f78  R14: 000000000000000c  R15: 00007f2944a4b010
    ORIG_RAX: 0000000000000002  CS: 0033  SS: 002b

This task tried to open the cdrom device, the sr_block_open function
acquired the global sr_mutex lock. The call to check_disk_change()
then saw an event flag indicating a possible media change and tried
to flush any cached data for the device.
As part of the flush, it tried to acquire the super_block->s_umount
lock associated with the cdrom device.
This was the same super_block as created and locked by the previous task.

The first task acquires the s_umount lock and then the sr_mutex_lock;
the second task acquires the sr_mutex_lock and then the s_umount lock.

This patch fixes the issue by moving check_disk_change() out of
cdrom_open() and let the caller take care of it.

Signed-off-by: Maurizio Lombardi <mlombard@redhat.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
asus-leslieyu pushed a commit that referenced this issue Nov 12, 2021
@rkhuangtao
Bluetooth: rtk_btusb: static init running_flag_lock
b9af286 
rtk_btusb: RTKBT_RELEASE_NAME: 20200318_BT_ANDROID_9.0
rtk_btusb: Realtek Bluetooth USB driver module init, version 5.2.1
rtk_btusb: Register usb char device interface for BT driver
BUG: spinlock bad magic on CPU#0, swapper/0/1
 lock: running_flag_lock+0x0/0x38, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.4.194 #10
Hardware name: Rockchip RK3399 Evaluation Board v3 (Android) (DT)
Call trace:
[<ffffff800808a8c0>] dump_backtrace+0x0/0x1f4
[<ffffff800808aac8>] show_stack+0x14/0x1c
[<ffffff8008416248>] dump_stack+0xb4/0xf4
[<ffffff800810b1c0>] spin_dump+0x70/0x8c
[<ffffff800810b204>] spin_bug+0x28/0x34
[<ffffff800810b2a0>] do_raw_spin_lock+0x34/0x158
[<ffffff8008d68650>] _raw_spin_lock+0x48/0x54
[<ffffff80093b996c>] btusb_init+0x200/0x21c
[<ffffff80080834a8>] do_one_initcall+0x84/0x1a8
[<ffffff8009380f10>] kernel_init_freeable+0x278/0x27c
[<ffffff8008d61d3c>] kernel_init+0x10/0xf8
[<ffffff80080832d0>] ret_from_fork+0x10/0x40

Fixes: 4c267a4 ("Bluetooth: rtk_btusb: update rtk_btusb to version 5.2.1")
Change-Id: I6ea6c46a5abccc5848ec6e1538c4d7109135b725
Signed-off-by: Tao Huang <huangtao@rock-chips.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@kundaria @jamess-huang