Re: Linux 2.6.22 released
* Linus Torvalds ([EMAIL PROTECTED]) wrote: > But yeah, if Debian/sid is just using random compiler snapshots of the > day, I htink we can just bury this as "pointless". Err, debian/sid *isn't* defaulting to gcc-4.2 yet, but it is made available to people who want to install it and play with it. Additionally, the kernel build is actually tied to a specific compiler (doesn't default to just using whatever the default compiler is) so even when gcc-4.2 is eventually made the default compiler the linux images built for Debian won't use it immediately. That change will be made seperately and after additional testing to make sure it doesn't break the built kernel which is distributed. Thanks, Stephen signature.asc Description: Digital signature
Re: Linux 2.6.22 released
* Linus Torvalds ([EMAIL PROTECTED]) wrote: > I'm hoping your Debian/sid gcc version is some very experimental > known-buggy one, and not something that people _expect_ to be solid and > work well? No such luck. :( Debian's close to moving to gcc-4.2 as the default compiler in sid. We've rebuilt the archive a number of times (both since the 4.2 release and during its development) using gcc-4.2 and thought we'd identified most of the issues with it. It clearly sounds like we need to open a high-severity bug on this issue and track it down before we move to it as the default compiler. I'll start harassing the appropriate folks also. Stefano, can you file that bug, including the config, dmesg, and backtrace from gcc if you can get it? Thanks, Stephen signature.asc Description: Digital signature
Re: OpenAFS gatekeepers request addition of AFS_SUPER_MAGIC to magic.h
* Adam Megacz ([EMAIL PROTECTED]) wrote: > --- include/linux/magic.h 2006-12-29 15:48:50.0 -0800 > +++ include/linux/magic.h 2006-11-29 13:57:37.0 -0800 > @@ -3,7 +3,6 @@ > > #define ADFS_SUPER_MAGIC 0xadf5 > #define AFFS_SUPER_MAGIC 0xadff > -#define AFS_SUPER_MAGIC0x5346414F > #define AUTOFS_SUPER_MAGIC 0x0187 > #define CODA_SUPER_MAGIC 0x73757245 > #define EFS_SUPER_MAGIC0x414A53 Wouldn't you want a patch which *adds* it, rather than one which *removes* it...? Thanks, Stephen signature.asc Description: Digital signature
Re: [git patches] libata fixes
* Jeff Garzik ([EMAIL PROTECTED]) wrote: > FWIW the Tejun cleanups are a fix, split into three reviewable pieces. > > Also, my local iomap branch has advanced sufficiently enough that I > think it's high time to kill those libata warnings that spew on every > build. (I hear the crowds roar) Perhaps I missed it, but, when is PMP support going to be included in main-stream? Seems like it's been around for a while now and I doubt I'm the only one extremely frustrated with having to hunt down an external patch to get a new toy supported. I'll probably bug the Debian kernel folks next but it'd be nicer if it was in upstream. Thanks! Stephen - 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: NCQ support NVidia NForce4 (CK804) SATAII
* Lion Vollnhals ([EMAIL PROTECTED]) wrote: > Am Sonntag, den 14.08.2005, 09:29 -0400 schrieb Willem Riede: > > On Wed, 10 Aug 2005 20:54:35 +, Allen Martin wrote: > > That is disappointing. I was seriously considering a motherboard with your > > chipset because of its impressive specifications, but now I have to > > reconsider (I'm one of those folks that never bought an nVidia graphics > > board due to the lack of open full-function driver). I _hate_ not being > > able to use all features. > > I agree. > > I am considering buying an nForce4 board, too. > But i am discouraged by it's closed source nature. I also agree and am rather disappointed by this news. Unfortunately, I've already bought an A8N-SLI. I've been considering some nvidia-based systems for work though and now plan to ask my vendor (penguincomputing.com in this case) if this will be an issue with their systems or not. Thanks, Stephen signature.asc Description: Digital signature
Re: 10 GB in Opteron machine
* Jakob Oestergaard ([EMAIL PROTECTED]) wrote: > This is really the clever way to run a 64-bit system - 99% of what is > commonly run on most systems only gains overhead from the 64-bit address > space - tools like postfix, cron, syslog, apache, ... will not gain from > being native 64-bit. For most 64-bit systems, sure. For amd64 it's a little different because there are additional changes to the architecture (as compared to ia32/x86) which can more than make up for the difference for many applications. Then there's also things like encryption (postfix/tls, apache/ssl, etc) which can benefit greatly from better handling of 64bit (and larger) types. So, basically, it's not nearly so clear-cut as you portray it. :) > Solaris has done this for ages - maintaining a mostly 32-bit user space, > a 64-bit kernel, and then allowing for certain memory intensive > applications to run natively 64-bit. The differences between a 64bit sparc chip in 32bit and 64bit are quite a bit less than the differences between an amd64 chip in 32bit and 64bit. Thus, this makes alot more sense for sparc. > It's a nice way to run a Linux based system too, IMO. Perhaps on sparc or mips; it's much less clear-cut on amd64. Stephen signature.asc Description: Digital signature
Re: Kernel header policy
* Marc Aurele La France ([EMAIL PROTECTED]) wrote: > To that end, I would propose, as a possible technical solution, extending > the kernel build process to detect these errors during kernel development. Well, couple stupid comments: #1: I'm not *entirely* sure Linus reads every mail to lkml.. Dunno if you also sent it to him directly, but if not then that might explain the lack of response... #2: Have you got a patch that does this? If not, you might want to write one up and just submit it.. If you're expecting someone else to write it, well, that might also be why you've not had much response... :) Thanks, Stephen signature.asc Description: Digital signature
Re: [PATCH] dynamic tick patch
* Benjamin Herrenschmidt ([EMAIL PROTECTED]) wrote: > Hrm... reading more of the patch & Martin's previous work, I'm not sure > I like the idea too much in the end... The main problem is that you are > just "replaying" the ticks afterward, which I see as a problem for > things like sched_clock() which returns the real current time, no ? > > I'll toy a bit with my own implementation directly using Martin's work > and see what kind of improvement I really get on ppc laptops. I don't know if this is the same thing, or the same issue, but I've noticed on my Windows machines that the longer my laptop sleeps the longer it takes for it to wake back up- my guess is that it's doing exactly this (replaying ticks). It *really* sucks though because it can take quite a while for it to come back if it's been asleep for a while. Stephen signature.asc Description: Digital signature
Re: rsync hangs on RedHat 2.4.2 or stock 2.4.4
* David S. Miller ([EMAIL PROTECTED]) wrote: > > Russell King writes: > > At the time I suggested it was because of a missing wakeup in 2.4.2 kernels, > > but I was shouted down for using 2.2.15pre13. Since then I've seen these > > reports appear on lkml several times, each time without a solution nor > > explaination. > > > > Oh, and yes, we're still using the same setup here at work, and its running > > fine now - no rsync lockups. I'm not sure why that is. ;( > > Look everyone, it was determined to be a deadlock because of some > interaction between how rsync sets up it's communication channels > with the ssh subprocess, readas: userland bug. > > I don't remember if the specific problem was in rsync itself or some > buggy version of ssh. One can search the list archives to discover > Alexey's full analysis of the problem. I don't have a URL handy. I have to say I find this likely to be the case for those who are having issues with rsync over ssh. I was recently playing with rsync over ssh (newer openssh to older openssh) and was just using it as a pass-through to another machine. When I replaced ssh with rinetd, everything worked fine. I havn't had a chance yet (though I'd like to) to try with two recent versions of ssh but I'm curious what the result will be. It may be that the problem has been fixed in later versions of ssh. Stephen PGP signature
'spurious APIC interrupt' - Dell PowerEdge 1400
Running into a problem with one of our Dell PowerEdge 1400 servers. We see these messages very rarely, but after they show up the machine goes into a really odd state: Mar 26 09:37:27 maul kernel: spurious APIC interrupt on CPU#1, should never happen. Mar 26 09:37:27 maul kernel: unexpected IRQ vector 216 on CPU#1! Basically things seem to only kinda work. My guess is that possibly one of the CPUs has been shut down or similar and so half the processes are getting kind of 'stuck'. Any thoughts? dmesg follows, more information availible upon request, thanks! Stephen --- ===# dmesg Linux version 2.2.18-raid-mosix (bma@black) (gcc version 2.95.2 2220 (Debian GNU/Linux)) #2 SMP Tue Jan 2 12:40:13 EST 2001 Intel MultiProcessor Specification v1.4 Virtual Wire compatibility mode. OEM ID: DELL Product ID: POWEREDGE CE APIC at: 0xFEE0 Processor #1 Pentium(tm) Pro APIC version 17 Processor #0 Pentium(tm) Pro APIC version 17 I/O APIC #2 Version 17 at 0xFEC0. I/O APIC #3 Version 17 at 0xFEC01000. Processors: 2 mapped APIC to e000 (fee0) mapped IOAPIC to d000 (fec0) mapped IOAPIC to c000 (fec01000) Detected 794719 kHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 1585.97 BogoMIPS Memory: 1034844k/1048512k available (1512k kernel code, 424k reserved, 11676k data, 56k init) Dentry hash table entries: 131072 (order 8, 1024k) Buffer cache hash table entries: 524288 (order 9, 2048k) Page cache hash table entries: 262144 (order 8, 1024k) 256K L2 cache (8 way) CPU: L2 Cache: 256K Checking 386/387 coupling... OK, FPU using exception 16 error reporting. Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.35a (19990819) Richard Gooch ([EMAIL PROTECTED]) Intel machine check architecture supported. Intel machine check reporting enabled on CPU#1. 256K L2 cache (8 way) CPU: L2 Cache: 256K per-CPU timeslice cutoff: 50.03 usecs. CPU1: Intel Pentium III (Coppermine) stepping 06 calibrating APIC timer ... . CPU clock speed is 794.6271 MHz. . system bus clock speed is 132.4377 MHz. Booting processor 0 eip 2000 Calibrating delay loop... 1585.97 BogoMIPS Intel machine check reporting enabled on CPU#0. 256K L2 cache (8 way) CPU: L2 Cache: 256K OK. CPU0: Intel Pentium III (Coppermine) stepping 06 Total of 2 processors activated (3171.94 BogoMIPS). enabling symmetric IO mode... ...done. ENABLING IO-APIC IRQs ...changing IO-APIC physical APIC ID to 2 ...changing IO-APIC physical APIC ID to 3 init IO_APIC IRQs IO-APIC (apicid-pin) 2-0, 2-2, 2-5, 2-11, 2-13WARNING: ASSIGN_IRQ_VECTOR wrapped back to 52 , 3-13 not connected. ...trying to set up timer as ExtINT... .. (found pin 0) ... works. number of MP IRQ sources: 39. number of IO-APIC #2 registers: 16. number of IO-APIC #3 registers: 16. testing the IO APIC... IO APIC #2.. register #00: 0200 ...: physical APIC id: 02 register #01: 000F0011 ... : max redirection entries: 000F ... : IO APIC version: 0011 register #02: ... : arbitration: 00 IRQ redirection table: NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect: 00 001 01 000 0 00751 01 000 00 000 0 01159 02 000 00 100 0 00000 03 000 00 000 0 01161 04 000 00 000 0 01169 05 000 00 100 0 00000 06 000 00 000 0 01171 07 000 00 000 0 01179 08 000 00 000 0 01181 09 000 00 000 0 01189 0a 0FF 0F 110 1 01191 0b 000 00 100 0 00000 0c 000 00 000 0 01199 0d 000 00 100 0 00000 0e 000 00 000 0 011A1 0f 000 00 000 0 011A9 IO APIC #3.. register #00: 0300 ...: physical APIC id: 03 register #01: 000F0011 ... : max redirection entries: 000F ... : IO APIC version: 0011 register #02: 0E00 ... : arbitration: 0E IRQ redirection table: NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect: 00 0FF 0F 110 1 011B1 01 0FF 0F 110 1 011B9 02 0FF 0F 110 1 011C1 03 0FF 0F 110 1 011C9 04 0FF 0F 110 1 011D1 05 0FF 0F 110 1 011D9 06 0FF 0F 110 1 011E1 07 0FF 0F 110 1 011E9 08 0FF 0F 110 1 011F1 09 0FF 0F 110 1 011F9 0a 0FF 0F 110 1 01152 0b 0FF 0F 110 1 0115A 0c 0FF 0F 110 1 01162 0d 000 00 100 0 0
Re: Linux stifles innovation...
* fsnchzjr ([EMAIL PROTECTED]) wrote: > Watch Microsoft's Jim Allchin go Linux-bashing!!! > Nice little article on how we're all going to die of herpes from our > repeated exposition to Linux... > http://news.cnet.com/investor/news/newsitem/0-9900-1028-4825719-RHAT.html?tag=ltnc Just remember, the tag is 'ltnc' --> 'long-time, no clue'. Stephen PGP signature
Re: 2.4.x and SMP fails to compile (`current' undefined)
* David Ford ([EMAIL PROTECTED]) wrote: > A person just brought up a problem in #kernelnewbies, building an SMP > kernel doesn't work very well, current is undefined. I don't have more > time to debug it but I'll strip the config and put it up at > http://stuph.org/smp-config They're trying to compile SMP for Athlon/K7 (CONFIG_MK7=y). Stephen PGP signature
Re: Updated zerocopy patches on kernel.org
* David S. Miller ([EMAIL PROTECTED]) wrote: > > Now against 2.4.1-pre2: > > ftp.kernel.org:/pub/linux/kernel/people/davem/zerocopy-2.4.1p2-1.diff.gz Tried it with 2.4.1-pre3, didn't have any problem applying it, but when I rebooted the system it pretty much had no interest in talking TCP to anything. 2.4.1-pre3 alone has no problem. Should I give 2.4.1p2 a try with the zerocopy patch? I think that's my next step, but if it isn't likely to change anything.. The problem tended to be that a connection could reach the 'ESTABLISHED' point (in netstat), but then very little data would pass over the connection. ie; 'telnet somehost 25' would give me the SMTP HELO statement, but nothing I typed seemed to make it anywhere. Inbound and outbound ssh connections would reach 'ESTABLISHED', but then wouldn't make it to the point of prompting me for a password. Nothing apparent in any log files or anything. Info attached, more availible upon request. Stephen Linux version 2.4.1-pre2 (root@gw2-snowman) (gcc version 2.95.3 20010111 (prerelease)) #1 SMP Mon Jan 15 12:59:07 EST 2001 BIOS-provided physical RAM map: BIOS-e820: 0009fc00 @ (usable) BIOS-e820: 0400 @ 0009fc00 (reserved) BIOS-e820: 0001 @ 000f (reserved) BIOS-e820: 0feec000 @ 0010 (usable) BIOS-e820: 3000 @ 0ffec000 (ACPI data) BIOS-e820: 0001 @ 0ffef000 (reserved) BIOS-e820: 1000 @ 0000 (ACPI NVS) BIOS-e820: 0001 @ (reserved) Scan SMP from c000 for 1024 bytes. Scan SMP from c009fc00 for 1024 bytes. Scan SMP from c00f for 65536 bytes. Scan SMP from c009fc00 for 4096 bytes. On node 0 totalpages: 65516 zone(0): 4096 pages. zone(1): 61420 pages. zone(2): 0 pages. mapped APIC to e000 (01444000) Kernel command line: auto BOOT_IMAGE=Linux ro root=301 Initializing CPU#0 Detected 655.851 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 1307.44 BogoMIPS Memory: 255292k/262064k available (1062k kernel code, 6384k reserved, 429k data, 200k init, 0k highmem) Dentry-cache hash table entries: 32768 (order: 6, 262144 bytes) Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes) Page-cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 16384 (order: 5, 131072 bytes) CPU: Before vendor init, caps: 0183f9ff c1c7f9ff , vendor = 2 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 64K (64 bytes/line) CPU: After vendor init, caps: 0183f9ff c1c7f9ff CPU: After generic, caps: 0183f9ff c1c7f9ff CPU: Common caps: 0183f9ff c1c7f9ff Enabling fast FPU save and restore... done. Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX CPU: Before vendor init, caps: 0183f9ff c1c7f9ff , vendor = 2 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 64K (64 bytes/line) CPU: After vendor init, caps: 0183f9ff c1c7f9ff CPU: After generic, caps: 0183f9ff c1c7f9ff CPU: Common caps: 0183f9ff c1c7f9ff CPU0: AMD Athlon(tm) Processor stepping 00 per-CPU timeslice cutoff: 182.95 usecs. SMP motherboard not detected. Using dummy APIC emulation. Setting commenced=1, go go go PCI: PCI BIOS revision 2.10 entry at 0xf1010, last bus=1 PCI: Using configuration type 1 PCI: Probing PCI hardware Unknown bridge resource 0: assuming transparent Unknown bridge resource 1: assuming transparent Unknown bridge resource 2: assuming transparent PCI: Using IRQ router VIA [1106/0686] at 00:04.0 isapnp: Scanning for Pnp cards... isapnp: No Plug & Play device found Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket DMI 2.3 present. 49 structures occupying 1371 bytes. DMI table at 0x000F27D0. BIOS Vendor: Award Software, Inc. BIOS Version: ASUS A7V ACPI BIOS Revision 1003 BIOS Release: 07/21/2000 System Vendor: System Manufacturer. Product Name: System Name. Version System Version. Serial Number SYS-1234567890. Board Vendor: ASUSTeK Computer INC.. Board Name: . Board Version: REV 1.xx. Asset Tag: Asset-1234567890. Starting kswapd v1.8 pty: 256 Unix98 ptys configured RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize loop: enabling 8 loop devices Uniform Multi-Platform E-IDE driver Revision: 6.31 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx VP_IDE: IDE controller on PCI bus 00 dev 21 VP_IDE: chipset revision 16 VP_IDE: not 100% native mode: will probe irqs later ide0: BM-DMA at 0xd800-0xd807, BIOS settings: hda:DMA, hdb:pio ide1: BM-DMA at 0xd808-0xd80f, BIOS settings: hdc:pio, hdd:pio PDC20265: IDE controller on PCI bus 00 dev 88 PCI: Found IRQ 10 for device 00:11.0 PDC20265: chipset revision 2 PDC202
Re: [PLEASE-TESTME] Zerocopy networking patch, 2.4.0-1
* Ingo Molnar ([EMAIL PROTECTED]) wrote: > > On Tue, 9 Jan 2001, Stephen Frost wrote: > > > Now, the interesting bit here is that the processes can grow to be > > pretty large (200M+, up as high as 500M, higher if we let it ;) ) and what > > happens with MOSIX is that entire processes get sent over the wire to > > other machines for work. MOSIX will also attempt to rebalance the load on > > all of the machines in the cluster and whatnot so it can often be moving > > processes back and forth. > > then you'll love the zerocopy patch :-) Just use sendfile() or specify > MSG_NOCOPY to sendmsg(), and you'll see effective memory-to-card > DMA-and-checksumming on cards that support it. Excellent, this patch certainly sounds interesting which is why I've been following this discussion. Once the MOSIX patch for 2.4 comes out I think I'm going to tinker with this and see if I can get MOSIX to use these methods. > the discussion with Stephen is about various device-to-device schemes. > (which Mosix i dont think wants to use. Mosix wants to use memory to > device zero-copy, right?) Yes, very much so actually now that I think about it. Alot of memory->device and device->memory work going on. I was mainly replying to the idea of clustering since that's what MOSIX is all about. Stephen PGP signature
Re: [PLEASE-TESTME] Zerocopy networking patch, 2.4.0-1
* Ingo Molnar ([EMAIL PROTECTED]) wrote: > > On Tue, 9 Jan 2001, Stephen C. Tweedie wrote: > > > but it just doesn't apply when you look at some other applications, > > such as streaming out video data or performing fileserving in a > > high-performance compute cluster where you are serving bulk data. > > The multimedia and HPC worlds typically operate on datasets which are > > far too large to cache, so you want to keep them in memory as little > > as possible when you ship them over the wire. > > i'd love to first see these kinds of applications (under Linux) before > designing for them. Eg. if an IO operation (eg. streaming video webcast) > does a DMA from a camera card to an outgoing networking card, would it be > possible to access the packet data in case of a TCP retransmit? Basically > these applications are limited enough in scope to justify even temporary > 'hacks' that enable them - and once we *see* things in action, we could > design for them. Not the other way around. Well, I know I for one use a system that you might have heard of called 'MOSIX'. It's a (kinda large) kernel patch with some user-space tools but allows for migration of processes between machines without modifying any code. There are some limitations (threaded applications and shared memory and whatnot) but it works very well for the rendering work we use it for. We use radiance which in general has pretty little inter- process communication and what it has is done through the filesystem. Now, the interesting bit here is that the processes can grow to be pretty large (200M+, up as high as 500M, higher if we let it ;) ) and what happens with MOSIX is that entire processes get sent over the wire to other machines for work. MOSIX will also attempt to rebalance the load on all of the machines in the cluster and whatnot so it can often be moving processes back and forth. So, anyhow, this is just an fyi if you weren't aware of it that I believe more than a few people are using MOSIX these days for similar appliactions and that it's availible at http://www.mosix.org if you're curious. Stephen PGP signature
Re: [PLEASE-TESTME] Zerocopy networking patch, 2.4.0-1
* Jes Sorensen ([EMAIL PROTECTED]) wrote: > > "David" == David S Miller <[EMAIL PROTECTED]> writes: > > I don't question Alexey's skills and I have no intentions of working > against him. All I am asking is that someone lets me know if they make > major changes to my code so I can keep track of whats happening. It is > really hard to maintain code if you work on major changes while > someone else branches off in a different direction without you > knowing. It's simply a waste of everybody's time. Perhaps you missed it, but I believe Dave's intent is for this to only be a proof-of-concept idea at this time. These changes are not currently up for inclusion into the mainstream kernel. I can not think that Dave would ever just step around a maintainer and submit a patch to Linus for large changes. If many people test these and things work out well for them then I'm sure Dave will go back to the maintainers with the code and the api and work with them to get it into the mainstream kernel. Soliciting ideas and suggestions on how to improve the api and the code paths in the drivers to handle this new method most effectively. Stephen PGP signature
Re: test13-pre1 changelog
* Oliver Xymoron ([EMAIL PROTECTED]) wrote: > On Thu, 14 Dec 2000, Linus Torvalds wrote: > > > A 100ms delay sounds like some interrupt shut up or similar (and then > > timer handling makes it limp along). > > Possibly related datapoint: after several days of uptime, my > 2.4.0-test10pre? machine went into some sort of slow mode after coming > back from suspend (and doing an /etc/init.d/networking restart). Symptoms > seemed to be extra second or so setting up a TCP connection. Ping, etc., > appeared to work just fine, no packet loss apparent, bandwidth looked good > too. Sadly I had to do actual work that required zippy web access, so I > rebooted rather than doing a thorough diagnostic. This is a VAIO with > compiled in eepro100, no special networking options. Actually, I figured out what it was and I feel kind of stupid, and suprised. I knew I should have tried rebooting before complaining. It turns out it actually was something in my firewall rules, it appears that for every logged packet there is something along the lines of a 100ms delay that gets added on. Not sure if that is something that could be easily fixed or not, or perhaps I'm doing something wrong, but that seems unlikely since all I changed was if it jumped to the LOG chain or not. Stephen PGP signature
Re: test13-pre1 changelog
* Linus Torvalds ([EMAIL PROTECTED]) wrote: > > > On Thu, 14 Dec 2000, Stephen Frost wrote: > > > > This go around I compiled everything into the kernel, actually. > > If it would be useful I can compile them as modules reboot and then see > > what happens... > > Even when compiled into the kernel, you might just ifdown/ifup the device. > That will re-initialize most of the driver state. I'll give that a shot... ifdown -a/ifup -a, no change in behaviour. > Is this ppp over serial.c, or what? There is a ppp connection, but the slowdown is on *all* interfaces, of which there are a total of 4; eth0, eth1, eth2, ppp0. Stephen PGP signature
Re: test13-pre1 changelog
* Linus Torvalds ([EMAIL PROTECTED]) wrote: > > > On Thu, 14 Dec 2000, Stephen Frost wrote: > > > > Any idea if these issues would cause a general slow-down of a > > machine? For no apparent reason after 5 days running 2.4.0test12 > > everything going through my firewall (set up using iptables) I got about > > 100ms time added on to pings and traceroutes. > > Probably not related to that particular bug - the netfilter issue has > apparently been around forever, and it was just some changes in IP > fragmentation that just made it show up as an oops. > > A 100ms delay sounds like some interrupt shut up or similar (and then > timer handling makes it limp along). Hmm, it's happening on all interfaces. No oops or anything in the logs/dmesg. I can check console when I get home, but I doubt there's anything of interest. All cards are 3com 3c905's. Does this info help any? ===# cat /proc/interrupts CPU0 CPU1 0: 29170703 23315160IO-APIC-edge timer 1: 2 0IO-APIC-edge keyboard 2: 0 0 XT-PIC cascade 3: 258815 247131IO-APIC-edge serial 4:101120IO-APIC-edge serial 5:17480961692143 IO-APIC-level usb-uhci, eth0 8: 1 0IO-APIC-edge rtc 10:11992271146776 IO-APIC-level eth2 12:23672392389531 IO-APIC-level eth1 14: 210804 193050IO-APIC-edge ide0 15: 7052 6391IO-APIC-edge ide1 NMI: 52509191 52509191 LOC: 52472090 52472489 ERR: 0 ===# sleep 10 ===# cat /proc/interrupts CPU0 CPU1 0: 29171536 23315741IO-APIC-edge timer 1: 2 0IO-APIC-edge keyboard 2: 0 0 XT-PIC cascade 3: 258818 247134IO-APIC-edge serial 4:101120IO-APIC-edge serial 5:17482951692372 IO-APIC-level usb-uhci, eth0 8: 1 0IO-APIC-edge rtc 10:11992301146777 IO-APIC-level eth2 12:23672442389534 IO-APIC-level eth1 14: 210833 193050IO-APIC-edge ide0 15: 7052 6391IO-APIC-edge ide1 NMI: 52510605 52510605 LOC: 52473504 52473902 ERR: 0 ===# Boot log: Linux version 2.4.0-test12 (root@whitegryphon) (gcc version 2.95.2 2220 (Debian GNU/Linux)) #1 SMP Wed Dec 6 01:53:29 EST 2000 BIOS-provided physical RAM map: BIOS-e820: 000a @ (usable) BIOS-e820: 0001 @ 000f (reserved) BIOS-e820: 0fefd000 @ 0010 (usable) BIOS-e820: 2000 @ 0fffd000 (ACPI data) BIOS-e820: 1000 @ 0000 (ACPI NVS) BIOS-e820: 1000 @ fec0 (reserved) BIOS-e820: 1000 @ fee0 (reserved) BIOS-e820: 0001 @ (reserved) Scan SMP from c000 for 1024 bytes. Scan SMP from c009fc00 for 1024 bytes. Scan SMP from c00f for 65536 bytes. found SMP MP-table at 000f6e80 hm, page 000f6000 reserved twice. hm, page 000f7000 reserved twice. hm, page 000f6000 reserved twice. hm, page 000f7000 reserved twice. On node 0 totalpages: 65533 zone(0): 4096 pages. zone(1): 61437 pages. zone(2): 0 pages. Intel MultiProcessor Specification v1.1 Virtual Wire compatibility mode. OEM ID: OEM0 Product ID: PROD APIC at: 0xFEE0 Processor #1 Pentium(tm) Pro APIC version 17 Floating point unit present. Machine Exception supported. 64 bit compare & exchange supported. Internal APIC present. SEP present. MTRR present. PGE present. MCA present. CMOV present. PAT present. PSE present. MMX present. FXSR present. Bootup CPU Processor #0 Pentium(tm) Pro APIC version 17 Floating point unit present. Machine Exception supported. 64 bit compare & exchange supported. Internal APIC present. SEP present. MTRR present. PGE present. MCA present. CMOV present. PAT present. PSE present. MMX present. FXSR present. Bus #0 is PCI Bus #1 is ISA I/O APIC #2 Version 17 at 0xFEC0. Int: type 3, pol 0, trig 0, bus 1, IRQ 00, APIC ID 2, APIC INT 00 Int: type 0, pol 0, trig 0, bus 1, IRQ 01, APIC ID 2, APIC INT 01 Int: type 0, pol 0, trig 0, bus 1, IRQ 00, APIC ID 2, APIC INT 02 Int: type 0, pol 0, trig 0, bus 1, IRQ 03, APIC ID 2, APIC INT 03 Int: type 0, pol 0, trig 0, bus 1, IRQ 04, APIC ID 2, APIC INT 04 Int: type 0, pol 0, trig 0, bus 1, IRQ 06, APIC ID 2, APIC INT 06 Int: type 0, pol 0, trig 0, bus 1, IRQ 07, APIC ID 2, APIC INT 07 Int: type 0, pol 0, trig 0, bus 1, IRQ 08, APIC ID 2, APIC INT 08 Int: type 0, pol 0, trig 0, bus 1, IRQ 09, APIC ID 2, APIC INT 09 Int: type 0, pol 0, trig 0, bus 1, IRQ 0e, APIC ID 2, APIC INT 0e
Re: test13-pre1 changelog
* Alan Cox ([EMAIL PROTECTED]) wrote: > > machine? For no apparent reason after 5 days running 2.4.0test12 > > everything going through my firewall (set up using iptables) I got about > > 100ms time added on to pings and traceroutes. I'll probably reboot the > > machine tonight and see if that helps. > > Before you do that can you see if ifconfig down, rmmod, insmod, ifconfig up > fixes it. This go around I compiled everything into the kernel, actually. If it would be useful I can compile them as modules reboot and then see what happens... ===# cat /proc/modules ppp_deflate39200 0 (autoclean) bsd_comp4160 0 (autoclean) ppp_async 6512 1 (autoclean) ppp_generic15232 3 (autoclean) [ppp_deflate bsd_comp ppp_async] slhc4528 0 (autoclean) [ppp_generic] ===# I can say that cleaning out all my firewall rules and adding them back didn't change behaviour any. Also, I'm sure that this was not happening until today or maybe yesterday. Earlier in the week the machine was doing fine and I was getting reasonable response times. Now, out *every* interface, I get something close to 100ms additional time. Also of note, traceroutes appear to be more lagged than pings, for what that's worth (traceroute using udp, ping using icmp, dunno if it makes a difference). Stephen PGP signature
Re: test13-pre1 changelog
* Linus Torvalds ([EMAIL PROTECTED]) wrote: > > Especially if we get that netfilter problem sorted out (see the other > thread about the IP fragmentation issues associated with that one), and > if we figure out why apparently some people have trouble with external > modules (at least one person has trouble with loading alsa modules). Any idea if these issues would cause a general slow-down of a machine? For no apparent reason after 5 days running 2.4.0test12 everything going through my firewall (set up using iptables) I got about 100ms time added on to pings and traceroutes. I'll probably reboot the machine tonight and see if that helps. Stephen PGP signature
Re: 2.2.17 & Eepro(10)
* Jeroen Geusebroek ([EMAIL PROTECTED]) wrote: > > I'm having troubles with the eepro driver included in kernel 2.2.17. > It stops sometimes with no apparent reason. The one thing i noticed > is that it seems to have a lot of carrier problems(998!) > > This is part of the result from ifconfig: > > eth1 Link encap:Ethernet HWaddr 00:AA:00:A6:05:01 > inet addr:24.132.xx.xxx Bcast:24.132.xx.xxx Mask:255.255.254.0 > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:248714 errors:0 dropped:0 overruns:0 frame:0 > TX packets:64711 errors:1925 dropped:0 overruns:0 carrier:998 > collisions:832 txqueuelen:100 > Interrupt:10 Base address:0x230 I have similar problems, though I don't have any carrier problems: eth0 Link encap:Ethernet HWaddr 00:A0:C9:66:12:9B inet addr:xx.xx.xx.xx Bcast:xx.xx.xx.xx Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:214835 errors:0 dropped:0 overruns:0 frame:0 TX packets:33050 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 Interrupt:9 Base address:0xe0e0 Seems to just drop out when there hasn't been any activity for a while for me though. Give it about 10-15 seconds and it comes back. > Needless to say i didn't have this problem with previous kernels > (including 2.2.16). Linux junior 2.2.17-raid #1 Wed Nov 8 07:48:57 EST 2000 i686 unknown I didn't run this machine very long w/ 2.2.16 so I don't really know if previous versions had the same problem. If I have some time, perhaps over the weekend, I'll try and find out. Stephen PGP signature
Re: 32-bit pid_t / security
* Andries Brouwer ([EMAIL PROTECTED]) wrote: > So, in the long run we want a large pid_t. What about the short run? > For today the disadvantages are negligeable, and for people who > like security there are definite advantages. Much more the problem is giving people the *impression* of actual security advantage. > David, I already said the same to someone else: > Security is not a yes/no matter. It is a matter of less or more. > Thus, "Hoping for security" is meaningless. > But "Hoping for more security by having more PID's" is quite > reasonable. If I am local user on your system then I can break in > using a wraparound. If that takes 2147483647 processes I have to > wait longer than when that takes 32000 processes. Yes, it does, but it doesn't increase security signifigantly. Trying to claim it does just seems completely nutty. There are certainly other reasons for a larger pid, and personally I would find it reasonable for it to be a config option, but if someone came up to me and said I should be using 32bit pids because it's more secure than 15bit pids I'd laugh at them. So, how about a patch that adds it in as a config option with an appropriate default? My personal feeling is that the default should be 15bit because it's what is currently used and has no chance of breaking anything. Admittedly, nothing *should* break w/ 32bit pids, but then reality steps in. Would be nice to see what does break. Stephen PGP signature
Re: Linux kernel modules development in C++
* Igmar Palsenberg ([EMAIL PROTECTED]) wrote: > > Tell my teacher it's a good idea, he is telling otherwise :) Academics and reality don't tend to equate. :) Something to do with the world not exactly being perfect. The reality is, if you hadn't guessed, Linux is doing rather well. :) Stephen PGP signature
Re: eepro100 trouble
* Admin Mailing Lists ([EMAIL PROTECTED]) wrote: > On Tue, 5 Sep 2000, Andrey Savochkin wrote: > > > On Sun, Sep 03, 2000 at 02:57:54PM -0300, Cesar Eduardo Barros wrote: > > > > > > I'm having endless problem with an eepro100 here. After some trying found out > > > that doing a soft reset (ctrl+alt+del) fixed the problem, and that a power > > > cycle made it happen again. > > > > > > Kernel version is 2.2.17pre20 > > > > The problem you faced is a known one. > > But I expected 2.2.17pre20 to work, it contains a work-around which helped > > all other people complaining about the same things. > > is it fixed in 2.2.17 final or any of the 2.2.18 releases? My eepro100 has > been working fine (i'm in 2.2.15pre18) and i'm planning to upgarde to > 2.2.17. Wondering if it's a longstanding problem or a NEW one. In 2.2.17pre20 I started running into *really* annoying issues w/ an eepro100, I'm going to go back to 2.2.16 and see if they clear up. Basically things were constantly seeming to stall for me. Not everything though, it seemed like larger things would whereas smaller things wouldn't, but only sometimes. :) Examples: dmesg consistantly would stall ps awux had no real issues (small process list) top worked okay switching between windows under screen quickly would stall it grabbing kernel source wasn't a problem scp'ing a couple >1M files wasn't an issue Very odd. Never had any problems w/ eepro100's under 2.2.16 or earlier. Stephen PGP signature
