Bug 914994 - [skge] WARNING: at lib/dma-debug.c:933 check_unmap+0x407/0x8a0()
Summary: [skge] WARNING: at lib/dma-debug.c:933 check_unmap+0x407/0x8a0()
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: rawhide
Hardware: All
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-02-23 22:47 UTC by poma
Modified: 2014-02-21 12:28 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-08-22 14:52:59 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description poma 2013-02-23 22:47:45 UTC
Description of problem:
DMA(mapping) failing within SysKonnect Gigabit Ethernet driver - skge.

Version-Release number of selected component (if applicable):
3.9.0-0.rc0.git5.1.fc18.x86_64

How reproducible:
Engaging the network interface during system startup.

Actual results:
The only side effect that has been observed is the reduced flow of data.
Network interface behaves as 100Mb/s, therefore slower than it should be - 1000Mb/s.

Expected results:
Speed: 1000Mb/s, that is in practice ~300Mb/s.

Additional info:
------------[ cut here ]------------
WARNING: at lib/dma-debug.c:933 check_unmap+0x407/0x8a0()
Hardware name: M720-US3
skge 0000:01:09.0: DMA-API: device driver failed to check map
error[device address=0x0000000105d52522] [size=90 bytes] [mapped as single]
Modules linked in:
 …rfkill ip6t_REJECT nf_conntrack_ipv6 nf_conntrack_ipv4
nf_defrag_ipv6 nf_defrag_ipv4 xt_conntrack ip6table_filter nf_conntrack
ip6_tables… vhost_net tun macvtap… macvlan… nfsd auth_rpcgss nfs_acl
lockd… r8169… mii skge… sunrpc… (irrelevant omitted)
Pid: 0, comm: swapper/3 Tainted: GF          O
3.9.0-0.rc0.git5.1.fc18.x86_64 #1
Call Trace:
 <IRQ>  [<ffffffff81069b5f>] warn_slowpath_common+0x7f/0xc0
 [<ffffffff81069c56>] warn_slowpath_fmt+0x46/0x50
 [<ffffffff81387a47>] check_unmap+0x407/0x8a0
 [<ffffffff810ab62f>] ? try_to_wake_up+0x1ff/0x350
 [<ffffffff813880fe>] debug_dma_unmap_page+0x5e/0x70
 [<ffffffffa00750ac>] ? skge_intr+0x2c/0x570 [skge]
 [<ffffffffa0073525>] skge_poll+0x1b5/0x9c0 [skge]
 [<ffffffff815e7672>] net_rx_action+0x172/0x380
 [<ffffffff810737e0>] __do_softirq+0x100/0x400
 [<ffffffff81021dd3>] ? native_sched_clock+0x13/0x80
 [<ffffffff81739c7c>] call_softirq+0x1c/0x30
 [<ffffffff8101c435>] do_softirq+0xa5/0xe0
 [<ffffffff81073cd5>] irq_exit+0xd5/0xe0
 [<ffffffff8173a5b3>] do_IRQ+0x63/0xe0
 [<ffffffff8172f732>] common_interrupt+0x72/0x72
 <EOI>  [<ffffffff8172f150>] ? _raw_spin_unlock_irq+0x30/0x50
 [<ffffffff8172f154>] ? _raw_spin_unlock_irq+0x34/0x50
 [<ffffffff8172f150>] ? _raw_spin_unlock_irq+0x30/0x50
 [<ffffffff810a3ddc>] finish_task_switch+0x7c/0x120
 [<ffffffff810a3d9f>] ? finish_task_switch+0x3f/0x120
 [<ffffffff8172cd02>] __schedule+0x442/0xa00
 [<ffffffff8172d5f9>] schedule+0x29/0x70
 [<ffffffff81023abf>] cpu_idle+0x12f/0x140
 [<ffffffff8171a70e>] start_secondary+0x269/0x26b
---[ end trace d41e441560f83f6a ]---
Mapped at:
 [<ffffffff813881b9>] debug_dma_map_page+0xa9/0x150
 [<ffffffffa0074c83>] skge_xmit_frame+0x163/0x560 [skge]
 [<ffffffff815e8330>] dev_hard_start_xmit+0x260/0x6f0
 [<ffffffff8160bb0e>] sch_direct_xmit+0xfe/0x2a0
 [<ffffffff815e8a07>] dev_queue_xmit+0x247/0x970
…

Comment 1 poma 2013-02-27 04:35:04 UTC
(In reply to comment #0)
[…]
> 
> Actual results:
> The only side effect that has been observed is the reduced flow of data.
> Network interface behaves as 100Mb/s, therefore slower than it should be -
> 1000Mb/s.
> 
> Expected results:
> Speed: 1000Mb/s, that is in practice ~300Mb/s.
> 

OK. Network throughput is related to the kernel debugging facilities.
So, please disregard the speed issue.

Comment 2 poma 2013-08-21 21:48:13 UTC
Unfortunately, this proved to be a bug, after all.
The most beautiful part, after the patches have been applied, only now the module(skge) is completely unusable.
Maintainer claims that in his case now everything is working properly, but mine is just the opposite.
And such a broken module has now become part of the 3.11 series kernel.
The tragicomic part, I'm the one who reported this bug in the first place.
Hilarious. :)

A complete thread is here:
http://www.spinics.net/lists/netdev/msg245381.html


poma

Comment 3 poma 2013-08-22 14:52:59 UTC
Everything that has a beginning has an end.

poma

Comment 4 poma 2014-02-21 12:28:54 UTC
Thanks.


Note You need to log in before you can comment on or make changes to this bug.