On 30 July 2018 at 13:12, Yongqin Liu yongqin.liu@linaro.org wrote:
On Fri, 27 Jul 2018 at 23:03, Bero Rosenkränzer Bernhard.Rosenkranzer@linaro.org wrote:
Hi, -11 is -EAGAIN -- AFAIK connect() returning EAGAIN usually means the listen() backlog is full. Unless the test's purpose is to check connections are accepted quickly under load, it may make sense to make the test handle EAGAIN instead of failing on it, e.g. change
xyz = connect(...);
to something more like
int retries = 10; do { xyz = connect(...) if(xyz >= 0 || errno != EAGAIN) break; sleep(1); } while(--retries);
Hmm, I don't think the failure is that case, it passes for 4.14 and 4.9 kernel, and it passes for other parameter combination as well.
And here, except this special case, I most want to know the methods on how to debug on kernel side functions. With adding printk lines to find the real error happened function, it's not smart I think. maybe others have good methods on such cases.
I usually work only inside the kernel, but recently I had to debug why wpa_cli wouldn't connect to wpa_supplicant on my setup.
strace to find the entry point that errs (and you could see what error). Then generous sprinkling of trace_printk("%s:%d\n", __func__, __LINE__) around areas of interest. If you know the end point that returns the error, you could dump_stack() and find which functions are involved and add the trace_printk calls.
cheers.