On Fri, Jul 10, 2009 at 12:30:51PM -0700, Elwood C. Downey wrote:
> Hello all,
>
> I have a problem with a PCI char driver. I would appreciate any pointers on how to proceed.
>
> Basically, I have a PCI char driver that worked under 2.6.13 and does not
> work under 2.6.22.
OK, so basically you're crazy. 2.6.13 was released on August 28, 2005 and
2.6.22 was released on July 8th 2007. You're posting to a development
mailing list about kernels that dropped off the 'we care' list about 21
months ago. It would be slightly easier to take you seriously if you
were at least trying to update to a kernel from this year.
Who is forcing you to use such antiquated kernels? You should be seeking
support from them, not us.
> The system is a 1.8 GHz Intel SBC (single-board computer) with 2GB RAM. There is
> no disk, just a 32 GB Flash drive. I did the original development on an Intel desktop
> running 2.6.13. I temporarily connected the IDE disk from that desktop to the SBC and
> everything works fine that way so it doesn't appear to be the hardware, although I
> suppose it's possible the flash-based configuration might be an issue in some way.
> Unfortunately, changing the Flash to use 2.6.22 is not an option for reasons unrelated.
So ... you compiled this module against 2.6.13, then tried to load it
on a machine running 2.6.22? Has your vendor deliberately disabled all
the safety features we put in to stop you doing something this crazy?
Basically, every data structure in the Linux kernel is subject to change.
You have to compile your module against the kernel you're loading it into.
> Anyway, insmod loads the module just fine. It is listed by lsmod; "lspci -v" shows the
> device addresses and correct module; and its char device, /dev/ik220, is created
> correctly. But the first time an app calls open ("/dev/ik220", O_RDWR) the kernel
> crashes flat immediately. I put a printk in the open file_operations and it does even
> get into the open (or at least there is nothing in /var/log/syslog after a reboot).
>
> Since it loaded OK I figured the probe code was setting up for some future problem. So I
> gutted all the probe code and added it back slowly. I found that the open would not
> crash until I added the first call to ioremap(). That call itself claims to succeed but
> evidently sets up for later disaster.
>
> I actually don't really need an open entry, just ioctl is fine, but I added one with
> just a printk to see what would happen. The same thing happens in the ioctl: it never
> gets called because the kernel crashes.
>
> I've put a copy of the driver at http://www.clearskyinstitute.com/ik220. Any thoughts
> would be appreciated.
Thanks for posting that; it looks like a fairly standard crappy driver.
Greg, want to pick that one up for staging?
--
Matthew Wilcox Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
