On Fri, Jul 10, 2009 at 03:06:23PM -0600, Matthew Wilcox wrote:
> 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?
Yeah, looks good to me to add for staging, thanks for the prompting.
greg k-h
--
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
