From: Jarod W. <ja...@wi...> - 2011-03-29 20:16:51
|
On Mar 29, 2011, at 3:56 PM, Juan Jesús García de Soria Lucena wrote: > Hi, Dmitrii, Jarod... > > I'll put the lirc list in copy of this, if you don't mind, Dmitrii... :-) > > > I've been debugging a little bit the problem that Dmitrii is having > with lirc 0.9.0 and 2.6.37.4. I've been able to reproduce it with > 2.6.35 from Ubuntu 10.10: > > [ 1617.821085] divide error: 0000 [#1] SMP > [ 1617.821104] last sysfs file: > /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq > [ 1617.821114] CPU 1 > [ 1617.821120] Modules linked in: lirc_wpc8769l lirc_dev binfmt_misc > parport_pc ppdev joydev arc4 snd_hda_codec_atihdmi fglrx(P) > snd_hda_codec_realtek mxl5005s snd_hda_intel snd_hda_codec snd_hwdep > snd_pcm snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer > ath9k snd_seq_device zl10353 ath9k_common ath9k_hw ath mac80211 > dvb_usb_ce6230 uvcvideo snd dvb_usb videodev v4l1_compat cfg80211 > v4l2_compat_ioctl32 dvb_core edac_core soundcore i2c_piix4 k10temp > snd_page_alloc psmouse serio_raw edac_mce_amd led_class shpchp video > output lp parport usb_storage ahci pata_atiixp atl1e libahci [last > unloaded: lirc_dev] > [ 1617.821271] > [ 1617.821285] Pid: 8091, comm: xmode2 Tainted: P > 2.6.35-28-generic #49-Ubuntu Mantasta /Aspire 6530G > [ 1617.821298] RIP: 0010:[<ffffffffa00fb4cd>] [<ffffffffa00fb4cd>] > lirc_dev_fop_read+0xfd/0x504 [lirc_dev] > [ 1617.821330] RSP: 0018:ffff88008d5c5e38 EFLAGS: 00010246 > [ 1617.821340] RAX: 0000000000000004 RBX: ffff88013182af00 RCX: 0000000000000000 > [ 1617.821350] RDX: 0000000000000000 RSI: 00000000000080d0 RDI: 0000000000000001 > [ 1617.821360] RBP: ffff88008d5c5ee8 R08: 0000000000000000 R09: ffff880151c30000 > [ 1617.821370] R10: 00007fff91ca4480 R11: 0000000000000246 R12: ffff88013f15ec00 > [ 1617.821380] R13: 0000000000000010 R14: 0000000000000003 R15: 0000000000000004 > [ 1617.821392] FS: 00007f7d33f85760(0000) GS:ffff880001f00000(0000) > knlGS:00000000f696aa90 > [ 1617.821403] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b > [ 1617.821413] CR2: 00007ff5d44cd000 CR3: 000000008d5d1000 CR4: 00000000000006e0 > [ 1617.821423] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > [ 1617.821434] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 > [ 1617.821445] Process xmode2 (pid: 8091, threadinfo ffff88008d5c4000, > task ffff8801231b5b80) > [ 1617.821453] Stack: > [ 1617.821459] 0000000000000000 0000000000000000 ffff88008d5c5d28 > ffff88008d5c5f48 > [ 1617.821474] <0> ffff88013182af90 0000000000000000 00007fff91ca486c > 0000000000000000 > [ 1617.821490] <0> 00007f7d32361720 0000000000000000 0000000000000000 > ffff8801231b5b80 > [ 1617.821508] Call Trace: > [ 1617.821532] [<ffffffff810572f0>] ? default_wake_function+0x0/0x20 > [ 1617.821554] [<ffffffff81260466>] ? security_file_permission+0x16/0x20 > [ 1617.821570] [<ffffffff811539a5>] vfs_read+0xb5/0x1a0 > [ 1617.821583] [<ffffffff81153ae1>] sys_read+0x51/0x80 > [ 1617.821598] [<ffffffff81165b3c>] ? sys_poll+0x7c/0x110 > [ 1617.821617] [<ffffffff8100a0f2>] system_call_fastpath+0x16/0x1b > [ 1617.821626] Code: e8 49 e8 48 e1 89 c2 48 c7 c0 00 fe ff ff 85 d2 > 75 c7 8b bb 88 00 00 00 85 ff 0f 84 57 03 00 00 8b 8b b8 00 00 00 31 > d2 4c 89 f8 <48> f7 f1 48 85 d2 0f 85 a8 01 00 00 48 8b bb b0 00 00 00 > 48 8d > [ 1617.821745] RIP [<ffffffffa00fb4cd>] lirc_dev_fop_read+0xfd/0x504 [lirc_dev] > [ 1617.821765] RSP <ffff88008d5c5e38> > [ 1617.821825] ---[ end trace 9ba104d6dafeedb0 ]--- > > > This is after he modified the driver so that it'll fill in the .dev > field of the lirc_driver struct (this seems to be a new requirement > that the driver did not get modified to satisfy before), because it > wouldn't even load otherwise: > >>>> driver.dev = &lirc_wpc8769l_platform_dev->dev; >>>> before >>>> driver.minor = lirc_register_driver(&driver); > > What's happening: it's a divide_by_zero error because lirc_dev seems > to be reading the ir->chunk_size in lirc_dev_fop_read(): > > 777 if (length % ir->chunk_size) { > 778 dprintk(LOGHEAD "read result = -EINVAL\n", > 779 ir->d.name, ir->d.minor); > > And right now this ir->chunk_size field is copied from > ir->buf->chunk_size in lirc_register_driver(): > > 384 } > 385 ir->chunk_size = ir->buf->chunk_size; > 386 > > Whereas my driver doesn't actually have a valid buffer allocated at > that time. Actually it gets allocated/freed on set_use_inc() and > set_use_dec() as the device is opened/closed. > > After moving lirc_buffer_init()/lirc_buffer_free() calls to some > proper place in > lirc_wpc8769l_module_init()/lirc_wpc8769l_module_exit() (that is, > before/after the lirc_register_driver()/lirc_unregister_driver() > calls), the driver works again. > > So, Jarod... > > Is this behavior change actually intended? I guess so, since these two > commits happened on lirc_serial (the driver I used as a reference for > writing lirc_wpc8769l): > > > 1. Fill in dev pointer: > > http://lirc.git.sourceforge.net/git/gitweb.cgi?p=lirc/lirc;a=commitdiff;h=2d69a41a790ab2c006cb46811beadd132286cbd5 This one was definitely intended, as the dev pointer gets used all over the place now for debug spew in both device-specific drivers and in lirc_dev. > 2. Moving buffer allocation/deallocation as explained above: > > http://lirc.git.sourceforge.net/git/gitweb.cgi?p=lirc/lirc;a=commitdiff;h=6b440d65b50f3d2fab0a618e7c35ee6a34cdc1e8 Less clear on this one... I think there were more fine-grained commits either in my pre-merge kernel tree or in the staging tree, which all got lumped together in lirc git when I did a resync... I do think it was for good reason at some point though. :) > So... should I prepare a patch doing these two things for my driver > and send it to the list? Is there any other modification required to > make the driver up to date? Sounds like that's probably about it for now. Somehow, I neglected to include this driver in the upstream kernel staging submission, and thus, it doesn't get much attention -- most of my focus has been on gradual clean-ups of the drivers in the kernel, with occasional efforts to bring those changes into the lirc git tree. Ultimately, what would be ideal is a rewrite of the driver for rc-core, which is still the goal for all the drivers in the kernel staging area, but it definitely requires a person with the motivation (and probably the hardware) to do it... ;) -- Jarod Wilson ja...@wi... |