Re: obsolete code must die
On Thu, 14 Jun 2001, Alan Cox wrote: > > 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 should be a FAQ entry. > > For folks doing kernel development a split tree is a nightmare to > manage so we dont bother. Nothing stops a third party splitting and > maintaining the tools to download just the needed bits for those who > want to do it that way I vaguely remember a distro shipping a kernel source tree without the non-i386 arch directories. Looked like a good idea at first - saved a fair chunk of disk space, and didn't break anything. Then you try applying a patch, and get a truckload of errors... Easier just to keep the whole thing together, IMO. James. - 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: Gigabit Intel NIC? - Intel Gigabit Ethernet Pro/1000T
On Wed, 13 Jun 2001, Ralf Baechle wrote: > On Wed, Jun 13, 2001 at 03:25:22AM -0700, Ion Badulescu wrote: > > Date: Wed, 13 Jun 2001 03:25:22 -0700 > > From: Ion Badulescu <[EMAIL PROTECTED]> > > To: Riley Williams <[EMAIL PROTECTED]> > > Cc: Shawn Starr <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, > > Alan Cox <[EMAIL PROTECTED]> > > Subject: Re: Gigabit Intel NIC? - Intel Gigabit Ethernet Pro/1000T > > > > On Tue, 12 Jun 2001 18:20:58 +0100 (BST), Riley Williams <[EMAIL PROTECTED]> wrote: > > > > > Shawn, I'd suggest you tell the said sales guy that IF he can get you > > > the FULL specs TOGETHER WITH permission to freely distribute them, AND > > > > Permission to freely distribute the specs isn't necessary, although it > > is nice indeed. All that's needed is permission to GPL the driver sources > > written using knowledge from said specs. > > Which would still be a problem. You then have a GPL'ed driver which still > cannot be sanely modified in the way the GPL would like to guarantee. That isn't a problem - the GPL doesn't attempt to guarantee users the INFORMATION needed to make sane changes, just that they have the facility to do so. Just as the kernel doesn't come with a copy of the POSIX specs, the RFCs, etc. - some of the standards the kernel implements aren't available publicly, but that doesn't stop the kernel being freely modifiable! James. - 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: 3com Driver and the 3XP Processor
On Tue, 12 Jun 2001, Pavel Machek wrote: > Hi! > > > I just had one of the "3com Etherlink 10/100 PCI NIC with 3XP processor" > > float accross my desk, I was wondering how much the linux kernel uses the > > 3xp processor for its encryption offloading and such. According to the > > hype it does DES without using the CPU, does linux take advantage of that? > > Doing DES is uninteresting these days... > > That feature is useless --- everything but IPsec does encryption at > application layer where NIC can not help. Now, if the NIC were to integrate with OpenSSL and offload some of THAT donkey work... Just offloading DES isn't terribly useful, as Pavel says: apart from anything else, DES is a bit elderly now - SSH using 3DES or Blowfish etc... How dedicated is this card? Could it be used to offload other work? James. - 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: temperature standard - global config option?
On 9 Jun 2001, H. Peter Anvin wrote: > Followup to: <[EMAIL PROTECTED]> > By author:"Albert D. Cahalan" <[EMAIL PROTECTED]> > In newsgroup: linux.dev.kernel > > > > > > But in spite of all this, you're not really measure the critical > > > temperature, which is junction tempature. Yes, case tempature has *some* > > > > There are processors with temperature measurement built right > > into the silicon. > > As far as I know, ALL current microprocessors do. The current x86 setup uses a small sensor sitting under the CPU socket. Intel's more recent output does have a heat sensor of its own, for thermal protection purposes - presumably this is exported to the chipset - but older ones don't appear to... James. - 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: Please help me fill in the blanks.
On Sat, 26 May 2001, Jeff Garzik wrote: > Cesar Da Silva wrote: > > The features that I'm wondering about are: > > * Dynamic Processor Resilience > > is this fault tolerance? I think if a CPU croaks, you are dead. > > There are patches for hot swap cpu support, but I haven't seen any CPU > fault tolerance patches that can handle a dead processor The S/390 has this; presumably it applies to Linux as well as the other supported OSs? > > * Dynamic Memory Resilience > > RAM fault tolerance? There was a patch a long time ago which detected > bad ram, and would mark those memory clusters as unuseable at boot. > However that is clearly not dynamic. > > If your memory croaks, your kernel will experience random corruptions ECC can be supported by the hardware; no support for mapping out duff banks on x86, but again S/390 may differ? > > * Live Upgrade > > LOBOS will let one Linux kernel boot another, but that requires a boot > step, so it is not a live upgrade. so, no, afaik Live SOFTWARE upgrade, or live HARDWARE upgrade? If the latter, things like hotswap PCI, USB... and again the S/390? > > * Service Location Protocol (SLP) > > don't know Yes, I think so - mars_nwe surely needs this? > > * TCP/IP Gratuitous ARP (RFC 2002) > > not sure Isn't that how LVS clusters handle IP takeovers? > > * Path MTU Discovery (RFC 1191) > > yes With one or two RFC violations, yes. Basically, most of those features relating to hardware resilience should be usable with Linux on an S/390 - they are hardware features, though, AFAICS? James. - 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: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h
On Fri, 25 May 2001, Adam J. Richter wrote: > Larry McVoy wrote: > >On Fri, May 25, 2001 at 07:34:57PM -0700, Adam J. Richter wrote: > >It's also about the concept of boundaries - if you think that that > >concept is not a legal one then why aren't all programs which are run > >on top of a GPLed kernel then GPLed? > > Apparently Linus felt that that was a sufficiently > plausible gray area that he addressed it explicitly in > /usr/src/linux/COPYING: > > | NOTE! This copyright does *not* cover user programs that use kernel > | services by normal system calls - this is merely considered normal use > | of the kernel, and does *not* fall under the heading of "derived work". > | Also note that the GPL below is copyrighted by the Free Software > | Foundation, but the instance of code that it refers to (the Linux > | kernel) is copyrighted by me and others who actually wrote it. Note the "derived work"; there is no way on this earth (or any other) that you could regard the device's firmware as being a "derived work" of the driver! AFAICS, the firmware is just a file served up to the device as needed - no more a derivative work from the kernel than my homepage is a derivative work of Apache. James. - 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: LILO and serial speeds over 9600
On Sat, 17 Feb 2001, Patrick Michael Kane wrote: > * Pavel Machek ([EMAIL PROTECTED]) [010217 05:40]: > > Being able to remotely resed machine with crashed userland would be > > *very* nice, too... > > If it provides a true remote console, enable SYSRQ and youi should get this > for free. Yes, it should work fine. Of course, there's always the risk you'll connect to the crashed box from your machine, then hit Alt+SysRq+B, and say rude things as YOUR machine reboots... :-) James. - 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 stifles innovation...
On Fri, 16 Feb 2001, Michael H. Warfield wrote: > On Fri, Feb 16, 2001 at 04:35:02PM -0800, Dan Hollis wrote: > > On Fri, 16 Feb 2001, Carlos Fernandez Sanz wrote: > > > I did some research on the patent database and found nothing regarding such > > > a patent. There's patent on word processors (not the concept but related to) > > > and uses tab on the description...and that patent is from 1980. > > > You know XOR is patented (yes, the logical bit operation XOR). > > But wasn't that Xerox that had that? Yeah, the same ones that > screwed us over with the compression patent that shot .gif images out > of the sky. There was inovation for you. That was Unisys, and it is certainly more innovative than XOR. (Or even FFT, which is also now patented in one form...) James. - 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 stifles innovation...
On Fri, 16 Feb 2001, Carlos Fernandez Sanz wrote: > I did some research on the patent database and found nothing regarding such > a patent. There's patent on word processors (not the concept but related to) > and uses tab on the description...and that patent is from 1980. Perhaps that's it, then. Or maybe the story is a little distorted. No doubt you've spotted that IBM does have quite a significant portfolio of patents, though! James. - 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 stifles innovation...
On Fri, 16 Feb 2001, David D.W. Downey wrote: > Would someone tell me where you get all this lovely information on > patents held by M$? I can't find anything. Sorry, it's *IBM* who are said to hold a patent on the tab key. Legend has it Microsoft once found a patent of theirs which IBM appeared to have infringed, and were very excited at the possibility of something to hold over IBM, so their lawyers met IBM's lawyers. The MS lawyers beamed "look at our patent you've infringed!" IBM's lawyers replied "look at this pile of our patents YOU'VE infringed... let's start with this one. A Tab key." MS suddenly realised they were outlawyered... No idea how accurate it is, but just the thought of MS's lawyers getting a nasty shock like that has a certain appeal :-) James. - 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 stifles innovation...
On Fri, 16 Feb 2001, Rik van Riel wrote: > On Thu, 15 Feb 2001, Alan Olsen wrote: > > > I expect the next thing that will happen is that they will get > > patents on key portions of their protocols and then start > > enforcing them. > > If Microsoft would start pissing off IBM and other major > companies which have big business interests in Linux by > invoking their patents, I can just imagine IBM coming down > on Microsoft with their own patents ... > > "Hey you! Stop flipping those bits! Hold it right there! > ... Don't you flip any more bits, read this patent first..." > > (and I'm sure they must have patents on _setting_ bits as > well ;)) Apparently they DO have a patent on the tab key - you thought Amazon's "one click shopping" patent was bad?! James. - 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: 8139 full duplex?
On Fri, 16 Feb 2001, Rogier Wolff wrote: > Jeff Garzik wrote: > > On Fri, 16 Feb 2001, Rogier Wolff wrote: > > > I have a bunch of computers with 8139 cards. When I moved the cables > > > over from my hub to my new switch all the "full duplex" lights came on > > > immediately. > > > > > > Would this mean that the driver/card already were in full-duplex? That > > > would explain me seeing way too many collisions on that old hub (which > > > obviously doesn't support full-duplex). > > > > > > (Some machines run 2.2 kernels, others run 2.4 kernels some run the > > > old driver, others run the 8139too driver). > > > > Some versions of the driver bork the LED register, which may lead to > > false assumptions. > > Does the driver control the led on my switch? No, the switch does that. > (My cards just have a "link" led, and a "100Mbps" led) Ah... Mine have an FD indicator. I think - it's a while since I last looked closely enough at the back of the machine to tell :) > I'm not going back to the hub after upgrading just to see the > changeover messages. I'm confident that we're running full-duplex now > on the switch and that that's OK with the switch. I was just wondering > wether this confirmed my suspicion that there was something wrong with > the /duplexicity/. I suppose one machine could have auto-negotiated wrongly - was it a Linux box? I've seen Win2k fail to negotiate the best settings - running HD on a switch - but I haven't seen FD on a hub... James. - 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: 8139 full duplex?
On Fri, 16 Feb 2001, Rogier Wolff wrote: > James Sutherland wrote: > > > That would explain me seeing way too many collisions on that old hub > > > (which obviously doesn't support full-duplex). > > > > No, it would just prevent your card working. Large numbers of collisions > > are normal during fast transfers across a hub. > > Why would it completely "not work"? It wouldn't be able to detect collisions, I suspect; you might be able to get data through, though. Not something I've ever wanted to try :-) > As long as the host doesn't have something to send while a recieve is > in progress, everything should work. A friend reports that he spent > lots of time trying to debug a network where "too many" collisions > were happening. Turns out one card was in full-duplex, while the other > side wasn't. On a crossover cable direct between two machines, that would make sense: you would WANT both cards full duplex, but if one ran half duplex instead, it would think it was getting a huge number of collisions when it wasn't... > I benchmarked my old network at 10-12 seconds for a 100Mb > transfer. That sounds indeed as if there isn't a whole lot of > collisions happening. And I can immagine that the acks run into the > next data-packet all the time, so that performance would indeed be > very bad if the card was misconfigured. On the other hand I had one > machine that was taking 180 seconds for the 100Mb transfer. Ouch! Remember each collision only knocks out a few hundred bytes - perhaps 1.5K - so even hundreds of collisions per second only knock a few hundred K/sec off a transfer rate of ten Mbyte/sec or so. > Anyway, I remember fiddling with the eexpress 100 driver, and there > the driver was involved in switching the speeds, and doing some > management of the switchover of full-duplex/half-duplex. I'd expect > some message from the driver if it saw such a change. > > But you're saying that the 8139 chip does it internally, and fully > automatically? Ok. Good. Well, mine do anyway :-) (Except under the Win2k bug, where I needed to force the link to 100 Mbit/sec full duplex...) James. - 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 stifles innovation...
On Fri, 16 Feb 2001, Helge Hafting wrote: > They are wrong about linux stifling innovation, there is plenty of > innovation in linux itself. Indeed. If Linux did nothing new, what do they have to fear?! > On the other hand: > ''I can't imagine something that could be worse than this > for the software business and the intellectual-property business.'' Linux IS (part of) the software business, though! That's like saying Walmart is bad for shops - it is bad for OTHER, COMPETING shops. > Sure. Linux *is* bad for the IP business. Open source outcompetes it! Eh? Linux IS intellectual property! OK, those in the OSS community are rather less litigious AFAICS, which is bad for IP *lawyers* - in much the same way antibiotics are "bad" for diseases... > I see no problem with that though. And those who want to get > paid for computing work? No problem. There is always support. Hrm. Getting paid to write code is preferable, IMHO... James. - 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: 8139 full duplex?
On Fri, 16 Feb 2001, Rogier Wolff wrote: > > Hi All, > > I have a bunch of computers with 8139 cards. When I moved the cables > over from my hub to my new switch all the "full duplex" lights came on > immediately. That's what you would expect: they will auto-negotiate full duplex, in the same way they would negotiate 10 or 100 Mbit/sec. > Would this mean that the driver/card already were in full-duplex? No, that's not possible. They just automatically configured for the best performance available - in this case, full duplex. > That would explain me seeing way too many collisions on that old hub > (which obviously doesn't support full-duplex). No, it would just prevent your card working. Large numbers of collisions are normal during fast transfers across a hub. James. - 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] 2.4.2-pre3: parport_pc init_module bug
On Wed, 14 Feb 2001, Jeff Garzik wrote:
> On Tue, 13 Feb 2001, Tim Waugh wrote:
> > Here's a patch that fixes a bug that can cause PCI driver list
> > corruption. If parport_pc's init_module fails after it calls
> > pci_register_driver, cleanup_module isn't called and so it's still
> > registered when it gets unloaded.
>
> > --- linux/drivers/parport/parport_pc.c.init Tue Feb 13 23:31:25 2001
> > +++ linux/drivers/parport/parport_pc.c Tue Feb 13 23:35:56 2001
> > @@ -89,6 +89,7 @@
> > } superios[NR_SUPERIOS] __devinitdata = { {0,},};
> >
> > static int user_specified __devinitdata = 0;
> > +static int registered_parport;
> >
> > /* frob_control, but for ECR */
> > static void frob_econtrol (struct parport *pb, unsigned char m,
> > @@ -2605,6 +2606,7 @@
> > count += parport_pc_find_nonpci_ports (autoirq, autodma);
> >
> > r = pci_register_driver (&parport_pc_pci_driver);
> > + registered_parport = 1;
> > if (r > 0)
> > count += r;
>
> Bad patch. It should be
>
> if (r >= 0) {
> registered_parport = 1;
> if (r > 0)
> count += r;
> }
The second "if" is redundant here: if r==0, count+=r has no effect. I
don't think gcc would spot that on optimization, would it??
James.
-
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: Is this the ultimate stack-smash fix?
On Tue, 13 Feb 2001, Jeremy Jackson wrote: (Long description of how to create a non-executable stack on x86) I'm afraid you just reinvented the wheel. The idea has been around for a long time, and it was OK as a quick hack to stop existing exploits working, but it's possible to modify a buffer overflow exploit to work around this. It does sound look like a good idea, but it doesn't really gain you anything in the long run: the exploits just change a bit. ISTR there is a patch which does this for Linux, though?? James. - 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: LILO and serial speeds over 9600
On Tue, 13 Feb 2001, Russell King wrote: > James Sutherland writes: > > If the kernel starts spewing data faster than you can send it to the far > > end, either the data gets dropped, or you block the kernel. Having the > > kernel hang waiting to send a printk to the far end seems like a bad > > situation... > > It can actually be useful. Why? Lets take a real life example: the > recent IDE multi-sector write bug. > > In that specific case, I was logging through one 115200 baud serial port > the swapin activity (in do_swap_page), the swap out activity (in > try_to_swap_out), as well as every IDE request down to individual buffers > as they were written to/read from the drive. This produces a rather a > lot of data, far faster than a 115200 baud serial port can send it. > > The ability then to run scripts which can interpret the data and > pick out errors (eg, we swap in data that is different from the data > that was swapped out) was invaluable for tracking down the problem. > > Had messages been dropped, this would not have been possible or would > have indicated false errors. Blocking the kernel while debug stuff > was sent was far more preferable to loosing messages in this case. > I would imagine that that is also true for the majority of cases as > well. OK, in this particular case you need to log EVERYTHING for diagnostic purposes. In most cases, though, I'd rather have some messages dropped than have the machine slow to a crawl... Would you be OK with a "blocking netconsole" option, to provide this behavious where needed? If it's the default, I bet the next Mindcraft tests will be run with verbose logging on a 9600bps link :-) Most people wouldn't need/want this, but I can see it would be useful: giving the user this choice seems a better option. Also, losses on a 10 or 100 Mbit/sec Ethernet connection will be rather less likely than they could on a serial link! James. - 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: LILO and serial speeds over 9600
On Tue, 13 Feb 2001, Alan Cox wrote: > > That's the whole crux of the matter. For something like this, you *will* > > drop data under certain circumstances. I suspect it's better to have > > this done in a controlled manner, rather than stop completely, which is > > what TCP would do. > > Why do you plan to drop data ? That seems unneccessary. If the kernel starts spewing data faster than you can send it to the far end, either the data gets dropped, or you block the kernel. Having the kernel hang waiting to send a printk to the far end seems like a bad situation... James. - 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: LILO and serial speeds over 9600
On Mon, 12 Feb 2001, H. Peter Anvin wrote: > James Sutherland wrote: > > > > > > Depends on what the client can handle. For the kernel, that might be > > > true, but for example a boot loader may only have a few K worth of buffer > > > space. > > > > Fortunately, the bulky stuff (printk's from the booting kernel) will be > > going from the boot loader to the server, and should be buffered there > > OK until they can be processed. Only the stuff sent to the client will > > need buffering, and that should be simple keystrokes... > > Well, any time there is a network there needs to be buffering, if you > want to have any kind of ACK protocol. Yes, but only the last packet sent, if you limit to one packet at a time... Shouldn't be a problem, even for the smallest code. James. - 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://vger.kernel.org/lkml/
Re: LILO and serial speeds over 9600
On Mon, 12 Feb 2001, H. Peter Anvin wrote: > Alan Cox wrote: > > > > > > Explain 'controlled buffer overrun'. > > > > > > That's probably the ability to send new data even if there's unacked old > > > data (e.g. because the receiver can't keep up or because we've had losses). > > > > Well let me see, the typical window on the other end of the connection if > > its a normal PC class host will be 32K. I think that should be sufficient. > > Depends on what the client can handle. For the kernel, that might be > true, but for example a boot loader may only have a few K worth of buffer > space. Fortunately, the bulky stuff (printk's from the booting kernel) will be going from the boot loader to the server, and should be buffered there OK until they can be processed. Only the stuff sent to the client will need buffering, and that should be simple keystrokes... James. - 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://vger.kernel.org/lkml/
Re: LILO and serial speeds over 9600
On Mon, 12 Feb 2001, H. Peter Anvin wrote: > James Sutherland wrote: > > > My thinking at the moment is to require kernel IP configuration (either > ip= or RARP/BOOTP/DHCP). It seems to be the only practical way; > otherwise you miss too much at the beginning. However, that mechanism is > already in place, and shouldn't be too hard to piggy-back on. Yes: that should be easy enough, specially DHCP and ip=. > > I'll do a server to receive these sessions - simple text (no vt100 etc), > > one window per session - and work on the protocol spec. Anyone willing > > to do the client end of things - lilo, grub, kernel, etc?? > > I'll do PXELINUX, for sure. I'd prefer to do the protocol spec, if you > don't mind -- having done PXELINUX I think I know the kinds of pitfalls > that you run into doing an implementation in firmware or firmware-like > programming (PXELINUX isn't firmware, but it might as well be.) Fine by me: we seem to agree on the basic concept already, and there isn't going to be very much protocol involved! > Doing it in LILO would be extremely difficult, since LILO has no ability > to handle networking, and no reasonable way to graft it on (you need a > driver for networking.) GRUB I can't really comment on. I haven't seen much of GRUB, but it does seem to have DHCP support, so it must have some facility for sending/receiving packets. LILO's command-line approach would be better suited to this, really, though... > I might just decide to do the kernel as well. > > Hmmm... this sounds like it's turning into a group effort. Would you (or > someone else) like to set up a sourceforge project for this? I would > prefer not to have to deal with that end myself. OK, I've filled in the paperwork - we should have a project account sometime tomorrow. I put the license type as "Other", since the heart of the project is the protocol, and patches to add support to the kernel, FreeBSD etc. will have to be under the license of the OS in question. Title: "Network Console Protocol" for now? James. - 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://vger.kernel.org/lkml/
Re: LILO and serial speeds over 9600
On Mon, 12 Feb 2001, Alan Cox wrote: > > > I have toyed a few times about having a simple Ethernet- or UDP-based > > > console protocol (TCP is too heavyweight, sorry) where a machine would > > > seek out a console server on the network. Anyone has any ideas about > > > it? > > > > Excellent plan: data centre sysadmins the world over will worship your > > name if it works... > > Sounds like MOP on the old Vaxen. TCP btw isnt as heavyweight as people > sometimes think. You can (and people have) implemented a simple TCP client > and IP and SLIP in 8K of EPROM on a 6502. There is a common misconception > that a TCP must be complex. > > All you actually _have_ to support is receiving frames in order, sending one > frame at a time when the last data is acked and basic backoff. You dont have > to parse tcp options, you dont have to support out of order reassembly. It's not a huge undertaking, I know, but UDP will probably still be a bit simpler. Turn the question around: would using TCP bring any real benefits, in a system which will only be used to shift a few kb each boot time? At a later date, perhaps TCP could be used - it would certainly make sense for the kernel-side code: once you have a fully-fledged IP stack, why not use it. There's no reason the server couldn't support both, and machines would just use whichever was more appropriate at the time. James. - 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://vger.kernel.org/lkml/
Re: LILO and serial speeds over 9600
On 12 Feb 2001, H. Peter Anvin wrote: > Followup to: <[EMAIL PROTECTED]> > By author:Ivan Passos <[EMAIL PROTECTED]> > In newsgroup: linux.dev.kernel > > > > Since I still want to add support for speeds up to 115200, the other two > > questions are still up (see below): > > > > > - If not, do I need to change just LILO to do that, or do I need to change > > > the kernel as well (I don't think I'd need to do that too, as the serial > > > console kernel code does support up to 115.2Kbps, but it doesn't hurt to > > > ask ... ;) ?? > > > - Does another bootloader (e.g. GRUB) support serial speeds higher than > > > 9600bps?? If so, which one(s)?? > > > > I'd really appreciate any help. > > > > SYSLINUX supports up to 57600 (it doesn't support 115200 because it > stores the number in a 16-bit register) but seriously... why the heck > does this matter? It isn't booting the kernel off the serial line, > you know. A console at 38400 is really quite sufficient... if you > need something more than that, you probably should be logging in via > the network. > > I have toyed a few times about having a simple Ethernet- or UDP-based > console protocol (TCP is too heavyweight, sorry) where a machine would > seek out a console server on the network. Anyone has any ideas about > it? Excellent plan: data centre sysadmins the world over will worship your name if it works... What exactly do you have in mind: a bidirectional connection you could use to control everything from LILO/Grub onwards? Should be feasible, anyway. I'd go with UDP for this, rather than raw Ethernet. Use DHCP to get the IP address(es) to connect to as console hosts? (That or a command line option...) The first thing is the kernel: just wrap around printk so as soon as eth0 is up, you set up a session and start sending packets. I'll do a server to receive these sessions - simple text (no vt100 etc), one window per session - and work on the protocol spec. Anyone willing to do the client end of things - lilo, grub, kernel, etc?? James. - 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://vger.kernel.org/lkml/
Re: making forward at vger.rutgers.org? [was Re: maestro3 patch,resent]
On Sun, 11 Feb 2001, Pavel Machek wrote: > Hi! > > > duh. I sent this to rutgers originally.. > > I'm doing same mistake over and over. > > Perhaps creating forward at vger.rutgers.edu would be good thing (tm)? Apparently the rutgers.edu people didn't like this idea... If they'd been feeling that helpful, they could have made the MX for vger.rutgers.edu point to the new server and made the transition transparent. It seems they weren't - no idea why, though. James. - 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: [OT] Major Clock Drift
On Mon, 12 Feb 2001, Alan Cox wrote: > > > queued_writes=1; > > > return; > > > > Just what happens when you run out of dmesg ring in an interrupt ? > > You lose a couple of lines. Big deal. I'd rather lose two lines a year on > a problem (and the dmesg ring buffer is pretty big) than two minutes an hour > every hour for the entire running life of the machine Also, you should know when the ring overflows, and be able to indicate this: it will be clear when and where messages were lost? James. - 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: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait
On Thu, 8 Feb 2001, Rik van Riel wrote: > On Thu, 8 Feb 2001, Mikulas Patocka wrote: > > > > > You need aio_open. > > > Could you explain this? > > > > If the server is sending many small files, disk spends huge > > amount time walking directory tree and seeking to inodes. Maybe > > opening the file is even slower than reading it > > Not if you have a big enough inode_cache and dentry_cache. Eh? However big the caches are, you can still get misses which will require multiple (blocking) disk accesses to handle... > OTOH ... if you have enough memory the whole async IO argument > is moot anyway because all your files will be in memory too. Only for cache hits. If you're doing a Mindcraft benchmark or something with everything in RAM, you're fine - for real world servers, that's not really an option ;-) Really, you want/need cache MISSES to be handled without blocking. However big the caches, short of running EVERYTHING from a ramdisk, these will still happen! James. - 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: freshmeat editorial on journaling filesystems
On Tue, 6 Feb 2001, Ray Strode wrote: > >We'd like to run an editorial this coming Saturday about the > >journaling filesystems available for Linux. We'd like an author who > >isn't a developer on any of them so he/she can give an object analysis > >of the pros and cons of each and share thoughts on his/her opinions > >about which should be eventually be supported by the kernel. > I disagree. I think you should ask someone who works on more than > one of the filesystems. That person will know the pros and cons of all > of them, and surely will be objective. Either that, or have a developer from each talking about their own FS, and how they think it compares to others. Then an impartial summary of what each has said. James. - 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: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)
On Mon, 5 Feb 2001, Hans Reiser wrote: > Alan Cox wrote: > > > > > In an __init function, have some code that will trigger the bug. > > > This can be used to disable Reiserfs if the compiler was bad. > > > Then the admin gets a printk() and the Reiserfs mount fails. > > > > Thats actually quite doable. I'll see about dropping the test into -ac that > > way. > NO!! It should NOT fail at mount time, it should fail at compile time. A simple "make test" to run this sort of automated sanity check would be good, I think? James. - 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: Better battery info/status files
On Mon, 5 Feb 2001, Steve Underwood wrote:
> James Sutherland wrote:
> > On Sun, 4 Feb 2001, Ben Ford wrote:
> > > David Woodhouse wrote:
> > > > On Sun, 4 Feb 2001, James Sutherland wrote:
> > > >
> > > > > For the end-user, the ability to see readings in other units would be
> > > > > useful - how many people on this list work in litres/metres/kilometres,
> > > > > and how many in gallons/feet/miles? Probably enough in both groups that
> > > > > neither could count as universal...
> > > >
> > > > Yeah. We can have this as part of the locale settings, changable by
> > > > echoing the desired locale string to /proc/sys/kernel/lc_all.
> > >
> > > Just an idea, . . but isn't this something better done in userland?
> > >
> > > (ben@Deacon)-(06:49am Sun Feb 4)-(ben)
> > > $ date +%s
> > > 981298161
> > > (ben@Deacon)-(06:49am Sun Feb 4)-(ben)
> > > $ date +%c
> > > Sun Feb 4 06:49:24 2001
> >
> > That's what I'd do, anyway - /dev/pieceofstring would return the length of
> > said piece of string in some units, explicityly stated. (e.g. "5m" or
> > "15ft").
> >
> > "uname -s" ("how long's a piece of string on this system") would then
> > convert the length into feet, metres or fathoms, depending on what the
> > user prefers.
>
> Don't get carried away. In the present context we are only talking about
> time and electrical measurements. Whilst most of the human race can't
> read the English labels in /proc, they all use the same measurements for
> electrical units and time (unless the time exceeds 24 hours, where dates
> get a bit screwed up). In this case even the US in in line with the rest
> of humanity. or would you like to be able to express battery
> capacity in BTUs?
Personally, I'd prefer a percentage and/or estimated time remaining
anyway... However, from the kernel's PoV, the rule is just "KISS". Print
in something consistent, let userspace do any conversions you
want. Probably seconds for time (simplest - scripts can compare "if
est_batterylife_remaining < 300 do something", UI things can convert to
H:M:S or whatever), watts for power.
What is measured, BTW - battery voltage, presumably, and drain
current?
James.
-
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: Better battery info/status files
On Sun, 4 Feb 2001, Ben Ford wrote:
> David Woodhouse wrote:
>
> > On Sun, 4 Feb 2001, James Sutherland wrote:
> >
> > > For the end-user, the ability to see readings in other units would be
> > > useful - how many people on this list work in litres/metres/kilometres,
> > > and how many in gallons/feet/miles? Probably enough in both groups that
> > > neither could count as universal...
> >
> > Yeah. We can have this as part of the locale settings, changable by
> > echoing the desired locale string to /proc/sys/kernel/lc_all.
> >
> > -
>
> Just an idea, . . but isn't this something better done in userland?
>
> (ben@Deacon)-(06:49am Sun Feb 4)-(ben)
> $ date +%s
> 981298161
> (ben@Deacon)-(06:49am Sun Feb 4)-(ben)
> $ date +%c
> Sun Feb 4 06:49:24 2001
That's what I'd do, anyway - /dev/pieceofstring would return the length of
said piece of string in some units, explicityly stated. (e.g. "5m" or
"15ft").
"uname -s" ("how long's a piece of string on this system") would then
convert the length into feet, metres or fathoms, depending on what the
user prefers.
James.
-
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: Better battery info/status files
On Sat, 3 Feb 2001, Russell King wrote: > Albert D. Cahalan writes: > > The units seem to vary. I suggest using fundamental SI units. > > That would be meters, kilograms, seconds, and maybe a very > > few others -- my memory fails me on this. > > iirc, SI comes from France, and therefore it should be "metres" Yes. Quite why a distance matters to the battery is another question, though... For the end-user, the ability to see readings in other units would be useful - how many people on this list work in litres/metres/kilometres, and how many in gallons/feet/miles? Probably enough in both groups that neither could count as universal... James. - 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: sendfile+zerocopy: fairly sexy (nothing to do with ECN)
On Fri, 2 Feb 2001, David Lang wrote: > Thanks, that info on sendfile makes sense for the fileserver situation. > for webservers we will have to see (many/most CGI's look at stuff from the > client so I still have doubts as to how much use cacheing will be) CGI performance isn't directly affected by this - the whole point is to reduce the "cost" of handling static requests to zero (at least, as close as possible) leaving as much CPU as possible for the CGI to use. So sendfile won't help your CGI directly - it will just give your CGI more resources to work with. James. - 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: [reiserfs-list] Re: ReiserFS Oops (2.4.1, deterministic, symlink
On Sat, 3 Feb 2001, Hans Reiser wrote: > Alan Cox wrote: > > > > > It makes sense to refuse to build a piece of the kernel if it break's > > > a machine - anything else is a timebomb waiting to explode. > > > > The logical conclusion of that is to replace the entire kernel tree with > > > > #error "compiler or program might have a bug. Aborting" > > No, this is a compiler that DOES have a bug. ReiserFS is, as best as > I can make it, for mission critical servers where some sysadmin > doesn't want to explain it to the CEO. There are plenty of ways that > I fail at this, but not intentionally. Yep. For once, I agree with Hans here: if you *KNOW* the current compiler is fatally broken, the best thing to do is blow up. As hard as possible, as soon as possible. Anything else is just hiding the problem. (snip) > My design objective in ReiserFS is not to say that it wasn't my fault > they had that bug because they are so ignorant about a filesystem that > really isn't very important to them unless it screws up. My design > objective is to ensure they don't have that bug. They are more > important than me. Hrm... better idiot-proofing just tends to produce better idiots. > > The kernel is NOT some US home appliance festooned with 'do not eat this > > furniture' and 'do not expose your laserwrite to naked flame' messages. > > The readme says its been tested with egcs-1.1.2 and gcc 2.95. Hrm. Ever wonder which country Alan lives in? :-) (Alan: Visit the next McDonalds you pass, and buy a coffee. Look at the warning on the side about the coffee being hot... then complain it isn't, after a suitable delay...) > > Large numbers of people routinely build the kernel with 'unsupported' compilers > > notably the pgcc project people and another group you will cause problems for > > - the GCC maintainers. They use the kernel tree as part of the test set for > > their kernel, something putting #ifdefs all over it will mean they have to > > mess around to fix too. If it's specific enough to that particular gcc, it won't trip the gcc people up - unless they're really using that specific version, in which case it SHOULD blow up anyway! > A moment of precision here. We won't test to see if the right > compiler is used, we will just test for the wrong one. Which is fine, IMO. "Warning: your compiler MIGHT be broken - please look at README" is OK, as is "Error: this compiler *IS* broken - it's gcc X.XX, which we know is broken because (foo)". "Error: this compiler looks like version foo, which we think might be broken" isn't, as Alan says... James. - 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: reiserfs min size (was: [2.4.1] mkreiserfs on loopdevice freezeskernel)
On Wed, 31 Jan 2001, Bernd Eckenfels wrote: > On Wed, Jan 31, 2001 at 09:24:39AM +0000, James Sutherland wrote: > > 32 megaBLOCK?? How big is it in Mbytes? > > Blocksize is 4k, mkreiserfs in my version is telling me it can not generate > partitions smaller than 32M but it is not true, i have to do > > dd if=/dev/zero of=/var/loop.img count=32768 size=4096 That just creates a 128Mb file of zeros... This sounds a bit small. Why "size=4096"?? > > You do know reiserfs defaults to > > building a 32 Mbyte journal on the device, I take it? > > Yes, I wonder if it is a Error in mkreiserfs to require 128MB. Have you tried using a smaller blocksize to mkreiserfs? James. - 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: BUG
On Wed, 31 Jan 2001, Grzegorz Sojka wrote: > I am using kernel v2.4.0 on Abit BP6 with two Intel Pentium Celeron > 366@517Mhz + video based on Riva TNT2 M64 32Mb + network card 3com 3c905b > + Creative Sound Blaster 64 pnp isa and hercules video card. I'm geting > all over the time messages like that: > Jan 31 23:37:16 Zeus kernel: APIC error on CPU0: 02(02) > Jan 31 23:37:17 Zeus kernel: APIC error on CPU1: 02(08) > Jan 31 23:37:26 Zeus kernel: APIC error on CPU1: 08(08) > Jan 31 23:37:26 Zeus kernel: APIC error on CPU1: 08(08) > Jan 31 23:37:26 Zeus kernel: APIC error on CPU0: 02(04) > Jan 31 23:37:27 Zeus kernel: APIC error on CPU0: 04(02) > Jan 31 23:37:30 Zeus kernel: APIC error on CPU1: 08(08) > Jan 31 23:38:17 Zeus kernel: APIC error on CPU0: 02(08) > Jan 31 23:38:20 Zeus kernel: APIC error on CPU1: 08(08) > Jan 31 23:38:22 Zeus kernel: APIC error on CPU0: 08(02) > Jan 31 23:38:26 Zeus kernel: APIC error on CPU1: 08(08) > Jan 31 23:38:26 Zeus kernel: APIC error on CPU0: 02(02) > Jan 31 23:38:29 Zeus kernel: APIC error on CPU1: 08(02) > Jan 31 23:38:41 Zeus kernel: APIC error on CPU1: 02(08) > Jan 31 23:38:51 Zeus kernel: APIC error on CPU0: 02(02) > Jan 31 23:38:58 Zeus kernel: APIC error on CPU1: 08(08) > Jan 31 23:39:15 Zeus kernel: APIC error on CPU1: 08(02) > Jan 31 23:39:15 Zeus kernel: APIC error on CPU1: 02(08) > Jan 31 23:39:15 Zeus kernel: APIC error on CPU0: 02(04) > Jan 31 23:39:17 Zeus kernel: APIC error on CPU1: 08(08) > Jan 31 23:39:18 Zeus kernel: APIC error on CPU1: 08(02) > Jan 31 23:39:46 Zeus kernel: APIC error on CPU0: 04(02) > And when I was using kernels v2.2.x ther was no such messages. I am > wandering if it is hardware or software problem? Hardware problem. You don't SEE these messages on 2.2 because it doesn't tell you about them :-) (These are common, but fairly harmless FWIH, on BP6s.) James. - 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: CPU error codes
On Wed, 31 Jan 2001, Alan Cox wrote: > > > In the intel databook. Generally an MCE indicates hardware/power/cooling > > > issues > > > > Doesn't an MCE also cover some hardware memory problems - parity/ECC > > issues etc? > > Parity/ECC on main memory is reported by the chipset and needs seperate > drivers or apps to handle this Yes - MCE only covers errors in the CPU's cache, IIRC? (Is there still an NMI on main memory parity errors, or has this changed on modern chipsets? Presumably ECC is handled differently, being recoverable??) James. - 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: Version 2.4.1 cannot be built.
On Wed, 31 Jan 2001, Richard B. Johnson wrote: > On Wed, 31 Jan 2001, Rik van Riel wrote: > > On Wed, 31 Jan 2001, Richard B. Johnson wrote: > > > On Tue, 30 Jan 2001, Rik van Riel wrote: > > > > On Tue, 30 Jan 2001, Richard B. Johnson wrote: > > > > > > > > > The subject says it all. `make dep` is now broken. > > > > > > > > It worked fine here, with 2.4.1 unpacked from the tarball. > > > > > > I cannot find the source for GNU Make 3.77+ > > > > I have a hard time believing that you don't have > > the skills to go to ftp.gnu.org and download the > > stuff... > > > > Now just a cotton-picken minute. When was the last time you > accessed that site? I spent most of last night looking through > EMPTY directories with files that are invisible to ftp but > (sometimes) show with their `ls`, and never with nlist. > > Maybe you can still download stuff if you are running from a > Web Crawler, but it doesn't work with `ftp` anymore. Works fine for me with "ftp"... Passive FTP is incredibly slow, though... James. - 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: Request: increase in PCI bus limit
On Tue, 30 Jan 2001, Timur Tabi wrote: > ** Reply to message from Christopher Neufeld <[EMAIL PROTECTED]> on Tue, 30 > Jan 2001 16:08:32 -0800 > > > > Would it be possible to bump it up to 128, or even > > 256, in later 2.4.* kernel releases? That would allow this customer to > > work with an unpatched kernel, at the cost of an additional 3.5 kB of > > variables in the kernel. > > I don't think that's going to happen. If we did this for your obscure system, > then we'd have to do it for every obscure system, and before you know it, the > kernel is 200KB larger. > > Besides, why is your client afraid of patched kernels? It sounds like a very > odd request from someone with a linuxcare.com email address. I would think that > you'd WANT to provide patched kernels so that the customer can keep paying you > (until they learn how to use a text editor, at which point they can patch the > kernel themselves!!!) Should there not at least be some bounds checking on this table, though?! If it's only built at boot time, it's not performance critical. Maybe at a later date it could even expand (or shrink, on small PCs??) the table as needed? James. - 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 Disk Performance/File IO per process
On Mon, 29 Jan 2001, List User wrote: > Just wanted to 'chime' in here. Yes this would be noisy and will have > an affect on system performance however these statistics are what are > used in conjunction with several others to size systems as well as to > plan on growth. If Linux is to be put into an enterprise environment > these types of statistics will be needed. > > When you start hooking up 100's of 'physical volumes' (be it real > disks or raided logical drives) this data helps you pin-point > problems. I think the idea of having the ability to turn such > accounting on/off via /proc entry a very nice method of doing things. Question: how will the extra overhead of checking this configuration compare with just doing it anyway? If the code ends up as: if (stats_enabled) counter++; then you'd be better off keeping stats enabled all the time... Obviously it'll be a bit more complex, but will the stats code be able to remove itself completely when disabled, even at runtime?? Might be possible with IBM's dprobes, perhaps...? > That way you can leave it off for normal run-time but when users > complain or DBA's et al you can turn it on get some stats for a couple > hours/days whatever, then turn it back off and plan an upgrade or > re-create a logical volume or stripping set. NT allows boot-time (en|dis)abling of stats; they quote a percentage for the performance hit caused - 4%, or something like that?? Of course, they don't say whether that's a 486 on a RAID array or a quad Xeon on IDE, so the accuracy of that figure is a bit questionable... James. - 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: ECN: Clearing the air (fwd)
On Sun, 28 Jan 2001, jamal wrote: > On Sun, 28 Jan 2001, James Sutherland wrote: > > On Sun, 28 Jan 2001, jamal wrote: > > > There were people who made the suggestion that TCP should retry after a > > > RST because it "might be an anti-ECN path" > > > > That depends what you mean by "retry"; I wanted the ability to attempt a > > non-ECN connection. i.e. if I'm a mailserver, and try connecting to one of > > Hotmail's MX hosts with ECN, I'll get RST every time. I would like to be > > able to retry with ECN disabled for that connection. > > We are allowing two rules to be broken, one is RFC 793 which > clearly and unambigously defines what a RST means. the second is This is NOT being violated: the RST is honoured as normal. > the firewall or IDS box which clearly is in violation. Disagreed: it is complying with firewall RFCs, rejecting suspect packets. Sending an RST isn't a very bright way to do it, but that's irrelevant: it happens. Deal with it. > The simplest thing in this chaos is to fix the firewall because it is in > violation to begin with. It is not in violation, and you can't fix it: it's not yours. > I think it is silly to try to be "robust against RSTs" because of ECN. > What if the RST was genuine? It is genuine, and is treated as such. There is no "robust against RSTs" or anything else: just graceful handling of non-ECN routes. > I see that we mostly have philosphical differences. You'd rather adapt > to the criminal and most people would rather have the criminal adjust to > society. There is no "criminal": no rules are being broken. Since it is "society" (or a tiny minority thereof) which has changed the rules, it is "society" which must adapt to be compatible with existing rules. > I think CISCO have been very good in responding fast. I blame the site > owners who dont want to go beyond their 9-5 job and upgrade their boxes. > In the old internet where only hackers were qualified for such jobs, the > upgrade would have happened by now at hotmail. I suppose it's part of > growing pains. I'd have said that's still true - only "hackers" are qualified. The problem is just that the staff doing (or attempting) the job aren't necessarily qualified to do it properly... > If you think the CISCOs were bad sending RSTs, i am sure you havent heard > about the Raptor firewalls. They dont even bother to send you anything if > you have ECN enabled ;-> Simply swallow your SYNs. That's regarded as a better response, actually: just drop suspect packets. > So tell me, what do you propose we deal with these? Do we further > disambiguate or assume the packet was lost? > I actually bothered calling Raptor, they chose to ignore me. You mean they are still shipping a firewall which drops ECN packets? Hrm... > You should never ASSume anything about something that is "reserved". > I posted the definition from the collegiate dictionary, but i am sure most > dictionaries would give the same definition. It isn't just reserved, though, it's stated "must be zero". Very poor wording, but it's too late now. > It's too bad we end up defining protocols using English. We should use > mathematical equations to remove any ambiguity ;-> No, just use English properly. "Must be zero" doesn't actually mean "must be set to zero when sending, and ignored when receiving/processing", which is probably what the standard SHOULD have said. However, it's too late now: ECN-disabled routes exist. ECN implementations should degrade as well as possible when handling these circumstances. James. - 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: ECN: Clearing the air (fwd)
On Sun, 28 Jan 2001, Miquel van Smoorenburg wrote: > In article <[EMAIL PROTECTED]>, > James Sutherland <[EMAIL PROTECTED]> wrote: > >On Sun, 28 Jan 2001, jamal wrote: > >> The internet is a form of organized chaos, sometimes you gotta make > >> these type of decisions to get things done. Imagine the joy _most_ > >> people would get flogging all firewall admins who block all ICMP. > > > >Blocking out ICMP doesn't bother me particularly. I know they should be > >selective, but it doesn't break anything essential. > > It breaks Path MTU Discovery. If you have a link somewhere in your > network (not at an endpoint, or TCP MSS will take care of it) that > has an MTU < 1500, you cannot reach hotmail and a lot of other sites > either currently. It _does_ break essential things. Daily. I would > get a lot of joy from flogging all firewall admins who block all ICMP. Except you can detect and deal with these "PMTU black holes". Just as you should detect and deal with ECN black holes. Maybe an ideal Internet wouldn't have them, but this one does. If you can find an ideal Internet, go code for it: until then, stick with the real one. It's all we've got. James. - 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: ECN: Clearing the air (fwd)
On Sun, 28 Jan 2001, Ben Ford wrote: > James Sutherland wrote: > > > I'm sure we all know what the IETF is, and where ECN came from. I haven't > > seen anyone suggesting ignoring RST, either: DM just imagined that, > > AFAICS. > > > > The one point I would like to make, though, is that firewalls are NOT > > "brain-damaged" for blocking ECN: according to the RFCs governing > > firewalls, and the logic behind their design, blocking packets in an > > unknown format (i.e. with reserved bits set) is perfectly legitimate. Yes, > > those firewalls should be updated to allow ECN-enabled packets > > through. However, to break connectivity to such sites deliberately just > > because they are not supporting an *experimental* extension to the current > > protocols is rather silly. > > Do keep in mind, we aren't breaking connectivity, they are. Let me guess: you're a lawyer? :-) This is a very strange definition: if someone makes a change such that their machine can no longer communicate with existing systems, I would say the person making the incompatible change is the one who broke it. Maybe my mains sockets should be waterproof: it's still my fault when pouring water over them causes problems, even if the standards say the socket should be waterproof! James. - 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: ECN: Clearing the air (fwd)
On Sun, 28 Jan 2001, jamal wrote: > On Sun, 28 Jan 2001, James Sutherland wrote: > > > I'm sure we all know what the IETF is, and where ECN came from. I haven't > > seen anyone suggesting ignoring RST, either: DM just imagined that, > > AFAICS. > > The email was not necessarily intended for you. You just pulled the pin. > There were people who made the suggestion that TCP should retry after a > RST because it "might be an anti-ECN path" That depends what you mean by "retry"; I wanted the ability to attempt a non-ECN connection. i.e. if I'm a mailserver, and try connecting to one of Hotmail's MX hosts with ECN, I'll get RST every time. I would like to be able to retry with ECN disabled for that connection. > > The one point I would like to make, though, is that firewalls are NOT > > "brain-damaged" for blocking ECN: according to the RFCs governing > > firewalls, and the logic behind their design, blocking packets in an > > unknown format (i.e. with reserved bits set) is perfectly legitimate. > > I dont agree that unknown format == reserved. I think it is bad design to > assume that. You may be forgiven if you provide the operator > opportunities to reset your assumptions via a config option. > It has nothing to do with a paranoia setting, just a bad design. Nothing > legit about that. On the contrary: rejecting weird-looking traffic is perfectly legit. I agree RST is the wrong response, but it's too late to tell Cisco that now... > > Yes, > > those firewalls should be updated to allow ECN-enabled packets > > through. However, to break connectivity to such sites deliberately just > > because they are not supporting an *experimental* extension to the current > > protocols is rather silly. > > This is the way it's done with all protocols. or i should say the way it > used to be done. How do you expect ECN to be deployed otherwise? The current versions of these firewalls handle ECN OK. I just want Linux to degrade gracefully when unable to use ECN: it will be a while before all these firewalls have gone. > The internet is a form of organized chaos, sometimes you gotta make > these type of decisions to get things done. Imagine the joy _most_ > people would get flogging all firewall admins who block all ICMP. Blocking out ICMP doesn't bother me particularly. I know they should be selective, but it doesn't break anything essential. > There is nothing silly with the decision, davem is simply a modern day > internet hero. No. If it were something essential, perhaps, but it's just a minor performance tweak to cut packet loss over congested links. It's not IPv6. It's not PMTU. It's not even very useful right now! James. - 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: ps hang in 241-pre10
On 27 Jan 2001, Linus Torvalds wrote: > In article <[EMAIL PROTECTED]>, David Ford <[EMAIL PROTECTED]> > wrote: > > > >We've narrowed it down to "we're all running xmms" when it happend. > > Does anybody have a clue about what is different with xmms? > > Does it use KNI if it can, for example? We used to have a problem with > KNI+Athlons, for example. Not KNI, I don't think, but 1.2.4 did add support for 3dnow!, with auto-detection of CPU type. Disabled by default, but available. Are there any 3dnow! issues?? > It might also be that it's threading-related, and that XMMS is one of > the few things that uses threads. Things like that. I'm not an XMMS > user, can somebody who knows XMMS comment on things that it does that > are unusual? Always uses threads, can use 3dnow!, DGA and realtime priority. Can also do direct hardware access to some graphics cards (inc SB16), but I haven't looked at that one closely. James. - 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: ECN: Clearing the air (fwd)
I'm sure we all know what the IETF is, and where ECN came from. I haven't seen anyone suggesting ignoring RST, either: DM just imagined that, AFAICS. The one point I would like to make, though, is that firewalls are NOT "brain-damaged" for blocking ECN: according to the RFCs governing firewalls, and the logic behind their design, blocking packets in an unknown format (i.e. with reserved bits set) is perfectly legitimate. Yes, those firewalls should be updated to allow ECN-enabled packets through. However, to break connectivity to such sites deliberately just because they are not supporting an *experimental* extension to the current protocols is rather silly. James. - 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: hotmail not dealing with ECN
On Sat, 27 Jan 2001, Gregory Maxwell wrote: > On Sat, Jan 27, 2001 at 11:09:27PM +0000, James Sutherland wrote: > > On Sat, 27 Jan 2001, David Schwartz wrote: > > > > > > > > > Firewalling should be implemented on the hosts, perhaps with centralized > > > > policy management. In such a situation, there would be no reason to filter > > > > on funny IP options. > > > > > > That's madness. If you have to implement your firewalling on every host, > > > what do you do when someone wants to run a new OS? Forbid it? > > > > Of course. Then you find out about some new problem you want to block, so > > you spend the next week reconfiguring a dozen different OS firewalling > > systems. Hrm... I'll stick with a proper firewall, TYVM! > > It's this kind of ignorance that makes the internet a less secure and stable > place. > > The network should not be a stateful device. If you need stateful > firewalling the only place it should be implimented is on the end node. If > management of that is a problem, then make an interface solve that problem > insted of breaking the damn network. I'm not suggesting making the network a stateful device. I'm suggesting having a firewall. That should NOT be implemented on the end node. Apart from anything else, the firewall shouldn't run any services: this is a bit difficult on a server... The network isn't broken. It works very nicely, TYVM. The firewall will occasionally need reconfiguring (block out new types of attack, allow new services, etc.) It's just much easier (and more secure) on a dedicated firewall than running a load of filtering on every single server. James. - 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: hotmail not dealing with ECN
On Sat, 27 Jan 2001, David Schwartz wrote: > > > Firewalling should be implemented on the hosts, perhaps with centralized > > policy management. In such a situation, there would be no reason to filter > > on funny IP options. > > That's madness. If you have to implement your firewalling on every host, > what do you do when someone wants to run a new OS? Forbid it? Of course. Then you find out about some new problem you want to block, so you spend the next week reconfiguring a dozen different OS firewalling systems. Hrm... I'll stick with a proper firewall, TYVM! James. - 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: RE: hotmail not dealing with ECN
On Fri, 26 Jan 2001, Lars Marowsky-Bree wrote: > On 2001-01-26T16:04:03, >"Randal, Phil" <[EMAIL PROTECTED]> said: > > > We may be right, "they" may be wrong, but in the real world > > arrogance rarely wins anyone friends. > > So you also turn of PMTU and just set the MTU to 200 bytes because broken > firewalls may drop ICMP ? No - a workaround is used to detect such "black holes". Much as I was advocating for ECN, in fact. Also note that some firewalls (Microsoft's in particular) DO drop ICMP packets. James. - 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: hotmail not dealing with ECN
On Fri, 26 Jan 2001, Lars Marowsky-Bree wrote: > On 2001-01-26T15:08:21, > James Sutherland <[EMAIL PROTECTED]> said: > > > Obviously. The connection is now dead. However, trying to make a new > > connection with different settings is perfectly reasonable. > > No. > > If connect() suddenly did two connection attempts instead of one, just how > many timeouts might that break? None. You time the request out as normal, if it does time out. > > Why? The connection is dead, but there is nothing to prevent attempting > > another connection. > > Right. And thats why connect() returns an error and retries are handled in > userspace. Except you can't retry without ECN, because DaveM wants to do a Microsoft and force ECN on everyone, whether they like it or not. If ECN is so wonderful, why doesn't anybody actually WANT to use it anyway? James. - 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: hotmail not dealing with ECN
On Fri, 26 Jan 2001, David S. Miller wrote: > James Sutherland writes: > > I was not suggesting ignoring these. OTOH, there is no reason to treat an > > RST packet as "go away and never ever send traffic to this host again" - > > i.e. trying another TCP connection, this time with ECN disabled, would be > > acceptable. > > The connection failed, RST means connection reset. RST means all > state is corrupt and this connection must die. It cannot be > interpreted in any other way. Obviously. The connection is now dead. However, trying to make a new connection with different settings is perfectly reasonable. > Using it as a metric for ECN enabling is thus unacceptable. Why? The connection is dead, but there is nothing to prevent attempting another connection. James. - 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: hotmail not dealing with ECN
On Fri, 26 Jan 2001, David S. Miller wrote: > > James Sutherland writes: > > A delayed retry without ECN might be a good compromise... > > > > Every single connection to ECN-broken sites would work as normal - it > > would just take an extra few seconds. Instead of "Hotmail doesn't > > work!" it becomes "Hrm... Hotmail is fscking slow, but Yahoo is fine. I'll > > use Yahoo". A few million of those, and suddenly Hotmail isn't so hot... > > No, as explained in previous emails, no retry scheme can work. > > Hotmails failing machines, for example, send RST packets back when > they see ECN. Ignoring valid TCP RST frames is unacceptable and > Linux will not do that as long as I am maintaining it. I was not suggesting ignoring these. OTOH, there is no reason to treat an RST packet as "go away and never ever send traffic to this host again" - i.e. trying another TCP connection, this time with ECN disabled, would be acceptable. James. - 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: hotmail not dealing with ECN
On Fri, 26 Jan 2001, Lars Marowsky-Bree wrote: > On 2001-01-26T11:40:36, > James Sutherland <[EMAIL PROTECTED]> said: > > > A delayed retry without ECN might be a good compromise... > > _NO!_ Why? As it stands, I have ECN disabled. It's staying disabled until I know it won't degrade my Net access. James. - 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: hotmail not dealing with ECN
On Fri, 26 Jan 2001, David S. Miller wrote: > > Matti Aarnio writes: > > But could you nevertheless consider supplying a socket option for it ? > > By all means default it per sysctl, but allow clearing/setting by > > program too. > > No, because then people will do the wrong thing. > > They will create intricate "ECN black lists" and make > their apps set the socket option based upon whether > a site is in the black list or not. > > This is wrong, and allows the problematic sites to continue to be > delinquent. > > If these sites gradually become more and more disconnected from > the rest of the internet, they will fix their kit. Other schemes > so far have been met with reluctance on the part of these sites. > > I do not want to condone mechanisms which allow people to make > crutches for these broken sites ad infinitum. A delayed retry without ECN might be a good compromise... Every single connection to ECN-broken sites would work as normal - it would just take an extra few seconds. Instead of "Hotmail doesn't work!" it becomes "Hrm... Hotmail is fscking slow, but Yahoo is fine. I'll use Yahoo". A few million of those, and suddenly Hotmail isn't so hot... James. - 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: hotmail can't deal with ECN
On Thu, 25 Jan 2001, David S. Miller wrote: > Some of the MX records that show up for hotmail.com go > to different machines, such as INKY.SOLINUS.COM which seems > to let ECN connections through just fine. Ahh.. In which case, *@hotmail.com list subscribers should still get their mail OK - it will just appear that most of the hotmail mail servers are down? James. - 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.16 through 2.2.18preX TCP hang bug triggered by rsync
On Thu, 25 Jan 2001, David S. Miller wrote: > > Andi Kleen writes: > > It's mostly for security to make it more difficult to nuke connections > > without knowing the sequence number. > > > > Remember RFC is from a very different internet with much less DoS attacks. > > Andi, one of the worst DoSs in the world is not being able to > communicate with half of the systems out there. > > BSD and Solaris both make these kinds of packets, therefore it is must > to handle them properly. So we will fix Linux, there is no argument. Hang on... From what was quoted of the RFC, this behaviour (accepting these packets) isn't required of hosts? In which case, if BSD or Solaris depend on it, THEY are violating the protocol, not Linux?? James. - 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.16 through 2.2.18preX TCP hang bug triggered by rsync
On Thu, 25 Jan 2001, Matthias Andree wrote: > On Wed, 24 Jan 2001, Andi Kleen wrote: > > > It's mostly for security to make it more difficult to nuke connections > > without knowing the sequence number. > > > > Remember RFC is from a very different internet with much less DoS attacks. > > If you're deliberately breaking compatibility by violating the specs, > you're making your own DoS if your machines can't chat to each other. If > you insist on breaking the RFC, make a sysctl for this behaviour that > defaults to "off". This isn't a violation - the section quoted does not REQUIRE the behaviour, it only RECOMMENDS it as being a good idea. Since implementing it apparently makes DoS attacks easier, NOT implementing it is now a better idea... James. - 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: Is sendfile all that sexy?
On Thu, 25 Jan 2001, bert hubert wrote: > On Thu, Jan 25, 2001 at 09:06:33AM +0000, James Sutherland wrote: > > > performance than it would for an httpd, because of the long-lived > > sessions, but rewriting it as a state machine (no forking, threads or > > other crap, just use non-blocking I/O) would probably make much more > > sense. > > From a kernel coders perspective, possibly. But a lot of SMB details are > pretty convoluted. Statemachines may produce more efficient code but can be > hell to maintain and expand. Bugs can hide in lots of corners. I said they were good from a performance PoV - I didn't say they were easy! Obviously there are reasons why the Samba guys have done what they have. In fact, some parts of Samba ARE implemented as state machines to some extent; presumably the remainder were considered too difficult to reimplement that way for the time being. James. - 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: CPU error codes
On Thu, 25 Jan 2001, Alan Cox wrote: > > I was wondering if someone could tell me where I can find > > Xeon Pentium III cpu error messages/codes > > In the intel databook. Generally an MCE indicates hardware/power/cooling > issues Doesn't an MCE also cover some hardware memory problems - parity/ECC issues etc? James. - 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: Is sendfile all that sexy?
On Thu, 25 Jan 2001, Alan Cox wrote: > > I think, that is not what we need. Once Ingo wrote, that since HTTP > > serving can also be viewed as a kind of fileserving, it should be > > possible to create a TUX like module for the same framwork, that serves > > using the SMB protocol instead of HTTP... > > > Kernel SMB is basically not a sane idea. sendfile can help it though Right now, ISTR Samba is still a forking daemon?? This has less impact on performance than it would for an httpd, because of the long-lived sessions, but rewriting it as a state machine (no forking, threads or other crap, just use non-blocking I/O) would probably make much more sense. James. - 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: Is sendfile all that sexy?
On Wed, 24 Jan 2001, Sasi Peter wrote: > > AIUI, Jeff Merkey was working on loading "userspace" apps into the > kernel > > to tackle this sort of problem generically. I don't know if he's > tried it > > with Samba - the forking would probably be a problem... > > I think, that is not what we need. Once Ingo wrote, that since HTTP > serving can also be viewed as a kind of fileserving, it should be > possible to create a TUX like module for the same framwork, that serves > using the SMB protocol instead of HTTP... I must admit I'm a bit sceptical - apart from anything else, Jeff's approach allows a bug in the server software to blow the whole OS away, instead of just quietly coring! (Or, worse still, trample on some FS metadata in RAM... eek!) A TUX module would be a nice idea, although I haven't even been able to find a proper TUX web page - Google just gave page after page of mailing list archives and discussion about it :-( James. - 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: Is sendfile all that sexy?
On Wed, 24 Jan 2001, Sasi Peter wrote: > On 14 Jan 2001, Linus Torvalds wrote: > > > The only obvious use for it is file serving, and as high-performance > > file serving tends to end up as a kernel module in the end anyway (the > > only hold-out is samba, and that's been discussed too), "sendfile()" > > really is more a proof of concept than anything else. > > No plans for samba to use sendfile? Even better make it a tux-like module? > (that would enable Netware-Linux like performance with the standard > kernel... would be cool afterall ;) AIUI, Jeff Merkey was working on loading "userspace" apps into the kernel to tackle this sort of problem generically. I don't know if he's tried it with Samba - the forking would probably be a problem... James. - 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: Is sendfile all that sexy?
On Tue, 23 Jan 2001, Helge Hafting wrote: > James Sutherland wrote: > > > > On Mon, 22 Jan 2001, Helge Hafting wrote: > > > > > And when the next user wants the same webpage/file you read it from > > > the RAID again? Seems to me you loose the benefit of caching stuff in > > > memory with this scheme. Sure - the RAID controller might have some > > > cache, but it is usually smaller than main memory anyway. > > > > Hrm... good point. Using "main memory" (whose memory, on a NUMA box??) as > > a cache could be a performance boost in some circumstances. On the other > > hand, you're eating up a chunk of memory bandwidth which could be used for > > other things - even when you only cache in "spare" RAM, how do you decide > > who uses that RAM - and whether or not they should? > > If we will need it again soon - cache it. If not, consider > your device->device scheme. What we will need is often impossible to > know, > so approximations like LRU is used. You could have a object table > (probably a file table or disk block table) counting how often various > files/objects are referenced. You can then decide to use RAID->NIC > transfers for something that haven't been read before, and memory > cache when something is re-read for the nth time in a given time > interval. I think my compromise of sending it to both simultaneously is better: if you do reuse it, you've just got a cache hit (win); if not, you've just burned some RAM bandwidth, which isn't a catastrophe. > This might be a win, maybe even a big win under some circumstances. > But considering how it works only for a few devices only, and how > complicated it is, the conclusion becomes don't do it for > standard linux. Eh? This is a hardware system - Linux has very little hardware in it :-) > You may of course try to make super-performance servers that work for > a special hw combination, with a single very optimized linux driver > taking care of the RAID adapter, the NIC(s), the fs, parts of the > network stack and possibly the web server too. Actually, I'd like it to be a much more generic thing. If you get an "intelligent" NIC, it will have, say, a StrongARM processor on it. Why shouldn't the code running on that processor be supplied by the kernel, as part of the NIC driver? Given a powerful enough CPU on the NIC, you could offload a useful chunk of the Linux network stack to it. Or a RAID adapter - instead of coming with the manufacturer's proprietary code for striping etc., upload Linux's own RAID software to the CPU. Run some subset of X's primitives on the graphics card. On an I2O-type system (dedicated ARM processor or similar for handling I/O), run the low-level caching stuff, perhaps, or some of the FS code. Over the next few years, we'll see a lot of little baby CPUs in our PCs, on network cards, video cards etc. I'd like to see Linux able to take advantage of this sort of off-load capability where possible. James. - 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: Is sendfile all that sexy?
On Mon, 22 Jan 2001, Helge Hafting wrote: > And when the next user wants the same webpage/file you read it from > the RAID again? Seems to me you loose the benefit of caching stuff in > memory with this scheme. Sure - the RAID controller might have some > cache, but it is usually smaller than main memory anyway. Hrm... good point. Using "main memory" (whose memory, on a NUMA box??) as a cache could be a performance boost in some circumstances. On the other hand, you're eating up a chunk of memory bandwidth which could be used for other things - even when you only cache in "spare" RAM, how do you decide who uses that RAM - and whether or not they should? There certainly comes a point at which not caching in RAM would be a net win, but ATM the kernel doesn't know enough to determine this. On a shared bus, probably the best solution would be to have the data sent to both devices (NIC and RAM) at once? > And then there are things like retransmissions... Hopefully handled by an intelligent NIC in most cases; if you're caching the file in RAM as well (by "CCing" the data there the first time) this is OK anyway. Something to think about, but probably more on-topic for linux-futures I suspect... James. - 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: Is sendfile all that sexy?
On Sat, 20 Jan 2001, Linus Torvalds wrote: > > > On Sat, 20 Jan 2001, Roman Zippel wrote: > > > > On Sat, 20 Jan 2001, Linus Torvalds wrote: > > > > > But point-to-point also means that you don't get any real advantage from > > > doing things like device-to-device DMA. Because the links are > > > asynchronous, you need buffers in between them anyway, and there is no > > > bandwidth advantage of not going through the hub if the topology is a > > > pretty normal "star" kind of thing. And you _do_ want the star topology, > > > because in the end most of the bandwidth you want concentrated at the > > > point that uses it. > > > > I agree, but who says, that the buffer always has to be the main memory? > > It doesn't _have_ to be. > > But think like a good hardware designer. > > In 99% of all cases, where do you want the results of a read to end up? > Where do you want the contents of a write to come from? > > Right. Memory. For many applications, yes - but think about a file server for a moment. 99% of the data read from the RAID (or whatever) is really aimed at the appropriate NIC - going via main memory would just slow things down. Take a heavily laden webserver. With a nice intelligent NIC and RAID controller, you might have the httpd write the header to this NIC, then have the NIC and RAID controller handle the sendfile operation themselves - without ever touching the OS with this data. > Now, optimize for the common case. Make the common case go as fast as > you can, with as little latency and as high bandwidth as you can. > > What kind of hardware would _you_ design for the point-to-point link? > > I'm claiming that you'd do a nice DMA engine for each link point. There > wouldn't be any reason to have any other buffers (except, of course, > minimal buffers inside the IO chip itself - not for the whole packet, but > for just being able to handle cases where you don't have 100% access to > the memory bus all the time - and for doing things like burst reads and > writes to memory etc). > > I'm _not_ seeing the point for a high-performance link to have a generic > packet buffer. I'd agree with that, but I would want peripherals to be able to send data to each other without touching the host memory - think about playing video files with an accelerator (just pipe the files from disk to the accelerator), music with an "intelligent" sound card (just pipe the music to the card), video capture, file servers, CD burning... Having an Ethernet-style point-to-point "network" (everything connected as a star, with something intelligent in the middle to direct the data where it needs to go) makes sense, but don't assume everything is heading for the host's memory. DMA straight to/from a "switch" would be a nice solution, though... James. - 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: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]
On Sun, 21 Jan 2001, Lincoln Dale wrote: > hi, > > At 04:56 PM 20/01/2001 +0200, Kai Henningsen wrote: > >[EMAIL PROTECTED] (dean gaudet) wrote on 18.01.01 in > ><[EMAIL PROTECTED]>: > > > i'm pretty sure the actual use of pipelining is pretty disappointing. > > > the work i did in apache preceded the widespread use of HTTP/1.1 and we > > > >What widespread use of HTTP/1.1? > > this is probably digressing significantly from linux-kernel related issues, > but i owuld say that HTTP/1.1 usage is more widespread than your probably > think. > > from the statistics of a beta site running a commercial transparent caching > software: > # show statistics http requests >Statistics - Requests > Total % > --- > ... > HTTP 0.9 Requests: 41907 0.0 > HTTP 1.0 Requests: 3756320124.1 > HTTP 1.1 Requests: 11828209275.9 > HTTP Unknown Requests: 1 0.0 IIRC, the discrepancy is because some browsers (IE, not sure about Netscape) default to speaking HTTP/1.0 to a proxy if they are configured to use one - a chicken and egg situation, AFAICS: proxies are assumed to be HTTP 1.0 only, so browsers only send HTTP 1.0 requests - so people look at the logs and think 90% of their users are HTTP/1.0 only anyway, so there's no point in supporting 1.1 yet... Also something to do with HTTP 1.1 being much harder to support properly in proxies due to the new cache control features etc.?? James. - 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: ext3 vs. JFS file locations...
On Sat, 4 Nov 2000, Albert D. Cahalan wrote: > Dominik Kubla writes: > > On Fri, Nov 03, 2000 at 11:33:10AM -0800, H. Peter Anvin wrote: > > [about IBM's JFS and ext3 both wanting to put code in fs/jfs] > > >> How about naming it something that doesn't end in -fs, such as > >> "journal" or "jfsl" (Journaling Filesystem Layer?) > > > > Why? I'd rather rename IBM's jfs to ibmjfs and be done with it. > > jfs == Journalling File System > > The journalling layer for ext3 is not a filesystem by itself. > It is generic journalling code. So, even if IBM did not have > any jfs code, the name would be wrong. > > IBM ought to change their name too, because the code they ported > can not mount AIX's current filesystems. An appropriate name > would be jfs2 or os2jfs, to distinguish it from the original. > If the AIX filesystem is ever implemented for Linux, then that > code can get the jfs name. How about "Journalling Support Layer (JSL)"? How different is AIX's JFS from OS/2's? Is there any possibility of the current code being able to handle AIX filesystems as well, or is it a different system entirely? If the latter, I'd agree with something like "os2jfs". James. - 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: syslog() blocks on glibc 2.1.3 with kernel 2.2.x
On Sun, 29 Oct 2000, Jesse Pollard wrote: > On Sun, 29 Oct 2000, Stephen Harris wrote: > >Horst von Brand wrote: > > > >> > > If you send SIGSTOP to syslogd on a Red Hat 6.2 system (glibc 2.1.3, > >> > > kernel 2.2.x), within a few minutes you will find your entire machine > >> > > grinds to a halt. For example, nobody can log in. > >> > >> Great! Yet another way in which root can get the rope to shoot herself in > >> the foot. Anything _really_ new? > > > >OK, let's go a step further - what if syslog dies or breaks in some way > >shape or form so that the syslog() function blocks...? > > > >My worry is the one that was originally raised but ignored: syslog() should > >not BLOCK regardless of whether it's local or remote. syslog is not a > >reliable mechanism and many programs have been written assuming they can > >fire off syslog() calls without worry. > > It was NOT ignored. If syslogd dies, then the system SHOULD stop, after a > few seconds (depending on the log rate...). No. You should have the OPTION of stopping the machine, if accurate syslog information is more important to you than system functionality. This should also be an OS function, rather than just freezing processes as and when they call syslog()! > I do believe that restarting syslog should be possible... Perhaps syslog > should be started by inetd at the very beginning. Then it could be restarted > after an exit/abort. inetd? I'd have thought init would make a more suitable choice, perhaps with a monitor to lock the machine up or reboot if syslog fails and can't be restored. > This can STILL fail if the syslog.conf is completely invalid - but then the > system SHOULD be stopped pending the investigation of why the file has been > corrupted, or syslogd falls back on a default configuration (record everything > in the syslog file). Again, that might be useful in some cases, but certainly shouldn't be the only, or even default, mode. James. - 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: guarantee_memory() syscall?
On 29 Oct 2000, Eric W. Biederman wrote: > Raul Miller <[EMAIL PROTECTED]> writes: > > > Can anyone tell me about the viability of a guarantee_memory() syscall? > > > > [I'm thinking: it would either kill the process, or allocate all virtual > > memory needed for its shared libraries, buffers, allocated memory, etc. > > Furthermore, it would render this process immune to the OOM killer, > > unless it allocated further memory.] > > Except for the OOM killer semantics mlockall already exists. More to the point, "immortality" is NOT a desirable "feature": the OOM killer just kills things which must be killed to protect the overall system. We'll have a finely adjustable memory killer daemon soon, which will be a better solution. James. - 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: GPL Question
On Fri, 27 Oct 2000, David Schwartz wrote: > > > Now, if a module is loaded that registers a set of functions that have > > increased functionality compared to the original functions, if that > > modules is not based off GPL'd code, must the source code of that module > > be released under the GPL? > > If the answer to this is "yes", then Microsoft should own some rights to > every piece of software that uses the Windows API. In fact, since you call the Windows API by linking against Windows libraries (kernel32.dll etc), Microsoft have as much right to dictate the licensing of Windows apps as the FSF has to require apps linked against GPLed code to be GPLed. (IMO, neither has any such right; of course, given the spate of recent laws we've seen, I wouldn't put any faith in a legal system to reach the "right" decision...) In this particular case - just communicating with GPLed code - the answer is no, you are not required to impose GPL restrictions on your users, you can use a free license instead (or a proprietary one, if you really want...) James. - 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: K6-2+ name (was Re: AMD CPU misdetection?)
On Mon, 23 Oct 2000 [EMAIL PROTECTED] wrote: > In the words of Barry K. Nathan : > > > > Why they didn't call it K6-4 is anyones guess. > > I read somewhere (I don't have a URL handy, sorry) that the reason AMD > > went with K6-2+ is that, apparently, the K6-2 name is well-known, and > > they wanted to build on that... > > Sounds like a marketing thing. > Not really an excuse imo. The "Oh, K6-4. I must upgrade" brigade would've > justified the name for more than confusing people. At least K6-2+ > is mostly used in laptops from what I've seen, so the confusion is > limited. > > Maybe there just wasn't enough architectural difference between the > K6-3 & the K6-2+ to justify calling it the K6-4. AFAIR, the powersaving > speed changing is the only thing thats changed. > > I'm buying a K6-2+ laptop tomorrow, so I guess I'll find out more then :) ISTR the name is because it is derived more from the K6-II than the K6-3? The -3 was better on performance, but they wanted a more economical chip for laptop/embedded use, so they reverted to the K6-II core? James. - 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] 2.4 version of my duplicate IP and MAC detection patch
On Tue, 17 Oct 2000, Werner Almesberger wrote: > Marc MERLIN wrote: > > Come on, Andi, it's not. You do DAD, you get your IP, I plug my laptop, use > > your IP, you don't even know it. My patch lets you know. > > The reason I wrote it is that I've seen this happen too many times already. > > Also, if the network is not operational at the time you configure your > interface, you don't notice duplicates, even if everybody carefully > looks for them when bringing up or changing interfaces. > > This is a rather common situation at meetings, where wireless cards are > mis-configured, hubs have no power, some of the cables are broken, and > people who are blissfully unaware of any address allocation procedure > enter the room and instantly try to set up their machines. (And of > course nobody had time to prepare a DHCP server.) > > Thumbs up from me. Another case where detecting duplicate IP addresses would be useful: this machine was broken into yesterday morning, and reconfigured to take over every IP address on the local subnet, then use all these addresses to connect to Demon's IRCnet server. Detecting the duplicated IP addresses and shouting about them would definitely have been welcome! James. - 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] VM fix for 2.4.0-test9 & OOM handler
On Mon, 9 Oct 2000, Ingo Molnar wrote: > On Mon, 9 Oct 2000, Rik van Riel wrote: > > > > so dns helper is killed first, then netscape. (my idea might not > > > make sense though.) > > > > It makes some sense, but I don't think OOM is something that > > occurs often enough to care about it /that/ much... > > i'm trying to handle Andrea's case, the init=/bin/bash manual-bootup case, > with 4MB RAM and no swap, where the admin tries to exec a 2MB process. I > think it's a legitimate concern - i cannot know in advance whether a > freshly started process would trigger an OOM or not. Shouldn't the runtime factor handle this, making sure the new process is killed? (Maybe not if you're almost OOM right from the word go, and run this process straight off... Hrm.) James. - 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 kernel modules development in C++
On Fri, 29 Sep 2000, Daniel Phillips wrote: > Marty Fouts wrote: > > My own opinion is that no, the nominal cost of standards documents has > > little to do with why programmers don't have complete and up to date > > definitions of the language. > > I can't change your opinion but I can tell you a fact: this is the > reason that *I* do not have a copy of the standard. If I could just > download it from a URL I would have done it long ago. Not that I can't > afford it, it's just too much of a pain in the butt. That sounds likely to be a common case. Every real bookstore I've seen lately has had books on C, C++, Linux, Windows etc. programming - I have yet to see one with a since ANSI or IEEE document for sale! OTOH, these standards documents aren't the most readable of text. Perhaps a human-friendly explanation of the standard would be more widely read? > > Most of them, after all, are willing to pay > > 3-4 times that much for tutorial or text books on the language, often more > > than one. My opinion is that few C or C++ programmers actually possess > > complete and up to date definitions of the language, because many of them > > are unaware of or uninterested in the existence of such standards, because > > they believe that the dielect of the language they are using on their > > platform of choice is, for their purposes, the language, and so they believe > > they only need the vendor reference for the language. Also, standards are > > written in a peculiar style and dialect, and they require developing a > > certain kind of reading skill to be useful. > > I think you are wrong. No, that's too week. I *know* you are wrong. > If there was no cost in getting the standard every last one of us would > have it, the same way every last one of us has a copy of the kernel. > Consider this: if Linux costed $18, most of us wouldn't be here. I wouldn't bet on that; I suspect most of us have bought a copy of Linux at some point, even if only via a magazine cover CD. We don't all have cable modems or OC-48s! (OK, I do as of this morning - even if the ISP is part-owned by MS...) > Charging a toll on the standard is just plain evil. If ansi needs > money, let them get it some other way than by having a monopoly on this > public information. I'd be inclined to agree with this - except it is difficult to find money other ways. Perhaps the companies concerned would be prepared to sponsor the process enough to cover all the costs? James. - 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: AW: Given an image, how can show its config?
On Wed, 27 Sep 2000, David Ford wrote: > James Sutherland wrote: > > > No. I am assuming you are installing the kernel on the machine you do > > "make modules_install" on. Obviously it is possible to install a different > > kernel image of the same version without updating the modules - but if you > > do so, expect nasty things to happen anyway if you're using modules! > > I normally compile on one machine and distribute it. This isn't a viable > solution. Unless you omit the modules directory, that's not a problem. > > In more complex cases, find a more complex solution - this is a nice > > simple solution which works for the typical case of building and > > installing a kernel! > > > > If you are DIY upgrading a box's kernel, this solution works fine. If > > you're maintaining a distribution, you should be able to use this solution > > without much extra effort. If you are building kernels to DIY upgrade > > other machines, and don't bother copying /lib/modules/`uname -r` then you > > need to find another solution. I doubt this scenario is common enough to > > justify denying the vast majority of Linux users this facility! > > Linus tends to go for the 'perfect' solution, not the 'almost' solution. I > fully agree. uname -r simply doesn't have the granularity necessary. It's worked perfectly well so far. James. - 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: AW: Given an image, how can show its config?
On Wed, 27 Sep 2000, Butter, Frank wrote: > > How about putting these files in the modules directory? That > > way, we have > > a nice consistent location for them. > > /lib/modules/`uname -r`/build/System.map etc. is a fair > > approximation, but > > you lose that every time the kernel source is changed, even if the new > > image isn't installed. > > Your assumption is that you have only one config per machine with a certain > kernel-release and that you are building the kernel for _this_ box. No. I am assuming you are installing the kernel on the machine you do "make modules_install" on. Obviously it is possible to install a different kernel image of the same version without updating the modules - but if you do so, expect nasty things to happen anyway if you're using modules! > There are other options, and in these more complex cases the > "config-tracking" is more important than in the single case, where you > actually have /usr/src/linux/arch/boot. In more complex cases, find a more complex solution - this is a nice simple solution which works for the typical case of building and installing a kernel! If you are DIY upgrading a box's kernel, this solution works fine. If you're maintaining a distribution, you should be able to use this solution without much extra effort. If you are building kernels to DIY upgrade other machines, and don't bother copying /lib/modules/`uname -r` then you need to find another solution. I doubt this scenario is common enough to justify denying the vast majority of Linux users this facility! James. - 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: SCO: "thread creation is about a thousand times faster than onnative Linux"
On Tue, 26 Sep 2000, Thomas Zehetbauer wrote: > > But if you can get rid of the stacks, and you _can_ get rid of the > > stacks sometimes, then why not have one thread per widget in a GUI? Or > > one thread per animated objected on a web page? Some notions of > For this to work without opening up a security hole we must be able to > distribute the processor timeslice for a process among all of it's threads. > Please correct me if I am wrong but AFAIK this is impossible with the current > scheduler logic. Sounds like a job for fairsched? (Actually, it just sounds like a bad idea... it might work, though, I suppose...) James. - 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: [DOC] Debugging early kernel hangs
On Mon, 25 Sep 2000, Russell King wrote: > James Sutherland writes: > > On Sat, 23 Sep 2000, Russell King wrote: > > > And I'll try to make the point a second time that everything does not have > > > a character-based screen to write to. > > > > So what? For platforms which have a nice easy way to stick ASCII on > > screen, use this. For other platforms, find some other approach - if you > > have a nice easy serial port handy, try feeding the characters there. > > So what? It shouldn't be called "VIDEO_CHAR" then - calling it that > describes ONE implementation only, not what it is actually doing. > Something more like DEBUGCH(char) or whatever is a better choice because > it describes what the intention of it is, rather than the implementation. Yes, a better name could be found; I'd go for DUMP_CHAR() myself, I think. The basic concept is great, it just needs a new name... James. - 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: [DOC] Debugging early kernel hangs
On Sat, 23 Sep 2000, Russell King wrote: > Keith Owens writes: > > Something I forgot to mention about debugging using screen writes. If > > the problem is caused by incorrect compiler output then even printk can > > fail. Not because the C code is wrong but because the generated > > assembler is wrong. Writing direct to screen memory is as simple as it > > gets and gives the compiler little or no chance to get it wrong. > > And I'll try to make the point a second time that everything does not have > a character-based screen to write to. So what? For platforms which have a nice easy way to stick ASCII on screen, use this. For other platforms, find some other approach - if you have a nice easy serial port handy, try feeding the characters there. This feature doesn't need to work identically on all platforms. It doesn't even need to work on all platforms (although that would be nice). James. - 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: Given an image, how can show its config?
On Sat, 23 Sep 2000, Keith Owens wrote: > On Sat, 23 Sep 2000 11:33:31 +0200, > Daniel Phillips <[EMAIL PROTECTED]> wrote: > >I'd just like to remind you of Alan Cox's suggestion about appending > >.config.gz to bzImage so that it doesn't get loaded into memory, and > >my suggestion to put System.map.gz there as well. > > I worry about anything that increases the on disk size of bzImage, even > if the extra data does not get loaded into kernel memory. > > 629590 2.2.16/arch/i386/boot/bzImage > 786273 2.4.0-test8/arch/i386/boot/bzImage > > cat .config System.map | gzip | wc -c > 107591 > > That would take my 2.4.0 bzImage to 893864, it does not leave much room > out of a 1.4Mb floppy for LILO files. We could have multiple make > targets, with and without appended config/map but that just complicates > the build environment. > > This is all to protect those few poor 'administrators' who cannot keep > track of three separate files. We should not coddle such idiots, if > they cannot track 3 files they should not be configuring Linux. > Anybody who loses their config and System.map will learn from their > mistake and only do it once or they will never learn, in which case > they are better off running Windows. > > "Think of it as evolution in action". How about putting these files in the modules directory? That way, we have a nice consistent location for them. /lib/modules/`uname -r`/build/System.map etc. is a fair approximation, but you lose that every time the kernel source is changed, even if the new image isn't installed. James. - 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.17 crashes with RTL8139B and/or IPv6
On Wed, 20 Sep 2000, Marco Colombo wrote: > On Wed, 20 Sep 2000, Simon Richter wrote: > > > Hi, > > > > I just upgraded our server (486DX2/120, running 186 days`) with a 100MBit > ^^ > isn't it overclocked? >From the CPU identification given later, it is said to be a 486 DX4/120 - 120 MHz core on a 40 MHz FSB, 3x clock multiplier. Simon: Have you tried the 8139too driver with this series?? I can't remember much detail about it off-hand, but it could be worth a try? James. - 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: /proc/sys/vm/freepages not writable.
On Sun, 17 Sep 2000, Evan Jeffrey wrote: > > > > 1. The inactive_target is 1 second worth of allocations, minus > > >the amount of frees in 1 second, averaged over a minute > > > > So it cannot take load bursts. That's ok for a default, but for special loads > > it would be good if there was a way for the administrator to overwrite that, > > similar to the old freepages. > > How about taking a decaying average (loadavg style) of the peak > allocation-free rate on a minute-by-minute basis. Then make the > number of seconds at that rate to use as the inactive_target a tunable > parameter. That way, a user could, if necessary, tune based on their > expected type of load (length of load bursts), and the alg. would tune > to the load level (height of those bursts). For a consistent load, > peak rate ~= avg. rate, and this decays to the current behavior, > except that the "1 second of allocations" is tunable. If we take the load avg analogy a bit further, we should be able to spot trends, at least to a limited extent: if the short term allocation rate is higher than the long term, there's an increasing trend, so we should probably try to keep more. Tracking something like the last minute - as presently - but divided into "last 30 seconds" and "previous 30 seconds" would probably help here; take the first minus the second (rate of "acceleration") and add to the first, and divide by 30. Use 32 for speed, perhaps, making it: ((a << 1) - b) >> 5 Should be an easy enough change, and a slightly better metric than just a simple average? > I haven't actually looked at the code, so I don't know how easy/hard > this is to implement, and while it does reintroduce a tuning > parameter, it should be needed less often, and has a much more > user-meaningful value (burst length) than # of free pages to keep > handy, which depends on the code, and could change between versions. With a reasonable "guess" based on recent history, we should be able to keep enough around to handle most circumstances. James. - 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: (reiserfs) Re: More on 2.2.18pre2aa2
On Sat, 16 Sep 2000, Giuliano Pochini wrote: > I wrote, then got air-brushed out of the thread?! > > That's one approach; I prefer my "weighted scoring" approach. Supposing we > > have three devices: a solid state disk (instant "seeks"), a hard drive and > > a tape. The SSD will benefit from merges (fewer commands to process), but > > not hugely - set both the metrics at 1, so a 64Kb request is just under > > twice the "cost" of a 32Kb one. The hard drive can seek fairly quickly, > > but long reads are preferable - say, seek_cost = 16, block_cost = 1. A > > single 64Kb request is "cheaper" than a pair of 32Kb requests, but not > > hugely so. Then the tape: seeks can take a few minutes, so make it > > seek_cost = 65536, block_cost = 1: we don't really care how much is being > > read, within reason, since seeks are so "expensive". > > If we could read by a SCSI command the maximun/typical/minimum seek and > transfer speed directly from the drive things were a lot simpler :)) We can almost do that with any device; if we have a nice interface for user-space tuning (a few /proc files), we can be told at boot-time what the characteristics of each device are. A simple piece of code which does a couple of seeks and a big read or two on each device would achieve this easily enough. We don't need to know the exact characteristics, but it could be of some use in fine-tuning performance; my overall approach should work reasonably well for any given device, I think? James. - 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: (reiserfs) Re: More on 2.2.18pre2aa2
On Wed, 13 Sep 2000, Rik van Riel wrote:
> On Thu, 14 Sep 2000, Ragnar Kjørstad wrote:
> This (IMHO) is wrong. When the drive has trouble keeping up
> with requests in FCFS order, we should do some elevator sorting
> to keep throughput high enough to deal with the requests we get.
Reversing that, you mean the drive should be given requests on an FCFS
basis until it is running flat out, at which point elevator sorting should
come into play? That's what I would suggest: under light loads, requests
are then handled with no extra latency at all, but we still get increased
throughput under heavier load.
> Jeff's idea would take care of this, together with a *limited*
> (say, 32 entries) queue size. Every time the "work" queue (the
> one the disk is working on) is empty, we switch queues.
Then process one queue until it's empty, even if there are higher priority
requests in another queue? I'm not so sure about that: then my backup
program or a file copy will be getting between my MP3 player and the disk.
> Processes get to put their request on the other queue, either
> until the disk takes their requests (the queues are switched)
> or until the queue is full. That way only the N highest priority
> processes can get access to the disk if we're really overloaded
> in a bad way.
How does your approach block lower priority processes? If they were to
issue a request before a higher priority one, it is inserted into the
"filling" queue; once we switch queues, this request will be handled -
perhaps before a higher priority request, if we're unlucky with the
timing?
If we can keep it sorted reasonably efficiently, a single rolling queue
seems better - or perhaps model it on the process scheduler? Have
"realtime" requests ("it doesn't matter if everything else locks up, this
request MUST be completed ASAP"), then "other" requests of various
priorities?
> The current HUGE queue size is probably another reason for
> the very bad latencies we sometimes see...
If the code ever sits there sorting the queue out, while the disk goes
idle, the code needs adjusting: getting requests processed in a
sub-optimal order is still better than not getting any requests processed
at all for some period of time!
> > > (maybe with the twist that we /do/ allow merges on the queue
> > > that's being processed by the disk, but no insertions of new
> > > requests)
> >
> > I don't think you should allow merges. If one process is doing a big
> > IO operation on a big file it would still get _all_ capacity, right?
>
> Only if you were to allow unlimited merges ;)
>
> I guess a 'decent' maximum size for one request would
> be somewhere around 256kB, since this is the amount of
> data a drive can read in the time of one disk seek...
That's one approach; I prefer my "weighted scoring" approach. Supposing we
have three devices: a solid state disk (instant "seeks"), a hard drive and
a tape. The SSD will benefit from merges (fewer commands to process), but
not hugely - set both the metrics at 1, so a 64Kb request is just under
twice the "cost" of a 32Kb one. The hard drive can seek fairly quickly,
but long reads are preferable - say, seek_cost = 16, block_cost = 1. A
single 64Kb request is "cheaper" than a pair of 32Kb requests, but not
hugely so. Then the tape: seeks can take a few minutes, so make it
seek_cost = 65536, block_cost = 1: we don't really care how much is being
read, within reason, since seeks are so "expensive".
In short, having a single rolling queue (probably divided into priority
classes) seems preferable; we should also bypass the elevator entirely if
the device is able to accept new commands at the time. (Q: how
intelligently will drives which handle command queueing themselves be??)
James.
-
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: (reiserfs) Re: More on 2.2.18pre2aa2
On Wed, 13 Sep 2000, Andrea Arcangeli wrote: > On Wed, 13 Sep 2000, Mitchell Blank Jr wrote: > > >The "large queue" goes against the whole point of this exercise - that > >is that if there are many items in the "queue" being sorted then > >unlucky requests can end up waiting a long time to get serviced. > > Yep. Ehmm... that large queue is a backlog of I/O requests. Since that's a function of the workload and the disk speed, you can't reduce it without either cutting the workload or speeding up the disk! I suspect we were talking at cross purposes here a little. I was NOT suggesting holding back requests to build up a big queue - I was talking about the situation where we have a large backlog of requests pending. James. - 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: (reiserfs) Re: More on 2.2.18pre2aa2
On Wed, 13 Sep 2000, Mitchell Blank Jr wrote: > James Sutherland wrote: > > In terms of latency, I'd suggest we aim to keep the device in use all the > > time we have outstanding requests: every time the device is ready to > > accept a request, we feed it the "next" one in the queue; until it is free > > again, requests pile up in the queue, being sorted, merged etc. > > > > This should perform very well under light loads - requests just get passed > > to the device as fast as they can be handled - and under very heavy loads > > - we have a large queue in play, with plenty of scope for reordering, > > merges etc. > > The "large queue" goes against the whole point of this exercise - that > is that if there are many items in the "queue" being sorted then > unlucky requests can end up waiting a long time to get serviced. Yes, you need some sort of priority boost to avoid starving unlucky processes. Tracking a sort of I/O goodness value may help here: if I fire off a copy of a large file, and a "find /", the former will get much higher throughput due to large consecutive reads. As it does so, though, it reduces its own I/O priority; 'eventually' it will be below find, and find gets some I/O bandwidth. > You want to have some reasonable break-off point where you just > decide to make an elevator swipe in order to avoid starving those > requests. Hrmm... not quite the system I had in mind. I specifically want to avoid delaying any requests: when possible, we just pass requests straight to the drive. The queue of outstanding requests only arises in the first place when the drive is busy. > Keep in mind that I'm using the word "queue" in a confusing manner > here - we're talking about how much we'll try to elevator-sort in > a go, not the actual queue of all requests. I've been calling this > a queue because from a performance standpoint that's what it is, > so I think it helps to think of the problem that way. Ahh... I see. If we have a large enough backlog of requests that we can't even elevator sort them fast enough, there's something very odd going on. Still, I was planning to impose a maximum limit on the backlog - the question is, what to do when that limit is reached?? > Oh yeah one other thing about huge elevator queues to think about > (although its not too pertinant these days). A friend of mine had > a job 15 years or so ago to working on a commercial UNIX flavor. > They were having some severe I/O performance problems under high > loads. The problem was that they were trying to sort and merge > all the pending requests. When I/O was heavy this ended up > chewing all the CPU time and the kernel wouldn't actually be > able to keep up sending requests to the disk :-) However, keep > in mind that this was int the bad-old-days when "hard drive" > meant a rack-mount Eagle and the elevator was expected to consider > things like head positioning and rotational speed when doing > a sort... LOL! My approach does avoid that, though. As a worst case, the elevator just doesn't get a chance to sort anything: every request issues hits the disk directly. If the disk is handling requests fast enough the CPU can't keep up, we don't really want an elevator anyway... So, in various scenarios: * Light I/O - disk handling requests as they are issued. Disk may be idle at times. * Medium I/O - small backlog being elevator sorted as needed. Disk active continuously, but all requests being handled OK. * Heavy I/O - large backlog building up. Disk continuously active, some processes may be starved or throttled, depending on priorities. In the third case, sometimes we WILL want processes starved of I/O. If I have three processes running - an MP3 player (high priority), a 'find' and a low priority backup job, I DO want the backup job starved in favour of the other two. James. - 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: (reiserfs) Re: More on 2.2.18pre2aa2
On Wed, 13 Sep 2000, Mitchell Blank Jr wrote: > Alan Cox wrote: > > > Yes, but "how hard is it reasonable for the kernel to try" is based on > > > both items. A good first order approximation is number of requests. > > > > I must strongly disagree with that claim. A request could be 512 bytes or > > 128K. > > Yeah, as sct pointed out this gets thorny. For a modern harddrive this > probably doesn't matter (since sequential I/O is SO fast compared to > seek times) but for other devices its an issue. How about a simple "cost metric" for each request? (Each individual request gets X "points", plus Y per block. Make Y almost zero for HDDs and tape drives etc., make X and Y equal for solid state storage, say.) In terms of latency, I'd suggest we aim to keep the device in use all the time we have outstanding requests: every time the device is ready to accept a request, we feed it the "next" one in the queue; until it is free again, requests pile up in the queue, being sorted, merged etc. This should perform very well under light loads - requests just get passed to the device as fast as they can be handled - and under very heavy loads - we have a large queue in play, with plenty of scope for reordering, merges etc. > > > ...where the user sets a number exlpicitly for what performance they > > > want. Again, if we're going to make the user set this latency > > > > No they do not. The parameters are defined by the bandwidth and measured > > behaviour. > > Hmmm... well if someone wants to propose an algorithm to self-tune the > "queue depth in milliseconds" number then maybe we'll get somewhere. > You'd need to do some sort of moving averages of both requests/sec and > sectors/sec that come out of the elevator and use those as feedback to > adjust the queue-depth-value. I'm not sure if this is advisable, but > at least it sounds feasable. With the metrics above, you should be able to calculate appropriate values for X and Y to make the "cost" figures roughly correspond to actual times, I think? The big question, of course, is what do you do when the queue reaches the maximum - block the next process to make a request? Better, block all but the highest "I/O priority" process? Then, I can go copying, moving and deleting files left, right and centre without my MP3 player ever skipping, which is nice :-) James. - 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/
