Re: Top 10 kernel oopses for the week ending January 12th, 2008
On Sun, 13 Jan 2008, Adrian Bunk wrote: > > Rank 1: implement (hid code) > > WARN_ON at drivers/hid/hid-core.c:784 > > Reported 23 times (39 total reports) > > This appears to be the kernel doing a WARN_ON based on unexpected > > ioctl() arguments > > More info: http://www.kerneloops.org/search.php?search=implement > >... > The only complete bug reports seems to be from one user who loaded a > module whose distribution might be considered a criminal act in some > countries. The most usual case is hid2hci utility, that tries to switch modes on Bluetooth HID peripherials (via hiddev). When these "switching" packets are not compliant with HID report descriptor of the device, this WARN_ON() happens. Unfortunately there is no standard specifying how these packets should look like, so it is guess-game and some rev-eng, that Marcel has put into hid2hci for individual vendors, and sometimes this just happens not to work. I have had the commit below queued in my tree for 2.6.25 for quite some time commit dbacd67dc33f7b0d5fe64323668cf266d18f4b3f Author: Jiri Kosina <[EMAIL PROTECTED]> Date: Fri Nov 30 11:12:58 2007 +0100 HID: remove redundant WARN_ON()s in order not to scare users The WARN_ON() in implement() and extract() spit out stacktraces and a lot of other information that might make users think that there is something seriously wrong with the system. WARN_ON() should not be deliberately triggerable by userspace application, which these can be. Usually this WARN_ON() triggers when hid2hci utility is sending the data that don't correspond to the device's report descriptor. Convert these messages to more friendly printk(). -- Jiri Kosina -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Top 10 kernel oopses for the week ending January 12th, 2008
On Sun, 13 Jan 2008, Adrian Bunk wrote: Rank 1: implement (hid code) WARN_ON at drivers/hid/hid-core.c:784 Reported 23 times (39 total reports) This appears to be the kernel doing a WARN_ON based on unexpected ioctl() arguments More info: http://www.kerneloops.org/search.php?search=implement ... The only complete bug reports seems to be from one user who loaded a module whose distribution might be considered a criminal act in some countries. The most usual case is hid2hci utility, that tries to switch modes on Bluetooth HID peripherials (via hiddev). When these switching packets are not compliant with HID report descriptor of the device, this WARN_ON() happens. Unfortunately there is no standard specifying how these packets should look like, so it is guess-game and some rev-eng, that Marcel has put into hid2hci for individual vendors, and sometimes this just happens not to work. I have had the commit below queued in my tree for 2.6.25 for quite some time commit dbacd67dc33f7b0d5fe64323668cf266d18f4b3f Author: Jiri Kosina [EMAIL PROTECTED] Date: Fri Nov 30 11:12:58 2007 +0100 HID: remove redundant WARN_ON()s in order not to scare users The WARN_ON() in implement() and extract() spit out stacktraces and a lot of other information that might make users think that there is something seriously wrong with the system. WARN_ON() should not be deliberately triggerable by userspace application, which these can be. Usually this WARN_ON() triggers when hid2hci utility is sending the data that don't correspond to the device's report descriptor. Convert these messages to more friendly printk(). -- Jiri Kosina -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Top 10 kernel oopses for the week ending January 12th, 2008
Adrian Bunk wrote: On Sat, Jan 12, 2008 at 03:13:29PM -0800, Arjan van de Ven wrote: Adrian Bunk wrote: All the other reports only contain the plain trace. Is there any way to get more information whether the former is a pattern or not, and to get this information somehow displayed on the webpage? IF the kernel prints that its tainted or whatever it'll be shown, as well as the exact versions etc etc if they are there. Sadly none of this information is there prior to 2.6.24-rc4. ... OK, the problem might actually not be the omission of displaying the tainted information but the omission of considering any relevant context. Looking deeper: Number #2424 is WARN_ON-after-tainted-oops. Is your rank 1 just a symptom that the system is in a bad state after running in what is your rank 8? In this case the information when following e.g. #2827 is quite useless since wherever you got this trace from all related context information like e.g. whether it's like #2424 just the symptom of a previous Oops is not displayed. the tainted flags have a flag for "there was a previous oops", and if that's set, the kerneloops.org website ignores the report. Simple as that. In the worst case, an entry might only contain WARN_ON traces without any information where the traces came from and whether it's worth looking at them or whether the system always already was in a known-bad state when they occured? again as of 2.6.24-rc4 or so, this is just no longer the case. The problem is with older kernels which had a WARN_ON() that didn't print ANY information other than a plain backtrace. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Top 10 kernel oopses for the week ending January 12th, 2008
On Sat, Jan 12, 2008 at 03:13:29PM -0800, Arjan van de Ven wrote: > Adrian Bunk wrote: >> >> All the other reports only contain the plain trace. Is there any way to >> get more information whether the former is a pattern or not, and to >> get this information somehow displayed on the webpage? > > IF the kernel prints that its tainted or whatever it'll be shown, as well > as the exact versions etc etc if they are there. > Sadly none of this information is there prior to 2.6.24-rc4. >... OK, the problem might actually not be the omission of displaying the tainted information but the omission of considering any relevant context. Looking deeper: Number #2424 is WARN_ON-after-tainted-oops. Is your rank 1 just a symptom that the system is in a bad state after running in what is your rank 8? In this case the information when following e.g. #2827 is quite useless since wherever you got this trace from all related context information like e.g. whether it's like #2424 just the symptom of a previous Oops is not displayed. In the worst case, an entry might only contain WARN_ON traces without any information where the traces came from and whether it's worth looking at them or whether the system always already was in a known-bad state when they occured? cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Top 10 kernel oopses for the week ending January 12th, 2008
Adrian Bunk wrote: All the other reports only contain the plain trace. Is there any way to get more information whether the former is a pattern or not, and to get this information somehow displayed on the webpage? IF the kernel prints that its tainted or whatever it'll be shown, as well as the exact versions etc etc if they are there. Sadly none of this information is there prior to 2.6.24-rc4. (I wonder if the patch to print this should be put in -stable ;-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Top 10 kernel oopses for the week ending January 12th, 2008
On Sat, Jan 12, 2008 at 10:48:05AM -0800, Arjan van de Ven wrote: > The http://www.kerneloops.org website collects kernel oops and > warning reports from various mailing lists and bugzillas as well as > with a client users can install to auto-submit oopses. > Below is a top 10 list of the oopses collected in the last 7 days. > (Reports prior to 2.6.23 have been omitted in collecting the top 10) > > This week, a total of 136 oopses and warnings have been reported, > compared to 46 reports in the previous 7 days. > > kerneloops.org news: > * Based on feedback from last weeks report, the website now tries > to also present a disassembled Code: line > * the kerneloops collection client is now part of Fedora (rawhide) > (yum install kerneloops) > * the kerneloops collection client is now included in Debian testing > (apt-get install kerneloops) > * gentoo has received an updated version of the client > > > Rank 1: implement (hid code) > WARN_ON at drivers/hid/hid-core.c:784 > Reported 23 times (39 total reports) > This appears to be the kernel doing a WARN_ON based on unexpected > ioctl() arguments > More info: http://www.kerneloops.org/search.php?search=implement >... The only complete bug reports seems to be from one user who loaded a module whose distribution might be considered a criminal act in some countries. All the other reports only contain the plain trace. Is there any way to get more information whether the former is a pattern or not, and to get this information somehow displayed on the webpage? cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Top 10 kernel oopses for the week ending January 12th, 2008
Adrian Bunk wrote: All the other reports only contain the plain trace. Is there any way to get more information whether the former is a pattern or not, and to get this information somehow displayed on the webpage? IF the kernel prints that its tainted or whatever it'll be shown, as well as the exact versions etc etc if they are there. Sadly none of this information is there prior to 2.6.24-rc4. (I wonder if the patch to print this should be put in -stable ;-) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Top 10 kernel oopses for the week ending January 12th, 2008
On Sat, Jan 12, 2008 at 03:13:29PM -0800, Arjan van de Ven wrote: Adrian Bunk wrote: All the other reports only contain the plain trace. Is there any way to get more information whether the former is a pattern or not, and to get this information somehow displayed on the webpage? IF the kernel prints that its tainted or whatever it'll be shown, as well as the exact versions etc etc if they are there. Sadly none of this information is there prior to 2.6.24-rc4. ... OK, the problem might actually not be the omission of displaying the tainted information but the omission of considering any relevant context. Looking deeper: Number #2424 is WARN_ON-after-tainted-oops. Is your rank 1 just a symptom that the system is in a bad state after running in what is your rank 8? In this case the information when following e.g. #2827 is quite useless since wherever you got this trace from all related context information like e.g. whether it's like #2424 just the symptom of a previous Oops is not displayed. In the worst case, an entry might only contain WARN_ON traces without any information where the traces came from and whether it's worth looking at them or whether the system always already was in a known-bad state when they occured? cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
