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

New amlogic cec driver #5

Open
wants to merge 1 commit into
base: amlogic-3.10.y
Choose a base branch
from
Open

New amlogic cec driver #5

wants to merge 1 commit into from

Conversation

gdachs
Copy link

@gdachs gdachs commented Feb 15, 2016

This cec driver supports the libcec and is successfully tested with the wetek play.
Will be activated by the kernel config:
CONFIG_AML_HDMI_TX_NEW_CEC_DRIVER=y

to switch of debug logging:

echo 0 >/sys/devices/virtual/amhdmitx/amhdmitx0/amlogic_cec_debug_config

@gdachs gdachs mentioned this pull request Feb 15, 2016
Merged
@gdachs gdachs force-pushed the new-cec-driver branch 2 times, most recently from cc752a3 to 3bde219 Compare February 16, 2016 19:28
@kszaq
Copy link

kszaq commented Feb 17, 2016

Hello @gdachs. This is a really great addition and thank you for the amazing work.

However, it does not work for me. I compiled this for a S805 box (meson8b platform) and it worked with a LG TV but does not with a Samsung TV. I tried connecting my box both via an AVR and directly to TV. My TV shows the box on a list (listed as "Recorder") but can't control it and after a while there's a failure message from my TV.

Here's a dmesg collected a minute after boot:
http://sprunge.us/giMV

Please let me know what debug information can I provide to help.

@gdachs
Copy link
Author

gdachs commented Feb 17, 2016

I support only devices that I own and that are supported by the OpenELEC team. This driver is tested with Wetek Core/Play with TVs from Samsung and LG. The low level driver from Amlogic that I have to use is very buggy and without documentation nearly impossible to fix. It would be much too much work to debug this remotely.
This transmit errors you have I get from time to time too, but not always. What makes me wonder is that there is even not a single read. Do you really use the necessary patched libcec?

@kszaq
Copy link

kszaq commented Feb 17, 2016

Yes, I used libcec 3.0.1 with your patches. You're right about supporting only WeTek devices. I'll try to find some time to compile and test your patches with WeTek Play and report back if I get the same issues. Thanks for replying!

@gdachs
Copy link
Author

gdachs commented Feb 17, 2016

I had often a problem that it didn't work after the first boot after an update. If I reboot another time it worked and never got an issue again, till the next update.

@gdachs
Copy link
Author

gdachs commented Feb 18, 2016

I think I have found a race condition in the command transmission. Need some time to sort it out.

@gdachs gdachs force-pushed the new-cec-driver branch 2 times, most recently from b239dfc to 35ee3fb Compare February 27, 2016 23:23
@gdachs gdachs force-pushed the new-cec-driver branch 3 times, most recently from 6aec2b1 to 5df9266 Compare March 4, 2016 23:22
@kszaq
Copy link

kszaq commented Apr 1, 2016

With the latest version everything works great on my S805 devices. Thank you, @gdachs!

gdachs referenced this pull request in gdachs/libcec Apr 4, 2016
@gdachs
new adapter for amlogic devices
111381e
@gdachs
new amlogic cec driver
bed6850 
redesigned initialization
    - code of delayed init now part of open call
    - interrupt handling moved into open/release
    - removed some debug lines
    - repaired logical address detection

fixed that not all entries from read queue was read
@kszaq kszaq mentioned this pull request Aug 4, 2016
Closed
@kszaq kszaq mentioned this pull request Aug 22, 2016
Closed
kszaq pushed a commit to kszaq/linux that referenced this pull request Dec 9, 2017
@tytso @wtarreau
ext4: fix hang when processing corrupted orphaned inode list
3d1658b 
commit c9eb13a upstream.

If the orphaned inode list contains inode codesnake#5, ext4_iget() returns a
bad inode (since the bootloader inode should never be referenced
directly).  Because of the bad inode, we end up processing the inode
repeatedly and this hangs the machine.

This can be reproduced via:

   mke2fs -t ext4 /tmp/foo.img 100
   debugfs -w -R "ssv last_orphan 5" /tmp/foo.img
   mount -o loop /tmp/foo.img /mnt

(But don't do this if you are using an unpatched kernel if you care
about the system staying functional.  :-)

This bug was found by the port of American Fuzzy Lop into the kernel
to find file system problems[1].  (Since it *only* happens if inode codesnake#5
shows up on the orphan list --- 3, 7, 8, etc. won't do it, it's not
surprising that AFL needed two hours before it found it.)

[1] http://events.linuxfoundation.org/sites/events/files/slides/AFL%20filesystem%20fuzzing%2C%20Vault%202016_0.pdf

Cc: [email protected]
Reported by: Vegard Nossum <[email protected]>
Signed-off-by: Theodore Ts'o <[email protected]>
Signed-off-by: Willy Tarreau <[email protected]>
kszaq pushed a commit to kszaq/linux that referenced this pull request Dec 9, 2017
@wtarreau
reiserfs: Unlock superblock before calling reiserfs_quota_on_mount()
ee89427 
commit 420902c upstream.

If we hold the superblock lock while calling reiserfs_quota_on_mount(), we can
deadlock our own worker - mount blocks kworker/3:2, sleeps forever more.

crash> ps|grep UN
    715      2   3  ffff880220734d30  UN   0.0       0      0  [kworker/3:2]
   9369   9341   2  ffff88021ffb7560  UN   1.3  493404 123184  Xorg
   9665   9664   3  ffff880225b92ab0  UN   0.0   47368    812  udisks-daemon
  10635  10403   3  ffff880222f22c70  UN   0.0   14904    936  mount
crash> bt ffff880220734d30
PID: 715    TASK: ffff880220734d30  CPU: 3   COMMAND: "kworker/3:2"
 #0 [ffff8802244c3c20] schedule at ffffffff8144584b
 #1 [ffff8802244c3cc8] __rt_mutex_slowlock at ffffffff814472b3
 #2 [ffff8802244c3d28] rt_mutex_slowlock at ffffffff814473f5
 codesnake#3 [ffff8802244c3dc8] reiserfs_write_lock at ffffffffa05f28fd [reiserfs]
 codesnake#4 [ffff8802244c3de8] flush_async_commits at ffffffffa05ec91d [reiserfs]
 codesnake#5 [ffff8802244c3e08] process_one_work at ffffffff81073726
 codesnake#6 [ffff8802244c3e68] worker_thread at ffffffff81073eba
 codesnake#7 [ffff8802244c3ec8] kthread at ffffffff810782e0
 torvalds#8 [ffff8802244c3f48] kernel_thread_helper at ffffffff81450064
crash> rd ffff8802244c3cc8 10
ffff8802244c3cc8:  ffffffff814472b3 ffff880222f23250   .rD.....P2."....
ffff8802244c3cd8:  0000000000000000 0000000000000286   ................
ffff8802244c3ce8:  ffff8802244c3d30 ffff880220734d80   0=L$.....Ms ....
ffff8802244c3cf8:  ffff880222e8f628 0000000000000000   (.."............
ffff8802244c3d08:  0000000000000000 0000000000000002   ................
crash> struct rt_mutex ffff880222e8f628
struct rt_mutex {
  wait_lock = {
    raw_lock = {
      slock = 65537
    }
  },
  wait_list = {
    node_list = {
      next = 0xffff8802244c3d48,
      prev = 0xffff8802244c3d48
    }
  },
  owner = 0xffff880222f22c71,
  save_state = 0
}
crash> bt 0xffff880222f22c70
PID: 10635  TASK: ffff880222f22c70  CPU: 3   COMMAND: "mount"
 #0 [ffff8802216a9868] schedule at ffffffff8144584b
 #1 [ffff8802216a9910] schedule_timeout at ffffffff81446865
 #2 [ffff8802216a99a0] wait_for_common at ffffffff81445f74
 codesnake#3 [ffff8802216a9a30] flush_work at ffffffff810712d3
 codesnake#4 [ffff8802216a9ab0] schedule_on_each_cpu at ffffffff81074463
 codesnake#5 [ffff8802216a9ae0] invalidate_bdev at ffffffff81178aba
 codesnake#6 [ffff8802216a9af0] vfs_load_quota_inode at ffffffff811a3632
 codesnake#7 [ffff8802216a9b50] dquot_quota_on_mount at ffffffff811a375c
 torvalds#8 [ffff8802216a9b80] finish_unfinished at ffffffffa05dd8b0 [reiserfs]
 torvalds#9 [ffff8802216a9cc0] reiserfs_fill_super at ffffffffa05de825 [reiserfs]
    RIP: 00007f7b9303997a  RSP: 00007ffff443c7a8  RFLAGS: 00010202
    RAX: 00000000000000a5  RBX: ffffffff8144ef12  RCX: 00007f7b932e9ee0
    RDX: 00007f7b93d9a400  RSI: 00007f7b93d9a3e0  RDI: 00007f7b93d9a3c0
    RBP: 00007f7b93d9a2c0   R8: 00007f7b93d9a550   R9: 0000000000000001
    R10: ffffffffc0ed040e  R11: 0000000000000202  R12: 000000000000040e
    R13: 0000000000000000  R14: 00000000c0ed040e  R15: 00007ffff443ca20
    ORIG_RAX: 00000000000000a5  CS: 0033  SS: 002b

Signed-off-by: Mike Galbraith <[email protected]>
Acked-by: Frederic Weisbecker <[email protected]>
Acked-by: Mike Galbraith <[email protected]>
Signed-off-by: Jan Kara <[email protected]>
Signed-off-by: Willy Tarreau <[email protected]>
kszaq pushed a commit to kszaq/linux that referenced this pull request Dec 9, 2017
@wtarreau
ocfs2: fix BUG_ON() in ocfs2_ci_checkpointed()
1918581 
commit 3d46a44 upstream.

PID: 614    TASK: ffff882a739da580  CPU: 3   COMMAND: "ocfs2dc"
  #0 [ffff882ecc3759b0] machine_kexec at ffffffff8103b35d
  #1 [ffff882ecc375a20] crash_kexec at ffffffff810b95b5
  #2 [ffff882ecc375af0] oops_end at ffffffff815091d8
  codesnake#3 [ffff882ecc375b20] die at ffffffff8101868b
  codesnake#4 [ffff882ecc375b50] do_trap at ffffffff81508bb0
  codesnake#5 [ffff882ecc375ba0] do_invalid_op at ffffffff810165e5
  codesnake#6 [ffff882ecc375c40] invalid_op at ffffffff815116fb
     [exception RIP: ocfs2_ci_checkpointed+208]
     RIP: ffffffffa0a7e940  RSP: ffff882ecc375cf0  RFLAGS: 00010002
     RAX: 0000000000000001  RBX: 000000000000654b  RCX: ffff8812dc83f1f8
     RDX: 00000000000017d9  RSI: ffff8812dc83f1f8  RDI: ffffffffa0b2c318
     RBP: ffff882ecc375d20   R8: ffff882ef6ecfa60   R9: ffff88301f272200
     R10: 0000000000000000  R11: 0000000000000000  R12: ffffffffffffffff
     R13: ffff8812dc83f4f0  R14: 0000000000000000  R15: ffff8812dc83f1f8
     ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
  codesnake#7 [ffff882ecc375d28] ocfs2_check_meta_downconvert at ffffffffa0a7edbd [ocfs2]
  torvalds#8 [ffff882ecc375d38] ocfs2_unblock_lock at ffffffffa0a84af8 [ocfs2]
  torvalds#9 [ffff882ecc375dc8] ocfs2_process_blocked_lock at ffffffffa0a85285 [ocfs2]
assert is tripped because the tran is not checkpointed and the lock level is PR.

Some time ago, chmod command had been executed. As result, the following call
chain left the inode cluster lock in PR state, latter on causing the assert.
system_call_fastpath
  -> my_chmod
   -> sys_chmod
    -> sys_fchmodat
     -> notify_change
      -> ocfs2_setattr
       -> posix_acl_chmod
        -> ocfs2_iop_set_acl
         -> ocfs2_set_acl
          -> ocfs2_acl_set_mode
Here is how.
1119 int ocfs2_setattr(struct dentry *dentry, struct iattr *attr)
1120 {
1247         ocfs2_inode_unlock(inode, 1); <<< WRONG thing to do.
..
1258         if (!status && attr->ia_valid & ATTR_MODE) {
1259                 status =  posix_acl_chmod(inode, inode->i_mode);

519 posix_acl_chmod(struct inode *inode, umode_t mode)
520 {
..
539         ret = inode->i_op->set_acl(inode, acl, ACL_TYPE_ACCESS);

287 int ocfs2_iop_set_acl(struct inode *inode, struct posix_acl *acl, ...
288 {
289         return ocfs2_set_acl(NULL, inode, NULL, type, acl, NULL, NULL);

224 int ocfs2_set_acl(handle_t *handle,
225                          struct inode *inode, ...
231 {
..
252                                 ret = ocfs2_acl_set_mode(inode, di_bh,
253                                                          handle, mode);

168 static int ocfs2_acl_set_mode(struct inode *inode, struct buffer_head ...
170 {
183         if (handle == NULL) {
                    >>> BUG: inode lock not held in ex at this point <<<
184                 handle = ocfs2_start_trans(OCFS2_SB(inode->i_sb),
185                                            OCFS2_INODE_UPDATE_CREDITS);

ocfs2_setattr.#1247 we unlock and at #1259 call posix_acl_chmod. When we reach
ocfs2_acl_set_mode.torvalds#181 and do trans, the inode cluster lock is not held in EX
mode (it should be). How this could have happended?

We are the lock master, were holding lock EX and have released it in
ocfs2_setattr.#1247.  Note that there are no holders of this lock at
this point.  Another node needs the lock in PR, and we downconvert from
EX to PR.  So the inode lock is PR when do the trans in
ocfs2_acl_set_mode.torvalds#184.  The trans stays in core (not flushed to disc).
Now another node want the lock in EX, downconvert thread gets kicked
(the one that tripped assert abovt), finds an unflushed trans but the
lock is not EX (it is PR).  If the lock was at EX, it would have flushed
the trans ocfs2_ci_checkpointed -> ocfs2_start_checkpoint before
downconverting (to NULL) for the request.

ocfs2_setattr must not drop inode lock ex in this code path.  If it
does, takes it again before the trans, say in ocfs2_set_acl, another
cluster node can get in between, execute another setattr, overwriting
the one in progress on this node, resulting in a mode acl size combo
that is a mix of the two.

Orabug: 20189959
Signed-off-by: Tariq Saeed <[email protected]>
Reviewed-by: Mark Fasheh <[email protected]>
Cc: Joel Becker <[email protected]>
Cc: Joseph Qi <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Willy Tarreau <[email protected]>
kszaq pushed a commit to kszaq/linux that referenced this pull request Dec 9, 2017
@wtarreau
net: reduce skb_warn_bad_offload() noise
1bff8a2 
commit b2504a5 upstream.

Dmitry reported warnings occurring in __skb_gso_segment() [1]

All SKB_GSO_DODGY producers can allow user space to feed
packets that trigger the current check.

We could prevent them from doing so, rejecting packets, but
this might add regressions to existing programs.

It turns out our SKB_GSO_DODGY handlers properly set up checksum
information that is needed anyway when packets needs to be segmented.

By checking again skb_needs_check() after skb_mac_gso_segment(),
we should remove these pesky warnings, at a very minor cost.

With help from Willem de Bruijn

[1]
WARNING: CPU: 1 PID: 6768 at net/core/dev.c:2439 skb_warn_bad_offload+0x2af/0x390 net/core/dev.c:2434
lo: caps=(0x000000a2803b7c69, 0x0000000000000000) len=138 data_len=0 gso_size=15883 gso_type=4 ip_summed=0
Kernel panic - not syncing: panic_on_warn set ...

CPU: 1 PID: 6768 Comm: syz-executor1 Not tainted 4.9.0 codesnake#5
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
 ffff8801c063ecd8 ffffffff82346bdf ffffffff00000001 1ffff100380c7d2e
 ffffed00380c7d26 0000000041b58ab3 ffffffff84b37e38 ffffffff823468f1
 ffffffff84820740 ffffffff84f289c0 dffffc0000000000 ffff8801c063ee20
Call Trace:
 [<ffffffff82346bdf>] __dump_stack lib/dump_stack.c:15 [inline]
 [<ffffffff82346bdf>] dump_stack+0x2ee/0x3ef lib/dump_stack.c:51
 [<ffffffff81827e34>] panic+0x1fb/0x412 kernel/panic.c:179
 [<ffffffff8141f704>] __warn+0x1c4/0x1e0 kernel/panic.c:542
 [<ffffffff8141f7e5>] warn_slowpath_fmt+0xc5/0x100 kernel/panic.c:565
 [<ffffffff8356cbaf>] skb_warn_bad_offload+0x2af/0x390 net/core/dev.c:2434
 [<ffffffff83585cd2>] __skb_gso_segment+0x482/0x780 net/core/dev.c:2706
 [<ffffffff83586f19>] skb_gso_segment include/linux/netdevice.h:3985 [inline]
 [<ffffffff83586f19>] validate_xmit_skb+0x5c9/0xc20 net/core/dev.c:2969
 [<ffffffff835892bb>] __dev_queue_xmit+0xe6b/0x1e70 net/core/dev.c:3383
 [<ffffffff8358a2d7>] dev_queue_xmit+0x17/0x20 net/core/dev.c:3424
 [<ffffffff83ad161d>] packet_snd net/packet/af_packet.c:2930 [inline]
 [<ffffffff83ad161d>] packet_sendmsg+0x32ed/0x4d30 net/packet/af_packet.c:2955
 [<ffffffff834f0aaa>] sock_sendmsg_nosec net/socket.c:621 [inline]
 [<ffffffff834f0aaa>] sock_sendmsg+0xca/0x110 net/socket.c:631
 [<ffffffff834f329a>] ___sys_sendmsg+0x8fa/0x9f0 net/socket.c:1954
 [<ffffffff834f5e58>] __sys_sendmsg+0x138/0x300 net/socket.c:1988
 [<ffffffff834f604d>] SYSC_sendmsg net/socket.c:1999 [inline]
 [<ffffffff834f604d>] SyS_sendmsg+0x2d/0x50 net/socket.c:1995
 [<ffffffff84371941>] entry_SYSCALL_64_fastpath+0x1f/0xc2

Signed-off-by: Eric Dumazet <[email protected]>
Reported-by: Dmitry Vyukov  <[email protected]>
Cc: Willem de Bruijn <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Willy Tarreau <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@gdachs @kszaq