From: Johnny W. <joh...@gm...> - 2009-11-17 22:55:44
|
using Mythbuntu 8.10 and lirc 0.8.6-0ubuntu2 SilverStone LC11SM case with SoundGraph IMON USB device and PAD remote. This device locks up and stops responding after a time. The problem is that after about an hour maybe the device stops responding. It's almost exactly like the behavior described when on previous versions you were running only 1 lirc instance and not 2 tied together with a listen statement. When it locks up the LCD stops updating (it's not that good actually - I notice the LCD is not updating pretty often) The remote stops working altogether. I am unable to rmmod the lirc_imon module - it says it's in use. I've enable debug=1 in the modprobe.d/lirc.conf file but i'm not sure how to use this data. Is it possible that the '0.8.6-0ubuntu2' package of lirc still doesn't support this device correctly? What information do I need to contribute to help with this? |
From: Jarod W. <ja...@wi...> - 2009-11-18 01:20:05
|
On Nov 17, 2009, at 5:55 PM, Johnny Walker wrote: > using Mythbuntu 8.10 and lirc 0.8.6-0ubuntu2 > SilverStone LC11SM case with SoundGraph IMON USB device and PAD remote. > > This device locks up and stops responding after a time. > > The problem is that after about an hour maybe the device stops > responding. It's almost exactly like the behavior described when on > previous versions you were running only 1 lirc instance and not 2 tied > together with a listen statement. > > When it locks up the LCD stops updating (it's not that good actually > - I notice the LCD is not updating pretty often) The remote stops > working altogether. I am unable to rmmod the lirc_imon module - it > says it's in use. > > I've enable debug=1 in the modprobe.d/lirc.conf file but i'm not sure > how to use this data. > > Is it possible that the '0.8.6-0ubuntu2' package of lirc still doesn't > support this device correctly? > > What information do I need to contribute to help with this? Feedback when using your device with a test patch I posted two or three weeks back would be useful (you should be able to find it in the list archives, needs to be applied to the lirc_imon driver). Basically, so far as we can determine, some LCD/VFD can't keep up with constant writes to the display, so we hack in a delay before returning from any writes, hoping that with delay, the display can then keep up. However, it hasn't helped for at least one user, who has a display that locks up pretty much immediately. Most have manifested as periods of working, and an eventual lockup. The fun part in this is that neither my iMON LCD or VFD has any problems at all keeping up, even in a relatively fast machine constantly blasting data to it, so we need testing by folks such as yourself with problematic displays to figure out a fix. However, it does require patching, building and installing a kernel driver yourself. -- Jarod Wilson ja...@wi... |
From: Jarod W. <ja...@wi...> - 2009-11-18 02:42:22
|
On Nov 17, 2009, at 8:19 PM, Jarod Wilson wrote: > On Nov 17, 2009, at 5:55 PM, Johnny Walker wrote: > >> using Mythbuntu 8.10 and lirc 0.8.6-0ubuntu2 >> SilverStone LC11SM case with SoundGraph IMON USB device and PAD remote. >> >> This device locks up and stops responding after a time. >> >> The problem is that after about an hour maybe the device stops >> responding. It's almost exactly like the behavior described when on >> previous versions you were running only 1 lirc instance and not 2 tied >> together with a listen statement. >> >> When it locks up the LCD stops updating (it's not that good actually >> - I notice the LCD is not updating pretty often) The remote stops >> working altogether. I am unable to rmmod the lirc_imon module - it >> says it's in use. >> >> I've enable debug=1 in the modprobe.d/lirc.conf file but i'm not sure >> how to use this data. >> >> Is it possible that the '0.8.6-0ubuntu2' package of lirc still doesn't >> support this device correctly? >> >> What information do I need to contribute to help with this? > > Feedback when using your device with a test patch I posted two or three weeks back would be useful (you should be able to find it in the list archives, needs to be applied to the lirc_imon driver). Basically, so far as we can determine, some LCD/VFD can't keep up with constant writes to the display, so we hack in a delay before returning from any writes, hoping that with delay, the display can then keep up. > > However, it hasn't helped for at least one user, who has a display that locks up pretty much immediately. Most have manifested as periods of working, and an eventual lockup. The fun part in this is that neither my iMON LCD or VFD has any problems at all keeping up, even in a relatively fast machine constantly blasting data to it, so we need testing by folks such as yourself with problematic displays to figure out a fix. However, it does require patching, building and installing a kernel driver yourself. Minor correction: seems my VFD actually *was* showing occasional write errors the last time I poked at it. Can't remember if they locked things up though. Will try to poke at it again soonish... -- Jarod Wilson ja...@wi... |
From: Johnny W. <joh...@gm...> - 2009-11-30 15:04:04
|
On Tue, Nov 17, 2009 at 7:19 PM, Jarod Wilson <ja...@wi...> wrote: > On Nov 17, 2009, at 5:55 PM, Johnny Walker wrote: > >> using Mythbuntu 8.10 and lirc 0.8.6-0ubuntu2 >> SilverStone LC11SM case with SoundGraph IMON USB device and PAD remote. >> >> This device locks up and stops responding after a time. >> >> The problem is that after about an hour maybe the device stops >> responding. It's almost exactly like the behavior described when on >> previous versions you were running only 1 lirc instance and not 2 tied >> together with a listen statement. >> >> When it locks up the LCD stops updating (it's not that good actually >> - I notice the LCD is not updating pretty often) The remote stops >> working altogether. I am unable to rmmod the lirc_imon module - it >> says it's in use. >> >> I've enable debug=1 in the modprobe.d/lirc.conf file but i'm not sure >> how to use this data. >> >> Is it possible that the '0.8.6-0ubuntu2' package of lirc still doesn't >> support this device correctly? >> >> What information do I need to contribute to help with this? > > Feedback when using your device with a test patch I posted two or three weeks back would be useful (you should be able to find it in the list archives, needs to be applied to the lirc_imon driver). Basically, so far as we can determine, some LCD/VFD can't keep up with constant writes to the display, so we hack in a delay before returning from any writes, hoping that with delay, the display can then keep up. > > However, it hasn't helped for at least one user, who has a display that locks up pretty much immediately. Most have manifested as periods of working, and an eventual lockup. The fun part in this is that neither my iMON LCD or VFD has any problems at all keeping up, even in a relatively fast machine constantly blasting data to it, so we need testing by folks such as yourself with problematic displays to figure out a fix. However, it does require patching, building and installing a kernel driver yourself. > > -- > Jarod Wilson > ja...@wi... > This weekend the LCD has been lockign up in under an hour reliably. I don't see anything in logs regarding it. The good news is the remote still works when the LCD locks up. Anything you can suggest? -JJ |
From: Johnny W. <joh...@gm...> - 2009-11-18 18:07:23
|
Ok i've patched the lirc_imon driver out of cvs and replaced the following: /lib/modules/2.6.31-14-generic/kernel/ubuntu/lirc/lirc_dev/lirc_dev.ko /lib/modules/2.6.31-14-generic/kernel/ubuntu/lirc/lirc_imon/lirc_imon.ko there were also the new files already at: /lib/modules/2.6.31-14-generic/misc/ I suppose now i just wait and see if the problem persists? On Tue, Nov 17, 2009 at 7:19 PM, Jarod Wilson <ja...@wi...> wrote: > On Nov 17, 2009, at 5:55 PM, Johnny Walker wrote: > >> using Mythbuntu 8.10 and lirc 0.8.6-0ubuntu2 >> SilverStone LC11SM case with SoundGraph IMON USB device and PAD remote. >> >> This device locks up and stops responding after a time. >> >> The problem is that after about an hour maybe the device stops >> responding. It's almost exactly like the behavior described when on >> previous versions you were running only 1 lirc instance and not 2 tied >> together with a listen statement. >> >> When it locks up the LCD stops updating (it's not that good actually >> - I notice the LCD is not updating pretty often) The remote stops >> working altogether. I am unable to rmmod the lirc_imon module - it >> says it's in use. >> >> I've enable debug=1 in the modprobe.d/lirc.conf file but i'm not sure >> how to use this data. >> >> Is it possible that the '0.8.6-0ubuntu2' package of lirc still doesn't >> support this device correctly? >> >> What information do I need to contribute to help with this? > > Feedback when using your device with a test patch I posted two or three weeks back would be useful (you should be able to find it in the list archives, needs to be applied to the lirc_imon driver). Basically, so far as we can determine, some LCD/VFD can't keep up with constant writes to the display, so we hack in a delay before returning from any writes, hoping that with delay, the display can then keep up. > > However, it hasn't helped for at least one user, who has a display that locks up pretty much immediately. Most have manifested as periods of working, and an eventual lockup. The fun part in this is that neither my iMON LCD or VFD has any problems at all keeping up, even in a relatively fast machine constantly blasting data to it, so we need testing by folks such as yourself with problematic displays to figure out a fix. However, it does require patching, building and installing a kernel driver yourself. > > -- > Jarod Wilson > ja...@wi... > > > > |
From: Johnny W. <joh...@gm...> - 2009-11-20 19:16:14
|
My remote has not locked up (yet) but my LCD device has. It's usually at about an hour. There's nothing in the logs about failed writes unless I go to shut down the box. Then it logs these. I wonder if they are related to the shutdown though and not the lock up that forced the reboot. And ideas? On Wed, Nov 18, 2009 at 12:07 PM, Johnny Walker <joh...@gm...> wrote: > Ok i've patched the lirc_imon driver out of cvs and replaced the following: > > /lib/modules/2.6.31-14-generic/kernel/ubuntu/lirc/lirc_dev/lirc_dev.ko > /lib/modules/2.6.31-14-generic/kernel/ubuntu/lirc/lirc_imon/lirc_imon.ko > > there were also the new files already at: > > /lib/modules/2.6.31-14-generic/misc/ > > I suppose now i just wait and see if the problem persists? > > > On Tue, Nov 17, 2009 at 7:19 PM, Jarod Wilson <ja...@wi...> wrote: >> On Nov 17, 2009, at 5:55 PM, Johnny Walker wrote: >> >>> using Mythbuntu 8.10 and lirc 0.8.6-0ubuntu2 >>> SilverStone LC11SM case with SoundGraph IMON USB device and PAD remote. >>> >>> This device locks up and stops responding after a time. >>> >>> The problem is that after about an hour maybe the device stops >>> responding. It's almost exactly like the behavior described when on >>> previous versions you were running only 1 lirc instance and not 2 tied >>> together with a listen statement. >>> >>> When it locks up the LCD stops updating (it's not that good actually >>> - I notice the LCD is not updating pretty often) The remote stops >>> working altogether. I am unable to rmmod the lirc_imon module - it >>> says it's in use. >>> >>> I've enable debug=1 in the modprobe.d/lirc.conf file but i'm not sure >>> how to use this data. >>> >>> Is it possible that the '0.8.6-0ubuntu2' package of lirc still doesn't >>> support this device correctly? >>> >>> What information do I need to contribute to help with this? >> >> Feedback when using your device with a test patch I posted two or three weeks back would be useful (you should be able to find it in the list archives, needs to be applied to the lirc_imon driver). Basically, so far as we can determine, some LCD/VFD can't keep up with constant writes to the display, so we hack in a delay before returning from any writes, hoping that with delay, the display can then keep up. >> >> However, it hasn't helped for at least one user, who has a display that locks up pretty much immediately. Most have manifested as periods of working, and an eventual lockup. The fun part in this is that neither my iMON LCD or VFD has any problems at all keeping up, even in a relatively fast machine constantly blasting data to it, so we need testing by folks such as yourself with problematic displays to figure out a fix. However, it does require patching, building and installing a kernel driver yourself. >> >> -- >> Jarod Wilson >> ja...@wi... >> >> >> >> > |
From: Johnny W. <joh...@gm...> - 2009-12-01 22:44:39
|
>> Feedback when using your device with a test patch I posted two or three weeks back would be useful (you should be able to find it in the list archives, needs to be applied to the lirc_imon driver). Basically, so far as we can determine, some LCD/VFD can't keep up with constant writes to the display, so we hack in a delay before returning from any writes, hoping that with delay, the display can then keep up. So now that I've corrected the LCD Server setting to localhost I can see in the mythfrontend.log when the lcd device stops working: 2009-12-01 15:21:17.003 lcddevice: Connection to LCDServer died unexpectedly. Trying to reconnect every 10 seconds. . . But I don't see any write errors being logged in the kern.log. It seems to restart the mythlcdserver and then keep trying... 2009-12-01 15:29:17.248 Starting mythlcdserver QWidget: Cannot create a QWidget when no GUI is being used 2009-12-01 15:29:17.757 Connecting to lcd server: 127.0.0.1:6545 (try 1 of 10) 2009-12-01 15:29:18.258 Connecting to lcd server: 127.0.0.1:6545 (try 2 of 10) 2009-12-01 15:29:18.758 Connecting to lcd server: 127.0.0.1:6545 (try 3 of 10) 2009-12-01 15:29:19.259 Connecting to lcd server: 127.0.0.1:6545 (try 4 of 10) 2009-12-01 15:29:19.760 Connecting to lcd server: 127.0.0.1:6545 (try 5 of 10) 2009-12-01 15:29:20.260 Connecting to lcd server: 127.0.0.1:6545 (try 6 of 10) 2009-12-01 15:29:20.761 Connecting to lcd server: 127.0.0.1:6545 (try 7 of 10) 2009-12-01 15:29:21.261 Connecting to lcd server: 127.0.0.1:6545 (try 8 of 10) 2009-12-01 15:29:21.762 Connecting to lcd server: 127.0.0.1:6545 (try 9 of 10) 2009-12-01 15:29:22.262 Connecting to lcd server: 127.0.0.1:6545 (try 10 of 10) 2009-12-01 15:29:27.251 Starting mythlcdserver 2009-12-01 15:29:27.759 Connecting to lcd server: 127.0.0.1:6545 (try 1 of 10) Should I take this up on the lcdproc mailing list - or is this handled by the lirc_imon module? |
From: Jarod W. <ja...@wi...> - 2009-12-02 02:36:08
|
On 11/30/2009 10:03 AM, Johnny Walker wrote: > This weekend the LCD has been lockign up in under an hour reliably. I > don't see anything in logs regarding it. The good news is the remote > still works when the LCD locks up. Anything you can suggest? If there's nothing in the logs... Then I'm hesitant to believe its a driver problem. At least, its not hte problem others were having -- they had distinct send_packet failed messages in their system logs. On 12/01/2009 05:44 PM, Johnny Walker wrote: >>> Feedback when using your device with a test patch I posted two or three weeks back would be useful (you should be able to find it in the list archives, needs to be applied to the lirc_imon driver). Basically, so far as we can determine, some LCD/VFD can't keep up with constant writes to the display, so we hack in a delay before returning from any writes, hoping that with delay, the display can then keep up. > > So now that I've corrected the LCD Server setting to localhost I can > see in the mythfrontend.log when the lcd device stops working: > > 2009-12-01 15:21:17.003 lcddevice: Connection to LCDServer died unexpectedly. > Trying to reconnect every 10 seconds. . . > > But I don't see any write errors being logged in the kern.log. > > It seems to restart the mythlcdserver and then keep trying... > > 2009-12-01 15:29:17.248 Starting mythlcdserver > QWidget: Cannot create a QWidget when no GUI is being used > 2009-12-01 15:29:17.757 Connecting to lcd server: 127.0.0.1:6545 (try 1 of 10) > 2009-12-01 15:29:18.258 Connecting to lcd server: 127.0.0.1:6545 (try 2 of 10) > 2009-12-01 15:29:18.758 Connecting to lcd server: 127.0.0.1:6545 (try 3 of 10) > 2009-12-01 15:29:19.259 Connecting to lcd server: 127.0.0.1:6545 (try 4 of 10) > 2009-12-01 15:29:19.760 Connecting to lcd server: 127.0.0.1:6545 (try 5 of 10) > 2009-12-01 15:29:20.260 Connecting to lcd server: 127.0.0.1:6545 (try 6 of 10) > 2009-12-01 15:29:20.761 Connecting to lcd server: 127.0.0.1:6545 (try 7 of 10) > 2009-12-01 15:29:21.261 Connecting to lcd server: 127.0.0.1:6545 (try 8 of 10) > 2009-12-01 15:29:21.762 Connecting to lcd server: 127.0.0.1:6545 (try 9 of 10) > 2009-12-01 15:29:22.262 Connecting to lcd server: 127.0.0.1:6545 (try 10 of 10) > 2009-12-01 15:29:27.251 Starting mythlcdserver > 2009-12-01 15:29:27.759 Connecting to lcd server: 127.0.0.1:6545 (try 1 of 10) > > Should I take this up on the lcdproc mailing list - or is this handled > by the lirc_imon module? I don't know if that's an lcdproc error or a mythlcdserver error there. But it definitely looks to me like lirc_imon isn't at fault. -- Jarod Wilson ja...@wi... |
From: Johnny W. <joh...@gm...> - 2009-12-03 00:45:58
|
On Tue, Dec 1, 2009 at 8:40 PM, Jarod Wilson <ja...@wi...> wrote: > On 11/30/2009 10:03 AM, Johnny Walker wrote: >> >> This weekend the LCD has been lockign up in under an hour reliably. I >> don't see anything in logs regarding it. The good news is the remote >> still works when the LCD locks up. Anything you can suggest? > > If there's nothing in the logs... Then I'm hesitant to believe its a driver > problem. At least, its not hte problem others were having -- they had > distinct send_packet failed messages in their system logs. > > On 12/01/2009 05:44 PM, Johnny Walker wrote: >>>> >>>> Feedback when using your device with a test patch I posted two or three >>>> weeks back would be useful (you should be able to find it in the list >>>> archives, needs to be applied to the lirc_imon driver). Basically, so far as >>>> we can determine, some LCD/VFD can't keep up with constant writes to the >>>> display, so we hack in a delay before returning from any writes, hoping that >>>> with delay, the display can then keep up. >> >> So now that I've corrected the LCD Server setting to localhost I can >> see in the mythfrontend.log when the lcd device stops working: >> >> 2009-12-01 15:21:17.003 lcddevice: Connection to LCDServer died >> unexpectedly. >> Trying to reconnect every 10 seconds. . . >> >> But I don't see any write errors being logged in the kern.log. >> >> It seems to restart the mythlcdserver and then keep trying... >> >> 2009-12-01 15:29:17.248 Starting mythlcdserver >> QWidget: Cannot create a QWidget when no GUI is being used >> 2009-12-01 15:29:17.757 Connecting to lcd server: 127.0.0.1:6545 (try 1 of >> 10) >> 2009-12-01 15:29:18.258 Connecting to lcd server: 127.0.0.1:6545 (try 2 of >> 10) >> 2009-12-01 15:29:18.758 Connecting to lcd server: 127.0.0.1:6545 (try 3 of >> 10) >> 2009-12-01 15:29:19.259 Connecting to lcd server: 127.0.0.1:6545 (try 4 of >> 10) >> 2009-12-01 15:29:19.760 Connecting to lcd server: 127.0.0.1:6545 (try 5 of >> 10) >> 2009-12-01 15:29:20.260 Connecting to lcd server: 127.0.0.1:6545 (try 6 of >> 10) >> 2009-12-01 15:29:20.761 Connecting to lcd server: 127.0.0.1:6545 (try 7 of >> 10) >> 2009-12-01 15:29:21.261 Connecting to lcd server: 127.0.0.1:6545 (try 8 of >> 10) >> 2009-12-01 15:29:21.762 Connecting to lcd server: 127.0.0.1:6545 (try 9 of >> 10) >> 2009-12-01 15:29:22.262 Connecting to lcd server: 127.0.0.1:6545 (try 10 >> of 10) >> 2009-12-01 15:29:27.251 Starting mythlcdserver >> 2009-12-01 15:29:27.759 Connecting to lcd server: 127.0.0.1:6545 (try 1 of >> 10) >> >> Should I take this up on the lcdproc mailing list - or is this handled >> by the lirc_imon module? > > I don't know if that's an lcdproc error or a mythlcdserver error there. But > it definitely looks to me like lirc_imon isn't at fault. > ok - so the last few days I've zeroed in on what's actually happening. The pad on the imon remote is what stops. That includes my enter key which is on that pad. This is all that's in the logs: Dec 2 17:31:33 mythliving kernel: [38109.134168] intf0 decoded packet: 01 00 00 7f 00 00 00 00 Dec 2 17:31:33 mythliving kernel: [38109.174168] intf0 decoded packet: 01 00 00 7f 00 00 00 00 Dec 2 17:31:33 mythliving kernel: [38109.206156] intf0 decoded packet: 01 00 00 7f 00 00 00 00 Dec 2 17:31:36 mythliving kernel: [38112.694506] intf0 decoded packet: 28 a1 95 b7 00 00 24 01 Dec 2 17:31:37 mythliving kernel: [38112.862519] intf0 decoded packet: 28 a1 d5 b7 00 00 24 01 Dec 2 17:40:50 mythliving kernel: [38666.122449] intf0 decoded packet: 28 a1 95 b7 00 00 24 01 Dec 2 17:40:50 mythliving kernel: [38666.290457] intf0 decoded packet: 28 a1 d5 b7 ff 00 24 01 These go on and on until they suddenly stop. The LCD is still updating this time - so it's just the pad on the remote that has stopped functioning. Actually I just tested it and it seems the entire remote has now stopped functioning. What could be the issue here? |
From: Johnny W. <joh...@gm...> - 2009-12-04 17:29:33
|
On Wed, Dec 2, 2009 at 6:22 PM, Johnny Walker <joh...@gm...> wrote: > On Tue, Dec 1, 2009 at 8:40 PM, Jarod Wilson <ja...@wi...> wrote: >> On 11/30/2009 10:03 AM, Johnny Walker wrote: >>> >>> This weekend the LCD has been lockign up in under an hour reliably. I >>> don't see anything in logs regarding it. The good news is the remote >>> still works when the LCD locks up. Anything you can suggest? >> >> If there's nothing in the logs... Then I'm hesitant to believe its a driver >> problem. At least, its not hte problem others were having -- they had >> distinct send_packet failed messages in their system logs. >> >> On 12/01/2009 05:44 PM, Johnny Walker wrote: >>>>> >>>>> Feedback when using your device with a test patch I posted two or three >>>>> weeks back would be useful (you should be able to find it in the list >>>>> archives, needs to be applied to the lirc_imon driver). Basically, so far as >>>>> we can determine, some LCD/VFD can't keep up with constant writes to the >>>>> display, so we hack in a delay before returning from any writes, hoping that >>>>> with delay, the display can then keep up. >>> >>> So now that I've corrected the LCD Server setting to localhost I can >>> see in the mythfrontend.log when the lcd device stops working: >>> >>> 2009-12-01 15:21:17.003 lcddevice: Connection to LCDServer died >>> unexpectedly. >>> Trying to reconnect every 10 seconds. . . >>> >>> But I don't see any write errors being logged in the kern.log. >>> >>> It seems to restart the mythlcdserver and then keep trying... >>> >>> 2009-12-01 15:29:17.248 Starting mythlcdserver >>> QWidget: Cannot create a QWidget when no GUI is being used >>> 2009-12-01 15:29:17.757 Connecting to lcd server: 127.0.0.1:6545 (try 1 of >>> 10) >>> 2009-12-01 15:29:18.258 Connecting to lcd server: 127.0.0.1:6545 (try 2 of >>> 10) >>> 2009-12-01 15:29:18.758 Connecting to lcd server: 127.0.0.1:6545 (try 3 of >>> 10) >>> 2009-12-01 15:29:19.259 Connecting to lcd server: 127.0.0.1:6545 (try 4 of >>> 10) >>> 2009-12-01 15:29:19.760 Connecting to lcd server: 127.0.0.1:6545 (try 5 of >>> 10) >>> 2009-12-01 15:29:20.260 Connecting to lcd server: 127.0.0.1:6545 (try 6 of >>> 10) >>> 2009-12-01 15:29:20.761 Connecting to lcd server: 127.0.0.1:6545 (try 7 of >>> 10) >>> 2009-12-01 15:29:21.261 Connecting to lcd server: 127.0.0.1:6545 (try 8 of >>> 10) >>> 2009-12-01 15:29:21.762 Connecting to lcd server: 127.0.0.1:6545 (try 9 of >>> 10) >>> 2009-12-01 15:29:22.262 Connecting to lcd server: 127.0.0.1:6545 (try 10 >>> of 10) >>> 2009-12-01 15:29:27.251 Starting mythlcdserver >>> 2009-12-01 15:29:27.759 Connecting to lcd server: 127.0.0.1:6545 (try 1 of >>> 10) >>> >>> Should I take this up on the lcdproc mailing list - or is this handled >>> by the lirc_imon module? >> >> I don't know if that's an lcdproc error or a mythlcdserver error there. But >> it definitely looks to me like lirc_imon isn't at fault. >> > ok - so the last few days I've zeroed in on what's actually happening. > The pad on the imon remote is what stops. That includes my enter key > which is on that pad. This is all that's in the logs: > > Dec 2 17:31:33 mythliving kernel: [38109.134168] intf0 decoded > packet: 01 00 00 7f 00 00 00 00 > Dec 2 17:31:33 mythliving kernel: [38109.174168] intf0 decoded > packet: 01 00 00 7f 00 00 00 00 > Dec 2 17:31:33 mythliving kernel: [38109.206156] intf0 decoded > packet: 01 00 00 7f 00 00 00 00 > Dec 2 17:31:36 mythliving kernel: [38112.694506] intf0 decoded > packet: 28 a1 95 b7 00 00 24 01 > Dec 2 17:31:37 mythliving kernel: [38112.862519] intf0 decoded > packet: 28 a1 d5 b7 00 00 24 01 > Dec 2 17:40:50 mythliving kernel: [38666.122449] intf0 decoded > packet: 28 a1 95 b7 00 00 24 01 > Dec 2 17:40:50 mythliving kernel: [38666.290457] intf0 decoded > packet: 28 a1 d5 b7 ff 00 24 01 > > These go on and on until they suddenly stop. > > The LCD is still updating this time - so it's just the pad on the > remote that has stopped functioning. > Actually I just tested it and it seems the entire remote has now > stopped functioning. Interestingly - or not - is that I rebooted the machine at this point to regain remote control and after only 5 or so minutes the LCD stopped responding - ie: the display forze up and did not continue to update. I'm suspecting the USB cable that is part of this case. the SilverStone LC11SM - the usb cables to connect this device are rather lengthy and I've wrapped them up to get them out of the way. Is it possible there's an issue even if I'm not seeing it drop off the USB? |
From: Jarod W. <ja...@wi...> - 2009-12-15 05:55:43
|
On Dec 2, 2009, at 7:22 PM, Johnny Walker wrote: ... > ok - so the last few days I've zeroed in on what's actually happening. > The pad on the imon remote is what stops. That includes my enter key > which is on that pad. This is all that's in the logs: > > Dec 2 17:31:33 mythliving kernel: [38109.134168] intf0 decoded > packet: 01 00 00 7f 00 00 00 00 > Dec 2 17:31:33 mythliving kernel: [38109.174168] intf0 decoded > packet: 01 00 00 7f 00 00 00 00 > Dec 2 17:31:33 mythliving kernel: [38109.206156] intf0 decoded > packet: 01 00 00 7f 00 00 00 00 > Dec 2 17:31:36 mythliving kernel: [38112.694506] intf0 decoded > packet: 28 a1 95 b7 00 00 24 01 > Dec 2 17:31:37 mythliving kernel: [38112.862519] intf0 decoded > packet: 28 a1 d5 b7 00 00 24 01 > Dec 2 17:40:50 mythliving kernel: [38666.122449] intf0 decoded > packet: 28 a1 95 b7 00 00 24 01 > Dec 2 17:40:50 mythliving kernel: [38666.290457] intf0 decoded > packet: 28 a1 d5 b7 ff 00 24 01 > > These go on and on until they suddenly stop. Wait, you're getting a constant stream of that, even when not pressing any button? Or is that from pressing buttons? If you're not pressing anything, then you probably have a stuck button on the case itself, wouldn't be the first one I've heard of... -- Jarod Wilson ja...@wi... |
From: Johnny W. <joh...@gm...> - 2009-12-15 23:21:10
|
>> Dec 2 17:40:50 mythliving kernel: [38666.122449] intf0 decoded >> packet: 28 a1 95 b7 00 00 24 01 >> Dec 2 17:40:50 mythliving kernel: [38666.290457] intf0 decoded >> packet: 28 a1 d5 b7 ff 00 24 01 >> >> These go on and on until they suddenly stop. > > Wait, you're getting a constant stream of that, even when not pressing any button? Or is that from pressing buttons? If you're not pressing anything, then you probably have a stuck button on the case itself, wouldn't be the first one I've heard of... no - the steady stream is from each valid remote keypress. This was when the module was loaded with debug=1. The remote appears to be staying on now - but the VFD is useless if it's gonna lock up and show the wrong time. I guess I could set the screen to flash '12:00AM' as a joke. -jj |