kernel BUG at drivers/platform/msm/ipa/ipa_v2/ipa_uc.c:366! #1
Comments
krasCGQ
added a commit
that referenced
this issue
May 4, 2020
CAF's explanation on the error code doesn't give any helpful hint on why this kind of error even happens, hence escalating the debugging. Issue tracker: #1 Signed-off-by: Albert I <kras@raphielgang.org>
Nicklas373
pushed a commit
to Nicklas373/kernel_xiaomi_msm8953-4.9
that referenced
this issue
May 4, 2020
CAF's explanation on the error code doesn't give any helpful hint on why this kind of error even happens, hence escalating the debugging. Issue tracker: KudProject/kernel_xiaomi_msm8953-4.9#1 Signed-off-by: Albert I <kras@raphielgang.org>
|
Apparently also happens on other parts of IPA as well: |
krasCGQ
added a commit
that referenced
this issue
May 5, 2020
Both ipa_uc_send_cmd() of v2 and ipa3_uc_send_cmd_64b_param() of v3 already have their own BUG() handler before returning -EFAULT, making these BUG() are kinda pointless. Issue tracker: #1 Signed-off-by: Albert I <kras@raphielgang.org>
Nicklas373
pushed a commit
to Nicklas373/kernel_xiaomi_msm8953-4.9
that referenced
this issue
May 5, 2020
CAF's explanation on the error code doesn't give any helpful hint on why this kind of error even happens, hence escalating the debugging. Issue tracker: KudProject/kernel_xiaomi_msm8953-4.9#1 Signed-off-by: Albert I <kras@raphielgang.org>
Nicklas373
pushed a commit
to Nicklas373/kernel_xiaomi_msm8953-4.9
that referenced
this issue
May 5, 2020
Both ipa_uc_send_cmd() of v2 and ipa3_uc_send_cmd_64b_param() of v3 already have their own BUG() handler before returning -EFAULT, making these BUG() are kinda pointless. Issue tracker: KudProject/kernel_xiaomi_msm8953-4.9#1 Signed-off-by: Albert I <kras@raphielgang.org>
|
I have cherry-pick your commit but some user report to me its no booted I get this almost same error in dmesg from user now... [ 31.458328] clock_panic_callback: a53_perf_clk frequency: 0 Hz |
|
@Aarqw12 can you post logs leading to panic? |
|
Very obvious of kernel stack corruption |
sorry its no ipa issue so ... |
Nicklas373
pushed a commit
to Nicklas373/kernel_xiaomi_msm8953-4.9
that referenced
this issue
May 12, 2020
CAF's explanation on the error code doesn't give any helpful hint on why this kind of error even happens, hence escalating the debugging. Issue tracker: KudProject/kernel_xiaomi_msm8953-4.9#1 Signed-off-by: Albert I <kras@raphielgang.org>
Nicklas373
pushed a commit
to Nicklas373/kernel_xiaomi_msm8953-4.9
that referenced
this issue
May 12, 2020
Both ipa_uc_send_cmd() of v2 and ipa3_uc_send_cmd_64b_param() of v3 already have their own BUG() handler before returning -EFAULT, making these BUG() are kinda pointless. Issue tracker: KudProject/kernel_xiaomi_msm8953-4.9#1 Signed-off-by: Albert I <kras@raphielgang.org>
krasCGQ
pushed a commit
that referenced
this issue
May 19, 2020
commit 9f614197c744002f9968e82c649fdf7fe778e1e7 upstream. Looks like the dma_sync calls don't do what we want on armv7 either. Fixes: Unable to handle kernel paging request at virtual address 50001000 pgd = (ptrval) [50001000] *pgd=00000000 Internal error: Oops: 805 [#1] SMP ARM Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.3.0-rc6-00271-g9f159ae07f07 #4 Hardware name: Freescale i.MX53 (Device Tree Support) PC is at v7_dma_clean_range+0x20/0x38 LR is at __dma_page_cpu_to_dev+0x28/0x90 pc : [<c011c76c>] lr : [<c01181c4>] psr: 20000013 sp : d80b5a88 ip : de96c000 fp : d840ce6c r10: 00000000 r9 : 00000001 r8 : d843e010 r7 : 00000000 r6 : 00008000 r5 : ddb6c000 r4 : 00000000 r3 : 0000003f r2 : 00000040 r1 : 50008000 r0 : 50001000 Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 10c5387d Table: 70004019 DAC: 00000051 Process swapper/0 (pid: 1, stack limit = 0x(ptrval)) Signed-off-by: Rob Clark <robdclark@chromium.org> Fixes: 3de433c5b38a ("drm/msm: Use the correct dma_sync calls in msm_gem") Tested-by: Fabio Estevam <festevam@gmail.com> Cc: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
krasCGQ
pushed a commit
that referenced
this issue
May 19, 2020
[ Upstream commit 4dee15b4fd0d61ec6bbd179238191e959d34cf7a ]
In the macvlan_device_event(), the list_first_entry_or_null() is used.
This function could return null pointer if there is no node.
But, the macvlan module doesn't check the null pointer.
So, null-ptr-deref would occur.
bond0
|
+----+-----+
| |
macvlan0 macvlan1
| |
dummy0 dummy1
The problem scenario.
If dummy1 is removed,
1. ->dellink() of dummy1 is called.
2. NETDEV_UNREGISTER of dummy1 notification is sent to macvlan module.
3. ->dellink() of macvlan1 is called.
4. NETDEV_UNREGISTER of macvlan1 notification is sent to bond module.
5. __bond_release_one() is called and it internally calls
dev_set_mac_address().
6. dev_set_mac_address() calls the ->ndo_set_mac_address() of macvlan1,
which is macvlan_set_mac_address().
7. macvlan_set_mac_address() calls the dev_set_mac_address() with dummy1.
8. NETDEV_CHANGEADDR of dummy1 is sent to macvlan module.
9. In the macvlan_device_event(), it calls list_first_entry_or_null().
At this point, dummy1 and macvlan1 were removed.
So, list_first_entry_or_null() will return NULL.
Test commands:
ip netns add nst
ip netns exec nst ip link add bond0 type bond
for i in {0..10}
do
ip netns exec nst ip link add dummy$i type dummy
ip netns exec nst ip link add macvlan$i link dummy$i \
type macvlan mode passthru
ip netns exec nst ip link set macvlan$i master bond0
done
ip netns del nst
Splat looks like:
[ 40.585687][ T146] general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP DEI
[ 40.587249][ T146] KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
[ 40.588342][ T146] CPU: 1 PID: 146 Comm: kworker/u8:2 Not tainted 5.7.0-rc1+ #532
[ 40.589299][ T146] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
[ 40.590469][ T146] Workqueue: netns cleanup_net
[ 40.591045][ T146] RIP: 0010:macvlan_device_event+0x4e2/0x900 [macvlan]
[ 40.591905][ T146] Code: 00 00 00 00 00 fc ff df 80 3c 06 00 0f 85 45 02 00 00 48 89 da 48 b8 00 00 00 00 00 fc ff d2
[ 40.594126][ T146] RSP: 0018:ffff88806116f4a0 EFLAGS: 00010246
[ 40.594783][ T146] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000
[ 40.595653][ T146] RDX: 0000000000000000 RSI: ffff88806547ddd8 RDI: ffff8880540f1360
[ 40.596495][ T146] RBP: ffff88804011a808 R08: fffffbfff4fb8421 R09: fffffbfff4fb8421
[ 40.597377][ T146] R10: ffffffffa7dc2107 R11: 0000000000000000 R12: 0000000000000008
[ 40.598186][ T146] R13: ffff88804011a000 R14: ffff8880540f1000 R15: 1ffff1100c22de9a
[ 40.599012][ T146] FS: 0000000000000000(0000) GS:ffff888067800000(0000) knlGS:0000000000000000
[ 40.600004][ T146] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 40.600665][ T146] CR2: 00005572d3a807b8 CR3: 000000005fcf4003 CR4: 00000000000606e0
[ 40.601485][ T146] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 40.602461][ T146] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 40.603443][ T146] Call Trace:
[ 40.603871][ T146] ? nf_tables_dump_setelem+0xa0/0xa0 [nf_tables]
[ 40.604587][ T146] ? macvlan_uninit+0x100/0x100 [macvlan]
[ 40.605212][ T146] ? __module_text_address+0x13/0x140
[ 40.605842][ T146] notifier_call_chain+0x90/0x160
[ 40.606477][ T146] dev_set_mac_address+0x28e/0x3f0
[ 40.607117][ T146] ? netdev_notify_peers+0xc0/0xc0
[ 40.607762][ T146] ? __module_text_address+0x13/0x140
[ 40.608440][ T146] ? notifier_call_chain+0x90/0x160
[ 40.609097][ T146] ? dev_set_mac_address+0x1f0/0x3f0
[ 40.609758][ T146] dev_set_mac_address+0x1f0/0x3f0
[ 40.610402][ T146] ? __local_bh_enable_ip+0xe9/0x1b0
[ 40.611071][ T146] ? bond_hw_addr_flush+0x77/0x100 [bonding]
[ 40.611823][ T146] ? netdev_notify_peers+0xc0/0xc0
[ 40.612461][ T146] ? bond_hw_addr_flush+0x77/0x100 [bonding]
[ 40.613213][ T146] ? bond_hw_addr_flush+0x77/0x100 [bonding]
[ 40.613963][ T146] ? __local_bh_enable_ip+0xe9/0x1b0
[ 40.614631][ T146] ? bond_time_in_interval.isra.31+0x90/0x90 [bonding]
[ 40.615484][ T146] ? __bond_release_one+0x9f0/0x12c0 [bonding]
[ 40.616230][ T146] __bond_release_one+0x9f0/0x12c0 [bonding]
[ 40.616949][ T146] ? bond_enslave+0x47c0/0x47c0 [bonding]
[ 40.617642][ T146] ? lock_downgrade+0x730/0x730
[ 40.618218][ T146] ? check_flags.part.42+0x450/0x450
[ 40.618850][ T146] ? __mutex_unlock_slowpath+0xd0/0x670
[ 40.619519][ T146] ? trace_hardirqs_on+0x30/0x180
[ 40.620117][ T146] ? wait_for_completion+0x250/0x250
[ 40.620754][ T146] bond_netdev_event+0x822/0x970 [bonding]
[ 40.621460][ T146] ? __module_text_address+0x13/0x140
[ 40.622097][ T146] notifier_call_chain+0x90/0x160
[ 40.622806][ T146] rollback_registered_many+0x660/0xcf0
[ 40.623522][ T146] ? netif_set_real_num_tx_queues+0x780/0x780
[ 40.624290][ T146] ? notifier_call_chain+0x90/0x160
[ 40.624957][ T146] ? netdev_upper_dev_unlink+0x114/0x180
[ 40.625686][ T146] ? __netdev_adjacent_dev_unlink_neighbour+0x30/0x30
[ 40.626421][ T146] ? mutex_is_locked+0x13/0x50
[ 40.627016][ T146] ? unregister_netdevice_queue+0xf2/0x240
[ 40.627663][ T146] unregister_netdevice_many.part.134+0x13/0x1b0
[ 40.628362][ T146] default_device_exit_batch+0x2d9/0x390
[ 40.628987][ T146] ? unregister_netdevice_many+0x40/0x40
[ 40.629615][ T146] ? dev_change_net_namespace+0xcb0/0xcb0
[ 40.630279][ T146] ? prepare_to_wait_exclusive+0x2e0/0x2e0
[ 40.630943][ T146] ? ops_exit_list.isra.9+0x97/0x140
[ 40.631554][ T146] cleanup_net+0x441/0x890
[ ... ]
Fixes: e289fd2 ("macvlan: fix the problem when mac address changes for passthru mode")
Reported-by: syzbot+5035b1f9dc7ea4558d5a@syzkaller.appspotmail.com
Signed-off-by: Taehee Yoo <ap420073@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
krasCGQ
pushed a commit
that referenced
this issue
May 19, 2020
commit 9a9fc42b86c06120744555fea43fdcabe297c656 upstream. If there is a lot(more then 16) of virtio-console devices or virtio_console module is reloaded - buffers 'vtermnos' and 'cons_ops' are overflowed. In older kernels it overruns spinlock which leads to kernel freezing: https://bugzilla.redhat.com/show_bug.cgi?id=1786239 To reproduce the issue, you can try simple script that loads/unloads module. Something like this: while [ 1 ] do modprobe virtio_console sleep 2 modprobe -r virtio_console sleep 2 done Description of problem: Guest get 'Call Trace' when loading module "virtio_console" and unloading it frequently - clearly reproduced on kernel-4.18.0: [ 81.498208] ------------[ cut here ]------------ [ 81.499263] pvqspinlock: lock 0xffffffff92080020 has corrupted value 0xc0774ca0! [ 81.501000] WARNING: CPU: 0 PID: 785 at kernel/locking/qspinlock_paravirt.h:500 __pv_queued_spin_unlock_slowpath+0xc0/0xd0 [ 81.503173] Modules linked in: virtio_console fuse xt_CHECKSUM ipt_MASQUERADE xt_conntrack ipt_REJECT nft_counter nf_nat_tftp nft_objref nf_conntrack_tftp tun bridge stp llc nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nf_tables_set nft_chain_nat_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 nft_chain_route_ipv6 nft_chain_nat_ipv4 nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack nft_chain_route_ipv4 ip6_tables nft_compat ip_set nf_tables nfnetlink sunrpc bochs_drm drm_vram_helper ttm drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm i2c_piix4 pcspkr crct10dif_pclmul crc32_pclmul joydev ghash_clmulni_intel ip_tables xfs libcrc32c sd_mod sg ata_generic ata_piix virtio_net libata crc32c_intel net_failover failover serio_raw virtio_scsi dm_mirror dm_region_hash dm_log dm_mod [last unloaded: virtio_console] [ 81.517019] CPU: 0 PID: 785 Comm: kworker/0:2 Kdump: loaded Not tainted 4.18.0-167.el8.x86_64 #1 [ 81.518639] Hardware name: Red Hat KVM, BIOS 1.12.0-5.scrmod+el8.2.0+5159+d8aa4d83 04/01/2014 [ 81.520205] Workqueue: events control_work_handler [virtio_console] [ 81.521354] RIP: 0010:__pv_queued_spin_unlock_slowpath+0xc0/0xd0 [ 81.522450] Code: 07 00 48 63 7a 10 e8 bf 64 f5 ff 66 90 c3 8b 05 e6 cf d6 01 85 c0 74 01 c3 8b 17 48 89 fe 48 c7 c7 38 4b 29 91 e8 3a 6c fa ff <0f> 0b c3 0f 0b 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 48 [ 81.525830] RSP: 0018:ffffb51a01ffbd70 EFLAGS: 00010282 [ 81.526798] RAX: 0000000000000000 RBX: 0000000000000010 RCX: 0000000000000000 [ 81.528110] RDX: ffff9e66f1826480 RSI: ffff9e66f1816a08 RDI: ffff9e66f1816a08 [ 81.529437] RBP: ffffffff9153ff10 R08: 000000000000026c R09: 0000000000000053 [ 81.530732] R10: 0000000000000000 R11: ffffb51a01ffbc18 R12: ffff9e66cd682200 [ 81.532133] R13: ffffffff9153ff10 R14: ffff9e6685569500 R15: ffff9e66cd682000 [ 81.533442] FS: 0000000000000000(0000) GS:ffff9e66f1800000(0000) knlGS:0000000000000000 [ 81.534914] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 81.535971] CR2: 00005624c55b14d0 CR3: 00000003a023c000 CR4: 00000000003406f0 [ 81.537283] Call Trace: [ 81.537763] __raw_callee_save___pv_queued_spin_unlock_slowpath+0x11/0x20 [ 81.539011] .slowpath+0x9/0xe [ 81.539585] hvc_alloc+0x25e/0x300 [ 81.540237] init_port_console+0x28/0x100 [virtio_console] [ 81.541251] handle_control_message.constprop.27+0x1c4/0x310 [virtio_console] [ 81.542546] control_work_handler+0x70/0x10c [virtio_console] [ 81.543601] process_one_work+0x1a7/0x3b0 [ 81.544356] worker_thread+0x30/0x390 [ 81.545025] ? create_worker+0x1a0/0x1a0 [ 81.545749] kthread+0x112/0x130 [ 81.546358] ? kthread_flush_work_fn+0x10/0x10 [ 81.547183] ret_from_fork+0x22/0x40 [ 81.547842] ---[ end trace aa97649bd16c8655 ]--- [ 83.546539] general protection fault: 0000 [#1] SMP NOPTI [ 83.547422] CPU: 5 PID: 3225 Comm: modprobe Kdump: loaded Tainted: G W --------- - - 4.18.0-167.el8.x86_64 #1 [ 83.549191] Hardware name: Red Hat KVM, BIOS 1.12.0-5.scrmod+el8.2.0+5159+d8aa4d83 04/01/2014 [ 83.550544] RIP: 0010:__pv_queued_spin_lock_slowpath+0x19a/0x2a0 [ 83.551504] Code: c4 c1 ea 12 41 be 01 00 00 00 4c 8d 6d 14 41 83 e4 03 8d 42 ff 49 c1 e4 05 48 98 49 81 c4 40 a5 02 00 4c 03 24 c5 60 48 34 91 <49> 89 2c 24 b8 00 80 00 00 eb 15 84 c0 75 0a 41 0f b6 54 24 14 84 [ 83.554449] RSP: 0018:ffffb51a0323fdb0 EFLAGS: 00010202 [ 83.555290] RAX: 000000000000301c RBX: ffffffff92080020 RCX: 0000000000000001 [ 83.556426] RDX: 000000000000301d RSI: 0000000000000000 RDI: 0000000000000000 [ 83.557556] RBP: ffff9e66f196a540 R08: 000000000000028a R09: ffff9e66d2757788 [ 83.558688] R10: 0000000000000000 R11: 0000000000000000 R12: 646e61725f770b07 [ 83.559821] R13: ffff9e66f196a554 R14: 0000000000000001 R15: 0000000000180000 [ 83.560958] FS: 00007fd5032e8740(0000) GS:ffff9e66f1940000(0000) knlGS:0000000000000000 [ 83.562233] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 83.563149] CR2: 00007fd5022b0da0 CR3: 000000038c334000 CR4: 00000000003406e0 Signed-off-by: Andrew Melnychenko <andrew@daynix.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200414191503.3471783-1-andrew@daynix.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
krasCGQ
pushed a commit
that referenced
this issue
May 19, 2020
commit f1eec3b0d0a849996ebee733b053efa71803dad5 upstream. While calculating overhead for internal journal, also check that j_inum shouldn't be 0. Otherwise we get below error with xfstests generic/050 with external journal (XXX_LOGDEV config) enabled. It could be simply reproduced with loop device with an external journal and marking blockdev as RO before mounting. [ 3337.146838] EXT4-fs error (device pmem1p2): ext4_get_journal_inode:4634: comm mount: inode #0: comm mount: iget: illegal inode # ------------[ cut here ]------------ generic_make_request: Trying to write to read-only block-device pmem1p2 (partno 2) WARNING: CPU: 107 PID: 115347 at block/blk-core.c:788 generic_make_request_checks+0x6b4/0x7d0 CPU: 107 PID: 115347 Comm: mount Tainted: G L --------- -t - 4.18.0-167.el8.ppc64le #1 NIP: c0000000006f6d44 LR: c0000000006f6d40 CTR: 0000000030041dd4 <...> NIP [c0000000006f6d44] generic_make_request_checks+0x6b4/0x7d0 LR [c0000000006f6d40] generic_make_request_checks+0x6b0/0x7d0 <...> Call Trace: generic_make_request_checks+0x6b0/0x7d0 (unreliable) generic_make_request+0x3c/0x420 submit_bio+0xd8/0x200 submit_bh_wbc+0x1e8/0x250 __sync_dirty_buffer+0xd0/0x210 ext4_commit_super+0x310/0x420 [ext4] __ext4_error+0xa4/0x1e0 [ext4] __ext4_iget+0x388/0xe10 [ext4] ext4_get_journal_inode+0x40/0x150 [ext4] ext4_calculate_overhead+0x5a8/0x610 [ext4] ext4_fill_super+0x3188/0x3260 [ext4] mount_bdev+0x778/0x8f0 ext4_mount+0x28/0x50 [ext4] mount_fs+0x74/0x230 vfs_kern_mount.part.6+0x6c/0x250 do_mount+0x2fc/0x1280 sys_mount+0x158/0x180 system_call+0x5c/0x70 EXT4-fs (pmem1p2): no journal found EXT4-fs (pmem1p2): can't get journal size EXT4-fs (pmem1p2): mounted filesystem without journal. Opts: dax,norecovery Fixes: 3c816de ("ext4: use journal inode to determine journal overhead") Reported-by: Harish Sriram <harish@linux.ibm.com> Signed-off-by: Ritesh Harjani <riteshh@linux.ibm.com> Reviewed-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20200316093038.25485-1-riteshh@linux.ibm.com Signed-off-by: Theodore Ts'o <tytso@mit.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
krasCGQ
pushed a commit
that referenced
this issue
May 19, 2020
[ Upstream commit e461bc9f9ab105637b86065d24b0b83f182d477c ] Sed broke on some strings as it used colon as a separator. I made it more robust by using \001, which is legit POSIX AFAIK. E.g. ./config --set-str CONFIG_USBNET_DEVADDR "de:ad:be:ef:00:01" failed with: sed: -e expression #1, char 55: unknown option to `s' Signed-off-by: Jeremie Francois (on alpha) <jeremie.francois@gmail.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
krasCGQ
added a commit
that referenced
this issue
May 19, 2020
CAF's explanation on the error code doesn't give any helpful hint on why this kind of error even happens, hence escalating the debugging. Issue tracker: #1 Signed-off-by: Albert I <kras@raphielgang.org>
krasCGQ
added a commit
that referenced
this issue
May 19, 2020
Both ipa_uc_send_cmd() of v2 and ipa3_uc_send_cmd_64b_param() of v3 already have their own BUG() handler before returning -EFAULT, making these BUG() are kinda pointless. Issue tracker: #1 Signed-off-by: Albert I <kras@raphielgang.org>
krasCGQ
added a commit
that referenced
this issue
May 19, 2020
CAF's explanation on the error code doesn't give any helpful hint on why this kind of error even happens, hence escalating the debugging. Issue tracker: #1 Signed-off-by: Albert I <kras@raphielgang.org>
krasCGQ
added a commit
that referenced
this issue
May 19, 2020
Both ipa_uc_send_cmd() of v2 and ipa3_uc_send_cmd_64b_param() of v3 already have their own BUG() handler before returning -EFAULT, making these BUG() are kinda pointless. Issue tracker: #1 Signed-off-by: Albert I <kras@raphielgang.org>
krasCGQ
added a commit
that referenced
this issue
May 19, 2020
CAF's explanation on the error code doesn't give any helpful hint on why this kind of error even happens, hence escalating the debugging. Issue tracker: #1 Signed-off-by: Albert I <kras@raphielgang.org>
krasCGQ
added a commit
that referenced
this issue
May 19, 2020
Both ipa_uc_send_cmd() of v2 and ipa3_uc_send_cmd_64b_param() of v3 already have their own BUG() handler before returning -EFAULT, making these BUG() are kinda pointless. Issue tracker: #1 Signed-off-by: Albert I <kras@raphielgang.org>
krasCGQ
added a commit
that referenced
this issue
May 19, 2020
CAF's explanation on the error code doesn't give any helpful hint on why this kind of error even happens, hence escalating the debugging. Issue tracker: #1 Signed-off-by: Albert I <kras@raphielgang.org>
krasCGQ
added a commit
that referenced
this issue
May 19, 2020
Both ipa_uc_send_cmd() of v2 and ipa3_uc_send_cmd_64b_param() of v3 already have their own BUG() handler before returning -EFAULT, making these BUG() are kinda pointless. Issue tracker: #1 Signed-off-by: Albert I <kras@raphielgang.org>
krasCGQ
added a commit
that referenced
this issue
May 21, 2020
CAF's explanation on the error code doesn't give any helpful hint on why this kind of error even happens, hence escalating the debugging. Issue tracker: #1 Signed-off-by: Albert I <kras@raphielgang.org>
krasCGQ
added a commit
that referenced
this issue
May 21, 2020
Both ipa_uc_send_cmd() of v2 and ipa3_uc_send_cmd_64b_param() of v3 already have their own BUG() handler before returning -EFAULT, making these BUG() are kinda pointless. Issue tracker: #1 Signed-off-by: Albert I <kras@raphielgang.org>
SH4ND
pushed a commit
to Team-NoobMaster69/kernel_motorola_msm8937
that referenced
this issue
Feb 1, 2023
Both ipa_uc_send_cmd() of v2 and ipa3_uc_send_cmd_64b_param() of v3 already have their own BUG() handler before returning -EFAULT, making these BUG() are kinda pointless. Issue tracker: KudProject/kernel_xiaomi_msm8953-4.9#1 Signed-off-by: Albert I <kras@raphielgang.org>
SH4ND
pushed a commit
to Team-NoobMaster69/kernel_motorola_msm8937
that referenced
this issue
Feb 12, 2023
CAF's explanation on the error code doesn't give any helpful hint on why this kind of error even happens, hence escalating the debugging. Issue tracker: KudProject/kernel_xiaomi_msm8953-4.9#1 Signed-off-by: Albert I <kras@raphielgang.org>
SH4ND
pushed a commit
to Team-NoobMaster69/kernel_motorola_msm8937
that referenced
this issue
Feb 12, 2023
Both ipa_uc_send_cmd() of v2 and ipa3_uc_send_cmd_64b_param() of v3 already have their own BUG() handler before returning -EFAULT, making these BUG() are kinda pointless. Issue tracker: KudProject/kernel_xiaomi_msm8953-4.9#1 Signed-off-by: Albert I <kras@raphielgang.org>
TogoFire
pushed a commit
to Dev-msm8953/kernel_xiaomi_msm8953
that referenced
this issue
Mar 22, 2023
Both ipa_uc_send_cmd() of v2 and ipa3_uc_send_cmd_64b_param() of v3 already have their own BUG() handler before returning -EFAULT, making these BUG() are kinda pointless. Issue tracker: KudProject/kernel_xiaomi_msm8953-4.9#1 Signed-off-by: Albert I <kras@raphielgang.org>
TogoFire
pushed a commit
to Dev-msm8953/kernel_xiaomi_msm8953
that referenced
this issue
Mar 22, 2023
Both ipa_uc_send_cmd() of v2 and ipa3_uc_send_cmd_64b_param() of v3 already have their own BUG() handler before returning -EFAULT, making these BUG() are kinda pointless. Issue tracker: KudProject/kernel_xiaomi_msm8953-4.9#1 Signed-off-by: Albert I <kras@raphielgang.org>
zeta96
pushed a commit
to zeta96/L_soul_santoni_msm4.9
that referenced
this issue
Mar 27, 2023
Both ipa_uc_send_cmd() of v2 and ipa3_uc_send_cmd_64b_param() of v3 already have their own BUG() handler before returning -EFAULT, making these BUG() are kinda pointless. Issue tracker: KudProject/kernel_xiaomi_msm8953-4.9#1 Signed-off-by: Albert I <kras@raphielgang.org>
zeta96
pushed a commit
to zeta96/L_soul_santoni_msm4.9
that referenced
this issue
Mar 28, 2023
Both ipa_uc_send_cmd() of v2 and ipa3_uc_send_cmd_64b_param() of v3 already have their own BUG() handler before returning -EFAULT, making these BUG() are kinda pointless. Issue tracker: KudProject/kernel_xiaomi_msm8953-4.9#1 Signed-off-by: Albert I <kras@raphielgang.org>
zeta96
pushed a commit
to zeta96/L_soul_santoni_msm4.9
that referenced
this issue
Apr 1, 2023
Both ipa_uc_send_cmd() of v2 and ipa3_uc_send_cmd_64b_param() of v3 already have their own BUG() handler before returning -EFAULT, making these BUG() are kinda pointless. Issue tracker: KudProject/kernel_xiaomi_msm8953-4.9#1 Signed-off-by: Albert I <kras@raphielgang.org>
zeta96
pushed a commit
to zeta96/L_soul_santoni_msm4.9
that referenced
this issue
Apr 6, 2023
Both ipa_uc_send_cmd() of v2 and ipa3_uc_send_cmd_64b_param() of v3 already have their own BUG() handler before returning -EFAULT, making these BUG() are kinda pointless. Issue tracker: KudProject/kernel_xiaomi_msm8953-4.9#1 Signed-off-by: Albert I <kras@raphielgang.org>
TogoFire
pushed a commit
to Dev-msm8953/kernel_xiaomi_msm8953
that referenced
this issue
Apr 7, 2023
Both ipa_uc_send_cmd() of v2 and ipa3_uc_send_cmd_64b_param() of v3 already have their own BUG() handler before returning -EFAULT, making these BUG() are kinda pointless. Issue tracker: KudProject/kernel_xiaomi_msm8953-4.9#1 Signed-off-by: Albert I <kras@raphielgang.org>
zeta96
pushed a commit
to zeta96/L_soul_santoni_msm4.9
that referenced
this issue
Apr 7, 2023
Both ipa_uc_send_cmd() of v2 and ipa3_uc_send_cmd_64b_param() of v3 already have their own BUG() handler before returning -EFAULT, making these BUG() are kinda pointless. Issue tracker: KudProject/kernel_xiaomi_msm8953-4.9#1 Signed-off-by: Albert I <kras@raphielgang.org>
TogoFire
pushed a commit
to Dev-msm8953/kernel_xiaomi_msm8953
that referenced
this issue
May 18, 2023
Both ipa_uc_send_cmd() of v2 and ipa3_uc_send_cmd_64b_param() of v3 already have their own BUG() handler before returning -EFAULT, making these BUG() are kinda pointless. Issue tracker: KudProject/kernel_xiaomi_msm8953-4.9#1 Signed-off-by: Albert I <kras@raphielgang.org> Change-Id: Ieb3ffdae6cbbe946c005a6bc8408b5a031cdfe44
TogoFire
pushed a commit
to Dev-msm8953/kernel_xiaomi_msm8953
that referenced
this issue
May 18, 2023
Both ipa_uc_send_cmd() of v2 and ipa3_uc_send_cmd_64b_param() of v3 already have their own BUG() handler before returning -EFAULT, making these BUG() are kinda pointless. Issue tracker: KudProject/kernel_xiaomi_msm8953-4.9#1 Signed-off-by: Albert I <kras@raphielgang.org> Change-Id: Iae235bde809d8a7e958734abdec2032d393d7969
TogoFire
pushed a commit
to Dev-msm8953/kernel_xiaomi_msm8953
that referenced
this issue
May 31, 2023
Both ipa_uc_send_cmd() of v2 and ipa3_uc_send_cmd_64b_param() of v3 already have their own BUG() handler before returning -EFAULT, making these BUG() are kinda pointless. Issue tracker: KudProject/kernel_xiaomi_msm8953-4.9#1 Signed-off-by: Albert I <kras@raphielgang.org> Change-Id: I70fb6ca8acfc41500ed1fbf833f5800bcee54865
TogoFire
pushed a commit
to Dev-msm8953/kernel_xiaomi_msm8953
that referenced
this issue
Jun 2, 2023
Both ipa_uc_send_cmd() of v2 and ipa3_uc_send_cmd_64b_param() of v3 already have their own BUG() handler before returning -EFAULT, making these BUG() are kinda pointless. Issue tracker: KudProject/kernel_xiaomi_msm8953-4.9#1 Signed-off-by: Albert I <kras@raphielgang.org> Change-Id: I6b46989a76530abc21b451e6fdbbc847dfd5fd3a
TogoFire
pushed a commit
to Dev-msm8953/kernel_xiaomi_msm8953
that referenced
this issue
Jun 2, 2023
Both ipa_uc_send_cmd() of v2 and ipa3_uc_send_cmd_64b_param() of v3 already have their own BUG() handler before returning -EFAULT, making these BUG() are kinda pointless. Issue tracker: KudProject/kernel_xiaomi_msm8953-4.9#1 Signed-off-by: Albert I <kras@raphielgang.org> Change-Id: Iaf158e2c78f8ce03a01907fb0edd28fec16d72f8
zeta96
pushed a commit
to zeta96/L_check_msm-4.9
that referenced
this issue
Jun 3, 2023
Both ipa_uc_send_cmd() of v2 and ipa3_uc_send_cmd_64b_param() of v3 already have their own BUG() handler before returning -EFAULT, making these BUG() are kinda pointless. Issue tracker: KudProject/kernel_xiaomi_msm8953-4.9#1 Signed-off-by: Albert I <kras@raphielgang.org>
zeta96
pushed a commit
to zeta96/L_check_msm-4.9
that referenced
this issue
Jun 3, 2023
Both ipa_uc_send_cmd() of v2 and ipa3_uc_send_cmd_64b_param() of v3 already have their own BUG() handler before returning -EFAULT, making these BUG() are kinda pointless. Issue tracker: KudProject/kernel_xiaomi_msm8953-4.9#1 Signed-off-by: Albert I <kras@raphielgang.org>
TogoFire
pushed a commit
to Dev-msm8953/kernel_xiaomi_msm8953
that referenced
this issue
Jun 6, 2023
Both ipa_uc_send_cmd() of v2 and ipa3_uc_send_cmd_64b_param() of v3 already have their own BUG() handler before returning -EFAULT, making these BUG() are kinda pointless. Issue tracker: KudProject/kernel_xiaomi_msm8953-4.9#1 Signed-off-by: Albert I <kras@raphielgang.org> Change-Id: I6c14de1fb8c1e858632a7253f7368f7eafc3075f
TogoFire
pushed a commit
to Dev-msm8953/kernel_xiaomi_msm8953
that referenced
this issue
Aug 23, 2023
Both ipa_uc_send_cmd() of v2 and ipa3_uc_send_cmd_64b_param() of v3 already have their own BUG() handler before returning -EFAULT, making these BUG() are kinda pointless. Issue tracker: KudProject/kernel_xiaomi_msm8953-4.9#1 Signed-off-by: Albert I <kras@raphielgang.org> Change-Id: Ibe2b770af5b1c37211170110afebd7a97751d796
ekkusa
pushed a commit
to Miiyo/android_kernel_sony_sdm845
that referenced
this issue
Sep 3, 2023
Both ipa_uc_send_cmd() of v2 and ipa3_uc_send_cmd_64b_param() of v3 already have their own BUG() handler before returning -EFAULT, making these BUG() are kinda pointless. Issue tracker: KudProject/kernel_xiaomi_msm8953-4.9#1 Signed-off-by: Albert I <kras@raphielgang.org> Change-Id: Ibe2b770af5b1c37211170110afebd7a97751d796
TogoFire
pushed a commit
to Dev-msm8953/kernel_xiaomi_msm8953
that referenced
this issue
Sep 3, 2023
Both ipa_uc_send_cmd() of v2 and ipa3_uc_send_cmd_64b_param() of v3 already have their own BUG() handler before returning -EFAULT, making these BUG() are kinda pointless. Issue tracker: KudProject/kernel_xiaomi_msm8953-4.9#1 Signed-off-by: Albert I <kras@raphielgang.org> Change-Id: Ibe2b770af5b1c37211170110afebd7a97751d796
TogoFire
pushed a commit
to Dev-msm8953/kernel_xiaomi_msm8953
that referenced
this issue
Sep 5, 2023
Both ipa_uc_send_cmd() of v2 and ipa3_uc_send_cmd_64b_param() of v3 already have their own BUG() handler before returning -EFAULT, making these BUG() are kinda pointless. Issue tracker: KudProject/kernel_xiaomi_msm8953-4.9#1 Signed-off-by: Albert I <kras@raphielgang.org> Change-Id: Ia2f5b3424f71dbb92af38d1178cd171cf377ec45
ekkusa
pushed a commit
to Miiyo/android_kernel_sony_sdm845
that referenced
this issue
Sep 15, 2023
Both ipa_uc_send_cmd() of v2 and ipa3_uc_send_cmd_64b_param() of v3 already have their own BUG() handler before returning -EFAULT, making these BUG() are kinda pointless. Issue tracker: KudProject/kernel_xiaomi_msm8953-4.9#1 Signed-off-by: Albert I <kras@raphielgang.org> Change-Id: I300c5904aa71057d1f75ab644ad374b65cff656a
ekkusa
pushed a commit
to Miiyo/android_kernel_sony_sdm845
that referenced
this issue
Sep 30, 2023
Both ipa_uc_send_cmd() of v2 and ipa3_uc_send_cmd_64b_param() of v3 already have their own BUG() handler before returning -EFAULT, making these BUG() are kinda pointless. Issue tracker: KudProject/kernel_xiaomi_msm8953-4.9#1 Signed-off-by: Albert I <kras@raphielgang.org> Change-Id: I300c5904aa71057d1f75ab644ad374b65cff656a
TogoFire
pushed a commit
to Dev-msm8953/kernel_xiaomi_msm8953
that referenced
this issue
Oct 24, 2023
Both ipa_uc_send_cmd() of v2 and ipa3_uc_send_cmd_64b_param() of v3 already have their own BUG() handler before returning -EFAULT, making these BUG() are kinda pointless. Issue tracker: KudProject/kernel_xiaomi_msm8953-4.9#1 Signed-off-by: Albert I <kras@raphielgang.org> Change-Id: I2ca4c8bc2d86e0118c7d3f3f20398028b6af6038
TogoFire
pushed a commit
to Dev-msm8953/kernel_xiaomi_msm8953
that referenced
this issue
Oct 24, 2023
Both ipa_uc_send_cmd() of v2 and ipa3_uc_send_cmd_64b_param() of v3 already have their own BUG() handler before returning -EFAULT, making these BUG() are kinda pointless. Issue tracker: KudProject/kernel_xiaomi_msm8953-4.9#1 Signed-off-by: Albert I <kras@raphielgang.org> Change-Id: Ib587e9de51cfd328225e47c6024c32aa3c43d754
TogoFire
pushed a commit
to Dev-msm8953/kernel_xiaomi_msm8953
that referenced
this issue
Oct 26, 2023
Both ipa_uc_send_cmd() of v2 and ipa3_uc_send_cmd_64b_param() of v3 already have their own BUG() handler before returning -EFAULT, making these BUG() are kinda pointless. Issue tracker: KudProject/kernel_xiaomi_msm8953-4.9#1 Signed-off-by: Albert I <kras@raphielgang.org> Change-Id: Ibca67e359f193e39b353ff86bb562870cfc81e0e
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When rebooting or shutting down, kernel panic occured with IPAv2 uC event handler failing:
The text was updated successfully, but these errors were encountered: