"Baxter, Jim" <jim_baxter@xxxxxxxxxx> writes: > I tested this with printk's to show when the low memory code was triggered > and the value of ctx->tx_low_mem_val and ctx->tx_low_mem_max_cnt. > I created a workqueue that slowly used up the atomic memory until the > code is triggered. > > I could add debug prints, though I have noticed that cdc_ncm_fill_tx_frame() > does not currently have any debug prints do you think this is because it can be > called in an atomic context and I think debug messages if enabled could cause > too great a delay? Yes, I guess you're right. Maybe count the number of failed allocations and export it along with the other driver private counters? Or export the tx_curr_size as a sysfs attribute? Or both? Just an idea... I don't expect to see this code ever being hit on my systems :-) Bjørn -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
