Bug 14169

Summary: [e100] device driver syncs DMA memory with different direction
Product: Drivers Reporter: Robert de Rooy (robert.de.rooy)
Component: NetworkAssignee: Jesse Brandeburg (jbrandeb)
Status: CLOSED PATCH_ALREADY_AVAILABLE    
Severity: normal CC: akpm, jbrandeb, khalasa
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 2.6.31 Subsystem:
Regression: No Bisected commit-id:
Attachments: dmesg log file

Description Robert de Rooy 2009-09-12 21:55:23 UTC
Created attachment 23082 [details]
dmesg log file

ThinkPad X22 running Fedora Rawhide

------------[ cut here ]------------
WARNING: at lib/dma-debug.c:917 check_sync+0x23c/0x413() (Not tainted)
Hardware name: 266295U
e100 0000:02:08.0: DMA-API: device driver syncs DMA memory with different direction [device address=0x0000000025975202] [size=1534 bytes] [mapped with DMA_BIDIRECTIONAL] [synced with DMA_FROM_DEVICE]
Modules linked in: ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 dm_multipath uinput snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm ppdev snd_timer thinkpad_acpi nsc_ircc parport_pc snd e100 hwmon soundcore yenta_socket mii i2c_i801 parport rfkill rsrc_nonstatic irda snd_page_alloc iTCO_wdt iTCO_vendor_support crc_ccitt video output radeon ttm drm_kms_helper drm i2c_algo_bit i2c_core [last unloaded: scsi_wait_scan]
Pid: 973, comm: NetworkManager Not tainted 2.6.31-2.fc12.i686 #1
Call Trace:
 [<c0444a19>] warn_slowpath_common+0x7b/0xa3
 [<c060b4c0>] ? check_sync+0x23c/0x413
 [<c0444aaa>] warn_slowpath_fmt+0x34/0x48
 [<c060b4c0>] check_sync+0x23c/0x413
 [<c060b9e3>] debug_dma_sync_single_for_device+0x52/0x6a
 [<e9664f75>] pci_dma_sync_single_for_device.clone.0+0x5d/0x7c [e100]
 [<e9665695>] e100_poll+0xc9/0x28f [e100]
 [<c07872b3>] net_rx_action+0xa7/0x1d3
 [<c044b409>] ? __do_softirq+0x60/0x192
 [<c044b471>] __do_softirq+0xc8/0x192
 [<c044b584>] do_softirq+0x49/0x7f
 [<c044b6d8>] irq_exit+0x48/0x8c
 [<c0405705>] do_IRQ+0x92/0xb7
 [<c0404095>] common_interrupt+0x35/0x3c
 [<c0826447>] ? _spin_unlock_irqrestore+0x53/0x6d
 [<c0433ac2>] __wake_up_sync_key+0x50/0x6b
 [<c077a3d0>] sock_def_readable+0x4d/0x7e
 [<c07a2222>] netlink_broadcast+0x1ac/0x257
 [<c07a28f8>] nlmsg_notify+0x4f/0x99
 [<c0790d72>] rtnl_notify+0x49/0x65
 [<c0790e25>] rtmsg_ifinfo+0x97/0xc9
 [<c0790ea1>] rtnetlink_event+0x4a/0x5f
 [<c0828dab>] notifier_call_chain+0x5d/0x95
 [<c0462145>] raw_notifier_call_chain+0x21/0x37
 [<c0787f2d>] call_netdevice_notifiers+0x25/0x38
 [<c0788bfd>] dev_open+0xca/0xe4
 [<c0788282>] dev_change_flags+0xa6/0x166
 [<c0791918>] do_setlink+0x2ab/0x362
 [<c0826342>] ? _read_unlock+0x30/0x45
 [<c0791aac>] rtnl_setlink+0xdd/0xee
 [<c07919cf>] ? rtnl_setlink+0x0/0xee
 [<c07912f1>] rtnetlink_rcv_msg+0x1a1/0x1c8
 [<c0791150>] ? rtnetlink_rcv_msg+0x0/0x1c8
 [<c07a2a74>] netlink_rcv_skb+0x43/0x9b
 [<c0791138>] rtnetlink_rcv+0x2c/0x44
 [<c07a25cd>] netlink_unicast+0xfc/0x16a
 [<c07a288b>] netlink_sendmsg+0x250/0x26e
 [<c0776718>] __sock_sendmsg+0x5f/0x79
 [<c0776fb2>] sock_sendmsg+0xc7/0xee
 [<c045d1ca>] ? autoremove_wake_function+0x0/0x55
 [<c04d7690>] ? might_fault+0x56/0xa4
 [<c04d7690>] ? might_fault+0x56/0xa4
 [<c07805b3>] ? verify_iovec+0x53/0x94
 [<c0777171>] sys_sendmsg+0x198/0x1f9
 [<c046f899>] ? mark_lock+0x29/0x1f6
 [<c040949d>] ? sched_clock+0x9/0xd
 [<c046e605>] ? lock_release_holdtime+0x39/0x143
 [<c04d7690>] ? might_fault+0x56/0xa4
 [<c04d7690>] ? might_fault+0x56/0xa4
 [<c04d76cb>] ? might_fault+0x91/0xa4
 [<c077876e>] sys_socketcall+0x16a/0x1a6
 [<c0403a50>] syscall_call+0x7/0xb
---[ end trace 40298d0455ef53ff ]---
Mapped at:
 [<c060c68f>] debug_dma_map_page+0x6b/0x13b
 [<e9662cb5>] pci_map_single+0x81/0x9c [e100]
 [<e9665013>] e100_rx_alloc_skb+0x7f/0x113 [e100]
 [<e966513d>] e100_rx_alloc_list+0x96/0x108 [e100]
 [<e96651d1>] e100_up+0x22/0xec [e100]
Comment 1 Andrew Morton 2009-09-24 23:20:55 UTC
Thanks, I queued a fix (e100c-use-pci_dma_bidirectional-in-e100_rx_indicate.patch) - perhaps you cant test it sometime?
Comment 2 Krzysztof Halasa 2009-09-27 12:43:25 UTC
Not a bug :-)

Commit 6ff9c2e7fa8ca63a575792534b63c5092099c286:

    E100: fix interaction with swiotlb on X86.
    
    E100 places it's RX packet descriptors inside skb->data and uses them
    with bidirectional streaming DMA mapping. Data in descriptors is
    accessed simultaneously by the chip (writing status and size when
    a packet is received) and CPU (reading to check if the packet was
    received). This isn't a valid usage of PCI DMA API, which requires use
    of the coherent (consistent) memory for such purpose. Unfortunately e100
    chips working in "simplified" RX mode have to store received data
    directly after the descriptor. Fixing the driver to conform to the API
    would require using unsupported "flexible" RX mode or receiving data
    into a coherent memory and using CPU to copy it to network buffers.
    
    This patch, while not yet making the driver conform to the PCI DMA API,
    allows it to work correctly on X86 with swiotlb (while not breaking
    other architectures).

Syncing with BIDIR would cause swiotlb (and any similar "soft-IOMMU") to copy the buffer (CPU->e100) first, probably discarding status changes made by e100.

Printing the warning is a bug, though. I'll fix that.

Summary: I think that the valid sync modes should be:
- TO_DEVICE with TO_DEVICE and BIDIR mappings
- FROM_DEVICE with FROM_DEVICE and BIDIR mappings
- BIDIR with BIDIR mappings.
Comment 3 Jesse Brandeburg 2009-12-14 19:34:08 UTC
Marking this bug as fixed.