I'm not terribly familiar with ISDv4 operation, but I think the X server is just handing us all the devices it can find, including card0. If it were a serial device, it'd be routed to the ISDv4 code. I'm not sure where we filter out invalid devices, but wcmPreInit needs to eventually find its way down to SetupProc_fail to prevent our driver from claiming it. My guess is that we aren't failing soon enough, and isdv4Init assumes that we're actually giving it a real ISDv4 device.
Jason --- Day xee-nee-svsh duu-'ushtlh-ts'it; nuu-wee-ya' duu-xan' 'vm-nvshtlh-ts'it. Huu-chan xuu naa~-gha. On Tue, Nov 29, 2011 at 12:52 PM, Michael Spreng <[email protected]> wrote: > Hi > > I was successful in attaching the debugger :) And it crashes in > wcmISDV4.c:950, in a call to fclose with a NULL pointer. It obviously > jumps to out: after a failed fopen(), and then closes file anyway, which > shouldn't be done. It tries to open > "/sys/devices/pci0000:00/0000:00:02.0/drm/card0/device/id" which doesn't > make a lot of sense to me. Maybe I can find out more, why this happens, > in a few days. > > After writing an if(file) in front of the fclose, it crashes in > /lib64/ld-linux-x86-64.so.2, called from xf86SetSerialSpeed, for which I > do not have debug symbols yet. Also needs more investigation. > > Michael > > On 17.11.2011 18:47, Jason Gerecke wrote: >> On Wed, Nov 16, 2011 at 1:40 PM, Michael Spreng <[email protected]> >> wrote: >>> Hello >>> >>> I already wrote on the discuss mailing list, to get my tablet working >>> again. Now I got a bit further, The device sows up as /dev/ttyS0, but it >>> crashes the X server: >>> >>> Backtrace: >>> 0: X (xorg_backtrace+0x28) [0x45fcb8] >>> 1: X (0x400000+0x64299) [0x464299] >>> 2: /lib64/libpthread.so.0 (0x7fa106c1f000+0xf430) [0x7fa106c2e430] >>> 3: /lib64/libc.so.6 (fclose+0x7) [0x7fa105bd83c7] >>> 4: /usr/lib64/xorg/modules/input/wacom_drv.so (0x7fa1025b6000+0xca00) >>> [0x7fa1025c2a00] >>> 5: /usr/lib64/xorg/modules/input/wacom_drv.so (0x7fa1025b6000+0xcadf) >>> [0x7fa1025c2adf] >>> 6: /usr/lib64/xorg/modules/input/wacom_drv.so (0x7fa1025b6000+0x12e31) >>> [0x7fa1025c8e31] >>> 7: /usr/lib64/xorg/modules/input/wacom_drv.so (0x7fa1025b6000+0xa1e5) >>> [0x7fa1025c01e5] >>> 8: X (0x400000+0x7ee31) [0x47ee31] >>> 9: X (0x400000+0x11d2df) [0x51d2df] >>> 10: X (0x400000+0x11d9ae) [0x51d9ae] >>> 11: X (config_init+0x9) [0x51cc99] >>> 12: X (InitInput+0x105) [0x471ff5] >>> 13: X (0x400000+0x24ab5) [0x424ab5] >>> 14: /lib64/libc.so.6 (__libc_start_main+0xfd) [0x7fa105b93d2d] >>> 15: X (0x400000+0x24699) [0x424699] >>> Segmentation fault at address (nil) >>> >>> Fatal server error: >>> Caught signal 11 (Segmentation fault). Server aborting >>> >>> I couldn't debug the server, it crashes very quickly, so no time to >>> attach a debugger. And starting xinit from gdb doesn't help either, as >>> it doesn't stop at the segmentation fault. How can I debug it, to help >>> find the bug? >>> >>> Michael >>> >>> P.S. : I'm using xorg 1.10.4 and kernel 3.0.6 >>> >>> >> If you're comfortable debugging the driver with GDB, my suggestion >> would be to call sleep(10) when the driver starts to initialize the >> tablet. Add it to the top of the wcmPreInit function in wcmConfig.c. >> This should give you ample time to attach GDB before the driver starts >> to do anything. >> >> Jason >> >> --- >> Day xee-nee-svsh duu-'ushtlh-ts'it; >> nuu-wee-ya' duu-xan' 'vm-nvshtlh-ts'it. >> Huu-chan xuu naa~-gha. > ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d _______________________________________________ Linuxwacom-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
