Re: [OpenWrt-Devel] Math operation gets wrong result on ar71xx for AA

[Wojciech Kromer]

W dniu 27.04.2013 03:45, Luiz Angelo Daros de Luca pisze:


/block/partitions/msdos.c:

this_sector = first_sector + start_sect(p) * sector_size;




please look at linux/types.h
maybe CONFIG_LBDAF is not set

#ifdef CONFIG_LBDAF
typedef u64 sector_t;
typedef u64 blkcnt_t;
#else
typedef unsigned long sector_t;
typedef unsigned long blkcnt_t;
#endif

if it does not help, try to remove inline here,
maby it's an omptimise problem

static inline sector_t start_sect(struct partition *p)
{
return (sector_t)get_unaligned_le32(&p->start_sect);
}


best regards

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Math operation gets wrong result on ar71xx for AA

[Luiz Angelo Daros de Luca]

The usage of sign-extension might be cause. The problem is that all these
variables are sector_t, which as far as I know, is a u64.
Even if it was using signed variable, all of them are 64bit and using
values much lower that 2^63.

As mips is not a 64-bit processor, the compiler must do it by parts. So,
where is this problem from? Compiler? Kernel?

I guess no one faced this problem before because it might be rare to
someone have a logical partition over 2147483648 sectors (2^31),
or a little over 1TB (1099 GB), in a arch for embebed systems.

---
 Luiz Angelo Daros de Luca, Me.
luizl...@gmail.com


2013/4/27 David Newall 

> On 27/04/13 11:15, Luiz Angelo Daros de Luca wrote:
>
>>
>> The correct output would be 2273342085 and not 18446744071687926405.
>> Comparing both, the  MSB 32bit of first_sector becomes all 1.
>>
>> 2273342085   = 0x87807285
>> 18446744071687926405 = 0x87807285
>>
>> Any idea of why? Maybe this has something to do with
>> target/linux/ar71xx/patches-3.**3/902-unaligned_access_hacks.**patch?
>>
>>
> Looks very much like sign-extension when converting a 32-bit negative
> value to 64-bit.
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] WNDR4300

[David Lang]

As far as I can tell the openwrt for the 4300 requires using a initramfs image 
instead of a squashfs or jffs image. But how do you load the initramfs image on 
the system?


I managed to compile such an image, but I was unable to successfully load it 
using the standard netgear hold-reset-then-tftp process. I just get timeouts on 
the tftp.


Any suggestions?

David Lang
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Math operation gets wrong result on ar71xx for AA

[David Newall]

On 27/04/13 11:15, Luiz Angelo Daros de Luca wrote:


The correct output would be 2273342085 and not 18446744071687926405. 
Comparing both, the  MSB 32bit of first_sector becomes all 1.


2273342085   = 0x87807285
18446744071687926405 = 0x87807285

Any idea of why? Maybe this has something to do with 
target/linux/ar71xx/patches-3.3/902-unaligned_access_hacks.patch?




Looks very much like sign-extension when converting a 32-bit negative 
value to 64-bit.

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] Math operation gets wrong result on ar71xx for AA

[Luiz Angelo Daros de Luca]

Hello,

I reported a bug that prevents partitions in a large disk (1.5TB) to be
used here:
https://dev.openwrt.org/ticket/13420

I already isolated it to this line:

/block/partitions/msdos.c:

this_sector = first_sector + start_sect(p) * sector_size;

And some printk show their values:

[   98.23] parse_extended: sector_size = 1
[   98.23] parse_extended: start_sect(p) = 2147488875
[   98.23] parse_extended: start_sect(p)*sector_size = 2147488875
[   98.24] parse_extended: first_sector = 125853210
[   98.25] parse_extended: first_sector + start_sect(p) * sector_size =
this_sector = 18446744071687926405

The correct output would be 2273342085 and not 18446744071687926405.
Comparing both, the  MSB 32bit of first_sector becomes all 1.

2273342085   = 0x87807285
18446744071687926405 = 0x87807285

Any idea of why? Maybe this has something to do with
target/linux/ar71xx/patches-3.3/902-unaligned_access_hacks.patch?

Thanks,

---
 Luiz Angelo Daros de Luca, Me.
luizl...@gmail.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] Traffic Control Subsystem

[scolfield]

Hello,

I have a doubt about queue length, more specifically, if the parameter
called "*limit*" from PFIFO/BFIFO works well or not.

I've tried to configure the queue length of the Ethernet interface via TC
command and everything was well, but when I used IFCONFIG command to see
the '*txqueuelen*', such parameter has not been modified. Well, I think
that is because the traffic control and ifconfig uses different variables
(internal to kernel) to represent the queue length, that why 'txqueuelen'
 of the ifconfig command has not been modified... yes or no?

Moreover, I've configured different values of queue size (128, 512, 1024,
...) from TC command (bfifo and pfifo) recently. And, to test it, I sent
UDP flows using Iperf tool from one host to other.
It was little strange for me.. because for small value of queue length
(bfifo = 128 Bytes) *any *transmission occurred. However, for big value
(bfifo = 1500 Bytes) the *transmission ocurred*.

So, I would like a help to understand the problem. I'd like to know the
relationship (if exist) between the 'limit' parameter of TC and the
'txqueuelen' parameter of the ifconfig command.

My best regards,
Scolfield
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] [lantiq] ltq-atm: add rx tasklet

[Luca dariz]

Il 26/04/2013 16:35, Conor O'Gorman ha scritto:
> On Fri, 2013-04-26 at 14:13 +0200, Luca dariz wrote:
>> Use a tasklet to handle incoming packets. Fix #12917.
>>
>> Incoming packets are now processes in a tasklet instead of in the
>> irq handler; this should improve latency.
>>
>> This patch is based on a previous version of ltq-atm driver, which
>> did implement a tasklet.
>>
>> It has been tested on a arv4518pw with a
>> Lantiq Danube for about a month and it seems to work well.
> 
> And how much 'better' is it?
> 

I did't measure latency with this patch and without it, so i can't tell
exactly.

Luca
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Maintenance of external packages

[Jonas Gorski]

On Fri, Apr 26, 2013 at 5:18 PM, Guillermo Senna  wrote:
> I have a question, is there a way of browsing the Makefiles of the packages
> in feeds of AA for example? Because here
> 'https://dev.openwrt.org/browser/packages/libs/faad2/Makefile' is the new
> Makefile, but where is the old (AA) one exactly?

AA's packages branch is at
.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] ar71xx: Add Netgear WNR2000v3 support

[Gabor Juhos]

2013.04.22. 18:29 keltezéssel, Mathieu Olivari írta:
> Network connectivity works fine (LAN and WAN).
> For GPIOs, only pwr led and the green wan leds are supported for now.
> 
> Signed-off-by: Mathieu Olivari 

Applied.

Thanks,
Gabor
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] [ar71xx] Add support for TPLINK WR720N v3

[Gabor Juhos]

2013.04.10. 4:50 keltezéssel, Yousong Zhou írta:
> Add support for TPLINK WR720N v3 which has 4MB flash, 32MB ram, 2 ethernet
> interfaces, 1 USB 2.0 port. The patch is mostly a modification from
> mach-tl-wr703n.c. GPIO numbers for the slider switch is from 
> mach-tl-mr3020n.c.
> 
> Tested on my device and they worked fine.
> 
> Signed-off-by: yousong 

Applied.

Thanks,
Gabor
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] mpc85xx: Add subtargets Generic and P1020

[Gabor Juhos]

2013.04.16. 17:18 keltezéssel, Helmut Schaa írta:
> Only difference between Generic and P1020 is that P1020
> enables SMP with two CPUs in the kernel config.
> 
> Signed-off-by: Helmut Schaa 

Applied.

Thanks,
Gabor
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] snmpd trap for IPv6

[Pietro Paolini]

Hello all,
I am experiencing probleming configuring the snmpd daemon trap for IPv6, I am 
using this line :

trap2sink udp6:[fe80::aa20:66ff:fe39:a181]:162 

In this configuration file:

agentaddress UDP:161
agentaddress UDP6:161
authtrapenable 2
sysObjectID 1.3.6.1.4.1.9303.1.6.4
com2sec public default public
com2sec6 public default public
group grp_dEFaUlt_2_public v2c public
view all included .1
access grp_dEFaUlt_2_public "" v2c noauth exact all all none
rouser userro
iquerySecName userro
agentSecName userro
linkUpDownNotifications yes
clientaddr 10.1.198.191
trap2sink udp6:[fe80::aa20:66ff:fe39:a181]:162   

But I can't see outgoing trap message, I can see this output from the snmpd 
daemon.

Sending 149 bytes to UDP/IPv6: [fe80::aa20:66ff:fe39:a181]:162
: 30 81 92 02  01 01 04 02  22 22 A7 81  88 02 04 170...""..
0016: 1F 18 22 02  01 00 02 01  00 30 7A 30  0E 06 08 2B.."..0z0...+
0032: 06 01 02 01  01 03 00 43  02 2F 5E 30  17 06 0A 2B...C./^0...+
0048: 06 01 06 03  01 01 04 01  00 06 09 2B  06 01 06 03...+
0064: 01 01 05 04  30 11 06 0B  2B 06 01 02  01 02 02 010...+...
0080: 01 CE 14 02  02 27 14 30  10 06 0B 2B  06 01 02 01.'.0...+
0096: 02 02 01 07  CE 14 02 01  01 30 10 06  0B 2B 06 01.0...+..
0112: 02 01 02 02  01 08 CE 14  02 01 01 30  18 06 0A 2B...0...+
0128: 06 01 06 03  01 01 04 03  00 06 0A 2B  06 01 04 01...+
0144: C8 57 01 06  04   .W…

Then I don't understand what happen.
Any suggests ?


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Maintenance of external packages

[Guillermo Senna]

I see. I asked because there was a time when it was being said that as the
project kept growing, it was impossible for the developers to also maintain
external packages.
I have a question, is there a way of browsing the Makefiles of the packages
in feeds of AA for example? Because here '
https://dev.openwrt.org/browser/packages/libs/faad2/Makefile' is the new
Makefile, but where is the old (AA) one exactly?

Thank you for replying.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] [lantiq] ltq-atm: add rx tasklet

[Conor O'Gorman]

On Fri, 2013-04-26 at 14:13 +0200, Luca dariz wrote:
> Use a tasklet to handle incoming packets. Fix #12917.
> 
> Incoming packets are now processes in a tasklet instead of in the
> irq handler; this should improve latency.
> 
> This patch is based on a previous version of ltq-atm driver, which
> did implement a tasklet.
> 
> It has been tested on a arv4518pw with a
> Lantiq Danube for about a month and it seems to work well.

And how much 'better' is it?

Thanks,
Conor

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] [lantiq] ltq-atm: add rx tasklet

[Luca dariz]

Use a tasklet to handle incoming packets. Fix #12917.

Incoming packets are now processes in a tasklet instead of in the
irq handler; this should improve latency.

This patch is based on a previous version of ltq-atm driver, which
did implement a tasklet.

It has been tested on a arv4518pw with a
Lantiq Danube for about a month and it seems to work well.

Signed-off-by: Luca Dariz 
Tested-by: Luca Dariz 
--
Index: package/platform/lantiq/ltq-atm/src/ltq_atm.c
===
--- package/platform/lantiq/ltq-atm/src/ltq_atm.c   (revisione 36090)
+++ package/platform/lantiq/ltq-atm/src/ltq_atm.c   (copia locale)
@@ -199,6 +199,8 @@
 static inline void mailbox_aal_rx_handler(void);
 static irqreturn_t mailbox_irq_handler(int, void *);
 static inline void mailbox_signal(unsigned int, int);
+static void do_ppe_tasklet(unsigned long);
+DECLARE_TASKLET(g_dma_tasklet, do_ppe_tasklet, 0);
 
 /*
  *  QSB & HTU setting functions
@@ -491,6 +493,9 @@
break;
}
 
+   /* wait for incoming packets to be processed by upper layers */
+   tasklet_unlock_wait(&g_dma_tasklet);
+
 PPE_CLOSE_EXIT:
return;
 }
@@ -1039,14 +1044,25 @@
}
 }
 
+static void do_ppe_tasklet(unsigned long data)
+{
+   *MBOX_IGU1_ISRC = *MBOX_IGU1_ISR;
+   mailbox_oam_rx_handler();
+   mailbox_aal_rx_handler();
+
+   if ((*MBOX_IGU1_ISR & ((1 << RX_DMA_CH_AAL) | (1 << RX_DMA_CH_OAM))) != 
0)
+   tasklet_schedule(&g_dma_tasklet);
+   else
+   enable_irq(PPE_MAILBOX_IGU1_INT);
+}
+
 static irqreturn_t mailbox_irq_handler(int irq, void *dev_id)
 {
if ( !*MBOX_IGU1_ISR )
return IRQ_HANDLED;
 
-   *MBOX_IGU1_ISRC = *MBOX_IGU1_ISR;
-   mailbox_oam_rx_handler();
-   mailbox_aal_rx_handler();
+   disable_irq_nosync(PPE_MAILBOX_IGU1_INT);
+   tasklet_schedule(&g_dma_tasklet);
 
return IRQ_HANDLED;
 }



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Maintenance of external packages

[Jiri Slachta]

Dne 25.4.2013 17:42, Guillermo Senna napsal(a):
> Hi,
> I wanted to ask what is the situation of packages inside feeds? Does this 
> list still receives patches for external packages?
> I ask this because faad2 library for example in AA still has an old Makefile 
> when there was Changeset 34527 made 5 months ago.
> Also, I would like to update the LIRC package and also make some changes to 
> the Makefile itself and submit it as a Patch. Where should I post such patch?
> 
> Thank you.
> 
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> 

This mailing list works as usual and also receives patches for external 
packages. The reason why faad2 library in AA has the older version of Makefile 
is because of the development process. Once the branch is created from trunk, 
it mainly receives bugfixes until it is released, otherwise it will be in next 
release (it should appear in next revision of AA branch or future BB branch).

If you would love to make some changes, send them as usual to mailing list in 
according to https://dev.openwrt.org/wiki/SubmittingPatches . Dev's were kind 
of busy I suppose :-)

Jiri 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel