On 20/07/11 23:18, Jarod Wilson wrote:
On Wed, Jul 20, 2011 at 08:05:43AM +1000, Chris W wrote:
On 20/07/11 02:12, Jarod Wilson wrote:
The imon devices have either 1 or 2 usb interfaces on them, each wired
up to its own urb callback. The interface 0 urb callback is wired up
before the imon
On 20/07/11 02:12, Jarod Wilson wrote:
The imon devices have either 1 or 2 usb interfaces on them, each wired
up to its own urb callback. The interface 0 urb callback is wired up
before the imon context's rc_dev pointer is filled in, which is
necessary for imon 0xffdc device auto-detection to
On 17/07/11 10:43, Andy Walls wrote:
This is an obviously repeatable NULL pointer dereference in
rc_g_keycode_from_table(). The faulting line of code in both cases
disasembles to:
1e: 8b 80 dc 00 00 00 mov0xdc(%eax),%eax
%eax obviously holds the value 0 (NULL). But I'm
On 14/07/11 08:11, Jarod Wilson wrote:
On Jul 13, 2011, at 1:42 AM, Chris W wrote:
Just noticed your report is for 2.6.39.x and 2.6.38.x only, but I'm
not aware of any relevant imon changes between 2.6.39 and 3.0.
I just tried 3.0.0-rc7 with the same result (used defaults for new
config items
Thanks for the reply.
On 13/07/11 05:55, Jarod Wilson wrote:
I don't see any rc_imon_pad or rc_imon_mce modules there, and I've not
seen any panics with multiple imon devices here, so I'm guessing you
didn't build either of the possible imon keymaps, and having a null
keymap is interacting
On 13/07/11 14:20, Jarod Wilson wrote:
Chris W wrote:
The rc keymap modules have been built (en masse as a result of
CONFIG_RC_MAP=m) but I am not explicitly loading them and they do not
get automatically loaded.
Huh. That's unexpected. They get auto-loaded here, last I knew. I'll
have
