[PATCH] nozomi DTR/RTS
Hi,
I noticed that DTR toggling doesn't work with the nozomi driver
(TIOCMBIS/TIOCMBIC ioctls have no effect). This is a nuisance because
that makes it hard to get the modem back in command mode.
Attached patch adds a tty_ops->tiocmset function that makes it work.
Should we also rip out the TIOCMBIS/TIOCMBIC handling in ntty_ioctl()?
It doesn't seem to be used anyway.
Patch is against 2.6.23-rc3-mm1, but not tested with that. I tested it
with 2.6.18.4 and the pharscape.org driver.
Eric
--- linux-2.6.23-rc3-mm1/drivers/char/nozomi.c.orig 2007-08-24
05:39:06.0 -0400
+++ linux-2.6.23-rc3-mm1/drivers/char/nozomi.c 2007-08-24 05:41:07.0
-0400
@@ -1930,12 +1930,16 @@
}
/* Sets io controls parameters */
-static int ntty_tiocmset(struct tty_struct *tty, struct file *file, u32 arg)
+static int ntty_tiocmset(struct tty_struct *tty, struct file *file,
+ unsigned int set, unsigned int clear)
{
struct port *port = (struct port *)tty->driver_data;
- set_rts(port->tty_index, (arg & TIOCM_RTS) ? 1 : 0);
- set_dtr(port->tty_index, (arg & TIOCM_DTR) ? 1 : 0);
+ if(set & TIOCM_RTS) set_rts(port->tty_index, 1);
+ else if(clear & TIOCM_RTS) set_rts(port->tty_index, 0);
+
+ if(set & TIOCM_DTR) set_dtr(port->tty_index, 1);
+ else if(clear & TIOCM_DTR) set_dtr(port->tty_index, 0);
return 0;
}
@@ -2039,7 +2043,7 @@
spin_unlock_irqrestore(>spin_mutex, flags);
break;
case TIOCMSET:
- rval = ntty_tiocmset(tty, file, arg);
+ rval = ntty_tiocmset(tty, file, arg, ~arg);
break;
case TIOCMBIC:
if (get_user(mask, (unsigned long __user *)arg))
@@ -2152,6 +2156,7 @@
.set_termios = ntty_set_termios,
.chars_in_buffer = ntty_chars_in_buffer,
.put_char = ntty_put_char,
+ .tiocmset = ntty_tiocmset,
};
/* Initializes the tty */
[PATCH] nozomi DTR/RTS
Hi,
I noticed that DTR toggling doesn't work with the nozomi driver
(TIOCMBIS/TIOCMBIC ioctls have no effect). This is a nuisance because
that makes it hard to get the modem back in command mode.
Attached patch adds a tty_ops-tiocmset function that makes it work.
Should we also rip out the TIOCMBIS/TIOCMBIC handling in ntty_ioctl()?
It doesn't seem to be used anyway.
Patch is against 2.6.23-rc3-mm1, but not tested with that. I tested it
with 2.6.18.4 and the pharscape.org driver.
Eric
--- linux-2.6.23-rc3-mm1/drivers/char/nozomi.c.orig 2007-08-24
05:39:06.0 -0400
+++ linux-2.6.23-rc3-mm1/drivers/char/nozomi.c 2007-08-24 05:41:07.0
-0400
@@ -1930,12 +1930,16 @@
}
/* Sets io controls parameters */
-static int ntty_tiocmset(struct tty_struct *tty, struct file *file, u32 arg)
+static int ntty_tiocmset(struct tty_struct *tty, struct file *file,
+ unsigned int set, unsigned int clear)
{
struct port *port = (struct port *)tty-driver_data;
- set_rts(port-tty_index, (arg TIOCM_RTS) ? 1 : 0);
- set_dtr(port-tty_index, (arg TIOCM_DTR) ? 1 : 0);
+ if(set TIOCM_RTS) set_rts(port-tty_index, 1);
+ else if(clear TIOCM_RTS) set_rts(port-tty_index, 0);
+
+ if(set TIOCM_DTR) set_dtr(port-tty_index, 1);
+ else if(clear TIOCM_DTR) set_dtr(port-tty_index, 0);
return 0;
}
@@ -2039,7 +2043,7 @@
spin_unlock_irqrestore(dc-spin_mutex, flags);
break;
case TIOCMSET:
- rval = ntty_tiocmset(tty, file, arg);
+ rval = ntty_tiocmset(tty, file, arg, ~arg);
break;
case TIOCMBIC:
if (get_user(mask, (unsigned long __user *)arg))
@@ -2152,6 +2156,7 @@
.set_termios = ntty_set_termios,
.chars_in_buffer = ntty_chars_in_buffer,
.put_char = ntty_put_char,
+ .tiocmset = ntty_tiocmset,
};
/* Initializes the tty */
Re: Slowdown with randomize_va_space in 2.6.12.2
On Thu, 7 Jul 2005, Arjan van de Ven wrote: > On Wed, 2005-07-06 at 18:12 -0700, Andrew Morton wrote: > > Dave Jones <[EMAIL PROTECTED]> wrote: > > > On Transmeta CPUs that probably triggers a retranslation of > > > x86->native bytecode, if it thinks it hasn't seen code at that > > > address before. > > > > ouch. What do we do? Default to off? Default to off on xmeta? > > off-on-xmeta would be my preference; I'll cook up a patch for that. It would be nice if a fix for this could get in before 2.6.13 comes out. What about this patch? cheers, Eric --- linux-2.6.13-rc4/arch/i386/kernel/cpu/transmeta.c.orig 2005-06-17 15:48:29.0 -0400 +++ linux-2.6.13-rc4/arch/i386/kernel/cpu/transmeta.c 2005-07-29 20:46:54.0 -0400 @@ -76,6 +76,10 @@ #define USER686 (X86_FEATURE_TSC|X86_FEATURE_CX8|X86_FEATURE_CMOV) if ( c->x86 == 5 && (c->x86_capability[0] & USER686) == USER686 ) c->x86 = 6; + + /* randomize_va_space slows us down enormously; + it probably triggers retranslation of x86->native bytecode */ + randomize_va_space = 0; } static void transmeta_identify(struct cpuinfo_x86 * c) - 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: Slowdown with randomize_va_space in 2.6.12.2
On Thu, 7 Jul 2005, Arjan van de Ven wrote: On Wed, 2005-07-06 at 18:12 -0700, Andrew Morton wrote: Dave Jones [EMAIL PROTECTED] wrote: On Transmeta CPUs that probably triggers a retranslation of x86-native bytecode, if it thinks it hasn't seen code at that address before. ouch. What do we do? Default to off? Default to off on xmeta? off-on-xmeta would be my preference; I'll cook up a patch for that. It would be nice if a fix for this could get in before 2.6.13 comes out. What about this patch? cheers, Eric --- linux-2.6.13-rc4/arch/i386/kernel/cpu/transmeta.c.orig 2005-06-17 15:48:29.0 -0400 +++ linux-2.6.13-rc4/arch/i386/kernel/cpu/transmeta.c 2005-07-29 20:46:54.0 -0400 @@ -76,6 +76,10 @@ #define USER686 (X86_FEATURE_TSC|X86_FEATURE_CX8|X86_FEATURE_CMOV) if ( c-x86 == 5 (c-x86_capability[0] USER686) == USER686 ) c-x86 = 6; + + /* randomize_va_space slows us down enormously; + it probably triggers retranslation of x86-native bytecode */ + randomize_va_space = 0; } static void transmeta_identify(struct cpuinfo_x86 * c) - 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: Booting from USB with initrd
gabriel wrote: Hi Im trying to boot an encrypted file system using an initrd on a USB. I use syslinux for the actual boot process as I couldnt get Grub to boot of it for some reason. This is the .cfg append initrd=/initrd.gz root=/dev/ram0 rootfstype=minix init=/linuxrc I don't think syslinux digs the "/" in the initrd filename. Did you try it with initrd=initrd.gz? Eric - 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: Booting from USB with initrd
gabriel wrote: Hi Im trying to boot an encrypted file system using an initrd on a USB. I use syslinux for the actual boot process as I couldnt get Grub to boot of it for some reason. This is the .cfg append initrd=/initrd.gz root=/dev/ram0 rootfstype=minix init=/linuxrc I don't think syslinux digs the / in the initrd filename. Did you try it with initrd=initrd.gz? Eric - 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/
[PATCH] cramfs: small stat(2) fix
Hi,
When I stat(2) a device node on a cramfs, the st_blocks field is
bogus (it's derived from the size field which in this case holds the
major/minor numbers). This makes du(1) output completely wrong.
Please apply the patch below.
Eric
Signed-off-by: Eric Lammerts <[EMAIL PROTECTED]>
--- linux-2.6.11-rc5/fs/cramfs/inode.c.orig 2005-03-01 11:10:29.0
-0500
+++ linux-2.6.11-rc5/fs/cramfs/inode.c 2005-03-01 11:10:36.0 -0500
@@ -70,6 +70,7 @@
inode->i_data.a_ops = _aops;
} else {
inode->i_size = 0;
+ inode->i_blocks = 0;
init_special_inode(inode, inode->i_mode,
old_decode_dev(cramfs_inode->size));
}
-
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/
[PATCH] cramfs: small stat(2) fix
Hi,
When I stat(2) a device node on a cramfs, the st_blocks field is
bogus (it's derived from the size field which in this case holds the
major/minor numbers). This makes du(1) output completely wrong.
Please apply the patch below.
Eric
Signed-off-by: Eric Lammerts [EMAIL PROTECTED]
--- linux-2.6.11-rc5/fs/cramfs/inode.c.orig 2005-03-01 11:10:29.0
-0500
+++ linux-2.6.11-rc5/fs/cramfs/inode.c 2005-03-01 11:10:36.0 -0500
@@ -70,6 +70,7 @@
inode-i_data.a_ops = cramfs_aops;
} else {
inode-i_size = 0;
+ inode-i_blocks = 0;
init_special_inode(inode, inode-i_mode,
old_decode_dev(cramfs_inode-size));
}
-
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/
[PATCH] Fix SAA7134 transport stream errors
Hi,
I had a lot of problems with the transport stream input on the
SAA7134. Even the slighest bit of other system activity caused data
corruption. This patch corrects the switching of the two DMA
buffers.
Without the patch, the driver updates the buffer that is just about to
be used by the chip. It still works, but only if no new TS packet
comes in before the registers are updated (in my case there's
typically ~500us between TS packets).
FYI, the problems only occur on Transmeta TM5800/TM5400 Crusoe boards
(1GHz/533MHz). When I move the SAA7134 board to a 400MHz Celeron, no
problems at all. I measured the interrupt latency of the SAA7134
interrupt on the Crusoe, and that peaks to >1000us when power
management is enabled and other activity (IDE DMA) is taking place!!
That may explain why other people haven't seen this problem.
Question for lkml: are interrupt latencies supposed to be like that on
Crusoe systems, or is there something wrong with my boards? Booting
with no-hlt acpi=off apm=off, setting the cpufreq governor to
performance, or running a reniced "while :; do :; done" in the
background all seem to help quite a bit, but it doesn't eliminate the
problem completely.
Eric
--- video4linux/saa7134-ts.c.orig 2004-12-10 08:07:00.0 -0500
+++ video4linux/saa7134-ts.c2005-02-01 18:58:50.0 -0500
@@ -221,10 +221,10 @@
if (dev->ts_q.curr) {
field = dev->ts_q.curr->vb.field;
if (field == V4L2_FIELD_TOP) {
- if ((status & 0x10) != 0x10)
+ if ((status & 0x10) == 0x10)
goto done;
} else {
- if ((status & 0x10) != 0x00)
+ if ((status & 0x10) == 0x00)
goto done;
}
saa7134_buffer_finish(dev,>ts_q,STATE_DONE);
-
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/
[PATCH] Fix SAA7134 transport stream errors
Hi,
I had a lot of problems with the transport stream input on the
SAA7134. Even the slighest bit of other system activity caused data
corruption. This patch corrects the switching of the two DMA
buffers.
Without the patch, the driver updates the buffer that is just about to
be used by the chip. It still works, but only if no new TS packet
comes in before the registers are updated (in my case there's
typically ~500us between TS packets).
FYI, the problems only occur on Transmeta TM5800/TM5400 Crusoe boards
(1GHz/533MHz). When I move the SAA7134 board to a 400MHz Celeron, no
problems at all. I measured the interrupt latency of the SAA7134
interrupt on the Crusoe, and that peaks to 1000us when power
management is enabled and other activity (IDE DMA) is taking place!!
That may explain why other people haven't seen this problem.
Question for lkml: are interrupt latencies supposed to be like that on
Crusoe systems, or is there something wrong with my boards? Booting
with no-hlt acpi=off apm=off, setting the cpufreq governor to
performance, or running a reniced while :; do :; done in the
background all seem to help quite a bit, but it doesn't eliminate the
problem completely.
Eric
--- video4linux/saa7134-ts.c.orig 2004-12-10 08:07:00.0 -0500
+++ video4linux/saa7134-ts.c2005-02-01 18:58:50.0 -0500
@@ -221,10 +221,10 @@
if (dev-ts_q.curr) {
field = dev-ts_q.curr-vb.field;
if (field == V4L2_FIELD_TOP) {
- if ((status 0x10) != 0x10)
+ if ((status 0x10) == 0x10)
goto done;
} else {
- if ((status 0x10) != 0x00)
+ if ((status 0x10) == 0x00)
goto done;
}
saa7134_buffer_finish(dev,dev-ts_q,STATE_DONE);
-
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/
[PATCH] ext3: commit superblock before panicking
Hi,
I have a problem with errors=panic on ext3. When a panic occurs, the
error event is not recorded anywhere. So after the reboot, e2fsck
doesn't kick in, the file system gets mounted again and the box panics
again...
Patch below moves the ERRORS_PANIC test down a bit so the journal is
aborted before panic() is called.
Eric
Signed-off-by: Eric Lammerts <[EMAIL PROTECTED]>
--- linux-2.6.10/fs/ext3/super.c.orig 2005-01-18 15:07:47.673128436 -0500
+++ linux-2.6.10/fs/ext3/super.c2005-01-18 15:43:55.311501654 -0500
@@ -143,9 +143,6 @@
if (sb->s_flags & MS_RDONLY)
return;
- if (test_opt (sb, ERRORS_PANIC))
- panic ("EXT3-fs (device %s): panic forced after error\n",
- sb->s_id);
if (test_opt (sb, ERRORS_RO)) {
printk (KERN_CRIT "Remounting filesystem read-only\n");
sb->s_flags |= MS_RDONLY;
@@ -156,6 +153,9 @@
if (journal)
journal_abort(journal, -EIO);
}
+ if (test_opt (sb, ERRORS_PANIC))
+ panic ("EXT3-fs (device %s): panic forced after error\n",
+ sb->s_id);
ext3_commit_super(sb, es, 1);
}
-
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/
[PATCH] ext3: commit superblock before panicking
Hi,
I have a problem with errors=panic on ext3. When a panic occurs, the
error event is not recorded anywhere. So after the reboot, e2fsck
doesn't kick in, the file system gets mounted again and the box panics
again...
Patch below moves the ERRORS_PANIC test down a bit so the journal is
aborted before panic() is called.
Eric
Signed-off-by: Eric Lammerts [EMAIL PROTECTED]
--- linux-2.6.10/fs/ext3/super.c.orig 2005-01-18 15:07:47.673128436 -0500
+++ linux-2.6.10/fs/ext3/super.c2005-01-18 15:43:55.311501654 -0500
@@ -143,9 +143,6 @@
if (sb-s_flags MS_RDONLY)
return;
- if (test_opt (sb, ERRORS_PANIC))
- panic (EXT3-fs (device %s): panic forced after error\n,
- sb-s_id);
if (test_opt (sb, ERRORS_RO)) {
printk (KERN_CRIT Remounting filesystem read-only\n);
sb-s_flags |= MS_RDONLY;
@@ -156,6 +153,9 @@
if (journal)
journal_abort(journal, -EIO);
}
+ if (test_opt (sb, ERRORS_PANIC))
+ panic (EXT3-fs (device %s): panic forced after error\n,
+ sb-s_id);
ext3_commit_super(sb, es, 1);
}
-
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: [PATCH] add kmalloc check in drviers/pcmcia/rsrc_mgr.c (245-ac16)
On Sun, 24 Jun 2001, Rasmus Andersen wrote: > On Sun, Jun 24, 2001 at 10:52:31PM +0200, Eric Lammerts wrote: > [...] > > There are zillions of functions called 'init_module' in the kernel. > > I think my suggestion was better (and it had a \n at the end!) > > Agreed. Actually, 'ouch' on point two :) BTW, was it intentional > that you dropped the maintainer from the recipient-list back then? No, sorry. Eric - 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: [PATCH] add kmalloc check in drviers/pcmcia/rsrc_mgr.c (245-ac16)
On Sun, 24 Jun 2001, Rasmus Andersen wrote:
> Excellent suggestion. How about this one:
> +if (!b) {
> + printk(" -- aborting.\n");
> + printk(KERN_ERR __FUNCTION__ ": Out of memory.");
> + return;
> +}
There are zillions of functions called 'init_module' in the kernel.
I think my suggestion was better (and it had a \n at the end!)
Eric
-
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: [PATCH] add kmalloc check in drviers/pcmcia/rsrc_mgr.c (245-ac16)
On Sun, 24 Jun 2001, Rasmus Andersen wrote:
Excellent suggestion. How about this one:
+if (!b) {
+ printk( -- aborting.\n);
+ printk(KERN_ERR __FUNCTION__ : Out of memory.);
+ return;
+}
There are zillions of functions called 'init_module' in the kernel.
I think my suggestion was better (and it had a \n at the end!)
Eric
-
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: [PATCH] add kmalloc check in drviers/pcmcia/rsrc_mgr.c (245-ac16)
On Sun, 24 Jun 2001, Rasmus Andersen wrote: On Sun, Jun 24, 2001 at 10:52:31PM +0200, Eric Lammerts wrote: [...] There are zillions of functions called 'init_module' in the kernel. I think my suggestion was better (and it had a \n at the end!) Agreed. Actually, 'ouch' on point two :) BTW, was it intentional that you dropped the maintainer from the recipient-list back then? No, sorry. Eric - 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: [PATCH] add kmalloc check in drviers/pcmcia/rsrc_mgr.c (245-ac16)
On Sat, 23 Jun 2001, Rasmus Andersen wrote:
> +if (!b) {
> + printk(" -- aborting.\n");
> + printk(KERN_ERR "Out of memory.");
> + return;
> +}
Why not printk(KERN_ERR "rsrc_mgr: Out of memory.\n"); ?
Then at least people will know what it was that ran out of memory.
Eric
-
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: [PATCH] add kmalloc check in drviers/pcmcia/rsrc_mgr.c (245-ac16)
On Sat, 23 Jun 2001, Rasmus Andersen wrote:
+if (!b) {
+ printk( -- aborting.\n);
+ printk(KERN_ERR Out of memory.);
+ return;
+}
Why not printk(KERN_ERR rsrc_mgr: Out of memory.\n); ?
Then at least people will know what it was that ran out of memory.
Eric
-
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: Linux 2.2.20-pre4
On Tue, 19 Jun 2001, Alan Cox wrote: > > Is it mean now kernel 2.2 with prepatch is (or will be) gcc 3.0 ready ? > > If not what must be fixed/chenged to be ready ? > > It wont build with gcc 3.0 yet. To start with gcc 3.0 will assume it can > insert calls to 'memcpy' I tried it, but didn't run into problems (apart from the volatile xtime thing) Linux version 2.2.18 (eric@andredvb) (gcc version 3.0 (Debian)) #1 Wed Jun 20 23:15:46 CEST 2001 (Tons of warnings, though) Eric - 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: Linux 2.2.20-pre4
On Tue, 19 Jun 2001, Alan Cox wrote: Is it mean now kernel 2.2 with prepatch is (or will be) gcc 3.0 ready ? If not what must be fixed/chenged to be ready ? It wont build with gcc 3.0 yet. To start with gcc 3.0 will assume it can insert calls to 'memcpy' I tried it, but didn't run into problems (apart from the volatile xtime thing) Linux version 2.2.18 (eric@andredvb) (gcc version 3.0 (Debian)) #1 Wed Jun 20 23:15:46 CEST 2001 (Tons of warnings, though) Eric - 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: Forwarding broadcast traffic
On Sat, 3 Mar 2001, Jon Masters wrote: > e.g. on desktop a broadcast udp packet (with a specified port) needs to > go not only to itself and the router but also the "REST OF LAN" part > too - and vice versa. Removing the router is not an option. Write an application that creates 2 sockets listening on the same port but different interfaces (using the SO_BINDTODEVICE socket option, see the dhcp source for an example). Then forward any packet you receive on one socket to the other side. If you need to keep the source ip intact, you may have to use a raw socket for the sending part. You could adapt a DHCP relay program to do this stuff instead of writing it from scratch. Eric -- Eric Lammerts <[EMAIL PROTECTED]> | "An NT server can be run by http://www.lammerts.org | an idiot, and usually is." - 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: Forwarding broadcast traffic
On Sat, 3 Mar 2001, Jon Masters wrote: e.g. on desktop a broadcast udp packet (with a specified port) needs to go not only to itself and the router but also the "REST OF LAN" part too - and vice versa. Removing the router is not an option. Write an application that creates 2 sockets listening on the same port but different interfaces (using the SO_BINDTODEVICE socket option, see the dhcp source for an example). Then forward any packet you receive on one socket to the other side. If you need to keep the source ip intact, you may have to use a raw socket for the sending part. You could adapt a DHCP relay program to do this stuff instead of writing it from scratch. Eric -- Eric Lammerts [EMAIL PROTECTED] | "An NT server can be run by http://www.lammerts.org | an idiot, and usually is." - 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: [2.2.18] outgoing connections getting stuck in SYN_SENT
On 24 Jan 2001, Mark Longair wrote: > It turned out that this was caused by using autofw to forward a range > of ports (2300-2400 in this case.) It seems that these ports aren't > reserved in any way, so eventually the server tries to use one as a > local port on an outgoing connection. > > I'm looking at finding fix for that. Tell the kernel to use a different range for automatically assigned ports, that doesn't conflict with your forwarded ports. For example: echo "49152 5" >/proc/sys/net/ipv4/ip_local_port_range Eric -- Eric Lammerts <[EMAIL PROTECTED]> | The best way to accelerate a computer http://www.lammerts.org | running Windows is at 9.8 m/s^2. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [2.2.18] outgoing connections getting stuck in SYN_SENT
On 24 Jan 2001, Mark Longair wrote: It turned out that this was caused by using autofw to forward a range of ports (2300-2400 in this case.) It seems that these ports aren't reserved in any way, so eventually the server tries to use one as a local port on an outgoing connection. I'm looking at finding fix for that. Tell the kernel to use a different range for automatically assigned ports, that doesn't conflict with your forwarded ports. For example: echo "49152 5" /proc/sys/net/ipv4/ip_local_port_range Eric -- Eric Lammerts [EMAIL PROTECTED] | The best way to accelerate a computer http://www.lammerts.org | running Windows is at 9.8 m/s^2. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Off-Topic: how do I trace a PID over double-forks?
On Fri, 19 Jan 2001, Felix von Leitner wrote: > Now, the back channel for my init has a function that allows to set the > PID of a process. The idea is that the init does not start sendmail but > a wrapper. The wrapper forks, runs sendmail, does some magic trickery > to find the real PID of the daemonized sendmail and tells init this PID > so init will know it has to restart sendmail when it exits and won't > restart the wrapper when that exits. > Someone suggested using fcntl to create a lock and then use fcntl again > to see who holds the lock. That sounded good at first, but fork() does > not seem to inherit locks. Does anyone have another idea? Take a look at fghack (http://cr.yp.to/daemontools/fghack.html). It opens a pipe, gives the write end to the daemon (but the daemon is not aware of that) and monitors the read end. When the daemon process exits, the read end of the pipe gets EOF. If the daemon closes all filehandles, you're out of luck. Eric -- Eric Lammerts <[EMAIL PROTECTED]> | The best way to accelerate a computer http://www.lammerts.org | running Windows is at 9.8 m/s^2. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Off-Topic: how do I trace a PID over double-forks?
On Fri, 19 Jan 2001, Felix von Leitner wrote: Now, the back channel for my init has a function that allows to set the PID of a process. The idea is that the init does not start sendmail but a wrapper. The wrapper forks, runs sendmail, does some magic trickery to find the real PID of the daemonized sendmail and tells init this PID so init will know it has to restart sendmail when it exits and won't restart the wrapper when that exits. Someone suggested using fcntl to create a lock and then use fcntl again to see who holds the lock. That sounded good at first, but fork() does not seem to inherit locks. Does anyone have another idea? Take a look at fghack (http://cr.yp.to/daemontools/fghack.html). It opens a pipe, gives the write end to the daemon (but the daemon is not aware of that) and monitors the read end. When the daemon process exits, the read end of the pipe gets EOF. If the daemon closes all filehandles, you're out of luck. Eric -- Eric Lammerts [EMAIL PROTECTED] | The best way to accelerate a computer http://www.lammerts.org | running Windows is at 9.8 m/s^2. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: `rmdir .` doesn't work in 2.4
On Tue, 9 Jan 2001, Stefan Traby wrote: > "rmdir `pwd`" is required to fail (at least under csh, bash, ksh) if the > path component contains a white space and thereof it can't be a valid > replacement for Andreas "rmdir ." which was what Al initially suggested. > > Yes, I'm very pickey about that; but hey, I don't want to force anyone > to write GNU/Linux like rms; just valid shell code. :) Of course you should do rmdir "`pwd`" But this is a userspace issue. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: `rmdir .` doesn't work in 2.4
On Tue, 9 Jan 2001, Stefan Traby wrote: "rmdir `pwd`" is required to fail (at least under csh, bash, ksh) if the path component contains a white space and thereof it can't be a valid replacement for Andreas "rmdir ." which was what Al initially suggested. Yes, I'm very pickey about that; but hey, I don't want to force anyone to write GNU/Linux like rms; just valid shell code. :) Of course you should do rmdir "`pwd`" But this is a userspace issue. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18 and Maxtor 96147H6 (61 GB)
On Thu, 4 Jan 2001, Igmar Palsenberg wrote: > Yeah.. I removed the clipping, and the machine won't boot. It halts after > PnP init. Any way to use full capacity with the clipping enabled ? I had the same problem with my 80Gb Maxtor. (Asus P2L97, works with 60Gb but hangs with 80Gb :-/) After clipping the drive with ibmsetmax (http://www.uwsg.indiana.edu/hypermail/linux/kernel/0012.1/0249.html) and removing the jumper, unclipping worked fine (kernel is 2.2.18+ide). Andre: can you add unclipping support to 2.4 too? Eric -- Eric Lammerts <[EMAIL PROTECTED]> | "It is a mistake to think you can solve http://www.lammerts.org| any major problems just with potatoes" | - Douglas Adams - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18 and Maxtor 96147H6 (61 GB)
On Thu, 4 Jan 2001, Igmar Palsenberg wrote: Yeah.. I removed the clipping, and the machine won't boot. It halts after PnP init. Any way to use full capacity with the clipping enabled ? I had the same problem with my 80Gb Maxtor. (Asus P2L97, works with 60Gb but hangs with 80Gb :-/) After clipping the drive with ibmsetmax (http://www.uwsg.indiana.edu/hypermail/linux/kernel/0012.1/0249.html) and removing the jumper, unclipping worked fine (kernel is 2.2.18+ide). Andre: can you add unclipping support to 2.4 too? Eric -- Eric Lammerts [EMAIL PROTECTED] | "It is a mistake to think you can solve http://www.lammerts.org| any major problems just with potatoes" | - Douglas Adams - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] /lib/modules/`uname -r`/build is not created
Since 2.2.18pre20, the symlink /lib/modules/`uname -r`/build is not
created because of a non-escaped $ in Makefile.
Patch:
--- linux/Makefile.orig Fri Dec 1 01:39:24 2000
+++ linux/Makefile Fri Dec 1 01:39:32 2000
@@ -335,7 +335,7 @@
MODLIB=$(INSTALL_MOD_PATH)/lib/modules/$(KERNELRELEASE); \
mkdir -p $$MODLIB; \
rm -f $$MODLIB/build; \
- [ `/sbin/insmod -V 2>&1 | head -1 | awk '/^insmod version /{split("$3", a,
/\./); printf "%d%03d%03d\n", a[1], a[2], a[3];}'`0 -ge 20030140 ] && \
+ [ `/sbin/insmod -V 2>&1 | head -1 | awk '/^insmod version /{split($$3, a,
+/\./); printf "%d%03d%03d\n", a[1], a[2], a[3];}'`0 -ge 20030140 ] && \
ln -s `pwd` $$MODLIB/build; \
cd modules; \
MODULES=""; \
Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] /lib/modules/`uname -r`/build is not created
Since 2.2.18pre20, the symlink /lib/modules/`uname -r`/build is not
created because of a non-escaped $ in Makefile.
Patch:
--- linux/Makefile.orig Fri Dec 1 01:39:24 2000
+++ linux/Makefile Fri Dec 1 01:39:32 2000
@@ -335,7 +335,7 @@
MODLIB=$(INSTALL_MOD_PATH)/lib/modules/$(KERNELRELEASE); \
mkdir -p $$MODLIB; \
rm -f $$MODLIB/build; \
- [ `/sbin/insmod -V 21 | head -1 | awk '/^insmod version /{split("$3", a,
/\./); printf "%d%03d%03d\n", a[1], a[2], a[3];}'`0 -ge 20030140 ] \
+ [ `/sbin/insmod -V 21 | head -1 | awk '/^insmod version /{split($$3, a,
+/\./); printf "%d%03d%03d\n", a[1], a[2], a[3];}'`0 -ge 20030140 ] \
ln -s `pwd` $$MODLIB/build; \
cd modules; \
MODULES=""; \
Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: bind() allowed to non-local addresses
On Fri, 20 Oct 2000, Matt Peterson wrote: > Are you also suggesting that every other program that expects bind() to > fail with EADDRNOTAVAIL are broken too? Just for fun, I greped all > sources of software shipped in Caldera's distributions for instances of > where a check is made for EADDRNOTAVAIL after a call to bind(). Guess > what else besides Java is probably "broken" ... > > - lpng > - bind 8.2 > - automount > - cvs > - dhcpd > - KDE > - UCL mbone > - ncftp > - netatalk > - nfsd > - rexec > - pppd > - sendmail > - xchat Just for fun I looked at the sources of cvs, ncftp, netatalk, rexec and pppd. Guess what? None of them check for EADDRNOTAVAIL after a call to bind(). Cvs and pppd don't even call bind()! Get your facts straight, please. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bind() allowed to non-local addresses
On Fri, 20 Oct 2000, Matt Peterson wrote: Are you also suggesting that every other program that expects bind() to fail with EADDRNOTAVAIL are broken too? Just for fun, I greped all sources of software shipped in Caldera's distributions for instances of where a check is made for EADDRNOTAVAIL after a call to bind(). Guess what else besides Java is probably "broken" ... - lpng - bind 8.2 - automount - cvs - dhcpd - KDE - UCL mbone - ncftp - netatalk - nfsd - rexec - pppd - sendmail - xchat Just for fun I looked at the sources of cvs, ncftp, netatalk, rexec and pppd. Guess what? None of them check for EADDRNOTAVAIL after a call to bind(). Cvs and pppd don't even call bind()! Get your facts straight, please. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] max_loop module parameter for 2.2.x loop.c
On Mon, 16 Oct 2000, Alan Cox wrote:
> ENOPATCH
sorry.
here it is.
--- linux-2.2.18pre16/drivers/block/loop.c.orig Mon Oct 16 22:09:17 2000
+++ linux-2.2.18pre16/drivers/block/loop.c Mon Oct 16 22:14:00 2000
@@ -22,6 +22,8 @@
* CBC (and relatives) mode encryption requiring unique IVs per data block.
* Reed H. Petty, [EMAIL PROTECTED]
*
+ * module parameter for max. number of loop devices - Eric Lammerts, Oct 16, 2000
+ *
* Still To Fix:
* - Advisory locking is ignored here.
* - Should use an own CAP_* category instead of CAP_SYS_ADMIN
@@ -42,6 +44,7 @@
#include
#include
#include
+#include
#include
#include
@@ -61,10 +64,12 @@
#define TIMEOUT_VALUE (6 * HZ)
#include
-#define MAX_LOOP 8
-static struct loop_device loop_dev[MAX_LOOP];
-static int loop_sizes[MAX_LOOP];
-static int loop_blksizes[MAX_LOOP];
+static int max_loop = 8;
+MODULE_PARM(max_loop, "i");
+
+static struct loop_device *loop_dev;
+static int *loop_sizes;
+static int *loop_blksizes;
#define FALSE 0
#define TRUE (!FALSE)
@@ -169,7 +174,7 @@
INIT_REQUEST;
current_request=CURRENT;
CURRENT=current_request->next;
- if (MINOR(current_request->rq_dev) >= MAX_LOOP)
+ if (MINOR(current_request->rq_dev) >= max_loop)
goto error_out;
lo = _dev[MINOR(current_request->rq_dev)];
if (!lo->lo_dentry || !lo->transfer)
@@ -577,7 +582,7 @@
return -ENODEV;
}
dev = MINOR(inode->i_rdev);
- if (dev >= MAX_LOOP)
+ if (dev >= max_loop)
return -ENODEV;
lo = _dev[dev];
switch (cmd) {
@@ -614,7 +619,7 @@
return -ENODEV;
}
dev = MINOR(inode->i_rdev);
- if (dev >= MAX_LOOP) {
+ if (dev >= max_loop) {
return -ENODEV;
}
lo = _dev[dev];
@@ -639,7 +644,7 @@
return 0;
}
dev = MINOR(inode->i_rdev);
- if (dev >= MAX_LOOP)
+ if (dev >= max_loop)
return 0;
err = fsync_dev(inode->i_rdev);
lo = _dev[dev];
@@ -689,7 +694,7 @@
if ((unsigned)number >= MAX_LO_CRYPT)
return -EINVAL;
- for (lo = _dev[0]; lo < _dev[MAX_LOOP]; lo++) {
+ for (lo = _dev[0]; lo < _dev[max_loop]; lo++) {
int type = lo->lo_encrypt_type;
if (type == number) {
xfer_funcs[type]->release(lo);
@@ -706,34 +711,65 @@
int __init loop_init(void)
{
- int i;
+ int i, retval;
+
+ if(max_loop < 1 || max_loop > 256) {
+ printk(KERN_ERR "loop: 1 <= max_loop <= 256\n");
+ return -EINVAL;
+ }
+
+ retval = -ENOMEM;
+ loop_dev = kmalloc(sizeof(*loop_dev) * max_loop, GFP_KERNEL);
+ if(loop_dev == NULL) goto out_nomem;
+
+ loop_sizes = kmalloc(sizeof(*loop_sizes) * max_loop, GFP_KERNEL);
+ if(loop_sizes == NULL) goto out_nomem_freedev;
+
+ loop_blksizes = kmalloc(sizeof(*loop_blksizes) * max_loop, GFP_KERNEL);
+ if(loop_blksizes == NULL) goto out_nomem_freesizes;
if (register_blkdev(MAJOR_NR, "loop", _fops)) {
printk(KERN_WARNING "Unable to get major number %d for loop device\n",
MAJOR_NR);
- return -EIO;
+ retval = -EIO;
+ goto out_nomem_freeblksizes;
}
#ifndef MODULE
printk(KERN_INFO "loop: registered device at major %d\n", MAJOR_NR);
#endif
blk_dev[MAJOR_NR].request_fn = DEVICE_REQUEST;
- for (i=0; i < MAX_LOOP; i++) {
+ for (i=0; i < max_loop; i++) {
memset(_dev[i], 0, sizeof(struct loop_device));
loop_dev[i].lo_number = i;
}
- memset(_sizes, 0, sizeof(loop_sizes));
- memset(_blksizes, 0, sizeof(loop_blksizes));
+ memset(loop_sizes, 0, sizeof(*loop_sizes) * max_loop);
+ memset(loop_blksizes, 0, sizeof(*loop_blksizes) * max_loop);
blk_size[MAJOR_NR] = loop_sizes;
blksize_size[MAJOR_NR] = loop_blksizes;
return 0;
+
+out_nomem_freeblksizes:
+ kfree(loop_blksizes);
+out_nomem_freesizes:
+ kfree(loop_sizes);
+out_nomem_freedev:
+ kfree(loop_dev);
+out_nomem:
+ return retval;
}
#ifdef MODULE
void cleanup_module(void)
{
- if (unregister_blkdev(MAJOR_NR, "loop") != 0)
+ if (unregister_blkdev(MAJOR_NR, "loop") != 0) {
printk(KERN_WARNING "loop: cannot unregister blkdev\n");
+ return;
+ }
+
+ kfree(loop_dev);
+ kfree(loop_sizes);
+ kfree(loop_blksizes);
}
#endif
[PATCH] max_loop module parameter for 2.2.x loop.c
This patch add the module parameter 'max_loop' to loop.c (like there is in 2.4). It's against 2.2.18pre16. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] max_loop module parameter for 2.2.x loop.c
On Mon, 16 Oct 2000, Alan Cox wrote:
ENOPATCH
sorry.
here it is.
--- linux-2.2.18pre16/drivers/block/loop.c.orig Mon Oct 16 22:09:17 2000
+++ linux-2.2.18pre16/drivers/block/loop.c Mon Oct 16 22:14:00 2000
@@ -22,6 +22,8 @@
* CBC (and relatives) mode encryption requiring unique IVs per data block.
* Reed H. Petty, [EMAIL PROTECTED]
*
+ * module parameter for max. number of loop devices - Eric Lammerts, Oct 16, 2000
+ *
* Still To Fix:
* - Advisory locking is ignored here.
* - Should use an own CAP_* category instead of CAP_SYS_ADMIN
@@ -42,6 +44,7 @@
#include linux/file.h
#include linux/stat.h
#include linux/errno.h
+#include linux/malloc.h
#include linux/major.h
#include linux/init.h
@@ -61,10 +64,12 @@
#define TIMEOUT_VALUE (6 * HZ)
#include linux/blk.h
-#define MAX_LOOP 8
-static struct loop_device loop_dev[MAX_LOOP];
-static int loop_sizes[MAX_LOOP];
-static int loop_blksizes[MAX_LOOP];
+static int max_loop = 8;
+MODULE_PARM(max_loop, "i");
+
+static struct loop_device *loop_dev;
+static int *loop_sizes;
+static int *loop_blksizes;
#define FALSE 0
#define TRUE (!FALSE)
@@ -169,7 +174,7 @@
INIT_REQUEST;
current_request=CURRENT;
CURRENT=current_request-next;
- if (MINOR(current_request-rq_dev) = MAX_LOOP)
+ if (MINOR(current_request-rq_dev) = max_loop)
goto error_out;
lo = loop_dev[MINOR(current_request-rq_dev)];
if (!lo-lo_dentry || !lo-transfer)
@@ -577,7 +582,7 @@
return -ENODEV;
}
dev = MINOR(inode-i_rdev);
- if (dev = MAX_LOOP)
+ if (dev = max_loop)
return -ENODEV;
lo = loop_dev[dev];
switch (cmd) {
@@ -614,7 +619,7 @@
return -ENODEV;
}
dev = MINOR(inode-i_rdev);
- if (dev = MAX_LOOP) {
+ if (dev = max_loop) {
return -ENODEV;
}
lo = loop_dev[dev];
@@ -639,7 +644,7 @@
return 0;
}
dev = MINOR(inode-i_rdev);
- if (dev = MAX_LOOP)
+ if (dev = max_loop)
return 0;
err = fsync_dev(inode-i_rdev);
lo = loop_dev[dev];
@@ -689,7 +694,7 @@
if ((unsigned)number = MAX_LO_CRYPT)
return -EINVAL;
- for (lo = loop_dev[0]; lo loop_dev[MAX_LOOP]; lo++) {
+ for (lo = loop_dev[0]; lo loop_dev[max_loop]; lo++) {
int type = lo-lo_encrypt_type;
if (type == number) {
xfer_funcs[type]-release(lo);
@@ -706,34 +711,65 @@
int __init loop_init(void)
{
- int i;
+ int i, retval;
+
+ if(max_loop 1 || max_loop 256) {
+ printk(KERN_ERR "loop: 1 = max_loop = 256\n");
+ return -EINVAL;
+ }
+
+ retval = -ENOMEM;
+ loop_dev = kmalloc(sizeof(*loop_dev) * max_loop, GFP_KERNEL);
+ if(loop_dev == NULL) goto out_nomem;
+
+ loop_sizes = kmalloc(sizeof(*loop_sizes) * max_loop, GFP_KERNEL);
+ if(loop_sizes == NULL) goto out_nomem_freedev;
+
+ loop_blksizes = kmalloc(sizeof(*loop_blksizes) * max_loop, GFP_KERNEL);
+ if(loop_blksizes == NULL) goto out_nomem_freesizes;
if (register_blkdev(MAJOR_NR, "loop", lo_fops)) {
printk(KERN_WARNING "Unable to get major number %d for loop device\n",
MAJOR_NR);
- return -EIO;
+ retval = -EIO;
+ goto out_nomem_freeblksizes;
}
#ifndef MODULE
printk(KERN_INFO "loop: registered device at major %d\n", MAJOR_NR);
#endif
blk_dev[MAJOR_NR].request_fn = DEVICE_REQUEST;
- for (i=0; i MAX_LOOP; i++) {
+ for (i=0; i max_loop; i++) {
memset(loop_dev[i], 0, sizeof(struct loop_device));
loop_dev[i].lo_number = i;
}
- memset(loop_sizes, 0, sizeof(loop_sizes));
- memset(loop_blksizes, 0, sizeof(loop_blksizes));
+ memset(loop_sizes, 0, sizeof(*loop_sizes) * max_loop);
+ memset(loop_blksizes, 0, sizeof(*loop_blksizes) * max_loop);
blk_size[MAJOR_NR] = loop_sizes;
blksize_size[MAJOR_NR] = loop_blksizes;
return 0;
+
+out_nomem_freeblksizes:
+ kfree(loop_blksizes);
+out_nomem_freesizes:
+ kfree(loop_sizes);
+out_nomem_freedev:
+ kfree(loop_dev);
+out_nomem:
+ return retval;
}
#ifdef MODULE
void cleanup_module(void)
{
- if (unregister_blkdev(MAJOR_NR, "loop") != 0)
+ if (unregister_blkdev(MAJOR_NR, "loop") != 0) {
printk(KERN_WARNING "loop: cannot unregister blkdev\n");
+ return;
+ }
+
+ kfree(loop_dev);
+ kfree(loop_sizes);
+ kfree(loop_blksizes);
}
#endif
Re: Majordomo Problems?
On Thu, 5 Oct 2000, Matti Aarnio wrote: > The list has been experiencing loop via somebody. > The likely suspect is now deleted from the list, and > it remains to be seen if that helped. from a looping message: > X-Mailing-List: [EMAIL PROTECTED] > X-Mailing-List: [EMAIL PROTECTED] > X-Mailing-List: [EMAIL PROTECTED] > X-Mailing-List: [EMAIL PROTECTED] > Sender: [EMAIL PROTECTED] > Precedence: bulk > X-Mailing-List: [EMAIL PROTECTED] Apparently Majordomo does not have loop detection, or it's defective. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Majordomo Problems?
On Thu, 5 Oct 2000, Matti Aarnio wrote: The list has been experiencing loop via somebody. The likely suspect is now deleted from the list, and it remains to be seen if that helped. from a looping message: X-Mailing-List: [EMAIL PROTECTED] X-Mailing-List: [EMAIL PROTECTED] X-Mailing-List: [EMAIL PROTECTED] X-Mailing-List: [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Precedence: bulk X-Mailing-List: [EMAIL PROTECTED] Apparently Majordomo does not have loop detection, or it's defective. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
