On Mar 30, 2011, at 10:49 PM, Paul Bordukoff wrote:
> Wed, 30 Mar 2011 13:41:26 -0400 Jarod Wilson <jarod@...>:
>
>> On Mar 29, 2011, at 11:15 PM, Paul Bordukoff wrote:
>>
>>> Tue, 29 Mar 2011 16:06:38 -0400 Jarod Wilson <jarod@...>:
>>>
>>>> On Mar 26, 2011, at 5:37 AM, Wgge wrote:
>>>>
>>>>> Jarod Wilson <jarod@...> writes:
>>>>>
>>>>>> Nope, that's the right place, and while you may have built and
>>>>>> installed bits from there, I'm positive that's not what you're
>>>>>> actually seeing load on your system. chardev 61 went away quite
>>>>>> a few months ago. We use a dynamic miscdev now, which typically
>>>>>> ends up being something in the high 240s or low 250s. Look in
>>>>>> your kernel tree, see if there isn't another lirc_dev.ko and
>>>>>> lirc_sir.ko.
>>>>>
>>>>> Same problem seen. If chardev 61 is gone, why we see configure scripts
>>>> default
>>>>> it to 61?
>>>>> --with-major=value specify the device major for the driver (61)
>>>>> This is also seen in gcc options when making:
>>>>> -DIRCTL_DEV_MAJOR=61
>>>>
>>>> Unused legacy cruft. Its been unused in lirc git since October 20,
>>>> 2010, via commit 2f41e817, the most relevant excerpt of which is:
>>>>
>>>> static int __init lirc_dev_init(void)
>>>> {
>>>> - if (register_chrdev(IRCTL_DEV_MAJOR, IRCTL_DEV_NAME,
>> &lirc_dev_fops))
>>>> {
>>>> - printk(KERN_ERR "lirc_dev: register_chrdev failed\n");
>>>> - goto out;
>>>> - }
>>>> + int retval;
>>>>
>>>> lirc_class = class_create(THIS_MODULE, "lirc");
>>>> if (IS_ERR(lirc_class)) {
>>>> + retval = PTR_ERR(lirc_class);
>>>> printk(KERN_ERR "lirc_dev: class_create failed\n");
>>>> - goto out_unregister;
>>>> + goto error;
>>>> + }
>>>> +
>>>> + retval = alloc_chrdev_region(&lirc_base_dev, 0, MAX_IRCTL_DEVICES,
>>>> + IRCTL_DEV_NAME);
>>>> + if (retval) {
>>>> + class_destroy(lirc_class);
>>>> + printk(KERN_ERR "lirc_dev: alloc_chrdev_region failed\n");
>>>> + goto error;
>>>> }
>>>>
>>>> printk(KERN_INFO "lirc_dev: IR Remote Control driver registered, "
>>>> "major %d \n", IRCTL_DEV_MAJOR);
>>>
>>> Ok, looks like printk uses deprecated varliable IRCTL_DEV_MAJOR to tell us
>> what number is registered. Here should be MAJOR(lirc_base_dev) instead of it.
>>
>> Oh, crap, you're right. lirc-git still has the above, while the in-kernel
>> bits have long since been changed to:
>>
>> printk(KERN_INFO "lirc_dev: IR Remote Control driver registered, "
>> "major %d \n", MAJOR(lirc_base_dev));
>
> Anyway it is a cosmetic change which does not influence on the "resource busy" problem.
Sorry, yes, meant to say as much.
> I found that the problem is in obsolete (?) code lirc_sir.c. Functions lirc_open and lirc_close should be the same as in lirc_it87.c from kernel (2.6.38) tree.
Um. Why look at the lirc_it87.c code and not the lirc_sir.c code in the
2.6.38 kernel tree? :)
But yes, lirc_sir.c hasn't been resync'd with what's in the upstream
kernel tree. Mostly because lirc_sir.c is an atrocious mess and a bit
of a hack to begin with... (And it doesn't work reliably at all with
the only hardware I have that is driven by it).
> They are don't use the MOD_IN_USE variable, but device_open. The problem was gone after this:
> --- ./lirc/drivers/lirc_sir/lirc_sir.c 2011-03-31 08:33:52.743000005 +0600
> +++ /tmp/lirc_sir.c 2011-03-31 08:25:07.000000000 +0600
> @@ -199,6 +199,7 @@ static int debug;
> printk(KERN_DEBUG LIRC_DRIVER_NAME ": " \
> fmt, ## args); \
> } while (0)
> +static bool device_open;
>
> /* SECTION: Prototypes */
>
> @@ -278,16 +279,20 @@ static void safe_udelay(unsigned long us
> static int lirc_open(struct inode *inode, struct file *file)
> {
> spin_lock(&dev_lock);
> - if (MOD_IN_USE) {
> + if (device_open) {
> spin_unlock(&dev_lock);
> return -EBUSY;
> }
> + device_open = true;
> spin_unlock(&dev_lock);
> return 0;
> }
>
> static int lirc_close(struct inode *inode, struct file *file)
> {
> + spin_lock(&dev_lock);
> + device_open = false;
> + spin_unlock(&dev_lock);
> return 0;
> }
There's an even better fix implemented in the in-kernel lirc_sir.c, which
I'll throw into lirc git. Simply rip out the open and close functions and
use lirc_dev_fop_open and lirc_dev_fop_close.
--
Jarod Wilson
jarod@...
|