[PATCH] HID: corsair: Add support for the GLAIVE RGB gaming mouse
This mouse sold by Corsair as the GLAIVE RGB gaming mouse has the same
problem with its HID reports as the Scimitar PRO RGB, so reuse the
same fix for the GLAIVE RGB.
Signed-off-by: Guus Sliepen <g...@sliepen.org>
---
drivers/hid/hid-corsair.c | 16 ++--
drivers/hid/hid-ids.h | 1 +
drivers/hid/hid-quirks.c | 2 ++
3 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/drivers/hid/hid-corsair.c b/drivers/hid/hid-corsair.c
index 9ba5d98a1..6c9c8fe1b 100644
--- a/drivers/hid/hid-corsair.c
+++ b/drivers/hid/hid-corsair.c
@@ -673,7 +673,7 @@ static int corsair_input_mapping(struct hid_device *dev,
}
/*
- * The report descriptor of Corsair Scimitar RGB Pro gaming mouse is
+ * The report descriptor of some of the Corsair gaming mice is
* non parseable as they define two consecutive Logical Minimum for
* the Usage Page (Consumer) in rdescs bytes 75 and 77 being 77 0x16
* that should be obviousy 0x26 for Logical Magimum of 16 bits. This
@@ -681,7 +681,8 @@ static int corsair_input_mapping(struct hid_device *dev,
* Minimum being larger than Logical Maximum.
*
* This driver fixes the report descriptor for:
- * - USB ID b1c:1b3e, sold as Scimitar RGB Pro Gaming mouse
+ * - USB ID 1b1c:1b34, sold as GLAIVE RGB Gaming mouse
+ * - USB ID 1b1c:1b3e, sold as Scimitar RGB Pro Gaming mouse
*/
static __u8 *corsair_mouse_report_fixup(struct hid_device *hdev, __u8 *rdesc,
@@ -691,13 +692,14 @@ static __u8 *corsair_mouse_report_fixup(struct hid_device
*hdev, __u8 *rdesc,
if (intf->cur_altsetting->desc.bInterfaceNumber == 1) {
/*
-* Corsair Scimitar RGB Pro report descriptor is broken and
-* defines two different Logical Minimum for the Consumer
-* Application. The byte 77 should be a 0x26 defining a 16
-* bits integer for the Logical Maximum but it is a 0x16
+* Corsair GLAIVE RGB and Scimitar RGB Pro report descriptor is
+* broken and defines two different Logical Minimum for the
+* Consumer Application. The byte 77 should be a 0x26 defining
+* a 16 bits integer for the Logical Maximum but it is a 0x16
* instead (Logical Minimum)
*/
switch (hdev->product) {
+ case USB_DEVICE_ID_CORSAIR_GLAIVE_RGB:
case USB_DEVICE_ID_CORSAIR_SCIMITAR_PRO_RGB:
if (*rsize >= 172 && rdesc[75] == 0x15 && rdesc[77] ==
0x16
&& rdesc[78] == 0xff && rdesc[79] == 0x0f) {
@@ -715,6 +717,8 @@ static const struct hid_device_id corsair_devices[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_CORSAIR, USB_DEVICE_ID_CORSAIR_K90),
.driver_data = CORSAIR_USE_K90_MACRO |
CORSAIR_USE_K90_BACKLIGHT },
+ { HID_USB_DEVICE(USB_VENDOR_ID_CORSAIR,
+USB_DEVICE_ID_CORSAIR_GLAIVE_RGB) },
{ HID_USB_DEVICE(USB_VENDOR_ID_CORSAIR,
USB_DEVICE_ID_CORSAIR_SCIMITAR_PRO_RGB) },
{}
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 43ddcdfbd..a099e5194 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -291,6 +291,7 @@
#define USB_DEVICE_ID_CORSAIR_K70RGB0x1b13
#define USB_DEVICE_ID_CORSAIR_STRAFE0x1b15
#define USB_DEVICE_ID_CORSAIR_K65RGB0x1b17
+#define USB_DEVICE_ID_CORSAIR_GLAIVE_RGB0x1b34
#define USB_DEVICE_ID_CORSAIR_K70RGB_RAPIDFIRE 0x1b38
#define USB_DEVICE_ID_CORSAIR_K65RGB_RAPIDFIRE 0x1b39
#define USB_DEVICE_ID_CORSAIR_SCIMITAR_PRO_RGB 0x1b3e
diff --git a/drivers/hid/hid-quirks.c b/drivers/hid/hid-quirks.c
index 5f6035a5c..7203eba3c 100644
--- a/drivers/hid/hid-quirks.c
+++ b/drivers/hid/hid-quirks.c
@@ -62,6 +62,7 @@ static const struct hid_device_id hid_quirks[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_CORSAIR, USB_DEVICE_ID_CORSAIR_K70R),
HID_QUIRK_NO_INIT_REPORTS },
{ HID_USB_DEVICE(USB_VENDOR_ID_CORSAIR, USB_DEVICE_ID_CORSAIR_K95RGB),
HID_QUIRK_NO_INIT_REPORTS | HID_QUIRK_ALWAYS_POLL },
{ HID_USB_DEVICE(USB_VENDOR_ID_CORSAIR, USB_DEVICE_ID_CORSAIR_M65RGB),
HID_QUIRK_NO_INIT_REPORTS },
+ { HID_USB_DEVICE(USB_VENDOR_ID_CORSAIR,
USB_DEVICE_ID_CORSAIR_GLAIVE_RGB), HID_QUIRK_NO_INIT_REPORTS |
HID_QUIRK_ALWAYS_POLL },
{ HID_USB_DEVICE(USB_VENDOR_ID_CORSAIR,
USB_DEVICE_ID_CORSAIR_SCIMITAR_PRO_RGB), HID_QUIRK_NO_INIT_REPORTS |
HID_QUIRK_ALWAYS_POLL },
{ HID_USB_DEVICE(USB_VENDOR_ID_CORSAIR, USB_DEVICE_ID_CORSAIR_STRAFE),
HID_QUIRK_NO_INIT_REPORTS | HID_QUIRK_ALWAYS_POLL },
{ HID_USB_DEVICE(USB_VENDOR_ID_CREATIVELABS,
USB_DEVICE_ID_CREATIVE_SB_OMNI_SURROUND_51), HID_QUIRK_NOGET },
@@ -317,6 +318,7 @@ static const struct hid_device_id hid_have_special_driver[]
= {
#endif
#if IS_ENABLED(CONFIG_HID_CORSAIR)
{ HID_USB_DEVICE(USB_VENDOR_ID_CORSAIR, USB_DEVICE_ID_CORSAIR_K90)
[PATCH] HID: corsair: Add support for the GLAIVE RGB gaming mouse
This mouse sold by Corsair as the GLAIVE RGB gaming mouse has the same
problem with its HID reports as the Scimitar PRO RGB, so reuse the
same fix for the GLAIVE RGB.
Signed-off-by: Guus Sliepen
---
drivers/hid/hid-corsair.c | 16 ++--
drivers/hid/hid-ids.h | 1 +
drivers/hid/hid-quirks.c | 2 ++
3 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/drivers/hid/hid-corsair.c b/drivers/hid/hid-corsair.c
index 9ba5d98a1..6c9c8fe1b 100644
--- a/drivers/hid/hid-corsair.c
+++ b/drivers/hid/hid-corsair.c
@@ -673,7 +673,7 @@ static int corsair_input_mapping(struct hid_device *dev,
}
/*
- * The report descriptor of Corsair Scimitar RGB Pro gaming mouse is
+ * The report descriptor of some of the Corsair gaming mice is
* non parseable as they define two consecutive Logical Minimum for
* the Usage Page (Consumer) in rdescs bytes 75 and 77 being 77 0x16
* that should be obviousy 0x26 for Logical Magimum of 16 bits. This
@@ -681,7 +681,8 @@ static int corsair_input_mapping(struct hid_device *dev,
* Minimum being larger than Logical Maximum.
*
* This driver fixes the report descriptor for:
- * - USB ID b1c:1b3e, sold as Scimitar RGB Pro Gaming mouse
+ * - USB ID 1b1c:1b34, sold as GLAIVE RGB Gaming mouse
+ * - USB ID 1b1c:1b3e, sold as Scimitar RGB Pro Gaming mouse
*/
static __u8 *corsair_mouse_report_fixup(struct hid_device *hdev, __u8 *rdesc,
@@ -691,13 +692,14 @@ static __u8 *corsair_mouse_report_fixup(struct hid_device
*hdev, __u8 *rdesc,
if (intf->cur_altsetting->desc.bInterfaceNumber == 1) {
/*
-* Corsair Scimitar RGB Pro report descriptor is broken and
-* defines two different Logical Minimum for the Consumer
-* Application. The byte 77 should be a 0x26 defining a 16
-* bits integer for the Logical Maximum but it is a 0x16
+* Corsair GLAIVE RGB and Scimitar RGB Pro report descriptor is
+* broken and defines two different Logical Minimum for the
+* Consumer Application. The byte 77 should be a 0x26 defining
+* a 16 bits integer for the Logical Maximum but it is a 0x16
* instead (Logical Minimum)
*/
switch (hdev->product) {
+ case USB_DEVICE_ID_CORSAIR_GLAIVE_RGB:
case USB_DEVICE_ID_CORSAIR_SCIMITAR_PRO_RGB:
if (*rsize >= 172 && rdesc[75] == 0x15 && rdesc[77] ==
0x16
&& rdesc[78] == 0xff && rdesc[79] == 0x0f) {
@@ -715,6 +717,8 @@ static const struct hid_device_id corsair_devices[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_CORSAIR, USB_DEVICE_ID_CORSAIR_K90),
.driver_data = CORSAIR_USE_K90_MACRO |
CORSAIR_USE_K90_BACKLIGHT },
+ { HID_USB_DEVICE(USB_VENDOR_ID_CORSAIR,
+USB_DEVICE_ID_CORSAIR_GLAIVE_RGB) },
{ HID_USB_DEVICE(USB_VENDOR_ID_CORSAIR,
USB_DEVICE_ID_CORSAIR_SCIMITAR_PRO_RGB) },
{}
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 43ddcdfbd..a099e5194 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -291,6 +291,7 @@
#define USB_DEVICE_ID_CORSAIR_K70RGB0x1b13
#define USB_DEVICE_ID_CORSAIR_STRAFE0x1b15
#define USB_DEVICE_ID_CORSAIR_K65RGB0x1b17
+#define USB_DEVICE_ID_CORSAIR_GLAIVE_RGB0x1b34
#define USB_DEVICE_ID_CORSAIR_K70RGB_RAPIDFIRE 0x1b38
#define USB_DEVICE_ID_CORSAIR_K65RGB_RAPIDFIRE 0x1b39
#define USB_DEVICE_ID_CORSAIR_SCIMITAR_PRO_RGB 0x1b3e
diff --git a/drivers/hid/hid-quirks.c b/drivers/hid/hid-quirks.c
index 5f6035a5c..7203eba3c 100644
--- a/drivers/hid/hid-quirks.c
+++ b/drivers/hid/hid-quirks.c
@@ -62,6 +62,7 @@ static const struct hid_device_id hid_quirks[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_CORSAIR, USB_DEVICE_ID_CORSAIR_K70R),
HID_QUIRK_NO_INIT_REPORTS },
{ HID_USB_DEVICE(USB_VENDOR_ID_CORSAIR, USB_DEVICE_ID_CORSAIR_K95RGB),
HID_QUIRK_NO_INIT_REPORTS | HID_QUIRK_ALWAYS_POLL },
{ HID_USB_DEVICE(USB_VENDOR_ID_CORSAIR, USB_DEVICE_ID_CORSAIR_M65RGB),
HID_QUIRK_NO_INIT_REPORTS },
+ { HID_USB_DEVICE(USB_VENDOR_ID_CORSAIR,
USB_DEVICE_ID_CORSAIR_GLAIVE_RGB), HID_QUIRK_NO_INIT_REPORTS |
HID_QUIRK_ALWAYS_POLL },
{ HID_USB_DEVICE(USB_VENDOR_ID_CORSAIR,
USB_DEVICE_ID_CORSAIR_SCIMITAR_PRO_RGB), HID_QUIRK_NO_INIT_REPORTS |
HID_QUIRK_ALWAYS_POLL },
{ HID_USB_DEVICE(USB_VENDOR_ID_CORSAIR, USB_DEVICE_ID_CORSAIR_STRAFE),
HID_QUIRK_NO_INIT_REPORTS | HID_QUIRK_ALWAYS_POLL },
{ HID_USB_DEVICE(USB_VENDOR_ID_CREATIVELABS,
USB_DEVICE_ID_CREATIVE_SB_OMNI_SURROUND_51), HID_QUIRK_NOGET },
@@ -317,6 +318,7 @@ static const struct hid_device_id hid_have_special_driver[]
= {
#endif
#if IS_ENABLED(CONFIG_HID_CORSAIR)
{ HID_USB_DEVICE(USB_VENDOR_ID_CORSAIR, USB_DEVICE_ID_CORSAIR_K90) },
+ { HID_USB_DEVICE(USB_VENDOR_I
Looking for ifenslave.c
Hello, The Ethernet bonding module is useless without ifenslave.c. I'm making a Debian package for it, and I have tried to find the "offical" distribution of this small program. I could not find an authorative source, instead a lot of copies and patched versions are scattered around the Internet (I maintain a patched version myself too). I would like to combine all the useful extra features and patches into this Debian package, so if you know of a patched version or maintain one yourself, please send it to me. Thanks, -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> - 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/
Looking for ifenslave.c
Hello, The Ethernet bonding module is useless without ifenslave.c. I'm making a Debian package for it, and I have tried to find the offical distribution of this small program. I could not find an authorative source, instead a lot of copies and patched versions are scattered around the Internet (I maintain a patched version myself too). I would like to combine all the useful extra features and patches into this Debian package, so if you know of a patched version or maintain one yourself, please send it to me. Thanks, -- Met vriendelijke groet / with kind regards, Guus Sliepen [EMAIL PROTECTED] - 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/
Sound sequencer (at least with a GUS card) doesn't honor HZ value
Hello, I've recently started compiling i386 kernels with HZ (and also CLOCKS_PER_SEC) set to 1024 instead of 100 for various reasons. All works perfectly, except when I play mod files with s3mod on my Gravis UltraSound card. The modules are played 10 times too fast: [guus@haplo]~>time s3mod /usr/lib/bb/bb.s3m [...] 98 0 Length :4min 47sec GUS (ALPHA support) Playing "/usr/lib/bb/bb.s3m" Using 498690 of 524254 bytes of GUS RAM 0.814u 0.833s 0:29.95 5.4% 0+0k 0+0io 123pf+0w Kernel version is plain 2.4.4. I've gone through the s3mod sources and did a strace on it, but s3mod itself doesn't handle the timing, it only write()'s stuff to /dev/sequencer, nothing else. This makes me strongly believe the soundcard/sequencer driver itself is wrong here. A quick grep for 100, HZ and CLOCKS didn't yield any useful information, so I guess it's not a trivial problem... P.S.: The change of HZ and CLOCKS_PER_SEC to 1024 is the only change I made. -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> PGP signature
Sound sequencer (at least with a GUS card) doesn't honor HZ value
Hello, I've recently started compiling i386 kernels with HZ (and also CLOCKS_PER_SEC) set to 1024 instead of 100 for various reasons. All works perfectly, except when I play mod files with s3mod on my Gravis UltraSound card. The modules are played 10 times too fast: [guus@haplo]~time s3mod /usr/lib/bb/bb.s3m [...] 98 0 Length :4min 47sec GUS (ALPHA support) Playing /usr/lib/bb/bb.s3m Using 498690 of 524254 bytes of GUS RAM 0.814u 0.833s 0:29.95 5.4% 0+0k 0+0io 123pf+0w Kernel version is plain 2.4.4. I've gone through the s3mod sources and did a strace on it, but s3mod itself doesn't handle the timing, it only write()'s stuff to /dev/sequencer, nothing else. This makes me strongly believe the soundcard/sequencer driver itself is wrong here. A quick grep for 100, HZ and CLOCKS didn't yield any useful information, so I guess it's not a trivial problem... P.S.: The change of HZ and CLOCKS_PER_SEC to 1024 is the only change I made. -- Met vriendelijke groet / with kind regards, Guus Sliepen [EMAIL PROTECTED] PGP signature
Re: #define HZ 1024 -- negative effects?
On Wed, Apr 25, 2001 at 10:02:26PM -0400, Dan Maas wrote: > > Are there any negative effects of editing include/asm/param.h to change > > HZ from 100 to 1024? Or any other number? This has been suggested as a > > way to improve the responsiveness of the GUI on a Linux system. [...] > Of course, the appearance of better interactivity could just be a placebo > effect. Double-blind trials, anyone? =) I tried HZ=1024 on my i386 kernel, to check two things. One was a timer routine. The performance of the timer routine depends heavily on the granularity of the nanosleep() or select() system call. Since those calls always block at least 1/HZ seconds, the timer precision indeed increased by a factor 10 when I changed the HZ value from 100 to 1024. However, another thing I wanted to do was to generate profiling statistics for freesci. Profiling is done with 1/HZ granularity. Any subroutine in a program executed in less than 1/HZ cannot be profiled correctly (for example a routine that executes in 1 nanosecond and one that needs 1/HZ/2 seconds both show up as taking 1 sample). Now, you would think that profiling would be a lot better with HZ=1024. However, the program didn't even run anymore! The reason is that some system calls are being interupted by SIGPROF every 1/HZ, and return something like ERESTARTSYS to the libraries. The libraries then try to restart the system call but a SIGPROF is bound to follow shortly, again interrupting the system call, and so on... --- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> --- See also: http://tinc.nl.linux.org/ http://www.kernelbench.org/ --- PGP signature
Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]
On Sat, Jan 20, 2001 at 10:39:36PM +0300, Alexey Kuznetsov wrote: > Yes. It is cost, which we have to pay. Look into Minshall's draft, > by the way (draft-minshall-nagle-*), it discusses pros and contras. What kind of draft is that? I can't find it on the IETF site. Could you provide me with a link? --- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> --- See also: http://tinc.nl.linux.org/ http://www.kernelbench.org/ --- PGP signature
Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]
On Sat, Jan 20, 2001 at 10:39:36PM +0300, Alexey Kuznetsov wrote: Yes. It is cost, which we have to pay. Look into Minshall's draft, by the way (draft-minshall-nagle-*), it discusses pros and contras. What kind of draft is that? I can't find it on the IETF site. Could you provide me with a link? --- Met vriendelijke groet / with kind regards, Guus Sliepen [EMAIL PROTECTED] --- See also: http://tinc.nl.linux.org/ http://www.kernelbench.org/ --- PGP signature
Re: (iptables) ip_conntrack bug?
On Wed, Nov 15, 2000 at 04:34:50PM -0500, safemode wrote: > On Wed, 15 Nov 2000 16:19:23 Guus Sliepen wrote: > > On Wed, Nov 15, 2000 at 03:46:03PM -0500, safemode wrote: > > > > > I was DDoS'd today while away and came home to find the firewall unable > > to > > > do anything network related (although my connection to irc was still > > > working oddly). a quick dmesg showed the problem. > > > ip_conntrack: maximum limit of 2048 entries exceeded > > [...] > > > > I have also seen this happen on a box which ran test9. Apparently because > > of > > it's long uptime, because the logs should no signs of an attack. safemode and I discussed this and we tried to find an answer in the kernel source. However, the chain of called functions is too long to determine where exactly the problem is. But most likely, because init_conntrack() can fail (because it cannot free an entry, which is either because netfilter does not dare to throw out entries with large timeouts (tcp connections have ridiculous long timeouts btw, almost 2.3 days?!) or because IPS_CONFIRMED is not set), and this failure is propagating back all the way to the tcp code, so that no new sockets can be opened. From our point of view, the conntrack stuff should be totally transparent to the tcp/ip stack. Since this allows for a DoS attack, might be wise to fix this before 2.4 comes out... ------- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> --- See also: http://tinc.nl.linux.org/ http://www.kernelbench.org/ --- PGP signature
Re: (iptables) ip_conntrack bug?
On Wed, Nov 15, 2000 at 03:46:03PM -0500, safemode wrote: > I was DDoS'd today while away and came home to find the firewall unable to > do anything network related (although my connection to irc was still > working oddly). a quick dmesg showed the problem. > ip_conntrack: maximum limit of 2048 entries exceeded [...] I have also seen this happen on a box which ran test9. Apparently because of it's long uptime, because the logs should no signs of an attack. I guess conntrack forgets to flush some entries? Or maybe there is no way it can recover from a full conntrack table? Is it maybe necessary to make the maximum size a configurable option? Or a userspace conntrack daemon like the arpd? I also see a lot of messages like this (on all 2.4 test kernels): NAT: 0 dropping untracked packet c00643f0 1 131.211.122.89 -> 224.0.0.2 NAT: 0 dropping untracked packet c05468e0 1 131.211.122.89 -> 224.0.0.2 NAT: 0 dropping untracked packet c0064760 1 131.211.122.31 -> 224.0.0.2 Turning of multicast on the respective network interface does not stop these messages, but anyway they seem rather annoying to me :) --- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> --- See also: http://tinc.nl.linux.org/ http://www.kernelbench.org/ --- PGP signature
Re: (iptables) ip_conntrack bug?
On Wed, Nov 15, 2000 at 03:46:03PM -0500, safemode wrote: I was DDoS'd today while away and came home to find the firewall unable to do anything network related (although my connection to irc was still working oddly). a quick dmesg showed the problem. ip_conntrack: maximum limit of 2048 entries exceeded [...] I have also seen this happen on a box which ran test9. Apparently because of it's long uptime, because the logs should no signs of an attack. I guess conntrack forgets to flush some entries? Or maybe there is no way it can recover from a full conntrack table? Is it maybe necessary to make the maximum size a configurable option? Or a userspace conntrack daemon like the arpd? I also see a lot of messages like this (on all 2.4 test kernels): NAT: 0 dropping untracked packet c00643f0 1 131.211.122.89 - 224.0.0.2 NAT: 0 dropping untracked packet c05468e0 1 131.211.122.89 - 224.0.0.2 NAT: 0 dropping untracked packet c0064760 1 131.211.122.31 - 224.0.0.2 Turning of multicast on the respective network interface does not stop these messages, but anyway they seem rather annoying to me :) --- Met vriendelijke groet / with kind regards, Guus Sliepen [EMAIL PROTECTED] --- See also: http://tinc.nl.linux.org/ http://www.kernelbench.org/ --- PGP signature
Re: (iptables) ip_conntrack bug?
On Wed, Nov 15, 2000 at 04:34:50PM -0500, safemode wrote: On Wed, 15 Nov 2000 16:19:23 Guus Sliepen wrote: On Wed, Nov 15, 2000 at 03:46:03PM -0500, safemode wrote: I was DDoS'd today while away and came home to find the firewall unable to do anything network related (although my connection to irc was still working oddly). a quick dmesg showed the problem. ip_conntrack: maximum limit of 2048 entries exceeded [...] I have also seen this happen on a box which ran test9. Apparently because of it's long uptime, because the logs should no signs of an attack. safemode and I discussed this and we tried to find an answer in the kernel source. However, the chain of called functions is too long to determine where exactly the problem is. But most likely, because init_conntrack() can fail (because it cannot free an entry, which is either because netfilter does not dare to throw out entries with large timeouts (tcp connections have ridiculous long timeouts btw, almost 2.3 days?!) or because IPS_CONFIRMED is not set), and this failure is propagating back all the way to the tcp code, so that no new sockets can be opened. From our point of view, the conntrack stuff should be totally transparent to the tcp/ip stack. Since this allows for a DoS attack, might be wise to fix this before 2.4 comes out... --- Met vriendelijke groet / with kind regards, Guus Sliepen [EMAIL PROTECTED] --- See also: http://tinc.nl.linux.org/ http://www.kernelbench.org/ --- PGP signature
Oops with >= 2.4.0-test7 when modprobing gus module
Hello, Whenever I modprobe the gus module the kernel gives an oops: Gravis Ultrasound audio driver Copyright (C) by Hannu Savolainen 1993-1996 at 0x240 irq 3 dma 1,5 Unable to handle kernel NULL pointer dereference at virtual address The module is loaded after that, and the soundcard is functioning as it should. However, the refcount of the module is all wrong and it can't be removed anymore. The full oops (processed by ksymoops) is attached. --- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> --- See also: http://tinc.nl.linux.org/ http://www.kernelbench.org/ --- ksymoops 2.3.4 on i586 2.4.0-test8. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.0-test8/ (default) -m /System.map (specified) Unable to handle kernel NULL pointer dereference at virtual address c486321b *pde = Oops: CPU:0 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010212 eax: ebx: c37c64a0 ecx: c486f8b8 edx: 0040 esi: c11f14a0 edi: c36a1240 ebp: c379fee0 esp: c360df4c ds: 0018 es: 0018 ss: 0018 Process aumix (pid: 95, stackpage=c360d000) Stack: c012acd8 c36a1240 c37c64a0 c37c64a0 c3688060 0001 c012ae82 c37c64a0 c0129ec1 c37c64a0 c3688060 0009 c0117268 c37c64a0 c3688060 c11db6c0 c360c000 bd5c c3688180 c01177ea c3688060 Call Trace: [] [] [] [] [] [] [] Code: 8b 00 85 c0 74 4d ff 48 10 8b 04 0a 8b 00 80 48 14 08 eb 3f >>EIP; c486321b <[sound]sound_release+2b/84> <= Trace; c012acd8 <_fput+2c/c0> Trace; c012ae82 Trace; c0129ec1 Trace; c0117268 Trace; c01177ea Trace; c0117e76 Trace; c0108d63 Code; c486321b <[sound]sound_release+2b/84> <_EIP>: Code; c486321b <[sound]sound_release+2b/84> <= 0: 8b 00 mov(%eax),%eax <= Code; c486321d <[sound]sound_release+2d/84> 2: 85 c0 test %eax,%eax Code; c486321f <[sound]sound_release+2f/84> 4: 74 4d je 53 <_EIP+0x53> c486326e <[sound]sound_release+7e/84> Code; c4863221 <[sound]sound_release+31/84> 6: ff 48 10 decl 0x10(%eax) Code; c4863224 <[sound]sound_release+34/84> 9: 8b 04 0a mov(%edx,%ecx,1),%eax Code; c4863227 <[sound]sound_release+37/84> c: 8b 00 mov(%eax),%eax Code; c4863229 <[sound]sound_release+39/84> e: 80 48 14 08 orb$0x8,0x14(%eax) Code; c486322d <[sound]sound_release+3d/84> 12: eb 3f jmp53 <_EIP+0x53> c486326e <[sound]sound_release+7e/84>
Oops with = 2.4.0-test7 when modprobing gus module
Hello, Whenever I modprobe the gus module the kernel gives an oops: Gravis Ultrasound audio driver Copyright (C) by Hannu Savolainen 1993-1996 Gravis UltraSound 3.7 (512k) at 0x240 irq 3 dma 1,5 Unable to handle kernel NULL pointer dereference at virtual address The module is loaded after that, and the soundcard is functioning as it should. However, the refcount of the module is all wrong and it can't be removed anymore. The full oops (processed by ksymoops) is attached. --- Met vriendelijke groet / with kind regards, Guus Sliepen [EMAIL PROTECTED] --- See also: http://tinc.nl.linux.org/ http://www.kernelbench.org/ --- ksymoops 2.3.4 on i586 2.4.0-test8. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.0-test8/ (default) -m /System.map (specified) Unable to handle kernel NULL pointer dereference at virtual address c486321b *pde = Oops: CPU:0 EIP:0010:[c486321b] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010212 eax: ebx: c37c64a0 ecx: c486f8b8 edx: 0040 esi: c11f14a0 edi: c36a1240 ebp: c379fee0 esp: c360df4c ds: 0018 es: 0018 ss: 0018 Process aumix (pid: 95, stackpage=c360d000) Stack: c012acd8 c36a1240 c37c64a0 c37c64a0 c3688060 0001 c012ae82 c37c64a0 c0129ec1 c37c64a0 c3688060 0009 c0117268 c37c64a0 c3688060 c11db6c0 c360c000 bd5c c3688180 c01177ea c3688060 Call Trace: [c012acd8] [c012ae82] [c0129ec1] [c0117268] [c01177ea] [c0117e76] [c0108d63] Code: 8b 00 85 c0 74 4d ff 48 10 8b 04 0a 8b 00 80 48 14 08 eb 3f EIP; c486321b [sound]sound_release+2b/84 = Trace; c012acd8 _fput+2c/c0 Trace; c012ae82 fput+12/18 Trace; c0129ec1 filp_close+51/5c Trace; c0117268 put_files_struct+54/b8 Trace; c01177ea do_exit+c2/1fc Trace; c0117e76 sys_exit+e/10 Trace; c0108d63 system_call+33/40 Code; c486321b [sound]sound_release+2b/84 _EIP: Code; c486321b [sound]sound_release+2b/84 = 0: 8b 00 mov(%eax),%eax = Code; c486321d [sound]sound_release+2d/84 2: 85 c0 test %eax,%eax Code; c486321f [sound]sound_release+2f/84 4: 74 4d je 53 _EIP+0x53 c486326e [sound]sound_release+7e/84 Code; c4863221 [sound]sound_release+31/84 6: ff 48 10 decl 0x10(%eax) Code; c4863224 [sound]sound_release+34/84 9: 8b 04 0a mov(%edx,%ecx,1),%eax Code; c4863227 [sound]sound_release+37/84 c: 8b 00 mov(%eax),%eax Code; c4863229 [sound]sound_release+39/84 e: 80 48 14 08 orb$0x8,0x14(%eax) Code; c486322d [sound]sound_release+3d/84 12: eb 3f jmp53 _EIP+0x53 c486326e [sound]sound_release+7e/84
