Hi Ian, | Would suggest that patch is worth pushing upstreams then as quickly as we can... | I went through the code again and found that X_calc = 0 does not cause harm, due to clamping to s/t_mbi. My suggestion is to remove this BUG_ON and to test instead if t_ipi = 0 (since this would allow flooding of network). Patch is in the next email, test tree has been updated, also CCID-4 has now the same change (removed X_calc BUG_ON, added t_ipi==0 BUG_ON). Gerrit | On 21 February 2012 15:05, Gerrit Renker <gerrit@xxxxxxxxxxxxxx> wrote: | > | > Here is a patch that can be used in place of enabling the debug messages. | > It may be easier to use this, especially if it takes long to reproduce the | > bug. | > | > From a quick look it seems that x_calc = 0 will do no harm in the old | > code, since | > ccid3_hc_tx_update_x() is called subsequently, it will set x to s/t_mbi | > | > --- a/net/dccp/ccids/ccid3.c | > +++ b/net/dccp/ccids/ccid3.c | > @@ -237,7 +237,11 @@ static void ccid3_hc_tx_no_feedback_timer(unsigned | > long data) | > * | > * Note that X_recv is scaled by 2^6 while X_calc is not | > */ | > - BUG_ON(hc->tx_p && !hc->tx_x_calc); | > + if (hc->tx_p && !hc->tx_x_calc) | > + DCCP_CRIT("ERROR: s=%u, p=%u, x_calc = %u, x_recv | > = %llu, X = %llu", | > + hc->tx_s, hc->tx_p, hc->tx_x_calc, | > + (unsigned long long)hc->tx_x_recv, | > + (unsigned long long)hc->tx_x); | > | > if (hc->tx_x_calc > (hc->tx_x_recv >> 5)) | > hc->tx_x_recv = | > -- | > To unsubscribe from this list: send the line "unsubscribe dccp" in | > the body of a message to majordomo@xxxxxxxxxxxxxxx | > More majordomo info at http://vger.kernel.org/majordomo-info.html | -- | To unsubscribe from this list: send the line "unsubscribe dccp" in | the body of a message to majordomo@xxxxxxxxxxxxxxx | More majordomo info at http://vger.kernel.org/majordomo-info.html | -- -- To unsubscribe from this list: send the line "unsubscribe dccp" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html