from:"Nikolai Zhubr"

Re: [OpenWrt-Devel] brcm47xx ethernet oopses (Was: AA on brcm47xx: Unhandled kernel unaligned access)

2014-07-18 Thread Nikolai Zhubr


18.07.2014 23:55, Rafał Miłecki:
[...]

I understand you try to make a pressure, but it really doesn't help
and just annoys developers. Please avoid that.

I'm currently hardly working on b43 now, trying to fix a lot of issues
in it. That's pretty important too. Be more patient, we have lifes,
jobs, hobbies.


Ah, ok! Sorry if it was too pressing. I somehow supposed that most heavy 
work is (temporarily) over when expecting new release... And didn't mean 
to annoy anyone of course :)


Thank you,
Nikolai



.


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

[OpenWrt-Devel] brcm47xx ethernet oopses (Was: AA on brcm47xx: Unhandled kernel unaligned access)

2014-07-18 Thread Nikolai Zhubr


Hello friends,

S... it seems everybody ran out of ideas concerning this b44 thing?

Of course I know I can just buy another new TL-WDR4300 (that's easy) if 
I just need something proven stable right now, but, well, it's kind of 
shamefull surrender... I had WL-500* running Kamikaze for years and I 
can't recall much trouble with it. On the other hand, IMHO, an ethernet 
router with partly-broken ethernet is hardly an attractive device. 
(Maybe even abandoning brcm47xx target in upcoming releases would be 
better, as long as noone is able to fix it as of yet...)



Thank you,
Nikolai

16.07.2014 0:44, Nikolai Zhubr:
[...]

Here is a slightly different panic, although also involving
netif_receive_skb_core (And this is still with additional openwrt router
inserted before uplink):

[ 900.72] CPU 0 Unable to handle kernel paging request at virtual
address 0004, epc == 80119aa0, ra == 8011b2e8
[ 900.72] Oops[#1]:
[ 900.72] CPU: 0 PID: 3 Comm: ksoftirqd/0 Not tainted 3.10.44 #2
[ 900.72] task: 81820028 ti: 8182a000 task.ti: 8182a000
[ 900.72] $ 0 :  10003800 80f29a48 
[ 900.72] $ 4 : 802be1a0 802bdc1c  fffc
[ 900.72] $ 8 : 0384 2b82ea80 00989680 
[ 900.72] $12 : 0384 3c87  
[ 900.72] $16 : 802be1a0 802bdc1c 802bdc40 7fff
[ 900.72] $20 : 0384  2aea8de9 
[ 900.72] $24 :  80016dc0
[ 900.72] $28 : 8182a000 8182bb50 0384 8011b2e8
[ 900.72] Hi : 
[ 900.72] Lo : 3c87
[ 900.72] epc : 80119aa0 rb_insert_color+0x2c/0x14c
[ 900.72] Not tainted
[ 900.72] ra : 8011b2e8 timerqueue_add+0xc0/0x118
[ 900.72] Status: 10003802 KERNEL EXL
[ 900.72] Cause : 0088
[ 900.72] BadVA : 0004
[ 900.72] PrId : 00029006 (Broadcom BMIPS3300)
[ 900.72] Modules linked in: pppoe ppp_async iptable_nat b43legacy
b43 pppox ppp_generic nf_nat_ipv4 nf_conntrack_ipv4 mac80211
ipt_MASQUERADE cfg80211 xt_time xt_tcpudp xt_state xt_nat xt_multiport
xt_mark xt_mac xt_limit xt_conntrack xt_comment xt_TCPMSS xt_REDIRECT
xt_LOG xt_CT slhc nf_nat_irc nf_nat_ftp nf_nat nf_defrag_ipv4
nf_conntrack_irc nf_conntrack_ftp iptable_raw iptable_mangle
iptable_filter ipt_REJECT ip_tables crc_ccitt compat ip6t_REJECT
ip6table_raw ip6table_mangle ip6table_filter ip6_tables x_tables
nf_conntrack_ipv6 nf_conntrack nf_defrag_ipv6 ipv6 arc4 crypto_blkcipher
leds_gpio gpio_button_hotplug tg3 hwmon bgmac b44 ptp pps_core
[ 900.72] Process ksoftirqd/0 (pid: 3, threadinfo=8182a000,
task=81820028, tls=)
[ 900.72] Stack : 802bdc40 7fff 0384  802be1a0
802bdc10 802bdc40 8003a144
802be1a0 802c  802c 802c 802bdbe0 2aea8de9 8003a9c8
 8182bc08 80c52220 80eb93a0 0001 0001 2aea8de9 0384
0003 2aea8de9 0384 80f122e4  0007 802c2870 
 80a169b5 802c 802765f4 80276608 80012d00 0001 00014600
...
[ 900.72] Call Trace:
[ 900.72] [<80119aa0>] rb_insert_color+0x2c/0x14c
[ 900.72] [<8011b2e8>] timerqueue_add+0xc0/0x118
[ 900.72] [<8003a144>] __run_hrtimer.isra.26+0x7c/0xf8
[ 900.72] [<8003a9c8>] hrtimer_interrupt+0x14c/0x3f4
[ 900.72] [<80012d00>] c0_compare_interrupt+0x74/0xa0
[ 900.72] [<8005335c>] handle_irq_event_percpu+0x64/0x1ec
[ 900.72] [<80055e60>] handle_percpu_irq+0x54/0x84
[ 900.72] [<80052ce0>] generic_handle_irq+0x28/0x44
[ 900.72] [<8000e24c>] do_IRQ+0x1c/0x2c
[ 900.72] [<8000a3ec>] plat_irq_dispatch+0x40/0xb8
[ 900.72] [<80001448>] ret_from_irq+0x0/0x4
[ 900.72] [<80005590>] __copy_user_common+0x248/0x2d8
[ 900.72] [<801a8830>] skb_copy_ubufs+0xec/0x204
[ 900.72] [<801b3db0>] __netif_receive_skb_core+0x47c/0x52c
[ 900.72] [<81ad41d4>] 0x81ad41d4
[ 900.72]
[ 900.72]
Code: 30660001 14c00047  <8c660004> 10460016  10c5
 8cc8
[ 900.72] ---[ end trace de6e4d131b0441ac ]---
[ 900.72] Kernel panic - not syncing: Fatal exception in interrupt




retest this more carefully later, and meanwhile I think:

1. Apparently some (bogus?) packets ocasionally coming from uplink still
confuse b44 driver and cause panics regardless of my B44_RXMAXLEN
correction.

2. Silent reboot might probably indicate hardware problem like
overheating. Although I have its case open and I touched its chips,
well, they were acceptably warm I think. Another point is that CPU
performance limits routing capability of this device (when using openwrt
at least) somewhere around 33mbit, so getting close to continuous 100%
CPU usage might probably lead to watchdog trigger? (Just a random
speculation)


Thank you.
Nikolai




[ 271.21] [ cut here ]
[ 271.22] WARNING: at net/core/dev.c:2194
skb_warn_bad_offload+0xc0/0xe8()
[ 271.22] b44: caps=(0x

Re: [OpenWrt-Devel] AA on brcm47xx: Unhandled kernel unaligned access

2014-07-15 Thread Nikolai Zhubr


15.07.2014 23:26, Nikolai Zhubr:
[...]

And I've performed yet another experiment. If I insert an additional
router (running also openwrt but atheros-based) between this WL-500W and
uplink (with the idea to filter out any strange and bogus incoming
packets) and redo the same test, I get no panic but instead a silent
spontaneous reboot in a few minutes after reaching 30mbit traffic. I'll


Here is a slightly different panic, although also involving 
netif_receive_skb_core (And this is still with additional openwrt router 
inserted before uplink):


[  900.72] CPU 0 Unable to handle kernel paging request at virtual 
address 0004, epc == 80119aa0, ra == 8011b2e8

[  900.72] Oops[#1]:
[  900.72] CPU: 0 PID: 3 Comm: ksoftirqd/0 Not tainted 3.10.44 #2
[  900.72] task: 81820028 ti: 8182a000 task.ti: 8182a000
[  900.72] $ 0   :  10003800 80f29a48 
[  900.72] $ 4   : 802be1a0 802bdc1c  fffc
[  900.72] $ 8   : 0384 2b82ea80 00989680 
[  900.72] $12   : 0384 3c87  
[  900.72] $16   : 802be1a0 802bdc1c 802bdc40 7fff
[  900.72] $20   : 0384  2aea8de9 
[  900.72] $24   :  80016dc0
[  900.72] $28   : 8182a000 8182bb50 0384 8011b2e8
[  900.72] Hi: 
[  900.72] Lo: 3c87
[  900.72] epc   : 80119aa0 rb_insert_color+0x2c/0x14c
[  900.72] Not tainted
[  900.72] ra: 8011b2e8 timerqueue_add+0xc0/0x118
[  900.72] Status: 10003802 KERNEL EXL
[  900.72] Cause : 0088
[  900.72] BadVA : 0004
[  900.72] PrId  : 00029006 (Broadcom BMIPS3300)
[  900.72] Modules linked in: pppoe ppp_async iptable_nat b43legacy 
b43 pppox ppp_generic nf_nat_ipv4 nf_conntrack_ipv4 mac80211 
ipt_MASQUERADE cfg80211 xt_time xt_tcpudp xt_state xt_nat xt_multiport 
xt_mark xt_mac xt_limit xt_conntrack xt_comment xt_TCPMSS xt_REDIRECT 
xt_LOG xt_CT slhc nf_nat_irc nf_nat_ftp nf_nat nf_defrag_ipv4 
nf_conntrack_irc nf_conntrack_ftp iptable_raw iptable_mangle 
iptable_filter ipt_REJECT ip_tables crc_ccitt compat ip6t_REJECT 
ip6table_raw ip6table_mangle ip6table_filter ip6_tables x_tables 
nf_conntrack_ipv6 nf_conntrack nf_defrag_ipv6 ipv6 arc4 crypto_blkcipher 
leds_gpio gpio_button_hotplug tg3 hwmon bgmac b44 ptp pps_core
[  900.72] Process ksoftirqd/0 (pid: 3, threadinfo=8182a000, 
task=81820028, tls=)
[  900.72] Stack : 802bdc40 7fff 0384  802be1a0 
802bdc10 802bdc40 8003a144

  802be1a0 802c  802c 802c 802bdbe0 2aea8de9 
8003a9c8
   8182bc08 80c52220 80eb93a0 0001 0001 2aea8de9 
0384
  0003 2aea8de9 0384 80f122e4  0007 802c2870 

   80a169b5 802c 802765f4 80276608 80012d00 0001 
00014600
  ...
[  900.72] Call Trace:
[  900.72] [<80119aa0>] rb_insert_color+0x2c/0x14c
[  900.72] [<8011b2e8>] timerqueue_add+0xc0/0x118
[  900.72] [<8003a144>] __run_hrtimer.isra.26+0x7c/0xf8
[  900.72] [<8003a9c8>] hrtimer_interrupt+0x14c/0x3f4
[  900.72] [<80012d00>] c0_compare_interrupt+0x74/0xa0
[  900.72] [<8005335c>] handle_irq_event_percpu+0x64/0x1ec
[  900.72] [<80055e60>] handle_percpu_irq+0x54/0x84
[  900.72] [<80052ce0>] generic_handle_irq+0x28/0x44
[  900.72] [<8000e24c>] do_IRQ+0x1c/0x2c
[  900.72] [<8000a3ec>] plat_irq_dispatch+0x40/0xb8
[  900.72] [<80001448>] ret_from_irq+0x0/0x4
[  900.72] [<80005590>] __copy_user_common+0x248/0x2d8
[  900.72] [<801a8830>] skb_copy_ubufs+0xec/0x204
[  900.72] [<801b3db0>] __netif_receive_skb_core+0x47c/0x52c
[  900.72] [<81ad41d4>] 0x81ad41d4
[  900.72]
[  900.72]
Code: 30660001  14c00047   <8c660004> 10460016   
10c5    8cc8

[  900.72] ---[ end trace de6e4d131b0441ac ]---
[  900.72] Kernel panic - not syncing: Fatal exception in interrupt




retest this more carefully later, and meanwhile I think:

1. Apparently some (bogus?) packets ocasionally coming from uplink still
confuse b44 driver and cause panics regardless of my B44_RXMAXLEN
correction.

2. Silent reboot might probably indicate hardware problem like
overheating. Although I have its case open and I touched its chips,
well, they were acceptably warm I think. Another point is that CPU
performance limits routing capability of this device (when using openwrt
at least) somewhere around 33mbit, so getting close to continuous 100%
CPU usage might probably lead to watchdog trigger? (Just a random
speculation)


Thank you.
Nikolai




[ 271.21] [ cut here ]
[ 271.22] WARNING: at net/core/dev.c:2194
skb_warn_bad_offload+0xc0/0xe8()
[ 271.22] b44: caps=(0x4000, 0x) len=377
data_len=0 gso_size=57048 gso_type=32506 ip_summed=

Re: [OpenWrt-Devel] AA on brcm47xx: Unhandled kernel unaligned access

2014-07-15 Thread Nikolai Zhubr


15.07.2014 12:04, Nikolai Zhubr:

15.07.2014 1:42, Jonas Gorski:
[...]

or
bw32(bp, B44_RXMAXLEN, bp->dev->mtu + ETH_HLEN + 8) ?


This is the right one; mtu (the "payload") + ETH_HLEN (14 bytes) + 8
(4 bytes for vlan tag, probably 4 extra bytes for custom header
optionally used by broadcom switches)


Ok, tested this. Unfortunately it's still panicing under load (and
seemingly this change made no difference whatsoever):


And I've performed yet another experiment. If I insert an additional 
router (running also openwrt but atheros-based) between this WL-500W and 
uplink (with the idea to filter out any strange and bogus incoming 
packets) and redo the same test, I get no panic but instead a silent 
spontaneous reboot in a few minutes after reaching 30mbit traffic. I'll 
retest this more carefully later, and meanwhile I think:


1. Apparently some (bogus?) packets ocasionally coming from uplink still 
confuse b44 driver and cause panics regardless of my B44_RXMAXLEN 
correction.


2. Silent reboot might probably indicate hardware problem like 
overheating. Although I have its case open and I touched its chips, 
well, they were acceptably warm I think. Another point is that CPU 
performance limits routing capability of this device (when using openwrt 
at least) somewhere around 33mbit, so getting close to continuous 100% 
CPU usage might probably lead to watchdog trigger? (Just a random 
speculation)



Thank you.
Nikolai




[ 271.21] [ cut here ]
[ 271.22] WARNING: at net/core/dev.c:2194
skb_warn_bad_offload+0xc0/0xe8()
[ 271.22] b44: caps=(0x4000, 0x) len=377
data_len=0 gso_size=57048 gso_type=32506 ip_summed=0
[ 271.24] Modules linked in: pppoe ppp_async iptable_nat b43legacy
b43 pppox ppp_generic nf_nat_ipv4 nf_conntrack_ipv4 mac80211
ipt_MASQUERADE cfg80211 xt_time xt_tcpudp xt_state xt_nat xt_multiport
xt_mark xt_mac xt_limit xt_conntrack xt_comment xt_TCPMSS xt_REDIRECT
xt_LOG xt_CT slhc nf_nat_irc nf_nat_ftp nf_nat nf_defrag_ipv4
nf_conntrack_irc nf_conntrack_ftp iptable_raw iptable_mangle
iptable_filter ipt_REJECT ip_tables crc_ccitt compat ip6t_REJECT
ip6table_raw ip6table_mangle ip6table_filter ip6_tables x_tables
nf_conntrack_ipv6 nf_conntrack nf_defrag_ipv6 ipv6 arc4 crypto_blkcipher
leds_gpio gpio_button_hotplug tg3 hwmon bgmac b44 ptp pps_core
[ 271.30] CPU: 0 PID: 3 Comm: ksoftirqd/0 Not tainted 3.10.44 #2
[ 271.30] Stack :     8030d552
0036 818201d0 0008
80272688 802bf23b 0003 8030cd00 818201d0 0008 802bb6e4 
802bb6dc 8001c204 0003 80019bc4 80299520 0008 80273f28 8182bc5c
       
       8182bbe8
...
[ 271.34] Call Trace:
[ 271.34] [<80010ca0>] show_stack+0x48/0x70
[ 271.35] [<80019cc0>] warn_slowpath_common+0x78/0xa8
[ 271.35] [<80019d1c>] warn_slowpath_fmt+0x2c/0x38
[ 271.36] [<801b2d10>] skb_warn_bad_offload+0xc0/0xe8
[ 271.36] [<801b68c4>] __skb_gso_segment+0x50/0xec
[ 271.37] [<801de5bc>] ip_forward_finish+0x108/0x1bc
[ 271.37] [<801b3da0>] __netif_receive_skb_core+0x46c/0x52c
[ 271.38] [<81ad41d4>] 0x81ad41d4
[ 271.38]
[ 271.38] ---[ end trace b4f0aa7175b12bf7 ]---
[ 271.39] Unhandled kernel unaligned access[#1]:
[ 271.39] CPU: 0 PID: 3 Comm: ksoftirqd/0 Tainted: G W 3.10.44 #2
[ 271.39] task: 81820028 ti: 8182a000 task.ti: 8182a000
[ 271.39] $ 0 :  0001 81696a48 0028
[ 271.39] $ 4 : 2d37d9ee  7088 
[ 271.39] $ 8 : 002d 35373137 62323162 5d203766
[ 271.39] $12 :  03bf  bc00
[ 271.39] $16 : 80e7fec0 0001 0001 0014
[ 271.39] $20 :  0008 802bb6e4 
[ 271.39] $24 : 0003 80150bcc
[ 271.39] $28 : 8182a000 8182bd28 802bb6dc 801ab22c
[ 271.39] Hi : 
[ 271.39] Lo : 0083
[ 271.39] epc : 80064440 put_page+0x0/0x4c
[ 271.39] Tainted: G W
[ 271.39] ra : 801ab22c skb_release_data+0xc4/0x118
[ 271.39] Status: 1000b803 KERNEL EXL IE
[ 271.39] Cause : 00800010
[ 271.39] BadVA : 2d37d9ee
[ 271.39] PrId : 00029006 (Broadcom BMIPS3300)
[ 271.39] Modules linked in: pppoe ppp_async iptable_nat b43legacy
b43 pppox ppp_generic nf_nat_ipv4 nf_conntrack_ipv4 mac80211
ipt_MASQUERADE cfg80211 xt_time xt_tcpudp xt_state xt_nat xt_multiport
xt_mark xt_mac xt_limit xt_conntrack xt_comment xt_TCPMSS xt_REDIRECT
xt_LOG xt_CT slhc nf_nat_irc nf_nat_ftp nf_nat nf_defrag_ipv4
nf_conntrack_irc nf_conntrack_ftp iptable_raw iptable_mangle
iptable_filter ipt_REJECT ip_tables crc_ccitt compat ip6t_REJECT
ip6table_raw ip6table_mangle ip6table_filter ip6_tables x_tables
nf_conntrack_ipv6 nf_conntrack nf_defrag_ipv6 ipv6 arc4 crypto_blkcipher
leds_gpio gpio_

Re: [OpenWrt-Devel] AA on brcm47xx: Unhandled kernel unaligned access

2014-07-15 Thread Nikolai Zhubr


15.07.2014 1:42, Jonas Gorski:
[...]

or
bw32(bp, B44_RXMAXLEN, bp->dev->mtu + ETH_HLEN + 8) ?


This is the right one; mtu (the "payload") + ETH_HLEN (14 bytes) + 8
(4 bytes for vlan tag, probably 4 extra bytes for custom header
optionally used by broadcom switches)


Ok, tested this. Unfortunately it's still panicing under load (and 
seemingly this change made no difference whatsoever):



[  271.21] [ cut here ]
[  271.22] WARNING: at net/core/dev.c:2194 
skb_warn_bad_offload+0xc0/0xe8()
[  271.22] b44: caps=(0x4000, 0x) 
len=377 data_len=0 gso_size=57048 gso_type=32506 ip_summed=0
[  271.24] Modules linked in: pppoe ppp_async iptable_nat b43legacy 
b43 pppox ppp_generic nf_nat_ipv4 nf_conntrack_ipv4 mac80211 
ipt_MASQUERADE cfg80211 xt_time xt_tcpudp xt_state xt_nat xt_multiport 
xt_mark xt_mac xt_limit xt_conntrack xt_comment xt_TCPMSS xt_REDIRECT 
xt_LOG xt_CT slhc nf_nat_irc nf_nat_ftp nf_nat nf_defrag_ipv4 
nf_conntrack_irc nf_conntrack_ftp iptable_raw iptable_mangle 
iptable_filter ipt_REJECT ip_tables crc_ccitt compat ip6t_REJECT 
ip6table_raw ip6table_mangle ip6table_filter ip6_tables x_tables 
nf_conntrack_ipv6 nf_conntrack nf_defrag_ipv6 ipv6 arc4 crypto_blkcipher 
leds_gpio gpio_button_hotplug tg3 hwmon bgmac b44 ptp pps_core

[  271.30] CPU: 0 PID: 3 Comm: ksoftirqd/0 Not tainted 3.10.44 #2
[  271.30] Stack :     8030d552 
0036 818201d0 0008

  80272688 802bf23b 0003 8030cd00 818201d0 0008 802bb6e4 

  802bb6dc 8001c204 0003 80019bc4 80299520 0008 80273f28 
8182bc5c
         

         
8182bbe8
  ...
[  271.34] Call Trace:
[  271.34] [<80010ca0>] show_stack+0x48/0x70
[  271.35] [<80019cc0>] warn_slowpath_common+0x78/0xa8
[  271.35] [<80019d1c>] warn_slowpath_fmt+0x2c/0x38
[  271.36] [<801b2d10>] skb_warn_bad_offload+0xc0/0xe8
[  271.36] [<801b68c4>] __skb_gso_segment+0x50/0xec
[  271.37] [<801de5bc>] ip_forward_finish+0x108/0x1bc
[  271.37] [<801b3da0>] __netif_receive_skb_core+0x46c/0x52c
[  271.38] [<81ad41d4>] 0x81ad41d4
[  271.38]
[  271.38] ---[ end trace b4f0aa7175b12bf7 ]---
[  271.39] Unhandled kernel unaligned access[#1]:
[  271.39] CPU: 0 PID: 3 Comm: ksoftirqd/0 Tainted: GW 
3.10.44 #2

[  271.39] task: 81820028 ti: 8182a000 task.ti: 8182a000
[  271.39] $ 0   :  0001 81696a48 0028
[  271.39] $ 4   : 2d37d9ee  7088 
[  271.39] $ 8   : 002d 35373137 62323162 5d203766
[  271.39] $12   :  03bf  bc00
[  271.39] $16   : 80e7fec0 0001 0001 0014
[  271.39] $20   :  0008 802bb6e4 
[  271.39] $24   : 0003 80150bcc
[  271.39] $28   : 8182a000 8182bd28 802bb6dc 801ab22c
[  271.39] Hi: 
[  271.39] Lo: 0083
[  271.39] epc   : 80064440 put_page+0x0/0x4c
[  271.39] Tainted: GW
[  271.39] ra: 801ab22c skb_release_data+0xc4/0x118
[  271.39] Status: 1000b803 KERNEL EXL IE
[  271.39] Cause : 00800010
[  271.39] BadVA : 2d37d9ee
[  271.39] PrId  : 00029006 (Broadcom BMIPS3300)
[  271.39] Modules linked in: pppoe ppp_async iptable_nat b43legacy 
b43 pppox ppp_generic nf_nat_ipv4 nf_conntrack_ipv4 mac80211 
ipt_MASQUERADE cfg80211 xt_time xt_tcpudp xt_state xt_nat xt_multiport 
xt_mark xt_mac xt_limit xt_conntrack xt_comment xt_TCPMSS xt_REDIRECT 
xt_LOG xt_CT slhc nf_nat_irc nf_nat_ftp nf_nat nf_defrag_ipv4 
nf_conntrack_irc nf_conntrack_ftp iptable_raw iptable_mangle 
iptable_filter ipt_REJECT ip_tables crc_ccitt compat ip6t_REJECT 
ip6table_raw ip6table_mangle ip6table_filter ip6_tables x_tables 
nf_conntrack_ipv6 nf_conntrack nf_defrag_ipv6 ipv6 arc4 crypto_blkcipher 
leds_gpio gpio_button_hotplug tg3 hwmon bgmac b44 ptp pps_core
[  271.39] Process ksoftirqd/0 (pid: 3, threadinfo=8182a000, 
task=81820028, tls=)
[  271.39] Stack : 80e7fec0 801ab294 80e7fec0 7088  
80e7fec0 ffea 801ab2d0

  802bb6e4 80e7fec0 80e5da40 0001 80e7fec0 801de5d4 0850 
80f72ac0
  81b68000 801de4b4 0001 801aa3e4 802bca98 802bca98 802bb6d0 
81abc000
  80e7fec0 801b3da0 0042 81ad0964 81b7df20 801aa3e4 802bb6e4 
8018e658
  010a 01f1 81abc3e8 81abc3c0 0042 80e7fec0 0017 
0187
  ...
[  271.39] Call Trace:
[  271.39] [<80064440>] put_page+0x0/0x4c
[  271.39] [<801ab22c>] skb_release_data+0xc4/0x118
[  271.39] [<801ab2d0>] __kfree_skb+0x14/0xd4
[  271.39] [<801de5d4>] ip_forward_finish+0x120/0x1bc
[  271.39] [<801b3da0>] __netif_receive_skb_core+0x46c/0x52c
[  271.39] [<81ad41d4>] 0x81ad41d4
[  271.39]
[  271.39]
Code: 3c058006

Re: [OpenWrt-Devel] AA on brcm47xx: Unhandled kernel unaligned access

2014-07-14 Thread Nikolai Zhubr


14.07.2014 20:44, Jonas Gorski:
[...]

If I were to speculate wildly, I would guess that B44_RXMAXLEN refers to
the maximum frame length, not the maximum buffer length - and in the
code, it's being fed with the maximum buffer length.
This would allow the hardware to receive slightly oversized frames which
can corrupt the skb.


Since there is a public datasheet[1], this is easily verifiable, and
it looks you are right:

"Receive Maximum Length Register (RcvLength, Offset 0x404):

The value stored in this register specifies the largest valid Ethernet
Frame to be received."


Ok, so I'd suppose
bw32(bp, B44_RXMAXLEN, bp->dev->mtu + ETH_HLEN + 8 + RX_HEADER_LEN)
should instead be
bw32(bp, B44_RXMAXLEN, bp->dev->mtu + ETH_HLEN) ?
or
bw32(bp, B44_RXMAXLEN, bp->dev->mtu + ETH_HLEN + 8) ?
or maybe even
bw32(bp, B44_RXMAXLEN, bp->dev->mtu) ?

Apology for my ignorance, just can't stand testing it immediately to 
hopefully get it right for BB.



Thank you.
Nikolai



The same is true for the XmtMaxLength register, which is also set "too
large" (it defaults to 1518).


Jonas

[1]: https://www.broadcom.com/collateral/pg/440X-PG02-R.pdf

.


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

Re: [OpenWrt-Devel] AA on brcm47xx: Unhandled kernel unaligned access

2014-07-14 Thread Nikolai Zhubr


14.07.2014 18:42, Rafał Miłecki:
[...]

[  637.56] Call Trace:
[  637.56] [<80010bb4>] show_stack+0x48/0x70
[  637.57] [<80019bd4>] warn_slowpath_common+0x78/0xa8
[  637.57] [<80019c30>] warn_slowpath_fmt+0x2c/0x38
[  637.58] [<801b27dc>] skb_warn_bad_offload+0xc0/0xe8
[  637.58] [<801b6390>] __skb_gso_segment+0x50/0xec
[  637.59] [<801de0dc>] ip_forward_finish+0x108/0x1bc
[  637.59] [<801b386c>] __netif_receive_skb_core+0x46c/0x52c
[  637.60] [<81acc16c>] 0x81acc16c
[  637.60]
[  637.60] ---[ end trace 2c2a6a28d6589bcc ]---


Any idea anyone? Does above mean b44 provided a corrupted packet? Or
some wrong pointer?


Yet another note: the problem apparently appeared since after 10.03.1.
Maybe I could try to bisect the revision of interest, but doing it 
blindly would probably require tons of time, unless someone aware of 
what was happening to the driver at that time gives some enlightening 
instructions.



Thank you.
Nikolai



.


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

Re: [OpenWrt-Devel] Barrier Breaker 14.07-rc1

2014-07-14 Thread Nikolai Zhubr


14.07.2014 18:34, Rafał Miłecki:


Please create a ticket with boot log, nvram show and your default
(broken) /etc/config/network.


Done,
https://dev.openwrt.org/ticket/17111

(Note: trac does not seem to know about rc1 yet, therefore I had to mark 
it for trunk)


Thank you.
Nikolai



.


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

Re: [OpenWrt-Devel] Barrier Breaker 14.07-rc1

2014-07-14 Thread Nikolai Zhubr


Hello all,

this is good news, however bad news is that brcm47xx (generic) target is 
still seriously broken, at least on Asus WL-500W. The problem is 
absolutely reproducible, and I reported it some time ago, but 
unfortunately it attracted very little interest here for some reason. 
Don't take me wrong, I use openwrt quite a lot for a long time on 
various devices and value it high enough, but it's definitely beyond my 
expertise to fix ethernet driver bugs and that sort of things, and 
seeing broken images released for the second time (12.09 had similar 
problem) is pretty strange.


Now back to the problem. The problem is, ethernet load causes kernel 
oopses. In 12.09 it was "Unhandled kernel unaligned access", now in 
14.07 it is "Unable to handle kernel paging request". The serial log 
captured a few minutes ago from 14.07.rc1 is below. Usually I get this 
oopses in maybe a minute or two after the routed traffic rises above say 
15-20 MBit.


Additionally, there is now another (less important) problem. In 14.07 
ethernet ports of WL-500W get initially configured as if it was e.g. 
wl-500gp:


- WAN is assigned to eth0.2 instead of eth1.
- WAN6 is assigned to some "@wan".
- LAN ports does not include eth0.2 but they should (Its labelled LAN1).
(This is easily fixable by hand after installation as soon as you 
identify what is wrong with this setup)


Thank you
Nikolai

==
[  131.40] CPU 0 Unable to handle kernel paging request at virtual 
address 00a8, epc == 80014868, ra == 80001420

[  131.40] Oops[#1]:
[  131.40] CPU: 0 PID: 0 Comm:  Not tainted 3.10.44 #2
[  131.40] CPU 0 Unable to handle kernel paging request at virtual 
address 00a8, epc == 80014868, ra == 80001420

[  131.40] Oops[#2]:
[  131.40] CPU: 0 PID: -980009870 Comm: Аrрceiv>чкКgєpduАr Not 
tainted 3.10.44 #2

[  131.40] Data bus error, epc == 800054e0, ra == 8005ecec
[  131.40] Oops[#3]:
[  131.40] CPU 0 Unable to handle kernel paging request at virtual 
address 00a8, epc == 80014868, ra == 80001420

[  131.40] Oops[#4]:
[  131.40] CPU: 0 PID: -980009870 Comm: Аrрceiv>чкКgєpduАr Not 
tainted 3.10.44 #2

[  131.40] Data bus error, epc == 800054e0, ra == 8005ecec
[  131.40] Oops[#5]:
[  131.40] CPU 0 Unable to handle kernel paging request at virtual 
address 00a8, epc == 80014868, ra == 80001420

[  131.40] Oops[#6]:
[  131.40] CPU: 0 PID: -980009870 Comm: Аrрceiv>чкКgєpduАr Not 
tainted 3.10.44 #2

[  131.40] Data bus error, epc == 800054e0, ra == 8005ecec
[  131.40] Oops[#7]:
[  131.40] CPU 0 Unable to handle kernel paging request at virtual 
address 00a8, epc == 80014868, ra == 80001420

[  131.40] Oops[#8]:
[  131.40] CPU: 0 PID: -980009870 Comm: Аrрceiv>чкКgєpduАr Not 
tainted 3.10.44 #2

[  131.40] Data bus error, epc == 800054e0, ra == 8005ecec
[  131.40] Oops[#9]:
[  131.40] CPU 0 Unable to handle kernel paging request at virtual 
address 00a8, epc == 80014868, ra == 80001420

[  131.40] Oops[#10]:
[  131.40] CPU: 0 PID: -980009870 Comm: Аrрceiv>чкКgєpduАr Not 
tainted 3.10.44 #2

[  131.40] Data bus error, epc == 800054e0, ra == 8005ecec
[  131.40] Oops[#11]:
[  131.40] CPU 0 Unable to handle kernel paging request at virtual 
address 00a8, epc == 80014868, ra == 80001420

[  131.40] Oops[#12]:
[  131.40] CPU: 0 PID: -980009870 Comm: Аrрceiv>чкКgєpduАr Not 
tainted 3.10.44 #2

[  131.40] Data bus error, epc == 800054e0, ra == 8005ecec
[  131.40] Oops[#13]:
[  131.40] CPU 0 Unable to handle kernel paging request at virtual 
address 00a8, epc == 80014868, ra == 80001420

[  131.40] Oops[#14]:
[  131.40] CPU: 0 PID: -980009870 Comm: Аrрceiv>чкКgєpduАr Not 
tainted 3.10.44 #2

[  131.40] Data bus error, epc == 800054e0, ra == 8005ecec
[  131.40] Oops[#15]:
[  131.40] CPU 0 Unable to handle kernel paging request at virtual 
address 00a8, epc == 80014868, ra == 80001420

[  131.40] Oops[#16]:
[  131.40] CPU: 0 PID: -980009870 Comm: Аrрceiv>чкКgєpduАr Not 
tainted 3.10.44 #2

[  131.40] Data bus error, epc == 800054e0, ra == 8005ecec
[  131.40] Oops[#17]:
[  131.40] CPU 0 Unable to handle kernel paging request at virtual 
address 00a8, epc == 80014868, ra == 80001420

[  131.40] Oops[#18]:
[  131.40] CPU: 0 PID: -980009870 Comm: Аrрceiv>чкКgєpduАr Not 
tainted 3.10.44 #2

[  131.40] Data bus error, epc == 800054e0, ra == 8005ecec
[  131.40] Oops[#19]:
[  131.40] CPU 0 Unable to handle kernel paging request at virtual 
address 00a8, epc == 80014868, ra == 80001420

[  131.40] Oops[#20]:
[  131.40] CPU: 0 PID: -980009870 Comm: Аrрceiv>чкКgєpduАr Not 
tainted 3.10.44 #2

[  131.40] Data bus error, epc == 800054e0, ra == 8005ecec
[  131.40] Oops[#21]:
[  131.40] CPU 0 Unable to handle kernel paging

Re: [OpenWrt-Devel] How to rebuild exactly 12.09 from source?

2014-06-21 Thread Nikolai Zhubr


Hello Chirag,

I think I understand your method, although it is far from being 
automatic (which I was hoping for), anyway, I'll probably try it a bit 
later if I fail to locate my bug-of-interest otherwise.


Thank you for the detailed explanation. I think it definitely deserves 
some place in documentation.


Nikolai

21.06.2014 23:59, Chirag Chhatriwala wrote:

I generally try to do the following:

1. perform a git clone on the branch or trunk.
2. perform "git log --grep="", grab the hashtag or commit id and
note the date and time of that checkin and perform a "git checkout
", this will create a detached HEAD and will leave you at the
 and nothing after it.
3. if you are going to add feeds, you need to do something similar for
the feeds as well.. I.E. create a folder named "feeds" under your source
and checkout your feeds (most likely git based now).
4. for each feeds you checked out, perform a "git log
--before="-MM-DDThh:mm:ss+Zone" format
5. grab the latest commit id and perform a "git checkout " (for each feed checked out)

This way you know that everything you are building is roughly the same
age as the latest svn commit that  you're trying to replicate. You may
end up missing a commit or two but you will be fairly close to building
the version you want. Its not exact science but it is close enough.
Otherwise you may end up checking out an old version of openwrt, but
have it built against the latest pacakges/luci/routing/telephony feeds
and things may (most likely will) break.

It used to be easier when everything was svn based and you could just
specify the svn id in your feeds in the format
svn://feed.location@. Things change so we adapt.

Hope this helps. Let me know if this is not clear.


Chirag


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

Re: [OpenWrt-Devel] AA on brcm47xx: Unhandled kernel unaligned access

2014-06-21 Thread Nikolai Zhubr


21.06.2014 0:23, Rafał Miłecki:

On 20 June 2014 22:12, Nikolai Zhubr  wrote:
There are tons of updates in trunk, this bug can be fixed for a long
time already ;)


Unfortunately it seems no :/
Also, with trunk version, routing speed limit seems to be noticably 
lower (~27 Mbit trunk compared to ~34 Mbit 12.09)

Serial log follows (Unaligned access and something)
Please let me know what else I can do to find and fix it :)

Thank you,
Nikolai
 -
 BARRIER BREAKER (Bleeding Edge, r41293)
 -
  * 1/2 oz Galliano Pour all ingredients into
  * 4 oz cold Coffeean irish coffee mug filled
  * 1 1/2 oz Dark Rum   with crushed ice. Stir.
  * 2 tsp. Creme de Cacao
 -
root@OpenWrt:/# exit
Please press Enter to activate this console.
[  637.43] [ cut here ]
[  637.44] WARNING: at net/core/dev.c:2194 
skb_warn_bad_offload+0xc0/0xe8()
[  637.45] b44: caps=(0x4000, 0x) 
len=1500 data_len=0 gso_size=53118 gso_type=59551 ip_summed=0
[  637.46] Modules linked in: pppoe ppp_async iptable_nat b43legacy 
b43 pppox ppp_generic nf_nat_ipv4 nf_conntrack_ipv4 mac80211 
ipt_MASQUERADE cfg80211 xt_time xt_tcpudp xt_state xt_nat xt_multiport 
xt_mark xt_mac xt_limit xt_conntrack xt_comment xt_TCPMSS xt_REDIRECT 
xt_LOG xt_CT slhc nf_nat_irc nf_nat_ftp nf_nat nf_defrag_ipv4 
nf_conntrack_irc nf_conntrack_ftp iptable_raw iptable_mangle 
iptable_filter ipt_REJECT ip_tables crc_ccitt compat ip6t_REJECT 
ip6table_raw ip6table_mangle ip6table_filter ip6_tables x_tables 
nf_conntrack_ipv6 nf_conntrack nf_defrag_ipv6 ipv6 arc4 crypto_blkcipher 
leds_gpio gpio_button_hotplug tg3 hwmon bgmac b44 ptp pps_core

[  637.52] CPU: 0 PID: 3 Comm: ksoftirqd/0 Not tainted 3.10.36 #1
[  637.52] Stack :     8030d552 
0036 818201d0 0008

  8026cfd0 802bb23b 0003 8030cd00 818201d0 0008 802b76e4 

  802b76dc 8001c118 0003 80019ad8 80293ecc 0008 8026e870 
8182bc5c
         

         
8182bbe8
  ...
[  637.56] Call Trace:
[  637.56] [<80010bb4>] show_stack+0x48/0x70
[  637.57] [<80019bd4>] warn_slowpath_common+0x78/0xa8
[  637.57] [<80019c30>] warn_slowpath_fmt+0x2c/0x38
[  637.58] [<801b27dc>] skb_warn_bad_offload+0xc0/0xe8
[  637.58] [<801b6390>] __skb_gso_segment+0x50/0xec
[  637.59] [<801de0dc>] ip_forward_finish+0x108/0x1bc
[  637.59] [<801b386c>] __netif_receive_skb_core+0x46c/0x52c
[  637.60] [<81acc16c>] 0x81acc16c
[  637.60]
[  637.60] ---[ end trace 2c2a6a28d6589bcc ]---
[  637.61] Unhandled kernel unaligned access[#1]:
[  637.61] CPU: 0 PID: 3 Comm: ksoftirqd/0 Tainted: GW 
3.10.36 #1

[  637.61] task: 81820028 ti: 8182a000 task.ti: 8182a000
[  637.61] $ 0   :  0001 80d72b68 0028
[  637.61] $ 4   : c36ae951  7088 
[  637.61] $ 8   : 002d 36643832 62393835 5d206363
[  637.61] $12   :  03bf  bc00
[  637.61] $16   : 80ea6ce0 0001 0001 0014
[  637.61] $20   :  0008 802b76e4 
[  637.61] $24   : 0003 801507e8
[  637.61] $28   : 8182a000 8182bd28 802b76dc 801aadc0
[  637.61] Hi: 
[  637.61] Lo: 0083
[  637.61] epc   : 80064208 put_page+0x0/0x4c
[  637.61] Tainted: GW
[  637.61] ra: 801aadc0 skb_release_data+0xc4/0x118
[  637.61] Status: 1000b803 KERNEL EXL IE
[  637.61] Cause : 00800010
[  637.61] BadVA : c36ae951
[  637.61] PrId  : 00029006 (Broadcom BMIPS3300)
[  637.61] Modules linked in: pppoe ppp_async iptable_nat b43legacy 
b43 pppox ppp_generic nf_nat_ipv4 nf_conntrack_ipv4 mac80211 
ipt_MASQUERADE cfg80211 xt_time xt_tcpudp xt_state xt_nat xt_multiport 
xt_mark xt_mac xt_limit xt_conntrack xt_comment xt_TCPMSS xt_REDIRECT 
xt_LOG xt_CT slhc nf_nat_irc nf_nat_ftp nf_nat nf_defrag_ipv4 
nf_conntrack_irc nf_conntrack_ftp iptable_raw iptable_mangle 
iptable_filter ipt_REJECT ip_tables crc_ccitt compat ip6t_REJECT 
ip6table_raw ip6table_mangle ip6table_filter ip6_tables x_tables 
nf_conntrack_ipv6 nf_conntrack nf_defrag_ipv6 ipv6 arc4 crypto_blkcipher 
leds_gpio gpio_button_hotplug tg3 hwmon bgmac b44 ptp pps_core
[  637.61] Process ksoftirqd/0 (pid: 3, threadinfo=8182a000, 
task=81820028, tls=)
[  637.61] Stack : 80ea6ce0 801aae28 80ea6ce0 7088  
80ea6ce0 ffea 801aae64

  802b76e4 80ea6ce0 80d6f6c0 0001 80ea6ce0 801de0f4 0258 
8088de40
  81a9e000 801ddfd4 0001 80ea6ce0 802b8a98 802b8a98 802b76d0 
81ab5000

Re: [OpenWrt-Devel] AA on brcm47xx: Unhandled kernel unaligned access

2014-06-21 Thread Nikolai Zhubr


21.06.2014 0:23, Rafał Miłecki:
[...]
This time uplink load was even no more than 20 Mbit.
Here is what I got (although it doesn't look very promising to me).
Maybe I should enable some more debugging somewhere?

[  543.432000] Unhandled kernel unaligned access[#1]:
[  543.432000] Cpu 0
[  543.432000] $ 0   :  1000b800 2280a89f 
[  543.432000] $ 4   : 8032e4b0 804e86b6  8033
[  543.432000] $ 8   : 804e86b6  2400 
[  543.432000] $12   : 03bf ac00  0c00
[  543.432000] $16   : 8033 8179ebe0 1000b801 0100
[  543.432000] $20   : 0005 0024 8039 8039
[  543.432000] $24   : 0004 
[  543.432000] $28   : 81824000 81825e18 8031e490 801e3e90
[  543.432000] Hi: fea0
[  543.432000] Lo: 0160
[  543.432000] epc   : 801e3e9c __dst_free+0x2c/0x150
[  543.432000] Tainted: G   O
[  543.432000] ra: 801e3e90 __dst_free+0x20/0x150
[  543.432000] Status: 1000b803KERNEL EXL IE
[  543.432000] Cause : 00800010
[  543.432000] BadVA : 2280a99b
[  543.432000] PrId  : 00029006 (Broadcom BMIPS3300)
[  543.432000] Modules linked in: nf_nat_irc nf_conntrack_irc nf_nat_ftp 
nf_conntrack_ftp ipt_MASQUERADE iptable_nat nf_nat pppoe xt_conntrack 
xt_CT xt_NOTRACK iptable_raw xt_state nf_conntrack_ipv4 nf_defrag_ipv4 
nf_conntrack pppox ipt_REJECT xt_TCPMSS ipt_LOG xt_comment xt_multiport 
xt_mac xt_limit iptable_mangle iptable_filter ip_tables xt_tcpudp 
x_tables ppp_async ppp_generic slhc b43legacy(O) b43(O) mac80211(O) 
crc_ccitt cfg80211(O) compat(O) arc4 aes_generic crypto_algapi 
switch_robo(O) switch_core(O) diag(O)
[  543.432000] Process ksoftirqd/0 (pid: 3, threadinfo=81824000, 
task=81822060, tls=)
[  543.432000] Stack : 8031e490 80063ab8 1000b802  945ef2d5 
945ef2d5 8179ebe0 80063b88
[  543.432000] 0009 80063bc4 0005 000c 8038f088 
0001 0009 80020200
[  543.432000]  8005426c    
 8039 8039
[  543.432000]  0001    
  8002037c
[  543.432000] 81819e24  800202e4   
81819e24  800202e4

[  543.432000] ...
[  543.432000] Call Trace:
[  543.432000] [<801e3e9c>] __dst_free+0x2c/0x150
[  543.432000] [<80063b88>] __rcu_process_callbacks+0x118/0x140
[  543.432000] [<80020200>] __do_softirq+0xd0/0x1b4
[  543.432000] [<8002037c>] run_ksoftirqd+0x98/0x154
[  543.432000] [<80037678>] kthread+0x88/0x90
[  543.432000] [<80007cc0>] kernel_thread_helper+0x10/0x18
[  543.432000]
[  543.432000]
[  543.432000] Code: 8e22000c  5046  3c02801e <8c4200fc> 30420001 
1446  24020002  3c02801e  244240cc

[  543.664000] ---[ end trace f941e3bc313ba83f ]---
[  543.668000] Kernel panic - not syncing: Fatal exception in interrupt





I suppose this is something that should not normally happen, and I'd like to
have it fixed somehow. I haven't tried trunk yet, but I will, if it could
make some difference.


There are tons of updates in trunk, this bug can be fixed for a long
time already ;)

.


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

Re: [OpenWrt-Devel] How to rebuild exactly 12.09 from source?

2014-06-21 Thread Nikolai Zhubr


21.06.2014 14:39, Rafał Miłecki:

What about using tag in svn repo?
svn://svn.openwrt.org/openwrt/tags/attitude_adjustment_12.09/


I tried that, and although version.mk indeed stated 12.09, there is some 
discrepancy:


- svn told me that it fetched r41293 this time;
- the router flashed with this self-built 12.09 claimed it is r36422;
- binary AA 12.09 from downloads.openwrt.org claims it is r36088.

So I'm now closer, but still can't produce a build which would identify 
itself exactly as the official 12.09 release (12.09 r36088).


Thank you,
Nikolai



.


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

[OpenWrt-Devel] How to rebuild exactly 12.09 from source?

2014-06-21 Thread Nikolai Zhubr


Hello people,

Since I'm trying to locate a kenrel panic happening in AA 12.09, I 
thought I'll just rebuild it from source with debuginfo and rerun my 
tests. However, git.openwrt.org/12.09/openwrt.git clearly puts me 
somewhere in between 12.09 and (the unreleased yet) 12.09.1. On the 
other hand, using svn checkout with -r 36088 seems to give 12.09-rc1 
(according to version.mk). Well, of course I could test pre-12.09.1 and 
trunk etc, but I'd first like to locate my problem in the latest 
released version, where I get it. Also, if I build 12.09.1 from source 
now I can not e.g. opkg update/install on the router, because the 
necessary repository is obviously nonexistent yet. So its a bit of a 
mess and I'd like to ask for some hint. And generally, I think some sort 
of instruction on how to _exactly_ reproduce a certain released binary 
version from source (in the wiki maybe) would be nice and appropriate 
for many reasons, especially debugging (Maybe there is one somewhere, 
which I couldn't find, maybe its my fault then...)


Thank you,
Nikolai
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] AA on brcm47xx: Unhandled kernel unaligned access

2014-06-20 Thread Nikolai Zhubr


Hello people,

I have asus wl-500W router (http://wiki.openwrt.org/toh/asus/wl500w). It 
is also very similar to wl-500gp.
Some few months ago I updated to 12.09. I can't recall now if it was 
backfire or kamikaze before, but I noticed 2 things immediately:


1. Maximum practically achievable download speed increased somewhat.
(From ~30Mbit to ~34mbit approx)

2. After reaching (and keeping) this max download speed, the device will 
always reboot soon. (Absolutely reproducible)


For some time I was thinking that's just hardware, like bad electrolytic 
capacitors and/or weak power supply. Finally I opened the router, 
replaced all 3 capacitors (2 of 3 appeared somewhat damaged indeed), 
attached a voltmeter to check for undervoltage. Still nothing: power 
supply is OK, reboots still happen.


So I had to turn to the software side, and found 2 new things again:

1. While uplink load goes up approaching 34Mbit, softirqs eat up more 
and more CPU, approaching 100% CPU.


2. At some point I get (on a serial link):
[  368.948000] sched: RT throttling activated
[  382.688000] Unhandled kernel unaligned access[#1]:
trim
[  382.932000] Kernel panic - not syncing: Fatal exception in interrupt
[  382.94] Rebooting in 3 seconds..
(Trimmed all in between because there is no debugging info for now)

I suppose this is something that should not normally happen, and I'd 
like to have it fixed somehow. I haven't tried trunk yet, but I will, if 
it could make some difference. I can provide serial logs, compile trunk, 
apply patches, redo testing etc. (As time permits)

Any hints appreciated.

Thank you,
Nikolai
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] pptp fails on x86

2012-11-06 Thread Nikolai Zhubr


Hi,
this is translation from russian:

The problem is observed on x86.
At the first test pptp was operable, with the following schematic layout 
used:

[ISP] -- LAN2 [tp-link wr1043nd(Backfire 10.03)] LAN1 -- eth0[x86(AA 12.09)]
TP-link wr1043nd was configured as follows:
VLAN 1:
info: VLAN 1: Ports: '12345t', members=003e, untag=001e, fid=0
fid: 0
ports: 1 2 3 4 5t

Then after changing the network layout to:
[ISP] -- WAN [tp-link wr1043nd(Backfire 10.03)] LAN1 -- eth0[x86(AA 12.09)]

TP-link wr1043nd was configured as follows:
VLAN 2:
info: VLAN 2: Ports: '01', members=0021, untag=0001, fid=0
fid: 0
ports: 0 1

Now pptp link fails to come up with no visible relevant messages/complaints.

Then we created /etc/ppp/peers/isp describing the connection.
Issueing "pppd call isp nodetach debug" completes without any messages. 
I've noticed that ppp.sh exits as soon as the server is available.


Any help is much appreciated. I'll try to provide whatever debugging 
information necessary.


06.11.2012 11:22, Илья Кучмин wrote:

Добрый день.

Хочу извиниться за сообщение на русском. Но для обсуждения данной
проблемы моего английского к сожалению не хватит.

Проблема наблюдается на платформе x86.
При первом испытании pptp работал, при этом схема была следующая:
[ISP] -- LAN2 [tp-link wr1043nd(Backfire 10.03)] LAN1 -- eth0[x86(AA 12.09)]
TP-link wr1043nd настроен следующим образом:
VLAN 1:
info: VLAN 1: Ports: '12345t', members=003e, untag=001e, fid=0
fid: 0
ports: 1 2 3 4 5t

При изменении сетевой схемы на следующую:
[ISP] -- WAN [tp-link wr1043nd(Backfire 10.03)] LAN1 -- eth0[x86(AA 12.09)]

TP-link wr1043nd настроен следующим образом:
VLAN 2:
info: VLAN 2: Ports: '01', members=0021, untag=0001, fid=0
fid: 0
ports: 0 1

Поднять pptp соединение не получается, при этом никаких отладочных
сообщений не наблюдается.

После был создан файл /etc/ppp/peers/isp с описанием подключения.
Выполнение команды pppd call isp nodetach debug завершается без каких
либо сообщений. Так же заметил, что ppp.sh завершается как только
становится доступен cервер.

Прошу помочь разобраться в проблеме. По возможности предоставлю всю
необходимую отладочную информацию.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


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

Re: [OpenWrt-Devel] DesignWare USB OTG dwc_otg issues with high-speed hubs

2012-08-11 Thread Nikolai Zhubr


Hi,
11.08.2012 0:13, Paul Fertser:

Hi Felipe,

On Fri, Aug 10, 2012 at 10:39:52PM +0300, Felipe Balbi wrote:

On Fri, Aug 10, 2012 at 10:35:20PM +0400, Paul Fertser wrote:

I'm using an RT3052F device (DIR-620 SOHO wifi router) with current
OpenWrt trunk and its USB port is handled by the dwc_otg driver. The
source is available from their repository:
https://dev.openwrt.org/browser/trunk/target/linux/ramips/files/drivers/usb/dwc_otg


there's no such driver in mainline kernel. We cannot support you. You
need to ask help from openwrt project.


Well, sorry, but i'm not sure that's entirely correct. People involved
in writing and using that driver are quite possibly hanging around
here. I know this is not an upstream driver (in fact it was ported
from Ralink's SDK by Layne Edwards) and i understand that vendor
drivers usually suck big time.

OTOH, vendor drivers are quite often a valuable source of the
information and having a link to a version that works on current
kernels might be beneficial as one can do a side-by-side comparison
and testing.

Of course i would appreciate someone sharing his ideas about another,
proper upstream driver that is usable on an RT3052 target.


Some version of this thing (dwc otg) is also used in AML8726M SoC which 
is found in a lot of internet tablets. I took a driver for RT3052 from 
openwrt (there are several other versions floating around) and spent 
quite some time trying to get it working correctly in gadget mode on my 
AML8726M-powered device. Combining several versions, I managed to fix 
some minor issues, but due to lack of USB knowledge and in the absence 
of any documentation/support from the manufacturer I gave up for now. I 
cound not even get g_serial to work completely. The hardware is messy, 
the driver is essentially in initial stage, no one seems to be 
interested/capable enough to rework/fix it properly. There were also 
some copyright/licensing issues IIRC.


Nikolai



I hope i put it clearly enough so that a person not interested in
non-upstream code won't waste his time reading this thread. I hope
this is enough of an excuse for CCing the list. If not, please let me
know.



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

Re: [OpenWrt-Devel] anyone have a working recipe for kexec-booting from USB storage?

2012-05-19 Thread Nikolai Zhubr


Hi,
19.05.2012 18:10, Brian J. Murrell:
[...]


To do this though, I need a kexec-ing image I can flash to my router to
become my "boot loader".

Anyone got one for an ar71xx?
Yes. I sometimes use kexec to chain-boot debian from USB hard disk on 
wndr3800. I'm using backfire 10.03.1 slightly patched and customized for 
my specific needs. So generally it is doable, but not quite 
out-of-the-box apparently.



Somewhat related, Quentin Armitage proposed a block-extroot-kexec to do
just this at
https://lists.openwrt.org/pipermail/openwrt-devel/2010-April/006671.html.
I wonder why it didn't even get a comment, nevermind not getting
committed.  Was there objection to it?
No idea. Anyway, most probably it won't work for ar71xx as is because of 
yet 2 issues (as of 10.03.1):


First:
--- arch/mips/kernel/machine_kexec.c.orig   2012-02-08 
01:58:13.0 +0300

+++ arch/mips/kernel/machine_kexec.c2012-02-20 22:19:11.0 +0300
@@ -52,7 +52,7 @@
reboot_code_buffer =
  (unsigned long)page_address(image->control_code_page);

-   kexec_start_address = image->start;
+   kexec_start_address = (unsigned long) phys_to_virt(image->start);

Second: drivers for onboard network stuff have to be compiled as modules 
and must NOT be loaded before kexecing, or otherwise kexec'ed system 
would crash at random points for some reason.


Finally, IIRC kexec feature was not even enabled by default in the 
kernel in backfire (though I might be wrong).


HTH
Nikolai



I would really love to see the openwrt project itself producing
"bootloader" flash images in addition to the traditional images they
currently produce so that people wanting this feature didn't have to
roll their own.

Any chance of that happening?

Cheers,
b.




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


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

Re: [OpenWrt-Devel] Lost connection to OpenWRT router

2012-04-09 Thread Nikolai Zhubr


Hi,
09.04.2012 15:45, Jo-Philipp Wich:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

http://wiki.openwrt.org/doc/howto/generic.failsafe


Alternatively, fresh "installation using the TFTP method" using reset 
button as described in http://wiki.openwrt.org/toh/netgear/wndr3700 
should also work very well for this device, regardless of whether 
current image got broken or not.


Nikolai


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+Cy+EACgkQdputYINPTPMQkwCfXuYbhT1uSzxZ8rKTdip2NoG/
IZ0An1hB/ViErmiUntYbq3yblfHVFfpC
=CWYR
-END PGP SIGNATURE-
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel




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

Re: [OpenWrt-Devel] NFS root during development

2012-02-24 Thread Nikolai Zhubr


24.02.2012 20:25, Christian Gagneraud:

Hi there,

I'm currently trying to add a new device (based on a ATSAM9G20), and
during development I would like to boot it on a NFS root.
Unfortunately I noticed that a couple of firstboot/preinit/init scripts
are messing up with either the rootfs and/or the network configuration.
Does anyone has any tricks for using a NFS root?


Some while ago I used NFS root for development too. I don't remember 
much details, but I'd say it appeared pretty easy to arrange. I guess I 
had to manually tweak or delete some of init scripts (obviously to avoid 
issues you mentioned), but otherwise had no problems with NFS root 
whatsoever.


HTH,
Nikolai


Especially I would like to:
- Avoid root remounting (or make openwrt aware onf the NFS root)
- Avoid mtd checking and stuff
- Avoid network interface reconfiguration (especially the hotplug call
on eth0 in /etc/rc.d/S10boot)

Regards,
Chris




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

[OpenWrt-Devel] Button Hotplug driver (compatability)

2012-02-24 Thread Nikolai Zhubr


Hi people,

First off, I'd note that button hotplug driver is a really great thing - 
lots of thanks to its creators!


As I sometimes use openwrt kernel with debian userspace, I've found that 
stock button_hotplug has no effect on debian. Even udevadm monitor shows 
nothing. Now, because researching debian's udev problems (if there are 
any) didn't seem quite attractive to me, I went another way around. I 
noticed that exactly zero in-tree drivers use uevent socket, but plenty 
of drivers use kobject_uevent_env() instead. So I modified 
button-hotplug to not use the socket but use kobject_uevent_env(). In 
the end, the driver even became somewhat smaller and simpler (imho). See 
the diff below. And, now it also works on debian! I've no idea if there 
are any serious downsides - I'm leaving judging up to the authors. The 
naming is a bit different, yes. (E.g. "ACTION" -> "BACTION", ...)
For reference: my hardware is netgear wndr3800, openwrt is 10.03.1, 
debian is 6.0
Note: trunk version of button_hotplug is slightly different, I haven't 
tried it yet, but it still uses the socket AFAICS (via a wrapper, though)



Thank you.
Nikolai

--- button-hotplug.c.orig   2012-02-24 13:38:30.0 +0300
+++ button-hotplug.c2012-02-24 14:04:39.0 +0300
@@ -25,7 +25,7 @@

 #define DRV_NAME   "button-hotplug"
 #define DRV_VERSION"0.3.1"
-#define DRV_DESC   "Button Hotplug driver"
+#define DRV_DESC   "Button Hotplug driver (for Debian)"

 #define BH_SKB_SIZE2048

@@ -53,6 +53,7 @@
 struct bh_priv {
unsigned long   seen[BH_BTN_COUNT];
struct input_handle handle;
+   struct kobject  bh_kobj;
 };

 struct bh_event {
@@ -60,12 +61,24 @@
char*action;
unsigned long   seen;

-   struct sk_buff  *skb;
+   struct bh_priv  *priv;
struct work_struct  work;
+
 };

-extern struct sock *uevent_sock;
-extern u64 uevent_next_seqnum(void);
+static struct kset *bh_kset;
+
+static struct attribute *bh_attrs[] = {
+   NULL,
+};
+
+static struct sysfs_ops bh_attr_ops = {
+};
+
+static struct kobj_type bh_ktype = {
+   .default_attrs = bh_attrs,
+   .sysfs_ops = &bh_attr_ops,
+};

 static char *button_names[BH_BTN_COUNT] = {
"BTN_0", "BTN_1", "BTN_2", "BTN_3", "BTN_4",
@@ -74,103 +87,25 @@

 /* 
-*/


-static int bh_event_add_var(struct bh_event *event, int argv,
-   const char *format, ...)
-{
-   static char buf[128];
-   char *s;
-   va_list args;
-   int len;
-
-   if (argv)
-   return 0;
-
-   va_start(args, format);
-   len = vsnprintf(buf, sizeof(buf), format, args);
-   va_end(args);
-
-   if (len >= sizeof(buf)) {
-   BH_ERR("buffer size too small\n");
-   WARN_ON(1);
-   return -ENOMEM;
-   }
-
-   s = skb_put(event->skb, len + 1);
-   strcpy(s, buf);
-
-   BH_DBG("added variable '%s'\n", s);
-
-   return 0;
-}
-
-static int button_hotplug_fill_event(struct bh_event *event)
-{
-   int ret;
-
-   ret = bh_event_add_var(event, 0, "HOME=%s", "/");
-   if (ret)
-   return ret;
-
-   ret = bh_event_add_var(event, 0, "PATH=%s",
-   "/sbin:/bin:/usr/sbin:/usr/bin");
-   if (ret)
-   return ret;
-
-   ret = bh_event_add_var(event, 0, "SUBSYSTEM=%s", "button");
-   if (ret)
-   return ret;
-
-   ret = bh_event_add_var(event, 0, "ACTION=%s", event->action);
-   if (ret)
-   return ret;
-
-   ret = bh_event_add_var(event, 0, "BUTTON=%s", event->name);
-   if (ret)
-   return ret;
-
-   ret = bh_event_add_var(event, 0, "SEEN=%ld", event->seen);
-   if (ret)
-   return ret;
-
-   ret = bh_event_add_var(event, 0, "SEQNUM=%llu", uevent_next_seqnum());
-
-   return ret;
-}
-
 static void button_hotplug_work(struct work_struct *work)
 {
struct bh_event *event = container_of(work, struct bh_event, work);
-   int ret = 0;
-
-   if (!uevent_sock)
-   goto out_free_event;
-
-   event->skb = alloc_skb(BH_SKB_SIZE, GFP_KERNEL);
-   if (!event->skb)
-   goto out_free_event;
-
-   ret = bh_event_add_var(event, 0, "%s@", event->action);
-   if (ret)
-   goto out_free_skb;
-
-   ret = button_hotplug_fill_event(event);
-   if (ret)
-   goto out_free_skb;
+   struct bh_priv  *priv = event->priv;
+   char env_baction[20];
+   char env_button[20];
+   char env_seen[20];
+   char *envp[] = { env_baction, env_button, env_seen, NULL };

-   NETLINK_CB(event->skb).dst_group = 1;
-   netlink_broadcast(uevent_sock, event->skb, 0, 1, GFP_KERNEL);
+   sprintf(env_baction, "BACTION=%s", event->action);
+   sprintf(env_bu

Re: [OpenWrt-Devel] kexec on mips

2012-02-21 Thread Nikolai Zhubr


21.02.2012 18:48, Peter Naulls:
[...]


- kexec_start_address = image->start;
+ kexec_start_address = (unsigned long) phys_to_virt(image->start);
kexec_indirection_page =
(unsigned long) phys_to_virt(image->head & PAGE_MASK);


Right. The kernel I'm using has this. But if you look back a bit through
the list, you'll see I had problems on ar71xx still - on Buffalo G300NH.
There was some grief in the serial handling, and I had to go via u-boot
to completely reset things. I mention this in case anyone else is
trying kexec.


My device is ar71xx too. And actually I had some (another) issue as 
well. I discovered that if network device(s) initialization is performed 
before kexec, the new kernel starts successfully but later the system 
ends up rebooting spontaneously.
I didn't mention this yet because I found this problem also "fixable" by 
compiling network drivers as modules and delaying their loading until 
after kexec might have been attempeted.

So currently, I do have it all working prefectly fine here.


Nikolai



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




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

[OpenWrt-Devel] kexec on mips

2012-02-20 Thread Nikolai Zhubr


Hello all,

I'm running both openwrt and debian on a mips-based wndr3800 netgear 
router/ap and I'm using kexec to arrange kind of dual-boot in a safe and 
comfortable manner.


Now, I've found that the following is critical for kexec to actually work:
--- arch/mips/kernel/machine_kexec.c.orig   2012-02-08 
01:58:13.0 +0300

+++ arch/mips/kernel/machine_kexec.c2012-02-20 22:19:11.0 +0300
@@ -52,7 +52,7 @@
reboot_code_buffer =
  (unsigned long)page_address(image->control_code_page);

-   kexec_start_address = image->start;
+   kexec_start_address = (unsigned long) phys_to_virt(image->start);
kexec_indirection_page =
(unsigned long) phys_to_virt(image->head & PAGE_MASK);

I've found that in openwrt repository this change was present (among 
others) in a big patchset targeted for kernel 2.6.30 and now it is still 
present as a small separate patch for 2.6.38 
(target/linux/generic/patches-2.6.38/303-mips_fix_kexec.patch) and maybe 
others. Meanwhile, the latest _stable_ openwrt for the moment (backfire 
10.03.1) was released with kernel 2.6.32 without this patch so I had to 
dig through some forums to find the reason of kexec not working 
out-of-the-box. I've just now checked and the latest kernel.org's stable 
kernel (3.2.6) does not seem to include this either. Ok, since I know 
the secret already I'll fix it for myself anytime, but maybe some kind 
soul could just submit this _one_ line upstream? I'd say this feature is 
really handy in some cases.


Thank you.

(Please CC me, I'm not subscribed to linux-mips)

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

Re: [OpenWrt-Devel] OpenWrt Logo

2012-02-09 Thread Nikolai Zhubr


09.02.2012 3:48, Jonathan McCrohan:

Hi,

Does the OpenWrt project have any alternate versions of the logo [1]? It
would be nice to have a small version logo that could be turned into a
favicon for both the website itself, and for LuCI.


...and also even to stick it on our favourite devices running openwrt :)

Nikolai



Jon

1: https://openwrt.org/.styles/img/openwrt-logo.png
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel




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

Re: [OpenWrt-Devel] Synopsys DWC OTG USB, round 4

2012-01-24 Thread Nikolai Zhubr


Hello Alan,
24.01.2012 19:45, Alan Stern:
[trim]

Does this mean that the hardware has only one FIFO?  Or only one for
each direction?  That's a pretty limited design.


Well EPs do have separate FIFOs, at least that's how the driver see it, 
but it looks like they are somehow not fully independent actually.


[trim]

It's even possible that the host will want to receive one packet from
one endpoint (presumably the FIFO can hold more than one packet's
worth?) followed by one packet from another endpoint.  Judging by your
description, it is impossible for the device to fulfill such requests.

You will simply have to live with mismatches.  There's nothing wrong
them, so long as the device responds to a mismatch with NAK.


Ok, so you mean that it would be correct to just allow mismatches happen 
as much as they will and consider handling them (that is, resubmitting 
data) as a normal workflow?


Thank you.
Nikolai



Alan Stern





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

Re: [OpenWrt-Devel] Designware USB OTG driver upstream questions

2012-01-24 Thread Nikolai Zhubr


Hi,
24.01.2012 19:12, Loh Tien Hock:

Hi Nikolai.

I tried the patch with g_serial. it needed some fix I have in my company's
repository for slave mode. Dma mode works correctly.


Wow, this puzzles me somewhat. I'll definitely try to test it and report 
back.


Thank you.
Nikolai

[trim]



These patches are not in mergable state, for the very least, they have

no information as to what they do, who wrote them, and all the other
meta-data we need to be able to read them.



Hi Greg,

Sorry for the late reply. The patch was obtained from these link:
http://patchwork.ozlabs.org/**patch/119923/
http://patchwork.ozlabs.org/**patch/119924/
http://patchwork.ozlabs.org/**patch/119925/
http://patchwork.ozlabs.org/**patch/119925/
http://patchwork.ozlabs.org/**patch/119926/
http://patchwork.ozlabs.org/**patch/119927/
http://patchwork.ozlabs.org/**patch/119928/
http://patchwork.ozlabs.org/**patch/119929/
http://patchwork.ozlabs.org/**patch/119930/
http://patchwork.ozlabs.org/**patch/119931/
http://patchwork.ozlabs.org/**patch/119932/

Are the meta-data in place? I'm still new to kernel patch, so please let
me know
if there's anymore things you need. Please advice on the work needed (as
to
rewrite, or to refactor).



Before even proceeding to any formal requirements: have you checked how
well it works with g_serial and g_ether?


Thank you.
Nikolai





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

[OpenWrt-Devel] Synopsys DWC OTG USB, round 4

2012-01-24 Thread Nikolai Zhubr


Hello people,

I'd like to hear some advice before I waste yet more time on this. 
Because my knowledge of USB concepts is close to nonexistent, I'll just 
present the situation as I see it currently with just all details I have.


As I understand it, the problem with this thing in device mode is that 
it is unable to automatically reorder IN data for different EPs 
submitted to it by the driver to match the sequence of EPs in IN tokens 
coming from host side. (A mismatch will be detected, however, and 
reported to the driver through an irq) So as long as the hardware can 
not provide necessary ordering by itself, this obviously has to be done 
in software (in the driver). Otherwise, the device might ocasionally 
still work in cases of very few IN EPs used and some very predictable IN 
patterns (for which g_file_storage is apparently an example) but will 
fail sooner or later.


Ok. The unpatched original dwc driver just does not care at all. The 
workaround code (supposedly created by Amlogic) does care but the 
reordering it applies is not based on any actual IN tokens. (To be 
short, its does some hard-coded preventive reordering, probably based on 
some experiments) So essentially, it just masqerades the problem a 
little bit rather than removes it (Well, at least now I know why 
android's adb via usb is so unstable on this device) So I suppose such 
workaround isn't really worth applying.


In order to guarantee proper ordering in software (in case there are 2 
or more IN EPs), the driver will need to:


1. not start submitting new IN data to Tx FIFO until a respective IN 
token is received;
2. either be notified of every new IN token separately, or have an 
opportunity to examine EP numbers of actual IN tokens received in a batch.


From my recent attempts I know that 1 is possible and simple, though 
delaying start of transfer would probably result in less-than-optimal 
overall speed in simple scenarios, but that it ok.


Now 2 is harder. While there are individual intktxfemp bits ("IN Token 
while Tx Fifo Empty") for all EPs, under heavy CPU load (or just 
occasionally) they might collide in a single irq and therefore will not 
be sufficient to build the required sequence unambiguously. Fetching 
informations on actual IN tokens from the controller is mentioned in 
header files and implemented in some function in the driver but it does 
not work on my device (all zeroes all the time, maybe the feature was 
dropped to simplify the silicon or header file is imprecise, no idea) So 
basically in this case of collided intktxfemp bits the only possibility 
is do a random guess (e.g. try the first one), then if "EP mismatch" 
interrupt occures, blacklist this EP temporarily and try another. Repeat 
as necessary. Very ugly.


So question is, does it even make sense? Is it worth trying or am I too 
wrong somethere?


Thank you.
Nikolai


22.01.2012 15:12, I wrote:

Hello,
22.01.2012 1:40, I wrote:
[...]

if matters). Without that, controller starts raising "IN Token Received
with EP mismatch" instead of normal "Transfer complete" bit. If I
understand it correctly, this means that Tx FIFO happened to be filled
in some particular order that controller disliked (and refused). I've
also found a fragment of code with possibly relevant comment (quoted
below). Indeed, apparently this "EP mismatch" event is not handled
anywhere in the driver (other than providing a line for dmesg). If it
should, then I'd guess it means the driver is just plain unfininshed and
I have no idea if it can even be fixed with a reasonable effort. Not


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
I can fix this workaround to actually do what it tries to.
(This somewhat reduces the whole usefullness of EPs probably, but at
least the damned thing stops throwing "EP mismatch", I've checked)


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

Re: [OpenWrt-Devel] DWC OTG USB, round 3

2012-01-22 Thread Nikolai Zhubr


Hello,
22.01.2012 1:40, I wrote:
[...]

if matters). Without that, controller starts raising "IN Token Received
with EP mismatch" instead of normal "Transfer complete" bit. If I
understand it correctly, this means that Tx FIFO happened to be filled
in some particular order that controller disliked (and refused). I've
also found a fragment of code with possibly relevant comment (quoted
below). Indeed, apparently this "EP mismatch" event is not handled
anywhere in the driver (other than providing a line for dmesg). If it
should, then I'd guess it means the driver is just plain unfininshed and
I have no idea if it can even be fixed with a reasonable effort. Not


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 
I can fix this workaround to actually do what it tries to.
(This somewhat reduces the whole usefullness of EPs probably, but at 
least the damned thing stops throwing "EP mismatch", I've checked)


Thank you.
NIkolai


sure what was meant exactly by "one endpoint at once" though.. Of course
usefull gadget drivers would probably employ > 1 EPs, even
g_file_storage does so? Strange thing.

Thank you.
Nikolai

/* Reactive the EP */
dwc_otg_ep_activate(GET_CORE_IF(pcd), &ep->dwc_ep);
if (ep->stopped) {
ep->stopped = 0;
/* If there is a request in the EP queue start it */

/** @todo FIXME: this causes an EP mismatch in DMA mode.
* epmismatch not yet implemented. */

/*
* Above fixme is solved by implmenting a tasklet to call the
* start_next_request(), outside of interrupt context at some
* time after the current time, after a clear-halt setup packet.
* Still need to implement ep mismatch in the future if a gadget
* ever uses more than one endpoint at once
*/
ep->queue_sof = 1;
tasklet_schedule (pcd->start_xfer_tasklet);
}
/* Start Control Status Phase */
do_setup_in_status_phase(pcd);

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html




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

[OpenWrt-Devel] DWC OTG USB, round 3 (was: hardware driver <-> gadget driver...)

2012-01-21 Thread Nikolai Zhubr


Hello Paul and Alan,
21.01.2012 1:17, Paul Zimmerman:

On Fri, 20 Jan 2012, Alan Stern wrote:


This is a serious problem.  The gadget API does not specify whether
usb_ep_enable and usb_ep_disable should be able to run in interrupt
context.  Consequently we end up with UDC drivers like your DWC thing
in which the routines cannot run in interrupt context, together with
gadget drivers like g_serial which do call them in interrupt context.

It may be that the best solution is for the composite.c driver to
implement Set-Config and Set-Interface requests in a workqueue, so that
the calls could be made in process context.  For now, you can avoid the
problem by not calling dma_alloc_coherent in your endpoint-setup
routine.

g_file_storage doesn't have this problem because it uses its own kernel
thread for handling these requests.


Actually, dma_alloc_coherent() takes a gfp_t parameter, so you should be
able to set GFP_ATOMIC and do the allocation from interrupt context.

The problem comes from dma_free_coherent(). It unconditionally checks for
being called in process context, and gives a warning if not. This check was
added a year or two ago, for something in the ARM architecture IIRC. I keep
expecting that this will get fixed at some point, but so far it hasn't.

Based on your comments I decided to move some preparations to a 
workqueue and there are no issues with those allocations anymore.


I've now finally got g_serial fully recognised on another side (by host 
PC) and was even able to open the respective serial device there, but 
unfortunately for that to succeed I had to also disable (just throw 
away) all requests for EPs != 0 (I did this in ep_queue in dwc driver, 
if matters). Without that, controller starts raising "IN Token Received 
with EP mismatch" instead of normal "Transfer complete" bit. If I 
understand it correctly, this means that Tx FIFO happened to be filled 
in some particular order that controller disliked (and refused). I've 
also found a fragment of code with possibly relevant comment (quoted 
below). Indeed, apparently this "EP mismatch" event is not handled 
anywhere in the driver (other than providing a line for dmesg). If it 
should, then I'd guess it means the driver is just plain unfininshed and 
I have no idea if it can even be fixed with a reasonable effort. Not 
sure what was meant exactly by "one endpoint at once" though.. Of course 
usefull gadget drivers would probably employ > 1 EPs, even 
g_file_storage does so? Strange thing.


Thank you.
Nikolai

/* Reactive the EP */
dwc_otg_ep_activate(GET_CORE_IF(pcd), &ep->dwc_ep);
if (ep->stopped) {
ep->stopped = 0;
/* If there is a request in the EP queue start it */

/** @todo FIXME: this causes an EP mismatch in DMA mode.
 * epmismatch not yet implemented. */

/*
 * Above fixme is solved by implmenting a tasklet to call the
 * start_next_request(), outside of interrupt context at some
 * time after the current time, after a clear-halt setup packet.
 * Still need to implement ep mismatch in the future if a gadget
 * ever uses more than one endpoint at once
 */
ep->queue_sof = 1;
tasklet_schedule (pcd->start_xfer_tasklet);
}
/* Start Control Status Phase */
do_setup_in_status_phase(pcd);

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

Re: [OpenWrt-Devel] Driver(s) for Synopsys' DesignWare USB OTG

2012-01-20 Thread Nikolai Zhubr


20.01.2012 17:10, Alexander Gordeev:
[...]

However, there were at least several attempts to push dwc-otg to
mainline through linuxppc-dev list. This is what I meant.


Ah, ok. AFAICS the thing on linuxppc-dev failed totally, and I can see 
good reasons why. (It was based on an outdated version, only targeted 
very limited set of devices and one single platform, lacked devel 
history, mixed driver code with some ppc platform stuff, etc etc)

However, maybe I'll try to examine it too (if time permits)




The only excuse I'd see for creating yet another repository is if it
appears too hard (or too long) to get stuff accepted to openwrt (AFAICS
openwrt maintainers are somewhat overburdened already, but no idea how
much really)


I think the real goal is to have this driver in the mainline kernel and


Yes.


then it will be in openwrt automatically. Ok, it would be cool to merge
at least those several implementations inside openwrt (octeon,
ramips, etc). But there are others too so I think this attempt should
not be bound to Openwrt or any other project or we will always find
different drivers all other the net.


Well, openwrt targets many different devices and tries to keep close to 
mainline. It is even no problem generally to borrow some driver from 
openwrt tree for a platform which openwrt does not immediately target 
yet (and that's what I do right now actually). There might be some more 
complications with preparing and submitting patches in such case though. 
But still, I think it'd be a step towards mainline.


Thank you.
Nikolai





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

Re: [OpenWrt-Devel] Driver(s) for Synopsys' DesignWare USB OTG

2012-01-20 Thread Nikolai Zhubr


Hello Conor,

20.01.2012 14:09, Conor O'Gorman:


I would suggest gathering all the available versions into a repository.
Not merged, just gathered together, organised by version and source.
That would be a step towards comparing versions, and also gaining the
attention of the relevant people.


Yes, that would make sense probably. I'll think about it.

Thank you.
Nikolai


So this would be a possible the directory structure:

2.40a
- octeon
2.60a
- ppp4xx 1.05
- ipmate
2.70
2.72a
- dd-wrt
- fonosfera

Those versions found with a google for

"defineDWC_DRIVER_VERSION"

This discussion is one of the more extensive I have seen. And the people
involved appear to have experience with the driver:

http://patchwork.ozlabs.org/patch/57332/

Conor


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

Re: [OpenWrt-Devel] Driver(s) for Synopsys' DesignWare USB OTG

2012-01-20 Thread Nikolai Zhubr


Hello Alexander,

20.01.2012 13:01, Alexander Gordeev:
[trim]


IMO a separate repository (or adoption into staging) would be better
because there are too many interested parties and also the main dwc-otg
development happens not in openwrt.



Where does it happen?

I've actually got a feeling that in fact no real development is now 
happening, but rather some manufacturers and interested users make their 
copies (of basically the same thing), reformat tabs and whitespace all 
over 200k lines of code as they feel cool, then in some cases introduce 
several random 3-line additions/fixes in order to make their specific 
device just do what they need at the moment... and finally (sometimes) 
publish this as "new shining" version. Now this is NOT a development, 
IMHO. I'd be happy if you prove me wrong however.


The only excuse I'd see for creating yet another repository is if it 
appears too hard (or too long) to get stuff accepted to openwrt (AFAICS 
openwrt maintainers are somewhat overburdened already, but no idea how 
much really)



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

Re: [OpenWrt-Devel] Driver(s) for Synopsys' DesignWare USB OTG

2012-01-19 Thread Nikolai Zhubr


Hello Conor,

I'm now trying ver 2.72 basically from openwrt trunk with some tiny 
amlogic-specific additions. I think 2.72 is most relevant currently (and 
nothing newer exists apparently) but device-mode does not work well for 
me yet. And 2.60 was no better for me in this respect. Can't test 
host-mode at the moment because it is quite difficult to arrange as long 
as USB is the only wired interface physycally available and wifi not 
working yet (It's a tablet, ARMv7-based)


If I manage to get it to work satisfactory at least in device-mode, I'll 
certainly share my findings and either try to submit patches to openwrt 
(I'd prefer that way) or maybe create a separate repository somewhere 
(downside in this case would be yet more scattering of this driver, 
which I'd like to avoid). If all goes well then I'll probably test 
host-mode a bit later (Not sure when it happens exactly)


Anyway, it would be nice to eventually combine all those various 
versions floating around (targeted for different architectures and 
revisions of controller) into a single unified version.


So I suppose you'll be able to do some testing in host-mode on your 
platform, if it happens to be necessary?



Thank you,
Nikolai


19.01.2012 16:58, Conor O'Gorman:


Hello Nikolai,

I am currently looking at this driver as used on the Lantiq Danube
platform, in Openwrt.

I notice there are a few version strings around the net, 2.72, 2.60
being the most common, but apparently stretching back to a 1.05 and 1.0.
But I believe that even version with the same string have been modified
thereafter in various repositories.

Version strings,
"2.72a 24-JUN-2008"
"2.60a 22-NOV-2006"
"2.40a 10-APR-2006"
"1.05"
"1.0"

I am interested in an improved driver, and can do work to that end. At
the moment I have the 2.60a on a MIPS big endian processor, using host
mode.

Thanks,
Conor O'Gorman


On Sun, 2012-01-08 at 16:56 +0400, Nikolai Zhubr wrote:

Hello Piter,

08.01.2012 7:12, you wrote:

2012/1/8 Nikolai Zhubr:

Hello developers,

I'm trying to find/combine/fix a driver for Synopsys' DesignWare USB
controller. This thing is USB 2.0 host/slave/otg capable and is used in
various SoCs including Amlogic 8726M, Ralink RT305x, and probably more.


[...trim...]


Please see:
http://marc.info/?l=linux-usb&m=129906859817430&w=2

Ah, thanks. So sadly uncoordinated work in this area is quite common.
However, in case of Synopsys the situation is even more disappointing
because initially it _was_ a single driver! What probably lacked was
some shared repository and proper communication between developers to
stay in sync. Maybe there were also licensing issues at some point,
though currently file headers contain rather reasonable (imho)
permissive license from Synopsys.


I am not sure we can combine all Synopsys USB drivers to single file, but we


Synopsys driver which I examine consists of 16 files (each of 2
versions), 200k lines total. I've already perpared some few smaller
files for version merging. So probably it is doable, but quite a lot of
work, therefore I wouldn't like it to be wasted.


can try combine similar IP versions to one file, this work may need all Synopsys
USB IP driver maintainer work together.


Exactly. This is why I'm now trying to find all relevant people to begin
with.

Thank you.
Nikolai.

Please CC me, I'm not subscribed to the lists.






Thank you.
Nikolai.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html






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







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

[OpenWrt-Devel] [PATCH] DWC otg usb (ramips): compilation fixes and trivial bugfix in slave mode

2012-01-12 Thread Nikolai Zhubr


Hello people,

The attached trivial patch updates slave-mode parts in dwc otg usb 
driver for ramips target. It doesn't touch anything host-mode. The first 
2 fragments correct an error in passing argument, this is immediately 
clear from comparing with (already correct) calls to 
dwc_otg_hcd_remove/dwc_otg_hcd_init of host-mode code around and/or 
looking at respective declarations. All other fragments just fix 
compatability with various kernel versions. Maybe a little bit too much 
of version mess, but there are still ifdefs for 2.6.19 in the trunk 
anyway and I have some reasons to compile it also for 2.6.34. At the 
moment, slave-mode parts are not used in openwrt but used by me (well, 
sort of, on ARM platform though). With the patch applied, the driver 
still does not actually work on my device yet but this is expected and 
will probably be addressed later. At least it compiles and loads.


[8.93] dwc_otg: version 2.72a 24-JUN-2008
[8.93] dwc_otg dwc_otg.0: request_mem_region failed

Posting as attachment to avoid line wrapping, please let me know how if 
this is inappropriate. Hopefully the patch is too simple for discussion 
anyway.


Thank you.
Nikolai




diff -ur trunk/target/linux/ramips/files/drivers/usb/dwc_otg/dwc_otg_driver.c 
trunk.test/target/linux/ramips/files/drivers/usb/dwc_otg/dwc_otg_driver.c
--- trunk/target/linux/ramips/files/drivers/usb/dwc_otg/dwc_otg_driver.c
2012-01-10 00:33:03.0 +0300
+++ trunk.test/target/linux/ramips/files/drivers/usb/dwc_otg/dwc_otg_driver.c   
2012-01-13 04:18:17.0 +0300
@@ -634,7 +634,7 @@
 
 #ifndef DWC_HOST_ONLY
if (otg_dev->pcd) {
-   dwc_otg_pcd_remove(pdev);
+   dwc_otg_pcd_remove(&pdev->dev);
}
 #endif
if (otg_dev->core_if) {
@@ -823,7 +823,7 @@
/*
 * Initialize the PCD
 */
-   retval = dwc_otg_pcd_init(pdev);
+   retval = dwc_otg_pcd_init(&pdev->dev);
if (retval != 0) {
DWC_ERROR("dwc_otg_pcd_init failed\n");
otg_dev->pcd = NULL;
diff -ur trunk/target/linux/ramips/files/drivers/usb/dwc_otg/dwc_otg_hcd.c 
trunk.test/target/linux/ramips/files/drivers/usb/dwc_otg/dwc_otg_hcd.c
--- trunk/target/linux/ramips/files/drivers/usb/dwc_otg/dwc_otg_hcd.c   
2012-01-10 00:33:03.0 +0300
+++ trunk.test/target/linux/ramips/files/drivers/usb/dwc_otg/dwc_otg_hcd.c  
2012-01-07 02:15:54.0 +0300
@@ -1781,8 +1781,10 @@
desc->wHubCharacteristics = 0x08;
desc->bPwrOn2PwrGood = 1;
desc->bHubContrCurrent = 0;
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,39)
desc->u.hs.DeviceRemovable[0] = 0;
desc->u.hs.DeviceRemovable[1] = 0xff;
+#endif
break;
case GetHubStatus:
DWC_DEBUGPL(DBG_HCD, "DWC OTG HCD HUB CONTROL - "
diff -ur trunk/target/linux/ramips/files/drivers/usb/dwc_otg/dwc_otg_hcd.h 
trunk.test/target/linux/ramips/files/drivers/usb/dwc_otg/dwc_otg_hcd.h
--- trunk/target/linux/ramips/files/drivers/usb/dwc_otg/dwc_otg_hcd.h   
2012-01-10 00:33:03.0 +0300
+++ trunk.test/target/linux/ramips/files/drivers/usb/dwc_otg/dwc_otg_hcd.h  
2012-01-13 00:40:18.0 +0300
@@ -36,7 +36,11 @@
 
 #include 
 #include 
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,35)
 #include 
+#else
+#include <../drivers/usb/core/hcd.h>
+#endif
 
 struct dwc_otg_device;
 
diff -ur trunk/target/linux/ramips/files/drivers/usb/dwc_otg/dwc_otg_pcd.c 
trunk.test/target/linux/ramips/files/drivers/usb/dwc_otg/dwc_otg_pcd.c
--- trunk/target/linux/ramips/files/drivers/usb/dwc_otg/dwc_otg_pcd.c   
2012-01-10 00:33:03.0 +0300
+++ trunk.test/target/linux/ramips/files/drivers/usb/dwc_otg/dwc_otg_pcd.c  
2012-01-13 03:56:36.0 +0300
@@ -80,7 +80,11 @@
 # include 
 #endif
 
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,24)
+#include 
+#else
 #include 
+#endif
 
 #include "dwc_otg_driver.h"
 #include "dwc_otg_pcd.h"
@@ -412,6 +416,7 @@
kfree(request);
 }
 
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,23)
 /**
  * This function allocates an I/O buffer to be used for a transfer
  * to/from the specified endpoint.
@@ -489,6 +494,7 @@
kfree(buf);
}
 }
+#endif
 
 
 /**
@@ -571,8 +577,10 @@
 
if(ep->dwc_ep.is_in)
{
+#if (LINUX_VERSION_CODE < KERNEL_VERSION(2,6,24)) || defined(CONFIG_MIPS)
if(usb_req->length)
dma_cache_wback_inv((unsigned 
long)usb_req->buf, usb_req->length + 2);
+#endif
}
}
 
@@ -1518,8 +1526,10 @@
.alloc_request  = dwc_otg_pcd_alloc_request,
.free_request   = dwc_otg_pcd_free_request,
 
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,23)
.alloc_buffer   = dwc_otg_pcd_alloc_buffer,
.free_buffer= dwc_otg_pcd_free_buffer,
+#endif
 
.queue  = dwc_otg

Re: [OpenWrt-Devel] Driver(s) for Synopsys' DesignWare USB OTG

2012-01-09 Thread Nikolai Zhubr


Hello Leo,

09.01.2012 9:17, Leo Li:

On Sun, Jan 8, 2012 at 8:56 PM, Nikolai Zhubr  wrote:

2012/1/8 Nikolai Zhubr:


Hello developers,

I'm trying to find/combine/fix a driver for Synopsys' DesignWare USB
controller. This thing is USB 2.0 host/slave/otg capable and is used in
various SoCs including Amlogic 8726M, Ralink RT305x, and probably more.


[...trim...]


I think the challenge of cooperation in situation like this is that
most companies don't like to advertise the source of the licensed IP
block.  Even the owner of the IP block doesn't list all users of the
block(maybe business requirement). It was really hard to find out if
the same IP has been used by anyone else.  Also the owner of this USB
IP block has been changed for several times(ARC, TDI, ChipIdea, and
Synopsys) which made it even more difficult to tell.


Ah, I see. It explains.
But communicating in private and keeping some public repository up to 
date would still be allowed I suppose?








I am not sure we can combine all Synopsys USB drivers to single file, but
we



Synopsys driver which I examine consists of 16 files (each of 2 versions),
200k lines total. I've already perpared some few smaller files for version
merging. So probably it is doable, but quite a lot of work, therefore I
wouldn't like it to be wasted.


I didn't examine the Synopsys driver myself.  But if it is so complex
as you described, it might be better to start with the in-tree drivers
IMO.


Unfortunately its far beyond my capabilities at the moment. Besides, it 
looks like huge effort has already been invested into the existing 
driver, so to me it seems fixing it rather than starting from scratch 
would be more realistic anyway (unless a company with unlimited 
resources step in...)



Thank you.
Nikolai.



- Leo




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

Re: [OpenWrt-Devel] Driver(s) for Synopsys' DesignWare USB OTG

2012-01-09 Thread Nikolai Zhubr


Hello Peter,

09.01.2012 6:12, Peter Chen:

I am not sure we can combine all Synopsys USB drivers to single file, but we


Synopsys driver which I examine consists of 16 files (each of 2
versions), 200k lines total. I've already perpared some few smaller
files for version merging. So probably it is doable, but quite a lot
of work, therefore I wouldn't like it to be wasted.

I mean one file is just a common udc driver for all Synopsys, not all usb file.
For ehci, I think it will be easier to use single file as well as
some specific SoC's quirks if needed.
For udc, as there is no standard spec for how usb device should be designed,
maybe different Synopsys IPs have a little different for work flow.
For otg, it  should be not difficult after we split PHY's operation
from the otg, as common otg operation is the same.



can try combine similar IP versions to one file, this work may need all Synopsys
USB IP driver maintainer work together.


Exactly. This is why I'm now trying to find all relevant people to
begin with.

I know someone(@Pengutronix and @linux.intel.com) is doing that. I think first
we should find which driver file at current code base is most capable and
compatible. I would like to help it, and verify it at Freescale i.MX SoCs.


Ok. Because my resources are limited (and my knowledge is actually 
limited too) I'll list what exactly I'm able (and willing) to do:


- split formatting/naming/uninteresting changes from algorythmical 
changes, prepare clean diffs as necessary (boring work, but anyway);

- bisect changes which make the driver stop working on my tablet;
- try whichever driver parameters and see what happens to my tablet;
- connect the tablet to a regular linux PC with USB cable, do some 
tests, capture traffic dumps as necessary;

- connect some devices to the tablet, do tests, report results;

and with some luck:
- prepare bufixes (depending very much on how simple is the bug).

So basically my effort would probably only be usefull in cooperation 
with someone with more knowledge and understanding of the situation in 
whole. Otherwise it would be more wasting of time.


If usb issues were solved, it might make some sense to try to create 
e.g. a generic openwrt target for 8726m-based tablet. (Of course it 
wouldn't allow to use the device for its intended purpose yet, but still 
might be interesting as kind of devel/testing reference option)



Thank you.
Nikolai.




Thank you.
Nikolai.

Please CC me, I'm not subscribed to the lists.






Thank you.
Nikolai.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html






--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html





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

Re: [OpenWrt-Devel] Driver(s) for Synopsys' DesignWare USB OTG

2012-01-08 Thread Nikolai Zhubr


Hello Piter,

08.01.2012 7:12, you wrote:

2012/1/8 Nikolai Zhubr:

Hello developers,

I'm trying to find/combine/fix a driver for Synopsys' DesignWare USB
controller. This thing is USB 2.0 host/slave/otg capable and is used in
various SoCs including Amlogic 8726M, Ralink RT305x, and probably more.


[...trim...]


Please see:
http://marc.info/?l=linux-usb&m=129906859817430&w=2
Ah, thanks. So sadly uncoordinated work in this area is quite common. 
However, in case of Synopsys the situation is even more disappointing 
because initially it _was_ a single driver! What probably lacked was 
some shared repository and proper communication between developers to 
stay in sync. Maybe there were also licensing issues at some point, 
though currently file headers contain rather reasonable (imho) 
permissive license from Synopsys.



I am not sure we can combine all Synopsys USB drivers to single file, but we


Synopsys driver which I examine consists of 16 files (each of 2 
versions), 200k lines total. I've already perpared some few smaller 
files for version merging. So probably it is doable, but quite a lot of 
work, therefore I wouldn't like it to be wasted.



can try combine similar IP versions to one file, this work may need all Synopsys
USB IP driver maintainer work together.


Exactly. This is why I'm now trying to find all relevant people to begin 
with.


Thank you.
Nikolai.

Please CC me, I'm not subscribed to the lists.






Thank you.
Nikolai.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html






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

[OpenWrt-Devel] Fwd: Driver(s) for Synopsys' DesignWare USB OTG

2012-01-07 Thread Nikolai Zhubr

I'm re-sending this (because first try was rejected by mailman).

 Original Message 
Subject: Driver(s) for Synopsys' DesignWare USB OTG
Date: Sat, 07 Jan 2012 21:30:10 +0400
From: Nikolai Zhubr 
To: linux-...@vger.kernel.org, openwrt-devel@lists.openwrt.org, 
linuxppc-...@lists.ozlabs.org, supp...@amlogic.com

Hello developers,

I'm trying to find/combine/fix a driver for Synopsys' DesignWare USB 
controller. This thing is USB 2.0 host/slave/otg capable and is used in 
various SoCs including Amlogic 8726M, Ralink RT305x, and probably more.

There is some code floating around, partly usable, but all I could see 
for now is really not perfect. I also saw commit logs on linuxppc-dev, 
but failed to find out what repository they are related to. I'd like to 
know if someone is currently developing/testing/maintaining the driver 
or is planning to do so in the near future (in a FOSS-friendly manner - 
making development results public immediately and with eventual goal of 
inclusion into mainline) in order to avoid duplicate/uncoordinated work 
and waste of effort.

I'm currently examining 2 versions (That is, 2 sets of files):

1. From android kernel for 8726m-based tablets (like the one I own). 
Usable to some extent, but there are issues (e.g. it looks like certain 
packets get corrupted, reproducibly, relevant dumps are available)

2. From openwrt kernel for RT305x-based routers. The code looks a bit 
more tidy, but not quite well updated (slave-mode parts are unused in 
openwrt and they can not even be compiled for modern kernels without 
certain patching; have not tried host-mode on the hardware yet)

Quite obviously both versions originated from the same code initially, 
but subsequently were apparently tested/corrected/updated by separate 
teams. It is not quite clear if all bugfixes were cross-applied 
carefully (if at all). I was initially hoping that compare and bisect 
will just do the job, but the driver is quite huge... and some files 
have diverged substantially in the 2 versions, so at the moment I'm a 
bit fed up and will probably resume a bit later. Meanwhile, I'd be happy 
to discuss the subject with whoever interested in order to plan my 
further steps.

Please CC me, I'm not subscribed to the lists.

Thank you.
Nikolai.

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

38 matches

Mail list logo