Re: Lockup with imon (15c2:0038)

[Benjamin H. <be...@xn...>]

On 21/04/2011 20:59, Jarod Wilson wrote:
> On Apr 21, 2011, at 3:14 PM, Benjamin Hodgetts wrote:
>
>> The LCD/VFD used to work fine with Debian but since moving to Arch Linux
>> (which has newer versions of everything involved as far as I'm aware)
>> I'm unable to use the display.
>>
>> It identifies itself as: Bus 002 Device 003: ID 15c2:0038 SoundGraph
>> Inc. GD01 MX VFD Display/IR Receiver
>>
>> The /dev/lcd0 device is created with 600 permissions so that has to be
>> fixed before it can be accessed, but once it has been, anything that
>> tries to access it just locks up, the following is seen in dmesg after
>> trying to run LCDd:
>>
>> [ 1679.457305] INFO: task LCDd:8460 blocked for more than 120 seconds.
>> [ 1679.457307] "echo 0>  /proc/sys/kernel/hung_task_timeout_secs"
>> disables this message.
>> [ 1679.457309] LCDd            D ffff88010fcd89c8     0  8460      1
>> 0x00000000
>> [ 1679.457312]  ffff8800d5a03b48 0000000000000082 0000000000000000
>> ffff8800d5a03fd8
>> [ 1679.457314]  00000000012dcd30 fffffffffffffffd ffff8800d5a03fd8
>> ffff88010fcd86f0
>> [ 1679.457316]  ffff8800d5a03fd8 ffff8800d5a03fd8 ffff88010fcd89d0
>> ffff8800d5a03fd8
>> [ 1679.457319] Call Trace:
>> [ 1679.457324]  [<ffffffff810ff1a5>] ? zone_statistics+0x75/0x90
>> [ 1679.457327]  [<ffffffff810ea907>] ? get_page_from_freelist+0x3c7/0x820
>> [ 1679.457330]  [<ffffffff813b0a49>] __mutex_lock_slowpath+0x139/0x320
>> [ 1679.457335]  [<ffffffff813b0c41>] mutex_lock+0x11/0x30
>> [ 1679.457338]  [<ffffffffa0d54216>] display_open+0x66/0x130 [imon]
>> [ 1679.457345]  [<ffffffffa01d06c0>] usb_open+0x180/0x310 [usbcore]
>> [ 1679.457349]  [<ffffffff81143b3b>] chrdev_open+0x1bb/0x2d0
>> [ 1679.457350]  [<ffffffff8113d93d>] __dentry_open+0x10d/0x370
>> [ 1679.457352]  [<ffffffff81143980>] ? chrdev_open+0x0/0x2d0
>> [ 1679.457355]  [<ffffffff811d4f45>] ?
>> devcgroup_inode_permission+0x125/0x150
>> [ 1679.457357]  [<ffffffff8113ede1>] nameidata_to_filp+0x71/0x80
>> [ 1679.457359]  [<ffffffff8114dd78>] finish_open+0xc8/0x1b0
>> [ 1679.457361]  [<ffffffff8114c8a1>] ? do_path_lookup+0x71/0x130
>> [ 1679.457362]  [<ffffffff8114e4e6>] do_filp_open+0x296/0x760
>> [ 1679.457364]  [<ffffffff81108d30>] ? handle_mm_fault+0x1b0/0x330
>> [ 1679.457366]  [<ffffffff8115ac2c>] ? alloc_fd+0xec/0x140
>> [ 1679.457368]  [<ffffffff8113ee54>] do_sys_open+0x64/0x110
>> [ 1679.457370]  [<ffffffff8113ef1b>] sys_open+0x1b/0x20
>> [ 1679.457372]  [<ffffffff8100ae12>] system_call_fastpath+0x16/0x1b
>>
>>
>> Output of modinfo for the imon module is:
>>
>>
>> filename:       /lib/modules/2.6.38-ARCH/kernel/drivers/media/rc/imon.ko.gz
>> license:        GPL
>> version:        0.9.2
>> description:    Driver for SoundGraph iMON MultiMedia IR/Display
> ...
>> vermagic:       2.6.38-ARCH SMP preempt mod_unload
> ...
>> Does anyone know what may be causing this? Whether it's just something
>> extra that needs to be parsed to the kernel when the module is loaded or
>> if this is actually a bug?
>
> Its definitely not expected behavior, which suggests a bug *somewhere*, but
> I'm not aware of anything in particular that would cause this. Further, I've
> got a VFD hooked up to a Fedora box running a 2.6.38.3 kernel right now, and
> it works flawlessly with LCDd and lcdproc. :\
>
> However, its an ffdc-gen VFD, not one of the newer ones, which *could* be
> relevant here. I've got a newer VFD, but its currently preoccupied...
>
> Do you know if the Arch kernel is plain 2.6.38, or is it 2.6.38.x with stable
> updates? Could be there's something in the stable tree updates that I've got
> here that results in it working better.
>

It's kernel 2.6.38.3-1 with these - 
http://projects.archlinux.org/linux-2.6-ARCH.git/tree/patches - patches 
applied.

The screen is the one found on the Zalman HD503 (purchased a week ago) 
if that helps with versions and releases.