<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/net/ethernet, branch v3.2.52</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>gianfar: Change default HW Tx queue scheduling mode</title>
<updated>2013-10-26T20:06:14+00:00</updated>
<author>
<name>Claudiu Manoil</name>
<email>claudiu.manoil@freescale.com</email>
</author>
<published>2012-09-23T22:39:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=c23e05d637c461d13e473bee595ae781622b5ebf'/>
<id>c23e05d637c461d13e473bee595ae781622b5ebf</id>
<content type='text'>
commit b98b8babd6e3370fadb7c6eaacb00eb2f6344a6c upstream.

This is primarily to address transmission timeout occurrences, when
multiple H/W Tx queues are being used concurrently. Because in
the priority scheduling mode the controller does not service the
Tx queues equally (but in ascending index order), Tx timeouts are
being triggered rightaway for a basic test with multiple simultaneous
connections like:
iperf -c &lt;server_ip&gt; -n 100M -P 8

resulting in kernel trace:
NETDEV WATCHDOG: eth1 (fsl-gianfar): transmit queue &lt;X&gt; timed out
------------[ cut here ]------------
WARNING: at net/sched/sch_generic.c:255
...
and controller reset during intense traffic, and possibly further
complications.

This patch changes the default H/W Tx scheduling setting (TXSCHED)
for multi-queue devices, from priority scheduling mode to a weighted
round robin mode with equal weights for all H/W Tx queues, and
addresses the issue above.

Signed-off-by: Claudiu Manoil &lt;claudiu.manoil@freescale.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit b98b8babd6e3370fadb7c6eaacb00eb2f6344a6c upstream.

This is primarily to address transmission timeout occurrences, when
multiple H/W Tx queues are being used concurrently. Because in
the priority scheduling mode the controller does not service the
Tx queues equally (but in ascending index order), Tx timeouts are
being triggered rightaway for a basic test with multiple simultaneous
connections like:
iperf -c &lt;server_ip&gt; -n 100M -P 8

resulting in kernel trace:
NETDEV WATCHDOG: eth1 (fsl-gianfar): transmit queue &lt;X&gt; timed out
------------[ cut here ]------------
WARNING: at net/sched/sch_generic.c:255
...
and controller reset during intense traffic, and possibly further
complications.

This patch changes the default H/W Tx scheduling setting (TXSCHED)
for multi-queue devices, from priority scheduling mode to a weighted
round robin mode with equal weights for all H/W Tx queues, and
addresses the issue above.

Signed-off-by: Claudiu Manoil &lt;claudiu.manoil@freescale.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>sfc: Fix efx_rx_buf_offset() for recycled pages</title>
<updated>2013-10-26T20:06:11+00:00</updated>
<author>
<name>Ben Hutchings</name>
<email>bhutchings@solarflare.com</email>
</author>
<published>2013-09-06T21:39:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=5f7f65dae41a2f2ba134b880d2b9a8bc459ba01b'/>
<id>5f7f65dae41a2f2ba134b880d2b9a8bc459ba01b</id>
<content type='text'>
This bug fix is only for stable branches older than 3.10.  The bug was
fixed upstream by commit 2768935a4660 ('sfc: reuse pages to avoid DMA
mapping/unmapping costs'), but that change is totally unsuitable for
stable.

Commit b590ace09d51 ('sfc: Fix efx_rx_buf_offset() in the presence of
swiotlb') added an explicit page_offset member to struct
efx_rx_buffer, which must be set consistently with the u.page and
dma_addr fields.  However, it failed to add the necessary assignment
in efx_resurrect_rx_buffer().  It also did not correct the calculation
of efx_rx_buffer::dma_addr in efx_resurrect_rx_buffer(), which assumes
that DMA-mapping a page will result in a page-aligned DMA address
(exactly what swiotlb violates).

Add the assignment of efx_rx_buffer::page_offset and change the
calculation of dma_addr to make use of it.

Signed-off-by: Ben Hutchings &lt;bhutchings@solarflare.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This bug fix is only for stable branches older than 3.10.  The bug was
fixed upstream by commit 2768935a4660 ('sfc: reuse pages to avoid DMA
mapping/unmapping costs'), but that change is totally unsuitable for
stable.

Commit b590ace09d51 ('sfc: Fix efx_rx_buf_offset() in the presence of
swiotlb') added an explicit page_offset member to struct
efx_rx_buffer, which must be set consistently with the u.page and
dma_addr fields.  However, it failed to add the necessary assignment
in efx_resurrect_rx_buffer().  It also did not correct the calculation
of efx_rx_buffer::dma_addr in efx_resurrect_rx_buffer(), which assumes
that DMA-mapping a page will result in a page-aligned DMA address
(exactly what swiotlb violates).

Add the assignment of efx_rx_buffer::page_offset and change the
calculation of dma_addr to make use of it.

Signed-off-by: Ben Hutchings &lt;bhutchings@solarflare.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ll_temac: Reset dma descriptors indexes on ndo_open</title>
<updated>2013-10-26T20:06:09+00:00</updated>
<author>
<name>Ricardo Ribalda</name>
<email>ricardo.ribalda@gmail.com</email>
</author>
<published>2013-10-01T06:17:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=a82dc4e1e4c628f23c14fc48ce72ae0b56a68db8'/>
<id>a82dc4e1e4c628f23c14fc48ce72ae0b56a68db8</id>
<content type='text'>
[ Upstream commit 7167cf0e8cd10287b7912b9ffcccd9616f382922 ]

The dma descriptors indexes are only initialized on the probe function.

If a packet is on the buffer when temac_stop is called, the dma
descriptors indexes can be left on a incorrect state where no other
package can be sent.

So an interface could be left in an usable state after ifdow/ifup.

This patch makes sure that the descriptors indexes are in a proper
status when the device is open.

Signed-off-by: Ricardo Ribalda Delgado &lt;ricardo.ribalda@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 7167cf0e8cd10287b7912b9ffcccd9616f382922 ]

The dma descriptors indexes are only initialized on the probe function.

If a packet is on the buffer when temac_stop is called, the dma
descriptors indexes can be left on a incorrect state where no other
package can be sent.

So an interface could be left in an usable state after ifdow/ifup.

This patch makes sure that the descriptors indexes are in a proper
status when the device is open.

Signed-off-by: Ricardo Ribalda Delgado &lt;ricardo.ribalda@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>via-rhine: fix VLAN priority field (PCP, IEEE 802.1p)</title>
<updated>2013-10-26T20:06:08+00:00</updated>
<author>
<name>Roger Luethi</name>
<email>rl@hellgate.ch</email>
</author>
<published>2013-09-21T12:24:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=10c25bb9fa4fe65ccf6492c8d8e77b2ce5b634f3'/>
<id>10c25bb9fa4fe65ccf6492c8d8e77b2ce5b634f3</id>
<content type='text'>
[ Upstream commit 207070f5221e2a901d56a49df9cde47d9b716cd7 ]

Outgoing packets sent by via-rhine have their VLAN PCP field off by one
(when hardware acceleration is enabled). The TX descriptor expects only VID
and PCP (without a CFI/DEI bit).

Peter Boström noticed and reported the bug.

Signed-off-by: Roger Luethi &lt;rl@hellgate.ch&gt;
Cc: Peter Boström &lt;peter.bostrom@netrounds.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 207070f5221e2a901d56a49df9cde47d9b716cd7 ]

Outgoing packets sent by via-rhine have their VLAN PCP field off by one
(when hardware acceleration is enabled). The TX descriptor expects only VID
and PCP (without a CFI/DEI bit).

Peter Boström noticed and reported the bug.

Signed-off-by: Roger Luethi &lt;rl@hellgate.ch&gt;
Cc: Peter Boström &lt;peter.bostrom@netrounds.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>8139cp: Add dma_mapping_error checking</title>
<updated>2013-10-26T20:05:56+00:00</updated>
<author>
<name>Neil Horman</name>
<email>nhorman@tuxdriver.com</email>
</author>
<published>2013-07-31T13:03:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=5cacde1a5f5e7c958dd1f2f74fd57fc3bf176784'/>
<id>5cacde1a5f5e7c958dd1f2f74fd57fc3bf176784</id>
<content type='text'>
[ Upstream commits cf3c4c03060b688cbc389ebc5065ebcce5653e96 and
  d06f5187469eee1b2932c02fd093d113cfc60d5e (the latter is a fixup
  from Dave Jones) ]

Self explanitory dma_mapping_error addition to the 8139 driver, based on this:
https://bugzilla.redhat.com/show_bug.cgi?id=947250

It showed several backtraces arising for dma_map_* usage without checking the
return code on the mapping.  Add the check and abort the rx/tx operation if its
failed.  Untested as I have no hardware and the reporter has wandered off, but
seems pretty straightforward.

Signed-off-by: Neil Horman &lt;nhorman@tuxdriver.com&gt;
CC: "David S. Miller" &lt;davem@davemloft.net&gt;
CC: Francois Romieu &lt;romieu@fr.zoreil.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commits cf3c4c03060b688cbc389ebc5065ebcce5653e96 and
  d06f5187469eee1b2932c02fd093d113cfc60d5e (the latter is a fixup
  from Dave Jones) ]

Self explanitory dma_mapping_error addition to the 8139 driver, based on this:
https://bugzilla.redhat.com/show_bug.cgi?id=947250

It showed several backtraces arising for dma_map_* usage without checking the
return code on the mapping.  Add the check and abort the rx/tx operation if its
failed.  Untested as I have no hardware and the reporter has wandered off, but
seems pretty straightforward.

Signed-off-by: Neil Horman &lt;nhorman@tuxdriver.com&gt;
CC: "David S. Miller" &lt;davem@davemloft.net&gt;
CC: Francois Romieu &lt;romieu@fr.zoreil.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ixgbe: Fix Tx Hang issue with lldpad on 82598EB</title>
<updated>2013-09-10T00:57:16+00:00</updated>
<author>
<name>Jacob Keller</name>
<email>jacob.e.keller@intel.com</email>
</author>
<published>2013-07-26T12:46:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=090f5ec2de3025a9d6d0f65ff0b535c5bac01fa8'/>
<id>090f5ec2de3025a9d6d0f65ff0b535c5bac01fa8</id>
<content type='text'>
commit 1eb9ac14c34a948bf1538bfb9034e8ab29099a64 upstream.

This patch fixes an issue with the 82598EB device, where lldpad is causing Tx
Hangs on the card as soon as it attempts to configure DCB for the device. The
adapter will continually Tx hang and reset in a loop.

Signed-off-by: Jacob Keller &lt;jacob.e.keller@intel.com&gt;
Tested-by: Phil Schmitt &lt;phillip.j.schmitt@intel.com&gt;
Tested-by: Jack Morgan &lt;jack.morgan@intel.com&gt;
Signed-off-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 1eb9ac14c34a948bf1538bfb9034e8ab29099a64 upstream.

This patch fixes an issue with the 82598EB device, where lldpad is causing Tx
Hangs on the card as soon as it attempts to configure DCB for the device. The
adapter will continually Tx hang and reset in a loop.

Signed-off-by: Jacob Keller &lt;jacob.e.keller@intel.com&gt;
Tested-by: Phil Schmitt &lt;phillip.j.schmitt@intel.com&gt;
Tested-by: Jack Morgan &lt;jack.morgan@intel.com&gt;
Signed-off-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>atl1e: unmap partially mapped skb on dma error and free skb</title>
<updated>2013-08-02T20:14:50+00:00</updated>
<author>
<name>Neil Horman</name>
<email>nhorman@tuxdriver.com</email>
</author>
<published>2013-07-16T14:49:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=729c5244dac355ca8c81f402739c218cc3212a10'/>
<id>729c5244dac355ca8c81f402739c218cc3212a10</id>
<content type='text'>
[ Upstream commit 584ec4355355ffac43571b02a314d43eb2f7fcbf ]

Ben Hutchings pointed out that my recent update to atl1e
in commit 352900b583b2852152a1e05ea0e8b579292e731e
("atl1e: fix dma mapping warnings") was missing a bit of code.

Specifically it reset the hardware tx ring to its origional state when
we hit a dma error, but didn't unmap any exiting mappings from the
operation.  This patch fixes that up.  It also remembers to free the
skb in the event that an error occurs, so we don't leak.  Untested, as
I don't have hardware.  I think its pretty straightforward, but please
review closely.

Signed-off-by: Neil Horman &lt;nhorman@tuxdriver.com&gt;
CC: Ben Hutchings &lt;bhutchings@solarflare.com&gt;
CC: Jay Cliburn &lt;jcliburn@gmail.com&gt;
CC: Chris Snook &lt;chris.snook@gmail.com&gt;
CC: "David S. Miller" &lt;davem@davemloft.net&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 584ec4355355ffac43571b02a314d43eb2f7fcbf ]

Ben Hutchings pointed out that my recent update to atl1e
in commit 352900b583b2852152a1e05ea0e8b579292e731e
("atl1e: fix dma mapping warnings") was missing a bit of code.

Specifically it reset the hardware tx ring to its origional state when
we hit a dma error, but didn't unmap any exiting mappings from the
operation.  This patch fixes that up.  It also remembers to free the
skb in the event that an error occurs, so we don't leak.  Untested, as
I don't have hardware.  I think its pretty straightforward, but please
review closely.

Signed-off-by: Neil Horman &lt;nhorman@tuxdriver.com&gt;
CC: Ben Hutchings &lt;bhutchings@solarflare.com&gt;
CC: Jay Cliburn &lt;jcliburn@gmail.com&gt;
CC: Chris Snook &lt;chris.snook@gmail.com&gt;
CC: "David S. Miller" &lt;davem@davemloft.net&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>atl1e: fix dma mapping warnings</title>
<updated>2013-08-02T20:14:50+00:00</updated>
<author>
<name>Neil Horman</name>
<email>nhorman@tuxdriver.com</email>
</author>
<published>2013-07-12T14:58:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=70513e78db3910edc5ba74ca5f31f6e619acac97'/>
<id>70513e78db3910edc5ba74ca5f31f6e619acac97</id>
<content type='text'>
[ Upstream commit 352900b583b2852152a1e05ea0e8b579292e731e ]

Recently had this backtrace reported:
WARNING: at lib/dma-debug.c:937 check_unmap+0x47d/0x930()
Hardware name: System Product Name
ATL1E 0000:02:00.0: DMA-API: device driver failed to check map error[device
address=0x00000000cbfd1000] [size=90 bytes] [mapped as single]
Modules linked in: xt_conntrack nf_conntrack ebtable_filter ebtables
ip6table_filter ip6_tables snd_hda_codec_hdmi snd_hda_codec_realtek iTCO_wdt
iTCO_vendor_support snd_hda_intel acpi_cpufreq mperf coretemp btrfs zlib_deflate
snd_hda_codec snd_hwdep microcode raid6_pq libcrc32c snd_seq usblp serio_raw xor
snd_seq_device joydev snd_pcm snd_page_alloc snd_timer snd lpc_ich i2c_i801
soundcore mfd_core atl1e asus_atk0110 ata_generic pata_acpi radeon i2c_algo_bit
drm_kms_helper ttm drm i2c_core pata_marvell uinput
Pid: 314, comm: systemd-journal Not tainted 3.9.0-0.rc6.git2.3.fc19.x86_64 #1
Call Trace:
 &lt;IRQ&gt;  [&lt;ffffffff81069106&gt;] warn_slowpath_common+0x66/0x80
 [&lt;ffffffff8106916c&gt;] warn_slowpath_fmt+0x4c/0x50
 [&lt;ffffffff8138151d&gt;] check_unmap+0x47d/0x930
 [&lt;ffffffff810ad048&gt;] ? sched_clock_cpu+0xa8/0x100
 [&lt;ffffffff81381a2f&gt;] debug_dma_unmap_page+0x5f/0x70
 [&lt;ffffffff8137ce30&gt;] ? unmap_single+0x20/0x30
 [&lt;ffffffffa01569a1&gt;] atl1e_intr+0x3a1/0x5b0 [atl1e]
 [&lt;ffffffff810d53fd&gt;] ? trace_hardirqs_off+0xd/0x10
 [&lt;ffffffff81119636&gt;] handle_irq_event_percpu+0x56/0x390
 [&lt;ffffffff811199ad&gt;] handle_irq_event+0x3d/0x60
 [&lt;ffffffff8111cb6a&gt;] handle_fasteoi_irq+0x5a/0x100
 [&lt;ffffffff8101c36f&gt;] handle_irq+0xbf/0x150
 [&lt;ffffffff811dcb2f&gt;] ? file_sb_list_del+0x3f/0x50
 [&lt;ffffffff81073b10&gt;] ? irq_enter+0x50/0xa0
 [&lt;ffffffff8172738d&gt;] do_IRQ+0x4d/0xc0
 [&lt;ffffffff811dcb2f&gt;] ? file_sb_list_del+0x3f/0x50
 [&lt;ffffffff8171c6b2&gt;] common_interrupt+0x72/0x72
 &lt;EOI&gt;  [&lt;ffffffff810db5b2&gt;] ? lock_release+0xc2/0x310
 [&lt;ffffffff8109ea04&gt;] lg_local_unlock_cpu+0x24/0x50
 [&lt;ffffffff811dcb2f&gt;] file_sb_list_del+0x3f/0x50
 [&lt;ffffffff811dcb6d&gt;] fput+0x2d/0xc0
 [&lt;ffffffff811d8ea1&gt;] filp_close+0x61/0x90
 [&lt;ffffffff811fae4d&gt;] __close_fd+0x8d/0x150
 [&lt;ffffffff811d8ef0&gt;] sys_close+0x20/0x50
 [&lt;ffffffff81725699&gt;] system_call_fastpath+0x16/0x1b

The usual straighforward failure to check for dma_mapping_error after a map
operation is completed.

This patch should fix it, the reporter wandered off after filing this bz:
https://bugzilla.redhat.com/show_bug.cgi?id=954170

and I don't have hardware to test, but the fix is pretty straightforward, so I
figured I'd post it for review.

Signed-off-by: Neil Horman &lt;nhorman@tuxdriver.com&gt;
CC: Jay Cliburn &lt;jcliburn@gmail.com&gt;
CC: Chris Snook &lt;chris.snook@gmail.com&gt;
CC: "David S. Miller" &lt;davem@davemloft.net&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 352900b583b2852152a1e05ea0e8b579292e731e ]

Recently had this backtrace reported:
WARNING: at lib/dma-debug.c:937 check_unmap+0x47d/0x930()
Hardware name: System Product Name
ATL1E 0000:02:00.0: DMA-API: device driver failed to check map error[device
address=0x00000000cbfd1000] [size=90 bytes] [mapped as single]
Modules linked in: xt_conntrack nf_conntrack ebtable_filter ebtables
ip6table_filter ip6_tables snd_hda_codec_hdmi snd_hda_codec_realtek iTCO_wdt
iTCO_vendor_support snd_hda_intel acpi_cpufreq mperf coretemp btrfs zlib_deflate
snd_hda_codec snd_hwdep microcode raid6_pq libcrc32c snd_seq usblp serio_raw xor
snd_seq_device joydev snd_pcm snd_page_alloc snd_timer snd lpc_ich i2c_i801
soundcore mfd_core atl1e asus_atk0110 ata_generic pata_acpi radeon i2c_algo_bit
drm_kms_helper ttm drm i2c_core pata_marvell uinput
Pid: 314, comm: systemd-journal Not tainted 3.9.0-0.rc6.git2.3.fc19.x86_64 #1
Call Trace:
 &lt;IRQ&gt;  [&lt;ffffffff81069106&gt;] warn_slowpath_common+0x66/0x80
 [&lt;ffffffff8106916c&gt;] warn_slowpath_fmt+0x4c/0x50
 [&lt;ffffffff8138151d&gt;] check_unmap+0x47d/0x930
 [&lt;ffffffff810ad048&gt;] ? sched_clock_cpu+0xa8/0x100
 [&lt;ffffffff81381a2f&gt;] debug_dma_unmap_page+0x5f/0x70
 [&lt;ffffffff8137ce30&gt;] ? unmap_single+0x20/0x30
 [&lt;ffffffffa01569a1&gt;] atl1e_intr+0x3a1/0x5b0 [atl1e]
 [&lt;ffffffff810d53fd&gt;] ? trace_hardirqs_off+0xd/0x10
 [&lt;ffffffff81119636&gt;] handle_irq_event_percpu+0x56/0x390
 [&lt;ffffffff811199ad&gt;] handle_irq_event+0x3d/0x60
 [&lt;ffffffff8111cb6a&gt;] handle_fasteoi_irq+0x5a/0x100
 [&lt;ffffffff8101c36f&gt;] handle_irq+0xbf/0x150
 [&lt;ffffffff811dcb2f&gt;] ? file_sb_list_del+0x3f/0x50
 [&lt;ffffffff81073b10&gt;] ? irq_enter+0x50/0xa0
 [&lt;ffffffff8172738d&gt;] do_IRQ+0x4d/0xc0
 [&lt;ffffffff811dcb2f&gt;] ? file_sb_list_del+0x3f/0x50
 [&lt;ffffffff8171c6b2&gt;] common_interrupt+0x72/0x72
 &lt;EOI&gt;  [&lt;ffffffff810db5b2&gt;] ? lock_release+0xc2/0x310
 [&lt;ffffffff8109ea04&gt;] lg_local_unlock_cpu+0x24/0x50
 [&lt;ffffffff811dcb2f&gt;] file_sb_list_del+0x3f/0x50
 [&lt;ffffffff811dcb6d&gt;] fput+0x2d/0xc0
 [&lt;ffffffff811d8ea1&gt;] filp_close+0x61/0x90
 [&lt;ffffffff811fae4d&gt;] __close_fd+0x8d/0x150
 [&lt;ffffffff811d8ef0&gt;] sys_close+0x20/0x50
 [&lt;ffffffff81725699&gt;] system_call_fastpath+0x16/0x1b

The usual straighforward failure to check for dma_mapping_error after a map
operation is completed.

This patch should fix it, the reporter wandered off after filing this bz:
https://bugzilla.redhat.com/show_bug.cgi?id=954170

and I don't have hardware to test, but the fix is pretty straightforward, so I
figured I'd post it for review.

Signed-off-by: Neil Horman &lt;nhorman@tuxdriver.com&gt;
CC: Jay Cliburn &lt;jcliburn@gmail.com&gt;
CC: Chris Snook &lt;chris.snook@gmail.com&gt;
CC: "David S. Miller" &lt;davem@davemloft.net&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>sunvnet: vnet_port_remove must call unregister_netdev</title>
<updated>2013-08-02T20:14:48+00:00</updated>
<author>
<name>Dave Kleikamp</name>
<email>dave.kleikamp@oracle.com</email>
</author>
<published>2013-07-01T21:49:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=bb99c9900545e3323c61aa912034b8e955e1f344'/>
<id>bb99c9900545e3323c61aa912034b8e955e1f344</id>
<content type='text'>
[ Upstream commit aabb9875d02559ab9b928cd6f259a5cc4c21a589 ]

The missing call to unregister_netdev() leaves the interface active
after the driver is unloaded by rmmod.

Signed-off-by: Dave Kleikamp &lt;dave.kleikamp@oracle.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit aabb9875d02559ab9b928cd6f259a5cc4c21a589 ]

The missing call to unregister_netdev() leaves the interface active
after the driver is unloaded by rmmod.

Signed-off-by: Dave Kleikamp &lt;dave.kleikamp@oracle.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>sh_eth: fix unhandled RFE interrupt</title>
<updated>2013-08-02T20:14:46+00:00</updated>
<author>
<name>Sergei Shtylyov</name>
<email>sergei.shtylyov@cogentembedded.com</email>
</author>
<published>2013-06-20T21:12:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=694c73ea108919b72b689a20c218c4249f0fbffb'/>
<id>694c73ea108919b72b689a20c218c4249f0fbffb</id>
<content type='text'>
[ Upstream commit ca8c35852138ee0585eaffe6b9f10a5261ea7771 ]

EESR.RFE (receive FIFO overflow) interrupt is enabled by the driver on all SoCs
and sh_eth_error() handles it but it's not present in any initializer/assignment
of the 'eesr_err_check' field of 'struct sh_eth_cpu_data'. This leads to that
interrupt not being handled and cleared, and finally to disabling IRQ and the
driver being non-functional.

Modify DEFAULT_EESR_ERR_CHECK macro and all explicit initializers of the above
mentioned field to contain the EESR.RFE bit. Remove useless backslashes from the
initializers, while at it.

Signed-off-by: Sergei Shtylyov &lt;sergei.shtylyov@cogentembedded.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit ca8c35852138ee0585eaffe6b9f10a5261ea7771 ]

EESR.RFE (receive FIFO overflow) interrupt is enabled by the driver on all SoCs
and sh_eth_error() handles it but it's not present in any initializer/assignment
of the 'eesr_err_check' field of 'struct sh_eth_cpu_data'. This leads to that
interrupt not being handled and cleared, and finally to disabling IRQ and the
driver being non-functional.

Modify DEFAULT_EESR_ERR_CHECK macro and all explicit initializers of the above
mentioned field to contain the EESR.RFE bit. Remove useless backslashes from the
initializers, while at it.

Signed-off-by: Sergei Shtylyov &lt;sergei.shtylyov@cogentembedded.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
</feed>
