Hi, I just wanna followup this issue a bit more. We have now tested on several hardware platform, and it is only on one platform it fails. The platform it fails on is Atom Intel e6xx CPU with EG20T PCH platform controller. We do not observe it on the Intel i7 3517UE CPU with Intel 6/7 series system controller. We see this error around 4 times over 100 boots / 2 hours runtime. After the Oops our process is in uninterruptable sleep state (D state). The process is not killable when in this state. The process also uses around 70% CPU, maybe because it is waiting for the ioctl system call to return? We haven't found another way to recover from besides rebooting the system. How can we proceed to fix this issue? Andreas On Thursday, August 15, 2013 at 8:37 AM, Greg KH wrote: > > > > When communicating with AT90USB1287, at random intervals (1/25 boots) > > > > the linux hid_output_field Oopses and kills the communicating thread. > > > > The AT90USB1287 microcontroller uses LUFA library for usb/hid > > > > communication. It is trigged by a ioctl call from userspace and fails > > > > in a kernel paging request. The system is after the oops in a state > > > > where no hid commands is sent anymore and only a boot can fix the > > > > system. > > > > > > > > Keywords: usbhid hid > > > > > > > > Kernel version: Linux version 3.8.13-03081301-generic (apw@gomeisa) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #201305311535 SMP Fri May 31 19:44:30 UTC 2013 > > > > > > > > Oopses: > > > > http://paste.debian.net/24305 > > > > http://paste.debian.net/24306 > > > > http://paste.debian.net/24307 > > > > > > > > Code: > > > > The error is triggered by: > > > > ioctl(fd,HIDIOCSUSAGES, &ref_multi_u); > > > > ioctl(fd,HIDIOCSREPORT, &rep_info_u); > > > > > > > > Notes: > > > > It is very hard to reproduce so seems like race condition… > > > > > > > > Any tips to resolve/workaround this issue is appreciated and please > > > > let me know if my information is incomplete (This is my first kernel > > > > bug report) > > > > > > > > > Any chance you can try a supported kernel, like 3.10.6 or 3.11-rc5 to > > > see if that also causes problems? We can't do anything with > > > distro-specific kernel releases like your 3.8.13 release from Ubuntu, > > > sorry. > > > > > > I've now tried with kernel 3.10.6 (http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.10.6-saucy/) and I can trigger the same issue on this kernel. > > > > Here is a paste from last Oops on this kernel: > > http://paste.debian.net/24993/ > > > > I am also using usbmon to monitor the usb bus traffic, but cannot see anything that should cause the driver to Oops. > > > > Is there any way to find out what can trigger this issue? -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
