Re: /proc/config idea
Jeff Garzik wrote: > Jeremy Jackson wrote: > > Yes, I like this. I do this manually, it allows reproducability, and > > incremental > > modifications, tracing how that kernel on that problem system was made... > > > > I think the ultimate would be to put all of .config (gzipped?) in a new ELF > > section without the Loadable attribute... I wish System.map was the same. > > The you're guaranteed you know how a kernel on disk was configured. > > > > To correlate a running kernel to one on disk (vmlinuz) you have LILO... > > it appends an environment variable to the kernel command line with > > the name of the file it booted. This is not infallable, since LILO maps > > disk sectors, only using the filesystem at map install time. > > > > Permaps an md5sum of the .text ELF section would conclusively > > link the in-core kernel with an on-disk vmlinuz? Shouldn't be hard > > to do with objcopy and /proc/kmem? > [...] > > Comments anyone? > > Instead of doing all this stuff in the kernel, you could simply update > symlinks to properly installed files at boot time. > > Putting _files_ in the kernel is plain silly. This is unreclaimable not in the kernel in an ELF section, marked not loadable. it never leaves the disk. as someone else posted, it's ~900 bytes gzipped (if you want to have it in core) unfortunately (in the LILO case) x86 doesn't boot an ELF image... (oops) > > memory, folks. There is no need to special case an operation as simple If you have a lot of kernels around, which Config-2.4.3 applies to kernel 2.4.3 given 5 to choose from...the idea (same for System.map) is that it being in the same file they can't be confused. Kinda like forks under Mac (but let's not go there now) > > as reading a file. [I think this about firmware images too, but that's > another thread] - 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: /proc/config idea
Alan Cox wrote: > > a module for 2.4.3 will work for any 2.4.3 kernel that supports modules > > at all (except for the SMP vs UP issue) so it's not the same thing as > > trying to figure out which if the 2.4.3 kernels matches what you are > > running. > > Nope. The 2.4 kernel ABI depends upon a mixture of config options including the > cpu type, as well as the compiler version being used. The API is intended to > be constant throughout 2.4 (but isnt yet totally solid due to bug fixing > activity). We don't care about the ABI because we are source code based > Is it possible to identify *all* the dependencies and include symbols (or by some other method) have these dependencies checked by insmod? It would be simply smashing to have it all inherently bullet proof. (i know never say never, but lower maintenance then or simpler for users or something) - 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/
Userspace TCP sequence number control?
Hello, If there's a forum more specifically dedicated to 2.4 networking, please point me in the right direction, otherwise please consider the following. (I'm on lkml so you don't need to CC: me) Is there a way to set the sequence number sent in the SYN response to an incoming connnection request (an incoming SYN) to a specific value with listen()? It may sound like a security risk, but consider the problem of trying to do http load balancing using 2.4 netfilter, (ie in kernel, packet/conntrack-based) but trying to maintain session affinity to a specific backend server. Clearly, the load balancer must open a http (and thus TCP) connection to determine the client that is connecting, in order to determine which back-end server is already servicing the user session. Typically, from this point on, the load balancer must just copy the data back and forth between the socket connected to the client and another socket. This could be userspace or kernelspace, but it's copying either way. What if the connection could be handed off via DNAT *after* it had been established? The load balancer could establish a connection with the backend server, posing as the client, setup an iptable entry directing the client connection's packets to the backend server, then close it's connection (somehow without sending FIN)... the (big) part missing is that the backend server's sequence number will differ from the one used by the load-balancer. (whereas the load balancer can just copy the last sequence number recieved by the client) Does this functionality exist already? Or can iptables re-write the sequence numbers ? (Cisco's PIX does this to re-randomize them for hosts inside firewall that have poor random number generation) Am I talking crazy talk already? (I know I should research the tunneling method more) Regards, Jeremy - 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: Zero Copy IO
Douglas Gilbert wrote: > "Alex Q Chen" <[EMAIL PROTECTED]> wrote: > > > I am trying to find a way to pin down user space > > memory from kernel, so that these user space buffer > > can be used for direct IO transfer or otherwise > > known as "zero copying IO". Searching through the > > Internet and reading comments on various news groups, > > it would appear that most developers including Linus > > himself doesn't believe in the benefit of "zero > > copying IO". Most of the discussion however was based > > on network card drivers. For certain other drivers > > such as SCSI Tape driver, which need to handle great > > deal of data transfer, it would seemed still be more > > advantageous to enable zero copy IO than copy_from_user() > > and copy_to_user() all the data. Other OS such as AIX > > and OS2 have kernel functions that can be used to > > accomplish such a task. Has any ground work been done > > in Linux 2.4 to enable "zero copying IO"? > > Alex, > The kiobufs mechanism in the 2.4 series is the appropriate > tool for avoiding copy_from_user() and copy_to_user(). > The definitive driver is in drivers/char/raw.c which > does synchronous IO to block devices such as disks > (but is probably not appropriate for tapes). > > The SCSI generic (sg) driver supports direct IO. The driver > in lk 2.4.3 has the direct IO code commented out while > a version that I'm currently testing (sg 3.1.18 at > www.torque.net/sg) has its direct IO code activated. I have > a web page comparing throughput times and CPU utilizations > at http://www.torque.net/sg/rbuf_tbl.html . My testing > indicates that the kiobufs mechanism is now working > quite well. For various reasons I still think that it > is best to default to indirect IO and let speed hungry > users enable dio (which is done in sg via procfs). Even > when the user selects direct IO is should be possible to > fall back to indirect IO. [Sg does this when a SCSI > adapter can't support direct IO (e.g. an ISA adapter).] > > Since the SCSI tape (st) driver is structurally similar > to sg, it should be possible to add direct IO support > to st. > > One thing to note is that when you let the user provide > the buffer for direct IO (e.g. with malloc) then on > the i386 it won't be contiguous from a bus address POV. > This means large scatter gather lists (typically with > each element 4 KB on i386) which can be time consuming > to load on some SCSI adapters. One way around this would > be for a driver to provide "malloc/free" like ioctls. I'm not very knowledgeable, but doesn't the sound driver use mmap() to do this? Either way, AGP GART is basically a paged-MMU allowing non-contiguous phys-mem to be made to look contiguous from the AGP *and* from PCI (on most chipsets?). perhaps this would be helpful. Large contiguous phys-mem seems to be difficult currently, but would be nice as it would allow use of larger MMU pages with many cpus. Someone mentioned reverse page table support would be required first... > > Doug Gilbert > - > 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: Writing to Pana DVD-RAM
[EMAIL PROTECTED] wrote: > Hello, > > I am running RedHat Wolverine (beta) with kernel 2.4.2. I have a SCSI subsystem >(AHA2740) with a Panasonic LF-D101 DVDRAM on it. > > I read that the CDROM driver is built to recognize DVDRAMs and allow writes; well I >can mount and read the UDF file system fine, but am not allowed writes. I have >UDF2.0 on the disk, because it didn't recognize UDF2.1. > > Also, when I make xconfig, it includes UDF support, but read-only. >(Write-Experimental is grayed-out) > > In fstab: /dev/scd1 is mounted to /mnt/dvdram udf default 0 0. (paraphrasing) > > I need the DVDRAM for backups and file transfers. Is the problem the driver, the >UDF filesystem, my setup, or what? > -- > C. > > The best way out is always through. > - Robert Frost A Servant to Servants, 1914 > > - > 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/ Check that "Experimental " is enabled under "Code Maturity level options", if you can't find it try using "make menuconfig" instead of "make xconfig" Note that the UDF-write support option is listed as "Dangerous"... possibly making things difficult, but then again if you have a DVD-RAM, how bad can things be :) Cheers, Jeremy - 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: I can eject a mounted CD
Giuliano Pochini wrote:
> >> >> That's not the point. The kernel should not allow someone to
> >> >> eject a mounted media.
> >> >
> >> > rpm -e magicdev
> >>
> >> Magicdev is not installed.
> >> Ok, I'm the only one with this problem, I'll manage to find the bug by myself.
> >
> > eject(1) line 36:
> >
> >If the device is currently mounted, it is unmounted before
> >ejecting.
>
> But it doesn't get unmounted. I eject the disk but I can still see
> and read the (cached) files !
>
> Bye.
> Giuliano Pochini ->)|(<- Shiny Network {AS6665} ->)|(<-
>
> -
> 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/
hdparm has an option controlling door locking; try locking it manually
to see if the drive can even lock the door. then try setting it
to match mounted/unmounted status of device; maybe it defaults
to always unlocked for some reason.
hdparm -L 1 /dev/hdc
also try commenting out one of those fstab lines... may be confusing things.
it should work the way you have it - you say mount /mnt/fstype and
depending of fstype it picks the right line, but just for the sake of debugging
try loosing one temporarily.
Cheers
-
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 turn file caching off ?
Bjorn Wesen wrote: > A similar phenomenon happens when you simply copy a file - file A is read > into the cache and file B is written to the cache, until the memory runs > out. Then both start to flush at the same time, creating a horrible in this example only file B needs uses IO when being flushed; A's buffers aren't dirty, so they're just 'forgotten' > > performance hit (especially if A and B are on the same disk :) > bdflush and 2.4's equivalent are tunable; if all you do is this copying then optimise these parameters for this task. > > I don't know a way to fix this except having the kernel correctly identify > the access pattern and optimize for it (i.e. if it recognizes that cache currently all the kernel's heuristics are feed-back control loops. what you are asking for is a feed-forward system: a way for the application to tell kernel "I'm only reading this once, so after I'm done, throw it out straight away" and "I'm only writing this data, so after I'm done, start writing it out and then forget it" perhaps you could try mounting the destinatinon 'sync' with dd at least you could specify block size, there is also raw devices (no cache) mmaped files with madvise, fdatasync()... lots of ways. > > pages are flushed in order to make room for more pages from the same > inode, then it's probably a suboptimal caching pattern and instead it > should probably increase the readahead and flush bigger chunks of pages at > the same time). I don't think anything can be done to the writing queue > (except maybe make the kernel understand that seek-time is more expensive > than transfer-time, so it does not schedule the read/writeing each odd there is the elevator seek mechanism... > > page..) > > I'm still using 2.4.0 though so maybe this behaviour has been fixed to the > better in later kernels.. > > As a sidenote, try the same thing on an WinNT box and watch it die :) Like > unpacking a 1 GB file on a machine with 128 MB ram.. after it has unpacked > the first 100 MB's or so, performance drops to 1% or something.. Isn't this due to the journaling filesystem? All that seeking sure slows things down... > > > -BW > > On Tue, 17 Apr 2001, Laurent Chavet wrote: > > First cache grows to the size of RAM (2GB) with transfer rate > > slowing down as the cache grows. > > Then the transfer rates drops a lot (2 to 3 time slower than the > > drive capacity) and there is a very high CPU usage of system time (more > > than a CPU) used by bdflush and kswapd (and some others like kupdated). > > - > 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: Is there a way to turn file caching off ?
Helge Hafting wrote: > Jeremy Jackson wrote: > > > currently all the kernel's heuristics are feed-back control loops. > > what you are asking for is a feed-forward system: a way for the application > > to tell kernel "I'm only reading this once, so after I'm done, throw it out > > straight away" > > and "I'm only writing this data, so after I'm done, start writing it out and > > then forget it" > > > This is hard to get right. Sure - your unpack/copy program read once > and > writes once. But the stuff might be used shortly thereafter by > another process. For example: I unpack a kernel tarball. tar > knows it writes only once and might not need more than 5M to do > this as efficient as possible with my disks. A lot of other cache > could be saved, fewer things swapped out. > But then I compile it. Todays system ensures that lots of the source > is in memory already. Limiting the caching to what tar needed > however will force the source to be read from disk once during > the compile - not what I want at all. They why would you tell tar not to use cache? If you know what's happening next you need to tell the system (feed-forward), not have it try to read your mind. I'm assuming your modified tar would have an option switch to cause this behaviour, not be hard coded... > > > A program may know its own access pattern, but it don't usually know > future access patterns. Well, backing up the entire fs could benefit Yes, so a script that does the above wouldn't enable no cache mode for written files. The program doesn't know, but the encompasing script (or person at console) does. > > from a something like this, you probably won't need the backup again > soon. But this is hard to know in many other cases. - 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 timer performance ?
Praveen Rajendran wrote: > hi > > I am working on a kernel module which requires the addition of a large > number of kernel timers to expire statistical values ( including time > ) maintained in a table. > > One alternative would be to use a single timer and traverse the entire > table and use the existing system time to expire the values ( comparing > it with the time already stored in the table )when the timer expires . Most versions of cron claim to be very scalable, and use an optimized algorithm to do the second option. (avoiding linear scan) You could likely just cut and paste the code. Problem solved? > > > Following the method I describe first I would have to add a large number > of timers ( around 2000) ... would this cause any significant > performance drop ? which method should I use ? > > thanks in advance > > Praveen > > - > 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: [PATCH] Single user linux
Alan Cox wrote: > > so what the hell is transmeta doing with mobile linux (midori). > > is it going to teach multi-user thing to tablet owners? > > Thats you problem. Distinguish the OS from the user interface. > > > surely mortals expect midori to behave like their pc. lets say > > on redhat, they have to login as root to access their files, > > they don't even know what a root is! > > Even my digital tv box has multiple users. The fact you cannot figure out how > to make your UI present that to the end user in a suitable manner is not > the kernels problem. Get a real UI designer. Quote of the day: Never engage in a battle of wits with an idiot; they will bring you down to their level, then beat you with experience. Cheers! Jeremy - 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/
Is this the ultimate stack-smash fix?
Greetings. This is my first post on linux-kernel, I hope this is appropriate. The recent CERT IN-2001-01 's massive repercussions and CA-2001-02's re-releasing old material in an attempt to coerce admins to update their OS, has led me to think about buffer overrun exploits. I have gained a new appreciation after being rooted twice this month. I believe there is a solution that can be implemented in the kernel (Linux and probably most Unix) that can prevent this type of exploit, has no effect on userspace code, and is minimally obtrusive for the kernel. Making a few assumptions here - I'm writing to confirm or deny this idea. Background: The virtual address space of a Linux process starts at a low address (0?) with a block containing -the executable's code & constant data mmaped read-only from the executable. -the executable's static initialized data mmapped copy-on-write from same file. -more of each of the above, but for shared libraries. each continuous address range from the above is described in a kernel vm_area_struct, and is mapped on demand and placed into hardware page-protection perms (rwx) by the CPU's PMMU hardware and the kernel's fault-handler's. Next, there is a variable ammount of un mapped memory, Followed by the Stack. The stack's vm_area grows downward, unlike the others ( brk() call) and begins at the high address at the top of user space, which varies but is 3GB for a 1GB max mem kernel. beyond this there is no vm_area's, and the page tables contain mappings which are marked supervisor-only (is this right?), and definitely don't contain user code. Next, gcc doesn't generate any code which would be placed in the stack, nor does it generate any calls/jumps to the stack area. Next, buffer overruns are the only source of code whch would execute from the stack, and from what I understand, remote (if not all) buffer overruns depend on this to "work". Solution: if the kernel sets up the CPU's memory management unit (PMMU) so that it won't execute code in the stack address space, the exploits are foiled. Problem: on intel, the page tables page permissions are not flexible enough, so when a page is marked (for userspace) read-write permissions, execute permission is implied. But, intel also has segment descriptors held in the GDT/LDTs, which configure a base address and range, and a different one can be selected for each segment register of a process. Under the current Linux the code segment (CS) has a descriptor from the GDT which allows code to be executed read-only from base address 0 with a range of 4G (i.e. the entire linear address space), and the data segment allows read-write but not execute (can't be loaded into CS register). SO, if the CS descriptor were changed by the kernel to track the bottom of the stack (lower in memory), then any attempt to execute code on the stack would segfault (or another signal to help track exploit attempts) It could get the bottom page address from the vm_area_struct for the stack (are there more than one GROWS_DOWN vm areas in a process?) Currently the CS for all linux programs gets it's descriptor from GDT, so it would have to be manually changed at each task-swap, and perhaps there are segment descriptor and other cache flushing issues, (maybe just store CS limit in the per-task data structure, and update GDT then reload CS at each context change) I realize that the GDT/LDT must be accessible, and that they are in kernel space (above 3GB), but I don't think these go through CS register access controls. The DS segment can be left alone. For other arch's, maybe they have separate read/write/execute perms per page, or something similar to segment descriptors. I would appreciate thoughful comments; anybody who knows why it won't work, tell me, I haven't got my hopes up for the Nobel prize yet :) Cheers, Jeremy - 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: Destination Loose UDP in 2.4 (net/ipv4/netfilter)
TeknoDragon wrote: > What is the status of "dloose udp" in 2.4.x? From my reading in a few list > archives it seems to have been some sort of a hack, yet it is needed for > games such as Asheron's Call to be played behind a firewall. I use Starcraft behind a 2.4.0 (RH7) masq firewall using netfilter/nat/iptables and it works fine by default. iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE (or something very close) Under redhat 6.2, stock kernel, it also worked. Under 7.0 stock kernel, I had to echo 1 to that /proc file you mention below. > > > In 2.2.18 the code implementing this seems to be in net/ipv4/ip_masq.c > and was controlled by a sysctl "ip_masq_udp_dloose". > > Is there anything in 2.4.x to replace this functionallity? Is there a way > to replace it with an iptables rule? Any help would be much appreciated. > > -karl > > - > 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: [Xpert]Video drivers and the kernel
Please CC me if sending to xpert list. This is a big topic. I think I can contribute a whole two cents worth though... Interesting to note that NT's windowing system moved from being originally in userland to inside the kernel between V3.? and 4.0. Remember mom saying "If your friends all jump off a bridge..." The issue I understand is that context switching kernel<>user slows things down. And then there's trying to make an api... XFree just maps mmio/framebuffer and ioports into it's own address space and bangs the hardware, so it's fast and can do anything. DRI extends this to client 3D code in a sense. Bottom line for me, I don't care; as long as I still can use remote X apps, and Quake3 uses my 3D hardware, I'm happy to have people spend their time improving X how they see fit, and they're done an incredible job so far. My only complaint is when there's a problem with X: It's cool that I can just restart it rather than reboot like windows. (so you can play from console of a server right? :) This is a benefit of it being in userspace. But it would be nice if I didn't have to do it via telnet; sometimes I don't have a box on a network. (Aside, is this because X uses keyboard in raw mode? would be nice to still be able to ctrl-alt-del to rebood from console) Anyone know about using alt-sysrq to restore console? So, if the kernel had a card specific module that just knew enough to put the card back into text mode, or if it used the card's bios to do it like the int10.a module in XFree 4.0, we would lack for nothing. (hmm vesafb could be extended?) > On Tue, 13 Feb 2001, Louis Garcia wrote: > > > I was wondering why video drivers are not part of the kernel like every > > other piece of hardware. I would think if video drivers were part of the > > kernel and had a nice API for X or any other windowing system, would not > > only improve performance but would allow competing windowing systems > > without having to develop drivers for each. Has anyone thought or > > rejected this idea. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is this the ultimate stack-smash fix?
"Eric W. Biederman" wrote: > Jeremy Jackson <[EMAIL PROTECTED]> writes: > (about non-executable stack) > > There is another much more effective solution in the works. The C > standard allows bounds checking of arrays. So it is quite possible > for the compiler itself to check this in a combination of run-time and > compile-time checks. I haven't followed up but not too long ago > there was an effort to add this as an option to gcc. If you really > want this fixed that is the direction to go. Then buffer overflow > exploits become virtually impossible. > I've thought some more, and yes someone else has already done this. Problems are with compilers that put code on stack (g++ trampolines for local functions i think). There is the gcc-mod (Stack-guard?) that checks for corrupt stack frame using magic number containing zeros before returning... this will take away some performance though... I wonder if the root of the issue is the underlying security architechure ... anything that needs ANY privilege gets ALL privileges (ie root). chown named and such fixes this, but can't rebind to privileged port, must be restarted by root to do so. VMS / NT have more fine grained privileges. Is there any documentation of the kernel's 'capabilities' functions? It would be exceedingly cool if services (named, nfs, etc) could be updated to use this; I think crackers would loose some motivation if instead of "hey I can totally rule this box!" they have to settle for "hey I can make the ident service report user 'CrAp' for every port!". - 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: Samba performance / zero-copy network I/O
"Gord R. Lamb" wrote: > Hi everyone, > > I'm trying to optimize a box for samba file serving (just contiguous block > I/O for the moment), and I've now got both CPUs maxxed out with system > load. > > (For background info, the system is a 2x933 Intel, 1gb system memory, > 133mhz FSB, 1gbit 64bit/66mhz FC card, 2x 1gbit 64/66 etherexpress boards > in etherchannel bond, running linux-2.4.1+smptimers+zero-copy+lowlatency) > > CPU states typically look something like this: > > CPU states: 3.6% user, 94.5% system, 0.0% nice, 1.9% idle > > .. with the 3 smbd processes each drawing around 50-75% (according to > top). > > When reading the profiler results, the largest consuming kernel (calls?) > are file_read_actor and csum_partial_copy_generic, by a longshot (about > 70% and 20% respectively). > > Presumably, the csum_partial_copy_generic should be eliminated (or at > least reduced) by David Miller's zerocopy patch, right? Or am I > misunderstanding this completely? :) I only know enough to be dangerous here, but I believe you will need to be using one of the network cards whose driver actually uses the zero-copy patches, and/or which can perform tcp checksum in hardware (of the network card). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is this the ultimate stack-smash fix?
"Eric W. Biederman" wrote: > Jeremy Jackson <[EMAIL PROTECTED]> writes: > > > "Eric W. Biederman" wrote > No. I'm not talking about stack-guard patches. I'm talking about bounds checking. Sorry, I was quite incoherent. Many others have pointed out that there exist patches for non-executatble stack, and the problems with it. That's what I meant to comment on. But I'm glad to find out about bounds checking as an option. > But the gcc bounds checking work is the ultimate buffer overflow fix. > You can recompile all of your trusted applications, and libraries with > it and be safe from one source of bugs. That's why I was wondering of limiting privileged addresses security at a more fundamental level... as you say above, this fixes *ONE* source of bugs(security threats)... but itn't it inevitable that there will be others? But if services are each put in a separate box, that doesn't have a door leading to the inner sanctum, things would be more secure in spite of "bugs". Well I thank everyone for their responses in this thread, I think It's been beaten into the ground (my original idea), and I'm left with some food for thought. - 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: re. too long mac address for --mac-source netfilter option
[EMAIL PROTECTED] wrote: >All hits on my firewall from cable modem servers other than my own provider also have >the 14 group "MAC" address so it l>ooks like this may be a feature of these units. Some cable providers use Ethernet bridging instead of full ip routing. perhaps this is what you are seeing. Maybe TCPdump will label packets which are for "spanning tree" or similar? - 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/
Multi-sized MMU page support
Greetings, I have been staying up late thinking about this, so I'm writing to clear my head. (and get some sleep in the future) Background: Under ia32 Pentium and higher, 3 different MMU page sizes are available in hardware: 4kB, 4MB & 2MB. Under Alpha (21064), sizes include 8kB, 4MB for code, 8kB, 64kB, 512kB, and 4MB. Under ia64, sizes range (in powers of two) from 4kB to 256MB. Significance: a number of important architectures support multi-sized pages. For applications with large contiguous code and/or data objects, this enhanced hardware allows a performance increase. A prerequisite for using these features is kernel support. I am unaware of what order of improvement this will allow, but I can immagine the pipeline stalls caused on TLB misses: examples: gimp lightens an entire 64MB image; a linear scan read-modify-write. This access pattern isn't *so* bad. The X server mmaps a 32MB area (3dfx) or larger of the video card for linear frame buffer/mmio and accesses it in a slightly less that random fashion. This could benefit much more from larger pages. Note that this is completely different that MTRR support. Also consider that the TLB cache must be flushed and reloaded frequently durring context switches under an OS with separate memory areas for each process. The larger the pages, the fewer entries which must be reloaded. Also, not completely unrelated are comments in the kernel 2.3.? slab allocator regarding the inabliity of the zoned-buddy allocator to provide more than single (or trivially larger) pages for slab-cache. The code which would request larger pages when it would be more optimal to do so is commented with 1's hardcoded instead. Proposed implementation: Short term: allow a special (temporary) mmap argument or syscall and support in fault handlers/page table routines, to allow mmap or non-ram areas with larger sized pages. the X server could uses this immediately by adding the call alongside the MTRR setting. This avoids swap / mmaped file issues. Long term: extend the zoned-buddy allocator to include buddy-lists up to the largest hardware page size; page table and fault handlers, swap code, etc; massive work just for UP. user-space code could mmap ANON and get an aligned 4MB area using a single hardware page... Egad man! or "stop the madness"? - 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 OS boilerplate
Scott Long wrote: > Does there exist an outline (detailed or not) of the boot process from > the point of BIOS bootsector load to when the kernel proper begins > execution? If not would anyone be willing to help me understand > bootsect.S and setup.S enough so that I might write such an outline? I have been over it, and would be willing to help. You should first read all of the LILO documentation, and check out some of the LinuxBIOS project at www.linuxbios.org. - 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: Kernel executation from ROM
Jaswinder Singh wrote: > Dear Sirs, > > Thanks for your help, > > I see . The biggest negative point of running kernel from ROM is that ROM > speed is slow :( Also, the PCI specification forbids executing code from ROMs over the PCI bus. The system BIOS in a PC is not on the PCI bus, bus, but everything else is. - 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: Kernel executation from ROM
"Eric W. Biederman" wrote: > No it forbids executing boot roms that way, by a standard pc bios. > The system BIOS in a PC is normally on the ISA bus which is reached > across via the PCI bus with a PCI->ISA bridge. Son of a gun, I missed that... sure enough my PIIX4 docs beside me here show a #BIOSCS pin on the southbridge... Can anybody clarify what this restriction does and doesn't apply to ? The MindShare PCI Arch. book where I got that info from doesn't elaborate that much. > The thing is slow it really doesn't matter, all you need to do is > enable caching on that area of the physical address space. You can't > do this on the alpha currently but only because the alpha sucks that > way. You can on practically everything else. > > As for ROM being slow on x86 you can enable the MTRR to speed things Don't MTRR's just do write combining? > > up. Usually though ROMs are at least as expensive as RAM, so it is > pointless. - 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: pmap.c : Can you please try another name for it?
Dieter Nützel wrote: > * Justification: the formatting available in /proc//maps is less > * than optimal. It's hard to figure out the size of a mapping from > * that information (unless you can do 8-digit hex arithmetic in your > * head) and it's just generally not friendly. Hence this utility. you may want to check sourceforge for xmlprocfs 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: Is this the ultimate stack-smash fix?
Xavier Bestel wrote:
> Le 20 Feb 2001 02:10:12 +0100, Andreas Bombe a écrit :
> >
> > An array is a word that contains the address of the first element.
>
> No. Exercise 3: compile and run this:
> file a.c:
> char array[] = "I'm really an array";
>
> file b.c:
> extern char* array;
> main() { printf("array = %s\n", array); }
>
try file b.c
extern char array;
main() { printf("array= %s\n", &array); }
?
>
> ... and watch it biting the dust !
> in short: an array is NOT a pointer.
-
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: [rfc] Near-constant time directory index for Ext2
> In article <01022020011905.18944@gimli>, > Daniel Phillips <[EMAIL PROTECTED]> wrote: > >Earlier this month a runaway installation script decided to mail all its > >problems to root. After a couple of hours the script aborted, having > >created 65535 entries in Postfix's maildrop directory. Removing those > >files took an awfully long time. The problem is that Ext2 does each > >directory access using a simple, linear search though the entire > >directory file, resulting in n**2 behaviour to create/delete n files. > >It's about time we fixed that. In the case of your script I'm not sure this will help, but: I've seen /home directories organised like /home/a/adamsonj, /home/a/arthurtone, /home/b/barrettj, etc. this way (crude) indexing only costs areas where it's needed, without kernel modification. (app does it) What other placed would we need indexing *in* the filesystem? - 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: [rfc] Near-constant time directory index for Ext2
Mike Dresser wrote: > the way i'm reading this, the problem is there's 65535 files in the directory > /where/postfix/lives. rm * or what have you, is going to take forever and > ever, and bog the machine down while its doing it. My understanding is you > could do the rm *, and instead of it reading the tree over and over for every > file that has to be deleted, it just jumps one or two blocks to the file that's > being deleted, instead of thousands of files to be scanned for each file > deleted. > I thought about it again, and the proformance problem with "rm *" is that the shell reads and sorts the directory, passes each file as a separate argument to rm, which then causes the kernel to lookup each file from a random directory block (random because of previous sort), modify that directory block, then read another... after a few seconds the modified blocks start to be written back to disk while new ones are looked up... disk seek contention. and this becomes hard on the dir. block cache (wherever this is) since from source each dir entry is just over 256 bytes (?) 65535 files would require 16MB to cache dir entries. Plus it has to read in all the inodes, modify, then write, taking up xxMB more. You're probably swapping out, with swap partition on same disk, the disk may explode. If it were truly doing a linear scan, it might be faster. Two successive mods to same dir block would be merged onto same write. Perhaps rm -rf . would be faster? Let rm do glob expansion, without the sort. Care to recreate those 65535 files and try it? or use ls with the nosort flag pipe through xargs then to rm... again loose sorting but don't delete directory or subdirs. > > Jeremy Jackson wrote: > > > > In article <01022020011905.18944@gimli>, > > > Daniel Phillips <[EMAIL PROTECTED]> wrote: > > > >Earlier this month a runaway installation script decided to mail all its > > > >problems to root. After a couple of hours the script aborted, having > > > >created 65535 entries in Postfix's maildrop directory. Removing those > > > >files took an awfully long time. The problem is that Ext2 does each > > > >directory access using a simple, linear search though the entire > > > >directory file, resulting in n**2 behaviour to create/delete n files. > > > >It's about time we fixed that. > > - 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/
test delete me
please disregard this message. - 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/
test delete me
please disregard this message. - 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: New net features for added performance
Jeff Garzik wrote: (about optimizing kernel network code for busmastering NIC's) > Disclaimer: This is 2.5, repeat, 2.5 material. Related question: are there any 100Mbit NICs with cpu's onboard? Something mainstream/affordable?(i.e. not 1G ethernet) Just recently someone posted asking some technical question about ARMlinux for and intel card with 2 1G ports, 8 100M ports, an onboard ARM cpu and 4 other uControllers... seems to me that ultimately the networking code should go in that direction: immagine having the *NIC* do most of this... no cache pollution 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: New net features for added performance
Andrew Morton wrote: (kernel profile of TCP tx/rx)So, naively, the most which can be saved here by optimising > the skb and memory usage is 5% of networking load. (1% of > system load @100 mbps) > For a local tx/rx. (open question) What happens with a router box with netfilter and queueing? Perhaps this type of optimisation will help more in that case? think about a box with 4 1G NICs being able to route AND do QoS per conntrack connection (ala RSVP and such) Really what I'm looking for is something like SGI's STP (Scheduled Transfer Protocol). mmap your tcp recieve buffer, and have a card smart enough to figure out header alignment, (i.e. know header size based on protocol number) transfer only that, let the kernel process it, then tell the card to DMA the data from the buffer right into process memory. (or other NIC) Make it possible to have the performance of a Juniper network processor + flexiblity of 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: Should isa-pnp utilize the PnP BIOS?
Thomas Hood wrote: > On my ThinkPad 600, The ThinkPad PnP BIOS configures > all PnP devices at boot time. > > If I load the isa-pnp.o driver it never detects any ISA PnP > devices: it says "isapnp: No Plug & Play device found". This > is unfortunate, because it means that device drivers can't > find out from isa-pnp where the devices are. > > David Hinds's pcmcia-cs package contains driver code that > interfaces with the PnP BIOS. With it, one can list the resource > usage of ISA PnP devices (serial and parallel ports, sound chip, > etc.) and set them, using the "lspnp" and "setpnp" commands. > > Would it not be useful if the isa-pnp driver would fall back > to utilizing the PnP BIOS (if possible) in order to read and I would find this EXTREMELY usefull... my Compaq laptop's hot-dock with power eject will only work if Linux uses PnP BIOS's insert/eject methods. I saw some code in early 2.3 that would talk to bios, i still have a tarball, but it seems 2.4 only does hardware banging (best in *most* cases...) > > change ISA PnP device configurations when it can't do this > itself? If so, could this perhaps be done by bringing the Hinds > PnP BIOS driver into the kernel and interfacing isa-pnp to it? - 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: IDE floppy drives and devfs - no device nodes if no disk loaded atboot
Derrik Pates wrote: > Subject says about all there is to say. I have figured out that IDE drives > are enumerated as part of the boot-time partition check in > fs/partitions/check.c, but if I don't have something loaded at boot time > (IDE SuperDisk in PC at home, IDE Zip 100 in G3 tower at work), I never > get device nodes at all with devfs. Something really needs to be done > about this, IMHO. hdparm's got a cmd line switch to unregiser/register and ide interface. It tried it *once* and it just complained about cmd line args being wrong... i'll have to look into it more. when working it should help your situation. - 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: tcp stalls with 2.4 (but not 2.2)
Brian Grossman wrote: > I'm seeing stalls sending packets to some clients. I see this problem > under 2.4 (2.4.1 and 2.4.1ac17) but not under 2.2.17. compiled in ECN support? SYNcookies? try disabling through /proc tcp or udp? if udp check /proc/net/ipv4/ip_udpdloose or such > > > My theory is there is an ICMP black hole between my server and some of its > clients. Is there a tool to pinpoint that black hole if it exists? ping is your friend. -s lets you set size of packet. (to check for fragmentation) use tcpdump to capture a trace of this or a tcp session. email trace to me private if you want. > > > Can anyone suggest another cause or a direction for investigation? > > Why does this affect 2.4 but not 2.2? > > The characteristics I've discovered so far: > > From strace of the server process, each write to the network is > preceeded by a select on the output fd. The select waits for a > long time, after which the write succeeds. > > The packets are received by the client a couple minutes after my > server sends them. > > The clients I have tested with are win98 and winNT. > > The router for both 2.4 and 2.2 servers is running 2.2.18 with > ipvs (ipvs-1.0.2-2.2.18). > > That router does not block any ICMP. > > The behavior occurs on the 2.4 machine whether the packets are > routed directly or are mangled by ipvs. > > I've tried the same machine with both 2.4 and 2.2, as well as > another machine with just 2.2. 2.2 works. 2.4 doesn't. > > Both of my servers and the router I mentioned have two tulip > network cards. > > The clients I've tested with are behind a modem through earthlink. > Another I suspect to have same problem is behind a modem > through Juno. > > I've tried adjusting both /proc/sys/net/ipv4/route/min_adv_mss and > /proc/sys/net/ipv4/route/min_pmtu downward. Do these require an > ifconfig down/up to take effect? > - 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: CLOCAL and TIOCMIWAIT
Ivan Passos wrote: > Hello, > > A customer has just brought to my attention that when you try to use the > TIOCMIWAIT ioctl with our boards and CLOCAL is enabled, you can't check > changes in the DCD signal. He also mentioned that that is possible with > the regular serial ports. > > As I understood, CLOCAL meant disabling DCD sensitivity, so if CLOCAL is > disabled, no changes in DCD will be passed from hardware driver to the > kernel or userspace. The way the serial driver is implemented, this is not > true (i.e. even with CLOCAL enabled, you can still see DCD changes through > the TIOCMIWAIT command). I remember auditing the exact code where this happens, but on 2.0 or earlier. I had written a simple program 10-20 lines C to count pulses at rate of 1 per second give or take. It turned out that the driver disabled the UART's generation of interrupts completely for certain signals. I don't remember which exactly, but I think it was DCD; I was using CLOCAL so the hangups wouldn't close the descriptor. The problems was that by disabling the interrupt at the source, the ioctl's to read the bits stopped working! not what I wanted. I'm afraid I can't help, other that to suggest that that behaviour can have problems. The extra irq traffic was probably the motivation for this optimisation, but I don't know of anyone's modem hanging up frequently enough to measure the extra load. Only people crazy enough to use the built-in serial port ($0) as opposed to an $500 industrial digital io card are likely to care though... > > > My question is: what's the correct interpretation of CLOCAL?? If the > serial driver's interpretation is the correct one, I'll be more than happy > to change the Cyclades' driver to comply with that, I just want to make > sure that this is the expected behavior before I patch the driver. - 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: Problem creating filesystem
Carlos Fernandez Sanz wrote: > I have just purchased a new HD and I'm getting problems creating a > filesystem for it. I've done some research and some people claim the problem > might be kernel related so I'm asking here just in case. > > The HD is a Maxtor 80 Gb, plugged to the Promise controller that comes with > Asus A7V motherboards. The controller is ide2, and the HD is /dev/hde. ide0 how did you get it to recognise this controller? kernel command line? stock RH7's kernel 2.2.16-22 doesn't have automatic support. I'd be interested to know if 2.2.17-14 does, as I could use this on a system. > > and ide1 are working with no problems. > > - > fdisk shows some warnings (but doesn't refuse to create the partition): > > [root@alhambra /sbin]# fdisk /dev/hde > Device contains neither a valid DOS partition table, nor Sun, SGI or OSF > disklabel > Building a new DOS disklabel. Changes will remain in memory only, > until you decide to write them. After that, of course, the previous > content won't be recoverable. This is normal for a blank disk; hopefully that's all this is. > > > The number of cylinders for this disk is set to 15871. > There is nothing wrong with that, but this is larger than 1024, > and could in certain setups cause problems with: > 1) software that runs at boot time (e.g., old versions of LILO) > 2) booting and partitioning software from other OSs >(e.g., DOS FDISK, OS/2 FDISK) this is fine. just a note for the inexperienced. > > Warning: invalid flag 0xa855 of partition table 5 will be corrected by > w(rite) normal - related to first message. > > > Command (m for help): n > Command action >e extended >p primary partition (1-4) > p > Partition number (1-4): 1 > First cylinder (1-15871, default 1): > Using default value 1 > Last cylinder or +size or +sizeM or +sizeK (1-15871, default 15871): > Using default value 15871 > > Command (m for help): p > > Disk /dev/hde: 16 heads, 63 sectors, 15871 cylinders > Units = cylinders of 1008 * 512 bytes > >Device BootStart EndBlocks Id System > /dev/hde1 1 15871 7998952+ 83 Linux > > Command (m for help): w > The partition table has been altered! > > Calling ioctl() to re-read partition table. > > WARNING: If you have created or modified any DOS 6.x > partitions, please see the fdisk manual page for additional > information. > Syncing disks. although it doesn't look like it's necessary, it's a good idea to reboot here. (it usually gives a additional error if reboot needed) > > -- > When trying to create the filesystem, I get this: > > [root@alhambra /sbin]# ./mke2fs /dev/hde1 > mke2fs 1.18, 11-Nov-1999 for EXT2 FS 0.5b, 95/08/09 > /dev/hde1: Invalid argument passed to ext2 library while setting up > superblock sounds like an overflow. try using badblocks to verify that the kernel will allow access to all sectors in the partition. badblocks -b 1024 -sv `fdisk -s /dev/hde1` if that works, it looks like overflow in mke2fs or e2fs libraries; try: delete partition 1 and make 2 more, each half of the disk, try mke2fs /dev/hde1 if that works try mke2fs /dev/hde2; if they both work then the overflow is likely the size of the disk; but you have access to all of it in just two halves, until a fix is found. > > --- > > I'm using > Linux version 2.2.17-14 ([EMAIL PROTECTED]) (gcc version > egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 Mon Feb 5 16:02:20 EST > 2001 > > The IDE controller is > Bus 0, device 17, function 0: > Unknown mass storage controller: Promise Technology Unknown device (rev > 2). > Vendor id=105a. Device id=d30. > Medium devsel. IRQ 10. Master Capable. Latency=32. Unrelated to disk "problem", you might want to set your PCI latency timer in BIOS to 64 or more. > > I/O at 0x9000 [0x9001]. > I/O at 0x8800 [0x8801]. > I/O at 0x8400 [0x8401]. > I/O at 0x8000 [0x8001]. > I/O at 0x7800 [0x7801]. > Non-prefetchable 32 bit memory at 0xdd80 [0xdd80]. > [root@alhambra /proc]# - 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: New net features for added performance
"David S. Miller" wrote: > Andi Kleen writes: > > Or did I misunderstand you? > > What is wrong with making methods, keyed off of the ethernet protocol > ID, that can do the "I know where/how-long headers are" stuff for that > protocol? Only cards with the problem call into this function vector > or however we arrange it, and then for those that don't have these > problems at all we can make NULL a special value for this > "post-header" pointer. > I had a dream about a NIC that would do exactly the above by itsself. The dumb cards would use the above code, and the smart ones' drivers would overload the functions and allow the NIC to do it. "Tell me of the waters of your homeworld, Usul" :) Except the driver interacts differently than netif_rx... knowing the protocol it DMA's the header only(it knows the length then too) (SMC's epic100's descriptors can do this, but the card can't do the de-mux on proto id, forcing the network core to run in the ISR so the card can finish DMA and not exhaust it's tiny memory.) The network code can then do all the routing/netfilter/QoS stuff, and tell the card to DMA the payload into the TX queue of another NIC (or queue the header with a pointer to the payload in the PCI address space of the incoming NIC heh heh) OR into the process' mmap'ed TCP receive buffer ala SGI's STP. - 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: Dynamically altering code segments
"Collins, Tom" wrote: > Hi... > > This is my first post, so if this is off topic for this list, please direct > me > to another one that is more appropriate. Thanks > > That said, I am wanting to dynamically modify the kernel in specific places > to > implement a custom kernel trace mechanism. The general idea is that, when > the > "trace" is off, there are NOP instruction sequences at various places in the > kernel. When the "trace" is turned on, those same NOPs are replaced by JMPs > to code that implements the trace (such as logging events, using the MSR and > PMC's etc..). > > This was a trick that was done in my old days of OS/2 performance tools > developement to get trace information from the running kernel. In that > case, > we simply remapped the appropriate code segments to data segments (I think > back then it was called 'aliasing code segments') and used that segment to > make changes to the kernel code on the fly. > > Is it possible to do the same thing in Linux? > the CS and DS segment descriptors already both map 0-4G, the DS being read-write. what you want is to change page protections, the system call mprotect() comes to mind. - 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: Promise Ultra100 IDE PDC20265 chip problem
[EMAIL PROTECTED] wrote:
> (I am not subscribed to this list, if it is in fact a list. Please CC
any
> replies to me directly - Thanks)
>
> I am attempting to install the new beta release of Red Hat (fisher) on
my
> home computer. It has an Asus A7V motherboard and a Promise Ultra100
IDE
> controller (PDC20265 chip), with two partitions. Windows ME is
installed in
> the first partition. The second one is where I'm attempting to install
Red
> Hat.
>
> In previous releases of the Linux kernel, my hard drive was not seen
at all.
> I could go all the way up to the point in the Red Hat installation
where it
> wanted to do disk geometry, and then said that I didn't have any mass
media
> device. Searching through various mail archives lead me to believe the
> culprit was the PDC20265 controller chip and the fact that it was too
new to
> be recognized.
>
> In the new kernel 2.4.0 (and thereby the fisher release of Red Hat), I
now
> see the error below printed out to the console when booting from the
Red Hat
> installation floppy. After the error is printed out, my computer
hangs. I
> apologize in advance if this is not a Linux kernel issue, and
appreciate any
> help that can be provided.
>
> --Pete
>
> [snip]
>
> PDC 20265: chipset revision 2
> PDC 20265: not 100% native mode: will probe irqs later
>
> [snip]
>
> Partition Check:
> hde: [PTBL] [1826/255/63] hde1 hde2 < hde5hde: dma_intr: status=0x51 {
> DriveReady SeekComplete Error }
> hde: dma_intr: error=0x10 { SectorIdNotFound }, LBAsect=32885055,
sector=0
> hde: dma_intr: status=0x51 { DriveReady SeekComplete Error }
>
> [last repeats 3-4 times]
>
> hde: DMA disabled
>
this looks like a sign that the kernel you're using is configured to try
to use
harddisk DMA right at boot. That *could* cause problems in rare cases.
SectorIdNotFound looks like a bad sector on the harddisk though.
looks like you can't get into linux at all... try scandisk from windows
on Thorough setting (have to format linux partition as fat32 first).
-
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: Unmounting and ejecting the root fs on shutdown.
David Balazic wrote: Per Erik Stendahl wrote : > What I do know now is how to make the kernel not lock the CD in the > first place. Simply ioctl(/dev/cdrom, CDROM_CLEAR_OPTIONS, CDO_LOCK) > from /linuxrc in the initrd. This way I can remove the CD anytime > I please which is enough for me. And I dont have to patch the kernel. Or : echo 0 > /proc/sys/dev/cdrom/lock ( I am not sure if this is the right filename ) Or run magicdev ;-) This might save everyone some pain: from hdparm(8) man page (mine has some format bugs, but you get the picture) -L Set the drive's doorlock flag. Setting this to will lock the door mechanism of some removeable hard drives (eg. Syquest, ZIP, Jazz..), and setting it to maintains the door locking mechanism automat ically, depending on drive usage (locked whenever a filesystem is mounted). But on system shutdown, this can be a nuisance if the root partition is on a removeable disk, since the root partition is left mounted (read-only) after shutdown. So, by using this command to unlock the door -b after the root filesystem is remounted read-only, one can then remove the cartridge from the drive after shutdown. you seem to be into reading the source (tm) so hdparm's might be a good place to look (if it doesn't just work like it says above) - 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: How to set hdparms for ide-scsi devices on devfs?
Eduard Hasenleithner wrote:
> Sorry, if this issue was already discussed in lkml. I didn't find
> a reference to this at www.geocrawler.com
>
> My Problem:
> I want to set the unmaskirq and dma -flag for my ide cd-recorder.
> The Problem is, that devfs creates no ide device, but only
> the /dev/scsi/../{cd,general} devices are created. And hdparm
> don't accepts this devices for setting the ide-parameters.
>
> My current workaround is to create a /dev/hd? device "by hand"
> at system startup. This is not very beautiful. Furthermore, if
> the device numbers in devfs are deactivated, this won't work
> anymore.
>
> I can live with my current solution. But i would be very happy
> if someone can present a clean solution.
>
> I posted this message intentionally not on the devfs mailing list
> as i think this problem is related to accessing the same device
> through different /dev entries. Under devfs, the /dev/ide/...
> device node gets allocated after the corresponding ide-xx.o has
> been loaded. But this is not possible with ide-scsi claiming
> the device :(
>
> Thanks in advance
workaround - before ide-scsi is loaded in boot sequence
(finding is left as an exercise to the reader :) do:
modprobe ide-cd
hdparm -u 1 -d 1 /dev/xxx
rmmod ide-cd
might have to do near top of /etc/rc.d/rc.sysinit under redhat,
but this is good since problems will happen before root filesystem
is remounted read-write, so any problems with hdparm settings
won't mess up disk.
-
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: Unmounting and ejecting the root fs on shutdown.
Per Erik Stendahl wrote: > > Nah, that looks too easy! ;-) > > > This might save everyone some pain: > > from hdparm(8) man page (mine has some format > > bugs, but you get the picture) > > > Is it true that the root fs is left mounted read-only? What is the > rationale behind this? It seems to me that it would be better to > completely unmount it and do whatever cleaning up is required (like > cdrom_release()?). But I've been known to miss important issues before! > :-) > > BTW, what would be the best way to determine which devices are cdrom > devices? Looks like /proc/sys/dev/cdrom/info could be of use but what > happens on a computer with more than one cdrom device? > Read about devfs option in 2.4 kernel. it puts only devices that exist into /dev/cdroms/cdrom0, dev/cdroms/cdrom1, etc. and if hdparm works (and it must since redhat's installer ejects it's cd when rebooting) and you still are looking for a solution, well no comment. - 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: [Newbie] Re: Problem creating filesystem
Rogerio Brito wrote: > On Feb 26 2001, Jeremy Jackson wrote: > > Carlos Fernandez Sanz wrote: > > > The IDE controller is > > > Bus 0, device 17, function 0: > > > Unknown mass storage controller: Promise Technology Unknown device (rev > > > 2). > > > Vendor id=105a. Device id=d30. > > > Medium devsel. IRQ 10. Master Capable. Latency=32. > > > > Unrelated to disk "problem", you might want to set your PCI latency timer in > > BIOS to 64 or more. This should be accessible in your BIOS setup. I'm basing my comments on one NIC driver complaining in my logs and overriding settings lower that 64; however the general idea is to trade off latency for throughput. If I go crazy, like 192 or so, on *my* system, sound card starts to pop a bit, indicating that it's fifo buffer is smaller that that and is emptying when other devices are using the bus at the same time (it's like a timeslice) > > > Ok, I understand that this is probably off-topic and way too > basic, but what exactly would this do, in layman terms? Would > the latency being set to 32 result in any potential data > corruption? BTW, to set this quantity, one should use setpci, > right? - 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 problems
Rob wrote: > Hi, I'd like to thank everyone that helped me with the compiler problem. > I've updated everthing in Documentation/Changes I have a brand spankers > new gcc, ppp, etc. The problem I'm running into now is when I try to > connect to the internet, it says that I don't have a kernel that supports > PPP. I've tried compiling it in as modules and as part of the kernel but > when I try to connect to the isp I keep getting the message that I don't > have a kernel that supports PPP. I've even contacted my System > Administrator, Hi Chris ;^). Any ideas on what I could try next? A cc > would be great, as I'm not on the linux-kernel list. Do you have the right kernel configuratoin? It sounds like you need to load the modules (or set modules.conf to auto-load them with "alias" lines) On linux 2.4 you need ppp_generic, ppp_async, slhc loaded with modprobe or insmod. on 2.4 config options under "network device support" PPP (point-to-point protocol) support [ ] PPP multilink support (EXPERIMENTAL) PPP support for async serial ports PPP support for sync tty ports PPP Deflate compression PPP BSD-Compress compression PPP over Ethernet (EXPERIMENTAL) your using a modem? cable or ADSL? reply to me privately, as linux-kernel probably isn't the place to discuss this since it sounds like an install issue... if we find it's a kernel bug then it would be ok. if you're using a 2.2 kernel i suggest you try the one that came with your distribution. oh yeah what is your distribution? Cheers, Jeremy - 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: How to set hdparms for ide-scsi devices on devfs?
Wakko Warner wrote: > > PS: Is there still a possibility for setting the IDE-sleep timeout > > for a ide-scsi harddisk? (I know, this doesnt make sense) Yeah, why would you ? ide-scsi is mainly to support cd-rw drives, AFAIK > > > I didn't know you could use ide-scsi emulation for hard drives. > > -- > Lab tests show that use of micro$oft causes cancer in lab animals > - > 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: IRQ advice (2.4.2-ac7)
Favre Gregoire wrote: > Hello, > > as I boot some times under windows, i have to change my IRQ for my PCI > devices to (all) 9... and all the times I tried to boot that way under linux, > it doesn't boot... > > So I haven't tested it that way for ages... and now with 2.4.2-ac7 i booted > without any problem that way: > cat /proc/interrupts 03.03 1:52 >CPU0 > 0:3051534 XT-PIC timer > 1: 37390 XT-PIC keyboard > 2: 0 XT-PIC cascade > 8: 1 XT-PIC rtc > 9:6193814 XT-PIC HiSax, aic7xxx, EMU10K1, usb-uhci, saa7146(1), bttv > 12: 314048 XT-PIC PS/2 Mouse > 14: 11820 XT-PIC ide0 > 15: 42041 XT-PIC ide1 > NMI: 27599 > LOC:3051630 > ERR: 0 > MIS: 0 > > Is it safe to do it that way? I personally don't like sharing interrupts unles absolutely necessary. Can you tell me why you need to do this? I would recommend disabling any devices you aren't using in the BIOS, to free up interrupts. (IE 2nd serial port, USB, 1st serial if you only use PS/2 mouse) If you don't use the floppy you might be able to disable it in BIOS. I have one board that will use irq 6 for something more useful in this case. Also, changing PCI slot assignment of some cards (if you have spare slots) can prevent sharing as well. The BIOS on many boards will show PCI interrupt assignment on the bootup screen. Otherwise check in windows device manager - double click on Computer node. according to the above usage, you could use 4 (com1) (if not mouse or modem) 3 com2 5 unused 9,10,11 for devices. Good luck! - 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: VFS: Cannot open root device
Jeremy wrote: This is going to get confusing! > Hello all, > HELP, I have a new server that I am trying to put > Redhat 7.0 on. It is a Compaq Proliant ML530 Dual PIII > 1Ghz with a Gig of RAM. It has a Compaq smart array > 5300 in it also. It boots just fine with the default > Redhat 7 kernel 2.2.16smp but when I compiled my own > 2.4.2 kernel I get the following message. > > request_module[scsi_host_adapter]: Root FS not mounted > request_module[scsi_host_adapter]: Root FS not mounted 2 possibilities: you misconfigured kernel or didn't make an initial ramdisk to load scsi modules. to make a good configuration, you may wish to use the config files that redhat used to build the kernel you say works, and then just tweak a few things like processor type. they're installed (i think) in /usr/src/linux/configs if you install kernel-source package. try command 'man mkinitrd' under redhat for hints about initial ramdisk. > > > Then some standard lines Then: > > NET 4: Unix domain sockets 1.0/SMP for Linux NET 4.0 > request_module[block-major-104]: Root FS not mounted > VFS: Cannot open root device "6802" or 68:02 > Please append a correct "root=" boot option > Kernel Panic: VFS: Unable to mount root FS on 68:02 > > When I boot 2.2.16 the only modules that are loaded > are cciss, NCR53C8XX, eepro100 and tlan. I have triple > checked and I have built cciss and NCR53C8XX into the > kernel, I even tried them as modules. It almost looks > like it just isn't loading the NCR53C8XX and then it > cant mount the File system. > If you need any more info please let me know. > > Please CC anything to me directly since I am not on > the mailing list. > > Thanks, >Jeremy - 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: [Re: paging behavior in Linux]
Manfred Spraul wrote: > Neelam Saboo wrote: > > > > hi, > > > > After I installed a newer version of Kernel (2.4.2) and enable DMA option in Ah hah! There's a huge difference in performance (in my experience) with DMA. also, using hdparm utility, *most* drives work fine with dma, irq unmasking, multisector transfers, and 32bit access. hdparm -i /dev/hda or such will tell you maximum multisector supported. the only reason these aren't enabled AFAIK is that SOME drives don't, and when there's a problem it could cause data loss. The worker thread may just have been overtaking the prefetcher because dma was off and disk was slow. > > > hardware configuration, the behavior changes. > > I can see performance improvements when another thread is used. Also, i can > > see timing overlaps between two threads. i.e. when one thread is blocked on a > > page fault, other thread keeps working. > > Now, how can this behavior be explained , given the earlier argument. > > Is it that, a newer version of kernel has fixed the problem of the semaphore > > ? > > > No, that change won't happen until 2.5 > > I can only guess: > the other thread keeps working until it causes a page fault - with both > 2.4.1 and 2.4.2. > > I haven't followed the threads about the mm changes closely, but I > assume that the swapout behaviour changed, and that your worker thread > now runs without causing page faults. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Fwd: [LARTC] 1 adsl + 1 sdsl + masq + simultaneous incomming routes]
Mike Fedyk wrote: > [EMAIL PROTECTED] wrote: > > > > On Fri, 2 Mar 2001, Mike Fedyk wrote: > > > > > I have two dsl links, each with one ip, and a single gateway is assigned the ip > > > for each. > > > > > > ____ > > > | ADSL | | SDSL | > > > |__| |__| > > >\ / > > > \/ > > > ___|| > > > | gateway | > > > |_| > > > || > > > || > > > || > > >_||__ > > > | web | > > > |_| > > > > > > OK. > > > > > > The problem: I am able to have the web server use one or the other dsl, but not > > > both at the same time. > > > > > > If I have web set to sdsl, replies to queries that came from adsl go out on the > > > sdsl link. Also since masq is involved, it also responds with the sdsl ip. > > > > > > How can I have replies go back on the correct internet link? OH, btw, the web > > > server is NT, so I won't be able to modify any packets there... > > > > What I've done is to put two IPs on the server (your web server, in this > > case). You would then have the gateway send one IP out via ADSL, and the > > out via SDSL. > > > > There is no way I know of to make that work. > > > > -- > > --- > > Phil Brutsche [EMAIL PROTECTED] > > There has to be a better way. I'm forwarding this to LKML. Maybe they have a > better idea... > > I know the kernel keeps a route cache, is there something like a reverse MASQ > feature somewhere. Storing which incoming route + port number and keeping a > dynamic list... try www.liuxdoc.org search for iproute2 and netfilter. with 2.4. kernel, you can mark packets *before* they go through routing table, and the routing tablecan use mark value to choose which route to use, so if you use set up the NT box with two IP's, your firewall can mark packets based on destination (on webserver) IP. think of it like having two default routes... - 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: Forwarding broadcast traffic
Jon Masters wrote: > Hello, > I have a brain-dead application here which relies on broadcast > traffic for client/server discovery and I have a question with regard > to forwarding broadcast traffic. try bridging instead if ip forwarding. use netfilter too if you want > > > A small part of my local LAN looks like this: > > REST OF LAN > | > | (router eth1) > | > masquerading > router (kernel 2.2.14) > | > | (router eth0) > | >desktop (private IP) > boxen (kernel 2.4.2) > > * upgrading the router is not a problem[0]. > > I wish to have the router forward certain broadcast traffic coming > from either side out to the other (as well as itself). > > e.g. on desktop a broadcast udp packet (with a specified port) needs to > go not only to itself and the router but also the "REST OF LAN" part > too - and vice versa. Removing the router is not an option. > > I know this isn't a *nice* idea and ordinarily I wouldn't be jumping up > and down suggesting one throws broadcast traffic around however I need > to do this for various reasons and the solution appears to be > non-obvious at least to me[1]. > > I have considered the idea of creating a transparent bridge however I > would really rather not do that here for various reasons. > > I have posted this message to groups elsewhere however I have not yet > had any useful responses beyond basic instruction of IP forwarding, > etc. which is not what I need here :P > > Any ideas? I think this one has come up before but I could not find a > helpful answer in my archives. > > Appreciate your time, > --jcm > > P.S. My lkml feed at home is great but here it is not so could you > please CC me on replies thanks. > > [0] Yeah, yeah, I know 2.2.14 is old but it's an old router and when I > move that box over to Debian I'll upgrade the kernel at the same > time :P > [1] either due to general stupidity or tiredness, or both. > - - 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: Forwarding broadcast traffic
Jon Masters wrote: > Jeremy Jackson wrote: > > > try bridging instead if ip forwarding. use netfilter too if you want > > I mentioned bridging before - I don't want some kind of transparent > bridge, really so what I would need is for the router to be contactable > in the same way as before and for regular traffic to pass normally but > with a special arrangement for certain broadcast traffic. > > Is it possible to selectively bridge broadcast traffic in the way I have > described? > > Normally of course I'd have the router either being a standard router or > a bridge but in this case some kind of hybrid arrangement would be > preferable. > > Thanks for your help, > --jcm Well it you give the server an ip alias address that's on the subnet of the clients, bridge the two segments together, but use netfilter to drop all packets that aren't your broadcasts, it might do the trick. I'm not to familiar with bridging, but i'm confident that 2.4's netfilter can do it... you can filter/route based on pretty much *any* data in the packet, by manually specifying an arbitrary offset in the headers and bit pattern if necessary IIRC. if you know which port IP port it's easy. Can you be more specific... is this an IP broadcast? or ethernet only like IPX or NetBEUI? perhaps subnetting with "invalid" netmasks could cause broadcast to reach entire supernet even though subnets are on diff segments (in case of IP) - 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.2: What happened ? (No such file or directory)
" Frédéric L. W. Meunier" wrote: > Correction. I can umount the partitions, but I get the > following message: > > "can't link lock file /etc/mtab~: No such file or > directory (use -n flag to override)" > > And /etc/mtab isn't updated. Is your root filesystem mounted read-only at any point? (check with 'mount' look for ro in line for / filesystem) Check permissions on /etc, /etc/mtab, /etc/mtab~ - 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: Slight Time drift in linux by division fault
Erwin Six wrote: > Hello, > > I'm a senior Student in electronic Engineering. A lot of my work takes > place inside the network-part of the kernel, but now I'm confronted with > time. I designed a hardware-board whitch trys to synchronize I would study the xntpd daemon furthur before trying to reinvent the wheel. PC clock oscillators are notoriously inaccurate, the ntp documentation goes really in depth about the kernel and time, so try reading this first. Good luck! > > network-monitors by GPS. Electronicly this board is tested, and it has an > hardware resolution of about 1 usec (in phase, so in relative time). Now > I'm writing the device-driver that synchronizes the Linux-time system. If > I interrupt the kernel at the exact GPS-zero-time. And I watch the > do_timeoftheday() the seconds increases, but there is also a extra > increase of +-16 usec each second. So it seams that a linux second takes > 16usec more than one GPS second. Can I explain this with math? > > the cristal inside the computer ticks with a frequency of 1193180 Hz this > 16usec could be an fault of 16ppm whitch is rather big. But 2 diffrent > systems have the allmost drift (+-2). Or it can be caused by the division > inside the linux time-system (whitch is possible after you see this > calculations) > > If HZ = 100 then the LATCH of the PIT = (1193180 + HZ/2) / HZ = 11932 > so in 1 sec we have 1193200 ticks of the PIT which causes 100 > timer-interrupts. 1193200 ticks instead of 1193180 means that there are 20 > ticks to mutch inside of each second. or 20 * 1/1193180 = 16.7619 usec. or > 1 second to mutch every 16.5 hours (or 8.8 minutes a year). I've looked > the PLL closely but I can't find a mechanisme that compensates for this > problem, maybe I'm looking over it? Indeed 8.8 minutes is mutch, but I > think if I hadn't use a GPS, I wouldn't notice it. > > Why do I suppose the second option? If you play a little bit with the HZ > parameter, you can let your timeclock drift mutch faster just by taking a > HZ that has a big 1193180 % HZ. eg. 5000 Hz gives a latch of 291 which > causes 119500 instead of 1193180 or a drift of 1820 ticks = 1.525 ms! > > I have some solutions in mind to compensate this problem, but I have to > be sure. > Can somebody confirm this problem? - 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: Make Up to a Half Million Dollars from HOME in LESS than 12 months!
Opportunity Knocks wrote: > Dear Friend & Future Millionaire: > > AS SEEN ON NATIONAL TV : > ''Making over half million dollars every 4 to 5 months from your home for > an investment of only $25 U.S. Dollars expense one time'' > > THANK'S TO THE COMPUTER AGE AND THE INTERNET ! WOW, I can't believe I'm going to get paid to do linux hacking! Too bad, I already spent way more that $25 on my computer. > > == > BE A MILLIONAIRE LIKE OTHERS WITHIN A YEAR!!! > Before you say ''Bull'', please read the following. This is the letter you (snip, barf) - 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: [OFFTOPIC] Hardlink utility - reclaim drive space
Padraig Brady wrote: > Hmm.. useful until you actually want to modify a linked file, > but then your modifying the file in all "merged" trees. > Wouldn't it be cool to have an extended attribute > for files called "Copy on Write", so then you could > hardlink all duplicate files together, but when a file is > modified a copy is transparently created. > Actually should it be called "Copy On Modify"? since if > you copied a file there would be no need to make an actual > copy until the file was modified. > > The only problem I see with this is that you wouldn't have > enough space to store a copy of a file, what would you do > in this case, just return an error on write? > > Is there any way this could be extended across filesystems? > I suppose you could add it on top of existing DFS'? > > I could see many uses for this, like backup systems, but perhaps > a block level system is more appropriate in this case? > (like the just announced SnapFS). > > Is there any filesystem that supports this @ present? > > Padraig. > > William Stearns wrote: > > > Good day, all, > > Sorry for the offtopic post; I sincerely believe this will be > > useful to developers with multiple copies of, say, the linux kernel tree > > on their drives. I'll be brief. Please followup to private mail - > > thanks. > > Freedups scans the directories you give it for identical files and > > hardlinks them together to save drive space. Please see > > ftp://ftp.stearns.org/pub/freedups . V0.2.1 is up there; it has received > > some testing, but may yet contain bugs. > > I was able to recover ~676M by running it against 8 different > > 2.4.x kernel trees with different patches that originally contained ~948M > > of files. YMMV. > > I do understand there are better ways to handle this problem (cp > > -av --link, cvs? Bitkeeper, deleting unneeded trees, tarring up trees, > > etc.). See the readme for a little discussion on this. This is just one > > approach that may be useful in some situations. > > Cheers, > > - Bill snapFS might handle this - versioning, copy-on-write disk file clones... even finer grained: only modified blocks of a file are duplicated, not the entire file, and it does this in real-time. in the case of kernel, why not get the whole repository? CVS stores versions as diffs internally, saving space. - 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: How-To for PPPoE in v2.4.x?
[EMAIL PROTECTED] wrote: > Is there a How-To for getting the Linux v2.4.x PPPoE support to work? > I've searched for info but have mostly found sketchy references on getting > PPPoE to work with the v2.2 kernel. > I have been using PPPoE in the 2.4.0 kernel for about 2 months now. It's very nice. I used http://www.math.uwaterloo.ca/~mostrows/ just grab the tarball and compile. I bet it will work under 2.4.2 also. > > My system is running RedHat v6.2 and the v2.4.2 Linux kernel. I've built > PPP and PPPoE support into the kernel and I've installed the v2.4.0 PPP > software. I've got the /dev/ppp created by the RedHat installation and I > see "pppoe" in the /proc/drivers list of drivers. > > I've got a (PCMCIA-based) NIC that I know works as a plain non-PPPoE > device under v2.4.x. > > So what do I do now? Do I have to patch pppd to utilize the kernel's > new PPPoE support? Do I have to create a /dev/pppoe devnode? > > While I have a lot of experience with Ethernet networking on Linux, I am a > total PPP (let alone PPPoE) newbie. Please be gentle. :-) - 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 installation problem
[EMAIL PROTECTED] wrote: > Hi all, >I am trying to install Linux (redhat-7) on a ps/2 server-9595 > machine (mca ). I am booting from a floppy disk and using a custom build > 2.4.1 kernel image since there are problems booting the machine using the > installation image on redhat CD and also it is not CD bootable. The > problem is that after booting it asks for redhat CDROM and when I insert > the redhat CDROM it gives a message "I could not find a redhat linux CDROM > in any of your CDROM drives ". The CD drive is a SCSI device and I have > enabled SCSI cdrom in kernel compilation . Can any one help me . > > Thanks & Regards > Shiju Hi, I have a type 8560 PS/2... not the same as yours but I did install slackware on it once. I would suggest installing from a standard PC. Boot disks are very inflexible, since you don't have any utilities to poke around and figure out what's going on. Once you have a complete root filesystem, once you've got a kernel to recognise your scsi adapter, (and disk), you're off to the races, and can use all kinds of tools to look into the CDROM problem...BUT it's probably not going to recognise the disk either... check different virtual consoles with alt-f1, f2, etc: under a normal redhat boot disk, the different vc's will have diagnostic messages, ie kernel messages, list of modules being loaded, etc. maybe the best way is to be sure to compile kernel with support for scsi subsystem *in kernel* - not module, along with scsi-disk, scsi-cdrom, and your scsi host adapter. the last one may be the tricky one. you will have to figure out if it is supported. (the one in my PS/2 is at least for 2.0 kernel) if you can make the kernel on the boot disk use a smaller font, you will be able to see more of the messages at once. also, shift-PgUp should let you scroll back some of the messages. look for the kernel messages from your scsi host adapter driver... if you don't see any there's a problem! take a look inside your box and see what kind of scsi adapter it has. or use your reference disk to see what it is. post that here so someone (maybe me) can check for kernel support. Cheers, Jeremy - 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.2.19pre - Kernel Panic: no init found
Stephane GARIN wrote: > Hi, > > I tried with init=/bin/sh but no success. I download a 2.2.18 Kernel and I > use patch 2.2.19pre16 but no success too... I don't know why there is this > error with this 2.2.19 kernel but not with my 2.2.18 kernel. I'm ready to > send all technical information about my computer (PIII 650 with 256Mb and a > ABIT BX133-RAID mothercard). looks like you have a lot of partitions. maybe the kernel isn't using the right one for root filesystem? if using LILO to boot, make sure root= line for your new kernel is the same as old one. if using redhat on a large disk, it will set up the first partition as /boot filesystem, so kernel will mount it ok, but won't find any programs like init or sh on it. Let me know how this works out. > > > With Regards, > Stephane Garin > > -Message d'origine- > De : James Stevenson > Envoyé : samedi 3 mars 2001 18:58 > À : [EMAIL PROTECTED] > Objet : Re: 2.2.19pre - Kernel Panic: no init found > > Hi > > it would mean pass something like > init=/bin/sh > not the runlevel you want > > In local.linux-kernel-list, you wrote: > >Hi, > > > >I have a kernel panic with the patch 2.2.19pre16 that I test. I use a > 2.2.18 > >Kernel very well. I used the last patch on this kernel and make my kernel > >with sames parameters without error message. At the boot, I can see this : > > > >.. > >eth0: RealTek RTL8139 Fast Ethernet at 0xa800, IRQ 10, 00:50:fc:0b:60:70 > >eth1: RealTek RTL8139 Fast Ethernet at 0xac00, IRQ 11, 00:50:fc:1f:c1:98 > >Partition check: > > hda: hda1 hda2 < hda5 hda6 hda7 hda8 hda9 hda10 > > >Trying to vfree() noexistent vm area (c00f) > >VFS: Mounted root (ext2 filesystem) readonly. > >Freeing unused kernel memory: 68k freed > >Kernel panic: No init found. Try passing init= option to kernel. > > > > > > > >I tried to start with init=3 but no change. I send this information on this > >mailing list because I think that could be a bug. Sorry if it is a wrong > >action of me... > > - 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: VFS: Cannot open root device
Peter Samuelson wrote: > [Jeremy Jackson] > > try command 'man mkinitrd' under redhat for hints about initial > > ramdisk. > > I have been puzzled about this for quite some time. Why exactly does > everyone always recommend using 'mkinitrd' on Red Hat systems? It > seems to me that if you are compiling a kernel for a specific server > anyway, it is a much more reliable proposition to just compile in > whatever drivers you need to boot. > > initrd's are inherently clumsy and fragile, to my way of thinking. > I've always thought they should only be used to support diverse or > unknown hardware, or odd cases like crypto loopback root. Are there > other advantages to 'mkinitrd' in the case of a custom kernel for a > single machine? > no the reason redhat uses it is to allow a generic kernel for everyone. having *ALL* drivers in kernel would make it huge, and some drivers conflict with each other (not many) so they couldn't all be in there. If you have made a custom kernel (that is configured properly) you don't need to bother. The question is if you configured it properly :) I would suggest taking a config from redhat (it puts them in /usr/src/linux/configs) and just tweaking that. (sorry if i already said that once) other pitfalls include not having the right root= entry (or missing one) in lilo.conf. > > Peter > - > 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: conducting TCP sessions with non-local IPs
Mike Fedyk wrote: > > [snip] > > > > /sbin/ip addr add 10.2.0.0/24 dev eth0 > > > > Tada > How would you deal with the other computer responding to the host "port not > reachable"? What the hell kind of monster are you making? There's got to be another way. - 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: Ide Hot-swaping?
Pozsar Balazs wrote: > Is it possible to hot-swap ide drives and re-detect them? > Does 'normal' Pc-hardware allow it? read a recent man page for hdparm and you will see kernel allows remove/add ide interface. scripts with correct parameter usage are in contrib directory of hdparm source. IDE maintainer has code to electrically turn off (tristate) ide channels on most PC ide chips, but is waiting to demonstrate at an industry conference before releasing to public. > > > thanks, > Balazs Pozsar. > > - > 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 and PPPoE problem
Martin Hicks wrote: > Hello, > > I'm using PPPoE with an i586 machine running 2.4.2. are you using the kernel pppoe or the user-space one (rp-pppoe, etc)? did it work on other kernels? > > > The machine connects fine and allows network traffic to pass > through the link. > > However, certain websites seem to choke. > (notable ones are www.chapters.ca and www.hp.com) > > Using Lynx or Netscape I get the same results, a few bytes of > traffic are received and then nothing (eventually the connection > times out). > > The same does not happen in windows. (ugh) > > I have not encountered any machine that I have telnet/ftp/ssh > access to that breaks in this way so I can only confirm that http traffic > is not working. > > This gateway machine does masquerading, and internal machines and the external > machine react the same way. are you positive the external (2.4.2 machine, right?) acts this way? you can send me a tcpdump trace of a session or two that chokes. > > > TIA > mh > > Here is some useful info: > > mort@galileo:~$ uname -a > Linux galileo 2.4.2 #4 Thu Feb 22 14:13:23 EST 2001 i586 unknown > > mort@galileo:~$ /sbin/ifconfig ppp0 > ppp0 Link encap:Point-to-Point Protocol > inet addr:209.217.122.37 P-t-P:209.217.122.1 Mask:255.255.255.255 > UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1480 Metric:1 > RX packets:1272056 errors:0 dropped:0 overruns:0 frame:0 > TX packets:1476697 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:3 > RX bytes:430171737 (410.2 Mb) TX bytes:1260803415 (1202.3 Mb) > > mort@galileo:~$ /sbin/route > Kernel IP routing table > Destination Gateway Genmask Flags Metric RefUse Iface > magma * 255.255.255.255 UH0 00 ppp0 > 192.168.69.0* 255.255.255.0 U 0 00 eth0 > default magma 0.0.0.0 UG0 00 ppp0 > > -- > Martin Hicks || [EMAIL PROTECTED] > Use PGP/GnuPG || DSS PGP Key: 0x4C7F2BEE > Beer: So much more than just a breakfast drink. > > >Part 1.2Type: application/pgp-signature - 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: Network init script causes 2.2.18 kernel oops (tulip driver)
Matthew Callaway wrote: > Greetings, > > This is a reproducible oops, and my guess is that it's related to > the tulip driver included in the 2.2.18 source tree. We're using > a D-Link 4 port NIC, and it appears that it doesn't work well with > IPV6 interfaces. I have had problems with this NIC as well... Redhat's installer/kudzu tries to use de4x5 (sp?) module ... bad news. But it works fine using old_tulip module with only IPv4. Same with 2.2 series and 2.4 series kernels. FYI > > > Keywords: linux kernel-2.2.18 tulip D-Link 4-port NIC DFE-570 TX - 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: UDMA 100 / PIIX4 question
Tim Moore wrote: > [EMAIL PROTECTED] wrote: > > I have an IBM DTLA 307030 (ATA 100 / UDMA 5) on an 815e board (Asus CUSL2), which >has a PIIX4 controller. > > ... > > My problem is that (according to hdparm -t), I never get a better transfer rate >than approximately 15.8 Mb/sec. I achieve this when DMA is enabled, - without it I >fall back to about 5 Mb /sec. No amount of fiddling with other hdparm settings makes >any difference. > > ... > > 15MB/s for hdparm is about right. Yes, since hdparm -t measures *SUSTAINED* transfers... the actual "head rate" of data reads from disk surface. Only if you read *only* data that is alread in harddrive's cache will you get a speed close to the UDMA mode of the drive/controller. The cache is around 1Mbyte, so for a split-second re-read of some data > > > "...four IDE devices can be supported in Bus Master mode. > PIIX4 contains support for "Ultra DMA/33" synchronous DMA > compatible devices." > > http://developer.intel.com/design/intarch/techinfo/440BX/PIIX4_intro.htm > > -- > - > 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: UDMA 100 / PIIX4 question
Tim Moore wrote: > [EMAIL PROTECTED] wrote: > > I have an IBM DTLA 307030 (ATA 100 / UDMA 5) on an 815e board (Asus CUSL2), which >has a PIIX4 controller. > > ... > > My problem is that (according to hdparm -t), I never get a better transfer rate >than approximately 15.8 Mb/sec. I achieve this when DMA is enabled, - without it I >fall back to about 5 Mb /sec. No amount of fiddling with other hdparm settings makes >any difference. > > ... > > 15MB/s for hdparm is about right. You should be able to get about 30 MB/s at the start of the disk (zone 0) according to IBM's datasheet at http://ssdweb01.storage.ibm.com/techsup/hddtech/prodspec/dtla_spw.pdf so if you were testing say /dev/hda1 which is at the start of the disk it should be faster. Try hdparm -i /dev/hda (or whatever) .. . note the reported MaxMultSect= value, and put it in place of X in command: hdparm -u 1 -d 1 -m X -c 1 /dev/hda Cheers, Jeremy PS - please let me know if this fixed your problem, since I have a system with the same motherboard. - 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 should better cope with power failure
Brian Gerst wrote: > "Richard B. Johnson" wrote: > > > > On Mon, 19 Mar 2001, Otto Wyss wrote: > > > > > Lately I had an USB failure, leaving me without any access to my system > > > since I only use an USB-keyboard/-mouse. All I could do in that > > > situation was switching power off and on after a few minutes of > > > inactivity. From the impression I got during the following startup, I > > > assume Linux (2.4.2, EXT2-filesystem) is not very suited to any power > > > failiure or manually switching it off. Not even if there wasn't any > > > activity going on. > > > > > > Shouldn't a good system allways try to be on the save side? Shouldn't > > > Linux try to be more fail save? There is currently much work done in > > > getting high performance during high activity but it seems there is no > > > work done at all in getting a save system during low/no activity. I > > > think this is a major drawback and should be addressed as fast as > > > possible. Bringing a system to save state should allway have a high priority. > > > > > > How could this be accomplished: > > > 1. Flush any dirty cache pages as soon as possible. There may not be any > > > dirty cache after a certain amount of idle time. > > > 2. Keep open files in a state where it doesn't matter if they where > > > improperly closed (if possible). > > > 3. Swap may not contain anything which can't be discarded. Otherwise > > > swap has to be treated as ordinary disk space. > > > > > > These actions are not filesystem dependant. It might be that certain > > > filesystem cope better with power failiure than others but still it's > > > much better not to have errors instead to fix them. > > > > > > Don't we tell children never go close to any abyss or doesn't have > > > alpinist a saying "never go to the limits"? So why is this simple rule > > > always broken with computers? > > > > > > > Unix and other such variants have what's called a Virtual File System > > (VFS). The idea behind this is to keep as much recently-used file stuff > > in memory so that the system can be as fast as if you used a RAM disk > > instead of real physical (slow) hard disks. If you can't cope with this, > > use DOS. > > At the very least the disk should be consistent with memory. If the > dirty pages aren't written back to the disk (but not necessarily removed > from memory) after a reasonable idle period, then there is room for > improvement. They are. If you leave your machine one for a minute or so (probably less is ok, but I don't know) the kernel will flush dirty buffers... fsck will complain, but the file's *data* blocks will be on the disk. There are way more reasons that this is a silly and annoying thread. You should read more about things like asynchronous/synchronous filesystems, lazy-write cacheing, etc, etc,. If you know how to write software and/or configure your system, you can avoid all of these problems. Or use a journaling filesystem ext3/xfs, etc. But I tire of this... - 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 should better cope with power failure
"Richard B. Johnson" wrote: > On Mon, 19 Mar 2001, Brian Gerst wrote: > [SNIPPED...] > > > > > At the very least the disk should be consistent with memory. If the > > dirty pages aren't written back to the disk (but not necessarily removed > > from memory) after a reasonable idle period, then there is room for > > improvement. > > > > Hmmm. Now think about it a minute. You have a database operation > with a few hundred files open, most of which will be deleted after > a sort/merge completes. At the same time, you've got a few thousand > directories with their ATIME being updated. Also, you have thousands > of temporary files being created in /tmp during a compile that didn't > use "-pipe". > > If you periodically write everything to disk, you don't have many > CPU cycles available to do anything useful. > > It is up to the application to decide if anything is 'precious'. > If you've got some database running, it's got to be checkpointed > with some "commitable" file-system so it can be interrupted at any time. > > If you make your file-systems up of "slices", you can mount the > executable stuff read/only. Currently, only /var and /tmp need to > be writable for normal use, plus any user "slices", of course. > -- Yes I know you need to modify /etc/stuff occasionally (startup > and shutdown, plus an occasional password change). I proposed > a long time ago that /etc/mtab get moved to /var. so how does mount update /var/mtab when mounting var? he he. Actually, I think /etc/mtab is not needed at all. Originally, UNIX used to put as much onto the disk (and not in "core") as possible. so much state information related only to one boot-cycle was taken out of kernel and stored on disk. /var/run/utmp, /etc/mtab, , rmtab, and many others. all are invalidated by a reboot, and are yet stored in non-volatile storage. kernel memory is not swappable, so they manually separated out the minimum needed in core. Linux currently has a lot of this info in core, and maintains the disk files for backwards compatibility. in the case of /etc/mtab, I believe /proc/mounts has the same info. It appears to be in the same format as /etc/mtab, so most of the groundwork has already been done. i've considered trying just changing /etc/mtab to /proc/mounts in some utilities, to remove the need for read-write root. This (and other cases) would guarantee consistency (look at /etc/mtab after restart in single user more - ugh) I wonder if embedded folks would like to at least keep the old behaviour as a compile-time option; they're in almost the same boat as early (64k core memory) unix folks. My favorite compromise between journaling and performance is the compaq smart array controllers, with a battery-backed sram write cache; they can do (fast)lazy writes and still be perfectly reliable. plus they keep *everything* reliable, not just metadata. I find this a fascinating topic... the ultimate would be to use the nvram (it's mostly empty if using LinuxBIOS) to store a clean shutdown flag, and/or a system heartbeat timestamp (like syslogd's)... only this timestamp would let the hdd spin down (not hit every 20 minutes or so with a timestamp log entry) and not wear out a flash disk based system. Regards, Jeremy - 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: IDE DMA resets with ALI15X3 on Aladdin V
Jules Bean wrote:
> Hi,
>
> I have an intermittent problem with my IDE setup:
>
> pear# dmesg | grep -i ide
> Uniform Multi-Platform E-IDE driver Revision: 6.31
> ide: Assuming 33MHz system bus speed for PIO modes; override with
> idebus=xx
> ALI15X3: IDE controller on PCI bus 00 dev 78
> ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:DMA, hdb:pio
> ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:DMA, hdd:DMA
> ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
> ide1 at 0x170-0x177,0x376 on irq 15
> scsi0 : SCSI host adapter emulation for IDE ATAPI devices
> {snip}
>
> It works absolutely fine under normal load; I see the very occasional
>
> Mar 18 12:23:01 pear kernel: hda: dma_intr: status=0x51 { DriveReady
> SeekComplete Error }
> Mar 18 12:23:01 pear kernel: hda: dma_intr: error=0x84 {
> DriveStatusError BadCRC }
>
This is clue #1 - BadCRC
>
> but they don't seem to affect performance.
>
> However, very occasionally, normally when the HD is under very heavy
> load, I get messages like this:
>
> Mar 20 10:24:05 pear kernel: hda: timeout waiting for DMA
> Mar 20 10:24:05 pear kernel: ide_dmaproc: chipset supported
> ide_dma_timeout func only: 14
> Mar 20 10:24:05 pear kernel: hda: irq timeout: status=0x58 {
> DriveReady SeekComplete DataRequest }
> Mar 20 10:24:05 pear kernel: hda: status timeout: status=0xd0 { Busy }
> Mar 20 10:24:05 pear kernel: hda: drive not ready for command
> Mar 20 10:24:05 pear kernel: ide0: reset: success
>
> This is accompanied by a freeze of the machine, which in this
> particular instance sorted itself out. Sometimes, the machine goes
> down hard, causing some disk corruption (always minor, thankfully, so
> far).
>
> This all sounds very like that described in the thread which starts at
> http://www.uwsg.iu.edu/hypermail/linux/kernel/0006.1/0924.html
> although he didn't seem to get an actually crashes from it.
>
> Sometimes I also hear alarming clicking sounds from the disk; on those
This is clue #2.
>
> occasions, the crash is hard, and the machine has to be reset.
>
> Is this a hardware fault? I would think so, except for the
> intermittent dma_intr errors suggesting there could be a motherboard
> problem too?
>
> The disk is as follows:
>
> pear# cat /proc/ide/hda/model
> Maxtor 91080D5
If memory serves me correctly, this disk is the same model as
one I send back for RMA... I think your disk is toast.
you could try using badblocks to scan it, prefferably in read-write
mode (you'll have to move your data to another disk first, of course,
since this erases data) You could try just a read scan first.
The clicking is likely the drive trying to re-read the bad sectors.
You should try to exchange it under warranty, before your data
disappears.
You could try using an Ultra-DMA 66 cable to improve signal quality,
even though this chipset (I think) only supports UDMA33. Also,
try it with the drive by itsself (not sharing cable with a cdrom or
another disk) on an interface.
Cheers,
Jeremy
>
>
> (It does normally seem to be that disk, but the other disk is much
> smaller anyhow).
>
> I do also sometime see problems with hdd, which is an ATAPI
> cd-rom. This normally happens after there's been some problem with
> hda, and I get:
{snip}
-
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: UDMA 100 / PIIX4 question
Holger Lubitz wrote: > [EMAIL PROTECTED] wrote: > > > > On Mon, 19 Mar 2001 12:17:38 -0800 > > Tim Moore <[EMAIL PROTECTED]> wrote: > > > > > Apologies for the too brief answer. Sustained real world transfer rates > > > for the PIIX4 under ideal > > > setup conditions and a quiet bus are 14-18MB/s. > > I dare to disagree. These numbers are from an Asus P2L97-DS (Dual P2, > Intel 440LX chipset with PIIX4) with an IBM DTLA 307045: Yes this is why I originally replied to the post... but he's not using a PIIXx at all, but the IDE chip on an Intel 815 motherboard. I'm not sure if they use the same driver , but I don't think so. > > > /dev/hda5: > Timing buffer-cache reads: 128 MB in 1.21 seconds =105.79 MB/sec > Timing buffered disk reads: 64 MB in 2.30 seconds = 27.83 MB/sec > > /dev/hda5 is the outermost linux partition, starting at cyl 256. > > (if you don't count hdparm measurements as real world transfer rates - > linear read as measured by bonnie is 26.3 MB/s). > > > There is a Win partition - so I do not think I am at the start of the drive. > > > > Then hdparm -tT /dev/hda > > > > /dev/hda: > > Timing buffer-cache reads: 128 MB in 1.04 seconds =123.08 MB/sec > > Timing buffered disk reads: 64 MB in 4.08 seconds = 15.69 MB/sec > > Would your windows partition by any chance be at the beginning of the > disk? > hdparm speed measurements differ by filesystem (i have no idea why, this is false. They may differ by partition, since different parts (zones) of a modern disk have different recording densities and therefore transfer rates. IBM's spec sheet says rates vary from 15MB/sec to 31MB/sec... it he's seeing 15MB/sec, maybe he should try the other end of the disk. can you verify this? try hdparm -t /dev/hda1 instead of hda5 (if those are on opposite ends of the disk) include output of fdisk so we can see partition layout, and results of hdparm on different areas. > > since they don't go through it - maybe some interaction with the > buffering code). > > if you are testing a windows partition, you can expect to see > significantly lower values for hdparm: > > /dev/hda1: > Timing buffer-cache reads: 128 MB in 1.65 seconds = 77.58 MB/sec > Timing buffered disk reads: 64 MB in 3.48 seconds = 18.39 MB/sec please show us your partition table. > > > Remarkably /dev/hda benches slightly better, even though the 64 MB read > are nearly the same as for hda1: > > /dev/hda: > Timing buffer-cache reads: 128 MB in 1.40 seconds = 91.43 MB/sec > Timing buffered disk reads: 64 MB in 3.06 seconds = 20.92 MB/sec > > I also noticed that operations on a lot of files (like scanning for all > files in a filesystem as done by updatedb) got really slow with the 2.4 > vfat fs, with a very high percentage (in the 90s) of CPU time attributed > to "system". Has anybody else noticed this? - 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 Worm (fwd)
Dax Kelson wrote: > Gerhard Mack said once upon a time (Fri, 23 Mar 2001): > > > On Fri, 23 Mar 2001, Bob Lorenzini wrote: > > > > > I'm annoyed when persons post virus alerts to unrelated lists but this > > > is a serious threat. If your offended flame away. > > > > This should be a wake up call... distributions need to stop using product > > with consistently bad security records. > > This TSIG bug in BIND 8 that is being exploited was added to BIND 8 by the > same team who wrote BIND 9. > > In fact the last two major remote root compromises (TSIG and NXT) for BIND > 8 was in code added to BIND 8 by the BIND 9 developers. You could say new code in general causes security holes... don't fix it and you won't break it. There is the security principle of least privilege though... RH7 (and earlier I think) run bind drops root and runs as user named after opening a listening socket, so I don't think a bind compromise could retrieve the /etc/shadow file and modify system binaries... and RH7.1(beta) will use capabilities to furthur restrict privileges given to bind(v9). (not root ever) - 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: /proc/config idea
Ian Soboroff wrote: > [sorry this doesn't have proper References: headers, i read the list > off the hypermail archive.] > > there was some discussion of whether the kernel should emit a > /proc/config or some such for purposes of bug reporting, but that > seems to be a lot of bloat. > > instead, why not try to point to a canonical location for a config > copy (we already basically do this with ksymoops and System.map), and > instead have a /proc/config-hash which emits a (precomputed) MD5 hash > of the .config file it was compiled with? > > this way, you could check possible configs (Debian for example likes > to stash a copy in /boot, like System.map) and also know if they were Yes, I like this. I do this manually, it allows reproducability, and incremental modifications, tracing how that kernel on that problem system was made... I think the ultimate would be to put all of .config (gzipped?) in a new ELF section without the Loadable attribute... I wish System.map was the same. The you're guaranteed you know how a kernel on disk was configured. To correlate a running kernel to one on disk (vmlinuz) you have LILO... it appends an environment variable to the kernel command line with the name of the file it booted. This is not infallable, since LILO maps disk sectors, only using the filesystem at map install time. Permaps an md5sum of the .text ELF section would conclusively link the in-core kernel with an on-disk vmlinuz? Shouldn't be hard to do with objcopy and /proc/kmem? > > the right ones. > > the one problem that comes to mind right now is modules, which needn't > correspond to a full kernel .config. Well it's a step... Comments anyone? - 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: Event tools, do they exist
I think all of this has been done... you should check out the Linux Trace Toolkit. george anzinger wrote: > This is an attempt to look in the wheel locker. > > I need a simple event sub system for use in the kernel. I envision at > least two types of events: the history event and the timing event. > > The timing event would keep track of start/stop times by class. If, for > example, I wanted to know how much time the kernel spends doing the > recalc in schedule() I would put and event start in front of it and an > end at the other end. The sub system would note the first event time > and the cumulative time between all starts and stops on the same event. > When reported by /proc/ it would give the total event time, the elapsed > time and the % of processor time for each of the possibly several > classes. > > The history event would record each events time, location, data1, > data2. It would keep N of these (the last N) and report M (M= /proc/. This list should also be kept in a format that a simple > debugger can easily examine. > > Somebody must have written these routines and have them in their > library. Sure would help if I could have a peek. - 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: Block device strategy and requests
Malcolm Beattie wrote: > I'm designing a block device driver for a high performance disk > subsystem with unusual characteristics. To what extent is the > limited number of "struct request"s (128 by default) necessary for > back-pressure? With this I/O subsystem it would be possible for the > strategy function to rip the requests from the request list straight > away, arrange for the I/Os to be done to/from the buffer_heads (with > no additional state required) with no memory "leak". This would > effectively mean that the only limit on the number of I/Os queued > would be the number of buffer_heads allocated; not a fixed number of > "struct request"s in flight. Is this reasonable or does any memory or > resource balancing depend on the number of I/Os outstanding being > bounded? > > Also, there is a lot of flexibility in how often interrupts are sent > to mark the buffer_heads up-to-date. (With the requests pulled > straight off the queue, the job of end_that_request_first() in doing > the linked list updates and bh->b_end_io() callbacks would be done by > the interrupt routine directly.) At one extreme, I could take an > interrupt for each 4K block issued and mark it up-to-date very > quickly making for very low-latency I/O but a very large interrupt > rate when I/O throughput is high. The alternative would be to arrange > for an interrupt every n buffer_heads (or based on some other > criterion) and only take an interrupt and mark buffers up-to-date on I believe it is common practice for this type of problem is to mix both approaches: Wait for a certain number of requests *OR* a timeout, whichever comes first. Then, if there's not much IO, things are still guaranteed to be updated reasonably quickly. If io is heavy, then things will be updated in large chunks, becoming more efficient (fewer interrupts) when it is needed most. > > each of those). Are there any rules of thumb on which is best or > doesn't it matter too much? > - 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: busmaster question
daniel sheltraw wrote: > Hello kernel listees > > I have a busmaster question I am hoping you can help me with. > If a PCI device is acting as a busmaster and the processor initiates a > read/write to another device on the PCI bus while the busmater-device is in > control of the bus what happens to the instructions initiated by the > processor? Are they never seen by the device that the processor > is trying to read/write? An excellent book about PCI is Mindshare's "PCI System Architecture" Third (or later?) Edition. In the scenerio you outlined, the device currently holding the bus would continue until it's latency timer expired (if it already hadn't), stalling the CPU, then the master which has been granted access next to the bus would start it's access. If the only other master requesting access is the CPU, then it will get it. If there are others, then it is implementation dependent who has highest arbitration priority. Note that since main memory is not on the PCI bus, the CPU can cary on unless it tries to access video memory, IDE registers, etc. for IO. - 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/
