Hi Thomas,
Can you please enable CONFIG_SLUB_DEBUG=y and CONFIG_SLUB_DEBUG_ON=y
and give it another try?
If we can not catch it that way, I'll whip up a patch which points
us
to the code which added the offending timer.
Hi,
Note: I switched to 2.6.25-rc2. The only new thing I see is this
message:
hci_cmd_task: hci0 command tx timeout
This comes from net/bluetooth/hci_core.c, line 1547
There is indeed a timeout message in the log (at the end of this
email). I tried to boot with slub_debug but did not get anything
more. slabinfo -v does not report anything either.
Crash log:
hci_cmd_task: hci0 command tx timeout
BUG: unable to handle kernel paging request at 6b6b6b6b
We got some more info ---------------------------^^^^^^^^
#define POISON_FREE 0x6b /* for use-after-free poisoning */
So the timer is in an allocated data structure, which is
freed without having removed the timer first.
Sorry for the meager yield.
Hey, we know already more :)
Marcel, any idea on this one ?
I don't really have any idea. Nothing has been changed in this area
for a couple of years. The command TX timeout is the timeout that
indicates a missing answer to a command sent down to the Bluetooth chip.
However this involves some atomic and tasklet stuff. Did we have some
changes that I missed and might now render this usage as broken.
Regards
Marcel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
