Load a 32bit kernel module on 64bit OS?

ferite · 06-01-2015, 07:58 PM

Hi.

Here is the scenario:

I have a third party software (SDK) that uses a kernel module to drive an infrared camera. The software are 32bit libraries of which I have not source code. The driver (kernel module) in the other hand is provided as source code. Now I have tested without problem this system on 32 bit machine. For some reasons now I must make this work on 64 bit machine.

So I installed the 32 bit support libraries for Linux (Ubuntu). With this, the software runs. But I have issues trying the software to work with the driver.

>If I build the driver against the 64 bit kernel, modprobe loads the module, but the software throws a "segmentation fault (core dumped)". Obviously there is a mismatch between 32bit software and 64 bit driver.

>If I build the driver against the 32 bit kernel, modprobe fails with "ERROR: could not insert 'moduleName': Exec format error". A 32 bit module does not simply loads on 64 bit OS.

My question is what can i do to get this work. I supposed that if 32 bit software can run on 64 bit OS, a kernel module can too, but obviously is not so simple. Is there a way to achieve this?.

Thanks.

Ztcoracat · 06-01-2015, 09:16 PM

Hi:

I've heard that re-compiling the kernel will get things that didn't work to work.
https://help.ubuntu.com/community/Kernel/Compile

Your program is only allowed to touch memory that belongs to it. Any access outside of those areas will cause a segmentation fault. Maybe debugging will help?

Here's a few links that may help or at least get you pointed in the right direction.
Sorry I don't know more.

http://www.cprogramming.com/debugging/segfaults.html
https://www.netbsd.org/docs/guide/en/chap-kernel.html
https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel

Debugging:-
https://wiki.ubuntu.com/DebuggingProcedures
https://wiki.ubuntu.com/Kernel/Debugging

HTH

syg00 · 06-01-2015, 10:30 PM

Generally it should work - but ... have a read of this. Opensuse, but generally applicable.
The 32-bit API should cover most cases as it says - else the vendor needs to supply compatible binaries.

Ztcoracat · 06-01-2015, 10:35 PM

Thanks for the link syg00-

johnsfine · 06-02-2015, 05:29 AM

Quote:

Originally Posted by ferite

If I build the driver against the 64 bit kernel, modprobe loads the module, but the software throws a "segmentation fault (core dumped)". Obviously there is a mismatch between 32bit software and 64 bit driver.

That "obvious" conclusion would not even be my first guess. More likely, the driver contains some portability error and simply doesn't work when compiled for 64-bit. Since you have the source code, it should be possible to find and correct that portability error.

32-bit applications work with 64-bit drivers in Linux (and other OS's). A correctly designed driver interfaces with the kernel in a way that should make the issue of the application bit size invisible to the driver. The kernel takes care of dealing with the 32-bit application.

So your guess that the 32-bit application is not compatible with 64-bit driver is not easy to completely rule out, but it is also not easy for me to believe.

Quote:

I supposed that if 32 bit software can run on 64 bit OS, a kernel module can too, but obviously is not so simple. Is there a way to achieve this?.

VM so you have a 32-bit kernel in which to use the 32-bit driver. Otherwise, I'm pretty sure your assumption that a 32-bit kernel module can run in a 64-bit kernel is wrong.

Quote:

Originally Posted by syg00

Generally it should work

Which "it" is that? In context you seem to be saying a 32-bit kernel module can work in a 64-bit kernel. But then you posted a link explicitly saying it can't.

A 64-bit driver and 64-bit kernel and 32-bit application should all play well together. So hopefully that is what you meant by "it".

syg00 · 06-02-2015, 05:34 AM

Indeed - the OP basically proved the 64-bit kernel requirement.

Didn't realise I was being ambidextrous.

jpollard · 06-02-2015, 06:28 AM

It may also depend on any ioctls that may be implemented by the kernel module... These get translated by the 32bit ABI, but custom ioctls would not. This in turn would cause a segmentation fault in the 32bit libraries as the data being passed would be for 64 bit rather than 32 bit. The only way to find out is to trace the segmentation fault.

And 32 bit kernel modules DON'T WORK in a 64 bit kernel. The kernel internal APIs are 64 bit only.

ferite · 06-02-2015, 03:31 PM

Thanks all for your answers.

Quote:

Originally Posted by jpollard

It may also depend on any ioctls that may be implemented by the kernel module... These get translated by the 32bit ABI, but custom ioctls would not. This in turn would cause a segmentation fault in the 32bit libraries as the data being passed would be for 64 bit rather than 32 bit. The only way to find out is to trace the segmentation fault.

And 32 bit kernel modules DON'T WORK in a 64 bit kernel. The kernel internal APIs are 64 bit only.

Unfortunately my knowledge regarding C++, and driver development is limited for making a complete diagnostics. The definitions that could be found in the header file are:

Code:

#define USB_FJVEINCAM_IOCTL_CTRLMSG 	_IOWR(0xB4,0x01,struct fjveincam_cmsg)
#define USB_FJVEINCAM_IOCTL_CHECK		_IO(0xB4,0x02)
#define USB_FJVEINCAM_IOCTL_INFO		_IOR(0xB4,0x03,struct fjveincam_info)
#define USB_FJVEINCAM_IOCTL_CONFIRM 	_IO(0xB4,0x04)

/* for USB_FJVEINCAM_IOCTL_CTRLMSG */

struct fjveincam_cmsg {
	struct {
		unsigned char bRequestType;
		unsigned char bRequest;
		unsigned short wValue;
		unsigned short wIndex;
		unsigned short wLength;
	} req;						/* USB device control request data */
	void *data; 				/* response data area pointer */
};

/* for USB_FJVEINCAM_IOCTL_CHECK */

	/* no structure */

/* for USB_FJVEINCAM_IOCTL_INFO */

/* Magic number for Fujitsu Palmsecure sensor driver. */
#define FJPV_MAGIC	0x464A5056

struct fjveincam_info {
	int magic;					/* Magic number for indicating Fujitsu Palmsecure sensor driver. */
	int minor;					/* minor number */
	int o_timeout;				/* counter of open time out */
	int r_error;				/* counter of read error */
	int r_lasterr;				/* read last error */
	int w_error;				/* counter of write error */
	int w_lasterr;				/* write last error */
	unsigned char version[8];	/* device driver version string */
};

Just for the record, I am using this with a modified kernel. Installation instructions specify CONFIG_USB_DYNAMIC_MINORS should be disabled.

jpollard · 06-02-2015, 05:12 PM

The void *data would be wrong.

In a 32 bit binary that is a 32 bit address. The driver would be assuming it got a 64 bit address - which would be invalid, and possibly be the cause of your segmentation error. It would be if the fault is traced to the ioctl.

sundialsvcs · 06-16-2015, 07:43 AM

By far the simplest solution would be to ask the vendor for appropriate drivers. I'm not quite sure why "an infrared camera" has kernel requirements, anyway. How is this camera connected?

jpollard · 06-16-2015, 08:41 AM

Quote:

Originally Posted by sundialsvcs

By far the simplest solution would be to ask the vendor for appropriate drivers. I'm not quite sure why "an infrared camera" has kernel requirements, anyway. How is this camera connected?

Even if the camera were connected via USB, there could be problems in that the application isn't using libusb to communicate with it...

I THINK (but not sure) the 32 bit version of libusb would work on a 64 bit system.

Ztcoracat · 06-16-2015, 07:22 PM

It can't hurt to re-compile the kernel and see if that works. It might just work but you won't know till you give it a go.

See here for libusb-
http://www.libusb.org/

The Infrared-HOWTO provides an introduction to Linux and infrared devices-
(not sure if this will help but none the less I looked it up.
http://www.tldp.org/HOWTO/html_single/Infrared-HOWTO/

What make and model is your camera ferite?

mrtcn · 11-03-2015, 05:22 PM

I've compiled the same driver for different architectures, do you still need any help?

jefro · 11-03-2015, 07:08 PM

Run a virtual machine in 32 bit??