On Mon, 23 Jan 2012 20:33:31 +0100, Felix Fietkau wrote:
As you've probably noticed, we've had issues keeping up with the
workload of incoming patches.
There is quite a bit of work involved in taking care of incoming
patches, not just review. Patches need to be compile tested, ideally
also runt
Hi,
I cannot get collectd-mod-iwinfo to work for the proprietary wl0 drivers.
They work fine on ath5k and ath9k.
Before I try further, does collectd-mod-iwinfo support wl0 or do I need to
fall back to collectd-mod-wireless?
___
openwrt-dev
Hi jow
I just upgraded to latest trunk 29871 and discovered that the iwinfo
improvements introduced in 29421 which display hardware name, and txpower
offset apparently still only apply to the atheros platform if the outdated
madwifi driver is used. If using ath5k the standard wireless driver fo
Im pretty new here but id help anyway that i can. My company mostly deals
with ar231x and ar71xx. So id be available to test both platforms daily.
On Jan 23, 2012 2:33 PM, "Felix Fietkau" wrote:
> As you've probably noticed, we've had issues keeping up with the
> workload of incoming patches.
> T
On Monday 23 Jan 2012 21:18:48 Outback Dingo wrote:
> On Mon, Jan 23, 2012 at 2:33 PM, Felix Fietkau wrote:
> > As you've probably noticed, we've had issues keeping up with the
> > workload of incoming patches.
> > There is quite a bit of work involved in taking care of incoming
> > patches, not j
On Mon, Jan 23, 2012 at 2:33 PM, Felix Fietkau wrote:
> As you've probably noticed, we've had issues keeping up with the
> workload of incoming patches.
> There is quite a bit of work involved in taking care of incoming
> patches, not just review. Patches need to be compile tested, ideally
> also
> and allows you to start and start the daemon.
(with-smartypants-mode "But what if I want to start it instead?")
Stefan
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
On Sun, Jan 22, 2012 at 8:40 PM, Roman Yeryomin wrote:
> On 22 January 2012 14:13, Marco Antonio Mauro wrote:
>> On Sat, Jan 21, 2012 at 6:36 PM, Roman Yeryomin
>> wrote:
>>> On 21 January 2012 00:53, Marco Antonio Mauro wrote:
This patch adds support for the Sitecom WL-341 v3 and other S
On Wed, Jan 18, 2012 at 10:27:26PM +, Lee Essen wrote:
> > On Wed, Jan 18, 2012 at 01:22:10PM +, lee.es...@nowonline.co.uk wrote:
> >> The attached patch adds a "notify" script to the dsl_cpe_control app
> >> to bring the relevant pppoa interface up (or down) whenever there is
> >> a line s
Hi!
This might be a bit off topic, but I hope someone might be able to help me.
I'm currently doing a port of the USB Host mode driver for Samsung
Galaxy S and similar devices (S5PV210 / S5PC110 platform). This chipset
uses the same Synopsys OTG, as some other devices, liek the designware
one
Hi Aaron,
thanks for the detailed report.
With a quick look I was unable to see anything suspicious in the logs. I
will try to reproduce your problems on one of my devices.
Hauke
On 01/22/2012 07:49 PM, Aaron Z wrote:
> Got the wireless to work today. I followed the directions at
> http://wiki.
On 1/23/12 11:47 AM, John Crispin wrote:
>
>> There might be a miscommunication: I wasn't talking about rewriting the DSL
>> stack, but merely adding instrumentation to the existing drivers that would
>> message into user-space any line status changes.
>>
>> -Philip
>
> ideally using netlink an
Hi,
I have a few WZR-HP-G450H units. I'm using OpenWRT trunk on them right
now and it seems to be working fairly well, with the exception of radio
support. Specifically, I'm lacking the ability to change channels (the
important part) and have no ability to control antenna chains or adjust
power.
On 23.01.2012 20:33, Felix Fietkau wrote:
> As you've probably noticed, we've had issues keeping up with the
> workload of incoming patches.
> There is quite a bit of work involved in taking care of incoming
> patches, not just review. Patches need to be compile tested, ideally
> also runtime tes
Generate sysupgrade image for the ALL0256N.
Signed-off-by: Daniel Golle
Index: target/linux/ramips/image/Makefile
===
--- target/linux/ramips/image/Makefile (revision 29801)
+++ target/linux/ramips/image/Makefile (working copy)
@@
This adds uci-defaults and sysupgrade support for the ALL0256N.
Signed-off-by: Daniel Golle
Index: target/linux/ramips/base-files/lib/ramips.sh
===
--- target/linux/ramips/base-files/lib/ramips.sh(revision 29801)
+++ target/
Add mach-all0256n.c doing the board-setup.
Signed-off-by: Daniel Golle
Index: target/linux/ramips/files/arch/mips/ralink/rt305x/mach-all0256n.c
===
--- target/linux/ramips/files/arch/mips/ralink/rt305x/mach-all0256n.c
(revision 0
ALL0256N: add entires in machtype.h, Makefile, Kconfig and enable board in
config-2.3.39
Signed-off-by: Daniel Golle
Index: target/linux/ramips/files/arch/mips/ralink/rt305x/Kconfig
===
--- target/linux/ramips/files/arch/mips/ralin
This adds support for the Allnet ALL0256N outdoor AP.
The ALL0256N is based on the Mediatek/RaLink Rt3050 chipset.
It comes with 4MB of SPI flash and 32MB RAM and OpenWrt preinstalled.
Patches in the series are:
1) add entires in machtype.h, Makefile, Kconfig and enable board in
config-2.3.39
2)
As you've probably noticed, we've had issues keeping up with the
workload of incoming patches.
There is quite a bit of work involved in taking care of incoming
patches, not just review. Patches need to be compile tested, ideally
also runtime tested, and checked for dependency issues. Most of the
ti
Hi Lee,
> The patch is in two parts, this one contains the non-LuCI bits, the next one
> provides support for DSL in LuCI with an overview status in the admin_status
> page and a extra DSL tab on the network admin section which shows similar
> data and allows you to start and start the daemon.
Hi,
I think I've got my initial concept for DSL support to a point where it's quite
functional now and ready for a bit more extensive testing. I will look at
netlink as discussed, but I think that will take some time, so I think this
would serve as a good interim solution (some of it is valid
Jonas Gorski schrieb:
> Hi,
>
>
> On 22 January 2012 21:12, Hartmut Knaack wrote:
>> Blow the dust off your adm5120 machines, here comes Linux 3.1 support. Main
>> issues:
> Any reason for choosing 3.1 over 3.2 (apart from 3.1 likely being
> easier ;)? 3.1 is EOL'd, it won't receive updates anymo
> There might be a miscommunication: I wasn't talking about rewriting the DSL
> stack, but merely adding instrumentation to the existing drivers that would
> message into user-space any line status changes.
>
> -Philip
ideally using netlink and having a iw/ip/... like userland tool
we should c
>
> Nevermind. I've meanwhile found some code crafted by Amlogic (or whoever
> it was) addressing exactly this problem. It does not work well because
> it is buggy, however the idea is simple enough: do not push data to Tx
> FIFO if it still holds some previous unsent data for another EP. I think
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
is there any difference to the version from 20th?
As far as I can see it is identical just that this one got mangled by
your mailer.
~ Jow
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http:/
On 1/23/12 2:38 AM, Florian Fainelli wrote:
> Hello,
>
> On 01/23/12 02:34, Philip Prindeville wrote:
>> On 1/21/12 1:18 AM, Lee Essen wrote:
>>> On 20 Jan 2012, at 23:47, Philip Prindeville wrote:
>>>
I'd sure like to see netlink being used to communicate speed/carrier
changes up into u
Dstat is a versatile replacement for vmstat, iostat, netstat and ifstat
written in python and with a very good plugin system.
Signed-off-by: Roberto Riggio
---
Index: utils/dstat/Makefile
===
--- utils/dstat/Makefile(revisio
On 23.01.2012 15:30, Jonas Gorski wrote:
> [...]
> This all belongs into a seperate patch and has nothing to do with
> updating at91 to 3.2.1 (which you also do in this patch).
ok, as 'original' MMnet1000 patch is not included in the tree my idea
was to do it from scratch to replace the previous/ba
On 23 January 2012 16:26, Helmut Schaa wrote:
> On Mon, Jan 23, 2012 at 3:13 PM, Roman Yeryomin wrote:
>> On 23 January 2012 14:38, Helmut Schaa wrote:
>>> On Mon, Jan 23, 2012 at 11:37 AM, Roman Yeryomin
>>> wrote:
I will test more thoroughly but I noticed about 0.7 MB/s speed drop
I took a brief look and it looks like upstream now has its own
capabilities to specify an active high vbus [1], so it seems we can
drop the patch and set vbus_pin_inverted = 1 in the board-tqma9263.c
files at91_usbh_data struct.
~ Jow
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2
2012/1/23 Przemysław Rudy :
> Any suggestions how can we proceed with this?
> The 600- patch does not apply for newest kernel:
> - removing it breaks thing you noticed,
> - keeping it prevents from using kernel 3xx
The generic process I use is:
1. Find out what upstream commit made the patch not
2012/1/23 Przemysław Rudy :
> On 23.01.2012 11:20, Jonas Gorski wrote:
>> ...
>> Please split this patch into two patches (update to 3.2 and MMnet1000
>> support). Also when doing a kernel update please refresh the patches
> The MMnet1000 support has been already sent (in 2011).
> This is actually
On Mon, Jan 23, 2012 at 3:13 PM, Roman Yeryomin wrote:
> On 23 January 2012 14:38, Helmut Schaa wrote:
>> On Mon, Jan 23, 2012 at 11:37 AM, Roman Yeryomin
>> wrote:
>>> I will test more thoroughly but I noticed about 0.7 MB/s speed drop
>>> comparing with those spinlocks commented out.
>>
>> Hm
On 23 January 2012 14:38, Helmut Schaa wrote:
> On Mon, Jan 23, 2012 at 11:37 AM, Roman Yeryomin
> wrote:
>> I will test more thoroughly but I noticed about 0.7 MB/s speed drop
>> comparing with those spinlocks commented out.
>
> Hmm, ok, might as well just be a wifi interference/noise issue? Ma
On 23.01.2012 11:20, Jonas Gorski wrote:
> ...
> Please split this patch into two patches (update to 3.2 and MMnet1000
> support). Also when doing a kernel update please refresh the patches
The MMnet1000 support has been already sent (in 2011).
This is actually an update to 3.2.1 only.
Unless you
Any suggestions how can we proceed with this?
The 600- patch does not apply for newest kernel:
- removing it breaks thing you noticed,
- keeping it prevents from using kernel 3xx
Thanks
Przemek
On 23.01.2012 11:25, Jo-Philipp Wich wrote:
> Hi.
>
>> Note it removes 600-usb_vbus_active_high.patch,
Right, mail-wrap, will fix it.
On 23.01.2012 11:20, Jonas Gorski wrote:
> Hi,
>
> On 22 January 2012 22:55, Przemek Rudy wrote:
>> Update for MMnet1000 board support for kernel 3.2.1 (svn r29742).
>
> This patch does not apply for me:
>
> jonas@shaker64:~/openwrt/root-git$ patch -p1 -i index.h
On Mon, Jan 23, 2012 at 11:37 AM, Roman Yeryomin wrote:
> I will test more thoroughly but I noticed about 0.7 MB/s speed drop
> comparing with those spinlocks commented out.
Hmm, ok, might as well just be a wifi interference/noise issue? Maybe just
try on eth only with iperf or something similar?
Hi,
On 22 January 2012 21:12, Hartmut Knaack wrote:
> Blow the dust off your adm5120 machines, here comes Linux 3.1 support. Main
> issues:
Any reason for choosing 3.1 over 3.2 (apart from 3.1 likely being
easier ;)? 3.1 is EOL'd, it won't receive updates anymore.
> - updated mtd api
> - ma
On 23 January 2012 11:27, Helmut Schaa wrote:
> On Sun, Jan 22, 2012 at 11:44 AM, John Crispin wrote:
>> On 22/01/12 02:45, Roman Yeryomin wrote:
>>> On 17 January 2012 11:42, Helmut Schaa wrote:
@@ -313,6 +312,7 @@ ramips_eth_tx_housekeeping(unsigned long ptr)
struct net_device
Hi.
> Note it removes 600-usb_vbus_active_high.patch, that does not apply any
> more.
Unless upstream gained some logic to handle the inverted active state,
this is still needed, otherwise USB on the TQMA9263 will break if the
patch is not forward ported, therefore a NACK from me here.
~ Jow
___
Hi,
On 22 January 2012 22:55, Przemek Rudy wrote:
> Update for MMnet1000 board support for kernel 3.2.1 (svn r29742).
This patch does not apply for me:
jonas@shaker64:~/openwrt/root-git$ patch -p1 -i index.html.1
patching file linux/at91/MMnet1000/config-default
patching file linux/at91/MMnet10
Hello,
On 01/23/12 02:34, Philip Prindeville wrote:
On 1/21/12 1:18 AM, Lee Essen wrote:
On 20 Jan 2012, at 23:47, Philip Prindeville wrote:
I'd sure like to see netlink being used to communicate speed/carrier changes up
into userspace.
Unfortunately there's absolutely no netlink support
> "Weedy" == Weedy writes:
>>> Requirements:
>>>
>>> - 500mhz or more - 128mb ram+, DDR+ - 32mb flash - 2 gigabit ports
>>> (but I would like 4) - 1 minipci, bonus points for more - cf/sd
>>> card slot - available enclosure that isn't more then 75% the cost
>>> of the board
Weedy> Thank yo
On Sun, Jan 22, 2012 at 11:44 AM, John Crispin wrote:
> On 22/01/12 02:45, Roman Yeryomin wrote:
>> On 17 January 2012 11:42, Helmut Schaa wrote:
>>> @@ -313,6 +312,7 @@ ramips_eth_tx_housekeeping(unsigned long ptr)
>>> struct net_device *dev = (struct net_device*)ptr;
>>> struct ra
Hello Philip,
> For those of us using x86-based platforms we'd like to have a way to do
> in-place upgrades without losing configuration state.
I use squashfs images on x86 within backfire 10.03 and saving config works for
me (sysupgrade -v and webbased (webif)).
I not tested 10.03.1 or trunk on
47 matches
Mail list logo
