[SOLVED] When using wget, getting "read error" messages

I've recently seen the following issue occur where when I run "wget" I get a bunch of messages of the type:

wget http://dnld.lime-technology.com/stable/unRAIDServer-5.0.5-i386.zip

--2014-05-07 11:22:07--  http://dnld.lime-technology.com/stable/unRAIDServer-5.0.5-i386.zip
Resolving dnld.lime-technology.com (dnld.lime-technology.com)... 207.171.187.117
Connecting to dnld.lime-technology.com (dnld.lime-technology.com)|207.171.187.117|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 36390492 (35M) [application/zip]
Saving to: `unRAIDServer-5.0.5-i386.zip'

2% [                                       ] 758,380      757K/s   in 1.0s

2014-05-07 11:22:09 (757 KB/s) - Read error at byte 758380/36390492 (Invalid argument). Retrying.

--2014-05-07 11:22:10--  (try: 2)  http://dnld.lime-technology.com/stable/unRAIDServer-5.0.5-i386.zip
Connecting to dnld.lime-technology.com (dnld.lime-technology.com)|207.171.187.117|:80... connected.
HTTP request sent, awaiting response... 206 Partial Content
Length: 36390492 (35M), 35632112 (34M) remaining [application/zip]
Saving to: `unRAIDServer-5.0.5-i386.zip'

2% [                                       ] 887,780     --.-K/s   in 0.1s

2014-05-07 11:22:10 (1.05 MB/s) - Read error at byte 887780/36390492 (Invalid argument). Retrying.

--2014-05-07 11:22:12--  (try: 3)  http://dnld.lime-technology.com/stable/unRAIDServer-5.0.5-i386.zip
Connecting to dnld.lime-technology.com (dnld.lime-technology.com)|207.171.187.117|:80... connected.
HTTP request sent, awaiting response... 206 Partial Content
Length: 36390492 (35M), 35502712 (34M) remaining [application/zip]
Saving to: `unRAIDServer-5.0.5-i386.zip'

2% [>                                      ] 948,060     --.-K/s   in 0.1s

2014-05-07 11:22:12 (492 KB/s) - Read error at byte 948060/36390492 (Invalid argument). Retrying.

I'm not sure where to start looking here for my problem.  I've now tried two different network cards (an r8169 and an Intel e1000e) and it happens in both cases.  I've switched out network cables to no avail.  I also don't see this issue on other systems on my network.

Here is the output from ifconfig and ethtool eth0, as well -- any ideas out there?

>> ifconfig
eth0      Link encap:Ethernet  HWaddr 00:15:17:ae:cb:e4
          inet addr:192.168.1.131  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:9000  Metric:1
          RX packets:869079 errors:0 dropped:22 overruns:0 frame:0
          TX packets:1066385 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:133853376 (127.6 MiB)  TX bytes:1407046032 (1.3 GiB)
          Interrupt:16 Memory:fe7e0000-fe800000

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:1111 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1111 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:145096 (141.6 KiB)  TX bytes:145096 (141.6 KiB)

>> ethtool -i eth0
driver: e1000e
version: 2.2.14-k
firmware-version: 5.11-8
bus-info: 0000:02:00.0

Solved this one myself.  I had decided to unlock the second core on my AMD Sempron 140 last week and that appears to have been the issue(?) because as soon as I went back in and locked the second core, everything started working as expected (this issue was one of several I was suddenly having).

So be careful when unlocking cores (or just buy an i7 already).

Core unlocking is never a good idea. They are locked because they failed validation testing. They may crash on every boot or they may crash only under very specific conditions or they may behave unexpectedly. All chips are manufactured as multi-core but the the manufacturing yield (and thus cost) is lowered if more single core chips are needed. Selling chips with a second valid core as single core chips make little economic sense.