Thanks.
Alex
-----Original Message-----
From: owner-linux-kernel-digest@vger.rutgers.edu
<owner-linux-kernel-digest@vger.rutgers.edu>
To: linux-kernel-digest@vger.rutgers.edu
<linux-kernel-digest@vger.rutgers.edu>
Date: Thursday, September 16, 1999 10:49 AM
Subject: linux-kernel-digest V1 #4467
>
>linux-kernel-digest Thursday, 16 September 1999 Volume 01 : Number
4467
>
>In this issue:
>
> Re: Linux 2.3.18ac5
> SB PnP IDE driver
> Re: ext2 file sizes
> 2.3.18ac[4] PCMCIA...
> Re: problem with system clock
> Re: NFS problem: __nfs_fhget: inode still busy
> Re: ext2 file sizes
> Re: problem with system clock
> Re: ext2 file sizes
> /proc/bus/usb/000 will not work correctly when usb is compiled into kernel
> Re: 2.3.18ac[4] PCMCIA...
> Re: ext2 file sizes
> Re: Linux 2.3.18ac5
> strange mounting problem
> [patch] __flush_one_page() on i386
> Re: [patch] __flush_one_page() on i386
> Symbios DAC960 and Quad Xeon
> Re: ext2 file sizes
> Re: State of USB drivers
> Re: 2.2.12: serial driver swapping characters?
> [PATCH] console alertness - notifying of console activities
> Email subject line
> Re: Mouse input corrupted under X 3.3.3.1 with kernel 2.2.12
> > 15K simultaneous connections EXAMPLE program/OS config needed, was: Re:
POSIX aio vs completion ports
> Re: [patch] __flush_one_page() on i386
> Re: Email subject line
> Re: Email subject line
> Re: Resource Limits Architecture
> Re: Email subject line
> oops when insmodding msp3400, bttv 0.6.4, linux 2.2.12
> 2.2.18ac5 NFS client bug
> Problem in inserting module
> Re: Lockups - lost interrupt
>
>See the end of the digest for information on subscribing to the
linux-kernel
>or linux-kernel-digest mailing lists.
>
>----------------------------------------------------------------------
>
>From: Richard Guenther <zxmpm11@student.uni-tuebingen.de>
>Date: Thu, 16 Sep 1999 12:04:24 +0200 (METDST)
>Subject: Re: Linux 2.3.18ac5
>
>On Thu, 16 Sep 1999, Alan Cox wrote:
>
>>
>> Ok give this a spin. We need to sort out the modules/setup argument thing
yet.
>
>Note that a fix using MODULE_NAME() _will_ break the current semantics
>of some modules:
>- - we (really) should enforce everyone to have a MODULE_NAME (can we get
> a default out of __FILE_NAME__ with some tricky macro??)
>- - some already have a prefix encoded into their arguments (isapnp springs
> into my mind) - those will have to be ripped off - and it "breaks"
> backward-compatibility, as the prefixes are not always like "isapnp_"
>
>now, well if its easy, I'll look into it.
>
>Richard.
>
>
>- --
>Richard Guenther <richard.guenther@student.uni-tuebingen.de>
>PGP: 2E829319 - 2F 83 FC 93 E9 E4 19 E2 93 7A 32 42 45 37 23 57
>WWW: http://www.anatom.uni-tuebingen.de/~richi/
>
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: Antonio Miguel Ferreira Marques Trindade
<trindade@student.dei.uc.pt>
>Date: Thu, 16 Sep 1999 11:17:20 +0100 (WET DST)
>Subject: SB PnP IDE driver
>
> Now that the kernel has ISA PnP support, is it going to be possible to
>use the IDE port on this card? I am desperatly needing one more IDE port
>so in addition to my already filled 4. I tried over and over to put the
>IDE driver in a module and boot the system through the initrd method but
>without success and I REALLY NEED that IDE port working?
>
>- --
> Regards,
> Antonio Trindade.
>
>/--------------------------------------------------------------------------
-\
>|Timor Loro Sae will prevail!!! | F.C.T. da Universidade de Coimbra
|
>|ux RuleZ Linux RuleZ Linux Rule| Antonio Miguel Ferreira Marques Trindade
|
>|-------------------------------| PGP Public key available by finger
|
>|Jean-Michel Jarre is very cool!| Coimbra, PORTUGAL |
>|--------------------------------------------------------------------------
-|
>| E-mail address: trindade@student.dei.uc.pt |S/2 OS/2 OS/2 OS/2 OS/2 OS/2
O|
>\--------------------------------------------------------------------------
-/
>
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: David Weinehall <tao@acc.umu.se>
>Date: Thu, 16 Sep 1999 12:31:38 +0200 (MET_DST)
>Subject: Re: ext2 file sizes
>
>On Thu, 16 Sep 1999, Alexander Kjeldaas wrote:
>
>> On Wed, Sep 15, 1999 at 11:48:07AM -0400, Blankenship, Keith wrote:
>> > I am having some difficulty with the ext2 file systems. I need to
generate a
>> > file that will be > 5 Gigabytes, and there appears to be a file size
cap at
>> > approximately 2 Gig. I am running what appears to be a version 2.0.36
>> > Kernel. Is there anything I can adjust, or do to increase the maximum
file
>> > size? Or is there a newer kernel that may work?
>> >
>>
>> You will have to run another OS like FreeBSD for this to work - or
>> wait for Linux to catch up. Which will probably take some time.
>
>I'd say no on both claims here.
>
>a.) (most simple solution) Get an Alpha, Sparc64 or Power64 (not PPC)
>based machine
>b.) I don't believe Matti Aarnio's patches are too far away...
>
>Of course, at least for video & audio, using Raw-IO would probably be a
>third alternative.
>
>/David
> _ _
> // David Weinehall <tao@acc.umu.se> /> Northern lights wander \\
>// Project MCA Linux hacker // Dance across the winter sky //
>\> http://www.acc.umu.se/~tao/ </ Full colour fire </
>
>
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: John Michael Clemens <clemej@rpi.edu>
>Date: Thu, 16 Sep 1999 06:33:21 -0400 (EDT)
>Subject: 2.3.18ac[4] PCMCIA...
>
>what is the status of the PCMCIA merge? I can't seem to get 2.3.18ac4 to
>compile on my laptop, and it's barfing on the pcmcia code in
>drivers/pcmcia (i have it trying to compile in, and not as a module).
>After changing some things in the makefile in that directory, it compiled
>and built a pcmcia_core.o file. But on linking the entire kernel, it
>seemed to be looking for a pcmcia.o file in that directory which does not
>exist. Haven't tried it as a module yet....
>
>Any pointers? Alan?
>
>john.c
>
>- - --
>/* John Clemens http://www.rpi.edu/~clemej _/ I like cats too, */
>/* ICQ: 7175925 clemej@rpi.edu _/ Lets exchange recipies */
>/* RPI Comp. Eng. 2000, Linux Parllel/Network/OS/Driver Specialist */
>
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: Andrea Arcangeli <andrea@suse.de>
>Date: Thu, 16 Sep 1999 12:33:44 +0200 (CEST)
>Subject: Re: problem with system clock
>
>On Thu, 16 Sep 1999, Herbert Huber wrote:
>
>>motherboard used is an ASUS P2B-DF. Trying to set the BIOS clock via
>>the /sbin/clock or the /sbin/hwclock
>>commands fail. As probable reason for this behaviour the syslog file is
>>full of entries like:
>>
>>Sep 16 07:31:23 lxsrv2 kernel: set_rtc_mmss: can't update from 50 to 1
>>Sep 16 07:32:24 lxsrv2 kernel: set_rtc_mmss: can't update from 50 to 2
>>Sep 16 07:33:25 lxsrv2 kernel: set_rtc_mmss: can't update from 50 to 3
>>Sep 16 07:34:26 lxsrv2 kernel: set_rtc_mmss: can't update from 50 to 4
>
>You forgot to specify that you are running ntpd ;). It's a SMP race
somewhere.
>I didn't gone into that yet.
>
>Andrea
>
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: Paul Jakma <paul@clubi.ie>
>Date: Thu, 16 Sep 1999 11:36:47 +0100 (IST)
>Subject: Re: NFS problem: __nfs_fhget: inode still busy
>
>Hi Trond.
>
>Thanks for the patch. I'll give it a go as soon as i can.
>
>Incidentally, how does the stale inode persist across reboots? I
>presume it must be cached somewhere? But where? I've cleared out the
>server's state cache, and i don't know where it could be cached on
>the client.
>
>thanks,
>
>Paul Jakma.
>
>On 16 Sep 1999, Trond Myklebust wrote:
>
> Paul Jakma <paul@clubi.ie> writes:
>
> > I have an nfs client which virtually hangs immediately after boot. it
> > continually prints out the message:
> >
> > __nfs_fhget: inode 8227 still busy, i_count=1
> >
> > This happens just after finishing executing rc.local. (RH5 boot-up
> > scripts). It's then supposed to start xdm, but never get's that far.
> > Inode number is always the same.
>
> This is due to the stale inode code getting activated, and trying to
> clean out an inode that is in use. I have a patch which softens the
> stale inode code which may (or may not) help.
>
> Please try it out and see if it helps...
>
> Cheers,
> Trond
>
> diff -u --recursive --new-file linux-2.2.12.orig/fs/dcache.c
linux-2.2.12/fs/dcache.c
> --- linux-2.2.12.orig/fs/dcache.c Mon Apr 26 08:17:56 1999
> +++ linux-2.2.12/fs/dcache.c Mon Aug 30 16:13:24 1999
> @@ -168,6 +168,11 @@
> int d_invalidate(struct dentry * dentry)
> {
> /*
> + * If it's already been dropped, return OK.
> + */
> + if (&list_empty(&dentry->d_hash))
> + return 0;
> + /*
> * Check whether to do a partial shrink_dcache
> * to get rid of unused child entries.
> */
> diff -u --recursive --new-file linux-2.2.12.orig/fs/nfs/dir.c
linux-2.2.12/fs/nfs/dir.c
> --- linux-2.2.12.orig/fs/nfs/dir.c Mon Aug 9 21:04:57 1999
> +++ linux-2.2.12/fs/nfs/dir.c Mon Aug 30 16:15:54 1999
> @@ -395,13 +395,14 @@
> * If mtime is close to present time, we revalidate
> * more often.
> */
> +#define NFS_REVALIDATE_NEGATIVE (1 * HZ)
> static inline int nfs_neg_need_reval(struct dentry *dentry)
> {
> - unsigned long timeout = 30 * HZ;
> + unsigned long timeout = NFS_ATTRTIMEO(dentry->d_parent->d_inode);
> long diff = CURRENT_TIME - dentry->d_parent->d_inode->i_mtime;
>
> - if (diff < 5*60)
> - timeout = 1 * HZ;
> + if (diff < 5*60 && timeout > NFS_REVALIDATE_NEGATIVE)
> + timeout = NFS_REVALIDATE_NEGATIVE;
>
> return time_after(jiffies, dentry->d_time + timeout);
> }
> @@ -462,12 +463,8 @@
> goto out_bad;
>
> /* Filehandle matches? */
> - if (memcmp(dentry->d_fsdata, &fhandle, sizeof(struct nfs_fh))) {
> - if (!list_empty(&dentry->d_subdirs))
> - shrink_dcache_parent(dentry);
> - if (dentry->d_count < 2)
> - goto out_bad;
> - }
> + if (memcmp(dentry->d_fsdata, &fhandle, sizeof(struct nfs_fh)))
> + goto out_bad;
>
> /* Ok, remeber that we successfully checked it.. */
> nfs_renew_times(dentry);
> @@ -476,6 +473,9 @@
> out_valid:
> return 1;
> out_bad:
> + d_drop(dentry);
> + if (!list_empty(&dentry->d_subdirs))
> + shrink_dcache_parent(dentry);
> if (dentry->d_parent->d_inode)
> nfs_invalidate_dircache(dentry->d_parent->d_inode);
> if (inode && S_ISDIR(inode->i_mode))
> diff -u --recursive --new-file linux-2.2.12.orig/fs/nfs/inode.c
linux-2.2.12/fs/nfs/inode.c
> --- linux-2.2.12.orig/fs/nfs/inode.c Mon Aug 9 21:05:05 1999
> +++ linux-2.2.12/fs/nfs/inode.c Mon Aug 30 16:14:37 1999
> @@ -492,6 +492,48 @@
> }
>
> /*
> + * The following may seem pretty minimal, but the stateless nature
> + * of NFS means that we can't do too much more. Previous attempts to use
> + * fattr->nlink to determine how well the cached state matches the
> + * server suffer from races with stale dentries. You also risk killing
> + * off processes by just doing 'mv file newdir' on the server.
> + *
> + * FIXME: Of course, if 2 exported files have the same fileid (but
> + * different fsid which makes it legal) you're still buggered...
> + * Trond, August 1999.
> + */
> +static int
> +nfs_inode_is_stale(struct inode *inode, struct nfs_fattr *fattr)
> +{
> + int unhashed;
> + int is_stale = 0;
> +
> + if (inode->i_mode &&
> + (fattr->mode & S_IFMT) != (inode->i_mode & S_IFMT))
> + is_stale = 1;
> +
> + if (is_bad_inode(inode))
> + is_stale = 1;
> +
> + /*
> + * Free up unused cached dentries to see if it's wise to unhash
> + * the inode (which we can do if all the dentries have been unhashed).
> + */
> + unhashed = nfs_free_dentries(inode);
> +
> + /* Assume we're holding 1 lock on the inode from 'iget'
> + *
> + * NB: sockets sometimes have volatile file handles
> + * don't invalidate their inodes even if all dentries are
> + * unhashed. */
> + if (unhashed && inode->i_count == unhashed + 1
> + && !S_ISSOCK(inode->i_mode) && !S_ISFIFO(inode->i_mode))
> + is_stale = 1;
> +
> + return is_stale;
> +}
> +
> +/*
> * This is our own version of iget that looks up inodes by file handle
> * instead of inode number. We use this technique instead of using
> * the vfs read_inode function because there is no way to pass the
> @@ -550,53 +592,26 @@
> static struct inode *
> __nfs_fhget(struct super_block *sb, struct nfs_fattr *fattr)
> {
> - struct inode *inode;
> - int max_count, stale_inode, unhashed = 0;
> + struct inode *inode = NULL;
>
> -retry:
> - inode = iget(sb, fattr->fileid);
> - if (!inode)
> + if (!fattr)
> goto out_no_inode;
> - /* N.B. This should be impossible ... */
> - if (inode->i_ino != fattr->fileid)
> - goto out_bad_id;
>
> - /*
> - * Check for busy inodes, and attempt to get rid of any
> - * unused local references. If successful, we release the
> - * inode and try again.
> - *
> - * Note that the busy test uses the values in the fattr,
> - * as the inode may have become a different object.
> - * (We can probably handle modes changes here, too.)
> - */
> - stale_inode = inode->i_mode &&
> - ((fattr->mode ^ inode->i_mode) & S_IFMT);
> - stale_inode |= inode->i_count && inode->i_count == unhashed;
> - max_count = S_ISDIR(fattr->mode) ? 1 : fattr->nlink;
> - if (stale_inode || inode->i_count > max_count + unhashed) {
> - dprintk("__nfs_fhget: inode %ld busy, i_count=%d, i_nlink=%d\n",
> - inode->i_ino, inode->i_count, inode->i_nlink);
> - unhashed = nfs_free_dentries(inode);
> - if (stale_inode || inode->i_count > max_count + unhashed) {
> - printk("__nfs_fhget: inode %ld still busy, i_count=%d\n",
> - inode->i_ino, inode->i_count);
> - if (!list_empty(&inode->i_dentry)) {
> - struct dentry *dentry;
> - dentry = list_entry(inode->i_dentry.next,
> - struct dentry, d_alias);
> - printk("__nfs_fhget: killing %s/%s filehandle\n",
> - dentry->d_parent->d_name.name,
> - dentry->d_name.name);
> - memset(dentry->d_fsdata, 0,
> - sizeof(struct nfs_fh));
> - }
> - remove_inode_hash(inode);
> - nfs_invalidate_inode(inode);
> - unhashed = 0;
> - }
> + while (!inode) {
> + inode = iget(sb, fattr->fileid);
> + if (!inode)
> + goto out_no_inode;
> + /* N.B. This should be impossible ... */
> + if (inode->i_ino != fattr->fileid)
> + goto out_bad_id;
> +
> + if (!nfs_inode_is_stale(inode,fattr))
> + break;
> +
> + remove_inode_hash(inode);
> + nfs_invalidate_inode(inode);
> iput(inode);
> - goto retry;
> + inode = NULL;
> }
> nfs_fill_inode(inode, fattr);
> dprintk("NFS: __nfs_fhget(%x/%ld ct=%d)\n",
> fh = (u32 *) &fhandle;
> dfprintk(PAGECACHE, " %08x%08x%08x%08x%08x%08x%08x%08x\n",
> @@ -751,6 +766,8 @@
> fh[0],fh[1],fh[2],fh[3],fh[4],fh[5],fh[6],fh[7]);
> + if (!IS_ROOT(dentry))
> + d_drop(dentry);
> goto out;
> }
>
>
>
>
>- --
>Paul Jakma
>paul@clubi.ie http://hibernia.clubi.ie
>PGP5 key: http://www.clubi.ie/jakma/publickey.txt
>- -------------------------------------------
>Fortune:
>They are called computers simply because computation is the only
significant
>job that has so far been given to them.
>
>
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: Matti Aarnio <matti.aarnio@sonera.fi>
>Date: Thu, 16 Sep 1999 13:52:42 +0300
>Subject: Re: ext2 file sizes
>
>On Thu, Sep 16, 1999 at 12:31:38PM +0200, David Weinehall wrote:
>.... (using other operating systems than Linux at ia32 system) ....
>> I'd say no on both claims here.
>>
>> a.) (most simple solution) Get an Alpha, Sparc64 or Power64 (not PPC)
>> based machine
>
> Initial condition was stated as: "ia32 system",
> which excludes current 64-bit systems...
>
>> b.) I don't believe Matti Aarnio's patches are too far away...
>>
>> Of course, at least for video & audio, using Raw-IO would probably be a
>> third alternative.
>
> Thanks for the "b", but for grabbing I would (myself) use
> initially raw partition and Raw-IO, then I would pull the
> data out from there in a more leisure pace to normal
> filesystem for non-realtime task of editing -- and for
> the playback I would again drop it into the Raw-IO...
>
> For video playback (and grabbing) nothing really beats
> filesystems with 32-to-256 kB block sizes, and schedulable
> IO. Linux does not have such a beast - so far...
> (Getting extent indexing into EXT2 would allow it to mutate
> towards such wonder animal, though..)
>
> If you want to play some, my LFS things are at:
> ftp://mea.tmt.tele.fi/linux/LFS/
>
>> /David
>> // David Weinehall <tao@acc.umu.se> /> Northern lights wander \\
>
>/Matti Aarnio
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: Herbert Huber <Herbert.Huber@lrz-muenchen.de>
>Date: Thu, 16 Sep 1999 12:56:01 +0200
>Subject: Re: problem with system clock
>
>Yes, you are right! I´m running xntpd version xntp-4.0.92c-3. However
>what astonishes me is that my second smp server, running the same kernel
>but having two 450 MHz PII instead of two 500 MHz PIII installed,
>doesn´t have this problem at all. To my knowledge linux-2.2.3 doesn´t
>support any special PIII features. So what makes the difference - clock
>rate?
>
>/Herbert
>
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: David Weinehall <tao@acc.umu.se>
>Date: Thu, 16 Sep 1999 12:57:08 +0200 (MET_DST)
>Subject: Re: ext2 file sizes
>
>On Thu, 16 Sep 1999, Matti Aarnio wrote:
>
>> On Thu, Sep 16, 1999 at 12:31:38PM +0200, David Weinehall wrote:
>> .... (using other operating systems than Linux at ia32 system) ....
>> > I'd say no on both claims here.
>> >
>> > a.) (most simple solution) Get an Alpha, Sparc64 or Power64 (not PPC)
>> > based machine
>>
>> Initial condition was stated as: "ia32 system",
>> which excludes current 64-bit systems...
>
>Sorry, missed out that one... :/
>
>> > b.) I don't believe Matti Aarnio's patches are too far away...
>> >
>> > Of course, at least for video & audio, using Raw-IO would probably be a
>> > third alternative.
>>
>> Thanks for the "b", but for grabbing I would (myself) use
>> initially raw partition and Raw-IO, then I would pull the
>> data out from there in a more leisure pace to normal
>> filesystem for non-realtime task of editing -- and for
>> the playback I would again drop it into the Raw-IO...
>>
>> For video playback (and grabbing) nothing really beats
>> filesystems with 32-to-256 kB block sizes, and schedulable
>> IO. Linux does not have such a beast - so far...
>> (Getting extent indexing into EXT2 would allow it to mutate
>> towards such wonder animal, though..)
>>
>> If you want to play some, my LFS things are at:
>> ftp://mea.tmt.tele.fi/linux/LFS/
>
>Well... My largest disk at the moment is 200 MB, so...
>
>(I do all kernel-dev at the University)
>
>/David
> _ _
> // David Weinehall <tao@acc.umu.se> /> Northern lights wander \\
>// Project MCA Linux hacker // Dance across the winter sky //
>\> http://www.acc.umu.se/~tao/ </ Full colour fire </
>
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: Pavel Machek <pavel@bug.ucw.cz>
>Date: Thu, 16 Sep 1999 12:41:04 +0200
>Subject: /proc/bus/usb/000 will not work correctly when usb is compiled
into kernel
>
>Hi!
>
>Here's patch to make it work. Basically you need to first
>proc_usb_init(), because otherwise it will be unable to register buses
>(/proc/bus/usb/000 will not appear).
>
> Pavel
>
>- --- clean//drivers/usb/usb-core.c Wed Sep 8 20:41:58 1999
>+++ linux/drivers/usb/usb-core.c Thu Sep 16 12:33:29 1999
>@@ -31,6 +31,9 @@
>
> int usb_init(void)
> {
>+#ifdef CONFIG_USB_PROC
>+ proc_usb_init ();
>+#endif
> #ifndef CONFIG_USB_MODULE
> # ifdef CONFIG_USB_UHCI
> uhci_init();
>@@ -68,9 +71,6 @@
> # ifdef CONFIG_USB_SCSI
> usb_scsi_init();
> # endif
>- -#endif
>- -#ifdef CONFIG_USB_PROC
>- - proc_usb_init ();
> #endif
> return 0;
> }
>
>- --
> pavel@suse.cz
>Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: Alan Cox <alan@lxorguk.ukuu.org.uk>
>Date: Thu, 16 Sep 1999 12:20:19 +0100 (BST)
>Subject: Re: 2.3.18ac[4] PCMCIA...
>
>> drivers/pcmcia (i have it trying to compile in, and not as a module).
>> After changing some things in the makefile in that directory, it compiled
>> and built a pcmcia_core.o file. But on linking the entire kernel, it
>> seemed to be looking for a pcmcia.o file in that directory which does not
>> exist. Haven't tried it as a module yet....
>>
>> Any pointers? Alan?
>
>I test build PCMCIA as a module. If the makefiles arent yet quite right
>Im not suprised
>
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: Erik Mouw <J.A.K.Mouw@its.tudelft.nl>
>Date: Thu, 16 Sep 99 13:34:21 +0200
>Subject: Re: ext2 file sizes
>
>On Wed, 15 Sep 1999 15:17:47 -0400 (EDT), Richard B. Johnson wrote:
>> What on earth are you doing with a single _file_ of that size? If you
>> need a gob of storage for data acquisition, you might be better off
>> with a dedicated raw device. Since you access it in blocks, rather than
>> bytes, you won't have a size limitation for a few more years.
>
>Recording studio quality uncompressed digital video (CCIR 601:
>720x576@25Hz YUV 4:2:2; ~20 Mbyte per second[1]) for example. One minute of
>video already uses ~1.2 Gbyte. It's much easier to record it to a normal
>filesystem[2] instead of a raw device: you can use the standard libc file
>functions to manipulate the data.
>
>
>Erik
>
>[1] 720 pixels horizontal x 576 pixels vertical x 2 bytes per pixel + 6144
> bytes padding to get to the nearest multiple of 16 kbyte (for
> performance reasons) = 835584 bytes per frame.
>[2] Although you can hardly call SGI IRIX XFS with real-time partitions
> and guaranteed rate I/O a "normal filesystem".
>
>- --
>J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department
>of Electrical Engineering, Faculty of Information Technology and Systems,
>Delft University of Technology, PO BOX 5031, 2600 GA Delft, The
Netherlands
>Phone: +31-15-2785859 Fax: +31-15-2781843 Email J.A.K.Mouw@its.tudelft.nl
>WWW: http://www-ict.its.tudelft.nl/~erik/
>
>
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: Alan Cox <alan@lxorguk.ukuu.org.uk>
>Date: Thu, 16 Sep 1999 12:36:47 +0100 (BST)
>Subject: Re: Linux 2.3.18ac5
>
>> Note that a fix using MODULE_NAME() _will_ break the current semantics
>> of some modules:
>> - we (really) should enforce everyone to have a MODULE_NAME (can we get
>> a default out of __FILE_NAME__ with some tricky macro??)
>
>I'd rather enforce it. I can go through and put all the module name's in
>pretty fast if someone puts the base code together and gets it working
>for a few items
>
>> - some already have a prefix encoded into their arguments (isapnp springs
>> into my mind) - those will have to be ripped off - and it "breaks"
>> backward-compatibility, as the prefixes are not always like "isapnp_"
>
>I think we only break compatibility with 2.0 modules
>>
>> now, well if its easy, I'll look into it.
>
>Ok
>
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: Andreas Tobler <toa@pop.agri.ch>
>Date: Thu, 16 Sep 1999 13:51:21 +0200
>Subject: strange mounting problem
>
>Hi,
>
>the subject I struggled over this thing is still my not working
>MO-drive. I sat down to extensivly test the conditions when and how my
>Optical behaves when mounting it.
>As said earlier this is an older Optical drive with SCSI revision: 01 CCS
>I booted with media inserted.
>
>Then I mounted the device via 'hand' means: mount /dev/sdc <mountpoint>
>and NOT mount <mountpoint> which is written in fstab.
>Ok, behaves ok.
>Now umounting the drive and ejecting it.
>Mount an empty drive (no cartridge in) with mount /dev/sdc <mountpoint>
>gives a few errors, ok.
>Umount the empty drive.
>gives a few errors, same as above, ok.
>Mount an empty drive with mount /dev/sdc <mountpoint>
>gives a few more errors.
>Umount the empty drive.
>umount: /dev/sdc: not found, ok.
>
>Now I change the side of the cartridge and do the same again.
>Doing so I get the correct content listed from Bside.
>
>In short I can see my A and Bside of the MO-media when I go through a
>uninserted media step. A progress for me then before I did the same with
>the following result:
>
>Scenario same as above EXCEPT I mount via mount <mountpoint> (/mnt/Aopto).
>My entry in fstab: /dev/sdc /mnt/Aopto ext2 noauto 0 0
>
>Now I mounted the device via mount <mountpoint>
>Ok, behaves ok.
>Now umounting the drive and ejecting it.
>Mount an empty drive (no cartridge in) with mount /dev/sdc <mountpoint>
>gives a few errors, ok.
>Umount the empty drive.
>gives a few errors, same as above, ok.
>Mount an empty drive with mount /dev/sdc <mountpoint>
>gives a few more errors.
>but different than above in first scenario.
>
>unmount /mnt/Aopto
>umount: /mnt/Aopto/: not mounted
>
>Now I change the side of the cartridge and do the same again.
>Doing so I get the WRONG content listed from Bside. The tree is still
>the same as on the Aside.
>
>And here it stops. The only chance to get the Bside was a reboot with
>Bside inserted at boottime.
>
>Now I can save this step :-)
>
>My question: why this behavior when working with fstab entries???
>
>A detailed log of the procedures I did is available..
>
>Thanks for any hint
>Andreas
>
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: Andrea Arcangeli <andrea@suse.de>
>Date: Thu, 16 Sep 1999 14:01:52 +0200 (CEST)
>Subject: [patch] __flush_one_page() on i386
>
>On i386 we are doing a flush_tlb_current_task() when a __flush_one_page()
>is requested. This is plain wrong as if there isn't the `invlpg` asm
>instruction we should revert to the only bit more larger (and CPU local)
>operation by moving back and forth the %%cr3 register so doing a full
>flush of the local tlb and nothing more.
>
>This bug is on both 2.2.x and 2.3.x.
>
>In 2.3.18 __flush_one_page() actually is called by flush_tlb_page() in
>smp.c and flush_tlb_page is called by kswapd. kswapd has no current->mm so
>then flush_tlb_current_page() oopses because current->mm is null and it's
>trying to dereference it to flush the mm of the current (kswapd) task.
>
>Fix against 2.3.18ac4:
>
>- --- 2.3.18ac4-tlb/include/asm-i386/pgtable.h.~1~ Wed Sep 15 14:48:32 1999
>+++ 2.3.18ac4-tlb/include/asm-i386/pgtable.h Wed Sep 15 15:47:41 1999
>@@ -44,7 +44,7 @@
> do { unsigned long tmpreg; __asm__ __volatile__("movl %%cr3,%0\n\tmovl
%0,%%cr3":"=r" (tmpreg) : :"memory"); } while (0)
>
> #ifndef CONFIG_X86_INVLPG
>- -#define __flush_tlb_one(addr) flush_tlb()
>+#define __flush_tlb_one(addr) __flush_tlb()
> #else
> #define __flush_tlb_one(addr) \
> __asm__ __volatile__("invlpg %0": :"m" (*(char *) addr))
>
>Andrea
>
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: Alan Cox <alan@lxorguk.ukuu.org.uk>
>Date: Thu, 16 Sep 1999 13:10:17 +0100 (BST)
>Subject: Re: [patch] __flush_one_page() on i386
>
>> In 2.3.18 __flush_one_page() actually is called by flush_tlb_page() in
>> smp.c and flush_tlb_page is called by kswapd. kswapd has no current->mm
so
>> then flush_tlb_current_page() oopses because current->mm is null and it's
>> trying to dereference it to flush the mm of the current (kswapd) task.
>
>For this latter item would it not be better to give kswapd and everything
else
>a valid mm (eg the task 0 mm), just to be more regular
>
>
>
>Alan
>
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: Brian Geisel <briang@microlite.com>
>Date: Thu, 16 Sep 1999 08:46:40 -0400
>Subject: Symbios DAC960 and Quad Xeon
>
>Greetings,
> I'm having trouble with a system booting with an Intel SC450NX
>motherboard. The board has Quad Xeon 450Mhz with a built-in Symbios 53C896
>dual SCSI3 Ultra2 and a Symbios 5353C810AE Narrow Fast SCSI controller. It
>is also using the 0-Channel Mylex AcceleRAID 200 card.
>
> The System boots fine normally. The Symbios is built into the kernel and
>I believe the DAC960 is as well (I believe because I can't actually get my
>hands on the system - That's the catch to the whole thing). The problem
>occurs when they use boot disks. I work for Microlite Corporation and we
>make a boot/recovery solution that builds custom boot disks. Now we're
>booting with LILO (just like they normally do) and have checked their
>lilo.conf file for any special command line parameters. There are none.
>We're also using the same kernel they use to boot with, and have grabbed
>any loadable modules they may have installed.
> When the system starts to boot it gets to the NCR/Symbios. It then finds
>three drives on that card (which I'm told it doesn't do from the HD, they
>appear instead as a RAID drive on the AcceleRAID). This is in the midst of
>several error messages, all of which come from an assert line in the NCR
>driver (line 7780 - while it's looking up the ccb in ncr_int_sir).
> This problem doesn't occur when booting from the HD which is what is
>really confusing me.
>
> Ok, so here's the information I'm really looking for:
>
>Should this be using the sym53c8xx driver instead of the ncr53c8xx driver?
>What might be the differences there, or what they should be used for?
>
>Is there any chance this is modified by the SMP stuff? My first thought is
>no, but I have heard stuff floating around about problems with LILO booting
>Symbios cards on SMP systems. (Something about it taking part of the 640k
>that LILO expects is unused).
>
>Anything I should know about the boot process between these two cards?
>Should the NCR/Symbios find the drives and then the DAC960 'take' them, or
>should this have already happened in hardware? Does one need to be loaded
>before the other? Anything else that might be special under this
>configuration, parameters, etc?
>
>TIA,
>
>Brian Geisel
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: "Richard B. Johnson" <root@chaos.analogic.com>
>Date: Thu, 16 Sep 1999 09:06:04 -0400 (EDT)
>Subject: Re: ext2 file sizes
>
>On Thu, 16 Sep 1999, Clem Taylor wrote:
>
>> "Richard B. Johnson" wrote:
>> > On Wed, 15 Sep 1999, Blankenship, Keith wrote:
>> > > I am having some difficulty with the ext2 file systems. I need to
generate a
>> > > file that will be > 5 Gigabytes, and there appears to be a file size
cap at
>> > > approximately 2 Gig. I am running what appears to be a version 2.0.36
>> > > Kernel. Is there anything I can adjust, or do to increase the maximum
file
>> > > size? Or is there a newer kernel that may work?
>> >
>> > Note that on a 32-bit machine, toff_t, used as fpos_t, for file
offsets,
>> > i.e., lseek, is unsigned 32 bits. You will not be able to access such a
>> > file on a 32-bit machine. There has been some work on changing this
>> > to 'long long' (__kernel_loff_t, in ../asm/posix_types.h although you
may
>> > need a new 'C' runtime library to take advantage of this.
>> >
>> > What on earth are you doing with a single _file_ of that size? If you
>> > need a gob of storage for data acquisition, you might be better off
>> > with a dedicated raw device. Since you access it in blocks, rather than
>> > bytes, you won't have a size limitation for a few more years.
>>
>> I work with compressed video and my average file size is 3-6 gigs,
>> increasing
>> all the time (higher bitrates). A while back I looked into using Linux
for
>> a
>> video application and gave up and went with Solaris and Irix because of
>> the lack
>> of large file support. I was hoping that 2.4 would have large file
support
>> (and
>> not just on 64 bit platforms), but that isn't looking promising based on
>> comments here. Going to a 64 bit off_t (on 32 bit platforms) is a major
>> change
>> and will have a serious impact in user space. Just look at all the pain
>> Solaris
>> and Irix had in making the move.
>>
>> --Clem
>>
>
>Here, we acquire great gobs of data (CAT Scan Data), typically 4 gb per
>run. I run it off to a dedicated SCSI. After it's converted into useful
>images, the images are saved in a conventional database on a file-system.
>
>This seems to be a real good approach because, even with smaller files
>the ext2 file-system has a problem keeping up with the data-rate when
>buffers get filled and must be flushed to disk. Our data rate is
>2880*1440 = 4,147,200 longwords/second. We throw away the high byte
>so we have a sustained data rate of 12,441,600 bytes/second. Good SCSI
>controllers (BusLogic) keep up with this fine. The ext2 file-system keeps
>up with this until its buffers get full. Then it's too bad.
>
>Writes to a dedicated SCSI solved all our problems. I can sustain writes
>at these speeds forever (until the drive is full).
>
>
>Cheers,
>Dick Johnson
> **** FILE SYSTEM WAS MODIFIED ****
>Penguin : Linux version 2.2.4 on an i686 machine (400.59 BogoMips).
>Warning : It's hard to remain at the trailing edge of technology.
>
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: ebi4 <ebi4@ozob.net>
>Date: Thu, 16 Sep 1999 08:08:02 -0500 (CDT)
>Subject: Re: State of USB drivers
>
>> "Popular" (my definition of it :) devices work well. By that, I mean
>> things like keyboards, mice, hubs. Audio devices are being worked on, as
>> are cameras. UPSs and other power devices are being worked on. Ethernet
>> adapters are on the list, and we're getting some support. Parallel and
>> serial converters are nonstandard, proprietary, and not supported.
>>
>> Did I miss anything?
>
>Scanners, if not part of the last group.
>
>::::: Gene Imes http://www.ozob.net :::::
>
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: Mark Buda <hermit@clark.net>
>Date: 16 Sep 1999 09:12:03 -0400
>Subject: Re: 2.2.12: serial driver swapping characters?
>
>>>>>> "Dag" == Dag Brattli <dagb@cs.uit.no> writes:
>
> Dag> The Doctor What <docwhat@gerf.org> writes:
> >> I have similar problems with my palm. I use pyrite, but the
> >> symtoms are the same (wierd packet error, and then everything
> >> else bombs).
>
> Dag> I'm experiencing the same problem with 2.2.12, but I'm using
> Dag> IrCOMM which emulates serial port communication over IrDA
> Dag> (infrared).
>
>My problem appears to be solved (so far). I removed my Megahertz
>EM1144-T PCMCIA Ethernet/modem card and inserted a D-Link DFE-650 Fast
>Ethernet PC Card, and the problem seems to go away.
>
>I imagine it has something to do with the serial_cs driver. I'm using
>version 3.0.12 of PCMCIA Card Services.
>- --
>I get my monkeys for nothing and my chimps for free.
>http://www.clark.net/pub/hermit/
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: Jacek Kopecky <kopeckyj@inf.upol.cz>
>Date: Thu, 16 Sep 1999 15:15:17 +0200 (MET DST)
>Subject: [PATCH] console alertness - notifying of console activities
>
>Hello.
>
>I always wanted the console to be able to alert me when something happened
it
>it. So I started writing a patch to allow me to set a virtual console so
that
>it gets switched to whenever it beeps. I then expanded it so that now you
>can:
> - have the vc switched to when it beeps,
> - have the vc switched to when anything is written to it,
> - have the vc beep whenever anything is written to it
> - do nothing of the above. 8-)
>
>See the documentation file at the end of the patch for details. And tell me
>if you feel such functionality is desired.
>
>The patch applies cleanly with 2.2.12 and 2.3.18, it was originally made
for
>2.2.10.
>
>(Is this mail enough for the patch to get into the main kernel or what
should
>I do if I get positive responses about it?)
>
> Jacek Kopecky
>
>E-mail: jacek.kopecky(at)upol.cz (ISO Latin 2 encoding gladly accepted)
>WWW: http://www.inf.upol.cz/~kopeckyj ICQ: 49514837
>Finger kopeckyj@alpha.inf.upol.cz for Geek Code.
>
>The patch:
>- ----------------------------------------------------------
>
>diff -u --recursive linux-2.2.12/drivers/char/console.c
linux/drivers/char/console.c
>- --- linux-2.2.12/drivers/char/console.c Thu Mar 11 01:51:35 1999
>+++ linux/drivers/char/console.c Thu Jul 15 11:55:38 1999
>@@ -66,6 +66,8 @@
> *
> * Resurrected character buffers in videoram plus lots of other trickery
> * by Martin Mares <mj@atrey.karlin.mff.cuni.cz>, July 1998
>+ *
>+ * Console alertness by Jacek Kopecky <jacek@unforgettable.com>, July 1999
> */
>
> #include <linux/module.h>
>@@ -1263,6 +1265,10 @@
> case 14: /* set vesa powerdown interval */
> vesa_off_interval = ((par[1] < 60) ? par[1] : 60) * 60 * HZ;
> break;
>+ case 15: /* set console alertness:
>+ 1 beep on write, 2 switch on beep , 3 switch on write*/
>+ alert = (par[1] > 2) ? 3 : par[1];
>+ break;
> }
> }
>
>@@ -1402,6 +1408,8 @@
> save_cur(currcons);
> if (do_clear)
> csi_J(currcons,2);
>+
>+ alert = 0;
> }
>
> static void do_con_trol(struct tty_struct *tty, unsigned int currcons, int
c)
>@@ -1416,6 +1424,9 @@
> case 7:
> if (bell_duration)
> kd_mksound(bell_pitch, bell_duration);
>+ /* switch console if alertness on beep */
>+ if ((alert == 2) && (currcons != fg_console))
>+ change_console(currcons);
> return;
> case 8:
> bs(currcons);
>@@ -1927,6 +1938,16 @@
> }
> FLUSH
> enable_bh(CONSOLE_BH);
>+
>+ /* Switch to this console if alertness is 3
>+ * or beep if alertness is 1
>+ */
>+ if (alert && (currcons != fg_console)) {
>+ if (alert == 3) change_console(currcons);
>+ else if ((alert == 1) && bell_duration)
>+ kd_mksound(bell_pitch, bell_duration);
>+ }
>+
> return n;
> #undef FLUSH
> }
>diff -u --recursive linux-2.2.12/drivers/char/console_macros.h
linux/drivers/char/console_macros.h
>- --- linux-2.2.12/drivers/char/console_macros.h Thu Sep 17 18:35:03 1998
>+++ linux/drivers/char/console_macros.h Wed Jun 30 20:50:00 1999
>@@ -64,6 +64,7 @@
> #define complement_mask (vc_cons[currcons].d->vc_complement_mask)
> #define s_complement_mask (vc_cons[currcons].d->vc_s_complement_mask)
> #define hi_font_mask (vc_cons[currcons].d->vc_hi_font_mask)
>+#define alert (vc_cons[currcons].d->vc_alert)
>
> #define vcmode (vt_cons[currcons]->vc_mode)
>
>diff -u --recursive linux-2.2.12/include/linux/console_struct.h
linux/include/linux/console_struct.h
>- --- linux-2.2.12/include/linux/console_struct.h Thu Sep 17 18:35:04 1998
>+++ linux/include/linux/console_struct.h Wed Jun 30 22:45:11 1999
>@@ -65,6 +65,7 @@
> unsigned int vc_can_do_color : 1;
> unsigned int vc_report_mouse : 2;
> unsigned int vc_kmalloced : 1;
>+ unsigned int vc_alert : 2; /* Switch to this console on write or beep
*/
> unsigned char vc_utf : 1; /* Unicode UTF-8 encoding */
> unsigned char vc_utf_count;
> int vc_utf_char;
>diff -u --recursive --new-file linux-2.2.12/Documentation/console-alertness
linux/Documentation/console-alertness
>- --- linux-2.2.12/Documentation/console-alertness Thu Jan 1 01:00:00 1970
>+++ linux/Documentation/console-alertness Fri Aug 6 22:45:45 1999
>@@ -0,0 +1,31 @@
>+This file describes the console alertness function of linux virtual
consoles
>+as implemented by Jacek Kopecky (jacek@unforgettable.com) in July 1999.
>+
>+First, what does console alertness mean anyway?
>+In cases when you want to be warned when something changes or only beeps
on a
>+virtual console other than the one that's active at the moment (so that
you
>+don't see the changes yourself), you can use the following escape
sequences
>+to set the console-alertness-level to get some warnings:
>+
>+echo -ne "\033[15;0]" > /dev/ttyX alertnes off ("beep on beep")
>+echo -ne "\033[15;1]" > /dev/ttyX beep on write to the console
>+echo -ne "\033[15;2]" > /dev/ttyX switch to the console on beep
>+echo -ne "\033[15;3]" > /dev/ttyX switch to the console on write
>+
>+At the level 1 the virtual console /dev/ttyX beeps whenever anything is
>+written to it but only if the console is not currently the foreground
console.
>+The level 2 makes the console get switched to whenever it beeps. On the
highest
>+level the console gets switched to on each write to it.
>+
>+A side-effect of setting beep-on-write (1) or switch-on-write (3) on
another
>+console is that the other console beeps or is switched to, this comes
handy
>+as a test it's working. 8-)
>+The sequence for setting the switch-on-beep (2) level can be enhanced to
give
>+the same kind of test:
>+
>+echo -ne "\033[15;2]\a" > /dev/ttyX
>+
>+The setting sequences may seem to be a little too user-unfriendly so I'm
>+planning to try to incorporate alertness setting into the setterm package.
>+
>+Enjoy. 8-)
>
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: afei@jhu.edu
>Date: Thu, 16 Sep 1999 09:31:24 -0400 (EDT)
>Subject: Email subject line
>
>Hi, Guys:
>
> I am a new comer to this email list and presumably I should shut up for
>a while. But this is really a traffic email-list and I got about 100
>emails everyday, which stuffed my mailbox and made it very hard for me
>to read other kinds of emails--emails from friends, department activities,
>etc.
>
> I have a little suggestion as to the email subject line being sent out
>by the email list server program. Can we add something like [LK] in front
>of every email subject line? LK stands for Linux Kernel. I was in several
>other email list before which has high traffic too. They did something
>like this and it was very neat.
>
> This amount of traffic almost scared the hell out of me and it
>surely stoped some people from joining us. So hope my suggestions can be
>adopted.
>
>with regards to all your hard working developers,
>Fei
>
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: Daniel.Egger@t-online.de
>Date: Thu, 16 Sep 1999 15:34:57 +0200 (CEST)
>Subject: Re: Mouse input corrupted under X 3.3.3.1 with kernel 2.2.12
>
>On 15 Sep, Alec Smith wrote:
>
>> Any pointers would be greatly appreciated. I can try to provide more
>> information as needed.
>
> This is a know problem.... You have to use X 3.3.5...
>
>Servus,
> Daniel
>
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: "Stephen D. Williams" <sdw@lig.net>
>Date: Thu, 16 Sep 1999 09:50:44 -0400
>Subject: > 15K simultaneous connections EXAMPLE program/OS config needed,
was: Re: POSIX aio vs completion ports
>
>Stephen, or anyone else, are you aware of a test program that illustrates
the
>use of existing (2.2.12+) mechanisms to efficiently handle many sockets?
>
>I have several needs for this, including a communication concentrator
server.
>I could use a collection of processes each having at most 1024 (or
something
>similarly small) sockets each working together, but although this appears
to
>be workable it sounds like there are much more efficient ways.
>
>What will slow down at the OS level with many sockets?
>
>Is there a limit to the number of connections per IP address, assuming many
>different client IP's? (In other words, is there any problem with running
out
>of local sockets? There shouldn't be really since a client program that
>doesn't specify a certain local socket doesn't care if it has that same
socket
>number used with N different remote IP's.)
>
>I really want to handle 100,000 TCP connections simultaneously per system,
>eventually.
>
>I can see that there are two ways to optimize: for many descriptors with
>little traffic and fewer (but still large) descriptors with a lot of
traffic.
>Ideally, if there were a significant latency or performance benefit, you
>should be able to dynamically tune the handling of a connection.
>
>Thanks
>sdw
>
>"Stephen C. Tweedie" wrote:
>
>> Hi,
>>
>> On Sat, 11 Sep 1999 21:26:47 -0700, John Gardiner Myers
>> <jgmyers@netscape.com> said:
>>
>> > Alan Cox wrote:
>> >> POSIX real time signal queues are effectively completion ports.
>>
>> > You must not have understood the post you were replying to. POSIX real
>> > time signal queues are inferior to completion ports in many ways.
>>
>> > * As far as I know, there is no way to allocate a POSIX real time
signal
>> > number in a thread safe manner. There is no equivalent to the socket()
>> > system call--one must just pick a number and hope that no other thread
>> > in the same process just picked the same number.
>>
>> As far as I know, completion ports still have the demultiplexing done in
>> a single place, so in that model you still have to have extra explicit
>> application/library cooperation to let libraries share queues.
>>
>> > * Chuck Lever informs me that the signal queue might overflow, leading
>> > to lost completion notifications. There is no reasonable way for an
>> > application to recover from such a condition.
>>
>> There is. The existing kernel supports sending a separate, higher
>> priority event to notify the application of overflow, and poll is a
>> sufficient recovery mechanism. You don't expect overflow to be a
>> common, performance-critical case.
>>
>> > * POSIX aio lacks a mechanism to request read polls.
>>
>> Who is talking about POSIX aio? That is a totally different API. For
>> the purposes in question --- networking IO --- leave POSIX aio well
>> alone, Unix O_NONBLOCK plus completion events is a perfectly adequate
>> API. The async IO API is not necessary or desirable.
>>
>> > * POSIX aio lacks asynchronous versions of writev() and sendfile().
>> > (Though the lack of an aio_writev() is made less important by
>> > TCP_CORK.)
>>
>> See the previous point: you'd be crazy to want aio_writev on a socket.
>>
>> --Stephen
>>
>> -
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel"
in
>> the body of a message to majordomo@vger.rutgers.edu
>> Please read the FAQ at http://www.tux.org/lkml/
>
>- --
>OptimaLogic - Finding Optimal Solutions
Web/Crypto/OO/Unix/Comm/Video/DBMS
>
>sdw@lig.net Stephen D. Williams Senior Consultant/Architect
http://sdw.st
>
>43392 Wayside Cir,Ashburn,VA 20147-4622 703-724-0118W 703-995-0407Fax
5Jan1999
>
>
>
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: Andrea Arcangeli <andrea@suse.de>
>Date: Thu, 16 Sep 1999 15:47:06 +0200 (CEST)
>Subject: Re: [patch] __flush_one_page() on i386
>
>On Thu, 16 Sep 1999, Alan Cox wrote:
>
>>> In 2.3.18 __flush_one_page() actually is called by flush_tlb_page() in
>>> smp.c and flush_tlb_page is called by kswapd. kswapd has no current->mm
so
>>> then flush_tlb_current_page() oopses because current->mm is null and
it's
>>> trying to dereference it to flush the mm of the current (kswapd) task.
>>
>>For this latter item would it not be better to give kswapd and everything
else
>>a valid mm (eg the task 0 mm), just to be more regular
>
>AFIK Linus removed such &init_mm thing because tsk->mm == 0 is more
>regular in his opinion.
>
>The tsk->mm == 0 thing Oopses because the i386 version of
>__flush_one_page() is buggy (and my patch fixes the bug). With the bug
>fixed the new tsk->mm == 0 logic (should) work fine on i386 too without
>further changes. And just to avoid mistakes: with "i386" this time I mean
>a real 386 and not a 486 or Pentium with the invlpg instruction ;).
>
>As last thing tsk->mm == 0 is faster as the asm doesn't need to play with
>the &init_mm address (the zero version will work with a plain testl on the
>tsk->mm value).
>
>Andrea
>
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: Ben Collins <bcollins@debian.org>
>Date: Thu, 16 Sep 1999 05:50:41 -0400
>Subject: Re: Email subject line
>
>On Thu, Sep 16, 1999 at 09:31:24AM -0400, afei@jhu.edu wrote:
>> Hi, Guys:
>>
>> I am a new comer to this email list and presumably I should shut up for
>> a while. But this is really a traffic email-list and I got about 100
>> emails everyday, which stuffed my mailbox and made it very hard for me
>> to read other kinds of emails--emails from friends, department
activities,
>> etc.
>>
>> I have a little suggestion as to the email subject line being sent out
>> by the email list server program. Can we add something like [LK] in front
>> of every email subject line? LK stands for Linux Kernel. I was in several
>> other email list before which has high traffic too. They did something
>> like this and it was very neat.
>>
>> This amount of traffic almost scared the hell out of me and it
>> surely stoped some people from joining us. So hope my suggestions can be
>> adopted.
>>
>> with regards to all your hard working developers,
>> Fei
>
>It would probably be easier for you to use some sort of filtering (procmail
>works nice, and Netscape/Outlook on windows has the ability aswell).
>
>I'm sub'd to over 20 mailing lists, and get about 2k emails a day...even
with
>a subject line, I couldn't do it without procmail filtering.
>
>Ben
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: Coy A Hile <hile@cse.psu.edu>
>Date: Thu, 16 Sep 1999 09:51:55 -0400 (EDT)
>Subject: Re: Email subject line
>
>afei@jhu.edu sez....
>>
>>
>> I have a little suggestion as to the email subject line being sent out
>> by the email list server program. Can we add something like [LK] in front
>> of every email subject line? LK stands for Linux Kernel. I was in several
>> other email list before which has high traffic too. They did something
>> like this and it was very neat.
>>
>An even better solution would be to have majordomo do that for us.
>
>Coy
>
>- --
>Coy Hile
>hile@cse.psu.edu
>"Theirs not to reason why; theirs but to do...."
>Tennyson, "Charge of the Light Brigade"
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: Jesse Pollard <pollard@tomcat.admin.navo.hpc.mil>
>Date: Thu, 16 Sep 1999 08:52:51 -0500 (CDT)
>Subject: Re: Resource Limits Architecture
>
>> From: Jordan Mendelson <jordy@wserv.com>
>>
>> A few days ago I mentioned that robust resource limits really didn't
exist in
>> Linux. Alan Cox (who I thought moved to the US, but uses a UK email
address)
>> mentioned
>>
>> ftp://ftp.nc.orc.ru/pub/Linux/people/saw/kernel/userbean.5
>>
>> which appears to be a good start for resource limits, however I still
don't
>> find it robust enough.
>>
>> I have searched high and low and can't find a good complete resource
limits
>> architecture in any Unix implementation. As I see it, there should be a
few
>> different categories of limits:
>>
>> Per-System : Limits which are placed on all processes
>> Per-Group : Limits which are placed on all processes from a group id
>> Per-User : Limits which are placed on all processes from a user id
>> Per-Process Group : Limits which are placed on a group of processes
(shared)
>> Per-Process : Limits which are placed on a process
>> Per-Thread Group : Limits which are placed on a group of threads (shared)
>> Per-Thread : Limits which are placed on a thread
>>
>> Now of course, these will overlap since a thread is part of a process
which
>> has a user id a group id and runs on a system. The accepted semantics of
the
>> most generalized type being the upper limit of the more specific type
should
>> work fine, so:
>>
>> Per-Thread's hard limit is Per-Thread-Group
>> Per-Thread-Group's hard limit is Per-Process
>> Per-Process's hard limit is Per-Process-Group
>> Per-Process-Group's hard limit is Per-User
>> Per-User's hard limit is Per-Group (if mult groups, lowest would be hard
>> limit)
>> Per-Group's hard limit would be Per-System
>> Per-System's hard limit would be the kernel's upper limit
>>
>> The commercial unices I've seen really only do per-user, per-process,
>> per-thread and per-system which is probably adequate most of the time.
>>
>> A lot of resources themselves overlap as well. So the hard limit of
network
>> buffers would be total memory.
>>
>> There are of course some resource limits which I'd love to see
implemented:
>>
>> Wall clock time - Time in seconds the process has physically ran, current
time
>> - start time. As far as I know, the only time related resource limit is
CPU
>> time which only measures time in the run state.
>>
>> Number of CPUs - Processes/Threads will be restricted to use a maximum of
x
>> cpus. This would be a great thing for a per-group limit, you could set
users
>> in group 'cpuhogs' to a maximum of 2 CPUs and the rest of the system to 4
>> CPUs.
>>
>> Disk Space - Sure would be nice if this was all handled by a single
interface.
>> Right now we have a separate quota interface, I'm not sure how feasible
it is
>> to have disk space limits settable by the same interface as other things.
>>
>> Is this a bit of an overkill?
>>
>> Are there any unices or other OS's which implement these types of
resource
>> limits?
>
>yes - look at Cray UNICOS. Besides resource limits there are also security
>limits (MLS), fair-share limits (fading away now), project (project level
>accounting) limits, a different set for batch and interactive
(resource/project
>limits). There is also an utility to generate/collate accounting records
>into an extended accounting record for job level accounting.
>
>Note: I want project level accounting separate from group access control.
>The place I work has several projects that share group access to a given
set
>of files that is owned (and quota limited) to only one project. Files may
>be created by all project members, with group access - but accounting for
>each file/process is done to the specific project the user belongs to.
>
>Now that Linux is reaching into the "supercomputer" range with beowuf
>clusters, it is becoming more important to track (and justify) the usage
>on large systems. If my site (a DoD shared resource center) were ever to
>consider a cluser then we will have to be able to track (and report on)
>this stuff.
>
>- -------------------------------------------------------------------------
>Jesse I Pollard, II
>Email: pollard@navo.hpc.mil
>
>Any opinions expressed are solely my own.
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: Martin Mares <mj@atrey.karlin.mff.cuni.cz>
>Date: Thu, 16 Sep 1999 15:55:16 +0200
>Subject: Re: Email subject line
>
>Hello,
>
>> I am a new comer to this email list and presumably I should shut up for
>> a while. But this is really a traffic email-list and I got about 100
>> emails everyday, which stuffed my mailbox and made it very hard for me
>> to read other kinds of emails--emails from friends, department
activities,
>> etc.
>>
>> I have a little suggestion as to the email subject line being sent out
>> by the email list server program. Can we add something like [LK] in front
>> of every email subject line? LK stands for Linux Kernel. I was in several
>> other email list before which has high traffic too. They did something
>> like this and it was very neat.
>>
>> This amount of traffic almost scared the hell out of me and it
>> surely stoped some people from joining us. So hope my suggestions can be
>> adopted.
>
> Why not set up procmail filtering based on the `Sender' header instead?
>My .procmailrc contains:
>
>:0
>*Sender: owner-linux-kernel@
>Mail/kernel_list
>
> Have a nice fortnight
>- --
>Martin `MJ' Mares <mj@ucw.cz> http://atrey.karlin.mff.cuni.cz/~mj/
>Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
>"Everything counts in large amounts." -- Depeche Mode
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: robbie@scot-mur.demon.co.uk
>Date: Mon, 13 Sep 1999 23:16:01 +0100
>Subject: oops when insmodding msp3400, bttv 0.6.4, linux 2.2.12
>
>[sorry if you receive this twice, I didn't sea it on either list the first
>time.]
>
>Hi
>
>I got the below oops when loading the msp3400 module from bttv 0.6.4. It
>also happened with the bttv included with the kernel, but I didn't write
>that one down.(user space hung, kernel still responded to pings etc.) It
>is reproducible.
>
>this is a dual pii 450, (overclocked to 504, but its been *very* stable
>for months now).
>128 mb of ram.
>sb 128 soundcard (es1370) alsa driver loaded.
>Hauppage wintv (don't know the model number, it has an ir controller, no
>radio). Here is the lspci output:
>
>00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge
(rev 03)
>00:01.0 PCI bridge: Intel Corporation 440BX/ZX - 82443BX/ZX AGP bridge (rev
03)
>00:07.0 ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 02)
>00:07.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01)
>00:07.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01)
>00:07.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 02)
>00:0b.0 SCSI storage controller: Adaptec AIC-7880U
>00:11.0 Multimedia audio controller: Ensoniq ES1370 [AudioPCI] (rev 01)
>00:12.0 VGA compatible controller: Cirrus Logic GD 5430/40 [Alpine] (rev
22)
>00:13.0 Multimedia video controller: Brooktree Corporation Bt878 (rev 02)
>00:13.1 Multimedia controller: Brooktree Corporation Bt878 (rev 02)
>
>oops follows:
>
>i2c: driver registered: msp3400
>Unable to handle kernel NULL pointer dereference at virtual address
00000001
>current->tss.cr3 = 0700e000, %cr3 = 0700e000
>*pde = 00000000
>oops: 0000
>cpu: 1
>eip: 0010:[<00000001>]
>eflags: 00010283
>eax: 00000001 ebx: c8898b68 ecx: 0006df9a edx: 0006df9a
>esi: 00000000 edi: c63c2424 ebp: c63c23c0 esp: c778de18
>ds: 0018 es: 0018 ss: 0018
>Process insmod (pid: 617, process nr: 60, stackpage=c778d000)
>stack: 00000000 c021f600 c01a4611 c8898b68 00000000 00000001 c01a4611
000008cc
> 00000000 00000001 c88b7070 c8898b68 c8898b68 00000019 00000282
c33abb40
> c33abb40 c8898b68 00000000 0000a7bc 00000000 00000000 c88b8d4a
c8898b68
>Call Trace: [<c01a4611>] [<c8898b68>] [<c01a4611>] [<c88b7070>]
[<c8898b68>] [<c8898b68>] [<c8898b68>]
> [<c88b8d4a>] [<c8898b68>] [<c888f6fa>] [<c8898b68>] [<c8898b68]>
[<c888f170>] [<c011654a>] [<c88ba420>]
> [<c888fe60>] [<c88b7048>] [<c888f541>] [<c8898b68<] [<c88ba420>]
[<c88b7000>] [<c88b7050>] [<c88b7000>]
> [<c88b7050>] [<c88b944c>] [<c88ba420>] [<c88b7050>] [<c88b7048>]
[<c01186f3>] [<c88b7000>] [<c8c00000>]
> [<c88b3000>] [<c88b7048>] [<c01093c1>] [<c01092bc>] [<c88b7000>]
>Code: <1>Unable to handle kernel NULL pointer dereference at virtual
address 00000001
>current->tss.cr3 = 0700e000, %cr3 = 0700e000
>*pde = 00000000
>
>
>
>
>and the ksymoops output:
>
>ksymoops 0.7c on i686 2.2.12. Options used
> -V (default)
> -k /proc/ksyms (default)
> -L (specified)
> -o /lib/modules/2.2.12/ (default)
> -m /boot/System.map-2.2.12 (default)
>
>Unable to handle kernel NULL pointer dereference at virtual address
00000001
>current->tss.cr3 = 0700e000, %cr3 = 0700e000
>*pde = 00000000
>oops: 0000
>cpu: 1
>eip: 0010:[<00000001>]
>Using defaults from ksymoops -t elf32-i386 -a i386
>eflags: 00010283
>eax: 00000001 ebx: c8898b68 ecx: 0006df9a edx: 0006df9a
>esi: 00000000 edi: c63c2424 ebp: c63c23c0 esp: c778de18
>ds: 0018 es: 0018 ss: 0018
>Process insmod (pid: 617, process nr: 60, stackpage=c778d000)
>stack: 00000000 c021f600 c01a4611 c8898b68 00000000 00000001 c01a4611
000008cc
> 00000000 00000001 c88b7070 c8898b68 c8898b68 00000019 00000282
c33abb40
> c33abb40 c8898b68 00000000 0000a7bc 00000000 00000000 c88b8d4a
c8898b68
>Call Trace: [<c01a4611>] [<c8898b68>] [<c01a4611>] [<c88b7070>]
[<c8898b68>] [<c8898b68>] [<c8898b68>]
> [<c88b8d4a>] [<c8898b68>] [<c888f6fa>] [<c8898b68>] [<c8898b68]>
[<c888f170>] [<c011654a>] [<c88ba420>]
> [<c888fe60>] [<c88b7048>] [<c888f541>] [<c8898b68<] [<c88ba420>]
[<c88b7000>] [<c88b7050>] [<c88b7000>]
> [<c88b7050>] [<c88b944c>] [<c88ba420>] [<c88b7050>] [<c88b7048>]
[<c01186f3>] [<c88b7000>] [<c8c00000>]
> [<c88b3000>] [<c88b7048>] [<c01093c1>] [<c01092bc>] [<c88b7000>]
>Code: <1>Unable to handle kernel NULL pointer dereference at virtual
address 00000001
>Warning (Oops_code): trailing garbage ignored on Code: line
> Text: 'Code: <1>Unable to handle kernel NULL pointer dereference at
virtual address 00000001'
> Garbage: 'Unable to handle kernel NULL pointer dereference at virtual
address 00000001'
>Warning (Oops_code_values): Code looks like message, not hex digits. No
disassembly attempted.
>
>>>EIP; 00000001 Before first symbol <=====
>Trace; c01a4611 <__const_udelay+29/30>
>Trace; c8898b68 <END_OF_CODE+45ee4/????>
>Trace; c01a4611 <__const_udelay+29/30>
>Trace; c88b7070 <END_OF_CODE+643ec/????>
>Trace; c8898b68 <END_OF_CODE+45ee4/????>
>Trace; c8898b68 <END_OF_CODE+45ee4/????>
>Trace; c8898b68 <END_OF_CODE+45ee4/????>
>Trace; c88b8d4a <END_OF_CODE+660c6/????>
>Trace; c8898b68 <END_OF_CODE+45ee4/????>
>Trace; c888f6fa <END_OF_CODE+3ca76/????>
>Trace; c8898b68 <END_OF_CODE+45ee4/????>
>Trace; c888fe60 <END_OF_CODE+3d1dc/????>
>Trace; c88b7048 <END_OF_CODE+643c4/????>
>Trace; c888f541 <END_OF_CODE+3c8bd/????>
>Trace; c88b7050 <END_OF_CODE+643cc/????>
>Trace; c88b944c <END_OF_CODE+667c8/????>
>Trace; c88ba420 <END_OF_CODE+6779c/????>
>Trace; c88b7050 <END_OF_CODE+643cc/????>
>Trace; c88b7048 <END_OF_CODE+643c4/????>
>Trace; c01186f3 <sys_init_module+467/4e8>
>Trace; c88b7000 <END_OF_CODE+6437c/????>
>Trace; c8c00000 <END_OF_CODE+3ad37c/????>
>Trace; c88b3000 <END_OF_CODE+6037c/????>
>Trace; c88b7048 <END_OF_CODE+643c4/????>
>Trace; c01093c1 <error_code+2d/34>
>Trace; c01092bc <system_call+34/38>
>Trace; c88b7000 <END_OF_CODE+6437c/????>
>
>current->tss.cr3 = 0700e000, %cr3 = 0700e000
>*pde = 00000000
>
>2 warnings issued. Results may not be reliable.
>
>What does all that end of code stuff mean? Is it not finding the module
>symbols?
>
>Regards
>
> --
>Rob Murray
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: Frank van Maarseveen <fvm@tasking.nl>
>Date: Thu, 16 Sep 1999 16:22:10 +0200
>Subject: 2.2.18ac5 NFS client bug
>
>Try the following:
>
> sleep 10000 >file & // client
> rm file;date >file // server
> ls -l file // client again
> ls: file: Stale NFS file handle
>
>mount options: rw,nodev,rsize=8192,wsize=8192,acregmin=0
>
>I also tried:
> linux-2.2.6-ac3: ok
> linux-2.2.10-ac11 bug (a bit worse)
>
>btw: uname -r says 2.3.18ac4 instead of 2.3.18ac5
>
>- --
>Frank
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: Anil Kumar S R <anilsr@sasi.com>
>Date: Thu, 16 Sep 1999 19:56:23 +0530
>Subject: Problem in inserting module
>
>Hi,
> 1. After I compile the driver , If I insert the module I am getting
> following warning:
>
> ./cardtest.o: kernel-module version mismatch
> ./cardtest.o was compiled for kernel version 2.2.5-15
> while this kernel is version 2.2.5-22.
>
> cardtest is name of module to be inserted.
> what needs to be done to this?
>
> 2. After inserting the module should I have it in /proc/modules.
> b'coz /proc/modules has modules which are loaded and the usage
> count of the module can be looked from /proc/modules.
> so when I insert a module(cardtest) should I get it in /proc/modules?
>
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
>Date: Thu, 16 Sep 1999 16:28:44 +0200 (MET DST)
>Subject: Re: Lockups - lost interrupt
>
>On Sun, 12 Sep 1999 mingo@chiara.csoma.elte.hu wrote:
>
>> FYI, i'm working on a patch for 2.3 that adds the NMI oopser (optionally,
>> because 1) it doesnt work on all SMP boxes, and 2) it forces the timer
irq
>> to the BP) to the 2.3 kernel. Looks like one of the most common uses of
>> IKD is lockup detection - the rest is mostly used by kernel hackers. I'll
>> post it together with some other x86 APIC fixes and irq cleanups soon.
>
> Why wouldn't the NMI oopser work on a given SMP system? And why the
>timer has to be delivered to the BP if these NMIs are exploited? I don't
>see any reasons but I might be missing something.
>
> Note that even if IRQ0 is not connected to any I/O APIC, the LINT0 line
>is usually broadcasted and even if it's not, NMI may be distributed by the
>catcher using "all excluding self" IPI. It is theoretically possible that
>there exist i82489DX based systems that have the NMI output of local APICs
>not connected to the NMI input of CPUs, but have you ever seen or heard of
>such a brain-damaged system? It wouldn't be MPS-compliant, anyway.
>
> I might add a modified NMI oopser to my pending APIC patches (I should
>make them available tomorrow, BTW -- they are almost ready but I need to
>perform some additional tests), if you don't object, that would handle all
>legal cases of timer configuration. The current implementation included
>in the ikd patch is somewhat simplistic, indeed.
>
> I don't object the oopser to be optional, of course.
>
>- --
>+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
>+--------------------------------------------------------------+
>+ e-mail: macro@ds2.pg.gda.pl, PGP key available +
>
>
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>End of linux-kernel-digest V1 #4467
>***********************************
>
>To subscribe to linux-kernel-digest, send the command:
>
> subscribe linux-kernel-digest
>
>in the body of a message to "Majordomo@vger.rutgers.edu". If you want
>to subscribe something other than the account the mail is coming from,
>such as a local redistribution list, then append that address to the
>"subscribe" command; for example, to subscribe "local-linux-kernel":
>
> subscribe linux-kernel-digest local-linux-kernel@your.domain.net
>
>A non-digest (direct mail) version of this list is also available; to
>subscribe to that instead, replace all instances of "linux-kernel-digest"
>in the commands above with "linux-kernel".
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/