Developer's meeting - December 19, 2010
Topics discussed were about some of the RFC's Helmut sent to the mailing list.
Comments were made about queues, specially the order which seems to be reversed in some devices, subtle changes in register use.
The infamous MCU problem currently present in some rt2800pci devices was again discussed.
Also some discussion about converting irq to tasklets.
it is all here:
<hschaa> JFI: Johannes Stezenbach wrote me a mail yesterday that he cannot participate <ivd> ok <ivd> So I guess everybody is here? <lfcorreia> guess so :) the 'usual suspects' <hschaa> :) <ivd> So with which subject shall we begin? <lfcorreia> we can start with the first one on the topic list <lfcorreia> Asynchronous tx status handling in rt2800usb. <hschaa> Fine with me. Although Ivo merged that already , right? <lfcorreia> (I'm just following the list :)) <ivd> Yeah, I merged it a couple of days ago, I will test it today on my system <lfcorreia> ok then <hschaa> yeah, ok, I guess it is a step in the right direction and I think Johannes will further work on improving the tx status reporting in rt2800usb <ivd> Although there are some parts I still would like to change (especially see if we can share more code with rt2800pci) <lfcorreia> we can move to the next one on the list, TX queue priorization.- Discuss how the hw handles that on USB and PCI -> differences? <hschaa> ok, let me quickly summarize what we've got: <hschaa> the newer ralink devices have multiple tx queues (one per AC and two more for MGMT and HCCA) <hschaa> the channel access parameters (like cwmin, aifs ...) can be configured (only for the AC queues) with specific registers <hschaa> WMM_* or something <hschaa> however, as we heard (and as far as I understood) from Jay there seems to be a static priorization of the DMA queues <hschaa> and that priorization is inverted to how we currently use the queues <ivd> But only for USB <ivd> Or are also the QUEUE0, QUEUE1 registers inversed? <ivd> (As far as I understood, we have only inverted the urbs) <hschaa> to be honest, I'm not sure :( <ivd> And even then it is still unclear if the same inversion is present in RT73usb <hschaa> right <hschaa> The info from ralink regarding the PCI devices was a bit less informative then the answer about rt2800usb <hschaa> on rt2800usb we know for sure that we have an inversion somehow <hschaa> on rt2800pci we are not sure (or are you sure? ;) ) <ivd> true <hschaa> and on older devices we don't know either <ivd> Perhaps we should just synchronize the code with the legacy driver, and assume rt73usb and rt2800usb assign the same endpoints to the queues <hschaa> does inverting the enpoints mean we will still use the mac80211 queue ids but just send it to a different endpoint? <ivd> yes, because the QID from mac80211, is never passed as-value to a register. So we don't need any mapping on that <hschaa> let me have a quick look ... * Jusic (~email@example.com) has joined #rt2x00 <hschaa> on PCI devices how does the hw know which DMA queue is used for which AC? <ivd> Because of the queues with AIFSN configuration? <hschaa> if that's the case everything should be fine on rt2800pci <ivd> yeah, but what is the assignment in the legacy driver? is QUEUE there BE, BK, or VO? <hschaa> Did you mean QUEUE==QSEL? <ivd> Is that a register? <hschaa> no, part of the TXD <hschaa> for the "second stage scheduler" <ivd> hmm, and let me guess we are sending the QID to that? <ivd> So that means we do need some mapping... :( <hschaa> nope, we always use QSEL:2 <hschaa> and that should be fine (at least for now) <ivd> ah right. But QSEL 2 means EDCA. <hschaa> yep <ivd> So indeed, we don't need anything on that <hschaa> ok, only the endpoint inversion on USB <hschaa> btw. here's what jay wrote about the DMA queues on rt2800pci: <hschaa> "yes, scheduler will refer WMM_&_CFG in SCH/DMA register to decide next frame " <hschaa> so, if at least seems to have no static priorization but uses the configured aifsn, cwmin ... values <hschaa> Anyone plans to make use of the MGMT queue somewhen? <ivd> No we can't make use of the MGMT queue. <gwingerde> Wouldn't that require support from mac80211? <ivd> we shouldn't filter out MGMT frames from mac80211, and neither can we add the queue to mac80211 due to the hardlimit of 4 queues <hschaa> Yeah, if would require work in mac80211 <ivd> and I am not sure if Johannes Berg would agree on such a special queue <gwingerde> Do we know if other HW has such special MGMT queues as well? <hschaa> not sure if other devices have similar queues? <hschaa> we could send a mail to linux-wireless and just ask :) <ivd> Ok, perhaps he changed his mind, because I asked it a couple of years ago as well :P <hschaa> aha, ok <gwingerde> I guess the alternative is to check the incoming TX frames to see if they are mgmt frames, and then send them on the MGMT queue. <ivd> Anyway, for USB, does it mean that endpoint0, is attached to QUEUE0 registers? <gwingerde> Not sure if that breaks things, though. <hschaa> we've discussed that on the mailing list but that could reorder tx status reports <ivd> no that should not be done, we did that in the past, and Johannes requested that to be removed <hschaa> (since the MGMT queue has a higher prio) <gwingerde> OK. Didn't know the past of this ;-) <hschaa> If enpoint0 is attached to QUEUE0 registers, no idea, sorry <hschaa> I've just got one possible use case for the MGMT queue: <ivd> Well for safety I will just reorder those registers as well to be in sync with legacy <hschaa> ok <hschaa> on PCI devices we've got a TBTT interrupt that gets issues when the beacon is sent out <hschaa> and during TBTT processing we should send out all buffered multi- and broadcast frames (if DTIM == 0) <hschaa> and 802.11-2007 tells us that there should be no unicast (data?) frame between the beacon and the buffered frames <hschaa> at the moment, that could happen because there might still be some frames in the queue after the beacon was sent out <hschaa> but if we put the buffered frames into the MGMT queue they should get sent out before the AC* queues get transmited, right? <hschaa> (that's still racy due to the hw design relying on the interrupt processing but it might improve things) <ivd> Doesn't mac80211 call flush()? <ivd> And does the MGMT queue guarentee the TX status register to be filled? <hschaa> nope, mac80211 doesn't interfere with beacon handling at all <hschaa> not sure if the MGMT queue will issue proper status reports <hschaa> anyway, that was just a quick idea <hschaa> (and I'm not even sure if it is really that important) <ivd> ok <lfcorreia> diverting a bit from the current topic <lfcorreia> phy0 -> rt2800pci_mcu_status: Error - MCU request failed <lfcorreia> does any of you with rt2800pci devices also get this error while loading the driver? <gwingerde> On some of my devices. However, I do believe I know where this one comes from. <gwingerde> It is the policy on rt2800pci to always first issue a SLEEP MCU command before sending the WAKEUP command. <gwingerde> in rt2800pci_set_state. <lfcorreia> on recent rt2x00 git kernel, the device seems to work fine, although I think it will never sleep or use otherwise the powersaving functions <gwingerde> I had it confirmed a long time ago if that SLEEP was not done than that MCU error doesn't occur. <gwingerde> However, I do not know why we are always issueing a SLEEP, so I have refrained from sending in a patch. <gwingerde> Ivo, do you know why we do wake-up this way? <hschaa> hmm, what are the legacy drivers doing? <lfcorreia> well yes, but this really happens right after the firmware is loaded into the device <lfcorreia> so, if the MCU is not working, it won't accept any commands IMHO <ivd> I think this code is synchronized with the legacy driver, which contains the comment that WAKUP is only valid after the SLEEP command <gwingerde> Hmmm, I think this was only at start-up, but I'll check that. If I find something then I'll send a patch. <gwingerde> The other thing is that we don't wait for the MCU status after the SLEEP command, while we do for the WAKEUP command. Should we also wait for the SLEEP command?> <ivd> Not sure, perhaps we should, but I can't recall if legacy driver did it as well <gwingerde> OK. I'll check that as well. <lfcorreia> AFAIR, we replicate all processes from the legacy code <gwingerde> And the legacy drivers have changed quite a bit since their first releases, so it doesn't harm to re-check. <hschaa> yep, makes sense <lfcorreia> I specifically analised the first rt2800 legacy code and compared it with ours <lfcorreia> but that might need to be done again :) <gwingerde> Yeah, will do that ;-) <hschaa> ok, let's move on? <lfcorreia> sure <hschaa> Further optimization of hotpaths (RX/TX) <hschaa> I don't know why but rt2x00+mac80211 seems to have quite some more overhead then the legacy drivers <hschaa> so, I thought about ways to improve the hotpaths in rt2x00 <gwingerde> Do we know where this overhead is? <hschaa> Nope, I was unable to get profiling to work on the ralink soc <hschaa> However, we are doing quite some unnecessary work in rt2x00 <hschaa> for example, the tx descriptor contains values for all ralink devices <hschaa> example: <hschaa> length_high and length_low are set for every device but only a few need them <ivd> But how can we cleanly optimize that? <hschaa> hehe, no comes the fun part :) <hschaa> I thought about removing the biggest parts of the tx descriptor <hschaa> rt2x00queue_create_tx_descriptor_plcp fills in the plcp values into the tx descriptor * Ju5ic (~firstname.lastname@example.org) has joined #rt2x00 <hschaa> but when we remove all plcp related values from the descriptor <hschaa> we could simply add a call to rt2x00queue_create_tx_descriptor_plcp from the individual drivers write_tx_desc callbacks <hschaa> so, in short, remove most values in the tx descriptor and provide the drivers functions to retrieve these values <ivd> I think there is an old TODO for mac80211 that this is moved to mac80211 <hschaa> the plcp stuff <ivd> yeah <hschaa> but of course, there are other fields like all the ht related stuff that isn't needed on legacy devices <hschaa> but if you want to run rt61 and rt2800 with the same kernel the ht fields are also filled in for rt61 <hschaa> does that approach sound somehow reasonable? <ivd> Perhaps we should have the drivers indicate which TX descriptor stuff they want during init. Then we still have a simple write_tx_descriptor function in the drivers <gwingerde> From my side it does, in one form or the other, but to be honest, I don't feel that these things are major overhead generators. <hschaa> ivd: that would mean introducing quite a number of new flags, don't think I like that ... <hschaa> gwingerde: I don't expect to gain much from it but on these slow embedded machines every cycle counts <gwingerde> True, I guess I'm quite spoiled running on high-end Intel x86_64 HW :-) <hschaa> yep :) a 380Mhz MIPS CPU is really slow <hschaa> ivd: if we just replace every (set of) fields in the tx descirptor with a corresponding function that shoul leave the write_tx_desc callback quite simple <hschaa> something like <hschaa> rt2x00_set_field32(&word, TXWI_W1_BW_WIN_SIZE, txdesc->ba_size); <hschaa> would become <hschaa> rt2x00_set_field32(&word, TXWI_W1_BW_WIN_SIZE, rt2x00_txdesc_get_ba_size(xxx)); <ivd> That won't work for most fields, since a lot of values can only be determined in groups <ivd> e.g. PLCP cannot be done individually <hschaa> ok, but that could do something like: <ivd> And you can reduce the number of if-statements in other cases by getting the values in a group <hschaa> rt2x00_txdesc_get_plcp(plcp_settings) <hschaa> rt2x00_set_field32(&word, plcp1, xx) <hschaa> rt2x00_set_field32(&word, plcp2, xx) <hschaa> of course we need to review which fields need to be grouped together <ivd> I guess most stuff which are currently already in different functions <gwingerde> What is your end-goal here? Complete removal of the pre-processing and struct txentry_desc? <gwingerde> And only do "on-demand" processing? <hschaa> Not the complete removal, but to only keep data in txentry_desc that is used by every driver <hschaa> and all the hw specific stuff would be generated on-demand, yes <gwingerde> Maybe it would be good if you can provide an overview of what it is that you would keep, and what would go "on-demand". <hschaa> ok, I'm going to do a more deep review and come up with a list of possible changes? <gwingerde> Sounds good. <lfcorreia> btw <hschaa> ok, and one more thing regarding the rx descriptor <lfcorreia> trading the large descriptor for functions, won't that be an overhead as well? <lfcorreia> copy large chunks of memory vs more calls? <hschaa> yes, it would but if they are just inlined functions (or maybe macros) that life in rt2x00queue.h <lfcorreia> ah, ok then <gwingerde> I guess we should prefer in-line functions over macros, but yes, making them inline would reduce the overhead of function calls. <hschaa> at the moment drivers are calling rt2x00lib_rxdone and that in turn calls back into the drivers with fill_rxdone <hschaa> wouldn't it be possible to already pass the rxdesc to rt2x00lib_rxdone? <ivd> Don't think so, or at least not without moving a lot of logic back into the drivers again <gwingerde> Maybe, however, please note that the rxdone functions are currently called from the generic pci and usb code, not from the drivers themselves. <hschaa> right * yanook (~email@example.com) has joined #rt2x00 <hschaa> ok, I'll try to first come up with some stuff regarding the tx desc and if we agree on one of the possible alternatives I can look into the tx handling as well :) <lfcorreia> moving on? <hschaa> sure <lfcorreia> Remaining questions regarding the tasklet conversion of PCI drivers <gwingerde> Before we go into the details, can someone explain what it is that we are trying to achieve with using tasklets? <hschaa> ok <gwingerde> (sorry couldn't keep up with all the discussions on the mailing-list). <hschaa> before the irq thread conversion rt2x00 handled all interrupts in hard irq context <hschaa> I've introduced the irq thread mainly to periodically update the beacon (in AP and mesh mode for example) <hschaa> this is required to get the correct DTIM count from mac80211 and to sent out buffered multi-and broadcast traffic after the beacon <hschaa> since the beacon update code is/was mutex protected I thought the interrupt thread is a good idea sind it runs in process context <hschaa> b43 already handled its interrupts in that way <hschaa> the hard irq handler reads which interrupts triggerd and schedules the irq thread but keeps all interrupts masked out <hschaa> the interrupt thread processes all interrupts and unmasks the interrupts again <hschaa> on reasonable fast machines that works just fine <hschaa> but again on the SoC devices <hschaa> the rx and tx processing (when pushing a lot of traffic) caused for example a TBTT interrupt to get lost because the rx/tx processing took too long <hschaa> the legacy drivers do the following: <hschaa> the hard irq handler checks which interrupt triggerd and only masks out exactly these interrupts and schedules a tasklet for the according interrupt <hschaa> the tasklet after processing reenabled the irq in the device <hschaa> so, for example during rx processing only the rx irq is disabled <hschaa> but the others can still happen <hschaa> so, the goal is to process each interrupt individually while the other interrupts are still enabled <hschaa> such that rx processing cannot block other interrupts <gwingerde> OK. And I guess this requires tasklets, as otherwise the other interrupts can happen without being able to handle them as the thread is still busy? <hschaa> exactly ;) and there is no way to have multiple irq threads (at least not yet) <gwingerde> OK. Got it. <hschaa> Any remaining questions :P ? <gwingerde> Not from my side. <ivd> Neither from here <hschaa> My current RFC series works quite well for me but I'm unable to test older devices :( <hschaa> So, I hope to get the conversion right on these as well <hschaa> k, let's move on <ivd> btw helmut <ivd> when you refactor your patches, yout could perhaps move the patches which you think can be merged early to the start of the series. Then we can review and apply them before the rest of the series (if the rest is not ready yet) <hschaa> makes sense, yes, however, Gertjan already obsoleted one of the patches ;) <ivd> yeah, I know :P <ivd> But that was one of the patches which could have been applied before the rest of the series ;) <hschaa> right <hschaa> ok, I'll move the patches in a more clever order for the next iteration <ivd> ok thanks <gwingerde> Maybe send the intf locking patches as a separate batch, as they seem to be quite independent. <hschaa> yep, they are independent, I just had them pending in my tree on top of the others <gwingerde> So, I guess these could even go in right now, as they don't have to depend on the tasklet conversion. <hschaa> correct <ivd> right <hschaa> How to avoid start- and stop queue locking for the beacon queue <ivd> What was the exact problem with the locking? <hschaa> None yet ;) <hschaa> But the beaconing updates I've made for the PCI devices <hschaa> update the beacon from within a tasklet <hschaa> that's alright since I've made sure that that's the only beacon update point for PCI devices <hschaa> => no locking needed <ivd> but they do start_queue and stop_queue in there? <hschaa> Nope :) <ivd> Then no locking is happening right? <hschaa> Yep, but that is fine because stop_queue will wait for the beacon_tasklet to finish <hschaa> But ... <hschaa> Johannes pointed out that the code in the drivers write_beacon callback could be simplified if rt2x00queue <hschaa> if rt2x00queue would stop the beacon queue before the beacon update and start if afterwards again <ivd> ok, but what if we make it use pause_queue and unpause queue then? <hschaa> and this start and stop is not possible right now from within the periodic beacon update (tasklet -> atomic context) <hschaa> hmm <hschaa> pause_queue does nothing on the beacon queue right now? <ivd> at the moment not <ivd> But the entire queue refactoring was never focussed on the Beacon queue ;() <ivd> ;) <hschaa> might be a good idea <hschaa> I'll check that <hschaa> but currently the definition of pause/unpause-queue is to stop the queue in mac80211 ;) <hschaa> and if it would do something different for the beacon queues that could be confusing <ivd> true, or we move the register changes into a function and simply call those from the driver callback function, that way rt2x00lib doesn <ivd> 't need to do anything <hschaa> yeah, I guess that's ok for now <hschaa> I mean, it is really just setting a bit in the beaconing register, updating the beacon and resetting the bit again <ivd> right <hschaa> ok <hschaa> Last topic, from my point of view at least :) <hschaa> Pushing functionality down into drivers to allow easier modification <hschaa> of newer drivers without affecting older ones? <hschaa> We had at least one case where rt2800 behaved differently then older drivers and while fixing the bssid-register setup on rt2800 we broke the older devices <hschaa> At the moment, we have to be very careful when changing core code logic <hschaa> to not break older known-good devices <ivd> True, but we can't really escape that without duplicating code by moving code to the registers <hschaa> Yeah, that's why I wanted to discuss what we could do to mitigate these problems <hschaa> I mean, most core code is hw independant, and thus fine <hschaa> but some parts of the core code seem to depend on device specific behavior <hschaa> (as we had with the bssid register setup, and no I don't have another example :P ) <gwingerde> Guys, sorry to break in, but unfortunately I have to go now. I'll check the log later for the remaining discussions. <ivd> ok <hschaa> ok, have nice day * gwingerde has quit (Remote host closed the connection) <hschaa> hmm, have _a_ nice day sounds more correct <ivd> hehe <hschaa> Any good ideas how we can ensure that core code changes don't break older devices? <ivd> no, because it is very unclear when some action is device specific or not. I mean the BSSID thing worked for 5 devices, and only in the latest device they changed something quite subtle <hschaa> yep, unfortunatley <ivd> The code which was in rt2x00lib wasn't even obviously broken, since it was logical to do it that way <hschaa> right <ivd> SO we can't really resolve the issues in advance I'm afraid <ivd> I mean, the next time something in the TX descriptor handling can change... SO how could we anticipate that? <hschaa> ok, and I guess nobody has the time to always run regression tests with the older devices <hschaa> at least I don't <lfcorreia> and at the moment, neither can I <ivd> nope, I have a setup to test rt61pci and rt2500pci, but I focus so much on rt2800usb nowadays, that the PCI drivers are tested too little <lfcorreia> maybe at the end of this first semester, some time next February I can do something <hschaa> ok, so let's just hope that we've got enough users to notice bugs as soon as possible <hschaa> oh, and to report them as well <lfcorreia> I can always test my rt2800pci, as it sits on my machine <hschaa> same for me, rt2800pci is well tested from my side <hschaa> ok, do we have anything else to discuss? <lfcorreia> yes, but my rt2800pci is a true PCI card, not the SoC <hschaa> right, that makes a difference sometimes <lfcorreia> the MCU thing is a good example <lfcorreia> and btw, as a good joke <lfcorreia> my last patch sent to the kernel was April first :) <ivd> hehe <hschaa> hehe <hschaa> so, are we done? Anything else? <lfcorreia> from my side, yes <ivd> I don't think so <hschaa> Nice, so we can finally have lunch ;) <ivd> helmut do you need a review on the RFC you send this week, or did you want to send an updated series today? <lfcorreia> so, no objections to declare this meeting done? <hschaa> I don't have any changes in the series yet, so if you've got some times left a quick review would be nice, ye <hschaa> s <ivd> ok. :) <hschaa> thanks <ivd> Well then the meeting is over I guess. :) <ivd> Have a nice day guys <hschaa> yep, cya in a while <lfcorreia> have a nice day, guys!
Developer's meeting - August 9, 2008
Topics discussed were mainly about our recent request that Ralink should stop to provide the legacy drivers and work full time on rt2x00.
It then evolved into getting some payment from Ralink for our work in building and supporting the drivers (things we now do for free).
More documentation, better code examples and stop backporting the windows driver to Linux.
A forum overhaul was decided, with mostly some name changes.
Meanwhile, the Todo page was created, with recent topics, known bugs and such.
The meeting full log follows:
<ivd> Ok: Is my understanding correct that outgoing frames have both the IV data inside the TXD descriptor as well as inside the frame? <lfcorreia> hi all, sorry for being late :) <ivd> When I follow the TX path, it almost looks like it generates the IV/EIV into the TXD and copies it into the frame as well * lfcorreia has changed the topic to: rt2x00 developers meeting, right now :) <ivd> lfcorreia: Late? half hour early :P <gwingerde> Luis, I guess you're early, as 15:00 GMT is not for another 45 minutes <gwingerde> (GMT doesn't have summer time) <lfcorreia> eheh, then it's my timezone misunderstanding <lfcorreia> as always <lfcorreia> never mind then <ivd> There are a lot of early birds today, Mark made a miscalculation, hence his reason for being an hour early as well. :P * lfcorreia has changed the topic to: rt2x00 developers meeting, starting soon <ivd> But he is off for coffee to stay awake. ;) <lfcorreia> ivd, lol, as always, being an aussie has its perks :)= <gwingerde> Ivo, give me some time to check your question out. Don't know the answer without looking at the code ;-) <ivd> :) <ivd> Don't worry, even if the IV is copied into the frame, more questions are standing by, since I still can't get HW crypto going on rt2500usb. And I did try the IV included and excluded from the frame. ;) <gwingerde> OK. I'll check it out anyway. <ivd> thanks <lfcorreia> ivd: can you summarise a quick order of business for today, or we'll just talk? <ivd> lfcorreia did you make those debugfs dumps with encryption enabled in rt2570/rt2500usb? <ivd> lfcorreia: Mark had set some points he wanted to discuss. They are mostly summing up what issues there are at the moment, which should get some attention, and where he can start focussing on. <lfcorreia> actually, no. I was unable to connect with WEP using the legacy driver. it's probably an AP issue, but i was unable to dedicate more time to it <lfcorreia> ivd, ok, i'll wait for Mark to return <ivd> ok, alternatively you could try TKIP, that would normally be step 2 but it could at least uncover some general register problems with HW crypto <ivd> (but WEP has preference since it is the most simple form of encryption) <lfcorreia> let me try that again now <ivd> thanks <gwingerde> ivd: I think you're right in the legacy rt2570 driver, it is both setting the IV and EIV in the TXD and the output buffer. <ivd> Hmm, thats odd, because it seems they are adding the IV length to the TXLength twice <gwingerde> yes, and there are comments as well stating that the ASIC adds IV/EIV to the frame as well. Really odd. <ivd> Perhaps it is overriding it. That the hardware isn't doing the exact same as rt61pci and rt73usb, and that the data they add to the frame is required to make room for the IV/EIV <ivd> Something like: driver makes room for IV/EIV manually to let HW copy it into that room later. <ivd> Which is kind of stupid. <ivd> But somehow expected from rt2570 which is a slighly buggy chipset <gwingerde> That's what I was thinking as well. <gwingerde> Wrt the TXLength, I don't think there is an issue there, as they seem to recalculate the frame size after they have copied all data. <ivd> Yes, but what length to they send to the TX descriptor? <ivd> Is that a length which includes the IV length twice? <gwingerde> Not that I can see. It the size they calculate after all the copying, and only contains the IV/EIV length once. <ivd> ALthough I do believe to have tested with a loop adding 0 to 50 bytes to the length to see when it would start out to send out frames. <ivd> hmm ok, so they are doing that right., <ivd> I must be missing something else then.. :S <ivd> Too bad the USB drivers don't have a true TXdone reporting. That made things so much easier for rt61pci HW crypto :S <lfcorreia> be back in ten minutes <gwingerde> Yeah. I guess that also has something to do with USB. It's somewhat harder to have the status returned to the host from the USB device. <ivd> All that I am seeing now is a blinking TX activity led that tells the device is apparently trying to transmit something, but nothing appears in wireshark. <ivd> yeah, that is definately something the ratecontrol module of mac80211 enjoys. ;) <gwingerde> Hmmm, and our debugfs queue does show the frame? <ivd> Yes, the frames are being uploaded successfully. Hence the reason the TX led blinks as well. <gwingerde> True. <ivd> But wireshark on another system doesn't detect any of the frames. <gwingerde> Hmm. One of the problems can be that by default our drivers disable reception of "ToDS" frames. Maybe you can turn that on to see what the rt2570 sends to the AP? <ivd> The ToDS filter is automatically enabled by mac80211 when running in monitor mode. <ivd> The wireshark + rt61pci interface I use for monitoring is working since I had used it when debugging rt61pci and rt73usb HW crypto. <ivd> And I can see Assoc + Auth requests coming from the rt2500usb device. <gwingerde> Really? I thought I needed to patch that when I was testing the PCI mapping patches I did. <gwingerde> Guess I was wrong at the time * bbatten (firstname.lastname@example.org) has joined #rt2x00 <ivd> Well I don't know about all drivers, but at least rt61pci seems to work well in monitor mode. <ivd> It previously had some quirks when returning from monitor mode to managed mode, but those have been fixes <gwingerde> OK. Maybe I was handling it differently at the time (I wasn't really using wireshark at the time). <ivd> ah, that might be it, wiresharks enables promisc mode and mac80211 will convert that into the correct fitlers <ivd> \filters <ivd> And rt2x00 will listen exactly to those filters <gwingerde> Yep, i'll remember that for next time. <serialmonkey> Ugh, I'm regretting suggesting a 1am meeting in winter at the moment :-) <ivd> Hehe :P <bbatten> You're a brute for punishment, Mark <ivd> Shall we trade the Dutch summer for you Winter :P <serialmonkey> I'm the odd-one-out timezone wise so you think I would be used to it <serialmonkey> hehe <ivd> Not sure where the temperature would be higher :P <serialmonkey> So, basically, it's been awhile since we all caught up. I thought it would be a good time to discuss where things are at, what the major things on the list are and who we are all currently working on <serialmonkey> I honestly have not been keeping track of things, and SF seems to be pretty out-of-date as far as 'bugs' and the like <ivd> Well Bryan seems to have closed some bugs on sf.net recently * sn9 (email@example.com) has joined #rt2x00 <ivd> Or at least I saw the counter change a couple of times. ;) <bbatten> Who all of us "core" developers are still active? Ibrahim, Robin? <ivd> I usually close rt2x00 items or at least marking those bugs as invalid. ;) <ivd> Eh, well Ibrahim and Robin are definitely not active. <serialmonkey> The only people active are those here, minus myself who hasn't been active at all <bbatten> I think I've marked one bug as fixed, and another was fixed as a side effect. <ivd> Not sure when they send out their last mail to any rt2x00 mailinglist. ;) <ivd> Heh, I love bugs that fix themselves ;) <gwingerde> To be honest, I'm not that active as well (currently quite busy with my job :-() <ivd> Well I am way behind with rt2800 development, and my takslist for rt2x00 is growing fast. :S <serialmonkey> Any chance of getting that tasklist published ? <serialmonkey> then we can add to it from there with other items we are aware of <ivd> Eh yes that would be a good idea. The list on the wiki is outdated. <gwingerde> Yes. Maybe we should set up a TODO area on the wiki, so that people can assign themselves to it. <ivd> Well for rt2x00 we had such a list <serialmonkey> Absolutely. Lets not just restrict it to dev tasks other - there are things that need addressing regarding doco, support, etc as well <ivd> http://rt2x00.serialmonkey.com/wiki/index.php/Rt2x00_beta <gwingerde> Yep, it's time to revive it. <lfcorreia> ... an I'm back <serialmonkey> Isn't it about time we dropped the 'beta' as well ? <bbatten> Speaking of dropping beta, would it be a good idea to add additional nextgen sections to the forum for chip-specific drivers? <lfcorreia> sorry, doze off five more minutes then it was predicted <ivd> It is about time we dropped that entire page :P <ivd> As well as the alpha page <serialmonkey> So, if we had to sum up the rt2x00 drivers in one word, what would it be Ivo ? <gwingerde> Yep, and in the forum we should rename rt2x00beta to just rt2x00 as well. <serialmonkey> obviously they are still marked as 'experimental' in the kernel <ivd> Well the first request to remove the CONFIG_EXPERIMENTAL dependency has been raised already <serialmonkey> for all chipsets ? <ivd> That has been rejected by me, mostly because of the different opinions on the meaning of CONFIG_EXPERIMENTAL <bbatten> I would think dropping "beta" designation and replace testing with per-chpset sections wouild be good. <ivd> yes <serialmonkey> OK, I'm going to start the todo wiki page now, and that can be the first item <ivd> rt2x00 support doesn't need to be split up into different sections yet. <ivd> But the titles could indeed change <bbatten> OK. I raise it because I seem to notice more postings having to do with chip- specific impementations, but that could just be me. <serialmonkey> http://rt2x00.serialmonkey.com/wiki/index.php/Todo <ivd> yes but the setup of the rt2x00 drivers makes most bugs be common to all chips. ;) <serialmonkey> OK, I've just listed the item then as rename and re-describe <bbatten> Your call, obviously. <serialmonkey> Anything else forum or website related that people have on their minds while we are there ? <bbatten> Just my perennial favoriet - huge font size. <lfcorreia> we need to do something about the legacy rt2800 driver <ivd> Why, we hardly have developers? <ivd> And unless Bryan wants to maintain 2 more legacy drivers... <lfcorreia> we would only go as far as setting up the debugfs patches to compare <bbatten> I don't think there's anything there that's remotely functional? <lfcorreia> the last time I tried it, it did work, but produced a very large kernel driver <serialmonkey> That would be something worthwhile passing around the developers, but we wouldn't release it I imagine <ivd> yes, some patches need to be collected for debugging purposes. But we need to google a bit for patches from other people as well, since there are quite a lot of issues with the driver <lfcorreia> ivd, at least we would state our position regarding legacy rt2800 <bbatten> To be honest, folks, I'm trying to constrain my involvement here. Two more drivers doesn't sound good. <gwingerde> Might be difficult to get to know the rt28xx drivers, as they are completely different from the other drivers (due to the 802.11n support) <lfcorreia> as i've always said we wouldn't support it <serialmonkey> How about we just update the wiki to post our official call on rt2800 (no legacy, just rt2x00) <ivd> Well I should still add 802.11n support to rt2x00lib, but like I said I am way behind schedule with the drivers. <bbatten> Maybe tap Ralink for involvement in the project? <lfcorreia> as we all know Ralink 'may' be interested in working with us in the future <gwingerde> Side note: did we get any data sheets of the rt2800 chipsets? <ivd> I have problems with the TX power, antenna and queue handling. <ivd> Yes, we have the rt2860 sheets <gwingerde> Could you send that around? I don't think I have it? <ivd> but not the rt2870 one, but rt2860==rt2870 without any differences other then different bus <bbatten> Oh, and did Ralink ever respond about RT2500 ISR masking? <lfcorreia> which are mostly useless, when making the register definition setup file, i've already spotted differences... <ivd> gwingerde: send <ivd> Well I never got the response to that mail (and you were in the CC so you would have gotten it as well) <lfcorreia> gwingerde, ralink even made some very strange errors in the docs, as usual <ivd> lfcorreia: but your register headers were bugged as well <lfcorreia> things like, stuff that should be PCI only and had USB related strings <ivd> I reverted several things to get it back in line with the legacy driver <serialmonkey> ivd: how much involvement do you want from us in 11n support - aren't you engaged as part of your coursework for that ? <ivd> They used the same register file for both drivers :P <lfcorreia> ivd, sure, it was really my first time at it <ivd> The entire rt2800 project including 802.11n is coursework. But also the testing documents. <gwingerde> How much 802.11n support do we need in the driver, as mac80211 already contains support for it? <ivd> And with current rate I won't be able to finish everything in time I am afraid. <ivd> Well I am still collecting the pieces I need to get from mac80211. I can't find the way to detect if BW_20 or BW_40 is enabled for example. <ivd> Also the rates to 108Mbs are a bit unclear. <ivd> On the other hand, those things should have been in rt61pci and rt73usb as well since those are pre-n devices. <serialmonkey> I see you have added the feature requests to the TODO page Ivo. Do you have a list of bugs as well ? <gwingerde> Hmm, maybe the support in mac80211 isn't complete, and only sufficient for the Intel chips. <ivd> Some of the 802.11n fields are still a bit unclear, since I do get a flag BANDWITH but what it means... :S <ivd> serialmonkey: buglist is a bit harder, I'll try to think of some main issues and add those later. <serialmonkey> no worries <lfcorreia> ivd, yes, we both have a pre-n device which is rt61 based <lfcorreia> and have different radio chips <ivd> True, but I have never added support for it. Hopefully it can be added when rt2800 is done <gwingerde> Hmm, hard to believe that rt61 is pre-n. <ivd> There are some pre-n versions. <gwingerde> Although, it might be possible with the right driver. <lfcorreia> gwingerde, it actually is <ivd> I got a MIMO card, the legacy driver is a big vague about it hence it was never really implemented. But hopefully with rt2800 I can fill in the missing pieces <lfcorreia> gwingerde, i never got it working in the past as my device has a dud eeprom <ivd> Check the rt61 legacy code, they do mention rates up to 108 Mbs <bbatten> When Ralink says mimo, I'm not always sure whether they're talking diversity, or true mimo - shared data channels. <gwingerde> OK. I guess I've only seen rt2800 based pre-n devices. <ivd> lfcorreia: dud eeproms are fixed in rt2x00 it autodetects that and fixes the values. Same as legacy driver <lfcorreia> gwingerde, but now that I have a 11n AP, it may be possible to test it, as ivd says <lfcorreia> ivd, yes but remember that it never detected the proper radio chip? <lfcorreia> it always assumed the default was another <ivd> lfcorreia: that belongs to the same fix. It now recovers and defaults to the RF chipset defined by Ralink. <ivd> serialmonkey: Several items on the rt2x00 TODO list aren't hard for coding, but are purely investigation things. <lfcorreia> ivd, in that case, i'm taking a note to try that one again in the near future <ivd> serialmonkey: especially the WDS and Mesh modes, since all I need to know is what those modes do and what is required for support and what limitations there are (can they run concurrently with other interfaces) <serialmonkey> requirements gathering basically <serialmonkey> ok, assigned <serialmonkey> ivd: when you go through your notes regarding bugs, do you want to just email them to me and I'll raise them in SF so we can track them ? <ivd> Well the most important bugs are those raised in the kernel and fedora bugzilla. So they are already tracked. But some of them have pending fixes and are waiting for John to push patches upstream. I'll set some links to the bug reports. <ivd> (regardless of the state) * free-zombie is now known as tjol <serialmonkey> No worries- we don't want to be tracking them in two places. Perhaps we should just try and keep a list of the links in the wiki for reference <bbatten> Might be good to provide forum members an area to post bugs to, though, and the Sourceforge project seems a good candidate for that. <ivd> Well they are already free to do so, so far all rt2x00 bugs in sf.net that have been raised were marked as invalid or fixed <serialmonkey> so, are there any support/documentation tasks that need to be addressed ? <serialmonkey> for example - I assume the whole wiki needs a review <bbatten> Silence? Are we going to talk about the Ralink proposal? <serialmonkey> Has gone abit silent yes. I was impressed with their response <bbatten> Ivo, could you flesh out goals wrt. Ralink working directly with the rt2x00 project? <lfcorreia> bbatten, talks have started <lfcorreia> Ralink is assessing it atm <ivd> Well what I asked from them is stopping with those Legacy drivers. They should focus directly on the in-kernel rt2x00 drivers expanding rt2x00lib and adding new drivers directly for rt2x00lib. <ivd> When some protocol things are missing from mac80211 they should implement that <bbatten> I mean our business goals. e.g. Do we want payment? Do we want their developers on the core team? <lfcorreia> bbatten, that is a nasty subject, we've discussed it a while ago <bbatten> Oh? And what did we say? <ivd> Payment would be very nice. When they are interested in providing the in-kernel drivers directly and thus developing rt2x00lib then perhaps they can be added to the project, but I don't think it would come that far. <serialmonkey> It just means we will work with them, kind of like Intel works with the wireless developers now <lfcorreia> bbatten, the talk was done internally between me Mark and Ivo <ivd> Well my position remains unchanged on the matter: as far as I am concerned Ralink can pay us for the support and work we have on this project. <lfcorreia> serialmonkey, more like they work with us :) <serialmonkey> and my position was that it's all too complicated and I didn't mind what you all did :-) <bbatten> OK. But what do we envisage the nature of their contribution to be? -- and, could you provide a summary of the internal talks you refer to? <ivd> lfcorreia: Some of it was internal, but that was mostly after contact was made with Ralink about how they felt about it. <lfcorreia> I don't do that much work as such, and I personally don't want money from Ralink <lfcorreia> the best think Ralink would do is provide more then just documentation and crappy drivers <gwingerde> Same here. I would envisage Ralink just donating code to us and to the Linux wireless community. <serialmonkey> gwingerde: agreed <lfcorreia> because we don't have any docs from the radio chips (except for the one that comes with rt2400) <bbatten> That's basically what they do now, isn't it? <gwingerde> And yes it would be appreciated if they could give us more than just crappy documentation and crappy code. <gwingerde> bbatten: Nope, I would envisage them contributing actual code to the rt2x00 driver, not a crappy coded own driver. <lfcorreia> there are a lot of issues from very simple things that if Ralink was present and active, would get proper responses and faster problem solving <bbatten> Ah. Looks like item one is better documentation from them. <bbatten> Looks like item two is direct involvement by Ralink staff in RT2x00 project code development. <ivd> As far as I am concerned better drivers. rt2x00 drivers instead of ported windows drivers. <lfcorreia> and also engineer support, stuff like 'application notes', that I normally see from other hardware * tjol is now known as tjol0 <lfcorreia> which translates to, better docs, better code, better examples on how to sort stuff out <bbatten> Does Ralink have that available to their customers, even? say under NDA? * tjol0 is now known as freezombie <ivd> I can live without the documentation, but I can't keep porting their drivers to rt2x00. That is simply taking too much time. <lfcorreia> bbatten, i know that ralink does sell AP code (crap code) to some major software developers * freezombie is now known as tjol <serialmonkey> basically we are asking them to cut their losses, dump the support of the legacy drivers and dump developing any new 'legacy' style drivers - and instead take some stake in the rt2x00 driver <lfcorreia> the dd-wrt guy got a contract that allowed him to access such code <ivd> lfcorreia: But that is simply the legacy code with additional tweaks <serialmonkey> I'm probably going to have to go offline in 10 minutes guys sorry. <ivd> serialmonkey: ok <lfcorreia> ivd, kind of, it's actually the AP code Asus leaked out some years ago, things havent' changed much <ivd> lfcorreia: did ASUS leak the code? I thought they only released the closed source blob? <bbatten> Basically, I think there needs to be some development of a proposal if Ralink responds further; specifics on what we envisage from them <lfcorreia> ivd, the code was available in their website for months, but only for their rt2400 card <ivd> In any case, rt2800 contains master mode support. And I am not impressed by it. Most of the new features in the rt2800 legacy driver have already been brought to all earlier rt2x00 drivers (virtual interfaces, master mode) <ivd> bbatten: Well that is what I had written in the mail which I had BCC'ed to coredev. <ivd> serialmonkey: All bugs from kernel.org and fedora are not listed on the todo wiki page <lfcorreia> ivd, /s/not/now/g/ ?? <serialmonkey> I think us developing a 'proposal' and presenting it to Ralink asking them to comply is going to be way too official, and possibly scare them off. Open Source development is all about community, not proposals <serialmonkey> ivd: thanks for that <lfcorreia> serialmonkey, think of it as a co-op instead of a commitment to do stuff <ivd> well you saw the mail, and they responded that they will investigate it. Next step will be up to them. <lfcorreia> serialmonkey, phrase it in simple english terms as we don't want to have the language barrier to get in the way <bbatten> The email is basically a general statement. We need specific bullet items to have in minde in case Ralink responds. <serialmonkey> Exactly - and hopefully from that they will assign a person to lead their side of the ongoing work and we can 'suggest' to them the steps they should be taking (getting involved in the linux-wireless mailing lists, etc) <bbatten> ... at least so *we* understand what we want. <ivd> If I am not mistaken, some other guy with connections to Ralink will recommend them for sttarting to pay us, but I am not sure if he already send out that recommendation or not. <gwingerde> But what would that mean: "pay us"? <ivd> bbatten: Well I am not sure what more you want to know, the list of end goals have been given to Ralink. When they are interested we can guide them towards that goal. <ivd> gwingerde: That they should see if there is any form which they see fit to provide financial backing to this project. <ivd> gwingerde: He is going to ask that Ralink comes up with an offer for further cooperation between Ralink and this project. <serialmonkey> Ideally, if they want to follow Intel's example, they may even offer to take ownership (in a responsibility sense) for rt2x00 and that means there will be nothing left for us todo anyway <ivd> but that will be finally up to Ralink <serialmonkey> Then they will probably turn around and want to hire Ivo todo the actual work, lol <bbatten> serial: Great, maybe they'll need our help <ivd> serialmonkey: that will be the ideal situation, but we end up probably providing support and maintenance of the older drivers. <ivd> Which is fine, as long as the dreaded "driver porting" is no longer needed. <bbatten> Basicaly, if they pay the piper, they call the tune. <lfcorreia> lets wait and see <serialmonkey> Whatever happens, I would be more comfortable with them coming to arrangement with individuals rather than the "group". "Group" payment introduces all sorts of other issues <ivd> true <gwingerde> Yep. <bbatten> True <lfcorreia> agree <serialmonkey> OK, so I ask that everyone adds items to the Todo page now we have it <gwingerde> And, as I've mentioned before, I'm not in it to get paid. They will never be able to pay be equally as my current job does. <lfcorreia> I also don't want money, new devices are fine, but that is how fa I would go <lfcorreia> fa=far <serialmonkey> lol, paid in hardware ;-) <ivd> hehe <bbatten> Although, if we want increased participation from Ralink, we need to understand that that is a cost to them, and think about how to motivate them to pay that cost. <lfcorreia> serialmonkey, right, at least i can then send the devices to whoever needs them most, like I already did <serialmonkey> It was good talking to you all again, it's been too long. Can someone post a log to the mailing list when your all done chatting ? <ivd> Well their drivers would be in the kernel sooner, meaning that general usage of the driver occurs faster. They already agreed that rt2800 usage in Linux is slow because of the lack of in-kernel drivers. <bbatten> What devices? Oh, and how's the test lab setup dong? <ivd> serialmonkey: cya <gwingerde> Guys, I need to sign off soon as well. <lfcorreia> bbatten, like the rt73 device I sent you <serialmonkey> bbatten: The server is online with all the hardware installed, I just haven't found a way to automate any tests <lfcorreia> serialmonkey, bye <serialmonkey> I'll add it to the todo <serialmonkey> cyas * serialmonkey has quit () <lfcorreia> gwingerde, nice talking to you again <ivd> bbatten: Donated hardware is send around to various developers when requested. <gwingerde> Just one final note from my side: from next week on I will be away for 4 weeks (combined business trip and holidays). <ivd> bbatten: Usually when we have a lot of hardware a mail is send to coredev to see who wants it. <ivd> gwingerde: Have fun on your semi-holiday then. ;) <bbatten> gwingerde: Happy holidays! <lfcorreia> gwingerde, have fun! <ivd> Guys, my time is up as well. <lfcorreia> ok, i'm also going to cut this one short <ivd> Cya <bbatten> OK. Looks like we're done. Are we? <gwingerde> Ciao. <ivd> Well with everyone leaving. ;) <bbatten> bye <lfcorreia> I'll post the developers log in the wiki, as i did in the past * bbatten (firstname.lastname@example.org) has left #rt2x00 <ivd> (Y) * ivd has quit ("using sirc version 2.211+KSIRC/1.3.12") * gwingerde (email@example.com) has left #rt2x00 ("Leaving")
Developer's meeting - October 7, 2007
We started off with a proposed agenda:
1) legacy support 2) current issues with rt2x00: 3) upcoming chipset support in rt2x00 (802.11n)
Since no one objected to it we started off.
After the meeting we agreed with this summary of discussed items:
1) legacy should be provided 'as-is' after rt2x00 has reached mainline kernel and at least one distro has released a version containing 2.6.24. in the meanwhile, we should keep it. 2) mac80211 API is causing some breakage to our driver. 3) 802.11n drivers: legacy driver should exist but not for end users. this means that the driver won't have any kind of development effort besides helping rt2x00.
The meeting full log follows:
**** BEGIN LOGGING AT Sun Oct 7 10:23:31 2007 Oct 07 10:23:44 * lfcorreia is testing log recording for the session. Oct 07 10:24:20 * lfcorreia confirms, loggins works :P Oct 07 10:40:01 * lfcorreia has changed the topic to: rt2x00 - Hack-a-thon on rt2x00, comming up in a few minutes Oct 07 10:53:02 <lfcorreia> ivd: do you have any changes you need to make on the git repo? if no, then we could all sync to it ans have it ready Oct 07 10:54:47 <ivd> give me 2 minutes and I'll commit the software diversity code Oct 07 10:55:04 <lfcorreia> ok Oct 07 11:00:00 * AdamBaker (firstname.lastname@example.org) has joined #rt2x00 Oct 07 11:00:37 <lfcorreia> AdamBaker: welcome! Oct 07 11:01:10 <ivd> I have committed the software diversity to git/cvs Oct 07 11:02:04 <ivd> rt61 and rt73usb antenna setup is still a little/average/completely broken Oct 07 11:02:45 <sum> *G* Oct 07 11:03:01 <sum> is it correct, that i need to make "cg update" now? Oct 07 11:03:06 <ivd> But since the antenna setup code is still pending for a complete review, I hope that with the SW diversity code in, we at least have some progress on link quality/transfer speed Oct 07 11:03:11 <sum> (i have previously checked out "upstream") Oct 07 11:03:13 <ivd> yup Oct 07 11:03:23 <sum> ok, thx Oct 07 11:03:39 <AdamBaker> Hi, I haven't got time to follow what's going on here all afternoon but I'll drop by as and when I can Oct 07 11:04:17 <lfcorreia> AdamBaker: no problem, we're still some time from the actual meeting start Oct 07 11:05:11 <lfcorreia> ivd: regarding antenna setup, there is something we can't forget, most of the PCI devices only have one true antenna, but it is very difficult to actually know which is which Oct 07 11:06:11 <lfcorreia> because miniPCI devices (and probably USB also) can have from one to three antennas, whereas an internal PCI card will have ony one (unless it's a MIMO...) Oct 07 11:06:14 <ivd> I think we can assume that when there is only 1 antenna, then the EEPROM will indicate the default antenna is A or B. Or in any case not DIVERSITY Oct 07 11:07:17 <sum> when is the meeting start? Oct 07 11:07:21 <ivd> And the eeprom also indicates the number of available antenna's, so perhaps we should do something with that as well. But like I said, the antenna code must be reviewed anyway. Oct 07 11:07:39 <ivd> I feel there are still too many differences between legacy and rt2x00 Oct 07 11:08:01 <ivd> And each of those differences could be the case of poor sensitivity or low transfer speeds Oct 07 11:08:52 <lfcorreia> and unfortunately not all manufacturers care much about properly setting EEPROM parameters, so we're kinda stuck here Oct 07 11:09:20 <ivd> Well if that is the case, then the legacy driver wouldn't work either. Oct 07 11:09:23 <lfcorreia> sum: we'll wait some more minutes for Mark to show up Oct 07 11:09:46 <ivd> And since that is usually working we can assume rt2x00 is still doing something wrong/ Oct 07 11:09:55 <lfcorreia> ivd: yes, unless it has all those magical values for when it finds the broken eeprom Oct 07 11:10:21 <ivd> yes but even then we use the defaults given by the legacy drivers Oct 07 11:10:39 <lfcorreia> yep, tricky indeed Oct 07 11:11:23 <ivd> so we must follow the legacy drivers quite strictly. Which is the reason I am so keen on requesting code and register initialization validation Oct 07 11:11:28 <sum> what about some kind of rescue-procedure... there won't be many places around where absolutley no wlan-packets are flying through the air... Oct 07 11:11:35 * lfcorreia has changed the topic to: rt2x00 developers meeting + hack-a-ton comming up in 15 minutes (give or take) Oct 07 11:12:06 <ivd> sum: What do you mean? Oct 07 11:12:33 <sum> well, if eeprom settings are broken, we could just do scan's with different antenna/diversity/etc. settings and check which one works best. Oct 07 11:12:49 <sum> this could done by some user-space tool, indeed Oct 07 11:13:21 <ivd> Well we currently grab the defaults from the legacy drivers. rt61 and rt73 grab the diversity as default. And that means it will switch between antennas to search for the best setup Oct 07 11:13:35 <sum> ah, ok Oct 07 11:13:44 <sum> so "diversity" is the switching? Oct 07 11:14:34 <ivd> yeah, there is software diversity and hardware diversity. With software diversity we keep track of the measured RSSI for a specific antenna. And when the RSSI is fluxing too much we switch to the other antenna Oct 07 11:14:54 <sum> ah, ok. i dind't get that correct, then Oct 07 11:14:58 <lfcorreia> the diversity theory states that due to the short wavelenght of wireless signals, we can switch to the other antenna and still receive the signal Oct 07 11:15:14 <lfcorreia> ans RSSI regulates this switching method Oct 07 11:16:16 <sum> brb Oct 07 11:16:31 <AdamBaker> The intention is to cope with receive nulls - if you get the antenna in the wrong position it will receive a weak signal from the wanted AP even if it gets a good signal from other APs Oct 07 11:17:14 <AdamBaker> Unfortunately it seems some manufacturers have used it to solve other problems like switching between internal and external antennas if the external antenna is fitted Oct 07 11:18:58 <AdamBaker> I don't think we yet know why there are both SW and HW diversity options and in some cases the latter doesn't work Oct 07 11:19:07 <ivd> true, but we shouldn't be bothered with that. Basically we need to do what the legacy driver is doing untill some nice userspace tool is created which can handle software diversity Oct 07 11:20:56 <AdamBaker> agreed I was just pointing out the reasons we need to implement everything legacy does Oct 07 11:21:07 <ivd> ok :) Oct 07 11:24:17 * saittam (n=saittam@pD956653A.dip.t-dialin.net) has joined #rt2x00 Oct 07 11:24:49 <lfcorreia> saittam: Welcome! Oct 07 11:24:58 <saittam> hi all :-) Oct 07 11:25:04 <Spy84464> hi Oct 07 11:27:23 <blathijs> oeh, it's that hack-a-ton today :-) Oct 07 11:27:49 <blathijs> Too bad I have other things to do, but if this WLAN connection lasts far enough I might lurk around Oct 07 11:29:20 <lfcorreia> blathijs: hang around, you might see something funny comming up Oct 07 11:31:47 <lfcorreia> Gentleman, we're about to start our developers meeting Oct 07 11:31:58 <lfcorreia> here's the proposed agenda for today: Oct 07 11:32:15 <lfcorreia> Agenda Oct 07 11:32:15 <lfcorreia> 1) legacy support Oct 07 11:32:15 <lfcorreia> 2) current issues with rt2x00: Oct 07 11:32:15 <lfcorreia> 3) upcoming chipset support in rt2x00 (802.11n) Oct 07 11:32:42 <lfcorreia> anyone suggests other topics worth mentioning? Oct 07 11:33:14 * lfcorreia waits some time before proceeding Oct 07 11:34:14 <ivd> I guess not. :) Oct 07 11:34:34 <lfcorreia> ok then Oct 07 11:35:06 * lfcorreia has changed the topic to: rt2x00 developers meeting has started Oct 07 11:35:22 <lfcorreia> first topic, legacy support: Oct 07 11:35:28 <lfcorreia> 1) legacy support Oct 07 11:35:28 <lfcorreia> there is way too much effort being placed on Oct 07 11:35:28 <lfcorreia> legacy drivers. rt2x00 needs our full attention Oct 07 11:35:28 <lfcorreia> and legacy should be only used to figure out the Oct 07 11:35:28 <lfcorreia> differences needed to make rt2x00 work Oct 07 11:35:35 <lfcorreia> . Oct 07 11:36:24 <ivd> well this has always been a hot topic. Oct 07 11:36:54 <lfcorreia> everyday I keep seeing lot's of topics from users asking for help on legacy (and even ralink's) code Oct 07 11:37:07 <Spy84464> Agreed, but legacy are also needed for people running 2.4 and early 2.6 Oct 07 11:37:20 <saittam> also rt2x00 doesn't work for some people Oct 07 11:37:34 <Spy84464> for the time being only ;) Oct 07 11:37:34 <lfcorreia> and, even now as I keep seeing more and more rt2x00 related ones, that is not enough Oct 07 11:37:39 <saittam> those who cannot or don't want to compile a git kernel. Oct 07 11:37:53 <ivd> True, but with legacy drivers as comparison material we can improve rt2x00 to get rt2x00 working correctly Oct 07 11:38:08 <lfcorreia> well, Ivo tries to get CVS code compilable on older kernels Oct 07 11:38:24 <ivd> rt2x00 is scheduled for 2.6.24 that means that if rt2x00 is stable by then, then people don t have to use git Oct 07 11:38:35 <sum> re Oct 07 11:38:36 <ivd> lfcorreia: No I don't Oct 07 11:38:44 <lfcorreia> I can't and won't help a guy that uses a *ubunto live cd Oct 07 11:38:44 <Spy84464> yes, and distribution have already started to ship it Oct 07 11:39:00 <Spy84464> fedora and ubuntu I think Oct 07 11:39:09 <ivd> Fedora, Ubuntu, SuSE Oct 07 11:39:14 <saittam> and suse. remember that guy on the ml? Oct 07 11:39:15 <lfcorreia> ivd: i know, but CVS code is being somewhat maintained Oct 07 11:39:18 <ivd> Fedora seems to be most up to date Oct 07 11:39:45 <ivd> lfcorria: rt2x00 CVS is the exact copy of rt2x00.git Oct 07 11:39:56 <lfcorreia> yes, fedora has one of the most up-to-date versions of our rt2x00 code Oct 07 11:40:01 <ivd> lfcorreia: I have a script that copies and commits Oct 07 11:40:07 <ivd> from git to cvs Oct 07 11:40:24 <lfcorreia> ivd: oh, then it was me who was making the wrong assumptions Oct 07 11:40:26 <saittam> well, who's actually spending much time on legacy? I only check it when rt2x00 is broken... Oct 07 11:40:42 <lfcorreia> all: could we focus on trying to push our users to git? Oct 07 11:40:59 <ivd> Bryan & Ibrahim are doing legacy Oct 07 11:41:01 <sum> when will 2.6.24 be released? Oct 07 11:41:10 <ivd> Robin & GertJan are looking at both Oct 07 11:41:14 <ivd> sum: In a few months Oct 07 11:41:31 <saittam> I don't think we can push users to git. Sometimes it's fine, sometimes it's plain broken. Oct 07 11:41:32 <ivd> 2.6.23 has just been released and the merge window for 2.6.24 will close in a week or 2 Oct 07 11:41:42 <saittam> so you'd have to provide something more stable and known to work. Oct 07 11:41:49 <saittam> maybe a stable branch? Oct 07 11:42:12 <ivd> Well the stable branch should be in the wireless-2.6 tree. Oct 07 11:42:18 <lfcorreia> saittam: John has pushed rt2x00 to 2.6.24 as it is currently Oct 07 11:42:37 <ivd> I try to push patches to that reposity when most people are satisfied. Oct 07 11:42:46 <lfcorreia> and he says it's best to push it up then to have it wait indefinetely somewhere off mainline Oct 07 11:42:52 <sum> hm. what if we ship a package of ieee80211 and mac80211 modules together with rt2x00, so that could compile on older kernels? Oct 07 11:42:56 <ivd> Sometimes however reports about breakage come after the push to wireless-2.6 Oct 07 11:43:14 <saittam> that's because we're busy with all sorts of other stuff :-) Oct 07 11:43:25 <lfcorreia> sum: what do you mean about ieee80211? Oct 07 11:43:31 <sum> ivd: sorry for that, but it worked with the rt2x00-tree Oct 07 11:43:39 <ivd> sum: That has been discussed on the ML, if you are volunteering to that job, that that is fine. Oct 07 11:44:01 <sum> lfcorreia: well, if the only reason, rt2x00 can't build on 2.6.22 is that the other 80211-modules changed, we could package them up as wll... Oct 07 11:44:08 <ivd> sum: But basically keeping rt2x00 to compile on olders kernels, is too much work for me, and it slows rt2x00 progress Oct 07 11:44:44 <sum> make a package that contains rt2x00 and all needed 80211-modules inthe correct version... Oct 07 11:45:03 <lfcorreia> sum: intel was making some backport on the mac80211 API to make it compilable on older kernels, but i'm not sure wheteer that is useable anymore Oct 07 11:45:08 <Spy84464> sum: that was the situation a little while ago Oct 07 11:45:13 <ivd> sum: You mean creating a rt2x00 package for each kernel? Then how do you want to apply bugfixes/ Oct 07 11:45:32 <sum> well,, maybe i just get the problem wrong... Oct 07 11:45:34 <saittam> sounds like a full-time job ;-) Oct 07 11:45:49 <ivd> exactly, that was the reason why that idea was dropped. Oct 07 11:46:09 <ivd> It isn't the best solution, I agree, but with the availble resources it is the best solution I think Oct 07 11:46:11 <sum> so the problem is 80211-related and not rt2x00 specific? Oct 07 11:46:21 <lfcorreia> sum: exactly Oct 07 11:46:26 <saittam> it's just that everything involved moves too fast... Oct 07 11:46:34 <ivd> rt2x00 depends on mac80211 and the mac80211 API changes. Which means that rt2x00 needs to follow those changes. Oct 07 11:46:56 <ivd> I gtg for 20 minutes. l'b be back later Oct 07 11:47:20 <sum> ivd: what about putting a working version of both (mac80211 and rt2x00) into one single tar.gz and give that one to people. so we shouldn't have too much to do with it but at least there is something... Oct 07 11:48:05 <Spy84464> it may not be possible, mac80211 may depend on stuff from the rest of the kernel Oct 07 11:48:12 <Spy84464> like encryption modules Oct 07 11:48:22 <Spy84464> and their API may change as well Oct 07 11:48:26 <lfcorreia> sum: things are not that simple Oct 07 11:48:27 <sum> ah ... Oct 07 11:48:34 <sum> ok, sorry for that ;-) Oct 07 11:48:39 <lfcorreia> sum: no problem Oct 07 11:49:03 <saittam> seems we agree again that we won't do it :-) Oct 07 11:49:07 <lfcorreia> it is just that most people don't actually realize the effort being put on a 'simple' wlan drvier Oct 07 11:49:15 <sum> saittam: i do, indeed. Oct 07 11:49:18 <lfcorreia> saittam: right on! Oct 07 11:49:53 <lfcorreia> all: do we have more volunteers to shift focus towards rt2x00? Oct 07 11:50:21 <saittam> I've only ever done rt2x00 work, so I cannot shift ;-) Oct 07 11:50:30 <sum> same here ;) Oct 07 11:50:35 <Spy84464> do you mean dropping legacies? Oct 07 11:50:49 <lfcorreia> all: or at least use legacy only for comparison features Oct 07 11:51:16 <Spy84464> lfcorreia: so providing them "as it"? Oct 07 11:51:19 <saittam> I think the point here is whether someone does compilation fixes for newer kernels or not? Oct 07 11:51:20 <lfcorreia> Spy84464: well, it would be a GoodThing(TM) to do, but I won't actually do it Oct 07 11:51:36 <lfcorreia> saittam: it's actually the opposite Oct 07 11:51:49 <lfcorreia> saittam: making the rt2x00 following older ones :) Oct 07 11:52:27 <lfcorreia> legacy drivers should never have got so far as they did Oct 07 11:52:32 <sum> do i get this right: there is a hole between 2.6.22.something and 2.6.24 where neither the legacy nor the rt2x00 driver work? Oct 07 11:52:39 <Spy84464> no Oct 07 11:52:51 <Spy84464> legacy work everywhere Oct 07 11:52:55 <Spy84464> as far as I know Oct 07 11:53:17 <sum> so, then i would suggest telling people that legacy only works until 24 and after that the must use rt2x00 ;-) Oct 07 11:53:23 <lfcorreia> we've lost now about a year and a half focusing work on legacy whereas we should have been looking up to rt2x00 Oct 07 11:53:34 <saittam> I remember trying rt73 on ppc. It was plain broken. Oct 07 11:53:34 <lfcorreia> sum: that is the intended idea Oct 07 11:54:09 <lfcorreia> saittam: yes, because noone tested it :) i don't and won'0t have a ppc so I can't help Oct 07 11:54:10 * sum votes for "the idea". Oct 07 11:55:26 <lfcorreia> we (the main developers) have internally talked about the whole legacy drop after the rt2x00 driver has entered the mainline kernel Oct 07 11:55:45 <lfcorreia> it make absolutely no sense in keeping up effort on 'old stuff' Oct 07 11:56:27 <Spy84464> yes, but we should keep them for a little while anyway Oct 07 11:56:52 <Spy84464> at least until major distributions adopt the 2.6.24 kernel Oct 07 11:57:05 <lfcorreia> sure Oct 07 11:57:19 <lfcorreia> i know that doing a git kernel is not easy Oct 07 11:57:25 <sum> how long do you thing will the api still be in changing? Oct 07 11:57:32 <saittam> sum: ever! Oct 07 11:58:25 <lfcorreia> but honestly, if people still come to the forum and ask dumb questions without even using the search buttons.... i don't know what to say Oct 07 11:58:37 <lfcorreia> the kernel API will change a bit longer Oct 07 11:58:49 * serialmonkey (email@example.com) has joined #rt2x00 Oct 07 11:58:49 * ChanServ gives channel operator status to serialmonkey Oct 07 11:58:57 <lfcorreia> remember that the ad-hoc and master modes are still largely undefined Oct 07 11:59:04 <lfcorreia> serialmonkey: Welcome Mark! Oct 07 11:59:40 <lfcorreia> serialmonkey: we've already started, I can provide you with a log of previous conversation, if you're interested Oct 07 12:00:01 <serialmonkey> lfcorrei: already started ? I must have mixed up the time zones again - thought we had another hour. Oct 07 12:00:10 <saittam> na, we're early :-) Oct 07 12:00:17 <serialmonkey> Phew :-) Oct 07 12:00:23 <lfcorreia> serialmonkey: no, we just started half an hour earlier Oct 07 12:00:29 <lfcorreia> serialmonkey: don't worry mate Oct 07 12:00:56 * Offering FreeNode (formerly OpenProjects.net)-#rt2x00.log to serialmonkey Oct 07 12:01:54 <lfcorreia> serialmonkey: topic is: 1) legacy support Oct 07 12:01:54 <lfcorreia> there is way too much effort being placed on Oct 07 12:01:54 <lfcorreia> legacy drivers. rt2x00 needs our full attention Oct 07 12:01:54 <lfcorreia> and legacy should be only used to figure out the Oct 07 12:01:54 <lfcorreia> differences needed to make rt2x00 work Oct 07 12:03:07 * DCC SEND FreeNode (formerly OpenProjects.net)-#rt2x00.log to serialmonkey aborted. Oct 07 12:03:21 * Offering FreeNode (formerly OpenProjects.net)-#rt2x00.log to serialmonkey Oct 07 12:05:07 <lfcorreia> all: let Mark read on the previous chat session and we'll resume shorttly Oct 07 12:05:17 <lfcorreia> all: that means 'take five :)' Oct 07 12:06:03 <sum> can someone just tell me how to list all git-submits that modify files in a certain directory? Oct 07 12:06:22 * DCC SEND FreeNode (formerly OpenProjects.net)-#rt2x00.log to serialmonkey timed out - aborting. Oct 07 12:07:12 <lfcorreia> sum: maybe going into that directory and do a 'git log', who knows :) Oct 07 12:07:25 <sum> ah, thanks :) Oct 07 12:07:36 <saittam> yeah, you can also do git log <path> Oct 07 12:07:54 <lfcorreia> or you can go to the gitweb interface and look at it remotely Oct 07 12:08:38 * lfcorreia will be back in five minutes, now behave :) Oct 07 12:09:09 <sum> yeah, actually you need the path, else the whole git will be logged... Oct 07 12:17:39 <sum> when i do "git revert SHA-ID_of_some_commit", will only that commit be reverted or anything else later, too? Oct 07 12:18:21 <saittam> sum: anything. Oct 07 12:18:22 * serialmonkey has quit () Oct 07 12:19:36 * serialmonkey (firstname.lastname@example.org) has joined #rt2x00 Oct 07 12:19:36 * ChanServ gives channel operator status to serialmonkey Oct 07 12:23:22 * lfcorreia is back Oct 07 12:23:43 <lfcorreia> ok, we're going to proceed with this meeting Oct 07 12:24:01 <sum> saittam: sure? this is the result: http://rafb.net/p/rDbo3l24.html Oct 07 12:24:35 <lfcorreia> we really need your help in 'fighting' legacy :) Oct 07 12:24:49 <lfcorreia> ok, updated agenda: Oct 07 12:24:59 <lfcorreia> Agenda Oct 07 12:24:59 <lfcorreia> *1) legacy support Oct 07 12:24:59 <lfcorreia> 2) current issues with rt2x00: Oct 07 12:24:59 <lfcorreia> 3) upcoming chipset support in rt2x00 (802.11n) Oct 07 12:25:07 <lfcorreia> on to topic 2) Oct 07 12:25:16 <lfcorreia> 2) current issues with rt2x00: Oct 07 12:25:16 <lfcorreia> suspend-resume, Oct 07 12:25:16 <lfcorreia> ad-hoc is broken, Oct 07 12:25:16 <lfcorreia> quick disassociations Oct 07 12:25:16 <lfcorreia> scanning inconsistancy Oct 07 12:25:17 <lfcorreia> rt73 broken Oct 07 12:25:41 <sum> let's start from the end of the list ;-) Oct 07 12:26:20 <lfcorreia> i've been testing the latest code from git, after having compiled it on my devel machine Oct 07 12:26:37 <lfcorreia> none of my 3 usb dongles are working, two rt73 and one rt2500usb Oct 07 12:26:49 <sum> rt73usb isn't working here, too. Oct 07 12:26:56 <lfcorreia> they just can't get any scanning results Oct 07 12:28:13 <serialmonkey> Ivo: I take it 'issue list #6' is the most recent ? Oct 07 12:28:30 <sum> hm. i didn't test scan. but assiciation works but traffic isn't possible: only outgoing frames are ok, incoming frames are broken (i have written that on the ML...) Now i have reverted "[PATCH] mac80211: use RX_FLAG_DECRYPTED for sw decrypted as well" and reception is ok again... Oct 07 12:28:45 <lfcorreia> serialmonkey: no, it's #7 Oct 07 12:29:03 <serialmonkey> lfcorreia: ah yes, I see it now. Thanks. Oct 07 12:30:14 <ivd> I'm back Oct 07 12:30:25 <ivd> serialmonkey: #7 is indeed the latest Oct 07 12:30:44 <lfcorreia> sum: that was the patch that Johannes made, right? Oct 07 12:31:10 <lfcorreia> ivd: we've jumped to topic 2) on the agenda Oct 07 12:31:18 <ivd> ok :) Oct 07 12:33:01 <lfcorreia> Agenda summary of already discussed items: Oct 07 12:33:01 <lfcorreia> legacy should be provided 'as-is' after rt2x00 has reached mainline kernel and at least one distro has released a version containing 2.6.24. in the meanwhile, we should keep it. Oct 07 12:33:03 <sum> lfcorreia: lfcorreia i think so. Oct 07 12:33:36 <serialmonkey> ok Oct 07 12:34:07 <ivd> sounds good Oct 07 12:34:20 <saittam> cool. Oct 07 12:37:26 <AdamBaker> Is there any need to wait for a distro to adopt 2.6.24, if distro's are using older kernels then the existing legacy should work Oct 07 12:37:34 <sum> really looks like this patch breaks receiving... Oct 07 12:38:04 <lfcorreia> AdamBaker: this 'wait' is merely a suggestion, not a true requirement Oct 07 12:39:20 <lfcorreia> AdamBaker: it's more of an 'excuse' to finally drop legacy for the 2.6 kernel series (we know it still works for 2.4) Oct 07 12:40:03 <AdamBaker> Ultimately it is up to whoever wants to work on it - I abandoned legacy a long time ago when I realised I was never going to get it working on big endian ARM Oct 07 12:40:19 <AdamBaker> I think rt2x00 hitting mainline is the best excuse though Oct 07 12:40:34 <serialmonkey> Most definitely Oct 07 12:40:53 <saittam> sum: Yeah, it's that patch. Problem is in net/mac80211/wpa.c. It checks for the FLAG and thinks it's already been decrypted, so it doesn't decrypt. Oct 07 12:41:01 <serialmonkey> Talking about what we are going todo with legacy is all abit pointless until we are in a position to actually call rt2x00 stable. Oct 07 12:41:26 <sum> saittam: so its not rt2x00 related :) Oct 07 12:43:10 <lfcorreia> saittam: did you find out the reason for that patch? Oct 07 12:43:38 <saittam> lfcorreia: no idea ;) Oct 07 12:44:25 <saittam> we can just roll a patch that sets the flag after calling the decryption algos in ieee80211_rx_h_decrypt. Oct 07 12:44:51 <saittam> that'll keep the old patch and get it working with minimal changes. Johannes will speak up if he doesn't like it. Oct 07 12:44:57 <lfcorreia> saittam: if you provide a patch against most current ivd git tree, I can test it right away Oct 07 12:45:07 <saittam> will do, just a sec. Oct 07 12:47:27 <sum> but packages of "special" lengths are still not transmitted from rt73... Oct 07 12:47:37 <sum> could this also be encryption-related? Oct 07 12:47:58 <saittam> note that unencrypted frames shouldn't be affected. has anyone tested this? Oct 07 12:47:59 <AdamBaker> I think it is bitrate related Oct 07 12:48:12 <AdamBaker> (the special lengths) Oct 07 12:48:46 <AdamBaker> Once I hacked 11g to work again the special lengths problem went away Oct 07 12:49:14 <sum> AdamBaker: true, only 11m doesn't work, 2 and 5.5 works here with ping -s 68... Oct 07 12:50:00 <sum> btw, are there any docs about the chip and firmware? Oct 07 12:50:35 <ivd> sum: Yes. But they are restricted to only members of the rt2x00 team. Oct 07 12:51:01 <ivd> sum: But fear not, they are hardly usefull, the legacy driver provide far more information and more accurate information then the specsheets Oct 07 12:51:22 <saittam> ok, patch is at http://rafb.net/p/2tnAK319.html Oct 07 12:51:29 <saittam> only compile-tested though. Oct 07 12:51:39 <lfcorreia> sum: and there is no information about the firmware internals Oct 07 12:51:39 <AdamBaker> just confirmed that disabling WEP makes RT73 work again for me Oct 07 12:52:20 <saittam> There is another lenght-padding related thing I'd like to bring up: Oct 07 12:52:44 <saittam> If we post the skb buffer in the urb and increase length (up to 7 bytes in the rt73 case). Oct 07 12:53:08 <ivd> saittam: Should the flag RX_FLAG_DECRYPTED be set unconditionally or depending on the status of the decryption? Oct 07 12:53:09 <saittam> How do we guard against the problem that the buffer is actually shorter? Oct 07 12:53:50 <saittam> ivd: if decryption isn't successful, the frame is dropped immediately. Oct 07 12:54:11 <saittam> ivd: note that result is initialized as TXRX_DROP. Oct 07 12:54:28 <ivd> saittam: The skb buffer might indeed be shorter, but the USB layer will copy that to the allocated DMA. If the length is longer then skb->len it will probably copy some random bytes as well. Oct 07 12:54:43 * lfcorreia announces the Metting log wiki page: http://rt2x00.serialmonkey.com/wiki/index.php?title=Meetings Oct 07 12:54:44 <ivd> saittam: Ok Oct 07 12:54:53 <saittam> so does the device care about these bytes? Oct 07 12:55:14 <saittam> ivd: I mean we should make sure they are valid and zero them out if we want to be on the safe side. Oct 07 12:56:24 <ivd> saittam: I understand, but legacy drivers doesn't seem to do that either. Neither should it be important because the device knows the correct length because of the header. This means it will probably just ignore the random bytes Oct 07 12:57:42 <saittam> ivd: ah, ok. Oct 07 12:58:09 <saittam> ivd: what about the possibly invalid memory references the usb layer reads from on our behalf? Oct 07 12:59:13 <ivd> Well it should only be reading it. So as long as it doesn't write it shouldn't hurt. Since we are allowed to keep using a skb that is send to the device, the assumption the USB layer is reading it only would be safe enough Oct 07 13:00:24 <saittam> ivd: well, ok then. Oct 07 13:00:53 <AdamBaker> The problem that might occur is if the skb is right at the end of a memory page and the extra few bytes overflow to the next unallocated page. I think the alignment guarantees of an skb mean that can't happen Oct 07 13:02:12 <ivd> well it is either the current approach or expensive tail reallocation for each frame we should send Oct 07 13:02:35 <saittam> let's hope so. I'll hack a skb_tailroom() printk into the code anyway to see whether short skb buffers are related to packet loss. Oct 07 13:02:48 <ivd> ok :) Oct 07 13:03:08 <saittam> but not now, since I'm using the rt73 as my internet connection :-) Oct 07 13:03:30 <ivd> hehe :) Oct 07 13:03:32 <saittam> anyone has an idea why the driver deterministically drops packets of certain lenghts? Oct 07 13:03:39 <saittam> or does it as of current git? Oct 07 13:04:09 <ivd> well it depends is the packet loss caused by: Oct 07 13:04:20 <ivd> a) packet of a certain size cannot be send Oct 07 13:04:29 <ivd> b) packet of a certain size cannot be received Oct 07 13:04:52 <saittam> I'm after a) Oct 07 13:04:55 <sum> saittam: your patch doesn't apply ... Oct 07 13:05:03 <sum> multiple Adds trailing whitespace. Oct 07 13:05:19 <saittam> sum: I'll repost on the mailing list. Oct 07 13:05:24 <sum> ivd: which length can't be received? Oct 07 13:05:31 <sum> saittam: thx Oct 07 13:06:08 <ivd> saittam: If it is (a) I am suspecting the rt2x00lib_write_tx_desc() function to be calculation the PLCP values incorrectly Oct 07 13:06:36 * AdamBaker has quit (Read error: 104 (Connection reset by peer)) Oct 07 13:07:28 <lfcorreia> saittam: great, just had a kernel panic :9 Oct 07 13:07:39 <saittam> ivd: I'll have to retest later with current git. IIRC, I couldn't see the packets on my other machine. Oct 07 13:07:56 <saittam> lfcorreia: sorry, I said it's only been compile-tested :-) Oct 07 13:08:02 <lfcorreia> your patch did apply though Oct 07 13:08:11 <lfcorreia> saittam: it's not your problem at all Oct 07 13:08:16 <lfcorreia> rest assured Oct 07 13:08:29 <ivd> saittaim: Well my second guess would be antenna problems Oct 07 13:08:34 * lfcorreia has to be away from the meeting Oct 07 13:08:41 * AdamBaker (email@example.com) has joined #rt2x00 Oct 07 13:09:02 <lfcorreia> Friendly agenda reminder: 2) current issues with rt2x00: Oct 07 13:09:03 <lfcorreia> suspend-resume, Oct 07 13:09:03 <lfcorreia> ad-hoc is broken, Oct 07 13:09:03 <lfcorreia> quick disassociations Oct 07 13:09:03 <lfcorreia> scanning inconsistancy Oct 07 13:09:03 <lfcorreia> rt73 broken Oct 07 13:09:24 * lfcorreia is now known as lfcorreia_away Oct 07 13:09:26 <saittam> ivd: ok, will have a look, but I'll be away for the first half of next week. Oct 07 13:09:42 <AdamBaker> I recommend not testing the patch to fix s/w decrypt in mac80211 - it just kernel paniced on me Oct 07 13:10:01 <sum> hmm. strange.. Oct 07 13:10:08 <saittam> so I guess I'd better take the patch off the web :-) Oct 07 13:10:21 <saittam> do you have stack traces available? Oct 07 13:10:28 <sum> the break is missing! Oct 07 13:10:34 <saittam> uh, right :-) Oct 07 13:10:51 <sum> but shouldn't panic, eh? Oct 07 13:11:13 <AdamBaker> no - I didn't have a serial console plugged in and it paniced not Oopsed Oct 07 13:11:31 <AdamBaker> it worked fine with encryption disabled Oct 07 13:11:42 <sum> maybe the rx->u pointer is not valid after decryption any more? Oct 07 13:14:10 * drear has quit (Read error: 148 (No route to host)) Oct 07 13:15:59 <saittam> sum: it shouldn't panic, you're right. Oct 07 13:16:09 <saittam> I hope this one is better: http://rafb.net/p/SSGtMI20.html Oct 07 13:17:12 <saittam> just curious: anyone of you guys interested in suspend/resume? Oct 07 13:17:26 <AdamBaker> please excuse me if I wait till the meeting is over to test it Oct 07 13:17:31 <sum> ok, even with the break, doesn't panic but packets of 96 bytes in total don't get send.. Oct 07 13:17:41 <sum> reception ok Oct 07 13:17:51 <saittam> sum: was only meant to fix reception. Oct 07 13:17:55 <sum> yep. Oct 07 13:17:55 <AdamBaker> are you using WPA or WEP? Oct 07 13:17:57 <ivd> saittam: Inam interested in all rt2x00 bugs. ;) Oct 07 13:17:58 <sum> WPA2 Oct 07 13:18:05 <saittam> ivd: *gg* Oct 07 13:18:22 <sum> but the transmission bug is definitely 11mbit related. Oct 07 13:18:30 <saittam> AdamBaker: me too, will test tonight. Oct 07 13:18:31 <AdamBaker> I guess the panic could be in the WEP code then Oct 07 13:19:26 <saittam> saittam: Na, it's probably in one of the two others. WEP decrypt gets called first and the others probably received invalid state. Oct 07 13:19:38 <sum> as i already mentioned on the ML, the transmission bug is in there since the rt2x00 code is in git... Oct 07 13:20:17 <saittam> sum: But only 11mbit, right? Oct 07 13:21:08 <AdamBaker> Is the length problem limited to rt73? Has anyone tested RT61 or RT2500usb? Oct 07 13:21:28 <saittam> AdamBaker: I only have rt73 hardware... Oct 07 13:22:14 <AdamBaker> Me too - that's why I couldn't test it myself Oct 07 13:22:20 <saittam> I'd also be interesting to see whether legacy has frame length issues... Oct 07 13:28:35 * saittam reboots with the patch compiled in. Oct 07 13:28:48 * saittam has quit ("Leaving") Oct 07 13:33:06 <sum> hm, i think there was someone who reported problems with rt2500... Oct 07 13:35:00 <sum> hm, no Oct 07 13:36:22 * saittam (n=saittam@pD956653A.dip.t-dialin.net) has joined #rt2x00 Oct 07 13:36:33 <sum> saittam: yes, 2 and 5.5mbit are ok Oct 07 13:36:44 <sum> or at least with that one length i have tested... Oct 07 13:36:53 * saittam is back with WPA2 working and packets dropped at 11mbit ;-) Oct 07 13:37:20 <saittam> i'm now on a wired connection :) Oct 07 13:37:56 <sum> hm. do you know a way how to force the driver to a lower bitrate? Oct 07 13:38:00 <saittam> Adam, have you received any response to your inquiry about rate selection? Oct 07 13:38:06 <sum> or does wpa_supplicant change the bitrate? Oct 07 13:38:26 <saittam> sum: I don't know, but let's fix the 11mbit problem first :-) Oct 07 13:38:52 <sum> yes, i wanted to try if the driver also fails at 5.5 mbit, maybe with different lengths... Oct 07 13:39:15 <saittam> sum: Have you tried to change the padding, maybe even to 8 bytes or something? Oct 07 13:39:57 <saittam> note that legacy rt73 even has different padding rules for different kinds of packets. mlme-packets are only padded to 2-byte boundaries IIRC. Oct 07 13:40:25 <sum> no, i didn't change padding Oct 07 13:40:47 <sum> i would like to know if nothing is sent or if wrong-length/corrupted packets are sent... Oct 07 13:42:24 <saittam> I'll check, just switched on my monitor machine. Oct 07 13:43:00 <ivd> I gtg now. I won't be back for a few hours. So I'll view the logfile later. Oct 07 13:43:07 * ivd is now known as ivd_away Oct 07 13:44:18 <saittam> sum: btw, the skb buffer seems to be ok, it's virtually anytime much larger than the padding we apply. Oct 07 13:46:09 * lfcorreia_away is now known as lfcorreia Oct 07 13:46:19 * lfcorreia is back into the meeting Oct 07 13:46:49 <AdamBaker> change the bitrate with "sudo iwconfig wlan0 rate 5.5M" or whatever rate you prefer Oct 07 13:46:55 <lfcorreia> what was the outcome of the new patch? Oct 07 13:48:12 <sum> AdamBaker: this does not work, it just doesn't set the bitrate. i am using wpa_supplicant Oct 07 13:48:15 * free-zombie (i=someone@tuxhacker/free-zombie) has joined #rt2x00 Oct 07 13:48:23 <saittam> lfcorreia: seems to fix decryption problems on reception for both me and sum Oct 07 13:48:47 <lfcorreia> saittam: good, i'm updating my kernel to test it in a few minutes Oct 07 13:49:42 <saittam> lfcorreia: I'm pretty sure it's safe now ;-) Oct 07 13:49:46 <lfcorreia> ok Oct 07 13:49:55 <sum> but take the newest one ;) Oct 07 13:49:56 <saittam> sum: Seems like the packets don't go out. Oct 07 13:50:05 <lfcorreia> gents, what about the other issues with current rt2x00? Oct 07 13:50:16 <lfcorreia> suspend-resume, Oct 07 13:50:17 <lfcorreia> ad-hoc is broken, Oct 07 13:50:17 <lfcorreia> quick disassociations Oct 07 13:50:17 <lfcorreia> scanning inconsistancy Oct 07 13:50:41 <saittam> I can see ping packets on air for 92 and 94 byte ping packets, but 93-byte-sized packets fail and don't show up on the monitor station. Oct 07 13:51:03 <saittam> suspend-resume produced a kernel hang in the usb layer last time I tested. Oct 07 13:51:20 <saittam> but that was 2 weeks ago. Oct 07 13:51:24 <saittam> need to retest. Oct 07 13:52:51 <lfcorreia> and this hang is surely provoked by rt73? Oct 07 13:53:02 <AdamBaker> Setting the bit rate seems to be a bit intermittent but does sometimes work. It only affects tx bit rate, the bit rate of rx data is set by the AP based on what the driver claims to support at association time Oct 07 13:53:58 <lfcorreia> unfortunately due to an hardware problem, I can't test suspend/resume on my laptop Oct 07 13:53:58 <AdamBaker> Is ad-hoc broken? It worked last time I tested it (when I was testing Johannes ad-hoc patch for mac80211) Oct 07 13:54:27 <saittam> lfcorreia: well, I have posted the stack trace on the ML. I don't know whose fault it is. The stack trace indicates that it's hanging on some lock and sysrq says the kernel doesn't have any task that's ready to be executed. Oct 07 13:54:45 <lfcorreia> AdamBaker: well, since I think we never got positive results on that one, we're assuming it is still broken :) Oct 07 13:55:17 <lfcorreia> saittam: ah, so that is the tasklet issue i read about... hummm, must look into it a bit more Oct 07 13:55:50 <saittam> lfcorreia: It's not our tasklet though. Oct 07 13:56:00 <saittam> lfcorreia: Where did you read about it? Oct 07 13:56:09 <lfcorreia> from Ivd's latest issue report: 1 - Ad-Hoc [DEBUGFS] Oct 07 13:56:09 <lfcorreia> - rt2500usb & rt73usb don't send out beacons. Oct 07 13:56:09 <lfcorreia> - Are the PCI drivers working? Oct 07 13:56:09 <lfcorreia> - Is Master mode working for USB? Oct 07 13:56:39 <AdamBaker> lfcorreia: As soon as git is stable I'll re-test ad-hoc but I think the packet size problem needs fixing first Oct 07 13:56:41 <saittam> What's needed to test master mode? hostapd? Oct 07 13:56:45 <lfcorreia> saittam: erm... can't recall actually... but i've got a vague recollection on that issue, maybe i'm wrong Oct 07 13:56:53 <AdamBaker> Master mode isn't in the current mac80211 Oct 07 13:56:56 <lfcorreia> AdamBaker: sure Oct 07 13:57:24 <lfcorreia> we need to sort out these issues to make a proper issue list :) Oct 07 13:57:39 <saittam> Adam, what happened to the rate registration inquiry you posted on linux-wireless? Oct 07 13:58:00 <AdamBaker> saittam: no reply yet Oct 07 13:59:29 <lfcorreia> what about "scanning inconsistancy" Oct 07 13:59:37 <lfcorreia> i still get that one Oct 07 14:00:48 <saittam> I guess the scanning problem is still out there. Oct 07 14:00:58 <AdamBaker> lfcorreia: How weak are the signals from the other APs? The only other one I can pick up is so weak it depends on antenna orientation whether I see it Oct 07 14:01:04 <saittam> sometimes, scanning stops working and I have to reload the driver. Oct 07 14:01:18 <saittam> Next time I see it, I'll check whether frames go out. Oct 07 14:01:37 <saittam> But this could also be mac80211 being buggy... ;-) Oct 07 14:01:42 <AdamBaker> saittam: Do you lose your own AP from the scan or just unassociated ones? Oct 07 14:01:44 <lfcorreia> AdamBaker: using the same hardware with windoze, it sees a lot more AP's,but in fact all of them very weak Oct 07 14:02:10 * freezombie has quit (Read error: 110 (Connection timed out)) Oct 07 14:02:15 <saittam> AdamBaker: Everything gone. Nothing there. Nada, niente. Oct 07 14:02:21 <AdamBaker> lfcorreia: That could just mean we haven't got optimum sensitivity Oct 07 14:02:42 <lfcorreia> AdamBaker: yes, we have that issue from the very beggining Oct 07 14:02:52 <AdamBaker> Can you see the other APs with the legacy driver? Oct 07 14:02:55 <saittam> I can also confirm my madwifi card sees much more APs than the rt73. Oct 07 14:03:21 <lfcorreia> we made some adjustments to the link tuner and now ivd is pursuing the antenna selection to try and figure out the best way Oct 07 14:03:58 <lfcorreia> YES!!! Oct 07 14:04:05 <lfcorreia> rt73 is now working Oct 07 14:04:13 <saittam> gratulations :-) Oct 07 14:04:29 <saittam> but try some pings with 80-100 bytes packet size :-) Oct 07 14:04:56 <sum> hm, i don't get any idea, why there are some sizes, repeating each 44 bytes... Oct 07 14:05:15 <saittam> 44 bytes? Oct 07 14:05:33 <sum> those sizes do not work here (padding to 8!) Oct 07 14:05:34 <sum> 104 108 112 - 148 152 156 - 192 196 200 - 236 240 244 Oct 07 14:05:45 <sum> well the '-' only for readablilyt Oct 07 14:05:50 <AdamBaker> My guess is it is related to the encoding used at 11M Oct 07 14:06:23 <AdamBaker> some sizes also occasionally work Oct 07 14:06:55 <AdamBaker> I wonder if there is some issue with padding for the encoding Oct 07 14:07:17 <lfcorreia> funny enough, my rt73 is only using 11M, and this has to do with recent changes to the API I think Oct 07 14:07:20 * drear (firstname.lastname@example.org) has joined #rt2x00 Oct 07 14:07:42 <sum> AdamBaker: yes, i have also sometimes usually bad sizes that work (well, ping packets are returned in 2 or more seconds...) Oct 07 14:07:45 <AdamBaker> Maybe it would be helpful to test with a different mac80211 supported device Oct 07 14:08:01 <sum> i don't have any other device :(( Oct 07 14:08:11 <saittam> me neither. Oct 07 14:08:36 <sum> i have to go now, be back later. Oct 07 14:09:08 <lfcorreia> well, time to discuss the most unimportant topic in out agenda Oct 07 14:09:11 <AdamBaker> I've got a laptop with bcm43xx but the OS is so out of date I need to update that before trying a new kernel Oct 07 14:09:26 <lfcorreia> 802.11n devices Oct 07 14:09:50 <serialmonkey> Still haven't managed to get my hands on one locally - and I need PCI or USB Oct 07 14:09:53 <serialmonkey> (not minipci) Oct 07 14:10:20 <lfcorreia> AFAIK, there are only minipci available Oct 07 14:10:35 <lfcorreia> and these aren't even the final 11n specs Oct 07 14:10:44 <saittam> can we ask some vendor to donate some? Oct 07 14:10:57 <serialmonkey> Hence why I have actually stayed away from 802.11n all together. It's not even ratified yet Oct 07 14:11:06 <serialmonkey> Thats why my main vendor is staying away still Oct 07 14:11:27 <lfcorreia> saittam: ask the guy from minipci.biz Oct 07 14:11:32 <saittam> So, do these chips also speak 11b and 11g? Oct 07 14:11:50 <saittam> and if so, do they work with the current drivers? Oct 07 14:12:04 <lfcorreia> saittam: yes, yes and no Oct 07 14:12:24 <lfcorreia> it has a new driver, which is as shitty as all the others Ralink provides Oct 07 14:12:46 <saittam> ah, thanks. Oct 07 14:13:13 <lfcorreia> and new firmware Oct 07 14:13:19 <saittam> lfcorreia: I don't have a minipci adapter card here. Oct 07 14:13:38 <lfcorreia> but hte only time i tested it it did work, but as slow as all other ralink drivers Oct 07 14:13:53 <lfcorreia> saittam: the guy can also provide a minipci to pci adapter, ask him Oct 07 14:15:04 * freezombie (i=someone@tuxhacker/free-zombie) has joined #rt2x00 Oct 07 14:15:18 <saittam> lfcorreia: Do you have a contact address? But I don't have lots of spare time, maybe it gets better by the end of october. Oct 07 14:16:28 <lfcorreia> saittam: sure, martin dot hoehne at minipci dot biz Oct 07 14:16:43 <lfcorreia> or just go to minipci.biz and search for the proper contact :) Oct 07 14:17:20 <lfcorreia> anyway, what we were planning to do about the 11n driver is the following Oct 07 14:17:53 <saittam> lfcorreia: Thanks. Will contact him later this month. Oct 07 14:18:42 <lfcorreia> anyway, what we were planning to do about the 11n driver is the following, we need a volunteer to cleanup ralink's code and add our fixes to it Oct 07 14:18:57 <lfcorreia> do that we then can compare rt2x00 with legacy Oct 07 14:19:18 <lfcorreia> but, and this is the most important issue, we don't want to support it for users Oct 07 14:19:31 <saittam> *gg* Oct 07 14:19:33 <lfcorreia> what is your opinion about it? Oct 07 14:20:33 <Spy84464> You mean not supporting a legacy rt2800? Oct 07 14:21:33 * saittam doesn't do no legacy Oct 07 14:23:27 <lfcorreia> Spy84464: exactly Oct 07 14:24:04 <Spy84464> this is coherent with our current approach : getting rid of legacy drivers Oct 07 14:24:18 <Spy84464> so it makes sense Oct 07 14:24:26 <lfcorreia> what I actually mean, if we provide our version of their legacy driver, and as 802.11n is a hype product, we would get tons of help requests about fixing it Oct 07 14:24:42 <Spy84464> yes Oct 07 14:24:48 <lfcorreia> so, we *may* have it, but we don't actually support it for users Oct 07 14:25:05 <lfcorreia> nor we would have a section for it on the forum Oct 07 14:25:06 <Spy84464> the only interest is to have something to help developing rt2x00 Oct 07 14:25:11 <lfcorreia> exactly Oct 07 14:25:53 <Spy84464> that's fine for me Oct 07 14:25:56 <lfcorreia> I would even start to advertise legacy support EOL :) Oct 07 14:26:04 <lfcorreia> but that we had already discussed Oct 07 14:26:17 <saittam> sounds good. Oct 07 14:26:18 <lfcorreia> it's a long standing issue, legacy Oct 07 14:26:25 <lfcorreia> ok Oct 07 14:28:32 <lfcorreia> Agenda summary of discussed items: Oct 07 14:28:32 <lfcorreia> legacy should be provided 'as-is' after rt2x00 has reached mainline kernel and at least one distro has released a version containing 2.6.24. in the meanwhile, we should keep it. Oct 07 14:28:32 <lfcorreia> mac80211 API is causing some breakage to our driver. Oct 07 14:28:32 <lfcorreia> 802.11n drivers: legacy driver should exist but not for end users. this means that the driver won't have any kind of development effort besides helping rt2x00. Oct 07 14:29:12 <lfcorreia> if you all agree with this summary we may declare the meeting closed as for the proposed agenda Oct 07 14:29:26 <saittam> fine with me. Oct 07 14:29:36 <lfcorreia> we can continue to discuss some other issues or even test some other code/patches Oct 07 14:30:28 <serialmonkey> no worries, I have to run anyway - getting late here Oct 07 14:30:52 <serialmonkey> We should try and stick our heads in here to IRC while we are working on issues Oct 07 14:30:56 * free-zombie has quit (Read error: 110 (Connection timed out)) Oct 07 14:31:33 <serialmonkey> gotta run, bye all Oct 07 14:31:37 * serialmonkey has quit () Oct 07 14:31:38 <Spy84464> see you Oct 07 14:31:43 <Spy84464> too late :p Oct 07 14:32:08 * free-zombie (i=someone@tuxhacker/free-zombie) has joined #rt2x00 Oct 07 14:33:48 <AdamBaker> Did we conclude that no-one has been / is able to test if the packet loss issue at 11 Mb/s applies to anything other than RT73? Oct 07 14:35:15 <Spy84464> I have a rt2500 card at hand, but I don't have a clone of git, my hard drive died monday Oct 07 14:35:17 <Spy84464> sorry Oct 07 14:35:52 <saittam> I've just run into the scanning problem again. Oct 07 14:36:35 <saittam> seems no packets get transmitted at all, cannot see any on the monitor station. Oct 07 14:40:43 <lfcorreia> funny enough i've tested some large ping packet size and it fails with anything bigger then '-s 1669' Oct 07 14:46:18 * freezombie has quit (Read error: 110 (Connection timed out)) Oct 07 14:52:12 <lfcorreia> ok, we declare the developers meeting officially ended Oct 07 14:53:06 <lfcorreia> saittam: can you prepare a patch and submit it to Johannes aprooval? Oct 07 14:53:15 <saittam> will do :-)