Bug 914994

Summary:	[skge] WARNING: at lib/dma-debug.c:933 check_unmap+0x407/0x8a0()
Product:	[Fedora] Fedora	Reporter:	poma <pomidorabelisima>
Component:	kernel	Assignee:	Kernel Maintainer List <kernel-maint>
Status:	CLOSED RAWHIDE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	crope, gansalmon, itamar, jonathan, kernel-maint, madhu.chinakonda
Target Milestone:	---	Keywords:	Reopened
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-08-22 14:52:59 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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.