* Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery --the elegant solution)
From: Giacomo Catenazzi @ 2002-01-15 15:01 UTC (permalink / raw)
To: Marco Colombo; +Cc: linux-kernel
In-Reply-To: <Pine.LNX.4.33.0201151517550.11441-100000@Megathlon.ESI>
Marco Colombo wrote:
>>
>>The main discussion was in kbuild-devel list.
>>
>
> Uh, my mailbox hurts just at the thought of even more posting on the suject.
>
In kbuild: less people, less traffic, more discussion, less flames
> Kernel tarballs are for hackers. Marcelo can't test any configuration
> the autoconfigurator can produce. So basically it means an untested
> kernel. Running untested kernel isn't a job for Joe User, and never
> will be.
Also what are the stable series?
But you think your distribution test the kernel in all possible
use? With all possible hardware configuration?
Autoconfiguration will configure a compile and booting kernel.
(but on old machine). Neither vendor can assure you that the kernel
will work for a particolar permutation of hardware, and mainly
it is indipendent from configuration.
> Vendors and kernel developers have different goals. That horrible hack
> that fixes some bug or misbehavior fits fine into a vendor kernel, and
> has no place in Marcelo's tree; the same for that C++ written, cross OS
> crap driver for hardware XYZ. Users want it, vendors provide it.
> Different goals, different targets.
Change distribution. In Debian/unstable developers and distribution are
hardly linked!
Why do you need someone in the 'layer' between developers
and user?
> Autoconfiguration is nice. But please move the topic elsewhere.
Right. Let stop it
giacomo
^ permalink raw reply
* Re: [parisc-linux] vmware question?
From: Michael Wood @ 2002-01-15 15:03 UTC (permalink / raw)
To: parisc-linux
In-Reply-To: <3C3F9C83.850FFD03@hpsgnsw.sgp.hp.com>
On Fri, Jan 11, 2002 at 07:16:35PM -0700, chenhp@hpsgnsw.sgp.hp.com wrote:
> Hi,
> I'm wondering to know if vmware can work on PA-Linux ?
Bochs works :) Tried it out earlier today, but just with
FreeDOS. Nothing more complex.
http://bochs.sourceforge.net/
--
Michael Wood <mwood@its.uct.ac.za>
^ permalink raw reply
* Re: arpd not working in 2.4.17 or 2.5.1
From: Luigi Genoni @ 2002-01-15 15:02 UTC (permalink / raw)
To: Amit Gupta; +Cc: linux-kernel
In-Reply-To: <3C4380F2.292475B9@cmdmail.amd.com>
Latest kernel I saw working with arpd (user space daemon) I am manteining
is 2.2.16, then from 2.4.4 (for 2.4 series), some changes were done to
kernel so that the kernel does not talk correctly with the device
/dev/arpd anymore.
It is not the first time I write about this on lkml, but it seems none is
interested in manteining the kernel space component for arpd support.
I did some investigation, but the code for arpd support itself inside of
the kernel seems to be ok, something else is wrong with neighour.c.
So at less I can say the user space daemon works well on 2.2.16 I have
around ;).
Luigi
On Mon, 14 Jan 2002, Amit Gupta wrote:
>
> Hi All,
>
> I am running 2.5.1 kernel on a 2 AMD processor system and have enable
> routing messages, netlink and arpd support inside kernel as described in
> arpd docs.
>
> Then after making 36 character devices, when I run arpd, it's starts up
> but always keeps silent (strace) and the kernel also does not keep it's
> 256 arp address limit.
>
> Pls help fix it, I need linux to be able to talk to more than 1024
> clients.
>
> Thanks in Advance.
>
> Amit
> amit.gupta@amd.com
>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply
* Re: highmem=system killer, 2.2.17=performance killer ?
From: Stephan von Krawczynski @ 2002-01-15 15:00 UTC (permalink / raw)
To: Klaus Meyer; +Cc: linux-kernel
In-Reply-To: <3C439E6D.B2B8C5B8@m3its.de>
On Tue, 15 Jan 2002 04:13:49 +0100
Klaus Meyer <k.meyer@m3its.de> wrote:
> i've got serious problems using 2.4.x kernels using highmem support.
> It seems to me that i'm not the only one, but the difference to most
> other ones is,
> that i can't use highmem because the system performance is terrible
> slow.
>
> the testbed:
> 1) Asus CUR-DLS (Server Set LE III) with two 1Ghz Pentiums, 2GB of ram
Interestingly I have about the same setup and use, only I transfer about 25 GB
a day via nfs to an Asus CUV4XD with 2 GB under 2.4.18-pre3 and do not
experience any problem so far. I haven't had any with 2.4.17, too. Cache is
pretty heavy used, but I experience no slowdown or other weird things. Can this
be somehow chipset related? Maybe something about the DGE cards? I am using TP
100MBit tulip-based.
Regards,
Stephan
^ permalink raw reply
* Re: Significant Slowdown Occuring in 2.2 starting with 19pre2
From: Steve Sheftic @ 2002-01-15 14:57 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <p733d17kcdv.fsf@oldwotan.suse.de>
>
> Also the merge of blkdev-in-pagecache. If the magneto optical disk
> has a weird blocksize < PAGE_CACHE_SIZE (doesn't it have 2k normally?)
> then there could be problems.
>
I neglected to mention that. Yes, the media I am using has a 2k
blocksize.
And 2.4.17 is working great - this is only happening with recent 2.2.
Steve
^ permalink raw reply
* Re: [RFC] klibc requirements
From: David Lang @ 2002-01-15 14:54 UTC (permalink / raw)
To: Felix von Leitner; +Cc: Albert D. Cahalan, Greg KH, linux-kernel, andersen
In-Reply-To: <20020115115544.GA20020@codeblau.de>
On Tue, 15 Jan 2002, Felix von Leitner wrote:
> Date: Tue, 15 Jan 2002 12:55:44 +0100
> From: Felix von Leitner <felix-dietlibc@fefe.de>
> To: Albert D. Cahalan <acahalan@cs.uml.edu>
> Cc: Greg KH <greg@kroah.com>, linux-kernel@vger.kernel.org,
> andersen@codepoet.org
> Subject: Re: [RFC] klibc requirements
>
> Thus spake Albert D. Cahalan (acahalan@cs.uml.edu):
> > I think the dietlibc idea has to be scrapped so we can run BSD apps.
> > (and others maybe, but I'm not looking to start a flame war)
>
> What apps are you talking about?
he's talking about licencing issues.
LGPL libc replacements can be used with any program, GPL libc replacements
can only be used with programs licenced in a way that can be combined with
GPL (and the resulting program is GPL.
as an example (not for the boot process, but an example of a replacement
libc use) I use the firewall toolkit, it has been around for a _loooong_
time (in software terms anyway) and has a firly odd licence (free for you
to use, source available, cannot sell it) which is not compatable with the
GPL. with glibc staticly linked this makes huge binaries, with libc5 they
were a lot smaller. I would like to try to use this small libc for these
proxies, but if the library is GPL, not LGPL I'm not allowed to.
David Lang
^ permalink raw reply
* Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery --the elegant solution)
From: Marco Colombo @ 2002-01-15 14:50 UTC (permalink / raw)
To: Giacomo Catenazzi; +Cc: linux-kernel
In-Reply-To: <3C442BDB.7010008@debian.org>
On Tue, 15 Jan 2002, Giacomo Catenazzi wrote:
>
>
> Marco Colombo wrote:
>
>
> > Alan, Eric (and others, too), please.
> > Of course the autoconfigurator is an useful piece of software.
> > And of course Eric is posting to the wrong list here. Kernel developers
> > don't need any autoconfigurator at all (yes, it's just "extra state").
>
>
> The main discussion was in kbuild-devel list.
Uh, my mailbox hurts just at the thought of even more posting on the suject.
> > Eric, Aunt Tillie doesn't need any custom-made, untested, probably not
> > working kernel. QA comes at a price. The lastest VM fix may take a while
> > to reach mainstream kernels. That's life.
>
> Maybe this force kernel maintainer to merge the tested and trusted
> distribution patches into the main kernel's branches.
Which means, in Alan's (and Yoda's) words, even more perturbations of the
Source. I don't really like the idea of kernel maintainers forced into
anything...
Kernel tarballs are for hackers. Marcelo can't test any configuration
the autoconfigurator can produce. So basically it means an untested
kernel. Running untested kernel isn't a job for Joe User, and never
will be.
Some distro vendor may be interested in an easy, do-it-yourself kernel
compilation & customization tool. It brings almost nothing to kernel
developers.
Vendors and kernel developers have different goals. That horrible hack
that fixes some bug or misbehavior fits fine into a vendor kernel, and
has no place in Marcelo's tree; the same for that C++ written, cross OS
crap driver for hardware XYZ. Users want it, vendors provide it.
Different goals, different targets.
> Anyway, the target of Linux changes. If was a toy for hacker 10 year
> ago, maybe in future will be the toy for Aunt Tillies. So:
> Forget aunts and the other scenarios of Eric.
> Let talk about what autoconfigure can do yet (aka the creation of
> a /proc/drivers (better in /dev) with a list of all running
> kernel drivers. aka how the modules will be in the next months)
Creating .config (or whatever) is an userland issue, IMHO. /proc/driver
and the like is another issue, as it can be useful in general.
Autoconfiguration is nice. But please move the topic elsewhere.
.TM.
--
____/ ____/ /
/ / / Marco Colombo
___/ ___ / / Technical Manager
/ / / ESI s.r.l.
_____/ _____/ _/ Colombo@ESI.it
^ permalink raw reply
* 2.4.17: Hardwired limit of parallel nfs mounts
From: Rainer Krienke @ 2002-01-15 14:49 UTC (permalink / raw)
To: linux-kernel
Hello to everyone,
I have a question regarding the maximal number of NFS-mounts in Kernel 2.4.17
(on a i686 box running suse7.3). I found out that this number is hardwired
in the kernel in linux/fs/super.c in the bitmap unnamed_dev_in_use.
Since we have put all the data of our users (~4000) on several central NFS
servers it happens sometimes that eg. the mailserver (running linux) has to
mount several hundred home directories by autofs e.g. when users are reading
Mail by POP/IMAP. In this sense the limit of 256 is quite small. Even when I
set the expiration time of autofs to a quite small value it happens sometimes
that autfs cannot mount home directories since the mtable is currently full
(errno: EINVAL).
To change the limit I simply replaced the limit of 256 by 1024 in super.c. In
this situation I can mount about 800 NFS-directories at the same time and
then the kernel complains in /var/log/messages:
....
automount[861]: attempting to mount entry /home/anotheruser
Jan 15 09:03:11 bris kernel: RPC: Can't bind to reserved port (98).
Jan 15 09:03:11 bris kernel: NFS: cannot create RPC transport.
Jan 15 09:03:11 bris kernel: nfs warning: mount version older than kernel
Jan 15 09:03:11 bris kernel: RPC: Can't bind to reserved port (98).
Jan 15 09:03:11 bris kernel: NFS: cannot create RPC transport.
Nothing serious happens, exept that I cannot mount more NFS-Dirs until
autofs has expired some of the ones previously mounted.
Does anyone know why this happens? Do I have to change anything else of the
kernel to allow a number of about 1024 NFS-mounts at the same time?
Wouldnt it be generally a good idea to raise this limit or to make the value
configurable in any way? Why does this limit still exist anyway?
Thanks to all
Rainer
--
---------------------------------------------------------------------
Rainer Krienke krienke@uni-koblenz.de
Universitaet Koblenz, http://www.uni-koblenz.de/~krienke
Rechenzentrum, Voice: +49 261 287 - 1312
Rheinau 1, 56075 Koblenz, Germany Fax: +49 261 287 - 1001312
---------------------------------------------------------------------
^ permalink raw reply
* Re: floating point exception
From: Richard B. Johnson @ 2002-01-15 14:46 UTC (permalink / raw)
To: Zwane Mwaikambo; +Cc: Christian Thalinger, Linux Kernel
In-Reply-To: <Pine.LNX.4.33.0201151633300.2080-100000@netfinity.realnet.co.sz>
On Tue, 15 Jan 2002, Zwane Mwaikambo wrote:
> On 14 Jan 2002, Christian Thalinger wrote:
>
> > It seems the floating point exception is only raised with a new data
> > package. Is there a simple way to raise such a exception?
>
> New data package? And does the same behaviour re-occur after the fpu
> exception? ie programs start segfaulting etc. Can you try doing a "dmesg"
> after the segfaults and fpu exception and see if there is anything in the
> kernel ring buffer too.
>
> Regards,
> Zwane Mwaikambo
This will allow you to generate some math-errors and see if everything
works okay. By default, upon process creation, math errors like
/0 are masked.
/*
* Note FPU control only exists per process. Therefore, you have
* to set up the FPU before you use it in any program.
*/
#include <i386/fpu_control.h>
#define FPU_MASK (_FPU_MASK_IM |\
_FPU_MASK_DM |\
_FPU_MASK_ZM |\
_FPU_MASK_OM |\
_FPU_MASK_UM |\
_FPU_MASK_PM)
void fpu()
{
__setfpucw(_FPU_DEFAULT & ~FPU_MASK);
}
main() {
double zero=0.0;
double one=1.0;
fpu();
one /=zero;
}
Cheers,
Dick Johnson
Penguin : Linux version 2.4.1 on an i686 machine (797.90 BogoMips).
I was going to compile a list of innovations that could be
attributed to Microsoft. Once I realized that Ctrl-Alt-Del
was handled in the BIOS, I found that there aren't any.
^ permalink raw reply
* [PATCH] fat_read_super() cleanup, and small bug fix <2>
From: OGAWA Hirofumi @ 2002-01-15 14:46 UTC (permalink / raw)
To: linux-kernel; +Cc: Linus Torvalds
Hi,
The patch is re-diff to the linux-2.5.2, and including directory
entries limit.
The change is the following:
- check the maximum directory entries.
- don't support fat option. I think this option shouldn't use.
- check the 4 fields instead of magick number. Then, if silent,
don't output messages.
- remove debug message. More useful message is outputted.
- fixed bug in fat_clusters_flush().
- output message of useing nls instead of specified nls.
- cleanup.
Please apply.
--
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
diff -urN linux-2.5.2/fs/fat/dir.c fat_read-super-cleanup/fs/fat/dir.c
--- linux-2.5.2/fs/fat/dir.c Sat Oct 13 05:48:42 2001
+++ fat_read-super-cleanup/fs/fat/dir.c Tue Jan 15 20:20:38 2002
@@ -538,7 +538,6 @@
if (!memcmp(de->name,MSDOS_DOT,11))
inum = inode->i_ino;
else if (!memcmp(de->name,MSDOS_DOTDOT,11)) {
-/* inum = fat_parent_ino(inode,0); */
inum = filp->f_dentry->d_parent->d_inode->i_ino;
} else {
struct inode *tmp = fat_iget(sb, ino);
@@ -727,7 +726,13 @@
offset = curr = 0;
*bh = NULL;
row = 0;
- while (fat_get_entry(dir,&curr,bh,de,ino) > -1) {
+ while (fat_get_entry(dir, &curr, bh, de, ino) > -1) {
+ /* check the maximum size of directory */
+ if (curr >= FAT_MAX_DIR_SIZE) {
+ fat_brelse(sb, *bh);
+ return -ENOSPC;
+ }
+
if (IS_FREE((*de)->name)) {
if (++row == slots)
return offset;
@@ -742,7 +747,10 @@
if (!new_bh)
return -ENOSPC;
fat_brelse(sb, new_bh);
- do fat_get_entry(dir,&curr,bh,de,ino); while (++row<slots);
+ do {
+ fat_get_entry(dir, &curr, bh, de, ino);
+ } while (++row < slots);
+
return offset;
}
diff -urN linux-2.5.2/fs/fat/inode.c fat_read-super-cleanup/fs/fat/inode.c
--- linux-2.5.2/fs/fat/inode.c Sat Jan 12 03:38:07 2002
+++ fat_read-super-cleanup/fs/fat/inode.c Tue Jan 15 20:22:26 2002
@@ -208,7 +208,7 @@
}
-static int parse_options(char *options,int *fat, int *debug,
+static int parse_options(char *options, int *debug,
struct fat_mount_options *opts,
char *cvf_format, char *cvf_options)
{
@@ -227,7 +227,7 @@
opts->shortname = 0;
opts->utf8 = 0;
opts->iocharset = NULL;
- *debug = *fat = 0;
+ *debug = 0;
if (!options)
goto out;
@@ -305,13 +305,8 @@
else *debug = 1;
}
else if (!strcmp(this_char,"fat")) {
- if (!value || !*value) ret = 0;
- else {
- *fat = simple_strtoul(value,&value,0);
- if (*value || (*fat != 12 && *fat != 16 &&
- *fat != 32))
- ret = 0;
- }
+ printk("FAT: fat option is obsolete, "
+ "not supported now\n");
}
else if (!strcmp(this_char,"quiet")) {
if (value) ret = 0;
@@ -328,8 +323,6 @@
else if (!strcmp(this_char,"codepage") && value) {
opts->codepage = simple_strtoul(value,&value,0);
if (*value) ret = 0;
- else printk ("MSDOS FS: Using codepage %d\n",
- opts->codepage);
}
else if (!strcmp(this_char,"iocharset") && value) {
p = value;
@@ -348,7 +341,6 @@
opts->iocharset = buffer;
memcpy(buffer, p, len);
buffer[len] = 0;
- printk("MSDOS FS: IO charset %s\n", buffer);
} else
ret = 0;
}
@@ -373,11 +365,37 @@
return ret;
}
+static void fat_calc_dir_size(struct inode *inode)
+{
+ struct super_block *sb = inode->i_sb;
+ int nr;
+
+ inode->i_size = 0;
+ if (MSDOS_I(inode)->i_start == 0)
+ return;
+
+ nr = MSDOS_I(inode)->i_start;
+ do {
+ inode->i_size += 1 << MSDOS_SB(sb)->cluster_bits;
+ if (!(nr = fat_access(sb, nr, -1))) {
+ printk("FAT: Directory %ld: bad FAT\n",
+ inode->i_ino);
+ break;
+ }
+ if (inode->i_size > FAT_MAX_DIR_SIZE) {
+ fat_fs_panic(sb, "Directory %ld: "
+ "exceeded the maximum size of directory",
+ inode->i_ino);
+ inode->i_size = FAT_MAX_DIR_SIZE;
+ break;
+ }
+ } while (nr != -1);
+}
+
static void fat_read_root(struct inode *inode)
{
struct super_block *sb = inode->i_sb;
struct msdos_sb_info *sbi = MSDOS_SB(sb);
- int nr;
INIT_LIST_HEAD(&MSDOS_I(inode)->i_fat_hash);
MSDOS_I(inode)->i_location = 0;
@@ -391,16 +409,7 @@
inode->i_fop = &fat_dir_operations;
if (sbi->fat_bits == 32) {
MSDOS_I(inode)->i_start = sbi->root_cluster;
- if ((nr = MSDOS_I(inode)->i_start) != 0) {
- while (nr != -1) {
- inode->i_size += 1 << sbi->cluster_bits;
- if (!(nr = fat_access(sb, nr, -1))) {
- printk("Directory %ld: bad FAT\n",
- inode->i_ino);
- break;
- }
- }
- }
+ fat_calc_dir_size(inode);
} else {
MSDOS_I(inode)->i_start = 0;
inode->i_size = sbi->dir_entries * sizeof(struct msdos_dir_entry);
@@ -550,11 +559,9 @@
struct buffer_head *bh;
struct fat_boot_sector *b;
struct msdos_sb_info *sbi = MSDOS_SB(sb);
- char *p;
- int logical_sector_size, hard_blksize, fat_clusters = 0;
+ int logical_sector_size, fat_clusters;
unsigned int total_sectors, rootdir_sectors;
- int fat32, debug, error, fat, cp;
- struct fat_mount_options opts;
+ int debug, cp;
char buf[50];
int i;
char cvf_format[21];
@@ -562,22 +569,20 @@
cvf_format[0] = '\0';
cvf_options[0] = '\0';
- sbi->cvf_format = NULL;
sbi->private_data = NULL;
- sbi->dir_ops = fs_dir_inode_ops;
-
- sb->s_maxbytes = MAX_NON_LFS;
+ sb->s_magic = MSDOS_SUPER_MAGIC;
sb->s_op = &fat_sops;
+ sbi->dir_ops = fs_dir_inode_ops;
+ sbi->cvf_format = &default_cvf;
- opts.isvfat = sbi->options.isvfat;
- if (!parse_options((char *) data, &fat, &debug, &opts,
+ if (!parse_options((char *)data, &debug, &sbi->options,
cvf_format, cvf_options))
goto out_fail;
- /* N.B. we should parse directly into the sb structure */
- memcpy(&(sbi->options), &opts, sizeof(struct fat_mount_options));
fat_cache_init();
+ /* set up enough so that it can read an inode */
+ init_MUTEX(&sbi->fat_lock);
sb_min_blocksize(sb, 512);
bh = sb_bread(sb, 0);
@@ -586,37 +591,37 @@
goto out_fail;
}
-/*
- * The DOS3 partition size limit is *not* 32M as many people think.
- * Instead, it is 64K sectors (with the usual sector size being
- * 512 bytes, leading to a 32M limit).
- *
- * DOS 3 partition managers got around this problem by faking a
- * larger sector size, ie treating multiple physical sectors as
- * a single logical sector.
- *
- * We can accommodate this scheme by adjusting our cluster size,
- * fat_start, and data_start by an appropriate value.
- *
- * (by Drew Eckhardt)
- */
-
-
b = (struct fat_boot_sector *) bh->b_data;
+ if (!b->secs_track) {
+ if (!silent)
+ printk("FAT: bogus sectors-per-track value\n");
+ brelse(bh);
+ goto out_invalid;
+ }
+ if (!b->heads) {
+ if (!silent)
+ printk("FAT: bogus number-of-heads value\n");
+ brelse(bh);
+ goto out_invalid;
+ }
logical_sector_size =
CF_LE_W(get_unaligned((unsigned short *) &b->sector_size));
if (!logical_sector_size
- || (logical_sector_size & (logical_sector_size - 1))) {
- printk("FAT: bogus logical sector size %d\n",
- logical_sector_size);
+ || (logical_sector_size & (logical_sector_size - 1))
+ || (logical_sector_size < 512)
+ || (PAGE_CACHE_SIZE < logical_sector_size)) {
+ if (!silent)
+ printk("FAT: bogus logical sector size %d\n",
+ logical_sector_size);
brelse(bh);
goto out_invalid;
}
-
sbi->cluster_size = b->cluster_size;
if (!sbi->cluster_size
|| (sbi->cluster_size & (sbi->cluster_size - 1))) {
- printk("FAT: bogus cluster size %d\n", sbi->cluster_size);
+ if (!silent)
+ printk("FAT: bogus cluster size %d\n",
+ sbi->cluster_size);
brelse(bh);
goto out_invalid;
}
@@ -625,47 +630,62 @@
printk("FAT: logical sector size too small for device"
" (logical sector size = %d)\n", logical_sector_size);
brelse(bh);
- goto out_invalid;
+ goto out_fail;
}
+ if (logical_sector_size > sb->s_blocksize) {
+ brelse(bh);
- hard_blksize = sb->s_blocksize;
+ if (!sb_set_blocksize(sb, logical_sector_size)) {
+ printk("FAT: unable to set blocksize %d\n",
+ logical_sector_size);
+ goto out_fail;
+ }
+ bh = sb_bread(sb, 0);
+ if (bh == NULL) {
+ printk("FAT: unable to read boot sector"
+ " (logical sector size = %lu)\n",
+ sb->s_blocksize);
+ goto out_fail;
+ }
+ b = (struct fat_boot_sector *) bh->b_data;
+ }
- sbi->cluster_bits = ffs(logical_sector_size * sbi->cluster_size) - 1;
+ sbi->cluster_bits = ffs(sb->s_blocksize * sbi->cluster_size) - 1;
sbi->fats = b->fats;
+ sbi->fat_bits = 0; /* Don't know yet */
sbi->fat_start = CF_LE_W(b->reserved);
- if (!b->fat_length && b->fat32_length) {
+ sbi->fat_length = CF_LE_W(b->fat_length);
+ sbi->root_cluster = 0;
+ sbi->free_clusters = -1; /* Don't know yet */
+ sbi->prev_free = 0;
+
+ if (!sbi->fat_length && b->fat32_length) {
struct fat_boot_fsinfo *fsinfo;
struct buffer_head *fsinfo_bh;
- int fsinfo_block, fsinfo_offset;
/* Must be FAT32 */
- fat32 = 1;
+ sbi->fat_bits = 32;
sbi->fat_length = CF_LE_L(b->fat32_length);
sbi->root_cluster = CF_LE_L(b->root_cluster);
- sbi->fsinfo_sector = CF_LE_W(b->info_sector);
/* MC - if info_sector is 0, don't multiply by 0 */
+ sbi->fsinfo_sector = CF_LE_W(b->info_sector);
if (sbi->fsinfo_sector == 0)
sbi->fsinfo_sector = 1;
- fsinfo_block =
- (sbi->fsinfo_sector * logical_sector_size) / hard_blksize;
- fsinfo_offset =
- (sbi->fsinfo_sector * logical_sector_size) % hard_blksize;
- fsinfo_bh = bh;
- if (fsinfo_block != 0) {
- fsinfo_bh = sb_bread(sb, fsinfo_block);
- if (fsinfo_bh == NULL) {
- printk("FAT: bread failed, FSINFO block"
- " (blocknr = %d)\n", fsinfo_block);
- brelse(bh);
- goto out_invalid;
- }
+ fsinfo_bh = sb_bread(sb, sbi->fsinfo_sector);
+ if (fsinfo_bh == NULL) {
+ printk("FAT: bread failed, FSINFO block"
+ " (sector = %lu)\n", sbi->fsinfo_sector);
+ brelse(bh);
+ goto out_fail;
}
- fsinfo = (struct fat_boot_fsinfo *)&fsinfo_bh->b_data[fsinfo_offset];
+
+ fsinfo = (struct fat_boot_fsinfo *)fsinfo_bh->b_data;
if (!IS_FSINFO(fsinfo)) {
printk("FAT: Did not find valid FSINFO signature.\n"
- "Found signature1 0x%x signature2 0x%x sector=%ld.\n",
+ " Found signature1 0x%08x signature2 0x%08x"
+ " (sector = %lu)\n",
CF_LE_L(fsinfo->signature1),
CF_LE_L(fsinfo->signature2),
sbi->fsinfo_sector);
@@ -673,140 +693,110 @@
sbi->free_clusters = CF_LE_L(fsinfo->free_clusters);
}
- if (fsinfo_block != 0)
- brelse(fsinfo_bh);
- } else {
- fat32 = 0;
- sbi->fat_length = CF_LE_W(b->fat_length);
- sbi->root_cluster = 0;
- sbi->free_clusters = -1; /* Don't know yet */
+ brelse(fsinfo_bh);
}
- sbi->dir_per_block = logical_sector_size / sizeof(struct msdos_dir_entry);
+ sbi->dir_per_block = sb->s_blocksize / sizeof(struct msdos_dir_entry);
sbi->dir_per_block_bits = ffs(sbi->dir_per_block) - 1;
sbi->dir_start = sbi->fat_start + sbi->fats * sbi->fat_length;
sbi->dir_entries =
CF_LE_W(get_unaligned((unsigned short *)&b->dir_entries));
+ if (sbi->dir_entries & (sbi->dir_per_block - 1)) {
+ printk("FAT: bogus directroy-entries per block\n");
+ brelse(bh);
+ goto out_invalid;
+ }
+
rootdir_sectors = sbi->dir_entries
- * sizeof(struct msdos_dir_entry) / logical_sector_size;
+ * sizeof(struct msdos_dir_entry) / sb->s_blocksize;
sbi->data_start = sbi->dir_start + rootdir_sectors;
total_sectors = CF_LE_W(get_unaligned((unsigned short *)&b->sectors));
if (total_sectors == 0)
total_sectors = CF_LE_L(b->total_sect);
sbi->clusters = (total_sectors - sbi->data_start) / sbi->cluster_size;
- error = 0;
- if (!error) {
- sbi->fat_bits = fat32 ? 32 :
- (fat ? fat :
- (sbi->clusters > MSDOS_FAT12 ? 16 : 12));
- fat_clusters =
- sbi->fat_length * logical_sector_size * 8 / sbi->fat_bits;
- error = !sbi->fats || (sbi->dir_entries & (sbi->dir_per_block - 1))
- || sbi->clusters + 2 > fat_clusters + MSDOS_MAX_EXTRA
- || logical_sector_size < 512
- || PAGE_CACHE_SIZE < logical_sector_size
- || !b->secs_track || !b->heads;
- }
- brelse(bh);
+ if (sbi->fat_bits != 32)
+ sbi->fat_bits = (sbi->clusters > MSDOS_FAT12) ? 16 : 12;
- if (error)
- goto out_invalid;
+ /* check that FAT table does not overflow */
+ fat_clusters = sbi->fat_length * sb->s_blocksize * 8 / sbi->fat_bits;
+ if (sbi->clusters > fat_clusters - 2)
+ sbi->clusters = fat_clusters - 2;
+
+ brelse(bh);
- sb_set_blocksize(sb, logical_sector_size);
- sbi->cvf_format = &default_cvf;
if (!strcmp(cvf_format, "none"))
i = -1;
else
- i = detect_cvf(sb,cvf_format);
- if (i >= 0)
- error = cvf_formats[i]->mount_cvf(sb, cvf_options);
- if (error || debug) {
- /* The MSDOS_CAN_BMAP is obsolete, but left just to remember */
- printk("[MS-DOS FS Rel. 12,FAT %d,check=%c,conv=%c,"
- "uid=%d,gid=%d,umask=%03o%s]\n",
- sbi->fat_bits,opts.name_check,
- opts.conversion,opts.fs_uid,opts.fs_gid,opts.fs_umask,
- MSDOS_CAN_BMAP(sbi) ? ",bmap" : "");
- printk("[me=0x%x,cs=%d,#f=%d,fs=%d,fl=%ld,ds=%ld,de=%d,data=%ld,"
- "se=%u,ts=%u,ls=%d,rc=%ld,fc=%u]\n",
- b->media, sbi->cluster_size, sbi->fats,
- sbi->fat_start, sbi->fat_length, sbi->dir_start,
- sbi->dir_entries, sbi->data_start,
- CF_LE_W(get_unaligned((unsigned short *)&b->sectors)),
- CF_LE_L(b->total_sect), logical_sector_size,
- sbi->root_cluster, sbi->free_clusters);
- printk ("hard sector size = %d\n", hard_blksize);
- }
- if (i < 0)
- if (sbi->clusters + 2 > fat_clusters)
- sbi->clusters = fat_clusters - 2;
- if (error)
- goto out_invalid;
-
- sb->s_magic = MSDOS_SUPER_MAGIC;
- /* set up enough so that it can read an inode */
- init_MUTEX(&sbi->fat_lock);
- sbi->prev_free = 0;
+ i = detect_cvf(sb, cvf_format);
+ if (i >= 0) {
+ if (cvf_formats[i]->mount_cvf(sb, cvf_options))
+ goto out_invalid;
+ }
- cp = opts.codepage ? opts.codepage : 437;
+ cp = sbi->options.codepage ? sbi->options.codepage : 437;
sprintf(buf, "cp%d", cp);
sbi->nls_disk = load_nls(buf);
if (! sbi->nls_disk) {
/* Fail only if explicit charset specified */
- if (opts.codepage != 0)
+ if (sbi->options.codepage != 0) {
+ printk("FAT: codepage %s not found\n", buf);
goto out_fail;
+ }
sbi->options.codepage = 0; /* already 0?? */
sbi->nls_disk = load_nls_default();
}
+ if (!silent)
+ printk("FAT: Using codepage %s\n", sbi->nls_disk->charset);
- sbi->nls_io = NULL;
- if (sbi->options.isvfat && !opts.utf8) {
- p = opts.iocharset ? opts.iocharset : CONFIG_NLS_DEFAULT;
- sbi->nls_io = load_nls(p);
- if (! sbi->nls_io)
- /* Fail only if explicit charset specified */
- if (opts.iocharset)
- goto out_unload_nls;
+ if (sbi->options.isvfat && !sbi->options.utf8) {
+ if (sbi->options.iocharset != NULL) {
+ sbi->nls_io = load_nls(sbi->options.iocharset);
+ if (!sbi->nls_io) {
+ printk("FAT: IO charset %s not found\n",
+ sbi->options.iocharset);
+ goto out_fail;
+ }
+ } else
+ sbi->nls_io = load_nls_default();
+ if (!silent)
+ printk("FAT: Using IO charset %s\n",
+ sbi->nls_io->charset);
}
- if (! sbi->nls_io)
- sbi->nls_io = load_nls_default();
root_inode = new_inode(sb);
if (!root_inode)
- goto out_unload_nls;
+ goto out_fail;
+
root_inode->i_ino = MSDOS_ROOT_INO;
root_inode->i_version = 0;
fat_read_root(root_inode);
insert_inode_hash(root_inode);
sb->s_root = d_alloc_root(root_inode);
- if (!sb->s_root)
- goto out_no_root;
+ if (!sb->s_root) {
+ printk("FAT: get root inode failed\n");
+ iput(root_inode);
+ goto out_fail;
+ }
if(i >= 0) {
sbi->cvf_format = cvf_formats[i];
++cvf_format_use_count[i];
}
return sb;
-out_no_root:
- printk("FAT: get root inode failed\n");
- iput(root_inode);
- unload_nls(sbi->nls_io);
-out_unload_nls:
- unload_nls(sbi->nls_disk);
- goto out_fail;
out_invalid:
- if (!silent) {
+ if (!silent)
printk("VFS: Can't find a valid FAT filesystem on dev %s.\n",
sb->s_id);
- }
out_fail:
- if (opts.iocharset) {
- printk("FAT: freeing iocharset=%s\n", opts.iocharset);
- kfree(opts.iocharset);
- }
- if(sbi->private_data)
+ if (sbi->nls_io)
+ unload_nls(sbi->nls_io);
+ if (sbi->nls_disk)
+ unload_nls(sbi->nls_disk);
+ if (sbi->options.iocharset)
+ kfree(sbi->options.iocharset);
+ if (sbi->private_data)
kfree(sbi->private_data);
sbi->private_data = NULL;
@@ -882,7 +872,6 @@
{
struct super_block *sb = inode->i_sb;
struct msdos_sb_info *sbi = MSDOS_SB(sb);
- int nr;
INIT_LIST_HEAD(&MSDOS_I(inode)->i_fat_hash);
MSDOS_I(inode)->i_location = 0;
@@ -913,15 +902,7 @@
inode->i_nlink = 1;
}
#endif
- if ((nr = MSDOS_I(inode)->i_start) != 0)
- while (nr != -1) {
- inode->i_size += 1 << sbi->cluster_bits;
- if (!(nr = fat_access(sb, nr, -1))) {
- printk("Directory %ld: bad FAT\n",
- inode->i_ino);
- break;
- }
- }
+ fat_calc_dir_size(inode);
MSDOS_I(inode)->mmu_private = inode->i_size;
} else { /* not a directory */
inode->i_generation |= 1;
diff -urN linux-2.5.2/fs/fat/misc.c fat_read-super-cleanup/fs/fat/misc.c
--- linux-2.5.2/fs/fat/misc.c Sat Jan 5 02:42:12 2002
+++ fat_read-super-cleanup/fs/fat/misc.c Tue Jan 15 20:24:57 2002
@@ -38,15 +38,25 @@
* read-only. The file system can be made writable again by remounting it.
*/
-void fat_fs_panic(struct super_block *s,const char *msg)
+static char panic_msg[512];
+
+void fat_fs_panic(struct super_block *s, const char *fmt, ...)
{
int not_ro;
+ va_list args;
+
+ va_start (args, fmt);
+ vsnprintf (panic_msg, sizeof(panic_msg), fmt, args);
+ va_end (args);
not_ro = !(s->s_flags & MS_RDONLY);
- if (not_ro) s->s_flags |= MS_RDONLY;
- printk("Filesystem panic (dev %s).\n %s\n", s->s_id, msg);
if (not_ro)
- printk(" File system has been set read-only\n");
+ s->s_flags |= MS_RDONLY;
+
+ printk("FAT: Filesystem panic (dev %s)\n"
+ " %s\n", s->s_id, panic_msg);
+ if (not_ro)
+ printk(" File system has been set read-only\n");
}
@@ -102,13 +112,14 @@
/* Sanity check */
if (!IS_FSINFO(fsinfo)) {
printk("FAT: Did not find valid FSINFO signature.\n"
- "Found signature1 0x%x signature2 0x%x sector=%ld.\n",
+ " Found signature1 0x%08x signature2 0x%08x"
+ " (sector = %lu)\n",
CF_LE_L(fsinfo->signature1), CF_LE_L(fsinfo->signature2),
MSDOS_SB(sb)->fsinfo_sector);
- return;
+ } else {
+ fsinfo->free_clusters = CF_LE_L(MSDOS_SB(sb)->free_clusters);
+ fat_mark_buffer_dirty(sb, bh);
}
- fsinfo->free_clusters = CF_LE_L(MSDOS_SB(sb)->free_clusters);
- fat_mark_buffer_dirty(sb, bh);
fat_brelse(sb, bh);
}
@@ -472,11 +483,13 @@
int *number,int *ino,struct buffer_head **res_bh,struct msdos_dir_entry
**res_de)
{
- int count,cluster;
+ int count, cluster;
+ unsigned long dir_size;
#ifdef DEBUG
printk("raw_scan_nonroot: start=%d\n",start);
#endif
+ dir_size = 0;
do {
for (count = 0; count < MSDOS_SB(sb)->cluster_size; count++) {
if ((cluster = raw_scan_sector(sb,(start-2)*
@@ -484,6 +497,13 @@
count,name,number,ino,res_bh,res_de)) >= 0)
return cluster;
}
+ dir_size += 1 << MSDOS_SB(sb)->cluster_bits;
+ if (dir_size > FAT_MAX_DIR_SIZE) {
+ fat_fs_panic(sb, "Directory %d: "
+ "exceeded the maximum size of directory",
+ start);
+ break;
+ }
if (!(start = fat_access(sb,start,-1))) {
fat_fs_panic(sb,"FAT error");
break;
@@ -491,8 +511,8 @@
#ifdef DEBUG
printk("next start: %d\n",start);
#endif
- }
- while (start != -1);
+ } while (start != -1);
+
return -ENOENT;
}
diff -urN linux-2.5.2/fs/vfat/namei.c fat_read-super-cleanup/fs/vfat/namei.c
--- linux-2.5.2/fs/vfat/namei.c Mon Dec 31 03:53:53 2001
+++ fat_read-super-cleanup/fs/vfat/namei.c Sun Jan 13 03:01:06 2002
@@ -446,7 +446,7 @@
(x)->lower = 1; \
(x)->upper = 1; \
(x)->valid = 1; \
-} while (0);
+} while (0)
static inline unsigned char
shortname_info_to_lcase(struct shortname_info *base,
diff -urN linux-2.5.2/include/linux/msdos_fs.h fat_read-super-cleanup/include/linux/msdos_fs.h
--- linux-2.5.2/include/linux/msdos_fs.h Fri Dec 28 01:17:43 2001
+++ fat_read-super-cleanup/include/linux/msdos_fs.h Tue Jan 15 21:08:25 2002
@@ -19,13 +19,14 @@
#define MSDOS_DPS_BITS 4 /* log2(MSDOS_DPS) */
#define MSDOS_DIR_BITS 5 /* log2(sizeof(struct msdos_dir_entry)) */
+/* directory limit */
+#define FAT_MAX_DIR_ENTRIES (65536)
+#define FAT_MAX_DIR_SIZE (FAT_MAX_DIR_ENTRIES << MSDOS_DIR_BITS)
+
#define MSDOS_SUPER_MAGIC 0x4d44 /* MD */
#define FAT_CACHE 8 /* FAT cache size */
-#define MSDOS_MAX_EXTRA 3 /* tolerate up to that number of clusters which are
- inaccessible because the FAT is too short */
-
#define ATTR_RO 1 /* read-only */
#define ATTR_HIDDEN 2 /* hidden */
#define ATTR_SYS 4 /* system */
@@ -48,11 +49,6 @@
#define CASE_LOWER_BASE 8 /* base is lower case */
#define CASE_LOWER_EXT 16 /* extension is lower case */
-#define SCAN_ANY 0 /* either hidden or not */
-#define SCAN_HID 1 /* only hidden */
-#define SCAN_NOTHID 2 /* only not hidden */
-#define SCAN_NOTANY 3 /* test name, then use SCAN_HID or SCAN_NOTHID */
-
#define DELETED_FLAG 0xe5 /* marks file as deleted when in name[0] */
#define IS_FREE(n) (!*(n) || *(const unsigned char *) (n) == DELETED_FLAG)
@@ -78,8 +74,8 @@
#define FAT_FSINFO_SIG1 0x41615252
#define FAT_FSINFO_SIG2 0x61417272
-#define IS_FSINFO(x) (CF_LE_L((x)->signature1) == FAT_FSINFO_SIG1 \
- && CF_LE_L((x)->signature2) == FAT_FSINFO_SIG2)
+#define IS_FSINFO(x) (CF_LE_L((x)->signature1) == FAT_FSINFO_SIG1 \
+ && CF_LE_L((x)->signature2) == FAT_FSINFO_SIG2)
/*
* Inode flags
@@ -184,10 +180,6 @@
int ino; /* ino for the file */
};
-/* Determine whether this FS has kB-aligned data. */
-#define MSDOS_CAN_BMAP(mib) (!(((mib)->cluster_size & 1) || \
- ((mib)->data_start & 1)))
-
/* Convert attribute bits and a mask to the UNIX mode. */
#define MSDOS_MKMODE(a,m) (m & (a & ATTR_RO ? S_IRUGO|S_IXUGO : S_IRWXUGO))
@@ -297,7 +289,7 @@
extern int fat_notify_change(struct dentry * dentry, struct iattr * attr);
/* fat/misc.c */
-extern void fat_fs_panic(struct super_block *s, const char *msg);
+extern void fat_fs_panic(struct super_block *s, const char *fmt, ...);
extern int fat_is_binary(char conversion, char *extension);
extern void lock_fat(struct super_block *sb);
extern void unlock_fat(struct super_block *sb);
^ permalink raw reply
* Re: [linux-lvm] Re: [RFLART] kdev_t in ioctls
From: Andries.Brouwer @ 2002-01-15 14:46 UTC (permalink / raw)
To: hch, torvalds; +Cc: alan, linux-kernel, linux-lvm, viro
On Mon, 14 Jan 2002, Christoph Hellwig wrote:
>
> I know - still it makes Linus' suggestion not work on ~90% of the
> systems.
It doesn't matter if user-land compilation breaks. As long as old binaries
work (and they will), we're fine.
User-land was _already_ broken. By virtue of using a type that it should
NOT have used.
If you want to use __kernel_dev_t, go ahead.
Linus
Yes. As everyone knows, one should not use kernel includes.
On the other hand, having local copies of everything is also
a bad habit, to be avoided when possible.
With Linux it is generally impossible to avoid going to local
copies, but so far losetup survived with the construction
% cat loop.h
#include <linux/posix_types.h>
#undef dev_t
#define dev_t __kernel_dev_t
#include <linux/loop.h>
#undef dev_t
%
Yecch.
(This is terribly ugly, but the alternative may be even worse:
lots of #ifdef's testing architecture etc.)
It is a pity that dev_t, a type that is not used anywhere in the
kernel except at the interface with user space, is a different
type from what user space uses.
Andries
^ permalink raw reply
* Re: possible change to usb.agent
From: Robert Anderson @ 2002-01-15 14:43 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <marc-linux-hotplug-101097712222027@msgid-missing>
>Date: Mon, 14 Jan 2002 14:33:58 -0800
>From: David Brownell <david-b@pacbell.net>
>Cc: linux-hotplug-devel@lists.sourceforge.net
>X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
>Content-type: text/plain; charset=iso-8859-1
>X-Priority: 3
>X-MSMail-priority: Normal
>> I can see this approach works great now, but I do wonder what happens
>> when I get an rpm that installs scripts for my MP3 player, Camera, and
>> external harddrive. I thought that was the idea behind the
>> "usb.usermap" file and all the matching options.
>
>No, the original intent was to support user mode drivers ("usermap").
>With as few match options as practical -- since options create support
>problems/costs. (Options lead to confusion ... ;)
Actually once I understood what those files did I thought it was an
extreemly cleaver idea. After the first few hours debuging and
following the code paths I ended up seeing how all the matching was
being done and was able to write the line I wanted for my Fuji camera.
It would have worked great except for the fact that my camera is
already using your code to install it's usb-storage driver, so it was
ignoring my usermap lines. Which is how I ended up here to begin with.
>Could you clarify why you'd expect those different kinds of usb-storage
>device to get treated differently? I suspect I know why -- and it'll boil
>down to wanting SCSI hotplug to have access to more information
>in order to mount cameras under something like /mnt/camera/N and
>MP3 players under /mnt/mp3/N, and handle CD/DVD burners in a
>correspondingly intelligent way.
SCSI hotplugging could handle many of the issues I was thinking of. I
also see how future drivers could be created that somehow block my
usermap scripts from working.
For an example that I'll document for you within the week. Take the
Canon A20 camera. It's not recognized by any of your drivers. I know
that ghoto2 can talk with it. I can configure an A20 script using
usb.usermap to match it's two main identifiers and pull all the photos
off using gphoto2. My script would work fine until somebody writes a
real driver for that device. So after I upgrade and the new drivers
are available, my old A20 script would no longer work. I then need to
track down what the new driver is and rename my /etc/hotplug/usb/A20
script to match the new driver (I should also clean out the
usb.usermap at the same time as it would then be unused and
misleading).
I'm very happy with how your code works and the support you're giving
it! My current intent is to donate some documented example code to
get two different cameras working. I think having more exmaples would
have helped me know your code quicker than all the debuging code I
went through. I want to give back something for all the hard work
you've done and I can easily document a few examples for you to use as
you wish.
>> The way I had
>> changed it the device driver would load as well as anything matching
>> in the usb.usermap file. It allowed individual and multiple scripts
>> per device.
>
>I think the current scheme also allows that, but doesn't try to standardize
>any of it. Most of the cases I can imagine where a standard approach
>would be needed feel to me like cases where higher level hotplug tools
>(printer, scanner/sane, scsi, etc) should handle the problem. Given that,
>I'm reluctant to encourage USB-level solutions, only to replace them when
>the more capable solutions appear.
>
>- Dave
Since in my A20 example above I'm using your code for nothing more
than a hook to autorun another script, I can see how far off on a
tangent this can lead. Obviously you can't solve all these problems
at your one level, I just wanted to bring another view of this into
the light. From my point of view what I need to do can change
depending on if a driver has or hasn't been developed yet. What I may
have considered a really specific match on my hardware gets ignored by
something that could be very generic, but exists in a higher tier of
mapfile.
I'll try to document two or three examples for you. One of the
reasons I didn't use a "case $PRODUCT in" was that if I only used an
"if [ $PRODUCT = X]" syntax you could just append more products onto
the same file, even have multiple scripts fire during the coarse of a
single script.
--------------------------------------------------------------
Robert E. Anderson email: rea@sr.unh.edu
Systems Programmer phone: (603) 862-3489
UNH Research Computing Center fax: (603) 862-1761
--------------------------------------------------------------
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply
* Re: highmem=system killer, 2.2.17=performance killer ?
From: rwhron @ 2002-01-15 14:46 UTC (permalink / raw)
To: k.meyer; +Cc: linux-kernel
> i've got serious problems using 2.4.x kernels using highmem support.
> It seems to me that i'm not the only one, but the difference to most
> other ones is,
> that i can't use highmem because the system performance is terrible
> slow.
Klaus,
Have you tried 2.4.18pre2aa2 from:
ftp://ftp.de.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.18pre2aa2.bz2
With this patch applied:
http://marc.theaimsgroup.com/?l=linux-kernel&m=101110373911359&w=2
I get better performance with it, but I've only used it on
a machine with 1GB ram.
--
Randy Hron
^ permalink raw reply
* Re: Penelope builds a kernel
From: Matthias Andree @ 2002-01-15 11:53 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <20020114213641.I30639@redhat.com>
On Mon, 14 Jan 2002, Benjamin LaHaise wrote:
> On Mon, Jan 14, 2002 at 08:53:07PM -0500, Eric S. Raymond wrote:
> > I don't understand what you think you're seeing, but I am sure of
> > this; if I had been enough of a drug-addled lunatic to allow fetchmail
> > to delete mail before getting a positive acknowledge from the
> > downstream MTA, someone in the pool of over two thousand people who have sent
> > me bug reports and patches would have called me on it some time in the
> > six years of production use well before *you* entered the picture.
>
> Uhm, as someone who has run a number of mailing lists for the past 6
> years, I've seen fetchmail induced bounces numerous times, and 99% of
> the time they're because the damn thing should default to a
> --never-send-bounces-to-anyone.
It doesn't matter if people hose their qmail forwards without fetchmail
anywhere, a provider fails to provide envelope information for that dung
of pile that a multidrop POP3 mailbox is, somehow you can always screw
up mailing lists. Use VERP to figure who is bouncing on you. And now
please take this off-list.
> That's part of what you have to deal with by being a hybrid MTA/MUA:
> your error handling must be directed at the user of fetchmail, not the
> originator of the message. The originator of the message has no control
You have absolutely no clue of fetchmail. Get lost. Please. Come back
only after you got the *complete* fetchmail picture.
fetchmail does not bounce on its own for single-drop mailboxes, and as
long as 4.x.y or 5.3.x versions are still around on distributions, ESR
cannot do much about solutions you require either because users won't
get hold of the policy changes.
> the fact that fetchmail *is* an MUA -> it should not behave as if it is
> purely an MTA.
Fetchmail is by no means a MUA.
> Besides, I think you're trying to solve the wrong problem. A good many
> readers of linux-kernel don't want to start seeing posts from Aunt Tillie
> and would rather leave this ease of use issue to the distributions that
> already make it easy as pie.
Having a common solution upstream is the way to save duplicate efforts.
And now let the fetchmail part of this thread please die.
--
Matthias Andree
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." Benjamin Franklin
^ permalink raw reply
* Re: cross-cpu balancing with the new scheduler
From: Ingo Molnar @ 2002-01-15 16:37 UTC (permalink / raw)
To: Anton Blanchard; +Cc: Manfred Spraul, linux-kernel
In-Reply-To: <20020114061054.GB17549@krispykreme>
On Mon, 14 Jan 2002, Anton Blanchard wrote:
> Rusty and I were talking about this recently. Would it make sense for
> the load balancer to use a weighted queue length (sum up all
> priorities in the queue?) instead of just balancing the queue length?
something like this would work, but it's not an easy task to *truly*
balance priorities (or timeslice lengths instead) between CPUs.
Eg. in the following situation:
CPU#0 CPU#1
prio 1 prio 1
prio 1 prio 1
prio 20 prio 1
if the load-balancer only looks at the tail of the runqueue then it finds
that it cannot balance things any better - by moving the prio 20 task over
to CPU#1 it will not create a better-balanced situation. If it would look
at other runqueue entries then it could create the following,
better-balanced situation:
CPU#0 CPU#1
prio 20 prio 1
prio 1
prio 1
prio 1
prio 1
the solution would be to search the whole runqueue and migrate the task
with the shortest timeslice - but that is a pretty slow and
cache-intensive thing to do.
Ingo
^ permalink raw reply
* Re: floating point exception
From: Zwane Mwaikambo @ 2002-01-15 14:34 UTC (permalink / raw)
To: Christian Thalinger; +Cc: Linux Kernel
In-Reply-To: <1011043588.645.0.camel@sector17.home.at>
On 14 Jan 2002, Christian Thalinger wrote:
> It seems the floating point exception is only raised with a new data
> package. Is there a simple way to raise such a exception?
New data package? And does the same behaviour re-occur after the fpu
exception? ie programs start segfaulting etc. Can you try doing a "dmesg"
after the segfaults and fpu exception and see if there is anything in the
kernel ring buffer too.
Regards,
Zwane Mwaikambo
^ permalink raw reply
* Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)
From: Bruce Harada @ 2002-01-15 14:28 UTC (permalink / raw)
To: Andrew Pimlott; +Cc: esr, linux-kernel
In-Reply-To: <20020115072958.A7900@pimlott.ne.mediaone.net>
This topic is well past the point of being done to death - it's not so much
whipping a dead horse as trying to ride the gravestone, but ah well...
On Tue, 15 Jan 2002 07:29:58 -0500
Andrew Pimlott <andrew@pimlott.ne.mediaone.net> wrote:
> On Tue, Jan 15, 2002 at 08:02:18AM +0900, Bruce Harada wrote:
> > On Mon, 14 Jan 2002 17:34:23 -0500
> > "Eric S. Raymond" <esr@thyrsus.com> wrote:
> >
> > Aunt Tillie just DOESN'T CARE, OK? She can talk to her vendor if she gets
> > worried about whether her kernel supports the Flangelistic2000 SuperDoodad.
>
> Ok, Grandpa Willie only cares about support for his doodad. Why do
> you conclude that he should never build a kernel?
Because it adds extra complexity for very little gain and forces the vendor to
support 10,000 variations on a kernel that would normally only have a dozen or
so at most?
> It's just as easy in principle to write a friendly front-end that
> downloads sources and compiles them, as one that downloads binaries.
We're not talking about a front-end for kernel compilation - the topic is an
autoconfigurator that tries to decide what hardware is available, no matter
what might *need* to be available tomorrow, or next week, or next month.
> - It's easier for third-parties to provide kernel software in source
> form than in binary form (because binaries must be in the correct
> package format, and be compiled with the right config options, and
> adhere to the particular distribution's conventionts; whereas
> source is relatively neutral).
Except when it requires another source package to compile, which requires
another, and another... and God forbid that some patches conflict. Compiling
from source is a *bad* idea for someone who wants things to just work.
> Why should Willie be limited to
> getting his kernels from his vendor?
If he wants ongoing support from his vendor, he damn well better.
> What if his vendor doesn't
> support the Flangelistic2000 SuperDoodad yet, but there's a solid
> driver available from a volunteer?
"Solid" as in "will not eat his hard drive and spit it out as metal shavings
when used in combination with whatever other patches have been applied to the
kernel by the vendor"? Or "solid" as in "works for me, should work OK for you,
and if it doesn't there's always the next version, and hey, don't forget to
submit a bug report"?
> What if he hears the hype
> (sorry) about the low latency patch, and decides he wants to try
> it (maybe his MP3's skip when Netscape thrashes)?
I would say the chance of that level of user hearing about the low-latency
patches is about the same as me becoming an astronaut and flying to the Moon.
And if he does hear about them, the correct place for him to ask about them is
his vendor.
> Why take the
> choice out of Willie's hands?
Choice to do what? Break his box beyond hope of repair (by himself, at least)
and lose him any chance of support from the people he paid to do so?
> And why keep a willing tester and a
> developer apart? (If you claim that novice users don't want to
> install random beta software--that contradicts my experience with
> lots of Windows users!)
...and how many of those Windows users submitted meaningful bug reports? Or,
indeed, *any* bug reports?
> - It's a system that experts are likely to use as well, because
> there's a lot of overlap between this system and what experts
> want.
Er... from the response on the list so far, I somehow doubt that...
> A nice front-end to browse and manage kernel versions,
> patches, and drivers; to download, configure, compile and install
> them? I might use that.
Again, I believe the topic of this thread was an autoconfiguration system,
not a version management utility.
> - It makes it easier for Willie's hacker grandson to help him.
> Hackers know all about compiling kernels, but aren't as likely to
> be familiar with the distribution's binary packaging.
Really?? There aren't that many - RPM, deb, tgz. Anyone who's that familiar
with compiling kernels is rather likely to be able to handle 'man rpm'.
> The more we
> all do things the same way, the more we can help each other; when
> different groups use different tools, the community is fragmented.
Er, so you're one of those "let's all run Red Hat because it'll make things
simpler" people are you? Having a variety of tools that do similar things is
*good*.
> - It can support a graceful transition from beginner to expert.
> Suppose one day, for whatever reason, Willie really does need to
> change a compile-time option. Or, heaven forbid, he gets curious
> about what his computer is doing when the status line says
> "compiling". He's already got all the pieces he needs. Ideally,
> he just needs to click on that scary "Advanced options" button.
Who's to say that gcc is even installed on his box? Or Python? Or the userland
utilities required for him to actually make use of that compiletime option?
It's an awfully big jump from "I just want to balance my checkbook" to "let's
see, how do I activate and configure a new QoS algorithm". That's the VENDOR's
job, not Willie's or Penelope's or whoever the random user of the week may be.
If they want to do that, they are by definition no longer an average user.
> You might think these are trifles and < 1% cases. My intuition
> tells me that they add up in the long run. At least it's worth
> considering.
What is? A patch and version management utility? Sure - but it doesn't belong
in the kernel tree. An autoconfigurator? Not as it's been described so far by
Eric, and even if his idea wasn't broken it still shouldn't be in the kernel
tree.
Bruce
^ permalink raw reply
* Re: [BUG] symlink problem with knfsd and reiserfs
From: Nikita Danilov @ 2002-01-15 15:27 UTC (permalink / raw)
To: trond.myklebust
Cc: Nikita Danilov, Neil Brown, Hans-Peter Jansen, linux-kernel,
Reiserfs mail-list, David L. Parsley
In-Reply-To: <15428.12621.682479.589568@charged.uio.no>
Trond Myklebust writes:
> >>>>> " " == Nikita Danilov <Nikita@Namesys.COM> writes:
>
> > Yes, inode->i_generation is stored in the file handle:
> > fs/reiserfs/inode.c:reiserfs_dentry_to_fh().
>
> But what is stored in inode->i_generation? AFAICS
>
> inode->i_generation = le32_to_cpu (INODE_PKEY (inode)->k_dir_id);
>
> which appears not to be a unique generation count. Isn't that instead
> the directory's object id?
This is only for 3.5 reiserfs format (default for 2.2 kernels), for 3.6
format, generation is stored on the disk (in the same place where rdev
is stored for device files). 3.5 cannot work with nfs reliably.
Hans-Peter, you can check version of reiserfs you use with
/sbin/debugreiserfs /dev/device
or
cat /proc/fs/reiserfs/device/version
>
> The point of i_generation is to provide a unique number that changes
> every time you reuse the inode number.
In reiserfs there is no static inode table, so we keep global generation
counter in a super block which is incremented on each inode deletion,
this generation is stored in the new inodes. Not that good as per-inode
generation, but we cannot do better without changing disk format.
>
> Cheers,
> Trond
>
Nikita.
^ permalink raw reply
* Ramdisk doesn't work well in 2.4.17
From: Silviu Marin-Caea @ 2002-01-15 14:26 UTC (permalink / raw)
To: linux-kernel
I'm trying to make a pair of custom boot/root diskettes (for partimage).
The kernel I have compiled the kernel for bootdisk loads fine, reads the
rootdisk (gzipped image) to the end, and then, it says:
Kernel panic: no init found. Try passing init= option to kernel.
The root disk is good, because I have built a 2.4.9 in a similar
fashion, and it works with it. The problem is I need NTFS support, and
that doesn't compile in 2.4.9.
--
Silviu Marin-Caea - Network & Systems Administrator - Delta Romania
Phone +4093-267961
^ permalink raw reply
* Re: Hardwired drivers are going away?
From: David Lang @ 2002-01-15 14:25 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <200201151045.g0FAjduU002847@tigger.cs.uni-dortmund.de>
one other thing re: simplicity.
bootloaders
I know that many of you who are advocating this new approach despise lilo,
but for many people it does the job just fine. with the new approach when
switching between kernels you now not only need to switch the kernel
images, but also the initrd (or equivalent) images.
also don't forget that the current way of storing modules can have
problems when some kernel comile options change (SMP for example, but IIRC
there are others) if you make modules mandatory you will have to fix this
first.
David Lang
>
> > > > 3. simplicity in building kernels for other machines. with a monolithic
> > > > kernel you have one file to move (and a bootloader to run) with modules
> > > > you have to move quite a few more files.
>
^ permalink raw reply
* RE: mpc860 vs. mpc860T
From: Steven Vacca @ 2002-01-15 14:25 UTC (permalink / raw)
To: LinuxEmbeddedMailList (E-mail)
I did a complete search for CONFIG_8xx_CPU6, and
truncated variations, in my mpc8xx-2.2.13 kernel, and
could not find it. It doesn't show up as a cfg option either.
Even a grep on CONFIG_8xx doesn't show anything
resembling that. Could it be in there and accessible
in an alternative way?
Steven
-----Original Message-----
From: Wolfgang Denk [SMTP:wd@denx.de]
Sent: Tuesday, January 15, 2002 9:01 AM
To: svacca@valcom.com
Subject: Re: mpc860 vs. mpc860T
Dear Steven,
in message <01C19DA2.0031A1C0.svacca@valcom.com> you wrote:
>
> My 860T rev is: duht-duhduh-duuuuuhh: XPC860TZP50B3 :>(
>
> I guess that means I'll need some workarounds.
Right.
> My embedded linux kernel is Redhat's mpc8xx-2.2.13, so
> maybe porting in some workarounds might not be too painful.
> Could I please get access to your workarounds, Magnus?
Ummm... the CONFIG_8xx_CPU6 kernel configuation option (workaround
for CPU6 Silicon Errata (860 Pre Rev. C et al.)) was already
available with 2.2.13 kernels; you may check it RH bothered to
include it. If so, just enable it.
Hope that helps,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd@denx.de
Lead me not into temptation... I can find it myself.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* [patch] O(1) scheduler, 2.4.17-I0
From: Ingo Molnar @ 2002-01-15 16:20 UTC (permalink / raw)
To: linux-kernel
the 2.4.17-I0 O(1) scheduler patch is available at:
http://redhat.com/~mingo/O(1)-scheduler/sched-O1-2.4.17-I0.patch
this is a backport of the 2.5.2+I0 O(1) scheduler code.
Ingo
^ permalink raw reply
* Re: Softdog support on non-x86
From: Josh Wyatt @ 2002-01-15 14:19 UTC (permalink / raw)
To: Russell King; +Cc: 'Kernel-Mailingliste'
In-Reply-To: <20020111103423.A30436@flint.arm.linux.org.uk>
Russell King wrote:
>
> On Thu, Jan 10, 2002 at 09:49:00AM -0500, Josh Wyatt wrote:
> > I'd like to use the software watchdog timer, softdog.c, on the Sparc
> > architecture, using kernel 2.2.17. I used this to build the module:
> > cd /usr/src/linux-2.2.17/drivers/char
> > gcc -c -DMODVERSIONS -D__KERNEL__ -DMODULE -Wall -Wstrict-prototypes
> > softdog.c
>
> Why are you building it manually? It'd be better to turn it on
> using the configuration tools, and build it in the normal way?
Please CC: me as I am not on the list.
I built the module manually precisely because I did not want to rebuild
the entire kernel and module set just to get this one module.
Perhaps I do not understand the correct approach to building individual
modules, on an existing tree.
What's the documented, correct approach to only building a single
module, starting with menuconfig, such that it will happily fit in with
the currently running kernel and modules? I notice that many
drivers/modules happily include the correct gcc incantation (in comment)
for doing exactly this, and many do not.
And finally, back to my original question, is it a mute point? Is the
softdog an Intel-only thing?
Thanks,
josh
>
> --
> Russell King (rmk@arm.linux.org.uk) The developer of ARM Linux
> http://www.arm.linux.org.uk/personal/aboutme.html
^ permalink raw reply
* General Users
From: Westerman, Mark @ 2002-01-15 14:21 UTC (permalink / raw)
To: selinux; +Cc: 'sds@tislabs.com'
The current implementation of SELinux requires each user to be listed in the
user policy file
and the default_context. This is great for single purpose server and
workstation machines.
I am currently look at a project that will require hundreds of machines and
thousands of users. The user name and password are propagated thru NIS. With
the current implement of SELinux this makes the management of the machines
non-workable. Requires to much system administration. User are added and
removed on a regular basis. We cannot rebuild a policy file for each machine
for the
addition or removal of a user.
What would be the best way to modify the current implement to create a
standard
user. I was thinking of setting up a standard user for the user policy file
and
for the default context in the /etc/security (cron and default). I am
looking at modifying
the libsecure to look at the user, if the user is not found in the
default_context file
then assign him the standard user context.
Any suggestions would be great.
Mark Westerman
--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply
* Re: emu10k1_audio_open?? 2.5.2 problem
From: Nikita Gergel @ 2002-01-15 14:19 UTC (permalink / raw)
To: Frank Jacobberger; +Cc: linux-kernel
In-Reply-To: <3C443940.8070000@xmission.com>
[-- Attachment #1: Type: text/plain, Size: 1064 bytes --]
On Tue, 15 Jan 2002 07:14:24 -0700
Frank Jacobberger <f1j@xmission.com> wrote:
> gcc -D__KERNEL__ -I/usr/src/linux-2.5.2/include -Wall
> -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer
> -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2
> -march=i686 -DMODULE -DMODVERSIONS -include
> /usr/src/linux-2.5.2/include/linux/modversions.h -c -o audio.o audio.c
> audio.c: In function `emu10k1_audio_open':
> audio.c:1101: invalid operands to binary &
> make[3]: *** [audio.o] Error 1
> make[3]: Leaving directory `/usr/src/linux-2.5.2/drivers/sound/emu10k1'
> make[2]: *** [_modsubdir_emu10k1] Error 2
> make[2]: Leaving directory `/usr/src/linux-2.5.2/drivers/sound'
> make[1]: *** [_modsubdir_sound] Error 2
> make[1]: Leaving directory `/usr/src/linux-2.5.2/drivers'
> make: *** [_mod_drivers] Error 2
>
> What to do?
I've already contributed patch for 2.5 kernels to fix this. There are problems with 'MINOR' function.
Look in attach for the patch.
--
Nikita Gergel System Administrator
Moscow, Russia YAUZA-Telecom
[-- Attachment #2: emu10k1.diff --]
[-- Type: application/octet-stream, Size: 2645 bytes --]
diff -u --recursive --new-file v2.5.1/linux/drivers/sound/emu10k1/audio.c linux/drivers/sound/emu10k1/audio.c
--- v2.5.1/linux/drivers/sound/emu10k1/audio.c Tue Oct 9 21:53:00 2001
+++ linux/drivers/sound/emu10k1/audio.c Wed Jan 9 10:00:00 2002
@@ -1098,7 +1098,7 @@
static int emu10k1_audio_open(struct inode *inode, struct file *file)
{
- int minor = MINOR(inode->i_rdev);
+ int emu_minor = minor(inode->i_rdev);
struct emu10k1_card *card = NULL;
struct list_head *entry;
struct emu10k1_wavedevice *wave_dev;
@@ -1110,7 +1110,7 @@
list_for_each(entry, &emu10k1_devs) {
card = list_entry(entry, struct emu10k1_card, list);
- if (!((card->audio_dev ^ minor) & ~0xf) || !((card->audio_dev1 ^ minor) & ~0xf))
+ if (!((card->audio_dev ^ emu_minor) & ~0xf) || !((card->audio_dev1 ^ emu_minor) & ~0xf))
goto match;
}
@@ -1206,7 +1206,7 @@
woinst->buffer.fragment_size = 0;
woinst->buffer.ossfragshift = 0;
woinst->buffer.numfrags = 0;
- woinst->device = (card->audio_dev1 == minor);
+ woinst->device = (card->audio_dev1 == emu_minor);
woinst->timer.state = TIMER_STATE_UNINSTALLED;
woinst->num_voices = 1;
for (i = 0; i < WAVEOUT_MAXVOICES; i++) {
diff -u --recursive --new-file v2.5.1/linux/drivers/sound/emu10k1/midi.c linux/drivers/sound/emu10k1/midi.c
--- v2.5.1/linux/drivers/sound/emu10k1/midi.c Tue Oct 9 21:53:00 2001
+++ linux/drivers/sound/emu10k1/midi.c Wed Jan 9 10:00:00 2002
@@ -87,7 +87,7 @@
static int emu10k1_midi_open(struct inode *inode, struct file *file)
{
- int minor = MINOR(inode->i_rdev);
+ int emu_minor = minor(inode->i_rdev);
struct emu10k1_card *card = NULL;
struct emu10k1_mididevice *midi_dev;
struct list_head *entry;
@@ -98,7 +98,7 @@
list_for_each(entry, &emu10k1_devs) {
card = list_entry(entry, struct emu10k1_card, list);
- if (card->midi_dev == minor)
+ if (card->midi_dev == emu_minor)
goto match;
}
diff -u --recursive --new-file v2.5.1/linux/drivers/sound/emu10k1/mixer.c linux/drivers/sound/emu10k1/mixer.c
--- v2.5.1/linux/drivers/sound/emu10k1/mixer.c Tue Oct 9 21:53:00 2001
+++ linux/drivers/sound/emu10k1/mixer.c Wed Jan 9 10:00:00 2002
@@ -640,7 +640,7 @@
static int emu10k1_mixer_open(struct inode *inode, struct file *file)
{
- int minor = MINOR(inode->i_rdev);
+ int emu_minor = minor(inode->i_rdev);
struct emu10k1_card *card = NULL;
struct list_head *entry;
@@ -649,7 +649,7 @@
list_for_each(entry, &emu10k1_devs) {
card = list_entry(entry, struct emu10k1_card, list);
- if (card->ac97.dev_mixer == minor)
+ if (card->ac97.dev_mixer == emu_minor)
goto match;
}
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.