1. 06 7月, 2011 5 次提交
  2. 05 7月, 2011 2 次提交
  3. 04 7月, 2011 2 次提交
    • F
      natsemi: silence dma-debug warnings · 2fb83cd6
      FUJITA Tomonori 提交于
      This silences dma-debug warnings:
      
      https://lkml.org/lkml/2011/6/30/341
      
      ------------[ cut here ]------------
      WARNING: at /home/jimc/projects/lx/linux-2.6/lib/dma-debug.c:820
      check_unmap+0x1fe/0x56a()
      natsemi 0000:00:06.0: DMA-API: device driver frees DMA memory with
      different size [device address=0x0000000006ef0040] [map size=1538
      bytes] [unmap size=1522 bytes]
      Modules linked in: pc8736x_gpio pc87360 hwmon_vid scx200_gpio nsc_gpio
      scx200_hrt scx200_acb i2c_core arc4 rtl8180 mac80211 eeprom_93cx6
      cfg80211 pcspkr rfkill scx200 ide_gd_mod ide_pci_generic ohci_hcd
      usbcore sc1200 ide_core
      Pid: 870, comm: collector Not tainted 3.0.0-rc5-sk-00080-gca56a95e #1
      Call Trace:
       [<c011a556>] warn_slowpath_common+0x4a/0x5f
       [<c02565cb>] ? check_unmap+0x1fe/0x56a
       [<c011a5cf>] warn_slowpath_fmt+0x26/0x2a
       [<c02565cb>] check_unmap+0x1fe/0x56a
       [<c0256aaa>] debug_dma_unmap_page+0x53/0x5b
       [<c029d6cd>] pci_unmap_single+0x4d/0x57
       [<c029ea0a>] natsemi_poll+0x343/0x5ca
       [<c0116f41>] ? try_to_wake_up+0xea/0xfc
       [<c0122416>] ? spin_unlock_irq.clone.28+0x18/0x23
       [<c02d4667>] net_rx_action+0x3f/0xe5
       [<c011e35e>] __do_softirq+0x5b/0xd1
       [<c011e303>] ? local_bh_enable+0xa/0xa
       <IRQ>  [<c011e54b>] ? irq_exit+0x34/0x75
       [<c01034b9>] ? do_IRQ+0x66/0x79
       [<c034e869>] ? common_interrupt+0x29/0x30
       [<c0115ed0>] ? finish_task_switch.clone.118+0x31/0x72
       [<c034cb92>] ? schedule+0x3b2/0x3f1
       [<c012f4b0>] ? hrtimer_start_range_ns+0x10/0x12
       [<c012f4ce>] ? hrtimer_start_expires+0x1c/0x24
       [<c034d5aa>] ? schedule_hrtimeout_range_clock+0x8e/0xb4
       [<c012ed27>] ? update_rmtp+0x68/0x68
       [<c034d5da>] ? schedule_hrtimeout_range+0xa/0xc
       [<c017a913>] ? poll_schedule_timeout+0x27/0x3e
       [<c017b051>] ? do_select+0x488/0x4cd
       [<c0115ee2>] ? finish_task_switch.clone.118+0x43/0x72
       [<c01157ad>] ? need_resched+0x14/0x1e
       [<c017a99e>] ? poll_freewait+0x74/0x74
       [<c01157ad>] ? need_resched+0x14/0x1e
       [<c034cbc1>] ? schedule+0x3e1/0x3f1
       [<c011e55e>] ? irq_exit+0x47/0x75
       [<c01157ad>] ? need_resched+0x14/0x1e
       [<c034cf8a>] ? preempt_schedule_irq+0x44/0x4a
       [<c034dd1e>] ? need_resched+0x17/0x19
       [<c024bc12>] ? put_dec_full+0x7b/0xaa
       [<c0240060>] ? blkdev_ioctl+0x434/0x618
       [<c024bc70>] ? put_dec+0x2f/0x6d
       [<c024c6a5>] ? number.clone.1+0x10b/0x1d0
       [<c034cf8a>] ? preempt_schedule_irq+0x44/0x4a
       [<c034dd1e>] ? need_resched+0x17/0x19
       [<c024d046>] ? vsnprintf+0x225/0x264
       [<c024cea0>] ? vsnprintf+0x7f/0x264
       [<c018346f>] ? seq_printf+0x22/0x40
       [<c01a2fcc>] ? do_task_stat+0x582/0x5a3
       [<c017a913>] ? poll_schedule_timeout+0x27/0x3e
       [<c017b1b5>] ? core_sys_select+0x11f/0x1a3
       [<c017a913>] ? poll_schedule_timeout+0x27/0x3e
       [<c01a34a1>] ? proc_tgid_stat+0xd/0xf
       [<c012357c>] ? recalc_sigpending+0x32/0x35
       [<c0123b9c>] ? __set_task_blocked+0x64/0x6a
       [<c011dfb0>] ? timespec_add_safe+0x24/0x48
       [<c0123449>] ? spin_unlock_irq.clone.16+0x18/0x23
       [<c017b3a1>] ? sys_pselect6+0xe5/0x13e
       [<c034dd65>] ? syscall_call+0x7/0xb
       [<c0340000>] ? rpc_clntdir_depopulate+0x26/0x30
      ---[ end trace 180dcac41a50938b ]---
      Reported-by: NJim Cromie <jim.cromie@gmail.com>
      Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      Tested-by: NJim Cromie <jim.cromie@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2fb83cd6
    • S
      net: 8139too: Initial necessary vlan_features to support vlan · 60b67703
      Shan Wei 提交于
      Offload setting of vlan device requires
      vlan_features to be initialized.
      Signed-off-by: NShan Wei <shanwei@cn.fujitsu.com>
      Acked-by: NFrancois Romieu <romieu@fr.zoreil.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      60b67703
  4. 02 7月, 2011 10 次提交
    • S
      Fix call trace when interrupts are disabled while sleeping function kzalloc is called · 5f77898d
      Shyam Iyer 提交于
      request_threaded irq will call kzalloc that can sleep. Initializing the flags variable outside of spin_lock_irqsave/restore in bnad_mbox_irq_alloc will avoid call traces like below.
      
      Jun 27 08:15:24 home-t710 kernel: [11735.634550] Brocade 10G Ethernet driver
      Jun 27 08:15:24 home-t710 kernel: [11735.634590] bnad_pci_probe : (0xffff880427f3d000, 0xffffffffa020f3e0) PCI Func : (2)
      Jun 27 08:15:24 home-t710 kernel: [11735.637677] bna 0000:82:00.2: PCI INT A -> GSI 66 (level, low) -> IRQ 66
      Jun 27 08:15:24 home-t710 kernel: [11735.638290] bar0 mapped to ffffc90014980000, len 262144
      Jun 27 08:15:24 home-t710 kernel: [11735.638732] BUG: sleeping function called from invalid context at mm/slub.c:847
      Jun 27 08:15:24 home-t710 kernel: [11735.638736] in_atomic(): 0, irqs_disabled(): 1, pid: 11243, name: insmod
      Jun 27 08:15:24 home-t710 kernel: [11735.638740] Pid: 11243, comm: insmod Not tainted 3.0.0-rc4+ #6
      Jun 27 08:15:24 home-t710 kernel: [11735.638743] Call Trace:
      Jun 27 08:15:24 home-t710 kernel: [11735.638755]  [<ffffffff81046427>] __might_sleep+0xeb/0xf0
      Jun 27 08:15:24 home-t710 kernel: [11735.638766]  [<ffffffffa01fe469>] ? netif_wake_queue+0x3d/0x3d [bna]
      Jun 27 08:15:24 home-t710 kernel: [11735.638773]  [<ffffffff8111201c>] kmem_cache_alloc_trace+0x43/0xd8
      Jun 27 08:15:24 home-t710 kernel: [11735.638782]  [<ffffffffa01fe469>] ? netif_wake_queue+0x3d/0x3d [bna]
      Jun 27 08:15:24 home-t710 kernel: [11735.638787]  [<ffffffff810ab791>] request_threaded_irq+0xa1/0x113
      Jun 27 08:15:24 home-t710 kernel: [11735.638798]  [<ffffffffa020f0c0>] bnad_pci_probe+0x612/0x8e5 [bna]
      Jun 27 08:15:24 home-t710 kernel: [11735.638807]  [<ffffffffa01fe469>] ? netif_wake_queue+0x3d/0x3d [bna]
      Jun 27 08:15:24 home-t710 kernel: [11735.638816]  [<ffffffff81482ef4>] ? _raw_spin_unlock_irqrestore+0x17/0x19
      Jun 27 08:15:24 home-t710 kernel: [11735.638822]  [<ffffffff8124d17a>] local_pci_probe+0x44/0x75
      Jun 27 08:15:24 home-t710 kernel: [11735.638826]  [<ffffffff8124dc06>] pci_device_probe+0xd0/0xff
      Jun 27 08:15:24 home-t710 kernel: [11735.638832]  [<ffffffff812ef8ab>] driver_probe_device+0x131/0x213
      Jun 27 08:15:24 home-t710 kernel: [11735.638836]  [<ffffffff812ef9e7>] __driver_attach+0x5a/0x7e
      Jun 27 08:15:24 home-t710 kernel: [11735.638840]  [<ffffffff812ef98d>] ? driver_probe_device+0x213/0x213
      Jun 27 08:15:24 home-t710 kernel: [11735.638844]  [<ffffffff812ee933>] bus_for_each_dev+0x53/0x89
      Jun 27 08:15:24 home-t710 kernel: [11735.638848]  [<ffffffff812ef48a>] driver_attach+0x1e/0x20
      Jun 27 08:15:24 home-t710 kernel: [11735.638852]  [<ffffffff812ef0ae>] bus_add_driver+0xd1/0x224
      Jun 27 08:15:24 home-t710 kernel: [11735.638858]  [<ffffffffa01b8000>] ? 0xffffffffa01b7fff
      Jun 27 08:15:24 home-t710 kernel: [11735.638862]  [<ffffffff812efe57>] driver_register+0x98/0x105
      Jun 27 08:15:24 home-t710 kernel: [11735.638866]  [<ffffffffa01b8000>] ? 0xffffffffa01b7fff
      Jun 27 08:15:24 home-t710 kernel: [11735.638871]  [<ffffffff8124e4c9>] __pci_register_driver+0x56/0xc1
      Jun 27 08:15:24 home-t710 kernel: [11735.638875]  [<ffffffffa01b8000>] ? 0xffffffffa01b7fff
      Jun 27 08:15:24 home-t710 kernel: [11735.638884]  [<ffffffffa01b8040>] bnad_module_init+0x40/0x60 [bna]
      Jun 27 08:15:24 home-t710 kernel: [11735.638892]  [<ffffffff81002099>] do_one_initcall+0x7f/0x136
      Jun 27 08:15:24 home-t710 kernel: [11735.638899]  [<ffffffff8108608b>] sys_init_module+0x88/0x1d0
      Jun 27 08:15:24 home-t710 kernel: [11735.638906]  [<ffffffff81489682>] system_call_fastpath+0x16/0x1b
      Jun 27 08:15:24 home-t710 kernel: [11735.639642] bnad_pci_probe : (0xffff880427f3e000, 0xffffffffa020f3e0) PCI Func : (3)
      Jun 27 08:15:24 home-t710 kernel: [11735.639665] bna 0000:82:00.3: PCI INT A -> GSI 66 (level, low) -> IRQ 66
      Jun 27 08:15:24 home-t710 kernel: [11735.639735] bar0 mapped to ffffc90014400000, len 262144
      Signed-off-by: NShyam Iyer <shyam_iyer@dell.com>
      Acked-by: NRasesh Mody <rmody@brocade.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5f77898d
    • J
    • J
      qlge: Fix printk priority so chip fatal errors are always reported. · 5069ee55
      Jitendra Kalsaria 提交于
      Precedence of the printk should be at higher level so chip fatal
      errors are always reported.
      Signed-off-by: NJitendra Kalsaria <jitendra.kalsaria@qlogic.com>
      Signed-off-by: NRon Mercer <ron.mercer@qlogic.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5069ee55
    • J
      qlge:Fix crash caused by mailbox execution on wedged chip. · da92b393
      Jitendra Kalsaria 提交于
      When we are in a recover process from a chip fatal error,
      	driver should skip over execution of mailbox commands during
      	resetting chip.
      Signed-off-by: NJitendra Kalsaria <jitendra.kalsaria@qlogic.com>
      Signed-off-by: NRon Mercer <ron.mercer@qlogic.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      da92b393
    • S
      xfrm4: Don't call icmp_send on local error · b00897b8
      Steffen Klassert 提交于
      Calling icmp_send() on a local message size error leads to
      an incorrect update of the path mtu. So use ip_local_error()
      instead to notify the socket about the error.
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b00897b8
    • S
      ipv4: Don't use ufo handling on later transformed packets · c146066a
      Steffen Klassert 提交于
      We might call ip_ufo_append_data() for packets that will be IPsec
      transformed later. This function should be used just for real
      udp packets. So we check for rt->dst.header_len which is only
      nonzero on IPsec handling and call ip_ufo_append_data() just
      if rt->dst.header_len is zero.
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c146066a
    • S
      xfrm: Remove family arg from xfrm_bundle_ok · 12fdb4d3
      Steffen Klassert 提交于
      The family arg is not used any more, so remove it.
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      12fdb4d3
    • D
      ipv6: Don't put artificial limit on routing table size. · 957c665f
      David S. Miller 提交于
      IPV6, unlike IPV4, doesn't have a routing cache.
      
      Routing table entries, as well as clones made in response
      to route lookup requests, all live in the same table.  And
      all of these things are together collected in the destination
      cache table for ipv6.
      
      This means that routing table entries count against the garbage
      collection limits, even though such entries cannot ever be reclaimed
      and are added explicitly by the administrator (rather than being
      created in response to lookups).
      
      Therefore it makes no sense to count ipv6 routing table entries
      against the GC limits.
      
      Add a DST_NOCOUNT destination cache entry flag, and skip the counting
      if it is set.  Use this flag bit in ipv6 when adding routing table
      entries.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      957c665f
    • D
      ipv6: Don't change dst->flags using assignments. · 11d53b49
      David S. Miller 提交于
      This blows away any flags already set in the entry.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      11d53b49
    • A
      6pack,mkiss: fix lock inconsistency · 6e4e2f81
      Arnd Bergmann 提交于
      Lockdep found a locking inconsistency in the mkiss_close function:
      
      > kernel: [ INFO: inconsistent lock state ]
      > kernel: 2.6.39.1 #3
      > kernel: ---------------------------------
      > kernel: inconsistent {IN-SOFTIRQ-R} -> {SOFTIRQ-ON-W} usage.
      > kernel: ax25ipd/2813 [HC0[0]:SC0[0]:HE1:SE1] takes:
      > kernel: (disc_data_lock){+++?.-}, at: [<ffffffffa018552b>] mkiss_close+0x1b/0x90 [mkiss]
      > kernel: {IN-SOFTIRQ-R} state was registered at:
      
      The message hints that disc_data_lock is aquired with softirqs disabled,
      but does not itself disable softirqs, which can in rare circumstances
      lead to a deadlock. 
      The same problem is present in the 6pack driver, this patch fixes both
      by using write_lock_bh instead of write_lock.
      Reported-by: NBernard F6BVP <f6bvp@free.fr>
      Tested-by: NBernard F6BVP <f6bvp@free.fr>
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: Ralf Baechle<ralf@linux-mips.org>
      Cc: stable@kernel.org
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6e4e2f81
  5. 01 7月, 2011 6 次提交
  6. 30 6月, 2011 15 次提交