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]
Thanks, I queued a fix (e100c-use-pci_dma_bidirectional-in-e100_rx_indicate.patch) - perhaps you cant test it sometime?
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.
Marking this bug as fixed.