最近又遇到一次hung,dmesg中堆栈如下:

[176223.913270] ------------[ cut here ]------------
[176223.913280] WARNING: CPU: PID: at net/sched/sch_generic.c: dev_watchdog+0x248/0x260-----注意cpu号是10
[176223.913282] NETDEV WATCHDOG: eth4 (ixgbe): transmit queue timed out----------------warn的内容
[176223.913283] Modules linked in: witdriver(OE) mysendmsg(OE) fuse tipc(OE) ossmod(OE) iptable_filter mptctl mptbase bonding dm_mirror dm_region_hash dm_log dm_mod iTCO_wdt iTCO_vendor_support skx_edac edac_core intel_powerclamp coretemp intel_rapl iosf_mbi kvm_intel kvm irqbypass crc32_pclmul ghash_clmulni_intel aesni_intel lrw gf128mul glue_helper ablk_helper cryptd pcspkr joydev ses enclosure sg mei_me mei shpchp lpc_ich i2c_i801 wmi ipmi_si ipmi_devintf ipmi_msghandler nfit libnvdimm acpi_power_meter acpi_cpufreq acpi_pad tcp_bbr sch_fq binfmt_misc ip_tables ext4 mbcache jbd2 raid1 sd_mod crc_t10dif crct10dif_generic ast i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm crct10dif_pclmul crct10dif_common crc32c_intel ahci libahci libata ixgbe(OE) i40e(OE) mpt3sas(OE)
[176223.913340] ptp raid_class pps_core scsi_transport_sas i2c_core dca [last unloaded: witdriver]
[176223.913347] CPU: PID: Comm: swapper/ Tainted: G OE ------------ 3.10.-693.21..el7.x86_64 #
[176223.913348] Hardware name: ZTE ZXCDN/SC621DI-16F, BIOS .0b //
[176223.913350] Call Trace:
[176223.913351] <IRQ> [<ffffffff816b2f9e>] dump_stack+0x19/0x1b
[176223.913361] [<ffffffff8108ae58>] __warn+0xd8/0x100----------------------warn了,内容见第二行
[176223.913364] [<ffffffff8108aedf>] warn_slowpath_fmt+0x5f/0x80
[176223.913369] [<ffffffff815bcc28>] dev_watchdog+0x248/0x260----------------在处理到dev_watchdog时候出现问题
[176223.913372] [<ffffffff815bc9e0>] ? dev_deactivate_queue.constprop.+0x60/0x60
[176223.913375] [<ffffffff8109a9c8>] call_timer_fn+0x38/0x110----------------处理回调
[176223.913378] [<ffffffff815bc9e0>] ? dev_deactivate_queue.constprop.+0x60/0x60
[176223.913382] [<ffffffff8109ceed>] run_timer_softirq+0x22d/0x310-----------这个软中断是timer
[176223.913386] [<ffffffff8109404d>] __do_softirq+0xfd/0x290
[176223.913390] [<ffffffff816c8afc>] call_softirq+0x1c/0x30
[176223.913394] [<ffffffff8102d435>] do_softirq+0x65/0xa0---------------------硬中断处理后,顺便处理软中断
[176223.913397] [<ffffffff81094495>] irq_exit+0x175/0x180---------------------硬中断结束
[176223.913400] [<ffffffff816c9e88>] smp_apic_timer_interrupt+0x48/0x60
[176223.913402] [<ffffffff816c6732>] apic_timer_interrupt+0x162/0x170---------硬中断开始
[176223.913403] <EOI> [<ffffffff81534357>] ? cpuidle_enter_state+0x57/0xd0
[176223.913410] [<ffffffff815344ae>] cpuidle_idle_call+0xde/0x230
[176223.913414] [<ffffffff81034f8e>] arch_cpu_idle+0xe/0x40
[176223.913420] [<ffffffff810edc4a>] cpu_startup_entry+0x14a/0x1c0
[176223.913423] [<ffffffff81052222>] start_secondary+0x1f2/0x270
[176223.913425] ---[ end trace 30e7271cf4a53655 ]---
[176223.913430] ixgbe ::00.0 eth4: Fake Tx hang detected with timeout of seconds
[176224.918915] ixgbe ::00.1 eth5: Fake Tx hang detected with timeout of seconds
[176224.918917] ixgbe :af:00.1 eth7: Fake Tx hang detected with timeout of seconds
[176224.918948] ixgbe :af:00.0 eth6: Fake Tx hang detected with timeout of seconds
[176224.934872] ixgbe ::00.1 eth1: Fake Tx hang detected with timeout of seconds
[176226.403293] hrtimer_gaq_time = , soft_irq_time = , cpu =
[176233.921764] ixgbe ::00.0 eth4: Fake Tx hang detected with timeout of seconds
[176234.911438] ixgbe :af:00.1 eth7: Fake Tx hang detected with timeout of seconds
[176234.911441] ixgbe ::00.1 eth5: Fake Tx hang detected with timeout of seconds
[176234.911474] ixgbe :af:00.0 eth6: Fake Tx hang detected with timeout of seconds
[176234.943364] ixgbe ::00.1 eth1: Fake Tx hang detected with timeout of seconds
[176237.664127] hrtimer_gaq_time = , soft_irq_time = , cpu =

如果只盯着这个堆栈看,可以看出,网卡的 dev_watchdog 函数检测到了eth4的queue 5 出现了 trans_timeout。

超时的检测周期,不同的设备是不一样的,intel的ixgbe对应的超时时间是 ixgbe_main.c 中设置的

netdev->watchdog_timeo =  * HZ;

检测的原理就是,每当发包成功的时候,设置 txq->trans_start ,如果这个值在timer到期检测的时候,和当前时间相差 一个超时周期(默认是5s,各种驱动可能不同),则认为出现发送

超时。依赖于定时器软中断,检测的对象是处于running状态的网卡已经处于stop状态的发送队列,话说网卡如果没有running,检测也没有意义。

static inline netdev_tx_t netdev_start_xmit(struct sk_buff *skb, struct net_device *dev,
struct netdev_queue *txq, bool more)
{
const struct net_device_ops *ops = dev->netdev_ops;
int rc;
/*__netdev_start_xmit 里面就完全是使用driver 的ops去发包了,其实到此为止,一个skb已经从netdevice层送到driver层了,接下来会等待driver的返回*/
rc = __netdev_start_xmit(ops, skb, dev, more);
if (rc == NETDEV_TX_OK)
txq_trans_update(txq); return rc;
}
static inline void txq_trans_update(struct netdev_queue *txq)
{
if (txq->xmit_lock_owner != -)
txq->trans_start = jiffies;---------------------更新当前发送队列txq的最后发送时间
}

ixgbe驱动会检测是否pending,也就是有的tx中的ring没变动了,那么打印warning。

接下来,又有一个堆栈:

[176242.505583] NMI watchdog: BUG: soft lockup - CPU# stuck for 22s! [kthread_send/:]-----------注意这个时候是cpu9
[176242.506532] Modules linked in: witdriver(OE) mysendmsg(OE) fuse tipc(OE) ossmod(OE) iptable_filter mptctl mptbase bonding dm_mirror dm_region_hash dm_log dm_mod iTCO_wdt iTCO_vendor_support skx_edac edac_core intel_powerclamp coretemp intel_rapl iosf_mbi kvm_intel kvm irqbypass crc32_pclmul ghash_clmulni_intel aesni_intel lrw gf128mul glue_helper ablk_helper cryptd pcspkr joydev ses enclosure sg mei_me mei shpchp lpc_ich i2c_i801 wmi ipmi_si ipmi_devintf ipmi_msghandler nfit libnvdimm acpi_power_meter acpi_cpufreq acpi_pad tcp_bbr sch_fq binfmt_misc ip_tables ext4 mbcache jbd2 raid1 sd_mod crc_t10dif crct10dif_generic ast i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm crct10dif_pclmul crct10dif_common crc32c_intel ahci libahci libata ixgbe(OE) i40e(OE) mpt3sas(OE)
[176242.506588] ptp raid_class pps_core scsi_transport_sas i2c_core dca [last unloaded: witdriver]
[176242.506597] CPU: PID: Comm: kthread_send/ Tainted: G W OE ------------ 3.10.-693.21..el7.x86_64 #
[176242.506599] Hardware name: ZTE ZXCDN/SC621DI-16F, BIOS .0b //
[176242.506601] task: ffff88290f7ddee0 ti: ffff882b680d0000 task.ti: ffff882b680d0000
[176242.506603] RIP: :[<ffffffff811005ce>] [<ffffffff811005ce>] native_queued_spin_lock_slowpath+0x1ce/0x200
[176242.506610] RSP: :ffff882fbe843dc0 EFLAGS:
[176242.506611] RAX: RBX: ffff882fbe843d50 RCX:
[176242.506613] RDX: RSI: RDI: ffff882fb80a0bc0-------大家都在抢的锁
[176242.506614] RBP: ffff882fbe843dc0 R08: R09: ffff8801363f4000
[176242.506616] R10: R11: ffff882fbe843da8 R12: ffff882fbe843d38
[176242.506617] R13: ffffffff816c6732 R14: ffff882fbe843dc0 R15: ffff882fb80a0b40
[176242.506619] FS: () GS:ffff882fbe840000() knlGS:
[176242.506621] CS: DS: ES: CR0:
[176242.506622] CR2: 00007fd86fd46316 CR3: 0000000001a0a000 CR4: 00000000003607e0
[176242.506624] DR0: DR1: DR2:
[176242.506626] DR3: DR6: 00000000fffe0ff0 DR7:
[176242.506627] Call Trace:
[176242.506629] <IRQ>
[176242.506630]
[176242.506635] [<ffffffff816adeee>] queued_spin_lock_slowpath+0xb/0xf
[176242.506640] [<ffffffff816bb080>] _raw_spin_lock+0x20/0x30
[176242.506645] [<ffffffff815bca52>] dev_watchdog+0x72/0x260-----------------------同上分析,不过这次是拿不到锁
[176242.506649] [<ffffffff815bc9e0>] ? dev_deactivate_queue.constprop.+0x60/0x60
[176242.506653] [<ffffffff8109a9c8>] call_timer_fn+0x38/0x110
[176242.506655] [<ffffffff815bc9e0>] ? dev_deactivate_queue.constprop.+0x60/0x60
[176242.506658] [<ffffffff8109ceed>] run_timer_softirq+0x22d/0x310
[176242.506663] [<ffffffff8109404d>] __do_softirq+0xfd/0x290
[176242.506667] [<ffffffff816c8afc>] call_softirq+0x1c/0x30
[176242.506672] [<ffffffff8102d435>] do_softirq+0x65/0xa0
[176242.506675] [<ffffffff81094495>] irq_exit+0x175/0x180
[176242.506679] [<ffffffff816c9e88>] smp_apic_timer_interrupt+0x48/0x60
[176242.506682] [<ffffffff816c6732>] apic_timer_interrupt+0x162/0x170----------------被硬中断打断
[176242.506684] <EOI>

[176242.506702] [<ffffffffc01299e3>] ? ixgbe_xmit_frame_ring+0x53/0xf30 [ixgbe]
[176242.506710] [<ffffffffc012a918>] ixgbe_xmit_frame+0x58/0xd0 [ixgbe]
[176242.506715] [<ffffffffc043b63c>] wit_send_tasklet+0x73c/0xae0 [witdriver]
[176242.506719] [<ffffffffc043ba95>] wit_kthread_xmit_fn+0xb5/0x150 [witdriver]----------我们的内核线程kthread_send调用的发包函数
[176242.506723] [<ffffffffc043b9e0>] ? wit_send_tasklet+0xae0/0xae0 [witdriver]
[176242.506726] [<ffffffff810b5241>] kthread+0xd1/0xe0
[176242.506729] [<ffffffff810b5170>] ? insert_kthread_work+0x40/0x40
[176242.506733] [<ffffffff816c5577>] ret_from_fork+0x77/0xb0
[176242.506736] [<ffffffff810b5170>] ? insert_kthread_work+0x40/0x40

分析这个堆栈,dev_watchdog 这次拿不到锁了,已经持续了22s,走查代码,它需要哪一把锁呢?

etif_tx_lock(dev);
static inline void netif_tx_lock(struct net_device *dev)
{
unsigned int i;
int cpu; spin_lock(&dev->tx_global_lock);
cpu = smp_processor_id();
for (i = ; i < dev->num_tx_queues; i++) {
struct netdev_queue *txq = netdev_get_tx_queue(dev, i); /* We are the only thread of execution doing a
* freeze, but we have to grab the _xmit_lock in
* order to synchronize with threads which are in
* the ->hard_start_xmit() handler and already
* checked the frozen bit.
*/
__netif_tx_lock(txq, cpu);
set_bit(__QUEUE_STATE_FROZEN, &txq->state);
__netif_tx_unlock(txq);
}
}

那这把锁被谁拿了呢?被 wit_kthread_xmit_fn 函数拿了,因为我们正在发包啊。

也就是说,我们的内核线程发包的时候,拿了锁,结果被中断,然后硬中断处理dev_watchdog的时候,也要拿这把锁,死锁了。

接下来,又引发其他cpu死锁:(每次进入_raw_spin_lock,rdi中必然存放的就是锁,x86反汇编看的话确实是rdi,其他架构不是如此)

[176246.611936] NMI watchdog: BUG: soft lockup - CPU# stuck for 22s! [a.out:]-------------------------------cpu25
[176246.612901] Modules linked in: witdriver(OE) mysendmsg(OE) fuse tipc(OE) ossmod(OE) iptable_filter mptctl mptbase bonding dm_mirror dm_region_hash dm_log dm_mod iTCO_wdt iTCO_vendor_support skx_edac edac_core intel_powerclamp coretemp intel_rapl iosf_mbi kvm_intel kvm irqbypass crc32_pclmul ghash_clmulni_intel aesni_intel lrw gf128mul glue_helper ablk_helper cryptd pcspkr joydev ses enclosure sg mei_me mei shpchp lpc_ich i2c_i801 wmi ipmi_si ipmi_devintf ipmi_msghandler nfit libnvdimm acpi_power_meter acpi_cpufreq acpi_pad tcp_bbr sch_fq binfmt_misc ip_tables ext4 mbcache jbd2 raid1 sd_mod crc_t10dif crct10dif_generic ast i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm crct10dif_pclmul crct10dif_common crc32c_intel ahci libahci libata ixgbe(OE) i40e(OE) mpt3sas(OE)
[176246.612961] ptp raid_class pps_core scsi_transport_sas i2c_core dca [last unloaded: witdriver]
[176246.612969] CPU: PID: Comm: a.out Tainted: G W OEL ------------ 3.10.-693.21..el7.x86_64 #
[176246.612970] Hardware name: ZTE ZXCDN/SC621DI-16F, BIOS .0b //
[176246.612973] task: ffff882ba14a0000 ti: ffff882ba92c8000 task.ti: ffff882ba92c8000
[176246.612974] RIP: :[<ffffffff81100556>] [<ffffffff81100556>] native_queued_spin_lock_slowpath+0x156/0x200
[176246.612982] RSP: :ffff882ba92cb978 EFLAGS:
[176246.612983] RAX: RBX: 0000090190134ba9 RCX: 0000000000c90000
[176246.612985] RDX: 0000000000c90101 RSI: RDI: ffff882fb80a0bc0------------大家都在抢的香饽饽存放在此,就是这把锁
[176246.612986] RBP: ffff882ba92cb978 R08: ffff882fbe959700 R09:
[176246.612988] R10: R11: ffffea017c3e5580 R12: ffff882c18a85c00
[176246.612989] R13: 00000000000005dc R14: ffff882ba2091100 R15: ffffffff811e63d1
[176246.612991] FS: 00007fbf25f9b700() GS:ffff882fbe940000() knlGS:
[176246.612993] CS: DS: ES: CR0:
[176246.612995] CR2: 0000000000c79000 CR3: 000000593a2ec000 CR4: 00000000003607e0
[176246.612996] DR0: DR1: DR2:
[176246.612998] DR3: DR6: 00000000fffe0ff0 DR7:
[176246.612999] Call Trace:
[176246.613006] [<ffffffff816adeee>] queued_spin_lock_slowpath+0xb/0xf
[176246.613011] [<ffffffff816bb080>] _raw_spin_lock+0x20/0x30
[176246.613015] [<ffffffff815bcd7f>] sch_direct_xmit+0x13f/0x240------------qdisc中sys调用发包
[176246.613017] [<ffffffff815bcf15>] __qdisc_run+0x95/0x1c0
[176246.613022] [<ffffffff81596989>] __dev_queue_xmit+0x2c9/0x550-----------这个是实际物理网卡的
[176246.613025] [<ffffffff81596c20>] dev_queue_xmit+0x10/0x20
[176246.613032] [<ffffffffc03abbe2>] bond_dev_queue_xmit+0x32/0x80 [bonding]
[176246.613036] [<ffffffffc03ad7be>] bond_start_xmit+0x1be/0x420 [bonding]
[176246.613039] [<ffffffff81593bc0>] dev_hard_start_xmit+0x90/0x1a0
[176246.613041] [<ffffffff81596b08>] __dev_queue_xmit+0x448/0x550-----------这个是bond的
[176246.613044] [<ffffffff81596c20>] dev_queue_xmit+0x10/0x20
[176246.613048] [<ffffffff815dd8f6>] ip_finish_output+0x546/0x7a0
[176246.613050] [<ffffffff815dde53>] ip_output+0x73/0xe0
[176246.613053] [<ffffffff815dba46>] ? __ip_local_out_sk+0xf6/0x100
[176246.613055] [<ffffffff815dba87>] ip_local_out_sk+0x37/0x40
[176246.613058] [<ffffffff815de8a6>] ip_send_skb+0x16/0x50
[176246.613062] [<ffffffff81606a9c>] udp_send_skb+0xac/0x2b0
[176246.613065] [<ffffffff81606cde>] udp_push_pending_frames+0x3e/0x60
[176246.613068] [<ffffffff81608b19>] udp_sendpage+0x119/0x1c0
[176246.613071] [<ffffffff81615490>] inet_sendpage+0x70/0xe0
[176246.613075] [<ffffffff8157613e>] kernel_sendpage+0x1e/0x30
[176246.613079] [<ffffffffc04363a8>] sendfile_slowpath_2+0x1a8/0x1f0 [witdriver]
[176246.613084] [<ffffffffc04458a6>] sys_mycall+0x776/0x8f0 [witdriver]
[176246.613090] [<ffffffff816c5715>] system_call_fastpath+0x1c/0x21
[176246.613091] Code: 8b 4d c9 0f 8b 0f b7 c2 c0 f8 eb 1a 2e 0f 1f c0 0c f3 <8b> 0f b7 c2 f8 f0 be eb 0f 1f

由于我们拿的是dev的锁,在没开启抢占的情况下不调度出去,但也并没有关中断,这样其他cpu在系统调用中要发包,也会去尝试拿这把锁,好吧,你也死锁了,等着吧。

可以想象,后续其他cpu要拿这把锁的话,大家都会挂,一个cpu的softlock导致其他cpu全挂,只要你这个cpu来拿那锁就会如此。

由于我们拿的是spin_lock,并没有关中断,所以它还可以响应中断,看如下堆栈就明白,最早打印网卡异常的9号cpu,堆栈在死的时候是如下这样的:

crash> bt
PID: TASK: ffff88290f7ddee0 CPU: COMMAND: "kthread_send/9"
# [ffff882fbe843a70] machine_kexec at ffffffff8105d77b
# [ffff882fbe843ad0] __crash_kexec at ffffffff8110aca2
# [ffff882fbe843ba0] panic at ffffffff816ad52f
# [ffff882fbe843c20] watchdog_timer_fn at ffffffff81135a51----------------------------hardlock检测中hrtimer的回调
# [ffff882fbe843c58] __hrtimer_run_queues at ffffffff810b93a6
# [ffff882fbe843cb0] hrtimer_interrupt at ffffffff810b993f
# [ffff882fbe843cf8] local_apic_timer_interrupt at ffffffff8105467b
# [ffff882fbe843d10] smp_apic_timer_interrupt at ffffffff816c9e83
# [ffff882fbe843d28] apic_timer_interrupt at ffffffff816c6732--------------------------死之前又增加的堆栈,这个是硬中断
# [ffff882fbe843dc8] queued_spin_lock_slowpath at ffffffff816adeee---------------------一开始打印hung的堆栈,在自旋
# [ffff882fbe843dd8] _raw_spin_lock at ffffffff816bb080
# [ffff882fbe843de8] dev_watchdog at ffffffff815bca52
# [ffff882fbe843e28] call_timer_fn at ffffffff8109a9c8
# [ffff882fbe843e60] run_timer_softirq at ffffffff8109ceed
# [ffff882fbe843ed8] __do_softirq at ffffffff8109404d
# [ffff882fbe843f48] call_softirq at ffffffff816c8afc
# [ffff882fbe843f60] do_softirq at ffffffff8102d435
# [ffff882fbe843f80] irq_exit at ffffffff81094495
# [ffff882fbe843f98] smp_apic_timer_interrupt at ffffffff816c9e88
# [ffff882fbe843fb0] apic_timer_interrupt at ffffffff816c6732
--- <IRQ stack> ---
# [ffff882b680d3c28] apic_timer_interrupt at ffffffff816c6732
[exception RIP: ixgbe_xmit_frame_ring+]
RIP: ffffffffc01299e3 RSP: ffff882b680d3cd0 RFLAGS:
RAX: RBX: RCX: 000000000000403d
RDX: ffff882fb9331c00 RSI: ffff8828d7b8fac0 RDI:
RBP: ffff882b680d3d48 R8: R9: 0000a0a5447b9d78
R10: ffff8828c6e84f00 R11: 000000002b3000b8 R12: ffff8828c0291b00
R13: R14: R15: ffff882b680d3cc0
ORIG_RAX: ffffffffffffff10 CS: SS:
# [ffff882b680d3d50] ixgbe_xmit_frame at ffffffffc012a918 [ixgbe]
# [ffff882b680d3d80] wit_send_tasklet at ffffffffc043b63c [witdriver]
# [ffff882b680d3e78] wit_kthread_xmit_fn at ffffffffc043ba95 [witdriver]
# [ffff882b680d3ec8] kthread at ffffffff810b5241
# [ffff882b680d3f50] ret_from_fork at ffffffff816c5577

总结:

1、解决办法很简单,就是在 wit_kthread_xmit_fn 函数中,加了一个关闭软中断就行,因为就是软中断和sys拿锁冲突。

2、分析软锁,最好从dmesg中开始分析,那个时候时间还早,会按时间顺序来打印堆栈,比起直接crash来分析要快一些,特别是在对自己模块代码比较熟悉的情况下。

linux 3.10 的又一次hung的更多相关文章

  1. linux 学习10 shell 基础

    10.1 Shell概述 .Shell是什么 Shell是一个命令行解释器,它为用户提供了一个向Linux内核发送请求以便运行程序的界面系统级程序,用户可以用Shell来启动.挂起.停止甚至是编写一 ...

  2. Linux系统性能10条命令监控

    Linux系统性能10条命令监控 概述 通过执行以下命令,可以在1分钟内对系统资源使用情况有个大致的了解. uptime dmesg | tail vmstat 1 mpstat -P ALL 1 p ...

  3. 使用john破解ubuntu(linux)9.10密码

    Title:使用john破解ubuntu(linux)9.10密码 --2011-11-23 15:00 ubuntu 9.10的账户密码加密方式改用sha512了,默认的john是破不了的,还好官方 ...

  4. Linux系统管理10——进程和计划任务管理

    Linux系统管理10——进程和计划任务管理 一.程序和进程的关系 1.程序 ·保存在硬盘.光盘等介质中的可执行代码和数据 ·静态保存的代码 2.进程 ·在CPU及内存中运行的程序代码 ·动态执行的代 ...

  5. Linux系统启动那些事—基于Linux 3.10内核【转】

    转自:https://blog.csdn.net/shichaog/article/details/40218763 Linux系统启动那些事—基于Linux 3.10内核 csdn 我的空间的下载地 ...

  6. Linux 4.10.8 根文件系统制作(一)---环境搭建

    一.工具 制作工具为busybox 下载地址:https://busybox.net/ 解压: 二.制作文件系统 进入目录,执行make menuconfig: 2.1 busybox setting ...

  7. 交叉编译和安装ARM板(RK3288)和Linux 3.10上的RTL8188无线网卡驱动

    插入无线网卡,输入ifconfig,发现没有检测到网卡. 输入lsusb,查看无线网卡型号. 我用的无线网卡是EDUP的网卡,包装盒里有一张驱动光盘,把光盘里linux下的驱动目录复制下来.如果没有驱 ...

  8. Linux 4.10中两个新特性与我的一段故事

    今早5点半起来没有開始写文章,而是去西湾红树林连跑带走折腾了将近20公里.回来后就8点多了...洗了个澡之后坐稳当.開始写一段关于我的故事.        在2014年到2015年期间,我在负责研发一 ...

  9. [转] Linux 3.10 ARM Device Tree 的初始化

    [转] Linux 3.10 ARM Device Tree 的初始化 本文代码均来自标准 linux kernel 3.10,可以到这里下载 https://www.kernel.org/     ...

随机推荐

  1. Centos7下的systemctl命令与service和chkconfig

    博主使用的操作系统是最新的CentOS 7,所以可能和网上一些老的博文有一定出入,那是因为版本更新的原因. 这里写图片描述1 service service命令用于对系统服务进行管理,比如启动(sta ...

  2. MySQL主从数据库的安装

    安装环境 操作系统 :CentOS 6.5 数据库版本:MySQL 5.6.27 主机A:192.168.1.1 (Master) 主机B:192.168.1.2 (Slave) 1 2 3 4 这里 ...

  3. 关于 MySQL LEFT JOIN 不可不知的事

    你认为自己已对 MySQL 的 LEFT JOIN 理解深刻,这篇文章,我想让你能多学会点东西! ON 子句与 WHERE 子句的不同 一种更好地理解带有 WHERE ... IS NULL 子句的复 ...

  4. Type Cannot change version of project facet Dynamic Web Module to 2.5 报错

    项目下的.setings文件 夹中的 version 改为2.5

  5. ​游戏设计思考:对COK的理解和思考

    转自:http://www.gameres.com/804983.html 一.前言 发此文的起因是最近加入了一个游戏研究群,受到大家对游戏研究热情的感染,也想将自己对游戏的理解和感悟发出来和大家一起 ...

  6. Postgres 主从复制搭建步骤

    系统版本: CentOS Linux release 7.5.1804 (Core) 数据库 psql (PostgreSQL) 10.5 2台机器ip : 172.17.0.3 /172.17.0. ...

  7. Ext.net combobox 的disabled

    C#:禁用combobox this.ComboBox7.Disabled =true; C#:隐藏 <ext:RadioGroup ID="RadioG_sfzg" run ...

  8. 光伏电池测控系统python代码

    '''硬件keithley万用表和程控电源visa是VXIplug&play系统联盟制定的一套标准.python实现VISA,形成pyviva模块'''###IV测试系统的部分程序代码 fro ...

  9. js第四天学习小结:

    (1)函数的四种形式小结: 无参无返回值 function tellstory(){     console.log("从前有座山");     console.log(" ...

  10. Android图片变形,ImageView属性的设置。

    <ImageView android:id="@+id/iv" android:layout_width="match_parent" android:l ...