[CentOS] Null deference panic in CentOS-6.5

2017-10-18 Thread wuzhouhui 


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 =

Re: [CentOS] Null deference panic in CentOS-6.5

2017-10-18 Thread wuzhouhui 
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

2017-10-18 Thread wuzhouhui 
Fine, it seems that upgrade kernel is the only effective solution.

> On 18 Oct 2017, at 10:00 PM, Stephen John Smoogen <smo...@gmail.com> wrote:
> 
> On 18 October 2017 at 04:50, wuzhouhui <wuzhouhu...@mails.ucas.ac.cn> 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

Re: [CentOS] soft lockup after set multicast_router of bridge and it's port to 2

2018-01-10 Thread wuzhouhui 

Never mind, commit 1a040eaca1a2 (bridge: fix multicast router rlist endless 
loop)
fixes it.

> -原始邮件-
> 发件人: wuzhouhui <wuzhouhu...@mails.ucas.ac.cn>
> 发送时间: 2018-01-10 15:19:09 (星期三)
> 收件人: centos@centos.org
> 抄送: wuzhouhui14 <wuzhouhu...@mails.ucas.ac.cn>
> 主题: 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] soft lockup after set multicast_router of bridge and it's port to 2

2018-01-09 Thread wuzhouhui 
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] Adjust type of rw in submit_bio from int to unsigned long

2018-02-08 Thread wuzhouhui 
Forward mail to centos-devel mailing list for getting more attentions!

Sorry for disturbing.

> -Original Messages-
> From: wuzhouhui <wuzhouhu...@mails.ucas.ac.cn>
> Sent Time: 2018-02-07 13:44:07 (Wednesday)
> To: centos@centos.org
> Cc: wuzhouhui14 <wuzhouhu...@mails.ucas.ac.cn>
> 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] Adjust type of rw in submit_bio from int to unsigned long

2018-02-06 Thread wuzhouhui 
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

2018-02-23 Thread wuzhouhui 
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

2018-02-24 Thread wuzhouhui 

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

2018-02-25 Thread wuzhouhui 
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

2018-02-25 Thread wuzhouhui 
> -Original Messages-
> From: "Steven Tardy" <sjt5a...@gmail.com>
> Sent Time: 2018-02-26 10:48:48 (Monday)
> To: "CentOS mailing list" <centos@centos.org>
> Cc: 
> Subject: Re: [CentOS] How to update modules in iniramfs fastly
> 
> On Sun, Feb 25, 2018 at 8:29 PM wuzhouhui <wuzhouhu...@mails.ucas.ac.cn>
> 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

2018-02-26 Thread wuzhouhui 
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" <rpj...@crashcourse.ca>
> Sent Time: 2018-02-26 14:05:24 (Monday)
> To: "CentOS mailing list" <centos@centos.org>
> Cc: 
> Subject: Re: [CentOS] How to update modules in iniramfs fastly
> 
> On Mon, 26 Feb 2018, wuzhouhui wrote:
> 
> > > -Original Messages-
> > > From: "Steven Tardy" <sjt5a...@gmail.com>
> > > Sent Time: 2018-02-26 10:48:48 (Monday)
> > > To: "CentOS mailing list" <centos@centos.org>
> > > Cc:
> > > Subject: Re: [CentOS] How to update modules in iniramfs fastly
> > >
> > > On Sun, Feb 25, 2018 at 8:29 PM wuzhouhui <wuzhouhu...@mails.ucas.ac.cn>
> > > 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

[CentOS] Can't see register value in crash vmcore

2017-12-27 Thread wuzhouhui 
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] CentOS 7.4 paniced when running LTP tests

2018-04-17 Thread wuzhouhui 
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

Re: [CentOS] How to update modules in iniramfs fastly

2018-02-26 Thread wuzhouhui 
> -Original Messages-
> From: "Leon Fauster" <leonfaus...@googlemail.com>
> Sent Time: 2018-02-26 22:20:51 (Monday)
> To: "CentOS mailing list" <centos@centos.org>
> Cc: 
> Subject: Re: [CentOS] How to update modules in iniramfs fastly
> 
> 
> > Am 26.02.2018 um 06:46 schrieb wuzhouhui <wuzhouhu...@mails.ucas.ac.cn>:
> > 
> >> -Original Messages-
> >> From: "Steven Tardy" <sjt5a...@gmail.com>
> >> Sent Time: 2018-02-26 10:48:48 (Monday)
> >> To: "CentOS mailing list" <centos@centos.org>
> >> Cc: 
> >> Subject: Re: [CentOS] How to update modules in iniramfs fastly
> >> 
> >> On Sun, Feb 25, 2018 at 8:29 PM wuzhouhui <wuzhouhu...@mails.ucas.ac.cn>
> >> 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] Fw: Re: [SPDK] VM boot failed sometimes if using vhost-user-blk with spdk

2018-10-30 Thread wuzhouhui 
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

2018-11-10 Thread wuzhouhui 
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!

2018-11-12 Thread wuzhouhui 
...
[  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

2018-11-15 Thread wuzhouhui 
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

2019-01-27 Thread wuzhouhui 
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] How to specify kernel version when restart kdump

2019-03-25 Thread wuzhouhui 
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

[CentOS] do not uninstall old when yum install new

2019-03-25 Thread wuzhouhui 
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

Re: [CentOS] How to specify kernel version when restart kdump

2019-03-28 Thread wuzhouhui 
> -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

Re: [CentOS] How to specify kernel version when restart kdump

2019-03-27 Thread wuzhouhui 
> -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

[CentOS] udev rename NIC failed

2019-04-01 Thread wuzhouhui 
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

Re: [CentOS] How to specify kernel version when restart kdump

2019-03-26 Thread wuzhouhui 
> -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

2019-04-15 Thread wuzhouhui 
> -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] rpmbuild how to know we are building kernel module package

2019-04-12 Thread wuzhouhui 
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

2019-04-12 Thread wuzhouhui 


> 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

[CentOS] What happened if install a el7 package on a el6 system

2019-05-07 Thread wuzhouhui 
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

2019-05-07 Thread wuzhouhui 
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

Re: [CentOS] Who is responsible to load NIC driver when boot up

2019-04-27 Thread wuzhouhui 
> -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

[CentOS] Who is responsible to load NIC driver when boot up

2019-04-27 Thread wuzhouhui 
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

2019-04-28 Thread wuzhouhui 
> -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