From: Bob M. <wb...@wb...> - 2008-12-25 07:25:45
|
> Message: 2 > Date: 24 Dec 2008 11:20:00 +0100 > From: li...@ba... (Christoph Bartelmus) > Subject: Re: modprobe fail with lirc_dev.o: unresolved symbol > lirc_device_destroy > To: lir...@li... > Message-ID: <AsUZ+FH3jFB@christoph> > Content-Type: text/plain; charset=US-ASCII > > Hi! > > Bob Morgan "wb...@wb..." wrote: > > I have installed (from source) on two different PC's > > lirc-0.8.4a from recent tarball, and tried to set up > > a simple lirc_serial LED output to drive various > [...] > > modprobe lirc_serial > > > > which fails as follows: (on both systems) > > > > lirc-0.8.4a# modprobe lirc_serial > > /lib/modules/2.4.26/misc/lirc_dev.o: unresolved symbol lirc_device_destroy > > /lib/modules/2.4.26/misc/lirc_dev.o: unresolved symbol lirc_device_create > > The latest version of kcompat.h from CVS will solve this problem. > But keep in mind that 2.4 kernels are not supported anymore. > > Christoph > > > End of LIRC-list Digest, Vol 31, Issue 20 > ***************************************** Christoph, That did it. I probably would never found that. I am real grateful that CVS has a facility to fetch an individual file, rather than doing the whole CVS fetch (and also instlling CVS here just to do that, normally we just compile whole tarballs here). This has been a decent learning experience in tracking down bugs and following down kernel drivers. Along the way it seemed that just substituting kcompat.h and doing another make didn't result in gcc being called to recompile anything, so I ended up blowing away the install directory and unpacking the tarball again, then swapping in the updated file. It would have seemed to me that make should have spotted the updated file. When I went to make things actually work, I was getting some strange runtime errors that seemed to indicate something like a permissions problem or failure to register something. What I found by trial and error was a serial port irq setting that didn't match the jumpering on the io card, and by putting other possible values into the options line of modules.conf and unloading/reloading the drivers, the errors went away and things started to work. If it can spot a failure of the driver to receive an expected interrupt (and I am glad it doesn't i/o lock up the system) maybe it could write a little more specific error message into the log. lsdev does spot the correct io address for lirc_serial when the modules correctly insmod themselves, but it doesn't happen to mention the associated irq like the stock kernel serial drivers do. That might not be the biggest problem in the world either, and I wouldn't hazard a guess here if the kernel itself needs some other hooks to see it, or if all of the required changes would lie wholly in lirc_serial or in lsdev. lsdev inself has a problem displaying all of the various irq when it encounters multiple serial ports when it trys to print all of them on a single line, and like I said last time I have 6 ports in one system, and about all of them have data fairly continously flowing across them all the time doing all sorts of comm tasks and data acquisition. I now have two machines running it, and one of them actually controls the settop box satisfactorily - the other one is at the lab at work and I don't have any IR appliances handy to test it against, but it delivers waveforms on the scope where the led should connect, and neither is throwing any errors. I am sure I will do quite a few other things with this system, and maybe be able to contribute a few other things along the way, and maybe config a few other remotes that aren't yet on the list. The mode2 raw timing dumps look like they could actually be quite useful in the lab just for general logic analysis of pulse trains of just about anything, that are too long to capture on the scope, and too awkward to capture on a conventional parallel-bus logic capture analyzer, and that is a job I have to face occasionally. That in itself probably ought to be mentioned somewhere on the website. When I do these things, it is usually just one bit wide, and I am interested in timing of transitions between states. Thanks, and merry Christmas Christoph Bob |