> Hi everyone - Hi All, > >> > >> NACK on this. I don't wanna move code with the specific purpose of pass a PTS > >> test into the tree. This kinda of thing can survive outside of the tree. > > > > actually it can not life outside the tree. We need to be able to pass > > the PTS test cases with an upstream source. > > > > However instead of hacking this in, what is the actual test case details > > here that we need to have support for? > > ERTM will send an RNR when the socket receive buffer fills up. For > this test case, it works to just set the SO_RCVBUF sockopt to > a small enough value that the recv buffer fills before the transmit > window does - no kernel changes required. @Marcel This test case is to "Verify the IUT will send an S-Frame [RNR] when it detects a Local Busy condition." "Pass verdict: - ALT 1: The IUT immediately sends an S-Frame with function RNR after the Local Busy condition is set by the Upper Tester. - ALT 2: The IUT sends an S-Frame with function RNR after receiving I-Frame(s) from the Tester when the Local Busy condition is set by the Upper Tester." I was trying to pass ALT2 with Mat's suggestions but couldn't trigger local busy. Minimum possible value for SO_RCVBUF (at least here on 3.0 kernel) is 2224 bytes and this is still too high to allow PTS to trigger local busy (PTS tries to send txwin i-frames with 4 bytes of data only). [If it would possible to force PTS to send larger i-frames than it should work as well but I wasn't able to find any option that would do that... please correct me if it is possible] With forcing local busy on channels it is possible to pass ALT1 scenario: PTS ask IUT to enter local busy condition and just waits for RNR to be send. @Gustavo If you prefer not to temper with normal code path I could just get rid of force_local_busy variable and not hold channels in local busy state. This should be enough to pass test. -- BR Szymon Janc -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
