Re: 2.4.6-pre2, pre3 VM Behavior
On Thu, 14 Jun 2001, Roger Larsson wrote: > On Thursday 14 June 2001 10:47, Daniel Phillips wrote: > > On Thursday 14 June 2001 05:16, Rik van Riel wrote: > > > On Wed, 13 Jun 2001, Tom Sightler wrote: > > > > Quoting Rik van Riel <[EMAIL PROTECTED]>: > > > > > After the initial burst, the system should stabilise, > > > > > starting the writeout of pages before we run low on > > > > > memory. How to handle the initial burst is something > > > > > I haven't figured out yet ... ;) > > > > > > > > Well, at least I know that this is expected with the VM, although I do > > > > still think this is bad behavior. If my disk is idle why would I wait > > > > until I have greater than 100MB of data to write before I finally > > > > start actually moving some data to disk? > > > > > > The file _could_ be a temporary file, which gets removed > > > before we'd get around to writing it to disk. Sure, the > > > chances of this happening with a single file are close to > > > zero, but having 100MB from 200 different temp files on a > > > shell server isn't unreasonable to expect. > > > > This still doesn't make sense if the disk bandwidth isn't being used. > > > > It does if you are running on a laptop. Then you do not want the pages > go out all the time. Disk has gone too sleep, needs to start to write a few > pages, stays idle for a while, goes to sleep, a few more pages, ... True, you'd never want data trickling to disk on a laptop on battery. If you have to write, you'd want to write everything dirty at once to extend the period between disk powerups to the max. With file IO, there is a high probability that the disk is running while you are generating files temp or not (because you generally do read/write, not /write), so that doesn't negate the argument. Delayed write is definitely nice for temp files or whatever.. until your dirty data no longer comfortably fits in ram. At that point, the write delay just became lost time and wasted disk bandwidth whether it's a laptop or not. The problem is how do you know the dirty data is going to become too large for comfort? One thing which seems to me likely to improve behavior is to have two goals. One is the trigger point for starting flushing, the second is a goal below the start point so we define a quantity which needs to be flushed to prevent us from having to flush again so soon. Stopping as soon as the flush trigger is reached means that we'll reach that limit instantly if the box is doing any writing.. bad news for the laptop and not beneficial to desktop or server boxen. Another benefit of having two goals is that it's easy to see if you're making progress or losing ground so you can modify behavior accordingly. Rik mentioned that the system definitely needs to be optimized for read, and just thinking about it without posessing much OS theory, that rings of golden truth. Now, what does having much dirt lying around do to asynchronous readahead?.. it turn it synchronous prematurely and negates the read optimization. -Mike (That's why I mentioned having tried a clean shortage, to ensure more headroom for readahead to keep it asynchronous longer. Not working the disk hard 'enough' [define that;] must harm performance by turning both read _and_ write into strictly synchronous operations prematurely) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Chinese friend
Hallo: My name is Ma Hong Wei,I'm glad to meet you.Do you like antigues with oriental style? From no on,I believe ,we'll become friends. I like antigues very much and loun a small antigue shop selling porcelain and pottery wares, jade articles,fossils,calligrapiy and paintings and some bronze, brass or copper wares,My shop is in Xin Zheng of Henan Province,the middle part of China,It was an ancient capital of 3000 years ago with a long cultural heritage Its old city walls have been reserved to this day. Welcome to Xin Zheng, What do you like to collect? please tall me in lotters,My addreos. Ma Hong Wei 25 Dong Cheng Road, Xin Zheng, Henan,China, Tel:0086-371-2698337 - CDmail by ClanSofthttp://clansoft.yeah.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Buddy System bitmaps
well... I doubt whether buddy allocator would take u to a situation where pages 0 and 2 are used and 1 and 3 are free... try reading __get_free_pages in mm/page_alloc.c [EMAIL PROTECTED] on 06/15/2001 12:39:20 AM To: [EMAIL PROTECTED] cc:(bcc: Amol Lad/HSS) Subject: Buddy System bitmaps Hi, For this scenario consider a set of 4 page frames. Frames 0 and 2 are used while frames 1 and 3 are free. The question is would the bitmap for order 1 be a 1 or 0 for this scenario. I am not on the list so please cc me on your response. Thanks in advance. Ramil J.Santamaria Toshiba America Information Systems (949) 461-4379 (949) 206-3439 - fax [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[OT] Re: 3com Driver and the 3XP Processor
Insteresting that this thread fell into this. I just had one of those cards that came across my desk phreak out. It was 2 days old and placed in a win2k server. Last night it started dumping errors about firmware and bad microcde. Have yet to test it out on another machine, but I beleive the card went bad. first 3com I have had go bad and first card I have ever had go bad inside of 2 days :) > I've installed several thousand 3com cards of variousages and types. > I've had less than 20 bad cards. > Nick Brent Norris Executive Advisor -- WKU-Linux - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
This seems to be drifting into that old argument(s) of a forked kernel.. And of course here I am adding to the flotsams..and threadsomes 2.5 for Pentium Plus generation. <2.4 For older hardware.. Ducking the inevitable flames, I think for the most part, there might be justification for some forking.. (read obsolesence) Anyone with a <486 probably shudders at the space and time requirements of compiling modern kernels.. All they need is the older kernels.. The older boxes don't support the new hardware anyways.. But then there is always someone who will find a way to marry a new PCI or USB bus to an older CPU, and it is nice that 'one kernel to bind them' philosophy of linux.. But in this age of 'disposability' more and more people just accept they have to buy new hardware every 3-5 years.. For those that want to maintain Linux on that, so be it.. Maybe we need more Alan Cox's, and then we could have sperate kernel trees, Linus's which is the mother.. (HI MOM!) and the pre-pentium tree, the post-pentium tree, the embedded tree etc.. But in reality, with all the people contributing now to one tree, there is still more work to be done.. Who wants to split those resources? But it is a legitimate argument... In reality, hardware needs drive kernel upgrades.. and of course some security issues.. Those who have older hardware aren't interested in upgrading the kernel, why should they.. it is rock solid as it is.. And newer machines don't need support for the older hardware.. If you want to stay bleading edge kernel wise, usually you stay bleeding edge hardware wise.. But it is nice the we now can apply the power of iptables to older 486 firewalls.. BUT as much as it might be cleaner, and a little less headaches to drop all the fluff that doesn't usually get used, is it worth dropping it when all newer hardware doesn't care about a little bloat.. *cough* I can't believe I just supported bloat.. Okay, me personally, I wouldn't mind seeing tiny litle kernels and tiny little code trees, makes me feel more effecient, and I don't get blurry eyes from grepping so much code.. (Personally sometimes I think all this new power is wasted in PC's is wasted, but I have to admit.. these 10 second compiles vs the old 28 hour ones are nice) On 14 Jun 2001 02:13:29 +0100, Claudio Martins wrote: > On Thursday 14 June 2001 01:44, Daniel wrote: > > > -- If someone really needs support for this junk, they will always have the > > option of using the 2.0.x, 2.2.x or 2.4.x series. > > > > You mean you want 2.5+ series to just stop supporting all older hardware? -- "Catch the Magic of Linux..." Michael Peddemors - Senior Consultant LinuxAdministration - Internet Services NetworkServices - Programming - Security WizardInternet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604)589-0037 Beautiful British Columbia, Canada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Intel PRO/16 sudden latency problems
I'm using an old Inel EtherExpress Pro/10 ISA (i82595-based) to connect my testbox (AMD K6-3 400, VIA MVP3 chipset, running Debian woody with kernel 2.4.5) to my home LAN, which connects to the net through 608/128 kbit ADSL. The problem I'm seeing is after long periods of sustained activity, the eepro driver seems to go wonky -- sites that I can usually get the full 62KB/s download rates from, suddenly drop to below modem speed, and when I ping my default gateway (my Duron 800 running FreeBSD 4.3-STABLE), I get ping times of around 1s each, with relative little deviance. Resetting the card using "ifdown eth0" then "ifup eth0" fixes things, at least temporarily. I've also noticed that if I give the driver the IRQ and port address as parameters, sometimes the driver will detect the card multiple times (I've seen as many as 8 device entries in some cases); if I autodetect the parameters, it detects the card just once, which is correct for my setup. Either way, the driver seems to lose its mind after a few minues of downloads. For what it's worth, the card works fine in every other OS I've tested (Windows 2000 Pro, FreeBSD 4.3-STABLE, DOS with Intel's packet driver). -lee - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Client receives TCP packets but does not ACK
A couple people have requested a test case. The problem first showed up in a very large java app. Since then I wrote a small perl program to duplicate the behavior of the large app by sending the same data, in the same order, in the same sized blocks, from the server to the client. If you want to test this on your configuration then download the following two files: http://www.kleemann.org/crap/clientserver http://www.kleemann.org/crap/log1e1.txt Place a copy of the files in the same directory on both the client and the server and run the program the following way: [server]$ ./clientserver -s log1e1.txt listening on port 20001 [client]$ ./clientserver -c serverhostname log1e1.txt The server will attempt to send the data to the client which then verifies each byte received. My client generally stops ack-ing between messages 15 and 25. Robert. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SMP spin-locks
I thought that when you compiled a kernel as UP it replaced the spin-lock macros with versions that are blank. As a result a UP kernel spends no time doing spinlocks at all. that's why a SMP kernel on a UP box is slightly slower, there is more code to be executed David Lang On Thu, 14 Jun 2001, Richard B. Johnson wrote: > Date: Thu, 14 Jun 2001 23:21:35 -0400 (EDT) > From: Richard B. Johnson <[EMAIL PROTECTED]> > To: Roger Larsson <[EMAIL PROTECTED]> > Cc: Linux kernel <[EMAIL PROTECTED]> > Subject: Re: SMP spin-locks > > On Thu, 14 Jun 2001, Roger Larsson wrote: > > > On Thursday 14 June 2001 23:05, you wrote: > > > On Thu, 14 Jun 2001, Roger Larsson wrote: > > > > Hi, > > > > > > > > Wait a minute... > > > > > > > > Spinlocks on a embedded system? Is it _really_ SMP? > > > > > > The embedded system is not SMP. However, there is definite > > > advantage to using an unmodified kernel that may/may-not > > > have been compiled for SMP. Of course spin-locks are used > > > to prevent interrupts from screwing up buffer pointers, etc. > > > > > > > Not really - it prevents another processor entering the same code > > segment (spin_lock_irqsave prevents both another processor and > > local interrupts). > > > > An interrupt on UP can not wait on a spin lock - it will never be released > > since no other code than the interrupt spinning will be able to execute) > > An interrupt on a UP system will never spin, nor will the IP from > another CPU because there isn't another CPU. A spin-lock, compiled > for UP is: > > pushf > poplsome_register, currently EBX > cli ; Clear the interrupts on the only CPU you have > > do_some_code_that_must_not_be_interrupted(); > > pushl same_register_as_above > popf; Restore interrupts if they were enabled > > > For SMP is: > > pushf > poplsome_register > cli ; Clear interrupts > modify_a_memory_variable > x:see_if_it_is_what_you_expect > if_not_loop_to x > > do_some_code_that_must_not_be_interrupted(); > > modify_the_memory_variable_back > pushl same_register_as_above > popf > > > Since `cli` will only stop interrupts on the CPU that actually > fetches the instruction, another CPU can enter the code unless > it is forced to spin until the lock is released. > > If this code is executed on a UP machine, the memory variable > will always become exactly as expected so it will never spin. > Therefore SMP code should be perfectly safe on a UP machine, > in fact must be perfectly safe, or it's broken. > > The current spinlock code does work perfectly on a UP machine. > However, the large difference in performance shows that something > is quite less than optimum in the coding. > > Spinlocks are machine dependent. A simple increment of a byte > memory variable, spinning if it's not 1 will do fine. Decrementing > this variable will release the lock. A `lock` prefix is not necessary > because all Intel byte operations are atomic anyway. This assumes > that the lock was initialized to 0. It doesn't have to be. It > could be initialized to 0xaa (anything) and spin if it's not > 0xab (or anything + 1). > > > > > > SMP compiled kernel, but running on UP hardware - right? > > Then this _should not_ happen! > > > > see linux/Documentation/spinlocks.txt > > > > This, in fact, will happen. Machines booted from the network should > have SMP code so a SMP machine can use all its CPUs. This same > code, booted from the network, should have no measurable performance > penalty in UP machines. > > Also, when you develop drivers on a workstation, test them on > a workstation, then upload everything to an embedded system, you > had better be executing the same code, kernel, drivers, et all, > or you are in a world of hurt. Many embedded systems don't have > any 'standard I/O' so you can't prove that it meets its specs > (exception handling, etc) on the target. You have to test that > logic elsewhere. > > This workstation has two CPUs. All drivers are modules. It uses > initrd to install the ones for my SCSI disks, network, etc. > > Script started on Thu Jun 14 23:13:10 2001 > lsmod > Module Size Used by > ramdisk 4448 0 > loop8212 0 (autoclean) > ipx19248 0 (unused) > 3c59x 25020 1 (autoclean) > nls_cp437 4408 4 (autoclean) > BusLogic 38320 6 > sd_mod 10932 6 > scsi_mod 59460 2 [BusLogic sd_mod] > # exit > exit > > Script done on Thu Jun 14 23:13:45 2001 > > The same kernel, uploaded to an embedded system, also uses > initrd to load the machine-specific drivers. In this way, only > the drivers that are actually used, are loaded. The kernel remains > small. There is a slight performance penality for using modules, > but none other. > > # telnet platinum > Trying 10.106.100.166... > Connected to platinum.analogic.com. >
Re: how to patch driver into kernel
Em Fri, Jun 15, 2001 at 11:09:13AM +0800, [EMAIL PROTECTED] escreveu: > hi: > I write a serial driver for linux , and have a personal test . I went > to patch this driver into kernel > but I don't know how to contact serial.c author .. > can any one help me ? Look at MAINTAINERS in your kernel source tree, after a quick look I got: 8250/16?50 (AND CLONE UARTS) SERIAL DRIVER P: Theodore Ts'o M: [EMAIL PROTECTED] L: [EMAIL PROTECTED] W: http://serial.sourceforge.net S: Maintained But you can also send the patch here if its small, for peer review. - Arnaldo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SMP spin-locks
On Thu, 14 Jun 2001, Roger Larsson wrote: > On Thursday 14 June 2001 23:05, you wrote: > > On Thu, 14 Jun 2001, Roger Larsson wrote: > > > Hi, > > > > > > Wait a minute... > > > > > > Spinlocks on a embedded system? Is it _really_ SMP? > > > > The embedded system is not SMP. However, there is definite > > advantage to using an unmodified kernel that may/may-not > > have been compiled for SMP. Of course spin-locks are used > > to prevent interrupts from screwing up buffer pointers, etc. > > > > Not really - it prevents another processor entering the same code > segment (spin_lock_irqsave prevents both another processor and > local interrupts). > > An interrupt on UP can not wait on a spin lock - it will never be released > since no other code than the interrupt spinning will be able to execute) An interrupt on a UP system will never spin, nor will the IP from another CPU because there isn't another CPU. A spin-lock, compiled for UP is: pushf poplsome_register, currently EBX cli ; Clear the interrupts on the only CPU you have do_some_code_that_must_not_be_interrupted(); pushl same_register_as_above popf; Restore interrupts if they were enabled For SMP is: pushf poplsome_register cli ; Clear interrupts modify_a_memory_variable x: see_if_it_is_what_you_expect if_not_loop_to x do_some_code_that_must_not_be_interrupted(); modify_the_memory_variable_back pushl same_register_as_above popf Since `cli` will only stop interrupts on the CPU that actually fetches the instruction, another CPU can enter the code unless it is forced to spin until the lock is released. If this code is executed on a UP machine, the memory variable will always become exactly as expected so it will never spin. Therefore SMP code should be perfectly safe on a UP machine, in fact must be perfectly safe, or it's broken. The current spinlock code does work perfectly on a UP machine. However, the large difference in performance shows that something is quite less than optimum in the coding. Spinlocks are machine dependent. A simple increment of a byte memory variable, spinning if it's not 1 will do fine. Decrementing this variable will release the lock. A `lock` prefix is not necessary because all Intel byte operations are atomic anyway. This assumes that the lock was initialized to 0. It doesn't have to be. It could be initialized to 0xaa (anything) and spin if it's not 0xab (or anything + 1). > > SMP compiled kernel, but running on UP hardware - right? > Then this _should not_ happen! > > see linux/Documentation/spinlocks.txt > This, in fact, will happen. Machines booted from the network should have SMP code so a SMP machine can use all its CPUs. This same code, booted from the network, should have no measurable performance penalty in UP machines. Also, when you develop drivers on a workstation, test them on a workstation, then upload everything to an embedded system, you had better be executing the same code, kernel, drivers, et all, or you are in a world of hurt. Many embedded systems don't have any 'standard I/O' so you can't prove that it meets its specs (exception handling, etc) on the target. You have to test that logic elsewhere. This workstation has two CPUs. All drivers are modules. It uses initrd to install the ones for my SCSI disks, network, etc. Script started on Thu Jun 14 23:13:10 2001 lsmod Module Size Used by ramdisk 4448 0 loop8212 0 (autoclean) ipx19248 0 (unused) 3c59x 25020 1 (autoclean) nls_cp437 4408 4 (autoclean) BusLogic 38320 6 sd_mod 10932 6 scsi_mod 59460 2 [BusLogic sd_mod] # exit exit Script done on Thu Jun 14 23:13:45 2001 The same kernel, uploaded to an embedded system, also uses initrd to load the machine-specific drivers. In this way, only the drivers that are actually used, are loaded. The kernel remains small. There is a slight performance penality for using modules, but none other. # telnet platinum Trying 10.106.100.166... Connected to platinum.analogic.com. Escape character is '^]'. Enter "help" for commands PLATINUM> sho modules pcilynx13468 1 raw1394 7984 1 ieee1394 22984 0 [pcilynx raw1394] rtc_drvr2372 0 vxibus 10660 6 gpib_drvr 19200 2 ramdisk 4428 0 pcnet32se 15640 1 PLATINUM> exit Exit Connection closed by foreign host. # exit exit Cheers, Dick Johnson Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - To
Re: Linux 2.4.5-ac14
Am Freitag, 15. Juni 2001 04:30 schrieb John Cavan: > Dieter Nützel wrote: > > Hello Alan, > > > > I see 4.29 GB under shm with your latest try. > > something wrong? > > total:used:free: shared: buffers: cached: > Mem: 1053483008 431419392 622063616 122880 24387584 260923392 > Swap: 3947642880 394764288 > MemTotal: 1028792 kB > MemFree:607484 kB > MemShared: 120 kB > Buffers: 23816 kB > Cached: 254808 kB > Active: 225536 kB > Inact_dirty: 53208 kB > Inact_clean: 0 kB > Inact_target: 44 kB > HighTotal: 131056 kB > HighFree: 1048 kB > LowTotal: 897736 kB > LowFree:606436 kB > SwapTotal: 385512 kB > SwapFree: 385512 kB > > I don't seem to have the problem... You are using HIGHMEM?! -Dieter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
how to patch driver into kernel
hi: I write a serial driver for linux , and have a personal test . I went to patch this driver into kernel but I don't know how to contact serial.c author .. can any one help me ? rich.liu - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3com Driver and the 3XP Processor
I've installed several thousand 3com cards of various ages and types. I've had less than 20 bad cards. Nick On Thu, 14 Jun 2001, Dr. Kelsey Hudson wrote: > On Thu, 14 Jun 2001 [EMAIL PROTECTED] wrote: > > > Erm, that is going to be a problem. Crypto benifits more from open source > > than any other market segment, and binary only drivers for linux are not > > the way to go. I guess I need to get rid of my 5-10 3cr990s and replace > > them with someone else's product? > > I would... 3Com hardware (as far as i'm concerned) is garbage > > Kelsey Hudson [EMAIL PROTECTED] > Software Engineer > Compendium Technologies, Inc (619) 725-0771 > --- > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3com Driver and the 3XP Processor
On Thu, 14 Jun 2001, Kip Macy wrote: > As I mentioned previously IP heavy is a euphemism for commodity. ...and 3Com is notoriuos for putting out commodity, cheesy hardware. Kelsey Hudson [EMAIL PROTECTED] Software Engineer Compendium Technologies, Inc (619) 725-0771 --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3com Driver and the 3XP Processor
On Thu, 14 Jun 2001 [EMAIL PROTECTED] wrote: > Erm, that is going to be a problem. Crypto benifits more from open source > than any other market segment, and binary only drivers for linux are not > the way to go. I guess I need to get rid of my 5-10 3cr990s and replace > them with someone else's product? I would... 3Com hardware (as far as i'm concerned) is garbage Kelsey Hudson [EMAIL PROTECTED] Software Engineer Compendium Technologies, Inc (619) 725-0771 --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SMP spin-locks
Kurt Garloff wrote: > > On Thu, Jun 14, 2001 at 01:26:05PM -0400, Richard B. Johnson wrote: > > Question 2: What is the purpose of the code sequence, "repz nop" > > Puts iP4 into low power mode. Umm, slightly more accurate would be to say that it makes the P4 processor wait before resuming the loop to give the lock a chance to have been released. It makes the code go from a constant busy loop to a check/wait small amount of time/check again loop. This in turns keeps your processor from trying to constantly check the lock itself which is suppossed to have benefits in terms of inter-processor bus pressure. -- Doug Ledford <[EMAIL PROTECTED]> http://people.redhat.com/dledford Please check my web site for aic7xxx updates/answers before e-mailing me about problems - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.5-ac14
Hello Alan, I see 4.29 GB under shm with your latest try. something wrong? Regards, Dieter SunWave1>cat /proc/meminfo total:used:free: shared: buffers: cached: Mem: 327802880 322592768 5210112 4294184960 8417280 253640704 Swap: 1052794880 95768576 957026304 MemTotal: 320120 kB MemFree: 5088 kB MemShared:4294966532 kB Buffers: 8220 kB Cached: 247696 kB Active: 228008 kB Inact_dirty: 24552 kB Inact_clean: 2592 kB Inact_target: 468 kB HighTotal: 0 kB HighFree:0 kB LowTotal: 320120 kB LowFree: 5088 kB SwapTotal: 1028120 kB SwapFree: 934596 kB - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.5-ac14
Dieter Nützel wrote: > > Hello Alan, > > I see 4.29 GB under shm with your latest try. > something wrong? total:used:free: shared: buffers: cached: Mem: 1053483008 431419392 622063616 122880 24387584 260923392 Swap: 3947642880 394764288 MemTotal: 1028792 kB MemFree:607484 kB MemShared: 120 kB Buffers: 23816 kB Cached: 254808 kB Active: 225536 kB Inact_dirty: 53208 kB Inact_clean: 0 kB Inact_target: 44 kB HighTotal: 131056 kB HighFree: 1048 kB LowTotal: 897736 kB LowFree:606436 kB SwapTotal: 385512 kB SwapFree: 385512 kB I don't seem to have the problem... John - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: is there a way to export a fat32 file system using nfs? - YES!
On Wednesday June 13, [EMAIL PROTECTED] wrote:
>
> I might just do that first step (find_ino) and offer it as as an
> experimental patch to the growing number of people who have asked for
> nfs exporting of FAT filesystems, and see how reliable it is in
> practice.
Following is a patch against 2.4.6-pre3 which allows FAT (msdos or
VFAT) filesystems to be exported via NFS in Linux.
It should work reasonable well for simple accesses if the server
doesn't suffer too much memory pressure.
If the server reboots, if you hold a file open for extended periods
without much activity, or if the server needs to flush inodes due to
memory pressure, you will probably loose.
I would be interested to hear of how well it goes for anyone who needs
to use it. If I get enough favourable response, I might submit it to Linus.
It is also available at:
http://www.cse.unsw.edu.au/~neilb/patches/linux/2.4.6-pre3/patch-C-fatnfs
NeilBrown
--- ./fs/fat/inode.c2001/06/13 23:07:25 1.1
+++ ./fs/fat/inode.c2001/06/15 01:29:22 1.2
@@ -154,15 +154,19 @@
void fat_delete_inode(struct inode *inode)
{
- lock_kernel();
- inode->i_size = 0;
- fat_truncate(inode);
- unlock_kernel();
+ if (!is_bad_inode(inode)) {
+ lock_kernel();
+ inode->i_size = 0;
+ fat_truncate(inode);
+ unlock_kernel();
+ }
clear_inode(inode);
}
void fat_clear_inode(struct inode *inode)
{
+ if (is_bad_inode(inode))
+ return;
lock_kernel();
spin_lock(_inode_lock);
fat_cache_inval_inode(inode);
@@ -372,6 +376,7 @@
inode->i_uid = sbi->options.fs_uid;
inode->i_gid = sbi->options.fs_gid;
inode->i_version = ++event;
+ inode->i_generation = 0;
inode->i_mode = (S_IRWXUGO & ~sbi->options.fs_umask) | S_IFDIR;
inode->i_op = sbi->dir_ops;
inode->i_fop = _dir_operations;
@@ -403,12 +408,123 @@
inode->i_nlink = fat_subdirs(inode)+2;
}
+/*
+ * a FAT file handle with fhtype 3 is
+ * 0/ i_ino - for fast, reliable lookup if still in the cache
+ * 1/ i_generation - to see if i_ino is still valid
+ * bit 0 == 0 iff directory
+ * 2/ i_location - if ino has changed, but still in cache
+ * 3/ i_logstart - to semi-verify inode found at i_location
+ * 4/ parent->i_logstart - maybe used to hunt for the file on disc
+ *
+ */
+struct dentry *fat_fh_to_dentry(struct super_block *sb, __u32 *fh,
+ int len, int fhtype, int parent)
+{
+ struct inode *inode = NULL;
+ struct list_head *lp;
+ struct dentry *result;
+
+ if (fhtype != 3)
+ return NULL;
+ if (len < 5)
+ return NULL;
+ if (parent)
+ return NULL; /* We cannot find the parent,
+ It better just *be* there */
+
+ inode = iget(sb, fh[0]);
+ if (!inode || is_bad_inode(inode) ||
+ inode->i_generation != fh[1]) {
+ if (inode) iput(inode);
+ inode = NULL;
+ }
+ if (!inode) {
+ /* try 2 - see if i_location is in F-d-c
+* require i_logstart to be the same
+* Will fail if you truncate and then re-write
+*/
+
+ inode = fat_iget(sb, fh[2]);
+ if (inode && MSDOS_I(inode)->i_logstart != fh[3]) {
+ iput(inode);
+ inode = NULL;
+ }
+ }
+ if (!inode) {
+ /* For now, do nothing
+* What we could do is:
+* follow the file starting at fh[4], and record
+* the ".." entry, and the name of the fh[2] entry.
+* The follow the ".." file finding the next step up.
+* This way we build a path to the root of
+* the tree. If this works, we lookup the path and so
+* get this inode into the cache.
+* Finally try the fat_iget lookup again
+* If that fails, then weare totally out of luck
+* But all that is for another day
+*/
+ }
+ if (!inode)
+ return ERR_PTR(-ESTALE);
+
+
+ /* now to find a dentry.
+* If possible, get a well-connected one
+*
+* Given the way that we found the inode, it *MUST* be
+* well-connected, but it is easiest to just copy the
+* code.
+*/
+ spin_lock(_lock);
+ for (lp = inode->i_dentry.next; lp != >i_dentry ; lp=lp->next) {
+ result = list_entry(lp,struct dentry, d_alias);
+ if (! (result->d_flags & DCACHE_NFSD_DISCONNECTED)) {
+ dget_locked(result);
+ result->d_vfs_flags |= DCACHE_REFERENCED;
+ spin_unlock(_lock);
+ iput(inode);
+
Re: [BUG] 2.2.19 -> 80% Packet Loss
Odds are it's a raw socket receive buffer issue. Stock pings only ask for a ~96k socket buffer, which means that they can only hold one ~64k packet at a time. So, if you're ever slow grabbing packets out of the buffer, you're going to drop traffic. You can fix this by upping the socket buffer that ping asks for (look for setsockopt( ... SO_RCVBUF ...)) and then tuning the kernel to allow larger socket buffers. The file to fiddle with is /proc/sys/net/core/rmem_max. That doesn't really answer why you'd want to fling that many 64k-ish ping packets around, though. Scott On Thu, 14 Jun 2001 [EMAIL PROTECTED] wrote: > > 1. When pinging a machine using kernel 2.2.19 I consistently get an 80% > packet loss when doing a ping -f with a packet size of 64590 or higher. > > > 2. A "ping -f -s 64589" to a machine running kernel 2.2.19 results in 0% > packet loss. By incrementing the packetsize by one "ping -f -s 64590" or > higher, I consistently see 80% packet loss. ifconfig on the receiving > machine shows no anomolies. > > > 3. 2.2.19, ping, flood, 64589, 64590, 80%, packet, loss > > > 4. Linux version 2.2.19-7.0.1 ([EMAIL PROTECTED]) (gcc version > egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 Tue Apr 10 00:55:03 > EDT 2001 > > > 5. There was no oops associated with this. > > > 6. >>EOF > /bin/ping -f -s 64589 > /bin/ping -f -s 64590 > EOF > > > 7.1 /usr/src/linux-2.2.19/scripts/ver_linux > Linux orchid 2.2.19-7.0.1 #1 Tue Apr 10 00:55:03 EDT 2001 i686 unknown > > Gnu C 2.96 > Gnu make 3.79.1 > binutils 2.10.0.18 > util-linux 2.10r > modutils 2.3.21 > e2fsprogs 1.18 > Linux C Library> libc.2.2 > Dynamic linker (ldd) 2.2 > Procps 2.0.7 > Net-tools 1.56 > Console-tools 0.3.3 > Sh-utils 2.0 > Modules Loaded autofs nfsd lockd sunrpc 3c59x agpgart usb-uhci > usbcore > > > 7.2 cat /proc/cpuinfo > processor : 0 > vendor_id : GenuineIntel > cpu family: 6 > model : 8 > model name: Pentium III (Coppermine) > stepping : 3 > cpu MHz : 751.725 > cache size: 256 KB > fdiv_bug : no > hlt_bug : no > sep_bug : no > f00f_bug : no > coma_bug : no > fpu : yes > fpu_exception : yes > cpuid level : 2 > wp: yes > flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov > pat pse36 mmx fxsr xmm > bogomips : 1500.77 > > > 7.3 cat /proc/modules > autofs 9424 3 (autoclean) > nfsd 182752 8 (autoclean) > lockd 45264 1 (autoclean) [nfsd] > sunrpc 61808 1 (autoclean) [nfsd lockd] > 3c59x 21584 1 (autoclean) > agpgart18960 0 (unused) > usb-uhci 18736 0 (unused) > usbcore43120 1 [usb-uhci] > > > 7.4 No SCSI devices > > > 7.5 /sbin/ifconfig (after sending it several pings with 80% packet loss) > > eth0 Link encap:Ethernet HWaddr 00:60:97:D7:60:E4 > inet addr:10.0.0.102 Bcast:10.0.0.255 Mask:255.255.255.0 > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:3972983 errors:0 dropped:0 overruns:0 frame:0 > TX packets:5466442 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:100 > Interrupt:12 Base address:0xa800 > > loLink encap:Local Loopback > inet addr:127.0.0.1 Mask:255.0.0.0 > UP LOOPBACK RUNNING MTU:3924 Metric:1 > RX packets:210 errors:0 dropped:0 overruns:0 frame:0 > TX packets:210 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > > > X. This has only been tested/observed on a 10Mb as well as a newer 100Mb > LAN. This has also been observed on machines running kernel 2.2.17. Non > Linux machines (NT and Win98) were tested in the same manner and do not > show the same symptoms. I reviewed the LKML archives, grep'd in the > sources and did a string on the kernel binary and was not able to find any > useful reference to 64590, 64589 or ping losses due to packet size. > > -- > Chuck Wolber > System Administrator > AltaServ Corporation > (425)576-1202 > ten.vresatla@wkcuhc > > Quidquid latine dictum sit, altum viditur. > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: questions about link-level loopback, PF_PACKET and ETH_P_LOOP
Christopher Friesen wrote: > > I'm attempting to write a piece of code that will validate the physical ethernet > link from a NIC to the nearest router/hub/switch. What I'd like to do is to > send out an ethernet packet addressed to me, bounce it off the > hub/switch/router, and then read it back in. This is all at the ethernet layer. > No properly configured ethernet hub or router will return you the same packet you sent. You can get some of this information out of the drivers though, as their hardware knows the link state, at least the physical layer. Check out Becker's mii-diag program. There are some options in it to dump out all kinds of neat information about the drivers and link condition. > The nitty-gritty on this is that I have a machine that has two NICs but only one > IP address. I want to do some kind of packet loopback at the ethernet layer to > verify that my NIC transceiver is working properly. Ping your switch. Or use something like ethernet channel bonding. If both ports are up, then you should be able to send a pkt from one NIC with your other NICs MAC in it, and the switch should deliver that pkt to your other NIC. However, if you don't receive the packet, you cannot determine which one of your links/NICs is bad without going to a third party (which I suggest should be your switch itself). -- Ben Greear <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] 2.2.19 -> 80% Packet Loss
On Thursday, 14 June 2001, at 14:17:11 -0700, [EMAIL PROTECTED] wrote: > > 1. When pinging a machine using kernel 2.2.19 I consistently get an 80% > packet loss when doing a ping -f with a packet size of 64590 or higher. > What happens here is (under kernel 2.2.19): ping -f -s 49092 localhost -->> 0 % packet loss ping -f -s 49093 localhost -->> 100 % packet loss Maybe this has something to do with fragmentation of IP packets to fit in the underlying protocol's MTU (3929 in my loopback device). When pinging from the network, it is expected to get an increasing number of lost packets due to collisions in the medium. Moreover, IP fragmentation, encapsulation and reassembly can be a reason for lost packets, but is clear that what you get is quite strange :) What I have noticed is that pinging from the network with large packet sizes (for example, ping -s 55000 destinationIP), causes the ping program to sometimes dump a echo_reply packet to stdout with the following message: 55008 bytes from 192.168.1.10: icmp_seq=8 ttl=255 time=145.9 ms wrong data byte #190 should be 0xbe but was 0x3e And some other times I get ping results with interesting patterns: 55008 bytes from 192.168.1.10: icmp_seq=45 ttl=255 time=1155.6 ms 55008 bytes from 192.168.1.10: icmp_seq=46 ttl=255 time=143.3 ms 55008 bytes from 192.168.1.10: icmp_seq=47 ttl=255 time=1155.2 ms 55008 bytes from 192.168.1.10: icmp_seq=48 ttl=255 time=143.8 ms On a slower box, I get the following (kernel 2.4.4): ping -f -s 32293 localhost -->> 0 % packet loss ping -f -s 32294 localhost -->> 100 % packet loss I've no idea what this could mean. -- José Luis Domingo López Linux Registered User #189436 Debian GNU/Linux Potato (P166 64 MB RAM) jdomingo EN internautas PUNTO org => ¿ Spam ? Atente a las consecuencias jdomingo AT internautas DOT org => Spam at your own risk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: threading question (results after thread pooling)
On Thu, Jun 14, 2001 at 04:42:29PM -0600, [EMAIL PROTECTED] wrote:
> 2. The main thread sets up the data (which are global) and then signals
> that there is work to be done on the same condition variable. The first
> thread to get awaken takes the work. the remaining threads keep waiting.
For curiosities sake, at what point would this technique result in a
thundering herd issue? Does it happen near the level at which the number of
schedulable entities equal the number of processors or does it have to be
much greater than that?
mrc
--
Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/
We are all of us living in the shadow of Manhattan. -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: threading question (results after thread pooling)
> Hello, > > I have implemented thread pooling (with an environment variable > where I can give the number of threads to be created). Results: > > 1. Linux, no change in the times (not under 2.2.x or 2.4) [snip] > I am now pretty much inclined to believe that it is either a) hardware > issue (someone mentioned that SPARCs and MIPSes handle things differently) > or b) Linux for some reason just cant give me what IRIX/Solaris can in > this particular case [snip] Hello Ognen, can you get your hands on an dual AMD Athlon MP 1/1.2 GHz system? The only mobo currently on the marked is the AMD 760MP based Tyan Thunder K7. It has (all) the good stuff (Point-to-Point bus, crossbar) which former only the (big) Alphas/SUN/SGI etc. had. http://www.amd.com/products/cpg/server/athlon/index.html http://www.tyan.com/products/html/thunderk7.html Regards, Dieter -- Dieter Nützel Graduate Student, Computer Science University of Hamburg Department of Computer Science Cognitive Systems Group Vogt-Kölln-Straße 30 D-22527 Hamburg, Germany email: [EMAIL PROTECTED] @home: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linux 2.4.5-ac14
ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/ Intermediate diffs are available from http://www.bzimage.org In terms of going through the code audit almost all the sound drivers still need fixing to lock against format changes during a read/write. Poll creating and starting a buffer as write does and also mmap during write, write during an mmap. 2.4.5-ac14 o Fix oops on command abort on aha152x(me) | This so far is only a partial fix o Switch to unlazy swap cache free up (Marcelo Tosatti) o Page launder changes(Rik van Riel) o Remove dead irda irlap compression code (Dag Brattli) o Fix bug where init/main.c executes freed code (Hans-Peter Nilsson) o Fix ramfs accounting. truncate/freepage hook(Christoph Rohland) o Add MTWEOF ioctl to parallel tape (Russ Ingram) o Add driver for CATC based USB ethernet (Vojtech Pavlik) o Update cris architecture code (Bjorn Wesen) o Clean up reiserfs tail->full page convert (Chris Mason) o Clean up lp init, fix lp= option handling (Tim Waugh) o Don't panic on out of memory during ps/2 setup (Andrey Panin) o Initialise vc_cons objects in full (Richard Hirst) o Futher Configure.help resync(Eric Raymond) o Fix misdeclaration of xtime (Petr Vandrovec) o Add yet more sb variants(Andrey Panin) o Fix bogus VIA warning triggers (I hope) (me) o Fix 3c509 symbols when building nonpnp (Keith Owens) o Make pid on core dump configurable (Ben LaHaise) 2.4.5-ac13 o Fix i2o_block to use invalidate_device (me) o Fix viodasd to use invalidate_device(me) o Fix missing ipc alloc check (Manfred Spraul) o Use skb_purge_queue in isdn (Kai Germaschewski) o Fix epic100 printk error(Francois Romieu) o Resync with master Configure.help (Eric Raymond) o Avoid oops when reading swap proc during swapon (Paul Menage) o Sony pi driver update (Stelian Pop) o Sony motioneye camera driver(Stelian Pop, Andrew Tridgell) o Fix eepro100 access by user to some registers (Andrey Savochkin) o Small APM real mode reboot clean ups(Stephen Rothwell) o Fix isofs buffer leak on invalid iocharset (Tachino Nobuhiro) o Fix default encoding on pwc videocam(Mark Cooke) o Clean up FAT further, fix endian bug, and times (OGAWA Hirofumi) before 1/1/1980 o Support combo parallel/serial PCI cards (Tim Waugh) o CS46xx mmap oops fix(me) 2.4.5-ac12 o Report apic timer vector in hex too (Philip Pokorny) | With 0x in front so we can tell on reports.. o Report card services differently if kernel (Jeff Garzik) o Don't terminate init on sysrq (Adam Slattery) unless forced o Add more pci wrappers when PCI is off (Jeff Garzik) o Remove 4K object from the stack in emu10k1 (me) o Remove 3.5K object from the i2o_proc stack (me) o Remove 3K object from the ewrk3 ioctl stack (me) o Fix bugs in the es1371 locking (me) o Fix ohci iso alignments (Roman Weissgaerber) o Updated megaraid driver (Atul Mukker) | In paticular this now uses the new PCI api 2.4.5-ac11 o Fix the megaraid driver ioctl check (me) o Fix the moxa ioctl checks (me) o Fix the i810 dri length check (me) o Fix array check in se401.c (me) o Fix scc irq array problems (me) o Fix sign check on zr36120 (me) o Fix sign check in raw driver(me) o Fix zr36067 array size check(me) | All the above from the Stanford checker o Fix an irq order assumption in the i810 audio (Doug Ledford) o Make real mode poweroff configurable and also (Arjan van de Ven) add DMI entries for it o Clean up Alpha oops reporting (Will Woods) o Fix ia64 build bug from mmap change (Bill Nottingham) o Fix sysinfo padding so m68k comes out right (Jes Sorensen) o Update pci ids related to ide devices (Andre Hedrick) o Update ide registers/ioctl numbers/info (Andre Hedrick) o Fix speed detection on slc90e66
Re: threading question (results after thread pooling)
Hello, I have implemented thread pooling (with an environment variable where I can give the number of threads to be created). Results: 1. Linux, no change in the times (not under 2.2.x or 2.4) 2. SGI/Solaris/OSF/1: times decrease when the number of threads matched the number of processors available. The times were the same as my previous version or couple of percents better when I exhaggerated the number of threads to create, say, 128 threads on a 2 CPU. 3. The load on the machines has decreased considerably with the new solution. I consider this to be the only positive impact I have seen from this solution. The solution is basically designed in the following way: 1. Threads are created and they wait on a condition with pthread_cond_wait 2. The main thread sets up the data (which are global) and then signals that there is work to be done on the same condition variable. The first thread to get awaken takes the work. the remaining threads keep waiting. 3. Go to 2. until there is work to distribute I am now pretty much inclined to believe that it is either a) hardware issue (someone mentioned that SPARCs and MIPSes handle things differently) or b) Linux for some reason just cant give me what IRIX/Solaris can in this particular case Regretfully, the organization I work for prohibits me from releasing the code I am talking about until the lawyers decide what to do with it. My hope is to be able to release it for free to anyone interested since this sequence alignment tool is used a lot :). This kind of defeats the purpose of my question(s) since without the code it is difficult to talk. Best regards, Ognen Duzlevski On Thu, 14 Jun 2001, Alan Cox wrote: > > they are done. This should help it (and avoid the pthread_create, > > pthread_exit). I will implement this and report my results if there is > > interest. > > You should also check up the cache colouring. X86 boxes have relatively poor > memory performance and most x86 chips have lousy behaviour when data bounces > between processors or is driven out of cache -- Ognen Duzlevski Plant Biotechnology Institute National Research Council of Canada Bioinformatics team - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.5 data corruption
> any problems since 2.4.5 was published, they seem to have surfaced > immediately after I created a rather big file capturing video with > broadcast2000 (video card is bt848). Filesystem is ext2. Thats something I've seen reported elsehwere. The high bandwidth capture card stuff seems to show up problems. It could be drivers could be hardware. On my AMD 751 pre release board I see that problem but on the 751 production board I dont - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Going beyond 256 PCI buses
>It's funny you mention this because I have been working on something
>similar recently. Basically making xfree86 int10 and VGA poking happy
>on sparc64.
Heh, world is small ;)
>But this has no real use in the kernel. (actually I take this back,
>read below)
yup, fbcon at least...
>You have a primary VGA device, that is the one the bios (boot
>firmware, whatever you want to call it) enables to respond to I/O and
>MEM accesses, the rest are configured to VGA pallette snoop and that's
>it. The primary VGA device is the kernel console (unless using some
>fbcon driver of course), and that's that.
Yup, fbcon is what I have in mind here
>The secondary VGA devices are only interesting to things like the X
>server, and xfree86 does all the enable/disable/bridge-forward-vga
>magic when doing multi-head.
and multihead fbcon.
>Perhaps, you might need to program the VGA resources of some device to
>use it in a fbcon driver (ie. to init it or set screen crt parameters,
>I believe the tdfx requires the latter which is why I'm having a devil
>of a time getting it to work on my sparc64 box). This would be a
>seperate issue, and I would not mind at all seeing an abstraction for
>this sort of thing, let us call it:
>
> struct pci_vga_resource {
> struct resource io, mem;
> };
>
> int pci_route_vga(struct pci_dev *pdev, struct pci_vga_resource *res);
> pci_restore_vga(void);
>
> [.../...]
Well... that would work for VGA itself (note that this semaphore
you are talking about should be shared some way with the /proc
interface so XFree can be properly sync'ed as well).
But I still think it may be useful to generalize the idea to
all kind of legacy IO & PIOs. I definitely agree that VGA is a kind
of special case, mostly because of the necessary exclusion on
the VGA IO response.
But what about all those legacy drivers that will issue inx/outx
calls without an ioremap ? Should they call ioremap with hard-coded
legacy addresses ? There are chipsets containing things like legacy
timers, legacy keyboard controllers, etc... and in some (rare I admit)
cases, those may be scattered (or multiplied) on various domains.
If we decide we don't handle those, then well, I won't argue more
(it's mostly an estethic rant on my side ;), but the problem of
wether they should call ioremap or not is there, and since the
ISA bus can be "mapped" anywhere in the bus space by the host bridge,
there need to be a way to retreive the ISA resources in general for
a given domain.
That's why I'd suggest something like
pci_get_isa_mem(struct resource* isa_mem);
pci_get_isa_io(struct resource* isa_io);
(I prefer 2 different functions as some platforms like powermac just
don't provide the ISA mem space at all, there's no way to generate
a memory cycle in the low-address range on the PCI bus of those and
they don't have a PCI<->ISA bridge), so I like having the ability of
one of the functions returning an error and not the other.
Also, having the same ioremap() call for both mem IO and PIO means
that things like 0xc cannot be interpreted. It's a valid ISA-mem
address in the VGA space and a valid PIO address on a PCI bus that
supports >64k of PIO space.
I beleive it would make things clearer (and probably implementation
simpler) to separate ioremap and pioremap.
Ben.
>So you'd go:
>
> struct pci_vga_resource vga_res;
> int err;
>
> err = pci_route_vga(tdfx_pdev, _res);
>
> if (err)
> barf();
> vga_ports = ioremap(vga_res.io.start, vga_res.io.end-vga_res.io.start+1);
> program_video_crtc_params(vga_ports);
> iounmap(vga_ports);
> vga_fb = ioremap(vga_res.mem.start, vga_res.mem.end-vga_res.mem.start+1);
> clear_vga_fb(vga_fb);
> iounmap(vga_fb);
>
> pci_restore_vga();
>
>pci_route_vga does several things:
>
>1) It saves the current VGA routing information.
>2) It configures busses and VGA devices such that PDEV responds to
> VGA accesses, and other VGA devices just VGA palette snoop.
>3) Fills in the pci_vga_resources with
> io: 0x320-->0x340 in domain PDEV lives, vga I/O regs
> mem: 0xa-->0xc in domain PDEV lives, video ram
>
>pci_restore_vga, as the name suggests, restores things back to how
>they were before the pci_route_vga() call. Maybe also some semaphore
>so only one driver can do this at once and you can't drop the
>semaphore without calling pci_restore_vga(). VC switching into the X
>server would need to grab this thing too.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.6-pre2, pre3 VM Behavior
On Thu, 14 Jun 2001, John Stoffel wrote: > Rik> There's another issue. If dirty data is written out in small > Rik> bunches, that means we have to write out the dirty data more > Rik> often. > > What do you consider a small bunch? 32k? 1Mb? 1% of buffer space? > I don't see how delaying writes until the buffer is almost full really > helps us. As the buffer fills, the pressure to do writes should > increase, so that we tend, over time, to empty the buffer. > > A buffer is just that, not persistent storage. > > And in the case given, we were not seeing slow degradation, we saw > that the user ran into a wall (or inflection point in the response > time vs load graph), which was pretty sharp. We need to handle that > more gracefully. No doubt on the fact that we need to handle it gracefully, but as long as we don't have any answers to any of the tricky questions you're asking above it'll be kind of hard to come up with a patch ;)) > Rik> This in turn means extra disk seeks, which can horribly interfere > Rik> with disk reads. > > True, but are we optomizing for reads or for writes here? Shouldn't > they really be equally weighted for priority? And wouldn't the > Elevator help handle this to a degree? We definately need to optimise for reads. Every time we do a read, we KNOW there's a process waiting on the data to come in from the disk. Most of the time we do writes, they'll be asynchronous delayed IO which is done in the background. The program which wrote the data has moved on to other things long since. > Some areas to think about, at least for me. And maybe it should be > read and write pressure, not rate? > > - low write rate, and a low read rate. >- Do seeks dominate our IO latency/throughput? Seeks always dominate IO latency ;) If you have a program which needs to get data from some file on disk, it is beneficial for that program if the disk head is near the data it wants. Moving the disk head all the way to the other side of the disk once a second will not slow the program down too much, but moving the disk head away 30 times a second "because there is little disk load" might just slow the program down by a factor of 2 ... Ie. if the head is in the same track or in the track next door, we only have rotational latency to count for (say 3ms), if we're on the other side of the disk we also have to count in seek time (say 7ms). Giving the program 30 * 7 = 210 ms extra IO wait time per second just isn't good ;) > - low write rate, high read rate. > - seems like we want to keep writing the buffers, but at a lower > rate. Not at a lower rate, just in larger blocks. Disk transfer rate is so rediculously high nowadays that seek time seems the only sensible thing to optimise for. regards, Rik -- Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Going beyond 256 PCI buses
Jeff Garzik writes: > I think rth requested pci_ioremap also... It really isn't needed, and I understand why Linus didn't like the idea either. Because you can encode the bus etc. info into the resource addresses themselves. On sparc64 we just so happen to stick raw physical addresses into the resources, but that is just one way of implementing it. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3com Driver and the 3XP Processor
So it would seem. Here is the polite message I received in response my inquiry regarding the crypto interface to the card: > > > Thank you for your inquiry. We do not offer the > technical spec;s for the IPSec > features of this NIC, due to the intellectual > property-heavy nature of this > product. We will, however, be releasing a Linux > driver which supports this > feature in the very near future under the beta > section of our support site. The > base driver for the 990 will be open source, the > advanced driver (offloads, > etc.) will not be open source. Hope that somewhat > helps you. On Thu, 14 Jun 2001 [EMAIL PROTECTED] wrote: > Erm, that is going to be a problem. Crypto benifits more from open source > than any other market segment, and binary only drivers for linux are not > the way to go. I guess I need to get rid of my 5-10 3cr990s and replace > them with someone else's product? > Nick > > On Thu, 14 Jun 2001, Kip Macy wrote: > > > IPsec support will be binary only. > > As I mentioned previously IP heavy is a euphemism for commodity. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.4.6-pre3
In article <[EMAIL PROTECTED]>, Alan Cox <[EMAIL PROTECTED]> wrote: > >Use pre2. Linus applied a patch that changed the PCI power management stuff >and broke all the drivers. It shouldn't have broken anything. The warning happens, but the function call ends up doing the same thing as it used to - old drivers will just ignore the new argument. It was a necessary step in working ACPI suspend. Which Patrick has working - with caveats. And the fact that Pat happens to work at the same company I do probably has more to do with the fact that Transmeta is obviously interested in suspend issues more than most - and not so much with the fact that he would exert undue influence on me. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.6-pre2, pre3 VM Behavior
Rik> There's another issue. If dirty data is written out in small Rik> bunches, that means we have to write out the dirty data more Rik> often. What do you consider a small bunch? 32k? 1Mb? 1% of buffer space? I don't see how delaying writes until the buffer is almost full really helps us. As the buffer fills, the pressure to do writes should increase, so that we tend, over time, to empty the buffer. A buffer is just that, not persistent storage. And in the case given, we were not seeing slow degradation, we saw that the user ran into a wall (or inflection point in the response time vs load graph), which was pretty sharp. We need to handle that more gracefully. Rik> This in turn means extra disk seeks, which can horribly interfere Rik> with disk reads. True, but are we optomizing for reads or for writes here? Shouldn't they really be equally weighted for priority? And wouldn't the Elevator help handle this to a degree? Some areas to think about, at least for me. And maybe it should be read and write pressure, not rate? - low write rate, and a low read rate. - Do seeks dominate our IO latency/throughput? - low read rate, higher write rate (ie buffers filling faster than they are being written to disk) - Do we care as much about reads in this case? - If the write is just a small, high intensity burst, we don't want to go ape on writing out buffers to disk, but we do want to raise the rate we do so in the background, no? - low write rate, high read rate. - seems like we want to keep writing the buffers, but at a lower rate. Just some thoughts... John John Stoffel - Senior Unix Systems Administrator - Lucent Technologies [EMAIL PROTECTED] - http://www.lucent.com - 978-952-7548 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.4.5-ac12] New Sony Vaio Motion Eye camera driver
In article <[EMAIL PROTECTED]>, Stelian Pop <[EMAIL PROTECTED]> wrote: > >Well, not quite... I've had several X lockups while using the YUV >acceleration code. Let's say one lockup per half an hour. Strange. I've watched DVD's etc. Maybe it's not the Xv code, but your camera code? >Even the performances are controversial: with 320x240, I achieve >great performance with xawtv/meye driver, I can even use the hardware >scaling facilities (well, the xawtv sources need a little hacking for >that), but in 640x480 the framerate achieved with Xv is below the >one I get by converting YUV->RGB in software... There's something wrong with your setup. I watch full-screen DVD's on my VAIO. It's not really fast enough with just the YUV conversion done in hardware (it's plenty fast enough if MC and iDCT would be done in HW too, but ATI doesn't release docs without strict NDA's). But there's no way DVD's are watchable with sw YUV conversion and scaling. >But the main question remains: does the MotionEye camera support >overlay or not ? That one I have no clue about at all. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SMP spin-locks
On Thursday 14 June 2001 23:05, you wrote: > On Thu, 14 Jun 2001, Roger Larsson wrote: > > Hi, > > > > Wait a minute... > > > > Spinlocks on a embedded system? Is it _really_ SMP? > > The embedded system is not SMP. However, there is definite > advantage to using an unmodified kernel that may/may-not > have been compiled for SMP. Of course spin-locks are used > to prevent interrupts from screwing up buffer pointers, etc. > Not really - it prevents another processor entering the same code segment (spin_lock_irqsave prevents both another processor and local interrupts). An interrupt on UP can not wait on a spin lock - it will never be released since no other code than the interrupt spinning will be able to execute) > > What kind of performance problem do you have? > > The problem is that a data acquisition board across the PCI bus > gives a data transfer rate of 10 to 11 megabytes per second > with a UP kernel, and the transfer drops to 5-6 megabytes per > second with a SMP kernel. The ISR is really simple and copies > data, that's all. > > The 'read()' routine uses a spinlock when it modifies pointers. > > I started to look into where all the CPU clocks were going. The > SMP spinlock code is where it's going. There is often contention > for the lock because interrupts normally occur at 50 to 60 kHz. > SMP compiled kernel, but running on UP hardware - right? Then this _should not_ happen! see linux/Documentation/spinlocks.txt Is it your spinlocks that are causing this, or? > When there is contention, a very longjump occurs into > the test.lock segment. I think this is flushing queues. > It does not matter, if there is contention - let it take time. Waiting is what spinlocking is about anyway... /RogerL -- Roger Larsson Skellefteå Sweden - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3com Driver and the 3XP Processor
Erm, that is going to be a problem. Crypto benifits more from open source than any other market segment, and binary only drivers for linux are not the way to go. I guess I need to get rid of my 5-10 3cr990s and replace them with someone else's product? Nick On Thu, 14 Jun 2001, Kip Macy wrote: > IPsec support will be binary only. > > -Kip > On Thu, 14 Jun 2001 [EMAIL PROTECTED] wrote: > > > So what is the truth to the rumors 3com was throwing around about the > > "linux driver with ipsec support"? > > Nick > > > > On Thu, 14 Jun 2001, Martin Moerman wrote: > > > > > > > > > > > On Thu, 14 Jun 2001, Brent D. Norris wrote: > > > > > > > > Now, if the NIC were to integrate with OpenSSL and offload some of THAT > > > > > donkey work... Just offloading DES isn't terribly useful, as Pavel says: > > > > > apart from anything else, DES is a bit elderly now - SSH using 3DES or > > > > > Blowfish etc... How dedicated is this card? Could it be used to offload > > > > > other work? > > > > > > > > Sorry my bad it is 3DES that they have on it, but I don't know how > > > > in-grained it is in it. Like I sad it just floated across my desk a few > > > > days ago and it sounded like a cool bit of hardware. > > > > > > > > > The card is offloading TCP/IP checksums, TCP/IP packet fragmentation, and > > > does IPSEC through the ARM9 proc. > > > > > > I like the card. but no real real linux drivers yet. only basic network > > > card drivers for linux. > > > > > > /Martin > > > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > Brent Norris > > > > > > > > Executive Advisor -- WKU-Linux > > > > > > > > System Administrator -- WKU-Center for Biodiversity > > > > Best Mechanical > > > > > > > > W: 270-745-8864 > > > > H: 270-563-9226 > > > > > > > > "The problem with the Linux learning curve is that it is _so_ steep once > > > > at the top you can't see the people at the bottom" --Doug Hagan > > > > > > > > - > > > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > > > > the body of a message to [EMAIL PROTECTED] > > > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > > > Please read the FAQ at http://www.tux.org/lkml/ > > > > > > > > > > - > > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > > > the body of a message to [EMAIL PROTECTED] > > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > > Please read the FAQ at http://www.tux.org/lkml/ > > > > > > > - > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > > the body of a message to [EMAIL PROTECTED] > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > Please read the FAQ at http://www.tux.org/lkml/ > > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: IPsec support
On Thursday, 14 June 2001, at 12:30:02 -0600, [EMAIL PROTECTED] wrote: > Folks, > > I checked 2.4.x source code but did not find any code for IPsec. Does > anyone know that current or latest Linux support IPsec? Or does anyone know > who is working on this ipv6 issue? > Check FreeS/WAN (www.freeswan.org), seems to work fine for many people, and seems to interoperate with other vendors' products. PS: are there any plans for integrating widely known (and maybe stable and interesting enough) kernel patches into the mainstream kernel in the 2.6.x timeframe ?. I was thinking about things like FreeS/WAN, LIDS and so on (and maybe other interesting ones I'm unaware of :). -- José Luis Domingo López Linux Registered User #189436 Debian GNU/Linux Potato (P166 64 MB RAM) jdomingo EN internautas PUNTO org => ¿ Spam ? Atente a las consecuencias jdomingo AT internautas DOT org => Spam at your own risk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3com Driver and the 3XP Processor
IPsec support will be binary only. -Kip On Thu, 14 Jun 2001 [EMAIL PROTECTED] wrote: > So what is the truth to the rumors 3com was throwing around about the > "linux driver with ipsec support"? > Nick > > On Thu, 14 Jun 2001, Martin Moerman wrote: > > > > > > > On Thu, 14 Jun 2001, Brent D. Norris wrote: > > > > > > Now, if the NIC were to integrate with OpenSSL and offload some of THAT > > > > donkey work... Just offloading DES isn't terribly useful, as Pavel says: > > > > apart from anything else, DES is a bit elderly now - SSH using 3DES or > > > > Blowfish etc... How dedicated is this card? Could it be used to offload > > > > other work? > > > > > > Sorry my bad it is 3DES that they have on it, but I don't know how > > > in-grained it is in it. Like I sad it just floated across my desk a few > > > days ago and it sounded like a cool bit of hardware. > > > > > > The card is offloading TCP/IP checksums, TCP/IP packet fragmentation, and > > does IPSEC through the ARM9 proc. > > > > I like the card. but no real real linux drivers yet. only basic network > > card drivers for linux. > > > > /Martin > > [EMAIL PROTECTED] > > > > > > > > > > > > Brent Norris > > > > > > Executive Advisor -- WKU-Linux > > > > > > System Administrator -- WKU-Center for Biodiversity > > > Best Mechanical > > > > > > W: 270-745-8864 > > > H: 270-563-9226 > > > > > > "The problem with the Linux learning curve is that it is _so_ steep once > > > at the top you can't see the people at the bottom" --Doug Hagan > > > > > > - > > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > > > the body of a message to [EMAIL PROTECTED] > > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > > Please read the FAQ at http://www.tux.org/lkml/ > > > > > > > - > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > > the body of a message to [EMAIL PROTECTED] > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > Please read the FAQ at http://www.tux.org/lkml/ > > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3com Driver and the 3XP Processor
So what is the truth to the rumors 3com was throwing around about the "linux driver with ipsec support"? Nick On Thu, 14 Jun 2001, Martin Moerman wrote: > > > On Thu, 14 Jun 2001, Brent D. Norris wrote: > > > > Now, if the NIC were to integrate with OpenSSL and offload some of THAT > > > donkey work... Just offloading DES isn't terribly useful, as Pavel says: > > > apart from anything else, DES is a bit elderly now - SSH using 3DES or > > > Blowfish etc... How dedicated is this card? Could it be used to offload > > > other work? > > > > Sorry my bad it is 3DES that they have on it, but I don't know how > > in-grained it is in it. Like I sad it just floated across my desk a few > > days ago and it sounded like a cool bit of hardware. > > > The card is offloading TCP/IP checksums, TCP/IP packet fragmentation, and > does IPSEC through the ARM9 proc. > > I like the card. but no real real linux drivers yet. only basic network > card drivers for linux. > > /Martin > [EMAIL PROTECTED] > > > > > > > Brent Norris > > > > Executive Advisor -- WKU-Linux > > > > System Administrator -- WKU-Center for Biodiversity > > Best Mechanical > > > > W: 270-745-8864 > > H: 270-563-9226 > > > > "The problem with the Linux learning curve is that it is _so_ steep once > > at the top you can't see the people at the bottom" --Doug Hagan > > > > - > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > > the body of a message to [EMAIL PROTECTED] > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > Please read the FAQ at http://www.tux.org/lkml/ > > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[BUG] 2.2.19 -> 80% Packet Loss
1. When pinging a machine using kernel 2.2.19 I consistently get an 80% packet loss when doing a ping -f with a packet size of 64590 or higher. 2. A "ping -f -s 64589" to a machine running kernel 2.2.19 results in 0% packet loss. By incrementing the packetsize by one "ping -f -s 64590" or higher, I consistently see 80% packet loss. ifconfig on the receiving machine shows no anomolies. 3. 2.2.19, ping, flood, 64589, 64590, 80%, packet, loss 4. Linux version 2.2.19-7.0.1 ([EMAIL PROTECTED]) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 Tue Apr 10 00:55:03 EDT 2001 5. There was no oops associated with this. 6. >>EOF /bin/ping -f -s 64589 /bin/ping -f -s 64590 EOF 7.1 /usr/src/linux-2.2.19/scripts/ver_linux Linux orchid 2.2.19-7.0.1 #1 Tue Apr 10 00:55:03 EDT 2001 i686 unknown Gnu C 2.96 Gnu make 3.79.1 binutils 2.10.0.18 util-linux 2.10r modutils 2.3.21 e2fsprogs 1.18 Linux C Library> libc.2.2 Dynamic linker (ldd) 2.2 Procps 2.0.7 Net-tools 1.56 Console-tools 0.3.3 Sh-utils 2.0 Modules Loaded autofs nfsd lockd sunrpc 3c59x agpgart usb-uhci usbcore 7.2 cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 8 model name : Pentium III (Coppermine) stepping: 3 cpu MHz : 751.725 cache size : 256 KB fdiv_bug: no hlt_bug : no sep_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr xmm bogomips: 1500.77 7.3 cat /proc/modules autofs 9424 3 (autoclean) nfsd 182752 8 (autoclean) lockd 45264 1 (autoclean) [nfsd] sunrpc 61808 1 (autoclean) [nfsd lockd] 3c59x 21584 1 (autoclean) agpgart18960 0 (unused) usb-uhci 18736 0 (unused) usbcore43120 1 [usb-uhci] 7.4 No SCSI devices 7.5 /sbin/ifconfig (after sending it several pings with 80% packet loss) eth0 Link encap:Ethernet HWaddr 00:60:97:D7:60:E4 inet addr:10.0.0.102 Bcast:10.0.0.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:3972983 errors:0 dropped:0 overruns:0 frame:0 TX packets:5466442 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 Interrupt:12 Base address:0xa800 loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:3924 Metric:1 RX packets:210 errors:0 dropped:0 overruns:0 frame:0 TX packets:210 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 X. This has only been tested/observed on a 10Mb as well as a newer 100Mb LAN. This has also been observed on machines running kernel 2.2.17. Non Linux machines (NT and Win98) were tested in the same manner and do not show the same symptoms. I reviewed the LKML archives, grep'd in the sources and did a string on the kernel binary and was not able to find any useful reference to 64590, 64589 or ping losses due to packet size. -- Chuck Wolber System Administrator AltaServ Corporation (425)576-1202 ten.vresatla@wkcuhc Quidquid latine dictum sit, altum viditur. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3com Driver and the 3XP Processor
On Thu, 14 Jun 2001, Brent D. Norris wrote: > > Now, if the NIC were to integrate with OpenSSL and offload some of THAT > > donkey work... Just offloading DES isn't terribly useful, as Pavel says: > > apart from anything else, DES is a bit elderly now - SSH using 3DES or > > Blowfish etc... How dedicated is this card? Could it be used to offload > > other work? > > Sorry my bad it is 3DES that they have on it, but I don't know how > in-grained it is in it. Like I sad it just floated across my desk a few > days ago and it sounded like a cool bit of hardware. The card is offloading TCP/IP checksums, TCP/IP packet fragmentation, and does IPSEC through the ARM9 proc. I like the card. but no real real linux drivers yet. only basic network card drivers for linux. /Martin [EMAIL PROTECTED] > > Brent Norris > > Executive Advisor -- WKU-Linux > > System Administrator -- WKU-Center for Biodiversity > Best Mechanical > > W: 270-745-8864 > H: 270-563-9226 > > "The problem with the Linux learning curve is that it is _so_ steep once > at the top you can't see the people at the bottom" --Doug Hagan > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Gigabit Intel NIC? - Intel Gigabit Ethernet Pro/1000T
Riley Williams wrote: > > Hi Ion. > > >> Shawn, I'd suggest you tell the said sales guy that IF he can > >> get you the FULL specs TOGETHER WITH permission to freely > >> distribute them... > > > Permission to freely distribute the specs isn't necessary, > > although it is nice indeed. All that's needed is permission to > > GPL the driver sources written using knowledge from said specs. > > That presupposes that the person they give the specs to is the person > writing the driver. I don't remember shawn offering to write a driver > or anything approaching that. > > As I see it, if Shawn has permission to freely distribute the specs, > he can send a copy to Alan Cox for forwarding to the relevant driver > developers. However, if he has to sign an NDA to get them, they're > useless... > > Alan: Am I right in assuming this? If you can find specs, I have tested cards and help write a driver... Jeff -- Jeff Garzik | Andre the Giant has a posse. Building 1024| MandrakeSoft | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: FYI: ECN approved as Standard
On Thu, Jun 14, 2001 at 01:33:53PM +0200, Anders Peter Fugmann wrote: > Great to hear, but I cannot find anything that backs it up. > I really want to see the final RFC. > > Perhaps you could send me an URL pointing to it? Usually takes a few days until the RFC editor will announce and publish the new RFC. Ralf - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SMP spin-locks
On Thu, 14 Jun 2001, Roger Larsson wrote: > Hi, > > Wait a minute... > > Spinlocks on a embedded system? Is it _really_ SMP? > The embedded system is not SMP. However, there is definite advantage to using an unmodified kernel that may/may-not have been compiled for SMP. Of course spin-locks are used to prevent interrupts from screwing up buffer pointers, etc. > What kind of performance problem do you have? The problem is that a data acquisition board across the PCI bus gives a data transfer rate of 10 to 11 megabytes per second with a UP kernel, and the transfer drops to 5-6 megabytes per second with a SMP kernel. The ISR is really simple and copies data, that's all. The 'read()' routine uses a spinlock when it modifies pointers. I started to look into where all the CPU clocks were going. The SMP spinlock code is where it's going. There is often contention for the lock because interrupts normally occur at 50 to 60 kHz. When there is contention, a very longjump occurs into the test.lock segment. I think this is flushing queues. Cheers, Dick Johnson Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
questions about link-level loopback, PF_PACKET and ETH_P_LOOP
I'm attempting to write a piece of code that will validate the physical ethernet link from a NIC to the nearest router/hub/switch. What I'd like to do is to send out an ethernet packet addressed to me, bounce it off the hub/switch/router, and then read it back in. This is all at the ethernet layer. Needless to say, I've been having some issues. 1) Is it even possible to do something like this? I notice that tcpdump shows the packets outgoing (and properly formatted) but the packets don't seem to come back to me. Even if I send it out with the broadcast address, I don't seem to get the packet back to the interface that sent it. Is this standard behaviour? Is there any way to send out a packet addressed to myself and have it come back to me? 2) Using ETH_P_LOOP as the protocol in the call to socket(), I can't seem to receive any messages whatsoever. If I set this to ETH_P_ALL, then I get all messages (including ones with protocol set to ETH_P_LOOP). It almost seems like ETH_P_LOOP isn't properly handled by the kernel. Is this the case? The nitty-gritty on this is that I have a machine that has two NICs but only one IP address. I want to do some kind of packet loopback at the ethernet layer to verify that my NIC transceiver is working properly. If anyone has any bright ideas, I'd be glad to hear them. Thanks, Chris -- Chris Friesen| MailStop: 043/33/F10 Nortel Networks | work: (613) 765-0557 3500 Carling Avenue | fax: (613) 765-2986 Nepean, ON K2H 8E9 Canada| email: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Looking for ifenslave.c
Guus, there isn't a really official version of it.. At http://pdsf.nersc.gov/linux/ifenslave.c is the last version I produced, that works with bonding in v2.2 and v2.4 kernels. Please note; I'm currently bound up in DOE/LBNL contract issues, that prevent any work on any GPL code on DOE/LBNL time. Folks, don't flame us - we know it, we are working on it. (The problem actually dates back to the 50's, when the labs where created!) Once this contract issue is cleared up, I've been given the 'Ok' to work on it again. Which means, since I don't have anything at home to work on bonding with, I can't officially support it. Sorry. thomas Guus Sliepen wrote: > > Hello, > > The Ethernet bonding module is useless without ifenslave.c. I'm making a Debian > package for it, and I have tried to find the "offical" distribution of this > small program. I could not find an authorative source, instead a lot of copies > and patched versions are scattered around the Internet (I maintain a patched > version myself too). > > I would like to combine all the useful extra features and patches into this > Debian package, so if you know of a patched version or maintain one yourself, > please send it to me. > > Thanks, > > -- > Met vriendelijke groet / with kind regards, > Guus Sliepen <[EMAIL PROTECTED]> > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- +-- Thomas Davis| ASG Cluster guy [EMAIL PROTECTED] | (510) 486-4524 | "80 nodes and chugging Captain!" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SMP spin-locks
Hi, Wait a minute... Spinlocks on a embedded system? Is it _really_ SMP? What kind of performance problem do you have? My guess, since you are mentioning spin locks, is that you are having a latency problem - RT process does not execute/start quickly enough? If that is the case you should look at Andrew Mortons low latency patches. http://www.uow.edu.au/~andrewm/linux/schedlat.html /RogerL On Thursday 14 June 2001 19:26, Richard B. Johnson wrote: > I __finally__ got back on "the list". They finally fixed the > company firewall! > > During my absence, I had the chance to look at some SMP code > because of a performance problem (a few microseconds out of > spec on a 130 MHz embedded system) and I have a question about > the current spin-locks. > > Spin-locks now transfer control to the .text.lock segment. > This is a separate segment that can be at an offset that > is far away from the currently executing code. That may > cause the cache to be reloaded. Further, each spin-lock > invocation generates separate code within that segment. > > Question 1: Why? > > Question 2: What is the purpose of the code sequence, "repz nop" > generated by the spin-lock code? Is this a processor BUG work-around? > `as` doesn't "like" this sequence and, Intel doesn't seem to > document it. > > > Cheers, > Dick Johnson > > Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips). > > "Memory is like gasoline. You use it up when you are running. Of > course you get it all back when you reboot..."; Actual explanation > obtained from the Micro$oft help desk. > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Roger Larsson Skellefteå Sweden - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: bzDisk compression Q; boot debug Q
Holger Lubitz wrote: > > "D. Stimits" proclaimed: > > down to 1.44 MB. But then it would also have to be self-extracting, > > which complicates it, so I'm wondering how effective this current > > compression is, and if a more bzip2-like system would be beneficial as > > kernels get larger? > > bzip2 has pretty large memory requirements, consuming up to 8 MB in > addition to the data being uncompressed. > Although thats less of an issue now than it was some years ago, i still > doubt that the kernel is going to be bzip2 compressed any time soon. > > if you're looking for better compression, you might want to examine upx > (http://wildsau.idv.uni-linz.ac.at/mfx/upx.html). The kernel image > compression is still experimental, but already usable. kernels tend to > get ~100 K smaller compared to the usual gzip compressed bzImage. Interesting stuff...and the license is non-commercial as well. D. Stimits, [EMAIL PROTECTED] > > Holger > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.6-pre2, pre3 VM Behavior
Roger> It does if you are running on a laptop. Then you do not want Roger> the pages go out all the time. Disk has gone too sleep, needs Roger> to start to write a few pages, stays idle for a while, goes to Roger> sleep, a few more pages, ... That could be handled by a metric which says if the disk is spun down, wait until there is more memory pressure before writing. But if the disk is spinning, we don't care, you should start writing out buffers at some low rate to keep the pressure from rising too rapidly. The idea of buffers is more to keep from overloading the disk subsystem with IO, not to stop IO from happening at all. And to keep it from going from no IO to full out stalling the system IO. It should be a nice line as VM pressure goes up, buffer flushing IO rate goes up as well. Overall, I think Rik, Jonathan and the rest of the hard core VM crew have been doing a great job with 2.4.5+ work, it seems like it's getting better and better all the time, and I really appreciate it. We're now more into some corner cases and tuning issues. Hopefully. John John Stoffel - Senior Unix Systems Administrator - Lucent Technologies [EMAIL PROTECTED] - http://www.lucent.com - 978-952-7548 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.6-pre2, pre3 VM Behavior
On Thursday 14 June 2001 10:47, Daniel Phillips wrote: > On Thursday 14 June 2001 05:16, Rik van Riel wrote: > > On Wed, 13 Jun 2001, Tom Sightler wrote: > > > Quoting Rik van Riel <[EMAIL PROTECTED]>: > > > > After the initial burst, the system should stabilise, > > > > starting the writeout of pages before we run low on > > > > memory. How to handle the initial burst is something > > > > I haven't figured out yet ... ;) > > > > > > Well, at least I know that this is expected with the VM, although I do > > > still think this is bad behavior. If my disk is idle why would I wait > > > until I have greater than 100MB of data to write before I finally > > > start actually moving some data to disk? > > > > The file _could_ be a temporary file, which gets removed > > before we'd get around to writing it to disk. Sure, the > > chances of this happening with a single file are close to > > zero, but having 100MB from 200 different temp files on a > > shell server isn't unreasonable to expect. > > This still doesn't make sense if the disk bandwidth isn't being used. > It does if you are running on a laptop. Then you do not want the pages go out all the time. Disk has gone too sleep, needs to start to write a few pages, stays idle for a while, goes to sleep, a few more pages, ... /RogerL -- Roger Larsson Skellefteå Sweden - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Going beyond 256 PCI buses
Jeff Garzik writes: > ok with me. would bus #0 be the system or root bus? that would be my > preference, in a tiered system like this. Bus 0 is controller 0, of whatever bus type that happens to be. If we want to do something special we could create something like /proc/bus/root or whatever, but I feel this unnecessary. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Going beyond 256 PCI buses
"David S. Miller" wrote:
>
> Jeff Garzik writes:
> > Thinking a bit more independently of bus type, and with an eye toward's
> > 2.5's s/pci_dev/device/ and s/pci_driver/driver/, would it be useful to
> > go ahead and codify the concept of PCI domains into a more generic
> > concept of bus tree numbers? (or something along those lines) That
> > would allow for a more general picture of the entire system's device
> > tree, across buses.
> >
> > First sbus bus is tree-0, first PCI bus tree is tree-1, second PCI bus
> > tree is tree-2, ...
>
> If you're going to do something like this, ie. true hierarchy, why not
> make one tree which is "system", right? Use /proc/bus/${controllernum}
> ala:
>
> /proc/bus/0/type--> "sbus", "pci", "zorro", etc.
> /proc/bus/0/* --> for type == "pci" ${bus}/${dev}.${fn}
> for type == "sbus" ${slot}
> ...
>
> How about this?
ok with me. would bus #0 be the system or root bus? that would be my
preference, in a tiered system like this.
--
Jeff Garzik | Andre the Giant has a posse.
Building 1024|
MandrakeSoft |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: threading question
bert hubert wrote: > > > I see lots of people only using: > pthread_create()/pthread_join() > mutex_lock/unlock > sem_post/sem_wait > no signals > > My gut feeling is that you could implement this subset in a way that is both > fast and right - although it would not be 'pthreads compliant'. Can anybody > confirm this feeling? ... add condition variables (maybe a small per-thread storage area) and I'd toss out pthreads for most apps I write...especially if it is very efficient. -- --- Russell Leighton[EMAIL PROTECTED] --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3com Driver and the 3XP Processor
> Now, if the NIC were to integrate with OpenSSL and offload some of THAT > donkey work... Just offloading DES isn't terribly useful, as Pavel says: > apart from anything else, DES is a bit elderly now - SSH using 3DES or > Blowfish etc... How dedicated is this card? Could it be used to offload > other work? Sorry my bad it is 3DES that they have on it, but I don't know how in-grained it is in it. Like I sad it just floated across my desk a few days ago and it sounded like a cool bit of hardware. Brent Norris Executive Advisor -- WKU-Linux System Administrator -- WKU-Center for Biodiversity Best Mechanical W: 270-745-8864 H: 270-563-9226 "The problem with the Linux learning curve is that it is _so_ steep once at the top you can't see the people at the bottom" --Doug Hagan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
On Wed, 13 Jun 2001, Colonel wrote: >>I really think doing a clean up is worthwhile. Maybe while looking for stuff > >You left out all the old non-IDE CDROM drives. And also UP systems. I've got 2 SMP boxes here now. Why not remove support for any system with less than 2 processors? ;o) I'll just have to replace my 486 firewall with the dual 486 in the closet. ;o) -- Mike A. Harris - Linux advocate - Open Source advocate Opinions and viewpoints expressed are solely my own. -- If Bill Gates had a dime for every time Windows crashed, he'd be rich! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
On Wed, 13 Jun 2001, Daniel wrote: >i386, i486 >The Pentium processor has been around since 1995. Support for these older >processors should go so we can focus on optimizations for the pentium and >better processors. [SNIP] Boy, if this isn't a troll, I don't know what is. Obviously someone doesn't grok the kernel development processes very well. Newbie here? One needn't even *be* a kernel hacker to understand why all of the stuff stated is totally not going to happen, and there would be no benefit to doing so. -- Mike A. Harris - Linux advocate - Open Source advocate Opinions and viewpoints expressed are solely my own. -- Foot and mouth disease is believed by experts to be the first virus that is unable to spread via Microsoft Outlook. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.6pre3aa1 [was Re: 2.4.6pre2aa2 [was Re: 2.4.5aa1]]
Diff between 2.4.6pre2aa2 and 2.4.6pre3aa1: - Moved on top of 2.4.6pre3. Only in 2.4.6pre2aa2: 00_alpha-compile-swapon-1 Only in 2.4.6pre2aa2: 00_x86-entry.S-fix-1 Merged in 2.4.6pre3. Only in 2.4.6pre3aa1: 00_backout-gcc-3_0-patch-1 Backout 2.4.6pre3 gcc 3.0 change. (nice to have) Only in 2.4.6pre3aa1: 00_alpha-warnings-1 Fix alpha warning from Jeff. (nice to have) Only in 2.4.6pre2aa2: 00_ksoftirqd-5 Only in 2.4.6pre3aa1: 00_ksoftirqd-6 Replace _NOVERS with %c0. (nice to have) Only in 2.4.6pre2aa2: 00_o_direct-8 Only in 2.4.6pre3aa1: 00_o_direct-9 Improve truncate_inode_pages and invalidate_inode_pages2. This patch triggered a bug in the alpha port where O_DIRECT was defined as O_SYNC. O_DIRECTIO of tru64 is defined as ours O_NOFOLLOW, so some breakage is going on. To at least allow O_SYNC to work on alpha I defined for now O_DIRECT as 0200 and we'll possibly change it later. (recommended) Only in 2.4.6pre3aa1: 00_backout-udelay-1 Only in 2.4.6pre3aa1: 10_alpha-udelay-1 Replace 2.4.6pre3 change with a better fix proposed by me and implemented by Jeff. (nice to have) - Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: IPsec support
Yo Eddie! On Thu, 14 Jun 2001 [EMAIL PROTECTED] wrote: > I checked 2.4.x source code but did not find any code for IPsec. Does > anyone know that current or latest Linux support IPsec? Or does anyone know > who is working on this ipv6 issue? www.freeswan.org RGDS GARY --- Gary E. Miller Rellim 20340 Empire Ave, Suite E-3, Bend, OR 97701 [EMAIL PROTECTED] Tel:+1(541)382-8588 Fax: +1(541)382-8676 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bigmem support (4 gigas) is stable?
On Wed, Jun 13, 2001 at 01:55:00PM +0200, Miquel Colom Piza wrote: > I should add 1 giga of RAM to a machine which already has 1 giga. I know > I will have to configure bigmem support in the kernel (2.2.19). I would > like to know if this option is considered really stable and tested or I > can expect some problems, because this is a heavy loaded critical server > and in case of doubt I'll habilitate another server instead of giving > more RAM to the one I already use. I have a gigabyte GA-7DXR (athlon 1.33ghz) with 1.25GB of ram pumping out 100,000 postgresql database-driven emails per hour with 2.4.5-ac7, so I figure it's fine. -- Confucious say: passionate kiss like spider web, lead to undoing of fly. ** Sadistic Pacifist Bryon Roche, Kain <[EMAIL PROTECTED]> PGP signature
RE: [Acpi] APM, ACPI, and Wake on LAN - the bane of my existance
Alex, Looking at the back of a Linksys EtherFast 10/100 manual I happen to have, they describe two different remote wake-up events, Magic Packet and Link Change. The first one is pretty obvious and is probably not related to your problems, but the second one may be. The manual states ""Link Change is a remote wake up event that is triggered by any change in the EtherFast card's link state." Plugging in a LAN cable is the example given that would turn the system on. You may have to look at the driver source to see if this is enabled by default or you may have to modify the driver to disable this "feature" on the card. Regarding the WOL cable, this was used for older motherboards before PCI 2.2, though it is still present on newer motherboards to support older PCI cards. A PCI 2.2 compliant motherboard and NIC use the #PME signal on the PCI bus to signal the wake. Dave > > I have an athlon system with a iwill kk266 motherboard (via > kt133A). I > have a linksys 10/100 PCI ethernet card with wake on lan > capabilities. > Anyway, when I shut the PC down it turns off, but refuses to > stay off. > Within a minute or two, it turns itself on again. If i run over and > turn it off by hitting the power putton, it turns off, but then comes > back on again at a later somewaht arbitrary time (1 minute to several > hours later). I originally got the WOL card so I could > remotely boot my > PC, but at this point it has turned out to be more trouble than it's > worth. I tried to disable WOL inthe BIOS, but that didn't change > anything. So I removed the three pin cross connect that connects the > card to the WOL header on the motherboard. That fixed it for a few > days, but now it's doing it again, even without the cable installed. > the only fix is to unplug the ethernet cable when I turn it off. > > I suspect the problem has something to do with WOL vs. resume on LAN. > the system should only turn on when it recieves a magic packet, but it > seems that any packet may cause it to boot (or resume, but since it is > in the "off" state, boot). I've only been using APM, but perhaps acpi > is required for this to work properly. As far as why it does > this when > the 3 pin WOL connector was not used, I'm not sure, maybe something to > do with PCI 2.2. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux Documentation/modules.txt
I just noticed that file "rc.hints" mentioned in modules.txt does not exist anywhere in the module utilities package. I looked in modutils-2.4.2 as documented in Changes. If rc.hints really doesn't exist, perhaps the sentence in parenthesis should be removed, since it doesn't assist the reader. The following text is from modules.txt: To use modprobe successfully, you generally place the following command in your /etc/rc.d/rc.S script. (Read more about this in the "rc.hints" file in the module utilities package, "modutils-x.y.z.tar.gz".) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
IPsec support
Folks, I checked 2.4.x source code but did not find any code for IPsec. Does anyone know that current or latest Linux support IPsec? Or does anyone know who is working on this ipv6 issue? Many thanks! Eddie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
About KDKBDREP
Some days ago I posted patch to introduce KDKBDREP ioctl to i386 keyboard routines. KDKBDREP is defined in linux/kd.h but now he is used only on m68k. In sparc architectures is used KIOCSRATE, on i386 -- user-space utility kbdrate and I know nothing about others. It seems to be better to use one ioctl on all of archs because: - it unifies keyboard rate setting; - it will be done in kernel context avoiding cases of simultaneous access same I/O ports by different programs. (see A.Cox msg). In previous patch I had tried to change i386 kbd files in order to inmplement KDKBDREP. Now I changed sparc files in such a fashion. But I haven't sparc box and cannot test my changes so I'll be very glad if someone test my patch. Thanks advance. PS: please CC replies to my email because I'm not subscribed on linux-kernel. -- Sergey Tursanov mailto:[EMAIL PROTECTED] patch-kbdrate-2.4.5
Re: 2.4.6-pre2, pre3 VM Behavior
On Thursday 14 June 2001 17:10, John Stoffel wrote: > >> The file _could_ be a temporary file, which gets removed before > >> we'd get around to writing it to disk. Sure, the chances of this > >> happening with a single file are close to zero, but having 100MB > >> from 200 different temp files on a shell server isn't unreasonable > >> to expect. > > Daniel> This still doesn't make sense if the disk bandwidth isn't > Daniel> being used. > > And can't you tell that a certain percentage of buffers are owned by a > single file/process? It would seem that a simple metric of > >if ##% of the buffer/cache is used by 1 process/file, start >writing the file out to disk, even if there is no pressure. > > might do the trick to handle this case. Buffers and file pages are owned by the vfs, not processes pre se, so it makes accounting harder. In this case you don't care: it's a file, so in the absence of memory pressure and with disk bandwidth available it's better to get the data onto disk sooner rather than later. (This glosses over the question of mmap's, by the way.) It's pretty hard to see why there is any benefit at all in delaying, but it's clear there's a benefit in terms of data safety and a further benefit in terms of doing what the user expects. > >> Maybe we should just see if anything in the first few MB of > >> inactive pages was freeable, limiting the first scan to something > >> like 1 or maybe even 5 MB maximum (freepages.min? freepages.high?) > >> and flushing as soon as we find more unfreeable pages than that ? > > Daniel> For file-backed pages what we want is pretty simple: when 1) > Daniel> disk bandwidth is less than xx% used 2) memory pressure is > Daniel> moderate, just submit whatever's dirty. As pressure increases > Daniel> and bandwidth gets loaded up (including read traffic) leave > Daniel> things on the inactive list longer to allow more chances for > Daniel> combining and better clustering decisions. > > Would it also be good to say that pressure should increase as the > buffer.free percentage goes down? Maybe - right now getblk waits until it runs completely out of buffers of a given size before trying to allocate more, which means that sometimes an io will be delayed by the time it takes to complete a page_launder cycle. Two reasons why it may not be worth doing anything about this: 1) we will move most of the buffer users into the page cache in due course 2) the frequency of this kind of io delay is *probably* pretty low. > It won't stop you from filling the > buffer, but it should at least start pushing out pages to disk > earlier. -- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: unregistered changes to the user<->kernel API
On Thu, Jun 14, 2001 at 07:47:57PM +0200, Andrea Arcangeli wrote: > On Thu, Jun 14, 2001 at 10:32:49AM -0700, Richard Henderson wrote: > > within glibc, and (2) making these accesses slower since they > > will be considered O_DIRECT after the change. > > and then read/write will return -EINVAL which is life-threatening. It would? I thought it would be ignored at minimum. Damnit, I guess we'll have to move it after all. How completely irritating. r~ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: unregistered changes to the user<->kernel API
On Thu, Jun 14, 2001 at 07:47:57PM +0200, Andrea Arcangeli wrote: > On Thu, Jun 14, 2001 at 10:32:49AM -0700, Richard Henderson wrote: > > within glibc, and (2) making these accesses slower since they > > will be considered O_DIRECT after the change. > > and then read/write will return -EINVAL which is life-threatening. > O_DIRECT like rawio via /dev/raw imposes special buffer size and > alignment (size multiple of softblocksize of the fs and softblocksize > alignment, at max I can turn it down to hardblocksize without intensive > changes and guaranteeing zerocopy [modulo bounce buffers on x86 of > course]). > > So in short at least glibc would need to be replaced... in the meantime we solve this issue I released a new o_direct patch and a 2.4.6pre3aa1 with O_DIRECT set like in the patches I sent to Linus at the start of the thread. As soon as we take a definitive decision I will update them. (in the meantime alpha users will at least be allowed again to use O_SYNC with o_direct support applied ;) Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Buddy System bitmaps
Hi, For this scenario consider a set of 4 page frames. Frames 0 and 2 are used while frames 1 and 3 are free. The question is would the bitmap for order 1 be a 1 or 0 for this scenario. I am not on the list so please cc me on your response. Thanks in advance. Ramil J.Santamaria Toshiba America Information Systems (949) 461-4379 (949) 206-3439 - fax [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: more on VIA 686B (trials)
> Abit KT7A, kernel oops right after boot... :( Can be solved to turning off > 'Enhance Chip Performance' in the BIOS, but then our chip performance is > un'Enhance'd, and we can't have that! So back to the K6 kernel. And praying it doesnt go wrong on you - has it not occurred to you that the extremely high throughput copies that the mmx copy we use causes will occasionally happen by chance and get you anyway ? Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: more on VIA 686B (trials)
David Monniaux wrote: >I replaced this mobo+Duron with an ASUS A7V133+Athlon, which >work perfectly well. >Athlon-optimized kernel, UDMA100, no problem whatsoever. > Which is odd, because that's exactly my combination (ASUS A7V133 + Athlon), and I get crashes with DMA on anything from 2.4.3-ac7 onwards, but up to 2.4.3-ac6 is rock-steady. (my crash test is "bonnie -s 1024" :-)) I wonder what's different between our machines (apart from distro, which I wouldn't expect to be relevant)? Clock speed? We tried downclocking my Athlon to 1.0 GHz but it made no difference. I've been tinkering (have no kernel programming experience) with selectively forward-porting the 2.4.3-ac6 code to newer kernels for my own use at least, but haven't got it right yet. -- Rachel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: unregistered changes to the user<->kernel API
On Thu, 14 Jun 2001, Richard Henderson wrote: > Yes, I saw those. What is the effect of O_NOFOLLOW? To not > follow symbolic links when opening the file. If you open a > regular file, in effect nothing happens. Moreover, if these > opens were not finding files now, the system wouldn't work. > > So: the effect, I suppose, is (1) disabling some security > within glibc, and (2) making these accesses slower since they > will be considered O_DIRECT after the change. > > Which doesn't seem that life-threatening to me. O_NOFOLLOW is used to deal with symlink attacks. Breaking it means that for quite a few binaries you are opening security holes. And since it's a flagday change, you'll get the situation when no version will work for all kernels. Bad idea, IMO. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
aic7xxx problems on 2.4.4
On 2.4.4, with the aic7xxx driver loaded, if a test unit ready command (0) is sent to a device which is not loaded via the generic scsi interface, it results in the driver rolling out of memory, even though sg may have open file handles for /dev/sgX, etc. active. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: more on VIA 686B (trials)
On Thursday 14 June 2001 12:44 pm, David Monniaux wrote: > So we have two kinds of problems: > - *certain* 686B motherboards crash if used with an Athlon kernel > (and it does not depend on the compiler options, rather on hand-made > Athlon optimizations) Abit KT7A, kernel oops right after boot... :( Can be solved to turning off 'Enhance Chip Performance' in the BIOS, but then our chip performance is un'Enhance'd, and we can't have that! So back to the K6 kernel. -- Cory 'G' Watson Dad are you vicariously living through me in the hope that my accomplishments will validate your mediocre life and in some way compensate for all the opportunities you botched ? -- Calvin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: unregistered changes to the user<->kernel API
On Thu, Jun 14, 2001 at 01:52:44PM -0400, Jeff Garzik wrote: > You're missing the point -- it's a bad precedent. > > How many kernel forks and patches exist out there on the net? How many of them are applied to 90% of kernels running out there? How many of them will get merged eventually? How many of them makes modifications to the kernel that are visible to userspace in any possibly configuration of the kernel? > Tangent: Why is this webserver-specific crap in kernel_stat anyway? It > Even when merging Tux, I would hope Linus would not apply this > particular change. Indeed, I also said this in my first email :) Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Going beyond 256 PCI buses
David S. Miller writes:
> Jeff Garzik writes:
>> According to the PCI spec it is -impossible- to have more than 256
>> buses on a single "hose", so you simply have to implement multiple
>> hoses, just like Alpha (and Sparc64?) already do. That's how the
>> hardware is forced to implement it...
>
> Right, what userspace had to become aware of are "PCI domains" which
> is just another fancy term for a "hose" or "controller".
>
> All you have to do is (right now, the kernel supports this fully)
> open up a /proc/bus/pci/${BUS}/${DEVICE} node and then go:
>
> domain = ioctl(fd, PCIIOC_CONTROLLER, 0);
>
> Viola.
>
> There are only two real issues:
No, three.
0) The API needs to be taken out and shot.
You've added an ioctl. This isn't just any ioctl. It's a
wicked nasty ioctl. It's an OH MY GOD YOU CAN'T BE SERIOUS
ioctl by any standard.
Consider the logical tree:
hose -> bus -> slot -> function -> bar
Well, the hose and bar are missing. You specify the middle
three parts in the filename (with slot and function merged),
then use an ioctl to specify the hose and bar.
Doing the whole thing by filename would be better. Else
why not just say "screw it", open /proc/pci, and do the
whole thing by ioctl? Using ioctl for both the most and
least significant parts of the path while using a path
for the middle part is Wrong, Bad, Evil, and Broken.
Fix:
/proc/bus/PCI/0/0/3/0/config config space
/proc/bus/PCI/0/0/3/0/0the first bar
/proc/bus/PCI/0/0/3/0/1the second bar
/proc/bus/PCI/0/0/3/0/driver info about the driver, if any
/proc/bus/PCI/0/0/3/0/eventhot-plug, messages from driver...
Then we have arch-specific MMU cruft. For example the PowerPC
defines bits that affect caching, ordering, and merging policy.
The chips from IBM also define an endianness bit. I don't think
this ought to be an ioctl either. Maybe mmap() flags would be
reasonable. This isn't just for PCI; one might do an anon mmap
with pages locked and cache-incoherent for better performance.
> 1) Extending the type bus numbers use inside the kernel.
...
> 2) Figure out what to do wrt. sys_pciconfig_{read,write}()
...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: unregistered changes to the user<->kernel API
Andrea Arcangeli wrote: > > On Thu, Jun 14, 2001 at 01:25:10PM -0400, Jeff Garzik wrote: > > They don't hurt but it's also a bad precedent - you don't want to add a > > ton of CONFIG_xxx to the Linus tree for stuff outside the Linus tree. > > disagree with this patch. > > If tux will ever be merged into mainline eventually I don't think > there's a value in defer such bit. Of course if tux will never get > merged then I totally agree with you. You're missing the point -- it's a bad precedent. How many kernel forks and patches exist out there on the net? Many of these patches will get merged eventually. But it is a bad idea to include bits of such into the Linus tree, when they are not used in the Linus tree. -Exceptions- to this policy should be carefully considered... reserving syscall and sysctl numbers certainly makes sense. Bloating kernel_stat with tons of unused numbers, some specific to web servers AFAICS, does not make sense. Tangent: Why is this webserver-specific crap in kernel_stat anyway? It looks like there should be a separate per-cpu structure for webserver statistics. > + unsigned int parse_static_incomplete; > + unsigned int parse_static_redirect; > + unsigned int parse_static_cachemiss; > + unsigned int parse_static_nooutput; > + unsigned int parse_static_normal; > + unsigned int parse_dynamic_incomplete; > + unsigned int parse_dynamic_redirect; > + unsigned int parse_dynamic_cachemiss; > + unsigned int parse_dynamic_nooutput; > + unsigned int parse_dynamic_normal; > + unsigned int complete_parsing; > + > + unsigned int nr_keepalive_reqs; > + unsigned int nr_nonkeepalive_reqs; > +#define KEEPALIVE_HIST_SIZE 100 > + unsigned int keepalive_hist[KEEPALIVE_HIST_SIZE]; Even when merging Tux, I would hope Linus would not apply this particular change. Jeff -- Jeff Garzik | Andre the Giant has a posse. Building 1024| MandrakeSoft | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: unregistered changes to the user<->kernel API
On Thu, Jun 14, 2001 at 10:32:49AM -0700, Richard Henderson wrote: > within glibc, and (2) making these accesses slower since they > will be considered O_DIRECT after the change. and then read/write will return -EINVAL which is life-threatening. O_DIRECT like rawio via /dev/raw imposes special buffer size and alignment (size multiple of softblocksize of the fs and softblocksize alignment, at max I can turn it down to hardblocksize without intensive changes and guaranteeing zerocopy [modulo bounce buffers on x86 of course]). So in short at least glibc would need to be replaced... Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
more on VIA 686B (trials)
Due to a catastrophic fan short-circuit, I was forced to exchange my 686A-based motherboard for a 686B. Bad idea! The 686A MB (MSI-6330 aka K7T-Pro) worked perfectly well: no crashes, UDMA 66. It accepted Athlon-optimized kernels. The 686B MB (K7T-Lite) crashed if used with DMA (any kind - mdma0 to UDMA100), whatever version of the "VIA fixes" was in place. Furthermore, upgrading to BIOS 2.7 (instead of 2.5), including a so-called "SB Live fix", made the system permanently unstable. On top of that, running an Athlon-optimized kernel (whether or not it was compile with =march=i686 (egcs-1.1.2) or -march=athlon (gcc 2.96) immediately oops and crash during /etc/rc! I replaced this mobo+Duron with an ASUS A7V133+Athlon, which work perfectly well. Athlon-optimized kernel, UDMA100, no problem whatsoever. So we have two kinds of problems: - *certain* 686B motherboards crash if used with an Athlon kernel (and it does not depend on the compiler options, rather on hand-made Athlon optimizations) - *certain* 686B motherboards will crash if used with any kind of DMA under heavy disk access - some 686B motherboards have absolutely no problem. Crash test: for i in `seq 1 30` ; do echo $i; tar xfz X410src-1.tgz ; rm -rf xc; done All the above is valid for kernel version 2.4.2-RedHat to 2.4.5ac9... Another lesson: the MSI K7T-Lite is absolute crap. The manual sucks, and the BIOS upgrades supposed to make the machine stabler actually make it randomly hiccup (EVEN under Windows, which is what I suppose those mobos are supposed to run). -- David Monniauxhttp://www.di.ens.fr/~monniaux Laboratoire d'informatique de l'École Normale Supérieure, Paris, France - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: unregistered changes to the user<->kernel API
On Thu, Jun 14, 2001 at 01:25:10PM -0400, Jeff Garzik wrote: > They don't hurt but it's also a bad precedent - you don't want to add a > ton of CONFIG_xxx to the Linus tree for stuff outside the Linus tree. > disagree with this patch. If tux will ever be merged into mainline eventually I don't think there's a value in defer such bit. Of course if tux will never get merged then I totally agree with you. > this conflicts with noone, so can wait for tux patch same as above. > ouch! I would understand if this was inside CONFIG_TUX, but even so I > would disagree until Tux is merged. Then you may prefer to wait tux to be merged before merging the rest as well, in the meantime 90% of the kernels running out there will show such stuff out of /proc/stats (hopefully "the same stuff" which is why I'm posting those patches in first place). Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
APM, ACPI, and Wake on LAN - the bane of my existance
I have an athlon system with a iwill kk266 motherboard (via kt133A). I have a linksys 10/100 PCI ethernet card with wake on lan capabilities. Anyway, when I shut the PC down it turns off, but refuses to stay off. Within a minute or two, it turns itself on again. If i run over and turn it off by hitting the power putton, it turns off, but then comes back on again at a later somewaht arbitrary time (1 minute to several hours later). I originally got the WOL card so I could remotely boot my PC, but at this point it has turned out to be more trouble than it's worth. I tried to disable WOL inthe BIOS, but that didn't change anything. So I removed the three pin cross connect that connects the card to the WOL header on the motherboard. That fixed it for a few days, but now it's doing it again, even without the cable installed. the only fix is to unplug the ethernet cable when I turn it off. I suspect the problem has something to do with WOL vs. resume on LAN. the system should only turn on when it recieves a magic packet, but it seems that any packet may cause it to boot (or resume, but since it is in the "off" state, boot). I've only been using APM, but perhaps acpi is required for this to work properly. As far as why it does this when the 3 pin WOL connector was not used, I'm not sure, maybe something to do with PCI 2.2. Any thoughts? This is driving me nuts. Alex Please CC: me in your reply. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: what's the purpose of SYMBOL_NAME()
Marty Leisner wrote: > > I'm read Bovet's "Understand the Linux Kernel" > and looked at the assembly routine setup_idt... > > I noticed the assembly has SYMBOL_NAME > (its all over the place). > > This is define in include/linux/linkage.h > > to just: > #define SYMBOL_NAME(X) X > > (this wasn't in Bovet's book). > > What's the purpose? IIRC, it's a holdover from the days when the kernel could be compiled in a.out and ELF format. a.out prepends an underscore to all symbols, whereas ELF does not. -- Brian Gerst - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SMP spin-locks
On Thu, Jun 14, 2001 at 01:26:05PM -0400, Richard B. Johnson wrote: > Question 2: What is the purpose of the code sequence, "repz nop" Puts iP4 into low power mode. Regards, -- Kurt Garloff <[EMAIL PROTECTED]> Eindhoven, NL GPG key: See mail header, key servers Linux kernel development SuSE GmbH, Nuernberg, FRG SCSI, Security PGP signature
Re: 2.4.6-pre2, pre3 VM Behavior
> > Would it be possible to maintain a dirty-rate count > > for the dirty buffers? > > > > For example, we it is possible to figure an approximate > > disk subsystem speed from most of the given information. > > Disk speed is difficult. I may enable and disable swap on any number of ... > You may be able to get some useful approximations, but you > will probably not be able to get good numbers in all cases. a useful approximation would be simply an idle flag. for instance, if the disk is idle, then cleaning a few inactive-dirty pages would make perfect sense, even in the absence of memory pressure. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: unregistered changes to the user<->kernel API
On Thu, Jun 14, 2001 at 07:21:22PM +0200, Andrea Arcangeli wrote: > Richard are you sure we can break O_NOFOLLOW and still expect the machine to > boot? [uses in glibc] Yes, I saw those. What is the effect of O_NOFOLLOW? To not follow symbolic links when opening the file. If you open a regular file, in effect nothing happens. Moreover, if these opens were not finding files now, the system wouldn't work. So: the effect, I suppose, is (1) disabling some security within glibc, and (2) making these accesses slower since they will be considered O_DIRECT after the change. Which doesn't seem that life-threatening to me. r~ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: unregistered changes to the user<->kernel API
Andrea Arcangeli wrote:
> Here the third, it registers the tux syscall at for the alpha so other
> people won't use such same syscall for something else (I didn't remove
> the #ifdefs since they don't hurt as they're undefined in mainline).
>
> diff -urN ref/arch/alpha/kernel/entry.S tuxsys/arch/alpha/kernel/entry.S
> --- ref/arch/alpha/kernel/entry.S Sat Apr 28 18:37:45 2001
> +++ tuxsys/arch/alpha/kernel/entry.SSun Apr 29 17:52:44 2001
> @@ -1004,7 +1004,15 @@
> .quad alpha_ni_syscall
> .quad alpha_ni_syscall /* 220 */
> .quad alpha_ni_syscall
> +#ifdef CONFIG_TUX
> + .quad __sys_tux
> +#else
> +# ifdef CONFIG_TUX_MODULE
> + .quad sys_tux
> +# else
> .quad alpha_ni_syscall
> +# endif
> +#endif
They don't hurt but it's also a bad precedent - you don't want to add a
ton of CONFIG_xxx to the Linus tree for stuff outside the Linus tree.
disagree with this patch.
> Here the fifth, this defines the tux sysctl numbers (OTOH the sysctl by
> number gets broken all the time and nobody should use sysctl by number
> with new sysctls anyways).
>
> diff -urN 2.4.5pre5/include/linux/sysctl.h tux-sysctl/include/linux/sysctl.h
> --- 2.4.5pre5/include/linux/sysctl.hTue May 22 22:04:27 2001
> +++ tux-sysctl/include/linux/sysctl.h Wed May 23 19:20:48 2001
> @@ -157,7 +157,8 @@
> NET_TR=14,
> NET_DECNET=15,
> NET_ECONET=16,
> - NET_KHTTPD=17
> + NET_KHTTPD=17,
> + NET_TUX=18
> };
ok
> +/* /proc/sys/net/tux/ */
> +enum {
> + NET_TUX_DOCROOT = 1,
> + NET_TUX_LOGFILE = 2,
this conflicts with noone, so can wait for tux patch
> diff -urN 2.4.5pre5/include/linux/kernel_stat.h tux-kstat/include/linux/kernel_stat.h
> --- 2.4.5pre5/include/linux/kernel_stat.h Tue May 15 21:40:17 2001
> +++ tux-kstat/include/linux/kernel_stat.h Wed May 23 19:06:38 2001
> @@ -33,6 +33,53 @@
> unsigned int ierrors, oerrors;
> unsigned int collisions;
> unsigned int context_swtch;
> + unsigned int context_swtch_cross;
> + unsigned int nr_free_pending;
> + unsigned int nr_allocated;
> + unsigned int nr_idle_input_pending;
> + unsigned int nr_output_space_pending;
> + unsigned int nr_work_pending;
> + unsigned int nr_input_pending;
> + unsigned int nr_cachemiss_pending;
> + unsigned int nr_secondary_pending;
> + unsigned int nr_output_pending;
> + unsigned int nr_redirect_pending;
> + unsigned int nr_postpone_pending;
> + unsigned int nr_finish_pending;
> + unsigned int nr_userspace_pending;
> + unsigned int static_lookup_cachemisses;
> + unsigned int static_sendfile_cachemisses;
> + unsigned int user_lookup_cachemisses;
> + unsigned int user_fetch_cachemisses;
> + unsigned int user_sendobject_cachemisses;
> + unsigned int user_sendobject_write_misses;
> + unsigned int user_sendbuf_cachemisses;
> + unsigned int user_sendbuf_write_misses;
> +#define URL_HIST_SIZE 1000
> + unsigned int url_hist_hits[URL_HIST_SIZE];
> + unsigned int url_hist_misses[URL_HIST_SIZE];
> + unsigned int input_fastpath;
> + unsigned int input_slowpath;
> + unsigned int inputqueue_got_packet;
> + unsigned int inputqueue_no_packet;
> + unsigned int nr_keepalive_optimized;
> +
> + unsigned int parse_static_incomplete;
> + unsigned int parse_static_redirect;
> + unsigned int parse_static_cachemiss;
> + unsigned int parse_static_nooutput;
> + unsigned int parse_static_normal;
> + unsigned int parse_dynamic_incomplete;
> + unsigned int parse_dynamic_redirect;
> + unsigned int parse_dynamic_cachemiss;
> + unsigned int parse_dynamic_nooutput;
> + unsigned int parse_dynamic_normal;
> + unsigned int complete_parsing;
> +
> + unsigned int nr_keepalive_reqs;
> + unsigned int nr_nonkeepalive_reqs;
> +#define KEEPALIVE_HIST_SIZE 100
> + unsigned int keepalive_hist[KEEPALIVE_HIST_SIZE];
> };
ouch! I would understand if this was inside CONFIG_TUX, but even so I
would disagree until Tux is merged.
--
Jeff Garzik | Andre the Giant has a posse.
Building 1024|
MandrakeSoft |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
SMP spin-locks
I __finally__ got back on "the list". They finally fixed the company firewall! During my absence, I had the chance to look at some SMP code because of a performance problem (a few microseconds out of spec on a 130 MHz embedded system) and I have a question about the current spin-locks. Spin-locks now transfer control to the .text.lock segment. This is a separate segment that can be at an offset that is far away from the currently executing code. That may cause the cache to be reloaded. Further, each spin-lock invocation generates separate code within that segment. Question 1: Why? Question 2: What is the purpose of the code sequence, "repz nop" generated by the spin-lock code? Is this a processor BUG work-around? `as` doesn't "like" this sequence and, Intel doesn't seem to document it. Cheers, Dick Johnson Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: unregistered changes to the user<->kernel API
On Thu, Jun 14, 2001 at 07:16:34PM +0200, Andrea Arcangeli wrote: > I just got the email from Richard that he prefers to break O_NOFOLLOW Richard are you sure we can break O_NOFOLLOW and still expect the machine to boot? ./elf/cache.c: fd = open (temp_name, O_CREAT|O_WRONLY|O_TRUNC|O_NOFOLLOW, ./elf/dl-profile.c:#ifdef O_NOFOLLOW ./elf/dl-profile.c:# define EXTRA_FLAGS | O_NOFOLLOW ./elf/rtld.c:#ifdef O_NOFOLLOW ./elf/rtld.c: const int flags = O_WRONLY | O_APPEND | O_CREAT | O_NOFOLLOW; ./include/asm/fcntl.h:#define O_NOFOLLOW040 /* don't follow links */ ./sysdeps/generic/check_fds.c: the O_NOFOLLOW flag for open() but only on some system. */ ./sysdeps/generic/check_fds.c:#ifndef O_NOFOLLOW ./sysdeps/generic/check_fds.c:# define O_NOFOLLOW 0 ./sysdeps/generic/check_fds.c: check_one_fd (STDIN_FILENO, O_RDONLY | O_NOFOLLOW); ./sysdeps/generic/check_fds.c: check_one_fd (STDOUT_FILENO, O_RDWR | O_NOFOLLOW); ./sysdeps/generic/check_fds.c: check_one_fd (STDERR_FILENO, O_RDWR | O_NOFOLLOW); ./sysdeps/unix/sysv/linux/alpha/bits/fcntl.h:# define O_NOFOLLOW020 /* Do not follow links. */ ./sysdeps/unix/sysv/linux/shm_open.c: fd = open (fname, oflag | O_NOFOLLOW, mode); Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: unregistered changes to the user<->kernel API
On Thu, Jun 14, 2001 at 07:12:19PM +0200, Andrea Arcangeli wrote: > is not definitive yet, O_DIRECTIO of tru64 is our O_NOFOLLOW so we're > just screwed as we just need a wrapper anyways to make complex programs like I just got the email from Richard that he prefers to break O_NOFOLLOW than to define O_DIRECT to something else than 020. So probably there will be an incrmeental patch for the alpha later to apply on top of the previous ones. Also please folks remind to never choose random numbers for the alpha userspace visible kernel API. Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Download process for a "split kernel" (was: obsolete code must die)
On Thursday 14 June 2001 08:14, David Luyer wrote: > Well, I'm actually looking at the 2nd idea I mentioned in my e-mail -- a > very small "kernel package" which has a config script, a list of config > options and the files they depend on and an appropriately tagged CVS tree > which can then be used for a compressed checkout of a version to do a > build. (Or maybe something more bandwidth-friendly than CVS for the > initial checkout.) > > Maybe I'll find the spare time to do it, maybe I won't, either way I won't > post any more on the subject until I have something tangible (so far I've > just done the 'easy bit': written a quick shell script which imported 2.4.x > into a tagged CVS tree; the 'hard bit', to write a script to analyse each > kernel rev and determine which files are used by which config options and > mix that in together with the minimal install for a 'make menuconfig' will > take somewhat longer). > > David. You might want to float this idea by Eric Raymond. It's POSSIBLE (distant but possible) that the new CML2 stuff might make this sort of thing easier to automate. Correction, it's possible CML2 might make this POSSIBLE to automate. It sounds like it would still be a female dog and a half to implement. But I'm not the one to ask... Rob - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Download process for a "split kernel" (was: obsolete code must die)
Daniel Phillips writes: > On Thursday 14 June 2001 10:34, Alexander Viro wrote: > > On Thu, 14 Jun 2001, Daniel Phillips wrote: > > > This sounds a lot like apt-get, doesn't it? > > > > Folks, RTFFAQ, please. URL is attached to the end of each posting. > > The FAQ blesses the idea of people setting up incremental download > services, condems the idea of asking Linus to change his procedures > to support this. As it should. > It has nothing to say about the idea of leveraging the cml2 code > base to let apt-get configure and build kernels better, which was > the point of my post. That has been left as an excercise for the FAQ reader. > Presumably you want this question added to the FAQ? ;-) Going into this in detail is not the purpose of the FAQ, but a small, concise patch will be looked upon favourably :-) A link to a more detailed page would nicely supplement a small chunk of text. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
Ok here are my only 2cents, I use some of this hardware that this clean up would kill, I dont like that thought, and my brand spanking new 1.2ghz athalon has a single ISA slot and on board parallel / serial ports all of which are in use so maybee those should be kept, I however I do agree that a smaller kernal would be nice, could some of these older hardware devices be kept out of the kernal? I dont have a clue, I agree on most aspects of why this cleanup should take place, but to what extent? is it an option to take some of this out of the kernal and still support it? maybee in userspace? dont have a clue. but lets not kill everything in this list. thanks for listening and any feedback Richard Reynolds [EMAIL PROTECTED] - Original Message - From: "Jesse Pollard" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; "Daniel" <[EMAIL PROTECTED]>; "Linux kernel" <[EMAIL PROTECTED]> Cc: "Jaswinder Singh" <[EMAIL PROTECTED]> Sent: Thursday, June 14, 2001 7:01 AM Subject: Re: obsolete code must die > - Received message begins Here - > > > > > Cleanup is a nice idea , but Linux should support old hardware and should > > not affect them in any way. > > > > Jaswinder. > > I agree - and added my comments below. > > > - Original Message - > > From: "Daniel" <[EMAIL PROTECTED]> > > To: "Linux kernel" <[EMAIL PROTECTED]> > > Sent: Wednesday, June 13, 2001 5:44 PM > > Subject: obsolete code must die > > > > > > > Anyone concerned about the current size of the kernel source code? I am, > > and > > > I propose to start cleaning house on the x86 platform. I mean it's all > > very > > > well and good to keep adding features, but stuff needs to go if kernel > > > development is to move forward. Before listing the gunk I want to get rid > > > of, here's my justification for doing so: > > > -- Getting rid of old code can help simplify the kernel. This means less > > > chance of bugs. > > > -- Simplifying the kernel means that it will be easier for newbies to > > > understand and perhaps contribute. > > > -- a simpler, cleaner kernel will also be of more use in an academic > > > environment. > > > -- a smaller kernel is easier to maintain and is easier to re-architect > > > should the need arise. > > > -- If someone really needs support for this junk, they will always have > > the > > > option of using the 2.0.x, 2.2.x or 2.4.x series. > > > > > > So without further ado here're the features I want to get rid of: > > > > > > i386, i486 > > > The Pentium processor has been around since 1995. Support for these older > > > processors should go so we can focus on optimizations for the pentium and > > > better processors. > > I'm still using 486 systems Works fine for a DSL firewall. Why change it? > I'd have to buy a whole new system. The case won't hold anything newer - so > it costs $600-$800; I'd rather put that into fixing up the house... or getting > a newer workstation (1.4 GHz looks REALLY nice). I don't need high performance > for a firewall that only handles ~700Kbits/sec over a 10 base T network. > > I also understand that 386 systems make excellent terminal servers... > > > > math-emu > > > If support for i386 and i486 is going away, then so should math emulation. > > > Every intel processor since the 486DX has an FPU unit built in. In fact > > > shouldn't FPU support be a userspace responsibility anyway? > > Not when the code must support register save/restore on context switches. > Now the meat of the emulator perhaps. But then you must also provide a > way for applications that don't know about the lack to suddenly have access > to a new library, accessed via a kernel trap (illegal instruction). This > imposes more context switches on an already slow system (though why anywone > would use floating point on one is beyond me ... maybe performance tracking > of firewall/terminal server use...). > > > > ISA bus, MCA bus, EISA bus > > > PCI is the defacto standard. Get rid of CONFIG_BLK_DEV_ISAPNP, > > > CONFIG_ISAPNP, etc > > > > > > ISA, MCA, EISA device drivers > > > If support for the buses is gone, there's no point in supporting devices > > for > > > these buses. > > Not on the 386/486 systems (at least the ISA/EISA based ones). > > > > all code marked as CONFIG_OBSOLETE > > > Since we're cleaning house we may as well get rid of this stuff. > > > > > > MFM/RLL/XT/ESDI hard drive support > > > Does anyone still *have* an RLL drive that works? At the very least get > > rid > > > of the old driver (eg CONFIG_BLK_DEV_HD_ONLY, CONFIG_BLK_DEV_HD_IDE, > > > CONFIG_BLK_DEV_XD, CONFIG_BLK_DEV_PS2) > > > > > > parallel/serial/game ports > > > More controversial to remove this, since they are *still* in pretty wide > > > use -- but USB and IEEE 1394 are the way to go. No ifs ands or buts. > > really? I'm still running my printer this way (and just bought a parallel > printer/copier/scanner - the USB port isn't finished yet). And one of my > serial mice. Not to mention the plan to add the UPS
Re: [PATCH] Avoid !__GFP_IO allocations to eat from memory reservations
On Thursday 14 June 2001 14:59, Marcelo Tosatti wrote: > --- linux/mm/page_alloc.c.origThu Jun 14 11:00:14 2001 > +++ linux/mm/page_alloc.c Thu Jun 14 11:32:56 2001 > @@ -453,6 +453,12 @@ > int progress = try_to_free_pages(gfp_mask); > if (progress || gfp_mask & __GFP_IO) > goto try_again; > + /* > + * Fail in case no progress was made and the > + * allocation may not be able to block on IO. > + */ > + else > + return NULL; > } > } > } Nitpick dept: the 'else' is redundant. -- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
unregistered changes to the user<->kernel API
There are a number of changes in kernel API visisble to userspace that are unregistered in 2.4 mainline. I recommend to merge them ASAP to avoid generating collisions across different versions of the kernel. I'll attach here a number of patches that should make us to return in sync. They must be applied incrementally. (really the very last one is mostly here for comments, not intendeted for merging in mainline) here the first that defines O_DIRECT (NOTE: the O_DIRECT value for alpha is not definitive yet, O_DIRECTIO of tru64 is our O_NOFOLLOW so we're just screwed as we just need a wrapper anyways to make complex programs like dbms to run correctly without having to natively port them to linux, 0200 in tru64 is O_DSYNC, maybe I should move it to 01000 instead which maybe unused in tru64, but still we would have no guarantee that it won't be used in the future, I was waiting Richard's comment about it). The sparc64 values are approved by Dave. diff -urN 2.4.6pre3/include/asm-alpha/fcntl.h o_direct/include/asm-alpha/fcntl.h --- 2.4.6pre3/include/asm-alpha/fcntl.h Thu Nov 16 15:37:42 2000 +++ o_direct/include/asm-alpha/fcntl.h Thu Jun 14 17:34:56 2001 @@ -17,10 +17,10 @@ #define O_NDELAY O_NONBLOCK #define O_SYNC 04 #define FASYNC 02 /* fcntl, for BSD compatibility */ -#define O_DIRECT 04 /* direct disk access - should check with OSF/1 */ #define O_DIRECTORY010 /* must be a directory */ #define O_NOFOLLOW 020 /* don't follow links */ #define O_LARGEFILE040 /* will be set by the kernel on every open */ +#define O_DIRECT 0200 /* direct disk access - should check with OSF/1 */ #define F_DUPFD0 /* dup */ #define F_GETFD1 /* get close_on_exec */ diff -urN 2.4.6pre3/include/asm-i386/fcntl.h o_direct/include/asm-i386/fcntl.h --- 2.4.6pre3/include/asm-i386/fcntl.h Thu Nov 16 15:37:33 2000 +++ o_direct/include/asm-i386/fcntl.h Thu Jun 14 17:33:41 2001 @@ -16,7 +16,7 @@ #define O_NDELAY O_NONBLOCK #define O_SYNC 01 #define FASYNC 02 /* fcntl, for BSD compatibility */ -#define O_DIRECT04 /* direct disk access hint - currently ignored */ +#define O_DIRECT04 /* direct disk access hint */ #define O_LARGEFILE010 #define O_DIRECTORY020 /* must be a directory */ #define O_NOFOLLOW 040 /* don't follow links */ diff -urN 2.4.6pre3/include/asm-sparc/fcntl.h o_direct/include/asm-sparc/fcntl.h --- 2.4.6pre3/include/asm-sparc/fcntl.h Thu Nov 16 15:37:42 2000 +++ o_direct/include/asm-sparc/fcntl.h Thu Jun 14 17:33:41 2001 @@ -20,6 +20,7 @@ #define O_DIRECTORY0x1 /* must be a directory */ #define O_NOFOLLOW 0x2 /* don't follow links */ #define O_LARGEFILE0x4 +#define O_DIRECT0x10 /* direct disk access hint */ #define F_DUPFD0 /* dup */ #define F_GETFD1 /* get close_on_exec */ diff -urN 2.4.6pre3/include/asm-sparc64/fcntl.h o_direct/include/asm-sparc64/fcntl.h --- 2.4.6pre3/include/asm-sparc64/fcntl.h Thu Nov 16 15:37:42 2000 +++ o_direct/include/asm-sparc64/fcntl.hThu Jun 14 17:33:41 2001 @@ -20,6 +20,8 @@ #define O_DIRECTORY0x1 /* must be a directory */ #define O_NOFOLLOW 0x2 /* don't follow links */ #define O_LARGEFILE0x4 +#define O_DIRECT0x10 /* direct disk access hint */ + #define F_DUPFD0 /* dup */ #define F_GETFD1 /* get close_on_exec */ Here the second patch that defines the PF_ATOMICALLOC (strictly speaking this is not visible from userspace but it also cleanups a bit the definitions). --- atomicalloc/include/linux/sched.h.~1~ Thu Apr 26 02:04:44 2001 +++ atomicalloc/include/linux/sched.h Thu Apr 26 04:05:28 2001 @@ -403,18 +403,15 @@ /* * Per process flags */ -#define PF_ALIGNWARN 0x0001 /* Print alignment warning msgs */ - /* Not implemented yet, only for 486*/ -#define PF_STARTING0x0002 /* being created */ -#define PF_EXITING 0x0004 /* getting shut down */ -#define PF_FORKNOEXEC 0x0040 /* forked but didn't exec */ -#define PF_SUPERPRIV 0x0100 /* used super-user privileges */ -#define PF_DUMPCORE0x0200 /* dumped core */ -#define PF_SIGNALED0x0400 /* killed by a signal */ -#define PF_MEMALLOC0x0800 /* Allocating memory */ -#define PF_VFORK 0x1000 /* Wake up parent in mm_release */ - -#define PF_USEDFPU 0x0010 /* task used FPU this quantum (SMP) */ +#define PF_EXITING (1UL<<0)/* getting shut down */ +#define PF_FORKNOEXEC (1UL<<1)/* forked but didn't exec */ +#define PF_SUPERPRIV (1UL<<2)/* used super-user privileges */ +#define PF_DUMPCORE(1UL<<3)/* dumped core */ +#define PF_SIGNALED
Oops at NFS unmounting
Hi *! I got this Oops at unmounting a already renamed NFS source. The umount got a SEGFAULT. I compiled my 2.4.5 with 2.95.4 20010319 (Debian prerelease). Regards, -Gregor ksymoops 2.4.1 on i686 2.4.5. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.5/ (default) -m /boot/System.map-2.4.5 (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. Warning (compare_maps): snd symbol pm_register not found in /usr/lib/alsa-modules/2.4.5/0.5/snd.o. Ignoring /usr/lib/alsa-modules/2.4.5/0.5/snd.o entry Warning (compare_maps): snd symbol pm_send not found in /usr/lib/alsa-modules/2.4.5/0.5/snd.o. Ignoring /usr/lib/alsa-modules/2.4.5/0.5/snd.o entry Warning (compare_maps): snd symbol pm_unregister not found in /usr/lib/alsa-modules/2.4.5/0.5/snd.o. Ignoring /usr/lib/alsa-modules/2.4.5/0.5/snd.o entry WARNING: USB Mass Storage data integrity not assured kernel BUG at inode.c:486! invalid operand: CPU:0 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010286 eax: 001b ebx: dd3df820 ecx: d9406000 edx: ddd3e560 esi: c022f280 edi: c022f280 ebp: 08054008 esp: d9407f04 ds: 0018 es: 0018 ss: 0018 Process umount (pid: 1551, stackpage=d9407000) Stack: c01f79ac c01f7a0b 01e6 dd3df820 c0140387 dd3df820 c326a7c0 dd3df820 c015399a dd3df820 c013df96 c326a7c0 dd3df820 de260c00 c326a7c0 c013227c c326a7c0 c326a7c0 c3264e20 de260c00 c022e040 08054008 de260c34 c022f30c Call Trace: [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 83 c4 0c f6 83 f4 00 00 00 10 75 19 68 e8 01 00 00 68 >>EIP; c013f9bb<= Trace; c0140387 Trace; c015399a Trace; c013df96 Trace; c013227c Trace; c01316d4 <__mntput+3c/44> Trace; c0136baf Trace; c01326a8 Trace; c01326e0 Trace; c0106a7b Trace; c010002b Code; c013f9bb <_EIP>: Code; c013f9bb<= 0: 0f 0b ud2a <= Code; c013f9bd 2: 83 c4 0c add$0xc,%esp Code; c013f9c0 5: f6 83 f4 00 00 00 10 testb $0x10,0xf4(%ebx) Code; c013f9c7 c: 75 19 jne27 <_EIP+0x27> c013f9e2 Code; c013f9c9 e: 68 e8 01 00 00push $0x1e8 Code; c013f9ce 13: 68 00 00 00 00push $0x0 4 warnings issued. Results may not be reliable.
Re: 2.2.19: eepro100 and cmd_wait issues
On 12 Jun 2001 12:20:58 -0700, Ken Brownfield wrote: > Or you could keep your hardware and try the Intel driver, which seems to > work fine. It only works as a module, though. This might also help > narrow the issue to a driver vs. card vs. mobo/BIOS/IRQ/APIC/etc issue. I did that, and it seems to be the right solution. ;-) No problem until now (i got the old problem at least once every day). Hmmm... Seems like Intel did a good job with this driver... :-) -- Florin Andrei - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.5 kernel crash while using tcpdump+iptraf
> What kind of network card, and what network driver? I've got 3 NICs: ne.c:v1.10 9/23/94 Donald Becker ([EMAIL PROTECTED]) Last modified Nov 1, 2000 by Paul Gortmaker NE*000 ethercard probe at 0x300: 00 c0 df 64 7b d5 eth0: NE2000 found at 0x300, using IRQ 9. NE*000 ethercard probe at 0x340: 00 80 c8 64 df db eth1: NE2000 found at 0x340, using IRQ 5. loop: loaded (max 8 devices) ne2k-pci.c:v1.02 10/19/2000 D. Becker/P. Gortmaker http://www.scyld.com/network/ne2k-pci.html PCI: Found IRQ 12 for device 00:0b.0 eth2: RealTek RTL-8029 found at 0xe400, IRQ 12, 00:C0:F0:2B:C9:AA. I'm not exactly sure what brand the ISA ones are... if it's really relevent I guess I could take the cards out and inspect the chipsets :) Mathew Johnston - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Lockup in 2.4.2 kernel ADSL PCI card ATM driver module
[EMAIL PROTECTED] wrote: > SUBJECT: > Lockup in 2.4.2 kernel ADSL PCI card ATM driver module > > > DRIVER RESULTS: > Works fine in 2.4.0 kernel. > Locks up system (no messages/oops/etc.) in 2.4.2-2 kernel (rh 7.1). > Locks up system (no messages/oops/etc.) in 2.4.2 kernel (w/ or w/o kgdb). > Locks up system with "int 3" ??? message in 2.4.2-ac28 kernel. First, please try with a recent 2.4.5ac kernel - a number of ATM bugfixes have been made recently and they've been merged first with alan's branch. Anyway, there's a chance that you might just be hitting one of those bugs that have already been fixed, so it'd be best to try that first so we can exclude that possibility. > MESSAGE GENERATED IN 2.4.2-ac28: > int 3: > CPU: 0 > EIP: 0010:[] Please read the REPORTING-BUGS and Documentation/oops-tracing.txt files in the linux source tree - especially the parts about using the "ksymoops" tool. These numbers are useless to us unless you run it through that tool first. -Mitch - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.5 kernel on Sparc32
I've seen the exact same problem when trying to compile for sparc. I might try and fix it myself, as it doesn't seemed to be fixed in the vger cvs tree, or any other patch for that matter. Regards, Aaron On Tue, 29 May 2001, John wrote: > Sorry if this is a repeat. Can't find anything on it. My guess is that > I don't know where to look. I am trying to build the 2.4.5 kernel on a > Sparc LX. I get numerous error messages when trying to build the > kernel: > > > > make[1]: Entering directory `/usr/src/linux-2.4.5/mm' > > make all_targets > > make[2]: Entering directory `/usr/src/linux-2.4.5/mm' > > gcc -D__KERNEL__ -I/usr/src/linux-2.4.5/include -Wall -Wstrict-prototypes -O2 >-fomit-frame-pointer -fno-strict-aliasing -m32 -pipe -mno-fpu -fcall-used-g5 >-fcall-used-g7-c -o memory.o memory.c > > memory.c:183: macro `pmd_alloc' used with too many (3) args > > memory.c:204: macro `pte_alloc' used with too many (3) args > > memory.c:725: macro `pte_alloc' used with too many (3) args > > memory.c:750: macro `pmd_alloc' used with too many (3) args > > memory.c:805: macro `pte_alloc' used with too many (3) args > > memory.c:832: macro `pmd_alloc' used with too many (3) args > > memory.c:1339: macro `pmd_alloc' used with too many (3) args > > memory.c:1342: macro `pte_alloc' used with too many (3) args > > memory.c:1392: macro `pte_alloc' used with too many (3) args > > memory.c: In function `copy_page_range': > > memory.c:183: warning: passing arg 1 of `___f_pmd_alloc' from incompatible pointer >type > > memory.c:183: warning: passing arg 2 of `___f_pmd_alloc' makes integer from >pointer without a cast > > memory.c:204: warning: passing arg 1 of `___f_pte_alloc' from incompatible pointer >type > > memory.c:204: warning: passing arg 2 of `___f_pte_alloc' makes integer from >pointer without a cast > > memory.c: In function `zeromap_pmd_range': > > memory.c:725: warning: passing arg 1 of `___f_pte_alloc' from incompatible pointer >type > > memory.c:725: warning: passing arg 2 of `___f_pte_alloc' makes integer from >pointer without a cast > > memory.c: In function `zeromap_page_range': > > memory.c:750: warning: passing arg 1 of `___f_pmd_alloc' from incompatible pointer >type > > memory.c:750: warning: passing arg 2 of `___f_pmd_alloc' makes integer from >pointer without a cast > > memory.c: In function `remap_pmd_range': > > memory.c:805: warning: passing arg 1 of `___f_pte_alloc' from incompatible pointer >type > > memory.c:805: warning: passing arg 2 of `___f_pte_alloc' makes integer from >pointer without a cast > > memory.c: In function `remap_page_range': > > memory.c:832: warning: passing arg 1 of `___f_pmd_alloc' from incompatible pointer >type > > memory.c:832: warning: passing arg 2 of `___f_pmd_alloc' makes integer from >pointer without a cast > > memory.c: In function `handle_mm_fault': > > memory.c:1339: warning: passing arg 1 of `___f_pmd_alloc' from incompatible >pointer type > > memory.c:1339: warning: passing arg 2 of `___f_pmd_alloc' makes integer from >pointer without a cast > > memory.c:1342: warning: passing arg 1 of `___f_pte_alloc' from incompatible >pointer type > > memory.c:1342: warning: passing arg 2 of `___f_pte_alloc' makes integer from >pointer without a cast > > memory.c: In function `__pmd_alloc': > > memory.c:1364: warning: implicit declaration of function `pmd_alloc_one_fast' > > memory.c:1364: warning: assignment makes pointer from integer without a cast > > memory.c:1367: warning: implicit declaration of function `pmd_alloc_one' > > memory.c:1367: warning: assignment makes pointer from integer without a cast > > memory.c:1381: warning: implicit declaration of function `pgd_populate' > > memory.c: At top level: > > memory.c:1393: conflicting types for `___f_pte_alloc' > > /usr/src/linux-2.4.5/include/asm/pgalloc.h:125: previous declaration of >`___f_pte_alloc' > > memory.c: In function `___f_pte_alloc': > > memory.c:1398: warning: implicit declaration of function `pte_alloc_one_fast' > > memory.c:1398: `address' undeclared (first use in this function) > > memory.c:1398: (Each undeclared identifier is reported only once > > memory.c:1398: for each function it appears in.) > > memory.c:1398: warning: assignment makes pointer from integer without a cast > > memory.c:1401: warning: implicit declaration of function `pte_alloc_one' > > memory.c:1401: warning: assignment makes pointer from integer without a cast > > memory.c:1415: warning: implicit declaration of function `pmd_populate' > > make[2]: *** [memory.o] Error 1 > > make[2]: Leaving directory `/usr/src/linux-2.4.5/mm' > > make[1]: *** [first_rule] Error 2 > > make[1]: Leaving directory `/usr/src/linux-2.4.5/mm' > > make: *** [_dir_mm] Error 2 > > > > -- tia > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at
what's the purpose of SYMBOL_NAME()
I'm read Bovet's "Understand the Linux Kernel" and looked at the assembly routine setup_idt... I noticed the assembly has SYMBOL_NAME (its all over the place). This is define in include/linux/linkage.h to just: #define SYMBOL_NAME(X) X (this wasn't in Bovet's book). What's the purpose? marty [EMAIL PROTECTED] Don't confuse education with schooling. Milton Friedman to Yogi Berra - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Lockup in 2.4.2 kernel ADSL PCI card ATM driver module
Kernel community,
Sorry for intrusion, but I could use some guidance and/or direction in
tracking
down the source of a problem. None of the messages I have seen in the
archives quite seem to match this problem (if there is one please let me
know). I am looking for where or how to dig (deeper) to find the source of
the problem (described below).
Please CC me with any responses at
[EMAIL PROTECTED]
Thanks much (in advance of any help),
Dan Davidson
[EMAIL PROTECTED]
Conexant Systems, Inc.
SUBJECT:
Lockup in 2.4.2 kernel ADSL PCI card ATM driver module
DRIVER RESULTS:
Works fine in 2.4.0 kernel.
Locks up system (no messages/oops/etc.) in 2.4.2-2 kernel (rh 7.1).
Locks up system (no messages/oops/etc.) in 2.4.2 kernel (w/ or w/o kgdb).
Locks up system with "int 3" ??? message in 2.4.2-ac28 kernel.
PROBLEM:
We are developing reference design Linux drivers for our PCI ADSL
reference design hardware. We have had drivers working (not crashing
and able to transfer data) for kernel version 2.4.0.
Yet the same source code for the driver, compiled with each kernel
version, (and working fine for 2.4.0 kernel) causes system lockup
on 2.4.2 kernel versions.
The driver is a kernel module ATM driver for a Conexant PCI ADSL card.
SYSTEM:
Dell Dimension XPS 300
Pentium II 300 MHz
128MB RAM
Maxtor 31024H2 (ATA) HD
CDROM (ATAPI)
Iomega Zip100 (ATAPI)
1.44 FD
3COM PCI ethernet
Conexant PCI ADSL
FILES:
Several of the patch files, ".config" files, partial "System.map",
and output of dmesg can be found at "http://home.hiwaay.net/~rss1/linux;
and within the "2.4.0" and "2.4.2" subdirectories and the subdirectories
of "2.4.2" ("2", "ac28", and "kgdb").
2.4.0 KERNEL:
Start with Red Hat Linux 6.2 release.
Upgrade to kernel 2.4.0 (lilo for both 2.2.14-5 and 2.4.0)
applying patches "br2684-001212-against2.4.0.dif" and "atm-hdlc-patch"
and using "config.gz" as ".config".
Build kernel.
Install rpm "modutils-2.4.0-1.i386.rpm".
Install rpm "atm-0.78-1.i386.rpm".
Install Conexant ADSL driver.
2.4.2-2 (rh) KERNEL:
Start with Red Hat Linux 7.1 release.
Apply patches "br2684-001212-against2.4.2.dif" and "atm-hdlc-patch".
Configure kernel for:
code maturity - experimental
loadable module support - enable loadable and kernel module support
networking options - enable ATM and classical IP over ATM
and set to module enable LAN Emulation, multi-protocol over ATM,
and RFC1483/2684 bridged protocols
network device support - module enable PPP and PPPoATM
Build kernel.
Install rpm "atm-0.78-1.i386.rpm".
Install Conexant ADSL driver.
2.4.2-kgdb KERNEL:
Start with Red Hat Linux 7.1 release.
Add kernel 2.4.2 (lilo for both 2.4.2-2 and 2.4.2-kgdb)
Apply patch "linux-2.4.2-kgdb.patch".
Apply patches "br2684-001212-against2.4.2.dif" and "atm-hdlc-patch".
Configure kernel for:
code maturity - experimental
loadable module support - enable loadable and kernel module support
networking options - enable ATM and classical IP over ATM
and set to module enable LAN Emulation, multi-protocol over ATM,
and RFC1483/2684 bridged protocols
network device support - module enable PPP and PPPoATM
Build kernel.
Previously installed rpm "atm-0.78-1.i386.rpm".
Install Conexant ADSL driver.
2.4.2-ac28 KERNEL:
Start with Red Hat Linux 7.1 release.
Add kernel 2.4.2 (lilo for both 2.4.2-2, 2.4.2-kgdb, and 2.4.2-ac28)
Apply patch "patch-2.4.2-ac28".
Apply patches "br2684-001212-against2.4.2.dif" and "atm-hdlc-patch".
Configure kernel for:
code maturity - experimental
loadable module support - enable loadable and kernel module support
networking options - enable ATM and classical IP over ATM
and set to module enable LAN Emulation, multi-protocol over ATM,
and RFC1483/2684 bridged protocols
network device support - module enable PPP and PPPoATM
Build kernel.
Previously installed rpm "atm-0.78-1.i386.rpm".
Install Conexant ADSL driver.
MESSAGE GENERATED IN 2.4.2-ac28:
int 3:
CPU: 0
EIP: 0010:[]
EFLAGS: 0282
eax: c8854780 ebx: ecx: c02873e8 edx: c100df74
esi: edi: ebp: c14e5f28 esp: c14e5f20
Process insmod (pid: 1401, stackpage-c14e5000)
Stack: c884d000 0060 c0114c35 c0349000 000860a0
c034a000
0060 ffea 0007 c6979fdc 0060 c8845000 c884d060
000ae220
Call Trace: [] [] [] []
[] []
Code: 83 ec 0c 68 d0 17 8b c8 e8 e8 f6 8b f7 c7 04 24 00 18 8b c8
make[1]: *** [start] Segmentation fault
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: PPP: VJ uncompressed error
What kernel are you using?? I used to get it after I switced from a Linux-supported winmodem to a hardware modem, but the messages are now mysteriously absent from me logs. If you're running something prior to 2.4.5, I'd say it was fixed there. Also, it could've been fixed in Alan's tree; I'm running 2.4.5-ac2 On Thu, Jun 14, 2001 at 03:55:21PM +0200, Jacek Pop?awski wrote: > I see this message few times daily: > > PPP: VJ uncompressed error > > What does it mean? I searched news archives, HOWTOs, WWW, but only place I found that > string is kernel source. > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- -Steven In a time of universal deceit, telling the truth is a revolutionary act. -- George Orwell - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
