Am 31.05.2014 08:45, schrieb Alexander Holler:
Am 31.05.2014 07:28, schrieb Marcel Holtmann:
so I actually wonder if we should move away from timer and move to a delayed work item to handle the timeout and if that would actually fix this issue.
The problem is that I have absolutely no clue where these timeouts do
come from. They appear for different commands and almost always only at
boot. If the machine did come up without hci command timeouts, there
never was one afterwards. So I digged in the dark and the above patch
was one of the results. But I still had to increase the command timeout.
And I can't do much testing as I use this box. I just experience this
problem almost always when I boot it (to do kernel updates) and since a
very long time (more than a year I think).
And I should mention that I had these timeouts with a different dongle
too (I switched from a bt 3.x dongle to a bt 4.x dongle around a year
ago). But as said, in the commit msg, the old behaviour might have
masked different problems like deadlocks or similiar too, so I just
might have experienced several different problems.
Regards,
Alexander Holler
.
--
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
