| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
SVN-Revision: 27070
|
|
|
|
| |
SVN-Revision: 27069
|
|
|
|
| |
SVN-Revision: 27068
|
|
|
|
| |
SVN-Revision: 27067
|
|
|
|
| |
SVN-Revision: 27066
|
|
|
|
| |
SVN-Revision: 27065
|
|
|
|
| |
SVN-Revision: 27064
|
|
|
|
| |
SVN-Revision: 27063
|
|
|
|
| |
SVN-Revision: 27062
|
|
|
|
| |
SVN-Revision: 27061
|
|
|
|
| |
SVN-Revision: 27060
|
|
|
|
| |
SVN-Revision: 27059
|
|
|
|
| |
SVN-Revision: 27058
|
|
|
|
| |
SVN-Revision: 27057
|
|
|
|
| |
SVN-Revision: 27056
|
|
|
|
| |
SVN-Revision: 27055
|
|
|
|
| |
SVN-Revision: 27054
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
for WNDR3700v2
NETGEAR doesnt produce a distinct North American image for
WNDR3700v2, they use the same image worldwide. This is a change from
earlier models such as WNDR3700 (v1). NETGEAR's v2 images now contain
an "hd_id" parameter, as well. All observed WNDR3700v2, WNDR3800, and
WNDRMAC images use 29763654+16+64 as their hd_id value.
This patch changes the OpenWrt WNDR3700v2 "factory" image generation
to stop producing the extraneous -NA version and to tag the image with
the same hd_id used in NETGEAR's images.
There is no change to WNDR3700 (v1) image generation, as NETGEAR
continues to produce distinct -NA and worldwide images, neither of
which are tagged with hd_id.
Signed-off-by: Mark Mentovai <mark@moxienet.com>
SVN-Revision: 27053
|
|
|
|
| |
SVN-Revision: 27051
|
|
|
|
|
|
|
|
|
|
|
|
| |
Newer WRT160NLs have a flash chip with 4K erase blocks instead of 64K,
resulting in miscalculated partition sizes.
Since the actual sizes did not change, hardcode them to their current
sizes, and make sure they are at least one erase block big (in case Cisco
decides to start to use chips with 128K erase blocks).
Signed-off-by: Jonas Gorski <jonas.gorski+openwrt@gmail.com>
SVN-Revision: 27049
|
|
|
|
| |
SVN-Revision: 27048
|
|
|
|
| |
SVN-Revision: 27047
|
|
|
|
| |
SVN-Revision: 27045
|
|
|
|
| |
SVN-Revision: 27044
|
|
|
|
| |
SVN-Revision: 27043
|
|
|
|
| |
SVN-Revision: 27042
|
|
|
|
| |
SVN-Revision: 27041
|
|
|
|
| |
SVN-Revision: 27040
|
|
|
|
|
|
| |
Reported-by: Dave Täht <dave.taht@gmail.com>
SVN-Revision: 27039
|
|
|
|
|
|
| |
condition that got rx stuck when the interface is brought up during lots of inbound traffic (thx, matteo)
SVN-Revision: 27035
|
|
|
|
|
|
| |
continously sending MAC pause frames
SVN-Revision: 27034
|
|
|
|
| |
SVN-Revision: 26924
|
|
|
|
| |
SVN-Revision: 26922
|
|
|
|
| |
SVN-Revision: 26891
|
|
|
|
| |
SVN-Revision: 26890
|
|
|
|
| |
SVN-Revision: 26889
|
|
|
|
|
|
| |
Patch-by: Cezary Jackiewicz <cezary@eko.one.pl>
SVN-Revision: 26862
|
|
|
|
|
|
| |
Based on a patch by Magyar Szabolcs <mszabi@freemail.hu>
SVN-Revision: 26861
|
|
|
|
| |
SVN-Revision: 26860
|
|
|
|
| |
SVN-Revision: 26859
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reading of the PHY registers occasionally returns with bogus values
under heavy load. This misleads the PHY driver and thus causes false
link/speed change notifications which leads to performance loss.
This is easily noticable during an iperf session:
...
[ 3] 52.0-53.0 sec 11.3 MBytes 94.4 Mbits/sec
[ 3] 53.0-54.0 sec 11.4 MBytes 95.4 Mbits/sec
eth1: link down
br-lan: port 2(eth1) entering forwarding state
eth1: link up (100Mbps/Full duplex)
br-lan: port 2(eth1) entering forwarding state
br-lan: port 2(eth1) entering forwarding state
[ 3] 54.0-55.0 sec 6.75 MBytes 56.6 Mbits/sec
[ 3] 55.0-56.0 sec 0.00 Bytes 0.00 bits/sec
[ 3] 56.0-57.0 sec 10.5 MBytes 88.1 Mbits/sec
...
[ 3] 169.0-170.0 sec 11.4 MBytes 95.4 Mbits/sec
[ 3] 170.0-171.0 sec 11.4 MBytes 95.4 Mbits/sec
eth1: link up (10Mbps/Half duplex)
[ 3] 171.0-172.0 sec 7.63 MBytes 64.0 Mbits/sec
[ 3] 172.0-173.0 sec 9.38 MBytes 78.6 Mbits/sec
eth1: link up (100Mbps/Full duplex)
[ 3] 173.0-174.0 sec 11.3 MBytes 94.4 Mbits/sec
[ 3] 174.0-175.0 sec 11.4 MBytes 95.4 Mbits/sec
SVN-Revision: 26856
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The function __devinit ag71xx_probe() references
a function __devexit ag71xx_phy_disconnect().
This is often seen when error handling in the init function
uses functionality in the exit path.
The fix is often to remove the __devexit annotation of
ag71xx_phy_disconnect() so it may be used outside an exit section.
The function ag71xx_phy_disconnect() references a function in an exit
section.
Often the function ag71xx_ar7240_cleanup() has valid usage outside the
exit section
and the fix is to remove the __devexit annotation of
ag71xx_ar7240_cleanup.
SVN-Revision: 26855
|
|
|
|
| |
SVN-Revision: 26854
|
|
|
|
| |
SVN-Revision: 26845
|
|
|
|
| |
SVN-Revision: 26844
|
|
|
|
| |
SVN-Revision: 26843
|
|
|
|
| |
SVN-Revision: 26842
|
|
|
|
| |
SVN-Revision: 26840
|
|
|
|
| |
SVN-Revision: 26827
|
|
|
|
|
|
| |
default network config
SVN-Revision: 26779
|