Re: [PATCH] (part 3) fs/super.c cleanups
OK, chunk #3: beginnings of garbage collection for vfsmounts
and cleanup of do_umount() path.
* kill_super() had always been conditional on the
list_empty(>s_mounts). Check had been pulled inside kill_super(),
if we still have other mounts of that superblock kill_super() simply
returns. All callers of kill_super() call it unconditionally now.
* remove_vfsmnt() was an interesting (and obnoxious) beast.
It used to do the following: we called it with dcache_lock held and
passed it the last reference to struct vfsmount *. It detached the
thing from the tree, dropped dcache_lock, freed vfsmount and returned,
leaving us to call kill_super() (if that was the last vfsmount over
that superblock, that is). Ugly and I'm the one to blame here - I
plead the bad taste attack. It's gone now. First of all, detaching
from the tree is done by callers of remove_vfsmnt() now. The rest +
call of kill_super() became __mntput(mnt) - it frees the thing and
kills superblock if needed.
Notice that last reference to vfsmount was _always_ dropped that way.
mntput() called BUG(); if the reference dropped to 0. The next step is
obvious - now we call __mntput() instead.
* rules for mntput() had been changed: instead of old "thou shalt
not give the last reference up with mntput()" it's "the last reference
should be killed by mntput() from fs/super.c (old remove_vfsmount() callers)."
That restriction will be lifted as soon as we get sane locking
(->s_umount instead of the mount_sem crap) on read_super() and friends.
For the time being we simply extend the definition of mntput() - all old
callers never hit the last reference, new ones always do.
* do_umount() leaves the final call of mntput() to its callers
(each exit path used to end either on remove_vfsmnt() or on mntput()).
As the result we got rid of
dput(nd.dentry);
/* It drops nd.mnt */
do_umount(nd.mnt, 0);
stuff - now it's nice and sane
do_umount(nd.mnt, 0);
path_release();
So there... BTW, kern_umount() turned into mntput()
Linus, if you feel that this one would be better off split into several
steps - please, tell, if it's clean enough - please apply ;-)
Al
PS: I'm holding the next chunk in case if you have objections to ones
that had been sent so far or want to split the last one. If you are
OK with these - the next step is saner exclusion (based on ->s_umount).
That will remove all limitations from mntput() and close a bunch of existing
races.
diff -urN S5-pre5-mnt_detach/fs/super.c S5-pre5-GC/fs/super.c
--- S5-pre5-mnt_detach/fs/super.c Wed May 23 00:19:59 2001
+++ S5-pre5-GC/fs/super.c Wed May 23 01:21:30 2001
@@ -407,24 +407,20 @@
path_release(_nd);
}
-/*
- * Called with spinlock held, releases it.
- */
-static void remove_vfsmnt(struct vfsmount *mnt)
+static void kill_super(struct super_block *);
+
+void __mntput(struct vfsmount *mnt)
{
- struct nameidata parent_nd;
- /* First of all, remove it from all lists */
- detach_mnt(mnt, _nd);
+ struct super_block *sb = mnt->mnt_sb;
+
+ dput(mnt->mnt_root);
+ spin_lock(_lock);
list_del(>mnt_instances);
- list_del(>mnt_list);
spin_unlock(_lock);
- /* Now we can work safely */
- dput(mnt->mnt_root);
- if (parent_nd.mnt != mnt)
- path_release(_nd);
if (mnt->mnt_devname)
kfree(mnt->mnt_devname);
kfree(mnt);
+ kill_super(sb);
}
@@ -872,6 +868,12 @@
struct file_system_type *fs = sb->s_type;
struct super_operations *sop = sb->s_op;
+ spin_lock(_lock);
+ if (!list_empty(>s_mounts)) {
+ spin_unlock(_lock);
+ return;
+ }
+ spin_unlock(_lock);
down_write(>s_umount);
sb->s_root = NULL;
/* Need to clean after the sucker */
@@ -964,16 +966,6 @@
return mnt;
}
-/* Call only after unregister_filesystem() - it's a final cleanup */
-
-void kern_umount(struct vfsmount *mnt)
-{
- struct super_block *sb = mnt->mnt_sb;
- spin_lock(_lock);
- remove_vfsmnt(mnt);
- kill_super(sb);
-}
-
/*
* Doesn't take quota and stuff into account. IOW, in some cases it will
* give false negatives. The main reason why it's here is that we need
@@ -989,6 +981,7 @@
static int do_umount(struct vfsmount *mnt, int flags)
{
struct super_block * sb = mnt->mnt_sb;
+ struct nameidata parent_nd;
/*
* No sense to grab the lock for this test, but test itself looks
@@ -1005,7 +998,6 @@
* Special case for "unmounting" root ...
* we just try to remount it readonly.
*/
- mntput(mnt);
return do_remount("/", MS_RDONLY, NULL);
}
@@ -1014,14 +1006,16 @@
if (mnt->mnt_instances.next !=
[PATCH] net/wanrouter/wanproc.c
Hi All,
I am working with Dawson Engler's meta-compillation group @ Stanford.
In net/wanrouter/wanproc.c the authors check for a bad copy_to_user and
immediately return -EFAULT. However, it is necessary to rollback some
allocated memory. This can leak memory over time, thus leading to
system instability and lack of resources.
Thanks!
-Akash Jain
--- net/wanrouter/wanproc.c.origThu Apr 12 12:11:39 2001
+++ net/wanrouter/wanproc.c Thu May 17 12:52:05 2001
@@ -267,8 +267,10 @@
offs = file->f_pos;
if (offs < pos) {
len = min(pos - offs, count);
- if(copy_to_user(buf, (page + offs), len))
- return -EFAULT;
+ if(copy_to_user(buf, (page + offs), len)){
+ kfree(page);
+ return -EFAULT;
+ }
file->f_pos += len;
}
else
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: ioctl/setsockopt etc. vs read/write - idea
Hi everybody, I'd like to offer my $0.02 to the ongoing discussion. IIRC we already have some OOB-data channels - ioctl, setsockopt, fcntl ... to name only a few. But: we already have a side-band: send with MSG_OOB! And, as I just saw in the sources, there are some flags free. So how about defining more than 1 OOB-channel and using them instead of ioctl and so on? There could be some bits reserved for the channel - 0 for normal, 1 for alternate date (MSG_OOB), and eg. -1 for SOL_RAW, -2 for SOL_TCP, -3 for SOL_IP, ... and so on. For files there would be 1 layer giving locking functionality. So, a syscall is already there - we could use this. For compatibility this change could be undone in libc. Please don't flame if I didn't see something obvious - everything else is welcome. Regards, Phil - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Kernel memory mapped into user process
Hi , I have a proposition at hand to optimize getting system time by avoiding the system call(gettimeofday()) overhead. This can be implemented by keeping a read-only page of kernel memory mapped into user processes for reading quickly. A kernel process can keep that page up-to-date. I did some browsing of this mailing list archives to get the following related topics: * mapping user space buffer to kernel address space * Direct I/O * Zero Copy IO None of these seem to specifically address my problem. So can the experienced please throw some light on the issues involved in having a read-only page of kernel memory mapped into user process. Any help/suggestions will be much appreciated. Please CC your comments to "[EMAIL PROTECTED]" Thanks and Regards, Shashi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]device arguments from lookup)
On Wed, 23 May 2001, Edgar Toernig wrote: > And with special "ctrl" devices (ie /dev/ttyS0 and /dev/ttyS0ctrl): > This _may_ work for some kind of devices. But serial ports are one > example where it simply will _not_. It requires that you know the That's quite funny, you know... From: Dennis Ritchie ([EMAIL PROTECTED]) Subject: Re: Plan 9 (was Re: Rubouts) Newsgroups: alt.folklore.computers Date: 1998/10/12 Neil Franklin wrote: > > No ioctl()s? > > Something like:echo "38400,8,n,1" > /ioctrl/ttyS0? > > Now that would be cool. > Exactly like that, though it would be /dev/eia80ctl . No ioctl(). > Is there anyone who has an URL about Plan 9. Code download? > http://plan9.bell-labs.com/plan9 Dennis - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]device arguments from lookup)
Daniel Phillips wrote: > > On Tuesday 22 May 2001 17:24, Oliver Xymoron wrote: > > On Mon, 21 May 2001, Daniel Phillips wrote: > > > On Monday 21 May 2001 19:16, Oliver Xymoron wrote: > > > > What I'd like to see: > > > > > > > > - An interface for registering an array of related devices > > > > (almost always two: raw and ctl) and their legacy device numbers > > > > with a single userspace callout that does whatever /dev/ creation > > > > needs to be done. Thus, naming and permissions live in user > > > > space. No "device node is also a directory" weirdness... > > > > > > Could you be specific about what is weird about it? > > > > *boggle* > > > >[general sense of unease] I fully agree with Oliver. It's an abomination. > > I don't think it's likely to be even workable. Just consider the > > directory entry for a moment - is it going to be marked d or [cb]? > > It's going to be marked 'd', it's a directory, not a file. Aha. So you lose the S_ISCHR/BLK attribute. > > If it doesn't have the directory bit set, Midnight commander won't > > let me look at it, and I wouldn't blame cd or ls for complaining. If it > > does have the 'd' bit set, I wouldn't blame cp, tar, find, or a > > million other programs if they did the wrong thing. They've had 30 > > years to expect that files aren't directories. They're going to act > > weird. > > No problem, it's a directory. Directories are not allowed to be read from/written to. The VFS may support it, but it's not (current) UNIX. > > Linus has been kicking this idea around for a couple years now and > > it's still a cute solution looking for a problem. It just doesn't > > belong in UNIX. > > Hmm, ok, do we still have any *technical* reasons? So with your definition, I have a fs-object that is marked as a directory but opening it opens a device. Pretty nice. How I'm supposed to list it's contents? open+readdir? But the open has nasty side effects. So you have a directory that you are not allowed to list (because of the possible side effects) but is allowed to be read from/written to maybe even issue ioctls to?. And you call that sane??? IMO the whole idea of arguments following the device name is junk (incl a "/ctrl"). Just think about the implications of the original "/dev/ttyS0/19200" suggestion. It sounds nice and tempting. But which programs will benefit. Which gets confused. What will be cleaned up. After some thoughts you'll find out that it's useless ;-) And with special "ctrl" devices (ie /dev/ttyS0 and /dev/ttyS0ctrl): This _may_ work for some kind of devices. But serial ports are one example where it simply will _not_. It requires that you know the name of the device. For ttys this is often not the case. Even if you manage to get some name for stdin for example - now I should simply attach a "ctrl" to that name to get a control channel??? At least dangerous. If I'm lucky I only get an EPERM... Ciao, ET. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] (part 2) fs/super.c cleanups
On Wed, 23 May 2001, Andrew Morton wrote: > Alexander Viro wrote: > > > > Locking rules: both require mount_sem and dcache_lock being > > held by callers. > > > > It would help a lot if locking rules were commented in > the source, rather than on linux-kernel. They will change in the next chunks. In particular, we'll need rwlock for these two instead of mount_sem. Current locking rules for fs/super.c are mess. It used to be completely under BKL and nobody cared much about races there, so lots of things are sloppy. As usual - there is no such thing as SMP-only race... New variant makes much more sense, but I'm feeding it in small chunks and one of the obvious requirements is that at every stage situation should be better or same as on the previous step. It's -STABLE, damnit. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] (part 2) fs/super.c cleanups
Alexander Viro wrote: > > Locking rules: both require mount_sem and dcache_lock being > held by callers. > It would help a lot if locking rules were commented in the source, rather than on linux-kernel. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] (part 2) fs/super.c cleanups
OK, here's chunk #2.
* two helper functions added: attach_mnt() and detach_mnt().
attach_mnt() adds leaf to mount tree, detach_mnt() - removes.
Locking rules: both require mount_sem and dcache_lock being
held by callers.
The rest of stuff doing manipulations of mount tree converted
to using these two.
* move_vfsmnt() takes nameidata of the new attachment point
now.
* pivot_root() taught how to work in chroot environment (not
a security issue, since it requires root anyway, but why not handle
it correctly if it comes for free?)
It used to tear the chroot subtree away. Now it reattaches
new root to the place where old used to be (if any).
If process root is not on a mountpoint (or global root) -
-EINVAL.
That way it works as expected in chroot environment. Price:
extra if and call of attach_mnt(). Variant in the current tree screws
up in these conditions.
Patch (incremental to the previous) follow. Please, apply.
Al
PS: the next chunk is (finally) GC for struct vfsmount.
diff -urN S5-pre5-mountpoint/fs/super.c S5-pre5-mnt_detach/fs/super.c
--- S5-pre5-mountpoint/fs/super.c Tue May 22 23:27:25 2001
+++ S5-pre5-mnt_detach/fs/super.c Tue May 22 23:55:59 2001
@@ -282,6 +282,24 @@
static LIST_HEAD(vfsmntlist);
+static void detach_mnt(struct vfsmount *mnt, struct nameidata *old_nd)
+{
+ old_nd->dentry = mnt->mnt_mountpoint;
+ old_nd->mnt = mnt->mnt_parent;
+ mnt->mnt_parent = mnt;
+ mnt->mnt_mountpoint = mnt->mnt_root;
+ list_del_init(>mnt_child);
+ list_del_init(>mnt_clash);
+}
+
+static void attach_mnt(struct vfsmount *mnt, struct nameidata *nd)
+{
+ mnt->mnt_parent = mntget(nd->mnt);
+ mnt->mnt_mountpoint = dget(nd->dentry);
+ list_add(>mnt_clash, >dentry->d_vfsmnt);
+ list_add(>mnt_child, >mnt->mnt_mounts);
+}
+
/**
* add_vfsmnt - add a new mount node
* @nd: location of mountpoint or %NULL if we want a root node
@@ -337,13 +355,12 @@
if (nd && !IS_ROOT(nd->dentry) && d_unhashed(nd->dentry))
goto fail;
mnt->mnt_root = dget(root);
- mnt->mnt_mountpoint = nd ? dget(nd->dentry) : root;
- mnt->mnt_parent = nd ? mntget(nd->mnt) : mnt;
if (nd) {
- list_add(>mnt_child, >mnt->mnt_mounts);
- list_add(>mnt_clash, >dentry->d_vfsmnt);
+ attach_mnt(mnt, nd);
} else {
+ mnt->mnt_mountpoint = mnt->mnt_root;
+ mnt->mnt_parent = mnt;
INIT_LIST_HEAD(>mnt_child);
INIT_LIST_HEAD(>mnt_clash);
}
@@ -362,12 +379,10 @@
}
static void move_vfsmnt(struct vfsmount *mnt,
- struct dentry *mountpoint,
- struct vfsmount *parent,
+ struct nameidata *nd,
const char *dev_name)
{
- struct dentry *old_mountpoint;
- struct vfsmount *old_parent;
+ struct nameidata parent_nd;
char *new_devname = NULL;
if (dev_name) {
@@ -377,35 +392,19 @@
}
spin_lock(_lock);
- old_mountpoint = mnt->mnt_mountpoint;
- old_parent = mnt->mnt_parent;
+ detach_mnt(mnt, _nd);
+ attach_mnt(mnt, nd);
- /* flip names */
if (new_devname) {
if (mnt->mnt_devname)
kfree(mnt->mnt_devname);
mnt->mnt_devname = new_devname;
}
-
- /* flip the linkage */
- mnt->mnt_mountpoint = parent ? dget(mountpoint) : mnt->mnt_root;
- mnt->mnt_parent = parent ? mntget(parent) : mnt;
- list_del(>mnt_clash);
- list_del(>mnt_child);
- if (parent) {
- list_add(>mnt_child, >mnt_mounts);
- list_add(>mnt_clash, >d_vfsmnt);
- } else {
- INIT_LIST_HEAD(>mnt_child);
- INIT_LIST_HEAD(>mnt_clash);
- }
spin_unlock(_lock);
/* put the old stuff */
- if (old_parent != mnt) {
- dput(old_mountpoint);
- mntput(old_parent);
- }
+ if (parent_nd.mnt != mnt)
+ path_release(_nd);
}
/*
@@ -413,18 +412,16 @@
*/
static void remove_vfsmnt(struct vfsmount *mnt)
{
+ struct nameidata parent_nd;
/* First of all, remove it from all lists */
+ detach_mnt(mnt, _nd);
list_del(>mnt_instances);
- list_del(>mnt_clash);
list_del(>mnt_list);
- list_del(>mnt_child);
spin_unlock(_lock);
/* Now we can work safely */
- if (mnt->mnt_parent != mnt) {
- dput(mnt->mnt_mountpoint);
- mntput(mnt->mnt_parent);
- }
dput(mnt->mnt_root);
+ if (parent_nd.mnt != mnt)
+ path_release(_nd);
if (mnt->mnt_devname)
kfree(mnt->mnt_devname);
kfree(mnt);
@@
noapic doesn't quite work as advertised
Hi, I've got a tyan s2520 motherboard (dual PIII + i840) which is having a problem with APIC errors. I tried running with noapic, but there were still errors, although fewer. Does anyone have any idea what is going on? I'm running 2.4.4 and software raid5, which generates a lot of interrupts. Here are some of the APIC errors (with noapic): May 21 12:38:31 rad kernel: APIC error on CPU0: 02(01) May 21 12:42:31 rad kernel: APIC error on CPU0: 01(01) May 21 12:42:31 rad kernel: APIC error on CPU1: 02(02) May 21 12:43:13 rad kernel: APIC error on CPU0: 01(02) May 21 12:43:13 rad kernel: APIC error on CPU1: 02(01) May 21 13:48:19 rad kernel: SCSI disk error : host 3 channel 0 id 0 lun 0 return code = 802 May 21 13:48:19 rad kernel: [valid=0] Info fld=0x0, Current sd08:d2: sense key Aborted Command May 21 13:48:19 rad kernel: Additional sense indicates Scsi parity error May 21 13:48:19 rad kernel: I/O error: dev 08:d2, sector 56590336 May 21 13:48:19 rad kernel: interrupting MD-thread pid 1223 May 21 13:48:19 rad kernel: raid5: parity resync was not fully finished, restarting next time. Here is /proc/interrupts to prove I'm really running with noapic: CPU0 CPU1 0: 17760464 0 XT-PIC timer 1: 29525 0 XT-PIC keyboard 2: 0 0 XT-PIC cascade 3: 27416165 0 XT-PIC eth1 11: 188276091 0 XT-PIC aic7xxx, aic7xxx, aic7xxx, aic7xxx 12: 413496 0 XT-PIC PS/2 Mouse 14:1137884 0 XT-PIC ide0 15:1740847 0 XT-PIC ide1 NMI: 0 0 LOC: 17760053 17759969 ERR: 31 Right now I'm running with noapic and nosmp and so far this seems to be working. I really would like to be able to use the second cpu so any suggestion would be greatly appreciated. Andy [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] (part 1) fs/super.c cleanups
Linus, since we have sane kill_super() now, the long-promised
cleanups are coming ;-) I'm going to feed them in small incremental
chunks, so if you see something unacceptable - yell. It may turn out
to be a result of bad choice of chunk boundaries, so...
OK, here comes the chunk #1:
* we have different rules for ->mnt_parent and ->mnt_mountpoint
in case of root filesystem(s). I.e. in case if vfsmount is not mounted
on anything (root and kern_mount() stuff). In that case we have
mnt->mnt_parent == mnt
mnt->mnt_mountpoint == mnt->mnt_root.
We shouldn't hold ->d_count of ->mnt_mountpoint. It's inconsistent with
the way we treat ->mnt_parent, it's not needed (->mnt_root is pinned
down just fine), it complicates the logics and it's conceptually wrong -
sure, going upwards from root leaves us where we were (thus the rules
above), but we don't have anything actually mounted on the root.
Change: now ->mnt_mountpoint holds a reference to dentry only
if mnt is actually mounted on something. It will allow to simplify a
lot of stuff, since we get the same rules as we have for ->mnt_parent.
* pivot_root(2) was slightly broken. It is OK to have new_root
not at the root of filesystem. However, it should be a mountpoint. Which
is actually not a restriction - mount --bind foo foo will make foo a
mountpoint just fine.
Change: add the missing check, remove the broken attempts to handle
that case.
Patch follows. Please, apply.
Al
PS: next chunk simplifies the move_vfsmnt() and friends - both API and
internals.
diff -urN S5-pre5/fs/super.c S5-pre5-mountpoint/fs/super.c
--- S5-pre5/fs/super.c Tue May 22 16:44:21 2001
+++ S5-pre5-mountpoint/fs/super.c Tue May 22 22:54:54 2001
@@ -337,7 +337,7 @@
if (nd && !IS_ROOT(nd->dentry) && d_unhashed(nd->dentry))
goto fail;
mnt->mnt_root = dget(root);
- mnt->mnt_mountpoint = nd ? dget(nd->dentry) : dget(root);
+ mnt->mnt_mountpoint = nd ? dget(nd->dentry) : root;
mnt->mnt_parent = nd ? mntget(nd->mnt) : mnt;
if (nd) {
@@ -388,7 +388,7 @@
}
/* flip the linkage */
- mnt->mnt_mountpoint = dget(mountpoint);
+ mnt->mnt_mountpoint = parent ? dget(mountpoint) : mnt->mnt_root;
mnt->mnt_parent = parent ? mntget(parent) : mnt;
list_del(>mnt_clash);
list_del(>mnt_child);
@@ -402,9 +402,10 @@
spin_unlock(_lock);
/* put the old stuff */
- dput(old_mountpoint);
- if (old_parent != mnt)
+ if (old_parent != mnt) {
+ dput(old_mountpoint);
mntput(old_parent);
+ }
}
/*
@@ -419,10 +420,10 @@
list_del(>mnt_child);
spin_unlock(_lock);
/* Now we can work safely */
- if (mnt->mnt_parent != mnt)
+ if (mnt->mnt_parent != mnt) {
+ dput(mnt->mnt_mountpoint);
mntput(mnt->mnt_parent);
-
- dput(mnt->mnt_mountpoint);
+ }
dput(mnt->mnt_root);
if (mnt->mnt_devname)
kfree(mnt->mnt_devname);
@@ -1612,8 +1613,9 @@
* - we don't move root/cwd if they are not at the root (reason: if something
*cared enough to change them, it's probably wrong to force them elsewhere)
* - it's okay to pick a root that isn't the root of a file system, e.g.
- */nfs/my_root where /nfs is the mount point. Better avoid creating
- *unreachable mount points this way, though.
+ */nfs/my_root where /nfs is the mount point. It must be a mountpoint,
+ *though, so you may need to say mount --bind /nfs/my_root /nfs/my_root
+ *first.
*/
asmlinkage long sys_pivot_root(const char *new_root, const char *put_old)
@@ -1669,6 +1671,8 @@
if (new_nd.mnt == root_mnt || old_nd.mnt == root_mnt)
goto out2; /* loop */
error = -EINVAL;
+ if (new_nd.mnt->mnt_root != new_nd.dentry)
+ goto out2; /* not a mountpoint */
tmp = old_nd.mnt; /* make sure we can reach put_old from new_root */
spin_lock(_lock);
if (tmp != new_nd.mnt) {
@@ -1685,7 +1689,7 @@
goto out3;
spin_unlock(_lock);
- move_vfsmnt(new_nd.mnt, new_nd.dentry, NULL, NULL);
+ move_vfsmnt(new_nd.mnt, NULL, NULL, NULL);
move_vfsmnt(root_mnt, old_nd.dentry, old_nd.mnt, NULL);
chroot_fs_refs(root,root_mnt,new_nd.dentry,new_nd.mnt);
error = 0;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] struct char_device
Jeff Garzik wrote:
> /dev/sda <-> partition_blkdev <-> /dev/disk{0,1,2,3,4}
> /dev/hda <-> partition_blkdev <-> /dev/disk{5,6,7}
I also point out that handling disk partitions as a -tiny- remapping
blkdev also has the advantage of making it easy to have a single request
device per hardware device (a simple remap shouldn't require its own
request queue, right?), while remapping devices flexibility to do their
own request queue management.
> I do grant you that an offset at bh submit time is faster, but IMHO
> partitions -not- as a remapping blkdev are an ugly special case.
think of the simplifications possible, when partitions are just another
block device, just like anything else... No special partitions arrays
in the lowlevel blkdev, etc.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Oops on booting 2.4.4
> May 23 02:46:24 localhost kernel: Process kudzu (pid: 219, > stackpage=c7845000) > May 23 02:46:24 localhost kernel: Stack: c12607e0 0400 0400 > c73aa000 c122a060 c122a05c c122a058 c88fbb20 > May 23 02:46:24 localhost kernel:03f1 03f1 c014ab80 > c73aa3f1 c7845f9c 0400 ffea > May 23 02:46:24 localhost kernel:c7f43f60 0400 b4b8 > c7f2e220 c12607e0 c73aa000 > May 23 02:46:24 localhost kernel: Call Trace: [] > [proc_file_read+184/464] [sys_read+142/196] [system_call+51/56] > May 23 02:46:24 localhost kernel: Call Trace: [] [] > [] [] A module deregistered incorrectly, or has a race between post-load activities and unload. One way or another it left a dangling proc entry. The oops does not provide off-stack information, so it's impossible to tell what particular modules is the culprit. > May 23 02:46:24 localhost kernel: hub.c: USB new device connect on > bus1/2, assigned device number 2 > May 23 02:46:24 localhost kernel: usb.c: USB device 2 (vend/prod > 0x4a9/0x2204) is not claimed by any active driver. What is this thing you have on USB? Try to run without it. -- Pete - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] struct char_device
Linus Torvalds wrote:
>
> On Tue, 22 May 2001, Jeff Garzik wrote:
> >
> > Alan recently straightened me out with "EVMS/LVM is partitions done
> > right"
> >
> > so... why not implement partitions as simply doing block remaps to the
> > lower level device? That's what EVMS/LVM/md are doing already.
>
> Because we still need the partitioning code for backwards
> compatibility. There's no way I'm going to use initrd to do partition
> setup with lvmtools etc.
>
> Also, lvm and friends are _heavyweight_. The partitioning stuff should be
> _one_ add (and perhaps a range check) at bh submit time. None of this
> remapping crap. We don't need no steenking overhead for something we need
> to do anyway.
no no no. Not -that- heavyweight.
Partition support becomes a -peer- of LVM.
Imagine a tiny blkdev driver that understood MS-DOS (and other) hardware
partitions, and exported N block devices, representing the underlying
device (whatever it is). In fact, that might be even a -unifying-
factor: this tiny blkdev module -is- your /dev/disk. For example,
/dev/sda <-> partition_blkdev <-> /dev/disk{0,1,2,3,4}
/dev/hda <-> partition_blkdev <-> /dev/disk{5,6,7}
A nice side effect: modular partition support, since its a normal
blkdev just like anything yes.
YES there is overhead, but if partitions are just another remapping
blkdev, you get all this stuff for free.
I do grant you that an offset at bh submit time is faster, but IMHO
partitions -not- as a remapping blkdev are an ugly special case.
Remapping to an unchanging offset in the make_request_fn can be fast,
too...
--
Jeff Garzik | "Are you the police?"
Building 1024| "No, ma'am. We're musicians."
MandrakeSoft |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] struct char_device
On Wed, 23 May 2001 [EMAIL PROTECTED] wrote: > > > why not implement partitions as simply doing block remaps > > Everybody agrees. No they don't. Look at the cost of lvm. Function calls, buffer head remapping, the works. You _need_ that for a generic LVM layer, but you sure as hell don't need it for simple partitioning. Can LVM do it? Sure. Do we need LVM to do it? No. Does LVM simplify anything? No. It doesn't get much simpler than a single line that does the equivalent of "bh->sector += offset". Most of the bulk of the code in the partitioning stuff is for actually parsing the partitions, and we need that to bootstrap. Maybe we can get rid of some of the more esoteric ones (ie pretty much everything except for the native partitioning code for each architecture) and tell people to use LVM for the rest. In short, there are _no_ advantages to involve LVM here. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Weird bug in kernel (invalid operand?)
On Tue, 22 May 2001 22:52:47 +1000, Andrew Morton <[EMAIL PROTECTED]> wrote: > Carlos Laviola wrote: > > > > invalid operand: [ ... oops here ... ] > > Segmentation fault > > > > This seems to be a bug in the kernel, maybe because the file is too big, > > and VFAT partitions don't like that. > > It used to be that fatfs would hit the second BUG() in fat_get_block() > when a file reaches two gig. But I can't make that happen in testing, > because the s_maxbytes stuff restricts it to 2gig-1. What you *should* > have seen was `wget' locking up because of a different bug :) > > Are you sure you got this with 2.4.4? If so, please run the > output through > > ksymoops -m System.map < oops-text Well, in fact, I was using 2.4.5-pre1 when I had this problem. However, since it doesn't seem like anything within the VFAT subsystem has changed from 2.4.4 to 2.4.5-pre1, 2.4.4 is probably buggy too. The relevant output from ksymoops is below. >>EIP; c48fb709 <[fat]fat_get_block+5d/dc> <= Code; c48fb709 <[fat]fat_get_block+5d/dc> <_EIP>: Code; c48fb709 <[fat]fat_get_block+5d/dc> <= 0: 0f 0b ud2a <= Code; c48fb70b <[fat]fat_get_block+5f/dc> 2: 83 c4 0c add$0xc,%esp Code; c48fb70e <[fat]fat_get_block+62/dc> 5: b8 fb ff ff ffmov$0xfffb,%eax Code; c48fb713 <[fat]fat_get_block+67/dc> a: eb 6d jmp79 <_EIP+0x79> c48fb782 <[fat]fat_get_block+d6/dc> Code; c48fb715 <[fat]fat_get_block+69/dc> c: 8b 87 8c 00 00 00 mov0x8c(%edi),%eax Code; c48fb71b <[fat]fat_get_block+6f/dc> 12: 0f b7 00 movzwl (%eax),%eax Thanks, Carlos. -- _ _ _| _ _ | _ . _ | _ carlos.debian.net Debian-BR Project (_(_|| |(_)_) |(_|\/|(_)|(_| uin#: 981913 (icq) debian-br.sf.net Linux: the choice of a GNU generation - Registered Linux User #103594 Shah, shah! Ayatollah you so! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] struct char_device
On Tue, 22 May 2001, Jeff Garzik wrote: > > Alan recently straightened me out with "EVMS/LVM is partitions done > right" > > so... why not implement partitions as simply doing block remaps to the > lower level device? That's what EVMS/LVM/md are doing already. Because we still need the partitioning code for backwards compatibility. There's no way I'm going to use initrd to do partition setup with lvmtools etc. Also, lvm and friends are _heavyweight_. The partitioning stuff should be _one_ add (and perhaps a range check) at bh submit time. None of this remapping crap. We don't need no steenking overhead for something we need to do anyway. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] struct char_device
On Tue, 22 May 2001, Jeff Garzik wrote: > > IMHO it would be nice to (for 2.4) create wrappers for accessing the > block arrays, so that we can more easily dispose of the arrays when 2.5 > rolls around... No. We do not create wrappers "so that we can easily change the implementation when xxx happens". That way lies bad implementations. We do the _good_ implementation first, and then we create the "kcompat-2.4" file later that makes people able to use the good implementation. Why this way? Because wrapping for wrappings sake just makes code unreadable (see acpi), and often makes it less obvious what you actually _have_ to do, and what you don't. So get the design right _first_, and once the design is right, _then_ you worry about kcompat-2.4. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] struct char_device
On Tue, 22 May 2001, Alexander Viro wrote: > >which populate the "inode->dev" union pointer, which in turn is _only_ > >a cache of the lookup. Right now we do this purely based on "dev_t", > >and I think that is bogus. We should never pass a "dev_t" around > >without an inode, I think. > > I doubt it. First of all, then we'd better make i_rdev dev_t. Right now > we have it kdev_t and it makes absolutely no sense that way. Absolutely. In fact, the whole "kdev_t" makes no sense if we have proper char_dev and block_dev pointers. We have "dev_t" which is what we export to user space. And if we split up char dev and block dev (which I'm an avid proponent for), kdev_t will be an anachronism. > The real thing is inode->dev. Notice that for devfs (and per-device > filesystems) we can set it upon inode creation, since they _know_ it > from the very beginning and there is absolutely no reason to do any > hash lookups. Moreover, in these cases we may have no meaningful device > number at all. Sure. If something like devfs _knows_ the device pointers from the very beginning, then just do: - increment reference count - inode->dev.char = cdev; > >Block devices will have the "request queue" pointer, and the size and > >partitioning information. Character devices currently would not have > > Do we really want a separate queue for each partition? No. But the pointer is not a 1:1 thing (otherwise we'd just put the whole request queue _into_ the block device). The block device should have a pointer to the request queue, along with the partitioning information. Why? Because that way it becomes very simple indeed to do request processing: none of the current "look up the proper queue for each request and do the partition offset magic inside each driver". Instead, the queuing function becomes: bh->index = bdev->index; bh->sector += bdev->sector_offset; submit_bh(bh, bdev->request_queue); and you're done. Those three lines did both the queue lookup, the "index" for the driver, and the partitioning offset. Whoa, nelly. And THAT is why you want to have the queue pointer in the bdev structure. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.4-ac14
Is drivers/char/ser_a2232fw.ax supposed to be included? Nothing uses it. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Background to the argument about CML2 design philosophy
On Tue, 22 May 2001 11:24:54 +0200,
Daniel Phillips <[EMAIL PROTECTED]> wrote:
>On Tuesday 22 May 2001 02:59, Keith Owens wrote:
>> # Not a real dependency, this checks for hand editing of .config.
>> $(KBUILD_OBJTREE)include/linux/autoconf.h: $(KBUILD_OBJTREE).config
>> @echo Your .config is newer than include/linux/autoconf.h,
>> this should not happen. @echo Always run make one of
>> "{menu,old,x}config" after manually updating .config. @/bin/false
>
>Ahem. What is wrong with revalidating it automatically? *Then* if there's a
>problem, bother the user.
Revalidate using which tool? Did the user even mean to edit .config?
This is a case where the user has to decide what to do.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch] Output of L1,L2 and L3 cache sizes to /proc/cpuinfo
On Wed, 23 May 2001, Martin Knoblauch wrote: > They may not be stupid, just mislead :-( When Intel created the "cpuid" > Feature some way along the P3 line, they gave a stupid reason for it and > created a big public uproar. As silly as I think that was (on both > sides), the term "cpuid" is tainted. Some people just fear it like hell. > Anyway. I think you are confusing the CPU serial number with CPUID which is not the same. CPUID instruction has been around since late 486en. The P3 Serial number is still disabled by default in Linux, unless overridden with a boottime switch. regards, Davej. -- | Dave Jones.http://www.suse.de/~davej | SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] drivers/media/video/zr36120.c (repost)
Greetings,
I wanted to repost this zr36120 patch, both because so far it has gone
unnoticed, and because there was a problem with the text formatting which
is now fixed.
There is a bug in zr36120.c of not freeing memory on error paths. This one
is particularly dangerous, because kmalloc allocates a memory block the
size of an entire video clip! I simply free the local pointer, vcp, before
returning -EFAULT.
Philip
--- drivers/media/video/zr36120.c.orig Tue May 22 18:08:22 2001
+++ drivers/media/video/zr36120.c Tue May 22 18:08:49 2001
@@ -1195,8 +1195,10 @@
if (vcp==NULL)
return -ENOMEM;
if (vw.clipcount && copy_from_user(vcp,vw.clips,sizeof(s$
- return -EFAULT;
-
+ {
+ vfree(vcp);
+ return -EFAULT;
+ }
on = ztv->running;
if (on)
zoran_cap(ztv, 0);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch] Output of L1,L2 and L3 cache sizes to /proc/cpuinfo
On Wed, 23 May 2001, Tomas Telensky wrote: > Yes. Recently I tried to transform whole cpuid code to a userspace > utility. Not easy, not clean... but it worked. See http://www.sourceforge.net/projects/x86info or ftp://ftp.suse.com/pub/people/davej/x86info/ regards, Dave. -- | Dave Jones.http://www.suse.de/~davej | SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
REGISTRE EL SUYO AHORA
Si tiene una empresa en marcha, un proyecto o una idea registre su dominio en Internet AHORA, tal vez mañana sea demasiado tarde. Proteja su nombre en Internet. Si tiene ya dominio y ha de renovarlo proximamente transfiera el dominio por solo 20$ lo tendra un año renovado (esta operacion no afecta al hospedaje, solo al registrador del dominio) Si conoce a alguien en esta situacion y no sabe que regalarle regalele un dominio, es original y quedara bien. Vea toda la informacion referente al registro de dominios en http://ir-a.net/mark/ REGALE UN DOMINIO O REGISTRE EL SUYO Otros servicios: hospedaje, redireccion de dominio, ...etc ¿HAS DE RENOVAR EL REGISTRO DE TU DOMINIO? PRECIO ESPECIAL POR TRANSFERENCIA DE DOMINIO (20$ AÑO) PRECIO DE HOSTING IMBATIBLE ---REMOVE-- SI NO QUIERE RECIBIR MAS MENSAJES DESDE ESTA DIRECCION VAYA AL LINK INDICADO Y SERA DADO DE BAJA INMEDIATAMENTE. DICHO LINK ES UN SERVICIO INDEPENDIENTE DEL ENVIO DE ESTE EMAIL -- dar de baja de la lista de distribucion - remove distribution list http://borrame.anexos.com RemovingNet. Cuentas gratuitas para el control de bajas. Free accounts for the control of "unsubscribes" RemovingNet nada tiene que ver con este email ni con su contenido RemovingNet nothing has to do with this email nor with contained his IF YOU DON'T WANT TO RECEIVE MORE MESSAGES FROM US, PLEASE CLICK ON THE LINK BELOW. http://borrame.anexos.com YOUR EMAIL ADDRESS WILL BE REMOVED FROM OUR DATA BASE IMMEDIATELY. REMOVING.NET IS AN INDEPENDENT SERVICE ---REMOVE-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] struct char_device
On Wed, 23 May 2001 [EMAIL PROTECTED] wrote: > >>dev_t rdev; > > > Reasonable. > > Good. We all agree. > (But now you see what I meant in comments about mknod.) > > >>kdev_t dev; > > > Useless. If you hope that block_device will help to solve rmmod races > > Yes. Why am I mistaken? Because the problems begin in subsystems. Solving the situation with block_device_operations is trivial. It's stuff on the character side that is going to bite you big way. TTY drivers, for example. They are below the layer where your kdev_t lives. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.4 - I2O printer port weirdness
> I2C Printer port detects , then > 0x378 detects too > but both are parport0 ? > > SMSC Super-IO detection, now testing Ports 2F0, 370 ... > parport0: PC-style at 0x378 [PCSPP,TRISTATE,EPP] Thata your parallel port > i2c-philips-par.o: i2c Philips parallel port adapter module > i2c-philips-par.o: attaching to parport0 > i2c-dev.o: Registered 'Philips Parallel port adapter' as minor 0 Then for some reason you attached a driver for external i2c bus onto it. I suspect you compiled things into your kernel you didnt mean too 8) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] struct char_device
>> dev_t rdev; > Reasonable. Good. We all agree. (But now you see what I meant in comments about mknod.) >> kdev_t dev; > Useless. If you hope that block_device will help to solve rmmod races Yes. Why am I mistaken? Andries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] struct char_device
[EMAIL PROTECTED] wrote:
>
> > IMHO it would be nice to create wrappers for accessing the block arrays
>
> Last year Linus didnt like that at all. Maybe this year.
Well... the attached patch lines up into this effort and fixes
some abuses, removes redundant code and so on. Please have a second
look.
diff -urN linux/drivers/block/ll_rw_blk.c new/drivers/block/ll_rw_blk.c
--- linux/drivers/block/ll_rw_blk.c Thu Apr 12 21:15:52 2001
+++ new/drivers/block/ll_rw_blk.c Mon Apr 30 23:16:03 2001
@@ -85,25 +85,21 @@
int * blk_size[MAX_BLKDEV];
/*
- * blksize_size contains the size of all block-devices:
+ * blksize_size contains the block size of all block-devices:
*
* blksize_size[MAJOR][MINOR]
*
- * if (!blksize_size[MAJOR]) then 1024 bytes is assumed.
+ * Access to this array should happen through the get_blksize_size() function.
+ * If (!blksize_size[MAJOR]) then 1024 bytes is assumed.
*/
int * blksize_size[MAX_BLKDEV];
/*
* hardsect_size contains the size of the hardware sector of a device.
*
- * hardsect_size[MAJOR][MINOR]
- *
- * if (!hardsect_size[MAJOR])
- * then 512 bytes is assumed.
- * else
- * sector_size is hardsect_size[MAJOR][MINOR]
- * This is currently set by some scsi devices and read by the msdos fs driver.
- * Other uses may appear later.
+ * Access to this array should happen through the get_hardsect_size() function.
+ * The default value is assumed to be 512 unless specified differently by the
+ * corresponding low-level driver.
*/
int * hardsect_size[MAX_BLKDEV];
@@ -992,22 +988,14 @@
void ll_rw_block(int rw, int nr, struct buffer_head * bhs[])
{
- unsigned int major;
- int correct_size;
+ ssize_t correct_size;
int i;
if (!nr)
return;
- major = MAJOR(bhs[0]->b_dev);
-
/* Determine correct block size for this device. */
- correct_size = BLOCK_SIZE;
- if (blksize_size[major]) {
- i = blksize_size[major][MINOR(bhs[0]->b_dev)];
- if (i)
- correct_size = i;
- }
+ correct_size = get_blksize_size(bhs[0]->b_dev);
/* Verify requested block sizes. */
for (i = 0; i < nr; i++) {
diff -urN linux/drivers/block/loop.c new/drivers/block/loop.c
--- linux/drivers/block/loop.c Thu Apr 12 04:05:14 2001
+++ new/drivers/block/loop.cMon Apr 30 23:30:17 2001
@@ -272,22 +272,10 @@
return desc.error;
}
-static inline int loop_get_bs(struct loop_device *lo)
-{
- int bs = 0;
-
- if (blksize_size[MAJOR(lo->lo_device)])
- bs = blksize_size[MAJOR(lo->lo_device)][MINOR(lo->lo_device)];
- if (!bs)
- bs = BLOCK_SIZE;
-
- return bs;
-}
-
static inline unsigned long loop_get_iv(struct loop_device *lo,
unsigned long sector)
{
- int bs = loop_get_bs(lo);
+ int bs = get_blksize_size(lo->lo_device);
unsigned long offset, IV;
IV = sector / (bs >> 9) + lo->lo_offset / bs;
@@ -306,9 +294,9 @@
pos = ((loff_t) bh->b_rsector << 9) + lo->lo_offset;
if (rw == WRITE)
- ret = lo_send(lo, bh, loop_get_bs(lo), pos);
+ ret = lo_send(lo, bh, get_blksize_size(lo->lo_device), pos);
else
- ret = lo_receive(lo, bh, loop_get_bs(lo), pos);
+ ret = lo_receive(lo, bh, get_blksize_size(lo->lo_device), pos);
return ret;
}
@@ -650,12 +638,7 @@
lo->old_gfp_mask = inode->i_mapping->gfp_mask;
inode->i_mapping->gfp_mask = GFP_BUFFER;
- bs = 0;
- if (blksize_size[MAJOR(inode->i_rdev)])
- bs = blksize_size[MAJOR(inode->i_rdev)][MINOR(inode->i_rdev)];
- if (!bs)
- bs = BLOCK_SIZE;
-
+ bs = get_blksize_size(inode->i_rdev);
set_blocksize(dev, bs);
lo->lo_bh = lo->lo_bhtail = NULL;
diff -urN linux/drivers/char/raw.c new/drivers/char/raw.c
--- linux/drivers/char/raw.cFri Apr 27 23:23:25 2001
+++ new/drivers/char/raw.c Mon Apr 30 22:57:20 2001
@@ -124,22 +124,25 @@
return err;
}
-
- /*
-* Don't interfere with mounted devices: we cannot safely set
-* the blocksize on a device which is already mounted.
+ /*
+* 29.04.2001 Martin Dalecki:
+*
+* The original comment here was saying:
+*
+* "Don't interfere with mounted devices: we cannot safely set the
+* blocksize on a device which is already mounted."
+*
+* However the code below was setting happily the blocksize
+* disregarding the previous check. I have fixed this, however I'm
+* quite sure, that the statement above isn't right and we should be
+* able to remove the first arm of the branch below entierly.
*/
-
- sector_size = 512;
if (get_super(rdev) != NULL) {
- if
Re: [PATCH] struct char_device
> IMHO it would be nice to create wrappers for accessing the block arrays Last year Linus didnt like that at all. Maybe this year. Andries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] struct char_device
> why not implement partitions as simply doing block remaps Everybody agrees. Andries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch] Output of L1,L2 and L3 cache sizes to /proc/cpuinfo
On Tue, 22 May 2001, H. Peter Anvin wrote: > Martin Knoblauch wrote: > > > > > > If so, then that's their problem. We're not here to solve the problem of > > > stupid system administrators. > > > > > > > They may not be stupid, just mislead :-( When Intel created the "cpuid" > > Feature some way along the P3 line, they gave a stupid reason for it and > > created a big public uproar. As silly as I think that was (on both > > sides), the term "cpuid" is tainted. Some people just fear it like hell. > > Anyway. > > > > Ummm... CPUID has been around since the P5, and even if you have one with > the serial-number feature, Linux disables it. > > > > > - you would need a utility with root permission to analyze the cpuid > > > > info. The > > > > cahce info does not seem to be there in clear ascii. > > > > > > Bullsh*t. /dev/cpu/%d/cpuid is supposed to be mode 444 (world readable.) > > > > > > > Thanks you :-) In any case, on my system (Suse 7.1) the files are mode > > 400. > > > > It's pointless since you can execute CPUID directly in user space. The Yes. Recently I tried to transform whole cpuid code to a userspace utility. Not easy, not clean... but it worked. Tomas P.S.: but I still find the patch useful. > device is there just to support CPU selection in a multiprocessor system. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] struct char_device
On Tue, May 22 2001, Jeff Garzik wrote: > IMHO it would be nice to (for 2.4) create wrappers for accessing the > block arrays, so that we can more easily dispose of the arrays when 2.5 > rolls around... Agreed, in fact I have a lot of stuff that could be included in the kcompat files for 2.4 (of course still changing :) BTW, max_sectors/max_segments/hardsect_size already in place. Still some to go. -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: alpha iommu fixes
David S. Miller writes: > What are these "devices", and what drivers "just program the cards to > start the dma on those hundred mbyte of ram"? Hmmm, I have a few cards that are used that way. They are used for communication between nodes of a cluster. One might put 16 cards in a system. The cards are quite happy to do a 2 GB DMA transfer. Scatter-gather is possible, but it cuts performance. Typically the driver would provide a huge chunk of memory for an app to use, mapped using large pages on x86 or using BAT registers on ppc. (reserved during boot of course) The app would crunch numbers using the CPU (with AltiVec, VIS, 3dnow, etc.) and instruct the device to transfer data to/from the memory region. Remote nodes initiate DMA too, even supplying the PCI bus address on both sides of the interconnect. :-) No IOMMU problems with that one, eh? The other node may transfer data at will. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] struct char_device
Alexander Viro wrote: > Do we really want a separate queue for each partition? I'd rather have > disk_struct created when driver sees the disk and list of partitions > (possibly represented by struct block_device) anchored in disk_struct > and populated by grok_partitions(). Alan recently straightened me out with "EVMS/LVM is partitions done right" so... why not implement partitions as simply doing block remaps to the lower level device? That's what EVMS/LVM/md are doing already. -- Jeff Garzik | "Are you the police?" Building 1024| "No, ma'am. We're musicians." MandrakeSoft | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] CREDITS file update (address change)
Hi all Find enclosed a tiny patch to the CREDITS file - I have moved house. It's against the 2.2.19 CREDITS file, but is also relevant for the 2.4.x series. jonathan --- CREDITS-2.2.19 Thu May 10 09:43:35 2001 +++ CREDITS Thu May 10 09:44:15 2001 @@ -2398,8 +2398,8 @@ E: [EMAIL PROTECTED] W: http://www.physics.adelaide.edu.au/~jwoithe D: ALS-007 sound card extensions to Sound Blaster driver -S: 4/36 Trevelyan St -S: Wayville SA 5034 +S: 20 Jordan St +S: Valley View, SA 5093 S: Australia N: Clifford Wolf -- * Jonathan Woithe[EMAIL PROTECTED]* *http://www.physics.adelaide.edu.au/~jwoithe* ***---*** ** "Time is an illusion; lunchtime doubly so" ** * "...you wouldn't recognize a subtle plan if it painted itself purple * * and danced naked on a harpsicord singing 'subtle plans are here again'" * - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch] Output of L1,L2 and L3 cache sizes to /proc/cpuinfo
Martin Knoblauch wrote: > > > > If so, then that's their problem. We're not here to solve the problem of > > stupid system administrators. > > > > They may not be stupid, just mislead :-( When Intel created the "cpuid" > Feature some way along the P3 line, they gave a stupid reason for it and > created a big public uproar. As silly as I think that was (on both > sides), the term "cpuid" is tainted. Some people just fear it like hell. > Anyway. > Ummm... CPUID has been around since the P5, and even if you have one with the serial-number feature, Linux disables it. > > > - you would need a utility with root permission to analyze the cpuid > > > info. The > > > cahce info does not seem to be there in clear ascii. > > > > Bullsh*t. /dev/cpu/%d/cpuid is supposed to be mode 444 (world readable.) > > > > Thanks you :-) In any case, on my system (Suse 7.1) the files are mode > 400. > It's pointless since you can execute CPUID directly in user space. The device is there just to support CPU selection in a multiprocessor system. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] struct char_device
On Wed, 23 May 2001 [EMAIL PROTECTED] wrote:
> I am not sure whether we agree or differ in opinion. I wouldn't mind
>
> /* pairing for dev_t to bd_op/cd_op */
> struct bc_device {
> struct list_headbd_hash;
> atomic_tbd_count;
> dev_t bd_dev;
> atomic_tbd_openers;
> union {
> struct block_device_operations_and_data *bd_op;
> struct char_device_operations_and_data *cd_op;
> }
> struct semaphorebd_sem;
> };
>
> typedef struct bc_device *kdev_t;
What for? What part of the kernel needs a device and doesn't know apriory
whether it's block or character one?
> and in an inode
>
> kdev_t dev;
Useless. If you hope that block_device will help to solve rmmod races -
sorry, it won't. Wrong layer.
> dev_t rdev;
Reasonable.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch] Output of L1,L2 and L3 cache sizes to /proc/cpuinfo
"H. Peter Anvin" wrote: > > "Martin.Knoblauch" wrote: > > > > After some checking, I could have made the answer a bit less terse: > > > > - it would require that the kernel is compiled with cpuid [module] > > support > > - not everybody may want enable this, just for getting one or two > > harmless numbers. > > If so, then that's their problem. We're not here to solve the problem of > stupid system administrators. > They may not be stupid, just mislead :-( When Intel created the "cpuid" Feature some way along the P3 line, they gave a stupid reason for it and created a big public uproar. As silly as I think that was (on both sides), the term "cpuid" is tainted. Some people just fear it like hell. Anyway. > > - you would need a utility with root permission to analyze the cpuid > > info. The > > cahce info does not seem to be there in clear ascii. > > Bullsh*t. /dev/cpu/%d/cpuid is supposed to be mode 444 (world readable.) > Thanks you :-) In any case, on my system (Suse 7.1) the files are mode 400. Martin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch] Output of L1,L2 and L3 cache sizes to /proc/cpuinfo
On Wed, 23 May 2001, Tomas Telensky wrote: > > Any particular reason this needs to be done in the kernel, as opposed > It is already done in kernel, because it's displaying :) > So, once evaluated, why not to give it to /proc/cpuinfo. I think it makes > sense and gives it things in order. Displaying at boottime only means the function can be marked as initcode, and freed after usage. Putting it in proc/cpuinfo means we use up kernel space that can't be freed. regards, Dave. -- | Dave Jones.http://www.suse.de/~davej | SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] struct char_device
From [EMAIL PROTECTED] Wed May 23 00:39:23 2001
On Tue, 22 May 2001 [EMAIL PROTECTED] wrote:
>
> The operations are different, but all bdev/cdev code is identical.
>
> So the choice is between two uglies:
> (i) have some not entirely trivial amount of code twice in the kernel
> (ii) have a union at the point where the struct operations
> is assigned.
>
> I preferred the union.
I would much prefer a union of pointers over a pointer to a union.
Why? Because if you have a "struct inode", you also have enough
information to decide _which_ of the two types of pointers you have, so
you can do the proper dis-ambiguation of the union and properly select
either 'inode->dev.char' or 'inode->dev.block' depending on other
information in the inode.
I am not sure whether we agree or differ in opinion. I wouldn't mind
/* pairing for dev_t to bd_op/cd_op */
struct bc_device {
struct list_headbd_hash;
atomic_tbd_count;
dev_t bd_dev;
atomic_tbd_openers;
union {
struct block_device_operations_and_data *bd_op;
struct char_device_operations_and_data *cd_op;
}
struct semaphorebd_sem;
};
typedef struct bc_device *kdev_t;
and in an inode
kdev_t dev;
dev_t rdev;
In reality we want the pair (dev_t, pointer to stuff), but then
there is all this administrative nonsense needed to make sure
that nobody uses the pointer after the module has been unloaded
that makes the pointer a bit thicker.
And we should not depend on the "inode->dev." pointer
being valid all the time, as there is absolutely zero point
in initializing the pointer every time somebody does a "ls -l /dev".
Yes, that is why I want to go back and have dev_t rdev, not kdev_t.
The lookup is done when the device is opened.
Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: write to dvd ram
I tried to give you some pointers in a personal email. So it's not true you didn't receive any response. Also reminded you of the best place to look for info, namely, that driver's mailing list. You don't seem to have made any additional attempts at resolving it yourself since you reposted your original message. Get newer kernel sources, read the driver's documentation more thoroughly. -- Rafael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Oops on booting 2.4.4
Hi folks,(cc me, as i'm not on the list) [1.] One line summary of the problem: Kernel 2.4.4 oopses during boot [2.] Full description of the problem/report: Kernel 2.4.4 oopses during boot on RH 7.1 system, seems when it's running kudzu or something (maybe I saw it wrong) After first oops, some more appears and system hangs. on RH 6.2 2.4.4 with same .config worked fine. I tried both: CC = $(CROSS_COMPILE)kgcc and CC = $(CROSS_COMPILE)gcc [3.] Keywords (i.e., modules, networking, kernel): kernel, oops, boot [4.] Kernel version: Linux version 2.4.4 [5.] Output of Oops.. message (if applicable) with symbolic information resolved (see Documentation/oops-tracing.txt) ksymoops 2.4.0 on i686 2.4.2-2. Options used -V (default) -K (specified) -l /proc/modules (default) -o /lib/modules/2.4.4 (specified) -m /boot/System.map-2.4.4 (specified) No modules in ksyms, skipping objects No ksyms, skipping lsmod May 23 02:46:24 localhost kernel: Unable to handle kernel paging request at virtual address c88fbb28 May 23 02:46:24 localhost kernel: c02071ad May 23 02:46:24 localhost kernel: *pde = 01240067 May 23 02:46:24 localhost kernel: Oops: May 23 02:46:24 localhost kernel: CPU:0 May 23 02:46:24 localhost kernel: EIP: 0010:[get_pci_dev_info+269/432] May 23 02:46:24 localhost kernel: EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 May 23 02:46:24 localhost kernel: EFLAGS: 00010282 May 23 02:46:24 localhost kernel: eax: 0009 ebx: 008e ecx: c88fbb20 edx: c02b27e1 May 23 02:46:24 localhost kernel: esi: 00c4 edi: 0007 ebp: c122a000 esp: c7845f40 May 23 02:46:24 localhost kernel: ds: 0018 es: 0018 ss: 0018 May 23 02:46:24 localhost kernel: Process kudzu (pid: 219, stackpage=c7845000) May 23 02:46:24 localhost kernel: Stack: c12607e0 0400 0400 c73aa000 c122a060 c122a05c c122a058 c88fbb20 May 23 02:46:24 localhost kernel:03f1 03f1 c014ab80 c73aa3f1 c7845f9c 0400 ffea May 23 02:46:24 localhost kernel:c7f43f60 0400 b4b8 c7f2e220 c12607e0 c73aa000 May 23 02:46:24 localhost kernel: Call Trace: [] [proc_file_read+184/464] [sys_read+142/196] [system_call+51/56] May 23 02:46:24 localhost kernel: Call Trace: [] [] [] [] May 23 02:46:24 localhost kernel: Code: 8b 41 08 50 68 e3 27 2b c0 8b 44 24 34 01 d8 50 e8 02 d3 05 >>EIP; c02071ad<= Trace; c88fbb20 Trace; c88fbb20 Trace; c014ab80 Trace; c012e83e Trace; c0106aeb Code; c02071ad <_EIP>: Code; c02071ad<= 0: 8b 41 08 mov0x8(%ecx),%eax <= Code; c02071b0 3: 50push %eax Code; c02071b1 4: 68 e3 27 2b c0push $0xc02b27e3 Code; c02071b6 9: 8b 44 24 34 mov0x34(%esp,1),%eax Code; c02071ba d: 01 d8 add%ebx,%eax Code; c02071bc f: 50push %eax Code; c02071bd 10: e8 02 d3 05 00call 5d317 <_EIP+0x5d317> c02644c4 [6.] A small shell script or example program which triggers the problem (if possible) [7.] Environment [7.1.] Software (add the output of the ver_linux script here) Linux c122070.upc-c.chello.nl 2.4.2-2 #1 Sun Apr 8 20:41:30 EDT 2001 i686 unknow n Gnu C 2.96(kgcc egcs-2.91.66) Gnu make 3.79.1 binutils 2.10.91.0.2 util-linux 2.10s mount 2.11b modutils 2.4.5 e2fsprogs 1.19 reiserfsprogs 3.x.0f PPP2.4.0 Linux C Library2.2.2 Dynamic linker (ldd) 2.2.2 Procps 2.0.7 Net-tools 1.57 Console-tools 0.3.3 Sh-utils 2.0 Modules Loaded ppa parport_pc parport autofs 3c59x nls_iso8859-1 nls_cp4 37 vfat fat reiserfs usb-uhci usbcore aic7xxx sd_mod scsi_mod [7.2.] Processor information (from /proc/cpuinfo): processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 7 model name : Pentium III (Katmai) stepping : 3 cpu MHz : 451.031 cache size : 512 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr sse bogomips : 897.84 [8] Bootmessages May 23 02:46:23 localhost syslogd 1.4-0: restart. May 23 02:46:23 localhost syslog: syslogd startup succeeded May 23 02:46:23 localhost kernel: klogd 1.4-0, log source = /proc/kmsg started. May 23 02:46:23 localhost kernel: Inspecting /boot/System.map-2.4.4 May 23 02:46:23 localhost syslog: klogd startup succeeded May 23 02:46:23 localhost modprobe: modprobe: Can't locate module autofs May 23 02:46:23 localhost identd: identd startup succeeded May 23 02:46:23 localhost kernel: Loaded 16874 symbols from /boot/System.map-2.4.4. May 23 02:46:23 localhost kernel: Symbols match
Re: [PATCH][RFT] smbfs bugfixes for 2.4.4
On Wed, 23 May 2001, Xuan Baldauf wrote:
> Urban Widmark wrote:
>
> > The only other way I have found so far to get it to return the right file
> > size is to do a "seek-to-end". That still means an extra SMB but it avoids
> > the very painful "sync to disk".
> >
> > Fortunately the seek is only necessary when refreshing inode info, on a
> > "win95" server, on a file that is open and that we have written to.
>
> Maybe it is also a workaround for the problem where changes on the
> windows side are not reflected?
Yes, that was the point of removing the LOCALWRITE flag in the first
place. As far as I can tell this should still fix the file cache/sync
problems that have been found.
> Is it possible to resend the patch in mime format or publish it somewhere accessible
>by an URL? Netscape Messenger
> creates spaces everywhere where tabs should be :-(
Certainly.
/Urban
diff -urN -X exclude linux-2.4.5-pre4-orig/fs/smbfs/Makefile
linux-2.4.5-pre4-smbfs/fs/smbfs/Makefile
--- linux-2.4.5-pre4-orig/fs/smbfs/Makefile Thu Feb 22 20:52:03 2001
+++ linux-2.4.5-pre4-smbfs/fs/smbfs/MakefileWed May 23 00:19:08 2001
@@ -16,6 +16,7 @@
# SMBFS_PARANOIA should normally be enabled.
EXTRA_CFLAGS += -DSMBFS_PARANOIA
+EXTRA_CFLAGS += -DSMB_WIN95_LOCALWRITE_FIX
#EXTRA_CFLAGS += -DSMBFS_DEBUG
#EXTRA_CFLAGS += -DSMBFS_DEBUG_VERBOSE
#EXTRA_CFLAGS += -DDEBUG_SMB_MALLOC
diff -urN -X exclude linux-2.4.5-pre4-orig/fs/smbfs/file.c
linux-2.4.5-pre4-smbfs/fs/smbfs/file.c
--- linux-2.4.5-pre4-orig/fs/smbfs/file.c Sun May 20 15:20:17 2001
+++ linux-2.4.5-pre4-smbfs/fs/smbfs/file.c Tue May 22 23:53:43 2001
@@ -151,6 +151,7 @@
* Update the inode now rather than waiting for a refresh.
*/
inode->i_mtime = inode->i_atime = CURRENT_TIME;
+ inode->u.smbfs_i.flags |= SMB_F_LOCALWRITE;
if (offset > inode->i_size)
inode->i_size = offset;
} while (count);
diff -urN -X exclude linux-2.4.5-pre4-orig/fs/smbfs/inode.c
linux-2.4.5-pre4-smbfs/fs/smbfs/inode.c
--- linux-2.4.5-pre4-orig/fs/smbfs/inode.c Sun May 20 15:20:17 2001
+++ linux-2.4.5-pre4-smbfs/fs/smbfs/inode.c Tue May 22 21:02:29 2001
@@ -141,8 +141,8 @@
inode->u.smbfs_i.oldmtime = jiffies;
if (inode->i_mtime != last_time || inode->i_size != last_sz) {
- VERBOSE("%s/%s changed, old=%ld, new=%ld, oz=%ld, nz=%ld\n",
- DENTRY_PATH(dentry),
+ VERBOSE("%ld changed, old=%ld, new=%ld, oz=%ld, nz=%ld\n",
+ inode->i_ino,
(long) last_time, (long) inode->i_mtime,
(long) last_sz, (long) inode->i_size);
diff -urN -X exclude linux-2.4.5-pre4-orig/fs/smbfs/proc.c
linux-2.4.5-pre4-smbfs/fs/smbfs/proc.c
--- linux-2.4.5-pre4-orig/fs/smbfs/proc.c Sun May 20 15:20:17 2001
+++ linux-2.4.5-pre4-smbfs/fs/smbfs/proc.c Wed May 23 00:19:19 2001
@@ -919,6 +919,31 @@
}
/*
+ * Called with the server locked
+ */
+static int
+smb_proc_seek(struct smb_sb_info *server, __u16 fileid,
+ __u16 mode, off_t offset)
+{
+ int result;
+
+ smb_setup_header(server, SMBlseek, 4, 0);
+ WSET(server->packet, smb_vwv0, fileid);
+ WSET(server->packet, smb_vwv1, mode);
+ DSET(server->packet, smb_vwv2, offset);
+
+ result = smb_request_ok(server, SMBlseek, 2, 0);
+ if (result < 0) {
+ result = 0;
+ goto out;
+ }
+
+ result = DVAL(server->packet, smb_vwv0);
+out:
+ return result;
+}
+
+/*
* We're called with the server locked, and we leave it that way.
*/
static int
@@ -1210,10 +1235,12 @@
if (result >= 0)
result = WVAL(server->packet, smb_vwv0);
+#ifndef SMB_WIN95_LOCALWRITE_FIX
/* flush to disk, to trigger win9x to update its filesize */
/* FIXME: this will be rather costly, won't it? */
if (server->mnt->flags & SMB_MOUNT_WIN95)
smb_proc_flush(server, fileid);
+#endif
smb_unlock_server(server);
return result;
@@ -2246,6 +2273,7 @@
struct smb_fattr *fattr)
{
int result;
+ struct inode *inode = dir->d_inode;
smb_init_dirent(server, fattr);
@@ -2262,6 +2290,22 @@
else
result = smb_proc_getattr_trans2(server, dir, fattr);
}
+
+#ifdef SMB_WIN95_LOCALWRITE_FIX
+ /*
+* None of the getattr versions here can make win95 return the right
+* filesize if there are changes made to it. A seek-to-end does return
+* the right size, but we only need to do that on files we have written.
+*/
+ if (server->mnt->flags & SMB_MOUNT_WIN95 &&
+ inode &&
+ inode->u.smbfs_i.flags & SMB_F_LOCALWRITE &&
+
Re: [PATCH][RFT] smbfs bugfixes for 2.4.4
Urban Widmark wrote: > On Mon, 21 May 2001, Xuan Baldauf wrote: > > > That is annoying, because it heavily slows down bulk transfers of small > > writes, like automatically unzipping a new mozilla build from the linux box to > > the windows box. Every write of say 100 bytes is implemented as > > > > send write req > > recv write ack > > send flush req > > sync to disk (on the windows machine) > > recv flush ack > > The only other way I have found so far to get it to return the right file > size is to do a "seek-to-end". That still means an extra SMB but it avoids > the very painful "sync to disk". > > Fortunately the seek is only necessary when refreshing inode info, on a > "win95" server, on a file that is open and that we have written to. Maybe it is also a workaround for the problem where changes on the windows side are not reflected? > > > This should be significantly better, but still works with my testcases. > patch vs 2.4.5-pre4, please test. > > /Urban > [...patch...] Is it possible to resend the patch in mime format or publish it somewhere accessible by an URL? Netscape Messenger creates spaces everywhere where tabs should be :-( Xuân. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] struct char_device
And if we are at the topic... Those are the places where blk_size[] get's abused, since it's in fact a property of a FS in fact and not the property of a particular device... blksect_size is the array describing the physical access limits of a device and blk_size get's usually checked against it. However due to the bad naming and the fact that this information is associated with major/minor number usage same device driver writers got *very* confused as you can see below: ./fs/block_dev.c: Here this information should be passed entierly insice the request. ./fs/partitions/check.c: Here it basically get's reset or ignored Here it's serving the purpose of a sector size, which is bogous! ./mm/swapfile.c:#include /* for blk_size */ ./mm/swapfile.c:if (!dev || (blk_size[MAJOR(dev)] && ./mm/swapfile.c: !blk_size[MAJOR(dev)][MINOR(dev)])) ./mm/swapfile.c:if (blk_size[MAJOR(dev)]) ./mm/swapfile.c:swapfilesize = blk_size[MAJOR(dev)][MINOR(dev)] Here it shouldn't be needed ./drivers/block/ll_rw_blk.c: ./drivers/block/floppy.c: blk_size[MAJOR_NR] = floppy_sizes; ./drivers/block/nbd.c: blk_size[MAJOR_NR] = nbd_sizes; ./drivers/block/rd.c: * and set blk_size for -ENOSPC, Werner Fink <[EMAIL PROTECTED]>, Apr '99 ./drivers/block/amiflop.c: blk_size[MAJOR_NR] = floppy_sizes; ./drivers/block/loop.c: if (blk_size[MAJOR(lodev)]) ./drivers/block/ataflop.c: * - Set blk_size for proper size checking ./drivers/block/ataflop.c: blk_size[MAJOR_NR] = floppy_sizes; ./drivers/block/cpqarray.c: drv->blk_size; ./drivers/block/z2ram.c:blk_size[ MAJOR_NR ] = z2_sizes; ./drivers/block/swim3.c:blk_size[MAJOR_NR] = floppy_sizes; ./drivers/block/swim_iop.c: blk_size[MAJOR_NR] = floppy_sizes; ./drivers/char/raw.c: if (blk_size[MAJOR(dev)]) ./drivers/scsi/advansys.c:ASC_DCNTblk_size; ./drivers/scsi/sd.c:blk_size[SD_MAJOR(i)] = NULL; ./drivers/scsi/sr.c:blk_size[MAJOR_NR] = sr_sizes; ./drivers/scsi/sr.c:blk_size[MAJOR_NR] = NULL; ./drivers/sbus/char/jsflash.c: blk_size[JSFD_MAJOR] = jsfd_sizes; ./drivers/ide/ide-cd.c: blk_size[HWIF(drive)->major] = HWIF(drive)->gd->sizes; ./drivers/ide/ide-floppy.c: * Revalidate the new media. Should set blk_size[] ./drivers/acorn/block/fd1772.c: blk_size[MAJOR_NR] = floppy_sizes; ./drivers/i2o/i2o_block.c: blk_size[MAJOR_NR] = i2ob_sizes; In the following they are REALLY confusing it and then compensating for this misunderstanding in lvm.h by redefining the corresponding default values. ./drivers/s390/* And then some minor confusions follow... ./drivers/mtd/mtdblock.c: blk_size[MAJOR_NR] = NULL; ./drivers/md/md.c: if (blk_size[MAJOR(dev)]) ./arch/m68k/atari/stram.c:blk_size[STRAM_MAJOR] = stram_sizes; Basically one should just stop setting blk_size[][] inside *ANY* driver and anything should still work fine unless the driver is broken... Well that's the point for another fine kernel experiment I will do and report whatever it works really out like this in reality 8-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch] Output of L1,L2 and L3 cache sizes to /proc/cpuinfo
On 21 May 2001, H. Peter Anvin wrote: > Followup to: <[EMAIL PROTECTED]> > By author:"Martin.Knoblauch" <[EMAIL PROTECTED]> > In newsgroup: linux.dev.kernel > > > > Hi, > > > > while trying to enhance a small hardware inventory script, I found that > > cpuinfo is missing the details of L1, L2 and L3 size, although they may > > be available at boot time. One could of cource grep them from "dmesg" > > output, but that may scroll away on long lived systems. > > > > Any particular reason this needs to be done in the kernel, as opposed It is already done in kernel, because it's displaying :) So, once evaluated, why not to give it to /proc/cpuinfo. I think it makes sense and gives it things in order. Tomas > to having your script read /dev/cpu/*/cpuid? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] struct char_device
On Tue, 22 May 2001 [EMAIL PROTECTED] wrote:
>
> The operations are different, but all bdev/cdev code is identical.
>
> So the choice is between two uglies:
> (i) have some not entirely trivial amount of code twice in the kernel
> (ii) have a union at the point where the struct operations
> is assigned.
>
> I preferred the union.
I would much prefer a union of pointers over a pointer to a union.
So I'd much rather have the inode have a
union {
struct block_device *block;
struct char_device *char;
} dev;
and then have people do
cdev = inode->dev.char;
to get the right information, than to have
union block_char_union {
struct block_device block;
struct char_device char;
};
.. with struct inode containing ..
union block_char_union *dev;
Why? Because if you have a "struct inode", you also have enough
information to decide _which_ of the two types of pointers you have, so
you can do the proper dis-ambiguation of the union and properly select
either 'inode->dev.char' or 'inode->dev.block' depending on other
information in the inode.
In contrast, if you have a pointer to a union, you don't have information
of which sub-type it is, and you'd have to carry that along some other way
(for example, by having common fields at the beginning). Which I think is
broken.
So my suggestion for eventual interfaces:
- have functions like
struct block_dev *bdget(struct inode *);
struct char_dev *cdget(struct inode *);
which populate the "inode->dev" union pointer, which in turn is _only_
a cache of the lookup. Right now we do this purely based on "dev_t",
and I think that is bogus. We should never pass a "dev_t" around
without an inode, I think.
And we should not depend on the "inode->dev." pointer being valid all
the time, as there is absolutely zero point in initializing the pointer
every time the inode is read just because somebody does a "ls -l /dev".
Thus the "cache" part above.
- NO reason to try to make "struct block_dev" and "struct char_dev" look
similar. They will have some commonality for lookup purposes (that
issue is similar, as Andries points out), and maybe that commonality
can be separated out into a sub-structure or something. But apart from
that, they have absolutely nothing to do with each other, and I'd
rather not have them have even a _superficial_ connection.
Block devices will have the "request queue" pointer, and the size and
partitioning information. Character devices currently would not have
much more than the operations pointer and name, but who knows..
But the most important thing is to be able to do this in steps. One of the
reasons Andries has had patches for a long time is that it was never very
gradual. Al's patch is gradual, and I like that.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] struct char_device
[EMAIL PROTECTED] wrote: > > Martin Dalecki writes: > > > Erm... I wasn't talking about the DESIRED state of affairs! > > I was talking about the CURRENT state of affairs. OK? > > Oh, but in 1995 it was quite possible to compile the kernel > with kdev_t a pointer type, and I have done it several times since. Yes I remember but unfortunately some big L* did ignore your *fine* efforts entierly in favour of developing /proc and /dev/random and other crap maybe? > The kernel keeps growing, so each time it is more work than > the previous time. > > > At least you have admitted that you where the one responsible > > for the design of this MESS. > > Thank you! However, you give me too much honour. Well ... you ask for it in the corresponding header ;-). But it isn't yours fault indeed I admit... I know the discussions from memmory since I'm returning REGULARLY to this topic in intervals of about between 6 and 24 months since about maybe already 6 years!!! Currently they have just started to hurt seriously. And please remember the change I have mentioned above wasn't intended as developement but just only as an experiment... Well let's us stop throw flames at each other. Please have a tight look at the following *EXPERIMENT* I have already done. It's really really only intended to mark the places where the full mess shows it's ugly head: http://www.dalecki.de/big-002.diff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Gameport analog joystick broken in 2.4.4-ac13
> I have an analog joystick plugged into the gameport of a Soundblaster > AWE64. In 2.4.4-ac12 this was recognized and worked just fine. Under > ac13 the recognition is incomplete - it seems to identify that there > is a NS558 gameport device present, but not that there is a joystick > plugged into it (unless I'm completely misunderstanding the log > messages). No joystick changes in 12->13. Is the fail repeatable ? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFT] smbfs bugfixes for 2.4.4
On Mon, 21 May 2001, Xuan Baldauf wrote:
> That is annoying, because it heavily slows down bulk transfers of small
> writes, like automatically unzipping a new mozilla build from the linux box to
> the windows box. Every write of say 100 bytes is implemented as
>
> send write req
> recv write ack
> send flush req
> sync to disk (on the windows machine)
> recv flush ack
The only other way I have found so far to get it to return the right file
size is to do a "seek-to-end". That still means an extra SMB but it avoids
the very painful "sync to disk".
Fortunately the seek is only necessary when refreshing inode info, on a
"win95" server, on a file that is open and that we have written to.
This should be significantly better, but still works with my testcases.
patch vs 2.4.5-pre4, please test.
/Urban
diff -urN -X exclude linux-2.4.5-pre4-orig/fs/smbfs/Makefile
linux-2.4.5-pre4-smbfs/fs/smbfs/Makefile
--- linux-2.4.5-pre4-orig/fs/smbfs/Makefile Thu Feb 22 20:52:03 2001
+++ linux-2.4.5-pre4-smbfs/fs/smbfs/MakefileWed May 23 00:19:08 2001
@@ -16,6 +16,7 @@
# SMBFS_PARANOIA should normally be enabled.
EXTRA_CFLAGS += -DSMBFS_PARANOIA
+EXTRA_CFLAGS += -DSMB_WIN95_LOCALWRITE_FIX
#EXTRA_CFLAGS += -DSMBFS_DEBUG
#EXTRA_CFLAGS += -DSMBFS_DEBUG_VERBOSE
#EXTRA_CFLAGS += -DDEBUG_SMB_MALLOC
diff -urN -X exclude linux-2.4.5-pre4-orig/fs/smbfs/file.c
linux-2.4.5-pre4-smbfs/fs/smbfs/file.c
--- linux-2.4.5-pre4-orig/fs/smbfs/file.c Sun May 20 15:20:17 2001
+++ linux-2.4.5-pre4-smbfs/fs/smbfs/file.c Tue May 22 23:53:43 2001
@@ -151,6 +151,7 @@
* Update the inode now rather than waiting for a refresh.
*/
inode->i_mtime = inode->i_atime = CURRENT_TIME;
+ inode->u.smbfs_i.flags |= SMB_F_LOCALWRITE;
if (offset > inode->i_size)
inode->i_size = offset;
} while (count);
diff -urN -X exclude linux-2.4.5-pre4-orig/fs/smbfs/inode.c
linux-2.4.5-pre4-smbfs/fs/smbfs/inode.c
--- linux-2.4.5-pre4-orig/fs/smbfs/inode.c Sun May 20 15:20:17 2001
+++ linux-2.4.5-pre4-smbfs/fs/smbfs/inode.c Tue May 22 21:02:29 2001
@@ -141,8 +141,8 @@
inode->u.smbfs_i.oldmtime = jiffies;
if (inode->i_mtime != last_time || inode->i_size != last_sz) {
- VERBOSE("%s/%s changed, old=%ld, new=%ld, oz=%ld, nz=%ld\n",
- DENTRY_PATH(dentry),
+ VERBOSE("%ld changed, old=%ld, new=%ld, oz=%ld, nz=%ld\n",
+ inode->i_ino,
(long) last_time, (long) inode->i_mtime,
(long) last_sz, (long) inode->i_size);
diff -urN -X exclude linux-2.4.5-pre4-orig/fs/smbfs/proc.c
linux-2.4.5-pre4-smbfs/fs/smbfs/proc.c
--- linux-2.4.5-pre4-orig/fs/smbfs/proc.c Sun May 20 15:20:17 2001
+++ linux-2.4.5-pre4-smbfs/fs/smbfs/proc.c Wed May 23 00:19:19 2001
@@ -919,6 +919,31 @@
}
/*
+ * Called with the server locked
+ */
+static int
+smb_proc_seek(struct smb_sb_info *server, __u16 fileid,
+ __u16 mode, off_t offset)
+{
+ int result;
+
+ smb_setup_header(server, SMBlseek, 4, 0);
+ WSET(server->packet, smb_vwv0, fileid);
+ WSET(server->packet, smb_vwv1, mode);
+ DSET(server->packet, smb_vwv2, offset);
+
+ result = smb_request_ok(server, SMBlseek, 2, 0);
+ if (result < 0) {
+ result = 0;
+ goto out;
+ }
+
+ result = DVAL(server->packet, smb_vwv0);
+out:
+ return result;
+}
+
+/*
* We're called with the server locked, and we leave it that way.
*/
static int
@@ -1210,10 +1235,12 @@
if (result >= 0)
result = WVAL(server->packet, smb_vwv0);
+#ifndef SMB_WIN95_LOCALWRITE_FIX
/* flush to disk, to trigger win9x to update its filesize */
/* FIXME: this will be rather costly, won't it? */
if (server->mnt->flags & SMB_MOUNT_WIN95)
smb_proc_flush(server, fileid);
+#endif
smb_unlock_server(server);
return result;
@@ -2246,6 +2273,7 @@
struct smb_fattr *fattr)
{
int result;
+ struct inode *inode = dir->d_inode;
smb_init_dirent(server, fattr);
@@ -2262,6 +2290,22 @@
else
result = smb_proc_getattr_trans2(server, dir, fattr);
}
+
+#ifdef SMB_WIN95_LOCALWRITE_FIX
+ /*
+* None of the getattr versions here can make win95 return the right
+* filesize if there are changes made to it. A seek-to-end does return
+* the right size, but we only need to do that on files we have written.
+*/
+ if (server->mnt->flags & SMB_MOUNT_WIN95 &&
+ inode &&
+ inode->u.smbfs_i.flags & SMB_F_LOCALWRITE &&
+ smb_is_open(inode))
+ {
+ __u16 fileid = inode->u.smbfs_i.fileid;
+ fattr->f_size = smb_proc_seek(server, fileid, 2, 0);
+ }
+#endif
re: scheduling callbacks in user space triggered via kernel....
Ashok wrote: > Is there a method to schedule user mode code from > kernel agent? ... > windows 2000 offers 2 such facilities. (APC or async > procedure calls) where a thread can block and when > ready will be woken via the kernel agent and can run a > user supplied function. > > or a method to bind a function to a file handle, when > there is Completed IO, the kernel would call the > registered function with a parameter of the buffer > submitted for IO. The traditional Unix way might be for user process to call one of the blocking functions (read(), poll(), sigwait(), etc), and have the kernel unblock the process in the usual way. There is support for real async I/O on the horizon; see the SGI patch at http://oss.sgi.com/projects/kaio/ if you need async I/O today. Not sure this is what you're after, though. Can you provide an example of how you want to use this? For those who haven't read about this NT stuff, see http://www.microsoft.com/msj/0499/pooling/pooling.htm Even AS/400 is getting into this stuff; see http://www.as400.ibm.com/developer/v4r5/api.html - Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
When is the earliest point I can call ioremap() ?
I'm trying to call ioremap fairly early on in kernel init (and it doesn't work ;-) ) What setup functions have to run before ioremap() will work? I can debug exactly what it's doing now if I have to, but I don't suspect it'll tell me much ... I'm calling from aroung console_init in start_kernel. Thanks, Martin. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] struct char_device
Martin Dalecki writes: > Erm... I wasn't talking about the DESIRED state of affairs! > I was talking about the CURRENT state of affairs. OK? Oh, but in 1995 it was quite possible to compile the kernel with kdev_t a pointer type, and I have done it several times since. The kernel keeps growing, so each time it is more work than the previous time. > At least you have admitted that you where the one responsible > for the design of this MESS. Thank you! However, you give me too much honour. Andries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Xircom RealPort versus 3COM 3C3FEM656C
On Tue, 22 May 2001 [EMAIL PROTECTED] wrote: > This sounds like a bug I have heard before: some switches don't work with > the xircom card (well, our drivers for it) when doing full duplex. > Could you try the latest driver from > > http://people.redhat.com/arjanv > > which forces the card to half-duplex? I doesn't help, the switch still thinks it's running in full-duplex mode. Performance is obviously the same. The switch I have is not managed, so there is nothing I can do on that front. Any other suggestions? [BTW, you've removed too many includes, the driver doesn't compile anymore in the 2.4.4-ac tree.] Thanks, Ion -- It is better to keep your mouth shut and be thought a fool, than to open it and remove all doubt. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.4-ac13
Alan Cox <[EMAIL PROTECTED]> écrit :
[...]
> o Add missing locking to stradis driver (me)
- unbalanced returns after down();
- 1770: if the initial version isn't racy with saa7146_irq (line 534), this
one is equivalent and shorter.
init_saa7146:2185
if ((saa->dmadebi = kmalloc(32768 + 4096, GFP_KERNEL)) == NULL)
[...]
looks suspect if the next vmalloc fail. Btw, I don't get the author
idea behind the whole "if (foo->bar == null) { foo->bar = vmalloc(...)}"
thing (chainsaw ?).
Fine against 2.4.4-ac14.
--- linux-2.4.4-ac13.orig/drivers/media/video/stradis.c Tue May 22 16:40:01 2001
+++ linux-2.4.4-ac13/drivers/media/video/stradis.c Tue May 22 17:31:48 2001
@@ -1513,8 +1513,10 @@ out:
SAA7146_MC1);
} else {
if (saa->win.vidadr == 0 || saa->win.width == 0
- || saa->win.height == 0)
+ || saa->win.height == 0) {
+ up(>sem);
return -EINVAL;
+ }
saa->cap |= 1;
saawrite((SAA7146_MC1_TR_E_1 << 16) | 0x,
SAA7146_MC1);
@@ -1770,16 +1772,18 @@ out:
if (saa->endmarktail <
saa->endmarkhead) {
if (saa->endmarkhead -
- saa->endmarktail < 2)
+ saa->endmarktail < 2) {
+ up(>sem);
return -ENOSPC;
- } else if (saa->endmarkhead <=
- saa->endmarktail) {
+ }
+ } else {
if (saa->endmarktail -
saa->endmarkhead >
- (MAX_MARKS - 2))
+ (MAX_MARKS - 2)) {
+ up(>sem);
return -ENOSPC;
- } else
- return -ENOSPC;
+ }
+ }
saa->endmark[saa->endmarktail] =
saa->audtail;
saa->endmarktail++;
@@ -1928,8 +1932,10 @@ static long saa_write(struct video_devic
saa->audtail = 0;
}
if (copy_from_user(saa->audbuf + saa->audtail, buf,
- blocksize))
- return -EFAULT;
+ blocksize)) {
+ count = -EFAULT;
+ goto out;
+ }
saa->audtail += blocksize;
todo -= blocksize;
buf += blocksize;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] struct char_device
[EMAIL PROTECTED] wrote: > > Martin Dalecki writes: > > > I fully agree with you. > > Good. > > Unfortunately I do not fully agree with you. > > > Most of the places where there kernel is passing kdev_t > > would be entierly satisfied with only the knowlendge of > > the minor number. > > My kdev_t is a pointer to a structure with device data > and device operations. Among the operations a routine > that produces a name. Among the data, in the case of a > block device, the size, and the sectorsize, .. > > A minor gives no name, and no data. > > Linus' minor is 20-bit if I recall correctly. > My minor is 32-bit. Neither of the two can be > used to index arrays. Erm... I wasn't talking about the DESIRED state of affairs! I was talking about the CURRENT state of affairs. OK? The fact still remains that most of the places which a have pointed out just need the minor nibble of whatever bits you pass to them. Apparently nobody on this list here blabbering about a new improved minor/major space didn't actually take the time and looked into all those places where the kernel is CURRENTLY replying in minor/major array enumeration. They are TON's of them. The most ugly are RAID drivers an all those MD LVW and whatever stuff as well as abused minor number spaces as replacements of differnt majors. At least you have admitted that you where the one responsible for the design of this MESS. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ECN is on!
Richard Gooch <[EMAIL PROTECTED]> writes: > Sure, Dave is being bloody-minded, but that's the only way we'll see > people get off their fat, lazy asses and fix their broken systems. > In fact, hopefully he's still in a dark mood, and he may take up the > suggestion to bounce mails of the following type: > - MIME encoded > - HTML encoded > - quoted printables (those stupid "=20" things are particuarly hard to > read). MIME is no encoding, but a way to declare mail contents and encode binary data. You need not use it on mail you send. HTML is no encoding. (No doubt it's usually sent by people without A Clue[tm] or being ruthless.) quoted-printable is an encoding, and it's probably around for ten years now. I can send base64 if you like that better, but then, even more people will cry, while others don't even notice. Gnus 5.8 + Emacs, mutt, Netscape Communicator are three packages which deal with MIME-"enhanced" mail. Plus, people which use any characters beyond ASCII have no real choice but to use MIME; if they have MTAs in between that don't talk ESMTP/8BITMIME, then quoted-printable is what happens. Use emil, metamail or such if you want to keep your mailer. -- Matthias Andree - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Gameport analog joystick broken in 2.4.4-ac13
I have an analog joystick plugged into the gameport of a Soundblaster AWE64. In 2.4.4-ac12 this was recognized and worked just fine. Under ac13 the recognition is incomplete - it seems to identify that there is a NS558 gameport device present, but not that there is a joystick plugged into it (unless I'm completely misunderstanding the log messages). Anyway, I've attached the .config for the ac12 kernel - the ac13 kernel is the same except I've enabled ECN. I've also attached the initial log messages for the ac12 and ac13 boots on the machine in question. Stephen Thomas kernel: Linux version 2.4.4-ac12 (root@domain-removed) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #2 Tue May 22 08:28:12 BST 2001 kernel: BIOS-provided physical RAM map: kernel: BIOS-e820: - 0009fc00 (usable) kernel: BIOS-e820: 0009fc00 - 000a (reserved) kernel: BIOS-e820: 000f - 0010 (reserved) kernel: BIOS-e820: 0010 - 0c00 (usable) kernel: BIOS-e820: fec0 - fec01000 (reserved) kernel: BIOS-e820: fee0 - fee01000 (reserved) kernel: BIOS-e820: - 0001 (reserved) kernel: found SMP MP-table at 000f5a10 kernel: hm, page 000f5000 reserved twice. kernel: hm, page 000f6000 reserved twice. kernel: hm, page 000f2000 reserved twice. kernel: hm, page 000f3000 reserved twice. kernel: On node 0 totalpages: 49152 kernel: zone(0): 4096 pages. kernel: zone(1): 45056 pages. kernel: zone(2): 0 pages. kernel: Intel MultiProcessor Specification v1.1 kernel: Virtual Wire compatibility mode. kernel: OEM ID: OEM0 Product ID: PROD APIC at: 0xFEE0 kernel: Processor #0 Pentium(tm) Pro APIC version 17 kernel: Processor #255 Pentium(tm) Pro APIC version 17 kernel: Processor #255 INVALID. (Max ID: 16). kernel: I/O APIC #2 Version 17 at 0xFEC0. kernel: Processors: 2 kernel: Kernel command line: BOOT_IMAGE=s24acp ro root=306 hdc=scsi kernel: ide_setup: hdc=scsi kernel: Initializing CPU#0 kernel: Detected 200.457 MHz processor. kernel: Console: colour VGA+ 132x60 kernel: Calibrating delay loop... 399.76 BogoMIPS kernel: Memory: 191196k/196608k available (933k kernel code, 5024k reserved, 256k data, 196k init, 0k highmem) kernel: Dentry-cache hash table entries: 32768 (order: 6, 262144 bytes) kernel: Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes) kernel: Page-cache hash table entries: 65536 (order: 6, 262144 bytes) kernel: Inode-cache hash table entries: 16384 (order: 5, 131072 bytes) kernel: CPU: L1 I cache: 8K, L1 D cache: 8K kernel: CPU: L2 cache: 256K kernel: Intel machine check architecture supported. kernel: Intel machine check reporting enabled on CPU#0. kernel: CPU: Intel Pentium Pro stepping 09 kernel: Checking 'hlt' instruction... OK. kernel: POSIX conformance testing by UNIFIX kernel: enabled ExtINT on CPU#0 kernel: ESR value before enabling vector: 0004 kernel: ESR value after enabling vector: kernel: ENABLING IO-APIC IRQs kernel: ...changing IO-APIC physical APIC ID to 2 ... ok. kernel: ..TIMER: vector=49 pin1=2 pin2=0 kernel: testing the IO APIC... kernel: kernel: done. kernel: Using local APIC timer interrupts. kernel: calibrating APIC timer ... kernel: . CPU clock speed is 200.4615 MHz. kernel: . host bus clock speed is 66.8201 MHz. kernel: cpu: 0, clocks: 668201, slice: 334100 kernel: CPU0 kernel: mtrr: v1.40 (20010327) Richard Gooch ([EMAIL PROTECTED]) kernel: mtrr: detected mtrr type: Intel kernel: PCI: PCI BIOS revision 2.10 entry at 0xfb210, last bus=0 kernel: PCI: Using configuration type 1 kernel: PCI: Probing PCI hardware kernel: PCI->APIC IRQ transform: (B0,I10,P0) -> 18 kernel: Limiting direct PCI/PCI transfers. kernel: Activating ISA DMA hang workarounds. kernel: isapnp: Scanning for PnP cards... kernel: isapnp: SB audio device quirk - increasing port range kernel: isapnp: AWE32 quirk - adding two ports kernel: isapnp: Card 'Creative SB AWE64 PnP' kernel: isapnp: 1 Plug & Play card detected total kernel: PnP: PNP BIOS installation structure at 0xc00fbee0 kernel: PnP: PNP BIOS version 1.0, entry at f:bf08, dseg at f kernel: Linux NET4.0 for Linux 2.4 kernel: Based upon Swansea University Computer Society NET3.039 kernel: Starting kswapd v1.8 kernel: pty: 256 Unix98 ptys configured kernel: gameport0: NS558 PnP at 0x200 size 8 speed 710 kHz kernel: input0: Analog 4-axis 4-button joystick at gameport0.0 [TSC timer, 200 MHz clock, 1545 ns res] kernel: Real Time Clock Driver v1.10d ... kernel: Linux version 2.4.4-ac13 (root@domain-removed) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 Tue May 22 18:51:35 BST 2001 kernel: BIOS-provided physical RAM map: kernel: BIOS-e820: - 0009fc00 (usable) kernel:
Re: [PATCH] struct char_device
Martin Dalecki writes: > I fully agree with you. Good. Unfortunately I do not fully agree with you. > Most of the places where there kernel is passing kdev_t > would be entierly satisfied with only the knowlendge of > the minor number. My kdev_t is a pointer to a structure with device data and device operations. Among the operations a routine that produces a name. Among the data, in the case of a block device, the size, and the sectorsize, .. A minor gives no name, and no data. Linus' minor is 20-bit if I recall correctly. My minor is 32-bit. Neither of the two can be used to index arrays. Andries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Xircom RealPort versus 3COM 3C3FEM656C
In article <[EMAIL PROTECTED]> you wrote: > On Tue, 22 May 2001 20:10:41 +0100 (BST), Alan Cox <[EMAIL PROTECTED]> wrote: >> Before you give up on the xircom thing, try the -ac kernel and set the box >> up to use xircom_cb not xircom_tulip_cb >> >> That might help a lot > It doesn't, it still performs poorly with any of the three available > drivers -- xircom_cb, xircom_tulip_cb, and tulip_cb (from the pcmcia package): > * Rx gets only about 1.8Mbit/s on a 100Base-TX network with any of the three > * Tx gets 80+Mb/s with xircom_tulip_cb and tulip_cb, and less than 30Mb/s > with xircom_cb. This sounds like a bug I have heard before: some switches don't work with the xircom card (well, our drivers for it) when doing full duplex. Could you try the latest driver from http://people.redhat.com/arjanv which forces the card to half-duplex? I manage to get 8Mbyte/sec with it without any problems. Greetings, Arjan van de Ven - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linux 2.4.4-ac14
ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/ Intermediate diffs are available from http://www.bzimage.org Rather than starting to propogate these fixes to other drivers I'd be greatful if they would audit the changes (especially the sound one) carefully. That way we can ripple correct changes to the other drivers rather than duplicating several rounds of fixes into each driver we touch 2.4.4-ac14 o Fix error corner case on max file size check(Andrew Morton) o Do first bits of applicom.c cleanup (me) | This needs a lot of cleaning yet o Fix open/close locking on dsp56k(me) o Clean up the obvious namespace mess in h8.c (me) | Wants verifying by Alpha folks o Fix locking errors in machzwd watchdog (me) o Fix printk levels on nwflush , someone with a (me) netwindup needs to see the FIXME cases still o Fix out of memory oops in pcwd.c(me) o Add more Dell raid devices to sparselun table (Matt Domsch) o Add hotplug table entry for aic7xxx (Marcus Meissner) o Drop deceased APA1480 driver to match Linus tree(me) o Fix ali15x3 nodma behaviour (Jeff Garzik) o Further quota fixups(Jan Kara) o Update a2232 to current version (Geert Uytterhoeven) | Older one got merged in error.. o Clean up sonicvibes pci handling(Marcus Meissner) o Remove dead radio miscdevice bits (Al Viro) o Merge ATI Rage XL console support (Geert Uytterhoeven) o Fix problems with pyxis iommu on Alpha (Ivan Kokshaysky) o Fix compile errors when built without /proc (Andrzej Krzysztofowicz) o Encapsulate shmem inode info using macros (Christoph Rohland) | So Al can attack the inode struct.. o Move small symlinks into shmem_inode_info (Christoph Rohland) o Count shmemfs pages and put them in /proc (Christoph Rohland) o Put back accidentally reverted PnPBIOS parport (Marcelo Jimenez) 2.4.4-ac13 o Fix binfmt_misc compile bug (me) o Add missing locking to pms driver (me) o Fix planb locking/rt deadlock (me) o Add missing locking to saa5249 driver (me) o Add missing locking to stradis driver (me) o Add missing locking to zr36067 driver (me) o Fix locking on trident sound driver (me) | Probably all the other PCI sound drivers need doing too... o Fix wrong ioctl return on trident sound driver (me) o Clean up NCR53c406 compile warnings (me) o Fix dmx3191 compile warnings, printk levels (me) o Fix coda cache compile warnings (me) o Fix a warning in jffs2 (me) o Fix nautilus SRM poweroff (Richard Henderson) o Fix Alpha build bug (Richard Henderson) o Fix a hang in the maestro dock support (Ben Pfaff) o Fix memory leak in ACPI drivers (Philip Wang) o Eliminate popping in cs46xx, fix powerdown (Tom Woller) o Fix ps2esdi SMP build (Rasmus Andersen) o Fix a hang on NFS write (Trond Myklebust) o Cleaned up assorted random warnings (me) 2.4.4-ac12 o Just tracking Linus 2.4.5pre4 - A chunk more merged with Linus - dropped out some oddments that are now obsolete 2.4.4-ac11 o Fix hang after "Freeing unused.." on S/390 (Dick Hitt) o Fix ramfs accounting bug(Christoph Rohland) o Raw HID access interface for USB(Brad Hards) o Fix missing release_region on QlogicFAS (Marcus Meissner) o Fix missing release region in NCR53c406 code(Marcus Meissner) o Make trident use the new pm callbacks (Pavel Roskin) o Fix dmi ident handling (Arjan van de Ven) o dc2xx locking fixes (Greg Kroah-Hartmann) o Fix overrun on the acm driver (Greg Kroah-Hartmann) o Sitecom workarounds for mct-u232(Stelian Pop) o Makefile fixes (Al Viro) o Make hgafb show logo if non modular only like (me) the rest o Merge back the invalidate_device changes into (me) the new cciss/cpqarray o Rio and sx serial driver updates(Rogier Wolff) o Add another SB AWE 32 variant to the tables (Jeremy Manson) o Fix serial.c warning(Jesper Juhl) o Basic maestro dock
Re: alpha iommu fixes
At 10:24 PM +0100 2001-05-22, Alan Cox wrote: > > On the main board, and not just the old ones. These days it's >> typically in the chipset's south bridge. "Third-party DMA" is >> sometimes called "fly-by DMA". The ISA card is a slave, as is memory, >> and the DMA chip reads from one ands writes to the other. > >There is also another mode which will give the Alpha kittens I suspect. A >few PCI cards do SB emulation by snooping the PCI bus. So the kernel writes >to the ISA DMA controller which does a pointless ISA transfer and the PCI >card sniffs the DMA controller setup (as it goes to pci, then when nobody >claims it on to the isa bridge) then does bus mastering DMA of its own to fake >the ISA dma That's sick. -- /Jonathan Lundell. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Xircom RealPort versus 3COM 3C3FEM656C
On Tue, 22 May 2001 20:10:41 +0100 (BST), Alan Cox <[EMAIL PROTECTED]> wrote: > Before you give up on the xircom thing, try the -ac kernel and set the box > up to use xircom_cb not xircom_tulip_cb > > That might help a lot It doesn't, it still performs poorly with any of the three available drivers -- xircom_cb, xircom_tulip_cb, and tulip_cb (from the pcmcia package): * Rx gets only about 1.8Mbit/s on a 100Base-TX network with any of the three * Tx gets 80+Mb/s with xircom_tulip_cb and tulip_cb, and less than 30Mb/s with xircom_cb. And no, promisc mode played no role in this experiment, because my test network is switched and otherwise very quiet. Windows drivers handle both Rx and Tx at full speed. I have this feeling that we're handling the card in some (tulip) compat mode, which severely cripples performance. It's hard to tell, without docs... Ion -- It is better to keep your mouth shut and be thought a fool, than to open it and remove all doubt. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: alpha iommu fixes
At 2:02 PM -0700 2001-05-22, Richard Henderson wrote: >On Tue, May 22, 2001 at 01:48:23PM -0700, Jonathan Lundell wrote: >> 64KB for 8-bit DMA; 128KB for 16-bit DMA. [...] This doesn't >> apply to bus-master DMA, just the legacy (8237) stuff. > >Would this 8237 be something on the ISA card, or something on >the old pc mainboards? I'm wondering if we can safely ignore >this issue altogether here... On the main board, and not just the old ones. These days it's typically in the chipset's south bridge. "Third-party DMA" is sometimes called "fly-by DMA". The ISA card is a slave, as is memory, and the DMA chip reads from one ands writes to the other. IDE didn't originally use DMA at all (but floppies did), just programmed IO. These days, PC chipsets mostly have some form of extended higher-performance DMA facilities for stuff like IDE, but I'm not really familiar with the details. I do wish Linux didn't have so much PC legacy sh^Htuff embedded into the i386 architecture. > > There was also a 24-bit address limitation. > >Yes, that's in the number of address lines going to the isa card. >We work around that one by having an iommu arena from 8M to 16M >and forcing all ISA traffic to go through there. -- /Jonathan Lundell. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] struct char_device
[EMAIL PROTECTED] wrote: > > > They are entirely different. Too different sets of operations. > > Maybe you didnt understand what I meant. > both bdev and cdev take care of the correspondence > device number <---> struct with operations. > > The operations are different, but all bdev/cdev code is identical. > > So the choice is between two uglies: > (i) have some not entirely trivial amount of code twice in the kernel > (ii) have a union at the point where the struct operations > is assigned. > > I preferred the union. > > >> And a second remark: don't forget that presently the point where > >> bdev is introduced is not quite right. We must only introduce it > >> when we really have a device, not when there only is a device > >> number (like on a mknod call). > > > That's simply wrong. kdev_t is used for unopened objects quite often. > > Yes, but that was my design mistake in 1995. I fully agree with you. Most of the places where there kernel is passing kdev_t would be entierly satisfied with only the knowlendge of the minor number used to distinguish between different device ranges, which is BTW an abuse by itself as well since minors where for encounters of instances of similiar devices in linux... The places where this is the case are namely: 1. literally: all character devices. 2. The whole scsi stuff. 3. most of the ide stuff. 4. md/lvm and similiar culprits. I did "discover" this by splitting the i_dev field from stuct inode into explicit i_minor and i_major fields and then actually "fixing" my particular kernel configuration until it worked again. This was *very* insigtfull, since it discovered all the places where kdev_t get's used, where it shouldn't be of any need anylonger anyway. The remaining places where kdev_t comes into sight are mostly the places where the kernel is mounting the initial root device. In case you would like to have a look at the resulting bit huge patch I can send it to you... > I think you'll find if you continue on this way, > as I found and already wrote in kdev_t.h > that it is bad to carry pointers around for unopened and unknown devices. > > So, I think that the setup must be changed a tiny little bit > and distinguish meaningless numbers from devices. > > Andries > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- - phone: +49 214 8656 283 - job: eVision-Ventures AG, LEV .de (MY OPINIONS ARE MY OWN!) - langs: de_DE.ISO8859-1, en_US, pl_PL.ISO8859-2, last ressort: ru_RU.KOI8-R - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Speeding up VFS using HW assist
Hello All, I will be using Linux as the OS for an embedded system. I was looking into 2.4.4 kernel code and saw the dcache implementation in VFS which is pretty neat and fast by itself. My question is, will I gain any considerable efficiency in file system access if I can move this "pathname -> inode" lookup into some proprietery HW assist mechanism and take out the dcache hashing and "cached_lookup" function. How good(bad) was it before the dcache implementation and in which release was dcache feature added (was it only after 2.2.x release). Did we get 2-3 times better performance with dcache? (if not, how much?) Can anyone suggest any other place in the file system (VFS and EXT2) where we can use any HW assist (let us say FPGA implementing search, lookup, etc.) to speed up file-system access (both for opening and read/write) Would tweaking the buffer cache and page cache sizes make a considerable effect on efficiency? Any other suggestions? Thanks a lot, Bharath - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: alpha iommu fixes
> On Tue, May 22, 2001 at 05:00:16PM +0200, Andrea Arcangeli wrote: > > I'm also wondering if ISA needs the sg to start on a 64k boundary, > Traditionally, ISA could not do DMA across a 64k boundary. The ISA dmac on the x86 needs a 64K boundary (128K for 16bit) because it did not carry the 16 bit address to the top latch byte. > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: scheduling callbacks in user space triggered via kernel....
> Is there a method to schedule user mode code from kernel agent?
You can wake user processes,send them signals etc but ingeneral its not
a good idea
> registers with the kernel mode agent with a function/parm to run, then when
> the callback is appropriate the kerenl agent triggers this callback to
> happen.
The unix model is much more that the app does
while(1)
{
get_event(fd);
switcH(event)
{
..
...
}
}
> or a method to bind a function to a file handle, when there is Completed IO,
> the kernel would call the registered function with a parameter of the buffer
> submitted for IO.
The b_end_io callback can possibly be used, or Ben's asynchronosu callbacks,
but that deals with kernel level completion.
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: alpha iommu fixes
> ISA cards can do sg? AHA1542 scsi for one. It wasnt that uncommon. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: alpha iommu fixes
Hi! > > > [..] Even sparc64's fancy > > > iommu-based pci_map_single() always succeeds. > > > > Whatever sparc64 does to hide the driver bugs you can break it if you > > pci_map 4G+1 bytes of phyical memory. > > Which is an utterly stupid thing to do. > > Please construct a plausable situation where this would occur legally > and not be a driver bug, given the maximum number of PCI busses and > slots found on sparc64 and the maximum _concurrent_ usage of PCI dma > space for any given driver (which isn't doing something stupid). What stops you from plugging PCI-to-PCI bridges in order to create some large number of slots, like 128? Pavel -- I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: no ioctls for serial ports? [was Re: LANANA: To Pending Device Num
Hi! > > I've seen this question several times in this thread. I haven't seen the > > obvious answer, though. > > > > Have a new system call: > > > > ctlfd = open_device_control_fd(fd); > > > > If fd is something that doesn't have a control interface (say, it already > > is a control filehandle), this returns an appropriate error code. > > It may have several. Which one? > > FWIW, I think that mixing network and device ioctls is a bad idea. These > groups are very different and we'd be better off dealing with changes in > them separately. > > For devices... I'd say that fpath(2) (same type as getcwd(2)) would be > a good way to deal with that. Or fpath(3) - implemented via readlink(2) > on /proc/self/fd/. fpath is *wrong* solution, and extremely ugly. stty 115200 < /dev/ttyS0 & rm /dev/ttyS0 or even worse stty 115200 < /dev/ttyS0 & ln -s /dev/ttyS1 /dev/ttyS0 What I'm trying to show is that with fpath you can no longer delete open devices and continue to work with them. I really think that open_sub(fd, "control") is right solution. Pavel -- I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: alpha iommu fixes
On Tue, May 22, 2001 at 01:48:23PM -0700, Jonathan Lundell wrote: > 64KB for 8-bit DMA; 128KB for 16-bit DMA. [...] This doesn't > apply to bus-master DMA, just the legacy (8237) stuff. Would this 8237 be something on the ISA card, or something on the old pc mainboards? I'm wondering if we can safely ignore this issue altogether here... > There was also a 24-bit address limitation. Yes, that's in the number of address lines going to the isa card. We work around that one by having an iommu arena from 8M to 16M and forcing all ISA traffic to go through there. r~ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] struct char_device
> They are entirely different. Too different sets of operations. Maybe you didnt understand what I meant. both bdev and cdev take care of the correspondence device number <---> struct with operations. The operations are different, but all bdev/cdev code is identical. So the choice is between two uglies: (i) have some not entirely trivial amount of code twice in the kernel (ii) have a union at the point where the struct operations is assigned. I preferred the union. >> And a second remark: don't forget that presently the point where >> bdev is introduced is not quite right. We must only introduce it >> when we really have a device, not when there only is a device >> number (like on a mknod call). > That's simply wrong. kdev_t is used for unopened objects quite often. Yes, but that was my design mistake in 1995. I think you'll find if you continue on this way, as I found and already wrote in kdev_t.h that it is bad to carry pointers around for unopened and unknown devices. So, I think that the setup must be changed a tiny little bit and distinguish meaningless numbers from devices. Andries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]device arguments from lookup)
Andreas, I think that the issue is something different. Suppose the snapshot has been created. I know that this can be done safely with the API's you allude to. Life goes on and the journal FS keeps changing the file system and if the system doesn't crash, everything is fine: blocks get copied correctly from the primary volume to the snapshot volume. Now consider a crash -- not during snapshot creation, but way after that when "life is going on". Suppose there is a two block transaction that has made it to the journal and after writing one block to the fs location the system crashes. The journal replay will try to write that block again. But during recovery, LVM cannot possibly know if the whole process of copying out the data from the current to the snapshot area completed during the previous run. Yes, LVM updates the redirection table first and then copies, but, still, you don't know _where exactly_ the writes stopped happening and in particular you don't know if the block was copied already or not. So during replay it is quite possible that LVM corrupts the snapshot. It's better to keep the snapshot in the old volume and write the new data to a separate area (that's what most commercial systems do I think). It avoid redirections and copying upon write. When you delete the snapshot you have to copy, but you can do that as a low priority process. Finally, as you pointed out a full volume is handled better too in that way, since you don't terminate the snapshot but you tell the current volume that it is full. Hmm, I was expecting a storm of email explaining what I have misunderstood, but it has in fact been rather quiet... - Peter - On Tue, 22 May 2001, Andreas Dilger wrote: > Peter Braam writes: > > On Tue, 22 May 2001, Andreas Dilger wrote: > > > Actually, the LVM snapshot > > > interface has (optional) hooks into the filesystem to ensure that it > > > is consistent at the time the snapshot is created. > > > > File system journal recovery can corrupt a snapshot, because it copies > > data that needs to be preserved in a snapshot. During journal replay such > > data may be copied again, but the source can have new data already. > > The way it is implemented in reiserfs is to wait for existing transactions > to complete, entirely flush the journal and block all new transactions from > starting. Stephen implemented a journal flush API to do this for ext3, but > the hooks to call it from LVM are not in place yet. This way the journal is > totally empty at the time the snapshot is done, so the read-only copy does > not need to do journal recovery, so no problems can arise. > > Cheers, Andreas > -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: alpha iommu fixes
On Tue, May 22, 2001 at 04:40:17PM -0400, Jeff Garzik wrote: > ISA cards can do sg? No, but the host iommu can. The isa card sees whatever view of memory presented to it by the iommu. r~ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: alpha iommu fixes
At 1:28 PM -0700 2001-05-22, Richard Henderson wrote: >On Tue, May 22, 2001 at 05:00:16PM +0200, Andrea Arcangeli wrote: >> I'm also wondering if ISA needs the sg to start on a 64k boundary, > >Traditionally, ISA could not do DMA across a 64k boundary. > >The only ISA card I have (a soundblaster compatible) appears >to work without caring for this, but I suppose we should pay >lip service to pedantics. 64KB for 8-bit DMA; 128KB for 16-bit DMA. It's a limitation of the legacy third-party-DMA controllers, which had only 16-bit address registers (the high part of the address lives in a non-counting register). This doesn't apply to bus-master DMA, just the legacy (8237) stuff. There was also a 24-bit address limitation. -- /Jonathan Lundell. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
__alloc_pages: 0-order allocation failed on 2.4.5-pre3
Hi, I searched the lkml for previous reports of this error, and I've found a few questions asked, but no real answer given. I'm not looking for a quick answer, but this just seems to be an issue that hasn't been touched on much. Any thoughts (and solutions) would be greatly appreciated. I'm cc'ing this to previous thread starters and responders. I got the following errors streaming down my console after about 5 days uptime on 2.4.5-pre3. I sent a previous message out regarding the same error on 2.4.3-ac13. Others have reported this same problem on 2.4.4 and 2.4.3 (no mention of series). __alloc_pages: 0-order allocation failed. __alloc_pages: 0-order allocation failed. __alloc_pages: 0-order allocation failed. __alloc_pages: 0-order allocation failed. __alloc_pages: 0-order allocation failed. __alloc_pages: 0-order allocation failed. The system was unresponsive, but sysrq worked for a short while until the above errors kicked in again. The system is rather minimal. The kernel is compiled with SMP (two CPUs) and a 4GB limit to take advantage of the 1GB memory in it. The system has a SCSI disk subsystem (Adaptec 2940 + 3 uw-scsi drives), a 3c905b nic, and a cheap video card. The workload it handles is ~120 Apache processes (~5MB/process) and ~20 mysql threads (256MB keycache + ~5MB/thread). -- Vibol Hou - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Background to the argument about CML2 design philosophy
Jonathan Morton <[EMAIL PROTECTED]>: > I'm going to assume for now that CML2 saves two files - one storing a > relatively small number of symbols (which is strictly limited to those > explicitly set by the user), and one containing the full set for > consumption by the Makefiles. No, that's not the case. Would it be too much to ask that you learn how the existing language works brfore proposing improvements? -- http://www.tuxedo.org/~esr/;>Eric S. Raymond The prestige of government has undoubtedly been lowered considerably by the Prohibition law. For nothing is more destructive of respect for the government and the law of the land than passing laws which cannot be enforced. It is an open secret that the dangerous increase of crime in this country is closely connected with this. -- Albert Einstein, "My First Impression of the U.S.A.", 1921 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: alpha iommu fixes
On Tue, May 22, 2001 at 05:00:16PM +0200, Andrea Arcangeli wrote: > I'm also wondering if ISA needs the sg to start on a 64k boundary, Traditionally, ISA could not do DMA across a 64k boundary. The only ISA card I have (a soundblaster compatible) appears to work without caring for this, but I suppose we should pay lip service to pedantics. r~ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
USB crash in all kernels >2.4.3
Hi, I have discovered that my previous problem with immediate lockups of all kernels versioon >2.4.3 is USB and/or sound-related. My computer currently has onte internal soundcard (awe64) that is not used, and an external USB D/A. Playing a sound with the internal soundcard (cat whatever > /dev/sound0) works beautifully, but the same cat to /dev/audio2 (the external D/A) locks up the system completely without any trace in the logs. I hope someone has an idea what happened between 2.4.3 and 2.4.4 that could cause this. The latest kernel I tried is 2.4.5-pre5. dmesg and .config is attached to this mail. Cheers, //jb erved) BIOS-e820: fee0 - fee01000 (reserved) BIOS-e820: - 0001 (reserved) Scan SMP from c000 for 1024 bytes. Scan SMP from c009fc00 for 1024 bytes. Scan SMP from c00f for 65536 bytes. found SMP MP-table at 000f6e80 hm, page 000f6000 reserved twice. hm, page 000f7000 reserved twice. hm, page 000f6000 reserved twice. hm, page 000f7000 reserved twice. On node 0 totalpages: 131069 zone(0): 4096 pages. zone(1): 126973 pages. zone(2): 0 pages. Intel MultiProcessor Specification v1.4 Virtual Wire compatibility mode. OEM ID: OEM0 Product ID: PROD APIC at: 0xFEE0 Processor #1 Pentium(tm) Pro APIC version 17 Floating point unit present. Machine Exception supported. 64 bit compare & exchange supported. Internal APIC present. SEP present. MTRR present. PGE present. MCA present. CMOV present. PAT present. PSE present. MMX present. FXSR present. Bootup CPU Processor #0 Pentium(tm) Pro APIC version 17 Floating point unit present. Machine Exception supported. 64 bit compare & exchange supported. Internal APIC present. SEP present. MTRR present. PGE present. MCA present. CMOV present. PAT present. PSE present. MMX present. FXSR present. Bus #0 is PCI Bus #1 is PCI Bus #2 is ISA I/O APIC #2 Version 17 at 0xFEC0. Int: type 3, pol 0, trig 0, bus 2, IRQ 00, APIC ID 2, APIC INT 00 Int: type 0, pol 0, trig 0, bus 2, IRQ 01, APIC ID 2, APIC INT 01 Int: type 0, pol 0, trig 0, bus 2, IRQ 00, APIC ID 2, APIC INT 02 Int: type 0, pol 0, trig 0, bus 2, IRQ 03, APIC ID 2, APIC INT 03 Int: type 0, pol 0, trig 0, bus 2, IRQ 04, APIC ID 2, APIC INT 04 Int: type 0, pol 0, trig 0, bus 2, IRQ 05, APIC ID 2, APIC INT 05 Int: type 0, pol 0, trig 0, bus 2, IRQ 06, APIC ID 2, APIC INT 06 Int: type 0, pol 0, trig 0, bus 2, IRQ 07, APIC ID 2, APIC INT 07 Int: type 0, pol 0, trig 0, bus 2, IRQ 08, APIC ID 2, APIC INT 08 Int: type 0, pol 0, trig 0, bus 2, IRQ 0c, APIC ID 2, APIC INT 0c Int: type 0, pol 0, trig 0, bus 2, IRQ 0e, APIC ID 2, APIC INT 0e Int: type 0, pol 0, trig 0, bus 2, IRQ 0f, APIC ID 2, APIC INT 0f Int: type 0, pol 3, trig 3, bus 1, IRQ 00, APIC ID 2, APIC INT 10 Int: type 0, pol 3, trig 3, bus 0, IRQ 13, APIC ID 2, APIC INT 13 Int: type 0, pol 3, trig 3, bus 0, IRQ 28, APIC ID 2, APIC INT 12 Int: type 0, pol 3, trig 3, bus 0, IRQ 2c, APIC ID 2, APIC INT 11 Int: type 0, pol 3, trig 3, bus 0, IRQ 30, APIC ID 2, APIC INT 10 Lint: type 3, pol 1, trig 1, bus 2, IRQ 00, APIC ID ff, APIC LINT 00 Lint: type 1, pol 1, trig 1, bus 2, IRQ 00, APIC ID ff, APIC LINT 01 Processors: 2 mapped APIC to e000 (fee0) mapped IOAPIC to d000 (fec0) Kernel command line: auto BOOT_IMAGE=Linux ro root=301 Initializing CPU#0 Detected 400.917 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 799.53 BogoMIPS Memory: 512384k/524276k available (1582k kernel code, 11504k reserved, 637k data, 208k init, 0k highmem) Dentry-cache hash table entries: 65536 (order: 7, 524288 bytes) Buffer-cache hash table entries: 32768 (order: 5, 131072 bytes) Page-cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 32768 (order: 6, 262144 bytes) VFS: Diskquotas version dquot_6.4.0 initialized CPU: Before vendor init, caps: 0183fbff , vendor = 0 CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 512K Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU: After vendor init, caps: 0183fbff CPU: After generic, caps: 0183fbff CPU: Common caps: 0183fbff Enabling fast FPU save and restore... done. Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.40 (20010327) Richard Gooch ([EMAIL PROTECTED]) mtrr: detected mtrr type: Intel CPU: Before vendor init, caps: 0183fbff , vendor = 0 CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 512K Intel machine check reporting enabled on CPU#0. CPU: After vendor init, caps: 0183fbff CPU: After generic, caps: 0183fbff CPU: Common caps: 0183fbff CPU0: Intel Pentium II (Deschutes) stepping 03
Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]device arguments from lookup)
On Tuesday 22 May 2001 19:49, Oliver Xymoron wrote: > On Tue, 22 May 2001, Daniel Phillips wrote: > > > I don't think it's likely to be even workable. Just consider the > > > directory entry for a moment - is it going to be marked d or > > > [cb]? > > > > It's going to be marked 'd', it's a directory, not a file. > > Are we talking about the same proposal? The one where I can open > /dev/dsp and /dev/dsp/ctl? But I can still do 'cat /dev/hda > > /dev/dsp'? We already support read/write on directories in the VFS, that's not a problem. > It's still a file. If it's not a file anymore, it ain't UNIX. It's a file with the directory bit set, I believe that's UNIX. > > > If it doesn't have the directory bit set, Midnight commander > > > won't let me look at it, and I wouldn't blame cd or ls for > > > complaining. If it does have the 'd' bit set, I wouldn't blame > > > cp, tar, find, or a million other programs if they did the wrong > > > thing. They've had 30 years to expect that files aren't > > > directories. They're going to act weird. > > > > No problem, it's a directory. > > > > > Linus has been kicking this idea around for a couple years now > > > and it's still a cute solution looking for a problem. It just > > > doesn't belong in UNIX. > > > > Hmm, ok, do we still have any *technical* reasons? > > If you define *technical* to not include design, sure. Sorry, I don't see what you mean, do you mean the design is difficult? > Oh, did I mention unnecessary, solvable in userspace? That's exactly the point: the generic filesystem allows all the funny-shaped stuff to be dealt with in user space. The filesystem itself is lovely and clean. BTW, I didn't realize I was reinventing Linus's wheel, this just seemed very obvious and natural to me. So I had to believe there's a technical obstacle somewhere. Has anyone written code to demonstrate the idea? -- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
scheduling callbacks in user space triggered via kernel....
Hello Gurus... Is there a method to schedule user mode code from kernel agent? basically think that when some work is to be scheduled in user mode, the app registers with the kernel mode agent with a function/parm to run, then when the callback is appropriate the kerenl agent triggers this callback to happen. I can think of either using a shared buffer to communicate between kernel/user space and use a dedicated thread to do this task. But i would keep a page pinned for each process, and this may be limiting... are there any examples of code in kernel that would do this? if someone would not beat me up. for quoting this... windows 2000 offers 2 such facilities. (APC or async procedure calls) where a thread can block and when ready will be woken via the kernel agent and can run a user supplied function. or a method to bind a function to a file handle, when there is Completed IO, the kernel would call the registered function with a parameter of the buffer submitted for IO. any ideas would be greatly appreciated. ashokr - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel diff_small_2.4.5pre4_2.4.5pre5
On Tue, May 22, 2001 at 10:04:39PM +0200, Andrea Arcangeli wrote:
> diff -urN 2.4.5pre4/arch/alpha/kernel/pci_iommu.c
>2.4.5pre5/arch/alpha/kernel/pci_iommu.c
> --- 2.4.5pre4/arch/alpha/kernel/pci_iommu.c Sun Apr 1 01:17:07 2001
> +++ 2.4.5pre5/arch/alpha/kernel/pci_iommu.c Tue May 22 22:04:07 2001
> @@ -402,8 +402,20 @@
> paddr &= ~PAGE_MASK;
> npages = calc_npages(paddr + size);
> dma_ofs = iommu_arena_alloc(arena, npages);
> - if (dma_ofs < 0)
> - return -1;
> + if (dma_ofs < 0) {
> + /* If we attempted a direct map above but failed, die. */
> + if (leader->dma_address == 0)
> + return -1;
> +
> + /* Otherwise, break up the remaining virtually contiguous
> +hunks into individual direct maps. */
> + for (sg = leader; sg < end; ++sg)
> + if (sg->dma_address == 2 || sg->dma_address == -2)
> + sg->dma_address = 0;
> +
> + /* Retry. */
> + return sg_fill(leader, end, out, arena, max_dma);
> + }
>
> out->dma_address = arena->dma_base + dma_ofs*PAGE_SIZE + paddr;
> out->dma_length = size;
this is just broken as I said a few hours ago on l-k. please replace ==
2 with == 1 as described in earlier email. However it's not a
showstopper because it will trigger only after running of pci mappings
(and by that time things are going to break pretty soon anyways on the
much bigger than 2G boxes, where the 2G direct window has low probablity
to save you), the fact I found this patch in in I assume is your
agreemnt that the pci mapping bugs are an issue also for 2.4, good.
I couldn't hack all the day long today, I will finish the alpha updates
before tomorrow though.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] struct char_device
On Tue, 22 May 2001 [EMAIL PROTECTED] wrote: > One remark, repeating what I wrote on some web page: > - > A struct block_device provides the connection between a device number > and a struct block_device_operations. > ... > Clearly, we also want to associate a struct char_device_operations > to a character device number. When we do this, all bdev code will They are entirely different. Too different sets of operations. > have to be duplicated for cdev, so there seems no point in having > bdev code - kdev, for both bdev and cdev, seems more elegant. > - Not really. For struct block_device you have partitioning stuff sitting nearby. It should be handled by generic code. Nothing of that kind for character devices. But the main point is that for block devices ->read() and ->write() do not belong to the natural interface. Request queue does. They are about as far from each other as from FIFOs and sockets. > And a second remark: don't forget that presently the point where > bdev is introduced is not quite right. We must only introduce it > when we really have a device, not when there only is a device > number (like on a mknod call). That's simply wrong. kdev_t is used for unopened objects quite often. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] struct char_device
Alexander Viro writes: > patch below adds the missing half of kdev_t - > for block devices we already have a unique pointer > and that adds a similar animal for character devices. Very good. (Of course I did precisely the same, but am a bit slower in submitting things during a stable series or code freeze.) One remark, repeating what I wrote on some web page: - A struct block_device provides the connection between a device number and a struct block_device_operations. ... Clearly, we also want to associate a struct char_device_operations to a character device number. When we do this, all bdev code will have to be duplicated for cdev, so there seems no point in having bdev code - kdev, for both bdev and cdev, seems more elegant. - And a second remark: don't forget that presently the point where bdev is introduced is not quite right. We must only introduce it when we really have a device, not when there only is a device number (like on a mknod call). Andries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] struct char_device
On Tue, 22 May 2001, Guest section DW wrote: > On Tue, May 22, 2001 at 11:08:16AM -0500, Oliver Xymoron wrote: > > > > >+ struct list_headhash; > > > > Why not name consistently with the struct block_device? > > > struct list_headcd_hash; > > > Because foo_ is a throwback to the days when C compilers had a single > > namespace for all structure elements, not a readability aid. If you need > > foo_ to know what type of structure you're futzing with, you need to name > > your variables better. > > One often has to go through all occurrences of a variable or > field of a struct. That is much easier with cd_hash and cd_dev > than with hash and dev. > > No, it is a good habit, these prefixes, even though it is no longer > necessary because of the C compiler. A better habit is encapsulating your data structures well enough that the entire kernel doesn't feel the need to go digging through them. The fact that you have to change many widely-scattered instances of something points to bad modularity. Supporting that practice with verbose naming is not doing yourself a favor in the long run. If you must, use accessor functions instead. At best you'll be able to make sweeping semantic changes in one spot. At worst, you'll be able to grep for it. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Xircom RealPort versus 3COM 3C3FEM656C
On Tue, 22 May 2001, Alan Cox wrote: > > I currently have three Xircom RealPort Carbus modem/fast ethernet cards. > > The current driver blows major chunks (it has very poor performance, and > > stops working under load). I'm told the driver issues are because of > > hardware issues. The really nice feature of this card is the form factor > > though. > > Before you give up on the xircom thing, try the -ac kernel and set the box > up to use xircom_cb not xircom_tulip_cb > > That might help a lot Note that the reason why xircom_cb for all cases is that it sets the card into promisc mode, in all cases. This punishes your CPU and laptop battery on a loaded network. Promisc mode is required because (AFAIK) Xircoms under the same PCI id can use any one of three setup frame formats, and only one format is known. So, you are right, xircom_cb will help a lot in most cases, but the hardware sucks. I recommend avoiding it... Jeff P.S. If anybody knows Xircom engineers, we would love a tech contact... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] s_maxbytes handling
Linus writes: 0 is EOF _for_reads_. For writes it is not very well defined Hmm. So -EFBIG is certainly the preferable return value, Yes. The Austin 6th draft writes EFBIG: An attempt was made to write a file that exceeds the implementation-defined maximum file size or the process' file size limit, and there was no room for any bytes to be written. Andries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] struct char_device
On Tue, 22 May 2001, Guest section DW wrote: > One often has to go through all occurrences of a variable or > field of a struct. That is much easier with cd_hash and cd_dev > than with hash and dev. > > No, it is a good habit, these prefixes, even though it is no longer > necessary because of the C compiler. True, except for the stuff that should remain local. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] struct char_device
On Tue, May 22, 2001 at 11:08:16AM -0500, Oliver Xymoron wrote: > > >+ struct list_headhash; > > Why not name consistently with the struct block_device? > > struct list_headcd_hash; > Because foo_ is a throwback to the days when C compilers had a single > namespace for all structure elements, not a readability aid. If you need > foo_ to know what type of structure you're futzing with, you need to name > your variables better. One often has to go through all occurrences of a variable or field of a struct. That is much easier with cd_hash and cd_dev than with hash and dev. No, it is a good habit, these prefixes, even though it is no longer necessary because of the C compiler. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]device arguments from lookup)
On Tue, 22 May 2001, Linus Torvalds wrote: > > On Tue, 22 May 2001, Andreas Dilger wrote: Actually, the LVM snapshot > interface has (optional) hooks into the filesystem to ensure that it > is consistent at the time the snapshot is created. But I think that LVM is implemented "the wrong way around". File system journal recovery can corrupt a snapshot, because it copies data that needs to be preserved in a snapshot. During journal replay such data may be copied again, but the source can have new data already. Most LVM snapshot systems write the new data in the separate volume and don't copy the old data that eliminates this problem (and also eliminates the copy of data but introduces data copy when a snapshot is removed). - Peter - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Xircom RealPort versus 3COM 3C3FEM656C
> I currently have three Xircom RealPort Carbus modem/fast ethernet cards. > The current driver blows major chunks (it has very poor performance, and > stops working under load). I'm told the driver issues are because of > hardware issues. The really nice feature of this card is the form factor > though. Before you give up on the xircom thing, try the -ac kernel and set the box up to use xircom_cb not xircom_tulip_cb That might help a lot - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Xircom RealPort versus 3COM 3C3FEM656C
I currently have three Xircom RealPort Carbus modem/fast ethernet cards. The current driver blows major chunks (it has very poor performance, and stops working under load). I'm told the driver issues are because of hardware issues. The really nice feature of this card is the form factor though. 3COM has a new card that has a form factor like the Xircom RealPort. It is the 3C3FEM656C card. You and find information about it here: http://www.3com.com/products/en_US/detail.jsp?pathtype=purchase=features=3C3FEM656C I've been unable to find information about Linux support for this 3COM card. Is the modem a win modem, or a regular modem? Is there any planned support for this 3COM card? Dax - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]device arguments from lookup)
On Tue, 22 May 2001, Andreas Dilger wrote: > > Actually, the LVM snapshot interface has (optional) hooks into the filesystem > to ensure that it is consistent at the time the snapshot is created. Note that this is still fundamentally a broken interface: the filesystem may not _have_ a block device underneath it, yet you might very well like to do defragmentation and backup none-the-less. Also, lvm snapshots are fundamentally limited to read-only data, which means that the LVM interfaces cannot be used for defragmentation and lazy fsck etc anyway. You _have_ to do those at a filesystem level. disk snapshots are useful, but they are not the answer. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Changes in Kernel
On Tue, 22 May 2001, Alan Cox wrote: > Are there specific reasons you cannot just use the existing ioctls to load > fonts ? The console driver already supports Klingon for example. > > What are the issues - writing right - left ? No, but in some scripts [devanagari anyway] you only ever write a vowel as a letter if it's at the front of the word: otherwise vowels are added as sort of 'accents' to the consonants, plus there are letters that sometimes smoosh together if they are next to one another, iirc, and long and short forms for each vowel, and each accent-form, plus there are other idiosyncrasies... There seems to be kanji console thing called kon, looking at the package, it looks like it's implemented in userspace - perhaps a similar approach would be fruitful? -- Just one nuclear family can ruin your whole life. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD w/info-PATCH] device arguments from lookup, partion code in userspace
>> What is the communication between user space and kernel >> that transports device identities? > It doesn't change, the same symbolic names still work. But today, unless you think of devfs or so, device identities are not transported by symbolic names. They are given by device numbers. [Yes, symbolic names have a certain secondary role, e.g. in error messages, or perhaps to indicate the boot device.] Andries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: bdflush/mm performance drop-out defect (more info)
On Tue, 22 May 2001, null wrote: > Here is some additional info about the 2.4 performance defect. > > Only one person offered a suggestion about the use of HIGHMEM. I tried > with and without HIGHMEM enabled with the same results. However, it does > appear to take a bit longer to reach performance drop-out condition when > HIGHMEM is disabled. > > The same system degradation also appears when using partitions on a single > internal SCSI drive, but seems to happen only when performing the I/O in > parallel processes. It appears that the load must be sustained long > enough to affect some buffer cache behavior. Parallel dd commands > (if=/dev/zero) also reveal the problem. I still need to do some > benchmarks, but it looks like 2.4 kernels achieve roughly 25% (or less?) > of the throughput of the 2.2 kernels under heavy parallel loads (on > identical hardware). I've also confirmed the defect on a dual-processor > Xeon system with 2.4. The defect exists whether drivers are built-in or > compiled as modules, altho the parallel mkfs test duration improves by as > much as 50% in some cases when using a kernel with built-in SCSI drivers. That's a very interesting observation. May I suggest that the problem may be the driver for your SCSI device? I just ran some tests of parallel I/O on a 2 CPU Intel Pentium III 800 MHz with 2GB main memory, on a single Seagate Barracuda ST336704LWV attached to a AIC7896. The system controller is Intel 440GX. The kernel is 2.4.3-ac7: jwb@windmill:~$ for i in 1 2 3 4 5 6 7 8 9 10; do time dd if=/dev/zero of=/tmp/$i bs=4096 count=25600 & done; This spawns 10 writers of 100MB files on the same filesystem. While all this went on, the system was responsive, and vmstat showed a steady block write of at least 2 blocks/second. Meanwhile this machine also has constantly used mysql and postgresql database systems and a few interactive users. The test completed in 19 seconds and 24 seconds on separate runs. I also performed this test on a machine with 2 Intel Pentium III 933 MHz CPUs, 512MB main memory, an Intel 840 system controller, and a Quantum 10K II 9GB drive attached to an Adaptec 7899P controller, using kernel 2.4.4-ac8. I had no problems there either, and the test completed in 30 seconds (with a nearly full disk). I also didn't see this problem on an Apple Powerbook G4 nor on another Intel machine with a DAC960 RAID. In short, I'm not seeing this problem. Regards, Jeffrey Baker - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Changes in Kernel
Followup to: <[EMAIL PROTECTED]> By author:Alan Cox <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > > We are interested in making some changes to the linux kernel so that it > > supports some indian type fonts on the console... so what are the special > > things that we sould take care of so that our work would be included in > > the kernel-distribution, and how do we proceed about getting it included > > in the distributions? > > Are there specific reasons you cannot just use the existing ioctls to load > fonts ? The console driver already supports Klingon for example. > > What are the issues - writing right - left ? > Indian languages have complicated character/glyph mappings, similar to Arabic but worse. In general, these kinds of things is much better handled in user space, similar to the way Asian languages are handled using the user space console program "kon". You would typically use the frame buffer driver in the kernel and maintain the complicated state machines and glyph sets in user space. -hpa -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] s_maxbytes handling
Linus Torvalds wrote: > [deletia] > > So returning 0 for write() is usually a bad idea - exactly because it > does not have very well-defined semantics. So -EFBIG is certainly the > preferable return value, and seems to be what SuS wants, too. And what LFS wants too: 2.2.1.27 write() and writev() DESCRIPTION For regular files, no data transfer will occur past the offset maximum established in the open file description associated with fildes. ERRORS These functions will fail if: [EFBIG] The file is a regular file, nbyte is greater than 0 and the starting position is greater than or equal to the offset maximum established in the open file description associated with fildes. Note: This is an additional EFBIG error condition. -- David N. Lombard - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
