On Fri, Aug 23, 2013 at 12:52 PM, Andreas Lillebø Holm <andr...@sqhead.com> wrote: > 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?
IIRC, Jiri fixed some paging requests with the two following patches: http://git.kernel.org/cgit/linux/kernel/git/jikos/hid.git/commit/?h=for-next&id=27ce405039bfe6d3f4143415c638f56a3df77dca http://git.kernel.org/cgit/linux/kernel/git/jikos/hid.git/commit/?h=for-next&id=bc197eedef1ae082ec662c64c3f4aa302821fb7a At least, these two patches are related to hid_output_report(). I think they are scheduled for 3.12, so I can not find them in Linus' tree. It would worth trying them :) Cheers, Benjamin > > > 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 majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
