From: Benjamin H. <be...@xn...> - 2011-04-21 19:32:27
|
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 author: Jarod Wilson <ja...@wi...> srcversion: D62D7D95B5046CB7DCA6326 alias: usb:v15C2p0046d*dc*dsc*dp*ic*isc*ip* alias: usb:v15C2p0045d*dc*dsc*dp*ic*isc*ip* alias: usb:v15C2p0044d*dc*dsc*dp*ic*isc*ip* alias: usb:v15C2p0043d*dc*dsc*dp*ic*isc*ip* alias: usb:v15C2p0042d*dc*dsc*dp*ic*isc*ip* alias: usb:v15C2p0041d*dc*dsc*dp*ic*isc*ip* alias: usb:v15C2p0040d*dc*dsc*dp*ic*isc*ip* alias: usb:v15C2p003Fd*dc*dsc*dp*ic*isc*ip* alias: usb:v15C2p003Ed*dc*dsc*dp*ic*isc*ip* alias: usb:v15C2p003Dd*dc*dsc*dp*ic*isc*ip* alias: usb:v15C2p003Cd*dc*dsc*dp*ic*isc*ip* alias: usb:v15C2p003Bd*dc*dsc*dp*ic*isc*ip* alias: usb:v15C2p003Ad*dc*dsc*dp*ic*isc*ip* alias: usb:v15C2p0039d*dc*dsc*dp*ic*isc*ip* alias: usb:v15C2p0038d*dc*dsc*dp*ic*isc*ip* alias: usb:v15C2p0037d*dc*dsc*dp*ic*isc*ip* alias: usb:v15C2p0036d*dc*dsc*dp*ic*isc*ip* alias: usb:v15C2p0035d*dc*dsc*dp*ic*isc*ip* alias: usb:v15C2p0034d*dc*dsc*dp*ic*isc*ip* alias: usb:v15C2pFFDCd*dc*dsc*dp*ic*isc*ip* depends: usbcore,rc-core vermagic: 2.6.38-ARCH SMP preempt mod_unload parm: debug:Debug messages: 0=no, 1=yes (default: no) (bool) parm: display_type:Type of attached display. 0=autodetect, 1=vfd, 2=lcd, 3=vga, 4=none (default: autodetect) (int) parm: pad_stabilize:Apply stabilization algorithm to iMON PAD presses in arrow key mode. 0=disable, 1=enable (default). (int) parm: nomouse:Disable mouse input device mode when IR device is open. 0=don't disable, 1=disable. (default: don't disable) (bool) parm: pad_thresh:Threshold at which a pad push registers as an arrow key in kbd mode (default: 28) (int) 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? Thanks. |
From: Jarod W. <ja...@wi...> - 2011-04-21 19:59:44
|
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. -- Jarod Wilson ja...@wi... |
From: Benjamin H. <be...@xn...> - 2011-04-21 20:23:41
|
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. |
From: Jarod W. <ja...@wi...> - 2011-04-21 21:00:37
|
On Apr 21, 2011, at 4:23 PM, Benjamin Hodgetts wrote: > 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 Ugh. So another distro with a less-than-optimal kernel versioning scheme... > with these - http://projects.archlinux.org/linux-2.6-ARCH.git/tree/patches - patches applied. Don't immediately see anything that looks suspicious, though I haven't look at the entire 2.6.38.4-pre patch closely. Nothing in imon.c is any different between your kernel and mine, anyway. Regardless, the trace actually looks to be at a lower level inside the kernel, and could be system chipset-specific. The bits about handle_mm_fault and get_page_from_freelist are a bit disturbing. Not sure what to suggest here, I'm actually reasonably confident now that this isn't a bug in the imon code. > The screen is the one found on the Zalman HD503 (purchased a week ago) if that helps with versions and releases. Not really. The usb device ID already told me everything I needed to know about your hardware. :) -- Jarod Wilson ja...@wi... |
From: Jarod W. <ja...@wi...> - 2011-04-27 21:55:00
|
On Apr 21, 2011, at 5:00 PM, Jarod Wilson wrote: > On Apr 21, 2011, at 4:23 PM, Benjamin Hodgetts wrote: > >> 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 ... > I'm actually reasonably confident now that this > isn't a bug in the imon code. Nope, I was wrong, its a bug in the imon code. A Fedora kernel-debug build and a bit more code inspection revealed what was wrong. Now I just have to write up a patch to fix it, its kind of a gross little corner case bug that's been there a while, but only recently started to be triggered... Basically, when v4l-utils started installing a udev rule that ran ir-keytable, which calls the imon driver's change_protocol function, things started going sideways, because of an assumption in the driver that the send_packet() function is always called with ictx->lock already held, and that isn't the case with the change_protocol function. So it first tries to drop the lock (that it isn't holding), then tries to reacquire it, assuming the calling function will then drop it. It never gets dropped. Along comes a second process, like lcdproc, which tries to write to the display, which also calls send_packet(), but does so after first grabbing the lock -- which is already held. Thus the hung task warning. I'll try to get something together tomorrow, this'll be 2.6.38.x stable tree stuff here... [ 15.014153] ===================================== [ 15.015048] [ BUG: bad unlock balance detected! ] [ 15.015048] ------------------------------------- [ 15.015048] ir-keytable/773 is trying to release lock (&ictx->lock) at: [ 15.015048] [<ffffffff814c6297>] mutex_unlock+0xe/0x10 [ 15.015048] but there are no more locks to release! [ 15.015048] [ 15.015048] other info that might help us debug this: [ 15.015048] 2 locks held by ir-keytable/773: [ 15.015048] #0: (&buffer->mutex){+.+.+.}, at: [<ffffffff8119d400>] sysfs_write_file+0x3c/0x144 [ 15.015048] #1: (s_active#87){.+.+.+}, at: [<ffffffff8119d4ab>] sysfs_write_file+0xe7/0x144 [ 15.015048] [ 15.015048] stack backtrace: [ 15.015048] Pid: 773, comm: ir-keytable Not tainted 2.6.38.4-20.fc15.x86_64.debug #1 [ 15.015048] Call Trace: [ 15.015048] [<ffffffff81089715>] ? print_unlock_inbalance_bug+0xca/0xd5 [ 15.015048] [<ffffffff8108b35c>] ? lock_release_non_nested+0xc1/0x263 [ 15.015048] [<ffffffff814c6297>] ? mutex_unlock+0xe/0x10 [ 15.015048] [<ffffffff814c6297>] ? mutex_unlock+0xe/0x10 [ 15.015048] [<ffffffff8108b67b>] ? lock_release+0x17d/0x1a4 [ 15.015048] [<ffffffff814c6229>] ? __mutex_unlock_slowpath+0xc5/0x125 [ 15.015048] [<ffffffff814c6297>] ? mutex_unlock+0xe/0x10 [ 15.015048] [<ffffffffa02964b6>] ? send_packet+0x1c9/0x264 [imon] [ 15.015048] [<ffffffff8108b376>] ? lock_release_non_nested+0xdb/0x263 [ 15.015048] [<ffffffffa0296731>] ? imon_ir_change_protocol+0x126/0x15e [imon] [ 15.015048] [<ffffffffa024a334>] ? store_protocols+0x1c3/0x286 [rc_core] [ 15.015048] [<ffffffff81326e4e>] ? dev_attr_store+0x20/0x22 [ 15.015048] [<ffffffff8119d4cc>] ? sysfs_write_file+0x108/0x144 [ 15.015048] [<ffffffff8113f001>] ? vfs_write+0xaf/0x102 [ 15.015048] [<ffffffff81140530>] ? fget_light+0x3a/0x83 [ 15.015048] [<ffffffff8113f214>] ? sys_write+0x4d/0x74 [ 15.015048] [<ffffffff8110e3b3>] ? handle_pte_fault+0x1dc/0x6e2 [ 15.015048] [<ffffffff8100abc2>] ? system_call_fastpath+0x16/0x1b -- Jarod Wilson ja...@wi... |
From: Demian K. <ic...@gm...> - 2011-05-07 16:10:18
|
Jarod Wilson <jarod@...> writes: > Nope, I was wrong, its a bug in the imon code. > I'll try to get something together tomorrow, this'll be 2.6.38.x stable tree > stuff here... Hi Jarod, are there any news regarding this bug or a quick fix I could apply? It's really a showstopper on my HTPC at the moment. Demian |
From: Jarod W. <ja...@wi...> - 2011-05-07 20:35:26
|
On May 7, 2011, at 11:55 AM, Demian Kellermann wrote: > Jarod Wilson <jarod@...> writes: > >> Nope, I was wrong, its a bug in the imon code. > >> I'll try to get something together tomorrow, this'll be 2.6.38.x stable tree >> stuff here... > > Hi Jarod, > > are there any news regarding this bug or a quick fix I could apply? It's really > a showstopper on my HTPC at the moment. Its committed upstream and in Greg's queue for 2.6.38.6. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=23ef710e1a6c4d6b9ef1c2fa19410f7f1479401e -- Jarod Wilson ja...@wi... |