Surface Pro 3 Type Cover from Ubuntu Forums #129

chemelnucfin · 2014-10-29T07:08:47Z

Surface Pro 3 Type Cover that works with Ubuntu (and possibly Arch) from this thread. Both trackpad and keyboard work after compiling my own kernel.
http://ubuntuforums.org/showthread.php?t=2231207&page=2&s=44910e0c56047e4f93dfd9fea58121ef
This is the first time I'm submitting a pull request to the linux kernel, please point out any mistakes if I made any.

exec · 2014-10-29T19:11:27Z

Worked for me as well, thank you @chemelnucfin

jnavila · 2014-10-29T19:54:58Z

Not surprised that your PR is numbered only 129?

For more information, please refer to https://github.com/torvalds/linux/blob/master/Documentation/HOWTO

Also you should address to the subsystem mailing list.

…heckpatch-fixes ERROR: code indent should use tabs where possible torvalds#120: FILE: include/linux/capability.h:220: + return true;$ WARNING: please, no spaces at the start of a line torvalds#120: FILE: include/linux/capability.h:220: + return true;$ ERROR: code indent should use tabs where possible torvalds#125: FILE: include/linux/capability.h:225: + return true;$ WARNING: please, no spaces at the start of a line torvalds#125: FILE: include/linux/capability.h:225: + return true;$ ERROR: code indent should use tabs where possible torvalds#129: FILE: include/linux/capability.h:229: + return true;$ WARNING: please, no spaces at the start of a line torvalds#129: FILE: include/linux/capability.h:229: + return true;$ ERROR: code indent should use tabs where possible torvalds#134: FILE: include/linux/capability.h:234: + return true;$ WARNING: please, no spaces at the start of a line torvalds#134: FILE: include/linux/capability.h:234: + return true;$ ERROR: code indent should use tabs where possible torvalds#170: FILE: include/linux/cred.h:79: + return 1;$ WARNING: please, no spaces at the start of a line torvalds#170: FILE: include/linux/cred.h:79: + return 1;$ ERROR: code indent should use tabs where possible torvalds#174: FILE: include/linux/cred.h:83: + return 1;$ WARNING: please, no spaces at the start of a line torvalds#174: FILE: include/linux/cred.h:83: + return 1;$ total: 6 errors, 6 warnings, 310 lines checked NOTE: whitespace errors detected, you may wish to use scripts/cleanpatch or scripts/cleanfile ./patches/kernel-conditionally-support-non-root-users-groups-and-capabilities.patch has style problems, please review. If any of these errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: Iulia Manda <[email protected]> Signed-off-by: Andrew Morton <[email protected]>

On Mon, Nov 30, 2015 at 10:20:49AM +0100, Dmitry Vyukov wrote: > ============================================= > [ INFO: possible recursive locking detected ] > 4.4.0-rc1+ torvalds#129 Not tainted > --------------------------------------------- > a.out/6283 is trying to acquire lock: > (&ctx->lock){-.....}, at: [<ffffffff815072ce>] > __perf_event_period+0x8e/0x4b0 kernel/events/core.c:4156 > > but task is already holding lock: > (&ctx->lock){-.....}, at: [< inline >] perf_event_period > kernel/events/core.c:4212 > (&ctx->lock){-.....}, at: [< inline >] _perf_ioctl > kernel/events/core.c:4266 > (&ctx->lock){-.....}, at: [<ffffffff8152331c>] perf_ioctl+0x7bc/0xcc0 > kernel/events/core.c:4320 > Indeed so. I suppose the below should fix this, I'll go try in a bit.

Cc: David Rientjes <[email protected]> WARNING: line over 80 characters torvalds#99: FILE: mm/page_alloc.c:2965: + * zone list (with a backoff mechanism which is a function of no_progress_loops). WARNING: line over 80 characters torvalds#129: FILE: mm/page_alloc.c:2995: + * Keep reclaiming pages while there is a chance this will lead somewhere. WARNING: line over 80 characters torvalds#134: FILE: mm/page_alloc.c:3000: + for_each_zone_zonelist_nodemask(zone, z, ac->zonelist, ac->high_zoneidx, ac->nodemask) { WARNING: line over 80 characters torvalds#138: FILE: mm/page_alloc.c:3004: + available -= DIV_ROUND_UP(no_progress_loops * available, MAX_RECLAIM_RETRIES); WARNING: line over 80 characters torvalds#142: FILE: mm/page_alloc.c:3008: + * Would the allocation succeed if we reclaimed the whole available? WARNING: line over 80 characters torvalds#146: FILE: mm/page_alloc.c:3012: + /* Wait for some write requests to complete then retry */ total: 0 errors, 6 warnings, 202 lines checked ./patches/mm-oom-rework-oom-detection.patch has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: David Rientjes <[email protected]> Cc: Hillf Danton <[email protected]> Cc: Johannes Weiner <[email protected]> Cc: KAMEZAWA Hiroyuki <[email protected]> Cc: Mel Gorman <[email protected]> Cc: Michal Hocko <[email protected]> Cc: Tetsuo Handa <[email protected]> Signed-off-by: Andrew Morton <[email protected]>

When enabling stack trace via "echo 1 > /proc/sys/kernel/stack_tracer_enabled", the below KASAN warning is triggered: BUG: KASAN: stack-out-of-bounds in check_stack+0x344/0x848 at addr ffffffc0689ebab8 Read of size 8 by task ksoftirqd/4/29 page:ffffffbdc3a27ac0 count:0 mapcount:0 mapping: (null) index:0x0 flags: 0x0() page dumped because: kasan: bad access detected CPU: 4 PID: 29 Comm: ksoftirqd/4 Not tainted 4.5.0-rc1 torvalds#129 Hardware name: Freescale Layerscape 2085a RDB Board (DT) Call trace: [<ffffffc000091300>] dump_backtrace+0x0/0x3a0 [<ffffffc0000916c4>] show_stack+0x24/0x30 [<ffffffc0009bbd78>] dump_stack+0xd8/0x168 [<ffffffc000420bb0>] kasan_report_error+0x6a0/0x920 [<ffffffc000421688>] kasan_report+0x70/0xb8 [<ffffffc00041f7f0>] __asan_load8+0x60/0x78 [<ffffffc0002e05c4>] check_stack+0x344/0x848 [<ffffffc0002e0c8c>] stack_trace_call+0x1c4/0x370 [<ffffffc0002af558>] ftrace_ops_no_ops+0x2c0/0x590 [<ffffffc00009f25c>] ftrace_graph_call+0x0/0x14 [<ffffffc0000881bc>] fpsimd_thread_switch+0x24/0x1e8 [<ffffffc000089864>] __switch_to+0x34/0x218 [<ffffffc0011e089c>] __schedule+0x3ac/0x15b8 [<ffffffc0011e1f6c>] schedule+0x5c/0x178 [<ffffffc0001632a8>] smpboot_thread_fn+0x350/0x960 [<ffffffc00015b518>] kthread+0x1d8/0x2b0 [<ffffffc0000874d0>] ret_from_fork+0x10/0x40 Memory state around the buggy address: ffffffc0689eb980: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 f4 f4 f4 ffffffc0689eba00: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 >ffffffc0689eba80: 00 00 f1 f1 f1 f1 00 f4 f4 f4 f3 f3 f3 f3 00 00 ^ ffffffc0689ebb00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffffffc0689ebb80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 The stacker tracer traverses the whole kernel stack when saving the max stack trace. It may touch the stack red zones to cause the warning. So, just disable the instrumentation to silence the warning. Signed-off-by: Yang Shi <[email protected]>

Cc: David Rientjes <[email protected]> WARNING: line over 80 characters torvalds#99: FILE: mm/page_alloc.c:2965: + * zone list (with a backoff mechanism which is a function of no_progress_loops). WARNING: line over 80 characters torvalds#129: FILE: mm/page_alloc.c:2995: + * Keep reclaiming pages while there is a chance this will lead somewhere. WARNING: line over 80 characters torvalds#134: FILE: mm/page_alloc.c:3000: + for_each_zone_zonelist_nodemask(zone, z, ac->zonelist, ac->high_zoneidx, ac->nodemask) { WARNING: line over 80 characters torvalds#138: FILE: mm/page_alloc.c:3004: + available -= DIV_ROUND_UP(no_progress_loops * available, MAX_RECLAIM_RETRIES); WARNING: line over 80 characters torvalds#142: FILE: mm/page_alloc.c:3008: + * Would the allocation succeed if we reclaimed the whole available? WARNING: line over 80 characters torvalds#146: FILE: mm/page_alloc.c:3012: + /* Wait for some write requests to complete then retry */ total: 0 errors, 6 warnings, 202 lines checked ./patches/mm-oom-rework-oom-detection.patch has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: David Rientjes <[email protected]> Cc: Hillf Danton <[email protected]> Cc: Johannes Weiner <[email protected]> Cc: KAMEZAWA Hiroyuki <[email protected]> Cc: Mel Gorman <[email protected]> Cc: Michal Hocko <[email protected]> Cc: Tetsuo Handa <[email protected]> Signed-off-by: Andrew Morton <[email protected]>

When enabling stack trace via "echo 1 > /proc/sys/kernel/stack_tracer_enabled", the below KASAN warning is triggered: BUG: KASAN: stack-out-of-bounds in check_stack+0x344/0x848 at addr ffffffc0689ebab8 Read of size 8 by task ksoftirqd/4/29 page:ffffffbdc3a27ac0 count:0 mapcount:0 mapping: (null) index:0x0 flags: 0x0() page dumped because: kasan: bad access detected CPU: 4 PID: 29 Comm: ksoftirqd/4 Not tainted 4.5.0-rc1 #129 Hardware name: Freescale Layerscape 2085a RDB Board (DT) Call trace: [<ffffffc000091300>] dump_backtrace+0x0/0x3a0 [<ffffffc0000916c4>] show_stack+0x24/0x30 [<ffffffc0009bbd78>] dump_stack+0xd8/0x168 [<ffffffc000420bb0>] kasan_report_error+0x6a0/0x920 [<ffffffc000421688>] kasan_report+0x70/0xb8 [<ffffffc00041f7f0>] __asan_load8+0x60/0x78 [<ffffffc0002e05c4>] check_stack+0x344/0x848 [<ffffffc0002e0c8c>] stack_trace_call+0x1c4/0x370 [<ffffffc0002af558>] ftrace_ops_no_ops+0x2c0/0x590 [<ffffffc00009f25c>] ftrace_graph_call+0x0/0x14 [<ffffffc0000881bc>] fpsimd_thread_switch+0x24/0x1e8 [<ffffffc000089864>] __switch_to+0x34/0x218 [<ffffffc0011e089c>] __schedule+0x3ac/0x15b8 [<ffffffc0011e1f6c>] schedule+0x5c/0x178 [<ffffffc0001632a8>] smpboot_thread_fn+0x350/0x960 [<ffffffc00015b518>] kthread+0x1d8/0x2b0 [<ffffffc0000874d0>] ret_from_fork+0x10/0x40 Memory state around the buggy address: ffffffc0689eb980: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 f4 f4 f4 ffffffc0689eba00: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 >ffffffc0689eba80: 00 00 f1 f1 f1 f1 00 f4 f4 f4 f3 f3 f3 f3 00 00 ^ ffffffc0689ebb00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffffffc0689ebb80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 The stacker tracer traverses the whole kernel stack when saving the max stack trace. It may touch the stack red zones to cause the warning. So, just disable the instrumentation to silence the warning. Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Yang Shi <[email protected]> Signed-off-by: Steven Rostedt <[email protected]>

Cc: David Rientjes <[email protected]> WARNING: line over 80 characters torvalds#99: FILE: mm/page_alloc.c:2965: + * zone list (with a backoff mechanism which is a function of no_progress_loops). WARNING: line over 80 characters torvalds#129: FILE: mm/page_alloc.c:2995: + * Keep reclaiming pages while there is a chance this will lead somewhere. WARNING: line over 80 characters torvalds#134: FILE: mm/page_alloc.c:3000: + for_each_zone_zonelist_nodemask(zone, z, ac->zonelist, ac->high_zoneidx, ac->nodemask) { WARNING: line over 80 characters torvalds#138: FILE: mm/page_alloc.c:3004: + available -= DIV_ROUND_UP(no_progress_loops * available, MAX_RECLAIM_RETRIES); WARNING: line over 80 characters torvalds#142: FILE: mm/page_alloc.c:3008: + * Would the allocation succeed if we reclaimed the whole available? WARNING: line over 80 characters torvalds#146: FILE: mm/page_alloc.c:3012: + /* Wait for some write requests to complete then retry */ total: 0 errors, 6 warnings, 202 lines checked ./patches/mm-oom-rework-oom-detection.patch has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: David Rientjes <[email protected]> Cc: Hillf Danton <[email protected]> Cc: Johannes Weiner <[email protected]> Cc: KAMEZAWA Hiroyuki <[email protected]> Cc: Mel Gorman <[email protected]> Cc: Michal Hocko <[email protected]> Cc: Tetsuo Handa <[email protected]> Signed-off-by: Andrew Morton <[email protected]>

LE Create CIS command shall not be sent before all CIS Established events from its previous invocation have been processed. Currently it is sent via hci_sync but that only waits for the first event, but there can be multiple. Make it wait for all events, and simplify the CIS creation as follows: Add new flag HCI_CONN_CREATE_CIS, which is set if Create CIS has been sent for the connection but it is not yet completed. Make BT_CONNECT state to mean the connection wants Create CIS. On events after which new Create CIS may need to be sent, send it if possible and some connections need it. These events are: hci_connect_cis, iso_connect_cfm, hci_cs_le_create_cis, hci_le_cis_estabilished_evt. The Create CIS status/completion events shall queue new Create CIS only if at least one of the connections transitions away from BT_CONNECT, so that we don't loop if controller is sending bogus events. This fixes sending multiple CIS Create for the same CIS in the "ISO AC 6(i) - Success" BlueZ test case: < HCI Command: LE Create Co.. (0x08|0x0064) plen 9 torvalds#129 [hci0] Number of CIS: 2 CIS Handle: 257 ACL Handle: 42 CIS Handle: 258 ACL Handle: 42 > HCI Event: Command Status (0x0f) plen 4 torvalds#130 [hci0] LE Create Connected Isochronous Stream (0x08|0x0064) ncmd 1 Status: Success (0x00) > HCI Event: LE Meta Event (0x3e) plen 29 torvalds#131 [hci0] LE Connected Isochronous Stream Established (0x19) Status: Success (0x00) Connection Handle: 257 ... < HCI Command: LE Setup Is.. (0x08|0x006e) plen 13 torvalds#132 [hci0] ... > HCI Event: Command Complete (0x0e) plen 6 torvalds#133 [hci0] LE Setup Isochronous Data Path (0x08|0x006e) ncmd 1 ... < HCI Command: LE Create Co.. (0x08|0x0064) plen 5 torvalds#134 [hci0] Number of CIS: 1 CIS Handle: 258 ACL Handle: 42 > HCI Event: Command Status (0x0f) plen 4 torvalds#135 [hci0] LE Create Connected Isochronous Stream (0x08|0x0064) ncmd 1 Status: ACL Connection Already Exists (0x0b) > HCI Event: LE Meta Event (0x3e) plen 29 torvalds#136 [hci0] LE Connected Isochronous Stream Established (0x19) Status: Success (0x00) Connection Handle: 258 ... Fixes: c09b80b ("Bluetooth: hci_conn: Fix not waiting for HCI_EVT_LE_CIS_ESTABLISHED") Signed-off-by: Pauli Virtanen <[email protected]>

LE Create CIS command shall not be sent before all CIS Established events from its previous invocation have been processed. Currently it is sent via hci_sync but that only waits for the first event, but there can be multiple. Make it wait for all events, and simplify the CIS creation as follows: Add new flag HCI_CONN_CREATE_CIS, which is set if Create CIS has been sent for the connection but it is not yet completed. Make BT_CONNECT state to mean the connection wants Create CIS. On events after which new Create CIS may need to be sent, send it if possible and some connections need it. These events are: hci_connect_cis, iso_connect_cfm, hci_cs_le_create_cis, hci_le_cis_estabilished_evt. The Create CIS status/completion events shall queue new Create CIS only if at least one of the connections transitions away from BT_CONNECT, so that we don't loop if controller is sending bogus events. This fixes sending multiple CIS Create for the same CIS in the "ISO AC 6(i) - Success" BlueZ test case: < HCI Command: LE Create Co.. (0x08|0x0064) plen 9 torvalds#129 [hci0] Number of CIS: 2 CIS Handle: 257 ACL Handle: 42 CIS Handle: 258 ACL Handle: 42 > HCI Event: Command Status (0x0f) plen 4 torvalds#130 [hci0] LE Create Connected Isochronous Stream (0x08|0x0064) ncmd 1 Status: Success (0x00) > HCI Event: LE Meta Event (0x3e) plen 29 torvalds#131 [hci0] LE Connected Isochronous Stream Established (0x19) Status: Success (0x00) Connection Handle: 257 ... < HCI Command: LE Setup Is.. (0x08|0x006e) plen 13 torvalds#132 [hci0] ... > HCI Event: Command Complete (0x0e) plen 6 torvalds#133 [hci0] LE Setup Isochronous Data Path (0x08|0x006e) ncmd 1 ... < HCI Command: LE Create Co.. (0x08|0x0064) plen 5 torvalds#134 [hci0] Number of CIS: 1 CIS Handle: 258 ACL Handle: 42 > HCI Event: Command Status (0x0f) plen 4 torvalds#135 [hci0] LE Create Connected Isochronous Stream (0x08|0x0064) ncmd 1 Status: ACL Connection Already Exists (0x0b) > HCI Event: LE Meta Event (0x3e) plen 29 torvalds#136 [hci0] LE Connected Isochronous Stream Established (0x19) Status: Success (0x00) Connection Handle: 258 ... Fixes: c09b80b ("Bluetooth: hci_conn: Fix not waiting for HCI_EVT_LE_CIS_ESTABLISHED") Signed-off-by: Pauli Virtanen <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]>

[ Upstream commit 7f74563 ] LE Create CIS command shall not be sent before all CIS Established events from its previous invocation have been processed. Currently it is sent via hci_sync but that only waits for the first event, but there can be multiple. Make it wait for all events, and simplify the CIS creation as follows: Add new flag HCI_CONN_CREATE_CIS, which is set if Create CIS has been sent for the connection but it is not yet completed. Make BT_CONNECT state to mean the connection wants Create CIS. On events after which new Create CIS may need to be sent, send it if possible and some connections need it. These events are: hci_connect_cis, iso_connect_cfm, hci_cs_le_create_cis, hci_le_cis_estabilished_evt. The Create CIS status/completion events shall queue new Create CIS only if at least one of the connections transitions away from BT_CONNECT, so that we don't loop if controller is sending bogus events. This fixes sending multiple CIS Create for the same CIS in the "ISO AC 6(i) - Success" BlueZ test case: < HCI Command: LE Create Co.. (0x08|0x0064) plen 9 torvalds#129 [hci0] Number of CIS: 2 CIS Handle: 257 ACL Handle: 42 CIS Handle: 258 ACL Handle: 42 > HCI Event: Command Status (0x0f) plen 4 torvalds#130 [hci0] LE Create Connected Isochronous Stream (0x08|0x0064) ncmd 1 Status: Success (0x00) > HCI Event: LE Meta Event (0x3e) plen 29 torvalds#131 [hci0] LE Connected Isochronous Stream Established (0x19) Status: Success (0x00) Connection Handle: 257 ... < HCI Command: LE Setup Is.. (0x08|0x006e) plen 13 torvalds#132 [hci0] ... > HCI Event: Command Complete (0x0e) plen 6 torvalds#133 [hci0] LE Setup Isochronous Data Path (0x08|0x006e) ncmd 1 ... < HCI Command: LE Create Co.. (0x08|0x0064) plen 5 torvalds#134 [hci0] Number of CIS: 1 CIS Handle: 258 ACL Handle: 42 > HCI Event: Command Status (0x0f) plen 4 torvalds#135 [hci0] LE Create Connected Isochronous Stream (0x08|0x0064) ncmd 1 Status: ACL Connection Already Exists (0x0b) > HCI Event: LE Meta Event (0x3e) plen 29 torvalds#136 [hci0] LE Connected Isochronous Stream Established (0x19) Status: Success (0x00) Connection Handle: 258 ... Fixes: c09b80b ("Bluetooth: hci_conn: Fix not waiting for HCI_EVT_LE_CIS_ESTABLISHED") Signed-off-by: Pauli Virtanen <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>

BugLink: https://bugs.launchpad.net/bugs/2035588 [ Upstream commit 7f74563 ] LE Create CIS command shall not be sent before all CIS Established events from its previous invocation have been processed. Currently it is sent via hci_sync but that only waits for the first event, but there can be multiple. Make it wait for all events, and simplify the CIS creation as follows: Add new flag HCI_CONN_CREATE_CIS, which is set if Create CIS has been sent for the connection but it is not yet completed. Make BT_CONNECT state to mean the connection wants Create CIS. On events after which new Create CIS may need to be sent, send it if possible and some connections need it. These events are: hci_connect_cis, iso_connect_cfm, hci_cs_le_create_cis, hci_le_cis_estabilished_evt. The Create CIS status/completion events shall queue new Create CIS only if at least one of the connections transitions away from BT_CONNECT, so that we don't loop if controller is sending bogus events. This fixes sending multiple CIS Create for the same CIS in the "ISO AC 6(i) - Success" BlueZ test case: < HCI Command: LE Create Co.. (0x08|0x0064) plen 9 torvalds#129 [hci0] Number of CIS: 2 CIS Handle: 257 ACL Handle: 42 CIS Handle: 258 ACL Handle: 42 > HCI Event: Command Status (0x0f) plen 4 torvalds#130 [hci0] LE Create Connected Isochronous Stream (0x08|0x0064) ncmd 1 Status: Success (0x00) > HCI Event: LE Meta Event (0x3e) plen 29 torvalds#131 [hci0] LE Connected Isochronous Stream Established (0x19) Status: Success (0x00) Connection Handle: 257 ... < HCI Command: LE Setup Is.. (0x08|0x006e) plen 13 torvalds#132 [hci0] ... > HCI Event: Command Complete (0x0e) plen 6 torvalds#133 [hci0] LE Setup Isochronous Data Path (0x08|0x006e) ncmd 1 ... < HCI Command: LE Create Co.. (0x08|0x0064) plen 5 torvalds#134 [hci0] Number of CIS: 1 CIS Handle: 258 ACL Handle: 42 > HCI Event: Command Status (0x0f) plen 4 torvalds#135 [hci0] LE Create Connected Isochronous Stream (0x08|0x0064) ncmd 1 Status: ACL Connection Already Exists (0x0b) > HCI Event: LE Meta Event (0x3e) plen 29 torvalds#136 [hci0] LE Connected Isochronous Stream Established (0x19) Status: Success (0x00) Connection Handle: 258 ... Fixes: c09b80b ("Bluetooth: hci_conn: Fix not waiting for HCI_EVT_LE_CIS_ESTABLISHED") Signed-off-by: Pauli Virtanen <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Andrea Righi <[email protected]>

This reverts commit 0298609 due to a boot-time oops: BUG: Kernel NULL pointer dereference on read at 0x00000018 Faulting instruction address: 0xc00000000004223c Oops: Kernel access of bad area, sig: 7 [#1] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries Modules linked in: CPU: 0 PID: 0 Comm: swapper Tainted: G W 6.6.0-rc2+ torvalds#129 NIP: c00000000004223c LR: c000000000042238 CTR: 0000000000000000 REGS: c000000002c579d0 TRAP: 0300 Tainted: G W (6.6.0-rc2+) MSR: 8000000000001033 <SF,ME,IR,DR,RI,LE> CR: 28000284 XER: 00000000 CFAR: c000000000042008 DAR: 0000000000000018 DSISR: 00080000 IRQMASK: 3 GPR00: c000000000042238 c000000002c57c70 c000000001f5eb00 0000000000000000 GPR04: c00000000294cd08 0000000000000002 c000000002c579b4 0000000000000000 GPR08: 0000000000000000 0000000000000002 c000000002c0da80 0000000000000000 GPR12: 0000000000000000 c000000005e40000 0000000000000000 0000000002097728 GPR16: 0000000000001111 0000000000000001 0000000002097b80 00000000020975b8 GPR20: 00000000020976f0 00000000020974e8 00000000030feb00 00000000030feb00 GPR24: 0000000000002008 0000000000000000 0000000000000001 c0000000028f3d70 GPR28: 0000000002d31020 c000000002cac268 c000000002d31020 0000000000000000 NIP [c00000000004223c] do_enter_rtas+0xcc/0x460 LR [c000000000042238] do_enter_rtas+0xc8/0x460 Call Trace: [c000000002c57c70] [c000000000042238] do_enter_rtas+0xc8/0x460 (unreliable) [c000000002c57cc0] [c000000000042e34] rtas_call+0x434/0x490 [c000000002c57d20] [c0000000000fd584] papr_sysparm_get+0xe4/0x230 [c000000002c57db0] [c0000000020267d0] pSeries_probe+0x2f0/0x5fc [c000000002c57e80] [c00000000200a318] setup_arch+0x11c/0x524 [c000000002c57f10] [c00000000200418c] start_kernel+0xcc/0xc1c [c000000002c57fe0] [c00000000000e788] start_here_common+0x1c/0x20

…egdef.h The script checkpatch.pl reported spelling error in rtl871x_mp_phy_regdef.h as below: ''' WARNING: 'Tranceiver' may be misspelled - perhaps 'Transceiver'? torvalds#129: #define rFPGA0_XA_LSSIReadBack 0x8a0 /* Tranceiver LSSI Readback */ ^^^^^^^^^^ ''' This patch corrects a spelling error, changing "Tranceiver" to "Transceiver." Signed-off-by: Dipendra Khadka <[email protected]>

…egdef.h The script checkpatch.pl reported spelling error in rtl871x_mp_phy_regdef.h as below: ''' WARNING: 'Tranceiver' may be misspelled - perhaps 'Transceiver'? torvalds#129: #define rFPGA0_XA_LSSIReadBack 0x8a0 /* Tranceiver LSSI Readback */ ^^^^^^^^^^ ''' This patch corrects a spelling error, changing "Tranceiver" to "Transceiver." Signed-off-by: Dipendra Khadka <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>

Like commit 1cf3bfc ("bpf: Support 64-bit pointers to kfuncs") for s390x, add support for 64-bit pointers to kfuncs for LoongArch. Since the infrastructure is already implemented in BPF core, the only thing need to be done is to override bpf_jit_supports_far_kfunc_call(). Before this change, several test_verifier tests failed: # ./test_verifier | grep # | grep FAIL torvalds#119/p calls: invalid kfunc call: ptr_to_mem to struct with non-scalar FAIL torvalds#120/p calls: invalid kfunc call: ptr_to_mem to struct with nesting depth > 4 FAIL torvalds#121/p calls: invalid kfunc call: ptr_to_mem to struct with FAM FAIL torvalds#122/p calls: invalid kfunc call: reg->type != PTR_TO_CTX FAIL torvalds#123/p calls: invalid kfunc call: void * not allowed in func proto without mem size arg FAIL torvalds#124/p calls: trigger reg2btf_ids[reg->type] for reg->type > __BPF_REG_TYPE_MAX FAIL torvalds#125/p calls: invalid kfunc call: reg->off must be zero when passed to release kfunc FAIL torvalds#126/p calls: invalid kfunc call: don't match first member type when passed to release kfunc FAIL torvalds#127/p calls: invalid kfunc call: PTR_TO_BTF_ID with negative offset FAIL torvalds#128/p calls: invalid kfunc call: PTR_TO_BTF_ID with variable offset FAIL torvalds#129/p calls: invalid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL torvalds#130/p calls: valid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL torvalds#486/p map_kptr: ref: reference state created and released on xchg FAIL This is because the kfuncs in the loaded module are far away from __bpf_call_base: ffff800002009440 t bpf_kfunc_call_test_fail1 [bpf_testmod] 9000000002e128d8 T __bpf_call_base The offset relative to __bpf_call_base does NOT fit in s32, which breaks the assumption in BPF core. Enable bpf_jit_supports_far_kfunc_call() lifts this limit. Note that to reproduce the above result, tools/testing/selftests/bpf/config should be applied, and run the test with JIT enabled, unpriv BPF enabled. With this change, the test_verifier tests now all passed: # ./test_verifier ... Summary: 777 PASSED, 0 SKIPPED, 0 FAILED Tested-by: Tiezhu Yang <[email protected]> Signed-off-by: Hengqi Chen <[email protected]> Signed-off-by: Huacai Chen <[email protected]>

Surface Pro 3 Type Cover from Ubuntu Forums

4ec5c72

aw added 2 commits October 30, 2014 02:41

Merge branch 'master' of https://github.com/torvalds/linux

dc720b1

surface pro 3 type cover

592b155

chemelnucfin closed this Nov 12, 2014

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Surface Pro 3 Type Cover from Ubuntu Forums #129

Surface Pro 3 Type Cover from Ubuntu Forums #129

chemelnucfin commented Oct 29, 2014

exec commented Oct 29, 2014

jnavila commented Oct 29, 2014

Surface Pro 3 Type Cover from Ubuntu Forums #129

Surface Pro 3 Type Cover from Ubuntu Forums #129

Conversation

chemelnucfin commented Oct 29, 2014

exec commented Oct 29, 2014

jnavila commented Oct 29, 2014