On Mon, Sep 14, 2009 at 19:17, Robert Hancock wrote: > On 09/13/2009 11:18 PM, Mike Frysinger wrote: >> Commit ac019360fe3 changed the irq handler logic to BUG_ON rather than >> returning IRQ_NONE when the incoming argument is invalid. While this >> works in most cases, it doesn't work when the IRQ is shared with other >> devices (or when DEBUG_SHIRQ is enabled). > > Something doesn't add up here. It shouldn't be possible for the incoming > argument to be invalid. I'd think that if it is it means that the IRQ > handler is being registered too soon, before the data structures it requires > are set up fully. If that's the case, reverting the change just partially > papers over the bug. it's a shared irq. so there is no way to guarantee that the incoming interrupt is from the bluetooth device. aaaand there's the issue of registering too soon, but the pcmcia framework doesnt seem to provide a way to fix this. enable DEBUG_SHIRQ and you too will see the kernel crash (since this causes the IRQ to "fire" as soon as it's generated). i dont know anything about these devices, but another fix may be to remove the shareable flag from the irq registration. -mike -- 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