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

OpenELEC on CUBOX-I: CEC stopped working #12

Open
pieska opened this issue Aug 27, 2014 · 7 comments
Open

OpenELEC on CUBOX-I: CEC stopped working #12

pieska opened this issue Aug 27, 2014 · 7 comments

Comments

@pieska
Copy link

pieska commented Aug 27, 2014

i've opened an issue with OpenELEC (OpenELEC/OpenELEC.tv#3442) but it seems not to be an OpenELEC issue. i'm not familiar with this stuff, i'm just a user. here's the info i have, if you need more, just say so;

xbmc.log:
18:00:46 T:1984933888 NOTICE: Register - new cec device registered on cec->i.MX: CEC Adapter (0471
:1001)
18:00:46 T:1963979856 NOTICE: Thread CECAdapter start, auto delete: false
18:00:46 T:1954542672 NOTICE: Thread PeripBusCEC start, auto delete: false
18:00:46 T:1963979856 ERROR: CecLogMessage - Write: sent command error !
18:00:46 T:1963979856 ERROR: Previous line repeats 3 times.
18:00:46 T:1963979856 ERROR: CecLogMessage - RegisterLogicalAddress: HDMICEC_IOC_SETLOGICALADDRES
S failed !
18:00:46 T:1963979856 ERROR: CecLogMessage - Write: sent command error !
18:00:46 T:1918891088 ERROR: Previous line repeats 5 times.
18:00:46 T:1918891088 NOTICE: Thread CECAdapterUpdate start, auto delete: false
18:00:46 T:1918891088 ERROR: CecLogMessage - Write: sent command error !
18:00:46 T:1908405328 ERROR: Previous line repeats 5 times.
cec-client -l

ERROR: [ 58] could not open a connection (try 1)
ERROR: [ 1058] could not open a connection (try 2)
ERROR: [ 2061] could not open a connection (try 3)
ERROR: [ 3063] could not open a connection (try 4)
ERROR: [ 4064] could not open a connection (try 5)
ERROR: [ 5065] could not open a connection (try 6)
ERROR: [ 6065] could not open a connection (try 7)
ERROR: [ 7066] could not open a connection (try 8)
ERROR: [ 8066] could not open a connection (try 9)
ERROR: [ 9067] could not open a connection (try 10)
Found devices: 1

device: 1
com port: i.MX
vendor id: 0471
product id: 1001
firmware version: 65535
cec-client

No device type given. Using 'recording device'
CEC Parser created - libCEC version 2.1.4
no serial port given. trying autodetect:
path: /dev/mxc_hdmi_cec
com port: i.MX

opening a connection to the CEC adapter...
DEBUG: [ 58] unregistering all CEC clients
DEBUG: [ 59] Broadcast (F): osd name set to 'Broadcast'
ERROR: [ 59] could not open a connection (try 1)
ERROR: [ 1059] could not open a connection (try 2)
ERROR: [ 2060] could not open a connection (try 3)
ERROR: [ 3060] could not open a connection (try 4)
ERROR: [ 4061] could not open a connection (try 5)
ERROR: [ 5061] could not open a connection (try 6)
ERROR: [ 6064] could not open a connection (try 7)
ERROR: [ 7067] could not open a connection (try 8)
ERROR: [ 8069] could not open a connection (try 9)
ERROR: [ 9070] could not open a connection (try 10)
NOTICE: [ 10072] connection opened
ERROR: [ 10072] could not start CEC communications
unable to open the device on port i.MX
@Nevnaur
Copy link

Nevnaur commented Aug 28, 2014

Hi guys

I have the same problem, yesterday I tried the last image available of OpenElec to Cubox-I downloaded from http://snapshots.openelec.tv the file was OpenELEC-Cuboxi.arm-devel-20140827164907-r19125-gc5dd288.img.gz

In this version I detected a bug with the CEC module, the new version Alpha 3 did not work correctly with the Samsung TV and the TV can detect the device and of course the remote did not work to manage the XBMC, but if I change the SD with the old OpenElec Alpha 1 image published 11 Jul of 2014 all works perfectly.

I checked the configuration of the CEC in both versions, and the config was complitly the same, and I think this is a bug with the new CEC software version includen in the Alpha 3 image to Cubox-I.

I hope it helps to fund the problem, please let me know if you need any extra info o log to found the issue.

Thanks in advance

Cheers

CEC error in OpenElec ALPHA 4 with SAMSUNG TV UE46D6500

@Nevnaur
Copy link

Nevnaur commented Aug 30, 2014

Hi guys

I tried to use the “systemctl restart xbmc” after 5 minutes but the CEC cannot Works in the TV SAMSUNG UE46D6500 with the OpenElec image OpenELEC-Cuboxi.arm-devel-20140827164907-r19125-gc5dd288.img.gz.

I upgraded a new SD card to the new image OpenELEC-Cuboxi.arm-devel-20140829063119-r19134-g3a70ef5.img.gz but the problem is the same, of course I tried too use “systemctl restart xbmc” after 5 minutes of the system boot but the problem is the same.

I think we have some bugs in this CEC module of OpenElec Alpha 4, because with the Alpha 1 OpenELEC_Helix-Cuboxi.arm-devel-20140711235128-r18724-g357c9d3.img.gz of OpenElec all works perfectly in the same TV.

I hope it helps.

Cheers

mk01 pushed a commit to mk01/linux-linaro-stable-mx6 that referenced this issue Sep 3, 2014
@libin2015
x86/smpboot: Fix announce_cpu() to printk() the last "OK" properly
5223948 
When booting secondary CPUs, announce_cpu() is called to show which cpu has
been brought up. For example:

[    0.402751] smpboot: Booting Node   0, Processors  rabeeh#1 rabeeh#2 rabeeh#3 rabeeh#4 rabeeh#5 OK
[    0.525667] smpboot: Booting Node   1, Processors  rabeeh#6 linux4kix#7 linux4kix#8 linux4kix#9 linux4kix#10 linux4kix#11 OK
[    0.755592] smpboot: Booting Node   0, Processors  linux4kix#12 linux4kix#13 linux4kix#14 linux4kix#15 linux4kix#16 linux4kix#17 OK
[    0.890495] smpboot: Booting Node   1, Processors  linux4kix#18 linux4kix#19 linux4kix#20 linux4kix#21 linux4kix#22 linux4kix#23

But the last "OK" is lost, because 'nr_cpu_ids-1' represents the maximum
possible cpu id. It should use the maximum present cpu id in case not all
CPUs booted up.

Signed-off-by: Libin <[email protected]>
Cc: <[email protected]>
Cc: <[email protected]>
Cc: <[email protected]>
Cc: <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
[ tweaked the changelog, removed unnecessary line break, tweaked the format to align the fields vertically. ]
Signed-off-by: Ingo Molnar <[email protected]>
mk01 pushed a commit to mk01/linux-linaro-stable-mx6 that referenced this issue Sep 3, 2014
@torvalds
mm/memory-failure.c: fix bug triggered by unpoisoning empty zero page
3ba5eeb 
  Injecting memory failure for page 0x19d0 at 0xb77d2000
  MCE 0x19d0: non LRU page recovery: Ignored
  MCE: Software-unpoisoned page 0x19d0
  BUG: Bad page state in process bash  pfn:019d0
  page:f3461a00 count:0 mapcount:0 mapping:  (null) index:0x0
  page flags: 0x40000404(referenced|reserved)
  Modules linked in: nfsd auth_rpcgss i915 nfs_acl nfs lockd video drm_kms_helper drm bnep rfcomm sunrpc bluetooth psmouse parport_pc ppdev lp serio_raw fscache parport gpio_ich lpc_ich mac_hid i2c_algo_bit tpm_tis wmi usb_storage hid_generic usbhid hid e1000e firewire_ohci firewire_core ahci ptp libahci pps_core crc_itu_t
  CPU: 3 PID: 2123 Comm: bash Not tainted 3.11.0-rc6+ linux4kix#12
  Hardware name: LENOVO 7034DD7/        , BIOS 9HKT47AUS 01//2012
   00000000 00000000 e9625ea0 c15ec49b f3461a00 e9625eb8 c15ea119 c17cbf18
   ef084314 000019d0 f3461a00 e9625ed8 c110dc8a f3461a00 00000001 00000000
   f3461a00 40000404 00000000 e9625ef8 c110dcc1 f3461a00 f3461a00 000019d0
  Call Trace:
    dump_stack+0x41/0x52
    bad_page+0xcf/0xeb
    free_pages_prepare+0x12a/0x140
    free_hot_cold_page+0x21/0x110
    __put_single_page+0x21/0x30
    put_page+0x25/0x40
    unpoison_memory+0x107/0x200
    hwpoison_unpoison+0x20/0x30
    simple_attr_write+0xb6/0xd0
    vfs_write+0xa0/0x1b0
    SyS_write+0x4f/0x90
    sysenter_do_call+0x12/0x22
  Disabling lock debugging due to kernel taint

Testcase:

#define _GNU_SOURCE
#include <stdlib.h>
#include <stdio.h>
#include <sys/mman.h>
#include <unistd.h>
#include <fcntl.h>
#include <sys/types.h>
#include <errno.h>

#define PAGES_TO_TEST 1
#define PAGE_SIZE	4096

int main(void)
{
	char *mem;

	mem = mmap(NULL, PAGES_TO_TEST * PAGE_SIZE,
			PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, 0, 0);

	if (madvise(mem, PAGES_TO_TEST * PAGE_SIZE, MADV_HWPOISON) == -1)
		return -1;

	munmap(mem, PAGES_TO_TEST * PAGE_SIZE);

	return 0;
}

There is one page reference count for default empty zero page,
madvise_hwpoison add another one by get_user_pages_fast.  memory_hwpoison
reduce one page reference count since it's a non LRU page.
unpoison_memory release the last page reference count and free empty zero
page to buddy system which is not correct since empty zero page has
PG_reserved flag.  This patch fix it by don't reduce the page reference
count under 1 against empty zero page.

Signed-off-by: Wanpeng Li <[email protected]>
Reviewed-by: Naoya Horiguchi <[email protected]>
Cc: Andi Kleen <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
mk01 pushed a commit to mk01/linux-linaro-stable-mx6 that referenced this issue Sep 3, 2014
@ahunter6 @acmel
perf annotate: Fix objdump line parsing offset validation
886b37b 
When parsing lines from objdump a line containing source code starting
with a numeric label is mistaken for a line of disassembly starting with
a memory address.

Current validation fails to recognise that the "memory address" is out
of range and calculates an invalid offset which later causes this
segfault:

Program received signal SIGSEGV, Segmentation fault.
0x0000000000457315 in disasm__calc_percent (notes=0xc98970, evidx=0, offset=143705, end=2127526177, path=0x7fffffffbf50)
    at util/annotate.c:631
631				hits += h->addr[offset++];
(gdb) bt
 #0  0x0000000000457315 in disasm__calc_percent (notes=0xc98970, evidx=0, offset=143705, end=2127526177, path=0x7fffffffbf50)
    at util/annotate.c:631
 rabeeh#1  0x00000000004d65e3 in annotate_browser__calc_percent (browser=0x7fffffffd130, evsel=0xa01da0) at ui/browsers/annotate.c:364
 rabeeh#2  0x00000000004d7433 in annotate_browser__run (browser=0x7fffffffd130, evsel=0xa01da0, hbt=0x0) at ui/browsers/annotate.c:672
 rabeeh#3  0x00000000004d80c9 in symbol__tui_annotate (sym=0xc989a0, map=0xa02660, evsel=0xa01da0, hbt=0x0) at ui/browsers/annotate.c:962
 rabeeh#4  0x00000000004d7aa0 in hist_entry__tui_annotate (he=0xdf73f0, evsel=0xa01da0, hbt=0x0) at ui/browsers/annotate.c:823
 rabeeh#5  0x00000000004dd648 in perf_evsel__hists_browse (evsel=0xa01da0, nr_events=1, helpline=
    0x58b768 "For a higher level overview, try: perf report --sort comm,dso", ev_name=0xa02cd0 "cycles", left_exits=false, hbt=
    0x0, min_pcnt=0, env=0xa011e0) at ui/browsers/hists.c:1659
 rabeeh#6  0x00000000004de372 in perf_evlist__tui_browse_hists (evlist=0xa01520, help=
    0x58b768 "For a higher level overview, try: perf report --sort comm,dso", hbt=0x0, min_pcnt=0, env=0xa011e0)
    at ui/browsers/hists.c:1950
 linux4kix#7  0x000000000042cf6b in __cmd_report (rep=0x7fffffffd6c0) at builtin-report.c:581
 linux4kix#8  0x000000000042e25d in cmd_report (argc=0, argv=0x7fffffffe4b0, prefix=0x0) at builtin-report.c:965
 linux4kix#9  0x000000000041a0e1 in run_builtin (p=0x801548, argc=1, argv=0x7fffffffe4b0) at perf.c:319
 linux4kix#10 0x000000000041a319 in handle_internal_command (argc=1, argv=0x7fffffffe4b0) at perf.c:376
 linux4kix#11 0x000000000041a465 in run_argv (argcp=0x7fffffffe38c, argv=0x7fffffffe380) at perf.c:420
 linux4kix#12 0x000000000041a707 in main (argc=1, argv=0x7fffffffe4b0) at perf.c:521

After the fix is applied the symbol can be annotated showing the
problematic line "1:      rep"

copy_user_generic_string  /usr/lib/debug/lib/modules/3.9.10-100.fc17.x86_64/vmlinux
             */
            ENTRY(copy_user_generic_string)
                    CFI_STARTPROC
                    ASM_STAC
                    andl %edx,%edx
              and    %edx,%edx
                    jz 4f
              je     37
                    cmpl $8,%edx
              cmp    $0x8,%edx
                    jb 2f           /* less than 8 bytes, go to byte copy loop */
              jb     33
                    ALIGN_DESTINATION
              mov    %edi,%ecx
              and    $0x7,%ecx
              je     28
              sub    $0x8,%ecx
              neg    %ecx
              sub    %ecx,%edx
        1a:   mov    (%rsi),%al
              mov    %al,(%rdi)
              inc    %rsi
              inc    %rdi
              dec    %ecx
              jne    1a
                    movl %edx,%ecx
        28:   mov    %edx,%ecx
                    shrl $3,%ecx
              shr    $0x3,%ecx
                    andl $7,%edx
              and    $0x7,%edx
            1:      rep
100.00        rep    movsq %ds:(%rsi),%es:(%rdi)
                    movsq
            2:      movl %edx,%ecx
        33:   mov    %edx,%ecx
            3:      rep
              rep    movsb %ds:(%rsi),%es:(%rdi)
                    movsb
            4:      xorl %eax,%eax
        37:   xor    %eax,%eax
              data32 xchg %ax,%ax
                    ASM_CLAC
                    ret
              retq

Signed-off-by: Adrian Hunter <[email protected]>
Cc: David Ahern <[email protected]>
Cc: Frederic Weisbecker <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: Mike Galbraith <[email protected]>
Cc: Namhyung Kim <[email protected]>
Cc: Paul Mackerras <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Stephane Eranian <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
mk01 pushed a commit to mk01/linux-linaro-stable-mx6 that referenced this issue Sep 3, 2014
@suryasaimadhu
x86: Improve the printout of the SMP bootup CPU table
646e29a 
As the new x86 CPU bootup printout format code maintainer, I am
taking immediate action to improve and clean (and thus indulge
my OCD) the reporting of the cores when coming up online.

Fix padding to a right-hand alignment, cleanup code and bind
reporting width to the max number of supported CPUs on the
system, like this:

 [    0.074509] smpboot: Booting Node   0, Processors:      rabeeh#1  rabeeh#2  rabeeh#3  rabeeh#4  rabeeh#5  rabeeh#6  linux4kix#7 OK
 [    0.644008] smpboot: Booting Node   1, Processors:  linux4kix#8  linux4kix#9 linux4kix#10 linux4kix#11 linux4kix#12 linux4kix#13 linux4kix#14 linux4kix#15 OK
 [    1.245006] smpboot: Booting Node   2, Processors: linux4kix#16 linux4kix#17 linux4kix#18 linux4kix#19 linux4kix#20 linux4kix#21 linux4kix#22 linux4kix#23 OK
 [    1.864005] smpboot: Booting Node   3, Processors: linux4kix#24 linux4kix#25 linux4kix#26 linux4kix#27 linux4kix#28 #29 #30 #31 OK
 [    2.489005] smpboot: Booting Node   4, Processors: #32 #33 #34 #35 #36 #37 #38 #39 OK
 [    3.093005] smpboot: Booting Node   5, Processors: #40 #41 #42 #43 #44 #45 #46 #47 OK
 [    3.698005] smpboot: Booting Node   6, Processors: #48 #49 #50 #51 #52 #53 #54 #55 OK
 [    4.304005] smpboot: Booting Node   7, Processors: #56 #57 #58 #59 #60 #61 #62 #63 OK
 [    4.961413] Brought up 64 CPUs

and this:

 [    0.072367] smpboot: Booting Node   0, Processors:    rabeeh#1 rabeeh#2 rabeeh#3 rabeeh#4 rabeeh#5 rabeeh#6 linux4kix#7 OK
 [    0.686329] Brought up 8 CPUs

Signed-off-by: Borislav Petkov <[email protected]>
Cc: Libin <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Ingo Molnar <[email protected]>
mk01 pushed a commit to mk01/linux-linaro-stable-mx6 that referenced this issue Sep 3, 2014
@bp3tk0v
x86/boot: Further compress CPUs bootup message
a17bce4 
Turn it into (for example):

[    0.073380] x86: Booting SMP configuration:
[    0.074005] .... node   #0, CPUs:          rabeeh#1   rabeeh#2   rabeeh#3   rabeeh#4   rabeeh#5   rabeeh#6   linux4kix#7
[    0.603005] .... node   rabeeh#1, CPUs:     linux4kix#8   linux4kix#9  linux4kix#10  linux4kix#11  linux4kix#12  linux4kix#13  linux4kix#14  linux4kix#15
[    1.200005] .... node   rabeeh#2, CPUs:    linux4kix#16  linux4kix#17  linux4kix#18  linux4kix#19  linux4kix#20  linux4kix#21  linux4kix#22  linux4kix#23
[    1.796005] .... node   rabeeh#3, CPUs:    linux4kix#24  linux4kix#25  linux4kix#26  linux4kix#27  linux4kix#28  #29  #30  #31
[    2.393005] .... node   rabeeh#4, CPUs:    #32  #33  #34  #35  #36  #37  #38  #39
[    2.996005] .... node   rabeeh#5, CPUs:    #40  #41  #42  #43  #44  #45  #46  #47
[    3.600005] .... node   rabeeh#6, CPUs:    #48  #49  #50  #51  #52  #53  #54  #55
[    4.202005] .... node   linux4kix#7, CPUs:    #56  #57  #58  #59  #60  #61  #62  #63
[    4.811005] .... node   linux4kix#8, CPUs:    #64  #65  #66  #67  #68  #69  #70  #71
[    5.421006] .... node   linux4kix#9, CPUs:    #72  #73  #74  #75  #76  #77  #78  #79
[    6.032005] .... node  linux4kix#10, CPUs:    #80  #81  #82  #83  #84  #85  #86  #87
[    6.648006] .... node  linux4kix#11, CPUs:    #88  #89  #90  #91  #92  #93  #94  #95
[    7.262005] .... node  linux4kix#12, CPUs:    #96  #97  #98  #99 #100 #101 #102 #103
[    7.865005] .... node  linux4kix#13, CPUs:   #104 #105 #106 #107 #108 #109 #110 #111
[    8.466005] .... node  linux4kix#14, CPUs:   #112 #113 #114 #115 #116 #117 #118 #119
[    9.073006] .... node  linux4kix#15, CPUs:   #120 #121 #122 #123 #124 #125 #126 #127
[    9.679901] x86: Booted up 16 nodes, 128 CPUs

and drop useless elements.

Change num_digits() to hpa's division-avoiding, cell-phone-typed
version which he went at great lengths and pains to submit on a
Saturday evening.

Signed-off-by: Borislav Petkov <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: Linus Torvalds <[email protected]>
Cc: Andrew Morton <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Ingo Molnar <[email protected]>
mk01 pushed a commit to mk01/linux-linaro-stable-mx6 that referenced this issue Sep 3, 2014
@rostedt
tracing: Fix potential out-of-bounds in trace_get_user()
057db84 
Andrey reported the following report:

ERROR: AddressSanitizer: heap-buffer-overflow on address ffff8800359c99f3
ffff8800359c99f3 is located 0 bytes to the right of 243-byte region [ffff8800359c9900, ffff8800359c99f3)
Accessed by thread T13003:
  #0 ffffffff810dd2da (asan_report_error+0x32a/0x440)
  rabeeh#1 ffffffff810dc6b0 (asan_check_region+0x30/0x40)
  rabeeh#2 ffffffff810dd4d3 (__tsan_write1+0x13/0x20)
  rabeeh#3 ffffffff811cd19e (ftrace_regex_release+0x1be/0x260)
  rabeeh#4 ffffffff812a1065 (__fput+0x155/0x360)
  rabeeh#5 ffffffff812a12de (____fput+0x1e/0x30)
  rabeeh#6 ffffffff8111708d (task_work_run+0x10d/0x140)
  linux4kix#7 ffffffff810ea043 (do_exit+0x433/0x11f0)
  linux4kix#8 ffffffff810eaee4 (do_group_exit+0x84/0x130)
  linux4kix#9 ffffffff810eafb1 (SyS_exit_group+0x21/0x30)
  linux4kix#10 ffffffff81928782 (system_call_fastpath+0x16/0x1b)

Allocated by thread T5167:
  #0 ffffffff810dc778 (asan_slab_alloc+0x48/0xc0)
  rabeeh#1 ffffffff8128337c (__kmalloc+0xbc/0x500)
  rabeeh#2 ffffffff811d9d54 (trace_parser_get_init+0x34/0x90)
  rabeeh#3 ffffffff811cd7b3 (ftrace_regex_open+0x83/0x2e0)
  rabeeh#4 ffffffff811cda7d (ftrace_filter_open+0x2d/0x40)
  rabeeh#5 ffffffff8129b4ff (do_dentry_open+0x32f/0x430)
  rabeeh#6 ffffffff8129b668 (finish_open+0x68/0xa0)
  linux4kix#7 ffffffff812b66ac (do_last+0xb8c/0x1710)
  linux4kix#8 ffffffff812b7350 (path_openat+0x120/0xb50)
  linux4kix#9 ffffffff812b8884 (do_filp_open+0x54/0xb0)
  linux4kix#10 ffffffff8129d36c (do_sys_open+0x1ac/0x2c0)
  linux4kix#11 ffffffff8129d4b7 (SyS_open+0x37/0x50)
  linux4kix#12 ffffffff81928782 (system_call_fastpath+0x16/0x1b)

Shadow bytes around the buggy address:
  ffff8800359c9700: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  ffff8800359c9780: fd fd fd fd fd fd fd fd fa fa fa fa fa fa fa fa
  ffff8800359c9800: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  ffff8800359c9880: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  ffff8800359c9900: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>ffff8800359c9980: 00 00 00 00 00 00 00 00 00 00 00 00 00 00[03]fb
  ffff8800359c9a00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  ffff8800359c9a80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  ffff8800359c9b00: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
  ffff8800359c9b80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  ffff8800359c9c00: 00 00 00 00 00 00 00 00 fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap redzone:          fa
  Heap kmalloc redzone:  fb
  Freed heap region:     fd
  Shadow gap:            fe

The out-of-bounds access happens on 'parser->buffer[parser->idx] = 0;'

Although the crash happened in ftrace_regex_open() the real bug
occurred in trace_get_user() where there's an incrementation to
parser->idx without a check against the size. The way it is triggered
is if userspace sends in 128 characters (EVENT_BUF_SIZE + 1), the loop
that reads the last character stores it and then breaks out because
there is no more characters. Then the last character is read to determine
what to do next, and the index is incremented without checking size.

Then the caller of trace_get_user() usually nulls out the last character
with a zero, but since the index is equal to the size, it writes a nul
character after the allocated space, which can corrupt memory.

Luckily, only root user has write access to this file.

Link: http://lkml.kernel.org/r/[email protected]

Reported-by: Andrey Konovalov <[email protected]>
Signed-off-by: Steven Rostedt <[email protected]>
mk01 pushed a commit to mk01/linux-linaro-stable-mx6 that referenced this issue Sep 3, 2014
@torvalds
Merge branch 'x86-boot-for-linus' of git://git.kernel.org/pub/scm/lin…
014d595 
…ux/kernel/git/tip/tip

Pull x86 boot changes from Ingo Molnar:
 "Two changes that prettify and compactify the SMP bootup output from:

     smpboot: Booting Node   0, Processors  rabeeh#1 rabeeh#2 rabeeh#3 OK
     smpboot: Booting Node   1, Processors  rabeeh#4 rabeeh#5 rabeeh#6 linux4kix#7 OK
     smpboot: Booting Node   2, Processors  linux4kix#8 linux4kix#9 linux4kix#10 linux4kix#11 OK
     smpboot: Booting Node   3, Processors  linux4kix#12 linux4kix#13 linux4kix#14 linux4kix#15 OK
     Brought up 16 CPUs

  to something like:

     x86: Booting SMP configuration:
     .... node  #0, CPUs:        rabeeh#1  rabeeh#2  rabeeh#3
     .... node  rabeeh#1, CPUs:    rabeeh#4  rabeeh#5  rabeeh#6  linux4kix#7
     .... node  rabeeh#2, CPUs:    linux4kix#8  linux4kix#9 linux4kix#10 linux4kix#11
     .... node  rabeeh#3, CPUs:   linux4kix#12 linux4kix#13 linux4kix#14 linux4kix#15
     x86: Booted up 4 nodes, 16 CPUs"

* 'x86-boot-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86/boot: Further compress CPUs bootup message
  x86: Improve the printout of the SMP bootup CPU table
mk01 pushed a commit to mk01/linux-linaro-stable-mx6 that referenced this issue Sep 3, 2014
@horiag @herbertx
crypto: talitos - fix aead sglen for case 'dst != src'
62293a3 
For aead case when source and destination buffers are different,
there is an incorrect assumption that the source length includes the ICV
length. Fix this, since it leads to an oops when using sg_count() to
find the number of nents in the scatterlist:

Unable to handle kernel paging request for data at address 0x00000004
Faulting instruction address: 0xf2265a28
Oops: Kernel access of bad area, sig: 11 [rabeeh#1]
SMP NR_CPUS=8 P2020 RDB
Modules linked in: talitos(+)
CPU: 1 PID: 2187 Comm: cryptomgr_test Not tainted 3.11.0 linux4kix#12
task: c4e72e20 ti: ef634000 task.ti: ef634000
NIP: f2265a28 LR: f2266ad8 CTR: c000c900
REGS: ef635bb0 TRAP: 0300   Not tainted  (3.11.0)
MSR: 00029000 <CE,EE,ME>  CR: 42042084  XER: 00000000
DEAR: 00000004, ESR: 00000000

GPR00: f2266e10 ef635c60 c4e72e20 00000001 00000014 ef635c69 00000001 c11f3082
GPR08: 00000010 00000000 00000002 2f635d58 22044084 00000000 00000000 c0755c80
GPR16: c4bf1000 ef784000 00000000 00000000 00000020 00000014 00000010 ef2f6100
GPR24: ef2f6200 00000024 ef143210 ef2f6000 00000000 ef635d58 00000000 2f635d58
NIP [f2265a28] sg_count+0x1c/0xb4 [talitos]
LR [f2266ad8] talitos_edesc_alloc+0x12c/0x410 [talitos]
Call Trace:
[ef635c60] [c0552068] schedule_timeout+0x148/0x1ac (unreliable)
[ef635cc0] [f2266e10] aead_edesc_alloc+0x54/0x64 [talitos]
[ef635ce0] [f22680f0] aead_encrypt+0x24/0x70 [talitos]
[ef635cf0] [c024b948] __test_aead+0x494/0xf68
[ef635e20] [c024d54c] test_aead+0x64/0xcc
[ef635e40] [c024d604] alg_test_aead+0x50/0xc4
[ef635e60] [c024c838] alg_test+0x10c/0x2e4
[ef635ee0] [c0249d1c] cryptomgr_test+0x4c/0x54
[ef635ef0] [c005d598] kthread+0xa8/0xac
[ef635f40] [c000e3bc] ret_from_kernel_thread+0x5c/0x64
Instruction dump:
81230024 552807fe 0f080000 5523003a 4bffff24 39000000 2c040000 99050000
408100a0 7c691b78 38c00001 38600000 <80e90004> 38630001 8109000c 70ea0002
---[ end trace 4498123cd8478591 ]---

Signed-off-by: Horia Geanta <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
mk01 pushed a commit to mk01/linux-linaro-stable-mx6 that referenced this issue Sep 3, 2014
@joergroedel
iommu/vt-d: fix access after free issue in function free_dmar_iommu()
5ced12a 
Function free_dmar_iommu() may access domain->iommu_lock by
	spin_unlock_irqrestore(&domain->iommu_lock, flags);
after freeing corresponding domain structure.

Sample stack dump:
[    8.912818] =========================
[    8.917072] [ BUG: held lock freed! ]
[    8.921335] 3.13.0-rc1-gerry+ linux4kix#12 Not tainted
[    8.926375] -------------------------
[    8.930629] swapper/0/1 is freeing memory ffff880c23b56040-ffff880c23b5613f, with a lock still held there!
[    8.941675]  (&(&domain->iommu_lock)->rlock){......}, at: [<ffffffff81dc775c>] init_dmars+0x72c/0x95b
[    8.952582] 1 lock held by swapper/0/1:
[    8.957031]  #0:  (&(&domain->iommu_lock)->rlock){......}, at: [<ffffffff81dc775c>] init_dmars+0x72c/0x95b
[    8.968487]
[    8.968487] stack backtrace:
[    8.973602] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.13.0-rc1-gerry+ linux4kix#12
[    8.981556] Hardware name: Intel Corporation LH Pass ........../SVRBD-ROW_T, BIOS SE5C600.86B.99.99.x059.091020121352 09/10/2012
[    8.994742]  ffff880c23b56040 ffff88042dd33c98 ffffffff815617fd ffff88042dd38b28
[    9.003566]  ffff88042dd33cd0 ffffffff810a977a ffff880c23b56040 0000000000000086
[    9.012403]  ffff88102c4923c0 ffff88042ddb4800 ffffffff81b1e8c0 ffff88042dd33d28
[    9.021240] Call Trace:
[    9.024138]  [<ffffffff815617fd>] dump_stack+0x4d/0x66
[    9.030057]  [<ffffffff810a977a>] debug_check_no_locks_freed+0x15a/0x160
[    9.037723]  [<ffffffff811aa1c2>] kmem_cache_free+0x62/0x5b0
[    9.044225]  [<ffffffff81465e27>] domain_exit+0x197/0x1c0
[    9.050418]  [<ffffffff81dc7788>] init_dmars+0x758/0x95b
[    9.056527]  [<ffffffff81dc7dfa>] intel_iommu_init+0x351/0x438
[    9.063207]  [<ffffffff81d8a711>] ? iommu_setup+0x27d/0x27d
[    9.069601]  [<ffffffff81d8a739>] pci_iommu_init+0x28/0x52
[    9.075910]  [<ffffffff81000342>] do_one_initcall+0x122/0x180
[    9.082509]  [<ffffffff81077738>] ? parse_args+0x1e8/0x320
[    9.088815]  [<ffffffff81d850e8>] kernel_init_freeable+0x1e1/0x26c
[    9.095895]  [<ffffffff81d84833>] ? do_early_param+0x88/0x88
[    9.102396]  [<ffffffff8154f580>] ? rest_init+0xd0/0xd0
[    9.108410]  [<ffffffff8154f58e>] kernel_init+0xe/0x130
[    9.114423]  [<ffffffff81574a2c>] ret_from_fork+0x7c/0xb0
[    9.120612]  [<ffffffff8154f580>] ? rest_init+0xd0/0xd0

Signed-off-by: Jiang Liu <[email protected]>
Signed-off-by: Joerg Roedel <[email protected]>
mk01 pushed a commit to mk01/linux-linaro-stable-mx6 that referenced this issue Sep 3, 2014
@vireshk @rafaeljw
cpufreq: remove sysfs link when a cpu != policy->cpu, is removed
6964d91 
Commit 42f921a (cpufreq: remove sysfs files for CPUs which failed to
come back after resume) tried to do this but missed this piece of code
to fix.

Currently we are getting this on suspend/resume:

------------[ cut here ]------------
WARNING: CPU: 0 PID: 877 at fs/sysfs/dir.c:52 sysfs_warn_dup+0x68/0x84()
sysfs: cannot create duplicate filename '/devices/system/cpu/cpu1/cpufreq'
Modules linked in: brcmfmac brcmutil
CPU: 0 PID: 877 Comm: test-rtc-resume Not tainted 3.14.0-rc2-00259-g9398a10cd964 linux4kix#12
[<c0015bac>] (unwind_backtrace) from [<c0011850>] (show_stack+0x10/0x14)
[<c0011850>] (show_stack) from [<c056e018>] (dump_stack+0x80/0xcc)
[<c056e018>] (dump_stack) from [<c0025e44>] (warn_slowpath_common+0x64/0x88)
[<c0025e44>] (warn_slowpath_common) from [<c0025efc>] (warn_slowpath_fmt+0x30/0x40)
[<c0025efc>] (warn_slowpath_fmt) from [<c012776c>] (sysfs_warn_dup+0x68/0x84)
[<c012776c>] (sysfs_warn_dup) from [<c0127a54>] (sysfs_do_create_link_sd+0xb0/0xb8)
[<c0127a54>] (sysfs_do_create_link_sd) from [<c038ef64>] (__cpufreq_add_dev.isra.27+0x2a8/0x814)
[<c038ef64>] (__cpufreq_add_dev.isra.27) from [<c038f548>] (cpufreq_cpu_callback+0x70/0x8c)
[<c038f548>] (cpufreq_cpu_callback) from [<c0043864>] (notifier_call_chain+0x44/0x84)
[<c0043864>] (notifier_call_chain) from [<c0025f60>] (__cpu_notify+0x28/0x44)
[<c0025f60>] (__cpu_notify) from [<c00261e8>] (_cpu_up+0xf0/0x140)
[<c00261e8>] (_cpu_up) from [<c0569eb8>] (enable_nonboot_cpus+0x68/0xb0)
[<c0569eb8>] (enable_nonboot_cpus) from [<c006339c>] (suspend_devices_and_enter+0x198/0x2dc)
[<c006339c>] (suspend_devices_and_enter) from [<c0063654>] (pm_suspend+0x174/0x1e8)
[<c0063654>] (pm_suspend) from [<c00624e0>] (state_store+0x6c/0xbc)
[<c00624e0>] (state_store) from [<c01fc200>] (kobj_attr_store+0x14/0x20)
[<c01fc200>] (kobj_attr_store) from [<c0126e50>] (sysfs_kf_write+0x44/0x48)
[<c0126e50>] (sysfs_kf_write) from [<c012a274>] (kernfs_fop_write+0xb4/0x14c)
[<c012a274>] (kernfs_fop_write) from [<c00d4818>] (vfs_write+0xa8/0x180)
[<c00d4818>] (vfs_write) from [<c00d4bb8>] (SyS_write+0x3c/0x70)
[<c00d4bb8>] (SyS_write) from [<c000e620>] (ret_fast_syscall+0x0/0x30)
---[ end trace 76969904b614c18f ]---

Fix this by removing sysfs link for cpufreq directory when cpu removed
isn't policy->cpu.

Revamps: 42f921a (cpufreq: remove sysfs files for CPUs which failed to come back after resume)
Reported-and-tested-by: Stephen Warren <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
@Nevnaur
Copy link

Nevnaur commented Sep 3, 2014

Hi guys

I upgraded a SD card to the new image OpenELEC-Cuboxi.arm-devel-20140903072728-r19162-gee772f5.img.gz but the problem is the same, of course I tried too use “systemctl restart xbmc” after 5 minutes of the system boot but the problem is the same.

I hope it helps.

@pieska
Copy link
Author

pieska commented Sep 4, 2014

I just tested OpenELEC-Cuboxi.arm-devel-20140904012447-r19177-gd405945 and CEC is working again. Thanks guy, much appreciated.

@Nevnaur
Copy link

Nevnaur commented Sep 5, 2014

Hi guys

I upgraded my SD card to the new image OpenELEC-Cuboxi.arm-devel-20140904012447-r19177-gd405945.img.gz and the problem with CEC works fine now ;D

I detect a little issue, the sound by default with this image is configured with a “imx-spdif Analog” and any user who wont to use HDMI to video and audio of Cubox-i need to change the config to “imx-hdmi-soc HDMI”, but it is very easy to any OpenElec user.

Thanks a lot guys!!

@warped-rudi
Copy link
Contributor

@Nevnaur: Could you please stay on topic? This is issue tracker is for generic kernel problems. It is not the support channel for OpenELEC.

@sraue
Copy link

sraue commented Sep 5, 2014

works with #14 and updated libCEC from @mk01, could be closed if #14 is merged

tomlohave pushed a commit to tomlohave/linux-linaro-stable-mx6 that referenced this issue Feb 21, 2015
@rabeeh
Merge pull request linux4kix#12 from linux4kix/linux-linaro-lsk-v3.14…
43fe0bd 
…-mx6

brcmfmac: deal with NL80211_CHANWIDTH_20_NOHT setting
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
4 participants
@sraue @warped-rudi @pieska @Nevnaur