Bug 829425

Summary: unable to handle kernel NULL pointer dereference at 00000040 - kernel panic when using signotec sigma usb signature tablet
Product: [Fedora] Fedora Reporter: pi_raph
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 17CC: gansalmon, itamar, jforbes, jonathan, kernel-maint, madhu.chinakonda, sgruszka
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Unspecified   
Whiteboard: first=3.3.7 tested=3.4
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-09-12 16:37:59 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
bug report created by abrt
none
Another backtrace of a crash
none
another backtrace of a panic
none
/var/log/messages of kernel 3.4.0-1.f17 problem none

Description pi_raph 2012-06-06 16:58:30 UTC
Created attachment 589957 [details]
bug report created by abrt

Description of problem:
When fetching a signature from a signotec sigma signature tablet there is a high chance of a kernel panic on a fresh f17 live-usb boot. No such problem was found on a fresh f16 live-usb boot but an updated f16 install also shows this behaviour - as does an updated f17 install.
The application used for testing was their Java Demo which accesses a native linux .so (running as root or with udev 0666 rule for usb).


Version-Release number of selected component (if applicable):
kernel-3.3.7-1.fc17.i686
kernel-3.3.7-1.fc16.x86_64

How reproducible:
The number of attempts needed to get a crash varies but after a few dozen 
a kernel panic is a near certainty.


Steps to Reproduce:
1. boot fresh live 
2. install java and signotec demo
3. run and fetch signature a few times
- this unfortunately requires the tablet

Comment 1 pi_raph 2012-06-06 16:59:46 UTC
Created attachment 589958 [details]
Another backtrace of a crash

Comment 2 pi_raph 2012-06-06 17:00:31 UTC
Created attachment 589959 [details]
another backtrace of a panic

Comment 3 pi_raph 2012-06-10 01:48:04 UTC
Created attachment 590680 [details]
/var/log/messages of kernel 3.4.0-1.f17 problem

problem persists with new kernel update 3.4.0-1

Comment 4 Josh Boyer 2012-07-10 16:34:42 UTC
As far as I can tell, there is no in-kernel driver for this device.  It seems to have some kind of wrapper library to interface between the java demo and libusb, as you mentioned.

The crashes are all in very random areas with the exception that they all fail in allocating memory.  You might try running a debug kernel by installing kernel-debug to see if that produces some more useful information.  Additionally, you might try emailing this issue to the linux-usb mailing list.  They might be able to help you more directly.

Comment 5 Stanislaw Gruszka 2012-07-11 22:11:07 UTC
Hmm, something corrupts kmalloc (SLUB allocator) internal data. How does it happen, it's hard to tell from calltraces - corruption happens before that, or this is SLUB bug itself. If you install kernel-debug and try to reproduce the issue does it print some other WARNINGs/messages?

Comment 6 Stanislaw Gruszka 2012-07-13 12:56:47 UTC
Do you have any logs from kernel-debug ?