[CentOS] Null deference panic in CentOS-6.5
Hi, I got a panic when running CentOS-6.5: crash> bt PID: 106074 TASK: 8839c1e32ae0 CPU: 4 COMMAND: "flushd4[cbd-sd-" #0 [8839c2a91900] machine_kexec at 81038fa9 #1 [8839c2a91960] crash_kexec at 810c5992 #2 [8839c2a91a30] oops_end at 81515c90 #3 [8839c2a91a60] no_context at 81049f1b #4 [8839c2a91ab0] __bad_area_nosemaphore at 8104a1a5 #5 [8839c2a91b00] bad_area_nosemaphore at 8104a273 #6 [8839c2a91b10] __do_page_fault at 8104a9bf #7 [8839c2a91c30] do_page_fault at 81517bae #8 [8839c2a91c60] page_fault at 81514f95 [exception RIP: rb_next+1] RIP: 81286e21 RSP: 8839c2a91d10 RFLAGS: 00010046 RAX: RBX: 88204b501c00 RCX: RDX: 88013bc56840 RSI: 88013bc568d8 RDI: 0010 RBP: 8839c2a91d60 R8: 0001 R9: 0001 R10: R11: R12: R13: R14: R15: ORIG_RAX: CS: 0010 SS: 0018 #9 [8839c2a91d18] pick_next_task_fair at 81068121 #10 [8839c2a91d68] schedule at 81511e08 #11 [8839c2a91e28] flushd_run at a07a2cbd [cbd] #12 [8839c2a91ee8] kthread at 8109acd6 #13 [8839c2a91f48] kernel_thread at 8100c20a The [cbd] is a module developed by us, I think this bug has nothing to do with it. And the contents of rq in pick_next_task(struct rq *rq) is (see attachement for full contents of struct rq): struct rq { lock = { raw_lock = { slock = 67109881 } }, nr_running = 2, cpu_load = {0, 5923, 14993, 13888, 9115}, last_load_update_tick = 4365159236, nohz_balance_kick = 0 '\000', skip_clock_update = 0, load = { weight = 2, inv_weight = 0 }, nr_load_updates = 21530842, nr_switches = 148355748, cfs = { load = { weight = 2, inv_weight = 0 }, nr_running = 1, h_nr_running = 2, exec_clock = 3309310258875, min_vruntime = 1181294560093, tasks_timeline = { rb_node = 0x0 }, rb_leftmost = 0x0, tasks = { next = 0x88013bc568e8, prev = 0x88013bc568e8 }, balance_iterator = 0x88013bc568e8, curr = 0x88204b501e00, next = 0x0, last = 0x0, skip = 0x0, nr_spread_over = 5, We can see that the value if rq->cfs.nr_running is not zero, but rb_leftmost is null. With skip is null, this causes null deference panic in pick_next_entity() of pick_next_task_fair(). Does anyone have encountered same problem or advice? Thanks struct rq { lock = { raw_lock = { slock = 67109881 } }, nr_running = 2, cpu_load = {0, 5923, 14993, 13888, 9115}, last_load_update_tick = 4365159236, nohz_balance_kick = 0 '\000', skip_clock_update = 0, load = { weight = 2, inv_weight = 0 }, nr_load_updates = 21530842, nr_switches = 148355748, cfs = { load = { weight = 2, inv_weight = 0 }, nr_running = 1, h_nr_running = 2, exec_clock = 3309310258875, min_vruntime = 1181294560093, tasks_timeline = { rb_node = 0x0 }, rb_leftmost = 0x0, tasks = { next = 0x88013bc568e8, prev = 0x88013bc568e8 }, balance_iterator = 0x88013bc568e8, curr = 0x88204b501e00, next = 0x0, last = 0x0, skip = 0x0, nr_spread_over = 5, rq = 0x88013bc56840, on_list = 1, leaf_cfs_rq_list = { next = 0x881b03781690, prev = 0x882050d9ee90 }, tg = 0x81e25cc0 , task_weight = 0, h_load = 1026, load_avg = 0, load_period = 0, load_stamp = 1, load_last = 0, load_unacc_exec_time = 3309310258875, load_contribution = 0, runtime_enabled = 0, runtime_expires = 0, runtime_remaining = 0, throttled_timestamp = 0, throttled = 0, throttle_count = 0, throttled_list = { next = 0x88013bc569b8, prev = 0x88013bc569b8 } }, rt = { active = { bitmap = {0, 68719476736}, queue = {{ next = 0x88013bc569d8, prev = 0x88013bc569d8 }, { next = 0x88013bc569e8, prev = 0x88013bc569e8 }, { next = 0x88013bc569f8, prev = 0x88013bc569f8 }, { next = 0x88013bc56a08, prev = 0x88013bc56a08 }, { next = 0x88013bc56a18, prev = 0x88013bc56a18 }, { next = 0x88013bc56a28, prev = 0x88013bc56a28 }, { next = 0x88013bc56a38, prev = 0x88013bc56a38 }, { next = 0x88013bc56a48, prev = 0x88013b
Re: [CentOS] Null deference panic in CentOS-6.5
I googled this issue and found so many people have encountered, but most of them just said "the newer kernel doesn't have this problem, so upgrade kernel". We can't upgrade kernel easily, so we need to *really* solve this problem. On 10/18/2017 04:41 PM, John Hodrien wrote: On Wed, 18 Oct 2017, wuzhouhui wrote: Does anyone have encountered same problem or advice? Expect minimal help when running custom kernel modules on painfully old CentOS kernels? jh ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Null deference panic in CentOS-6.5
Fine, it seems that upgrade kernel is the only effective solution. > On 18 Oct 2017, at 10:00 PM, Stephen John Smoogen wrote: > > On 18 October 2017 at 04:50, wuzhouhui wrote: >> I googled this issue and found so many people have encountered, but most of >> them just said "the newer kernel doesn't have this problem, so upgrade >> kernel". We can't upgrade kernel easily, so we need to *really* solve this >> problem. >> >> > > If you can't update the kernel then how can anyone fix the problem? > The kernel needs to be changed out in some way. [Yes there are ways to > binary patch a running kernel but it is a) frought with danger b) > experts only area. People who do that do not offer their services for > free for a reason.] > > -- > Stephen J Smoogen. > ___ > CentOS mailing list > CentOS@centos.org > https://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] Can't see register value in crash vmcore
OS: CentOS 6.5 Crash: crash-7.1.0-6.el6.x86_64 Kdump: kexec-tools-2.0.0-273.el6.x86_64 GDB: gdb-7.2-60.el6_4.1.x86_64 /etc/kdump.conf: core_collector makedumpfile -c --message-level 1 -d 31 Kernel crashed by panic("string"), but I can't see any register in vmcore: crash> bt PID: 53331 TASK: 880c523ed540 CPU: 2 COMMAND: "bw_sd-ar-7-0_2" #0 [880c4f12f978] machine_kexec at 81038ed9 #1 [880c4f12f9d8] crash_kexec at 810c5a82 #2 [880c4f12faa8] panic at 815113b2 #3 [880c4f12fb28] sd_submit_bio at a0747a02 [sd] #4 [880c4f12fb68] submit_clone_bio at a0747d2b [sd] #5 [880c4f12fb78] split_and_submit_bio_for_cbd at a0747ec9 [sd] #6 [880c4f12fbf8] sd_make_request at a074c812 [sd] #7 [880c4f12fc68] sdu_make_request at a074ca41 [sd] #8 [880c4f12fc88] generic_make_request at 81264d70 #9 [880c4f12fd68] submit_bio at 81265140 #10 [880c4f12fdb8] submit_area_bio at a04ade20 [scst_vdisk] #11 [880c4f12fde8] bwraid_submit_bio at a04b03b2 [scst_vdisk] #12 [880c4f12fe38] worker_thread at 81094c50 #13 [880c4f12fee8] kthread at 8109ae26 #14 [880c4f12ff48] kernel_thread at 8100c20a crash> Is it normal? Thanks. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] soft lockup after set multicast_router of bridge and it's port to 2
OS: CentOS 6.5. After I set multicast_router of bridge and it's port to 2, like following: echo 2 > /sys/devices/virtual/net/eth81/bridge/multicast_router echo 2 > /sys/devices/virtual/net/bond2/brport/multicast_router Then soft lockup occured: Message from syslogd@node-0 at Jan 9 15:47:12 ... kernel:BUG: soft lockup - CPU#0 stuck for 61s! [swapper:0] And the call trace is RIP: 0010:[] [] br_multicast_flood+0x88/0x140 [bridge] RSP: 0018:88013bc038f0 EFLAGS: 0246 RAX: 88404f816020 RBX: 88013bc03940 RCX: 88204e40a640 RDX: 882002b9ce01 RSI: 882002b9ce80 RDI: RBP: 8100bb93 R08: 0001 R09: ff09f4a1 R10: 88202c884070 R11: R12: 88013bc03870 R13: 882002b9ce80 R14: 88013bc03860 R15: 8151b225 FS: () GS:88013bc0() knlGS: CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b CR2: 7fa11a942000 CR3: 01a85000 CR4: 001407e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Process swapper (pid: 0, threadinfo 81a0, task 81a8d020) Stack: 880be7e100028813 882002b9ce80 882002b9ce80 a04f3930 880be7e1 882002b9ce80 882002b9ce80 88200286c042 88202ae7c6e0 882002b9ceb8 88013bc03950 a04f36d5 Call Trace: [] ? __br_forward+0x0/0xd0 [bridge] [] ? br_multicast_forward+0x15/0x20 [bridge] [] ? br_handle_frame_finish+0x144/0x2a0 [bridge] [] ? br_nf_pre_routing_finish+0x238/0x350 [bridge] [] ? br_nf_pre_routing+0x48b/0x7b0 [bridge] [] ? __kfree_skb+0x47/0xa0 [] ? nf_iterate+0x69/0xb0 [] ? br_handle_frame_finish+0x0/0x2a0 [bridge] [] ? nf_hook_slow+0x76/0x120 [] ? br_handle_frame_finish+0x0/0x2a0 [bridge] [] ? br_handle_frame+0x18c/0x250 [bridge] [] ? __netif_receive_skb+0x529/0x750 [] ? __alloc_skb+0x7a/0x180 [] ? netif_receive_skb+0x58/0x60 [] ? napi_skb_finish+0x50/0x70 [] ? napi_gro_receive+0x39/0x50 [] ? bnx2x_rx_int+0x83f/0x1630 [bnx2x] [] ? perf_event_task_sched_out+0x4c/0x70 [] ? bnx2x_poll+0x23e/0x2f0 [bnx2x] [] ? net_rx_action+0x103/0x2f0 [] ? __do_softirq+0xc1/0x1e0 [] ? handle_IRQ_event+0x60/0x170 [] ? call_softirq+0x1c/0x30 [] ? do_softirq+0x65/0xa0 [] ? irq_exit+0x85/0x90 [] ? do_IRQ+0x75/0xf0 [] ? ret_from_intr+0x0/0x11 [] ? mwait_idle+0x77/0xd0 [] ? atomic_notifier_call_chain+0x1a/0x20 [] ? cpu_idle+0xb6/0x110 [] ? rest_init+0x7a/0x80 [] ? start_kernel+0x405/0x411 [] ? x86_64_start_reservations+0x125/0x129 [] ? x86_64_start_kernel+0x115/0x124 Does anyone know the reason? ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] soft lockup after set multicast_router of bridge and it's port to 2
Never mind, commit 1a040eaca1a2 (bridge: fix multicast router rlist endless loop) fixes it. > -原始邮件- > 发件人: wuzhouhui > 发送时间: 2018-01-10 15:19:09 (星期三) > 收件人: centos@centos.org > 抄送: wuzhouhui14 > 主题: soft lockup after set multicast_router of bridge and it's port to 2 > > OS: CentOS 6.5. > > After I set multicast_router of bridge and it's port to 2, like following: > echo 2 > /sys/devices/virtual/net/eth81/bridge/multicast_router > echo 2 > /sys/devices/virtual/net/bond2/brport/multicast_router > Then soft lockup occured: > Message from syslogd@node-0 at Jan 9 15:47:12 ... > kernel:BUG: soft lockup - CPU#0 stuck for 61s! [swapper:0] > And the call trace is > RIP: 0010:[] [] > br_multicast_flood+0x88/0x140 [bridge] > RSP: 0018:88013bc038f0 EFLAGS: 0246 > RAX: 88404f816020 RBX: 88013bc03940 RCX: 88204e40a640 > RDX: 882002b9ce01 RSI: 882002b9ce80 RDI: > RBP: 8100bb93 R08: 0001 R09: ff09f4a1 > R10: 88202c884070 R11: R12: 88013bc03870 > R13: 882002b9ce80 R14: 88013bc03860 R15: 8151b225 > FS: () GS:88013bc0() > knlGS: > CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b > CR2: 7fa11a942000 CR3: 01a85000 CR4: 001407e0 > DR0: DR1: DR2: > DR3: DR6: fffe0ff0 DR7: 0400 > Process swapper (pid: 0, threadinfo 81a0, task > 81a8d020) > Stack: > 880be7e100028813 882002b9ce80 882002b9ce80 a04f3930 > 880be7e1 882002b9ce80 882002b9ce80 88200286c042 > 88202ae7c6e0 882002b9ceb8 88013bc03950 a04f36d5 > Call Trace: > > [] ? __br_forward+0x0/0xd0 [bridge] > [] ? br_multicast_forward+0x15/0x20 [bridge] > [] ? br_handle_frame_finish+0x144/0x2a0 [bridge] > [] ? br_nf_pre_routing_finish+0x238/0x350 [bridge] > [] ? br_nf_pre_routing+0x48b/0x7b0 [bridge] > [] ? __kfree_skb+0x47/0xa0 > [] ? nf_iterate+0x69/0xb0 > [] ? br_handle_frame_finish+0x0/0x2a0 [bridge] > [] ? nf_hook_slow+0x76/0x120 > [] ? br_handle_frame_finish+0x0/0x2a0 [bridge] > [] ? br_handle_frame+0x18c/0x250 [bridge] > [] ? __netif_receive_skb+0x529/0x750 > [] ? __alloc_skb+0x7a/0x180 > [] ? netif_receive_skb+0x58/0x60 > [] ? napi_skb_finish+0x50/0x70 > [] ? napi_gro_receive+0x39/0x50 > [] ? bnx2x_rx_int+0x83f/0x1630 [bnx2x] > [] ? perf_event_task_sched_out+0x4c/0x70 > [] ? bnx2x_poll+0x23e/0x2f0 [bnx2x] > [] ? net_rx_action+0x103/0x2f0 > [] ? __do_softirq+0xc1/0x1e0 > [] ? handle_IRQ_event+0x60/0x170 > [] ? call_softirq+0x1c/0x30 > [] ? do_softirq+0x65/0xa0 > [] ? irq_exit+0x85/0x90 > [] ? do_IRQ+0x75/0xf0 > [] ? ret_from_intr+0x0/0x11 > > [] ? mwait_idle+0x77/0xd0 > [] ? atomic_notifier_call_chain+0x1a/0x20 > [] ? cpu_idle+0xb6/0x110 > [] ? rest_init+0x7a/0x80 > [] ? start_kernel+0x405/0x411 > [] ? x86_64_start_reservations+0x125/0x129 > [] ? x86_64_start_kernel+0x115/0x124 > > Does anyone know the reason? ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] Adjust type of rw in submit_bio from int to unsigned long
Hi, I am a developer who worked on CentOS. Recently I am working on porting one of my block drivers from CentOS 6.x to CentOS 7.x. In newest kernel (kernel-3.10.0-693.17.1.el7) I found there is an issue in submit_bio()'s first argument: void submit_bio(int rw, struct bio *bio) The type of bi_rw of struct bio is unsigned long, and the number of enum rq_flags_bits also exceeds 32, so we should better using unsigned long for rw in submit_bio(), like: void submit_bio(unsigned long rw, struct bio *bio) ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Adjust type of rw in submit_bio from int to unsigned long
Forward mail to centos-devel mailing list for getting more attentions! Sorry for disturbing. > -Original Messages- > From: wuzhouhui > Sent Time: 2018-02-07 13:44:07 (Wednesday) > To: centos@centos.org > Cc: wuzhouhui14 > Subject: Adjust type of rw in submit_bio from int to unsigned long > > Hi, I am a developer who worked on CentOS. Recently I am working on porting > one of my > block drivers from CentOS 6.x to CentOS 7.x. In newest kernel > (kernel-3.10.0-693.17.1.el7) > I found there is an issue in submit_bio()'s first argument: > void submit_bio(int rw, struct bio *bio) > The type of bi_rw of struct bio is unsigned long, and the number of enum > rq_flags_bits > also exceeds 32, so we should better using unsigned long for rw in > submit_bio(), like: > void submit_bio(unsigned long rw, struct bio *bio) > > ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] Network broke for a while when libvirtd start
When start service libvirtd by service libvirtd start the network will broke for a while and then reconnected. Following is /var/log/messages: Feb 24 13:28:51 node-0 kernel: lo: Dropping TSO features since no CSUM feature. Feb 24 13:28:51 node-0 kernel: lo: Disabled Privacy Extensions Feb 24 13:28:51 node-0 kernel: virbr0: Dropping TSO features since no CSUM feature. Feb 24 13:28:51 node-0 kernel: virbr0: Dropping TSO6 features since no CSUM feature. Feb 24 13:28:51 node-0 kernel: device virbr0-nic entered promiscuous mode Feb 24 13:28:51 node-0 kernel: virbr0: starting userspace STP failed, starting kernel STP Feb 24 13:28:51 node-0 kernel: ip_tables: (C) 2000-2006 Netfilter Core Team Feb 24 13:28:51 node-0 kernel: nf_conntrack version 0.5.0 (16384 buckets, 65536 max) Feb 24 13:28:51 node-0 kernel: virbr0: topology change detected, propagating Feb 24 13:28:51 node-0 kernel: virbr0: port 1(virbr0-nic) entering forwarding state Feb 24 13:28:51 node-0 kernel: 8021q: adding VLAN 0 to HW filter on device virbr0 Feb 24 13:28:51 node-0 kernel: ixgbe :02:00.0: eth2: detected SFP+: 3 Feb 24 13:28:52 node-0 kernel: ixgbe :02:00.1: eth3: detected SFP+: 4 Feb 24 13:28:52 node-0 kernel: bonding: bond0: link status definitely down for interface eth2, disabling it Feb 24 13:28:52 node-0 kernel: virbr0: port 1(virbr0-nic) entering disabled state Feb 24 13:28:52 node-0 kernel: bonding: bond0: link status definitely down for interface eth3, disabling it Feb 24 13:28:53 node-0 kernel: ixgbe :02:00.0: eth2: NIC Link is Up 10 Gbps, Flow Control: RX/TX Feb 24 13:28:53 node-0 kernel: bond0: link status definitely up for interface eth2, 1 Mbps full duplex. Feb 24 13:28:53 node-0 kernel: ixgbe :02:00.1: eth3: NIC Link is Up 10 Gbps, Flow Control: RX/TX Feb 24 13:28:53 node-0 kernel: bond0: link status definitely up for interface eth3, 1 Mbps full duplex. OS: CentOS 6.5 libvirt: libvirt-daemon-1.2.5-1.mira1.x86_64 Does anyone know the reason? ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Network broke for a while when libvirtd start
Never mind, I have found the reason. When libvirtd started, it will create bridge virbr0 and then write 1 to /proc/sys/net/ipv4/ip_forward (0 in default). Set ip_forward from 0 to 1 will cause ixgbe driver reset NIC, so the network broke for a while. > -Original Messages- > From: "Genghuang Wang" > Sent Time: 2018-02-24 14:34:16 (Saturday) > To: "CentOS mailing list" > Cc: > Subject: Re: [CentOS] Network broke for a while when libvirtd start > > Hello > > > When start service libvirtd by > > > > service libvirtd start > > > > > OS: CentOS 6.5 > > libvirt: libvirt-daemon-1.2.5-1.mira1.x86_64 > > https://www.redhat.com/mailman/listinfo/libvirt-users > is the official mailing list for the libvirt daemon, maybe you can ask > in there and get better support. > > > Does anyone know the reason? > > This mailing list is for the general usage of the CentOS system, I am > afraid that not many experts about libvert could be found here. > > If you ask in the most appropriate mailing list, you may get the > quickest and the most helpful assistance. > ___ > CentOS mailing list > CentOS@centos.org > https://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] How to update modules in iniramfs fastly
I know dracut can update modules in initramfs, but I think it is too slow. So I'm wondering what is the fastest way to update modules in initramfs of CentOS 7? Thanks! ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] How to update modules in iniramfs fastly
> -Original Messages- > From: "Steven Tardy" > Sent Time: 2018-02-26 10:48:48 (Monday) > To: "CentOS mailing list" > Cc: > Subject: Re: [CentOS] How to update modules in iniramfs fastly > > On Sun, Feb 25, 2018 at 8:29 PM wuzhouhui > wrote: > > > I know dracut can update modules in initramfs, but I think it is too > > slow. So I'm wondering what is the fastest way to update modules in > > initramfs of CentOS 7? > > > `dracut` calls `mkinitrd` which rebuilds the initrd file. . . you could do > it manually but that is prone to errors ( > https://access.redhat.com/solutions/24029). This solution does not work in CentOS 7, because initramfs in CentOS 7 is not a gzipped cpio: [root@bogon a]# file /boot/initramfs-3.10.0-693.el7.x86_64.img /boot/initramfs-3.10.0-693.el7.x86_64.img: ASCII cpio archive (SVR4 with no CRC) If I use zcat /boot/initrd-2.6.18-164.6.1.el5.img | cpio -idmv to uncompress initramfs, it will report errors: [root@bogon a]# zcat /boot/initramfs-3.10.0-693.el7.x86_64.img | cpio -idmv gzip: /boot/initramfs-3.10.0-693.el7.x86_64.img: not in gzip format cpio: premature end of archive > ___ > CentOS mailing list > CentOS@centos.org > https://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] How to update modules in iniramfs fastly
So, in the end, we can't recreate initramfs of CentOS 7 manually just like https://access.redhat.com/solutions/24029 did in CentOS 6? > -Original Messages- > From: "Robert P. J. Day" > Sent Time: 2018-02-26 14:05:24 (Monday) > To: "CentOS mailing list" > Cc: > Subject: Re: [CentOS] How to update modules in iniramfs fastly > > On Mon, 26 Feb 2018, wuzhouhui wrote: > > > > -Original Messages- > > > From: "Steven Tardy" > > > Sent Time: 2018-02-26 10:48:48 (Monday) > > > To: "CentOS mailing list" > > > Cc: > > > Subject: Re: [CentOS] How to update modules in iniramfs fastly > > > > > > On Sun, Feb 25, 2018 at 8:29 PM wuzhouhui > > > wrote: > > > > > > > I know dracut can update modules in initramfs, but I think it is too > > > > slow. So I'm wondering what is the fastest way to update modules in > > > > initramfs of CentOS 7? > > > > > > > > > `dracut` calls `mkinitrd` which rebuilds the initrd file. . . you could do > > > it manually but that is prone to errors ( > > > https://access.redhat.com/solutions/24029). > > i think you have that backwards ... mkinitrd is simply a wrapper > around a call to dracut, which builds an initramfs. > > > This solution does not work in CentOS 7, because initramfs in CentOS > > 7 is not a gzipped cpio: > > it is, but to get to the content, you need to use "skipcpio" to jump > over the initial tiny cpio archive. see, for example: > > https://sites.google.com/site/syscookbook/rhel/rhel-kernel-rebuild > > rday > ___ > CentOS mailing list > CentOS@centos.org > https://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] How to update modules in iniramfs fastly
> -Original Messages- > From: "Leon Fauster" > Sent Time: 2018-02-26 22:20:51 (Monday) > To: "CentOS mailing list" > Cc: > Subject: Re: [CentOS] How to update modules in iniramfs fastly > > > > Am 26.02.2018 um 06:46 schrieb wuzhouhui : > > > >> -Original Messages- > >> From: "Steven Tardy" > >> Sent Time: 2018-02-26 10:48:48 (Monday) > >> To: "CentOS mailing list" > >> Cc: > >> Subject: Re: [CentOS] How to update modules in iniramfs fastly > >> > >> On Sun, Feb 25, 2018 at 8:29 PM wuzhouhui > >> wrote: > >> > >>> I know dracut can update modules in initramfs, but I think it is too > >>> slow. So I'm wondering what is the fastest way to update modules in > >>> initramfs of CentOS 7? > >> > >> > >> `dracut` calls `mkinitrd` which rebuilds the initrd file. . . you could do > >> it manually but that is prone to errors ( > >> https://access.redhat.com/solutions/24029). > > This solution does not work in CentOS 7, because initramfs in CentOS 7 is > > not > > a gzipped cpio: > > [root@bogon a]# file /boot/initramfs-3.10.0-693.el7.x86_64.img > > /boot/initramfs-3.10.0-693.el7.x86_64.img: ASCII cpio archive (SVR4 with > > no CRC) > > If I use > > zcat /boot/initrd-2.6.18-164.6.1.el5.img | cpio -idmv > > to uncompress initramfs, it will report errors: > > [root@bogon a]# zcat /boot/initramfs-3.10.0-693.el7.x86_64.img | cpio > > -idmv > > > > gzip: /boot/initramfs-3.10.0-693.el7.x86_64.img: not in gzip format > > cpio: premature end of archive > > > > Maybe some ucode archive is in front of the initrd archive. > > Did you try to unpack it without uncompressing it? Whats the contents? [root@bogon a]# cpio -id < /boot/initramfs-3.10.0-693.el7.x86_64.img 28 blocks [root@bogon a]# ls -R .: early_cpio kernel ./kernel: x86 ./kernel/x86: microcode ./kernel/x86/microcode: GenuineIntel.bin Obviously, above is not what I want. In order to get full contents of initramfs, I have to use skipcpio to skip initial cpio of initramfs: [root@bogon a]# /usr/lib/dracut/skipcpio /boot/initramfs-3.10.0-693.el7.x86_64.img | zcat | cpio -id 85469 blocks [root@bogon a]# ls bin etc libproc run shutdown sysroot usr dev init lib64 root sbin sys tmp var I can use skipcpio to get full contents of initramfs, and then edit files in it. But the problem is how to recreate initramfs by extracted contents? > > -- > LF > > > > > > > > ___ > CentOS mailing list > CentOS@centos.org > https://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] CentOS 7.4 paniced when running LTP tests
LTP version: ltp-full-20180118 Kernel version: 3.10.0-693.el7.x86_64 Reproduce procedure: 1. cd ltp-full-20180118; ./configure; make && make install 2. cd /opt/ltp; ./runltp Trace: [ 377.516270] BUG: unable to handle kernel NULL pointer dereference at (null) [ 377.521746] IP: [] asn1_ber_decoder+0x327/0xd30 [ 377.525865] PGD 9c6ea067 PUD 66831067 PMD 0 [ 377.529043] Oops: [#1] SMP [ 377.531454] Modules linked in: ext4 mbcache jbd2 loop ip6t_rpfilter ipt_REJECT nf_reject_ipv4 ip6t_REJECT nf_reject_ipv6 xt_conntrack ip_set nfnetlink ebtable_nat ebtable_broute bridge stp llc ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter snd_seq_midi snd_seq_midi_event sb_edac edac_core coretemp iosf_mbi crc32_pclmul ghash_clmulni_intel ppdev aesni_intel lrw gf128mul glue_helper ablk_helper cryptd vmw_balloon snd_ens1371 snd_rawmidi snd_ac97_codec ac97_bus snd_seq snd_seq_device snd_pcm dm_mod pcspkr joydev snd_timer nfit sg snd vmw_vmci libnvdimm soundcore [ 377.592112] shpchp i2c_piix4 parport_pc parport ip_tables xfs libcrc32c sr_mod cdrom ata_generic pata_acpi sd_mod crc_t10dif crct10dif_generic vmwgfx drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm crct10dif_pclmul crct10dif_common drm crc32c_intel ata_piix mptspi libata scsi_transport_spi e1000 mptscsih serio_raw mptbase i2c_core [ 377.618291] CPU: 1 PID: 32027 Comm: add_key02 Not tainted 3.10.0-693.el7.x86_64 #1 [ 377.624130] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/02/2015 [ 377.632341] task: 880134c8bf40 ti: 8800b04c8000 task.ti: 8800b04c8000 [ 377.638459] RIP: 0010:[] [] asn1_ber_decoder+0x327/0xd30 [ 377.645145] RSP: 0018:8800b04cbcc0 EFLAGS: 00010206 [ 377.648925] RAX: 003f RBX: RCX: 0040 [ 377.653499] RDX: RSI: RDI: 0070 [ 377.659151] RBP: 8800b04cbda8 R08: 00019bc0 R09: [ 377.663875] R10: 0002 R11: 0040 R12: [ 377.668679] R13: R14: R15: [ 377.673414] FS: 7f57fc60f740() GS:88013964() knlGS: [ 377.678827] CS: 0010 DS: ES: CR0: 80050033 [ 377.682732] CR2: CR3: a9a11000 CR4: 001407e0 [ 377.687576] DR0: DR1: DR2: [ 377.692430] DR3: DR6: 0ff0 DR7: 0400 [ 377.698824] Stack: [ 377.701875] 880139003be8 0206 0202 0202 [ 377.708840] 8800b0535080 817167c0 8801356da200 001c [ 377.716247] 8801356da200 8800b04cbd00 0070 81716740 [ 377.723168] Call Trace: [ 377.726482] [] ? kmem_cache_alloc_trace+0x1d6/0x200 [ 377.732479] [] x509_cert_parse+0x91/0x120 [ 377.738012] [] x509_key_preparse+0x26/0x280 [ 377.743543] [] asymmetric_key_preparse+0x5b/0xd0 [ 377.749370] [] key_create_or_update+0x146/0x460 [ 377.755015] [] SyS_add_key+0x119/0x240 [ 377.760142] [] system_call_fastpath+0x16/0x1b [ 377.765606] Code: e0 01 88 85 48 ff ff ff 74 0d 4c 3b 9d 78 ff ff ff 0f 84 99 fd ff ff 48 8b b5 78 ff ff ff 49 8d 43 ff 48 39 f0 0f 86 90 06 00 00 <41> 0f b6 04 34 48 8d 7e 01 48 89 bd 60 ff ff ff 88 45 86 83 e0 [ 377.788713] RIP [] asn1_ber_decoder+0x327/0xd30 [ 377.794403] RSP [ 377.798198] CR2: ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] Fw: Re: [SPDK] VM boot failed sometimes if using vhost-user-blk with spdk
Forwarded to centos mailing list -Original Messages- From: wuzhouhui Sent Time: 2018-10-30 14:06:00 (Tuesday) To: "storage performance development kit" Cc: centos@centos.org, qemu-disc...@nongnu.org Subject: Re: [SPDK] VM boot failed sometimes if using vhost-user-blk with spdk I enable debug of systemd-udevd by changing guest's /etc/udev/udev.conf to this: udev_log="debug" and regenerate initramfs. Then, we can get more message about this issue. I select some useful messages from /run/initramfs/rdsosreport.txt: systemd-udevd[199] probe /dev/vdb raid offset=8 systemd-udevd[199] no db file to read /run/udev/data/+virtio:virtio1: No such systemd-udevd[199] handling device node '/dev/vdb', devnum=b253:16, mode=0660, systemd-udevd[199] set permissions /dev/vdb, 060660, uid=0, gid=6 systemd-udevd[199] creating symlink '/dev/block/253:16' to '../vdb' systemd-udevd[199] creating link '/dev/disk' to '/dev/vdb' systemd-udevd[199] creating symlink '/dev/disk' to 'vdb' We can see that the symlink /dev/disk was created by system-udevd, and cause boot failed. I also noticed that `blkid /dev/vdb' print nothing, but `blkid /dev/vda*' is normal. The /dev/vdb is correspond to the malloc bdev that spdk created. Is this a bug for system-udevd? (Add centos@centos.org and qemu-disc...@nongun.org in CC list) > -Original Messages- > From: wuzhouhui > Sent Time: 2018-10-30 11:31:15 (Tuesday) > To: qemu-disc...@nongnu.org, s...@lists.01.org > Cc: > Subject: [CASS SPAM][SPDK] VM boot failed sometimes if using vhost-user-blk > with spdk > > I'm using following command line to start VM (The /var/tmp/vhost.0 connected > to a > malloc bdev (16 MB ) created by SPDK): > /home/wuzhouhui/qemu-2.12.1/x86_64-softmmu/qemu-system-x86_64 \ > -name guest=wzh,debug-threads=on \ > -machine pc-i440fx-2.12,accel=kvm,usb=off \ > -cpu host \ > -m 4096 \ > -object > memory-backend-file,id=mem0,size=4096M,mem-path=/dev/hugepages,share=on \ > -numa node,memdev=mem0 \ > -realtime mlock=off \ > -smp 2,sockets=2,cores=1,threads=1 \ > -uuid a84e96e6-2c53-408d-986b-c709bc6a0e51 \ > -no-user-config \ > -nodefaults \ > -rtc base=utc,driftfix=slew \ > -global kvm-pit.lost_tick_policy=delay \ > -no-shutdown \ > -boot strict=on \ > -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \ > -device ahci,id=sata0,bus=pci.0,addr=0x4 \ > -drive > file=/home/wuzhouhui/wzh.qcow2,format=qcow2,if=none,id=drive-virtio-disk0,cache=none > \ > -device > virtio-blk-pci,scsi=off,bus=pci.0,addr=0x3,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=0 > \ > -device usb-tablet,id=input0,bus=usb.0,port=1 \ > -k en-us \ > -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 \ > -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 -msg > timestamp=on \ > -vnc :9 \ > -chardev socket,id=char0,path=/var/tmp/vhost.0 \ > -device vhost-user-blk-pci,id=blk0,chardev=char0,num-queues=4 \ > > But most of the time, VM boot failed with following message in vnc screen: > Warning: /dev/disk/by-uuid/e0dcaf0c-bc23-4df6-b2cd-d40aa1bbb0b5 does not > exist > > Generating "/run/initramfs/rdsosreport.txt" > > Entering emergency mode. Exit the shell to continue. > Type "journalctl" to view system logs. > You might want to save "/run/initramfs/rdsosreport.txt" to a USB stick or > /boot > after mounting them and attach it to a bug report. > > There is some message from /run/initramfs/rdsosreport.txt: > ... > system-udevd[196]: symlink '../../vdb' > '/dev/disk/by-id/virtio-Malloc.tmp-b253:16' failed: Not a directory > ... > > I checked /dev/disk, it should be a directory, but it is a symlink now: > :/# ls -l /dev/disk > lrwxrwxrwx 1 root 0 3 Oct 30 03:08 /dev/disk -> vdb > > If I just remove: > -chardev socket,id=char0,path=/var/tmp/vhost.0 \ > -device vhost-user-blk-pci,id=blk0,chardev=char0,num-queues=4 \ > The VM will boot normally. > > Does anyone have encountered similar issue like this? > > Host OS: CentOS 7.3, with kernel 3.10.0-862.11.6.el7.x86_64 > Guest OS: CentOS 7.5 > Qemu: 2.12.1 > SPDK: f0cb7b871e in master > ___ > SPDK mailing list > s...@lists.01.org > https://lists.01.org/mailman/listinfo/spdk ___ SPDK mailing list s...@lists.01.org https://lists.01.org/mailman/listinfo/spdk ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] where to download kernel-3.10.0-693.17.6.el7 and kernel-devel-3.10.0-693.17.6.el7
Who told you there is kernel-3.10.0-693.17.6.el7 available? You can't find these two rpms in vault.centos.org means that centos.org never release them at all. > -Original Messages- > From: qw > Sent Time: 2018-11-10 15:54:25 (Saturday) > To: centos@centos.org > Cc: > Subject: [CASS SPAM][CentOS] where to download kernel-3.10.0-693.17.6.el7 and > kernel-devel-3.10.0-693.17.6.el7 > > Hi, > > > I check the following link : > http://vault.centos.org/7.4.1708/updates/x86_64/Packages/, and can't find > kernel-3.10.0-693.17.6.el7 and kernel-devel-3.10.0-693.17.6.el7 rpm files. > > > Where can I download the kernel from CentOS website? > > > Thanks! > > > Regards > > > Andrew > ___ > CentOS mailing list > CentOS@centos.org > https://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] centos 7.5 crashed, kernel BUG at net/core/skbuff.c:3668!
... [ 176.025679] random: crng init done [ 411.168635] netem: version 1.3 [ 456.059840] [ cut here ] [ 456.059849] WARNING: CPU: 4 PID: 1918 at net/ipv4/tcp_output.c:1048 tcp_set_skb_tso_segs+0xeb/0x100 [ 456.059851] Modules linked in: sch_netem cirrus ttm drm_kms_helper crc32_pclmul syscopyarea ghash_clmulni_intel sysfillrect sysimgblt fb_sys_fops aesni_intel lrw ppdev gf128mul drm glue_helper ablk_helper cryptd parport_pc parport i2c_piix4 virtio_balloon i2c_core joydev pcspkr ip_tables ext4 mbcache jbd2 ata_generic pata_acpi ata_piix virtio_console virtio_net virtio_blk floppy crct10dif_pclmul virtio_pci crct10dif_common libata serio_raw virtio_ring crc32c_intel virtio [ 456.059886] CPU: 4 PID: 1918 Comm: sshd Kdump: loaded Not tainted 3.10.0-862.14.4.el7.x86_64 #1 [ 456.059887] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2007 [ 456.059890] Call Trace: [ 456.059896] [] dump_stack+0x19/0x1b [ 456.059901] [] __warn+0xd8/0x100 [ 456.059905] [] warn_slowpath_null+0x1d/0x20 [ 456.059908] [] tcp_set_skb_tso_segs+0xeb/0x100 [ 456.059911] [] tcp_init_tso_segs+0x37/0x50 [ 456.059915] [] tcp_write_xmit+0x1f1/0xd00 [ 456.059918] [] __tcp_push_pending_frames+0x2e/0xc0 [ 456.059922] [] tcp_push+0xec/0x120 [ 456.059925] [] tcp_sendmsg+0xd2/0xc80 [ 456.059930] [] inet_sendmsg+0x69/0xb0 [ 456.059935] [] sock_aio_write+0x15d/0x180 [ 456.059940] [] ? set_fd_set+0x21/0x30 [ 456.059944] [] do_sync_write+0x93/0xe0 [ 456.059948] [] vfs_write+0x1c5/0x1f0 [ 456.059953] [] ? get_monotonic_boottime+0x50/0x100 [ 456.059956] [] SyS_write+0x7f/0xf0 [ 456.059961] [] system_call_fastpath+0x22/0x27 [ 456.059963] ---[ end trace 77e1915bd237f005 ]--- [ 728.963668] [ cut here ] [ 728.964320] kernel BUG at net/core/skbuff.c:3668! [ 728.964933] invalid opcode: [#1] SMP [ 728.965501] Modules linked in: sch_netem cirrus ttm drm_kms_helper crc32_pclmul syscopyarea ghash_clmulni_intel sysfillrect sysimgblt fb_sys_fops aesni_intel lrw ppdev gf128mul drm glue_helper ablk_helper cryptd parport_pc parport i2c_piix4 virtio_balloon i2c_core joydev pcspkr ip_tables ext4 mbcache jbd2 ata_generic pata_acpi ata_piix virtio_console virtio_net virtio_blk floppy crct10dif_pclmul virtio_pci crct10dif_common libata serio_raw virtio_ring crc32c_intel virtio [ 728.971540] CPU: 3 PID: 0 Comm: swapper/3 Kdump: loaded Tainted: GW 3.10.0-862.14.4.el7.x86_64 #1 [ 728.972981] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2007 [ 728.973723] task: 94153bb1cf10 ti: 94153bb3 task.ti: 94153bb3 [ 728.974689] RIP: 0010:[] [] __skb_to_sgvec+0x1e4/0x280 [ 728.975792] RSP: 0018:941655183cf8 EFLAGS: 00010202 [ 728.976494] RAX: 94163c68c700 RBX: 05a8 RCX: 941648bd4ac0 [ 728.977407] RDX: 0001 RSI: 05a8 RDI: 02c0 [ 728.978322] RBP: 941655183d38 R08: 941653416cf8 R09: fe544a34ae00 [ 728.979241] R10: 941648bd4800 R11: 000a R12: 05ea [ 728.980160] R13: 05ea R14: R15: 0002 [ 728.981076] FS: () GS:94165518() knlGS: [ 728.982109] CS: 0010 DS: ES: CR0: 80050033 [ 728.982849] CR2: 7f7ed4008000 CR3: 000289e1a000 CR4: 001406e0 [ 728.983778] Call Trace: [ 728.984107] [ 728.984368] [] skb_to_sgvec+0x12/0x30 [ 728.985098] [] start_xmit+0x19f/0x500 [virtio_net] [ 728.985925] [] dev_hard_start_xmit+0x246/0x3b0 [ 728.986741] [] sch_direct_xmit+0x11a/0x250 [ 728.987489] [] __qdisc_run+0x8e/0x360 [ 728.988182] [] net_tx_action+0x1d6/0x240 [ 728.988924] [] __do_softirq+0xf5/0x280 [ 728.989634] [] call_softirq+0x1c/0x30 [ 728.990322] [] do_softirq+0x65/0xa0 [ 728.990994] [] irq_exit+0x105/0x110 [ 728.991680] [] smp_apic_timer_interrupt+0x48/0x60 [ 728.992504] [] apic_timer_interrupt+0x162/0x170 [ 728.993298] [ 728.993566] [] ? __cpuidle_text_start+0x8/0x8 [ 728.994377] [] ? native_safe_halt+0x6/0x10 [ 728.995161] [] default_idle+0x1e/0xc0 [ 728.995869] [] arch_cpu_idle+0x23/0xb0 [ 728.996568] [] cpu_startup_entry+0x14a/0x1e0 [ 728.997330] [] start_secondary+0x1f7/0x270 [ 728.998077] [] start_cpu+0x5/0x14 [ 728.998721] Code: 89 45 c8 e8 3f fe ff ff 44 8b 4d d0 41 01 c7 44 29 cb 74 41 44 8b 55 c4 4c 8b 45 c8 45 01 cd 4d 8b 36 4d 85 f6 75 90 85 db 74 2a <0f> 0b 66 2e 0f 1f 84 00 00 00 00 00 48 c7 c7 00 00 00 80 48 2b [ 729.003191] RIP [] __skb_to_sgvec+0x1e4/0x280 [ 729.005068] RSP Any advice? ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] Where is centos6.x kernel git repo
Hi, I following the steps described in https://wiki.centos.org/Sources to get centos7.x kernel repo. But I'm wondering how to get centos6.x kernel repo. Because when checkout branch 'c6' and found that there is nothing. Thanks ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] How to get unrelease kernel, e.g. 3.10.0-341.el7
Hi, I cloned https://git.centos.org/r/rpms/kernel.git and found that it only contains kernel version that CentOS released. So how do I get the kernel version that CentOS not release officialy, e.g. 3.10.0-341.el7 and 3.10.0-383.el7 (some kernel version I found in kernel.spec's changelog)? Thanks. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] do not uninstall old when yum install new
Hi, I have a specific needs that requires yum do not to uninstall old version when install new one. For example, I found that yum install kernel will install new kernel, and old kernel will remained. But yum install will uninstall old version after install new one, how to disable it? Thanks. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] How to specify kernel version when restart kdump
Hi, Is there a way to specify kernel version when (re)start kdump service? Suppose I have install a new kernel and kdump will generate kdump.img for new kernel in next boot. But I want kdump to generate kdump.img for new kernel immediately, is it possible? Thanks. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] How to specify kernel version when restart kdump
> -Original Messages- > From: "Benjamin Hauger" > Sent Time: 2019-03-27 00:15:21 (Wednesday) > To: centos@centos.org > Cc: > Subject: Re: [CentOS] How to specify kernel version when restart kdump > > kdump operates by booting a fresh kernel to capture the context of a > crashed kernel, and so the only way for kdump to dump a kernel is to > crash it and cause kdump to invoke its post-crash kernel. > > You can manually force a running kernel to panic (and invoke a > correctly-configured kdump) with the following command sequence: > > > echo 1 > /proc/sys/kernel/sysrq > > echo c > /proc/sysrq-trigger > > Cheers, > Ben Hi, Ben I think your response doesn't answered my question. I'm not asking how to trigger kernel crash and see whether the kdump is works, but asking how to specifying kernel version when start kdump service. Thanks. > > > On 3/25/19 7:19 PM, wuzhouhui wrote: > CentOS@centos.org > https://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] How to specify kernel version when restart kdump
> -Original Messages- > From: "Benjamin Hauger" > Sent Time: 2019-03-28 01:31:40 (Thursday) > To: wuzhouhui , centos@centos.org > Cc: > Subject: Re: [CentOS] How to specify kernel version when restart kdump > > What do you mean? Wouldn't the kernel version always be the actual > running version of the kernel that was booted? > Suppose the running kernel is 2.6.32, and then I installed kernel 3.10.0. The files under /boot includes (exclude some unimportant files): initramfs-2.6.32.img initramfs-3.10.0.img vmlinuz-2.6.32 vmlinuz-3.10.0 initrd-2.6.32kdump.img We can see that there is no initrd-3.10.0kdump.img for newly installed kernel 3.10.0, and kdump will generate initrd-3.10.0kdump.img only when booted as kernel 3.10.0. However, I want kdump to generate initrd-3.10.0kdump.img now (the current running kernel is 2.6.32). > Ben > > On 3/26/19 6:16 PM, wuzhouhui wrote: > >> -Original Messages- > >> From: "Benjamin Hauger" > >> Sent Time: 2019-03-27 00:15:21 (Wednesday) > >> To: centos@centos.org > >> Cc: > >> Subject: Re: [CentOS] How to specify kernel version when restart kdump > >> > >> kdump operates by booting a fresh kernel to capture the context of a > >> crashed kernel, and so the only way for kdump to dump a kernel is to > >> crash it and cause kdump to invoke its post-crash kernel. > >> > >> You can manually force a running kernel to panic (and invoke a > >> correctly-configured kdump) with the following command sequence: > >> > >>> echo 1 > /proc/sys/kernel/sysrq > >>> echo c > /proc/sysrq-trigger > >> > >> Cheers, > >> Ben > > Hi, Ben > > > > I think your response doesn't answered my question. I'm not asking > > how to trigger kernel crash and see whether the kdump is works, but > > asking how to specifying kernel version when start kdump service. > > > > Thanks. > >> > >> > >> On 3/25/19 7:19 PM, wuzhouhui wrote: > >> CentOS@centos.org > >> https://lists.centos.org/mailman/listinfo/centos > > ___ > > CentOS mailing list > > CentOS@centos.org > > https://lists.centos.org/mailman/listinfo/centos > > > > -- > > Benjamin Hauger > SysAdmin/CSDC-DMO > Rm. 94 > x8371 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] How to specify kernel version when restart kdump
> -Original Messages- > From: "Gianluca Cecchi" > Sent Time: 2019-03-28 16:59:19 (Thursday) > [...] > The command line fo CentOS 6 clearly misses the kernel version to build > initrd file for, so the correct command should be: > > /sbin/mkdumprd -d -f > "/boot/initrd-2.6.32-642.13.1.el6.x86_64kdump.img" 2.6.32-642.13.1.el6.x86_64 > I test it and it works for me, although prints some harmless warnings. Thanks ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] udev rename NIC failed
Hi, Sometimes, I found one of my Mellanox NIC renamed to rename6, instead of eth1. The right names of NICs in my system should be: eth0Mellanox NIC eth1Mellanox NIC eth2Intel NIC eth3Intel NIC eth4Intel NIC eth5Intel NIC eth0 and eth1 will combined as bond1 with mode 4. However, the current names are: eth0Mellanox NIC rename6 Mellanox NIC eth1Intel NIC eth2Intel NIC eth4Intel NIC eth5Intel NIC And bond1 still consist of eth0 and eth1, but eth1 is Intel NIC, instead of Mellanox NIC. Following is selected log from /var/log/messages: ... kernel: [ 23.098148] i40e: Intel(R) 40-10 Gigabit Ethernet Connection Network Driver - version 2.2.4 kernel: [ 23.098554] i40e: Copyright(c) 2013 - 2017 Intel Corporation. kernel: [ 23.114270] i40e :1a:00.0: fw 3.1.57069 api 1.5 nvm 3.33 0x8f09 255.65535.255 kernel: [ 23.118320] i40e :1a:00.0: MAC address: 28:41:c6:fb:c3:a2 kernel: [ 23.128007] i40e :1a:00.0: MSI-X vector limit reached, attempting to redistribute vectors kernel: [ 23.133699] i40e :1a:00.0: Added LAN device PF0 bus=0x1a dev=0x00 func=0x00 kernel: [ 23.134414] i40e :1a:00.0: Features: PF-id[0] VFs: 32 VSIs: 34 QP: 56 RSS FD_ATR FD_SB NTUPLE CloudF DCB VxLAN NVGRE PTP VEPA kernel: [ 23.148085] i40e :1a:00.1: fw 3.1.57069 api 1.5 nvm 3.33 0x8f09 255.65535.255 kernel: [ 23.151729] i40e :1a:00.1: MAC address: 28:41:c6:fb:c3:a3 kernel: [ 23.160694] i40e :1a:00.1: MSI-X vector limit reached, attempting to redistribute vectors kernel: [ 23.166232] i40e :1a:00.1: Added LAN device PF1 bus=0x1a dev=0x00 func=0x01 kernel: [ 23.167280] i40e :1a:00.1: Features: PF-id[1] VFs: 32 VSIs: 34 QP: 56 RSS FD_ATR FD_SB NTUPLE CloudF DCB VxLAN NVGRE PTP VEPA kernel: [ 23.185771] i40e :1a:00.2: fw 3.1.57069 api 1.5 nvm 3.33 0x8f09 255.65535.255 kernel: [ 23.193232] i40e :1a:00.2: MAC address: 28:41:c6:fb:c3:a4 kernel: [ 23.207420] i40e :1a:00.2: MSI-X vector limit reached, attempting to redistribute vectors kernel: [ 23.217474] i40e :1a:00.2: Added LAN device PF2 bus=0x1a dev=0x00 func=0x02 kernel: [ 23.219339] i40e :1a:00.2: Features: PF-id[2] VFs: 32 VSIs: 34 QP: 56 RSS FD_ATR FD_SB NTUPLE CloudF DCB VxLAN NVGRE PTP VEPA kernel: [ 23.237958] i40e :1a:00.3: fw 3.1.57069 api 1.5 nvm 3.33 0x8f09 255.65535.255 kernel: [ 23.242039] i40e :1a:00.3: MAC address: 28:41:c6:fb:c3:a5 kernel: [ 23.258645] i40e :1a:00.3: MSI-X vector limit reached, attempting to redistribute vectors kernel: [ 23.270395] i40e :1a:00.3: Added LAN device PF3 bus=0x1a dev=0x00 func=0x03 kernel: [ 23.271911] i40e :1a:00.3: Features: PF-id[3] VFs: 32 VSIs: 34 QP: 56 RSS FD_ATR FD_SB NTUPLE CloudF DCB VxLAN NVGRE PTP ... kernel: [ 250.279739] Compat-mlnx-ofed backport release: f8de107 kernel: [ 250.280006] Backport based on mlnx_ofed/mlnx-ofa_kernel-4.0.git f8de107 kernel: [ 250.280261] compat.git: mlnx_ofed/mlnx-ofa_kernel-4.0.git kernel: [ 250.287865] mlx5_core :3b:00.0: firmware version: 14.23.1020 kernel: [ 250.293492] tun: Universal TUN/TAP device driver, 1.6 kernel: [ 250.293731] tun: (C) 1999-2004 Max Krasnyansky kernel: [ 250.360407] nbd: registered device at major 43 kernel: [ 250.367659] nf_conntrack version 0.5.0 (65536 buckets, 262144 max) kernel: [ 250.373103] VFIO - User Level meta-driver version: 0.3 kernel: [ 250.455352] EXT4-fs (sda2): re-mounted. Opts: (null) kernel: [ 250.489486] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null) kernel: [ 251.202430] (:3b:00.0): E-Switch: Total vports 9, per vport: max uc(1024) max mc(16384) kernel: [ 251.343924] mlx5_core :3b:00.1: firmware version: 14.23.1020 kernel: [ 252.273017] (:3b:00.1): E-Switch: Total vports 9, per vport: max uc(1024) max mc(16384) kernel: [ 252.411436] mlx5_core :3b:00.0: MLX5E: StrdRq(1) RqSz(8) StrdSz(64) RxCqeCmprss(0) kernel: [ 252.575886] mlx5_core :3b:00.1: MLX5E: StrdRq(1) RqSz(8) StrdSz(64) RxCqeCmprss(0) kernel: [ 252.814797] mlx5_ib: Mellanox Connect-IB Infiniband driver v4.2-1.2.0 kernel: [ 343.507623] Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011) kernel: [ 343.508800] bonding: bond1 is being created... kernel: [ 343.525710] bond1: Setting MII monitoring interval to 100 kernel: [ 343.526101] bond1: Setting xmit hash policy to layer2+3 (2) kernel: [ 343.528088] IPv6: ADDRCONF(NETDEV_UP): bond1: link is not ready kernel: [ 343.543330] bond1: Adding slave eth0 kernel: [ 343.834246] mlx5_core :3b:00.0 eth0: mlx5e_update_carrier:153: Link up kernel: [ 343.837195] bond1: Enslaving eth0 as a backup interf
[CentOS] rpmbuild how to know we are building kernel module package
Hi, When I build a mpt3sas rpm package, I found something interesting: 1. package name is prefixed with kmod- automatically 2. so many requirements are added automatically, most of them are kabi So my question is rpmbuild how to know he is building kernel module package? Based on which condition? Here is mpt3sas.spec: Name: mpt3sas Version:26.00.00.00 Release:1 Summary:RHEL Driver Update Program package Group: System/Kernel License:GPLv2 URL:http://www.lsilogic.com Distribution: LSI Corporation Source0:%{name}-%{version}.tar.bz2 Source1:%{name}.files Source2:%{name}.conf BuildRoot: %(mktemp -ud %{_tmppath}/%{name}-%{version}-%{release}-XX) BuildRequires: %kernel_module_package_buildreqs %global kernel_version `uname -r` %kernel_module_package -f %{SOURCE1} default %description LSI MPT Fusion HBA drivers (12gb SAS) %prep %setup set -- * mkdir source mv "$@" source/ mkdir obj %build for flavor in %flavors_to_build; do rm -rf obj/$flavor cp -r source obj/$flavor make -C %{kernel_source $flavor} M=$PWD/obj/$flavor done %install export INSTALL_MOD_PATH=$RPM_BUILD_ROOT export INSTALL_MOD_DIR=extra/%{name} for flavor in %flavors_to_build ; do make -C %{kernel_source $flavor} modules_install \ M=$PWD/obj/$flavor # Cleanup unnecessary kernel-generated module dependency files. find $INSTALL_MOD_PATH/lib/modules -iname 'modules.*' -exec rm {} \; done sed -e s/this_weakupdate/`uname -r | cut -f1 -d-`/ \ ../../SOURCES/mpt3sas.conf > \ ../../SOURCES/mpt3sas.a mv ../../SOURCES/mpt3sas.a ../../SOURCES/mpt3sas.conf install -m 644 -D %{SOURCE2} $RPM_BUILD_ROOT/etc/depmod.d/%{name}.conf install -m 644 -D %{SOURCE2} $RPM_BUILD_ROOT/etc/modules-load.d/%{name}.conf %clean rm -rf $RPM_BUILD_ROOT %changelog ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] rpmbuild how to know we are building kernel module package
> On Apr 12, 2019, at 11:12 PM, Gordon Messmer wrote: > > On 4/12/19 7:04 AM, wuzhouhui wrote: >> So my question is rpmbuild how to know he is building kernel module package? >> Based on which condition? > > > I believe the %kernel_module_package macro defined in > /usr/lib/rpm/redhat/macros is used to invoke /usr/lib/rpm/redhat/kmodtool, > which provides some overrides. I checked these macros and files, and I think you are right, although I haven't verify it. Thanks. > > ___ > CentOS mailing list > CentOS@centos.org > https://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] How to specify kernel version when restart kdump
> -Original Messages- > From: wuzhouhui > Sent Time: 2019-03-29 10:06:06 (Friday) > To: "centos mailing list" > Cc: > Subject: Re: [CentOS] How to specify kernel version when restart kdump > > > -Original Messages- > > From: "Gianluca Cecchi" > > Sent Time: 2019-03-28 16:59:19 (Thursday) > > [...] > > The command line fo CentOS 6 clearly misses the kernel version to build > > initrd file for, so the correct command should be: > > > > /sbin/mkdumprd -d -f > > "/boot/initrd-2.6.32-642.13.1.el6.x86_64kdump.img" > > 2.6.32-642.13.1.el6.x86_64 > > Unfortunately, I encountered a new issue when mkdumprd for a kernel different from running. The phenomenon is mkdumprd cannot break following loop in function depsolve_modlist(), in /sbin/mkdumprd: 348 while [ -n "$TMPINMODS" ] 349 do 350for i in $TMPINMODS 351do 352 mname=`basename $i | sed -e's/\.ko//'` [...] 407 TMPINMODS=$TMPTMPMODS 408done 409 done 410 MODULES=$TMPOUTMODS and $TMPINMODS is vhost_net.ko when issue occurs. The reason is mkdumprd set $TMPINMODS by lsmod in running kernel. But there is a new depends of vhost_net in newer kernel and $TMPINMODS doesn't include it, so mkdumprd stuck in previous while loop. Is there a solution exists? > I test it and it works for me, although prints some harmless warnings. > > Thanks > ___ > CentOS mailing list > CentOS@centos.org > https://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] Who is responsible to load NIC driver when boot up
Hi I have a small question about NIC driver (e.g. i40e) loading. Who is responsible to load i40e driver? And how does he knows we should load i40e, instead of ixgbe? Thanks. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Who is responsible to load NIC driver when boot up
> -Original Messages- > From: "Steven Tardy" > Sent Time: 2019-04-28 13:02:18 (Sunday) > To: "CentOS mailing list" > Cc: > Subject: Re: [CentOS] Who is responsible to load NIC driver when boot up > > On Sat, Apr 27, 2019 at 11:44 PM wuzhouhui > wrote: > > > I have a small question about NIC driver (e.g. i40e) loading. Who is > > responsible to load i40e driver? And how does he knows we should load > > i40e, instead of ixgbe? > > > `depmod` may put hardware/driver lists into initramfs when `mkinitrd` is > called when a new kernel is installed. > Also check file: /lib/modules/`uname-r`/modules.alias > The modules.alias contains PCI vendor/device IDs which can be found via > `lspci -n`. > > Also you can `modinfo i40e` and `modinfo ixgbe` to see a list of PCI > vendor/device IDs which each driver supports. > > Most of the time “it just works” be can be confusing tracking down exactly > why one driver loads instead of another. Thanks for you explanation. But who loads (modprobe) drivers, udev, kernel, or others? > > > > ___ > CentOS mailing list > CentOS@centos.org > https://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Who is responsible to load NIC driver when boot up
> -Original Messages- > From: "Stephen John Smoogen" > Sent Time: 2019-04-28 21:54:13 (Sunday) > To: "CentOS mailing list" > Cc: > Subject: Re: [CentOS] Who is responsible to load NIC driver when boot up > > On Sun, 28 Apr 2019 at 01:22, wuzhouhui > wrote: > > > > -Original Messages- > > > From: "Steven Tardy" > > > Sent Time: 2019-04-28 13:02:18 (Sunday) > > > To: "CentOS mailing list" > > > Cc: > > > Subject: Re: [CentOS] Who is responsible to load NIC driver when boot up > > > > > > On Sat, Apr 27, 2019 at 11:44 PM wuzhouhui > > > > > wrote: > > > > > > > I have a small question about NIC driver (e.g. i40e) loading. Who is > > > > responsible to load i40e driver? And how does he knows we should load > > > > i40e, instead of ixgbe? > > > > > > > > > `depmod` may put hardware/driver lists into initramfs when `mkinitrd` is > > > called when a new kernel is installed. > > > Also check file: /lib/modules/`uname-r`/modules.alias > > > The modules.alias contains PCI vendor/device IDs which can be found via > > > `lspci -n`. > > > > > > Also you can `modinfo i40e` and `modinfo ixgbe` to see a list of PCI > > > vendor/device IDs which each driver supports. > > > > > > Most of the time “it just works” be can be confusing tracking down > > exactly > > > why one driver loads instead of another. > > > > Thanks for you explanation. But who loads (modprobe) drivers, udev, kernel, > > or others? > > > > > During the initial boot on EL7, the initial ramdisk which uses dracut to > set up that. After the initial boot, I believe udev is what is doing the > work. There are a ton of pretty good manual pages for all the different I think you are right. I add a dump_stack() and printk() in virtio_net driver, and following infos printed when boot up: kernel: Pid: 737, comm: modprobe Not tainted 2.6.32-279.22.1.el6.local.x86_64 #1 kernel: Call Trace: kernel: [] ? __blocking_notifier_call_chain+0x65/0x80 kernel: [] ? init+0x9/0x3c [virtio_net] kernel: [] ? do_one_initcall+0x3c/0x1d0 kernel: [] ? sys_init_module+0xe1/0x250 kernel: [] ? system_call_fastpath+0x16/0x1b kernel: parent: udevd > parts of dracut which explain how it is loading things, what order and how > to add/remove things. > > -- > Stephen J Smoogen. > ___ > CentOS mailing list > CentOS@centos.org > https://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] What happened if install a el7 package on a el6 system
Hi, Recently, I encountered a interesting phenomenon that CentOS 6.3 running as normal even if I (my colleague, actually) installed a kernel that build for CentOS 7.x (e.g. kernel-3.10.0-327.el7.x86_64.rpm). I found kernel is mismatch accidentally when I using "uname -r" to check kernel version. So my question is what the harmness we will get if I install a el7 rpm into a el6 system? Thanks. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] What happened if install a el7 package on a el6 system
Reproduce steps: 1. Prepare a CentOS 6.3 system on a VM (make sure grubby-7.0.15-3.el6.x86_64 has been installed) 2. Download kernel-3.10.0-327.el7.x86_64.rpm from http://vault.centos.org/ 3. 3.1 Create a symlink with "ln -s /sbin/new-kernel-pkg /usr/sbin/new-kernel-pkg" 3.2 Install kernel-3.10.0-327.el7.x86_64.rpm with "rpm -i --force --nodeps" 4. Reboot Then we'll see the system boot and running as normal. And /etc/grub.conf updated automatically. > -Original Messages- > From: wuzhouhui > Sent Time: 2019-05-07 16:05:54 (Tuesday) > To: centos@centos.org > Cc: > Subject: [CentOS] What happened if install a el7 package on a el6 system > > Hi, > > Recently, I encountered a interesting phenomenon that CentOS 6.3 > running as normal even if I (my colleague, actually) installed a > kernel that build for CentOS 7.x (e.g. kernel-3.10.0-327.el7.x86_64.rpm). > > I found kernel is mismatch accidentally when I using "uname -r" to > check kernel version. So my question is what the harmness we will > get if I install a el7 rpm into a el6 system? > > Thanks. > ___ > CentOS mailing list > CentOS@centos.org > https://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos