Bug 829425 - unable to handle kernel NULL pointer dereference at 00000040 - kernel panic when using signotec sigma usb signature tablet
unable to handle kernel NULL pointer dereference at 00000040 - kernel panic w...
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
17
i686 Unspecified
unspecified Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
first=3.3.7 tested=3.4
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-06 12:58 EDT by pi_raph
Modified: 2012-09-12 12:37 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-09-12 12:37:59 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
bug report created by abrt (5.48 KB, text/plain)
2012-06-06 12:58 EDT, pi_raph
no flags Details
Another backtrace of a crash (2.88 KB, text/plain)
2012-06-06 12:59 EDT, pi_raph
no flags Details
another backtrace of a panic (1.97 KB, text/plain)
2012-06-06 13:00 EDT, pi_raph
no flags Details
/var/log/messages of kernel 3.4.0-1.f17 problem (17.45 KB, text/plain)
2012-06-09 21:48 EDT, pi_raph
no flags Details

  None (edit)
Description pi_raph 2012-06-06 12:58:30 EDT
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 12:59:46 EDT
Created attachment 589958 [details]
Another backtrace of a crash
Comment 2 pi_raph 2012-06-06 13:00:31 EDT
Created attachment 589959 [details]
another backtrace of a panic
Comment 3 pi_raph 2012-06-09 21:48:04 EDT
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 12:34:42 EDT
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 18:11:07 EDT
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 08:56:47 EDT
Do you have any logs from kernel-debug ?

Note You need to log in before you can comment on or make changes to this bug.