[Kernel-packages] [Bug 1954924] Lspci-vt.txt
apport information ** Attachment added: "Lspci-vt.txt" https://bugs.launchpad.net/bugs/1954924/+attachment/5547805/+files/Lspci-vt.txt -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1954924 Title: Kernel 5.4 - general protection fault SMP NOPTI Status in linux package in Ubuntu: Confirmed Bug description: Setup is comprised of multiple compute nodes in an OpenStack setup, all nodes being connected to a SAN storage through FC. Env specs: Ubuntu-Server 20.04.3 LTS Kernel: 5.4.0-89-generic CPU: AMD EPYC 7H12 At random times we observe the nodes getting locked up, system load is increasing and no actions can be taken, leading to having to reboot the server to recover. There is no pattern in this and stress testing the servers does not reproduce this. Log snippet: [1673239.174269] general protection fault: [#1] SMP NOPTI [1673239.183446] CPU: 97 PID: 1224718 Comm: cadvisor Not tainted 5.4.0-89-generic #100-Ubuntu [1673239.192622] Hardware name: Dell Inc. PowerEdge R7525/0590KW, BIOS 2.3.6 07/06/2021 [1673239.203336] RIP: 0010:string_nocheck+0x38/0x60 [1673239.212811] Code: 66 85 c0 74 3e 83 e8 01 4c 8d 5c 07 01 31 c0 eb 19 49 39 fa 76 03 44 88 07 48 83 c7 01 41 8d 71 01 48 83 c0 01 4c 39 df 74 0f <44> 0f b6 04 02 41 89 c1 89 c6 45 84 c0 75 d8 4c 89 d2 e8 11 ff ff [1673239.232904] RSP: 0018:a25f3199fba0 EFLAGS: 00010046 [1673239.244331] RAX: RBX: a25f3199fc58 RCX: 0a00ff04 [1673239.256551] RDX: d969688991a5a25c RSI: 8de32b56 RDI: 8de32b5400c6 [1673239.269226] RBP: a25f3199fba0 R08: 9c445a00 R09: 000a [1673239.279111] R10: 8de32b56 R11: 8de42b5400c5 R12: 8de32b56 [1673239.289855] R13: d969688991a5a25c R14: 0a00ff04 R15: 8de32b5400c6 [1673239.299447] FS: 7f925a7fc700() GS:8df87f44() knlGS: [1673239.308670] CS: 0010 DS: ES: CR0: 80050033 [1673239.317988] CR2: 7f9012efcfb8 CR3: 007fa1abe000 CR4: 00340ee0 [1673239.327377] Call Trace: [1673239.337796] string+0x4a/0x60 [1673239.347948] vsnprintf+0x26f/0x4e0 [1673239.356909] seq_vprintf+0x35/0x50 [1673239.365819] seq_printf+0x53/0x70 [1673239.374919] __blkg_prfill_rwstat+0x5d/0xb0 [1673239.383362] blkg_prfill_rwstat_field+0x97/0xc0 [1673239.391580] blkcg_print_blkgs+0xba/0xf0 [1673239.399891] ? blkg_prfill_rwstat+0xc0/0xc0 [1673239.408266] blkg_print_stat_bytes+0x45/0x50 [1673239.416378] cgroup_seqfile_show+0x56/0xc0 [1673239.424336] kernfs_seq_show+0x27/0x30 [1673239.432208] seq_read+0xdc/0x490 [1673239.440065] kernfs_fop_read+0x35/0x1b0 [1673239.448107] __vfs_read+0x1b/0x40 [1673239.456329] vfs_read+0xab/0x160 [1673239.465529] ksys_read+0x67/0xe0 [1673239.473872] __x64_sys_read+0x1a/0x20 [1673239.481269] do_syscall_64+0x57/0x190 [1673239.488798] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [1673239.497445] RIP: 0033:0x4cc910 [1673239.504694] Code: 8b 7c 24 10 48 8b 74 24 18 48 8b 54 24 20 49 c7 c2 00 00 00 00 49 c7 c0 00 00 00 00 49 c7 c1 00 00 00 00 48 8b 44 24 08 0f 05 <48> 3d 01 f0 ff ff 76 20 48 c7 44 24 28 ff ff ff ff 48 c7 44 24 30 [1673239.519380] RSP: 002b:00c01dd1e7a0 EFLAGS: 0202 ORIG_RAX: [1673239.526527] RAX: ffda RBX: 00c46f00 RCX: 004cc910 [1673239.534890] RDX: 1000 RSI: 00c00c2cd000 RDI: 000e [1673239.542958] RBP: 00c01dd1e7f0 R08: R09: [1673239.549915] R10: R11: 0202 R12: [1673239.558350] R13: 0002 R14: 0001 R15: 0002 [1673239.565178] Modules linked in: veth vhost_net nf_conntrack_netlink vhost tap dm_queue_length cls_u32 sch_cbq xsk_diag udp_diag raw_diag unix_diag af_packet_diag tcp_diag inet_diag netlink_diag ebtable_filter ebtables sch_ingress geneve ip6_udp_tunnel udp_tunnel nfnetlink_cttimeout nfnetlink aufs overlay rpcsec_gss_krb5 auth_rpcgss nfsv4 nfs lockd grace fscache bonding ip6t_REJECT nf_reject_ipv6 ip6table_filter ip6_tables ipt_REJECT nf_reject_ipv4 xt_tcpudp xt_comment xt_state xt_conntrack iptable_filter bpfilter nls_iso8859_1 scsi_dh_rdac scsi_dh_emc scsi_dh_alua ipmi_ssif amd64_edac_mod edac_mce_amd dell_smbios kvm_amd dcdbas kvm wmi_bmof dell_wmi_descriptor ccp k10temp ipmi_si ipmi_devintf ipmi_msghandler acpi_power_meter mac_hid sch_fq_codel tcp_bbr openvswitch nsh nf_conncount nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 msr dm_multipath br_netfilter bridge stp llc sunrpc ip_tables x_tables autofs4 btrfs zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq [1673239.565265] async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear mlx5_ib lpfc drm_
[Kernel-packages] [Bug 1954924] ProcInterrupts.txt
apport information ** Attachment added: "ProcInterrupts.txt" https://bugs.launchpad.net/bugs/1954924/+attachment/5547811/+files/ProcInterrupts.txt -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1954924 Title: Kernel 5.4 - general protection fault SMP NOPTI Status in linux package in Ubuntu: Confirmed Bug description: Setup is comprised of multiple compute nodes in an OpenStack setup, all nodes being connected to a SAN storage through FC. Env specs: Ubuntu-Server 20.04.3 LTS Kernel: 5.4.0-89-generic CPU: AMD EPYC 7H12 At random times we observe the nodes getting locked up, system load is increasing and no actions can be taken, leading to having to reboot the server to recover. There is no pattern in this and stress testing the servers does not reproduce this. Log snippet: [1673239.174269] general protection fault: [#1] SMP NOPTI [1673239.183446] CPU: 97 PID: 1224718 Comm: cadvisor Not tainted 5.4.0-89-generic #100-Ubuntu [1673239.192622] Hardware name: Dell Inc. PowerEdge R7525/0590KW, BIOS 2.3.6 07/06/2021 [1673239.203336] RIP: 0010:string_nocheck+0x38/0x60 [1673239.212811] Code: 66 85 c0 74 3e 83 e8 01 4c 8d 5c 07 01 31 c0 eb 19 49 39 fa 76 03 44 88 07 48 83 c7 01 41 8d 71 01 48 83 c0 01 4c 39 df 74 0f <44> 0f b6 04 02 41 89 c1 89 c6 45 84 c0 75 d8 4c 89 d2 e8 11 ff ff [1673239.232904] RSP: 0018:a25f3199fba0 EFLAGS: 00010046 [1673239.244331] RAX: RBX: a25f3199fc58 RCX: 0a00ff04 [1673239.256551] RDX: d969688991a5a25c RSI: 8de32b56 RDI: 8de32b5400c6 [1673239.269226] RBP: a25f3199fba0 R08: 9c445a00 R09: 000a [1673239.279111] R10: 8de32b56 R11: 8de42b5400c5 R12: 8de32b56 [1673239.289855] R13: d969688991a5a25c R14: 0a00ff04 R15: 8de32b5400c6 [1673239.299447] FS: 7f925a7fc700() GS:8df87f44() knlGS: [1673239.308670] CS: 0010 DS: ES: CR0: 80050033 [1673239.317988] CR2: 7f9012efcfb8 CR3: 007fa1abe000 CR4: 00340ee0 [1673239.327377] Call Trace: [1673239.337796] string+0x4a/0x60 [1673239.347948] vsnprintf+0x26f/0x4e0 [1673239.356909] seq_vprintf+0x35/0x50 [1673239.365819] seq_printf+0x53/0x70 [1673239.374919] __blkg_prfill_rwstat+0x5d/0xb0 [1673239.383362] blkg_prfill_rwstat_field+0x97/0xc0 [1673239.391580] blkcg_print_blkgs+0xba/0xf0 [1673239.399891] ? blkg_prfill_rwstat+0xc0/0xc0 [1673239.408266] blkg_print_stat_bytes+0x45/0x50 [1673239.416378] cgroup_seqfile_show+0x56/0xc0 [1673239.424336] kernfs_seq_show+0x27/0x30 [1673239.432208] seq_read+0xdc/0x490 [1673239.440065] kernfs_fop_read+0x35/0x1b0 [1673239.448107] __vfs_read+0x1b/0x40 [1673239.456329] vfs_read+0xab/0x160 [1673239.465529] ksys_read+0x67/0xe0 [1673239.473872] __x64_sys_read+0x1a/0x20 [1673239.481269] do_syscall_64+0x57/0x190 [1673239.488798] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [1673239.497445] RIP: 0033:0x4cc910 [1673239.504694] Code: 8b 7c 24 10 48 8b 74 24 18 48 8b 54 24 20 49 c7 c2 00 00 00 00 49 c7 c0 00 00 00 00 49 c7 c1 00 00 00 00 48 8b 44 24 08 0f 05 <48> 3d 01 f0 ff ff 76 20 48 c7 44 24 28 ff ff ff ff 48 c7 44 24 30 [1673239.519380] RSP: 002b:00c01dd1e7a0 EFLAGS: 0202 ORIG_RAX: [1673239.526527] RAX: ffda RBX: 00c46f00 RCX: 004cc910 [1673239.534890] RDX: 1000 RSI: 00c00c2cd000 RDI: 000e [1673239.542958] RBP: 00c01dd1e7f0 R08: R09: [1673239.549915] R10: R11: 0202 R12: [1673239.558350] R13: 0002 R14: 0001 R15: 0002 [1673239.565178] Modules linked in: veth vhost_net nf_conntrack_netlink vhost tap dm_queue_length cls_u32 sch_cbq xsk_diag udp_diag raw_diag unix_diag af_packet_diag tcp_diag inet_diag netlink_diag ebtable_filter ebtables sch_ingress geneve ip6_udp_tunnel udp_tunnel nfnetlink_cttimeout nfnetlink aufs overlay rpcsec_gss_krb5 auth_rpcgss nfsv4 nfs lockd grace fscache bonding ip6t_REJECT nf_reject_ipv6 ip6table_filter ip6_tables ipt_REJECT nf_reject_ipv4 xt_tcpudp xt_comment xt_state xt_conntrack iptable_filter bpfilter nls_iso8859_1 scsi_dh_rdac scsi_dh_emc scsi_dh_alua ipmi_ssif amd64_edac_mod edac_mce_amd dell_smbios kvm_amd dcdbas kvm wmi_bmof dell_wmi_descriptor ccp k10temp ipmi_si ipmi_devintf ipmi_msghandler acpi_power_meter mac_hid sch_fq_codel tcp_bbr openvswitch nsh nf_conncount nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 msr dm_multipath br_netfilter bridge stp llc sunrpc ip_tables x_tables autofs4 btrfs zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq [1673239.565265] async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear mlx5_
[Kernel-packages] [Bug 1954924] Lsusb-v.txt
apport information ** Attachment added: "Lsusb-v.txt" https://bugs.launchpad.net/bugs/1954924/+attachment/5547808/+files/Lsusb-v.txt -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1954924 Title: Kernel 5.4 - general protection fault SMP NOPTI Status in linux package in Ubuntu: Confirmed Bug description: Setup is comprised of multiple compute nodes in an OpenStack setup, all nodes being connected to a SAN storage through FC. Env specs: Ubuntu-Server 20.04.3 LTS Kernel: 5.4.0-89-generic CPU: AMD EPYC 7H12 At random times we observe the nodes getting locked up, system load is increasing and no actions can be taken, leading to having to reboot the server to recover. There is no pattern in this and stress testing the servers does not reproduce this. Log snippet: [1673239.174269] general protection fault: [#1] SMP NOPTI [1673239.183446] CPU: 97 PID: 1224718 Comm: cadvisor Not tainted 5.4.0-89-generic #100-Ubuntu [1673239.192622] Hardware name: Dell Inc. PowerEdge R7525/0590KW, BIOS 2.3.6 07/06/2021 [1673239.203336] RIP: 0010:string_nocheck+0x38/0x60 [1673239.212811] Code: 66 85 c0 74 3e 83 e8 01 4c 8d 5c 07 01 31 c0 eb 19 49 39 fa 76 03 44 88 07 48 83 c7 01 41 8d 71 01 48 83 c0 01 4c 39 df 74 0f <44> 0f b6 04 02 41 89 c1 89 c6 45 84 c0 75 d8 4c 89 d2 e8 11 ff ff [1673239.232904] RSP: 0018:a25f3199fba0 EFLAGS: 00010046 [1673239.244331] RAX: RBX: a25f3199fc58 RCX: 0a00ff04 [1673239.256551] RDX: d969688991a5a25c RSI: 8de32b56 RDI: 8de32b5400c6 [1673239.269226] RBP: a25f3199fba0 R08: 9c445a00 R09: 000a [1673239.279111] R10: 8de32b56 R11: 8de42b5400c5 R12: 8de32b56 [1673239.289855] R13: d969688991a5a25c R14: 0a00ff04 R15: 8de32b5400c6 [1673239.299447] FS: 7f925a7fc700() GS:8df87f44() knlGS: [1673239.308670] CS: 0010 DS: ES: CR0: 80050033 [1673239.317988] CR2: 7f9012efcfb8 CR3: 007fa1abe000 CR4: 00340ee0 [1673239.327377] Call Trace: [1673239.337796] string+0x4a/0x60 [1673239.347948] vsnprintf+0x26f/0x4e0 [1673239.356909] seq_vprintf+0x35/0x50 [1673239.365819] seq_printf+0x53/0x70 [1673239.374919] __blkg_prfill_rwstat+0x5d/0xb0 [1673239.383362] blkg_prfill_rwstat_field+0x97/0xc0 [1673239.391580] blkcg_print_blkgs+0xba/0xf0 [1673239.399891] ? blkg_prfill_rwstat+0xc0/0xc0 [1673239.408266] blkg_print_stat_bytes+0x45/0x50 [1673239.416378] cgroup_seqfile_show+0x56/0xc0 [1673239.424336] kernfs_seq_show+0x27/0x30 [1673239.432208] seq_read+0xdc/0x490 [1673239.440065] kernfs_fop_read+0x35/0x1b0 [1673239.448107] __vfs_read+0x1b/0x40 [1673239.456329] vfs_read+0xab/0x160 [1673239.465529] ksys_read+0x67/0xe0 [1673239.473872] __x64_sys_read+0x1a/0x20 [1673239.481269] do_syscall_64+0x57/0x190 [1673239.488798] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [1673239.497445] RIP: 0033:0x4cc910 [1673239.504694] Code: 8b 7c 24 10 48 8b 74 24 18 48 8b 54 24 20 49 c7 c2 00 00 00 00 49 c7 c0 00 00 00 00 49 c7 c1 00 00 00 00 48 8b 44 24 08 0f 05 <48> 3d 01 f0 ff ff 76 20 48 c7 44 24 28 ff ff ff ff 48 c7 44 24 30 [1673239.519380] RSP: 002b:00c01dd1e7a0 EFLAGS: 0202 ORIG_RAX: [1673239.526527] RAX: ffda RBX: 00c46f00 RCX: 004cc910 [1673239.534890] RDX: 1000 RSI: 00c00c2cd000 RDI: 000e [1673239.542958] RBP: 00c01dd1e7f0 R08: R09: [1673239.549915] R10: R11: 0202 R12: [1673239.558350] R13: 0002 R14: 0001 R15: 0002 [1673239.565178] Modules linked in: veth vhost_net nf_conntrack_netlink vhost tap dm_queue_length cls_u32 sch_cbq xsk_diag udp_diag raw_diag unix_diag af_packet_diag tcp_diag inet_diag netlink_diag ebtable_filter ebtables sch_ingress geneve ip6_udp_tunnel udp_tunnel nfnetlink_cttimeout nfnetlink aufs overlay rpcsec_gss_krb5 auth_rpcgss nfsv4 nfs lockd grace fscache bonding ip6t_REJECT nf_reject_ipv6 ip6table_filter ip6_tables ipt_REJECT nf_reject_ipv4 xt_tcpudp xt_comment xt_state xt_conntrack iptable_filter bpfilter nls_iso8859_1 scsi_dh_rdac scsi_dh_emc scsi_dh_alua ipmi_ssif amd64_edac_mod edac_mce_amd dell_smbios kvm_amd dcdbas kvm wmi_bmof dell_wmi_descriptor ccp k10temp ipmi_si ipmi_devintf ipmi_msghandler acpi_power_meter mac_hid sch_fq_codel tcp_bbr openvswitch nsh nf_conncount nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 msr dm_multipath br_netfilter bridge stp llc sunrpc ip_tables x_tables autofs4 btrfs zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq [1673239.565265] async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear mlx5_ib lpfc drm_vr
[Kernel-packages] [Bug 1954924] acpidump.txt
apport information ** Attachment added: "acpidump.txt" https://bugs.launchpad.net/bugs/1954924/+attachment/5547815/+files/acpidump.txt ** Description changed: Setup is comprised of multiple compute nodes in an OpenStack setup, all nodes being connected to a SAN storage through FC. + Env specs: + Ubuntu-Server 20.04.3 LTS + Kernel: 5.4.0-89-generic + CPU: AMD EPYC 7H12 + At random times we observe the nodes getting locked up, system load is increasing and no actions can be taken, leading to having to reboot the server to recover. There is no pattern in this and stress testing the servers does not reproduce this. - Log snippet: [1673239.174269] general protection fault: [#1] SMP NOPTI [1673239.183446] CPU: 97 PID: 1224718 Comm: cadvisor Not tainted 5.4.0-89-generic #100-Ubuntu [1673239.192622] Hardware name: Dell Inc. PowerEdge R7525/0590KW, BIOS 2.3.6 07/06/2021 [1673239.203336] RIP: 0010:string_nocheck+0x38/0x60 [1673239.212811] Code: 66 85 c0 74 3e 83 e8 01 4c 8d 5c 07 01 31 c0 eb 19 49 39 fa 76 03 44 88 07 48 83 c7 01 41 8d 71 01 48 83 c0 01 4c 39 df 74 0f <44> 0f b6 04 02 41 89 c1 89 c6 45 84 c0 75 d8 4c 89 d2 e8 11 ff ff [1673239.232904] RSP: 0018:a25f3199fba0 EFLAGS: 00010046 [1673239.244331] RAX: RBX: a25f3199fc58 RCX: 0a00ff04 [1673239.256551] RDX: d969688991a5a25c RSI: 8de32b56 RDI: 8de32b5400c6 [1673239.269226] RBP: a25f3199fba0 R08: 9c445a00 R09: 000a [1673239.279111] R10: 8de32b56 R11: 8de42b5400c5 R12: 8de32b56 [1673239.289855] R13: d969688991a5a25c R14: 0a00ff04 R15: 8de32b5400c6 [1673239.299447] FS: 7f925a7fc700() GS:8df87f44() knlGS: [1673239.308670] CS: 0010 DS: ES: CR0: 80050033 [1673239.317988] CR2: 7f9012efcfb8 CR3: 007fa1abe000 CR4: 00340ee0 [1673239.327377] Call Trace: [1673239.337796] string+0x4a/0x60 [1673239.347948] vsnprintf+0x26f/0x4e0 [1673239.356909] seq_vprintf+0x35/0x50 [1673239.365819] seq_printf+0x53/0x70 [1673239.374919] __blkg_prfill_rwstat+0x5d/0xb0 [1673239.383362] blkg_prfill_rwstat_field+0x97/0xc0 [1673239.391580] blkcg_print_blkgs+0xba/0xf0 [1673239.399891] ? blkg_prfill_rwstat+0xc0/0xc0 [1673239.408266] blkg_print_stat_bytes+0x45/0x50 [1673239.416378] cgroup_seqfile_show+0x56/0xc0 [1673239.424336] kernfs_seq_show+0x27/0x30 [1673239.432208] seq_read+0xdc/0x490 [1673239.440065] kernfs_fop_read+0x35/0x1b0 [1673239.448107] __vfs_read+0x1b/0x40 [1673239.456329] vfs_read+0xab/0x160 [1673239.465529] ksys_read+0x67/0xe0 [1673239.473872] __x64_sys_read+0x1a/0x20 [1673239.481269] do_syscall_64+0x57/0x190 [1673239.488798] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [1673239.497445] RIP: 0033:0x4cc910 [1673239.504694] Code: 8b 7c 24 10 48 8b 74 24 18 48 8b 54 24 20 49 c7 c2 00 00 00 00 49 c7 c0 00 00 00 00 49 c7 c1 00 00 00 00 48 8b 44 24 08 0f 05 <48> 3d 01 f0 ff ff 76 20 48 c7 44 24 28 ff ff ff ff 48 c7 44 24 30 [1673239.519380] RSP: 002b:00c01dd1e7a0 EFLAGS: 0202 ORIG_RAX: [1673239.526527] RAX: ffda RBX: 00c46f00 RCX: 004cc910 [1673239.534890] RDX: 1000 RSI: 00c00c2cd000 RDI: 000e [1673239.542958] RBP: 00c01dd1e7f0 R08: R09: [1673239.549915] R10: R11: 0202 R12: [1673239.558350] R13: 0002 R14: 0001 R15: 0002 [1673239.565178] Modules linked in: veth vhost_net nf_conntrack_netlink vhost tap dm_queue_length cls_u32 sch_cbq xsk_diag udp_diag raw_diag unix_diag af_packet_diag tcp_diag inet_diag netlink_diag ebtable_filter ebtables sch_ingress geneve ip6_udp_tunnel udp_tunnel nfnetlink_cttimeout nfnetlink aufs overlay rpcsec_gss_krb5 auth_rpcgss nfsv4 nfs lockd grace fscache bonding ip6t_REJECT nf_reject_ipv6 ip6table_filter ip6_tables ipt_REJECT nf_reject_ipv4 xt_tcpudp xt_comment xt_state xt_conntrack iptable_filter bpfilter nls_iso8859_1 scsi_dh_rdac scsi_dh_emc scsi_dh_alua ipmi_ssif amd64_edac_mod edac_mce_amd dell_smbios kvm_amd dcdbas kvm wmi_bmof dell_wmi_descriptor ccp k10temp ipmi_si ipmi_devintf ipmi_msghandler acpi_power_meter mac_hid sch_fq_codel tcp_bbr openvswitch nsh nf_conncount nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 msr dm_multipath br_netfilter bridge stp llc sunrpc ip_tables x_tables autofs4 btrfs zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq [1673239.565265] async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear mlx5_ib lpfc drm_vram_helper i2c_algo_bit ib_uverbs nvmet_fc crct10dif_pclmul ib_core crc32_pclmul ttm ghash_clmulni_intel drm_kms_helper aesni_intel nvmet syscopyarea crypto_simd sysfillrect cryptd nvme_fc glue_helper sysimgblt nvme_fabrics ahci fb_sys_fops mlx5_core
[Kernel-packages] [Bug 1954924] UdevDb.txt
apport information ** Attachment added: "UdevDb.txt" https://bugs.launchpad.net/bugs/1954924/+attachment/5547813/+files/UdevDb.txt -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1954924 Title: Kernel 5.4 - general protection fault SMP NOPTI Status in linux package in Ubuntu: Confirmed Bug description: Setup is comprised of multiple compute nodes in an OpenStack setup, all nodes being connected to a SAN storage through FC. Env specs: Ubuntu-Server 20.04.3 LTS Kernel: 5.4.0-89-generic CPU: AMD EPYC 7H12 At random times we observe the nodes getting locked up, system load is increasing and no actions can be taken, leading to having to reboot the server to recover. There is no pattern in this and stress testing the servers does not reproduce this. Log snippet: [1673239.174269] general protection fault: [#1] SMP NOPTI [1673239.183446] CPU: 97 PID: 1224718 Comm: cadvisor Not tainted 5.4.0-89-generic #100-Ubuntu [1673239.192622] Hardware name: Dell Inc. PowerEdge R7525/0590KW, BIOS 2.3.6 07/06/2021 [1673239.203336] RIP: 0010:string_nocheck+0x38/0x60 [1673239.212811] Code: 66 85 c0 74 3e 83 e8 01 4c 8d 5c 07 01 31 c0 eb 19 49 39 fa 76 03 44 88 07 48 83 c7 01 41 8d 71 01 48 83 c0 01 4c 39 df 74 0f <44> 0f b6 04 02 41 89 c1 89 c6 45 84 c0 75 d8 4c 89 d2 e8 11 ff ff [1673239.232904] RSP: 0018:a25f3199fba0 EFLAGS: 00010046 [1673239.244331] RAX: RBX: a25f3199fc58 RCX: 0a00ff04 [1673239.256551] RDX: d969688991a5a25c RSI: 8de32b56 RDI: 8de32b5400c6 [1673239.269226] RBP: a25f3199fba0 R08: 9c445a00 R09: 000a [1673239.279111] R10: 8de32b56 R11: 8de42b5400c5 R12: 8de32b56 [1673239.289855] R13: d969688991a5a25c R14: 0a00ff04 R15: 8de32b5400c6 [1673239.299447] FS: 7f925a7fc700() GS:8df87f44() knlGS: [1673239.308670] CS: 0010 DS: ES: CR0: 80050033 [1673239.317988] CR2: 7f9012efcfb8 CR3: 007fa1abe000 CR4: 00340ee0 [1673239.327377] Call Trace: [1673239.337796] string+0x4a/0x60 [1673239.347948] vsnprintf+0x26f/0x4e0 [1673239.356909] seq_vprintf+0x35/0x50 [1673239.365819] seq_printf+0x53/0x70 [1673239.374919] __blkg_prfill_rwstat+0x5d/0xb0 [1673239.383362] blkg_prfill_rwstat_field+0x97/0xc0 [1673239.391580] blkcg_print_blkgs+0xba/0xf0 [1673239.399891] ? blkg_prfill_rwstat+0xc0/0xc0 [1673239.408266] blkg_print_stat_bytes+0x45/0x50 [1673239.416378] cgroup_seqfile_show+0x56/0xc0 [1673239.424336] kernfs_seq_show+0x27/0x30 [1673239.432208] seq_read+0xdc/0x490 [1673239.440065] kernfs_fop_read+0x35/0x1b0 [1673239.448107] __vfs_read+0x1b/0x40 [1673239.456329] vfs_read+0xab/0x160 [1673239.465529] ksys_read+0x67/0xe0 [1673239.473872] __x64_sys_read+0x1a/0x20 [1673239.481269] do_syscall_64+0x57/0x190 [1673239.488798] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [1673239.497445] RIP: 0033:0x4cc910 [1673239.504694] Code: 8b 7c 24 10 48 8b 74 24 18 48 8b 54 24 20 49 c7 c2 00 00 00 00 49 c7 c0 00 00 00 00 49 c7 c1 00 00 00 00 48 8b 44 24 08 0f 05 <48> 3d 01 f0 ff ff 76 20 48 c7 44 24 28 ff ff ff ff 48 c7 44 24 30 [1673239.519380] RSP: 002b:00c01dd1e7a0 EFLAGS: 0202 ORIG_RAX: [1673239.526527] RAX: ffda RBX: 00c46f00 RCX: 004cc910 [1673239.534890] RDX: 1000 RSI: 00c00c2cd000 RDI: 000e [1673239.542958] RBP: 00c01dd1e7f0 R08: R09: [1673239.549915] R10: R11: 0202 R12: [1673239.558350] R13: 0002 R14: 0001 R15: 0002 [1673239.565178] Modules linked in: veth vhost_net nf_conntrack_netlink vhost tap dm_queue_length cls_u32 sch_cbq xsk_diag udp_diag raw_diag unix_diag af_packet_diag tcp_diag inet_diag netlink_diag ebtable_filter ebtables sch_ingress geneve ip6_udp_tunnel udp_tunnel nfnetlink_cttimeout nfnetlink aufs overlay rpcsec_gss_krb5 auth_rpcgss nfsv4 nfs lockd grace fscache bonding ip6t_REJECT nf_reject_ipv6 ip6table_filter ip6_tables ipt_REJECT nf_reject_ipv4 xt_tcpudp xt_comment xt_state xt_conntrack iptable_filter bpfilter nls_iso8859_1 scsi_dh_rdac scsi_dh_emc scsi_dh_alua ipmi_ssif amd64_edac_mod edac_mce_amd dell_smbios kvm_amd dcdbas kvm wmi_bmof dell_wmi_descriptor ccp k10temp ipmi_si ipmi_devintf ipmi_msghandler acpi_power_meter mac_hid sch_fq_codel tcp_bbr openvswitch nsh nf_conncount nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 msr dm_multipath br_netfilter bridge stp llc sunrpc ip_tables x_tables autofs4 btrfs zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq [1673239.565265] async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear mlx5_ib lpfc drm_vram_
[Kernel-packages] [Bug 1954924] ProcModules.txt
apport information ** Attachment added: "ProcModules.txt" https://bugs.launchpad.net/bugs/1954924/+attachment/5547812/+files/ProcModules.txt -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1954924 Title: Kernel 5.4 - general protection fault SMP NOPTI Status in linux package in Ubuntu: Confirmed Bug description: Setup is comprised of multiple compute nodes in an OpenStack setup, all nodes being connected to a SAN storage through FC. Env specs: Ubuntu-Server 20.04.3 LTS Kernel: 5.4.0-89-generic CPU: AMD EPYC 7H12 At random times we observe the nodes getting locked up, system load is increasing and no actions can be taken, leading to having to reboot the server to recover. There is no pattern in this and stress testing the servers does not reproduce this. Log snippet: [1673239.174269] general protection fault: [#1] SMP NOPTI [1673239.183446] CPU: 97 PID: 1224718 Comm: cadvisor Not tainted 5.4.0-89-generic #100-Ubuntu [1673239.192622] Hardware name: Dell Inc. PowerEdge R7525/0590KW, BIOS 2.3.6 07/06/2021 [1673239.203336] RIP: 0010:string_nocheck+0x38/0x60 [1673239.212811] Code: 66 85 c0 74 3e 83 e8 01 4c 8d 5c 07 01 31 c0 eb 19 49 39 fa 76 03 44 88 07 48 83 c7 01 41 8d 71 01 48 83 c0 01 4c 39 df 74 0f <44> 0f b6 04 02 41 89 c1 89 c6 45 84 c0 75 d8 4c 89 d2 e8 11 ff ff [1673239.232904] RSP: 0018:a25f3199fba0 EFLAGS: 00010046 [1673239.244331] RAX: RBX: a25f3199fc58 RCX: 0a00ff04 [1673239.256551] RDX: d969688991a5a25c RSI: 8de32b56 RDI: 8de32b5400c6 [1673239.269226] RBP: a25f3199fba0 R08: 9c445a00 R09: 000a [1673239.279111] R10: 8de32b56 R11: 8de42b5400c5 R12: 8de32b56 [1673239.289855] R13: d969688991a5a25c R14: 0a00ff04 R15: 8de32b5400c6 [1673239.299447] FS: 7f925a7fc700() GS:8df87f44() knlGS: [1673239.308670] CS: 0010 DS: ES: CR0: 80050033 [1673239.317988] CR2: 7f9012efcfb8 CR3: 007fa1abe000 CR4: 00340ee0 [1673239.327377] Call Trace: [1673239.337796] string+0x4a/0x60 [1673239.347948] vsnprintf+0x26f/0x4e0 [1673239.356909] seq_vprintf+0x35/0x50 [1673239.365819] seq_printf+0x53/0x70 [1673239.374919] __blkg_prfill_rwstat+0x5d/0xb0 [1673239.383362] blkg_prfill_rwstat_field+0x97/0xc0 [1673239.391580] blkcg_print_blkgs+0xba/0xf0 [1673239.399891] ? blkg_prfill_rwstat+0xc0/0xc0 [1673239.408266] blkg_print_stat_bytes+0x45/0x50 [1673239.416378] cgroup_seqfile_show+0x56/0xc0 [1673239.424336] kernfs_seq_show+0x27/0x30 [1673239.432208] seq_read+0xdc/0x490 [1673239.440065] kernfs_fop_read+0x35/0x1b0 [1673239.448107] __vfs_read+0x1b/0x40 [1673239.456329] vfs_read+0xab/0x160 [1673239.465529] ksys_read+0x67/0xe0 [1673239.473872] __x64_sys_read+0x1a/0x20 [1673239.481269] do_syscall_64+0x57/0x190 [1673239.488798] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [1673239.497445] RIP: 0033:0x4cc910 [1673239.504694] Code: 8b 7c 24 10 48 8b 74 24 18 48 8b 54 24 20 49 c7 c2 00 00 00 00 49 c7 c0 00 00 00 00 49 c7 c1 00 00 00 00 48 8b 44 24 08 0f 05 <48> 3d 01 f0 ff ff 76 20 48 c7 44 24 28 ff ff ff ff 48 c7 44 24 30 [1673239.519380] RSP: 002b:00c01dd1e7a0 EFLAGS: 0202 ORIG_RAX: [1673239.526527] RAX: ffda RBX: 00c46f00 RCX: 004cc910 [1673239.534890] RDX: 1000 RSI: 00c00c2cd000 RDI: 000e [1673239.542958] RBP: 00c01dd1e7f0 R08: R09: [1673239.549915] R10: R11: 0202 R12: [1673239.558350] R13: 0002 R14: 0001 R15: 0002 [1673239.565178] Modules linked in: veth vhost_net nf_conntrack_netlink vhost tap dm_queue_length cls_u32 sch_cbq xsk_diag udp_diag raw_diag unix_diag af_packet_diag tcp_diag inet_diag netlink_diag ebtable_filter ebtables sch_ingress geneve ip6_udp_tunnel udp_tunnel nfnetlink_cttimeout nfnetlink aufs overlay rpcsec_gss_krb5 auth_rpcgss nfsv4 nfs lockd grace fscache bonding ip6t_REJECT nf_reject_ipv6 ip6table_filter ip6_tables ipt_REJECT nf_reject_ipv4 xt_tcpudp xt_comment xt_state xt_conntrack iptable_filter bpfilter nls_iso8859_1 scsi_dh_rdac scsi_dh_emc scsi_dh_alua ipmi_ssif amd64_edac_mod edac_mce_amd dell_smbios kvm_amd dcdbas kvm wmi_bmof dell_wmi_descriptor ccp k10temp ipmi_si ipmi_devintf ipmi_msghandler acpi_power_meter mac_hid sch_fq_codel tcp_bbr openvswitch nsh nf_conncount nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 msr dm_multipath br_netfilter bridge stp llc sunrpc ip_tables x_tables autofs4 btrfs zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq [1673239.565265] async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear mlx5_ib lpf
[Kernel-packages] [Bug 1954924] WifiSyslog.txt
apport information ** Attachment added: "WifiSyslog.txt" https://bugs.launchpad.net/bugs/1954924/+attachment/5547814/+files/WifiSyslog.txt -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1954924 Title: Kernel 5.4 - general protection fault SMP NOPTI Status in linux package in Ubuntu: Confirmed Bug description: Setup is comprised of multiple compute nodes in an OpenStack setup, all nodes being connected to a SAN storage through FC. Env specs: Ubuntu-Server 20.04.3 LTS Kernel: 5.4.0-89-generic CPU: AMD EPYC 7H12 At random times we observe the nodes getting locked up, system load is increasing and no actions can be taken, leading to having to reboot the server to recover. There is no pattern in this and stress testing the servers does not reproduce this. Log snippet: [1673239.174269] general protection fault: [#1] SMP NOPTI [1673239.183446] CPU: 97 PID: 1224718 Comm: cadvisor Not tainted 5.4.0-89-generic #100-Ubuntu [1673239.192622] Hardware name: Dell Inc. PowerEdge R7525/0590KW, BIOS 2.3.6 07/06/2021 [1673239.203336] RIP: 0010:string_nocheck+0x38/0x60 [1673239.212811] Code: 66 85 c0 74 3e 83 e8 01 4c 8d 5c 07 01 31 c0 eb 19 49 39 fa 76 03 44 88 07 48 83 c7 01 41 8d 71 01 48 83 c0 01 4c 39 df 74 0f <44> 0f b6 04 02 41 89 c1 89 c6 45 84 c0 75 d8 4c 89 d2 e8 11 ff ff [1673239.232904] RSP: 0018:a25f3199fba0 EFLAGS: 00010046 [1673239.244331] RAX: RBX: a25f3199fc58 RCX: 0a00ff04 [1673239.256551] RDX: d969688991a5a25c RSI: 8de32b56 RDI: 8de32b5400c6 [1673239.269226] RBP: a25f3199fba0 R08: 9c445a00 R09: 000a [1673239.279111] R10: 8de32b56 R11: 8de42b5400c5 R12: 8de32b56 [1673239.289855] R13: d969688991a5a25c R14: 0a00ff04 R15: 8de32b5400c6 [1673239.299447] FS: 7f925a7fc700() GS:8df87f44() knlGS: [1673239.308670] CS: 0010 DS: ES: CR0: 80050033 [1673239.317988] CR2: 7f9012efcfb8 CR3: 007fa1abe000 CR4: 00340ee0 [1673239.327377] Call Trace: [1673239.337796] string+0x4a/0x60 [1673239.347948] vsnprintf+0x26f/0x4e0 [1673239.356909] seq_vprintf+0x35/0x50 [1673239.365819] seq_printf+0x53/0x70 [1673239.374919] __blkg_prfill_rwstat+0x5d/0xb0 [1673239.383362] blkg_prfill_rwstat_field+0x97/0xc0 [1673239.391580] blkcg_print_blkgs+0xba/0xf0 [1673239.399891] ? blkg_prfill_rwstat+0xc0/0xc0 [1673239.408266] blkg_print_stat_bytes+0x45/0x50 [1673239.416378] cgroup_seqfile_show+0x56/0xc0 [1673239.424336] kernfs_seq_show+0x27/0x30 [1673239.432208] seq_read+0xdc/0x490 [1673239.440065] kernfs_fop_read+0x35/0x1b0 [1673239.448107] __vfs_read+0x1b/0x40 [1673239.456329] vfs_read+0xab/0x160 [1673239.465529] ksys_read+0x67/0xe0 [1673239.473872] __x64_sys_read+0x1a/0x20 [1673239.481269] do_syscall_64+0x57/0x190 [1673239.488798] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [1673239.497445] RIP: 0033:0x4cc910 [1673239.504694] Code: 8b 7c 24 10 48 8b 74 24 18 48 8b 54 24 20 49 c7 c2 00 00 00 00 49 c7 c0 00 00 00 00 49 c7 c1 00 00 00 00 48 8b 44 24 08 0f 05 <48> 3d 01 f0 ff ff 76 20 48 c7 44 24 28 ff ff ff ff 48 c7 44 24 30 [1673239.519380] RSP: 002b:00c01dd1e7a0 EFLAGS: 0202 ORIG_RAX: [1673239.526527] RAX: ffda RBX: 00c46f00 RCX: 004cc910 [1673239.534890] RDX: 1000 RSI: 00c00c2cd000 RDI: 000e [1673239.542958] RBP: 00c01dd1e7f0 R08: R09: [1673239.549915] R10: R11: 0202 R12: [1673239.558350] R13: 0002 R14: 0001 R15: 0002 [1673239.565178] Modules linked in: veth vhost_net nf_conntrack_netlink vhost tap dm_queue_length cls_u32 sch_cbq xsk_diag udp_diag raw_diag unix_diag af_packet_diag tcp_diag inet_diag netlink_diag ebtable_filter ebtables sch_ingress geneve ip6_udp_tunnel udp_tunnel nfnetlink_cttimeout nfnetlink aufs overlay rpcsec_gss_krb5 auth_rpcgss nfsv4 nfs lockd grace fscache bonding ip6t_REJECT nf_reject_ipv6 ip6table_filter ip6_tables ipt_REJECT nf_reject_ipv4 xt_tcpudp xt_comment xt_state xt_conntrack iptable_filter bpfilter nls_iso8859_1 scsi_dh_rdac scsi_dh_emc scsi_dh_alua ipmi_ssif amd64_edac_mod edac_mce_amd dell_smbios kvm_amd dcdbas kvm wmi_bmof dell_wmi_descriptor ccp k10temp ipmi_si ipmi_devintf ipmi_msghandler acpi_power_meter mac_hid sch_fq_codel tcp_bbr openvswitch nsh nf_conncount nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 msr dm_multipath br_netfilter bridge stp llc sunrpc ip_tables x_tables autofs4 btrfs zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq [1673239.565265] async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear mlx5_ib lpfc
[Kernel-packages] [Bug 1954924] Lsusb.txt
apport information ** Attachment added: "Lsusb.txt" https://bugs.launchpad.net/bugs/1954924/+attachment/5547806/+files/Lsusb.txt -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1954924 Title: Kernel 5.4 - general protection fault SMP NOPTI Status in linux package in Ubuntu: Confirmed Bug description: Setup is comprised of multiple compute nodes in an OpenStack setup, all nodes being connected to a SAN storage through FC. Env specs: Ubuntu-Server 20.04.3 LTS Kernel: 5.4.0-89-generic CPU: AMD EPYC 7H12 At random times we observe the nodes getting locked up, system load is increasing and no actions can be taken, leading to having to reboot the server to recover. There is no pattern in this and stress testing the servers does not reproduce this. Log snippet: [1673239.174269] general protection fault: [#1] SMP NOPTI [1673239.183446] CPU: 97 PID: 1224718 Comm: cadvisor Not tainted 5.4.0-89-generic #100-Ubuntu [1673239.192622] Hardware name: Dell Inc. PowerEdge R7525/0590KW, BIOS 2.3.6 07/06/2021 [1673239.203336] RIP: 0010:string_nocheck+0x38/0x60 [1673239.212811] Code: 66 85 c0 74 3e 83 e8 01 4c 8d 5c 07 01 31 c0 eb 19 49 39 fa 76 03 44 88 07 48 83 c7 01 41 8d 71 01 48 83 c0 01 4c 39 df 74 0f <44> 0f b6 04 02 41 89 c1 89 c6 45 84 c0 75 d8 4c 89 d2 e8 11 ff ff [1673239.232904] RSP: 0018:a25f3199fba0 EFLAGS: 00010046 [1673239.244331] RAX: RBX: a25f3199fc58 RCX: 0a00ff04 [1673239.256551] RDX: d969688991a5a25c RSI: 8de32b56 RDI: 8de32b5400c6 [1673239.269226] RBP: a25f3199fba0 R08: 9c445a00 R09: 000a [1673239.279111] R10: 8de32b56 R11: 8de42b5400c5 R12: 8de32b56 [1673239.289855] R13: d969688991a5a25c R14: 0a00ff04 R15: 8de32b5400c6 [1673239.299447] FS: 7f925a7fc700() GS:8df87f44() knlGS: [1673239.308670] CS: 0010 DS: ES: CR0: 80050033 [1673239.317988] CR2: 7f9012efcfb8 CR3: 007fa1abe000 CR4: 00340ee0 [1673239.327377] Call Trace: [1673239.337796] string+0x4a/0x60 [1673239.347948] vsnprintf+0x26f/0x4e0 [1673239.356909] seq_vprintf+0x35/0x50 [1673239.365819] seq_printf+0x53/0x70 [1673239.374919] __blkg_prfill_rwstat+0x5d/0xb0 [1673239.383362] blkg_prfill_rwstat_field+0x97/0xc0 [1673239.391580] blkcg_print_blkgs+0xba/0xf0 [1673239.399891] ? blkg_prfill_rwstat+0xc0/0xc0 [1673239.408266] blkg_print_stat_bytes+0x45/0x50 [1673239.416378] cgroup_seqfile_show+0x56/0xc0 [1673239.424336] kernfs_seq_show+0x27/0x30 [1673239.432208] seq_read+0xdc/0x490 [1673239.440065] kernfs_fop_read+0x35/0x1b0 [1673239.448107] __vfs_read+0x1b/0x40 [1673239.456329] vfs_read+0xab/0x160 [1673239.465529] ksys_read+0x67/0xe0 [1673239.473872] __x64_sys_read+0x1a/0x20 [1673239.481269] do_syscall_64+0x57/0x190 [1673239.488798] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [1673239.497445] RIP: 0033:0x4cc910 [1673239.504694] Code: 8b 7c 24 10 48 8b 74 24 18 48 8b 54 24 20 49 c7 c2 00 00 00 00 49 c7 c0 00 00 00 00 49 c7 c1 00 00 00 00 48 8b 44 24 08 0f 05 <48> 3d 01 f0 ff ff 76 20 48 c7 44 24 28 ff ff ff ff 48 c7 44 24 30 [1673239.519380] RSP: 002b:00c01dd1e7a0 EFLAGS: 0202 ORIG_RAX: [1673239.526527] RAX: ffda RBX: 00c46f00 RCX: 004cc910 [1673239.534890] RDX: 1000 RSI: 00c00c2cd000 RDI: 000e [1673239.542958] RBP: 00c01dd1e7f0 R08: R09: [1673239.549915] R10: R11: 0202 R12: [1673239.558350] R13: 0002 R14: 0001 R15: 0002 [1673239.565178] Modules linked in: veth vhost_net nf_conntrack_netlink vhost tap dm_queue_length cls_u32 sch_cbq xsk_diag udp_diag raw_diag unix_diag af_packet_diag tcp_diag inet_diag netlink_diag ebtable_filter ebtables sch_ingress geneve ip6_udp_tunnel udp_tunnel nfnetlink_cttimeout nfnetlink aufs overlay rpcsec_gss_krb5 auth_rpcgss nfsv4 nfs lockd grace fscache bonding ip6t_REJECT nf_reject_ipv6 ip6table_filter ip6_tables ipt_REJECT nf_reject_ipv4 xt_tcpudp xt_comment xt_state xt_conntrack iptable_filter bpfilter nls_iso8859_1 scsi_dh_rdac scsi_dh_emc scsi_dh_alua ipmi_ssif amd64_edac_mod edac_mce_amd dell_smbios kvm_amd dcdbas kvm wmi_bmof dell_wmi_descriptor ccp k10temp ipmi_si ipmi_devintf ipmi_msghandler acpi_power_meter mac_hid sch_fq_codel tcp_bbr openvswitch nsh nf_conncount nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 msr dm_multipath br_netfilter bridge stp llc sunrpc ip_tables x_tables autofs4 btrfs zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq [1673239.565265] async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear mlx5_ib lpfc drm_vram_he
[Kernel-packages] [Bug 1954924] ProcCpuinfoMinimal.txt
apport information ** Attachment added: "ProcCpuinfoMinimal.txt" https://bugs.launchpad.net/bugs/1954924/+attachment/5547809/+files/ProcCpuinfoMinimal.txt -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1954924 Title: Kernel 5.4 - general protection fault SMP NOPTI Status in linux package in Ubuntu: Confirmed Bug description: Setup is comprised of multiple compute nodes in an OpenStack setup, all nodes being connected to a SAN storage through FC. Env specs: Ubuntu-Server 20.04.3 LTS Kernel: 5.4.0-89-generic CPU: AMD EPYC 7H12 At random times we observe the nodes getting locked up, system load is increasing and no actions can be taken, leading to having to reboot the server to recover. There is no pattern in this and stress testing the servers does not reproduce this. Log snippet: [1673239.174269] general protection fault: [#1] SMP NOPTI [1673239.183446] CPU: 97 PID: 1224718 Comm: cadvisor Not tainted 5.4.0-89-generic #100-Ubuntu [1673239.192622] Hardware name: Dell Inc. PowerEdge R7525/0590KW, BIOS 2.3.6 07/06/2021 [1673239.203336] RIP: 0010:string_nocheck+0x38/0x60 [1673239.212811] Code: 66 85 c0 74 3e 83 e8 01 4c 8d 5c 07 01 31 c0 eb 19 49 39 fa 76 03 44 88 07 48 83 c7 01 41 8d 71 01 48 83 c0 01 4c 39 df 74 0f <44> 0f b6 04 02 41 89 c1 89 c6 45 84 c0 75 d8 4c 89 d2 e8 11 ff ff [1673239.232904] RSP: 0018:a25f3199fba0 EFLAGS: 00010046 [1673239.244331] RAX: RBX: a25f3199fc58 RCX: 0a00ff04 [1673239.256551] RDX: d969688991a5a25c RSI: 8de32b56 RDI: 8de32b5400c6 [1673239.269226] RBP: a25f3199fba0 R08: 9c445a00 R09: 000a [1673239.279111] R10: 8de32b56 R11: 8de42b5400c5 R12: 8de32b56 [1673239.289855] R13: d969688991a5a25c R14: 0a00ff04 R15: 8de32b5400c6 [1673239.299447] FS: 7f925a7fc700() GS:8df87f44() knlGS: [1673239.308670] CS: 0010 DS: ES: CR0: 80050033 [1673239.317988] CR2: 7f9012efcfb8 CR3: 007fa1abe000 CR4: 00340ee0 [1673239.327377] Call Trace: [1673239.337796] string+0x4a/0x60 [1673239.347948] vsnprintf+0x26f/0x4e0 [1673239.356909] seq_vprintf+0x35/0x50 [1673239.365819] seq_printf+0x53/0x70 [1673239.374919] __blkg_prfill_rwstat+0x5d/0xb0 [1673239.383362] blkg_prfill_rwstat_field+0x97/0xc0 [1673239.391580] blkcg_print_blkgs+0xba/0xf0 [1673239.399891] ? blkg_prfill_rwstat+0xc0/0xc0 [1673239.408266] blkg_print_stat_bytes+0x45/0x50 [1673239.416378] cgroup_seqfile_show+0x56/0xc0 [1673239.424336] kernfs_seq_show+0x27/0x30 [1673239.432208] seq_read+0xdc/0x490 [1673239.440065] kernfs_fop_read+0x35/0x1b0 [1673239.448107] __vfs_read+0x1b/0x40 [1673239.456329] vfs_read+0xab/0x160 [1673239.465529] ksys_read+0x67/0xe0 [1673239.473872] __x64_sys_read+0x1a/0x20 [1673239.481269] do_syscall_64+0x57/0x190 [1673239.488798] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [1673239.497445] RIP: 0033:0x4cc910 [1673239.504694] Code: 8b 7c 24 10 48 8b 74 24 18 48 8b 54 24 20 49 c7 c2 00 00 00 00 49 c7 c0 00 00 00 00 49 c7 c1 00 00 00 00 48 8b 44 24 08 0f 05 <48> 3d 01 f0 ff ff 76 20 48 c7 44 24 28 ff ff ff ff 48 c7 44 24 30 [1673239.519380] RSP: 002b:00c01dd1e7a0 EFLAGS: 0202 ORIG_RAX: [1673239.526527] RAX: ffda RBX: 00c46f00 RCX: 004cc910 [1673239.534890] RDX: 1000 RSI: 00c00c2cd000 RDI: 000e [1673239.542958] RBP: 00c01dd1e7f0 R08: R09: [1673239.549915] R10: R11: 0202 R12: [1673239.558350] R13: 0002 R14: 0001 R15: 0002 [1673239.565178] Modules linked in: veth vhost_net nf_conntrack_netlink vhost tap dm_queue_length cls_u32 sch_cbq xsk_diag udp_diag raw_diag unix_diag af_packet_diag tcp_diag inet_diag netlink_diag ebtable_filter ebtables sch_ingress geneve ip6_udp_tunnel udp_tunnel nfnetlink_cttimeout nfnetlink aufs overlay rpcsec_gss_krb5 auth_rpcgss nfsv4 nfs lockd grace fscache bonding ip6t_REJECT nf_reject_ipv6 ip6table_filter ip6_tables ipt_REJECT nf_reject_ipv4 xt_tcpudp xt_comment xt_state xt_conntrack iptable_filter bpfilter nls_iso8859_1 scsi_dh_rdac scsi_dh_emc scsi_dh_alua ipmi_ssif amd64_edac_mod edac_mce_amd dell_smbios kvm_amd dcdbas kvm wmi_bmof dell_wmi_descriptor ccp k10temp ipmi_si ipmi_devintf ipmi_msghandler acpi_power_meter mac_hid sch_fq_codel tcp_bbr openvswitch nsh nf_conncount nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 msr dm_multipath br_netfilter bridge stp llc sunrpc ip_tables x_tables autofs4 btrfs zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq [1673239.565265] async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath line
[Kernel-packages] [Bug 1954924] ProcEnviron.txt
apport information ** Attachment added: "ProcEnviron.txt" https://bugs.launchpad.net/bugs/1954924/+attachment/5547810/+files/ProcEnviron.txt -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1954924 Title: Kernel 5.4 - general protection fault SMP NOPTI Status in linux package in Ubuntu: Confirmed Bug description: Setup is comprised of multiple compute nodes in an OpenStack setup, all nodes being connected to a SAN storage through FC. Env specs: Ubuntu-Server 20.04.3 LTS Kernel: 5.4.0-89-generic CPU: AMD EPYC 7H12 At random times we observe the nodes getting locked up, system load is increasing and no actions can be taken, leading to having to reboot the server to recover. There is no pattern in this and stress testing the servers does not reproduce this. Log snippet: [1673239.174269] general protection fault: [#1] SMP NOPTI [1673239.183446] CPU: 97 PID: 1224718 Comm: cadvisor Not tainted 5.4.0-89-generic #100-Ubuntu [1673239.192622] Hardware name: Dell Inc. PowerEdge R7525/0590KW, BIOS 2.3.6 07/06/2021 [1673239.203336] RIP: 0010:string_nocheck+0x38/0x60 [1673239.212811] Code: 66 85 c0 74 3e 83 e8 01 4c 8d 5c 07 01 31 c0 eb 19 49 39 fa 76 03 44 88 07 48 83 c7 01 41 8d 71 01 48 83 c0 01 4c 39 df 74 0f <44> 0f b6 04 02 41 89 c1 89 c6 45 84 c0 75 d8 4c 89 d2 e8 11 ff ff [1673239.232904] RSP: 0018:a25f3199fba0 EFLAGS: 00010046 [1673239.244331] RAX: RBX: a25f3199fc58 RCX: 0a00ff04 [1673239.256551] RDX: d969688991a5a25c RSI: 8de32b56 RDI: 8de32b5400c6 [1673239.269226] RBP: a25f3199fba0 R08: 9c445a00 R09: 000a [1673239.279111] R10: 8de32b56 R11: 8de42b5400c5 R12: 8de32b56 [1673239.289855] R13: d969688991a5a25c R14: 0a00ff04 R15: 8de32b5400c6 [1673239.299447] FS: 7f925a7fc700() GS:8df87f44() knlGS: [1673239.308670] CS: 0010 DS: ES: CR0: 80050033 [1673239.317988] CR2: 7f9012efcfb8 CR3: 007fa1abe000 CR4: 00340ee0 [1673239.327377] Call Trace: [1673239.337796] string+0x4a/0x60 [1673239.347948] vsnprintf+0x26f/0x4e0 [1673239.356909] seq_vprintf+0x35/0x50 [1673239.365819] seq_printf+0x53/0x70 [1673239.374919] __blkg_prfill_rwstat+0x5d/0xb0 [1673239.383362] blkg_prfill_rwstat_field+0x97/0xc0 [1673239.391580] blkcg_print_blkgs+0xba/0xf0 [1673239.399891] ? blkg_prfill_rwstat+0xc0/0xc0 [1673239.408266] blkg_print_stat_bytes+0x45/0x50 [1673239.416378] cgroup_seqfile_show+0x56/0xc0 [1673239.424336] kernfs_seq_show+0x27/0x30 [1673239.432208] seq_read+0xdc/0x490 [1673239.440065] kernfs_fop_read+0x35/0x1b0 [1673239.448107] __vfs_read+0x1b/0x40 [1673239.456329] vfs_read+0xab/0x160 [1673239.465529] ksys_read+0x67/0xe0 [1673239.473872] __x64_sys_read+0x1a/0x20 [1673239.481269] do_syscall_64+0x57/0x190 [1673239.488798] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [1673239.497445] RIP: 0033:0x4cc910 [1673239.504694] Code: 8b 7c 24 10 48 8b 74 24 18 48 8b 54 24 20 49 c7 c2 00 00 00 00 49 c7 c0 00 00 00 00 49 c7 c1 00 00 00 00 48 8b 44 24 08 0f 05 <48> 3d 01 f0 ff ff 76 20 48 c7 44 24 28 ff ff ff ff 48 c7 44 24 30 [1673239.519380] RSP: 002b:00c01dd1e7a0 EFLAGS: 0202 ORIG_RAX: [1673239.526527] RAX: ffda RBX: 00c46f00 RCX: 004cc910 [1673239.534890] RDX: 1000 RSI: 00c00c2cd000 RDI: 000e [1673239.542958] RBP: 00c01dd1e7f0 R08: R09: [1673239.549915] R10: R11: 0202 R12: [1673239.558350] R13: 0002 R14: 0001 R15: 0002 [1673239.565178] Modules linked in: veth vhost_net nf_conntrack_netlink vhost tap dm_queue_length cls_u32 sch_cbq xsk_diag udp_diag raw_diag unix_diag af_packet_diag tcp_diag inet_diag netlink_diag ebtable_filter ebtables sch_ingress geneve ip6_udp_tunnel udp_tunnel nfnetlink_cttimeout nfnetlink aufs overlay rpcsec_gss_krb5 auth_rpcgss nfsv4 nfs lockd grace fscache bonding ip6t_REJECT nf_reject_ipv6 ip6table_filter ip6_tables ipt_REJECT nf_reject_ipv4 xt_tcpudp xt_comment xt_state xt_conntrack iptable_filter bpfilter nls_iso8859_1 scsi_dh_rdac scsi_dh_emc scsi_dh_alua ipmi_ssif amd64_edac_mod edac_mce_amd dell_smbios kvm_amd dcdbas kvm wmi_bmof dell_wmi_descriptor ccp k10temp ipmi_si ipmi_devintf ipmi_msghandler acpi_power_meter mac_hid sch_fq_codel tcp_bbr openvswitch nsh nf_conncount nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 msr dm_multipath br_netfilter bridge stp llc sunrpc ip_tables x_tables autofs4 btrfs zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq [1673239.565265] async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear mlx5_ib lpf
[Kernel-packages] [Bug 1954924] Lsusb-t.txt
apport information ** Attachment added: "Lsusb-t.txt" https://bugs.launchpad.net/bugs/1954924/+attachment/5547807/+files/Lsusb-t.txt -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1954924 Title: Kernel 5.4 - general protection fault SMP NOPTI Status in linux package in Ubuntu: Confirmed Bug description: Setup is comprised of multiple compute nodes in an OpenStack setup, all nodes being connected to a SAN storage through FC. Env specs: Ubuntu-Server 20.04.3 LTS Kernel: 5.4.0-89-generic CPU: AMD EPYC 7H12 At random times we observe the nodes getting locked up, system load is increasing and no actions can be taken, leading to having to reboot the server to recover. There is no pattern in this and stress testing the servers does not reproduce this. Log snippet: [1673239.174269] general protection fault: [#1] SMP NOPTI [1673239.183446] CPU: 97 PID: 1224718 Comm: cadvisor Not tainted 5.4.0-89-generic #100-Ubuntu [1673239.192622] Hardware name: Dell Inc. PowerEdge R7525/0590KW, BIOS 2.3.6 07/06/2021 [1673239.203336] RIP: 0010:string_nocheck+0x38/0x60 [1673239.212811] Code: 66 85 c0 74 3e 83 e8 01 4c 8d 5c 07 01 31 c0 eb 19 49 39 fa 76 03 44 88 07 48 83 c7 01 41 8d 71 01 48 83 c0 01 4c 39 df 74 0f <44> 0f b6 04 02 41 89 c1 89 c6 45 84 c0 75 d8 4c 89 d2 e8 11 ff ff [1673239.232904] RSP: 0018:a25f3199fba0 EFLAGS: 00010046 [1673239.244331] RAX: RBX: a25f3199fc58 RCX: 0a00ff04 [1673239.256551] RDX: d969688991a5a25c RSI: 8de32b56 RDI: 8de32b5400c6 [1673239.269226] RBP: a25f3199fba0 R08: 9c445a00 R09: 000a [1673239.279111] R10: 8de32b56 R11: 8de42b5400c5 R12: 8de32b56 [1673239.289855] R13: d969688991a5a25c R14: 0a00ff04 R15: 8de32b5400c6 [1673239.299447] FS: 7f925a7fc700() GS:8df87f44() knlGS: [1673239.308670] CS: 0010 DS: ES: CR0: 80050033 [1673239.317988] CR2: 7f9012efcfb8 CR3: 007fa1abe000 CR4: 00340ee0 [1673239.327377] Call Trace: [1673239.337796] string+0x4a/0x60 [1673239.347948] vsnprintf+0x26f/0x4e0 [1673239.356909] seq_vprintf+0x35/0x50 [1673239.365819] seq_printf+0x53/0x70 [1673239.374919] __blkg_prfill_rwstat+0x5d/0xb0 [1673239.383362] blkg_prfill_rwstat_field+0x97/0xc0 [1673239.391580] blkcg_print_blkgs+0xba/0xf0 [1673239.399891] ? blkg_prfill_rwstat+0xc0/0xc0 [1673239.408266] blkg_print_stat_bytes+0x45/0x50 [1673239.416378] cgroup_seqfile_show+0x56/0xc0 [1673239.424336] kernfs_seq_show+0x27/0x30 [1673239.432208] seq_read+0xdc/0x490 [1673239.440065] kernfs_fop_read+0x35/0x1b0 [1673239.448107] __vfs_read+0x1b/0x40 [1673239.456329] vfs_read+0xab/0x160 [1673239.465529] ksys_read+0x67/0xe0 [1673239.473872] __x64_sys_read+0x1a/0x20 [1673239.481269] do_syscall_64+0x57/0x190 [1673239.488798] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [1673239.497445] RIP: 0033:0x4cc910 [1673239.504694] Code: 8b 7c 24 10 48 8b 74 24 18 48 8b 54 24 20 49 c7 c2 00 00 00 00 49 c7 c0 00 00 00 00 49 c7 c1 00 00 00 00 48 8b 44 24 08 0f 05 <48> 3d 01 f0 ff ff 76 20 48 c7 44 24 28 ff ff ff ff 48 c7 44 24 30 [1673239.519380] RSP: 002b:00c01dd1e7a0 EFLAGS: 0202 ORIG_RAX: [1673239.526527] RAX: ffda RBX: 00c46f00 RCX: 004cc910 [1673239.534890] RDX: 1000 RSI: 00c00c2cd000 RDI: 000e [1673239.542958] RBP: 00c01dd1e7f0 R08: R09: [1673239.549915] R10: R11: 0202 R12: [1673239.558350] R13: 0002 R14: 0001 R15: 0002 [1673239.565178] Modules linked in: veth vhost_net nf_conntrack_netlink vhost tap dm_queue_length cls_u32 sch_cbq xsk_diag udp_diag raw_diag unix_diag af_packet_diag tcp_diag inet_diag netlink_diag ebtable_filter ebtables sch_ingress geneve ip6_udp_tunnel udp_tunnel nfnetlink_cttimeout nfnetlink aufs overlay rpcsec_gss_krb5 auth_rpcgss nfsv4 nfs lockd grace fscache bonding ip6t_REJECT nf_reject_ipv6 ip6table_filter ip6_tables ipt_REJECT nf_reject_ipv4 xt_tcpudp xt_comment xt_state xt_conntrack iptable_filter bpfilter nls_iso8859_1 scsi_dh_rdac scsi_dh_emc scsi_dh_alua ipmi_ssif amd64_edac_mod edac_mce_amd dell_smbios kvm_amd dcdbas kvm wmi_bmof dell_wmi_descriptor ccp k10temp ipmi_si ipmi_devintf ipmi_msghandler acpi_power_meter mac_hid sch_fq_codel tcp_bbr openvswitch nsh nf_conncount nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 msr dm_multipath br_netfilter bridge stp llc sunrpc ip_tables x_tables autofs4 btrfs zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq [1673239.565265] async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear mlx5_ib lpfc drm_vr
[Kernel-packages] [Bug 1954924] CRDA.txt
apport information ** Attachment added: "CRDA.txt" https://bugs.launchpad.net/bugs/1954924/+attachment/5547802/+files/CRDA.txt -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1954924 Title: Kernel 5.4 - general protection fault SMP NOPTI Status in linux package in Ubuntu: Confirmed Bug description: Setup is comprised of multiple compute nodes in an OpenStack setup, all nodes being connected to a SAN storage through FC. Env specs: Ubuntu-Server 20.04.3 LTS Kernel: 5.4.0-89-generic CPU: AMD EPYC 7H12 At random times we observe the nodes getting locked up, system load is increasing and no actions can be taken, leading to having to reboot the server to recover. There is no pattern in this and stress testing the servers does not reproduce this. Log snippet: [1673239.174269] general protection fault: [#1] SMP NOPTI [1673239.183446] CPU: 97 PID: 1224718 Comm: cadvisor Not tainted 5.4.0-89-generic #100-Ubuntu [1673239.192622] Hardware name: Dell Inc. PowerEdge R7525/0590KW, BIOS 2.3.6 07/06/2021 [1673239.203336] RIP: 0010:string_nocheck+0x38/0x60 [1673239.212811] Code: 66 85 c0 74 3e 83 e8 01 4c 8d 5c 07 01 31 c0 eb 19 49 39 fa 76 03 44 88 07 48 83 c7 01 41 8d 71 01 48 83 c0 01 4c 39 df 74 0f <44> 0f b6 04 02 41 89 c1 89 c6 45 84 c0 75 d8 4c 89 d2 e8 11 ff ff [1673239.232904] RSP: 0018:a25f3199fba0 EFLAGS: 00010046 [1673239.244331] RAX: RBX: a25f3199fc58 RCX: 0a00ff04 [1673239.256551] RDX: d969688991a5a25c RSI: 8de32b56 RDI: 8de32b5400c6 [1673239.269226] RBP: a25f3199fba0 R08: 9c445a00 R09: 000a [1673239.279111] R10: 8de32b56 R11: 8de42b5400c5 R12: 8de32b56 [1673239.289855] R13: d969688991a5a25c R14: 0a00ff04 R15: 8de32b5400c6 [1673239.299447] FS: 7f925a7fc700() GS:8df87f44() knlGS: [1673239.308670] CS: 0010 DS: ES: CR0: 80050033 [1673239.317988] CR2: 7f9012efcfb8 CR3: 007fa1abe000 CR4: 00340ee0 [1673239.327377] Call Trace: [1673239.337796] string+0x4a/0x60 [1673239.347948] vsnprintf+0x26f/0x4e0 [1673239.356909] seq_vprintf+0x35/0x50 [1673239.365819] seq_printf+0x53/0x70 [1673239.374919] __blkg_prfill_rwstat+0x5d/0xb0 [1673239.383362] blkg_prfill_rwstat_field+0x97/0xc0 [1673239.391580] blkcg_print_blkgs+0xba/0xf0 [1673239.399891] ? blkg_prfill_rwstat+0xc0/0xc0 [1673239.408266] blkg_print_stat_bytes+0x45/0x50 [1673239.416378] cgroup_seqfile_show+0x56/0xc0 [1673239.424336] kernfs_seq_show+0x27/0x30 [1673239.432208] seq_read+0xdc/0x490 [1673239.440065] kernfs_fop_read+0x35/0x1b0 [1673239.448107] __vfs_read+0x1b/0x40 [1673239.456329] vfs_read+0xab/0x160 [1673239.465529] ksys_read+0x67/0xe0 [1673239.473872] __x64_sys_read+0x1a/0x20 [1673239.481269] do_syscall_64+0x57/0x190 [1673239.488798] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [1673239.497445] RIP: 0033:0x4cc910 [1673239.504694] Code: 8b 7c 24 10 48 8b 74 24 18 48 8b 54 24 20 49 c7 c2 00 00 00 00 49 c7 c0 00 00 00 00 49 c7 c1 00 00 00 00 48 8b 44 24 08 0f 05 <48> 3d 01 f0 ff ff 76 20 48 c7 44 24 28 ff ff ff ff 48 c7 44 24 30 [1673239.519380] RSP: 002b:00c01dd1e7a0 EFLAGS: 0202 ORIG_RAX: [1673239.526527] RAX: ffda RBX: 00c46f00 RCX: 004cc910 [1673239.534890] RDX: 1000 RSI: 00c00c2cd000 RDI: 000e [1673239.542958] RBP: 00c01dd1e7f0 R08: R09: [1673239.549915] R10: R11: 0202 R12: [1673239.558350] R13: 0002 R14: 0001 R15: 0002 [1673239.565178] Modules linked in: veth vhost_net nf_conntrack_netlink vhost tap dm_queue_length cls_u32 sch_cbq xsk_diag udp_diag raw_diag unix_diag af_packet_diag tcp_diag inet_diag netlink_diag ebtable_filter ebtables sch_ingress geneve ip6_udp_tunnel udp_tunnel nfnetlink_cttimeout nfnetlink aufs overlay rpcsec_gss_krb5 auth_rpcgss nfsv4 nfs lockd grace fscache bonding ip6t_REJECT nf_reject_ipv6 ip6table_filter ip6_tables ipt_REJECT nf_reject_ipv4 xt_tcpudp xt_comment xt_state xt_conntrack iptable_filter bpfilter nls_iso8859_1 scsi_dh_rdac scsi_dh_emc scsi_dh_alua ipmi_ssif amd64_edac_mod edac_mce_amd dell_smbios kvm_amd dcdbas kvm wmi_bmof dell_wmi_descriptor ccp k10temp ipmi_si ipmi_devintf ipmi_msghandler acpi_power_meter mac_hid sch_fq_codel tcp_bbr openvswitch nsh nf_conncount nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 msr dm_multipath br_netfilter bridge stp llc sunrpc ip_tables x_tables autofs4 btrfs zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq [1673239.565265] async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear mlx5_ib lpfc drm_vram_help
[Kernel-packages] [Bug 1954924] Lspci.txt
apport information ** Attachment added: "Lspci.txt" https://bugs.launchpad.net/bugs/1954924/+attachment/5547804/+files/Lspci.txt -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1954924 Title: Kernel 5.4 - general protection fault SMP NOPTI Status in linux package in Ubuntu: Confirmed Bug description: Setup is comprised of multiple compute nodes in an OpenStack setup, all nodes being connected to a SAN storage through FC. Env specs: Ubuntu-Server 20.04.3 LTS Kernel: 5.4.0-89-generic CPU: AMD EPYC 7H12 At random times we observe the nodes getting locked up, system load is increasing and no actions can be taken, leading to having to reboot the server to recover. There is no pattern in this and stress testing the servers does not reproduce this. Log snippet: [1673239.174269] general protection fault: [#1] SMP NOPTI [1673239.183446] CPU: 97 PID: 1224718 Comm: cadvisor Not tainted 5.4.0-89-generic #100-Ubuntu [1673239.192622] Hardware name: Dell Inc. PowerEdge R7525/0590KW, BIOS 2.3.6 07/06/2021 [1673239.203336] RIP: 0010:string_nocheck+0x38/0x60 [1673239.212811] Code: 66 85 c0 74 3e 83 e8 01 4c 8d 5c 07 01 31 c0 eb 19 49 39 fa 76 03 44 88 07 48 83 c7 01 41 8d 71 01 48 83 c0 01 4c 39 df 74 0f <44> 0f b6 04 02 41 89 c1 89 c6 45 84 c0 75 d8 4c 89 d2 e8 11 ff ff [1673239.232904] RSP: 0018:a25f3199fba0 EFLAGS: 00010046 [1673239.244331] RAX: RBX: a25f3199fc58 RCX: 0a00ff04 [1673239.256551] RDX: d969688991a5a25c RSI: 8de32b56 RDI: 8de32b5400c6 [1673239.269226] RBP: a25f3199fba0 R08: 9c445a00 R09: 000a [1673239.279111] R10: 8de32b56 R11: 8de42b5400c5 R12: 8de32b56 [1673239.289855] R13: d969688991a5a25c R14: 0a00ff04 R15: 8de32b5400c6 [1673239.299447] FS: 7f925a7fc700() GS:8df87f44() knlGS: [1673239.308670] CS: 0010 DS: ES: CR0: 80050033 [1673239.317988] CR2: 7f9012efcfb8 CR3: 007fa1abe000 CR4: 00340ee0 [1673239.327377] Call Trace: [1673239.337796] string+0x4a/0x60 [1673239.347948] vsnprintf+0x26f/0x4e0 [1673239.356909] seq_vprintf+0x35/0x50 [1673239.365819] seq_printf+0x53/0x70 [1673239.374919] __blkg_prfill_rwstat+0x5d/0xb0 [1673239.383362] blkg_prfill_rwstat_field+0x97/0xc0 [1673239.391580] blkcg_print_blkgs+0xba/0xf0 [1673239.399891] ? blkg_prfill_rwstat+0xc0/0xc0 [1673239.408266] blkg_print_stat_bytes+0x45/0x50 [1673239.416378] cgroup_seqfile_show+0x56/0xc0 [1673239.424336] kernfs_seq_show+0x27/0x30 [1673239.432208] seq_read+0xdc/0x490 [1673239.440065] kernfs_fop_read+0x35/0x1b0 [1673239.448107] __vfs_read+0x1b/0x40 [1673239.456329] vfs_read+0xab/0x160 [1673239.465529] ksys_read+0x67/0xe0 [1673239.473872] __x64_sys_read+0x1a/0x20 [1673239.481269] do_syscall_64+0x57/0x190 [1673239.488798] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [1673239.497445] RIP: 0033:0x4cc910 [1673239.504694] Code: 8b 7c 24 10 48 8b 74 24 18 48 8b 54 24 20 49 c7 c2 00 00 00 00 49 c7 c0 00 00 00 00 49 c7 c1 00 00 00 00 48 8b 44 24 08 0f 05 <48> 3d 01 f0 ff ff 76 20 48 c7 44 24 28 ff ff ff ff 48 c7 44 24 30 [1673239.519380] RSP: 002b:00c01dd1e7a0 EFLAGS: 0202 ORIG_RAX: [1673239.526527] RAX: ffda RBX: 00c46f00 RCX: 004cc910 [1673239.534890] RDX: 1000 RSI: 00c00c2cd000 RDI: 000e [1673239.542958] RBP: 00c01dd1e7f0 R08: R09: [1673239.549915] R10: R11: 0202 R12: [1673239.558350] R13: 0002 R14: 0001 R15: 0002 [1673239.565178] Modules linked in: veth vhost_net nf_conntrack_netlink vhost tap dm_queue_length cls_u32 sch_cbq xsk_diag udp_diag raw_diag unix_diag af_packet_diag tcp_diag inet_diag netlink_diag ebtable_filter ebtables sch_ingress geneve ip6_udp_tunnel udp_tunnel nfnetlink_cttimeout nfnetlink aufs overlay rpcsec_gss_krb5 auth_rpcgss nfsv4 nfs lockd grace fscache bonding ip6t_REJECT nf_reject_ipv6 ip6table_filter ip6_tables ipt_REJECT nf_reject_ipv4 xt_tcpudp xt_comment xt_state xt_conntrack iptable_filter bpfilter nls_iso8859_1 scsi_dh_rdac scsi_dh_emc scsi_dh_alua ipmi_ssif amd64_edac_mod edac_mce_amd dell_smbios kvm_amd dcdbas kvm wmi_bmof dell_wmi_descriptor ccp k10temp ipmi_si ipmi_devintf ipmi_msghandler acpi_power_meter mac_hid sch_fq_codel tcp_bbr openvswitch nsh nf_conncount nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 msr dm_multipath br_netfilter bridge stp llc sunrpc ip_tables x_tables autofs4 btrfs zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq [1673239.565265] async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear mlx5_ib lpfc drm_vram_he
[Kernel-packages] [Bug 1954924] [NEW] Kernel 5.4 - general protection fault SMP NOPTI
Public bug reported: Setup is comprised of multiple compute nodes in an OpenStack setup, all nodes being connected to a SAN storage through FC. Env specs: Ubuntu-Server 20.04.3 LTS Kernel: 5.4.0-89-generic CPU: AMD EPYC 7H12 At random times we observe the nodes getting locked up, system load is increasing and no actions can be taken, leading to having to reboot the server to recover. There is no pattern in this and stress testing the servers does not reproduce this. Log snippet: [1673239.174269] general protection fault: [#1] SMP NOPTI [1673239.183446] CPU: 97 PID: 1224718 Comm: cadvisor Not tainted 5.4.0-89-generic #100-Ubuntu [1673239.192622] Hardware name: Dell Inc. PowerEdge R7525/0590KW, BIOS 2.3.6 07/06/2021 [1673239.203336] RIP: 0010:string_nocheck+0x38/0x60 [1673239.212811] Code: 66 85 c0 74 3e 83 e8 01 4c 8d 5c 07 01 31 c0 eb 19 49 39 fa 76 03 44 88 07 48 83 c7 01 41 8d 71 01 48 83 c0 01 4c 39 df 74 0f <44> 0f b6 04 02 41 89 c1 89 c6 45 84 c0 75 d8 4c 89 d2 e8 11 ff ff [1673239.232904] RSP: 0018:a25f3199fba0 EFLAGS: 00010046 [1673239.244331] RAX: RBX: a25f3199fc58 RCX: 0a00ff04 [1673239.256551] RDX: d969688991a5a25c RSI: 8de32b56 RDI: 8de32b5400c6 [1673239.269226] RBP: a25f3199fba0 R08: 9c445a00 R09: 000a [1673239.279111] R10: 8de32b56 R11: 8de42b5400c5 R12: 8de32b56 [1673239.289855] R13: d969688991a5a25c R14: 0a00ff04 R15: 8de32b5400c6 [1673239.299447] FS: 7f925a7fc700() GS:8df87f44() knlGS: [1673239.308670] CS: 0010 DS: ES: CR0: 80050033 [1673239.317988] CR2: 7f9012efcfb8 CR3: 007fa1abe000 CR4: 00340ee0 [1673239.327377] Call Trace: [1673239.337796] string+0x4a/0x60 [1673239.347948] vsnprintf+0x26f/0x4e0 [1673239.356909] seq_vprintf+0x35/0x50 [1673239.365819] seq_printf+0x53/0x70 [1673239.374919] __blkg_prfill_rwstat+0x5d/0xb0 [1673239.383362] blkg_prfill_rwstat_field+0x97/0xc0 [1673239.391580] blkcg_print_blkgs+0xba/0xf0 [1673239.399891] ? blkg_prfill_rwstat+0xc0/0xc0 [1673239.408266] blkg_print_stat_bytes+0x45/0x50 [1673239.416378] cgroup_seqfile_show+0x56/0xc0 [1673239.424336] kernfs_seq_show+0x27/0x30 [1673239.432208] seq_read+0xdc/0x490 [1673239.440065] kernfs_fop_read+0x35/0x1b0 [1673239.448107] __vfs_read+0x1b/0x40 [1673239.456329] vfs_read+0xab/0x160 [1673239.465529] ksys_read+0x67/0xe0 [1673239.473872] __x64_sys_read+0x1a/0x20 [1673239.481269] do_syscall_64+0x57/0x190 [1673239.488798] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [1673239.497445] RIP: 0033:0x4cc910 [1673239.504694] Code: 8b 7c 24 10 48 8b 74 24 18 48 8b 54 24 20 49 c7 c2 00 00 00 00 49 c7 c0 00 00 00 00 49 c7 c1 00 00 00 00 48 8b 44 24 08 0f 05 <48> 3d 01 f0 ff ff 76 20 48 c7 44 24 28 ff ff ff ff 48 c7 44 24 30 [1673239.519380] RSP: 002b:00c01dd1e7a0 EFLAGS: 0202 ORIG_RAX: [1673239.526527] RAX: ffda RBX: 00c46f00 RCX: 004cc910 [1673239.534890] RDX: 1000 RSI: 00c00c2cd000 RDI: 000e [1673239.542958] RBP: 00c01dd1e7f0 R08: R09: [1673239.549915] R10: R11: 0202 R12: [1673239.558350] R13: 0002 R14: 0001 R15: 0002 [1673239.565178] Modules linked in: veth vhost_net nf_conntrack_netlink vhost tap dm_queue_length cls_u32 sch_cbq xsk_diag udp_diag raw_diag unix_diag af_packet_diag tcp_diag inet_diag netlink_diag ebtable_filter ebtables sch_ingress geneve ip6_udp_tunnel udp_tunnel nfnetlink_cttimeout nfnetlink aufs overlay rpcsec_gss_krb5 auth_rpcgss nfsv4 nfs lockd grace fscache bonding ip6t_REJECT nf_reject_ipv6 ip6table_filter ip6_tables ipt_REJECT nf_reject_ipv4 xt_tcpudp xt_comment xt_state xt_conntrack iptable_filter bpfilter nls_iso8859_1 scsi_dh_rdac scsi_dh_emc scsi_dh_alua ipmi_ssif amd64_edac_mod edac_mce_amd dell_smbios kvm_amd dcdbas kvm wmi_bmof dell_wmi_descriptor ccp k10temp ipmi_si ipmi_devintf ipmi_msghandler acpi_power_meter mac_hid sch_fq_codel tcp_bbr openvswitch nsh nf_conncount nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 msr dm_multipath br_netfilter bridge stp llc sunrpc ip_tables x_tables autofs4 btrfs zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq [1673239.565265] async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear mlx5_ib lpfc drm_vram_helper i2c_algo_bit ib_uverbs nvmet_fc crct10dif_pclmul ib_core crc32_pclmul ttm ghash_clmulni_intel drm_kms_helper aesni_intel nvmet syscopyarea crypto_simd sysfillrect cryptd nvme_fc glue_helper sysimgblt nvme_fabrics ahci fb_sys_fops mlx5_core tg3 libahci nvme_core pci_hyperv_intf drm tls scsi_transport_fc mlxfw megaraid_sas i2c_piix4 wmi [1673239.664974] ---[ end trace b20e1996a1c8240d ]--- ** Affects: linux (Ubuntu) Importance: Undecided Status: Confirmed ** Tags: apport-colle
[Kernel-packages] [Bug 1954924] CurrentDmesg.txt
apport information ** Attachment added: "CurrentDmesg.txt" https://bugs.launchpad.net/bugs/1954924/+attachment/5547803/+files/CurrentDmesg.txt -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1954924 Title: Kernel 5.4 - general protection fault SMP NOPTI Status in linux package in Ubuntu: Confirmed Bug description: Setup is comprised of multiple compute nodes in an OpenStack setup, all nodes being connected to a SAN storage through FC. Env specs: Ubuntu-Server 20.04.3 LTS Kernel: 5.4.0-89-generic CPU: AMD EPYC 7H12 At random times we observe the nodes getting locked up, system load is increasing and no actions can be taken, leading to having to reboot the server to recover. There is no pattern in this and stress testing the servers does not reproduce this. Log snippet: [1673239.174269] general protection fault: [#1] SMP NOPTI [1673239.183446] CPU: 97 PID: 1224718 Comm: cadvisor Not tainted 5.4.0-89-generic #100-Ubuntu [1673239.192622] Hardware name: Dell Inc. PowerEdge R7525/0590KW, BIOS 2.3.6 07/06/2021 [1673239.203336] RIP: 0010:string_nocheck+0x38/0x60 [1673239.212811] Code: 66 85 c0 74 3e 83 e8 01 4c 8d 5c 07 01 31 c0 eb 19 49 39 fa 76 03 44 88 07 48 83 c7 01 41 8d 71 01 48 83 c0 01 4c 39 df 74 0f <44> 0f b6 04 02 41 89 c1 89 c6 45 84 c0 75 d8 4c 89 d2 e8 11 ff ff [1673239.232904] RSP: 0018:a25f3199fba0 EFLAGS: 00010046 [1673239.244331] RAX: RBX: a25f3199fc58 RCX: 0a00ff04 [1673239.256551] RDX: d969688991a5a25c RSI: 8de32b56 RDI: 8de32b5400c6 [1673239.269226] RBP: a25f3199fba0 R08: 9c445a00 R09: 000a [1673239.279111] R10: 8de32b56 R11: 8de42b5400c5 R12: 8de32b56 [1673239.289855] R13: d969688991a5a25c R14: 0a00ff04 R15: 8de32b5400c6 [1673239.299447] FS: 7f925a7fc700() GS:8df87f44() knlGS: [1673239.308670] CS: 0010 DS: ES: CR0: 80050033 [1673239.317988] CR2: 7f9012efcfb8 CR3: 007fa1abe000 CR4: 00340ee0 [1673239.327377] Call Trace: [1673239.337796] string+0x4a/0x60 [1673239.347948] vsnprintf+0x26f/0x4e0 [1673239.356909] seq_vprintf+0x35/0x50 [1673239.365819] seq_printf+0x53/0x70 [1673239.374919] __blkg_prfill_rwstat+0x5d/0xb0 [1673239.383362] blkg_prfill_rwstat_field+0x97/0xc0 [1673239.391580] blkcg_print_blkgs+0xba/0xf0 [1673239.399891] ? blkg_prfill_rwstat+0xc0/0xc0 [1673239.408266] blkg_print_stat_bytes+0x45/0x50 [1673239.416378] cgroup_seqfile_show+0x56/0xc0 [1673239.424336] kernfs_seq_show+0x27/0x30 [1673239.432208] seq_read+0xdc/0x490 [1673239.440065] kernfs_fop_read+0x35/0x1b0 [1673239.448107] __vfs_read+0x1b/0x40 [1673239.456329] vfs_read+0xab/0x160 [1673239.465529] ksys_read+0x67/0xe0 [1673239.473872] __x64_sys_read+0x1a/0x20 [1673239.481269] do_syscall_64+0x57/0x190 [1673239.488798] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [1673239.497445] RIP: 0033:0x4cc910 [1673239.504694] Code: 8b 7c 24 10 48 8b 74 24 18 48 8b 54 24 20 49 c7 c2 00 00 00 00 49 c7 c0 00 00 00 00 49 c7 c1 00 00 00 00 48 8b 44 24 08 0f 05 <48> 3d 01 f0 ff ff 76 20 48 c7 44 24 28 ff ff ff ff 48 c7 44 24 30 [1673239.519380] RSP: 002b:00c01dd1e7a0 EFLAGS: 0202 ORIG_RAX: [1673239.526527] RAX: ffda RBX: 00c46f00 RCX: 004cc910 [1673239.534890] RDX: 1000 RSI: 00c00c2cd000 RDI: 000e [1673239.542958] RBP: 00c01dd1e7f0 R08: R09: [1673239.549915] R10: R11: 0202 R12: [1673239.558350] R13: 0002 R14: 0001 R15: 0002 [1673239.565178] Modules linked in: veth vhost_net nf_conntrack_netlink vhost tap dm_queue_length cls_u32 sch_cbq xsk_diag udp_diag raw_diag unix_diag af_packet_diag tcp_diag inet_diag netlink_diag ebtable_filter ebtables sch_ingress geneve ip6_udp_tunnel udp_tunnel nfnetlink_cttimeout nfnetlink aufs overlay rpcsec_gss_krb5 auth_rpcgss nfsv4 nfs lockd grace fscache bonding ip6t_REJECT nf_reject_ipv6 ip6table_filter ip6_tables ipt_REJECT nf_reject_ipv4 xt_tcpudp xt_comment xt_state xt_conntrack iptable_filter bpfilter nls_iso8859_1 scsi_dh_rdac scsi_dh_emc scsi_dh_alua ipmi_ssif amd64_edac_mod edac_mce_amd dell_smbios kvm_amd dcdbas kvm wmi_bmof dell_wmi_descriptor ccp k10temp ipmi_si ipmi_devintf ipmi_msghandler acpi_power_meter mac_hid sch_fq_codel tcp_bbr openvswitch nsh nf_conncount nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 msr dm_multipath br_netfilter bridge stp llc sunrpc ip_tables x_tables autofs4 btrfs zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq [1673239.565265] async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear mlx5_ib l
[Kernel-packages] [Bug 1833744] Re: [Hyper-V] pick-up hv_netvsc commit in linux-azure 4.15
** Changed in: linux-azure (Ubuntu) Status: New => Confirmed -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-azure in Ubuntu. https://bugs.launchpad.net/bugs/1833744 Title: [Hyper-V] pick-up hv_netvsc commit in linux-azure 4.15 Status in linux-azure package in Ubuntu: Confirmed Bug description: Please include this missing commit. We need it in the Xenial 16.04 linux-azure kernel series 4.15. https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=273de02ae7d828d72d66eb5fce181e1f3f96d0cd hv_netvsc: Add handlers for ethtool get/set msg level The handlers for ethtool get/set msg level are missing from netvsc. This patch adds them. Signed-off-by: Haiyang Zhang Signed-off-by: David S. Miller da...@davemloft.net To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-azure/+bug/1833744/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1833744] [NEW] [Hyper-V] pick-up hv_netvsc commit in linux-azure 4.15
Public bug reported: Please include this missing commit. We need it in the Xenial 16.04 linux-azure kernel series 4.15. https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=273de02ae7d828d72d66eb5fce181e1f3f96d0cd hv_netvsc: Add handlers for ethtool get/set msg level The handlers for ethtool get/set msg level are missing from netvsc. This patch adds them. Signed-off-by: Haiyang Zhang Signed-off-by: David S. Miller da...@davemloft.net ** Affects: linux-azure (Ubuntu) Importance: Undecided Status: New ** Tags: hyperv -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-azure in Ubuntu. https://bugs.launchpad.net/bugs/1833744 Title: [Hyper-V] pick-up hv_netvsc commit in linux-azure 4.15 Status in linux-azure package in Ubuntu: New Bug description: Please include this missing commit. We need it in the Xenial 16.04 linux-azure kernel series 4.15. https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=273de02ae7d828d72d66eb5fce181e1f3f96d0cd hv_netvsc: Add handlers for ethtool get/set msg level The handlers for ethtool get/set msg level are missing from netvsc. This patch adds them. Signed-off-by: Haiyang Zhang Signed-off-by: David S. Miller da...@davemloft.net To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-azure/+bug/1833744/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1804054] Re: [Hyper-V] kdump is broken on trusty with linux-azure 4.15.0-1032 kernel
Issue remains in latest 4.15.0-1040-azure. No new version for kdump-tools - latest 1.5.5-2ubuntu1.6. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-azure in Ubuntu. https://bugs.launchpad.net/bugs/1804054 Title: [Hyper-V] kdump is broken on trusty with linux-azure 4.15.0-1032 kernel Status in linux-azure package in Ubuntu: Triaged Bug description: While testing linux-azure 4.15.0-1032 kernel from proposed we found that kdump is no longer working as expected, on trusty only. Here are some info and versions. We'll have to verify a few more scenarios with other images and try to isolate this, but as least the kdump on trusty issue is there. Also remains to be checked in which release this regression was introduced. The below can be repro'd on Azure. On Xenial it works with ubuntu provided latest kexec-tools 2.0.16. It looks like the kexec might require some patches from upstream as far as I can tell from the data we have so far. Distro / kernel: 4.15.0-1032-azure #33~14.04.2-Ubuntu Package: kdump-tools1.5.5-2ubuntu1.6 Errors from logs: kdump-config: failed to load kdump kernel kernel: [ 230.772409] init: kdump-tools main process (1726) terminated with status 1 # cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-4.15.0-1032-azure root=x ro console=tty1 console=ttyS0 earlyprintk=ttyS0 rootdelay=300 crashkernel=384M --- This issue looks resolved with the kexec package build from the official kernel.org kexec repo, on top of 14.04. kexec-tools 2.0.18 https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git # cat /sys/kernel/kexec_* 1 402653184 And kdump core file gets created when running with 1032 kernel. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-azure/+bug/1804054/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1813026] [NEW] [Hyper-V] VM console orphan newline input during login
Public bug reported: In Bionic azure-edge proposed kernel 4.18.0-1008 we're observing an issue that got carried from upstream. This is the first version we checked specifically for this issue, we don't have yet a good/bad proposed comparison set of versions. linux-next-5.0.0-9673b4a-20012019 does not have this issue <- daily upstream linux-next linux-next-4.20.0-6a1d293-27122018 has the issue <- all 4.1x/4.2x series from upstream have this problem. This behavior can be seen only on Hyper-V, as it must use the VM console UI: - boot the above kernels. - try to login with username and password. - After you input the username and press Enter in the Hyper-V console, another Enter (newline) is automatically received by the console, making it impossible to input the password. Afterward, the console behaves like a series of newlines are received and it resets after a while, presenting again the linux user login. Repro rates: - 100% on WS2019 - on WS2016 depending on situation it might not be visible 100%. Problem does not exist for Azure, it's specific to Hyper-V VM console only. ** Affects: linux-azure (Ubuntu) Importance: Undecided Status: New ** Tags: hyperv -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-azure in Ubuntu. https://bugs.launchpad.net/bugs/1813026 Title: [Hyper-V] VM console orphan newline input during login Status in linux-azure package in Ubuntu: New Bug description: In Bionic azure-edge proposed kernel 4.18.0-1008 we're observing an issue that got carried from upstream. This is the first version we checked specifically for this issue, we don't have yet a good/bad proposed comparison set of versions. linux-next-5.0.0-9673b4a-20012019 does not have this issue <- daily upstream linux-next linux-next-4.20.0-6a1d293-27122018 has the issue <- all 4.1x/4.2x series from upstream have this problem. This behavior can be seen only on Hyper-V, as it must use the VM console UI: - boot the above kernels. - try to login with username and password. - After you input the username and press Enter in the Hyper-V console, another Enter (newline) is automatically received by the console, making it impossible to input the password. Afterward, the console behaves like a series of newlines are received and it resets after a while, presenting again the linux user login. Repro rates: - 100% on WS2019 - on WS2016 depending on situation it might not be visible 100%. Problem does not exist for Azure, it's specific to Hyper-V VM console only. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-azure/+bug/1813026/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1805849] Re: apt repository in proposed packages availability issue
We have worked around this by doing dry test installs of azure kernel inside
containers, and wait until that is successfully getting installed.
We also tried to look for a set of packages for linux-azure - from linux-azure,
headers, image, but that also didn't help.
I wasn't aware of linux-signed-azure, which isn't installed by default.
We can close this, thank you!
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1805849
Title:
apt repository in proposed packages availability issue
Status in linux package in Ubuntu:
Triaged
Status in linux-azure package in Ubuntu:
Triaged
Bug description:
We have a watcher that does the following:
- verifies if any linux-azure kernels have been published in proposed repo.
- if it detects one, it will install.
The problem we have is that even though we detect a new kernel in proposed,
the installation of it will fail as there are unmet package dependencies not
being available.
This does resolve after several hours, but the way it works is not reliable
that we see the main package being available, but the packages in the repo are
not ready yet.
So it seems to be a timing issue from the time the kernel is released, and
the time the packages actual get on the repo.
Can you please suggest on some methods to better handle the detect &
install for these, or some suggestions to how we do this from below.
How we search for new kernel availability from proposed:
#apt-cache madison linux-azure | grep ${release}-proposed
But doing an install right after that will fail most of the times if the
kernel was just published:
#apt clean all
#apt -y update
#apt install linux-azure/$release
^ this is after we add the proposed repo in sources.list.
Actual error in the end:
linux-azure : Depends: linux-image-azure (= 4.15.0.1034.34) but 4.15.0.1030.30
E: Unable to correct problems, you have held broken packages.
This is observed on all LTS versions.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1805849/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1794477] Re: Accelerated networking (SR-IOV VF) broken in 18.10 daily
This does look resolved on WS2016 and Azure. However, SR-IOV is broken in another way now on WS2019. Affected proposed kernels: - cosmic proposed - bionic proposed edge - 4.18 based. Tested this with cosmic linux-azure 4.18.0.1006.7 from proposed, same vhd: - SR-IOV with Mellanox CX3 works fine on WS2016, all testing has passed. - SR-IOV with Mellanox CX3/CX4 is broken on WS2019. These are the relevant log portions showing the issue when the kernel attempts to load the driver: dmesg: [ 21.059766] mlx4_core: Mellanox ConnectX core driver v4.0-0 [ 21.059775] mlx4_core: Initializing 9488:00:02.0 [ 21.191481] mlx4_core 9488:00:02.0: Detected virtual function - running in slave mode [ 21.191508] mlx4_core 9488:00:02.0: Sending reset [ 21.191602] mlx4_core 9488:00:02.0: Sending vhcr0 [ 21.193338] mlx4_core 9488:00:02.0: HCA minimum page size:512 [ 21.193804] mlx4_core 9488:00:02.0: Timestamping is not supported in slave mode [ 93.148028] mlx4_core 9488:00:02.0: communication channel command 0x5 (op=0x31) timed out [ 93.148031] mlx4_core 9488:00:02.0: device is going to be reset [ 93.171917] mlx4_core 9488:00:02.0: VF is sending reset request to Firmware [ 93.172584] mlx4_core 9488:00:02.0: VF Reset succeed [ 93.172585] mlx4_core 9488:00:02.0: device was reset successfully [ 93.195311] mlx4_core 9488:00:02.0: NOP command failed to generate MSI-X interrupt IRQ 24) [ 93.195312] mlx4_core 9488:00:02.0: Trying again without MSI-X [ 93.196258] mlx4_core 9488:00:02.0: Failed to close slave function [ 93.196866] mlx4_core: probe of 9488:00:02.0 failed with error -5 syslog: Dec 4 14:35:18 ubuntu kernel: [ 21.059766] mlx4_core: Mellanox ConnectX core driver v4.0-0 Dec 4 14:35:18 ubuntu kernel: [ 21.059775] mlx4_core: Initializing 9488:00:02.0 Dec 4 14:35:18 ubuntu kernel: [ 21.191481] mlx4_core 9488:00:02.0: Detected virtual function - running in slave mode Dec 4 14:35:18 ubuntu kernel: [ 21.191508] mlx4_core 9488:00:02.0: Sending reset Dec 4 14:35:18 ubuntu kernel: [ 21.191602] mlx4_core 9488:00:02.0: Sending vhcr0 Dec 4 14:35:18 ubuntu kernel: [ 21.193338] mlx4_core 9488:00:02.0: HCA minimum page size:512 Dec 4 14:35:18 ubuntu kernel: [ 21.193804] mlx4_core 9488:00:02.0: Timestamping is not supported in slave mode Dec 4 14:35:18 ubuntu kernel: [ 93.148028] mlx4_core 9488:00:02.0: communication channel command 0x5 (op=0x31) timed out Dec 4 14:35:18 ubuntu kernel: [ 93.148031] mlx4_core 9488:00:02.0: device is going to be reset Dec 4 14:35:18 ubuntu kernel: [ 93.171917] mlx4_core 9488:00:02.0: VF is sending reset request to Firmware Dec 4 14:35:18 ubuntu kernel: [ 93.172584] mlx4_core 9488:00:02.0: VF Reset succeed Dec 4 14:35:18 ubuntu kernel: [ 93.172585] mlx4_core 9488:00:02.0: device was reset successfully Dec 4 14:35:18 ubuntu kernel: [ 93.195311] mlx4_core 9488:00:02.0: NOP command failed to generate MSI-X interrupt IRQ 24) Dec 4 14:35:18 ubuntu kernel: [ 93.195312] mlx4_core 9488:00:02.0: Trying again without MSI-X Dec 4 14:35:18 ubuntu kernel: [ 93.196258] mlx4_core 9488:00:02.0: Failed to close slave function Dec 4 14:35:18 ubuntu kernel: [ 93.196866] mlx4_core: probe of 9488:00:02.0 failed with error -5 -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-azure in Ubuntu. https://bugs.launchpad.net/bugs/1794477 Title: Accelerated networking (SR-IOV VF) broken in 18.10 daily Status in linux package in Ubuntu: Fix Committed Status in linux-azure package in Ubuntu: Fix Committed Status in linux source package in Cosmic: New Status in linux-azure source package in Cosmic: Fix Committed Bug description: While testing Ubuntu 18.10 daily from cloud-images repo, on Azure, we discovered that accelerated networking wasn’t working inside the VM. No VF shows up inside the VM and lspci didn’t show any Mellanox drivers in use. We tested the daily build on Hyper-V also, but there the Mellanox VF is functional, with the same mlx4 drivers. To give more details about this: • No mellanox logs are showing up in dmesg or syslog. • Modinfo mlx4_core/mlx4_en finds the module, but lsmod doesn’t show it as loaded, although Accelerated Networking is enabled for the Azure VM, so this should happen transparently. • Modprobe -r mlx4_core && modprobe mlx4_core is giving 0 exit code, but nothing really happens. And no Mellanox messages are logged in dmesg/syslog. - There are no entries in the logs to show anything about the drivers or netvsc/pci-hyperv that might relate to this issue. Kernel: 4.18.0-7-generic To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1794477/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/List
[Kernel-packages] [Bug 1805849] Re: apt repository in proposed packages availability issue
** Changed in: linux (Ubuntu)
Status: Incomplete => Confirmed
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1805849
Title:
apt repository in proposed packages availability issue
Status in linux package in Ubuntu:
Confirmed
Bug description:
We have a watcher that does the following:
- verifies if any linux-azure kernels have been published in proposed repo.
- if it detects one, it will install.
The problem we have is that even though we detect a new kernel in proposed,
the installation of it will fail as there are unmet package dependencies not
being available.
This does resolve after several hours, but the way it works is not reliable
that we see the main package being available, but the packages in the repo are
not ready yet.
So it seems to be a timing issue from the time the kernel is released, and
the time the packages actual get on the repo.
Can you please suggest on some methods to better handle the detect &
install for these, or some suggestions to how we do this from below.
How we search for new kernel availability from proposed:
#apt-cache madison linux-azure | grep ${release}-proposed
But doing an install right after that will fail most of the times if the
kernel was just published:
#apt clean all
#apt -y update
#apt install linux-azure/$release
^ this is after we add the proposed repo in sources.list.
Actual error in the end:
linux-azure : Depends: linux-image-azure (= 4.15.0.1034.34) but 4.15.0.1030.30
E: Unable to correct problems, you have held broken packages.
This is observed on all LTS versions.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1805849/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1805849] [NEW] apt repository in proposed packages availability issue
Public bug reported:
We have a watcher that does the following:
- verifies if any linux-azure kernels have been published in proposed repo.
- if it detects one, it will install.
The problem we have is that even though we detect a new kernel in proposed, the
installation of it will fail as there are unmet package dependencies not being
available.
This does resolve after several hours, but the way it works is not reliable
that we see the main package being available, but the packages in the repo are
not ready yet.
So it seems to be a timing issue from the time the kernel is released, and the
time the packages actual get on the repo.
Can you please suggest on some methods to better handle the detect &
install for these, or some suggestions to how we do this from below.
How we search for new kernel availability from proposed:
#apt-cache madison linux-azure | grep ${release}-proposed
But doing an install right after that will fail most of the times if the kernel
was just published:
#apt clean all
#apt -y update
#apt install linux-azure/$release
^ this is after we add the proposed repo in sources.list.
Actual error in the end:
linux-azure : Depends: linux-image-azure (= 4.15.0.1034.34) but 4.15.0.1030.30
E: Unable to correct problems, you have held broken packages.
This is observed on all LTS versions.
** Affects: linux (Ubuntu)
Importance: Undecided
Status: Incomplete
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1805849
Title:
apt repository in proposed packages availability issue
Status in linux package in Ubuntu:
Incomplete
Bug description:
We have a watcher that does the following:
- verifies if any linux-azure kernels have been published in proposed repo.
- if it detects one, it will install.
The problem we have is that even though we detect a new kernel in proposed,
the installation of it will fail as there are unmet package dependencies not
being available.
This does resolve after several hours, but the way it works is not reliable
that we see the main package being available, but the packages in the repo are
not ready yet.
So it seems to be a timing issue from the time the kernel is released, and
the time the packages actual get on the repo.
Can you please suggest on some methods to better handle the detect &
install for these, or some suggestions to how we do this from below.
How we search for new kernel availability from proposed:
#apt-cache madison linux-azure | grep ${release}-proposed
But doing an install right after that will fail most of the times if the
kernel was just published:
#apt clean all
#apt -y update
#apt install linux-azure/$release
^ this is after we add the proposed repo in sources.list.
Actual error in the end:
linux-azure : Depends: linux-image-azure (= 4.15.0.1034.34) but 4.15.0.1030.30
E: Unable to correct problems, you have held broken packages.
This is observed on all LTS versions.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1805849/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1794477] Re: Accelerated networking (SR-IOV VF) broken in 18.10 daily
"Just to confirm, the 4.18 kernel you see this bug in is the standard Ubuntu kernel?" > A: this first was seen in the daily cosmic 18.10 images (before RTM), and > when azure-edge kernels were created we've seen this problem on those as well. That being azure-edge for Bionic for example, not only Cosmic one. Both kernels provided in comment #9 are having the issue - 4.15.0-29 and 4.17.0-4. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-azure in Ubuntu. https://bugs.launchpad.net/bugs/1794477 Title: Accelerated networking (SR-IOV VF) broken in 18.10 daily Status in linux package in Ubuntu: In Progress Status in linux-azure package in Ubuntu: Confirmed Status in linux source package in Cosmic: In Progress Bug description: While testing Ubuntu 18.10 daily from cloud-images repo, on Azure, we discovered that accelerated networking wasn’t working inside the VM. No VF shows up inside the VM and lspci didn’t show any Mellanox drivers in use. We tested the daily build on Hyper-V also, but there the Mellanox VF is functional, with the same mlx4 drivers. To give more details about this: • No mellanox logs are showing up in dmesg or syslog. • Modinfo mlx4_core/mlx4_en finds the module, but lsmod doesn’t show it as loaded, although Accelerated Networking is enabled for the Azure VM, so this should happen transparently. • Modprobe -r mlx4_core && modprobe mlx4_core is giving 0 exit code, but nothing really happens. And no Mellanox messages are logged in dmesg/syslog. - There are no entries in the logs to show anything about the drivers or netvsc/pci-hyperv that might relate to this issue. Kernel: 4.18.0-7-generic To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1794477/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1804054] [NEW] [Hyper-V] kdump is broken on trusty with linux-azure 4.15.0-1032 kernel
Public bug reported: While testing linux-azure 4.15.0-1032 kernel from proposed we found that kdump is no longer working as expected, on trusty only. Here are some info and versions. We'll have to verify a few more scenarios with other images and try to isolate this, but as least the kdump on trusty issue is there. Also remains to be checked in which release this regression was introduced. The below can be repro'd on Azure. On Xenial it works with ubuntu provided latest kexec-tools 2.0.16. It looks like the kexec might require some patches from upstream as far as I can tell from the data we have so far. Distro / kernel: 4.15.0-1032-azure #33~14.04.2-Ubuntu Package: kdump-tools1.5.5-2ubuntu1.6 Errors from logs: kdump-config: failed to load kdump kernel kernel: [ 230.772409] init: kdump-tools main process (1726) terminated with status 1 # cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-4.15.0-1032-azure root=x ro console=tty1 console=ttyS0 earlyprintk=ttyS0 rootdelay=300 crashkernel=384M --- This issue looks resolved with the kexec package build from the official kernel.org kexec repo, on top of 14.04. kexec-tools 2.0.18 https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git # cat /sys/kernel/kexec_* 1 402653184 And kdump core file gets created when running with 1032 kernel. ** Affects: linux (Ubuntu) Importance: Undecided Status: Confirmed ** Tags: hyper-v -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1804054 Title: [Hyper-V] kdump is broken on trusty with linux-azure 4.15.0-1032 kernel Status in linux package in Ubuntu: Confirmed Bug description: While testing linux-azure 4.15.0-1032 kernel from proposed we found that kdump is no longer working as expected, on trusty only. Here are some info and versions. We'll have to verify a few more scenarios with other images and try to isolate this, but as least the kdump on trusty issue is there. Also remains to be checked in which release this regression was introduced. The below can be repro'd on Azure. On Xenial it works with ubuntu provided latest kexec-tools 2.0.16. It looks like the kexec might require some patches from upstream as far as I can tell from the data we have so far. Distro / kernel: 4.15.0-1032-azure #33~14.04.2-Ubuntu Package: kdump-tools1.5.5-2ubuntu1.6 Errors from logs: kdump-config: failed to load kdump kernel kernel: [ 230.772409] init: kdump-tools main process (1726) terminated with status 1 # cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-4.15.0-1032-azure root=x ro console=tty1 console=ttyS0 earlyprintk=ttyS0 rootdelay=300 crashkernel=384M --- This issue looks resolved with the kexec package build from the official kernel.org kexec repo, on top of 14.04. kexec-tools 2.0.18 https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git # cat /sys/kernel/kexec_* 1 402653184 And kdump core file gets created when running with 1032 kernel. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1804054/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1794477] Re: Accelerated networking (SR-IOV VF) broken in 18.10 daily
If you can point me to the ubuntu kernel sources where we can see how the 4.15 and 4.18 kernels are found then I can check if a bisect would be possible as such. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-azure in Ubuntu. https://bugs.launchpad.net/bugs/1794477 Title: Accelerated networking (SR-IOV VF) broken in 18.10 daily Status in linux package in Ubuntu: Confirmed Status in linux-azure package in Ubuntu: Confirmed Status in linux source package in Cosmic: Confirmed Bug description: While testing Ubuntu 18.10 daily from cloud-images repo, on Azure, we discovered that accelerated networking wasn’t working inside the VM. No VF shows up inside the VM and lspci didn’t show any Mellanox drivers in use. We tested the daily build on Hyper-V also, but there the Mellanox VF is functional, with the same mlx4 drivers. To give more details about this: • No mellanox logs are showing up in dmesg or syslog. • Modinfo mlx4_core/mlx4_en finds the module, but lsmod doesn’t show it as loaded, although Accelerated Networking is enabled for the Azure VM, so this should happen transparently. • Modprobe -r mlx4_core && modprobe mlx4_core is giving 0 exit code, but nothing really happens. And no Mellanox messages are logged in dmesg/syslog. - There are no entries in the logs to show anything about the drivers or netvsc/pci-hyperv that might relate to this issue. Kernel: 4.18.0-7-generic To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1794477/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1794477] Re: Accelerated networking (SR-IOV VF) broken in 18.10 daily
What I know is that this is working in azure kernels 4.15 series, but not in 4.18 since we got the dailies with it for Cosmic. >From the ubuntu kernel tree if these versions are separate branches then I don't know how a bisect would work... -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-azure in Ubuntu. https://bugs.launchpad.net/bugs/1794477 Title: Accelerated networking (SR-IOV VF) broken in 18.10 daily Status in linux package in Ubuntu: Confirmed Status in linux-azure package in Ubuntu: Confirmed Status in linux source package in Cosmic: Confirmed Bug description: While testing Ubuntu 18.10 daily from cloud-images repo, on Azure, we discovered that accelerated networking wasn’t working inside the VM. No VF shows up inside the VM and lspci didn’t show any Mellanox drivers in use. We tested the daily build on Hyper-V also, but there the Mellanox VF is functional, with the same mlx4 drivers. To give more details about this: • No mellanox logs are showing up in dmesg or syslog. • Modinfo mlx4_core/mlx4_en finds the module, but lsmod doesn’t show it as loaded, although Accelerated Networking is enabled for the Azure VM, so this should happen transparently. • Modprobe -r mlx4_core && modprobe mlx4_core is giving 0 exit code, but nothing really happens. And no Mellanox messages are logged in dmesg/syslog. - There are no entries in the logs to show anything about the drivers or netvsc/pci-hyperv that might relate to this issue. Kernel: 4.18.0-7-generic To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1794477/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1779640] Re: [Hyper-V] KVP daemon crashes at startup
Missed the reply on this thread, my apologies. I tried now to install the packages from those ppa's, however apt will not detect the kernels. I've added the ppa repo and did an #apt update, but apt will then not detect neither of the kernels, so I mus t be doing something wrong. On another note, the linux-tools packages seem to require a different libbinutils version, which I don't see in the mentioned repos to have been built. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1779640 Title: [Hyper-V] KVP daemon crashes at startup Status in linux package in Ubuntu: In Progress Status in linux source package in Bionic: In Progress Bug description: While testing Bionic daily build with kernel 4.15.0-20-generic we saw the following issue with the KVP daemon: KVP daemon crashes after approximatively 2 minutes of uptime and it enters in a failed state. The daemon can be manually started and it enters back in active (running) state. The error messages from /var/log/syslog after the daemon enters the failed state are the following: Apr 25 04:28:46 bionicDaily KVP: read failed; error:9 Bad file descriptor Apr 25 04:28:46 bionicDaily systemd[1]: hv-kvp-daemon.service: Main process exited, code=exited, status=1/FAILURE Apr 25 04:28:46 bionicDaily systemd[1]: hv-kvp-daemon.service: Failed with result 'exit-code'. Apr 25 04:28:59 bionicDaily systemd[1]: Started Hyper-V KVP Protocol Daemon. Note: There was a simmilar issue discussed on this thread https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1664663, but the fixing commit seems to be inclued in this Bionic build. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1779640/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1766857] Re: [Hyper-V] KVP daemon fails to start
Issue with 'Invalid kvp dependency scripts path /usr/libexec/hypervkvpd' remains in latest kernel-image bionic 4.15.0-38.41. Verified azure-kernel 4.15.0-1030.31 for bionic, same VM and environment, and the issue does *not* appear. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-azure in Ubuntu. https://bugs.launchpad.net/bugs/1766857 Title: [Hyper-V] KVP daemon fails to start Status in linux package in Ubuntu: In Progress Status in linux-azure package in Ubuntu: Invalid Status in linux source package in Bionic: In Progress Status in linux-azure source package in Bionic: Invalid Status in linux source package in Cosmic: In Progress Status in linux-azure source package in Cosmic: Invalid Bug description: While testing Bionic daily build with kernel 4.15.0-20-generic we saw that there are 2 issues with the KVP daemon: 1. KVP daemon crash after boot. Opened a different bug for this: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1779640 2. After the KVP daemon is being started the following messages appear: Apr 25 04:45:25 bionicDaily hv_kvp_daemon[1895]: sh: 1: /usr/libexec/hypervkvpd/hv_get_dns_info: not found Apr 25 04:45:25 bionicDaily hv_kvp_daemon[1895]: sh: 1: /usr/libexec/hypervkvpd/hv_get_dhcp_info: not found The above binaries are present on the system, but the their actual path is /usr/sbin/hv_get_dns_info and /usr/sbin/hv_get_dhcp_info. Either the hv_get_dhcp_info and hv_get_dns_info binaries should be placed in the location where the daemon is looking for (/usr/libexec/hypervkvpd/), or the daemon should be set to search for the binaries in the /usr/sbin directory. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1766857/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1794477] Re: Accelerated networking (SR-IOV VF) broken in 18.10 daily
Bug is now carried in linux-azure-edge kernels on the 4.18 tree, these should not be published to release further from proposed. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1794477 Title: Accelerated networking (SR-IOV VF) broken in 18.10 daily Status in linux package in Ubuntu: Confirmed Status in linux source package in Cosmic: Confirmed Bug description: While testing Ubuntu 18.10 daily from cloud-images repo, on Azure, we discovered that accelerated networking wasn’t working inside the VM. No VF shows up inside the VM and lspci didn’t show any Mellanox drivers in use. We tested the daily build on Hyper-V also, but there the Mellanox VF is functional, with the same mlx4 drivers. To give more details about this: • No mellanox logs are showing up in dmesg or syslog. • Modinfo mlx4_core/mlx4_en finds the module, but lsmod doesn’t show it as loaded, although Accelerated Networking is enabled for the Azure VM, so this should happen transparently. • Modprobe -r mlx4_core && modprobe mlx4_core is giving 0 exit code, but nothing really happens. And no Mellanox messages are logged in dmesg/syslog. - There are no entries in the logs to show anything about the drivers or netvsc/pci-hyperv that might relate to this issue. Kernel: 4.18.0-7-generic To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1794477/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1766857] Re: [Hyper-V] KVP daemon fails to start
Joe, for the 2nd issue initially reported here, about "After the KVP daemon is being started the following messages appear". We've noticed a regression for this in 18.10 - daily's and even GA. Can you please add Cosmic 18.10 to the bug here and re-open or should I send a new bug report for it? Thank you! -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-azure in Ubuntu. https://bugs.launchpad.net/bugs/1766857 Title: [Hyper-V] KVP daemon fails to start Status in linux package in Ubuntu: In Progress Status in linux-azure package in Ubuntu: Invalid Status in linux source package in Bionic: In Progress Status in linux-azure source package in Bionic: Invalid Bug description: While testing Bionic daily build with kernel 4.15.0-20-generic we saw that there are 2 issues with the KVP daemon: 1. KVP daemon crash after boot. Opened a different bug for this: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1779640 2. After the KVP daemon is being started the following messages appear: Apr 25 04:45:25 bionicDaily hv_kvp_daemon[1895]: sh: 1: /usr/libexec/hypervkvpd/hv_get_dns_info: not found Apr 25 04:45:25 bionicDaily hv_kvp_daemon[1895]: sh: 1: /usr/libexec/hypervkvpd/hv_get_dhcp_info: not found The above binaries are present on the system, but the their actual path is /usr/sbin/hv_get_dns_info and /usr/sbin/hv_get_dhcp_info. Either the hv_get_dhcp_info and hv_get_dns_info binaries should be placed in the location where the daemon is looking for (/usr/libexec/hypervkvpd/), or the daemon should be set to search for the binaries in the /usr/sbin directory. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1766857/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1794477] Re: Accelerated networking (SR-IOV VF) broken in 18.10 daily
** Summary changed: - [Azure] Accelerated networking broken in 18.10 daily + Accelerated networking (SR-IOV VF) broken in 18.10 daily -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1794477 Title: Accelerated networking (SR-IOV VF) broken in 18.10 daily Status in linux package in Ubuntu: Confirmed Status in linux source package in Cosmic: Confirmed Bug description: While testing Ubuntu 18.10 daily from cloud-images repo, on Azure, we discovered that accelerated networking wasn’t working inside the VM. No VF shows up inside the VM and lspci didn’t show any Mellanox drivers in use. We tested the daily build on Hyper-V also, but there the Mellanox VF is functional, with the same mlx4 drivers. To give more details about this: • No mellanox logs are showing up in dmesg or syslog. • Modinfo mlx4_core/mlx4_en finds the module, but lsmod doesn’t show it as loaded, although Accelerated Networking is enabled for the Azure VM, so this should happen transparently. • Modprobe -r mlx4_core && modprobe mlx4_core is giving 0 exit code, but nothing really happens. And no Mellanox messages are logged in dmesg/syslog. - There are no entries in the logs to show anything about the drivers or netvsc/pci-hyperv that might relate to this issue. Kernel: 4.18.0-7-generic To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1794477/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1794477] Re: [Azure] Accelerated networking broken in 18.10 daily
This is now broken also on Hyper-V VMs, tested with 4.18.0-8-generic and daily 18.10 server -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1794477 Title: [Azure] Accelerated networking broken in 18.10 daily Status in linux package in Ubuntu: Confirmed Status in linux source package in Cosmic: Confirmed Bug description: While testing Ubuntu 18.10 daily from cloud-images repo, on Azure, we discovered that accelerated networking wasn’t working inside the VM. No VF shows up inside the VM and lspci didn’t show any Mellanox drivers in use. We tested the daily build on Hyper-V also, but there the Mellanox VF is functional, with the same mlx4 drivers. To give more details about this: • No mellanox logs are showing up in dmesg or syslog. • Modinfo mlx4_core/mlx4_en finds the module, but lsmod doesn’t show it as loaded, although Accelerated Networking is enabled for the Azure VM, so this should happen transparently. • Modprobe -r mlx4_core && modprobe mlx4_core is giving 0 exit code, but nothing really happens. And no Mellanox messages are logged in dmesg/syslog. - There are no entries in the logs to show anything about the drivers or netvsc/pci-hyperv that might relate to this issue. Kernel: 4.18.0-7-generic To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1794477/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1756129] Re: [Hyper-V] Dynamic Memory HotAdd memory demand increases very fast to maximum
This behavior is still seen even in 4.18.0.1002 proposed azure kernel for Cosmic 18.10 release (daily builds). -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-azure in Ubuntu. https://bugs.launchpad.net/bugs/1756129 Title: [Hyper-V] Dynamic Memory HotAdd memory demand increases very fast to maximum Status in linux-azure package in Ubuntu: Confirmed Bug description: Issue description: Memory demand increases very fast up to the maximum available memory, call traces show up in /var/log/syslog, the VM becomes unresponsive during the memory consumption, but it becomes responsive right after stress-ng ends its execution, therefore we can say the issue might be in the Dynamic Memory feature. Platform: host independent Distribution name and release: - Bionic (4.15.0-10-generic) - Linux Azure kernel (4.13.0-1012-azure) Repro rate: 100% VM configuration: Kernel: 4.13.0-1012-azure CPU: 8 cores RAM: 2048 MB Enable Dynamic Memory: Yes Minimum RAM: 512 MB Maximum RAM: 8192 MB Memory buffer: 20% Memory weight: 100% Repro steps: 1. Start the VM with the above configuration. 2. Run stress-ng with the following parameters: stress-ng -m 16 --vm-bytes 256M -t 200 --backoff 1000 3. In less than 60 seconds the entire memory is consumed. Additional info: 1. We also tested this on Xenial with default kernel and the issue does not occur. 2. The call trace message from syslog can be seen below. Mar 14 08:42:17 xenial kernel: [ 257.120261] Call Trace: Mar 14 08:42:17 xenial kernel: [ 257.120267] dump_stack+0x63/0x82 Mar 14 08:42:17 xenial kernel: [ 257.120271] dump_header+0x97/0x225 Mar 14 08:42:17 xenial kernel: [ 257.120276] ? security_capable_noaudit+0x4b/0x70 Mar 14 08:42:17 xenial kernel: [ 257.120277] oom_kill_process+0x219/0x420 Mar 14 08:42:17 xenial kernel: [ 257.120279] out_of_memory+0x11d/0x4b0 Mar 14 08:42:17 xenial kernel: [ 257.120282] __alloc_pages_slowpath+0xd32/0xe10 Mar 14 08:42:17 xenial kernel: [ 257.120284] __alloc_pages_nodemask+0x263/0x280 Mar 14 08:42:17 xenial kernel: [ 257.120289] alloc_pages_vma+0x88/0x1e0 Mar 14 08:42:17 xenial kernel: [ 257.120292] shmem_alloc_page+0x70/0xc0 Mar 14 08:42:17 xenial kernel: [ 257.120295] ? __radix_tree_insert+0x45/0x230 Mar 14 08:42:17 xenial kernel: [ 257.120297] shmem_alloc_and_acct_page+0x73/0x1b0 Mar 14 08:42:17 xenial kernel: [ 257.120298] ? find_get_entry+0x1e/0xe0 Mar 14 08:42:17 xenial kernel: [ 257.120300] shmem_getpage_gfp+0x18f/0xbf0 Mar 14 08:42:17 xenial kernel: [ 257.120303] shmem_fault+0x9d/0x1e0 Mar 14 08:42:17 xenial kernel: [ 257.120306] ? file_update_time+0x60/0x110 Mar 14 08:42:17 xenial kernel: [ 257.120309] __do_fault+0x24/0xd0 Mar 14 08:42:17 xenial kernel: [ 257.120311] __handle_mm_fault+0x983/0x1080 Mar 14 08:42:17 xenial kernel: [ 257.120314] ? set_next_entity+0xd9/0x220 Mar 14 08:42:17 xenial kernel: [ 257.120316] handle_mm_fault+0xcc/0x1c0 Mar 14 08:42:17 xenial kernel: [ 257.120319] __do_page_fault+0x258/0x4f0 Mar 14 08:42:17 xenial kernel: [ 257.120320] do_page_fault+0x22/0x30 Mar 14 08:42:17 xenial kernel: [ 257.120323] ? page_fault+0x36/0x60 Mar 14 08:42:17 xenial kernel: [ 257.120325] page_fault+0x4c/0x60 Mar 14 08:42:17 xenial kernel: [ 257.120327] RIP: 0033:0x4493ad Mar 14 08:42:17 xenial kernel: [ 257.120328] RSP: 002b:7ffd3ff927b0 EFLAGS: 00010286 Mar 14 08:42:17 xenial kernel: [ 257.120329] RAX: c6a6a9e7 RBX: 0001a8ae9d07 RCX: 21b83c00 Mar 14 08:42:17 xenial kernel: [ 257.120330] RDX: 7f2ad911d000 RSI: 271ea9e7 RDI: 271e9660 Mar 14 08:42:17 xenial kernel: [ 257.120331] RBP: 7f2adab7 R08: 1bda3103 R09: 48373eca Mar 14 08:42:17 xenial kernel: [ 257.120331] R10: 48373eca R11: 7f2acab7 R12: Mar 14 08:42:17 xenial kernel: [ 257.120332] R13: 8309310348373eca R14: 56b63c1fe6166568 R15: 7f2acab7 Mar 14 08:42:17 xenial kernel: [ 257.120333] Mem-Info: Mar 14 08:42:17 xenial kernel: [ 257.120337] active_anon:249563 inactive_anon:83607 isolated_anon:65 Mar 14 08:42:17 xenial kernel: [ 257.120337] active_file:54 inactive_file:74 isolated_file:0 Mar 14 08:42:17 xenial kernel: [ 257.120337] unevictable:2561 dirty:0 writeback:68 unstable:0 Mar 14 08:42:17 xenial kernel: [ 257.120337] slab_reclaimable:10707 slab_unreclaimable:16622 Mar 14 08:42:17 xenial kernel: [ 257.120337] mapped:132260 shmem:332303 pagetables:2888 bounce:0 Mar 14 08:42:17 xenial kernel: [ 257.120337] free:12983 free_pcp:493 free_cma:0 Mar 14 08:42:17 xenial kernel: [ 257.120340] Node 0 active_anon:998252kB inactive_anon:334428kB active_file:216kB inactive_file:296kB unevictable:10244kB isolated(anon):260kB isolated(file):0kB mapped:529040kB dirty:0kB write
[Kernel-packages] [Bug 1794477] Re: [Azure] Accelerated networking broken in 18.10 daily
** Description changed: While testing Ubuntu 18.10 daily from cloud-images repo, on Azure, we discovered that accelerated networking wasn’t working inside the VM. No VF shows up inside the VM and lspci didn’t show any Mellanox drivers in use. We tested the daily build on Hyper-V also, but there the Mellanox VF is functional, with the same mlx4 drivers. To give more details about this: - • No mellanox logs are showing up in dmesg or syslog. - • Modinfo mlx4_core/mlx4_en finds the module, but lsmod doesn’t show it as loaded, although Accelerated Networking is enabled for the Azure VM, so this should happen transparently. - • Modprobe -r mlx4_core && modprobe mlx4_core is giving 0 exit code, but nothing really happens. And no Mellanox messages are logged in dmesg/syslog. + • No mellanox logs are showing up in dmesg or syslog. + • Modinfo mlx4_core/mlx4_en finds the module, but lsmod doesn’t show it as loaded, although Accelerated Networking is enabled for the Azure VM, so this should happen transparently. + • Modprobe -r mlx4_core && modprobe mlx4_core is giving 0 exit code, but nothing really happens. And no Mellanox messages are logged in dmesg/syslog. + - There are no entries in the logs to show anything about the drivers or netvsc/pci-hyperv that might relate to this issue. + + Kernel: 4.18.0-7-generic ** Changed in: linux (Ubuntu) Status: Incomplete => Confirmed -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1794477 Title: [Azure] Accelerated networking broken in 18.10 daily Status in linux package in Ubuntu: Confirmed Bug description: While testing Ubuntu 18.10 daily from cloud-images repo, on Azure, we discovered that accelerated networking wasn’t working inside the VM. No VF shows up inside the VM and lspci didn’t show any Mellanox drivers in use. We tested the daily build on Hyper-V also, but there the Mellanox VF is functional, with the same mlx4 drivers. To give more details about this: • No mellanox logs are showing up in dmesg or syslog. • Modinfo mlx4_core/mlx4_en finds the module, but lsmod doesn’t show it as loaded, although Accelerated Networking is enabled for the Azure VM, so this should happen transparently. • Modprobe -r mlx4_core && modprobe mlx4_core is giving 0 exit code, but nothing really happens. And no Mellanox messages are logged in dmesg/syslog. - There are no entries in the logs to show anything about the drivers or netvsc/pci-hyperv that might relate to this issue. Kernel: 4.18.0-7-generic To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1794477/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1794477] [NEW] [Azure] Accelerated networking broken in 18.10 daily
Public bug reported: While testing Ubuntu 18.10 daily from cloud-images repo, on Azure, we discovered that accelerated networking wasn’t working inside the VM. No VF shows up inside the VM and lspci didn’t show any Mellanox drivers in use. We tested the daily build on Hyper-V also, but there the Mellanox VF is functional, with the same mlx4 drivers. To give more details about this: • No mellanox logs are showing up in dmesg or syslog. • Modinfo mlx4_core/mlx4_en finds the module, but lsmod doesn’t show it as loaded, although Accelerated Networking is enabled for the Azure VM, so this should happen transparently. • Modprobe -r mlx4_core && modprobe mlx4_core is giving 0 exit code, but nothing really happens. And no Mellanox messages are logged in dmesg/syslog. ** Affects: linux (Ubuntu) Importance: Undecided Status: New ** Tags: azure -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1794477 Title: [Azure] Accelerated networking broken in 18.10 daily Status in linux package in Ubuntu: New Bug description: While testing Ubuntu 18.10 daily from cloud-images repo, on Azure, we discovered that accelerated networking wasn’t working inside the VM. No VF shows up inside the VM and lspci didn’t show any Mellanox drivers in use. We tested the daily build on Hyper-V also, but there the Mellanox VF is functional, with the same mlx4 drivers. To give more details about this: • No mellanox logs are showing up in dmesg or syslog. • Modinfo mlx4_core/mlx4_en finds the module, but lsmod doesn’t show it as loaded, although Accelerated Networking is enabled for the Azure VM, so this should happen transparently. • Modprobe -r mlx4_core && modprobe mlx4_core is giving 0 exit code, but nothing really happens. And no Mellanox messages are logged in dmesg/syslog. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1794477/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1750349] Re: [Hyper-V] include kvp fix for Avoid reading past allocated blocks from KVP file
** Changed in: linux (Ubuntu)
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1750349
Title:
[Hyper-V] include kvp fix for Avoid reading past allocated blocks from
KVP file
Status in linux package in Ubuntu:
Fix Released
Status in linux-azure package in Ubuntu:
Fix Released
Status in linux source package in Artful:
Fix Released
Status in linux source package in Bionic:
Fix Released
Bug description:
== SRU Justification ==
This commit is being requested in Bionic and linux-azure by Microsoft. It
has
already been applied to Bionic. It is being requested in Artful, so it makes
it's way into linux-azure through the re-base process.
This fix is required if a large number of records are injected into a pool,
which can cause the kvp daemon to crash.
This commit has been cc'd to upstream stable. However, it has not yet been
applied
to Artful, since upstream 4.13 is EOL.
== Fix ==
297d6b6e56c2 ("hv: kvp: Avoid reading past allocated blocks from KVP file")
== Regression Potential ==
Low. This patch has also been sent to upstream stable, so it has had
additional upstream
review.
== Test Case ==
A test kernel was built with this patch and tested by the original bug
reporter.
The bug reporter states the test kernel resolved the bug.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1750349/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1750349] Re: [Hyper-V] include kvp fix for Avoid reading past allocated blocks from KVP file
Joe, Brad - I see this bug still reads 'committed' for bionic.
Looking for a Fix released for all so that we can close it.
Thank you!
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1750349
Title:
[Hyper-V] include kvp fix for Avoid reading past allocated blocks from
KVP file
Status in linux package in Ubuntu:
Fix Committed
Status in linux-azure package in Ubuntu:
Fix Released
Status in linux source package in Artful:
Fix Released
Status in linux source package in Bionic:
Fix Committed
Bug description:
== SRU Justification ==
This commit is being requested in Bionic and linux-azure by Microsoft. It
has
already been applied to Bionic. It is being requested in Artful, so it makes
it's way into linux-azure through the re-base process.
This fix is required if a large number of records are injected into a pool,
which can cause the kvp daemon to crash.
This commit has been cc'd to upstream stable. However, it has not yet been
applied
to Artful, since upstream 4.13 is EOL.
== Fix ==
297d6b6e56c2 ("hv: kvp: Avoid reading past allocated blocks from KVP file")
== Regression Potential ==
Low. This patch has also been sent to upstream stable, so it has had
additional upstream
review.
== Test Case ==
A test kernel was built with this patch and tested by the original bug
reporter.
The bug reporter states the test kernel resolved the bug.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1750349/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1777128] Re: [Hyper-V] patches for SR-IOV post-bionic GA
** Changed in: linux (Ubuntu Bionic) Status: Fix Committed => Fix Released ** Changed in: linux (Ubuntu) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1777128 Title: [Hyper-V] patches for SR-IOV post-bionic GA Status in linux package in Ubuntu: Fix Released Status in linux source package in Bionic: Fix Released Bug description: For 18.04 we're seeing some SR-IOV functionality issues. Please pick these patches for the next SRU. Some of them are in ubuntu master-next tree, but still wanting to track these for inclusion into 18.04 kernel. "PCI: hv: Fix 2 hang issues in hv_compose_msi_msg()" is the most critical one to be picked up, the rest is part of the series or related that should be added along. Full list: 2018-03-28 Drivers: hv: vmbus: do not mark HV_PCIE as perf_device 2018-03-16 PCI: hv: Only queue new work items in hv_pci_devices_present() if necessary 2018-03-16 PCI: hv: Remove the bogus test in hv_eject_device_work() 2018-03-16 PCI: hv: Fix a comment typo in _hv_pcifront_read_config() 2018-03-16 PCI: hv: Fix 2 hang issues in hv_compose_msi_msg() 2018-03-16 PCI: hv: Serialize the present and eject work items To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1777128/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1779640] Re: [Hyper-V] KVP daemon crashes at startup
** Changed in: linux (Ubuntu) Status: Incomplete => Confirmed -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1779640 Title: [Hyper-V] KVP daemon crashes at startup Status in linux package in Ubuntu: Confirmed Bug description: While testing Bionic daily build with kernel 4.15.0-20-generic we saw the following issue with the KVP daemon: KVP daemon crashes after approximatively 2 minutes of uptime and it enters in a failed state. The daemon can be manually started and it enters back in active (running) state. The error messages from /var/log/syslog after the daemon enters the failed state are the following: Apr 25 04:28:46 bionicDaily KVP: read failed; error:9 Bad file descriptor Apr 25 04:28:46 bionicDaily systemd[1]: hv-kvp-daemon.service: Main process exited, code=exited, status=1/FAILURE Apr 25 04:28:46 bionicDaily systemd[1]: hv-kvp-daemon.service: Failed with result 'exit-code'. Apr 25 04:28:59 bionicDaily systemd[1]: Started Hyper-V KVP Protocol Daemon. Note: There was a simmilar issue discussed on this thread https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1664663, but the fixing commit seems to be inclued in this Bionic build. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1779640/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1777128] Re: [Hyper-V] patches for SR-IOV post-bionic GA
** Changed in: linux (Ubuntu) Status: Incomplete => Confirmed -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1777128 Title: [Hyper-V] patches for SR-IOV post-bionic GA Status in linux package in Ubuntu: Confirmed Bug description: For 18.04 we're seeing some SR-IOV functionality issues. Please pick these patches for the next SRU. Some of them are in ubuntu master-next tree, but still wanting to track these for inclusion into 18.04 kernel. "PCI: hv: Fix 2 hang issues in hv_compose_msi_msg()" is the most critical one to be picked up, the rest is part of the series or related that should be added along. Full list: 2018-03-28 Drivers: hv: vmbus: do not mark HV_PCIE as perf_device 2018-03-16 PCI: hv: Only queue new work items in hv_pci_devices_present() if necessary 2018-03-16 PCI: hv: Remove the bogus test in hv_eject_device_work() 2018-03-16 PCI: hv: Fix a comment typo in _hv_pcifront_read_config() 2018-03-16 PCI: hv: Fix 2 hang issues in hv_compose_msi_msg() 2018-03-16 PCI: hv: Serialize the present and eject work items To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1777128/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1777128] [NEW] [Hyper-V] patches for SR-IOV post-bionic GA
Public bug reported: For 18.04 we're seeing some SR-IOV functionality issues. Please pick these patches for the next SRU. Some of them are in ubuntu master-next tree, but still wanting to track these for inclusion into 18.04 kernel. "PCI: hv: Fix 2 hang issues in hv_compose_msi_msg()" is the most critical one to be picked up, the rest is part of the series or related that should be added along. Full list: 2018-03-28 Drivers: hv: vmbus: do not mark HV_PCIE as perf_device 2018-03-16 PCI: hv: Only queue new work items in hv_pci_devices_present() if necessary 2018-03-16 PCI: hv: Remove the bogus test in hv_eject_device_work() 2018-03-16 PCI: hv: Fix a comment typo in _hv_pcifront_read_config() 2018-03-16 PCI: hv: Fix 2 hang issues in hv_compose_msi_msg() 2018-03-16 PCI: hv: Serialize the present and eject work items ** Affects: linux (Ubuntu) Importance: Undecided Status: Incomplete ** Tags: bionic hyper-v -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1777128 Title: [Hyper-V] patches for SR-IOV post-bionic GA Status in linux package in Ubuntu: Incomplete Bug description: For 18.04 we're seeing some SR-IOV functionality issues. Please pick these patches for the next SRU. Some of them are in ubuntu master-next tree, but still wanting to track these for inclusion into 18.04 kernel. "PCI: hv: Fix 2 hang issues in hv_compose_msi_msg()" is the most critical one to be picked up, the rest is part of the series or related that should be added along. Full list: 2018-03-28 Drivers: hv: vmbus: do not mark HV_PCIE as perf_device 2018-03-16 PCI: hv: Only queue new work items in hv_pci_devices_present() if necessary 2018-03-16 PCI: hv: Remove the bogus test in hv_eject_device_work() 2018-03-16 PCI: hv: Fix a comment typo in _hv_pcifront_read_config() 2018-03-16 PCI: hv: Fix 2 hang issues in hv_compose_msi_msg() 2018-03-16 PCI: hv: Serialize the present and eject work items To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1777128/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1766857] Re: [Hyper-V] KVP daemon fails to start
** Changed in: linux (Ubuntu) Status: Incomplete => Confirmed -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1766857 Title: [Hyper-V] KVP daemon fails to start Status in linux package in Ubuntu: Confirmed Bug description: While testing Bionic daily build with kernel 4.15.0-20-generic we saw that there are 2 issues with the KVP daemon: 1. KVP daemon crashes after approximatively 2 minutes of uptime and it enters in a failed state. The daemon can be manually started and it enters back in active (running) state. The error messages from /var/log/syslog after the daemon enters the failed state are the following: Apr 25 04:28:46 bionicDaily KVP: read failed; error:9 Bad file descriptor Apr 25 04:28:46 bionicDaily systemd[1]: hv-kvp-daemon.service: Main process exited, code=exited, status=1/FAILURE Apr 25 04:28:46 bionicDaily systemd[1]: hv-kvp-daemon.service: Failed with result 'exit-code'. Apr 25 04:28:59 bionicDaily systemd[1]: Started Hyper-V KVP Protocol Daemon. Note: There was a simmilar issue discussed on this thread https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1664663, but the fixing commit seems to be inclued in this Bionic build. 2. After the KVP daemon is being started the following messages appear: Apr 25 04:45:25 bionicDaily hv_kvp_daemon[1895]: sh: 1: /usr/libexec/hypervkvpd/hv_get_dns_info: not found Apr 25 04:45:25 bionicDaily hv_kvp_daemon[1895]: sh: 1: /usr/libexec/hypervkvpd/hv_get_dhcp_info: not found The above binaries are present on the system, but the their actual path is /usr/sbin/hv_get_dns_info and /usr/sbin/hv_get_dhcp_info. Either the hv_get_dhcp_info and hv_get_dns_info binaries should be placed in the location where the daemon is looking for (/usr/libexec/hypervkvpd/), or the daemon should be set to search for the binaries in the /usr/sbin directory. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1766857/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1750349] Re: [Hyper-V] include kvp fix for Avoid reading past allocated blocks from KVP file
The change is looking fine in artful proposed 4.13.0.39.42 kernel. bug
status changed to verification-done
** Tags removed: verification-needed-artful
** Tags added: verification-done-artful
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1750349
Title:
[Hyper-V] include kvp fix for Avoid reading past allocated blocks from
KVP file
Status in linux package in Ubuntu:
Fix Committed
Status in linux-azure package in Ubuntu:
Triaged
Status in linux source package in Artful:
Fix Committed
Status in linux source package in Bionic:
Fix Committed
Bug description:
== SRU Justification ==
This commit is being requested in Bionic and linux-azure by Microsoft. It
has
already been applied to Bionic. It is being requested in Artful, so it makes
it's way into linux-azure through the re-base process.
This fix is required if a large number of records are injected into a pool,
which can cause the kvp daemon to crash.
This commit has been cc'd to upstream stable. However, it has not yet been
applied
to Artful, since upstream 4.13 is EOL.
== Fix ==
297d6b6e56c2 ("hv: kvp: Avoid reading past allocated blocks from KVP file")
== Regression Potential ==
Low. This patch has also been sent to upstream stable, so it has had
additional upstream
review.
== Test Case ==
A test kernel was built with this patch and tested by the original bug
reporter.
The bug reporter states the test kernel resolved the bug.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1750349/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1756129] Re: [Hyper-V] Dynamic Memory HotAdd memory demand increases very fast to maximum
** Summary changed: - [Hyper-V] Dynamic Memory HotAdd memory demand increases very fast to maximum and logs show call trace messages + [Hyper-V] Dynamic Memory HotAdd memory demand increases very fast to maximum ** Changed in: linux (Ubuntu) Status: Incomplete => Confirmed -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1756129 Title: [Hyper-V] Dynamic Memory HotAdd memory demand increases very fast to maximum Status in linux package in Ubuntu: Confirmed Bug description: Issue description: Memory demand increases very fast up to the maximum available memory, call traces show up in /var/log/syslog, the VM becomes unresponsive during the memory consumption, but it becomes responsive right after stress-ng ends its execution, therefore we can say the issue might be in the Dynamic Memory feature. Platform: host independent Distribution name and release: - Bionic (4.15.0-10-generic) - Linux Azure kernel (4.13.0-1012-azure) Repro rate: 100% VM configuration: Kernel: 4.13.0-1012-azure CPU: 8 cores RAM: 2048 MB Enable Dynamic Memory: Yes Minimum RAM: 512 MB Maximum RAM: 8192 MB Memory buffer: 20% Memory weight: 100% Repro steps: 1. Start the VM with the above configuration. 2. Run stress-ng with the following parameters: stress-ng -m 16 -vm-bytes 256M -t 200 --backoff 1000 3. In less than 60 seconds the entire memory is consumed. Additional info: 1. We also tested this on Xenial with default kernel and the issue does not occur. 2. The call trace message from syslog can be seen below. Mar 14 08:42:17 xenial kernel: [ 257.120261] Call Trace: Mar 14 08:42:17 xenial kernel: [ 257.120267] dump_stack+0x63/0x82 Mar 14 08:42:17 xenial kernel: [ 257.120271] dump_header+0x97/0x225 Mar 14 08:42:17 xenial kernel: [ 257.120276] ? security_capable_noaudit+0x4b/0x70 Mar 14 08:42:17 xenial kernel: [ 257.120277] oom_kill_process+0x219/0x420 Mar 14 08:42:17 xenial kernel: [ 257.120279] out_of_memory+0x11d/0x4b0 Mar 14 08:42:17 xenial kernel: [ 257.120282] __alloc_pages_slowpath+0xd32/0xe10 Mar 14 08:42:17 xenial kernel: [ 257.120284] __alloc_pages_nodemask+0x263/0x280 Mar 14 08:42:17 xenial kernel: [ 257.120289] alloc_pages_vma+0x88/0x1e0 Mar 14 08:42:17 xenial kernel: [ 257.120292] shmem_alloc_page+0x70/0xc0 Mar 14 08:42:17 xenial kernel: [ 257.120295] ? __radix_tree_insert+0x45/0x230 Mar 14 08:42:17 xenial kernel: [ 257.120297] shmem_alloc_and_acct_page+0x73/0x1b0 Mar 14 08:42:17 xenial kernel: [ 257.120298] ? find_get_entry+0x1e/0xe0 Mar 14 08:42:17 xenial kernel: [ 257.120300] shmem_getpage_gfp+0x18f/0xbf0 Mar 14 08:42:17 xenial kernel: [ 257.120303] shmem_fault+0x9d/0x1e0 Mar 14 08:42:17 xenial kernel: [ 257.120306] ? file_update_time+0x60/0x110 Mar 14 08:42:17 xenial kernel: [ 257.120309] __do_fault+0x24/0xd0 Mar 14 08:42:17 xenial kernel: [ 257.120311] __handle_mm_fault+0x983/0x1080 Mar 14 08:42:17 xenial kernel: [ 257.120314] ? set_next_entity+0xd9/0x220 Mar 14 08:42:17 xenial kernel: [ 257.120316] handle_mm_fault+0xcc/0x1c0 Mar 14 08:42:17 xenial kernel: [ 257.120319] __do_page_fault+0x258/0x4f0 Mar 14 08:42:17 xenial kernel: [ 257.120320] do_page_fault+0x22/0x30 Mar 14 08:42:17 xenial kernel: [ 257.120323] ? page_fault+0x36/0x60 Mar 14 08:42:17 xenial kernel: [ 257.120325] page_fault+0x4c/0x60 Mar 14 08:42:17 xenial kernel: [ 257.120327] RIP: 0033:0x4493ad Mar 14 08:42:17 xenial kernel: [ 257.120328] RSP: 002b:7ffd3ff927b0 EFLAGS: 00010286 Mar 14 08:42:17 xenial kernel: [ 257.120329] RAX: c6a6a9e7 RBX: 0001a8ae9d07 RCX: 21b83c00 Mar 14 08:42:17 xenial kernel: [ 257.120330] RDX: 7f2ad911d000 RSI: 271ea9e7 RDI: 271e9660 Mar 14 08:42:17 xenial kernel: [ 257.120331] RBP: 7f2adab7 R08: 1bda3103 R09: 48373eca Mar 14 08:42:17 xenial kernel: [ 257.120331] R10: 48373eca R11: 7f2acab7 R12: Mar 14 08:42:17 xenial kernel: [ 257.120332] R13: 8309310348373eca R14: 56b63c1fe6166568 R15: 7f2acab7 Mar 14 08:42:17 xenial kernel: [ 257.120333] Mem-Info: Mar 14 08:42:17 xenial kernel: [ 257.120337] active_anon:249563 inactive_anon:83607 isolated_anon:65 Mar 14 08:42:17 xenial kernel: [ 257.120337] active_file:54 inactive_file:74 isolated_file:0 Mar 14 08:42:17 xenial kernel: [ 257.120337] unevictable:2561 dirty:0 writeback:68 unstable:0 Mar 14 08:42:17 xenial kernel: [ 257.120337] slab_reclaimable:10707 slab_unreclaimable:16622 Mar 14 08:42:17 xenial kernel: [ 257.120337] mapped:132260 shmem:332303 pagetables:2888 bounce:0 Mar 14 08:42:17 xenial kernel: [ 257.120337] free:12983
[Kernel-packages] [Bug 1750349] Re: [Hyper-V] include kvp fix for Avoid reading past allocated blocks from KVP file
Yes, please pick it in linux-azure Xenial 4.13. This is not present in current 4.13.0-1012.14 proposed. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1750349 Title: [Hyper-V] include kvp fix for Avoid reading past allocated blocks from KVP file Status in linux package in Ubuntu: Fix Committed Status in linux-azure package in Ubuntu: Triaged Status in linux source package in Bionic: Fix Committed Status in linux-azure source package in Bionic: Triaged Bug description: Please pick this upstream commit in 18.04 release. This is required if a large number of records are injected into a pool, which can cause the kvp daemon to crash. We found this to be missing from bionic server daily image. hv: kvp: Avoid reading past allocated blocks from KVP file 297d6b6e56c2977fc504c61bbeeaa21296923f89 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1750349/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1750349] Re: [Hyper-V] include kvp fix for Avoid reading past allocated blocks from KVP file
Please apply it to both kernels/releases. Thank you! -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1750349 Title: [Hyper-V] include kvp fix for Avoid reading past allocated blocks from KVP file Status in linux package in Ubuntu: Triaged Status in linux source package in Bionic: Triaged Bug description: Please pick this upstream commit in 18.04 release. This is required if a large number of records are injected into a pool, which can cause the kvp daemon to crash. We found this to be missing from bionic server daily image. hv: kvp: Avoid reading past allocated blocks from KVP file 297d6b6e56c2977fc504c61bbeeaa21296923f89 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1750349/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1750349] Re: [Hyper-V] include kvp fix for Avoid reading past allocated blocks from KVP file
** Changed in: linux (Ubuntu) Status: Incomplete => Confirmed -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1750349 Title: [Hyper-V] include kvp fix for Avoid reading past allocated blocks from KVP file Status in linux package in Ubuntu: Confirmed Bug description: Please pick this upstream commit in 18.04 release. This is required if a large number of records are injected into a pool, which can cause the kvp daemon to crash. We found this to be missing from bionic server daily image. hv: kvp: Avoid reading past allocated blocks from KVP file 297d6b6e56c2977fc504c61bbeeaa21296923f89 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1750349/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1750349] [NEW] [Hyper-V] include kvp fix for Avoid reading past allocated blocks from KVP file
Public bug reported: Please pick this upstream commit in 18.04 release. This is required if a large number of records are injected into a pool, which can cause the kvp daemon to crash. We found this to be missing from bionic server daily image. hv: kvp: Avoid reading past allocated blocks from KVP file 297d6b6e56c2977fc504c61bbeeaa21296923f89 ** Affects: linux (Ubuntu) Importance: Undecided Status: New ** Tags: hyper-v -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1750349 Title: [Hyper-V] include kvp fix for Avoid reading past allocated blocks from KVP file Status in linux package in Ubuntu: New Bug description: Please pick this upstream commit in 18.04 release. This is required if a large number of records are injected into a pool, which can cause the kvp daemon to crash. We found this to be missing from bionic server daily image. hv: kvp: Avoid reading past allocated blocks from KVP file 297d6b6e56c2977fc504c61bbeeaa21296923f89 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1750349/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1664663] Re: [Hyper-V] kvp daemon start failure on Zesty
We do not have a clear repro on this issue, but recently there have been several fixes for rescind, so those might help. Let's close this for the time being. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1664663 Title: [Hyper-V] kvp daemon start failure on Zesty Status in linux package in Ubuntu: In Progress Status in linux source package in Zesty: In Progress Bug description: Hello, On Ubuntu Server 17.04 daily from Febr 14th we see that the KVP daemon although it is enabled in systemd, it fails to start at system boot. This is shown by error: "KVP: read failed; error:9 Bad file descriptor" I then manually ran the kvp binary, it returned the KVP data, and it's also automatically loading at boot. However, this is of course not the normal behavior. 17.04 daily from Febr 14th is the first build we covered, so I cannot say if this is a regression introduced only at some point in 17.04 dailies. In syslog these are the only messages for KVP: Feb 14 08:01:22 ubuntu systemd[1]: Started Hyper-V KVP Protocol Daemon. Feb 14 08:01:22 ubuntu KVP: KVP starting; pid is:1837 Feb 14 08:01:22 ubuntu KVP: KVP LIC Version: 3.1 Feb 14 08:02:31 ubuntu KVP: read failed; error:9 Bad file descriptor systemd status: root@ubuntu:~# systemctl status hv-kvp-daemon.service ● hv-kvp-daemon.service - Hyper-V KVP Protocol Daemon Loaded: loaded (/lib/systemd/system/hv-kvp-daemon.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Tue 2017-02-14 08:02:31 PST; 1min 41s ago Main PID: 1837 (code=exited, status=1/FAILURE) CPU: 4ms Feb 14 08:01:22 ubuntu systemd[1]: Started Hyper-V KVP Protocol Daemon. Feb 14 08:01:22 ubuntu KVP[1837]: KVP starting; pid is:1837 Feb 14 08:01:22 ubuntu KVP[1837]: KVP LIC Version: 3.1 Feb 14 08:02:31 ubuntu systemd[1]: hv-kvp-daemon.service: Main process exited, code=exited, status=1/FAILURE Feb 14 08:02:31 ubuntu systemd[1]: hv-kvp-daemon.service: Unit entered failed state. Feb 14 08:02:31 ubuntu systemd[1]: hv-kvp-daemon.service: Failed with result 'exit-code'. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1664663/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1701222] Re: [Hyper-V] LIS daemons fail to start after disable/re-enable VM integration services
The same happens on 4.4.0-40 kernel, I think this goes with comment #6. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1701222 Title: [Hyper-V] LIS daemons fail to start after disable/re-enable VM integration services Status in linux package in Ubuntu: Triaged Status in linux source package in Xenial: Triaged Status in linux source package in Zesty: Triaged Bug description: Issue description: Hyper-V daemons fail to start after disable/re- enable VM integration services. Platform: host independent Affected daemons - KVP, FCOPY and VSS. Distribution name and release: Ubuntu 16.04, Ubuntu 17.04 Kernel version: 4.11.0-rc7-next-20170421 (for Ubuntu 16.04), 4.10.0-19-generic (for Ubuntu 17.04) Repro rate: 100% Steps to reproduce: 1.Start VM with Guest Services enabled (FCopy daemon starts automatically) 2.Go to File > Settings > Integration Services, uncheck Guest Services and apply (FCopy daemon will stop at this point) 3.Re-enable Guest Services from VM Settings (Fcopy daemon is not running). This is the issue. systemd monitors for the service and if we have the hook for the Guest Service, it tries to start the daemon again. systemd attempt to start any of the LIS daemons will fail, but manually executing the daemon binary, it will start the daemon. Additional Info: - the steps above can be repro'd with KVP / Data Exchange integration service as well. - Manually starting hv_fcopy_daemon works fine. - other distros (RHEL) does not have this behavior, the LIS daemons are started automatically by systemd once we re-enable the integration service. On the upstream kernel and the upstream hv daemons, these messages are recorded in syslog, once we re-enable the Guest service: HV_FCOPY: pread failed: Bad file descriptor systemd[1]: hv-fcopy-daemon.service: Main process exited, code=exited, status=1/FAILURE systemd[1]: hv-fcopy-daemon.service: Unit entered failed state. systemd[1]: hv-fcopy-daemon.service: Failed with result 'exit-code'. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1701222/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1701222] Re: [Hyper-V] LIS daemons fail to start after disable/re-enable VM integration services
We verified anything between 14.04.0 and 15.10, the thing with those releases is that even if we disable the Data Exchange integration service, the KVP daemon remains running on the VM. Only starting from 16.04 the KVP daemon stops when Data Exchange is disabled. So 16.04 is the first version with this changed behavior, but then we get to the initial issue where systemd fails to start the service automatically, but it does load manually afterwards. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1701222 Title: [Hyper-V] LIS daemons fail to start after disable/re-enable VM integration services Status in linux package in Ubuntu: Triaged Status in linux source package in Xenial: Triaged Status in linux source package in Zesty: Triaged Bug description: Issue description: Hyper-V daemons fail to start after disable/re- enable VM integration services. Platform: host independent Affected daemons - KVP, FCOPY and VSS. Distribution name and release: Ubuntu 16.04, Ubuntu 17.04 Kernel version: 4.11.0-rc7-next-20170421 (for Ubuntu 16.04), 4.10.0-19-generic (for Ubuntu 17.04) Repro rate: 100% Steps to reproduce: 1.Start VM with Guest Services enabled (FCopy daemon starts automatically) 2.Go to File > Settings > Integration Services, uncheck Guest Services and apply (FCopy daemon will stop at this point) 3.Re-enable Guest Services from VM Settings (Fcopy daemon is not running). This is the issue. systemd monitors for the service and if we have the hook for the Guest Service, it tries to start the daemon again. systemd attempt to start any of the LIS daemons will fail, but manually executing the daemon binary, it will start the daemon. Additional Info: - the steps above can be repro'd with KVP / Data Exchange integration service as well. - Manually starting hv_fcopy_daemon works fine. - other distros (RHEL) does not have this behavior, the LIS daemons are started automatically by systemd once we re-enable the integration service. On the upstream kernel and the upstream hv daemons, these messages are recorded in syslog, once we re-enable the Guest service: HV_FCOPY: pread failed: Bad file descriptor systemd[1]: hv-fcopy-daemon.service: Main process exited, code=exited, status=1/FAILURE systemd[1]: hv-fcopy-daemon.service: Unit entered failed state. systemd[1]: hv-fcopy-daemon.service: Failed with result 'exit-code'. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1701222/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1664663] Re: [Hyper-V] kvp daemon start failure on Zesty
The new test kernel based on 4.10.0-26 also has this behavior. We also checked the latest upstream and we're not seeing the failure, so let me discuss this internally to see why this fails on 4.10 but not on upstream. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1664663 Title: [Hyper-V] kvp daemon start failure on Zesty Status in linux package in Ubuntu: In Progress Status in linux source package in Zesty: In Progress Bug description: Hello, On Ubuntu Server 17.04 daily from Febr 14th we see that the KVP daemon although it is enabled in systemd, it fails to start at system boot. This is shown by error: "KVP: read failed; error:9 Bad file descriptor" I then manually ran the kvp binary, it returned the KVP data, and it's also automatically loading at boot. However, this is of course not the normal behavior. 17.04 daily from Febr 14th is the first build we covered, so I cannot say if this is a regression introduced only at some point in 17.04 dailies. In syslog these are the only messages for KVP: Feb 14 08:01:22 ubuntu systemd[1]: Started Hyper-V KVP Protocol Daemon. Feb 14 08:01:22 ubuntu KVP: KVP starting; pid is:1837 Feb 14 08:01:22 ubuntu KVP: KVP LIC Version: 3.1 Feb 14 08:02:31 ubuntu KVP: read failed; error:9 Bad file descriptor systemd status: root@ubuntu:~# systemctl status hv-kvp-daemon.service ● hv-kvp-daemon.service - Hyper-V KVP Protocol Daemon Loaded: loaded (/lib/systemd/system/hv-kvp-daemon.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Tue 2017-02-14 08:02:31 PST; 1min 41s ago Main PID: 1837 (code=exited, status=1/FAILURE) CPU: 4ms Feb 14 08:01:22 ubuntu systemd[1]: Started Hyper-V KVP Protocol Daemon. Feb 14 08:01:22 ubuntu KVP[1837]: KVP starting; pid is:1837 Feb 14 08:01:22 ubuntu KVP[1837]: KVP LIC Version: 3.1 Feb 14 08:02:31 ubuntu systemd[1]: hv-kvp-daemon.service: Main process exited, code=exited, status=1/FAILURE Feb 14 08:02:31 ubuntu systemd[1]: hv-kvp-daemon.service: Unit entered failed state. Feb 14 08:02:31 ubuntu systemd[1]: hv-kvp-daemon.service: Failed with result 'exit-code'. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1664663/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1701222] Re: [Hyper-V] LIS daemons fail to start after disable/re-enable VM integration services
I took the v4.12 kernel and compiled the LIS daemons from those sources as well. Reloading the Data Exchange service, KVP will fail with the below message. This is the same as initially reported, so nothing changed in the behavior. Not sure on the regression part, only up to the point on differences between distributions. KVP failure with v4.12 and Jul 6 01:18:55 xenial KVP: read failed; error:9 Bad file descriptor Jul 6 01:18:55 xenial systemd[1]: hv-kvp-daemon.service: Main process exited, code=exited, status=1/FAILURE Jul 6 01:18:55 xenial systemd[1]: hv-kvp-daemon.service: Unit entered failed state. Jul 6 01:18:55 xenial systemd[1]: hv-kvp-daemon.service: Failed with result 'exit-code'. After this error when systemd tries to start KVP again, if I manually do #systemctl start hv-kvp-daemon.service then the daemon will start just fine. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1701222 Title: [Hyper-V] LIS daemons fail to start after disable/re-enable VM integration services Status in linux package in Ubuntu: Triaged Status in linux source package in Xenial: Triaged Status in linux source package in Zesty: Triaged Bug description: Issue description: Hyper-V daemons fail to start after disable/re- enable VM integration services. Platform: host independent Affected daemons - KVP, FCOPY and VSS. Distribution name and release: Ubuntu 16.04, Ubuntu 17.04 Kernel version: 4.11.0-rc7-next-20170421 (for Ubuntu 16.04), 4.10.0-19-generic (for Ubuntu 17.04) Repro rate: 100% Steps to reproduce: 1.Start VM with Guest Services enabled (FCopy daemon starts automatically) 2.Go to File > Settings > Integration Services, uncheck Guest Services and apply (FCopy daemon will stop at this point) 3.Re-enable Guest Services from VM Settings (Fcopy daemon is not running). This is the issue. systemd monitors for the service and if we have the hook for the Guest Service, it tries to start the daemon again. systemd attempt to start any of the LIS daemons will fail, but manually executing the daemon binary, it will start the daemon. Additional Info: - the steps above can be repro'd with KVP / Data Exchange integration service as well. - Manually starting hv_fcopy_daemon works fine. - other distros (RHEL) does not have this behavior, the LIS daemons are started automatically by systemd once we re-enable the integration service. On the upstream kernel and the upstream hv daemons, these messages are recorded in syslog, once we re-enable the Guest service: HV_FCOPY: pread failed: Bad file descriptor systemd[1]: hv-fcopy-daemon.service: Main process exited, code=exited, status=1/FAILURE systemd[1]: hv-fcopy-daemon.service: Unit entered failed state. systemd[1]: hv-fcopy-daemon.service: Failed with result 'exit-code'. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1701222/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1664663] Re: [Hyper-V] kvp daemon start failure on Zesty
Joe, I take that back - comment #16 is incorrect. I'm seeing a call trace kvp related when using a high numbers of cores on the VM on the test kernel provided. We cannot repro that on 4.10.0-19 and nor in the latest one 4.10.0-26. Can you please apply that patch on top of current 4.10.0-26 so we can re-test that? Thank you! Call trace for reference: [ 72.265165] BUG: unable to handle kernel NULL pointer dereference at 0008 [ 72.265177] IP: hv_begin_read+0xc/0x20 [hv_vmbus] [ 72.265178] PGD 0 [ 72.265179] [ 72.265182] Oops: 0002 [#1] SMP [ 72.265783] Modules linked in: hv_utils(+) hv_storvsc aesni_intel(+) aes_x86_64 ptp hid scsi_transport_fc hv_netvsc c rypto_simd pps_core hyperv_keyboard glue_helper cryptd psmouse pata_acpi floppy fjes hv_vmbus [ 72.265798] CPU: 48 PID: 300 Comm: ksoftirqd/48 Not tainted 4.10.0-22-generic #24~lp1664663 [ 72.265800] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS 090006 05/23/2012 [ 72.265801] task: 91907d62 task.stack: b78a00e6c000 [ 72.265807] RIP: 0010:hv_begin_read+0xc/0x20 [hv_vmbus] [ 72.265809] RSP: 0018:b78a00e6fe00 EFLAGS: 00010202 [ 72.265811] RAX: RBX: 9190764ba000 RCX: 4084 [ 72.265812] RDX: 9190764ba1c0 RSI: RDI: 9190764ba120 [ 72.265813] RBP: b78a00e6fe00 R08: 0027 R09: 000193c0 [ 72.265814] R10: eac0c6e6 R11: 0010 R12: 9190764ba000 [ 72.265815] R13: 9190764ba120 R14: 86005130 R15: 0006 [ 72.265817] FS: () GS:91907e20() knlGS: [ 72.265818] CS: 0010 DS: ES: CR0: 80050033 [ 72.265820] CR2: 0008 CR3: 46a09000 CR4: 001406e0 [ 72.265823] DR0: DR1: DR2: [ 72.265824] DR3: DR6: fffe0ff0 DR7: 0400 [ 72.265825] Call Trace: [ 72.265832] vmbus_on_event+0x49/0x70 [hv_vmbus] [ 72.265840] tasklet_action+0x5e/0x110 [ 72.265847] __do_softirq+0x104/0x2af [ 72.265850] run_ksoftirqd+0x29/0x60 [ 72.265855] smpboot_thread_fn+0x10a/0x160 [ 72.265860] kthread+0x109/0x140 [ 72.265863] ? sort_range+0x30/0x30 [ 72.265867] ? kthread_create_on_node+0x60/0x60 [ 72.265870] ret_from_fork+0x2c/0x40 [ 72.265871] Code: eb f0 89 c6 48 c7 c7 70 2f 21 c0 e8 7e d0 19 c5 eb d8 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 0f 1f 44 00 00 48 8b 07 55 48 89 e5 40 08 01 00 00 00 0f ae f0 5d c3 0f 1f 84 00 00 00 00 00 0f [ 72.265903] RIP: hv_begin_read+0xc/0x20 [hv_vmbus] RSP: b78a00e6fe00 [ 72.265904] CR2: 0008 [ 72.265922] ---[ end trace 896d8fc4b37b0731 ]--- [ 72.265923] Kernel panic - not syncing: Fatal exception in interrupt [ 72.269147] Kernel Offset: 0x420 from 0x8100 (relocation range: 0x8000-0xbfff ) [ 72.269147] ---[ end Kernel panic - not syncing: Fatal exception in interrupt -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1664663 Title: [Hyper-V] kvp daemon start failure on Zesty Status in linux package in Ubuntu: In Progress Status in linux source package in Zesty: In Progress Bug description: Hello, On Ubuntu Server 17.04 daily from Febr 14th we see that the KVP daemon although it is enabled in systemd, it fails to start at system boot. This is shown by error: "KVP: read failed; error:9 Bad file descriptor" I then manually ran the kvp binary, it returned the KVP data, and it's also automatically loading at boot. However, this is of course not the normal behavior. 17.04 daily from Febr 14th is the first build we covered, so I cannot say if this is a regression introduced only at some point in 17.04 dailies. In syslog these are the only messages for KVP: Feb 14 08:01:22 ubuntu systemd[1]: Started Hyper-V KVP Protocol Daemon. Feb 14 08:01:22 ubuntu KVP: KVP starting; pid is:1837 Feb 14 08:01:22 ubuntu KVP: KVP LIC Version: 3.1 Feb 14 08:02:31 ubuntu KVP: read failed; error:9 Bad file descriptor systemd status: root@ubuntu:~# systemctl status hv-kvp-daemon.service ● hv-kvp-daemon.service - Hyper-V KVP Protocol Daemon Loaded: loaded (/lib/systemd/system/hv-kvp-daemon.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Tue 2017-02-14 08:02:31 PST; 1min 41s ago Main PID: 1837 (code=exited, status=1/FAILURE) CPU: 4ms Feb 14 08:01:22 ubuntu systemd[1]: Started Hyper-V KVP Protocol Daemon. Feb 14 08:01:22 ubuntu KVP[1837]: KVP starting; pid is:1837 Feb 14 08:01:22 ubuntu KVP[1837]: KVP LIC Version: 3.1 Feb 14 08:02:31 ubuntu systemd[1]: hv-kvp-daemon.service: Main process exited, code=exited, status=1/FAILURE Feb 14 08:02:31 ubuntu systemd[1]: hv-kvp-daemon.service: Un
[Kernel-packages] [Bug 1664663] Re: [Hyper-V] kvp daemon start failure on Zesty
Please merge the changes. Sorry for the delay on this, we did some testing and we're not seeing any issues in the test kernel. We don't have a clear repro to exercise the bug behavior, but the changes do not break the functionality. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1664663 Title: [Hyper-V] kvp daemon start failure on Zesty Status in linux package in Ubuntu: In Progress Status in linux source package in Zesty: In Progress Bug description: Hello, On Ubuntu Server 17.04 daily from Febr 14th we see that the KVP daemon although it is enabled in systemd, it fails to start at system boot. This is shown by error: "KVP: read failed; error:9 Bad file descriptor" I then manually ran the kvp binary, it returned the KVP data, and it's also automatically loading at boot. However, this is of course not the normal behavior. 17.04 daily from Febr 14th is the first build we covered, so I cannot say if this is a regression introduced only at some point in 17.04 dailies. In syslog these are the only messages for KVP: Feb 14 08:01:22 ubuntu systemd[1]: Started Hyper-V KVP Protocol Daemon. Feb 14 08:01:22 ubuntu KVP: KVP starting; pid is:1837 Feb 14 08:01:22 ubuntu KVP: KVP LIC Version: 3.1 Feb 14 08:02:31 ubuntu KVP: read failed; error:9 Bad file descriptor systemd status: root@ubuntu:~# systemctl status hv-kvp-daemon.service ● hv-kvp-daemon.service - Hyper-V KVP Protocol Daemon Loaded: loaded (/lib/systemd/system/hv-kvp-daemon.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Tue 2017-02-14 08:02:31 PST; 1min 41s ago Main PID: 1837 (code=exited, status=1/FAILURE) CPU: 4ms Feb 14 08:01:22 ubuntu systemd[1]: Started Hyper-V KVP Protocol Daemon. Feb 14 08:01:22 ubuntu KVP[1837]: KVP starting; pid is:1837 Feb 14 08:01:22 ubuntu KVP[1837]: KVP LIC Version: 3.1 Feb 14 08:02:31 ubuntu systemd[1]: hv-kvp-daemon.service: Main process exited, code=exited, status=1/FAILURE Feb 14 08:02:31 ubuntu systemd[1]: hv-kvp-daemon.service: Unit entered failed state. Feb 14 08:02:31 ubuntu systemd[1]: hv-kvp-daemon.service: Failed with result 'exit-code'. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1664663/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1701222] [NEW] [Hyper-V] LIS daemons fail to start after disable/re-enable VM integration services
Public bug reported: Issue description: Hyper-V daemons fail to start after disable/re-enable VM integration services. Platform: host independent Affected daemons - KVP, FCOPY and VSS. Distribution name and release: Ubuntu 16.04, Ubuntu 17.04 Kernel version: 4.11.0-rc7-next-20170421 (for Ubuntu 16.04), 4.10.0-19-generic (for Ubuntu 17.04) Repro rate: 100% Steps to reproduce: 1. Start VM with Guest Services enabled (FCopy daemon starts automatically) 2. Go to File > Settings > Integration Services, uncheck Guest Services and apply (FCopy daemon will stop at this point) 3. Re-enable Guest Services from VM Settings (Fcopy daemon is not running). This is the issue. systemd monitors for the service and if we have the hook for the Guest Service, it tries to start the daemon again. systemd attempt to start any of the LIS daemons will fail, but manually executing the daemon binary, it will start the daemon. Additional Info: - the steps above can be repro'd with KVP / Data Exchange integration service as well. - Manually starting hv_fcopy_daemon works fine. - other distros (RHEL) does not have this behavior, the LIS daemons are started automatically by systemd once we re-enable the integration service. On the upstream kernel and the upstream hv daemons, these messages are recorded in syslog, once we re-enable the Guest service: HV_FCOPY: pread failed: Bad file descriptor systemd[1]: hv-fcopy-daemon.service: Main process exited, code=exited, status=1/FAILURE systemd[1]: hv-fcopy-daemon.service: Unit entered failed state. systemd[1]: hv-fcopy-daemon.service: Failed with result 'exit-code'. ** Affects: linux (Ubuntu) Importance: Undecided Status: Confirmed ** Tags: hyper-v ** Changed in: linux (Ubuntu) Status: New => Confirmed -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1701222 Title: [Hyper-V] LIS daemons fail to start after disable/re-enable VM integration services Status in linux package in Ubuntu: Confirmed Bug description: Issue description: Hyper-V daemons fail to start after disable/re- enable VM integration services. Platform: host independent Affected daemons - KVP, FCOPY and VSS. Distribution name and release: Ubuntu 16.04, Ubuntu 17.04 Kernel version: 4.11.0-rc7-next-20170421 (for Ubuntu 16.04), 4.10.0-19-generic (for Ubuntu 17.04) Repro rate: 100% Steps to reproduce: 1.Start VM with Guest Services enabled (FCopy daemon starts automatically) 2.Go to File > Settings > Integration Services, uncheck Guest Services and apply (FCopy daemon will stop at this point) 3.Re-enable Guest Services from VM Settings (Fcopy daemon is not running). This is the issue. systemd monitors for the service and if we have the hook for the Guest Service, it tries to start the daemon again. systemd attempt to start any of the LIS daemons will fail, but manually executing the daemon binary, it will start the daemon. Additional Info: - the steps above can be repro'd with KVP / Data Exchange integration service as well. - Manually starting hv_fcopy_daemon works fine. - other distros (RHEL) does not have this behavior, the LIS daemons are started automatically by systemd once we re-enable the integration service. On the upstream kernel and the upstream hv daemons, these messages are recorded in syslog, once we re-enable the Guest service: HV_FCOPY: pread failed: Bad file descriptor systemd[1]: hv-fcopy-daemon.service: Main process exited, code=exited, status=1/FAILURE systemd[1]: hv-fcopy-daemon.service: Unit entered failed state. systemd[1]: hv-fcopy-daemon.service: Failed with result 'exit-code'. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1701222/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1663354] Re: [Hyper-V] SR-IOV functionality regression in 16.04 HWE proposed
Adrian's info are correct, we can close this issue. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1663354 Title: [Hyper-V] SR-IOV functionality regression in 16.04 HWE proposed Status in linux package in Ubuntu: Triaged Status in linux source package in Xenial: Triaged Bug description: Hello, In 1650059 we requested the rebase to the 4.9 kernel LIS commits. Also, from comments #7 and #8 we confirmed that the SR-IOV functionality was working as expected. This was in the test kernel build 4.8.0-33.35. Now, while testing the HWE proposed kernel for Xenial - version 4.8.0-35, we seem to have a regression for SR-IOV. Issues start from the point where the Intel driver is not loaded automatically, then even with manually inserting it, the SR-IOV VF interfaces are not detected. We need to determine if between the test kernel and the proposed one if there have been any other related LIS / SR-IOV commits, or what related ones could have caused this. Thank you! To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1663354/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1555786] Re: [Hyper-V] VM with ubuntu 32bit with linux-next does not boot
Closing item, this got resolved in upstream eventually. ** Changed in: linux (Ubuntu) Status: Incomplete => Fix Released -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1555786 Title: [Hyper-V] VM with ubuntu 32bit with linux-next does not boot Status in linux package in Ubuntu: Invalid Status in linux source package in Yakkety: Incomplete Status in linux source package in Zesty: Incomplete Bug description: We identified that at least ubuntu (let's take 15.10) does not boot if installed in the 32bit architecture, and using the linux-next upstream kernel 4.5 on it. This has been seen on other distributions as well. We took both the official linux-next branch from kernel.org and the one from kernel.ubuntu.com v4.5-rc7. For the compilation process we went either with the 4.2 kernel config file from the installed running kernel, and also built the config separately. No errors have been encountered during the build or install process of the 4.5 kernel, however at boot, the VM will just hang. There are no call traces or messages at boot to show any pottential issue. Have you seen this on your end when testing the 32bit build? Attaching the full serial log for reference, however I don't see any errors in the kernel boot process. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1555786/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1650058] Re: [Hyper-V/Azure] Please include Mellanox OFED drivers in Azure kernel and image
** Tags removed: verification-needed-yakkety ** Tags added: verification-done-yakkety -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1650058 Title: [Hyper-V/Azure] Please include Mellanox OFED drivers in Azure kernel and image Status in linux package in Ubuntu: Fix Committed Status in linux source package in Xenial: Fix Released Status in linux source package in Yakkety: Fix Committed Bug description: In order to have the correct VF driver to support SR-IOV in Azure, the Mellanox OFED distribution needs to be included in the kernel and the image. Mellanox's drivers are not upstream, but they are available from here: https://www.mellanox.com/page/products_dyn?product_family=26&mtag=linux_sw_drivers&ssn=3nnhohirh5htv6dnp1uk7tf487 While this configuration is not explicitly listed as supported in the release notes, Microsoft and Mellanox engineers are working on the corresponding Windows Server 2016 PF driver to support this VF driver in operation in Ubuntu guests. I file file a corresponding rebase request to pick up the PCI passthrough and other SR-IOV work done for the Hyper-V capabilities in the upstream 4.9 kernel. Only 64-bit support for Ubuntu 16.04's HWE kernel is needed. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1650058/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1636656] Re: [Hyper-V] netvsc: fix incorrect receive checksum offloading
** Changed in: linux (Ubuntu) Status: In Progress => Fix Released -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1636656 Title: [Hyper-V] netvsc: fix incorrect receive checksum offloading Status in linux package in Ubuntu: Fix Released Status in linux source package in Xenial: Fix Released Status in linux source package in Yakkety: Fix Released Bug description: The Hyper-V netvsc driver was looking at the incorrect status bits in the checksum info. It was setting the receive checksum unnecessary flag based on the IP header checksum being correct. The checksum flag is skb is about TCP and UDP checksum status. Because of this bug, any packet received with bad TCP checksum would be passed up the stack and to the application causing data corruption. The problem is reproducible via netcat and netem. This had a side effect of not doing receive checksum offload on IPv6. The driver was also also always doing checksum offload independent of the checksum setting done via ethtool. Signed-off-by: Stephen Hemminger https://patchwork.ozlabs.org/patch/685660/ When this patch is committed I will include the commit ID in this bug. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1636656/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1670544] Re: [Hyper-V] Rebase Hyper-V to the upstream 4.10 kernel
Thanks Tim! We performed several sanity checks with the test kernel from comment #3 and it's looking good. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1670544 Title: [Hyper-V] Rebase Hyper-V to the upstream 4.10 kernel Status in linux package in Ubuntu: Fix Released Status in linux source package in Xenial: Triaged Status in linux source package in Yakkety: In Progress Status in linux source package in Zesty: Fix Released Bug description: Catching up with upstream 4.10 Hyper-V, files: arch/x86/kernel/cpu/mshyperv.c arch/x86/include/asm/mshyperv.h arch/x86/include/uapi/asm/hyperv.h include/linux/hyperv.h drivers/hv/channel.c drivers/hv/channel_mgmt.c drivers/hv/connection.c drivers/hv/hv_balloon.c drivers/hv/hv.c drivers/hv/hv_fcopy.c drivers/hv/hv_kvp.c drivers/hv/hv_snapshot.c drivers/hv/hv_util.c drivers/hv/hv_utils_transport.c drivers/hv/hv_utils_transport.h drivers/hv/hyperv_vmbus.h drivers/hv/ring_buffer.c drivers/hv/vmbus_drv.c tools/hv/hv_fcopy_daemon.c tools/hv/hv_get_dhcp_info.sh tools/hv/hv_get_dns_info.sh tools/hv/hv_kvp_daemon.c tools/hv/hv_set_ifconfig.sh tools/hv/hv_vss_daemon.c tools/hv/lsvmbus drivers/input/serio/hyperv-keyboard.c drivers/net/hyperv/hyperv_net.h drivers/net/hyperv/netvsc.c drivers/net/hyperv/netvsc_drv.c drivers/net/hyperv/rndis_filter.c drivers/scsi/storvsc_drv.c drivers/hid/hid-hyperv.c drivers/pci/host/pci-hyperv.c drivers/video/fbdev/hyperv_fb.c drivers/uio/uio_hv_generic.c Here is the delta from 4.9 to 4.10: mshyperv.c : commit a5a1d1c2914b5316924c7893eb683a5420ebd3be : clocksource: Use a plain u64 instead of cycle_t hyperv.h : commit 433e19cf33d34bb6751c874a9c00980552fe508c : Drivers: hv: vmbus: finally fix hv_need_to_signal_on_read() hyperv.h : commit f45be72c8ec0b85263d1fe1e6c681d8c87e198e6 : hyperv: Fix spelling of HV_UNKOWN hyperv.h : commit fc76936d3ea5720a6e0948a08381b803a68deb28 : vmbus: add support for dynamic device id's hyperv.h : commit 1f6ee4e7d83586c8b10bd4f2f4346353d04ce884 : Drivers: hv: vmbus: On write cleanup the logic to interrupt the host hyperv.h : commit fa32ff6576623616c1751562edaed8c164ca5199 : Drivers: hv: ring_buffer: count on wrap around mappings in get_next_pkt_raw() (v2) channel.c : commit 1f6ee4e7d83586c8b10bd4f2f4346353d04ce884 : Drivers: hv: vmbus: On write cleanup the logic to interrupt the host channel.c : commit 3372592a140db69fd63837e81f048ab4abf8111e : Drivers: hv: vmbus: On the read path cleanup the logic to interrupt the host channel_mgmt.c : commit f45be72c8ec0b85263d1fe1e6c681d8c87e198e6 : hyperv: Fix spelling of HV_UNKOWN channel_mgmt.c : commit abd1026da4a7700a8db370947f75cd17b6ae6f76 : hv: acquire vmbus_connection.channel_mutex in vmbus_free_channels() channel_mgmt.c : commit 74198eb4a42c4a3c4fbef08fa01a291a282f7c2e : Drivers: hv: vmbus: Base host signaling strictly on the ring state connection.c : commit 95096f2fbd10186d3e78a328b327afc71428f65f : uio-hv-generic: new userspace i/o driver for VMBus hv_balloon.c : commit b3bb97b8a49f3c489134793705bc636c7883e777 : Drivers: hv: balloon: Add logging for dynamic memory operations hv_balloon.c : commit 8500096017e3a1baadbdefe8b84a99117472af46 : Drivers: hv: balloon: Fix info request to show max page count hv_balloon.c : commit 8ba8c0a111083bfe53f7a8a0e2f14fd12eb2e030 : Drivers: hv: balloon: Disable hot add when CONFIG_MEMORY_HOTPLUG is not set hv.c : commit a5a1d1c2914b5316924c7893eb683a5420ebd3be : clocksource: Use a plain u64 instead of cycle_t hv.c : commit 6ffc4b85358f6b7d252420cfa5862312cf5f83d8 : hv: change clockevents unbind tactics hv_snapshot.c : commit b357fd3908c1191f2f56e38aa77f2aecdae18bc8 : Drivers: hv: vss: Operation timeouts should match host expectation hv_snapshot.c : commit 23d2cc0c29eb0e7c6fe4cac88098306c31c40208 : Drivers: hv: vss: Improve log messages. hv_util.c : commit 3da0401b4d0e17aea7526db0235d98fa535d903e : Drivers: hv: utils: Fix the mapping between host version and protocol to use hyperv_vmbus.h : commit d7edd31ba9a661f1a3f357b43e84e84e5fad9538 : Drivers: hv: utils: reduce HV_UTIL_NEGO_TIMEOUT timeout ring_buffer.c : commit 433e19cf33d34bb6751c874a9c00980552fe508c : Drivers: hv: vmbus: finally fix hv_need_to_signal_on_read() vmbus_drv.c : commit fc76936d3ea5720a6e0948a08381b803a68deb28 : vmbus: add support for dynamic device id's vmbus_drv.c : commit f6b2db084b65b9dc0f910bc48d5f77c0e5166dc6 : vmbus: make sysfs names consistent with PCI hv_fcopy_daemon.c : commit 0c38cda64aecb4a821210bb2d3d04092c181c0ae : tools: hv: remove unnecessary header files and netlink related code hv_kvp_daemon.c : commit 0c38cda64aecb4a821210bb2d3d04092c181c0ae : tools: hv: remove unnecessary header fi
[Kernel-packages] [Bug 1664663] Re: [Hyper-V] kvp daemon start failure on Zesty
Hi Stuart, >From your comment #8, I took the 16.04.2 server ISO and did an install. This uses kernel 4.4.0-62 and after installing the linux-tools/cloud-tools, then I haven't ran into the initial issue. Where you seeing the exact message from kvp that it didn't start? Note that if the kernel is 4.4.0-62, you must explicitly use the version for the tools: #apt install linux-tools-4.4.0-62-generic linux-cloud-tools-4.4.0-62-generic -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1664663 Title: [Hyper-V] kvp daemon start failure on Zesty Status in linux package in Ubuntu: In Progress Status in linux source package in Zesty: In Progress Bug description: Hello, On Ubuntu Server 17.04 daily from Febr 14th we see that the KVP daemon although it is enabled in systemd, it fails to start at system boot. This is shown by error: "KVP: read failed; error:9 Bad file descriptor" I then manually ran the kvp binary, it returned the KVP data, and it's also automatically loading at boot. However, this is of course not the normal behavior. 17.04 daily from Febr 14th is the first build we covered, so I cannot say if this is a regression introduced only at some point in 17.04 dailies. In syslog these are the only messages for KVP: Feb 14 08:01:22 ubuntu systemd[1]: Started Hyper-V KVP Protocol Daemon. Feb 14 08:01:22 ubuntu KVP: KVP starting; pid is:1837 Feb 14 08:01:22 ubuntu KVP: KVP LIC Version: 3.1 Feb 14 08:02:31 ubuntu KVP: read failed; error:9 Bad file descriptor systemd status: root@ubuntu:~# systemctl status hv-kvp-daemon.service ● hv-kvp-daemon.service - Hyper-V KVP Protocol Daemon Loaded: loaded (/lib/systemd/system/hv-kvp-daemon.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Tue 2017-02-14 08:02:31 PST; 1min 41s ago Main PID: 1837 (code=exited, status=1/FAILURE) CPU: 4ms Feb 14 08:01:22 ubuntu systemd[1]: Started Hyper-V KVP Protocol Daemon. Feb 14 08:01:22 ubuntu KVP[1837]: KVP starting; pid is:1837 Feb 14 08:01:22 ubuntu KVP[1837]: KVP LIC Version: 3.1 Feb 14 08:02:31 ubuntu systemd[1]: hv-kvp-daemon.service: Main process exited, code=exited, status=1/FAILURE Feb 14 08:02:31 ubuntu systemd[1]: hv-kvp-daemon.service: Unit entered failed state. Feb 14 08:02:31 ubuntu systemd[1]: hv-kvp-daemon.service: Failed with result 'exit-code'. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1664663/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1664663] Re: [Hyper-V] kvp daemon start failure on Zesty
Hi Joe, Using today's ISO - zesty-server-amd64.iso from March 8th, and doing a fresh install, then installing linux-tools-generic and linux-cloud-tools-generic, I see that the KVP daemon starts at the reboot without the previous issue. The tools are running on top of kernel 4.10.0-9. However, now another issue surfaced. A recent KVP daemon patch introduced a KVP_SCRIPT_PATH definition: #define KVP_SCRIPT_PATH “/usr/libexec/hypervkvpd/” LIS KVP implementation has 3 scripts: hv_get_dns_info hv_get_dhcp_info hv_set_ifconfig These scripts are put by default under /usr/sbin, however with the above change, now these must be moved under /usr/libexec/hypervkvpd. Or of course, default to /usr/sbin from the kvp daemon source file if you want to keep the current structure. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1664663 Title: [Hyper-V] kvp daemon start failure on Zesty Status in linux package in Ubuntu: Triaged Status in linux source package in Zesty: Triaged Bug description: Hello, On Ubuntu Server 17.04 daily from Febr 14th we see that the KVP daemon although it is enabled in systemd, it fails to start at system boot. This is shown by error: "KVP: read failed; error:9 Bad file descriptor" I then manually ran the kvp binary, it returned the KVP data, and it's also automatically loading at boot. However, this is of course not the normal behavior. 17.04 daily from Febr 14th is the first build we covered, so I cannot say if this is a regression introduced only at some point in 17.04 dailies. In syslog these are the only messages for KVP: Feb 14 08:01:22 ubuntu systemd[1]: Started Hyper-V KVP Protocol Daemon. Feb 14 08:01:22 ubuntu KVP: KVP starting; pid is:1837 Feb 14 08:01:22 ubuntu KVP: KVP LIC Version: 3.1 Feb 14 08:02:31 ubuntu KVP: read failed; error:9 Bad file descriptor systemd status: root@ubuntu:~# systemctl status hv-kvp-daemon.service ● hv-kvp-daemon.service - Hyper-V KVP Protocol Daemon Loaded: loaded (/lib/systemd/system/hv-kvp-daemon.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Tue 2017-02-14 08:02:31 PST; 1min 41s ago Main PID: 1837 (code=exited, status=1/FAILURE) CPU: 4ms Feb 14 08:01:22 ubuntu systemd[1]: Started Hyper-V KVP Protocol Daemon. Feb 14 08:01:22 ubuntu KVP[1837]: KVP starting; pid is:1837 Feb 14 08:01:22 ubuntu KVP[1837]: KVP LIC Version: 3.1 Feb 14 08:02:31 ubuntu systemd[1]: hv-kvp-daemon.service: Main process exited, code=exited, status=1/FAILURE Feb 14 08:02:31 ubuntu systemd[1]: hv-kvp-daemon.service: Unit entered failed state. Feb 14 08:02:31 ubuntu systemd[1]: hv-kvp-daemon.service: Failed with result 'exit-code'. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1664663/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1664663] Re: [Hyper-V] kvp daemon start failure on Zesty
The same error appears from KVP also on the test kernel 4.8.0-22_4.8.0-22.24~lp1664663. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1664663 Title: [Hyper-V] kvp daemon start failure on Zesty Status in linux package in Ubuntu: Triaged Status in linux source package in Zesty: Triaged Bug description: Hello, On Ubuntu Server 17.04 daily from Febr 14th we see that the KVP daemon although it is enabled in systemd, it fails to start at system boot. This is shown by error: "KVP: read failed; error:9 Bad file descriptor" I then manually ran the kvp binary, it returned the KVP data, and it's also automatically loading at boot. However, this is of course not the normal behavior. 17.04 daily from Febr 14th is the first build we covered, so I cannot say if this is a regression introduced only at some point in 17.04 dailies. In syslog these are the only messages for KVP: Feb 14 08:01:22 ubuntu systemd[1]: Started Hyper-V KVP Protocol Daemon. Feb 14 08:01:22 ubuntu KVP: KVP starting; pid is:1837 Feb 14 08:01:22 ubuntu KVP: KVP LIC Version: 3.1 Feb 14 08:02:31 ubuntu KVP: read failed; error:9 Bad file descriptor systemd status: root@ubuntu:~# systemctl status hv-kvp-daemon.service ● hv-kvp-daemon.service - Hyper-V KVP Protocol Daemon Loaded: loaded (/lib/systemd/system/hv-kvp-daemon.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Tue 2017-02-14 08:02:31 PST; 1min 41s ago Main PID: 1837 (code=exited, status=1/FAILURE) CPU: 4ms Feb 14 08:01:22 ubuntu systemd[1]: Started Hyper-V KVP Protocol Daemon. Feb 14 08:01:22 ubuntu KVP[1837]: KVP starting; pid is:1837 Feb 14 08:01:22 ubuntu KVP[1837]: KVP LIC Version: 3.1 Feb 14 08:02:31 ubuntu systemd[1]: hv-kvp-daemon.service: Main process exited, code=exited, status=1/FAILURE Feb 14 08:02:31 ubuntu systemd[1]: hv-kvp-daemon.service: Unit entered failed state. Feb 14 08:02:31 ubuntu systemd[1]: hv-kvp-daemon.service: Failed with result 'exit-code'. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1664663/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1630924] Re: Kdump through NMI SMP and single core not working on Ubuntu16.10
Can we get Vivid out of the list please? I see that it is now EOL. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1630924 Title: Kdump through NMI SMP and single core not working on Ubuntu16.10 Status in linux package in Ubuntu: Fix Released Status in linux source package in Vivid: In Progress Status in linux source package in Xenial: Fix Released Status in linux source package in Yakkety: Fix Released Status in linux source package in Zesty: Fix Released Bug description: During some tests I've encountered an issue with kdump through NMI SMP and single core. After kdump configuration, when I trigger the crash through an NMI call from the host, the VM will panic, however it will not write the vmcore dump files and neither reboot. REPRO STEPS: 1. configure kdump - crashkernel=512M-:384M /boot/grub/grub.cfg - USE_KDUMP=1 /etc/default/kdump-tools 2. after configuration reboot the VM 3. check kdump status - cat /sys/kernel/kexec_* - service kdump-tools status 4. configure NMI - sysctl -w kernel.unknown_nmi_panic=1 5. trigger a crash from host - Debug-VM -Name $vmName -InjectNonMaskableInterrupt -ComputerName $hvServer -Force This case also applies to: -Ubuntu 16.10 generation 2(kernel version: 4.8.0-17-generic) -Ubuntu 16.04.1(kernel: 4.4.0-38-generic) -Ubuntu 14.04.5(kernel: 3.19.0-69-generic) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1630924/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1664663] Re: [Hyper-V] kvp daemon start failure on Zesty
Hi Joe, The error comes from the kvp daemon, which is not part of the kernel itself. Or along with the kernel-ppa are you also building linux-tools/cloud-tools? -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1664663 Title: [Hyper-V] kvp daemon start failure on Zesty Status in linux package in Ubuntu: Confirmed Status in linux source package in Zesty: Confirmed Bug description: Hello, On Ubuntu Server 17.04 daily from Febr 14th we see that the KVP daemon although it is enabled in systemd, it fails to start at system boot. This is shown by error: "KVP: read failed; error:9 Bad file descriptor" I then manually ran the kvp binary, it returned the KVP data, and it's also automatically loading at boot. However, this is of course not the normal behavior. 17.04 daily from Febr 14th is the first build we covered, so I cannot say if this is a regression introduced only at some point in 17.04 dailies. In syslog these are the only messages for KVP: Feb 14 08:01:22 ubuntu systemd[1]: Started Hyper-V KVP Protocol Daemon. Feb 14 08:01:22 ubuntu KVP: KVP starting; pid is:1837 Feb 14 08:01:22 ubuntu KVP: KVP LIC Version: 3.1 Feb 14 08:02:31 ubuntu KVP: read failed; error:9 Bad file descriptor systemd status: root@ubuntu:~# systemctl status hv-kvp-daemon.service ● hv-kvp-daemon.service - Hyper-V KVP Protocol Daemon Loaded: loaded (/lib/systemd/system/hv-kvp-daemon.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Tue 2017-02-14 08:02:31 PST; 1min 41s ago Main PID: 1837 (code=exited, status=1/FAILURE) CPU: 4ms Feb 14 08:01:22 ubuntu systemd[1]: Started Hyper-V KVP Protocol Daemon. Feb 14 08:01:22 ubuntu KVP[1837]: KVP starting; pid is:1837 Feb 14 08:01:22 ubuntu KVP[1837]: KVP LIC Version: 3.1 Feb 14 08:02:31 ubuntu systemd[1]: hv-kvp-daemon.service: Main process exited, code=exited, status=1/FAILURE Feb 14 08:02:31 ubuntu systemd[1]: hv-kvp-daemon.service: Unit entered failed state. Feb 14 08:02:31 ubuntu systemd[1]: hv-kvp-daemon.service: Failed with result 'exit-code'. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1664663/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1630924] Re: Kdump through NMI SMP and single core not working on Ubuntu16.10
Verified the following proposed kernels and confirm this as fixed in: On Gen1VM: 16.04.1 with 4.4.0-63.67 On both Gen1 and Gen2VM: 16.10 with 4.8.0-38.49 Thank you! ** Tags removed: verification-needed-xenial verification-needed-yakkety ** Tags added: verification-done-xenial verification-done-yakkety -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1630924 Title: Kdump through NMI SMP and single core not working on Ubuntu16.10 Status in linux package in Ubuntu: In Progress Status in linux source package in Vivid: In Progress Status in linux source package in Xenial: Fix Committed Status in linux source package in Yakkety: Fix Committed Status in linux source package in Zesty: In Progress Bug description: During some tests I've encountered an issue with kdump through NMI SMP and single core. After kdump configuration, when I trigger the crash through an NMI call from the host, the VM will panic, however it will not write the vmcore dump files and neither reboot. REPRO STEPS: 1. configure kdump - crashkernel=512M-:384M /boot/grub/grub.cfg - USE_KDUMP=1 /etc/default/kdump-tools 2. after configuration reboot the VM 3. check kdump status - cat /sys/kernel/kexec_* - service kdump-tools status 4. configure NMI - sysctl -w kernel.unknown_nmi_panic=1 5. trigger a crash from host - Debug-VM -Name $vmName -InjectNonMaskableInterrupt -ComputerName $hvServer -Force This case also applies to: -Ubuntu 16.10 generation 2(kernel version: 4.8.0-17-generic) -Ubuntu 16.04.1(kernel: 4.4.0-38-generic) -Ubuntu 14.04.5(kernel: 3.19.0-69-generic) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1630924/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1664663] Re: [Hyper-V] kvp daemon start failure on Zesty
** Changed in: linux (Ubuntu) Status: Incomplete => Confirmed -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1664663 Title: [Hyper-V] kvp daemon start failure on Zesty Status in linux package in Ubuntu: Confirmed Bug description: Hello, On Ubuntu Server 17.04 daily from Febr 14th we see that the KVP daemon although it is enabled in systemd, it fails to start at system boot. This is shown by error: "KVP: read failed; error:9 Bad file descriptor" I then manually ran the kvp binary, it returned the KVP data, and it's also automatically loading at boot. However, this is of course not the normal behavior. 17.04 daily from Febr 14th is the first build we covered, so I cannot say if this is a regression introduced only at some point in 17.04 dailies. In syslog these are the only messages for KVP: Feb 14 08:01:22 ubuntu systemd[1]: Started Hyper-V KVP Protocol Daemon. Feb 14 08:01:22 ubuntu KVP: KVP starting; pid is:1837 Feb 14 08:01:22 ubuntu KVP: KVP LIC Version: 3.1 Feb 14 08:02:31 ubuntu KVP: read failed; error:9 Bad file descriptor systemd status: root@ubuntu:~# systemctl status hv-kvp-daemon.service ● hv-kvp-daemon.service - Hyper-V KVP Protocol Daemon Loaded: loaded (/lib/systemd/system/hv-kvp-daemon.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Tue 2017-02-14 08:02:31 PST; 1min 41s ago Main PID: 1837 (code=exited, status=1/FAILURE) CPU: 4ms Feb 14 08:01:22 ubuntu systemd[1]: Started Hyper-V KVP Protocol Daemon. Feb 14 08:01:22 ubuntu KVP[1837]: KVP starting; pid is:1837 Feb 14 08:01:22 ubuntu KVP[1837]: KVP LIC Version: 3.1 Feb 14 08:02:31 ubuntu systemd[1]: hv-kvp-daemon.service: Main process exited, code=exited, status=1/FAILURE Feb 14 08:02:31 ubuntu systemd[1]: hv-kvp-daemon.service: Unit entered failed state. Feb 14 08:02:31 ubuntu systemd[1]: hv-kvp-daemon.service: Failed with result 'exit-code'. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1664663/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1664663] [NEW] [Hyper-V] kvp daemon start failure on Zesty
Public bug reported: Hello, On Ubuntu Server 17.04 daily from Febr 14th we see that the KVP daemon although it is enabled in systemd, it fails to start at system boot. This is shown by error: "KVP: read failed; error:9 Bad file descriptor" I then manually ran the kvp binary, it returned the KVP data, and it's also automatically loading at boot. However, this is of course not the normal behavior. 17.04 daily from Febr 14th is the first build we covered, so I cannot say if this is a regression introduced only at some point in 17.04 dailies. In syslog these are the only messages for KVP: Feb 14 08:01:22 ubuntu systemd[1]: Started Hyper-V KVP Protocol Daemon. Feb 14 08:01:22 ubuntu KVP: KVP starting; pid is:1837 Feb 14 08:01:22 ubuntu KVP: KVP LIC Version: 3.1 Feb 14 08:02:31 ubuntu KVP: read failed; error:9 Bad file descriptor systemd status: root@ubuntu:~# systemctl status hv-kvp-daemon.service ● hv-kvp-daemon.service - Hyper-V KVP Protocol Daemon Loaded: loaded (/lib/systemd/system/hv-kvp-daemon.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Tue 2017-02-14 08:02:31 PST; 1min 41s ago Main PID: 1837 (code=exited, status=1/FAILURE) CPU: 4ms Feb 14 08:01:22 ubuntu systemd[1]: Started Hyper-V KVP Protocol Daemon. Feb 14 08:01:22 ubuntu KVP[1837]: KVP starting; pid is:1837 Feb 14 08:01:22 ubuntu KVP[1837]: KVP LIC Version: 3.1 Feb 14 08:02:31 ubuntu systemd[1]: hv-kvp-daemon.service: Main process exited, code=exited, status=1/FAILURE Feb 14 08:02:31 ubuntu systemd[1]: hv-kvp-daemon.service: Unit entered failed state. Feb 14 08:02:31 ubuntu systemd[1]: hv-kvp-daemon.service: Failed with result 'exit-code'. ** Affects: linux (Ubuntu) Importance: Undecided Status: Incomplete ** Tags: hyper-v -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1664663 Title: [Hyper-V] kvp daemon start failure on Zesty Status in linux package in Ubuntu: Incomplete Bug description: Hello, On Ubuntu Server 17.04 daily from Febr 14th we see that the KVP daemon although it is enabled in systemd, it fails to start at system boot. This is shown by error: "KVP: read failed; error:9 Bad file descriptor" I then manually ran the kvp binary, it returned the KVP data, and it's also automatically loading at boot. However, this is of course not the normal behavior. 17.04 daily from Febr 14th is the first build we covered, so I cannot say if this is a regression introduced only at some point in 17.04 dailies. In syslog these are the only messages for KVP: Feb 14 08:01:22 ubuntu systemd[1]: Started Hyper-V KVP Protocol Daemon. Feb 14 08:01:22 ubuntu KVP: KVP starting; pid is:1837 Feb 14 08:01:22 ubuntu KVP: KVP LIC Version: 3.1 Feb 14 08:02:31 ubuntu KVP: read failed; error:9 Bad file descriptor systemd status: root@ubuntu:~# systemctl status hv-kvp-daemon.service ● hv-kvp-daemon.service - Hyper-V KVP Protocol Daemon Loaded: loaded (/lib/systemd/system/hv-kvp-daemon.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Tue 2017-02-14 08:02:31 PST; 1min 41s ago Main PID: 1837 (code=exited, status=1/FAILURE) CPU: 4ms Feb 14 08:01:22 ubuntu systemd[1]: Started Hyper-V KVP Protocol Daemon. Feb 14 08:01:22 ubuntu KVP[1837]: KVP starting; pid is:1837 Feb 14 08:01:22 ubuntu KVP[1837]: KVP LIC Version: 3.1 Feb 14 08:02:31 ubuntu systemd[1]: hv-kvp-daemon.service: Main process exited, code=exited, status=1/FAILURE Feb 14 08:02:31 ubuntu systemd[1]: hv-kvp-daemon.service: Unit entered failed state. Feb 14 08:02:31 ubuntu systemd[1]: hv-kvp-daemon.service: Failed with result 'exit-code'. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1664663/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1663354] Re: [Hyper-V] SR-IOV functionality regression in 16.04 HWE proposed
Hi Joe, The bug exists only in the hwe proposed kernel 4.8.0-33.35. SR-IOV does indeed work on the latest yakkety proposed - 4.8.0.38.49. On 16.04.1 proposed 4.4.0.63.67 (lts-xenial) we also successfully tested SR-IOV. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1663354 Title: [Hyper-V] SR-IOV functionality regression in 16.04 HWE proposed Status in linux package in Ubuntu: In Progress Status in linux source package in Xenial: In Progress Bug description: Hello, In 1650059 we requested the rebase to the 4.9 kernel LIS commits. Also, from comments #7 and #8 we confirmed that the SR-IOV functionality was working as expected. This was in the test kernel build 4.8.0-33.35. Now, while testing the HWE proposed kernel for Xenial - version 4.8.0-35, we seem to have a regression for SR-IOV. Issues start from the point where the Intel driver is not loaded automatically, then even with manually inserting it, the SR-IOV VF interfaces are not detected. We need to determine if between the test kernel and the proposed one if there have been any other related LIS / SR-IOV commits, or what related ones could have caused this. Thank you! To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1663354/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1650059] Re: [Hyper-V] Rebase Hyper-V in 16.04 and 16.10 to the the upstream 4.9 kernel
** Tags removed: verification-needed-xenial ** Tags added: verification-done-xenial -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1650059 Title: [Hyper-V] Rebase Hyper-V in 16.04 and 16.10 to the the upstream 4.9 kernel Status in linux package in Ubuntu: Fix Released Status in linux source package in Xenial: Fix Committed Status in linux source package in Yakkety: Fix Committed Status in linux source package in Zesty: Fix Released Bug description: The following files comprise Hyper-V support in the upstream kernel: arch/x86/kernel/cpu/mshyperv.c arch/x86/include/asm/mshyperv.h arch/x86/include/uapi/asm/hyperv.h include/linux/hyperv.h drivers/hv/channel.c drivers/hv/channel_mgmt.c drivers/hv/connection.c drivers/hv/hv_balloon.c drivers/hv/hv.c drivers/hv/hv_fcopy.c drivers/hv/hv_kvp.c drivers/hv/hv_snapshot.c drivers/hv/hv_util.c drivers/hv/hv_utils_transport.c drivers/hv/hv_utils_transport.h drivers/hv/hyperv_vmbus.h drivers/hv/ring_buffer.c drivers/hv/vmbus_drv.c tools/hv/hv_fcopy_daemon.c tools/hv/hv_get_dhcp_info.sh tools/hv/hv_get_dns_info.sh tools/hv/hv_kvp_daemon.c tools/hv/hv_set_ifconfig.sh tools/hv/hv_vss_daemon.c tools/hv/lsvmbus drivers/input/serio/hyperv-keyboard.c drivers/net/hyperv/hyperv_net.h drivers/net/hyperv/netvsc.c drivers/net/hyperv/netvsc_drv.c drivers/net/hyperv/rndis_filter.c drivers/scsi/storvsc_drv.c drivers/hid/hid-hyperv.c drivers/pci/host/pci-hyperv.c drivers/video/fbdev/hyperv_fb.c The following commits are upstream in the 4.9 kernel release: mshyperv.c : commit 186f43608a5c827f8284fe4559225b4dccaa49ef : x86/kernel: Audit and remove any unnecessary uses of module.h hyperv.h : commit 509879bdb30b8e12bd0b3cb0bc8429f01478df4b : Drivers: hv: Introduce a policy for controlling channel affinity hyperv.h : commit e7fca5d860aeeb1e606448f5191cea8d925cc7a3 : Drivers: hv: get rid of id in struct vmbus_channel hyperv.h : commit 0f98829a99850836cf7c2cc9fbf1d7ce0f795780 : Drivers: hv: vmbus: suppress some "hv_vmbus: Unknown GUID" warnings hyperv.h : commit 8e1d260738ca89bc7c87444f95f04a026d12b496 : Drivers: hv: utils: Support TimeSync version 4.0 protocol samples. hyperv.h : commit 638fea33aee858cc665297a76f0039e95a28ce0c : Drivers: hv: vmbus: fix the race when querying & updating the percpu list channel.c : commit 3724287c0ec472815ebe5ae3790f77965c6aa557 : Drivers: hv: vmbus: Implement a mechanism to tag the channel for low latency channel.c : commit 4d63763296ab7865a98bc29cc7d77145815ef89f : Drivers: hv: get rid of redundant messagecount in create_gpadl_header() channel.c : commit 638fea33aee858cc665297a76f0039e95a28ce0c : Drivers: hv: vmbus: fix the race when querying & updating the percpu list channel.c : commit ccef9bcc02ee63ac171ea9f0d51e04b3e55b3a12 : Drivers: hv: vmbus: Enable explicit signaling policy for NIC channels channel_mgmt.c : commit 638fea33aee858cc665297a76f0039e95a28ce0c : Drivers: hv: vmbus: fix the race when querying & updating the percpu list channel_mgmt.c : commit e7fca5d860aeeb1e606448f5191cea8d925cc7a3 : Drivers: hv: get rid of id in struct vmbus_channel connection.c : commit 8de0d7e951826d7592e0ba1da655b175c4aa0923 : Drivers: hv: vmbus: Reduce the delay between retries in vmbus_post_msg() hv_balloon.c : commit eece30b9f0046cee810a2c7caa2247f3f8dc85e2 : Drivers: hv: balloon: replace ha_region_mutex with spinlock hv_balloon.c : commit b605c2d913589c448d4a6887262bb8e99da12009 : Drivers: hv: balloon: Use available memory value in pressure report hv.c : commit a9f61ca793becabdefab03b77568d6c6f8c1bc79 : Drivers: hv: avoid vfree() on crash mshyperv.c : commit 186f43608a5c827f8284fe4559225b4dccaa49ef : x86/kernel: Audit and remove any unnecessary uses of module.h hyperv.h : commit 509879bdb30b8e12bd0b3cb0bc8429f01478df4b : Drivers: hv: Introduce a policy for controlling channel affinity hyperv.h : commit e7fca5d860aeeb1e606448f5191cea8d925cc7a3 : Drivers: hv: get rid of id in struct vmbus_channel hyperv.h : commit 0f98829a99850836cf7c2cc9fbf1d7ce0f795780 : Drivers: hv: vmbus: suppress some "hv_vmbus: Unknown GUID" warnings hyperv.h : commit 8e1d260738ca89bc7c87444f95f04a026d12b496 : Drivers: hv: utils: Support TimeSync version 4.0 protocol samples. hyperv.h : commit 638fea33aee858cc665297a76f0039e95a28ce0c : Drivers: hv: vmbus: fix the race when querying & updating the percpu list channel.c : commit 3724287c0ec472815ebe5ae3790f77965c6aa557 : Drivers: hv: vmbus: Implement a mechanism to tag the channel for low latency channel.c : commit 4d63763296ab7865a98bc29cc7d77145815ef89f : Drivers: hv: get rid of redundant messagecount in create_gpadl_header() channel.c : commit 638fea33aee858cc665297a76f0039e95a28ce0c
[Kernel-packages] [Bug 1663354] [NEW] [Hyper-V] SR-IOV functionality regression in 16.04 HWE proposed
Public bug reported: Hello, In 1650059 we requested the rebase to the 4.9 kernel LIS commits. Also, from comments #7 and #8 we confirmed that the SR-IOV functionality was working as expected. This was in the test kernel build 4.8.0-33.35. Now, while testing the HWE proposed kernel for Xenial - version 4.8.0-35, we seem to have a regression for SR-IOV. Issues start from the point where the Intel driver is not loaded automatically, then even with manually inserting it, the SR-IOV VF interfaces are not detected. We need to determine if between the test kernel and the proposed one if there have been any other related LIS / SR-IOV commits, or what related ones could have caused this. Thank you! ** Affects: linux (Ubuntu) Importance: Undecided Status: Confirmed ** Tags: kernel-da-key kernel-hyper-v xenial ** Changed in: linux (Ubuntu) Status: New => Confirmed -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1663354 Title: [Hyper-V] SR-IOV functionality regression in 16.04 HWE proposed Status in linux package in Ubuntu: Confirmed Bug description: Hello, In 1650059 we requested the rebase to the 4.9 kernel LIS commits. Also, from comments #7 and #8 we confirmed that the SR-IOV functionality was working as expected. This was in the test kernel build 4.8.0-33.35. Now, while testing the HWE proposed kernel for Xenial - version 4.8.0-35, we seem to have a regression for SR-IOV. Issues start from the point where the Intel driver is not loaded automatically, then even with manually inserting it, the SR-IOV VF interfaces are not detected. We need to determine if between the test kernel and the proposed one if there have been any other related LIS / SR-IOV commits, or what related ones could have caused this. Thank you! To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1663354/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1636656] Re: [Hyper-V] netvsc: fix incorrect receive checksum offloading
Hi Joe, For the v2 test kernel for Trusty from comment #11: The kernels 3.13 and 3.19 at least from our testing might not be affected by this bug as those don't have any receive checksum offloading, and therefore the patch here is not applicable. Even with the cherry-pick, the behavior with only the patch for "fix incorrect receive checksum offloading" and the related dependencies, a file copy over scp is not completing. So please do not backport this patch to Trusty / kernel 3.13 and/or 3.19. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1636656 Title: [Hyper-V] netvsc: fix incorrect receive checksum offloading Status in linux package in Ubuntu: In Progress Status in linux source package in Trusty: In Progress Status in linux source package in Vivid: Fix Released Status in linux source package in Xenial: Fix Released Status in linux source package in Yakkety: Fix Committed Bug description: The Hyper-V netvsc driver was looking at the incorrect status bits in the checksum info. It was setting the receive checksum unnecessary flag based on the IP header checksum being correct. The checksum flag is skb is about TCP and UDP checksum status. Because of this bug, any packet received with bad TCP checksum would be passed up the stack and to the application causing data corruption. The problem is reproducible via netcat and netem. This had a side effect of not doing receive checksum offload on IPv6. The driver was also also always doing checksum offload independent of the checksum setting done via ethtool. Signed-off-by: Stephen Hemminger https://patchwork.ozlabs.org/patch/685660/ When this patch is committed I will include the commit ID in this bug. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1636656/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1630924] Re: Kdump through NMI SMP and single core not working on Ubuntu16.10
Hi Joe, The test kernels with the commits are looking fine, I was able to successfully trigger and complete a kdump over NMI. Tested Xenial and Yakkety on WS2016 and WS2012R2. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1630924 Title: Kdump through NMI SMP and single core not working on Ubuntu16.10 Status in linux package in Ubuntu: In Progress Status in linux source package in Vivid: In Progress Status in linux source package in Xenial: In Progress Status in linux source package in Yakkety: In Progress Status in linux source package in Zesty: In Progress Bug description: During some tests I've encountered an issue with kdump through NMI SMP and single core. After kdump configuration, when I trigger the crash through an NMI call from the host, the VM will panic, however it will not write the vmcore dump files and neither reboot. REPRO STEPS: 1. configure kdump - crashkernel=512M-:384M /boot/grub/grub.cfg - USE_KDUMP=1 /etc/default/kdump-tools 2. after configuration reboot the VM 3. check kdump status - cat /sys/kernel/kexec_* - service kdump-tools status 4. configure NMI - sysctl -w kernel.unknown_nmi_panic=1 5. trigger a crash from host - Debug-VM -Name $vmName -InjectNonMaskableInterrupt -ComputerName $hvServer -Force This case also applies to: -Ubuntu 16.10 generation 2(kernel version: 4.8.0-17-generic) -Ubuntu 16.04.1(kernel: 4.4.0-38-generic) -Ubuntu 14.04.5(kernel: 3.19.0-69-generic) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1630924/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1630924] Re: Kdump through NMI SMP and single core not working on Ubuntu16.10
Haven't checked mainline, but it is in upstream. Please find it here - http://git.kernel.org/cgit/linux/kernel/git/next/linux- next.git/commit/?id=56ef6718a -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1630924 Title: Kdump through NMI SMP and single core not working on Ubuntu16.10 Status in linux package in Ubuntu: Confirmed Status in linux source package in Vivid: Confirmed Status in linux source package in Xenial: Confirmed Status in linux source package in Yakkety: Confirmed Bug description: During some tests I've encountered an issue with kdump through NMI SMP and single core. After kdump configuration, when I trigger the crash through an NMI call from the host, the VM will panic, however it will not write the vmcore dump files and neither reboot. REPRO STEPS: 1. configure kdump - crashkernel=512M-:384M /boot/grub/grub.cfg - USE_KDUMP=1 /etc/default/kdump-tools 2. after configuration reboot the VM 3. check kdump status - cat /sys/kernel/kexec_* - service kdump-tools status 4. configure NMI - sysctl -w kernel.unknown_nmi_panic=1 5. trigger a crash from host - Debug-VM -Name $vmName -InjectNonMaskableInterrupt -ComputerName $hvServer -Force This case also applies to: -Ubuntu 16.10 generation 2(kernel version: 4.8.0-17-generic) -Ubuntu 16.04.1(kernel: 4.4.0-38-generic) -Ubuntu 14.04.5(kernel: 3.19.0-69-generic) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1630924/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1400319] Re: [Hyper-V] Kernel panic not functional on 32bit Ubuntu 14.10, 15.04, and 15.10
** Changed in: linux (Ubuntu) Status: In Progress => Fix Released -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1400319 Title: [Hyper-V] Kernel panic not functional on 32bit Ubuntu 14.10, 15.04, and 15.10 Status in linux package in Ubuntu: Fix Released Status in linux source package in Xenial: Fix Released Status in linux source package in Yakkety: Fix Released Bug description: While testing the final build of 14.10 32bit we found that kernel panic cannot be activated for an installation on a Hyper-V VM. Repro rate: 100% Repro details: Hyper-V: Server 2012 R2 VM: Ubuntu 14.10 32bit Kdump is enabled in the config file at /etc/default/kdump-tools Different crashkernel values used in grub.cfg – 128M-:64M | 256M-:128m | 384M-:256M VM settings: 2 cores, various RAM sizes attempted: 1, 2 or 4 GB – this in combination with the values for crashkernel. Trying to start the kdump service: root@ubuntu1410i386:~# /etc/init.d/kdump-tools start Starting kdump-tools: Could not find a free area of memory of 0x9f000 bytes... locate_hole failed * failed to load kdump kernel --- root@ubuntu1410i386:~# cat /sys/kernel/kexec_crash_loaded 0 If the conversion from hex to dec is right, the mentioned memory mapping of 0x9f000 bytes is equal to 651264 (bytes), so under 1MB. This is not then related to the RAM allocation nor the crashkernel value used. --- AlsaDevices: Error: command ['ls', '-l', '/dev/snd/'] failed with exit code 2: ls: cannot access /dev/snd/: No such file or directory AplayDevices: Error: [Errno 2] No such file or directory ApportVersion: 2.14.7-0ubuntu8 Architecture: i386 ArecordDevices: Error: [Errno 2] No such file or directory CRDA: Error: [Errno 2] No such file or directory DistroRelease: Ubuntu 14.10 HibernationDevice: RESUME=UUID=5a5d0aa4-b8ee-4bf7-b1b9-761b7d1550b6 InstallationDate: Installed on 2014-10-31 (37 days ago) InstallationMedia: Ubuntu-Server 14.10 "Utopic Unicorn" - Release i386 (20141022.2) IwConfig: lono wireless extensions. eth0 no wireless extensions. Lsusb: Error: command ['lsusb'] failed with exit code 1: unable to initialize libusb: -99 MachineType: Microsoft Corporation Virtual Machine Package: linux (not installed) PciMultimedia: ProcEnviron: TERM=xterm PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash ProcFB: 0 hyperv_fb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.16.0-24-generic root=UUID=83fb481a-8898-4adc-bf31-4e160f5f0ce8 ro crashkernel=128M-:64M ProcVersionSignature: Ubuntu 3.16.0-24.32-generic 3.16.4 RelatedPackageVersions: linux-restricted-modules-3.16.0-24-generic N/A linux-backports-modules-3.16.0-24-generic N/A linux-firmware 1.138 RfKill: Error: [Errno 2] No such file or directory Tags: utopic Uname: Linux 3.16.0-24-generic i686 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: WifiSyslog: Dec 8 08:16:46 ubuntu1410i386 dhclient: DHCPREQUEST of 10.226.59.102 on eth0 to 10.184.232.100 port 67 (xid=0x4b67ffa3) Dec 8 08:16:46 ubuntu1410i386 dhclient: DHCPACK of 10.226.59.102 from 10.184.232.100 Dec 8 08:16:47 ubuntu1410i386 dhclient: bound to 10.226.59.102 -- renewal in 13914 seconds. Dec 8 10:10:47 ubuntu1410i386 kernel: [1840786.031060] init: tty1 main process ended, respawning _MarkForUpload: True dmi.bios.date: 05/23/2012 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 090006 dmi.board.name: Virtual Machine dmi.board.vendor: Microsoft Corporation dmi.board.version: 7.0 dmi.chassis.asset.tag: 7176-0455-3377-8479-3268-6677-66 dmi.chassis.type: 3 dmi.chassis.vendor: Microsoft Corporation dmi.chassis.version: 7.0 dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr090006:bd05/23/2012:svnMicrosoftCorporation:pnVirtualMachine:pvr7.0:rvnMicrosoftCorporation:rnVirtualMachine:rvr7.0:cvnMicrosoftCorporation:ct3:cvr7.0: dmi.product.name: Virtual Machine dmi.product.version: 7.0 dmi.sys.vendor: Microsoft Corporation To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1400319/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1630924] Re: Kdump through NMI SMP and single core not working on Ubuntu16.10
Please build a test kernel with these 2 commits: 59107e2f48831daedc46973ce4988605ab066de3 56ef6718a1d8d77745033c5291e025ce18504159 Thank you! -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1630924 Title: Kdump through NMI SMP and single core not working on Ubuntu16.10 Status in linux package in Ubuntu: Confirmed Status in linux source package in Yakkety: Confirmed Bug description: During some tests I've encountered an issue with kdump through NMI SMP and single core. After kdump configuration, when I trigger the crash through an NMI call from the host, the VM will panic, however it will not write the vmcore dump files and neither reboot. REPRO STEPS: 1. configure kdump - crashkernel=512M-:384M /boot/grub/grub.cfg - USE_KDUMP=1 /etc/default/kdump-tools 2. after configuration reboot the VM 3. check kdump status - cat /sys/kernel/kexec_* - service kdump-tools status 4. configure NMI - sysctl -w kernel.unknown_nmi_panic=1 5. trigger a crash from host - Debug-VM -Name $vmName -InjectNonMaskableInterrupt -ComputerName $hvServer -Force This case also applies to: -Ubuntu 16.10 generation 2(kernel version: 4.8.0-17-generic) -Ubuntu 16.04.1(kernel: 4.4.0-38-generic) -Ubuntu 14.04.5(kernel: 3.19.0-69-generic) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1630924/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1650059] Re: [Hyper-V] Rebase Hyper-V in 16.04 and 16.10 to the the upstream 4.9 kernel
Hi Tim, We've verified the 2 updated test kernels hv.2 from comment #7 and network performance is back to the maximum throughput. Also, the bond script is present and functional. Thank you! -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1650059 Title: [Hyper-V] Rebase Hyper-V in 16.04 and 16.10 to the the upstream 4.9 kernel Status in linux package in Ubuntu: Triaged Status in linux source package in Xenial: Triaged Status in linux source package in Yakkety: In Progress Bug description: The following files comprise Hyper-V support in the upstream kernel: arch/x86/kernel/cpu/mshyperv.c arch/x86/include/asm/mshyperv.h arch/x86/include/uapi/asm/hyperv.h include/linux/hyperv.h drivers/hv/channel.c drivers/hv/channel_mgmt.c drivers/hv/connection.c drivers/hv/hv_balloon.c drivers/hv/hv.c drivers/hv/hv_fcopy.c drivers/hv/hv_kvp.c drivers/hv/hv_snapshot.c drivers/hv/hv_util.c drivers/hv/hv_utils_transport.c drivers/hv/hv_utils_transport.h drivers/hv/hyperv_vmbus.h drivers/hv/ring_buffer.c drivers/hv/vmbus_drv.c tools/hv/hv_fcopy_daemon.c tools/hv/hv_get_dhcp_info.sh tools/hv/hv_get_dns_info.sh tools/hv/hv_kvp_daemon.c tools/hv/hv_set_ifconfig.sh tools/hv/hv_vss_daemon.c tools/hv/lsvmbus drivers/input/serio/hyperv-keyboard.c drivers/net/hyperv/hyperv_net.h drivers/net/hyperv/netvsc.c drivers/net/hyperv/netvsc_drv.c drivers/net/hyperv/rndis_filter.c drivers/scsi/storvsc_drv.c drivers/hid/hid-hyperv.c drivers/pci/host/pci-hyperv.c drivers/video/fbdev/hyperv_fb.c The following commits are upstream in the 4.9 kernel release: mshyperv.c : commit 186f43608a5c827f8284fe4559225b4dccaa49ef : x86/kernel: Audit and remove any unnecessary uses of module.h hyperv.h : commit 509879bdb30b8e12bd0b3cb0bc8429f01478df4b : Drivers: hv: Introduce a policy for controlling channel affinity hyperv.h : commit e7fca5d860aeeb1e606448f5191cea8d925cc7a3 : Drivers: hv: get rid of id in struct vmbus_channel hyperv.h : commit 0f98829a99850836cf7c2cc9fbf1d7ce0f795780 : Drivers: hv: vmbus: suppress some "hv_vmbus: Unknown GUID" warnings hyperv.h : commit 8e1d260738ca89bc7c87444f95f04a026d12b496 : Drivers: hv: utils: Support TimeSync version 4.0 protocol samples. hyperv.h : commit 638fea33aee858cc665297a76f0039e95a28ce0c : Drivers: hv: vmbus: fix the race when querying & updating the percpu list channel.c : commit 3724287c0ec472815ebe5ae3790f77965c6aa557 : Drivers: hv: vmbus: Implement a mechanism to tag the channel for low latency channel.c : commit 4d63763296ab7865a98bc29cc7d77145815ef89f : Drivers: hv: get rid of redundant messagecount in create_gpadl_header() channel.c : commit 638fea33aee858cc665297a76f0039e95a28ce0c : Drivers: hv: vmbus: fix the race when querying & updating the percpu list channel.c : commit ccef9bcc02ee63ac171ea9f0d51e04b3e55b3a12 : Drivers: hv: vmbus: Enable explicit signaling policy for NIC channels channel_mgmt.c : commit 638fea33aee858cc665297a76f0039e95a28ce0c : Drivers: hv: vmbus: fix the race when querying & updating the percpu list channel_mgmt.c : commit e7fca5d860aeeb1e606448f5191cea8d925cc7a3 : Drivers: hv: get rid of id in struct vmbus_channel connection.c : commit 8de0d7e951826d7592e0ba1da655b175c4aa0923 : Drivers: hv: vmbus: Reduce the delay between retries in vmbus_post_msg() hv_balloon.c : commit eece30b9f0046cee810a2c7caa2247f3f8dc85e2 : Drivers: hv: balloon: replace ha_region_mutex with spinlock hv_balloon.c : commit b605c2d913589c448d4a6887262bb8e99da12009 : Drivers: hv: balloon: Use available memory value in pressure report hv.c : commit a9f61ca793becabdefab03b77568d6c6f8c1bc79 : Drivers: hv: avoid vfree() on crash mshyperv.c : commit 186f43608a5c827f8284fe4559225b4dccaa49ef : x86/kernel: Audit and remove any unnecessary uses of module.h hyperv.h : commit 509879bdb30b8e12bd0b3cb0bc8429f01478df4b : Drivers: hv: Introduce a policy for controlling channel affinity hyperv.h : commit e7fca5d860aeeb1e606448f5191cea8d925cc7a3 : Drivers: hv: get rid of id in struct vmbus_channel hyperv.h : commit 0f98829a99850836cf7c2cc9fbf1d7ce0f795780 : Drivers: hv: vmbus: suppress some "hv_vmbus: Unknown GUID" warnings hyperv.h : commit 8e1d260738ca89bc7c87444f95f04a026d12b496 : Drivers: hv: utils: Support TimeSync version 4.0 protocol samples. hyperv.h : commit 638fea33aee858cc665297a76f0039e95a28ce0c : Drivers: hv: vmbus: fix the race when querying & updating the percpu list channel.c : commit 3724287c0ec472815ebe5ae3790f77965c6aa557 : Drivers: hv: vmbus: Implement a mechanism to tag the channel for low latency channel.c : commit 4d63763296ab7865a98bc29cc7d77145815ef89f : Drivers: hv: get rid of redundant messagecount in create_gpadl_header() channel.c : commit 6
[Kernel-packages] [Bug 1630924] Re: Kdump through NMI SMP and single core not working on Ubuntu16.10
I did re-verify this now with the 4.9 mainline and kdump through NMI works fine. There might have been additional patches and there is at least one other commit in upstream, however that one is addressing only x86 arch. Full version info: v4.9 mainline build v4.9 (69973b830859bc6529a7a0468ba0d80ee5117826) Changing tag flag kernel-fixed-upstream ** Tags added: kernel-fixed-upstream -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1630924 Title: Kdump through NMI SMP and single core not working on Ubuntu16.10 Status in linux package in Ubuntu: Confirmed Status in linux source package in Yakkety: Confirmed Bug description: During some tests I've encountered an issue with kdump through NMI SMP and single core. After kdump configuration, when I trigger the crash through an NMI call from the host, the VM will panic, however it will not write the vmcore dump files and neither reboot. REPRO STEPS: 1. configure kdump - crashkernel=512M-:384M /boot/grub/grub.cfg - USE_KDUMP=1 /etc/default/kdump-tools 2. after configuration reboot the VM 3. check kdump status - cat /sys/kernel/kexec_* - service kdump-tools status 4. configure NMI - sysctl -w kernel.unknown_nmi_panic=1 5. trigger a crash from host - Debug-VM -Name $vmName -InjectNonMaskableInterrupt -ComputerName $hvServer -Force This case also applies to: -Ubuntu 16.10 generation 2(kernel version: 4.8.0-17-generic) -Ubuntu 16.04.1(kernel: 4.4.0-38-generic) -Ubuntu 14.04.5(kernel: 3.19.0-69-generic) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1630924/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1636656] Re: [Hyper-V] netvsc: fix incorrect receive checksum offloading
** Tags removed: verification-needed-vivid verification-needed-xenial ** Tags added: verification-done-vivid verification-done-xenial -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1636656 Title: [Hyper-V] netvsc: fix incorrect receive checksum offloading Status in linux package in Ubuntu: In Progress Status in linux source package in Trusty: In Progress Status in linux source package in Vivid: Fix Committed Status in linux source package in Xenial: Fix Committed Status in linux source package in Yakkety: Fix Committed Bug description: The Hyper-V netvsc driver was looking at the incorrect status bits in the checksum info. It was setting the receive checksum unnecessary flag based on the IP header checksum being correct. The checksum flag is skb is about TCP and UDP checksum status. Because of this bug, any packet received with bad TCP checksum would be passed up the stack and to the application causing data corruption. The problem is reproducible via netcat and netem. This had a side effect of not doing receive checksum offload on IPv6. The driver was also also always doing checksum offload independent of the checksum setting done via ethtool. Signed-off-by: Stephen Hemminger https://patchwork.ozlabs.org/patch/685660/ When this patch is committed I will include the commit ID in this bug. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1636656/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1400319] Re: [Hyper-V] Kernel panic not functional on 32bit Ubuntu 14.10, 15.04, and 15.10
We verified the following proposed kernels: Xenial: 4.4.0.58.61 and 4.4.0.58.79 Yakkety: 4.8.0.34.43 Standard kdump and kdump through NMI work now as expected, single core and SMP configurations. ** Tags removed: verification-needed-xenial verification-needed-yakkety ** Tags added: verification-done-xenial verification-done-yakkety -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1400319 Title: [Hyper-V] Kernel panic not functional on 32bit Ubuntu 14.10, 15.04, and 15.10 Status in linux package in Ubuntu: In Progress Status in linux source package in Xenial: Fix Committed Status in linux source package in Yakkety: Fix Committed Bug description: While testing the final build of 14.10 32bit we found that kernel panic cannot be activated for an installation on a Hyper-V VM. Repro rate: 100% Repro details: Hyper-V: Server 2012 R2 VM: Ubuntu 14.10 32bit Kdump is enabled in the config file at /etc/default/kdump-tools Different crashkernel values used in grub.cfg – 128M-:64M | 256M-:128m | 384M-:256M VM settings: 2 cores, various RAM sizes attempted: 1, 2 or 4 GB – this in combination with the values for crashkernel. Trying to start the kdump service: root@ubuntu1410i386:~# /etc/init.d/kdump-tools start Starting kdump-tools: Could not find a free area of memory of 0x9f000 bytes... locate_hole failed * failed to load kdump kernel --- root@ubuntu1410i386:~# cat /sys/kernel/kexec_crash_loaded 0 If the conversion from hex to dec is right, the mentioned memory mapping of 0x9f000 bytes is equal to 651264 (bytes), so under 1MB. This is not then related to the RAM allocation nor the crashkernel value used. --- AlsaDevices: Error: command ['ls', '-l', '/dev/snd/'] failed with exit code 2: ls: cannot access /dev/snd/: No such file or directory AplayDevices: Error: [Errno 2] No such file or directory ApportVersion: 2.14.7-0ubuntu8 Architecture: i386 ArecordDevices: Error: [Errno 2] No such file or directory CRDA: Error: [Errno 2] No such file or directory DistroRelease: Ubuntu 14.10 HibernationDevice: RESUME=UUID=5a5d0aa4-b8ee-4bf7-b1b9-761b7d1550b6 InstallationDate: Installed on 2014-10-31 (37 days ago) InstallationMedia: Ubuntu-Server 14.10 "Utopic Unicorn" - Release i386 (20141022.2) IwConfig: lono wireless extensions. eth0 no wireless extensions. Lsusb: Error: command ['lsusb'] failed with exit code 1: unable to initialize libusb: -99 MachineType: Microsoft Corporation Virtual Machine Package: linux (not installed) PciMultimedia: ProcEnviron: TERM=xterm PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash ProcFB: 0 hyperv_fb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.16.0-24-generic root=UUID=83fb481a-8898-4adc-bf31-4e160f5f0ce8 ro crashkernel=128M-:64M ProcVersionSignature: Ubuntu 3.16.0-24.32-generic 3.16.4 RelatedPackageVersions: linux-restricted-modules-3.16.0-24-generic N/A linux-backports-modules-3.16.0-24-generic N/A linux-firmware 1.138 RfKill: Error: [Errno 2] No such file or directory Tags: utopic Uname: Linux 3.16.0-24-generic i686 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: WifiSyslog: Dec 8 08:16:46 ubuntu1410i386 dhclient: DHCPREQUEST of 10.226.59.102 on eth0 to 10.184.232.100 port 67 (xid=0x4b67ffa3) Dec 8 08:16:46 ubuntu1410i386 dhclient: DHCPACK of 10.226.59.102 from 10.184.232.100 Dec 8 08:16:47 ubuntu1410i386 dhclient: bound to 10.226.59.102 -- renewal in 13914 seconds. Dec 8 10:10:47 ubuntu1410i386 kernel: [1840786.031060] init: tty1 main process ended, respawning _MarkForUpload: True dmi.bios.date: 05/23/2012 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 090006 dmi.board.name: Virtual Machine dmi.board.vendor: Microsoft Corporation dmi.board.version: 7.0 dmi.chassis.asset.tag: 7176-0455-3377-8479-3268-6677-66 dmi.chassis.type: 3 dmi.chassis.vendor: Microsoft Corporation dmi.chassis.version: 7.0 dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr090006:bd05/23/2012:svnMicrosoftCorporation:pnVirtualMachine:pvr7.0:rvnMicrosoftCorporation:rnVirtualMachine:rvr7.0:cvnMicrosoftCorporation:ct3:cvr7.0: dmi.product.name: Virtual Machine dmi.product.version: 7.0 dmi.sys.vendor: Microsoft Corporation To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1400319/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1632786] Re: [Hyper-V] do not lose pending heartbeat vmbus packets
** Tags removed: verification-needed-precise
** Tags added: verification-done-precise
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1632786
Title:
[Hyper-V] do not lose pending heartbeat vmbus packets
Status in linux package in Ubuntu:
Fix Committed
Status in linux source package in Precise:
Fix Committed
Status in linux source package in Trusty:
Fix Committed
Status in linux source package in Vivid:
Fix Committed
Status in linux source package in Xenial:
Fix Committed
Status in linux source package in Yakkety:
Fix Committed
Bug description:
Hyper-V hosts can continue sending heartbeat packets to guests
independent of whether earlier packets have responses, which led to a
potential issue of these packets being dropped when responses took too
long to process. Lost heartbeats will lead to the host diagnosing that
the guest is dead and should be shut down and restarted.
The following patch was submitted upstream but has not yet been
accepted. I will add the upstream commit ID once the patch goes into
linux-next:
From: Long Li
The host keeps sending heartbeat packets independent of the
guest responding to them. Even though we respond to the heartbeat messages at
interrupt level, we can have situations where there maybe multiple heartbeat
messages pending that have not been responded to. For instance this occurs
when the
VM is paused and the host continues to send the heartbeat messages.
Address this issue by draining and responding to all
the heartbeat messages that maybe pending.
Signed-off-by: Long Li
Signed-off-by: K. Y. Srinivasan
CC: Stable
---
V2: Submit the patch to stable as well - Joshua R. Poulson
drivers/hv/hv_util.c | 10 +++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/hv/hv_util.c b/drivers/hv/hv_util.c
index 4aa3cb6..bcd0630 100644
--- a/drivers/hv/hv_util.c
+++ b/drivers/hv/hv_util.c
@@ -314,10 +314,14 @@ static void heartbeat_onchannelcallback(void *context)
u8 *hbeat_txf_buf = util_heartbeat.recv_buffer;
struct icmsg_negotiate *negop = NULL;
- vmbus_recvpacket(channel, hbeat_txf_buf,
-PAGE_SIZE, &recvlen, &requestid);
+ while (1) {
+
+ vmbus_recvpacket(channel, hbeat_txf_buf,
+PAGE_SIZE, &recvlen, &requestid);
+
+ if (!recvlen)
+ break;
- if (recvlen > 0) {
icmsghdrp = (struct icmsg_hdr *)&hbeat_txf_buf[
sizeof(struct vmbuspipe_hdr)];
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1632786/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1632786] Re: [Hyper-V] do not lose pending heartbeat vmbus packets
** Tags removed: verification-needed-xenial
** Tags added: verification-done-xenial
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1632786
Title:
[Hyper-V] do not lose pending heartbeat vmbus packets
Status in linux package in Ubuntu:
Fix Committed
Status in linux source package in Precise:
Fix Committed
Status in linux source package in Trusty:
Fix Committed
Status in linux source package in Vivid:
Fix Committed
Status in linux source package in Xenial:
Fix Committed
Status in linux source package in Yakkety:
Fix Committed
Bug description:
Hyper-V hosts can continue sending heartbeat packets to guests
independent of whether earlier packets have responses, which led to a
potential issue of these packets being dropped when responses took too
long to process. Lost heartbeats will lead to the host diagnosing that
the guest is dead and should be shut down and restarted.
The following patch was submitted upstream but has not yet been
accepted. I will add the upstream commit ID once the patch goes into
linux-next:
From: Long Li
The host keeps sending heartbeat packets independent of the
guest responding to them. Even though we respond to the heartbeat messages at
interrupt level, we can have situations where there maybe multiple heartbeat
messages pending that have not been responded to. For instance this occurs
when the
VM is paused and the host continues to send the heartbeat messages.
Address this issue by draining and responding to all
the heartbeat messages that maybe pending.
Signed-off-by: Long Li
Signed-off-by: K. Y. Srinivasan
CC: Stable
---
V2: Submit the patch to stable as well - Joshua R. Poulson
drivers/hv/hv_util.c | 10 +++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/hv/hv_util.c b/drivers/hv/hv_util.c
index 4aa3cb6..bcd0630 100644
--- a/drivers/hv/hv_util.c
+++ b/drivers/hv/hv_util.c
@@ -314,10 +314,14 @@ static void heartbeat_onchannelcallback(void *context)
u8 *hbeat_txf_buf = util_heartbeat.recv_buffer;
struct icmsg_negotiate *negop = NULL;
- vmbus_recvpacket(channel, hbeat_txf_buf,
-PAGE_SIZE, &recvlen, &requestid);
+ while (1) {
+
+ vmbus_recvpacket(channel, hbeat_txf_buf,
+PAGE_SIZE, &recvlen, &requestid);
+
+ if (!recvlen)
+ break;
- if (recvlen > 0) {
icmsghdrp = (struct icmsg_hdr *)&hbeat_txf_buf[
sizeof(struct vmbuspipe_hdr)];
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1632786/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1630924] Re: Kdump through NMI SMP and single core not working on Ubuntu16.10
Hi Joe, I did verify this again with the below kernels and results: - 4.8.0-22 16.10 kernel - kdump through NMI on 4 CPU cores doesn't work - VM gets stuck and there is no crash file nor a reboot. - 4.9.0-040900RC8 kernel from ubuntu mainline - kdump through NMI works fine when using single core or SMP *with 4 cores*. Using 8 cores on this kernel, triggering the crash will result in the same bad behavior as from the GA kernel. I don't see any crash messages on the console, and the VM will just hang. Will have to do more debugging on this new pattern. All tests have been done with crashkernel=512M and 2GB RAM for the VM. 4.9 also just got released, as of 11/12. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1630924 Title: Kdump through NMI SMP and single core not working on Ubuntu16.10 Status in linux package in Ubuntu: Confirmed Status in linux source package in Yakkety: Confirmed Bug description: During some tests I've encountered an issue with kdump through NMI SMP and single core. After kdump configuration, when I trigger the crash through an NMI call from the host, the VM will panic, however it will not write the vmcore dump files and neither reboot. REPRO STEPS: 1. configure kdump - crashkernel=512M-:384M /boot/grub/grub.cfg - USE_KDUMP=1 /etc/default/kdump-tools 2. after configuration reboot the VM 3. check kdump status - cat /sys/kernel/kexec_* - service kdump-tools status 4. configure NMI - sysctl -w kernel.unknown_nmi_panic=1 5. trigger a crash from host - Debug-VM -Name $vmName -InjectNonMaskableInterrupt -ComputerName $hvServer -Force This case also applies to: -Ubuntu 16.10 generation 2(kernel version: 4.8.0-17-generic) -Ubuntu 16.04.1(kernel: 4.4.0-38-generic) -Ubuntu 14.04.5(kernel: 3.19.0-69-generic) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1630924/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1632786] Re: [Hyper-V] do not lose pending heartbeat vmbus packets
** Tags removed: verification-needed-trusty
** Tags added: verification-done-trusty
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1632786
Title:
[Hyper-V] do not lose pending heartbeat vmbus packets
Status in linux package in Ubuntu:
Fix Committed
Status in linux source package in Precise:
Fix Committed
Status in linux source package in Trusty:
Fix Committed
Status in linux source package in Vivid:
Fix Committed
Status in linux source package in Xenial:
Fix Committed
Status in linux source package in Yakkety:
Fix Committed
Bug description:
Hyper-V hosts can continue sending heartbeat packets to guests
independent of whether earlier packets have responses, which led to a
potential issue of these packets being dropped when responses took too
long to process. Lost heartbeats will lead to the host diagnosing that
the guest is dead and should be shut down and restarted.
The following patch was submitted upstream but has not yet been
accepted. I will add the upstream commit ID once the patch goes into
linux-next:
From: Long Li
The host keeps sending heartbeat packets independent of the
guest responding to them. Even though we respond to the heartbeat messages at
interrupt level, we can have situations where there maybe multiple heartbeat
messages pending that have not been responded to. For instance this occurs
when the
VM is paused and the host continues to send the heartbeat messages.
Address this issue by draining and responding to all
the heartbeat messages that maybe pending.
Signed-off-by: Long Li
Signed-off-by: K. Y. Srinivasan
CC: Stable
---
V2: Submit the patch to stable as well - Joshua R. Poulson
drivers/hv/hv_util.c | 10 +++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/hv/hv_util.c b/drivers/hv/hv_util.c
index 4aa3cb6..bcd0630 100644
--- a/drivers/hv/hv_util.c
+++ b/drivers/hv/hv_util.c
@@ -314,10 +314,14 @@ static void heartbeat_onchannelcallback(void *context)
u8 *hbeat_txf_buf = util_heartbeat.recv_buffer;
struct icmsg_negotiate *negop = NULL;
- vmbus_recvpacket(channel, hbeat_txf_buf,
-PAGE_SIZE, &recvlen, &requestid);
+ while (1) {
+
+ vmbus_recvpacket(channel, hbeat_txf_buf,
+PAGE_SIZE, &recvlen, &requestid);
+
+ if (!recvlen)
+ break;
- if (recvlen > 0) {
icmsghdrp = (struct icmsg_hdr *)&hbeat_txf_buf[
sizeof(struct vmbuspipe_hdr)];
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1632786/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1632786] Re: [Hyper-V] do not lose pending heartbeat vmbus packets
** Tags removed: verification-needed-yakkety
** Tags added: verification-done-yakkety
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1632786
Title:
[Hyper-V] do not lose pending heartbeat vmbus packets
Status in linux package in Ubuntu:
Fix Committed
Status in linux source package in Precise:
Fix Committed
Status in linux source package in Trusty:
Fix Committed
Status in linux source package in Vivid:
Fix Committed
Status in linux source package in Xenial:
Fix Committed
Status in linux source package in Yakkety:
Fix Committed
Bug description:
Hyper-V hosts can continue sending heartbeat packets to guests
independent of whether earlier packets have responses, which led to a
potential issue of these packets being dropped when responses took too
long to process. Lost heartbeats will lead to the host diagnosing that
the guest is dead and should be shut down and restarted.
The following patch was submitted upstream but has not yet been
accepted. I will add the upstream commit ID once the patch goes into
linux-next:
From: Long Li
The host keeps sending heartbeat packets independent of the
guest responding to them. Even though we respond to the heartbeat messages at
interrupt level, we can have situations where there maybe multiple heartbeat
messages pending that have not been responded to. For instance this occurs
when the
VM is paused and the host continues to send the heartbeat messages.
Address this issue by draining and responding to all
the heartbeat messages that maybe pending.
Signed-off-by: Long Li
Signed-off-by: K. Y. Srinivasan
CC: Stable
---
V2: Submit the patch to stable as well - Joshua R. Poulson
drivers/hv/hv_util.c | 10 +++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/hv/hv_util.c b/drivers/hv/hv_util.c
index 4aa3cb6..bcd0630 100644
--- a/drivers/hv/hv_util.c
+++ b/drivers/hv/hv_util.c
@@ -314,10 +314,14 @@ static void heartbeat_onchannelcallback(void *context)
u8 *hbeat_txf_buf = util_heartbeat.recv_buffer;
struct icmsg_negotiate *negop = NULL;
- vmbus_recvpacket(channel, hbeat_txf_buf,
-PAGE_SIZE, &recvlen, &requestid);
+ while (1) {
+
+ vmbus_recvpacket(channel, hbeat_txf_buf,
+PAGE_SIZE, &recvlen, &requestid);
+
+ if (!recvlen)
+ break;
- if (recvlen > 0) {
icmsghdrp = (struct icmsg_hdr *)&hbeat_txf_buf[
sizeof(struct vmbuspipe_hdr)];
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1632786/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1636656] Re: [Hyper-V] netvsc: fix incorrect receive checksum offloading
Hi Joe, We verified the test kernel for Trusty from comment #8, however it does not seem to be resolving the issue, as we ran into a different issue. With the test kernel 3.13.0-105.152~lp1636656_amd64 the VM is loosing network connectivity if we corrupt the packages and transfer a file. This behavior is not seen in all the other kernels already tested, so it seems to be specific to be backport to 3.13 - dependency patches maybe? Using the latest kernel for Trusty - 3.13.0-105-generic - we do *not* observe the netvsc messages if we corrupt the packages. I will have to check this internally if the given bug here might have been introduced in a later kernel, will reply once we clarify the situation for Trusty. Last question would be that in order to include the netvsc patch in 3.13, did you have to backport other patches? If so, can you please provide us with the list of them, that might help to understand the behavior. Thank you! -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1636656 Title: [Hyper-V] netvsc: fix incorrect receive checksum offloading Status in linux package in Ubuntu: In Progress Status in linux source package in Trusty: In Progress Status in linux source package in Vivid: In Progress Status in linux source package in Xenial: In Progress Status in linux source package in Yakkety: In Progress Bug description: The Hyper-V netvsc driver was looking at the incorrect status bits in the checksum info. It was setting the receive checksum unnecessary flag based on the IP header checksum being correct. The checksum flag is skb is about TCP and UDP checksum status. Because of this bug, any packet received with bad TCP checksum would be passed up the stack and to the application causing data corruption. The problem is reproducible via netcat and netem. This had a side effect of not doing receive checksum offload on IPv6. The driver was also also always doing checksum offload independent of the checksum setting done via ethtool. Signed-off-by: Stephen Hemminger https://patchwork.ozlabs.org/patch/685660/ When this patch is committed I will include the commit ID in this bug. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1636656/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1636656] Re: [Hyper-V] netvsc: fix incorrect receive checksum offloading
Hello, We've completed the testing of the kernels provided. The issue is resolved in the test kernels and we've also ran a sanity check for the netvsc driver, with no issues. Thank you! -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1636656 Title: [Hyper-V] netvsc: fix incorrect receive checksum offloading Status in linux package in Ubuntu: In Progress Status in linux source package in Precise: In Progress Status in linux source package in Trusty: In Progress Status in linux source package in Vivid: In Progress Status in linux source package in Xenial: In Progress Status in linux source package in Yakkety: In Progress Bug description: The Hyper-V netvsc driver was looking at the incorrect status bits in the checksum info. It was setting the receive checksum unnecessary flag based on the IP header checksum being correct. The checksum flag is skb is about TCP and UDP checksum status. Because of this bug, any packet received with bad TCP checksum would be passed up the stack and to the application causing data corruption. The problem is reproducible via netcat and netem. This had a side effect of not doing receive checksum offload on IPv6. The driver was also also always doing checksum offload independent of the checksum setting done via ethtool. Signed-off-by: Stephen Hemminger https://patchwork.ozlabs.org/patch/685660/ When this patch is committed I will include the commit ID in this bug. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1636656/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1400319] Re: [Hyper-V] Kernel panic not functional on 32bit Ubuntu 14.10, 15.04, and 15.10
Hi Joe, We did look at http://kernel.ubuntu.com/~jsalisbury/lp1400319/ however that folder has the 32bit kernel and binaries. As this bug is in regards to the 32bit architecture, we would need the i386 kernel actually. Thank you! -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to kexec-tools in Ubuntu. https://bugs.launchpad.net/bugs/1400319 Title: [Hyper-V] Kernel panic not functional on 32bit Ubuntu 14.10, 15.04, and 15.10 Status in kexec-tools package in Ubuntu: Confirmed Status in linux package in Ubuntu: In Progress Bug description: While testing the final build of 14.10 32bit we found that kernel panic cannot be activated for an installation on a Hyper-V VM. Repro rate: 100% Repro details: Hyper-V: Server 2012 R2 VM: Ubuntu 14.10 32bit Kdump is enabled in the config file at /etc/default/kdump-tools Different crashkernel values used in grub.cfg – 128M-:64M | 256M-:128m | 384M-:256M VM settings: 2 cores, various RAM sizes attempted: 1, 2 or 4 GB – this in combination with the values for crashkernel. Trying to start the kdump service: root@ubuntu1410i386:~# /etc/init.d/kdump-tools start Starting kdump-tools: Could not find a free area of memory of 0x9f000 bytes... locate_hole failed * failed to load kdump kernel --- root@ubuntu1410i386:~# cat /sys/kernel/kexec_crash_loaded 0 If the conversion from hex to dec is right, the mentioned memory mapping of 0x9f000 bytes is equal to 651264 (bytes), so under 1MB. This is not then related to the RAM allocation nor the crashkernel value used. --- AlsaDevices: Error: command ['ls', '-l', '/dev/snd/'] failed with exit code 2: ls: cannot access /dev/snd/: No such file or directory AplayDevices: Error: [Errno 2] No such file or directory ApportVersion: 2.14.7-0ubuntu8 Architecture: i386 ArecordDevices: Error: [Errno 2] No such file or directory CRDA: Error: [Errno 2] No such file or directory DistroRelease: Ubuntu 14.10 HibernationDevice: RESUME=UUID=5a5d0aa4-b8ee-4bf7-b1b9-761b7d1550b6 InstallationDate: Installed on 2014-10-31 (37 days ago) InstallationMedia: Ubuntu-Server 14.10 "Utopic Unicorn" - Release i386 (20141022.2) IwConfig: lono wireless extensions. eth0 no wireless extensions. Lsusb: Error: command ['lsusb'] failed with exit code 1: unable to initialize libusb: -99 MachineType: Microsoft Corporation Virtual Machine Package: linux (not installed) PciMultimedia: ProcEnviron: TERM=xterm PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash ProcFB: 0 hyperv_fb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.16.0-24-generic root=UUID=83fb481a-8898-4adc-bf31-4e160f5f0ce8 ro crashkernel=128M-:64M ProcVersionSignature: Ubuntu 3.16.0-24.32-generic 3.16.4 RelatedPackageVersions: linux-restricted-modules-3.16.0-24-generic N/A linux-backports-modules-3.16.0-24-generic N/A linux-firmware 1.138 RfKill: Error: [Errno 2] No such file or directory Tags: utopic Uname: Linux 3.16.0-24-generic i686 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: WifiSyslog: Dec 8 08:16:46 ubuntu1410i386 dhclient: DHCPREQUEST of 10.226.59.102 on eth0 to 10.184.232.100 port 67 (xid=0x4b67ffa3) Dec 8 08:16:46 ubuntu1410i386 dhclient: DHCPACK of 10.226.59.102 from 10.184.232.100 Dec 8 08:16:47 ubuntu1410i386 dhclient: bound to 10.226.59.102 -- renewal in 13914 seconds. Dec 8 10:10:47 ubuntu1410i386 kernel: [1840786.031060] init: tty1 main process ended, respawning _MarkForUpload: True dmi.bios.date: 05/23/2012 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 090006 dmi.board.name: Virtual Machine dmi.board.vendor: Microsoft Corporation dmi.board.version: 7.0 dmi.chassis.asset.tag: 7176-0455-3377-8479-3268-6677-66 dmi.chassis.type: 3 dmi.chassis.vendor: Microsoft Corporation dmi.chassis.version: 7.0 dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr090006:bd05/23/2012:svnMicrosoftCorporation:pnVirtualMachine:pvr7.0:rvnMicrosoftCorporation:rnVirtualMachine:rvr7.0:cvnMicrosoftCorporation:ct3:cvr7.0: dmi.product.name: Virtual Machine dmi.product.version: 7.0 dmi.sys.vendor: Microsoft Corporation To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/kexec-tools/+bug/1400319/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1632786] Re: [Hyper-V] do not lose pending heartbeat vmbus packets
Hi Joe,
I finished the verification of test kernels provided in comment #8 and the
reported heartbeat issue is resolved with the patch included.
Please continue with marking this for proposed & release.
Thank you!
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1632786
Title:
[Hyper-V] do not lose pending heartbeat vmbus packets
Status in linux package in Ubuntu:
In Progress
Status in linux source package in Precise:
In Progress
Status in linux source package in Trusty:
In Progress
Status in linux source package in Xenial:
In Progress
Status in linux source package in Yakkety:
In Progress
Bug description:
Hyper-V hosts can continue sending heartbeat packets to guests
independent of whether earlier packets have responses, which led to a
potential issue of these packets being dropped when responses took too
long to process. Lost heartbeats will lead to the host diagnosing that
the guest is dead and should be shut down and restarted.
The following patch was submitted upstream but has not yet been
accepted. I will add the upstream commit ID once the patch goes into
linux-next:
From: Long Li
The host keeps sending heartbeat packets independent of the
guest responding to them. Even though we respond to the heartbeat messages at
interrupt level, we can have situations where there maybe multiple heartbeat
messages pending that have not been responded to. For instance this occurs
when the
VM is paused and the host continues to send the heartbeat messages.
Address this issue by draining and responding to all
the heartbeat messages that maybe pending.
Signed-off-by: Long Li
Signed-off-by: K. Y. Srinivasan
CC: Stable
---
V2: Submit the patch to stable as well - Joshua R. Poulson
drivers/hv/hv_util.c | 10 +++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/hv/hv_util.c b/drivers/hv/hv_util.c
index 4aa3cb6..bcd0630 100644
--- a/drivers/hv/hv_util.c
+++ b/drivers/hv/hv_util.c
@@ -314,10 +314,14 @@ static void heartbeat_onchannelcallback(void *context)
u8 *hbeat_txf_buf = util_heartbeat.recv_buffer;
struct icmsg_negotiate *negop = NULL;
- vmbus_recvpacket(channel, hbeat_txf_buf,
-PAGE_SIZE, &recvlen, &requestid);
+ while (1) {
+
+ vmbus_recvpacket(channel, hbeat_txf_buf,
+PAGE_SIZE, &recvlen, &requestid);
+
+ if (!recvlen)
+ break;
- if (recvlen > 0) {
icmsghdrp = (struct icmsg_hdr *)&hbeat_txf_buf[
sizeof(struct vmbuspipe_hdr)];
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1632786/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1636656] Re: [Hyper-V] netvsc: fix incorrect receive checksum offloading
** Changed in: linux (Ubuntu) Status: Incomplete => Confirmed -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1636656 Title: [Hyper-V] netvsc: fix incorrect receive checksum offloading Status in linux package in Ubuntu: Confirmed Bug description: The Hyper-V netvsc driver was looking at the incorrect status bits in the checksum info. It was setting the receive checksum unnecessary flag based on the IP header checksum being correct. The checksum flag is skb is about TCP and UDP checksum status. Because of this bug, any packet received with bad TCP checksum would be passed up the stack and to the application causing data corruption. The problem is reproducible via netcat and netem. This had a side effect of not doing receive checksum offload on IPv6. The driver was also also always doing checksum offload independent of the checksum setting done via ethtool. Signed-off-by: Stephen Hemminger https://patchwork.ozlabs.org/patch/685660/ When this patch is committed I will include the commit ID in this bug. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1636656/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1630924] Re: Kdump through NMI SMP and single core not working on Ubuntu16.10
** Changed in: linux (Ubuntu) Status: Incomplete => Confirmed -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1630924 Title: Kdump through NMI SMP and single core not working on Ubuntu16.10 Status in linux package in Ubuntu: Confirmed Bug description: During some tests I've encountered an issue with kdump through NMI SMP and single core. After kdump configuration, when I trigger the crash through an NMI call from the host, the VM will panic, however it will not write the vmcore dump files and neither reboot. REPRO STEPS: 1. configure kdump - crashkernel=512M-:384M /boot/grub/grub.cfg - USE_KDUMP=1 /etc/default/kdump-tools 2. after configuration reboot the VM 3. check kdump status - cat /sys/kernel/kexec_* - service kdump-tools status 4. configure NMI - sysctl -w kernel.unknown_nmi_panic=1 5. trigger a crash from host - Debug-VM -Name $vmName -InjectNonMaskableInterrupt -ComputerName $hvServer -Force This case also applies to: -Ubuntu 16.10 generation 2(kernel version: 4.8.0-17-generic) -Ubuntu 16.04.1(kernel: 4.4.0-38-generic) -Ubuntu 14.04.5(kernel: 3.19.0-69-generic) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1630924/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1616677] Re: [Hyper-V] Rebase Hyper-V to 4.7.2 (stable)
Marking this as verification-done. Functional testing are looking good and performance for STOR and NET are in par with similar kernels. ** Tags removed: verification-needed-xenial ** Tags added: verification-done-xenial -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1616677 Title: [Hyper-V] Rebase Hyper-V to 4.7.2 (stable) Status in linux package in Ubuntu: Fix Released Status in linux source package in Xenial: Fix Committed Status in linux source package in Yakkety: Fix Released Bug description: Please rebase the Hyper-V drivers and tools in lts-xenial (and yakkity) to the final v4.7.2 stable upstream kernel. The following files comprise Hyper-V support in the upstream kernel: arch/x86/kernel/cpu/mshyperv.c arch/x86/include/asm/mshyperv.h arch/x86/include/uapi/asm/hyperv.h include/linux/hyperv.h drivers/hv/channel.c drivers/hv/channel_mgmt.c drivers/hv/connection.c drivers/hv/hv_balloon.c drivers/hv/hv.c drivers/hv/hv_fcopy.c drivers/hv/hv_kvp.c drivers/hv/hv_snapshot.c drivers/hv/hv_util.c drivers/hv/hv_utils_transport.c drivers/hv/hv_utils_transport.h drivers/hv/hyperv_vmbus.h drivers/hv/ring_buffer.c drivers/hv/vmbus_drv.c tools/hv/hv_fcopy_daemon.c tools/hv/hv_get_dhcp_info.sh tools/hv/hv_get_dns_info.sh tools/hv/hv_kvp_daemon.c tools/hv/hv_set_ifconfig.sh tools/hv/hv_vss_daemon.c tools/hv/lsvmbus drivers/input/serio/hyperv-keyboard.c drivers/net/hyperv/hyperv_net.h drivers/net/hyperv/netvsc.c drivers/net/hyperv/netvsc_drv.c drivers/net/hyperv/rndis_filter.c drivers/scsi/storvsc_drv.c drivers/hid/hid-hyperv.c drivers/pci/host/pci-hyperv.c drivers/video/fbdev/hyperv_fb.c While I know a number of post-4.6 commits are already included, I am including all of the commits from 4.6 to 4.7.2 for reference: channel_mgmt.c : commit cd95aad5579371ac332507fc946008217fc37e6c : Drivers: hv: vmbus: handle various crash scenarios connection.c : commit 5cc472477f928fb8584eb8e08245c9cf9002d74a : Drivers: hv: vmbus: Export the vmbus_set_event() API hv_balloon.c : commit 77c0c9735bc0ba5898e637a3a20d6bcb50e3f67d : Drivers: hv: balloon: don't crash when memory is added in non-sorted order hv_balloon.c : commit d19a55d6ed5bf0ffe553df2d8bf91d054ddf2d76 : Drivers: hv: balloon: reset host_specified_ha_region hv_kvp.c : commit 4dbfc2e68004c60edab7e8fd26784383dd3ee9bc : Drivers: hv: kvp: fix IP Failover hyperv_fb.c : commit 696ca5e82c057a272381ae6064d59eb97a578397 : drivers:hv: Use new vmbus_mmio_free() from client drivers. hyperv.h : commit 97fb77dc87582300fa3c141b63699f853576cab1 : drivers:hv: Make a function to free mmio regions through vmbus hyperv.h : commit a6341f24cdf1ec14dc26743a409a17378db5 : Drivers: hv: vmbus: Introduce functions for estimating room in the ring buffer hyperv.h : commit ab028db41ca9174caab7f9e3fc0a2e7f4a418410 : Drivers: hv: vmbus: Implement APIs to support "in place" consumption of vmbus packets hyperv_net.h : commit 10082f98878a9dff1563745f9f1dd9d1ff142700 : hv_netvsc: Eliminate status from struct hv_netvsc_packet hyperv_net.h : commit 3d541ac5a92af708d0085925d136f875f3a58d57 : hv_netvsc: untangle the pointer mess hyperv_net.h : commit c85e4924452ae8225c8829f3fa8a2f7baa34bc5c : hv_netvsc: Fix book keeping of skb during batching process hyperv_vmbus.h : commit 4dbfc2e68004c60edab7e8fd26784383dd3ee9bc : Drivers: hv: kvp: fix IP Failover hyperv_vmbus.h : commit 5cc472477f928fb8584eb8e08245c9cf9002d74a : Drivers: hv: vmbus: Export the vmbus_set_event() API hyperv_vmbus.h : commit cd95aad5579371ac332507fc946008217fc37e6c : Drivers: hv: vmbus: handle various crash scenarios lsvmbus : commit 552beb4930ef3889d42a049eb9ba3533b4cbe0f6 : tools: hv: lsvmbus: add pci pass-through UUID netvsc_drv.c : commit 15cfd40771e18a4e9b788c64c9db2606f958b93d : hv_netvsc: Fix the list processing for network change event netvsc_drv.c : commit 1bdcec8a5f05445752a0639edd603ac09ae6c553 : hv_netvsc: use start_remove flag to protect netvsc_link_change() netvsc_drv.c : commit 84bf9cefb162b197da20a0f4388929f4b5ba5db4 : hv_netvsc: Implement support for VF drivers on Hyper-V pci-hyperv.c : commit 696ca5e82c057a272381ae6064d59eb97a578397 : drivers:hv: Use new vmbus_mmio_free() from client drivers. pci-hyperv.c : commit bdd74440d9e887b1fa648eefa17421def5f5243c : PCI: hv: Add explicit barriers to config space access pci-hyperv.c : commit deb22e5c84c884a129d801cf3bfde7411536998d : PCI: hv: Report resources release after stopping the bus ring_buffer.c : commit a6341f24cdf1ec14dc26743a409a17378db5 : Drivers: hv: vmbus: Introduce functions for estimating room in the ring buffer rndis_filter.c : commit 0a1275ca5128b84c149960969ed351ae00eb : hv_netvsc: get rid of st
[Kernel-packages] [Bug 1616677] Re: [Hyper-V] Rebase Hyper-V to 4.7.2 (stable)
Thanks Brad! We're doing a test pass on the proposed kernel and update this thread once we have the results. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1616677 Title: [Hyper-V] Rebase Hyper-V to 4.7.2 (stable) Status in linux package in Ubuntu: Fix Released Status in linux source package in Xenial: Fix Committed Status in linux source package in Yakkety: Fix Released Bug description: Please rebase the Hyper-V drivers and tools in lts-xenial (and yakkity) to the final v4.7.2 stable upstream kernel. The following files comprise Hyper-V support in the upstream kernel: arch/x86/kernel/cpu/mshyperv.c arch/x86/include/asm/mshyperv.h arch/x86/include/uapi/asm/hyperv.h include/linux/hyperv.h drivers/hv/channel.c drivers/hv/channel_mgmt.c drivers/hv/connection.c drivers/hv/hv_balloon.c drivers/hv/hv.c drivers/hv/hv_fcopy.c drivers/hv/hv_kvp.c drivers/hv/hv_snapshot.c drivers/hv/hv_util.c drivers/hv/hv_utils_transport.c drivers/hv/hv_utils_transport.h drivers/hv/hyperv_vmbus.h drivers/hv/ring_buffer.c drivers/hv/vmbus_drv.c tools/hv/hv_fcopy_daemon.c tools/hv/hv_get_dhcp_info.sh tools/hv/hv_get_dns_info.sh tools/hv/hv_kvp_daemon.c tools/hv/hv_set_ifconfig.sh tools/hv/hv_vss_daemon.c tools/hv/lsvmbus drivers/input/serio/hyperv-keyboard.c drivers/net/hyperv/hyperv_net.h drivers/net/hyperv/netvsc.c drivers/net/hyperv/netvsc_drv.c drivers/net/hyperv/rndis_filter.c drivers/scsi/storvsc_drv.c drivers/hid/hid-hyperv.c drivers/pci/host/pci-hyperv.c drivers/video/fbdev/hyperv_fb.c While I know a number of post-4.6 commits are already included, I am including all of the commits from 4.6 to 4.7.2 for reference: channel_mgmt.c : commit cd95aad5579371ac332507fc946008217fc37e6c : Drivers: hv: vmbus: handle various crash scenarios connection.c : commit 5cc472477f928fb8584eb8e08245c9cf9002d74a : Drivers: hv: vmbus: Export the vmbus_set_event() API hv_balloon.c : commit 77c0c9735bc0ba5898e637a3a20d6bcb50e3f67d : Drivers: hv: balloon: don't crash when memory is added in non-sorted order hv_balloon.c : commit d19a55d6ed5bf0ffe553df2d8bf91d054ddf2d76 : Drivers: hv: balloon: reset host_specified_ha_region hv_kvp.c : commit 4dbfc2e68004c60edab7e8fd26784383dd3ee9bc : Drivers: hv: kvp: fix IP Failover hyperv_fb.c : commit 696ca5e82c057a272381ae6064d59eb97a578397 : drivers:hv: Use new vmbus_mmio_free() from client drivers. hyperv.h : commit 97fb77dc87582300fa3c141b63699f853576cab1 : drivers:hv: Make a function to free mmio regions through vmbus hyperv.h : commit a6341f24cdf1ec14dc26743a409a17378db5 : Drivers: hv: vmbus: Introduce functions for estimating room in the ring buffer hyperv.h : commit ab028db41ca9174caab7f9e3fc0a2e7f4a418410 : Drivers: hv: vmbus: Implement APIs to support "in place" consumption of vmbus packets hyperv_net.h : commit 10082f98878a9dff1563745f9f1dd9d1ff142700 : hv_netvsc: Eliminate status from struct hv_netvsc_packet hyperv_net.h : commit 3d541ac5a92af708d0085925d136f875f3a58d57 : hv_netvsc: untangle the pointer mess hyperv_net.h : commit c85e4924452ae8225c8829f3fa8a2f7baa34bc5c : hv_netvsc: Fix book keeping of skb during batching process hyperv_vmbus.h : commit 4dbfc2e68004c60edab7e8fd26784383dd3ee9bc : Drivers: hv: kvp: fix IP Failover hyperv_vmbus.h : commit 5cc472477f928fb8584eb8e08245c9cf9002d74a : Drivers: hv: vmbus: Export the vmbus_set_event() API hyperv_vmbus.h : commit cd95aad5579371ac332507fc946008217fc37e6c : Drivers: hv: vmbus: handle various crash scenarios lsvmbus : commit 552beb4930ef3889d42a049eb9ba3533b4cbe0f6 : tools: hv: lsvmbus: add pci pass-through UUID netvsc_drv.c : commit 15cfd40771e18a4e9b788c64c9db2606f958b93d : hv_netvsc: Fix the list processing for network change event netvsc_drv.c : commit 1bdcec8a5f05445752a0639edd603ac09ae6c553 : hv_netvsc: use start_remove flag to protect netvsc_link_change() netvsc_drv.c : commit 84bf9cefb162b197da20a0f4388929f4b5ba5db4 : hv_netvsc: Implement support for VF drivers on Hyper-V pci-hyperv.c : commit 696ca5e82c057a272381ae6064d59eb97a578397 : drivers:hv: Use new vmbus_mmio_free() from client drivers. pci-hyperv.c : commit bdd74440d9e887b1fa648eefa17421def5f5243c : PCI: hv: Add explicit barriers to config space access pci-hyperv.c : commit deb22e5c84c884a129d801cf3bfde7411536998d : PCI: hv: Report resources release after stopping the bus ring_buffer.c : commit a6341f24cdf1ec14dc26743a409a17378db5 : Drivers: hv: vmbus: Introduce functions for estimating room in the ring buffer rndis_filter.c : commit 0a1275ca5128b84c149960969ed351ae00eb : hv_netvsc: get rid of struct net_device pointer in struct netvsc_device rndis_filter.c : commit 10082f98878a9dff1563745f9f1dd9d1ff142700
[Kernel-packages] [Bug 1627709] Re: Ubuntu 16.10(Yakkety Yak) server amd64 and i386 from 21-Sep-2016 installation fails
** Changed in: linux (Ubuntu) Status: Incomplete => Confirmed -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1627709 Title: Ubuntu 16.10(Yakkety Yak) server amd64 and i386 from 21-Sep-2016 installation fails Status in linux package in Ubuntu: Confirmed Bug description: I was trying to install Ubuntu 16.10(Yakkety Yak) server amd64 from 21-Sep-2016 Ubuntu 16.10(Yakkety Yak). Unfortunately the installation failed at software install. The following messages appear in the console: in-target: The following packages have unmet dependencies: in-target: libpython3.5 : Depends: libpython3.5-stdlib (= 3.5.2-4ubuntu2) but 3.5.2-4ubuntu3 is to be installed in-target: Unable to correct problems, you have held broken packages. in-target: tasksel: apt-get failed (100) main-menu[785]: WARNING **: Configuring 'pkgsel' failed with error code 1 main-menu[785]: WARNING **: Menu item 'pkgsel' failed. Note: This case also applies to Ubuntu 16.10 server i386 from 21-Sep-2016. With the images from 24-Sep-2016 amd64 and i386 the installation failed because CD-ROM couldn't be mounted. Thanks, Ovidiu. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1627709/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1590655] Re: [Hyper-V] storvsc messages for CD-ROM medium not present tray closed
** Tags removed: verification-needed-trusty ** Tags added: verification-done-trusty -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1590655 Title: [Hyper-V] storvsc messages for CD-ROM medium not present tray closed Status in linux package in Ubuntu: Fix Released Status in linux source package in Trusty: Fix Committed Status in linux source package in Vivid: Won't Fix Status in linux source package in Wily: Won't Fix Status in linux source package in Xenial: Fix Released Status in linux source package in Yakkety: Fix Released Bug description: The below can be seen with any distribution running on a Generation 2 VM. There is a verified patch for this, however it has been scheduled only for the 4.8 scsi-queue. As it a small patch which has been verified by KY and also accepted in the patch queue, will you be able to include this as part of the 16.04 rebase to 4.6, and as well for 14.04 and 15.10? Patch can be found at https://patchwork.kernel.org/patch/9131929/ Description of problem: When starting and shutting down a Gen2 VM, at least 20-30 messages are recorded for storvsc with the below sample: [storvsc] Sense Key : Not Ready [current] [storvsc] Add. Sense: Medium not present - tray closed Steps to Reproduce: 1. create a Generation2 VM 2. start VM and observe the system logs 3. multiple messages for the cd-rom are recorded from storvsc Actual results: even without a CD-ROM unit attached, the messages would appear. Having an ISO attached or not would still produce the same messages. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1590655/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1616677] Re: [Hyper-V] Rebase Hyper-V to 4.7.2 (stable)
We've tested the kernel ~rtg/hv-lp1616677 provided and it passed the quality and functional testing. There are 2 issues that are to be handled: - missing SR-IOV patches - see comments #6 and #7. These should be included. - kdump triggered through NMI doesn't work. We'll identify the missing patches and submit a separate request to include those. Thank you! -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1616677 Title: [Hyper-V] Rebase Hyper-V to 4.7.2 (stable) Status in linux package in Ubuntu: Fix Released Status in linux source package in Xenial: In Progress Status in linux source package in Yakkety: Fix Released Bug description: Please rebase the Hyper-V drivers and tools in lts-xenial (and yakkity) to the final v4.7.2 stable upstream kernel. The following files comprise Hyper-V support in the upstream kernel: arch/x86/kernel/cpu/mshyperv.c arch/x86/include/asm/mshyperv.h arch/x86/include/uapi/asm/hyperv.h include/linux/hyperv.h drivers/hv/channel.c drivers/hv/channel_mgmt.c drivers/hv/connection.c drivers/hv/hv_balloon.c drivers/hv/hv.c drivers/hv/hv_fcopy.c drivers/hv/hv_kvp.c drivers/hv/hv_snapshot.c drivers/hv/hv_util.c drivers/hv/hv_utils_transport.c drivers/hv/hv_utils_transport.h drivers/hv/hyperv_vmbus.h drivers/hv/ring_buffer.c drivers/hv/vmbus_drv.c tools/hv/hv_fcopy_daemon.c tools/hv/hv_get_dhcp_info.sh tools/hv/hv_get_dns_info.sh tools/hv/hv_kvp_daemon.c tools/hv/hv_set_ifconfig.sh tools/hv/hv_vss_daemon.c tools/hv/lsvmbus drivers/input/serio/hyperv-keyboard.c drivers/net/hyperv/hyperv_net.h drivers/net/hyperv/netvsc.c drivers/net/hyperv/netvsc_drv.c drivers/net/hyperv/rndis_filter.c drivers/scsi/storvsc_drv.c drivers/hid/hid-hyperv.c drivers/pci/host/pci-hyperv.c drivers/video/fbdev/hyperv_fb.c While I know a number of post-4.6 commits are already included, I am including all of the commits from 4.6 to 4.7.2 for reference: channel_mgmt.c : commit cd95aad5579371ac332507fc946008217fc37e6c : Drivers: hv: vmbus: handle various crash scenarios connection.c : commit 5cc472477f928fb8584eb8e08245c9cf9002d74a : Drivers: hv: vmbus: Export the vmbus_set_event() API hv_balloon.c : commit 77c0c9735bc0ba5898e637a3a20d6bcb50e3f67d : Drivers: hv: balloon: don't crash when memory is added in non-sorted order hv_balloon.c : commit d19a55d6ed5bf0ffe553df2d8bf91d054ddf2d76 : Drivers: hv: balloon: reset host_specified_ha_region hv_kvp.c : commit 4dbfc2e68004c60edab7e8fd26784383dd3ee9bc : Drivers: hv: kvp: fix IP Failover hyperv_fb.c : commit 696ca5e82c057a272381ae6064d59eb97a578397 : drivers:hv: Use new vmbus_mmio_free() from client drivers. hyperv.h : commit 97fb77dc87582300fa3c141b63699f853576cab1 : drivers:hv: Make a function to free mmio regions through vmbus hyperv.h : commit a6341f24cdf1ec14dc26743a409a17378db5 : Drivers: hv: vmbus: Introduce functions for estimating room in the ring buffer hyperv.h : commit ab028db41ca9174caab7f9e3fc0a2e7f4a418410 : Drivers: hv: vmbus: Implement APIs to support "in place" consumption of vmbus packets hyperv_net.h : commit 10082f98878a9dff1563745f9f1dd9d1ff142700 : hv_netvsc: Eliminate status from struct hv_netvsc_packet hyperv_net.h : commit 3d541ac5a92af708d0085925d136f875f3a58d57 : hv_netvsc: untangle the pointer mess hyperv_net.h : commit c85e4924452ae8225c8829f3fa8a2f7baa34bc5c : hv_netvsc: Fix book keeping of skb during batching process hyperv_vmbus.h : commit 4dbfc2e68004c60edab7e8fd26784383dd3ee9bc : Drivers: hv: kvp: fix IP Failover hyperv_vmbus.h : commit 5cc472477f928fb8584eb8e08245c9cf9002d74a : Drivers: hv: vmbus: Export the vmbus_set_event() API hyperv_vmbus.h : commit cd95aad5579371ac332507fc946008217fc37e6c : Drivers: hv: vmbus: handle various crash scenarios lsvmbus : commit 552beb4930ef3889d42a049eb9ba3533b4cbe0f6 : tools: hv: lsvmbus: add pci pass-through UUID netvsc_drv.c : commit 15cfd40771e18a4e9b788c64c9db2606f958b93d : hv_netvsc: Fix the list processing for network change event netvsc_drv.c : commit 1bdcec8a5f05445752a0639edd603ac09ae6c553 : hv_netvsc: use start_remove flag to protect netvsc_link_change() netvsc_drv.c : commit 84bf9cefb162b197da20a0f4388929f4b5ba5db4 : hv_netvsc: Implement support for VF drivers on Hyper-V pci-hyperv.c : commit 696ca5e82c057a272381ae6064d59eb97a578397 : drivers:hv: Use new vmbus_mmio_free() from client drivers. pci-hyperv.c : commit bdd74440d9e887b1fa648eefa17421def5f5243c : PCI: hv: Add explicit barriers to config space access pci-hyperv.c : commit deb22e5c84c884a129d801cf3bfde7411536998d : PCI: hv: Report resources release after stopping the bus ring_buffer.c : commit a6341f24cdf1ec14dc26743a409a17378db5 : Drivers: hv: vmbus: Introduce functions f
[Kernel-packages] [Bug 1583357] Re: [Hyper-V] Rebase Hyper-V to 4.6 kernel
Verification is also done on our end, no new issues to report here. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1583357 Title: [Hyper-V] Rebase Hyper-V to 4.6 kernel Status in linux package in Ubuntu: Fix Released Status in linux source package in Xenial: Fix Released Bug description: Please rebase Hyper-V support to the final v4.6 upstream kernel. The following files comprise Hyper-V support in the upstream kernel: arch/x86/kernel/cpu/mshyperv.c arch/x86/include/asm/mshyperv.h arch/x86/include/uapi/asm/hyperv.h include/linux/hyperv.h drivers/hv/channel.c drivers/hv/channel_mgmt.c drivers/hv/connection.c drivers/hv/hv_balloon.c drivers/hv/hv.c drivers/hv/hv_fcopy.c drivers/hv/hv_kvp.c drivers/hv/hv_snapshot.c drivers/hv/hv_util.c drivers/hv/hv_utils_transport.c drivers/hv/hv_utils_transport.h drivers/hv/hyperv_vmbus.h drivers/hv/ring_buffer.c drivers/hv/vmbus_drv.c tools/hv/hv_fcopy_daemon.c tools/hv/hv_get_dhcp_info.sh tools/hv/hv_get_dns_info.sh tools/hv/hv_kvp_daemon.c tools/hv/hv_set_ifconfig.sh tools/hv/hv_vss_daemon.c tools/hv/lsvmbus drivers/input/serio/hyperv-keyboard.c drivers/net/hyperv/hyperv_net.h drivers/net/hyperv/netvsc.c drivers/net/hyperv/netvsc_drv.c drivers/net/hyperv/rndis_filter.c drivers/scsi/storvsc_drv.c drivers/hid/hid-hyperv.c drivers/pci/host/pci-hyperv.c drivers/video/fbdev/hyperv_fb.c While I know a number of post-4.4 commits are already committed, I am including all of the commits from 4.4 to 4.6 for reference: mshyperv.c : commit 1e2ae9ec072f3b7887f456426bc2cf23b80f661a : x86/hyperv: Avoid reporting bogus NMI status for Gen2 instances mshyperv.c : commit 1b74dde7c47c19a73ea3e9fac95ac27b5d3d50c5 : x86/cpu: Convert printk(KERN_ ...) to pr_(...) hyperv.h : commit 45870a441361d1c05a5f767c4ece2f6e30e0da9c : Drivers: hv: ring_buffer: remove stray smp_read_barrier_depends() hyperv.h : commit e8d6ca023efce3bd80050dcd9e708ee3cf8babd4 : Drivers: hv: vmbus: define the new offer type for Hyper-V socket (hvsock) hyperv.h : commit 5c23a1a5c60b0f472cfa61cd7d8279f8aaeb5b64 : Drivers: hv: vmbus: define a new VMBus message type for hvsock hyperv.h : commit 499e8401a515d04daa986b995da710d2b9737764 : Drivers: hv: vmbus: add a per-channel rescind callback hyperv.h : commit 3c75354d043ad546148d6992e40033ecaefc5ea5 : Drivers: hv: vmbus: add a helper function to set a channel's pending send size hyperv.h : commit 8981da320a11217589aa3c50f9e891bcdef07ece : Drivers: hv: vmbus: add a hvsock flag in struct hv_driver hyperv.h : commit b9830d120cbe155863399f25eaef6aa8353e767f : Drivers: hv: util: Pass the channel information during the init call channel.c : commit 63d55b2aeb5e4faa170316fee73c3c47ea9268c7 : Drivers: hv: vmbus: serialize process_chn_event() and vmbus_close_internal() channel.c : commit 5c23a1a5c60b0f472cfa61cd7d8279f8aaeb5b64 : Drivers: hv: vmbus: define a new VMBus message type for hvsock channel.c : commit fe760e4d64fe5c17c39e86c410d41f6587ee88bc : Drivers: hv: vmbus: Give control over how the ring access is serialized channel.c : commit 8599846d73997cdbccf63f23394d871cfad1e5e6 : Drivers: hv: vmbus: Fix a Host signaling bug channel_mgmt.c : commit fe760e4d64fe5c17c39e86c410d41f6587ee88bc : Drivers: hv: vmbus: Give control over how the ring access is serialized channel_mgmt.c : commit 79fd8e706637a5c7c41f9498fe0fbfb437abfdc8 : Drivers: hv: vmbus: avoid infinite loop in init_vp_index() channel_mgmt.c : commit 75ff3a8a9168df750b5bd0589e897a6c0517a9f1 : Drivers: hv: vmbus: avoid wait_for_completion() on crash channel_mgmt.c : commit 5c23a1a5c60b0f472cfa61cd7d8279f8aaeb5b64 : Drivers: hv: vmbus: define a new VMBus message type for hvsock connection.c : commit d6f591e339d23f434efda11917da511870891472 : Drivers: hv: vmbus: channge vmbus_connection.channel_lock to mutex connection.c : commit 75ff3a8a9168df750b5bd0589e897a6c0517a9f1 : Drivers: hv: vmbus: avoid wait_for_completion() on crash connection.c : commit 1b807e1011af46a595ba46c75ad5e20ad7177af7 : Drivers: hv: vmbus: Cleanup vmbus_set_event() hv.c : commit a108393dbf764efb2405f21ca759806c65b8bc16 : drivers:hv: Export the API to invoke a hypercall on Hyper-V hv.c : commit c35b82ef0294ae5052120615f5cfcef17c5a6bf7 : drivers/hv: correct tsc page sequence invalid value hv.c : commit 9220e39b5c900c67ddcb517d52fe52d90fb5e3c8 : Drivers: hv: vmbus: fix build warning hv.c : commit d81274aae61c0a045cd0f34191c51fa64ba58bc4 : Drivers: hv: vmbus: Support handling messages on multiple CPUs hv.c : commit 3ccb4fd8f492f99aece21acc1bd6142275f26236 : Drivers: hv: vmbus: don't manipulate with clocksources on crash hv_fcopy.c : commit 3cace4a616108539e2730f8dc21a636474395e0f : Drivers:
[Kernel-packages] [Bug 1555786] Re: [Hyper-V] VM with ubuntu 32bit with linux-next does not boot
We have a patch that was created for 32bit and testing it now it's also resolving the upstream 32bit boot issue. Waiting for it to be accepted in upstream, so we should be done with any of the current bisect work. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1555786 Title: [Hyper-V] VM with ubuntu 32bit with linux-next does not boot Status in linux package in Ubuntu: Triaged Bug description: We identified that at least ubuntu (let's take 15.10) does not boot if installed in the 32bit architecture, and using the linux-next upstream kernel 4.5 on it. This has been seen on other distributions as well. We took both the official linux-next branch from kernel.org and the one from kernel.ubuntu.com v4.5-rc7. For the compilation process we went either with the 4.2 kernel config file from the installed running kernel, and also built the config separately. No errors have been encountered during the build or install process of the 4.5 kernel, however at boot, the VM will just hang. There are no call traces or messages at boot to show any pottential issue. Have you seen this on your end when testing the 32bit build? Attaching the full serial log for reference, however I don't see any errors in the kernel boot process. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1555786/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
