Messages in this thread Patch in this message | | | From | "Alex" <> | Subject | Ext3 filesystem info? | Date | Thu, 16 Sep 1999 13:35:44 -0400 |
| |
Any news on ext3 filesystem?? Where can I get info?
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/
| |