1. 08 4月, 2019 1 次提交
    • W
      drivers: Remove explicit invocations of mmiowb() · fb24ea52
      Will Deacon 提交于
      mmiowb() is now implied by spin_unlock() on architectures that require
      it, so there is no reason to call it from driver code. This patch was
      generated using coccinelle:
      
      	@mmiowb@
      	@@
      	- mmiowb();
      
      and invoked as:
      
      $ for d in drivers include/linux/qed sound; do \
      spatch --include-headers --sp-file mmiowb.cocci --dir $d --in-place; done
      
      NOTE: mmiowb() has only ever guaranteed ordering in conjunction with
      spin_unlock(). However, pairing each mmiowb() removal in this patch with
      the corresponding call to spin_unlock() is not at all trivial, so there
      is a small chance that this change may regress any drivers incorrectly
      relying on mmiowb() to order MMIO writes between CPUs using lock-free
      synchronisation. If you've ended up bisecting to this commit, you can
      reintroduce the mmiowb() calls using wmb() instead, which should restore
      the old behaviour on all architectures other than some esoteric ia64
      systems.
      Acked-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      fb24ea52
  2. 08 3月, 2019 1 次提交
  3. 24 1月, 2019 1 次提交
    • S
      ravb: expand rx descriptor data to accommodate hw checksum · 12da6430
      Simon Horman 提交于
      EtherAVB may provide a checksum of packet data appended to packet data. In
      order to allow this checksum to be received by the host descriptor data
      needs to be enlarged by 2 bytes to accommodate the checksum.
      
      In the case of MTU-sized packets without a VLAN tag the
      checksum were already accommodated by virtue of the space reserved for the
      VLAN tag. However, a packet of MTU-size with a  VLAN tag consumed all
      packet data space provided by a descriptor leaving no space for the
      trailing checksum.
      
      This was not detected by the driver which incorrectly used the last two
      bytes of packet data as the checksum and truncate the packet by two bytes.
      This resulted all such packets being dropped.
      
      A work around is to disable RX checksum offload
       # ethtool -K eth0 rx off
      
      This patch resolves this problem by increasing the size available for
      packet data in RX descriptors by two bytes.
      
      Tested on R-Car E3 (r8a77990) ES1.0 based Ebisu-4D board
      
      v2
      * Use sizeof(__sum16) directly rather than adding a driver-local
        #define for the size of the checksum provided by the hw (2 bytes).
      
      Fixes: 4d86d381 ("ravb: RX checksum offload")
      Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>
      Reviewed-by: NSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      12da6430
  4. 24 11月, 2018 2 次提交
  5. 22 9月, 2018 1 次提交
  6. 20 9月, 2018 1 次提交
  7. 19 9月, 2018 1 次提交
  8. 13 9月, 2018 1 次提交
  9. 23 8月, 2018 1 次提交
  10. 18 7月, 2018 3 次提交
  11. 10 7月, 2018 1 次提交
  12. 07 7月, 2018 7 次提交
  13. 07 3月, 2018 1 次提交
  14. 17 2月, 2018 1 次提交
  15. 13 2月, 2018 1 次提交
  16. 03 1月, 2018 1 次提交
  17. 14 12月, 2017 1 次提交
  18. 13 10月, 2017 1 次提交
  19. 05 10月, 2017 1 次提交
    • S
      ravb: RX checksum offload · 4d86d381
      Simon Horman 提交于
      Add support for RX checksum offload. This is enabled by default and
      may be disabled and re-enabled using ethtool:
      
       # ethtool -K eth0 rx off
       # ethtool -K eth0 rx on
      
      The RAVB provides a simple checksumming scheme which appears to be
      completely compatible with CHECKSUM_COMPLETE: sum of all packet data after
      the L2 header is appended to packet data; this may be trivially read by the
      driver and used to update the skb accordingly.
      
      In terms of performance throughput is close to gigabit line-rate both with
      and without RX checksum offload enabled. Perf output, however, appears to
      indicate that significantly less time is spent in do_csum(). This is as
      expected.
      
      Test results with RX checksum offload enabled:
       # /usr/bin/perf_3.16 record -o /run/perf.data -a netperf -t TCP_MAERTS -H 10.4.3.162
       MIGRATED TCP MAERTS TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.4.3.162 () port 0 AF_INET : demo
       enable_enobufs failed: getprotobyname
       Recv   Send    Send
       Socket Socket  Message  Elapsed
       Size   Size    Size     Time     Throughput
       bytes  bytes   bytes    secs.    10^6bits/sec
      
        87380  16384  16384    10.00     937.54
      
       Summary of output of perf report:
          18.28%      ksoftirqd/0  [kernel.kallsyms]  [k] _raw_spin_unlock_irqrestore
          10.34%      ksoftirqd/0  [kernel.kallsyms]  [k] __pi_memcpy
           9.83%      ksoftirqd/0  [kernel.kallsyms]  [k] ravb_poll
           7.89%      ksoftirqd/0  [kernel.kallsyms]  [k] skb_put
           4.01%      ksoftirqd/0  [kernel.kallsyms]  [k] dev_gro_receive
           3.37%          netperf  [kernel.kallsyms]  [k] __arch_copy_to_user
           3.17%          swapper  [kernel.kallsyms]  [k] arch_cpu_idle
           2.55%          swapper  [kernel.kallsyms]  [k] tick_nohz_idle_enter
           2.04%      ksoftirqd/0  [kernel.kallsyms]  [k] __pi___inval_dcache_area
           2.03%          swapper  [kernel.kallsyms]  [k] _raw_spin_unlock_irq
           1.96%      ksoftirqd/0  [kernel.kallsyms]  [k] __netdev_alloc_skb
           1.59%      ksoftirqd/0  [kernel.kallsyms]  [k] __slab_alloc.isra.83
      
      Test results without RX checksum offload enabled:
       # /usr/bin/perf_3.16 record -o /run/perf.data -a netperf -t TCP_MAERTS -H 10.4.3.162
       MIGRATED TCP MAERTS TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.4.3.162 () port 0 AF_INET : demo
       enable_enobufs failed: getprotobyname
       Recv   Send    Send
       Socket Socket  Message  Elapsed
       Size   Size    Size     Time     Throughput
       bytes  bytes   bytes    secs.    10^6bits/sec
      
        87380  16384  16384    10.00     940.20
      
       Summary of output of perf report:
          17.10%    ksoftirqd/0  [kernel.kallsyms]  [k] _raw_spin_unlock_irqrestore
          10.99%    ksoftirqd/0  [kernel.kallsyms]  [k] __pi_memcpy
           8.87%    ksoftirqd/0  [kernel.kallsyms]  [k] ravb_poll
           8.16%    ksoftirqd/0  [kernel.kallsyms]  [k] skb_put
           7.42%    ksoftirqd/0  [kernel.kallsyms]  [k] do_csum
           3.91%    ksoftirqd/0  [kernel.kallsyms]  [k] dev_gro_receive
           2.31%        swapper  [kernel.kallsyms]  [k] arch_cpu_idle
           2.16%    ksoftirqd/0  [kernel.kallsyms]  [k] __pi___inval_dcache_area
           2.14%    ksoftirqd/0  [kernel.kallsyms]  [k] __netdev_alloc_skb
           1.93%        netperf  [kernel.kallsyms]  [k] __arch_copy_to_user
           1.79%        swapper  [kernel.kallsyms]  [k] tick_nohz_idle_enter
           1.63%    ksoftirqd/0  [kernel.kallsyms]  [k] __slab_alloc.isra.83
      
      Above results collected on an R-Car Gen 3 Salvator-X/r8a7796 ES1.0.
      Also tested on a R-Car Gen 3 Salvator-X/r8a7795 ES1.0.
      
      By inspection this also appears to be compatible with the ravb found
      on R-Car Gen 2 SoCs, however, this patch is currently untested on such
      hardware.
      Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4d86d381
  20. 02 8月, 2017 2 次提交
    • N
      ravb: add workaround for clock when resuming with WoL enabled · fbf3d034
      Niklas Söderlund 提交于
      The renesas-cpg-mssr clock driver are not yet aware of PSCI sleep where
      power is cut to the SoC. When resuming from this state with WoL enabled
      the enable count of the ravb clock is 1 and the clock driver thinks the
      clock is already on when PM core enables the clock and increments the
      enable count to 2. This will result in the ravb driver failing to talk
      to the hardware since the module clock is off. Work around this by
      forcing the enable count to 0 and then back to 2 when resuming with WoL
      enabled.
      
      This workaround should be reverted once the renesas-cpg-mssr clock
      driver becomes aware of this PSCI sleep behavior.
      Signed-off-by: NNiklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
      Acked-by: NSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fbf3d034
    • N
      ravb: add wake-on-lan support via magic packet · 3e3d6477
      Niklas Söderlund 提交于
      WoL is enabled in the suspend callback by setting MagicPacket detection
      and disabling all interrupts expect MagicPacket. In the resume path the
      driver needs to reset the hardware to rearm the WoL logic, this prevents
      the driver from simply restoring the registers and to take advantage of
      that ravb was not suspended to reduce resume time. To reset the
      hardware the driver closes the device, sets it in reset mode and reopens
      the device just like it would do in a normal suspend/resume scenario
      without WoL enabled, but it both closes and opens the device in the
      resume callback since the device needs to be reset for WoL to work.
      
      One quirk needed for WoL is that the module clock needs to be prevented
      from being switched off by Runtime PM. To keep the clock alive the
      suspend callback need to call clk_enable() directly to increase the
      usage count of the clock. Then when Runtime PM decreases the clock usage
      count it won't reach 0 and be switched off.
      Signed-off-by: NNiklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
      Acked-by: NSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3e3d6477
  21. 14 6月, 2017 1 次提交
  22. 07 6月, 2017 1 次提交
    • E
      ravb: Fix use-after-free on `ifconfig eth0 down` · 79514ef6
      Eugeniu Rosca 提交于
      Commit a47b70ea ("ravb: unmap descriptors when freeing rings") has
      introduced the issue seen in [1] reproduced on H3ULCB board.
      
      Fix this by relocating the RX skb ringbuffer free operation, so that
      swiotlb page unmapping can be done first. Freeing of aligned TX buffers
      is not relevant to the issue seen in [1]. Still, reposition TX free
      calls as well, to have all kfree() operations performed consistently
      _after_ dma_unmap_*()/dma_free_*().
      
      [1] Console screenshot with the problem reproduced:
      
      salvator-x login: root
      root@salvator-x:~# ifconfig eth0 up
      Micrel KSZ9031 Gigabit PHY e6800000.ethernet-ffffffff:00: \
             attached PHY driver [Micrel KSZ9031 Gigabit PHY]   \
             (mii_bus:phy_addr=e6800000.ethernet-ffffffff:00, irq=235)
      IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
      root@salvator-x:~#
      root@salvator-x:~# ifconfig eth0 down
      
      ==================================================================
      BUG: KASAN: use-after-free in swiotlb_tbl_unmap_single+0xc4/0x35c
      Write of size 1538 at addr ffff8006d884f780 by task ifconfig/1649
      
      CPU: 0 PID: 1649 Comm: ifconfig Not tainted 4.12.0-rc4-00004-g112eb072 #32
      Hardware name: Renesas H3ULCB board based on r8a7795 (DT)
      Call trace:
      [<ffff20000808f11c>] dump_backtrace+0x0/0x3a4
      [<ffff20000808f4d4>] show_stack+0x14/0x1c
      [<ffff20000865970c>] dump_stack+0xf8/0x150
      [<ffff20000831f8b0>] print_address_description+0x7c/0x330
      [<ffff200008320010>] kasan_report+0x2e0/0x2f4
      [<ffff20000831eac0>] check_memory_region+0x20/0x14c
      [<ffff20000831f054>] memcpy+0x48/0x68
      [<ffff20000869ed50>] swiotlb_tbl_unmap_single+0xc4/0x35c
      [<ffff20000869fcf4>] unmap_single+0x90/0xa4
      [<ffff20000869fd14>] swiotlb_unmap_page+0xc/0x14
      [<ffff2000080a2974>] __swiotlb_unmap_page+0xcc/0xe4
      [<ffff2000088acdb8>] ravb_ring_free+0x514/0x870
      [<ffff2000088b25dc>] ravb_close+0x288/0x36c
      [<ffff200008aaf8c4>] __dev_close_many+0x14c/0x174
      [<ffff200008aaf9b4>] __dev_close+0xc8/0x144
      [<ffff200008ac2100>] __dev_change_flags+0xd8/0x194
      [<ffff200008ac221c>] dev_change_flags+0x60/0xb0
      [<ffff200008ba2dec>] devinet_ioctl+0x484/0x9d4
      [<ffff200008ba7b78>] inet_ioctl+0x190/0x194
      [<ffff200008a78c44>] sock_do_ioctl+0x78/0xa8
      [<ffff200008a7a128>] sock_ioctl+0x110/0x3c4
      [<ffff200008365a70>] vfs_ioctl+0x90/0xa0
      [<ffff200008365dbc>] do_vfs_ioctl+0x148/0xc38
      [<ffff2000083668f0>] SyS_ioctl+0x44/0x74
      [<ffff200008083770>] el0_svc_naked+0x24/0x28
      
      The buggy address belongs to the page:
      page:ffff7e001b6213c0 count:0 mapcount:0 mapping:          (null) index:0x0
      flags: 0x4000000000000000()
      raw: 4000000000000000 0000000000000000 0000000000000000 00000000ffffffff
      raw: 0000000000000000 ffff7e001b6213e0 0000000000000000 0000000000000000
      page dumped because: kasan: bad access detected
      
      Memory state around the buggy address:
       ffff8006d884f680: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
       ffff8006d884f700: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
      >ffff8006d884f780: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
                         ^
       ffff8006d884f800: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
       ffff8006d884f880: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
      ==================================================================
      Disabling lock debugging due to kernel taint
      root@salvator-x:~#
      
      Fixes: a47b70ea ("ravb: unmap descriptors when freeing rings")
      Signed-off-by: NEugeniu Rosca <erosca@de.adit-jv.com>
      Acked-by: NSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      79514ef6
  23. 25 4月, 2017 1 次提交
  24. 30 1月, 2017 2 次提交
  25. 27 1月, 2017 1 次提交
  26. 17 1月, 2017 1 次提交
    • M
      ravb: do not use zero-length alignment DMA descriptor · 8ec3e8a1
      Masaru Nagai 提交于
      Due to alignment requirements of the hardware transmissions are split into
      two DMA descriptors, a small padding descriptor of 0 - 3 bytes in length
      followed by a descriptor for rest of the packet.
      
      In the case of IP packets the first descriptor will never be zero due to
      the way that the stack aligns buffers for IP packets. However, for non-IP
      packets it may be zero.
      
      In that case it has been reported that timeouts occur, presumably because
      transmission stops at the first zero-length DMA descriptor and thus the
      packet is not transmitted. However, in my environment a BUG is triggered as
      follows:
      
      [   20.381417] ------------[ cut here ]------------
      [   20.386054] kernel BUG at lib/swiotlb.c:495!
      [   20.390324] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
      [   20.395805] Modules linked in:
      [   20.398862] CPU: 0 PID: 2089 Comm: mz Not tainted 4.10.0-rc3-00001-gf13ad2db193f #162
      [   20.406689] Hardware name: Renesas Salvator-X board based on r8a7796 (DT)
      [   20.413474] task: ffff80063b1f1900 task.stack: ffff80063a71c000
      [   20.419404] PC is at swiotlb_tbl_map_single+0x178/0x2ec
      [   20.424625] LR is at map_single+0x4c/0x98
      [   20.428629] pc : [<ffff00000839c4c0>] lr : [<ffff00000839c680>] pstate: 800001c5
      [   20.436019] sp : ffff80063a71f9b0
      [   20.439327] x29: ffff80063a71f9b0 x28: ffff80063a20d500
      [   20.444636] x27: ffff000008ed5000 x26: 0000000000000000
      [   20.449944] x25: 000000067abe2adc x24: 0000000000000000
      [   20.455252] x23: 0000000000200000 x22: 0000000000000001
      [   20.460559] x21: 0000000000175ffe x20: ffff80063b2a0010
      [   20.465866] x19: 0000000000000000 x18: 0000ffffcae6fb20
      [   20.471173] x17: 0000ffffa09ba018 x16: ffff0000087c8b70
      [   20.476480] x15: 0000ffffa084f588 x14: 0000ffffa09cfa14
      [   20.481787] x13: 0000ffffcae87ff0 x12: 000000000063abe2
      [   20.487098] x11: ffff000008096360 x10: ffff80063abe2adc
      [   20.492407] x9 : 0000000000000000 x8 : 0000000000000000
      [   20.497718] x7 : 0000000000000000 x6 : ffff000008ed50d0
      [   20.503028] x5 : 0000000000000000 x4 : 0000000000000001
      [   20.508338] x3 : 0000000000000000 x2 : 000000067abe2adc
      [   20.513648] x1 : 00000000bafff000 x0 : 0000000000000000
      [   20.518958]
      [   20.520446] Process mz (pid: 2089, stack limit = 0xffff80063a71c000)
      [   20.526798] Stack: (0xffff80063a71f9b0 to 0xffff80063a720000)
      [   20.532543] f9a0:                                   ffff80063a71fa30 ffff00000839c680
      [   20.540374] f9c0: ffff80063b2a0010 ffff80063b2a0010 0000000000000001 0000000000000000
      [   20.548204] f9e0: 000000000000006e ffff80063b23c000 ffff80063b23c000 0000000000000000
      [   20.556034] fa00: ffff80063b23c000 ffff80063a20d500 000000013b1f1900 0000000000000000
      [   20.563864] fa20: ffff80063ffd18e0 ffff80063b2a0010 ffff80063a71fa60 ffff00000839cd10
      [   20.571694] fa40: ffff80063b2a0010 0000000000000000 ffff80063ffd18e0 000000067abe2adc
      [   20.579524] fa60: ffff80063a71fa90 ffff000008096380 ffff80063b2a0010 0000000000000000
      [   20.587353] fa80: 0000000000000000 0000000000000001 ffff80063a71fac0 ffff00000864f770
      [   20.595184] faa0: ffff80063b23caf0 0000000000000000 0000000000000000 0000000000000140
      [   20.603014] fac0: ffff80063a71fb60 ffff0000087e6498 ffff80063a20d500 ffff80063b23c000
      [   20.610843] fae0: 0000000000000000 ffff000008daeaf0 0000000000000000 ffff000008daeb00
      [   20.618673] fb00: ffff80063a71fc0c ffff000008da7000 ffff80063b23c090 ffff80063a44f000
      [   20.626503] fb20: 0000000000000000 ffff000008daeb00 ffff80063a71fc0c ffff000008da7000
      [   20.634333] fb40: ffff80063b23c090 0000000000000000 ffff800600000037 ffff0000087e63d8
      [   20.642163] fb60: ffff80063a71fbc0 ffff000008807510 ffff80063a692400 ffff80063a20d500
      [   20.649993] fb80: ffff80063a44f000 ffff80063b23c000 ffff80063a69249c 0000000000000000
      [   20.657823] fba0: 0000000000000000 ffff80063a087800 ffff80063b23c000 ffff80063a20d500
      [   20.665653] fbc0: ffff80063a71fc10 ffff0000087e67dc ffff80063a20d500 ffff80063a692400
      [   20.673483] fbe0: ffff80063b23c000 0000000000000000 ffff80063a44f000 ffff80063a69249c
      [   20.681312] fc00: ffff80063a5f1a10 000000103a087800 ffff80063a71fc70 ffff0000087e6b24
      [   20.689142] fc20: ffff80063a5f1a80 ffff80063a71fde8 000000000000000f 00000000000005ea
      [   20.696972] fc40: ffff80063a5f1a10 0000000000000000 000000000000000f ffff00000887fbd0
      [   20.704802] fc60: fffffff43a5f1a80 0000000000000000 ffff80063a71fc80 ffff000008880240
      [   20.712632] fc80: ffff80063a71fd90 ffff0000087c7a34 ffff80063afc7180 0000000000000000
      [   20.720462] fca0: 0000ffffcae6fe18 0000000000000014 0000000060000000 0000000000000015
      [   20.728292] fcc0: 0000000000000123 00000000000000ce ffff0000088d2000 ffff80063b1f1900
      [   20.736122] fce0: 0000000000008933 ffff000008e7cb80 ffff80063a71fd80 ffff0000087c50a4
      [   20.743951] fd00: 0000000000008933 ffff000008e7cb80 ffff000008e7cb80 000000100000000e
      [   20.751781] fd20: ffff80063a71fe4c 0000ffff00000300 0000000000000123 0000000000000000
      [   20.759611] fd40: 0000000000000000 ffff80063b1f0000 000000000000000e 0000000000000300
      [   20.767441] fd60: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
      [   20.775271] fd80: 0000000000000000 0000000000000000 ffff80063a71fda0 ffff0000087c8c20
      [   20.783100] fda0: 0000000000000000 ffff000008082f30 0000000000000000 0000800637260000
      [   20.790930] fdc0: ffffffffffffffff 0000ffffa0903078 0000000000000000 000000001ea87232
      [   20.798760] fde0: 000000000000000f ffff80063a71fe40 ffff800600000014 ffff000000000001
      [   20.806590] fe00: 0000000000000000 0000000000000000 ffff80063a71fde8 0000000000000000
      [   20.814420] fe20: 0000000000000000 0000000000000000 0000000000000000 0000000000000001
      [   20.822249] fe40: 0000000203000011 0000000000000000 0000000000000000 ffff80063a68aa00
      [   20.830079] fe60: ffff80063a68aa00 0000000000000003 0000000000008933 ffff0000081f1b9c
      [   20.837909] fe80: 0000000000000000 ffff000008082f30 0000000000000000 0000800637260000
      [   20.845739] fea0: ffffffffffffffff 0000ffffa07ca81c 0000000060000000 0000000000000015
      [   20.853569] fec0: 0000000000000003 000000001ea87232 000000000000000f 0000000000000000
      [   20.861399] fee0: 0000ffffcae6fe18 0000000000000014 0000000000000300 0000000000000000
      [   20.869228] ff00: 00000000000000ce 0000000000000000 00000000ffffffff 0000000000000000
      [   20.877059] ff20: 0000000000000002 0000ffffcae87ff0 0000ffffa09cfa14 0000ffffa084f588
      [   20.884888] ff40: 0000000000000000 0000ffffa09ba018 0000ffffcae6fb20 000000001ea87010
      [   20.892718] ff60: 0000ffffa09b9000 0000ffffcae6fe30 0000ffffcae6fe18 000000000000000f
      [   20.900548] ff80: 0000000000000003 000000001ea87232 0000000000000000 0000000000000000
      [   20.908378] ffa0: 0000000000000000 0000ffffcae6fdc0 0000ffffa09a7824 0000ffffcae6fdc0
      [   20.916208] ffc0: 0000ffffa0903078 0000000060000000 0000000000000003 00000000000000ce
      [   20.924038] ffe0: 0000000000000000 0000000000000000 ffffffffffffffff ffffffffffffffff
      [   20.931867] Call trace:
      [   20.934312] Exception stack(0xffff80063a71f7e0 to 0xffff80063a71f910)
      [   20.940750] f7e0: 0000000000000000 0001000000000000 ffff80063a71f9b0 ffff00000839c4c0
      [   20.948580] f800: ffff80063a71f840 ffff00000888a6e4 ffff80063a24c418 ffff80063a24c448
      [   20.956410] f820: 0000000000000000 ffff00000811cd54 ffff80063a71f860 ffff80063a24c458
      [   20.964240] f840: ffff80063a71f870 ffff00000888b258 ffff80063a24c418 0000000000000001
      [   20.972070] f860: ffff80063a71f910 ffff80063a7b7028 ffff80063a71f890 ffff0000088825e4
      [   20.979899] f880: 0000000000000000 00000000bafff000 000000067abe2adc 0000000000000000
      [   20.987729] f8a0: 0000000000000001 0000000000000000 ffff000008ed50d0 0000000000000000
      [   20.995560] f8c0: 0000000000000000 0000000000000000 ffff80063abe2adc ffff000008096360
      [   21.003390] f8e0: 000000000063abe2 0000ffffcae87ff0 0000ffffa09cfa14 0000ffffa084f588
      [   21.011219] f900: ffff0000087c8b70 0000ffffa09ba018
      [   21.016097] [<ffff00000839c4c0>] swiotlb_tbl_map_single+0x178/0x2ec
      [   21.022362] [<ffff00000839c680>] map_single+0x4c/0x98
      [   21.027411] [<ffff00000839cd10>] swiotlb_map_page+0xa4/0x138
      [   21.033072] [<ffff000008096380>] __swiotlb_map_page+0x20/0x7c
      [   21.038821] [<ffff00000864f770>] ravb_start_xmit+0x174/0x668
      [   21.044484] [<ffff0000087e6498>] dev_hard_start_xmit+0x8c/0x120
      [   21.050407] [<ffff000008807510>] sch_direct_xmit+0x108/0x1a0
      [   21.056064] [<ffff0000087e67dc>] __dev_queue_xmit+0x194/0x4cc
      [   21.061807] [<ffff0000087e6b24>] dev_queue_xmit+0x10/0x18
      [   21.067214] [<ffff000008880240>] packet_sendmsg+0xf40/0x1220
      [   21.072873] [<ffff0000087c7a34>] sock_sendmsg+0x18/0x2c
      [   21.078097] [<ffff0000087c8c20>] SyS_sendto+0xb0/0xf0
      [   21.083150] [<ffff000008082f30>] el0_svc_naked+0x24/0x28
      [   21.088462] Code: d34bfef7 2a1803f3 1a9f86d6 35fff878 (d4210000)
      [   21.094611] ---[ end trace 5bc544ad491f3814 ]---
      [   21.099234] Kernel panic - not syncing: Fatal exception in interrupt
      [   21.105587] Kernel Offset: disabled
      [   21.109073] Memory Limit: none
      [   21.112126] ---[ end Kernel panic - not syncing: Fatal exception in interrupt
      
      Fixes: 2f45d190 ("ravb: minimize TX data copying")
      Signed-off-by: Masaru Nagai <masaru.nagai.vx@renesas.com
      Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>
      Acked-by: NSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8ec3e8a1
  27. 12 1月, 2017 1 次提交
  28. 03 12月, 2016 1 次提交
  29. 30 11月, 2016 1 次提交