The change was to remove a check which would print the error message and return by a BUG_ON statement that causes an Oops. Since the error was there before, this seems to be a race that already was there but was handled less fatally. I am not sure whether it is possible for an IRQ to be triggered between pcmcia_request_irq and dtl1_open (which fills the info->hdev) but it somehow sounds like it.
The panic itself is caused by the following upstream commit:
commit ac019360fe311dd 6aa11b358a02eb3 a61675882e
Author: Jeff Garzik <email address hidden>
Date: Sat Oct 20 13:45:57 2007 +0200
[Bluetooth] Eliminate checks for impossible conditions in IRQ handler
Our info structure and info->hdev is always passed to the IRQ handler,
so we don't have to worry about these checks in every interrupt.
Leave a BUG_ON() just to help unwary programmers, but these could
probably be removed as well.
Signed-off-by: Jeff Garzik <email address hidden>
Signed-off-by: Marcel Holtmann <email address hidden>
The change was to remove a check which would print the error message and return by a BUG_ON statement that causes an Oops. Since the error was there before, this seems to be a race that already was there but was handled less fatally. I am not sure whether it is possible for an IRQ to be triggered between pcmcia_request_irq and dtl1_open (which fills the info->hdev) but it somehow sounds like it.