2.6.13 char driver not working on 2.6.22
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
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Sponsored by AMD
Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6
Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.
Learn more about catching the bad guy in this free white paper.
Sponsored by DLT Solutions
| Designing Electronics with Linux | May 22, 2013 |
| Dynamic DNS—an Object Lesson in Problem Solving | May 21, 2013 |
| Using Salt Stack and Vagrant for Drupal Development | May 20, 2013 |
| Making Linux and Android Get Along (It's Not as Hard as It Sounds) | May 16, 2013 |
| Drupal Is a Framework: Why Everyone Needs to Understand This | May 15, 2013 |
| Home, My Backup Data Center | May 13, 2013 |
- I once had a better way I
29 min 20 sec ago - Not only you I too assumed
46 min 43 sec ago - another very interesting
2 hours 39 min ago - Reply to comment | Linux Journal
4 hours 33 min ago - Reply to comment | Linux Journal
11 hours 27 min ago - Reply to comment | Linux Journal
11 hours 43 min ago - Favorite (and easily brute-forced) pw's
13 hours 34 min ago - Have you tried Boxen? It's a
19 hours 26 min ago - seo services in india
23 hours 58 min ago - For KDE install kio-mtp
23 hours 58 min ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi

It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Featured Jobs
| Linux Systems Administrator | Houston and Austin, Texas | Host Gator |
| Senior Perl Developer | Austin, Texas | Host Gator |
| Technical Support Rep | Houston and Austin, Texas | Host Gator |
| UX Designer | Austin, Texas | Host Gator |
| Web & UI Developer (JavaScript & j Query) | Austin, Texas | Host Gator |
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?



The Code
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.
2.6.13 char driver not working on 2.6.22
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
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.
2.6.13 char driver not working on 2.6.22
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
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.
2.6.13 char driver not working on 2.6.22
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
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.
IO Memory and Virtual Memory Values
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.
2.6.13 char driver not working on 2.6.22
[oh I see, the > characters looked like html tags]
2.6.13 char driver not working on 2.6.22
[lspci in next comment -- forum chopped it off]
Char Driver
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.
2.6.13 char driver not working on 2.6.22
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
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.