Stefan,
(Mar 01 2014 19:53), Stefan Richter wrote:
We could add a workaround in drivers/firewire/core-iso.c which works similar to your CMP related workaround in patch 18/39. I.e., after a timed-out lock request to CHANNELS_AVAILABLE or BANDWIDTH_AVAILABLE, perform a read request to see what happened. Like your CMP workaround, this is fragile because it races with concurrent lock requests.
Or we could add a workaround in drivers/firewire/core-card.c which would attempt to make the local node root node (and thereby IRM) if it detects that an M-Audio device is currently IRM.
Not sure what's better.
Currently I'm also not sure. So I want it pending for my future work.
Actually, the failure of operation to CSR_CHANNELS_AVAILABLE_HI appears in stopping streams. When starting streams, retries in manage_channels()/manage_bandwidth() works fine. So users can use their devices as usual.
The disadvantages may appears when the driver handles this failure many times. Then users will see this message 'isochronous resources exhausted'.
I think the way to recover this state is just to reboot the system. But this state doesn't bring sudden hangup to system. Users can observer what happened.
With trade-off of the fact that there is no driver for these devices in both of user-land/kernel-land, I want to include these patches.
Regards
Takashi Sakamoto o-takashi@sakamocchi.jp