It was (re)compiled on 2.6.22.
On Fri, July 10, 2009 2:06 pm, Matthew Wilcox said:
> 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?
>
--
Elwood Downey, President/CTO, Clear Sky Institute, Inc.
http://www.clearskyinstitute.com
--
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
