Re: Wifi driver stability improved -- wrong patch reverted

2009-09-05 Thread Paul Fertser
Nicola Mfb nicola@gmail.com writes:
 On Fri, Sep 4, 2009 at 10:07 PM, Paul Fertserfercer...@gmail.com wrote:
 Can you confirm it's a regression and if yes, in which version it did work
 without issues?

 I cannot confirm, I always had problem in some ways.
 It may be only due the fact that as I developed nwa I stressed a lot
 wifi during time.

I see. Our main wifi-related goal currently is not to actually fix the
driver, it's rather to bandaid it to avoid most easily reproducible
races most of the time.

I do not consider races with rfkill at all currently, i can't see why
spend time on that since rfkill is redudant and useless in our case.

 Another hint is the wow interrupt, I noted it a lot of time, is it
 harmful?

Probably it means only that an unpowered module was powered, i don't
think that's something to worry about.

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercer...@gmail.com

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Wifi driver stability improved -- wrong patch reverted

2009-09-04 Thread Paul Fertser
Hi,

I remember you were testing the fsoraw method and indeed proved that it
doesn't work properly with the latest kernel. After some discussion we
reverted the offending patch and now the latest SHR kernel should provide
the same level of stability as .28.

Please try again and report the results.

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercer...@gmail.com

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: Wifi driver stability improved -- wrong patch reverted

2009-09-04 Thread Nicola Mfb
On Fri, Sep 4, 2009 at 1:08 PM, Paul Fertserfercer...@gmail.com wrote:
 Hi,

 I remember you were testing the fsoraw method and indeed proved that it
 doesn't work properly with the latest kernel. After some discussion we
 reverted the offending patch and now the latest SHR kernel should provide
 the same level of stability as .28.

 Please try again and report the results.

I'm not sure but latest SHR kernel seems to be
2d158aae9d8d36f575504f59884ed8e80802efe2, and that does not include
the wifi revert.

I built a3587e4ed77974adfb057af261aaeea4022018e8 and commented the HTC
line suggested in your patch, and my freerunner crashed, but anyway I
played too much with my oe tree and I'm quite sure I was wrong
somewhere (as the HTC line is on a different position than your patch
suggests). I'm going to rebuild again and report.

Regards

 Nicola

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: Wifi driver stability improved -- wrong patch reverted

2009-09-04 Thread arne anka
 I remember you were testing the fsoraw method and indeed proved that it
 doesn't work properly with the latest kernel. After some discussion we
 reverted the offending patch and now the latest SHR kernel should provide
 the same level of stability as .28.

 Please try again and report the results.


sounds great!
but i am on debian and thus have probably to wait for the pkg-fso guys to  
create a new package, because i am not sure how (and if) the kernel differ  
between debian and shr.



___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: Wifi driver stability improved -- wrong patch reverted

2009-09-04 Thread Vinzenz Hersche
Am Freitag, 4. September 2009 13.08:05 schrieb Paul Fertser:
 Hi,
 
 I remember you were testing the fsoraw method and indeed proved that it
 doesn't work properly with the latest kernel. After some discussion we
 reverted the offending patch and now the latest SHR kernel should provide
 the same level of stability as .28.
 
 Please try again and report the results.
 
hello paul,
i saw the commit, tried it, and it's realy great!
since this i've ben able to connect every wlan :)

thx!

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: Wifi driver stability improved -- wrong patch reverted

2009-09-04 Thread Paul Fertser
Nicola Mfb nicola@gmail.com writes:
 I built a3587e4ed77974adfb057af261aaeea4022018e8 and commented the HTC
 line suggested in your patch

Oh no! We reverted Werner's patch and with that nothing should be
commented, it should work as is. And yes, you're building
andy-tracking HEAD, that's right revision.

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercer...@gmail.com

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: Wifi driver stability improved -- wrong patch reverted

2009-09-04 Thread Paul Fertser
Nicola Mfb nicola@gmail.com writes:
 I remember you were testing the fsoraw method and indeed proved that it
 doesn't work properly with the latest kernel. After some discussion we
 reverted the offending patch and now the latest SHR kernel should provide
 the same level of stability as .28.

 Please try again and report the results.

 I'm not sure but latest SHR kernel seems to be
 2d158aae9d8d36f575504f59884ed8e80802efe2, and that does not include
 the wifi revert.

http://build.shr-project.org/shr-unstable/ipk/om-gta02/kernel-2.6.29-rc3_2.6.29-oe11+gitr119844+a3587e4ed77974adfb057af261aaeea4022018e8-r3.5_om-gta02.ipk

opkg update  opkg upgrade should deliver it automatically.

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercer...@gmail.com

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: Wifi driver stability improved -- wrong patch reverted

2009-09-04 Thread William Kenworthy
That link looks like its only 762 bytes - somethings wrong?

On Fri, 2009-09-04 at 16:21 +0400, Paul Fertser wrote:
 Nicola Mfb nicola@gmail.com writes:
  I remember you were testing the fsoraw method and indeed proved that it
  doesn't work properly with the latest kernel. After some discussion we
  reverted the offending patch and now the latest SHR kernel should provide
  the same level of stability as .28.
 
  Please try again and report the results.
 
  I'm not sure but latest SHR kernel seems to be
  2d158aae9d8d36f575504f59884ed8e80802efe2, and that does not include
  the wifi revert.
 
 http://build.shr-project.org/shr-unstable/ipk/om-gta02/kernel-2.6.29-rc3_2.6.29-oe11+gitr119844+a3587e4ed77974adfb057af261aaeea4022018e8-r3.5_om-gta02.ipk
 
 opkg update  opkg upgrade should deliver it automatically.
 
-- 
William Kenworthy bi...@iinet.net.au
Home in Perth!


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: Wifi driver stability improved -- wrong patch reverted

2009-09-04 Thread William Kenworthy
my mistake - looks like a meta-package ... :(

BillK



On Fri, 2009-09-04 at 21:29 +0800, William Kenworthy wrote:
 That link looks like its only 762 bytes - somethings wrong?
 
 On Fri, 2009-09-04 at 16:21 +0400, Paul Fertser wrote:
  Nicola Mfb nicola@gmail.com writes:
   I remember you were testing the fsoraw method and indeed proved that it
   doesn't work properly with the latest kernel. After some discussion we
   reverted the offending patch and now the latest SHR kernel should provide
   the same level of stability as .28.
  
   Please try again and report the results.
  
   I'm not sure but latest SHR kernel seems to be
   2d158aae9d8d36f575504f59884ed8e80802efe2, and that does not include
   the wifi revert.
  
  http://build.shr-project.org/shr-unstable/ipk/om-gta02/kernel-2.6.29-rc3_2.6.29-oe11+gitr119844+a3587e4ed77974adfb057af261aaeea4022018e8-r3.5_om-gta02.ipk
  
  opkg update  opkg upgrade should deliver it automatically.
  
-- 
William Kenworthy bi...@iinet.net.au
Home in Perth!


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: Wifi driver stability improved -- wrong patch reverted

2009-09-04 Thread Nicola Mfb
On Fri, Sep 4, 2009 at 2:14 PM, Paul Fertserfercer...@gmail.com wrote:
 Nicola Mfb nicola@gmail.com writes:
 I built a3587e4ed77974adfb057af261aaeea4022018e8 and commented the HTC
 line suggested in your patch

 Oh no! We reverted Werner's patch and with that nothing should be
 commented, it should work as is. And yes, you're building
 andy-tracking HEAD, that's right revision.

Damn me! looking in the images directory and stucked in the old duscussion ;)
reflashed again and upgraded to be sure to use the last kernel:

opkg list_installed |grep kernel :
kernel - 2.6.29-oe11+gitr119844+a3587e4ed77974adfb057af261aaeea4022018e8-r3.5 -

rebooted and tryied with nwa, starting and quitting about 4/5 times resulted in:

[  692.365000] BMI Get Target Info: Exit (ver: 0x2059 type: 0x1)
[  692.365000] eth0 (sdio_ar6000): not using net_device_ops yet
[  692.425000] AR6000 Reg Code = 0x4060
[  715.78] mmc1: card 0001 removed
[  715.82] ar6000_wow interrupt
[  715.985000] s3c2440-sdi s3c2440-sdi: powered down.
[  715.985000] s3c2440-sdi s3c2440-sdi: powered down.
[  719.815000] s3c2440-sdi s3c2440-sdi: host detect has no irq available
[  719.815000] mapped channel 0 to 0
[  719.955000] s3c2440-sdi s3c2440-sdi: powered down.
[  719.955000] s3c2440-sdi s3c2440-sdi: running at 0kHz (requested: 0kHz).
[  719.955000] s3c2440-sdi s3c2440-sdi: running at 196kHz (requested: 195kHz).
[  719.96] s3c2440-sdi s3c2440-sdi: running at 196kHz (requested: 195kHz).
[  719.965000] s3c2440-sdi s3c2440-sdi: initialisation done.
[  719.97] s3c2440-sdi s3c2440-sdi: running at 196kHz (requested: 195kHz).
[  719.98] s3c2440-sdi s3c2440-sdi: running at 196kHz (requested: 195kHz).
[  719.995000] s3c2440-sdi s3c2440-sdi: running at 196kHz (requested: 195kHz).
[  720.005000] mmc1: queuing CIS tuple 0x01 length 3
[  720.065000] mmc1: queuing CIS tuple 0x1a length 5
[  720.085000] mmc1: queuing CIS tuple 0x1b length 8
[  720.085000] s3c2440-sdi s3c2440-sdi: running at 25000kHz
(requested: 25000kHz).
[  720.085000] s3c2440-sdi s3c2440-sdi: running at 25000kHz
(requested: 25000kHz).
[  720.095000] mmc1: queuing CIS tuple 0x80 length 1
[  720.095000] mmc1: queuing CIS tuple 0x81 length 1
[  720.095000] mmc1: queuing CIS tuple 0x82 length 1
[  720.095000] mmc1: new SDIO card at address 0001
[  721.14] BMI Get Target Info: Exit (ver: 0x2059 type: 0x1)
[  721.16] eth0 (sdio_ar6000): not using net_device_ops yet
[  721.225000] AR6000 Reg Code = 0x4060
[  743.61] Unable to handle kernel NULL pointer dereference at
virtual address 002c
[  743.61] pgd = c6f0
[  743.615000] [002c] *pgd=36d3e031, *pte=, *ppte=
[  743.62] Internal error: Oops: 17 [#1] PREEMPT
[  743.62] Modules linked in: sco bnep ar6000
snd_soc_neo1973_gta02_wm8753 snd_soc_s3c24xx_i2s snd_soc_s3c24xx
s3cmci btusb rfcomm ppp_generic slhc ohci_hcd ipv6 hidp snd_soc_wm8753
l2cap snd_soc_core bluetooth snd_pcm snd_timer snd_page_alloc g_ether
snd
[  743.62] CPU: 0Not tainted  (2.6.29-rc3 #1)
[  743.62] PC is at wmi_cmd_send+0x8c/0xb4 [ar6000]
[  743.62] LR is at wmi_cmd_send+0x54/0xb4 [ar6000]
[  743.62] pc : [bf14cd38]lr : [bf14cd00]psr: 8013
[  743.62] sp : c6de9d38  ip : c6de9d38  fp : c6de9d54
[  743.62] r10: c6d02000  r9 :   r8 : 
[  743.62] r7 :   r6 :   r5 : c6fbec20  r4 : 0009
[  743.62] r3 :   r2 :   r1 : c6fbec20  r0 : c7ac8282
[  743.62] Flags: Nzcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
[  743.62] Control: c000717f  Table: 36f0  DAC: 0015
[  743.62] Process wpa_supplicant (pid: 1300, stack limit = 0xc6de8268)
[  743.62] Stack: (0xc6de9d38 to 0xc6dea000)
[  743.62] 9d20:
c7ac8284 
[  743.62] 9d40: c6fbec20  c6de9d7c c6de9d58 bf14f114
bf14ccbc c0058cb4 
[  743.62] 9d60: c6de8000 c6ffa460   c6de9dbc
c6de9d80 bf145bdc bf14f098
[  743.62] 9d80: 0064 00cd 6013  c6d788e0
c0058b90 c6de9d98 c6de9d98
[  743.62] 9da0: c6de9e90 013c c02bd2d4 8b18 c6de9e24
c6de9dc0 c0292238 bf145ad0
[  743.62] 9dc0: 0001 c6de9e34 c6ffa000  c6de9e0c
  
[  743.62] 9de0:   c6de9e0c 8b18 c6de9e80
c08f9f50 c6de9e24 8b18
[  743.62] 9e00: c6de9e80 c08f9f50 bed4dbd8  c6de8000
 c6de9e5c c6de9e28
[  743.62] 9e20: c0291c28 c0291fbc bf145ac0 c6de9e38 c6de9e4c
8b18 c00630b8 
[  743.62] 9e40: 8b18 bed4dbd8 c6de9e80 c08f9f50 c6de9ed4
c6de9e60 c0220910 c0291b04
[  743.62] 9e60: 6013 c6de9f78 c6de9e9c c6de9e78 c00662f4
c0062c40 c6de9eb4 c76963b8
[  743.62] 9e80: 30687465    
  
[  743.62] 9ea0:  c7690610 c6de9ed4 c6ce6440 8b18
bed4dbd8 bed4dbd8 c0029fc4
[  743.62] 9ec0: c6de8000 bed4dbd8 c6de9ef4 c6de9ed8 c0210470

Re: Wifi driver stability improved -- wrong patch reverted

2009-09-04 Thread Paul Fertser
Hi,

Thanks for the feedback.

On Fri, Sep 04, 2009 at 04:13:28PM +0200, Nicola Mfb wrote:
  Nicola Mfb nicola@gmail.com writes:
  I built a3587e4ed77974adfb057af261aaeea4022018e8 and commented the HTC
  line suggested in your patch
  andy-tracking HEAD, that's right revision.
... 
 rebooted and tryied with nwa, starting and quitting about 4/5 times resulted 
 in:
...
 [  743.62] Backtrace:
 [  743.62] [bf14ccac] (wmi_cmd_send+0x0/0xb4 [ar6000]) from
 [bf14f114] (wmi_bssfilter_cmd+0x8c/0x98 [ar6000])
 [  743.62]  r7: r6:c6fbec20 r5: r4:c7ac8284
 [  743.62] [bf14f088] (wmi_bssfilter_cmd+0x0/0x98 [ar6000]) from
 [bf145bdc] (ar6000_ioctl_siwscan+0x11c/0x148 [ar6000])

Quite interesting indeed. Can you possibly provide a way to reproduce it
without nwa using some bash or minimal python script?

Can you confirm it's a regression and if yes, in which version it did work
without issues?

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercer...@gmail.com

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: Wifi driver stability improved -- wrong patch reverted

2009-09-04 Thread Nicola Mfb
On Fri, Sep 4, 2009 at 10:07 PM, Paul Fertserfercer...@gmail.com wrote:
[...]
 Quite interesting indeed. Can you possibly provide a way to reproduce it
 without nwa using some bash or minimal python script?

Yes, I'll try with standard tools, anyway when nwa quits it remove
eth0 from the list of interfaces managed by wpa_supplicant via a dbus
call.
I do not know exactly what wpa_supplicant does in such case, and as it
happens only some times I just guess the driver goes in some race
condition state.

 Can you confirm it's a regression and if yes, in which version it did work
 without issues?

I cannot confirm, I always had problem in some ways.
It may be only due the fact that as I developed nwa I stressed a lot
wifi during time.

Another hint is the wow interrupt, I noted it a lot of time, is it harmful?

Regards

Nicola

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: Wifi driver stability improved -- wrong patch reverted

2009-09-04 Thread Nicola Mfb
On Fri, Sep 4, 2009 at 11:59 PM, Nicola Mfbnicola@gmail.com wrote:
 On Fri, Sep 4, 2009 at 10:07 PM, Paul Fertserfercer...@gmail.com wrote:
 [...]
[...]
 Can you confirm it's a regression and if yes, in which version it did work
 without issues?

I forgot to say an important thing: thanks for your effort!
Keep up the good work on the kernel, we really need it ;)

Nicola

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community