Hello kernel gurus.
I have a char driver module that has been working fine under 2.6.13. It is a PCI card for a Heidenhaim rotational encoder. I am now moving to 2.6.22 and it no longer works. In order to get it to build I changed exactly one line:
I changed this:
rc = pci_module_init(&ik220_driver);
to this:
rc = pci_register_driver(&ik220_driver);
Under 2.6.22 it loads fine but as soon as my app opens /dev/ik200 the kernel crashes without a trace. I added lots of printk statements to see what is going on. The printk statements for pci_driver .probe and .remove show up as expected. But as soon as my application does an open the kernel crashes immediately -- I do not even see the file_operations .open() fops entry getting called.
Any clues would be appreciated.
Thanks in advance,
Elwood, Tucson AZ
__________________________
Subscribe now!
The Latest
Newsletter
Tech Tip Videos
- Nov-19-09
- Nov-04-09
Recently Popular
From the Magazine
December 2009, #188
If last month's Infrastrucuture issue was too "big" for you then try on this month's Embedded issue. Find out how to use Player for programming mobile robots, build a humidity controller for your root cellar, find out how to reduce the boot time of your embedded system, and if you're new to embedded systems find out the basics that go into one. You can also read about the Beagle Board, the Mesh Potato and a spate of other interestingly named items. And along with our regular columns don't miss our new monthly column: Economy Size Geek.
Delicious
Digg
StumbleUpon
Reddit
Facebook








The Code
On July 5th, 2009 Mitch Frazier says:
Since this is not a standard driver a reference to where it can be downloaded would be useful.
__________________________Mitch Frazier is an Associate Editor for Linux Journal and the Web Editor for linuxjournal.com.
2.6.13 char driver not working on 2.6.22
On July 8th, 2009 ecdowney says:
Hi Mitch, thanks for taking an interest in my little conundrum. I put a copy of the driver at http://www.clearskyinstitute.com/ik220 . The device in question is a PCI card from Heidenhain that interfaces to up to 8 of their absolute encoders. I got the driver originally from them for 2.4 kernels. They have nothing more recent so I hacked on it and got it to work on 2.6.13. Now at 2.6.22 it's not working again.
The probe function works because after insmod the module ik220 is listed by lsmod and reported correctly by lspci -v as the driver for the given device. It also creates /dev/ik220 correctly. But as soon as I try to open ("/dev/ik220", O_RDWR) the kernel immediately crashes. I put a printk in the ioctl file_operations but it never prints, so it looks like the kernel is panicing before it reaches the driver. I don't need an open file_ops but I added one anyway just to test with a printk and found it never prints either, the kernel crash comes before it is called.
Char Driver
On July 9th, 2009 Mitch Frazier says:
I looked at your code before I finished reading your post... my first suggestion was going to be to add an open() function, but now I see you already tried that. It shouldn't be necessary anyways, the char device code does not require an open() function.
What precise version of the kernel are you using, 2.6.22.what? There were about 15 different revisions of 2.6.22.
Another thought, and I have no real reason to think this might fix it, but it's consistent with other kernel drivers, is to add static const to the file_operations declaration:
static const struct file_operations ik220_fops = { ... };Another thing you might want to do, again for consistency with newer code, is to change the syntax of the structure initializers:
static struct pci_driver ik220_driver = { .name = DRV_NAME, .id_table = ik220_tbl, .probe = ik220_init_one, .remove = ik220_remove_one, }; static const struct file_operations ik220_fops = { .ioctl = ik220_driver_ioctl, };The "name: value" syntax was long ago deprecated by gcc.
Since the code dies before it gets to your open() function (when you have one), the next move is probably to add some debugging code to the kernel proper. A good starting point is the function chrdev_open() in the file fs/char_dev.c. That's where character devices are "opened", it's the function that calls your open() function.
__________________________Mitch Frazier is an Associate Editor for Linux Journal and the Web Editor for linuxjournal.com.
2.6.13 char driver not working on 2.6.22
On July 9th, 2009 ecdowney says:
Thanks for the thoughts. Alas, the extra statics and .name changes did not help. This is 2.6.22-rtai. We're not using any RTAI stuff, it's just there for possible future work.
I hesitate to open the door to hacking the kernel itself so I'm still fiddling with the driver.
Since it loads but fails on first use, I'm thinking something in ik220_init_board is setting up for later trouble. I gutted the code and added it back slowly. I found that the open would not crash until I added back the call to ioremap_nocache(). I wonder what that could mean??
Char Driver
On July 10th, 2009 Mitch Frazier says:
Like I said I didn't really expect those changes to fix it, I might have hoped, but I didn't believe. :).
I don't blame you not wanting to hack the kernel itself.
Is the call to pci_request_regions() working? The return value is not checked, should return zero.
You might try changing ioremap_nocache to ioremap. Nocache should be the right one to call, since you don't want device registers to be cached, but very few existing drivers seem to use it. Although, again, I don't really expect that to fix it.
Also does it make sense that pci resource #1 is skipped?
__________________________Mitch Frazier is an Associate Editor for Linux Journal and the Web Editor for linuxjournal.com.
2.6.13 char driver not working on 2.6.22
On July 10th, 2009 ecdowney says:
pci_request_regions() is confirmed to be returning 0.
using ioremap: no change (still later crashes).
changing pci_resource_start to 0, 1, 2 gives this in syslog:
Jul 10 18:40:12 montsec-ocs kernel: [37134.167618] IK220: 2nd IO-Resource is no
IOMemory! Wrong Card?
<Groan>
Stock Kernel
On July 10th, 2009 Mitch Frazier says:
Another thing that might be useful to test if possible is to see how the driver acts using a stock kernel, rather than an RTAI patched kernel.
__________________________Mitch Frazier is an Associate Editor for Linux Journal and the Web Editor for linuxjournal.com.
IO Memory and Virtual Memory Values
On July 10th, 2009 Mitch Frazier says:
What are the values printed out by the statements:
What's the output from "lspci -vvv" for the card?
__________________________Mitch Frazier is an Associate Editor for Linux Journal and the Web Editor for linuxjournal.com.
2.6.13 char driver not working on 2.6.22
On July 10th, 2009 ecdowney says:
[oh I see, the > characters looked like html tags]
2.6.13 char driver not working on 2.6.22
On July 10th, 2009 ecdowney says:
[lspci in next comment -- forum chopped it off]
Char Driver
On July 11th, 2009 Mitch Frazier says:
Nothing strange in those values that I can see.
However, I just noticed that the second and third region are mapped with ioremap and not with ioremap_nocache. Have you tried changing those to _nocache? Really doesn't seem like those should be cacheable.
__________________________Mitch Frazier is an Associate Editor for Linux Journal and the Web Editor for linuxjournal.com.
2.6.13 char driver not working on 2.6.22
On July 13th, 2009 ecdowney says:
That did not help either.
But we'll never know because we're giving up on 2.6.22. We've hatched a method to go back to 2.6.13 which we know works. It's an embedded system which will just sit and do it's job so the age of the kernel is not a big deal as long as we get it working.
Thank you very much for your efforts Mitch.
Elwood
Next Time
On July 13th, 2009 Mitch Frazier says:
It would have been nice to find/know the solution... but it doesn't always work out that way.
__________________________Mitch Frazier is an Associate Editor for Linux Journal and the Web Editor for linuxjournal.com.
Post new comment