Re: Download process for a "split kernel" (was: obsolete code must die)
(I wrote) > > This might actually make sense - a kernel composed of multiple versioned > > segments. A tool which works out dependencies of the options being selected, > > downloads the required parts if the latest versions of those parts are not > > already downloaded, and then builds the kernel (or could even build during > > the download, as soon as the build dependencies for each block of the kernel > > are satisfied, if you want to be fancy...). > > Please do look at the archives to find out just why this idea is floated > each 3 to 4 months and then shot down, and why. Well, I'm actually looking at the 2nd idea I mentioned in my e-mail -- a very small "kernel package" which has a config script, a list of config options and the files they depend on and an appropriately tagged CVS tree which can then be used for a compressed checkout of a version to do a build. (Or maybe something more bandwidth-friendly than CVS for the initial checkout.) Maybe I'll find the spare time to do it, maybe I won't, either way I won't post any more on the subject until I have something tangible (so far I've just done the 'easy bit': written a quick shell script which imported 2.4.x into a tagged CVS tree; the 'hard bit', to write a script to analyse each kernel rev and determine which files are used by which config options and mix that in together with the minimal install for a 'make menuconfig' will take somewhat longer). David. -- David LuyerPhone: +61 3 9674 7525 Engineering Projects Manager P A C I F I C Fax: +61 3 9699 8693 Pacific Internet (Australia) I N T E R N E T Mobile: +61 4 2983 http://www.pacific.net.au/ NASDAQ: PCNTF - 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: Download process for a split kernel (was: obsolete code must die)
(I wrote) This might actually make sense - a kernel composed of multiple versioned segments. A tool which works out dependencies of the options being selected, downloads the required parts if the latest versions of those parts are not already downloaded, and then builds the kernel (or could even build during the download, as soon as the build dependencies for each block of the kernel are satisfied, if you want to be fancy...). Please do look at the archives to find out just why this idea is floated each 3 to 4 months and then shot down, and why. Well, I'm actually looking at the 2nd idea I mentioned in my e-mail -- a very small kernel package which has a config script, a list of config options and the files they depend on and an appropriately tagged CVS tree which can then be used for a compressed checkout of a version to do a build. (Or maybe something more bandwidth-friendly than CVS for the initial checkout.) Maybe I'll find the spare time to do it, maybe I won't, either way I won't post any more on the subject until I have something tangible (so far I've just done the 'easy bit': written a quick shell script which imported 2.4.x into a tagged CVS tree; the 'hard bit', to write a script to analyse each kernel rev and determine which files are used by which config options and mix that in together with the minimal install for a 'make menuconfig' will take somewhat longer). David. -- David LuyerPhone: +61 3 9674 7525 Engineering Projects Manager P A C I F I C Fax: +61 3 9699 8693 Pacific Internet (Australia) I N T E R N E T Mobile: +61 4 2983 http://www.pacific.net.au/ NASDAQ: PCNTF - 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/
Download process for a "split kernel" (was: obsolete code must die)
> I agree that removing support for any hardware is a bad idea but I question > the idea of putting it all in one monolithic download (tar file). If we're > considering the concern for less developed nations with older hardware, > imagine how you would like to download the whole kernel with an old 2400 bps > modem. Not a fun thought. > > Would it make sense to create some sort of 'make config' script that > determines what you want in your kernel and then downloads only those > components? After all, with the constant release of new hardware, isn't a > 50MB kernel release not too far away? 100MB? This might actually make sense - a kernel composed of multiple versioned segments. A tool which works out dependencies of the options being selected, downloads the required parts if the latest versions of those parts are not already downloaded, and then builds the kernel (or could even build during the download, as soon as the build dependencies for each block of the kernel are satisfied, if you want to be fancy...). Or as a simpler design, something like; * a copy of the kernel maintained in a CVS tree * kernel download would pull down: * the build script * a file containing the list of filenames depended on by each config option * build script builds the config and then cvs updates the file list and the files for each config option in question to the version as tagged in the build script Someone could relatively easily maintain this separate to all the kernel developers, and it would mean only ever having to download files you were actually using. David. -- David LuyerPhone: +61 3 9674 7525 Engineering Projects Manager P A C I F I C Fax: +61 3 9699 8693 Pacific Internet (Australia) I N T E R N E T Mobile: +61 4 2983 http://www.pacific.net.au/ NASDAQ: PCNTF - 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: obsolete code must die
Obsolete code must die. Hardware support must live on. > > ISA, MCA, EISA device drivers > > If support for the buses is gone, there's no point in supporting devices for > > these buses. > > I am not certain if tis is a good idea, for the reason given above. (Not > certain about MCA and EISA though.) MCA is common for PS/2's, which are still around. > > MFM/RLL/XT/ESDI hard drive support > > Does anyone still *have* an RLL drive that works? At the very least get rid > > of the old driver (eg CONFIG_BLK_DEV_HD_ONLY, CONFIG_BLK_DEV_HD_IDE, > > CONFIG_BLK_DEV_XD, CONFIG_BLK_DEV_PS2) > > I am not certain how much this stuff is still used outside the US. The XT > driver still being around does surprise me though. (Will that even *work* > on modern hardware? I didn't think you could get that card to work on a > 386.) Could never get my OMTI 8627 ESDI controller to work under Linux when I tried. It works under DOS/Win, Xenix and VSTa though. These controllers were pseudo-common early 386 machines (before the 386sx and 386dx) built for Xenix. Surprisingly the old NEC ESDI drive still spins up, when most of the 1998 or 1999 Seagates/IBM drives are dead or dying and we've had close to an entire A1000 Sun disk unit fail to spin up -- the 'top-end' disks of today rarely seem to last more than 2-3 years (in that if you turn them off after 2-3 years of continual service and turn them back on 1/2 hr later, half of the drives which haven't spat out a drive head in the interim years will fail to spin up). Even old Eagle drives from 1988 still spin up... given you have to flick the starter switch to spin them up half a dozen times, but they still work... seems they don't make disk drives like they used to. David. -- David LuyerPhone: +61 3 9674 7525 Engineering Projects Manager P A C I F I C Fax: +61 3 9699 8693 Pacific Internet (Australia) I N T E R N E T Mobile: +61 4 2983 http://www.pacific.net.au/ NASDAQ: PCNTF - 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: obsolete code must die
Obsolete code must die. Hardware support must live on. ISA, MCA, EISA device drivers If support for the buses is gone, there's no point in supporting devices for these buses. I am not certain if tis is a good idea, for the reason given above. (Not certain about MCA and EISA though.) MCA is common for PS/2's, which are still around. MFM/RLL/XT/ESDI hard drive support Does anyone still *have* an RLL drive that works? At the very least get rid of the old driver (eg CONFIG_BLK_DEV_HD_ONLY, CONFIG_BLK_DEV_HD_IDE, CONFIG_BLK_DEV_XD, CONFIG_BLK_DEV_PS2) I am not certain how much this stuff is still used outside the US. The XT driver still being around does surprise me though. (Will that even *work* on modern hardware? I didn't think you could get that card to work on a 386.) Could never get my OMTI 8627 ESDI controller to work under Linux when I tried. It works under DOS/Win, Xenix and VSTa though. These controllers were pseudo-common early 386 machines (before the 386sx and 386dx) built for Xenix. Surprisingly the old NEC ESDI drive still spins up, when most of the 1998 or 1999 Seagates/IBM drives are dead or dying and we've had close to an entire A1000 Sun disk unit fail to spin up -- the 'top-end' disks of today rarely seem to last more than 2-3 years (in that if you turn them off after 2-3 years of continual service and turn them back on 1/2 hr later, half of the drives which haven't spat out a drive head in the interim years will fail to spin up). Even old Eagle drives from 1988 still spin up... given you have to flick the starter switch to spin them up half a dozen times, but they still work... seems they don't make disk drives like they used to. David. -- David LuyerPhone: +61 3 9674 7525 Engineering Projects Manager P A C I F I C Fax: +61 3 9699 8693 Pacific Internet (Australia) I N T E R N E T Mobile: +61 4 2983 http://www.pacific.net.au/ NASDAQ: PCNTF - 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/
Download process for a split kernel (was: obsolete code must die)
I agree that removing support for any hardware is a bad idea but I question the idea of putting it all in one monolithic download (tar file). If we're considering the concern for less developed nations with older hardware, imagine how you would like to download the whole kernel with an old 2400 bps modem. Not a fun thought. Would it make sense to create some sort of 'make config' script that determines what you want in your kernel and then downloads only those components? After all, with the constant release of new hardware, isn't a 50MB kernel release not too far away? 100MB? This might actually make sense - a kernel composed of multiple versioned segments. A tool which works out dependencies of the options being selected, downloads the required parts if the latest versions of those parts are not already downloaded, and then builds the kernel (or could even build during the download, as soon as the build dependencies for each block of the kernel are satisfied, if you want to be fancy...). Or as a simpler design, something like; * a copy of the kernel maintained in a CVS tree * kernel download would pull down: * the build script * a file containing the list of filenames depended on by each config option * build script builds the config and then cvs updates the file list and the files for each config option in question to the version as tagged in the build script Someone could relatively easily maintain this separate to all the kernel developers, and it would mean only ever having to download files you were actually using. David. -- David LuyerPhone: +61 3 9674 7525 Engineering Projects Manager P A C I F I C Fax: +61 3 9699 8693 Pacific Internet (Australia) I N T E R N E T Mobile: +61 4 2983 http://www.pacific.net.au/ NASDAQ: PCNTF - 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/
bug in 2.4.2-ac20 net/irda/af_irda.c or init/main.c
As per my previous e-mail (on l-k), built-in irda causes an infinite loop during bootup (ie, a lockup) by double-registering the same notifier. This happens because irda_proto_init is both called by init/main.c and set as a module_init() function which is then mapped to __initcall when built non-modular. So the notifier chain becomes looped as per the previous e-mail. The fix is to remove one of these, for my system I'm moving the module_init inside the #ifdef MODULE, someone else can choose what's best for the kernel at large... David. - 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/
2.4.2-ac20 gets in infinite loop during bootup
According to SysRq-P, my system gets in an infinite loop on bootup with notifier_call_chain calling irda_device_event repeatedly. This is triggered by toshoboe_open calling register_netdevice. This is with everything irda-related built-in (I don't like modules); it was working in 2.4.1-ac8. Is it possible that the irda_device_event notifier is added twice somewhere? It appears to me this would result in the observed loop, as if the irda (priority=0) is on the end of the list and the same notifier is added, it will position itself at the end of the list again and set it's own 'next' to a pointer to itself (twice), if I read it correctly. David. - 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/
2.4.2-ac20 gets in infinite loop during bootup
According to SysRq-P, my system gets in an infinite loop on bootup with notifier_call_chain calling irda_device_event repeatedly. This is triggered by toshoboe_open calling register_netdevice. This is with everything irda-related built-in (I don't like modules); it was working in 2.4.1-ac8. Is it possible that the irda_device_event notifier is added twice somewhere? It appears to me this would result in the observed loop, as if the irda (priority=0) is on the end of the list and the same notifier is added, it will position itself at the end of the list again and set it's own 'next' to a pointer to itself (twice), if I read it correctly. David. - 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/
bug in 2.4.2-ac20 net/irda/af_irda.c or init/main.c
As per my previous e-mail (on l-k), built-in irda causes an infinite loop during bootup (ie, a lockup) by double-registering the same notifier. This happens because irda_proto_init is both called by init/main.c and set as a module_init() function which is then mapped to __initcall when built non-modular. So the notifier chain becomes looped as per the previous e-mail. The fix is to remove one of these, for my system I'm moving the module_init inside the #ifdef MODULE, someone else can choose what's best for the kernel at large... David. - 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: Incoming TCP TOS: A simple question, I would have thought...
> getsockopt(fd, SOL_IP, IP_TOS, .. Doesn't work. Returns the TOS of outgoing packets, which defaults to 0 even if there is a TOS set on incoming traffic... that was what I tried in my first test program. David. > cheers, > > lincoln. > > At 03:00 PM 7/03/2001 +1100, David Luyer wrote: > > >I've scrolled through various code in net/ipv4, and I can't see how to query > >the TOS of an incoming TCP stream (or at the least, the TOS of the SYN which > >initiated the connection). > > > >Someone has sent in a feature request for squid which would require this, > >presumably so they can set the TOS in their routers and have the squid caches > >honour the TOS to select performance (via delay pools, multiple parents, > >different outgoing IP or similar). However I can't see how to get the TOS for > >a TCP socket out of the kernel short of having an open raw socket watching for > >SYNs and looking at the TOS on them. > > > >Any pointers? > > > >David. -- David LuyerPhone: +61 3 9674 7525 Engineering Projects Manager P A C I F I C Fax: +61 3 9699 8693 Pacific Internet (Australia) I N T E R N E T Mobile: +61 4 2983 http://www.pacific.net.au/ NASDAQ: PCNTF - 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/
Incoming TCP TOS: A simple question, I would have thought...
I've scrolled through various code in net/ipv4, and I can't see how to query the TOS of an incoming TCP stream (or at the least, the TOS of the SYN which initiated the connection). Someone has sent in a feature request for squid which would require this, presumably so they can set the TOS in their routers and have the squid caches honour the TOS to select performance (via delay pools, multiple parents, different outgoing IP or similar). However I can't see how to get the TOS for a TCP socket out of the kernel short of having an open raw socket watching for SYNs and looking at the TOS on them. Any pointers? David. -- David LuyerPhone: +61 3 9674 7525 Engineering Projects Manager P A C I F I C Fax: +61 3 9699 8693 Pacific Internet (Australia) I N T E R N E T Mobile: +61 4 2983 http://www.pacific.net.au/ NASDAQ: PCNTF - 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/
Incoming TCP TOS: A simple question, I would have thought...
I've scrolled through various code in net/ipv4, and I can't see how to query the TOS of an incoming TCP stream (or at the least, the TOS of the SYN which initiated the connection). Someone has sent in a feature request for squid which would require this, presumably so they can set the TOS in their routers and have the squid caches honour the TOS to select performance (via delay pools, multiple parents, different outgoing IP or similar). However I can't see how to get the TOS for a TCP socket out of the kernel short of having an open raw socket watching for SYNs and looking at the TOS on them. Any pointers? David. -- David LuyerPhone: +61 3 9674 7525 Engineering Projects Manager P A C I F I C Fax: +61 3 9699 8693 Pacific Internet (Australia) I N T E R N E T Mobile: +61 4 2983 http://www.pacific.net.au/ NASDAQ: PCNTF - 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: Incoming TCP TOS: A simple question, I would have thought...
getsockopt(fd, SOL_IP, IP_TOS, .. Doesn't work. Returns the TOS of outgoing packets, which defaults to 0 even if there is a TOS set on incoming traffic... that was what I tried in my first test program. David. cheers, lincoln. At 03:00 PM 7/03/2001 +1100, David Luyer wrote: I've scrolled through various code in net/ipv4, and I can't see how to query the TOS of an incoming TCP stream (or at the least, the TOS of the SYN which initiated the connection). Someone has sent in a feature request for squid which would require this, presumably so they can set the TOS in their routers and have the squid caches honour the TOS to select performance (via delay pools, multiple parents, different outgoing IP or similar). However I can't see how to get the TOS for a TCP socket out of the kernel short of having an open raw socket watching for SYNs and looking at the TOS on them. Any pointers? David. -- David LuyerPhone: +61 3 9674 7525 Engineering Projects Manager P A C I F I C Fax: +61 3 9699 8693 Pacific Internet (Australia) I N T E R N E T Mobile: +61 4 2983 http://www.pacific.net.au/ NASDAQ: PCNTF - 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: "Pass module parameters" to built-in drivers
input = r;
+ } else {
+ /* last string */
+ str = input;
+ input = "";
+ }
+ }
+
+ if (*fmt == 's') {
+ /* Normal string - kstrdup please? */
+ *(char **)loc = kmalloc(strlen(str) + 1, GFP_KERNEL);
+ if (*(char **)loc == NULL) {
+ /* Bail on this variable */
+ printk("parameter %s - kmalloc() failed\n",
+name);
+ } else
+ strcpy(*(char **)loc, str);
+
+ (char *)loc += tgt_sizeof_char_p;
+ } else {
+ /* Array of chars (in fact, matrix !) */
+ static long charssize __initdata = 0; /* size of
+each member */
+
+ /* Get the size of each member */
+ /* Probably we should do that outside the loop ? */
+ if (!isdigit(*(fmt + 1))) {
+ printk("parameter type 'c' for %s must be
+followed by"
+ " the maximum size\n", name);
+ return 0;
+ }
+ charssize = simple_strtoul(fmt + 1, (char **) NULL,
+10);
+
+ /* Check length */
+ if (strlen(str) >= charssize-1) {
+ printk("string too long for %s (max %ld)",
+ name, charssize - 1);
+ return 0;
+ }
+ /* Copy to location */
+ strcpy((char *) loc, str); /* safe, see check
+above */
+ (char *)loc += charssize;
+ }
+ /*
+* End of 's' and 'c'
+*/
+ break;
+
+ case 'b':
+ *(char *)loc++ = simple_strtoul(input, , 0);
+ break;
+
+ case 'h':
+ *(short *) loc = simple_strtoul(input, , 0);
+ (char *)loc += tgt_sizeof_short;
+ break;
+
+ case 'i':
+ *(int *) loc = simple_strtoul(input, , 0);
+ (char *)loc += tgt_sizeof_int;
+ break;
+
+ case 'l':
+ *(long *) loc = simple_strtoul(input, , 0);
+ (char *)loc += tgt_sizeof_long;
+ break;
+
+ default:
+ printk("unknown parameter type '%c' for %s",
+ *fmt, name);
+ return 0;
+ }
+ /*
+* end of switch (*fmt)
+*/
+
+ while (*input && isspace(*input))
+ ++input;
+ if (*input == '\0')
+ break; /* while (*input) */
+ /* else */
+
+ if (*input == ',') {
+ if (max && (++n > max)) {
+ printk("too many values for %s (max %d)", name, max);
+ return 0;
+ }
+ ++input;
+ /* continue with while (*input) */
+ } else {
+ printk("invalid argument syntax for %s: '%c'",
+ name, *input);
+ return 0;
+ }
+ } /* end of while (*input) */
+
+ if (min && (n < min)) {
+ printk("too few values for %s (min %d)", name, min);
+ return 0;
+ }
+
+ return 1;
+}
+#endif
EXPORT_SYMBOL(memparse);
EXPORT_SYMBOL(get_option);
David.
--
David LuyerPhone: +61 3 9674 7525
Senior Network EngineerP A C I F I C Fax: +61 3 9699 8693
Pacific Internet (Australia) I N T E R N E T Mobile: +61 4 2983
http://www.pacific.net.au/ NASDAQ: PCNTF
-
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: Pass module parameters to built-in drivers
/* Keep next fields */
+ input = r;
+ } else {
+ /* last string */
+ str = input;
+ input = "";
+ }
+ }
+
+ if (*fmt == 's') {
+ /* Normal string - kstrdup please? */
+ *(char **)loc = kmalloc(strlen(str) + 1, GFP_KERNEL);
+ if (*(char **)loc == NULL) {
+ /* Bail on this variable */
+ printk("parameter %s - kmalloc() failed\n",
+name);
+ } else
+ strcpy(*(char **)loc, str);
+
+ (char *)loc += tgt_sizeof_char_p;
+ } else {
+ /* Array of chars (in fact, matrix !) */
+ static long charssize __initdata = 0; /* size of
+each member */
+
+ /* Get the size of each member */
+ /* Probably we should do that outside the loop ? */
+ if (!isdigit(*(fmt + 1))) {
+ printk("parameter type 'c' for %s must be
+followed by"
+ " the maximum size\n", name);
+ return 0;
+ }
+ charssize = simple_strtoul(fmt + 1, (char **) NULL,
+10);
+
+ /* Check length */
+ if (strlen(str) = charssize-1) {
+ printk("string too long for %s (max %ld)",
+ name, charssize - 1);
+ return 0;
+ }
+ /* Copy to location */
+ strcpy((char *) loc, str); /* safe, see check
+above */
+ (char *)loc += charssize;
+ }
+ /*
+* End of 's' and 'c'
+*/
+ break;
+
+ case 'b':
+ *(char *)loc++ = simple_strtoul(input, input, 0);
+ break;
+
+ case 'h':
+ *(short *) loc = simple_strtoul(input, input, 0);
+ (char *)loc += tgt_sizeof_short;
+ break;
+
+ case 'i':
+ *(int *) loc = simple_strtoul(input, input, 0);
+ (char *)loc += tgt_sizeof_int;
+ break;
+
+ case 'l':
+ *(long *) loc = simple_strtoul(input, input, 0);
+ (char *)loc += tgt_sizeof_long;
+ break;
+
+ default:
+ printk("unknown parameter type '%c' for %s",
+ *fmt, name);
+ return 0;
+ }
+ /*
+* end of switch (*fmt)
+*/
+
+ while (*input isspace(*input))
+ ++input;
+ if (*input == '\0')
+ break; /* while (*input) */
+ /* else */
+
+ if (*input == ',') {
+ if (max (++n max)) {
+ printk("too many values for %s (max %d)", name, max);
+ return 0;
+ }
+ ++input;
+ /* continue with while (*input) */
+ } else {
+ printk("invalid argument syntax for %s: '%c'",
+ name, *input);
+ return 0;
+ }
+ } /* end of while (*input) */
+
+ if (min (n min)) {
+ printk("too few values for %s (min %d)", name, min);
+ return 0;
+ }
+
+ return 1;
+}
+#endif
EXPORT_SYMBOL(memparse);
EXPORT_SYMBOL(get_option);
David.
--
David LuyerPhone: +61 3 9674 7525
Senior Network EngineerP A C I F I C Fax: +61 3 9699 8693
Pacific Internet (Australia) I N T E R N E T Mobile: +61 4 2983
http://www.pacific.net.au/ NASDAQ: PCNTF
-
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: Pass parameters to xirc2ps_cs via kernel command line
Alan,
Looking forward to your talk tomorrow at linux.conf.au.
Here's an addition for drivers/net/pcmcia/xirc2ps_cs.c dedicated to all the
guys who were playing flood-ping-the-broadcast in the networking room
downstairs at linux.conf.au, so that I can specify lockup_hack = 1 in my fully
non-modular kernel and not have my ethernet lock up under extreme load :-)
(relative to: 2.4.0-ac9)
--- orig/linux/drivers/net/pcmcia/xirc2ps_cs.c Fri Oct 27 10:52:16 2000
+++ linux/drivers/net/pcmcia/xirc2ps_cs.c Wed Jan 17 22:13:03 2001
@@ -2058,3 +2058,28 @@
module_init(init_xirc2ps_cs);
module_exit(exit_xirc2ps_cs);
+#ifndef MODULE
+static int __init setup_xirc2ps_cs(char *str)
+{
+ /* irq, irq_mask, if_port, full_duplex, do_sound, lockup_hack
+* [,irq2 [,irq3 [,irq4]]]
+*/
+ int ints[10] = { -1 };
+
+ str = get_options(str, 9, ints);
+
+#define MAYBE_SET(X,Y) if (ints[0] >= Y && ints[Y] != -1) { X = ints[Y]; }
+ MAYBE_SET(irq_list[0], 1);
+ MAYBE_SET(irq_mask, 2);
+ MAYBE_SET(if_port, 3);
+ MAYBE_SET(full_duplex, 4);
+ MAYBE_SET(do_sound, 5);
+ MAYBE_SET(lockup_hack, 6);
+ MAYBE_SET(irq_list[1], 7);
+ MAYBE_SET(irq_list[2], 8);
+ MAYBE_SET(irq_list[3], 9);
+#undef MAYBE_SET(X,Y)
+}
+
+__setup("xirc2ps_cs=", setup_xirc2ps_cs);
+#endif
It occurs to me it would appear relatively trivial to write a "default" __setup
function for anything with module parameters (viz, xirc2ps_cs.lockup_hack=1).
Would a patch to that effect be likely to be accepted?
David.
--
David LuyerPhone: +61 3 9674 7525
Senior Network EngineerP A C I F I C Fax: +61 3 9699 8693
Pacific Internet (Australia) I N T E R N E T Mobile: +61 4 2983
http://www.pacific.net.au/ NASDAQ: PCNTF
-
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: Pass parameters to xirc2ps_cs via kernel command line
Alan,
Looking forward to your talk tomorrow at linux.conf.au.
Here's an addition for drivers/net/pcmcia/xirc2ps_cs.c dedicated to all the
guys who were playing flood-ping-the-broadcast in the networking room
downstairs at linux.conf.au, so that I can specify lockup_hack = 1 in my fully
non-modular kernel and not have my ethernet lock up under extreme load :-)
(relative to: 2.4.0-ac9)
--- orig/linux/drivers/net/pcmcia/xirc2ps_cs.c Fri Oct 27 10:52:16 2000
+++ linux/drivers/net/pcmcia/xirc2ps_cs.c Wed Jan 17 22:13:03 2001
@@ -2058,3 +2058,28 @@
module_init(init_xirc2ps_cs);
module_exit(exit_xirc2ps_cs);
+#ifndef MODULE
+static int __init setup_xirc2ps_cs(char *str)
+{
+ /* irq, irq_mask, if_port, full_duplex, do_sound, lockup_hack
+* [,irq2 [,irq3 [,irq4]]]
+*/
+ int ints[10] = { -1 };
+
+ str = get_options(str, 9, ints);
+
+#define MAYBE_SET(X,Y) if (ints[0] = Y ints[Y] != -1) { X = ints[Y]; }
+ MAYBE_SET(irq_list[0], 1);
+ MAYBE_SET(irq_mask, 2);
+ MAYBE_SET(if_port, 3);
+ MAYBE_SET(full_duplex, 4);
+ MAYBE_SET(do_sound, 5);
+ MAYBE_SET(lockup_hack, 6);
+ MAYBE_SET(irq_list[1], 7);
+ MAYBE_SET(irq_list[2], 8);
+ MAYBE_SET(irq_list[3], 9);
+#undef MAYBE_SET(X,Y)
+}
+
+__setup("xirc2ps_cs=", setup_xirc2ps_cs);
+#endif
It occurs to me it would appear relatively trivial to write a "default" __setup
function for anything with module parameters (viz, xirc2ps_cs.lockup_hack=1).
Would a patch to that effect be likely to be accepted?
David.
--
David LuyerPhone: +61 3 9674 7525
Senior Network EngineerP A C I F I C Fax: +61 3 9699 8693
Pacific Internet (Australia) I N T E R N E T Mobile: +61 4 2983
http://www.pacific.net.au/ NASDAQ: PCNTF
-
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/
linux-2.4.0-test10 and X4.0.1 don't like each other on Libretto 110CT
I'm having problems with X 4.0.1 and 2.4.0-test kernels on a Toshiba Libretto 110CT. Is this likely to be related to a known problem or can someone recommend some random intermediate kernel versions to try (binary elimination avoiding known-bad kernel versions...)? H/w: Toshiba Libretto 110CT (NM2160), Xircom CEM336 modem/ethernet S/w: Debian woody as at Wed Nov 8, with old xserver-svga package for testing Kernel xserver-xfree86 4.0.1-1xserver-svga 3.3.6-10 2.4.0-test10 Fail OK 2.4.0-test4pre3Fail OK 2.2.15 (Debian build) OK OK "Fail" here means X startup results in a blank LCD, unable to switch to text consoles either, SAK results in a screen full of previous graphics-mode display on LCD, even if it was pre-reboot, at that screen it is possible to type (although not to see the result), login, reboot the system, try a different version of X, etc (as long as you can remember what you've typed). Thanks for any help, David. - 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/
linux-2.4.0-test10 and X4.0.1 don't like each other on Libretto 110CT
I'm having problems with X 4.0.1 and 2.4.0-test kernels on a Toshiba Libretto 110CT. Is this likely to be related to a known problem or can someone recommend some random intermediate kernel versions to try (binary elimination avoiding known-bad kernel versions...)? H/w: Toshiba Libretto 110CT (NM2160), Xircom CEM336 modem/ethernet S/w: Debian woody as at Wed Nov 8, with old xserver-svga package for testing Kernel xserver-xfree86 4.0.1-1xserver-svga 3.3.6-10 2.4.0-test10 Fail OK 2.4.0-test4pre3Fail OK 2.2.15 (Debian build) OK OK "Fail" here means X startup results in a blank LCD, unable to switch to text consoles either, SAK results in a screen full of previous graphics-mode display on LCD, even if it was pre-reboot, at that screen it is possible to type (although not to see the result), login, reboot the system, try a different version of X, etc (as long as you can remember what you've typed). Thanks for any help, David. - 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: Linux 2.2 - BSD/OS 4.1 ARP incompatibility
> just try "traceroute -s 111.111.111.111 d.e.f.2" > What shows this simple test? > > arp who-has d.e.f.2 tell a.b.c.1 > > or > > arp who-has d.e.f.2 tell d.e.f.1 When I tried traceroute -s d.e.f.1 d.e.f.2, it worked, the first time the Linux box in question talked to the BSD/OS in question without the aid of an extra host spoofing responses to the arp queries in question. The command you suggested also had the desired effect. However... # arp -d d.e.f.2 # traceroute d.e.f.2 traceroute to d.e.f.2, 30 hops max, 40 byte packets 1 a.b.c.1 2997 ms !H 2998 ms !H 3000 ms !H (ie, failure by default) # traceroute -s d.e.f.1 d.e.f.2 traceroute to d.e.f.2 from d.e.f.1, 30 hops max, 40 byte packets 1 d.e.f.2 1 ms 0 ms 0 ms # traceroute d.e.f.2 traceroute to d.e.f.2, 30 hops max, 40 byte packets 1 d.e.f.2 1 ms 0 ms 0 ms (success, and success by default once the MAC address is known to the ARP table) # arp -d d.e.f.2 # traceroute -s 5.5.5.5 d.e.f.2 1 * * * at this point the tcpdump shows arp requests from d.e.f.1, ie, correct ARP requests. But straight command line ping and traceroute with no explicit source, and sockets which are not explicitly bound (eg, standard netkit telnet) are perhaps being auto-bound or otherwise made to choose a.b.c.1 as their for arp requests. > If the announced address is d.e.f.1 then there is no problem in > inet_select_addr() but your application is already bound to the > primary address. It's not in the case of telnet (simple to see by strace), and I expect not in the case of traceroute with no explicit source either. However, perhaps the automatic bind is choosing the primary address. So if I want it to work I most likely need to make the ARP request ignore the higher level bindings of the socket. David. -- ------ David Luyer Senior Network Engineer Pacific Internet (Aust) Pty Ltd Phone: +61 3 9674 7525 Fax:+61 3 9699 8693 Mobile: +61 4 1064 2258, +61 4 1114 2258 http://www.pacific.net.auNASDAQ: PCNTF << fast 'n easy >> -- - 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: Linux 2.2 - BSD/OS 4.1 ARP incompatibility
(Alan Cox) (Matt Kirkwood) > > Please forgive my obtuseness, but I am unable to conceive of > > one (beyond checking that your routing is symmetrical :-) > > Multiple virtual hosts, routing for tunnels And how is this in any way broken by arp-ing from the first interface address (in terms of walking the list of virtuals) on the same subnet as the machine your arp address request is for? And using the same as the preferred source address when none is specified, but that's not actually required to fix the problem (in fact, a userspace daemon on another machine generating the required spoofed ARP responses fixed the problem, but that seems like a rather ludicrous solution to such a simple problem!) Apart from that, every other implementation I've been able to check does it the same way and Linux is just the odd one out. It breaks things, it means Linux doesn't interoperate in what is quite a common environment, and basically it doesn't seem to have any solid reason to be how it is. If the rfc for ARP on Ethernet wasn't so old and brief I'd expect it to be against it, unfortunately the rfc is a little dated and simplistic. If the tunnels need a specific source address they should be explicitly bound. Heck, in Cisco IOS the source address for any tunnel is specified and IOS will generate the encapsulated packets with that source even if that IP doesn't exist on the router (makes trying to do HSRP redundant tunnel termination a bit complex :/). David. -- ------ David Luyer Senior Network Engineer Pacific Internet (Aust) Pty Ltd Phone: +61 3 9674 7525 Fax:+61 3 9699 8693 Mobile: +61 4 1064 2258, +61 4 1114 2258 http://www.pacific.net.auNASDAQ: PCNTF << fast 'n easy >> -- - 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: Linux 2.2 - BSD/OS 4.1 ARP incompatibility
(Alan Cox) (Matt Kirkwood) Please forgive my obtuseness, but I am unable to conceive of one (beyond checking that your routing is symmetrical :-) Multiple virtual hosts, routing for tunnels And how is this in any way broken by arp-ing from the first interface address (in terms of walking the list of virtuals) on the same subnet as the machine your arp address request is for? And using the same as the preferred source address when none is specified, but that's not actually required to fix the problem (in fact, a userspace daemon on another machine generating the required spoofed ARP responses fixed the problem, but that seems like a rather ludicrous solution to such a simple problem!) Apart from that, every other implementation I've been able to check does it the same way and Linux is just the odd one out. It breaks things, it means Linux doesn't interoperate in what is quite a common environment, and basically it doesn't seem to have any solid reason to be how it is. If the rfc for ARP on Ethernet wasn't so old and brief I'd expect it to be against it, unfortunately the rfc is a little dated and simplistic. If the tunnels need a specific source address they should be explicitly bound. Heck, in Cisco IOS the source address for any tunnel is specified and IOS will generate the encapsulated packets with that source even if that IP doesn't exist on the router (makes trying to do HSRP redundant tunnel termination a bit complex :/). David. -- -- David Luyer Senior Network Engineer Pacific Internet (Aust) Pty Ltd Phone: +61 3 9674 7525 Fax:+61 3 9699 8693 Mobile: +61 4 1064 2258, +61 4 1114 2258 http://www.pacific.net.auNASDAQ: PCNTF fast 'n easy -- - 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: Linux 2.2 - BSD/OS 4.1 ARP incompatibility
just try "traceroute -s 111.111.111.111 d.e.f.2" What shows this simple test? arp who-has d.e.f.2 tell a.b.c.1 or arp who-has d.e.f.2 tell d.e.f.1 When I tried traceroute -s d.e.f.1 d.e.f.2, it worked, the first time the Linux box in question talked to the BSD/OS in question without the aid of an extra host spoofing responses to the arp queries in question. The command you suggested also had the desired effect. However... # arp -d d.e.f.2 # traceroute d.e.f.2 traceroute to d.e.f.2, 30 hops max, 40 byte packets 1 a.b.c.1 2997 ms !H 2998 ms !H 3000 ms !H (ie, failure by default) # traceroute -s d.e.f.1 d.e.f.2 traceroute to d.e.f.2 from d.e.f.1, 30 hops max, 40 byte packets 1 d.e.f.2 1 ms 0 ms 0 ms # traceroute d.e.f.2 traceroute to d.e.f.2, 30 hops max, 40 byte packets 1 d.e.f.2 1 ms 0 ms 0 ms (success, and success by default once the MAC address is known to the ARP table) # arp -d d.e.f.2 # traceroute -s 5.5.5.5 d.e.f.2 1 * * * at this point the tcpdump shows arp requests from d.e.f.1, ie, correct ARP requests. But straight command line ping and traceroute with no explicit source, and sockets which are not explicitly bound (eg, standard netkit telnet) are perhaps being auto-bound or otherwise made to choose a.b.c.1 as their for arp requests. If the announced address is d.e.f.1 then there is no problem in inet_select_addr() but your application is already bound to the primary address. It's not in the case of telnet (simple to see by strace), and I expect not in the case of traceroute with no explicit source either. However, perhaps the automatic bind is choosing the primary address. So if I want it to work I most likely need to make the ARP request ignore the higher level bindings of the socket. David. -- ------ David Luyer Senior Network Engineer Pacific Internet (Aust) Pty Ltd Phone: +61 3 9674 7525 Fax:+61 3 9699 8693 Mobile: +61 4 1064 2258, +61 4 1114 2258 http://www.pacific.net.auNASDAQ: PCNTF fast 'n easy -- - 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: Linux 2.2 - BSD/OS 4.1 ARP incompatibility
Andi Kleen wrote: > > According to the standards, who is in the wrong? To me it looks like Linux > > is the misbehaved OS in this case. > > Strictly it is your routing which is wrong, because you're giving different > routing information to BSDI and Linux. Thanks for the workaround. Unfortunately I'm not currently in the same state as the systems with this problem so I haven't yet put a kernel which will support the tools required to test the workaround on the network in question. I see that the routing tables may be the core of the problem but it looks like the problem can so simply be solved by choosing the local IP address in the subnet which you are sending the ARP request to, and this should never break anything, it only doesn't fix the case where a machine has a direct route to a network it doesn't have an interface in. Covering the situation again: network 10.0.0.0/24 in transition to 192.168.0.0/24 new machines only in 192.168.0.0/24 machine 10.0.0.1 == 192.168.0.1, Linux wants to talk to new machine 192.168.0.2, BSD/OS if eth0 = 10.0.0.1 and eth0:0 = 192.168.0.1 it sends "hi I'm 10.0.0.1 looking for 192.168.0.2" which 192.168.0.2 completely ignores (either not knowing where to send the response, or not recognising the packet as destined for itself) Now Alan's suggestion was to "fix the routing table", ie, to add a route for 10.0.0.0/24 as a direct route on the 192.168.0.2 interface. After doing this, the BSD/OS system still ignored the ARP requests! It didn't even help to add a secondary IP of 10.0.0.2. If the machine would say "hi I'm 192.168.0.1 looking for 192.168.0.2" (choosing the source IP for the arp request by the IP it is searching for) then it would just work. For comparison, both Cisco routers and BSD/OS work this way, they choose which IP to put in an ARP request based on what IP address they are looking for. Linux is the odd one out in that it always chooses the primary interface IP to put in the ARP request on a given interface. David. -- ------ David Luyer Senior Network Engineer Pacific Internet (Aust) Pty Ltd Phone: +61 3 9674 7525 Fax:+61 3 9699 8693 Mobile: +61 4 1064 2258, +61 4 1114 2258 http://www.pacific.net.auNASDAQ: PCNTF << fast 'n easy >> -- - 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/
Linux 2.2 - BSD/OS 4.1 ARP incompatibility
I'm seeing a problem between Linux 2.2 and BSD/OS 4.1 in the situation on one of our backbones. We have a number of Linux hosts on this backbone with a primary address in the network a.b.c.0/24 and a secondary address in the network d.e.f.0/24. We also have some BSD/OS 4.1 machines in this network with addresses in d.e.f.0/24 only. Now when the Linux box a.b.c.1 (with secondary address d.e.f.1) wants to talk to the BSD/OS system d.e.f.2 it does a.b.c.1 arp who-has d.e.f.2 Which d.e.f.2 promptly ignores, presumably because the IP stack in BSD/OS throws it away at a low level, or possibly simply because BSD/OS has no idea where to send the ARP response. The end result is that a.b.c.1 can't talk to d.e.f.2 because it does an ARP from the wrong IP address and doesn't get a response. Is this already fixed in 2.4 or it is something which needs investigation and a patch? According to the standards, who is in the wrong? To me it looks like Linux is the misbehaved OS in this case. David. -- -- David Luyer Senior Network Engineer Pacific Internet (Aust) Pty Ltd Phone: +61 3 9674 7525 Fax:+61 3 9699 8693 Mobile: +61 4 1064 2258, +61 4 1114 2258 http://www.pacific.net.auNASDAQ: PCNTF << fast 'n easy >> -- - 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/
Linux 2.2 - BSD/OS 4.1 ARP incompatibility
I'm seeing a problem between Linux 2.2 and BSD/OS 4.1 in the situation on one of our backbones. We have a number of Linux hosts on this backbone with a primary address in the network a.b.c.0/24 and a secondary address in the network d.e.f.0/24. We also have some BSD/OS 4.1 machines in this network with addresses in d.e.f.0/24 only. Now when the Linux box a.b.c.1 (with secondary address d.e.f.1) wants to talk to the BSD/OS system d.e.f.2 it does a.b.c.1 arp who-has d.e.f.2 Which d.e.f.2 promptly ignores, presumably because the IP stack in BSD/OS throws it away at a low level, or possibly simply because BSD/OS has no idea where to send the ARP response. The end result is that a.b.c.1 can't talk to d.e.f.2 because it does an ARP from the wrong IP address and doesn't get a response. Is this already fixed in 2.4 or it is something which needs investigation and a patch? According to the standards, who is in the wrong? To me it looks like Linux is the misbehaved OS in this case. David. -- -- David Luyer Senior Network Engineer Pacific Internet (Aust) Pty Ltd Phone: +61 3 9674 7525 Fax:+61 3 9699 8693 Mobile: +61 4 1064 2258, +61 4 1114 2258 http://www.pacific.net.auNASDAQ: PCNTF fast 'n easy -- - 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/
