**** BEGIN LOGGING AT Fri Jul 02 02:59:58 2010
Jul 02 03:09:06 <CIA-38> craigc * r22043 /packages/net/multiwan/ (Makefile files/etc/config/multiwan files/usr/bin/multiwan): [packages] multiwan: Reverted back from using LAN as default route in main routing table.
Jul 02 09:19:11 <builder> build #72 of sibyte is complete: Failure [failed shell_6]  Build details are at http://tksite.gotdns.org:8010/builders/sibyte/builds/72
Jul 02 09:56:00 <CIA-38> juhosg * r22044 /trunk/target/linux/generic/files/drivers/net/phy/ (rtl8366rb.c rtl8366s.c): generic: rtl8366: enable VLAN ingress filtering
Jul 02 10:51:00 <CIA-38> acinonyx * r22045 /packages/net/quagga-unstable/patches/002-quagga_manet.patch: [packages] quagga-unstable: Add some missing vty newlines
Jul 02 12:46:20 <CIA-38> nbd * r22046 /trunk/package/mac80211/patches/550-ath9k_fix_wep_adhoc_crash.patch: ath9k: fix a crash with WEP in ad-hoc mode
Jul 02 12:47:27 <CIA-38> nbd * r22047 /branches/backfire/package/mac80211/patches/550-ath9k_fix_wep_adhoc_crash.patch: mac80211: backport ath9k wep fix from r22046
Jul 02 13:01:38 <_lore_> pind nbd
Jul 02 13:11:58 <nbd> pong
Jul 02 13:17:24 <_lore_> hi, I am facing a stuck issue on ath9k
Jul 02 13:17:48 <nbd> have you tried the latest rev yet?
Jul 02 13:18:28 <_lore_> yes
Jul 02 13:18:40 <_lore_> I am using the last compact-wireless
Jul 02 13:19:39 <_lore_> I collected some debug info
Jul 02 13:20:05 <nbd> which openwrt rev are you using exactly? and is it backfire or trunk?
Jul 02 13:20:20 <_lore_> trunk
Jul 02 13:20:44 <_lore_> I know you are facing the same kind of issue
Jul 02 13:20:48 <nbd> and which device?
Jul 02 13:20:54 <_lore_> ar9280
Jul 02 13:21:24 <nbd> ok, please give me some details on the issue
Jul 02 13:21:30 <_lore_> yes
Jul 02 13:23:19 <_lore_> the issue occurs when the driver runs out the tx.txbuf and the ath_tx_get_buffer fails
Jul 02 13:23:47 <_lore_> the tx interrupts seem to be stuck
Jul 02 13:24:01 <_lore_> and the HW is no able to free new buffers
Jul 02 13:24:14 <nbd> ap mode or sta mode?
Jul 02 13:24:26 <_lore_> ap
Jul 02 13:24:55 <nbd> odd, normally it should never run out of tx buffers, because there is a per-queue limit
Jul 02 13:25:04 <_lore_> yes
Jul 02 13:25:34 <nbd> sounds like there is a buffer leak somewhere
Jul 02 13:25:53 <nbd> or are all the buffers in the queue and the queue is stuck?
Jul 02 13:26:11 <_lore_> I inserted a counter in ath_tx_tasklet in order to count tx interrupts
Jul 02 13:26:49 <_lore_> and the the issue occurs the count is stuck
Jul 02 13:28:40 <nbd> ok, i'll do a review of the buffer handling in the tx path
Jul 02 13:28:53 <nbd> can you try to figure out if all the buffers are accounted for in the tx queues?
Jul 02 13:29:07 <nbd> btw. are you using 11n clients or legacy clients?
Jul 02 13:29:09 <nbd> or both?
Jul 02 13:29:14 <lorenzo_> 11n
Jul 02 13:29:33 <lorenzo_> the issue is quite infrequent
Jul 02 13:29:51 <lorenzo_> at most one time per day
Jul 02 13:29:57 <nbd> how many 11n clients?
Jul 02 13:30:03 <lorenzo_> 2
Jul 02 13:30:33 <nbd> ok, so since these are 11n clients only, we can assume that most of the buffers are staying in the software queue
Jul 02 13:30:51 <lorenzo_> yes
Jul 02 13:33:48 <lorenzo_> I inserted counters in order to estimated the # of buffer free/captures
Jul 02 13:34:27 <lorenzo_> now I am waiting the patiently issue :)
Jul 02 13:35:57 <lorenzo_> I tried also to reset the HW when the problem occurs...but this procedure does not solve the issue
Jul 02 13:37:57 <lorenzo_> Have you ever observe this issue? Could it be caused by an ANI bug?
Jul 02 13:38:52 <nbd> if you run out of buffers, then it cannot be a hw queue bug, or an ani bug
Jul 02 13:39:22 <nbd> since with 11n clients, you only have two aggregates in the hw queue
Jul 02 13:39:50 <nbd> and it should only be able to grab a quarter of the available tx buffers per queue
Jul 02 13:40:01 <nbd> so this must be a leak
Jul 02 13:40:23 <nbd> i have an idea
Jul 02 13:40:35 <nbd> i think the stale buffer handling is broken
Jul 02 13:40:45 <nbd> i think stale frames are thrown in the wrong queue
Jul 02 13:40:46 <nbd> let me check
Jul 02 13:41:35 <nbd> hm, nope
Jul 02 13:41:36 <nbd> not it
Jul 02 13:43:37 <lorenzo_> I think the problem is that ath_tx_tasklet is no more run
Jul 02 13:44:22 <nbd> no, that can't be the root cause
Jul 02 13:44:50 <nbd> as i said, without a buffer leak or a calculation error, one queue cannot drain all the tx buffers
Jul 02 13:45:01 <nbd> and it's unlikely that you have full utilization of all 4 queues
Jul 02 13:46:03 <lorenzo_> yes, I agree with you
Jul 02 15:08:35 <nbd> lorenzo__: another question about the txbuffer issue: does it recover if you restart the interface without reloading the ath9k module?
Jul 02 15:35:26 <lorenzo__> no, unfortunately not...also calling ath_rest does not fix the issue
Jul 02 15:37:28 <nbd> ok
Jul 02 16:11:21 <CIA-38> nbd * r22048 /trunk/package/mac80211/patches/560-ath9k_buffer_leak.patch: ath9k: fix a potential buffer leak
Jul 02 17:54:54 <goodasGNU> has openwrt been used with msys DiskOnChip flash chips? I find nothing in docs or wiki
Jul 02 17:58:43 <clem-vangelis> hello all
Jul 02 18:35:31 <clem-vangelis> hi all
Jul 02 18:35:43 <clem-vangelis> is flash in byte mode supported by openwrt ?
Jul 02 18:46:21 <clem-vangelis> as i said before i'm porting openwrt to an edimax printserver
Jul 02 18:46:39 <clem-vangelis> infos are here : https://forum.openwrt.org/viewtopic.php?pid=112016#p112016
Jul 02 18:47:31 <clem-vangelis> it boots in ramdisk mode but not when it has to write to flash
Jul 02 18:47:34 <clem-vangelis> https://forum.openwrt.org/viewtopic.php?pid=112016#p112016
Jul 02 18:47:37 <clem-vangelis> oups
Jul 02 19:01:40 <clem-vangelis> by the way if the flag MTD_WRITEABLE isn't put on a partition, it couldn't be erase no ?
Jul 02 19:08:59 <goodasGNU> check out flash_unlock and other mtd utils to change flags
Jul 02 19:12:27 <clem-vangelis> k in what file it is ?
Jul 02 19:12:42 <clem-vangelis> i tried to call mtd->unlock but this seems to be a null pointer
Jul 02 19:21:50 <goodasGNU> more info here > http://www.informit.com/articles/article.aspx?p=118710
Jul 02 19:22:03 <goodasGNU> http://www.informit.com/articles/article.aspx?p=1187102&seqNum=1
Jul 02 19:23:26 <clem-vangelis> thanks
Jul 02 19:23:57 <goodasGNU> page 6+ gets more specific
Jul 02 19:26:27 <dogge10> transfer started  udp error 1 kernel loading failed
Jul 02 19:26:39 <dogge10> getting this on rb433uah. where is the problem?
Jul 02 19:47:08 <clem-vangelis> i found a difference between the sotkc firmware ( 2.4 kernel) and openwrt
Jul 02 19:47:20 <clem-vangelis> the eraze size in the original kernel is 0x10000
Jul 02 19:47:33 <clem-vangelis> but in openwrt it's 0x20000
Jul 02 19:47:39 <clem-vangelis> could this be the problem ?
Jul 02 19:52:23 <clem-vangelis> forget it it's the same
Jul 02 19:57:50 <clem-vangelis> no that's effectively different
Jul 02 20:02:09 <dogge10> anyone?
Jul 02 20:03:06 <goodasGNU> Okn this is just not right. I add required ata drivers by make kernel_menuconfig and they get removed during build WHY!!!
Jul 02 20:04:40 <nbd> do you select them as module or built-in?
Jul 02 20:04:49 <goodasGNU> <*>
Jul 02 20:05:00 <nbd> odd
Jul 02 20:06:06 <goodasGNU> yeah, frustrating to just get "waiting for root device" after all that.
Jul 02 20:07:05 <goodasGNU> looking at .config  after the build, the drivers have reverted to "not set"
Jul 02 20:08:36 <nbd> which config symbols did you select specifically?
Jul 02 20:08:46 <nbd> and did your changes show up in svn/git diff
Jul 02 20:09:25 <goodasGNU> CONFIG_PATA_CS5530=y
Jul 02 20:18:12 <dogge10> http://openwrt.pastebin.com/H6M14yx4 - why is this?
Jul 02 20:21:13 <goodasGNU> dogge10:  wrong image flashed  maybe...
Jul 02 20:21:47 <goodasGNU> wong parition info on flash = no route to kernel
Jul 02 20:22:03 <dogge10> well, it's the .elf image...
Jul 02 20:23:49 <goodasGNU> what bootloader?
Jul 02 20:24:17 <dogge10> RouterBOOT
Jul 02 20:25:01 <dogge10> board MikroTik RB433UAH
Jul 02 20:25:26 <goodasGNU> make sure the kernel resides in correct partition in boot env and is compatible compression type
Jul 02 20:25:53 <goodasGNU> and correct name
Jul 02 20:26:16 <dogge10> k
Jul 02 20:56:30 <builder> build #65 of gemini is complete: Failure [failed shell_6]  Build details are at http://tksite.gotdns.org:8010/builders/gemini/builds/65
Jul 03 01:38:46 <builder> build #85 of ppc44x is complete: Success [build successful]  Build details are at http://tksite.gotdns.org:8010/builders/ppc44x/builds/85
Jul 03 02:21:33 <builder> build #79 of avr32 is complete: Success [build successful]  Build details are at http://tksite.gotdns.org:8010/builders/avr32/builds/79
**** ENDING LOGGING AT Sat Jul 03 02:59:56 2010