<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/drivers/net, branch v3.17-rc5</title>
<subtitle>Linux kernel source tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/'/>
<entry>
<title>Merge tag 'master-2014-09-04' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless</title>
<updated>2014-09-07T23:11:10+00:00</updated>
<author>
<name>David S. Miller</name>
<email>davem@davemloft.net</email>
</author>
<published>2014-09-07T23:11:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=45ce829dd010668c3839a61b25843590eb4677dc'/>
<id>45ce829dd010668c3839a61b25843590eb4677dc</id>
<content type='text'>
John W. Linville says:

====================
pull request: wireless 2014-09-05

Please pull this batch of fixes intended for the 3.17 stream...

For the mac80211 bits, Johannes says:

"Here are a few fixes for mac80211. One has been discussed for a while
and adds a terminating NUL-byte to the alpha2 sent to userspace, which
shouldn't be necessary but since many places treat it as a string we
couldn't move to just sending two bytes.

In addition to that, we have two VLAN fixes from Felix, a mesh fix, a
fix for the recently introduced RX aggregation offload, a revert for
a broken patch (that luckily didn't really cause any harm) and a small
fix for alignment in debugfs."

For the iwlwifi bits, Emmanuel says:

"I revert a patch that disabled CTS to self in dvm because users
reported issues. The revert is CCed to stable since the offending
patch was sent to stable too. I also bump the firmware API versions
since a new firmware is coming up. On top of that, Marcel fixes a
bug I introduced while fixing a bug in our Kconfig file."

Please let me know if there are problems!
====================

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
John W. Linville says:

====================
pull request: wireless 2014-09-05

Please pull this batch of fixes intended for the 3.17 stream...

For the mac80211 bits, Johannes says:

"Here are a few fixes for mac80211. One has been discussed for a while
and adds a terminating NUL-byte to the alpha2 sent to userspace, which
shouldn't be necessary but since many places treat it as a string we
couldn't move to just sending two bytes.

In addition to that, we have two VLAN fixes from Felix, a mesh fix, a
fix for the recently introduced RX aggregation offload, a revert for
a broken patch (that luckily didn't really cause any harm) and a small
fix for alignment in debugfs."

For the iwlwifi bits, Emmanuel says:

"I revert a patch that disabled CTS to self in dvm because users
reported issues. The revert is CCed to stable since the offending
patch was sent to stable too. I also bump the firmware API versions
since a new firmware is coming up. On top of that, Marcel fixes a
bug I introduced while fixing a bug in our Kconfig file."

Please let me know if there are problems!
====================

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>amd-xgbe: Enable interrupts for all management counters</title>
<updated>2014-09-06T05:37:30+00:00</updated>
<author>
<name>Lendacky, Thomas</name>
<email>Thomas.Lendacky@amd.com</email>
</author>
<published>2014-09-05T23:02:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=a3ba7c989d7c80b34401c58269c5903a1da8412a'/>
<id>a3ba7c989d7c80b34401c58269c5903a1da8412a</id>
<content type='text'>
As the management counters reach a threshold they will generate an
interrupt so the value can be saved and the counter reset. The
current code does not enable this interrupt on all counters. This
can result in inaccurate statistics.

Update the code to enable all the counters to generate an interrupt
when its threshold is exceeded.

Signed-off-by: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
As the management counters reach a threshold they will generate an
interrupt so the value can be saved and the counter reset. The
current code does not enable this interrupt on all counters. This
can result in inaccurate statistics.

Update the code to enable all the counters to generate an interrupt
when its threshold is exceeded.

Signed-off-by: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>amd-xgbe: Treat certain counter registers as 64 bit</title>
<updated>2014-09-06T05:37:30+00:00</updated>
<author>
<name>Lendacky, Thomas</name>
<email>Thomas.Lendacky@amd.com</email>
</author>
<published>2014-09-05T23:02:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=6026510896adfa0db5ed76a6d6d1cd1602b29208'/>
<id>6026510896adfa0db5ed76a6d6d1cd1602b29208</id>
<content type='text'>
Even if the management counters are configured to be 32 bit register
values, the [rt]xoctetcount_gb and [rt]xoctetcount_g counters are
always 64 bit counter registers.  Since they are not being treated as
64 bit values, these statistics are being reported incorrectly (ifconfig,
ethtool, etc.).

Update the routines used to read the registers to access the "hi"
register (an offset of 4 from the "lo" register) to create a 64 bit
value for these 64 bit counters.

Signed-off-by: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Even if the management counters are configured to be 32 bit register
values, the [rt]xoctetcount_gb and [rt]xoctetcount_g counters are
always 64 bit counter registers.  Since they are not being treated as
64 bit values, these statistics are being reported incorrectly (ifconfig,
ethtool, etc.).

Update the routines used to read the registers to access the "hi"
register (an offset of 4 from the "lo" register) to create a 64 bit
value for these 64 bit counters.

Signed-off-by: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>greth: moved TX ring cleaning to NAPI rx poll func</title>
<updated>2014-09-06T04:57:09+00:00</updated>
<author>
<name>Daniel Hellstrom</name>
<email>daniel@gaisler.com</email>
</author>
<published>2014-09-05T11:13:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=e1743a16a043f3d6b707730e46ba33ca931fb553'/>
<id>e1743a16a043f3d6b707730e46ba33ca931fb553</id>
<content type='text'>
This patch does not affect the 10/100 GRETH MAC.

Before all GBit GRETH TX descriptor ring cleaning was done in
start_xmit(), when descriptor list became full it activated
TX interrupt to start the NAPI rx poll function to do TX ring
cleaning.

With this patch the TX descriptor ring is always cleaned from
the NAPI rx poll function, triggered via TX or RX interrupt.
Otherwise we could end up in TX frames being sent but not
reported to the stack being sent. On the 10/100 GRETH this
is not an issue since the SKB is copied&amp;aligned into private
buffers so that the SKB can be freed directly on start_xmit()

Signed-off-by: Daniel Hellstrom &lt;daniel@gaisler.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch does not affect the 10/100 GRETH MAC.

Before all GBit GRETH TX descriptor ring cleaning was done in
start_xmit(), when descriptor list became full it activated
TX interrupt to start the NAPI rx poll function to do TX ring
cleaning.

With this patch the TX descriptor ring is always cleaned from
the NAPI rx poll function, triggered via TX or RX interrupt.
Otherwise we could end up in TX frames being sent but not
reported to the stack being sent. On the 10/100 GRETH this
is not an issue since the SKB is copied&amp;aligned into private
buffers so that the SKB can be freed directly on start_xmit()

Signed-off-by: Daniel Hellstrom &lt;daniel@gaisler.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>cnic : Cleanup CONFIG_IPV6 &amp; VLAN check</title>
<updated>2014-09-06T03:47:14+00:00</updated>
<author>
<name>Anish Bhatt</name>
<email>anish@chelsio.com</email>
</author>
<published>2014-09-05T00:12:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=c99d667e852766afc755fa4430be64bb94e5ea1c'/>
<id>c99d667e852766afc755fa4430be64bb94e5ea1c</id>
<content type='text'>
The cnic module needs to ensure that if ipv6 support is compiled as a module,
then the cnic module cannot be compiled as built-in as it depends on ipv6.
Made this check cleaner via Kconfig

Use simpler IS_ENABLED for CONFIG_VLAN_8021Q check

Signed-off-by: Anish Bhatt &lt;anish@chelsio.com&gt;
Acked-by: Michael Chan &lt;mchan@broadcom.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The cnic module needs to ensure that if ipv6 support is compiled as a module,
then the cnic module cannot be compiled as built-in as it depends on ipv6.
Made this check cleaner via Kconfig

Use simpler IS_ENABLED for CONFIG_VLAN_8021Q check

Signed-off-by: Anish Bhatt &lt;anish@chelsio.com&gt;
Acked-by: Michael Chan &lt;mchan@broadcom.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>bnx2x: Fix link problems for 1G SFP RJ45 module</title>
<updated>2014-09-06T00:28:37+00:00</updated>
<author>
<name>Yaniv Rosner</name>
<email>Yaniv.Rosner@qlogic.com</email>
</author>
<published>2014-09-04T10:26:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=6e9e5644378bdeebe09db9181534a03361701f4e'/>
<id>6e9e5644378bdeebe09db9181534a03361701f4e</id>
<content type='text'>
When 1G SFP RJ45 module is detected, driver must reset the Tx laser
in order to prevent link issues. As part of change, the link_attr_sync
was relocated from vars to params.

Signed-off-by: Yaniv Rosner &lt;Yaniv.Rosner@qlogic.com&gt;
Signed-off-by: Yuval Mintz &lt;Yuval.Mintz@qlogic.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When 1G SFP RJ45 module is detected, driver must reset the Tx laser
in order to prevent link issues. As part of change, the link_attr_sync
was relocated from vars to params.

Signed-off-by: Yaniv Rosner &lt;Yaniv.Rosner@qlogic.com&gt;
Signed-off-by: Yuval Mintz &lt;Yuval.Mintz@qlogic.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>3c59x: avoid panic in boomerang_start_xmit when finding page address:</title>
<updated>2014-09-06T00:24:02+00:00</updated>
<author>
<name>Neil Horman</name>
<email>nhorman@tuxdriver.com</email>
</author>
<published>2014-09-04T10:13:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=98ea232cf63961fad734cc8c5e07e8915ec73073'/>
<id>98ea232cf63961fad734cc8c5e07e8915ec73073</id>
<content type='text'>
This bug was reported on a very old kernel (RHEL6, 2.6.32-491.el6):

BUG: unable to handle kernel paging request at 00800000
IP: [&lt;c04107b5&gt;] nommu_map_page+0x15/0x110
*pdpt = 000000003454f001 *pde = 000000003f03d067
Oops: 0000 [#1] SMP
last sysfs file: /sys/devices/system/cpu/online
Modules linked in: nfsd lockd nfs_acl auth_rpcgss sunrpc exportfs p4_clockmod
ipv6 ppdev parport_pc parport microcode iTCO_wdt iTCO_vendor_support 3c59x mii
dcdbas serio_raw snd_intel8x0 snd_ac97_codec ac97_bus snd_seq snd_seq_device
snd_pcm snd_timer snd soundcore snd_page_alloc i2c_i801 sg lpc_ich mfd_core ext4
jbd2 mbcache sr_mod cdrom sd_mod crc_t10dif pata_acpi ata_generic ata_piix
radeon ttm drm_kms_helper drm i2c_algo_bit i2c_core dm_mirror dm_region_hash
dm_log dm_mod [last unloaded: mperf]

Pid: 4219, comm: nfsd Not tainted 2.6.32-491.el6.i686 #1 Dell Computer
Corporation OptiPlex GX240               /OptiPlex GX240
EIP: 0060:[&lt;c04107b5&gt;] EFLAGS: 00010246 CPU: 0
EIP is at nommu_map_page+0x15/0x110
EAX: 00000000 EBX: c0a83480 ECX: 00000000 EDX: 00800000
ESI: 00000000 EDI: f70e7860 EBP: e2d09b54 ESP: e2d09b24
 DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
Process nfsd (pid: 4219, ti=e2d08000 task=e2ceaaa0 task.ti=e2d08000)
Stack:
 00000056 00000000 0000000e c65efd38 00000020 00000296 00000206 00000206
&lt;0&gt; c050c850 c0a83480 e2cef154 00000001 e2d09ba8 f8fcd585 00000510 00000001
&lt;0&gt; 00000000 00000000 f5172200 f8fdac00 0039ef8c f5277020 f70e7860 00000510
Call Trace:
 [&lt;c050c850&gt;] ? page_address+0xd0/0xe0
 [&lt;f8fcd585&gt;] ? boomerang_start_xmit+0x3b5/0x520 [3c59x]
 [&lt;c07b2975&gt;] ? dev_hard_start_xmit+0xe5/0x400
 [&lt;f9182b00&gt;] ? ip6_output_finish+0x0/0xf0 [ipv6]
 [&lt;c07ca053&gt;] ? sch_direct_xmit+0x113/0x180
 [&lt;c07d5588&gt;] ? nf_hook_slow+0x68/0x120
 [&lt;c07b2ea5&gt;] ? dev_queue_xmit+0x1b5/0x290
 [&lt;f9182b6d&gt;] ? ip6_output_finish+0x6d/0xf0 [ipv6]
 [&lt;f9184cb8&gt;] ? ip6_xmit+0x3e8/0x490 [ipv6]
 [&lt;f91ab9f9&gt;] ? inet6_csk_xmit+0x289/0x2f0 [ipv6]
 [&lt;c07f6451&gt;] ? tcp_transmit_skb+0x431/0x7f0
 [&lt;c07a403f&gt;] ? __alloc_skb+0x4f/0x140
 [&lt;c07f85a2&gt;] ? tcp_write_xmit+0x1c2/0xa50
 [&lt;c07f90b1&gt;] ? __tcp_push_pending_frames+0x31/0xe0
 [&lt;c07ea47a&gt;] ? tcp_sendpage+0x44a/0x4b0
 [&lt;c07ea030&gt;] ? tcp_sendpage+0x0/0x4b0
 [&lt;c079be1e&gt;] ? kernel_sendpage+0x4e/0x90
 [&lt;f8457bb9&gt;] ? svc_send_common+0xc9/0x120 [sunrpc]
 [&lt;f8457c85&gt;] ? svc_sendto+0x75/0x1f0 [sunrpc]
 [&lt;c060d0d9&gt;] ? _atomic_dec_and_lock+0x59/0x90
 [&lt;f87d55d0&gt;] ? nfs3svc_encode_readres+0x0/0xc0 [nfsd]
 [&lt;f845876d&gt;] ? svc_authorise+0x2d/0x40 [sunrpc]
 [&lt;f87d4410&gt;] ? nfs3svc_release_fhandle+0x0/0x10 [nfsd]
 [&lt;f8455721&gt;] ? svc_process_common+0xf1/0x5a0 [sunrpc]
 [&lt;f8457e86&gt;] ? svc_tcp_sendto+0x36/0xa0 [sunrpc]
 [&lt;f8461778&gt;] ? svc_send+0x98/0xd0 [sunrpc]
 [&lt;f87c698c&gt;] ? nfsd+0xac/0x140 [nfsd]
 [&lt;c04470e0&gt;] ? complete+0x40/0x60
 [&lt;f87c68e0&gt;] ? nfsd+0x0/0x140 [nfsd]
 [&lt;c04802ac&gt;] ? kthread+0x7c/0xa0
 [&lt;c0480230&gt;] ? kthread+0x0/0xa0
 [&lt;c0409f9f&gt;] ? kernel_thread_helper+0x7/0x10
Code: 8d b6 00 00 00 00 eb f8 8d b4 26 00 00 00 00 8d bc 27 00 00 00 00 55 89 e5
83 ec 30 89 75 f8 31 f6 89 7d fc 89 c7 89 c8 89 5d f4 &lt;8b&gt; 1a 8b 4d 08 c1 eb 19
c1 e3 04 8b 9b c0 29 c7 c0 83 e3 fc 29

But the problem seems to still exist upstream.  It seems on 32 bit kernels
page_address() can reutrn a NULL value in some circumstances, and the
pci_map_single api isn't prepared to handle that (on this system it results in a
bogus pointer deference in nommu_map_page.

The fix is pretty easy, if we convert the 3c59x driver to use the more
convieient skb_frag_dma_map api we don't need to find the virtual address of the
page at all, and page gets mapped to the hardware properly.  Verified to fix the
problem as described by the reporter.

Applies to the net tree

Change Notes:

v2) Converted PCI_DMA_TODEVICE to DMA_TO_DEVICE.  Thanks Dave!

v3) Actually Run git commit after making changes to v2 :)

Signed-off-by: Neil Horman &lt;nhorman@tuxdriver.com&gt;
CC: klassert@mathematik.tu-chemnitz.de
CC: "David S. Miller" &lt;davem@davemloft.net&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This bug was reported on a very old kernel (RHEL6, 2.6.32-491.el6):

BUG: unable to handle kernel paging request at 00800000
IP: [&lt;c04107b5&gt;] nommu_map_page+0x15/0x110
*pdpt = 000000003454f001 *pde = 000000003f03d067
Oops: 0000 [#1] SMP
last sysfs file: /sys/devices/system/cpu/online
Modules linked in: nfsd lockd nfs_acl auth_rpcgss sunrpc exportfs p4_clockmod
ipv6 ppdev parport_pc parport microcode iTCO_wdt iTCO_vendor_support 3c59x mii
dcdbas serio_raw snd_intel8x0 snd_ac97_codec ac97_bus snd_seq snd_seq_device
snd_pcm snd_timer snd soundcore snd_page_alloc i2c_i801 sg lpc_ich mfd_core ext4
jbd2 mbcache sr_mod cdrom sd_mod crc_t10dif pata_acpi ata_generic ata_piix
radeon ttm drm_kms_helper drm i2c_algo_bit i2c_core dm_mirror dm_region_hash
dm_log dm_mod [last unloaded: mperf]

Pid: 4219, comm: nfsd Not tainted 2.6.32-491.el6.i686 #1 Dell Computer
Corporation OptiPlex GX240               /OptiPlex GX240
EIP: 0060:[&lt;c04107b5&gt;] EFLAGS: 00010246 CPU: 0
EIP is at nommu_map_page+0x15/0x110
EAX: 00000000 EBX: c0a83480 ECX: 00000000 EDX: 00800000
ESI: 00000000 EDI: f70e7860 EBP: e2d09b54 ESP: e2d09b24
 DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
Process nfsd (pid: 4219, ti=e2d08000 task=e2ceaaa0 task.ti=e2d08000)
Stack:
 00000056 00000000 0000000e c65efd38 00000020 00000296 00000206 00000206
&lt;0&gt; c050c850 c0a83480 e2cef154 00000001 e2d09ba8 f8fcd585 00000510 00000001
&lt;0&gt; 00000000 00000000 f5172200 f8fdac00 0039ef8c f5277020 f70e7860 00000510
Call Trace:
 [&lt;c050c850&gt;] ? page_address+0xd0/0xe0
 [&lt;f8fcd585&gt;] ? boomerang_start_xmit+0x3b5/0x520 [3c59x]
 [&lt;c07b2975&gt;] ? dev_hard_start_xmit+0xe5/0x400
 [&lt;f9182b00&gt;] ? ip6_output_finish+0x0/0xf0 [ipv6]
 [&lt;c07ca053&gt;] ? sch_direct_xmit+0x113/0x180
 [&lt;c07d5588&gt;] ? nf_hook_slow+0x68/0x120
 [&lt;c07b2ea5&gt;] ? dev_queue_xmit+0x1b5/0x290
 [&lt;f9182b6d&gt;] ? ip6_output_finish+0x6d/0xf0 [ipv6]
 [&lt;f9184cb8&gt;] ? ip6_xmit+0x3e8/0x490 [ipv6]
 [&lt;f91ab9f9&gt;] ? inet6_csk_xmit+0x289/0x2f0 [ipv6]
 [&lt;c07f6451&gt;] ? tcp_transmit_skb+0x431/0x7f0
 [&lt;c07a403f&gt;] ? __alloc_skb+0x4f/0x140
 [&lt;c07f85a2&gt;] ? tcp_write_xmit+0x1c2/0xa50
 [&lt;c07f90b1&gt;] ? __tcp_push_pending_frames+0x31/0xe0
 [&lt;c07ea47a&gt;] ? tcp_sendpage+0x44a/0x4b0
 [&lt;c07ea030&gt;] ? tcp_sendpage+0x0/0x4b0
 [&lt;c079be1e&gt;] ? kernel_sendpage+0x4e/0x90
 [&lt;f8457bb9&gt;] ? svc_send_common+0xc9/0x120 [sunrpc]
 [&lt;f8457c85&gt;] ? svc_sendto+0x75/0x1f0 [sunrpc]
 [&lt;c060d0d9&gt;] ? _atomic_dec_and_lock+0x59/0x90
 [&lt;f87d55d0&gt;] ? nfs3svc_encode_readres+0x0/0xc0 [nfsd]
 [&lt;f845876d&gt;] ? svc_authorise+0x2d/0x40 [sunrpc]
 [&lt;f87d4410&gt;] ? nfs3svc_release_fhandle+0x0/0x10 [nfsd]
 [&lt;f8455721&gt;] ? svc_process_common+0xf1/0x5a0 [sunrpc]
 [&lt;f8457e86&gt;] ? svc_tcp_sendto+0x36/0xa0 [sunrpc]
 [&lt;f8461778&gt;] ? svc_send+0x98/0xd0 [sunrpc]
 [&lt;f87c698c&gt;] ? nfsd+0xac/0x140 [nfsd]
 [&lt;c04470e0&gt;] ? complete+0x40/0x60
 [&lt;f87c68e0&gt;] ? nfsd+0x0/0x140 [nfsd]
 [&lt;c04802ac&gt;] ? kthread+0x7c/0xa0
 [&lt;c0480230&gt;] ? kthread+0x0/0xa0
 [&lt;c0409f9f&gt;] ? kernel_thread_helper+0x7/0x10
Code: 8d b6 00 00 00 00 eb f8 8d b4 26 00 00 00 00 8d bc 27 00 00 00 00 55 89 e5
83 ec 30 89 75 f8 31 f6 89 7d fc 89 c7 89 c8 89 5d f4 &lt;8b&gt; 1a 8b 4d 08 c1 eb 19
c1 e3 04 8b 9b c0 29 c7 c0 83 e3 fc 29

But the problem seems to still exist upstream.  It seems on 32 bit kernels
page_address() can reutrn a NULL value in some circumstances, and the
pci_map_single api isn't prepared to handle that (on this system it results in a
bogus pointer deference in nommu_map_page.

The fix is pretty easy, if we convert the 3c59x driver to use the more
convieient skb_frag_dma_map api we don't need to find the virtual address of the
page at all, and page gets mapped to the hardware properly.  Verified to fix the
problem as described by the reporter.

Applies to the net tree

Change Notes:

v2) Converted PCI_DMA_TODEVICE to DMA_TO_DEVICE.  Thanks Dave!

v3) Actually Run git commit after making changes to v2 :)

Signed-off-by: Neil Horman &lt;nhorman@tuxdriver.com&gt;
CC: klassert@mathematik.tu-chemnitz.de
CC: "David S. Miller" &lt;davem@davemloft.net&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drivers/net/fddi/skfp/h/skfbi.h: Remove useless PCI_BASE_2ND macros</title>
<updated>2014-09-05T21:51:09+00:00</updated>
<author>
<name>Chen Gang</name>
<email>gang.chen.5i5j@gmail.com</email>
</author>
<published>2014-09-03T15:26:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=4357450af3422219d3f77bd54f7b9a8a40f193c9'/>
<id>4357450af3422219d3f77bd54f7b9a8a40f193c9</id>
<content type='text'>
They are use less, and may generate compiling warnings, so remove them
(microblaze, arc, arm64, and unicore32 have already defined PCI_IOBASE).

The related warnings (with allmodconfig under microblaze):

  CC [M]  drivers/net/fddi/skfp/skfddi.o
  In file included from drivers/net/fddi/skfp/skfddi.c:95:0:
  drivers/net/fddi/skfp/h/skfbi.h:151:0: warning: "PCI_IOBASE" redefined
   #define PCI_IOBASE 0xffffff00L  /* Bit 31..8:  I/O Base address */
   ^
  In file included from include/linux/io.h:22:0,
                   from include/linux/pci.h:31,
                   from drivers/net/fddi/skfp/skfddi.c:82:
  ./arch/microblaze/include/asm/io.h:33:0: note: this is the location of the previous definition
   #define PCI_IOBASE ((void __iomem *)_IO_BASE)
   ^

Signed-off-by: Chen Gang &lt;gang.chen.5i5j@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
They are use less, and may generate compiling warnings, so remove them
(microblaze, arc, arm64, and unicore32 have already defined PCI_IOBASE).

The related warnings (with allmodconfig under microblaze):

  CC [M]  drivers/net/fddi/skfp/skfddi.o
  In file included from drivers/net/fddi/skfp/skfddi.c:95:0:
  drivers/net/fddi/skfp/h/skfbi.h:151:0: warning: "PCI_IOBASE" redefined
   #define PCI_IOBASE 0xffffff00L  /* Bit 31..8:  I/O Base address */
   ^
  In file included from include/linux/io.h:22:0,
                   from include/linux/pci.h:31,
                   from drivers/net/fddi/skfp/skfddi.c:82:
  ./arch/microblaze/include/asm/io.h:33:0: note: this is the location of the previous definition
   #define PCI_IOBASE ((void __iomem *)_IO_BASE)
   ^

Signed-off-by: Chen Gang &lt;gang.chen.5i5j@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>VMXNET3: Check for map error in vmxnet3_set_mc</title>
<updated>2014-09-05T18:50:39+00:00</updated>
<author>
<name>Andy King</name>
<email>acking@vmware.com</email>
</author>
<published>2014-09-02T20:13:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=4ad9a64f53c619969dede1143d56ccda1a453c39'/>
<id>4ad9a64f53c619969dede1143d56ccda1a453c39</id>
<content type='text'>
We should check if the map of the table actually succeeds, and also free
resources accordingly.

Version bumped to 1.2.1.0

Acked-by: Shelley Gong &lt;shelleygong@vmware.com&gt;
Acked-by: Bhavesh Davda &lt;bhavesh@vmware.com&gt;
Signed-off-by: Andy King &lt;acking@vmware.com&gt;
Reported-by: Tetsuo Handa &lt;penguin-kernel@I-love.SAKURA.ne.jp&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
We should check if the map of the table actually succeeds, and also free
resources accordingly.

Version bumped to 1.2.1.0

Acked-by: Shelley Gong &lt;shelleygong@vmware.com&gt;
Acked-by: Bhavesh Davda &lt;bhavesh@vmware.com&gt;
Signed-off-by: Andy King &lt;acking@vmware.com&gt;
Reported-by: Tetsuo Handa &lt;penguin-kernel@I-love.SAKURA.ne.jp&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge branch 'for-john' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes</title>
<updated>2014-09-04T17:12:02+00:00</updated>
<author>
<name>John W. Linville</name>
<email>linville@tuxdriver.com</email>
</author>
<published>2014-09-04T17:12:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=1bd3fa7b8c9b2936c16c6e6452f9cc991c405872'/>
<id>1bd3fa7b8c9b2936c16c6e6452f9cc991c405872</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
</feed>
