Hi,

We observed strange mutex blocking problem related to callout_* for our WiFi driver timer. We used our driver as AP mode. and basically we have 3 types of timers:
1. control timer: for controlling Tx flow
2. data timer: for flush out Rx packet if timeout. One per each WiFi Station connected.
3. command timer: for command timeout

We have control timer on io-pkt thread, the other 2 types of timer on our work thread, created by nw_pthread_create(). Depending on the conditions, the 3 timers are frequently start/stop or created on the fly (for new WiFi client, e.g).

Our observation is that when we running stress test with one AP against 2 WiFi stations, we have mutex lock up issue when calling callout_msec(..) or callout_stop(..). Our log shows the line before we call the callout_** function, but never returns. We believe the mutex being blocked is from TCP/IP stack of QNX and we would like to know why this issue happens. The pidin shows:

#pidin
1036304 1 /boot/io-pkt-v4-hc 21r SIGWAITINFO
1036304 2 /boot/io-pkt-v4-hc 25r RUNNING
1036304 3 /boot/io-pkt-v4-hc 21r RECEIVE 24
1036304 4 /boot/io-pkt-v4-hc 25r MUTEX (0x20b670) 1036304-02 #0

Thanks,

Yurong

_______________________________________________

Networking Drivers
http://community.qnx.com/sf/go/post98968
To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com