Von: Orjan Friberg [mailto:email@example.com]
Gesendet: Dienstag, 10. Juni 2003 15:52
An: Schachner Thomas
Betreff: Re: problem with ioctl call
Schachner Thomas wrote:
> this line in the code causes an segmentation fault on the axis board ,
> but on
> the host system all is ok!!
> ret = ioctl(dev->fd,IOCTL_USB_CLAIMINTF, &interface);
> It seems that the ioctl System call is causing this problem on the axis
> What can i do now ?
I'm guessing that the ioctl call goes to the onewire/libusb.so file, so
NO ioctl is system call which lives in libc.so.6
As i described earlier the libusb.so uses the usbdevfs kernel driver over
the special file /proc/bus/usb .
Look on the developer board with the command mount
you see this entry
none on /proc/bus/usb type usbfs (rw)
also make a cat /proc/bus/usb/drivers which produces:
The steps are: call from server to libusb.so , from libusb.so to libc.so.6 , from libc.so.6 to usbdevfs kernel driver
So maybe there is a problem with libc.so.6 as for usbdevfs driver it would hang the kernel i think.
You can think of libusb.so as a USER Space library which communicates with the kernel over the special file
/proc/bus/usb ( via the segfaulting ioctl calls ) which itself in the kernel communicates over usbdevfs driver with the kernel.
You can kickoff libusb.so and use the ioctl call directly and you will get the segfault.
My problem is that with the hostsystem all runs fine and there are no segmentation faults with the same code!!
The main difference is that the hostsystem uses gcc3.2 and the cris compiler is gcc2.96.
I think there is a problem with gcc2.96/libc.so.6
On the axis platform when you execute libc.so.6 gives
gnu c library stable release version 2.2.3 compiled with gnu cc version 2.96 axis release R46/1.25
on the host platform when you execute libc.so.6 gives
gnu c library stable release version 2.2.5 compiled with gnu cc version 3.2
Is it possible to get libc version 2.2.5 for the axis platform?
Is there a gcc3.2 axis release ?
Any hints how to track down the ioctl calls in the libc library on the axis platform, when gdb gives always "cannot access
memory" and on the host system all works fine??
I would suggest adding printouts to that function to try and narrow down
exactly which line in the code causes the segmentation fault. If that
particular line accesses a pointer, for example, I would trace back to
where and how it was declared and allocated. I've seen stuff before in
some USB drivers where static structs were declared __devinitdata (which
means it's thrown away by the kernel) and later used, which didn't work