最近又遇到一次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. [UE4]使用UnrealVS扩展快速编译C++代码

    一.如果UE4 编辑器已经打开,则VS中的重新生成项目将不能使用,一定要关了UE4 编辑器才可以.一般不是有VS自身的编译UE4的C++代码 二.epic提供了UnrealVS扩展,可以快速编译C++ ...

  2. SCCM 2012 R2实战系列之十三：辅助站点部署

    由于最近几个月一直处于AD升级项目中,很久没有更新SCCM的技术文档了.SCCM 2012中的辅助站点部署方法还是比较特别的,需要注意的地方也非常多,今天跟大家分享辅助站点的具体部署和配置方法. 1. ...

  3. 知识点：linux数据库备份

    服务端启用二进制日志 如果日志没有启开,必须启用binlog,要重启mysql,首先,关闭mysql,打开/etc/my.cnf,加入以下几行: [mysqld] log-bin 然后重新启动mysq ...

  4. SQLServer: 解决“错误15023:当前数据库中已存在用户或角色”

    首先介绍一下sql server中“登录”与“用户”的区别,“登录”用于用户身份验证,而数据库“用户”帐户用于数据库访问和权限验证.登录通过安全识别符 (SID) 与用户关联.将数据库恢复到其他服务器 ...

  5. windows server 2012 本地用户和组

  6. USACO 2008 Running(贝茜的晨练)

    [题解] 动态规划,dp[i][j]表示第i分钟疲劳度为j的最长距离. [代码] #include <iostream> #include <cstdlib> #include ...

  7. 一个服务器的IIS只能绑定一个HTTPS也就是443端口

    默认情况一个服务器的IIS只能绑定一个HTTPS也就是443端口 要实现多个站点对应HTTPS只能更改IIS配置 地址:C:\Windows\System32\inetsrv\config\appli ...

  8. 04 bash程序的基本特性

    我们知道Linux系统有两种操作方式,一种为GUI的图形界面化管理方式,其中图形程序常见的有Gnome.KDE.xfce:另一种管理方式就是就是GLI的命令行管理方式,而命令行的管理方式就是通过she ...

  9. cocos源码分析--ClippingNode绘图原理

    在OpenGL 绘制过程中,与帧缓冲有关的是模版,深度测试,混合操作.模版测试使应用程序可以定义一个遮罩,在遮罩内的片段将被保留或者丢弃,在遮罩外的片段操作行为则相反.深度测试用来剔除那些被场景遮挡的 ...

  10. JQ获取选中select 标签的值

    Jq://#ses为select 标签的Id$("#ses option:selected").val(); $("#ses option:selected") ...