Re: Coding Style
[Don't take this too seriously, the author had asked for flames without
meaning them, so this is the disclaimer ;-)]
On Fri, 19 Jan 2001, Mark I Manning IV wrote:
> found in teh kernel sources bz2. It is done in parody of teh original
> doc and is meant to be laughed at as much as taken seriously no
> offense is intended towards the original author :)
> int function(int x)
> {
> body of function// correctly braced and commented :)
> }
So you claim // is a correct C comment? Poor guy :)
> Sane people all over the world have claimed that the K inconsistency
> is... well... inconsistent, and they are all right-thinking people
> who know that (a) K are _wrong_ and (b) K are very wrong.
Hum, K were "somewhat involved" in C, but C has in the meanwhile
become bigger than just K, so there.
> Linus states that the placement of the first brace at the end of the
> first line keeps your code less vertical and thus saves you some space
> for comments. This commenting style just plane sucks,
Wow, airplanes. Who's bringing trains, ships and cars into Linux then?
(Not the other way round, that'd be easy.)
> I know, I was forced to use it once and I am defiantly brain
> damaged :)
What a confession.
> Chapter 5: Commenting
>
> Comments are good, the more you comment your code the better. These
> comments are not for you, they are for the poor schmuck that has to
> deal with your scratching later. Never underestimate the stupidity
> of this guy, don't leave anything to chance. Never assume that HE
> will understand your logic simply because YOU do.
Write readable code ;-)
> I have never really liked the C language, it seems to me that it has a
> habit of making ANY idiot think he/she can be a coder. C is an easy
> language to learn but to be a good C coder takes years of hard study
> and a TRUE artistic flair for programming. This means that 99% of all
> C code is JUNK code.
Not sure about the percentage, but there are langauages that are more
easily learned, and more easily abused, by people that have no clue what
locking or semaphores are good for that then write data base
applications for multiple simultaneous users.
-
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.4 and ipmasq modules
On 21 Jan 2001, Daniel Stone wrote: > FTP is under Connection Tracking support, FTP connection tracking. Does > the same stuff as ip_masq_ftp. IRC is located in patch-o-matic - > download iptables 1.2 and do a make patch-o-matic, there is also RPC and > eggdrop support in there. I'm half in the middle of porting ip_masq_icq, > but it's one hideously ugly kludge after another. Such is life. > uhmm... ICQ seems to work fine through connection tracking for me, so is there a need for a special ip_masq_icq module? > d regards, -- Paul Jakma [EMAIL PROTECTED] [EMAIL PROTECTED] PGP5 key: http://www.clubi.ie/jakma/publickey.txt --- Fortune: [We] use bad software and bad machines for the wrong things. -- R.W. Hamming - 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: named streams, extended attributes, and posix
Michael Rothwell writes: > ... >> Today, Michael Rothwell ([EMAIL PROTECTED]) wrote: >>> The filesystem, when registering that it supports the "named streams" >>> namespace, could specify its preferred delimiter to the VFS as well. >>> Ext4 could use /directory/file/stream, and NTFS could use >>> /directory/file:stream. ... > Oh, undoubtedly. But NTFS already disallows several characters > in valid filenames. NTFS allows all 16-bit characters in filenames, including 0x. Nothing is disallowed. The NT kernel's native API uses counted Unicode strings. The strings can be huge too, like 128 kB. So there isn't _any_ safe delimiter. Win32 will choke on 0x and a few other things, allowing a clever person to create apparently inaccessible files. - 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: Inefficient PCI DMA usage (was: [experimental patch] UHCI updates)
Johannes Erdfelt writes: > They need to be visible via DMA. They need to be 16 byte aligned. We > also have QH's which have similar requirements, but we don't use as many > of them. Can we get away from the "16 byte aligned" and make it "n byte aligned"? I believe that slab already has support for this? _ |_| - ---+---+- | | Russell King[EMAIL PROTECTED] --- --- | | | | http://www.arm.linux.org.uk/personal/aboutme.html / / | | +-+-+ --- -+- / | THE developer of ARM Linux |+| /|\ / | | | --- | +-+-+ - /\\\ | - 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?] Coding Style
On Sun, 21 Jan 2001, Admin Mailing Lists wrote: > > And the lord spake, saying, "First shalt thou write thy holy code. Indenting > > shalt thou count to three, no more, no less. Three shalt be the spaces thou > > shalt count, and the number of the counting shalt be three. Four shalt thou > > not count, nor count thou two, excepting that thou then proceedeth to three. > > Eight is right out. Once the number three, being the third number be > > reached, shalt thou move towards indenting thy next line .. > > > > now I know why I never read the bible. I thought that was the indention rules for Python. ]:> [EMAIL PROTECTED] | Note to AOL users: for a quick shortcut to reply Alan Olsen| to my mail, just hit the ctrl, alt and del keys. "In the future, everything will have its 15 minutes of blame." - 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?] Coding Style
We would never parody Monty Python! This is an excerpt from Judas, one of the gospels that was in dispute. I'm sorry, I must go, as there's a man in a military uniform here, shouting at me to stop being silly... -josh On Sat, 20 Jan 2001 23:58:07 Mike A. Harris wrote: > On Sun, 21 Jan 2001, Admin Mailing Lists wrote: > > >> And the lord spake, saying, "First shalt thou write thy holy code. . > If I'm not mistaken, the above is a parody on Monty Python's Holy > Grail. The Holy Hand Grenade of Antinoch if I'm correct. It's > been a while.. > . (i modified Mike's copyrighted document. do i need to get a license from all of the people he quoted as well as his? ;^) - 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: eepro100 error messages
On Tue, Jan 16, 2001 at 07:02:52PM -0800, Kostas Nikoloudakis wrote: > Jan 16 00:49:04 cd20 kernel: eth0: card reports no resources. > Jan 16 00:49:06 cd20 kernel: eth0: can't fill rx buffer (force 0)! The driver can't allocate buffers for incoming packets. Increase /proc/sys/vm/freepages numbers to start freeing the memory earlier and reserve more memory for allocation bursts. Best regards Andrey V. Savochkin - 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/
kernel 2.4.0 with 3c509 (patch included)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I have no trouble when I am using 2.2 with my 3c509 card but I can not load the 3c509 with 2.4 kernel. After digging into the kernel source, I figured out the problem. Here's the diff: 421,422d420 < request_region(ioaddr, EL3_IO_EXTENT, "3c509"); < /* 425d422 < */ Thanks. - -Xiaoyong - --- Network Research Engineer, 919.248.1469 Advanced Network Research Group,MCNC [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.1 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjpqhIUACgkQC2kI34vVezr8FwCbBaFRFiOtykAS9nZgDEoig4Mx dwgAnjgxB96gbCb2FC6T6TkuiF2PPsbS =fj/9 -END PGP SIGNATURE- - 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?] Coding Style
On Sun, 21 Jan 2001, Admin Mailing Lists wrote: >> And the lord spake, saying, "First shalt thou write thy holy code. Indenting >> shalt thou count to three, no more, no less. Three shalt be the spaces thou >> shalt count, and the number of the counting shalt be three. Four shalt thou >> not count, nor count thou two, excepting that thou then proceedeth to three. >> Eight is right out. Once the number three, being the third number be >> reached, shalt thou move towards indenting thy next line .. >> > >now I know why I never read the bible. > >people jsut dont know how old cryptography really is ;-) If I'm not mistaken, the above is a parody on Monty Python's Holy Grail. The Holy Hand Grenade of Antinoch if I'm correct. It's been a while.. -- Mike A. Harris - Linux advocate - Free Software advocate This message is copyright 2001, all rights reserved. Views expressed are my own, not necessarily shared by my employer. -- The day Microsoft makes something that doesn't suck, is probably the day Microsoft starts making vacuum cleaners. -- Ernst Jan Plugge - 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/
rwsemaphores and modules
Does anyone know why we have this code in include/linux/usbdevicefs.h? Is it still needed? /* * sigh. rwsemaphores do not (yet) work from modules */ #define rw_semaphore semaphore #define init_rwsem init_MUTEX #define down_read down #define down_write down #define up_read up #define up_write up Paul. -- Paul Mackerras, Open Source Research Fellow, Linuxcare, Inc. +61 2 6262 8990 tel, +61 2 6262 8991 fax [EMAIL PROTECTED], http://www.linuxcare.com.au/ Linuxcare. Support for the revolution. - 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?] Coding Style
On Sun, 21 Jan 2001, Ragnar Hojland Espinosa wrote: > On Sat, Jan 20, 2001 at 05:19:17PM +0100, [EMAIL PROTECTED] wrote: > > I just wanted to say that Linus´ CodingStyle is the ONLY SANE style of > > writing code in bigger projects. At university we are forced to use exactly the > > And the lord spake, saying, "First shalt thou write thy holy code. Indenting > shalt thou count to three, no more, no less. Three shalt be the spaces thou > shalt count, and the number of the counting shalt be three. Four shalt thou > not count, nor count thou two, excepting that thou then proceedeth to three. > Eight is right out. Once the number three, being the third number be > reached, shalt thou move towards indenting thy next line .. > now I know why I never read the bible. people jsut dont know how old cryptography really is ;-) -Tony .-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-. Anthony J. Biacco Network Administrator/Engineer [EMAIL PROTECTED] Intergrafix Internet Services "Dream as if you'll live forever, live as if you'll die today" http://www.asteroid-b612.orghttp://www.intergrafix.net .-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-. - 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: Minors remaining in Major 10 ??
On Sat, 20 Jan 2001, H. Peter Anvin wrote: > Andre Hedrick wrote: > > > > Hi Peter, > > > > Regardless if we rip out the entire rule of majors for dev_t, will there > > be a service dummy driver to various block-devices? There is a real need > > for this if we are going to get full control of the hardware by indirect > > access obtain the functionality that I see and need in the near future. > > > > At this point, I'll allocate a device number when someone is ready to > release a driver - no sooner. There simply is not a whole lot of choice > because of the extreme shortage of device numbers that's going to last us > until dev_t gets expanded. Cool Peter! Will finish the code hack and clean it up in the next three days or so... It is only an idea to test and you can see it in action first. Cheers, Andre Hedrick Linux ATA Development - 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: Minors remaining in Major 10 ??
Andre Hedrick wrote: > > Hi Peter, > > Regardless if we rip out the entire rule of majors for dev_t, will there > be a service dummy driver to various block-devices? There is a real need > for this if we are going to get full control of the hardware by indirect > access obtain the functionality that I see and need in the near future. > At this point, I'll allocate a device number when someone is ready to release a driver - no sooner. There simply is not a whole lot of choice because of the extreme shortage of device numbers that's going to last us until dev_t gets expanded. -hpad -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - 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: Minors remaining in Major 10 ??
On Sat, 20 Jan 2001, H. Peter Anvin wrote: > Andre Hedrick wrote: > > > > > > No, I think I understood perfectly well. I said that if it's going to be > > > bound to each block device subsystem it would make more sense to > > > establish that tie explicitly -- if that isn't possible I'm a bit > > > confused. > > > > Okay, I am definitely not clear because I am leading the wrong direction. > > A single char-device would access all of ATA or all of SCSI. > > > > That's fine. ATA and SCSI are a bit special because they have multiple > majors -- something that I hope we can get rid of with the dev_t > expansion anyway, but I think the principle still holds. Hi Peter, Regardless if we rip out the entire rule of majors for dev_t, will there be a service dummy driver to various block-devices? There is a real need for this if we are going to get full control of the hardware by indirect access obtain the functionality that I see and need in the near future. I want to use KMOD to an advantage. Assume removable device bays such that you can swap in any and every kind of ata-atapi device and/or all scsi-devices, one needs to have a way to tell the driver to do things that are not native to its general mode of operations as of today. Cheers, Andre Hedrick Linux ATA Development - 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: "Pass module parameters" to built-in drivers
On Sun, 21 Jan 2001 15:54:56 +1100, David Luyer <[EMAIL PROTECTED]> wrote: >Here's a proposed v2.4 "quick fix" to allow specifying "module parameters" to >any of the many drivers without option parsers when built in to the kernel. Fundamental problem: you assume that each module is built from a source of the same name, this is not true. For example, scsi_mod is built from several objects, including scsi.c and scsi_scan.c which contain MODULE_PARM. With your patch the user has to do scsi.c:scsihosts="..." scsi_scan.c:max_scsi_luns=n (built in) or options scsi_mod scsihosts="..." max_scsi_luns=n (module) Inconsistent methods for setting the same parameter are bad. I can and will do this cleanly in 2.5. Parameters will be always be keyed by the module name, even if they are compiled in. Adding an inconsistent method to 2.4 then changing to a correct method in 2.5 is a bad idea, wait until we can do it right. - 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?] Coding Style
On Sat, Jan 20, 2001 at 05:19:17PM +0100, [EMAIL PROTECTED] wrote: > I just wanted to say that Linus´ CodingStyle is the ONLY SANE style of > writing code in bigger projects. At university we are forced to use exactly the And the lord spake, saying, "First shalt thou write thy holy code. Indenting shalt thou count to three, no more, no less. Three shalt be the spaces thou shalt count, and the number of the counting shalt be three. Four shalt thou not count, nor count thou two, excepting that thou then proceedeth to three. Eight is right out. Once the number three, being the third number be reached, shalt thou move towards indenting thy next line .. .. ;) -- /| Ragnar Højland Freedom - Linux - OpenGL Fingerprint 94C4B \ o.O| 2F0D27DE025BE2302C =(_)= "Thou shalt not follow the NULL pointer for 104B78C56 B72F0822 U chaos and madness await thee at its end." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
PATCH: "Pass module parameters" to built-in drivers
Alan, Keith, All, Here's a proposed v2.4 "quick fix" to allow specifying "module parameters" to any of the many drivers without option parsers when built in to the kernel. I understand Keith has intentions to do this differently in v2.5, however I'd be happy if something along these lines could find its way into v2.4, maybe the below, something similar to the below but with the default of "N" instead, or maybe a completely different. I haven't tested it extensively - only so far as that it works just fine with all the modules that I wanted set options for on bootup; none of these are, for example, string or integer list options so those aren't tested. All code is placed in init functions, I'm not sure about where the strings specified as options to generic_parse_function will end up though. Comments/feedback? (and I know without the ".c" would be nicer, but AFAIK that can't be done without either extra run-time code (chop the .c at run-time) or makefile support (-D__FILEBASE__=). diff -urN orig/linux/Documentation/Configure.help linux/Documentation/Configure.help --- orig/linux/Documentation/Configure.help Wed Jan 17 15:30:13 2001 +++ linux/Documentation/Configure.help Sat Jan 20 11:18:41 2001 @@ -3729,6 +3729,14 @@ replacement for kerneld.) Say Y here and read about configuring it in Documentation/kmod.txt. +Module parameter parsing for non-modular drivers +CONFIG_MODPARM_BUILTIN + This allows you to set parameters which are normally passed as + options to modules by specifying the parameter as file.c:var=value + on the kernel command line (eg, xirc2ps_cs.c:lockup_hack=1). + Say Y here if unsure - all additional memory used is freed during + bootup. + ARP daemon support (EXPERIMENTAL) CONFIG_ARPD Normally, the kernel maintains an internal cache which maps IP diff -urN orig/linux/arch/alpha/config.in linux/arch/alpha/config.in --- orig/linux/arch/alpha/config.in Wed Jan 17 15:30:14 2001 +++ linux/arch/alpha/config.in Sat Jan 20 11:21:02 2001 @@ -20,6 +20,7 @@ bool 'Set version information on all symbols for modules' CONFIG_MODVERSIONS bool 'Kernel module loader' CONFIG_KMOD fi +bool 'Module parameter passing for non-modular drivers' CONFIG_MODPARM_BUILTIN endmenu mainmenu_option next_comment diff -urN orig/linux/arch/alpha/defconfig linux/arch/alpha/defconfig --- orig/linux/arch/alpha/defconfig Tue Oct 17 09:38:41 2000 +++ linux/arch/alpha/defconfig Sat Jan 20 11:19:05 2001 @@ -14,6 +14,7 @@ CONFIG_MODULES=y # CONFIG_MODVERSIONS is not set CONFIG_KMOD=y +CONFIG_MODPARM_BUILTIN=y # # General setup diff -urN orig/linux/arch/arm/config.in linux/arch/arm/config.in --- orig/linux/arch/arm/config.in Wed Jan 17 15:30:14 2001 +++ linux/arch/arm/config.inSat Jan 20 11:21:08 2001 @@ -25,6 +25,7 @@ bool ' Set version information on all module symbols' CONFIG_MODVERSIONS bool ' Kernel module loader' CONFIG_KMOD fi +bool 'Module parameter passing for non-modular drivers' CONFIG_MODPARM_BUILTIN endmenu diff -urN orig/linux/arch/arm/defconfig linux/arch/arm/defconfig --- orig/linux/arch/arm/defconfig Tue Jun 20 10:59:33 2000 +++ linux/arch/arm/defconfigSat Jan 20 11:19:11 2001 @@ -42,6 +42,7 @@ CONFIG_MODULES=y # CONFIG_MODVERSIONS is not set CONFIG_KMOD=y +CONFIG_MODPARM_BUILTIN=y # # General setup diff -urN orig/linux/arch/i386/config.in linux/arch/i386/config.in --- orig/linux/arch/i386/config.in Wed Jan 17 15:30:15 2001 +++ linux/arch/i386/config.in Sat Jan 20 11:14:55 2001 @@ -22,6 +22,7 @@ bool ' Set version information on all module symbols' CONFIG_MODVERSIONS bool ' Kernel module loader' CONFIG_KMOD fi +bool 'Module parameter passing for non-modular drivers' CONFIG_MODPARM_BUILTIN endmenu mainmenu_option next_comment diff -urN orig/linux/arch/i386/defconfig linux/arch/i386/defconfig --- orig/linux/arch/i386/defconfig Wed Jan 17 15:30:15 2001 +++ linux/arch/i386/defconfig Sat Jan 20 11:19:14 2001 @@ -17,6 +17,7 @@ CONFIG_MODULES=y CONFIG_MODVERSIONS=y CONFIG_KMOD=y +CONFIG_MODPARM_BUILTIN=y # # Processor type and features diff -urN orig/linux/arch/ia64/config.in linux/arch/ia64/config.in --- orig/linux/arch/ia64/config.in Wed Jan 17 15:30:16 2001 +++ linux/arch/ia64/config.in Sat Jan 20 11:21:18 2001 @@ -12,6 +12,7 @@ bool ' Set version information on all module symbols' CONFIG_MODVERSIONS bool ' Kernel module loader' CONFIG_KMOD fi +bool 'Module parameter passing for non-modular drivers' CONFIG_MODPARM_BUILTIN endmenu mainmenu_option next_comment diff -urN orig/linux/arch/ia64/defconfig linux/arch/ia64/defconfig --- orig/linux/arch/ia64/defconfig Fri Jun 23 00:09:44 2000 +++ linux/arch/ia64/defconfig Sat Jan 20 11:19:24 2001 @@ -39,6 +39,7 @@ # Loadable module support # # CONFIG_MODULES is not set +CONFIG_MODPARM_BUILTIN=y # # Parallel port support diff -urN orig/linux/arch/m68k/config.in linux/arch/m68k/config.in ---
[PATCH] Add help text for ATI Radeon
The below patch adds a help text for the ATI Radeon graphics card. The patch is against 2.4.1-pre9. --- linux/Documentation/Configure.help~ Sun Jan 21 04:08:54 2001 +++ linux/Documentation/Configure.help Sun Jan 21 04:49:29 2001 @@ -13132,6 +13132,11 @@ is selected, the module will be called r128.o. AGP support for this card is strongly suggested (unless you have a PCI version). +ATI Radeon +CONFIG_DRM_RADEON + Choose this option if you have a ATI Radeon graphics card. + If M is selected, the module will be called radeon.o. + Intel I810 CONFIG_DRM_I810 Choose this option if you have an Intel I810 graphics card. If M is -- André Dahlqvist <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Update URL for hdparm in Configure.help
The below patch changes the URL of hdparm to one which actually has the newest version of that tool. The patch is against 2.4.1-pre9. --- linux/Documentation/Configure.help~ Sun Jan 21 04:08:54 2001 +++ linux/Documentation/Configure.help Sun Jan 21 04:19:09 2001 @@ -415,7 +415,7 @@ To fine-tune ATA/IDE drive/interface parameters for improved performance, look for the hdparm package at - ftp://metalab.unc.edu/pub/Linux/kernel/patches/diskdrives/ . + http://www.ibiblio.org/pub/Linux/system/hardware . If you want to compile this driver as a module ( = code which can be inserted in and removed from the running kernel whenever you want), -- André Dahlqvist <[EMAIL PROTECTED]> - 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: PROBLEM: select() on TCP socket sleeps for 1 tick even if data available
OK, 2.4.0 kernel installed, and a new set of numbers: testkernel ping-pongs/s. @ total CPU util w/SOL_NDELAY sample (2 skts) 2.2.18 100 @ 0.1% 800 @ 1% sample (1 skt) 2.2.18 8000 @ 100% 8000 @ 50% real app2.2.18 100 @ 0.1% 800 @ 1% sample (2 skts) 2.4.0 8000 @ 50% 8000 @ 50% sample (1 skt) 2.4.0 1 @ 50% 1 @ 50% real app2.4.0 1200 @ 50% 1200 @ 50% real appWindows 2K 4000 @ 100% The two points that still seem strange to me are: 1. The 1 socket case is still 25% faster than the 2 socket case in 2.4.0 (in 2.2.18 the 1 socket case was 10x faster). 2. Linux never devotes more than 50% of the CPU (average over a long run) to the two processes (25% to each process, with the rest of the time idle). I'd really love to show that Linux is a viable platform for our SW, and I think it would be doable if I could figure out how to get the other 50% of my CPU involved. An "strace -rT" of the real app on 2.4.0 looks like this for each ping/pong. 0.052371 send(7, "\0\0\0 \177\0\0\1\3243\0\0\0\2\4\236\216\341\0\0\v\277"..., 32, 0) = 32 <0.000529> 0.000882 rt_sigprocmask(SIG_BLOCK, ~[], [RT_0], 8) = 0 <0.21> 0.000242 rt_sigprocmask(SIG_SETMASK, [RT_0], NULL, 8) = 0 <0.21> 0.000173 select(8, [3 4 6 7], NULL, NULL, NULL) = 1 (in [6]) <0.47> 0.000328 read(6, "\0\0\0 ", 4) = 4 <0.31> 0.000179 read(6, "\177\0\0\1\3242\0\0\0\2\4\236\216\341\0\0\7\327\177\0\0"..., 28) = 28 <0.75> -- Mike Lindner - 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?
Hi, On Sat, 20 Jan 2001, Linus Torvalds wrote: > 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. > > 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 completely agree, if we are talking about standard pc hardware. I was more thinking about some dedicated hardware, where you want to get the data directly to the correct place. If the hardware does a bit more with the data you need large buffers. In a standard pc the main cpu does most of the data processing, but in dedicated hardware you might have several cards each with it's own logic and memory and here the cpu does manage that stuff only. You can do all this of course from user space, but this means you have to copy the data around, what you don't want with such hardware, when the kernel can help you a bit. bye, Roman - 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.4 and ipmasq modules
On Sat, 20 Jan 2001, Aaron Lehmann wrote: > It was great to see that 2.4.0 reintroduced ipfwadm support! I had no > need for ipchains and ended up using the wrapper around it that > emulated ipfwadm. However, 2.[02].x used to have "special IP > masquerading modules" such as ip_masq_ftp.o, ip_masq_quake.o, etc. I > can't find these in 2.4.0. Where have they gone? Without important > modules such as ip_masq_ftp.o I cannot use non-passive ftp from behind > the masquerading firewall. I think its ip_conntrack_ftp, but I'll check my fw setup to verify if you still can't find it. -- -- John E. Jasen ([EMAIL PROTECTED]) -- In theory, theory and practise are the same. In practise, they aren't. - 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?
Hi, On Sat, 20 Jan 2001, Linus Torvalds wrote: > Now, there are things to look out for: when you do these kinds of dummy > "struct page" tricks, some macros etc WILL NOT WORK. In particular, we do > not currently have a good "page_to_bus/phys()" function. That means that > anybody trying to do DMA to this page is currently screwed, simply because > he has no good way of getting the physical address. > > This is a limitation in general: the PTE access functions would also like > to have "page_to_phys()" and "phys_to_page()" functions. It gets even > worse with IO mappings, where "CPU-physical" is NOT necessarily the same > as "bus-physical". That's why I want to avoid dummy struct page and use a real mem_map instead. I have two options: 1. I map everything together in one mem_map, like it's still done for m68k, the overhead here is in the phys_to_virt()/virt_to_phys() function. 2. I use several nodes like mips64/arm and virt_to_page() gets more complex, but this usually assumes a specific memory layout to keep it fast. Once that problem is solved, I can manage the memory on the card like the main memory and use it however I want. I probably do something like ia64 and use the highest bits as an offset into a table. bye, Roman - 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/
[OT] Re: 2.4 and ipmasq modules
Aaron Lehmann wrote: It was great to see that 2.4.0 reintroduced ipfwadm support! I had no need for ipchains and ended up using the wrapper around it that emulated ipfwadm. However, 2.[02].x used to have "special IP masquerading modules" such as ip_masq_ftp.o, ip_masq_quake.o, etc. I can't find these in 2.4.0. Where have they gone? Without important modules such as ip_masq_ftp.o I cannot use non-passive ftp from behind the masquerading firewall. It's working here for me - the netfilter modules are named differently: # lsmod Module Size Used by iptable_filter 1824 0 (autoclean) (unused) ip_nat_ftp 3280 0 (unused) iptable_nat 13120 1 [ip_nat_ftp] ip_conntrack_ftp 2016 0 (unused) ip_conntrack 13408 2 [ip_nat_ftp iptable_nat ip_conntrack_ftp] ip_tables 10784 4 [iptable_filter iptable_nat]
Re: PROBLEM: 2.4.1-pre9 does not compile on r128.c
Em Sun, Jan 21, 2001 at 02:45:16AM +0100, Pierre CORCINOS escreveu: > result of the compilation : read a previous post by Linus, it has a patch for that, IIRC - Arnaldo - 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/
PROBLEM: 2.4.1-pre9 does not compile on r128.c
result of the compilation :
gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2
-fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2
-march=i686 -DMODULE -DMODVERSIONS -include
/usr/src/linux/include/linux/modversions.h -DEXPORT_SYMTAB -c r128_drv.c
r128_drv.c:124: `DRM_IOCTL_R128_PACKET' undeclared here (not in a function)
r128_drv.c:124: nonconstant array index in initializer
r128_drv.c:124: (near initialization for `r128_ioctls')
{standard input}: Assembler messages:
{standard input}:8: Warning: Ignoring changed section attributes for .modinfo
make[3]: *** [r128_drv.o] Erreur 1
ver_linux :
Linux seyn 2.4.1-pre8 #3 dim jan 21 01:12:23 CET 2001 i686 unknown
Kernel modules 2.4.1
Gnu C 2.95.2
Gnu Make 3.79.1
Binutils 2.10.1.0.2
Linux C Library> libc.2.2
Dynamic linker ldd (GNU libc) 2.2
Procps 2.0.6
Mount 2.10q
Net-tools 2.05
Console-tools 0.2.3
Sh-utils 2.0.11
Modules Loaded ntfs nls_iso8859-15 nls_cp437 vfat fat emu10k1 soundcore
Congratulation for your job
--
Pierre CORCINOS <[EMAIL PROTECTED]>
-
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?
> I'm _not_ seeing the point for a high-performance link to have a generic > packet buffer. > > Linus Well suppose your RAID controller can take over control of disks distributed throughout your I/O subsystem. If you assume the bandwidth of the I/O subsystem is not the limiting factor, there's no need to hang the disks directly off the RAID controller. This makes even more sense if your computer can upload code to your peripherals which they can then run autonomously. Imagine if your filesystem code is mobile and can reside (perhaps to a variable extent) in your drives if you want it to. Of course none of this really relates to the case of the OS trying to get peripherals to talk to each other directly. DS - 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: PROBLEM: select() on TCP socket sleeps for 1 tick even if data available
> ...and I still don't understand why the identical program, but using one > socket instead of 2 sockets, IS CPU bound, and gets on the order of > 10K/sec. on the same HW. Diffs to produce 10K/sec. 1 socket version from > my previous sample follow... It's really this simple -- this isn't what TCP is intended for. DS - 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: Scanning problems - machine lockups
On Sat, Jan 20, 2001 at 03:54:22PM +, Stephen Kitchener wrote: > Any, I thought that it had cured the problem, but after a few scans, > admittedly more than before, the scan head didn't return on the last scan > that was successfully started. It sounds like you did solve the "lock the machine solid" problem by putting the video card on its own interrupt. Does anyone specifically maintain kernel/irq.c? - please submit some spurious interrupt handling (interrupts generated by devices that don't have a handler) along the lines of what David Woodhouse suggested. I would expect it to deactivate the IRQ and report the problem to the user so they can fix it themselves probably by changing the IRQ configuration - not perfect but better than locking up the machine with no message. > Trying to scan again, hoping that it would reset the scanner and carry on, > ... nothing, no response from scanner. So now apparently the scanner doesn't respond after a few scans, but the system continues to work OK. This sounds like a problem with either the scanner sw, advansys driver, or the scanner. 1) I'm not familiar with SANE (is that what you're using?), but it probably has some test programs. Please try them if they exist and report the results. 2) Please send the output of /proc/scsi/advansys/1 file after the hang. Also you said you have another advansys card (/proc/scsi/advansys/0) with a lot of devices attached. Do they all work correctly after the scanner hang? If so, the problem is isolated to the second card and it's not a general driver problem. 3) Another experiment is to compile the advansys driver as a module if you can and after the hang, rmmod/insmod it to see if the scanner starts working again. I would expect it to because this will reset the driver, adapter, and SCSI bus. -- Bob Frey [EMAIL PROTECTED] - 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: PROBLEM: select() on TCP socket sleeps for 1 tick even if data available
Chris Wedgwood wrote:
>
> On Sat, Jan 20, 2001 at 07:35:12PM -0500, Dan Maas wrote:
>
> Bingo! With this fix, 2.2.18 performance becomes almost identical to 2.4.0
> performance. I assume 2.4.0 disables Nagle by default on local
> connections...
>
> 2.4.x has a smarter nagle algorithm.
Thanks again for all the help, guys...
Haven't installed 2.4 yet, but I tried the setsockoption route.
Performance is better, but the two processes together never total more
than 50% of the CPU (i.e. the thing is still schedule-bound, not compute
bound, as it is on other platforms), and throughput is only up to 800
sends/sec. Better than the 100/sec. I was getting, but still a far cry
from the identical box running Windows, where performance is 8K/sec.
...and I still don't understand why the identical program, but using one
socket instead of 2 sockets, IS CPU bound, and gets on the order of
10K/sec. on the same HW. Diffs to produce 10K/sec. 1 socket version from
my previous sample follow...
--
Mike Lindner
diff sockperf.c sockperf1.c
163c163
< if (pings++ < 1000) {
---
> if (pings++ < 1) {
177c177
< fprintf(stderr, "elapsed time for 1000 pingpongs is %g\n",
now.tv_sec - then.tv_sec + (now.tv_usec - then.tv_usec) / 100.0);
---
> fprintf(stderr, "elapsed time for 1 pingpongs is %g\n", now.tv_sec -
>then.tv_sec + (now.tv_usec - then.tv_usec) / 100.0);
205c205
< int s = connectsock(argv[1], argv[3],
"tcp");
---
> int s = r;
214c214
< int r = accept(f, (struct sockaddr *) ,
);
---
> int r = s;
-
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: Minors remaining in Major 10 ??
On Sat, Jan 20 2001, Andre Hedrick wrote: > The idea is to have a char not a block because there is no buffered access > to the dummy driver. It is very painful to have to open one block device > and pass parameters to select the one you really want to service in a > passive mode. Like the raw devices we have already? -- * Jens Axboe <[EMAIL PROTECTED]> * SuSE Labs - 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, 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. 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. Linus - 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: PROBLEM: select() on TCP socket sleeps for 1 tick even if data available
> It's not the select that waits. It's a delay in the tcp send > path waiting for more data. Try disabling it: > > int f=1; > setsockopt(s, SOL_TCP, TCP_NODELAY, , sizeof(f)); Bingo! With this fix, 2.2.18 performance becomes almost identical to 2.4.0 performance. I assume 2.4.0 disables Nagle by default on local connections... Dan - 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: Ethernet drivers: SiS 900, Netgear FA311
Tobias Burnus wrote: > I think those drivers have not yet been merged. Since I happend to have > those (and had problem to get them run with the default kernel) I'd like > to asked whether those can be included into the kernel. They are GNU > licensed. Seemingly the SiS updates the existing sis900 driver, the > FA311 is not yet supported by the kernel. Not true, see natsemi.c (in 2.4.x at least). -- Jeff Garzik | "You see, in this world there's two kinds of Building 1024 | people, my friend: Those with loaded guns MandrakeSoft | and those who dig. You dig." --Blondie - 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, Roman Zippel wrote:
>
> AFAIK as long as that dummy page struct is only used in the page cache,
> that should work, but you get new problems as soon as you map the page
> also into a user process (grep for CONFIG_DISCONTIGMEM under
> include/asm-mips64 to see the needed changes). In the worst case one
> might need reverse mapping to get the page back. :)
No, for the CONTIGMEM case you can just use remap_page_range() directly:
it won't actually map the "struct page*" into the user space, it will just
map a special reserved page into user space. No changes needed.
So it just so happens that the physical address of the two "pages" is the
same in this case - one reachable through the dummy "struct page *" and
one reachable through the VM layer. The VM layer will never see the dummy
"struct page", and that's ok. It doesn't need it.
Now, there are things to look out for: when you do these kinds of dummy
"struct page" tricks, some macros etc WILL NOT WORK. In particular, we do
not currently have a good "page_to_bus/phys()" function. That means that
anybody trying to do DMA to this page is currently screwed, simply because
he has no good way of getting the physical address.
This is a limitation in general: the PTE access functions would also like
to have "page_to_phys()" and "phys_to_page()" functions. It gets even
worse with IO mappings, where "CPU-physical" is NOT necessarily the same
as "bus-physical".
It shouldn't be too hard to do the phys/bus addresses in general,
something like this should actually do it
static inline unsigned long page_to_physnr(struct page * page)
{
unsigned long offset;
struct zone_struct * zone = page->zone;
offset = zone->zone_mem_map - page;
return zone->zone_start_paddr + offset;
}
except right now I think "zone_start_paddr" is defined wrong (it's defined
to be the actual physical address, rather than being the "physical address
shifted right by the page-size". It needs to be the latter in order to
handle physical memory spaces that are bigger than "unsigned long" (ie
x86 PAE mode). Making the thing "unsigned long long" is _not_ an option,
considering how crappy gcc is at double integers.
Linus
-
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/
Ethernet drivers: SiS 900, Netgear FA311
Hi, I think those drivers have not yet been merged. Since I happend to have those (and had problem to get them run with the default kernel) I'd like to asked whether those can be included into the kernel. They are GNU licensed. Seemingly the SiS updates the existing sis900 driver, the FA311 is not yet supported by the kernel. http://www.sis.com.tw/ftp/Drivers/linux/630s/ readme.txt 13-Nov-2000 03:58 3k sis900.c13-Nov-2000 03:5846k sis900.h13-Nov-2000 03:58 9k http://www.netgear-support.com/ts/pwtservicepacks.cfm?spc=0=FA311=0 (e.g. fa311lx.zip: -rw-rw-rw- 48047 Aug 24 22:36 fa311.c -rw-rw-rw- 33203 Aug 24 22:36 fa311.h -rw-rw-rw-7820 Aug 24 22:36 fa311.o -rw-rw-rw- 131 Aug 24 22:36 makefile Tobias -- This above all: To thine own self be true / And it must follow as the night the day / Thou canst not then be false to any man. - 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.4 and ipmasq modules
Aaron Lehmann <[EMAIL PROTECTED]> writes: > On Sun, Jan 21, 2001 at 11:08:00AM +1100, Daniel Stone wrote: > > "I'd rather stay with my friendly old pushbike than my car!" > > So don't complain when you can't use cruise control. > > ipfwadm used to support the modules. Why have the modules for ipfwadm > been removed from the kernel source? Umm, because the underlying infrastructure is completely different? You're confusing 'ipfwadm' (a program that uses an old API that is emulated by the new kernel) and the kernel ipfw code, which is gone, gone, gone. -Doug - 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: Kernel 2.4.x & 2.4.1-preX Latency results - Based on 2.4.1-pre9
These results were based on the latest alpha 2.4.1-pre series kernel. Do they look ok? Shawn Starr wrote: > I've included the TPT latency timings. > > Do these look normal? > > These tests occured in X with netscape and gnomeicu. > > It should be noted that /dev/tty12 is being used for syslog info for > console. > > Shawn. > - 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-audio-dev] low-latency scheduling patch for 2.4.0
On Fri, Jan 12, 2001 at 07:45:43PM -0700, Jay Ts wrote: > Andrew Morton wrote: > > > > Jay Ts wrote: > > > > > > Now about the only thing left is to get it included > > > in the standard kernel. Do you think Linus Torvalds is more likely > > > to accept these patches than Ingo's? I sure hope this one works out. > > > > We (or "he") need to decide up-front that Linux is to become > > a low latency kernel. Then we need to decide the best way of > > doing that. > > > > Making the kernel internally preemptive is probably the best way of > > doing this. But it's a *big* task > > Ouch. Yes, I agree that the ideal path is for Linus and the other > kernel developers and ... well, just about everyone ... is to create > a long-range strategy and 'roadmap' that includes support for low-latency. > > And making the kernel preemptive might be the best way to do that > (and I'm saying "might"...). Keep in mind that Ken Thompson & Dennis Ritchie did not decide on a non-preemptive strategy for UNIX because they were unaware of such methods or because they were stupid. And when Rob Pike redesigned a new "unix" Plan9 note there is no-preemptive kernel, and the core Linux designers have rejected preemptive kernels too. Now it is certainly possible that things have change and/or all these folks are just plain wrong. But I wouldn't bet too much on it. -- - Victor Yodaiken Finite State Machine Labs: The RTLinux Company. www.fsmlabs.com www.rtlinux.com - 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.4 and ipmasq modules
On Sun, Jan 21, 2001 at 11:08:00AM +1100, Daniel Stone wrote: > > That option seems to conflict with "ipfwadm (2.0-style) support". > > Preferably, I'd like to stay with friendly old ipfwadm rather than > > switching firewalling tools _again_. > > "I'd rather stay with my friendly old pushbike than my car!" > So don't complain when you can't use cruise control. ipfwadm used to support the modules. Why have the modules for ipfwadm been removed from the kernel source? - 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-audio-dev] low-latency scheduling patch for 2.4.0
Let me just point out that Nigel (I think) has previously stated that the purpose of this approach is to bring the stunning success of IRIX style "RT" to Linux. Since some of us believe that IRIX is a virtual handbook of OS errors, it really comes down to a design style. I think that simplicity and "does the main job well" wins every time over "really cool algorithms" and "does everything badly". Others disagree. On Sat, Jan 13, 2001 at 12:30:46AM +1100, Andrew Morton wrote: > Nigel Gamble wrote: > > > > Spinlocks should not be held for lots of time. This adversely affects > > SMP scalability as well as latency. That's why MontaVista's kernel > > preemption patch uses sleeping mutex locks instead of spinlocks for the > > long held locks. > > Nigel, > > what worries me about this is the Apache-flock-serialisation saga. > > Back in -test8, kumon@fujitsu demonstrated that changing this: > > lock_kernel() > down(sem) > > up(sem) > unlock_kernel() > > into this: > > down(sem) > > up(sem) > > had the effect of *decreasing* Apache's maximum connection rate > on an 8-way from ~5,000 connections/sec to ~2,000 conn/sec. > > That's downright scary. > > Obviously, was very quick, and the CPUs were passing through > this section at a great rate. > > How can we be sure that converting spinlocks to semaphores > won't do the same thing? Perhaps for workloads which we > aren't testing? > > So this needs to be done with caution. > > As davem points out, now we know where the problems are > occurring, a good next step is to redesign some of those > parts of the VM and buffercache. I don't think this will > be too hard, but they have to *want* to change :) > > Some of those algorithms are approximately O(N^2), for huge > values of N. > > > - > - > 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/ -- - Victor Yodaiken Finite State Machine Labs: The RTLinux Company. www.fsmlabs.com www.rtlinux.com - 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.4.0-ac10
Hi Alan, --- linux-2.4.0-ac9/arch/i386/boot/bootsect.S Tue Jul 18 23:55:01 2000 +++ linux-2.4.0-ac10/arch/i386/boot/bootsect.S Sat Jan 20 02:47:07 2001 @@ -5,8 +5,12 @@ * modified by Bruce Evans (bde) * modified by Chris Noe (May 1999) (as86 -> gas) * - * bootsect is loaded at 0x7c00 by the bios-startup routines, and moves - * itself out of the way to address 0x9, and jumps there. + * 360k/720k disk support: Andrzej Krzysztofowicz <[EMAIL PROTECTED]> I wonder how this line gets into your patch. Please, remove it (patch follows). My bootsector patch is NOT enclosed into 2.4.0-ac10. Yes, I did rewrite some time ago the bootsect.S to enable booting a kernel with (bootsect.o + setup.o) > 4 kB [ it happens eg. when video selection is compiled in ] from a 360k/720k (8 sec/track) floppy, but AFAIR it is alredy obsolete and has never been ported to 2.4. Note that it is almost impossible to compile an usable [you must turn off networking] i386 2.4 kernel which fits into 360k floppy... And there are other bootsect.S related unsolved problems [large kernels]. Regards Andrzej ** --- arch/i386/boot/bootsect.S.orig Sat Jan 20 18:36:39 2001 +++ arch/i386/boot/bootsect.S Sat Jan 20 18:36:55 2001 @@ -5,8 +5,6 @@ * modified by Bruce Evans (bde) * modified by Chris Noe (May 1999) (as86 -> gas) * - * 360k/720k disk support: Andrzej Krzysztofowicz <[EMAIL PROTECTED]> - * * BIG FAT NOTE: We're in real mode using 64k segments. Therefore segment * addresses must be multiplied by 16 to obtain their respective linear * addresses. To avoid confusion, linear addresses are written using leading ** -- === Andrzej M. Krzysztofowicz [EMAIL PROTECTED] phone (48)(58) 347 14 61 Faculty of Applied Phys. & Math., Technical University of Gdansk - 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.4 and ipmasq modules
On 20 Jan 2001 15:34:03 -0800, Aaron Lehmann wrote: > On Sun, Jan 21, 2001 at 10:32:15AM +1100, Daniel Stone wrote: > > FTP is under Connection Tracking support, FTP connection tracking. Does > > the same stuff as ip_masq_ftp. IRC is located in patch-o-matic - > > download iptables 1.2 and do a make patch-o-matic, there is also RPC and > > eggdrop support in there. I'm half in the middle of porting ip_masq_icq, > > but it's one hideously ugly kludge after another. Such is life. > > That option seems to conflict with "ipfwadm (2.0-style) support". > Preferably, I'd like to stay with friendly old ipfwadm rather than > switching firewalling tools _again_. Your choice, but if you choose not to switch, you lose the power of: * stateful inspection * modules * a sane command line * a metric shitload of extensions "I'd rather stay with my friendly old pushbike than my car!" So don't complain when you can't use cruise control. d -- Daniel Stone Linux Kernel Developer [EMAIL PROTECTED] -BEGIN GEEK CODE BLOCK- Version: 3.1 G!>CS d s++:- a C++ ULS$>B P L+++> E+(joe)>+++ W++ N->++ !o K? w++(--) O M- V-- PS+++ PE- Y PGP>++ t--- 5-- X- R- tv-(!) b+++ DI+++ D+ G e->++ h!(+) r+(%) y? UF++ --END GEEK CODE BLOCK-- - 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: [preview] Latest AMD & VIA IDE drivers with UDMA100 support
On Sat, 20 Jan 2001 14:57:07 -0800 (PST), Andre Hedrick wrote: ... > >Vojtech, I worry that the dynamic timing that you are calculating could >bite you. Timings are exact especially at modes 3/4/5 the margins go to >an effective zero for varition or wiggle room. The state diagrams from >Quantum that created the Ultra DMA 0,1,2,3,4,5 show how darn tight it >constrained. You need to assume absolutes because the various board >makers screw up the skew tables by the PCB lane traces. > I am not sure this is just a question of small variations. The hdparm -t differences between these two versions is quite significant. This evidence would imply that the two approaches are making fundemental different decisions about what my hardware can do! Under 2.2.17 /dev/hda: Timing buffered disk reads: 64 MB in 21.86 seconds = 2.93 MB/sec /dev/hdc: Timing buffered disk reads: 64 MB in 20.81 seconds = 3.08 MB/sec Under 2.4.0 /dev/hda: Timing buffered disk reads: 64 MB in 6.58 seconds = 9.73 MB/sec /dev/hdc: Timing buffered disk reads: 64 MB in 6.59 seconds = 9.71 MB/sec Alan [EMAIL PROTECTED] http://www.chandler.u-net.com - 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: Minors remaining in Major 10 ??
On Sat, 20 Jan 2001, H. Peter Anvin wrote: > Andre Hedrick wrote: > > > > On Sat, 20 Jan 2001, H. Peter Anvin wrote: > > > > > Andre Hedrick wrote: > > > > > > > > HPA, > > > > > > > > Thoughts on granting all block subsystems a general access misc-char minor > > > > to do special service access that can not be down to a given device if it > > > > is open. There are some things you can not do to a device if you are > > > > using its device-point to gain entry. Also do the grab a neighboor and > > > > force the migration to find the desired major/minor is painful. > > > > > > > > > > Hmmm... this would be better done using a dedicated major (and then minor > > > = block major.) This is something we can do in 2.5 once we have the > > > larger dev_t; at this point, I'd be really hesitant to allocate > > > additional that aren't obligatory. > > > > Er, I did not make the point clear enough, drat. > > > > mknod /dev/ide-service c 10 ??? > > mknod /dev/scsi-service c 10 ??? > > > > These would be char devices that would allow one to pass a struct to an > > ioctl to do device or host services that normally have to attempted by > > opening the device desired. This fails if you are trying to unload the > > driver (with KMOD enabled) so that you could switch devices or change > > driver types. Yes this is the migration to a hotswap^H^H^H^H^H^H^H > > general host/device services calls. > > > > No, I think I understood perfectly well. I said that if it's going to be > bound to each block device subsystem it would make more sense to > establish that tie explicitly -- if that isn't possible I'm a bit > confused. Okay, I am definitely not clear because I am leading the wrong direction. A single char-device would access all of ATA or all of SCSI. Seek by a number of known things by the running kernel to find and select the needed host/device by a passive method. host[I] interrupt[J] iobases[K] lun_index[L] memmaps[M] or direct MAJOR|MINOR The idea is to have a char not a block because there is no buffered access to the dummy driver. It is very painful to have to open one block device and pass parameters to select the one you really want to service in a passive mode. However, this looks like a case for another phone call because I am not able to explain it in email the way it needs to be explained :-(( Somebody please write a book, 'Communication for DUMMIES' please. Andre Hedrick Linux ATA Development - 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/
Kernel 2.4.x & 2.4.1-preX Latency results
I've included the TPT latency timings. Do these look normal? These tests occured in X with netscape and gnomeicu. It should be noted that /dev/tty12 is being used for syslog info for console. Shawn. Destination Count Min Max Average Total do_IRQ.in:0 -> irq.c:437 2281 2.59 7.79 4.64 10,602.21 do_IRQ.out:0 913.39 18.8517.23 155.14 softirq.c:71 5839 10.19 29.9614.81 86,487.67 softirq.c:174 -> softirq.c:177 5848 .72 1.10 .74 4,350.14 timer.c:657 -> timer.c:664 5848 1.03 7.30 1.95 11,429.92 timer.c:290 -> timer.c:314 2965 1.04 10.20 1.72 5,122.29 timer.c:323 2883 .90 8.64 1.31 3,786.21 softirq.c:129 -> softirq.c:132 22 .73 .85 .75 16.69 console.c:2020 -> console.c:2044 202.50 2,189.42 113.99 2,279.94 softirq.c:83 -> sched.c:661 604.86 8.08 5.43 325.98 sched.c:591 483 3.15 10.00 5.57 2,692.64 do_IRQ.out:0 5990 .70 1.75 .90 5,441.94 softirq.c:71 83 .78 .89 .82 68.23 sched.c:702 -> sched.c:737 11998 .77 6.92 2.35 28,281.37 page_alloc.c:105 -> page_alloc.c:137 10981 .93 3.93 1.68 18,486.39 slab.c:1298 -> slab.c:1322 219754 .83 4.22 1.11 245,026.41 slab.c:1329 21 .85 1.50 1.07 22.67 slab.c:1107 -> slab.c:1118 211.11 1.70 1.29 27.21 page_alloc.c:181 -> page_alloc.c:198 11257 1.28 7.78 2.59 29,256.21 slab.c:1149 -> slab.c:1159 21 .83 1.11 .88 18.65 softirq.c:60 -> softirq.c:71 27 .81 1.40 .99 26.95 fork.c:688 -> fork.c:696 3 3.68 4.00 3.88 11.66 sched.c:336 -> sched.c:343 2096 .87 4.20 1.88 3,949.99 slab.c:1582 -> slab.c:1586 2189421.07 6.92 1.60 350,699.01 fork.c:51 -> fork.c:54 38 .83 1.10 .89 33.91 sched.c:666 -> sched.c:591 272 1.21 1.77 1.31 357.98 fork.c:61 -> fork.c:63 80150 .75 3.86 .90 72,482.23 sched.c:784 -> sched.c:661 402.82 5.13 3.20 128.27 sched.c:591 1182 2.39 9.84 3.24 3,831.06 signal.c:1053 -> signal.c:1056 13 .87 2.20 1.24 16.13 fork.c:41 -> fork.c:44 80112 .78 2.67 1.04 83,981.73 timer.c:180 -> timer.c:184 9557 .83 3.07 1.60 15,293.84 timer.c:316 -> timer.c:314 1513 .80 3.24 1.32 1,998.37 timer.c:323 2965 .82 1.81 1.08 3,224.91 timer.c:218 -> timer.c:221 9395 .76 1.83 1.02 9,588.75 time.c:262 -> time.c:271 420717 .86 3.42 1.18 498,929.85 pc_keyb.c:485 -> pc_keyb.c:487 19 12.84 33.2922.62 429.84 irq.c:446 -> sched.c:591 4 7.50 9.29 8.70 34.80 do_IRQ.out:0 2130 1.80 5.25 3.03 6,462.64 softirq.c:71 151 2.40 4.38 3.40 514.36 irq.c:476 -> irq.c:481 1 2.32 2.32 2.32 2.32 irq.c:523 -> irq.c:542 1 2.10 2.10 2.10 2.10 ide.c:1536 -> ide.c:1604 196 2.55 7.75 4.70 921.63 ide.c:538 -> ide.c:547 196 2.31 4.52
Re: 2.4 and ipmasq modules
On Sun, Jan 21, 2001 at 10:32:15AM +1100, Daniel Stone wrote: > FTP is under Connection Tracking support, FTP connection tracking. Does > the same stuff as ip_masq_ftp. IRC is located in patch-o-matic - > download iptables 1.2 and do a make patch-o-matic, there is also RPC and > eggdrop support in there. I'm half in the middle of porting ip_masq_icq, > but it's one hideously ugly kludge after another. Such is life. That option seems to conflict with "ipfwadm (2.0-style) support". Preferably, I'd like to stay with friendly old ipfwadm rather than switching firewalling tools _again_. - 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: 2.4 and ipmasq modules
FTP is under Connection Tracking support, FTP connection tracking. Does the same stuff as ip_masq_ftp. IRC is located in patch-o-matic - download iptables 1.2 and do a make patch-o-matic, there is also RPC and eggdrop support in there. I'm half in the middle of porting ip_masq_icq, but it's one hideously ugly kludge after another. Such is life. d On 20 Jan 2001 14:46:16 -0800, Aaron Lehmann wrote: > It was great to see that 2.4.0 reintroduced ipfwadm support! I had no > need for ipchains and ended up using the wrapper around it that > emulated ipfwadm. However, 2.[02].x used to have "special IP > masquerading modules" such as ip_masq_ftp.o, ip_masq_quake.o, etc. I > can't find these in 2.4.0. Where have they gone? Without important > modules such as ip_masq_ftp.o I cannot use non-passive ftp from behind > the masquerading firewall. > > Thanks, > Aaron Lehmann > - > 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/ -- Daniel Stone Linux Kernel Developer [EMAIL PROTECTED] -BEGIN GEEK CODE BLOCK- Version: 3.1 G!>CS d s++:- a C++ ULS$>B P L+++> E+(joe)>+++ W++ N->++ !o K? w++(--) O M- V-- PS+++ PE- Y PGP>++ t--- 5-- X- R- tv-(!) b+++ DI+++ D+ G e->++ h!(+) r+(%) y? UF++ --END GEEK CODE BLOCK-- - 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: md= broken. Found problem. Can't fix it. : (
Douglas Gilbert wrote: > > Dave, > Look at the dmesg output and check that your > "Kernel command line:" is what you think it > is. Some older versions of lilo truncate it. > Here is mine (which is what I expected): > > Kernel command line: auto BOOT_IMAGE=lin240 ro root=803 scsihosts=imm:advansys:a > dvansys:aha1542 No that is not the problem. I'm using GRUB (LILO == poopoo) and have looked at this throughly. I can see from the dmesg via my debugging printk's output that str is properly being passed. -- "Nobody will ever be safe until the last cop is dead." NH Rep. Tom Alciere - (My new Hero) - 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: Minors remaining in Major 10 ??
Andre Hedrick wrote: > > On Sat, 20 Jan 2001, H. Peter Anvin wrote: > > > Andre Hedrick wrote: > > > > > > HPA, > > > > > > Thoughts on granting all block subsystems a general access misc-char minor > > > to do special service access that can not be down to a given device if it > > > is open. There are some things you can not do to a device if you are > > > using its device-point to gain entry. Also do the grab a neighboor and > > > force the migration to find the desired major/minor is painful. > > > > > > > Hmmm... this would be better done using a dedicated major (and then minor > > = block major.) This is something we can do in 2.5 once we have the > > larger dev_t; at this point, I'd be really hesitant to allocate > > additional that aren't obligatory. > > Er, I did not make the point clear enough, drat. > > mknod /dev/ide-service c 10 ??? > mknod /dev/scsi-service c 10 ??? > > These would be char devices that would allow one to pass a struct to an > ioctl to do device or host services that normally have to attempted by > opening the device desired. This fails if you are trying to unload the > driver (with KMOD enabled) so that you could switch devices or change > driver types. Yes this is the migration to a hotswap^H^H^H^H^H^H^H > general host/device services calls. > No, I think I understood perfectly well. I said that if it's going to be bound to each block device subsystem it would make more sense to establish that tie explicitly -- if that isn't possible I'm a bit confused. -hpa -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - 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)]]
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: 37563201 24.1 HTTP 1.1 Requests: 118282092 75.9 HTTP Unknown Requests: 1 0.0 ... cheers, lincoln.
Re: Minors remaining in Major 10 ??
On Sat, 20 Jan 2001, H. Peter Anvin wrote: > Andre Hedrick wrote: > > > > HPA, > > > > Thoughts on granting all block subsystems a general access misc-char minor > > to do special service access that can not be down to a given device if it > > is open. There are some things you can not do to a device if you are > > using its device-point to gain entry. Also do the grab a neighboor and > > force the migration to find the desired major/minor is painful. > > > > Hmmm... this would be better done using a dedicated major (and then minor > = block major.) This is something we can do in 2.5 once we have the > larger dev_t; at this point, I'd be really hesitant to allocate > additional that aren't obligatory. Er, I did not make the point clear enough, drat. mknod /dev/ide-service c 10 ??? mknod /dev/scsi-service c 10 ??? These would be char devices that would allow one to pass a struct to an ioctl to do device or host services that normally have to attempted by opening the device desired. This fails if you are trying to unload the driver (with KMOD enabled) so that you could switch devices or change driver types. Yes this is the migration to a hotswap^H^H^H^H^H^H^H general host/device services calls. Cheers, Andre Hedrick Linux ATA Development - 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: [preview] Latest AMD & VIA IDE drivers with UDMA100 support
On Sat, 20 Jan 2001, Vojtech Pavlik wrote: > On Sat, Jan 20, 2001 at 06:45:10PM +, Alan Chandler wrote: > > On Thu, 20 Jan 2011 09:51:03 -0800 (PST), you wrote: > > > > >On Sat, 20 Jan 2001, Alan Chandler wrote: > > > > > >> I'm running with an Abit K7 (uses via82c686a in southbridge) with IBM > > >> deskstar 8.4gb disks (DHEA-38451) as masters in ide0 and 1. They only > > >> do UDMA mode 2. I am not overclocking or anything - all should be > > >> running at default speeds with an Athlon 900. > > >> > > >> Just to be clear - I am NOT getting any errors when I switch back to > > >> the 2.2.17 kernel (debian standard) - with a 2.4.0 kernel they occur > > >> every few minutes when there is significant disk activity. > > > > > >But that kernel uses the stock driver that was the original second > > >generation correct? > > > > > >Andre Hedrick > > >Linux ATA Development > > > > > > > Sorry, I realise now what I said was ambiguous. To be clear > > > > 2.2.17 - absolutely standard as shipped in debian - no errors This is with the original ide.2.2.17.??.date.patch and not the morfing timing code you have started. > > 2.4.0 - standard (downloaded tar.bz2) - ERRORS > > 2.4.0 - as standard except for three files in tar.bz2 attachment to > > Vojtech Pavlik's mail which were placed in drivers/ide directory - > > ERRORS. > > Alan > > Wonderful! A case where I can compare a working setup with a nonworking > one! :) Could you please send me the usual stuff (dmesg, lspci -vvxxx, > cat /proc/ide/via, hdparm -i /dev/hd*, hdparm -t /dev/hd*) for both the > 2.2 case and the 2.4.0+VIA-latest case? That'll allow me to find the > differences and possibly fix the new driver. Vojtech, I worry that the dynamic timing that you are calculating could bite you. Timings are exact especially at modes 3/4/5 the margins go to an effective zero for varition or wiggle room. The state diagrams from Quantum that created the Ultra DMA 0,1,2,3,4,5 show how darn tight it constrained. You need to assume absolutes because the various board makers screw up the skew tables by the PCB lane traces. By assuming only absolutes, all vendors that do bad designs will show and the user can not and "should" not be allowed to hold the driver in a state that can damage filesystems or lock the box. Since I have never addressed this issue in public it is no obvious why I hardcoded timings and did not let tehm float, but I hope it is clearer now. chipset ---\ | \-IDC-header chipset ---+ | +--IDC-header These are nearly the same but the corners cause bounce and iCRC's Cheers, Andre Hedrick Linux ATA Development - 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/
2.4 and ipmasq modules
It was great to see that 2.4.0 reintroduced ipfwadm support! I had no need for ipchains and ended up using the wrapper around it that emulated ipfwadm. However, 2.[02].x used to have "special IP masquerading modules" such as ip_masq_ftp.o, ip_masq_quake.o, etc. I can't find these in 2.4.0. Where have they gone? Without important modules such as ip_masq_ftp.o I cannot use non-passive ftp from behind the masquerading firewall. Thanks, Aaron Lehmann - 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: md= broken. Found problem. Can't fix it. : (
Sandy Harris wrote:
> Looks to me like this parsing code unnecessarily and rather clumsily
> re-invents strtok
The original parsing code is this:
if ((str = strchr(str, ',')) != NULL)
str++;
Which effectivly steps through
/dev/sda1,/dev/sdab1,/dev/sdc1
like this
str == /dev/sda1,/dev/sdab1,/dev/sdc1
str == /dev/sdab1,/dev/sdc1
str == /dev/sdc1
My code:char *ndevstr;
ndevstr = strchr(str, ',');
if (ndevstr != NULL)*ndevstr++ = 0;
...
str = ndevstr
Works perfectly. I don't find it 'clumsy' or more complex at all. (I don't care
for strtok, nor did I even know the kernel had it)
However I don't see this critique of coding style helping the problem I'm
seeing:
name_to_kdev_t(str);
Returns a bad value. Yet
name_to_kdev_t("/dev/sdd5");
does not. The strange thing is
printk("Checking: '%s'\n", str);
shows str does infact contain a proper string.
It appears str does not get passed to name_to_kdev_t() properly,
and I have no idea why. Both my testing code and the original code
exhibit the same problem.
--
"Nobody will ever be safe until the last cop is dead."
NH Rep. Tom Alciere - (My new Hero)
-
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?
Hi, 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? That might be true especially for embedded devices. The cpu is then just the local controller, that manages several devices with its own buffer. Let's take a file server with multiple disks and multiple network cards with it's own buffer. For stuff like this you don't want to go through the main memory, on the other hand you still need to synchronize all the data. Although I don't know such hardware, but I don't see a reason not to do it under Linux. :-) bye, Roman - 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: PROBLEM: select() on TCP socket sleeps for 1 tick even if data available
Michael Lindner wrote:
>[...]
> send(s, ".", 1, 0);
>[...]
> while (select(r+1, , 0, 0, 0) > 0) {
>[...]
>[select returns only after about 1 HZ]
Ever heard of nagle? (If not, there's a long thread about
it on the mailing list *g*)
It's not the select that waits. It's a delay in the tcp send
path waiting for more data. Try disabling it:
int f=1;
setsockopt(s, SOL_TCP, TCP_NODELAY, , sizeof(f));
Ciao, ET.
-
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: md= broken. Found problem. Can't fix it. : (
On Sat, Jan 20, 2001 at 04:58:56PM -0500, Sandy Harris wrote: > I suspect that I've misunderstood some constraint here. Perhaps the more complex > code you posted is necessary, but I'd like to know why. strtok is not reentrant and cannot be nested this way without saving __strtok. strsep would work. -Andi - 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: Minors remaining in Major 10 ??
Andre Hedrick wrote: > > HPA, > > Thoughts on granting all block subsystems a general access misc-char minor > to do special service access that can not be down to a given device if it > is open. There are some things you can not do to a device if you are > using its device-point to gain entry. Also do the grab a neighboor and > force the migration to find the desired major/minor is painful. > Hmmm... this would be better done using a dedicated major (and then minor = block major.) This is something we can do in 2.5 once we have the larger dev_t; at this point, I'd be really hesitant to allocate additional that aren't obligatory. -hpa -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - 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: md= broken. Found problem. Can't fix it. : (
Dave Cinege wrote:
>
> ... 'md=' for each device on
> the cmdline, but unfortuantly it's broken.
>
> Between a few emails to mingo and several wasted hours, I've managed to figure
> out the problem. However I don't know how to fix it; it *should*
> be working from what I can see.
>
> My only guess right now is because I'm using gcc 2.95.2, and it's doing
> something funky. (And I do not have another version to test with right now.)
>
> The problem is during parsing of the md= line, name_to_kdev_t() is not
> returning the proper k_dev_t for the device. (IE /dev/sdd5 returns as
> 16:45 /dev/sde5 returns as 20:05.)
Looks to me like this parsing code unnecessarily and rather clumsily re-invents
strtok() and should be rewritten to use that function. It takes two nested loops,
along the general lines of:
/*
outer loop, parse into space-separted strings
*/
for( p = strtok(str, " ") ; p != NULL ; p = strtok(NULL, " ") {
/*
inner loop using comma separator
*
for( q = strtok( p, ",") ; q != NULL ; q = strtok(NULL, ","){
}
}
I suspect that I've misunderstood some constraint here. Perhaps the more complex
code you posted is necessary, but I'd like to know why.
> However if I pass static text to name_to_kdev_t(), it works. I first believed
> it was in how the str pointer was sent to name_to_kdev_t(), (running over into
> comma's, instead of seperate terminated strings) I
> fixed that but the problem persists.
>
> My current test for loop is attached. The hard coded device names
> printk out to a proper major:minor. The devicenames obtained from
> 'str' don't. I don't see the bug in here or name_to_kdev_t()...
>
> I'm testing this with the following cmdline:
> root=/dev/md0 raid=noautodetect md=0,/dev/hdd5,/dev/hde5
> md=1,/dev/hdd6,/dev/hde6 md=2,/dev/hdd7,/dev/hde7
> md=3,/dev/hdd8,/dev/hde8 mem=524288K
>
> --
> "Nobody will ever be safe until the last cop is dead."
> NH Rep. Tom Alciere - (My new Hero)
>
>
>
> 2.4.1prepatch 8
> drivers/md/md.c line 3722
>
> for (; i < MD_SB_DISKS && str; i++) {
> /*
> if ((device = name_to_kdev_t(str))) {
> md_setup_args.devices[minor][i] = device;
> } else {
> printk ("md: Unknown device name, %s.\n", str);
> return 0;
> }
> if ((str = strchr(str, ',')) != NULL)
> str++;
> */
>
> char *ndevstr;
> ndevstr = strchr(str, ','); // Goto ','
> if (ndevstr != NULL)
> *ndevstr++ = 0; // Zero it for proper string
>
> // DEBUG Print device name
> printk("Checking: '%s'\n", str);
>
>
> // Convert device name to k_dev_t and assign to md_setup_args.devices
> // DEBUG As test, hardcode device names for /dev/md0.0 and /dev/md0.1
> if (minor == 0 && i == 0)
> md_setup_args.devices[minor][i] =
>name_to_kdev_t("/dev/sdd5");
> else if (minor == 0 && i == 1)
> md_setup_args.devices[minor][i] =
>name_to_kdev_t("/dev/sde5");
> else
> md_setup_args.devices[minor][i] = name_to_kdev_t(str);
>
> // DEBUG Print out kdevname of md_setup_args.devices
> printk("\t%s\n", kdevname(md_setup_args.devices[minor][i]));
> // DEBUG Print minor and i (insync?)
> printk("minor=%d, i=%d\n",minor, i);
>
> // name_to_kdev_t() returned 0. Invalid device
> if (md_setup_args.devices[minor][i] == 0) {
> printk ("md: Unknown device name, %s.\n", str);
> return 0;
> }
> // Jump to next devname in str
> str = ndevstr;
> }
-
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/
md= broken. Found problem. Can't fix it. : (
I have multiple Linux hosts on a SAN, making autodetect of raid devices
dangerous. This problem should be solved by specing an 'md=' for each device on
the cmdline, but unfortuantly it's broken.
Between a few emails to mingo and several wasted hours, I've managed to figure
out the problem. However I don't know how to fix it; it *should*
be working from what I can see.
My only guess right now is because I'm using gcc 2.95.2, and it's doing
something funky. (And I do not have another version to test with right now.)
The problem is during parsing of the md= line, name_to_kdev_t() is not
returning the proper k_dev_t for the device. (IE /dev/sdd5 returns as
16:45 /dev/sde5 returns as 20:05.)
However if I pass static text to name_to_kdev_t(), it works. I first believed
it was in how the str pointer was sent to name_to_kdev_t(), (running over into
comma's, instead of seperate terminated strings) I
fixed that but the problem persists.
My current test for loop is attached. The hard coded device names
printk out to a proper major:minor. The devicenames obtained from
'str' don't. I don't see the bug in here or name_to_kdev_t()...
I'm testing this with the following cmdline:
root=/dev/md0 raid=noautodetect md=0,/dev/hdd5,/dev/hde5
md=1,/dev/hdd6,/dev/hde6 md=2,/dev/hdd7,/dev/hde7
md=3,/dev/hdd8,/dev/hde8 mem=524288K
--
"Nobody will ever be safe until the last cop is dead."
NH Rep. Tom Alciere - (My new Hero)
2.4.1prepatch 8
drivers/md/md.c line 3722
for (; i < MD_SB_DISKS && str; i++) {
/*
if ((device = name_to_kdev_t(str))) {
md_setup_args.devices[minor][i] = device;
} else {
printk ("md: Unknown device name, %s.\n", str);
return 0;
}
if ((str = strchr(str, ',')) != NULL)
str++;
*/
char *ndevstr;
ndevstr = strchr(str, ','); // Goto ','
if (ndevstr != NULL)
*ndevstr++ = 0; // Zero it for proper string
// DEBUG Print device name
printk("Checking: '%s'\n", str);
// Convert device name to k_dev_t and assign to md_setup_args.devices
// DEBUG As test, hardcode device names for /dev/md0.0 and /dev/md0.1
if (minor == 0 && i == 0)
md_setup_args.devices[minor][i] = name_to_kdev_t("/dev/sdd5");
else if (minor == 0 && i == 1)
md_setup_args.devices[minor][i] = name_to_kdev_t("/dev/sde5");
else
md_setup_args.devices[minor][i] = name_to_kdev_t(str);
// DEBUG Print out kdevname of md_setup_args.devices
printk("\t%s\n", kdevname(md_setup_args.devices[minor][i]));
// DEBUG Print minor and i (insync?)
printk("minor=%d, i=%d\n",minor, i);
// name_to_kdev_t() returned 0. Invalid device
if (md_setup_args.devices[minor][i] == 0) {
printk ("md: Unknown device name, %s.\n", str);
return 0;
}
// Jump to next devname in str
str = ndevstr;
}
Re: Via apollo KX133 ide bug in 2.4.x
Peter Horton wrote: > On Thu, Jan 20, 2000 at 08:38:12AM +, Peter Horton wrote: > > > > I think I'm suffering the same thing on my new Asus A7V. Yesterday I got a > > single "error in bitmap, remounting read only" type error, and today I got > > some files in /tmp that returned I/O error when stat()ed. I do have DMA > > enabled, but only UDMA33. I've done several kernel compiles with no > > problems at all so looks like something is on the edge. Think I might go > > back to 2.2.x for a bit and see what happens, or maybe just remove the VIA > > driver :-((. > > > > I apologise for following up my own E-mail, but there is something I'm > missing here (maybe a whole lot of something). Anyone know how come we're > seeing silent corruption ... I thought this UDMA stuff was all checksummed > ? If there error is outside the data I assume the driver would notice ? > > P. The thing is, even with UDMA disabled in the kernel, I still see the corruption with 2.4.x (release) and above. Anything written while using the kernel is corrupted. Much of the stuff will read fine (files) ... but I believe directories get the IO error immediately and some files do also. Everything is seen as corrupted when you fsck a partition where this kernel has been run and created files on. This is a silent corruption without any errors reported and I've only tested it on ext2. You cannot create FS's with these kernels (at least on the VIA chipsets) since they too are corrupted (note, only tested ext2 fs). I did disable UDMA everywhere and still saw it happen, this problem is not present in older 2.4.0-test kernels so it's something in the late pre-release stage and into the release stage. - 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?
Hi, On Sat, 20 Jan 2001, Linus Torvalds wrote: > There's no no-no here: you can even create the "struct page"s on demand, > and create a dummy local zone that contains them that they all point back > to. It should be trivial - nobody else cares about those pages or that > zone anyway. AFAIK as long as that dummy page struct is only used in the page cache, that should work, but you get new problems as soon as you map the page also into a user process (grep for CONFIG_DISCONTIGMEM under include/asm-mips64 to see the needed changes). In the worst case one might need reverse mapping to get the page back. :) > That said, nobody has actually done this in practice yet, so there may be > details to work out, of course. I don't see any fundamental reasons it > wouldn't easily work, but.. I hope I have soon the time to experiment with this, so I'll now for sure. I don't see major problems, except I don't know yet, how the performance will be. bye, Roman - 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 Sat, Jan 20, 2001 at 10:39:36PM +0300, Alexey Kuznetsov wrote: > Yes. It is cost, which we have to pay. Look into Minshall's draft, > by the way (draft-minshall-nagle-*), it discusses pros and contras. What kind of draft is that? I can't find it on the IETF site. Could you provide me with a link? --- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> --- See also: http://tinc.nl.linux.org/ http://www.kernelbench.org/ --- PGP signature
Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]
On Sat, Jan 20, 2001 at 11:22:14PM +0300, [EMAIL PROTECTED] wrote: > Hello! > > > > write(10*MSS) > > > write(1) > > > write(1) > ... > > As far as I can tell, the second "write(1)" will always merge with the > > first one > > This would be true, if Andrea wrote not exactly 10*MSS, > but 10*MSS+1 or just write(). So then this: val = 1 setsockopt(TCP_CORK, ) /* cork */ write(10*MSS+1) write(1) val = 0 setsockopt(TCP_CORK, ) /* uncork */ is different from this: val = 1 setsockopt(TCP_CORK, ) /* cork */ write(10*MSS+1) write(1) val = 0 setsockopt(TCP_CORK, ) /* uncork */ val = 1 setsockopt(TCP_NODELAY, ) val = 0 setsockopt(TCP_NODELAY, ) This was all my wondering about uncorking not being equivalent to SIOCPUSH. (the two setsockopt(TCP_NODELAY) can be replaced with a SIOCPUSH of course) If I understood wall they would been equivalent if I did write(10*MSS) instead of write(10*MSS+1). (and btw, the TCP_NODELAY being cleared immediatly means that if the last packet can't be sent during the setsockopt it will be delayed with nagle as usual when we get the acknowledgments from the receiver, that's the same mistake of my SIOCPUSH first implementation that infact should be sligtly improved in the way descriped a few emails ago adding a tp->push field and then it will become different than going for a moment in TCP_NODELAY mode) Andrea - 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?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Today, Linus Torvalds ([EMAIL PROTECTED]) wrote: > Just wait. My crystal ball is infallible. One of these days, that line will be your downfall :-) *grins* Mo. - -- Mo McKinlay [EMAIL PROTECTED] - - GnuPG/PGP Key: pub 1024D/76A275F9 2000-07-22 -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjpp/ssACgkQRcGgB3aidfmcagCgkieTFD77O+Xqn+nmcaoiYERh UwwAoIL8cWZPdaKine4fZ4fJmQqwTvBZ =i1Ax -END PGP SIGNATURE- - 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 Sat, Jan 20, 2001 at 10:39:36PM +0300, [EMAIL PROTECTED] wrote: > Much saner behaviour wrt latency (and perfect clarity) overweights IMHO latency can be fixed in a much better way using ioctl(SIOCPUSH) after the last write() plus we could also add a MSG_NOMORE to set in the last send(). MSG_NOMORE would be not anonymous-capable but it would have zero syscall cost compared to SIOCPUSH. This would also address when the stack still delays something by mistake, and yes it must still delay something sometime (even if not in my example) otherwise setsockopt(TCP_NODELAY) is a noop. Whatever heuristic you use it can't get right all the cases because it misses information that it can't recover by guessing the right thing to do. Legacy userspace will run still fine, optimized software will take advantage of the new capability of the stack. In short instead of decreasing merging capabilities of the stack IMHO it's better to give the information from userspace to the stack to let it know when it must stop to do merging. This way the stack will always do the right thing. Andrea - 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 20 Jan 2001, Kai Henningsen wrote: > > Then again, I could easily see those I/O devices go the general embedded > route, which in a decade or two could well mean they run some sort of > embedded Linux on the controller. > > Which would make some features rather easy to implement. I'm not worried about a certain class of features. I will predict, for example, that disk subsystems etc will continue to get smarter, to the point where most people will end up just buying a "file server" whenever they buy a disk. THOSE kinds of features are the obvious ones when you have devices that get smarter, and the kinds of features people are willing to pay for. The things I find really doubtful is that somebody would be so silly as to make the low-level electrical protocol be anything but a simple direct point-to-point link. Shared buses just do not scale, and they also have some major problems with true high-performance GBps bandwidth. Look at where ethernet is today. Ten years ago most people used it as a bus. These days almost everybody thinks of ethernet as point-to-point, with switches and hubs to make it look nothing like the bus of yore. You just don't connect multiple devices to one wire any more. The advantage of direct point-to-point links is that it's a hell of a lot faster, and it's also much easier to distribute - the links don't have to be in lock-step any more etc. It's perfectly ok to have one really high-performance link for devices that need it, and a few low-performance links in the same system do not bog the fast one down. 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. The exception to this will be when you hav esmart devices that _internally_ also have the same kind of structure, and you have a RAID device with multiple disks in a star around the raid controller. Then you'll find the raid controller doing raid rebuilds etc without the data ever coming off that "local star" - but this is not something that the OS will even get involved in other than sending the raid controller the command to start the rebuild. It's not a "device-device" transfer in that bigger sense - it's internal to the raid unit. Just wait. My crystal ball is infallible. Linus - 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 Sat, Jan 20, 2001 at 11:39:30AM -0800, Linus Torvalds wrote: > As far as I can tell, the second "write(1)" will always merge with the > first one - unless the first one has already been sent out, [..] Here the question is only if the first write(1) will be still there when we do the second write(1). If the first write(1) is still there it will of course merge fine with the second write(1) as usual. With 2.4 we'll send out the first write(1) immediatly on the wire if cwnd and receiver window allows that without caring that there are packets out. While the classcal nagle (the only one I known about) would wait for the second write(1) to arrive until all the previously sent data is been acknowledged from the receiver (to give to the second write(1) the time to be merged with the first write(1)). It's not obvious this new algorithm a good thing to me but I won't argue if this is the new standard algorithm. So now the question is: when does this new nagle algorithm delay packets in the write queue? It _must_ do something, otherwise TCP_NODELAY would obviously be a noop. Andrea - 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: Via apollo KX133 ide bug in 2.4.x
On Thu, Jan 20, 2000 at 08:38:12AM +, Peter Horton wrote: > > I think I'm suffering the same thing on my new Asus A7V. Yesterday I got a > single "error in bitmap, remounting read only" type error, and today I got > some files in /tmp that returned I/O error when stat()ed. I do have DMA > enabled, but only UDMA33. I've done several kernel compiles with no > problems at all so looks like something is on the edge. Think I might go > back to 2.2.x for a bit and see what happens, or maybe just remove the VIA > driver :-((. > I apologise for following up my own E-mail, but there is something I'm missing here (maybe a whole lot of something). Anyone know how come we're seeing silent corruption ... I thought this UDMA stuff was all checksummed ? If there error is outside the data I assume the driver would notice ? P. - 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: [preview] Latest AMD & VIA IDE drivers with UDMA100 support
On Sat, Jan 20, 2001 at 06:45:10PM +, Alan Chandler wrote: > On Thu, 20 Jan 2011 09:51:03 -0800 (PST), you wrote: > > >On Sat, 20 Jan 2001, Alan Chandler wrote: > > > >> I'm running with an Abit K7 (uses via82c686a in southbridge) with IBM > >> deskstar 8.4gb disks (DHEA-38451) as masters in ide0 and 1. They only > >> do UDMA mode 2. I am not overclocking or anything - all should be > >> running at default speeds with an Athlon 900. > >> > >> Just to be clear - I am NOT getting any errors when I switch back to > >> the 2.2.17 kernel (debian standard) - with a 2.4.0 kernel they occur > >> every few minutes when there is significant disk activity. > > > >But that kernel uses the stock driver that was the original second > >generation correct? > > > >Andre Hedrick > >Linux ATA Development > > > > Sorry, I realise now what I said was ambiguous. To be clear > > 2.2.17 - absolutely standard as shipped in debian - no errors > 2.4.0 - standard (downloaded tar.bz2) - ERRORS > 2.4.0 - as standard except for three files in tar.bz2 attachment to > Vojtech Pavlik's mail which were placed in drivers/ide directory - > ERRORS. > Alan Wonderful! A case where I can compare a working setup with a nonworking one! :) Could you please send me the usual stuff (dmesg, lspci -vvxxx, cat /proc/ide/via, hdparm -i /dev/hd*, hdparm -t /dev/hd*) for both the 2.2 case and the 2.4.0+VIA-latest case? That'll allow me to find the differences and possibly fix the new driver. -- Vojtech Pavlik SuSE Labs - 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)]]
Hello! > > write(10*MSS) > > write(1) > > write(1) ... > As far as I can tell, the second "write(1)" will always merge with the > first one This would be true, if Andrea wrote not exactly 10*MSS, but 10*MSS+1 or just write(). In some exceptional situations (sort of writing exactly N*MSS, then remnant, then something) Minshall's and bsd coalescing are a bit different. Alexey - 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: Kernel 2.4.x and 2.4.1-preX - Higher latency then 2.2.x kernels?
Where can i get the patch? I can apply it right now. Gregory Maxwell wrote: > On Sat, Jan 20, 2001 at 02:50:16PM -0500, Shawn Starr wrote: > > It just seems that since using 2.4 ive noticed my poor Pentium 200Mhz > > slow down whether being in X or otherwise. It just seems that the system > > is sluggish. > > > > I am using the new ReiserFS filesystem and I do know its still in heavy > > development perhaps my latency is due to this (?) > > Reiserfs uses much more complex data structures then ext2 (trees..). I don't > think that latency has ever been a design criteria and all of the benchmarks > they use are pretty much pure throughput tests. > > So it wouldn't be really surprising if reiserfs had very bad latency. You > should apply the timepegs patch and profile your kernel latency to see where > it's coming from. > - > 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/ - 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: Kernel 2.4.x and 2.4.1-preX - Higher latency then 2.2.x kernels?
On Sat, Jan 20, 2001 at 02:50:16PM -0500, Shawn Starr wrote: > It just seems that since using 2.4 ive noticed my poor Pentium 200Mhz > slow down whether being in X or otherwise. It just seems that the system > is sluggish. > > I am using the new ReiserFS filesystem and I do know its still in heavy > development perhaps my latency is due to this (?) Reiserfs uses much more complex data structures then ext2 (trees..). I don't think that latency has ever been a design criteria and all of the benchmarks they use are pretty much pure throughput tests. So it wouldn't be really surprising if reiserfs had very bad latency. You should apply the timepegs patch and profile your kernel latency to see where it's coming from. - 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/
Oops in 2.2.17
Using 2.2.17 kernel that is standard other than the bridging firewall patch, this Oops happened while setting up tripwire - it was scanning the disk and then locked up. As its purely a remote machine, I am only able to go off of the logs in syslogd. Below is the ksymoops report. If im leaving anything out, please let me know. While its somewhat relevant, it will also oops when doing a shutdown -h but I added the option for buggy chipsets, but havnt tested it, as its a server and shouldnt really be shutdown anyhow. Ksymoops report: ksymoops 2.3.4 on i586 2.2.17. Options used -v /usr/src/linux/vmlinux (specified) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.2.17/ (default) -m /usr/src/linux/System.map (default) Jan 20 13:14:59 Venus kernel: current->tss.cr3 = 00101000, %%cr3 = 00101000 Jan 20 13:14:59 Venus kernel: *pde = Jan 20 13:14:59 Venus kernel: Oops: Jan 20 13:14:59 Venus kernel: CPU:0 Jan 20 13:14:59 Venus kernel: EIP:0010:[show_registers+653/704] Jan 20 13:14:59 Venus kernel: EFLAGS: 00010046 Jan 20 13:14:59 Venus kernel: eax: ebx: ecx: e86e2fe2 edx: c1c78000 Jan 20 13:14:59 Venus kernel: esi: 28181f68 edi: c1fb ebp: c280 esp: c1faff2c Jan 20 13:14:59 Venus kernel: ds: 0018 es: 0018 ss: 0018 Jan 20 13:14:59 Venus kernel: Process kswapd (pid: 5, process nr: 5, stackpage=c1faf000) Jan 20 13:14:59 Venus kernel: Stack: e86e2fe2 0e00 c0206d2e c01bee9a c1fae1c1 0e00 c1faffd4 c1fae000 Jan 20 13:14:59 Venus kernel:c021961c c021961c e86e2fe2 00010286 e86e2fe3 c300 c0108d58 c1faffb0 Jan 20 13:14:59 Venus kernel:c01bb776 c01bd16e c010dfc0 c01bd16e c1faffb0 Jan 20 13:15:00 Venus kernel: Call Trace: [tvecs+7194/13344] [] [die+48/56] [error_table+2646/9568] [error_table+9294/9568] [do_page_fault+708/944] [error_table+9294/9568] Jan 20 13:15:00 Venus kernel: Code: 8a 04 0b 89 44 24 38 50 68 6e b7 1b c0 e8 91 9d 00 00 83 c4 Using defaults from ksymoops -t elf32-i386 -a i386 Code; Before first symbol <_EIP>: Code; Before first symbol 0: 8a 04 0b mov(%ebx,%ecx,1),%al Code; 0003 Before first symbol 3: 89 44 24 38 mov%eax,0x38(%esp,1) Code; 0007 Before first symbol 7: 50push %eax Code; 0008 Before first symbol 8: 68 6e b7 1b c0push $0xc01bb76e Code; 000d Before first symbol d: e8 91 9d 00 00call 9da3 <_EIP+0x9da3> 9da3 Before first symbol Code; 0012 Before first symbol 12: 83 c4 00 add$0x0,%esp System information: [syonic@Venus syonic]$ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 5 model : 2 model name : Pentium 75 - 200 stepping : 5 cpu MHz : 100.230 fdiv_bug : no hlt_bug : no sep_bug : no f00f_bug : yes coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr mce cx8 bogomips : 199.88 Its a SOYO 5ED board with ETEQ 82C662X chipset (the manual is available at http://www.soyousa.com/manuals/586new/m5ed20f.pdf if your really interested in every part of the board) The machine is serving as a firewall for my internal network. Its only been running for a few days so far with no problems. If any other information is needed at all, please let me know. I am unable to reproduce it when using tripwire again, So im not sure how to reproduce this, but I'm open to any suggestions. Also, the bridging firewall patch (which I would like to see in 2.4) is available at http://ac2i.tzo.com/bridge_filter/linux_brfw_2.2.17.diff in case your wondering what I've done to my kernel, but I dont think its too relevant, but im not a kernel developer. Again, let me know if theres anything I can do to further trace this. -- James Brents [EMAIL PROTECTED] - 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)]]
Hello! > So this mean if I do: Yes. It is cost, which we have to pay. Look into Minshall's draft, by the way (draft-minshall-nagle-*), it discusses pros and contras. Much saner behaviour wrt latency (and perfect clarity) overweights a bit worse coalescing. Alexey - 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?
[EMAIL PROTECTED] (Linus Torvalds) wrote on 18.01.01 in <[EMAIL PROTECTED]>: > (Short and sweet: most hogh-performance people want point-to-point serial > line IO with no hops, because it's a known art to make that go fast. No > general-case routing in hardware - if you want to go as fast as the > devices and the link can go, you just don't have time to route. Trying to > support device->device transfers easily slows down the _common_ case, > which is why I personally doubt it will even be supported 10-15 years from > now. Better hardware does NOT mean "more features"). Well, maybe. Then again, I could easily see those I/O devices go the general embedded route, which in a decade or two could well mean they run some sort of embedded Linux on the controller. Which would make some features rather easy to implement. (Think about it: twenty years from mow, a typical desktop machine may be a heterogenous Linux cluster. Didn't someone say something about World Domination?) (Note that I predicted this 2001-01-20T16:35:30. Just in case it actually works out that way.) MfG Kai - 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)]]
[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? I justtried the following excercise: Request a nonexistant page with HTTP/1.1 syntax. a. Directly from Apache: I get a nice chunked HTTP/1.1 answer. b. Via Squid: I get a plain HTTP/1.0 answer. As long as not even Squid talks 1.1, how can we expect browsers to do it? WebMUX? In a thousand years perhaps. MfG Kai - 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/
Kernel 2.4.x and 2.4.1-preX - Higher latency then 2.2.x kernels?
It it just me or does it seem that 2.4.x has some latency problems? It just seems that since using 2.4 ive noticed my poor Pentium 200Mhz slow down whether being in X or otherwise. It just seems that the system is sluggish. I am using the new ReiserFS filesystem and I do know its still in heavy development perhaps my latency is due to this (?) Any suggestions? Shawn. - 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: [RFC] generic IO write clustering
On Sat, 20 Jan 2001, Christoph Hellwig wrote: > On Sat, Jan 20, 2001 at 02:00:24PM -0200, Marcelo Tosatti wrote: > > > True. But you have to go through ext2_get_branch (under the big kernel > > > lock) - if we can do only one logical->physical block translations, > > > why doing it multiple times? > > > > You dont. If the metadata is cached and uptodate there is no need to call > > get_block(). > > Ups. You are right for the stock tree - I was only looking at my kio tree, > where it can't be cached due to the lack of buffer-cache usage... Must be fixed. We need a higher level abstraction which can hold this (and other) information. Take a look at SGI's pagebuf page_buf_t. - 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-usb-devel] Re: Inefficient PCI DMA usage (was:[experimentalpatch] UHCI updates)
The usb-ohci driver, widely used on non-x86 platforms, has hit
the same issue. (Including on some ARM setups.) An EHCI driver
(usb 2.0, 60 MByte/sec) under way has it too.
The alternative of having every device driver implement their
own simplified (?) kmem_cache code would just seem wrong; it'd
certainly be the cause of lots of bugs. Simplest to just let
the kmem cache code reach into a different page pool, and make
drivers init their kmem caches appropriately.
I'd hope such a thing wouldn't need to wait for the 2.5 tree to
branch, since using 2.4 effectively on some non-Intel architectures
will require wider use of the pci_{alloc,free}_consistent() stuff.
- Dave
- Original Message -
From: Johannes Erdfelt <[EMAIL PROTECTED]>
To: Russell King <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Saturday, January 20, 2001 9:34 AM
Subject: [linux-usb-devel] Re: Inefficient PCI DMA usage (was: [experimentalpatch] UHCI
updates)
> On Sat, Jan 20, 2001, Russell King <[EMAIL PROTECTED]> wrote:
> > Johannes Erdfelt writes:
> > > On Fri, Jan 19, 2001, Miles Lane <[EMAIL PROTECTED]> wrote:
> > > > Johannes Erdfelt wrote:
> > > >
> > > > > TODO
> > > > >
> > > > > - The PCI DMA architecture is horribly inefficient on x86 and ia64. The
> > > > > result is a page is allocated for each TD. This is evil. Perhaps a slab
> > > > > cache internally? Or modify the generic slab cache to handle PCI DMA
> > > > > pages instead?
> > > >
> > > > This might be the kind of thing to run past Linus when the 2.5 tree
> > > > opens up. Are these inefficiencies necessary evils due to workarounds
> > > > for whacky bugs in BIOSen or PCI chipsets or are they due to poor
> > > > design/implementation?
> > >
> > > Looks like poor design/implementation. Or perhaps it was designed for
> > > another reason than I want to use it for.
> >
> > Why? What are you trying to do? Allocate one area per small structure?
> > Why not allocate one big area and allocate from that (like the tulip
> > drivers do for their TX and RX rings)?
> >
> > I don't really know what you're trying to do/what the problem is because
> > there isn't enough context left in the original mail above, and I have
> > no idea whether the original mail appeared here or where I can read it.
>
> I was hoping the context from the original TODO up there was sufficient
> and it looked like it was enough.
>
> TD's are around 32 bytes big (actually, they may be 48 or even 64 now, I
> haven't checked recently). That's a waste of space for an entire page.
>
> However, having every driver implement it's own slab cache seems a
> complete waste of time when we already have the code to do so in
> mm/slab.c. It would be nice if we could extend the generic slab code to
> understand the PCI DMA API for us.
>
> > > I should also check architectures other than x86 and ia64.
> >
> > This is an absolute must.
>
> Not really. The 2 interesting architectures are x86 and ia64 since
> that's where you commonly see UHCI controllers. While you can add UHCI
> controllers to most any other architecture which has PCI, you usually
> see OHCI on those systems.
>
> I was curious to see if any other architectures implemented it
> differently and I was just expecting too much out of the API. You pretty
> much confirmed my suspicions when you suggested doing what the tulip
> driver does.
>
> JE
>
>
> ___
> [EMAIL PROTECTED]
> To unsubscribe, use the last form field at:
> http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
-
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 Sat, 20 Jan 2001, Andrea Arcangeli wrote: > On Sat, Jan 20, 2001 at 10:05:45PM +0300, [EMAIL PROTECTED] wrote: > > It makes. One small packet is allowed to fly, not depending on packets_out. > > So this mean if I do: > > write(10*MSS) > write(1) > write(1) > > 2.4 can send 10 packet with MSS large payload plus two packets with a > payload of 1 byte even if during the two write(1) the previous packets were > still out (not acknowledged yet). Classical nagle would send 10 packet with > MSS large payload plus 1 packet with a two bytes payload in the same > scenario. As far as I can tell, the second "write(1)" will always merge with the first one - unless the first one has already been sent out, of course (in which classical nagle would have done the same thing). So I think we'd do TheRightThing(tm) regardless. But maybe I misread. Linus - 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 Sat, Jan 20, 2001 at 10:05:45PM +0300, [EMAIL PROTECTED] wrote: > It makes. One small packet is allowed to fly, not depending on packets_out. So this mean if I do: write(10*MSS) write(1) write(1) 2.4 can send 10 packet with MSS large payload plus two packets with a payload of 1 byte even if during the two write(1) the previous packets were still out (not acknowledged yet). Classical nagle would send 10 packet with MSS large payload plus 1 packet with a two bytes payload in the same scenario. Andre - 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 [EMAIL PROTECTED] wrote: > > Actually, as long as there is no "struct page" there _are_ problems. > > This is why the NUMA stuff was brought up - it would require that there > > be a mem_map for the PCI pages.. (to do ref-counting etc). > > I see. > > Is this strong "no-no-no"? What is obstacle to allow "struct page" > to sit outside of mem_map (in some private table, or as full orphan)? > Only bloat of struct page with reference to some "page_ops" or something > more profound? There's no no-no here: you can even create the "struct page"s on demand, and create a dummy local zone that contains them that they all point back to. It should be trivial - nobody else cares about those pages or that zone anyway. This is very much how the MM layer in 2.4.x is set up to work. That said, nobody has actually done this in practice yet, so there may be details to work out, of course. I don't see any fundamental reasons it wouldn't easily work, but.. Linus - 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: [RFC] generic IO write clustering
On Sat, Jan 20, 2001 at 02:00:24PM -0200, Marcelo Tosatti wrote: > > True. But you have to go through ext2_get_branch (under the big kernel > > lock) - if we can do only one logical->physical block translations, > > why doing it multiple times? > > You dont. If the metadata is cached and uptodate there is no need to call > get_block(). Ups. You are right for the stock tree - I was only looking at my kio tree, where it can't be cached due to the lack of buffer-cache usage... Christoph -- Whip me. Beat me. Make me maintain AIX. - 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)]]
Hello! > semantics of snd_sml), maybe it makes the difference but then I don't see how. It makes. One small packet is allowed to fly, not depending on packets_out. This is idea of Minshall. "Classic" Nagle also does not prohibit this, but it is difficult to formulate it in terms of presegmented queue, used in linux, so that we preferred Minshall's approach. Third algo, used by linux-2.2: "queue as soon as packet is small and packets_out!=0" is _not_ Nagle's one, it is surely wrong. Alexey - 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?
Hello! > Actually, as long as there is no "struct page" there _are_ problems. > This is why the NUMA stuff was brought up - it would require that there > be a mem_map for the PCI pages.. (to do ref-counting etc). I see. Is this strong "no-no-no"? What is obstacle to allow "struct page" to sit outside of mem_map (in some private table, or as full orphan)? Only bloat of struct page with reference to some "page_ops" or something more profound? > It does work at least on some hardware. But no, I don't think you can > depend on bursting (but I don't see why it couldn't work in theory). I do not see too, but documents are pretty obscure explaining this. MRM seems to be prohibited for pci-pci. But my education is still not enough even to understand, whether MRM is required to burst or this is fully orthogonal yet. 8) Alexey - 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: lvm-oops in 2.4.1pre8
On Sat, Jan 20 2001, Andrea Arcangeli wrote:
> On Sat, Jan 20, 2001 at 06:41:06PM +0100, [EMAIL PROTECTED] wrote:
> > hi,
> >
> > got this oops when doing a
> > vgextend -v vgroot /dev/ide/host2/bus0/target0/lun0/part2 \
> > /dev/ide/host2/bus1/target0/lun0/part2
>
> You should upgrade to 0.9.1_beta2 that should merge all the known fixes out
> there. It's planned for inclusion into 2.4.1.
If you are doing updates, could you include this patch too? All it does
is waste memory.
--
* Jens Axboe <[EMAIL PROTECTED]>
* SuSE Labs
--- /kt/linux-2.4.1-pre9/drivers/md/lvm.c Fri Dec 29 23:07:22 2000
+++ drivers/md/lvm.cSat Jan 20 19:50:59 2001
@@ -208,9 +208,6 @@
extern int lvm_init(void);
#endif
-static void lvm_dummy_device_request(request_queue_t *);
-#defineDEVICE_REQUEST lvm_dummy_device_request
-
static int lvm_make_request_fn(request_queue_t*, int, struct buffer_head*);
static int lvm_blk_ioctl(struct inode *, struct file *, uint, ulong);
@@ -464,7 +461,6 @@
lvm_hd_name_ptr = lvm_hd_name;
#endif
- blk_init_queue(BLK_DEFAULT_QUEUE(MAJOR_NR), DEVICE_REQUEST);
blk_queue_make_request(BLK_DEFAULT_QUEUE(MAJOR_NR), lvm_make_request_fn);
/* optional read root VGDA */
@@ -504,7 +500,6 @@
if (unregister_blkdev(MAJOR_NR, lvm_name) < 0) {
printk(KERN_ERR "%s -- unregister_blkdev failed\n", lvm_name);
}
- blk_cleanup_queue(BLK_DEFAULT_QUEUE(MAJOR_NR));
gendisk_ptr = gendisk_ptr_prev = gendisk_head;
while (gendisk_ptr != NULL) {
@@ -1730,21 +1725,6 @@
return;
}
#endif
-
-
-/*
- * this one never should be called...
- */
-static void lvm_dummy_device_request(request_queue_t * t)
-{
- printk(KERN_EMERG
-"%s -- oops, got lvm request for %02d:%02d [sector: %lu]\n",
- lvm_name,
- MAJOR(CURRENT->rq_dev),
- MINOR(CURRENT->rq_dev),
- CURRENT->sector);
- return;
-}
/*
Re: Serious file system corruption with RAID5+SMP and kernelsabove2.4.0
I can't even get RAID5 to assemble thew md devices under 2.4.0 and 2.4.1-pre7. On Sat, 20 Jan 2001, Holger Kiehl wrote: > Date: Sat, 20 Jan 2001 19:42:04 +0100 (CET) > From: Holger Kiehl <[EMAIL PROTECTED]> > To: Otto Meier <[EMAIL PROTECTED]> > Cc: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>, > "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> > Subject: Re: Serious file system corruption with RAID5+SMP and kernels > above2.4.0 > > On Sat, 20 Jan 2001, Otto Meier wrote: > > > Two days ago I tried new kernels on my SMP SW RAID5 System > > and expirienced serous file system corruption with kernels 2.4.1-pre8,9 as >2.4.0-ac8,9,10. > > The same error has been reported by other people on this list. With 2.4.0 release > > everything runs fine. So I backsteped to it and had no error since. > > > I just tried 2.4.0 and still get filesystem corruption. My system is > also SMP and SW Raid5. So far I have tried 2.4.0, 2.4.1-pre3,8 and > 2.4.0-ac10 and all corrupt my filesystem. 2.2.18 is ok. > > With the help of Manfred Spraul I can now reproduce this problem > within 10 minutes. > > Holger > > - > 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/ > -- -- -- John E. Jasen ([EMAIL PROTECTED]) -- In theory, theory and practise are the same. In practise, they aren't. - 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: [preview] Latest AMD & VIA IDE drivers with UDMA100 support
On Thu, 20 Jan 2011 09:51:03 -0800 (PST), you wrote: >On Sat, 20 Jan 2001, Alan Chandler wrote: > >> I'm running with an Abit K7 (uses via82c686a in southbridge) with IBM >> deskstar 8.4gb disks (DHEA-38451) as masters in ide0 and 1. They only >> do UDMA mode 2. I am not overclocking or anything - all should be >> running at default speeds with an Athlon 900. >> >> Just to be clear - I am NOT getting any errors when I switch back to >> the 2.2.17 kernel (debian standard) - with a 2.4.0 kernel they occur >> every few minutes when there is significant disk activity. > >But that kernel uses the stock driver that was the original second >generation correct? > >Andre Hedrick >Linux ATA Development > Sorry, I realise now what I said was ambiguous. To be clear 2.2.17 - absolutely standard as shipped in debian - no errors 2.4.0 - standard (downloaded tar.bz2) - ERRORS 2.4.0 - as standard except for three files in tar.bz2 attachment to Vojtech Pavlik's mail which were placed in drivers/ide directory - ERRORS. Alan [EMAIL PROTECTED] http://www.chandler.u-net.com - 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: Serious file system corruption with RAID5+SMP and kernels above2.4.0
On Sat, 20 Jan 2001, Otto Meier wrote: > Two days ago I tried new kernels on my SMP SW RAID5 System > and expirienced serous file system corruption with kernels 2.4.1-pre8,9 as >2.4.0-ac8,9,10. > The same error has been reported by other people on this list. With 2.4.0 release > everything runs fine. So I backsteped to it and had no error since. > I just tried 2.4.0 and still get filesystem corruption. My system is also SMP and SW Raid5. So far I have tried 2.4.0, 2.4.1-pre3,8 and 2.4.0-ac10 and all corrupt my filesystem. 2.2.18 is ok. With the help of Manfred Spraul I can now reproduce this problem within 10 minutes. Holger - 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: Documenting stat(2)
On Thu, 18 Jan 2001, Mike Castle wrote: > On Thu, Jan 18, 2001 at 09:52:02PM +0100, Igmar Palsenberg wrote: > > I use lstat to check if a config file is a symlink, and if it is, it > > refuses to open it. > > Nice race condition. Agree, but still better then opening things that are actually a symlink. Now would someone probably say : use the O_NOWFOLLOW option, but since I do other checks that wouldn't be an option. > mrc Igmar - 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 Sat, Jan 20, 2001 at 08:28:04PM +0300, [EMAIL PROTECTED] wrote: > Hello! > > > My argument applies to 2.4. The uncork _won't_ push on the wire the last > > not mss-sized fragment until it's the last one in the write queue even once > > cwnd and receiver window allows that. I think > > Look at the code again. You misread it. This is possible indeed, but in a few minutes re-read I still understand the same thing as yesterday: if there's only 1 packet in the write queue pointed by the send_head the nonagle will remains zero and the tcp_nagle_check will get nonagle zero as well and it will compute the nagle default algorithm, this last packet will be delayed normally in function of the nagle algortith. I can think of a: CORK write(1) UNCORK and the 1 byte of payload will stay there until there will be nothing in flight and all previously sent data will be acknowledged from the receiver. It seems even more clear that we can delay the push in the wire of the last packet with the uncorking if the receiver window or the congestion window forbid us to xmit such packet immediatly in the uncork call. I admit I didn't looked at all into the tcp_minshall_check due lack of time (that in turn means I don't know the semantics of snd_sml), maybe it makes the difference but then I don't see how. The rest seems quite obvious, packets_out indicates that we sent packets and that those packets aren't acknowledged yet. I would have written a testcase to try in practice what happens but I'm busy, I apologise for bothering if I'm totally wrong. However if you have the time you would make me a favour if you could tell _where_ my understanding of the code is wrong and what exactly I'm missing. Thx! Andrea - 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: lvm-oops in 2.4.1pre8
On Sat, Jan 20, 2001 at 06:41:06PM +0100, [EMAIL PROTECTED] wrote: > hi, > > got this oops when doing a > vgextend -v vgroot /dev/ide/host2/bus0/target0/lun0/part2 \ > /dev/ide/host2/bus1/target0/lun0/part2 You should upgrade to 0.9.1_beta2 that should merge all the known fixes out there. It's planned for inclusion into 2.4.1. Andrea - 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)]]
Hello! > is there really > much value in the second request flowing to the server before the first > byte of the reply has hit? Yes, of course, it has lots of sense: f.e. all the icons, referenced parent page are batched to single well-coalesced stream without rtt delays between them. It is the only sense of pipelining yet. Otherwise, you get http/1.0 with keepalives. Alexey - 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)]]
[EMAIL PROTECTED] wrote: > > > > The manpage disagrees with you: > > Do you jest? > > This manpages is wrong, or, to be more exact, is incomplete, > which is common flaw of them. > > get/set mean nothing but read-only/changing, i.e. > another important property missing in ioctl interface. setsockopt i.e. set socket options I think that Andrea's point is that SIOCPUSH don't set anything (i.e. don't change a state), but ask for an action to be done now. For this reason the name setsockopt is counter intuitive (apart from man page) and it seems to violate the principle of least surprise. I think this point of view is easily agreeable. -- Abramo Bagnara mailto:[EMAIL PROTECTED] Opera Unica Phone: +39.546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy ALSA project ishttp://www.alsa-project.org sponsored by SuSE Linuxhttp://www.suse.com It sounds good! - 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: Inefficient PCI DMA usage (was: [experimental patch] UHCI updates)
On Sat, Jan 20, 2001, Manfred Spraul <[EMAIL PROTECTED]> wrote: > > > > TD's are around 32 bytes big (actually, they may be 48 or even 64 now, I > > haven't checked recently). That's a waste of space for an entire page. > > > > However, having every driver implement it's own slab cache seems a > > complete waste of time when we already have the code to do so in > > mm/slab.c. It would be nice if we could extend the generic slab code to > > understand the PCI DMA API for us. > > > I missed the beginning of the thread: > > What are the exact requirements for TD's? > I have 3 tiny updates for mm/slab.c that I'll send to Linus as soon as > 2.4 has stabilized a bit more, perhaps I can integrate the code for USB. They need to be visible via DMA. They need to be 16 byte aligned. We also have QH's which have similar requirements, but we don't use as many of them. JE - 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: Inefficient PCI DMA usage (was: [experimental patch] UHCI updates)
> > TD's are around 32 bytes big (actually, they may be 48 or even 64 now, I > haven't checked recently). That's a waste of space for an entire page. > > However, having every driver implement it's own slab cache seems a > complete waste of time when we already have the code to do so in > mm/slab.c. It would be nice if we could extend the generic slab code to > understand the PCI DMA API for us. > I missed the beginning of the thread: What are the exact requirements for TD's? I have 3 tiny updates for mm/slab.c that I'll send to Linus as soon as 2.4 has stabilized a bit more, perhaps I can integrate the code for USB. -- Manfred - 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: [RFC] generic IO write clustering
On Sat, 20 Jan 2001, Christoph Hellwig wrote: > On Sat, Jan 20, 2001 at 01:24:40PM -0200, Marcelo Tosatti wrote: > > In case the metadata was not already cached before ->cluster() (in this > > case there is no disk IO at all), ->cluster() will cache it avoiding > > further disk accesses by writepage (or writepages()). > > True. But you have to go through ext2_get_branch (under the big kernel > lock) - if we can do only one logical->physical block translations, > why doing it multiple times? You dont. If the metadata is cached and uptodate there is no need to call get_block(). - 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/
