**** BEGIN LOGGING AT Thu Feb 07 02:59:57 2008
Feb 07 10:40:57 <jell> matteo: in yours patch you could remove asm/a7 in includes...
Feb 07 10:41:15 <jell> matteo: this dir is always in include path...
Feb 07 10:42:07 <jell> matteo: it's setted in 100-board_support.patch
Feb 07 10:42:43 <jell> so s/asm\a7// on patch
Feb 07 10:46:41 <jell> rest of patch looks rather good
Feb 07 18:15:54 <witchdoc_> re
Feb 07 18:31:44 <CIA-27> nbd * r10409 /trunk/target/linux/atheros/files/arch/mips/atheros/ar5312/board.c: increase the flash window size for ar5312 - there are apparently 5312 devices out there with 8M flash
Feb 07 18:40:25 <CIA-27> matteo * r10410 /trunk/target/linux/ar7/patches-2.6.24/ (100-board_support.patch 140-cpmac_fix.patch): [AR7] more 2.6.24 patches
Feb 07 20:05:14 <CIA-27> kaloz * r10411 /trunk/toolchain/uClibc/patches/ (007-avr32.patch 008-avr32_fix_sa_onstack.patch): sync AVR32 patches with upstream
Feb 07 20:08:35 <CIA-27> kaloz * r10412 /trunk/target/linux/avr32/ (4 files in 2 dirs): upgrade AVR32 to 2.6.24 - sync with 2.6.24.atmel.1
Feb 07 20:18:48 <CIA-27> kaloz * r10413 /trunk/toolchain/gcc/ (11 files in 2 dirs): add GCC 4.2.3
Feb 07 20:21:19 <CIA-27> kaloz * r10414 /trunk/toolchain/gcc/ (Config.in Config.version): use GCC 4.2.3 by default for AVR32
Feb 07 21:38:55 <matteo> http://openwrt.pastebin.ca/895500
Feb 07 21:38:58 <matteo> hangs here
Feb 07 21:48:38 <|matteo|> hi all
Feb 07 21:48:42 <|matteo|> i'm a mips linux hacker
Feb 07 21:48:44 <wrt> hi
Feb 07 21:48:58 <matteo> dmn
Feb 07 23:52:59 <jell> ///n
Feb 07 23:53:03 <jell> sry
Feb 08 00:21:15 <CIA-27> matteo * r10415 /trunk/target/linux/ar7/files/ (3 files in 2 dirs): [AR7] make current AR7 code 2.6.24 aware, for future use
Feb 08 01:26:42 <thepeople> nbd: ping
Feb 08 01:27:24 <matteo> http://openwrt.pastebin.ca/895744
Feb 08 01:27:27 <matteo> weird log
Feb 08 01:27:57 <nbd> thepeople: pong
Feb 08 01:29:14 <thepeople> nbd: having a few issues with madwifi
Feb 08 01:29:15 <thepeople> http://pastebin.ca/895752
Feb 08 01:29:34 <thepeople> that is the error I get on the ap
Feb 08 01:30:02 <thepeople> then the 2 clients I have on that interface will not connect
Feb 08 01:30:26 <thepeople> no errors on the client side, but it requires a reboot to get them communicating again
Feb 08 01:31:36 <thepeople> I am using psk for encryption
Feb 08 01:32:02 <thepeople> (trying psk2 now to see if the same error will occur again)
Feb 08 01:35:56 <nbd> what kind of device?
Feb 08 01:37:32 <thepeople> the ap is a wrap with a SR2 as ath0 (no problems with this card) and a cm9 as ath1 (card that the 2 stations with issues), the clients are both meraki mini's
Feb 08 01:40:16 <nbd> are you running low on ram sometimes?
Feb 08 01:43:27 <thepeople> I don't think so, hovering around 20meg used of 64 right now, I think it was right there before I restarted it
Feb 08 01:44:13 <thepeople> I will double check that when the error happens again
Feb 08 01:55:33 <matteo> nbd: .24 boots
Feb 08 01:55:38 <nbd> cool
Feb 08 01:55:41 <matteo> just serial is broken
Feb 08 01:55:42 <matteo> console handover: boot [early0] -> real [ttyS0]
Feb 08 01:55:52 <matteo> http://openwrt.pastebin.ca/895771
Feb 08 01:56:06 <matteo> read in the first lines what I did
Feb 08 01:56:52 <matteo> serial is broken but all works
Feb 08 01:56:59 <matteo> can I commit?
Feb 08 02:14:03 <matteo> gn8
Feb 08 02:26:49 <thepeople> nbd: another error that I am running into http://pastebin.ca/895799 <- from the ap
Feb 08 02:28:30 <thepeople> again requiring a reboot of the ap and the sta's to get everything running again
Feb 08 02:29:38 <nbd> with wpa2 as well?
Feb 08 02:29:52 <thepeople> yes
Feb 08 02:30:03 <thepeople> this log is with everything running psk2
Feb 08 02:30:06 <nbd> ok, i will look into it
Feb 08 02:30:08 <thepeople> when I put it under load iperf -P 30 I get it the error almost immediately
Feb 08 02:31:28 <thepeople> nbd: anything else I can get you?
Feb 08 02:39:48 <nbd> does it happen in regular operation as well or just under artificial load?
Feb 08 02:45:36 <thepeople> regular operation also
Feb 08 02:46:19 <thepeople> but it may take a day or so for the error to come back under regular load
Feb 08 02:46:35 <nbd> ok
Feb 08 02:46:46 <thepeople> so when it does I will get you what info I can
Feb 08 02:47:15 <nbd> i suspect that madwifi doesn't recover from temporary memory allocation failures too well
Feb 08 02:47:36 <nbd> so it might be accumulating dma ring entries without buffers
Feb 08 02:47:40 <nbd> not sure about this, thougj
Feb 08 02:49:25 <thepeople> nbd: how can I check that?
Feb 08 02:49:35 <nbd> no iea
Feb 08 02:49:37 <nbd> no idea
Feb 08 02:49:39 <nbd> i will review the code
Feb 08 02:49:45 <nbd> and check the memory allocation handling
Feb 08 02:49:51 <thepeople> ok
**** ENDING LOGGING AT Fri Feb 08 02:59:56 2008