LCDproc development and user support list

Text archives Help


[Lcdproc] LCDd daemon hangs with USB Crystalfontz 634 LCD


Chronological Thread 
  • From: npavel at ituner.com (Nicu Pavel)
  • Subject: [Lcdproc] LCDd daemon hangs with USB Crystalfontz 634 LCD
  • Date: Sat, 31 Jan 2009 12:13:26 +0200

Hi,

I don't have a Crystalfontz LCD but I got a similar report on picoLCD
20x4 with mythTV freezeing the LCD output.
Do you have the same problem if you run LCDd + lcdproc client ? Either
it's something wrong with mythTV LCDd client or another process is
taking over LCD device or there is a problem in driver usb
implementation. I will check on picoLCD side and post if I find something.

Regards,
Nicu Pavel
> On Fri, 30 Jan 2009, Jeff wrote:
>
>> On Thu, Jan 29, 2009 at 3:08 PM, Daryl F <wyatt at prairieturtle.ca> wrote:
>>
>>> On Thu, 29 Jan 2009, Jeff Artz wrote:
>>>
>>> Does anybody have anything to suggest? It's now been a month since I
>>>> posted my issue, but haven't even gotten a single response...
>>>>
>>>> :-(
>>>>
>>>> Jeff
>>>> ----- Original Message -----
>>>> From: Jeff Artz
>>>> To: lcdproc
>>>> Sent: Sunday, December 28, 2008 11:07 PM
>>>> Subject: [Lcdproc] LCDd daemon hangs with USB Crystalfontz 634 LCD
>>>>
>>>>
>>>> Ok, I've googled and found some references to this hang, and my
>>>> new CF
>>>> 634 display does the same, exactly as described in this thread from
>>>> last
>>>> year:
>>>> http://lists.omnipotent.net/pipermail/lcdproc/2007-April/011646.html
>>>>
>>>> I'm running Fedora Core 8, kernel "2.6.26.6-49.fc8", current CVS
>>>> LCDproc
>>>> v0.5.2
>>>>
>>>> Here's what happens:
>>>> [mythtv at mythbackend etc]$ sudo /sbin/service LCDd start
>>>> Starting up LCDd:
>>>> <hangs forever unless CTRL-C is pressed or a "kill -USR1" is
>>>> issued...>
>>>>
>>>> ps ax of above hang scenerio:
>>>> [root at mythbackend mythtv]# ps ax | grep LCDd
>>>> 16361 pts/1 S+ 0:00 /bin/sh /sbin/service LCDd start
>>>> 16368 pts/1 S+ 0:00 /bin/sh /etc/init.d/LCDd start
>>>> 16373 pts/1 S+ 0:00 /bin/bash -c ulimit -S -c 0 >/dev/null
>>>> 2>&1 ;
>>>> /usr/local/sbin/LCDd -c /home/mythtv/lcd/LCDd.conf
>>>> 16374 pts/1 S+ 0:00 /usr/local/sbin/LCDd -c
>>>> /home/mythtv/lcd/LCDd.conf
>>>> 16375 ? Ss 0:00 /usr/local/sbin/LCDd -c
>>>> /home/mythtv/lcd/LCDd.conf
>>>> 16381 pts/3 R+ 0:00 grep LCDd
>>>> [root at mythbackend mythtv]#
>>>>
>>>> If I manually do a "kill -USR1 16374", "[ OK ]" is displayed and the
>>>> prompt will come back and everything works fine.
>>>>
>>>> So, to help troubleshoot, I changed the ReportLevel to 5, and
>>>> here's what
>>>> I get to stdout:
>>>> [mythtv at mythbackend etc]$ sudo /sbin/service LCDd start
>>>> Starting up LCDd: LCDd version 0.5.2 starting
>>>> Built on Dec 22 2008, protocol version 0.3, API version 0.5
>>>> Using Configuration File: /home/mythtv/lcd/LCDd.conf
>>>> Set report level to 5, output to stderr
>>>> Server forking to background
>>>> Listening for queries on 127.0.0.1:13666
>>>> screenlist_init()
>>>> driver_load(name="CFontz", filename="/home/mythtv/lcd/CFontz.so")
>>>> CFontz: using Device /dev/lcd
>>>> CFontz: init() done
>>>> Key "Escape" is now reserved in exclusive mode by client [-1]
>>>> Key "Enter" is now reserved in shared mode by client [-1]
>>>> Key "Up" is now reserved in shared mode by client [-1]
>>>> Key "Down" is now reserved in shared mode by client [-1]
>>>> screenlist_process()
>>>> screenlist_switch(s=[_server_screen])
>>>> screenlist_switch: switched to screen [_server_screen]
>>>> screenlist_process()
>>>> screenlist_process()
>>>> screenlist_process()
>>>> screenlist_process()
>>>> screenlist_process()
>>>> screenlist_process()
>>>> screenlist_process()
>>>> screenlist_process()
>>>> screenlist_process()
>>>> screenlist_process()
>>>> <etc... And then the running 'mythlcdserver' process starts
>>>> displaying
>>>> screens within a few seconds>
>>>>
>>>> (Which doesn't seem very helpful to me - perhaps it will to the
>>>> developers)
>>>>
>>>> So for the moment I can't setup LCDd to start at boot time, or it
>>>> will
>>>> hang my system. I manually start it after booting. (Thankfully
>>>> that's not
>>>> very often, as it's my MythTV backend system)
>>>>
>>>> How can I help troubleshoot this further? (Suggestions of a debugger
>>>> and/or the process, not quite step-by-step, but the more explict
>>>> the better
>>>> - ie please don't reply with simply "just debug the process"... I
>>>> don't know
>>>> how to do that [yet]!)
>>>>
>>>> Thanks!
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>> Hi Jeff,
>>>
>>> It may be that the child is sending the USR1 signal but it is being
>>> blocked
>>> from the parent because of permissions. Instead of a `ps ax` try `ps
>>> -ef`
>>> and see who owns the processes.
>>>
>>> I suspect the init script is running as root and also the parent LCDd
>>> process but the child is running as a less privileged user and the
>>> signal is
>>> not being delivered. The assumption hear is that the `kill -USR1
>>> <pid>' is
>>> manually being done from a root login so it gets delivered and then the
>>> parent ends and the init script completes and delivers the [ OK ] to
>>> the
>>> console.
>>>
>>> Post the `ps -ef'. Maybe someone else on this list can figure out what
>>> needs to be done if it is permissions at fault.
>>>
>>> -Daryl
>>>
>>>
>>
>> Thanks Daryl,
>>
>> Here's the "ps -ef |grep LCDd" output while issuing a "/sbin/service
>> start
>> LCDd" command:
>>
>> [root at mythbackend ~]# ps -ef |grep LCDd
>> root 3667 3632 0 20:42 pts/5 00:00:00 /bin/sh /sbin/service
>> LCDd
>> start
>> root 3675 3667 0 20:42 pts/5 00:00:00 /bin/sh /etc/init.d/LCDd
>> start
>> root 3680 3675 0 20:42 pts/5 00:00:00 /bin/bash -c ulimit
>> -S -c 0
>>> /dev/null 2>&1 ; /usr/local/sbin/LCDd -c /home/mythtv/lcd/LCDd.conf
>> root 3681 3680 0 20:42 pts/5 00:00:00 /usr/local/sbin/LCDd -c
>> /home/mythtv/lcd/LCDd.conf
>> nobody 3682 3681 0 20:42 ? 00:00:00 /usr/local/sbin/LCDd -c
>> /home/mythtv/lcd/LCDd.conf
>> root 3686 23166 0 20:42 pts/1 00:00:00 grep LCDd
>> [root at mythbackend ~]#
>>
>> (and you can see the parent running as root, and the daemon launced as
>> nobody)
>>
>> If I comment out the "User=" line from the conf file, it still starts as
>> 'nobody', and I get the same result.
>>
>> If, however, I change it to "User=root", it starts as root and
>> exhibits the
>> same behavior, so it doesn't appear to be a permissions issue:
>> [root at mythbackend ~]# ps -ef |grep LCDd
>> root 3800 3632 0 20:51 pts/5 00:00:00 /bin/sh /sbin/service
>> LCDd
>> start
>> root 3807 3800 0 20:51 pts/5 00:00:00 /bin/sh /etc/init.d/LCDd
>> start
>> root 3812 3807 0 20:51 pts/5 00:00:00 /bin/bash -c ulimit
>> -S -c 0
>>> /dev/null 2>&1 ; /usr/local/sbin/LCDd -c /home/mythtv/lcd/LCDd.conf
>> root 3813 3812 0 20:51 pts/5 00:00:00 /usr/local/sbin/LCDd -c
>> /home/mythtv/lcd/LCDd.conf
>> root 3814 3813 0 20:51 ? 00:00:00 /usr/local/sbin/LCDd -c
>> /home/mythtv/lcd/LCDd.conf
>> root 3816 23166 0 20:51 pts/1 00:00:00 grep LCDd
>> [root at mythbackend ~]#
>>
>> PS: Same behavior with latest CVS - revision 1.29.2.4
>>
>> Thanks,
>>
>> Jeff
>>
>
> Hi Jeff,
>
> I run Gentoo so I can't verify the problem here but I can tell you of
> the strange way Gentoo starts LCDd: it uses the -f option to LCDd to
> tell it to start in the foreground but the init script uses a function
> called start-stop-daemon with the --background to force it into the
> background.
>
> I looked at the init scripts packaged with lcdproc for Redhat and it
> uses the daemon function. I don't know how it works or even if Fedora
> is using that for the init script but bear with me...
>
> I wonder if the method Gentoo uses somehow makes it possible for the
> child's USR1 signal to actually reach the parent process? It shouldn't
> matter if the parent is already detached when it forks the child but
> looking at the code in server/main.c it seems like there has been some
> problems with this on different platforms.
>
> I'm running kernel version 2.6.25. Did starting LCDd ever work with a
> kernel prior to 2.6.26?
>
> Please post a copy of the init script Fedora 8 uses so we can see if
> the distribution has changed it from what comes with lcdproc.
>
> -Daryl
> _______________________________________________
> LCDproc mailing list
> LCDproc at lists.omnipotent.net
> http://lists.omnipotent.net/mailman/listinfo/lcdproc
>


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.





Archive powered by MHonArc 2.6.18.

Top of page