Upgrading a 2.2.14-5.0 kernel to 2.2.16-3 kernel
I haven't been able to receive an answer from RedHat on this :o( We have a Dell PowerEdge server runninng RH 6.0 with the RH 2.2.14-5.0 kernel. Now, I am aware there are some security issues with the 2.2.14 kernel, however our Dell server requires the use of the third party MegaTrends RAID driver which is loaded through initrd. Will upgrading the kernel to 2.2.16-3 affect the initrd image? Or will I have to reinstall the initrd image with it? It's particularly important because if the MegaTrend driver isn't correctly installed we will have a dead server! Cheers, Alex. -- Bring on the music and lights! http://www.tahallah.clara.co.uk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: hfs support for blocksize != 512
On Tue, 29 Aug 2000, David A. Gatwood wrote: > Indeed, that's what a VFS layer should do -- abstract away all physical > structure, inodes, etc., leaving only the file abstraction. I've read It does. That leaves caring about the internal structures to fs - you don't want fscked block bitmap on ext2, you've got to protect it yourself. Sorry. > that the BSD-derived OSes have vnode interfaces that are remarkably > similar to what you're describing, i.e. the concept isn't restricted to > RTOSes. That's what had been done. BTW, pure vnode interface leaves all namespace-related race-prevention to fs writer. And they tend to fsck up. "They" include Kirk, so... I wouldn't call it simple. Moreover, tons of the code are duplicated (with slight variations in the set of present bugs) in all filesystems. > Note that I haven't touched the Linux VFS layer since 2.0.xx, so I'm not > in a position to comment on the current state of the code. :-) It got much simpler. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Posix library support in linux
Hi to all, I have raw linux source. i want to compile it along with posix library and a pre-written application which uses posix apis. please tell me where can i find the posix libraries for linux. i am using uClinux for coldfire. thanks for any help mahadev
Re: hfs support for blocksize != 512
On Tue, 29 Aug 2000, Tony Mantler wrote: > (Obligitory disclaimer: QNX is an embedded operating system, both it's > architecture and target market is considerably different from Linux's) > > QNX's filesystem interfaces make it so painfully easy to write a filesystem > that it puts everything else to shame. You can easily write a fully > functioning, race-free, completely coherent filesystem in less than a week, > it's that simple. I'd interject that it's not a very fair comparison between the kernel complexity of an RTOS and a full fledged traditional OS, but go on ;-) > Now, let's say you do an 'ls' on the FOO directory. The FS api would tap > your filesystem on the shoulder and ask "Hey you, what's in the FOO > directory?". Your filesystem would reply "BAR and BAZ". It might also reply with a stat structure, depending on the implementation, but otherwise, yeah, this is a good model to move towards. > So what does it all mean? Basically, if you want hugely complex dentries, > and inodes as big as your head, you can do that. If you don't, more power > to you. It's all entirely contained inside your specific FS code, the FS > api doesn't care one bit. It just asks you for files. Indeed, that's what a VFS layer should do -- abstract away all physical structure, inodes, etc., leaving only the file abstraction. I've read that the BSD-derived OSes have vnode interfaces that are remarkably similar to what you're describing, i.e. the concept isn't restricted to RTOSes. Note that I haven't touched the Linux VFS layer since 2.0.xx, so I'm not in a position to comment on the current state of the code. :-) Later, David - A brief Haiku: Microsoft is bad. It seems secure at first glance. Then you read your mail. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: hfs support for blocksize != 512
I concur with this appraisal from Al Viro. Single threading the VFS is going backwards -- not a good idea. :-) Jeff Alexander Viro wrote: > > On Wed, 30 Aug 2000, Roman Zippel wrote: > > > > > hfs. For example reading from a file might require a read from a btree > > > > file (extent file), with what another file write can be busy with (e.g. > > > > reordering the btree nodes). > > > > > > And? > > > > The point is: the thing I like about Linux is its simple interfaces, it's > > the basic idea of unix - keep it simple. That is true for most parts - the > > basic idea is simple and the real complexity is hidden behind it. But > > that's currently not true for vfs interface, a fs maintainer has to fight > > right now with fscking complex vfs interface and with a possible fscking > > Yes? And it will become simpler if you will put each and every locking > scheme into the API? > > Look: we have Hans with his trees-all-over-the-place + journal. He has a > very legitimate need to protect the internal data structures of Reiserfs > and do it without changing the VFS<->reiserfs interaction whenever he > decides to change purely internal structures. > > We have ext2 with indirect blocks, inode bitmaps and block bitmaps, one > per cylinder group + counters in each cylinder group. Should VFS know > about the internal locking rules? Should it be aware of the fact that > inodes foo and bar belong to the same cylinder group and if we remove them > we will need to protect the bitmap for a while? > > We have FAT32 where we've got a nasty allocation data with rather > interesting locking rules. Should it be protected by VFS? If it should - > well, I have bad news for you: write() on a file will lock the whole > filesystem until write() completes. Don't like it for every fs? Tough, it > will mean that VFS will not protect the thing and fs will have to do it > itself. > > We have AFFS with totally fscked directory structures. Do you propose to > make unlink() block all directory operations on the whole fs? No? Too > bad, because only AFFS knows enough to protect its data structures without > _that_ locking. Sorry, the only rule that would not require the knowledge > of layout and would be strong enough to protect is "no directory access > while unlink() is in progress". Yup, on the whole fs. Hardly acceptable > even for one filesystem, but try to impose that on everyone and see how > long you will survive. JPEGs of the murder scene would be appreciated, > BTW. > > We have HFS with the data structures of its own. You want locking in VFS > that would protect the things VFS doesn't know about and has no business > to meddle with? Fine, post the locking rules. > > It's insane - protection of purely internal data structures belongs to the > module that knows about them. Generic stuff can, should be and _is_ > protected. Private one _can't_ be protected without either horribly > crippled system (see above) or putting the knowledge of each data > structure into the generic layer. And the latter will be on the author of > filesystem anyway, because only he knows what rules he need. > > Please, propose your magical locking scheme that will protect everything > on every fs. And let maintainers of filesystems tell you whether it is > sufficient. Then check what's left after that locking - e.g. can two > processes access the same fs at the same time or not? > > If you are complaining about the fact that maintaining complex data > structures in multithreaded program (which kernel is) may be, well, > complex - welcome to reality. It had been that way since the very > beginning on _all_ MT projects, Linux included. You have complex private > data - you may be in for pain protecting yourself from races. Protection > of the public structures is there, so life became easier than it used to > be back in 2.0/2.1/2.2 days. > > Making VFS single-threaded will not fly. If you can show simpler MT one - > do it and a lot of people will be extremely grateful. 4.4BSD and SunOS > ones are more complex and make the life harder for filesystem writers. > Check yourself. OSF/1 is _much_ more complex. Hell knows what NT has, but > filesystem glue there looks absolutely horrible - compared to them we are > angels in that respect. v7 was simpler, sure enough. Without mmap(), > rename() and truncate() _and_ with only one fs type - why not? Too bad > that it was racey as hell... Plan 9 is nice and easy. Without mmap(), > without link(), without truncate(), without cross-directory rename() and > without support of crazy abortions from hell a-la AFFS. 2.0 and 2.2 are > _way_ more complex, just compare filesystem code size in 2.4 with them and > you will see. And yes, races in question are not new. I can reproduce them > on 2.0.9 box. Single-processor one - nothing fancy and SMP-related. > > If you have a way to simplify VFS and/or filesystems - by all means, > post it on fsdevel/l-k. Just tell what locking warranties you provide. > Current
2.4.0-test5 problems with Promise ATA100
After compliation with the Promise UDMA chipsets support, with Use DMA by Default checked, the kernel refuses to acknowledge the existence of the chip. I have an ASUS K7M m/b that has the controller built in to the motherboard. After using dmesg I saw no attempts at all to use the kernel driver at all, no error message, etc. Any ideas? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: hfs support for blocksize != 512
On Wed, 30 Aug 2000, Roman Zippel wrote: > > > hfs. For example reading from a file might require a read from a btree > > > file (extent file), with what another file write can be busy with (e.g. > > > reordering the btree nodes). > > > > And? > > The point is: the thing I like about Linux is its simple interfaces, it's > the basic idea of unix - keep it simple. That is true for most parts - the > basic idea is simple and the real complexity is hidden behind it. But > that's currently not true for vfs interface, a fs maintainer has to fight > right now with fscking complex vfs interface and with a possible fscking Yes? And it will become simpler if you will put each and every locking scheme into the API? Look: we have Hans with his trees-all-over-the-place + journal. He has a very legitimate need to protect the internal data structures of Reiserfs and do it without changing the VFS<->reiserfs interaction whenever he decides to change purely internal structures. We have ext2 with indirect blocks, inode bitmaps and block bitmaps, one per cylinder group + counters in each cylinder group. Should VFS know about the internal locking rules? Should it be aware of the fact that inodes foo and bar belong to the same cylinder group and if we remove them we will need to protect the bitmap for a while? We have FAT32 where we've got a nasty allocation data with rather interesting locking rules. Should it be protected by VFS? If it should - well, I have bad news for you: write() on a file will lock the whole filesystem until write() completes. Don't like it for every fs? Tough, it will mean that VFS will not protect the thing and fs will have to do it itself. We have AFFS with totally fscked directory structures. Do you propose to make unlink() block all directory operations on the whole fs? No? Too bad, because only AFFS knows enough to protect its data structures without _that_ locking. Sorry, the only rule that would not require the knowledge of layout and would be strong enough to protect is "no directory access while unlink() is in progress". Yup, on the whole fs. Hardly acceptable even for one filesystem, but try to impose that on everyone and see how long you will survive. JPEGs of the murder scene would be appreciated, BTW. We have HFS with the data structures of its own. You want locking in VFS that would protect the things VFS doesn't know about and has no business to meddle with? Fine, post the locking rules. It's insane - protection of purely internal data structures belongs to the module that knows about them. Generic stuff can, should be and _is_ protected. Private one _can't_ be protected without either horribly crippled system (see above) or putting the knowledge of each data structure into the generic layer. And the latter will be on the author of filesystem anyway, because only he knows what rules he need. Please, propose your magical locking scheme that will protect everything on every fs. And let maintainers of filesystems tell you whether it is sufficient. Then check what's left after that locking - e.g. can two processes access the same fs at the same time or not? If you are complaining about the fact that maintaining complex data structures in multithreaded program (which kernel is) may be, well, complex - welcome to reality. It had been that way since the very beginning on _all_ MT projects, Linux included. You have complex private data - you may be in for pain protecting yourself from races. Protection of the public structures is there, so life became easier than it used to be back in 2.0/2.1/2.2 days. Making VFS single-threaded will not fly. If you can show simpler MT one - do it and a lot of people will be extremely grateful. 4.4BSD and SunOS ones are more complex and make the life harder for filesystem writers. Check yourself. OSF/1 is _much_ more complex. Hell knows what NT has, but filesystem glue there looks absolutely horrible - compared to them we are angels in that respect. v7 was simpler, sure enough. Without mmap(), rename() and truncate() _and_ with only one fs type - why not? Too bad that it was racey as hell... Plan 9 is nice and easy. Without mmap(), without link(), without truncate(), without cross-directory rename() and without support of crazy abortions from hell a-la AFFS. 2.0 and 2.2 are _way_ more complex, just compare filesystem code size in 2.4 with them and you will see. And yes, races in question are not new. I can reproduce them on 2.0.9 box. Single-processor one - nothing fancy and SMP-related. If you have a way to simplify VFS and/or filesystems - by all means, post it on fsdevel/l-k. Just tell what locking warranties you provide. Current ones are documented in the tree, so it will be very easy to compare. I'm not saying that they are ideal (check the documentation in question - I'm saying the opposite in quite a few cases). They _can_ be made better. But if you are saying that you know how to protect purely internal data structures without losing MT
[PATCH] fs/proc/generic.c: check proc_register result
Linus,
proc_register can fail and its result is not being checked, I've also
noticed that at one place (the first hunk in the patch below) it returns a
kfreed pointer on failure.
- Arnaldo
--- linux-2.4.0-test8-pre1/fs/proc/generic.cThu Aug 24 07:40:11 2000
+++ linux-2.4.0-test8-pre1.acme/fs/proc/generic.c Tue Aug 29 21:27:10 2000
@@ -427,16 +427,17 @@
ent->nlink = 1;
ent->mode = S_IFLNK|S_IRUGO|S_IWUGO|S_IXUGO;
ent->data = kmalloc((ent->size=strlen(dest))+1, GFP_KERNEL);
- if (!ent->data) {
- kfree(ent);
- goto out;
- }
+ if (!ent->data)
+ goto cleanup_ent;
strcpy((char*)ent->data,dest);
- proc_register(parent, ent);
-
+ if (proc_register(parent, ent))
+ goto cleanup_data;
out:
return ent;
+cleanup_data: kfree(ent->data);
+cleanup_ent: kfree(ent);
+ return NULL;
}
struct proc_dir_entry *proc_mknod(const char *name, mode_t mode,
@@ -461,8 +462,10 @@
ent->mode = mode;
ent->rdev = rdev;
- proc_register(parent, ent);
-
+ if (proc_register(parent, ent)) {
+ kfree(ent);
+ return NULL;
+ }
out:
return ent;
}
@@ -489,8 +492,10 @@
ent->nlink = 2;
ent->mode = S_IFDIR | S_IRUGO | S_IXUGO;
- proc_register(parent, ent);
-
+ if (proc_register(parent, ent)) {
+ kfree(ent);
+ return NULL;
+ }
out:
return ent;
}
@@ -529,8 +534,10 @@
}
ent->mode = mode;
- proc_register(parent, ent);
-
+ if (proc_register(parent, ent)) {
+ kfree(ent);
+ return NULL;
+ }
out:
return ent;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: hfs support for blocksize != 512
At 8:09 PM -0500 8/29/2000, Roman Zippel wrote: >So lets get back to the vfs interface Yes, let's do that. Every time I hear someone talking about implementing a filesystem, the words "you are doomed" are usually to be heard somewhere along the lines. Now, the bits on disk aren't usually the part that kills you - heck, I repaired an HFS drive with a hex editor once (don't try that at home, kids) - it's the evil and miserable FS driver APIs that get you. Big ugly structs, coherency problems with layers upon layers of xyz-cache, locking nightmares etc. So, when my boss dropped a multiple-compressed-backed ramdisk filesystem in my lap and said "make it use less memory", the words "I am doomed" floated through my head. Thankfully for the sake of both myself and my sanity, the platform of choice was QNX 4. (Obligitory disclaimer: QNX is an embedded operating system, both it's architecture and target market is considerably different from Linux's) QNX's filesystem interfaces make it so painfully easy to write a filesystem that it puts everything else to shame. You can easily write a fully functioning, race-free, completely coherent filesystem in less than a week, it's that simple. When I wanted to make my compressed-backed ramdisk filesystem attach to multiple points in the namespace with seperate and multiple backings on each point, in only a single instance of the driver, it was as easy as changing 10 lines of code. Now, for those of you who don't have convinient access to QNX4 or QNX Neutrino (which has an even nicer interface, mostly cleaning up on the QNX4 stuff), here's the disneyfied version of how it all works: When your filesystem starts up it tells the FS api "hey you, fs api. if someone needs something under directory FOO, call me". Your filesystem then wanders off and sleeps in the background 'till someone needs it. Now, let's say you do an 'ls' on the FOO directory. The FS api would tap your filesystem on the shoulder and ask "Hey you, what's in the FOO directory?". Your filesystem would reply "BAR and BAZ". Now you do 'cat FOO/BAZ >/dev/null', the FS api taps your filesystem on the shoulder and says "someone wants to open FOO/BAZ". Your filesystem replys "Yeah, got it open, here's an FD for you". The FS layer then comes back again and says "I'll take block x y and z from the file on this FD", to which your filesystem replies "Ok, here it is". Etc etc, you get the point. So what does it all mean? Basically, if you want hugely complex dentries, and inodes as big as your head, you can do that. If you don't, more power to you. It's all entirely contained inside your specific FS code, the FS api doesn't care one bit. It just asks you for files. It also means that you can do cute things like use the exact same API for block/char/random devices as you do for filesystems. No big fuss over special files, procfs, devfs, or dead chickens, your device driver just calls up the FS api and says "hey, I'm /dev/dsp" or "hey, I'll be taking care of /proc/cpuinfo" and it all "just works". Also, it means that if you want to represent your multiforked filesystem as files-as-directories, (can-o-worms: open) you can just do it. No changes to the FS api, no other filesystems break, etc. Everything "just works". If someone, ANYONE, could bring this kind of painfully simple FS api to linux, and make it work, not only would I be eternally in their debt, I would personally send them a box of genuine canadian maple-sugar candies as a small token of my infinite thanks. Even failing that, I urge anyone who would want to look at (re)designing any filesystem API to look at how QNX does it. It's really a beautiful thing. Further reading can be found in "Getting Started with QNX Neutrino 2: A Guide for Realtime Programmers", ISBN 0968250114. I should apologise here for this email being particularily fluffy. It's getting a bit late here, and I don't want to switch my brain on again before I go to sleep. For those of you who would rather not have read through this entire email, here's the condensed version: VFS is inherintly a wrong-level API, QNX does it much better. Flame on. :) Cheers - Tony 'Nicoya' Mantler :) -- Tony "Nicoya" Mantler - Renaissance Nerd Extraordinaire - [EMAIL PROTECTED] Winnipeg, Manitoba, Canada -- http://nicoya.feline.pp.se/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: File system
Robert Schweikert said once upon a time (Tue, 29 Aug 2000): > I read in the September issue of Linux Journal that there is a potential > development of an ext3 FS, which would be a journaling file system. This > seems kind of odd to me, as JFS and XFS are both proven file systems, > the code for both is I think GPLed, wouldn't the resources for ext3 not > be better used getting JFS and XFS ported as quickly as possible? > > I'm just curious. It is not potential, it exists, it works (no "meta-data only" or performance tuning yet). Ext3 is simply ext2+journaling. It is very low risk to try it out as you can easily go back to ext2. I dare say that 95% of the Linux boxes out there currently run ext2. Once ext3 releases, it provides an easy in place upgrade of functionality without the trouble of nuking your current filesystem, creating new XYZ filesystem, and restoring your data. I converted a 25GB ext2 filesystem to ext3 and back to ext2 without problems. Dax Kelson Guru Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
File system
Any news whether or not the final 2.4 kernel will have a journaling file system (ReisserFS, XFS, or JFS)? Judging from the IBM site it appears that the JFS port is not anywhere near ready for prime time. The XFS port appears to be farther along and SGI has a 2.4.0-test5 source tree for download, why has this not been merged with the main kernel, as I recall when I build the 2.4.0-test5 kernel, downloaded from kernel.org I did not have the option of choosing XFS as the file system. I know that SUSE 6.4 ships with the option of having ReisserFS partitions, but that was not part of the available file systems for the 2.4.0-test5 either. I read in the September issue of Linux Journal that there is a potential development of an ext3 FS, which would be a journaling file system. This seems kind of odd to me, as JFS and XFS are both proven file systems, the code for both is I think GPLed, wouldn't the resources for ext3 not be better used getting JFS and XFS ported as quickly as possible? I'm just curious. Thanks, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU [EMAIL PROTECTED] LINUX - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Oops in 2.4.0-test7 and 2.4.0-test8/pre1
Hi, I'm getting a lot of oopses (or is it oopsii) when ESD tries to load. Sheldon. ksymoops 0.7c on i686 2.4.0-test6. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.0-test6/ (default) -m /usr/src/linux/System.map (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. Aug 28 06:59:35 Defiant kernel: e820: 0009fc00 @ (usable) Aug 28 06:59:35 Defiant kernel: e820: 0400 @ 0009fc00 (reserved) Aug 28 06:59:35 Defiant kernel: e820: 0001 @ 000f (reserved) Aug 28 06:59:35 Defiant kernel: e820: 03ef6000 @ 0010 (usable) Aug 28 06:59:35 Defiant kernel: e820: a000 @ 03ff6000 (ACPI NVS) Aug 28 11:04:44 Defiant kernel: e820: 0009fc00 @ (usable) Aug 28 11:04:44 Defiant kernel: e820: 0400 @ 0009fc00 (reserved) Aug 28 11:04:44 Defiant kernel: e820: 0001 @ 000f (reserved) Aug 28 11:04:44 Defiant kernel: e820: 03ef6000 @ 0010 (usable) Aug 28 11:04:44 Defiant kernel: e820: a000 @ 03ff6000 (ACPI NVS) Aug 28 15:37:45 Defiant kernel: e820: 0009fc00 @ (usable) Aug 28 15:37:45 Defiant kernel: e820: 0400 @ 0009fc00 (reserved) Aug 28 15:37:45 Defiant kernel: e820: 0001 @ 000f (reserved) Aug 28 15:37:45 Defiant kernel: e820: 03ef6000 @ 0010 (usable) Aug 28 15:37:45 Defiant kernel: e820: a000 @ 03ff6000 (ACPI NVS) Aug 28 19:19:53 Defiant kernel: e820: 0009fc00 @ (usable) Aug 28 19:19:53 Defiant kernel: e820: 0400 @ 0009fc00 (reserved) Aug 28 19:19:53 Defiant kernel: e820: 0001 @ 000f (reserved) Aug 28 19:19:53 Defiant kernel: e820: 03ef6000 @ 0010 (usable) Aug 28 19:19:53 Defiant kernel: e820: a000 @ 03ff6000 (ACPI NVS) Aug 28 19:24:06 Defiant kernel: e820: 0009fc00 @ (usable) Aug 28 19:24:06 Defiant kernel: e820: 0400 @ 0009fc00 (reserved) Aug 28 19:24:06 Defiant kernel: e820: 0001 @ 000f (reserved) Aug 28 19:24:06 Defiant kernel: e820: 03ef6000 @ 0010 (usable) Aug 28 19:24:06 Defiant kernel: e820: a000 @ 03ff6000 (ACPI NVS) Aug 28 19:29:57 Defiant kernel: e820: 0009fc00 @ (usable) Aug 28 19:29:57 Defiant kernel: e820: 0400 @ 0009fc00 (reserved) Aug 28 19:29:57 Defiant kernel: e820: 0001 @ 000f (reserved) Aug 28 19:29:57 Defiant kernel: e820: 03ef6000 @ 0010 (usable) Aug 28 19:29:57 Defiant kernel: e820: a000 @ 03ff6000 (ACPI NVS) Aug 28 20:16:18 Defiant kernel: e820: 0009fc00 @ (usable) Aug 28 20:16:18 Defiant kernel: e820: 0400 @ 0009fc00 (reserved) Aug 28 20:16:18 Defiant kernel: e820: 0001 @ 000f (reserved) Aug 28 20:16:18 Defiant kernel: e820: 03ef6000 @ 0010 (usable) Aug 28 20:16:18 Defiant kernel: e820: a000 @ 03ff6000 (ACPI NVS) Aug 28 22:14:47 Defiant kernel: e820: 0009fc00 @ (usable) Aug 28 22:14:47 Defiant kernel: e820: 0400 @ 0009fc00 (reserved) Aug 28 22:14:47 Defiant kernel: e820: 0001 @ 000f (reserved) Aug 28 22:14:47 Defiant kernel: e820: 03ef6000 @ 0010 (usable) Aug 28 22:14:47 Defiant kernel: e820: a000 @ 03ff6000 (ACPI NVS) Aug 29 06:58:11 Defiant kernel: e820: 0009fc00 @ (usable) Aug 29 06:58:11 Defiant kernel: e820: 0400 @ 0009fc00 (reserved) Aug 29 06:58:11 Defiant kernel: e820: 0001 @ 000f (reserved) Aug 29 06:58:11 Defiant kernel: e820: 03ef6000 @ 0010 (usable) Aug 29 06:58:11 Defiant kernel: e820: a000 @ 03ff6000 (ACPI NVS) Aug 29 11:43:37 Defiant kernel: Unable to handle kernel paging request at virtual address c4836320 Aug 29 11:43:37 Defiant kernel: c482845d Aug 29 11:43:37 Defiant kernel: *pde = 03fa8063 Aug 29 11:43:37 Defiant kernel: Oops: Aug 29 11:43:37 Defiant kernel: CPU:0 Aug 29 11:43:37 Defiant kernel: EIP: 0010:[fat:__insmod_fat_S.bss_L2240+70109/56182635] Aug 29 11:43:37 Defiant
[PATCH] 2.2: Refinements to CONFIG_IP_PNP
The 2.2.17pre series includes my DHCP support for CONFIG_IP_PNP
(thanks, Alan!). Subsequent experience with that patch has led
to the following refinements:
* MUCH better RFC compliance, esp. with multiple interfaces
* MUCH improved boot speed: usually too fast to notice
* Cosmetic display improvements
* More persistence before closing device, since eepro driver
is working much better lately (thanks, Dragan!)
* Accepted ip= parameters:
"on", "off", "any", "none", "dhcp", "rarp", "both" (backward compat)
and finally, something that really ought to be configurable:
* By default, IP config is DISABLED.
It is enabled by an "ip=" boot command line.
I'm posting this so people can use it, and to get comments that
might lead to its inclusion in 2.2.18.
Index: net/ipv4/Config.in
--- net/ipv4/Config.in.prev
+++ net/ipv4/Config.in Tue Aug 15 15:06:59 2000
@@ -16,5 +16,5 @@
fi
fi
-bool 'IP: kernel level autoconfiguration' CONFIG_IP_PNP
+bool 'IP: kernel-level configuration support' CONFIG_IP_PNP
if [ "$CONFIG_IP_PNP" = "y" ]; then
bool ' DHCP support' CONFIG_IP_PNP_DHCP
Index: net/ipv4/ipconfig.c
--- net/ipv4/ipconfig.c.prev
+++ net/ipv4/ipconfig.c Tue Aug 15 14:07:25 2000
@@ -75,6 +75,7 @@
/* Define the timeout for waiting for a DHCP/BOOTP/RARP reply */
-#define CONF_OPEN_RETRIES 3 /* (Re)open devices three times */
-#define CONF_SEND_RETRIES 3 /* Send requests three times */
+#define CONF_OPEN_RETRIES 2 /* (Re)open devices twice */
+#define CONF_SEND_RETRIES 6 /* Send six requests per open */
+#define CONF_INTER_TIMEOUT (HZ/2) /* Inter-device timeout: 1/2 second */
#define CONF_BASE_TIMEOUT (HZ*2) /* Initial timeout: 2 seconds */
#define CONF_TIMEOUT_RANDOM(HZ)/* Maximum amount of randomization */
@@ -87,5 +88,5 @@
*/
-int ic_enable __initdata = 1; /* Automatic IP cfg enabled? */
+int ic_enable __initdata = 0; /* IP config enabled? */
/* Protocol choice */
@@ -130,8 +131,9 @@ static int ic_proto_have_if __initdata =
#ifdef IPCONFIG_DYNAMIC
-static volatile int ic_got_reply = 0; /* Protocol(s) we got reply from */
+static spinlock_t ic_recv_lock = SPIN_LOCK_UNLOCKED;
+static volatile int ic_got_reply __initdata = 0;/* Proto(s) that replied */
#endif
#ifdef IPCONFIG_DHCP
-static int ic_dhcp_msgtype __initdata = 0; /* Last incoming msg type */
+static int ic_dhcp_msgtype __initdata = 0; /* DHCP msg type received */
#endif
@@ -145,9 +147,10 @@ struct ic_device {
struct device *dev;
unsigned short flags;
- int able;
+ short able;
+ u32 xid;
};
-static struct ic_device *ic_first_dev __initdata = NULL;/* List of open device */
-static struct device *ic_dev __initdata = NULL;/* Selected device */
+static struct ic_device *ic_first_dev __initdata = NULL; /* Open devices */
+static struct device *ic_dev __initdata = NULL; /* Selected device */
static int __init ic_open_devs(void)
@@ -186,6 +189,11 @@ static int __init ic_open_devs(void)
d->flags = oflags;
d->able = able;
+ if (able & IC_BOOTP)
+ get_random_bytes(>xid, sizeof(u32));
+ else
+ d->xid = 0;
ic_proto_have_if |= able;
- DBG((SELF "%s UP (able=%d)\n", dev->name, able));
+ DBG((SELF "%s UP (able=%d, xid=%08x)\n",
+dev->name, able, d->xid));
}
*last = NULL;
@@ -387,4 +395,8 @@ ic_rarp_recv(struct sk_buff *skb, struct
unsigned long sip, tip;
unsigned char *sha, *tha; /* s for "source", t for "target" */
+ struct ic_device *d;
+
+ /* One reply at a time, please. */
+ spin_lock(_recv_lock);
/* If we already have a reply, just drop the packet */
@@ -392,4 +404,11 @@ ic_rarp_recv(struct sk_buff *skb, struct
goto drop;
+ /* Find the ic_device that the packet arrived on */
+ d = ic_first_dev;
+ while (d && d->dev != dev)
+ d = d->next;
+ if (!d)
+ goto drop; /* should never happen */
+
/* If this test doesn't pass, it's not IP, or we should ignore it anyway */
if (rarp->ar_hln != dev->addr_len || dev->type != ntohs(rarp->ar_hrd))
@@ -421,5 +440,5 @@ ic_rarp_recv(struct sk_buff *skb, struct
goto drop;
- /* Victory! The packet is what we were looking for! */
+ /* We have a winner! */
ic_dev = dev;
if (ic_myaddr == INADDR_NONE)
@@ -429,6 +448,10 @@ ic_rarp_recv(struct sk_buff *skb, struct
drop:
- /* and throw the packet out */
+ /* Show's over. Nothing to see here. */
+ spin_unlock(_recv_lock);
+
+ /* Throw the packet out. */
Re: Hmm.. "notify_parent()".
> those things where it does make a few cycles of difference. And it's one > of the system calls people use for benchmarking. We don't care about it, do we? -- Cesar Eduardo Barros [EMAIL PROTECTED] [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.2: Magic patch for older Symbios SCSI
Date:Tue, 29 Aug 2000 18:33:54 -0700 From: Chip Salzenberg <[EMAIL PROTECTED]> Nobody knows why this patch works. (Really!) But it does. (Really!) It makes the sym53c8xx driver work even with some very old 53c810 chips. Without this patch, the driver hangs on them. This is reproducible I would suggest that this change goes through Gerard Roudier, the maintainer of this driver. Especially since I do know he does have a large set of other updates for his drivers scheduled for 2.2.18 Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 2.2: Magic patch for older Symbios SCSI
Nobody knows why this patch works. (Really!) But it does. (Really!) It makes the sym53c8xx driver work even with some very old 53c810 chips. Without this patch, the driver hangs on them. This is reproducible Index: drivers/scsi/sym53c8xx.c --- drivers/scsi/sym53c8xx.c.prev +++ drivers/scsi/sym53c8xx.cSat Jun 17 17:49:46 2000 @@ -4792,5 +4792,5 @@ printk(KERN_INFO NAME53C "%s-%d: rev=0x% #define XXX0 #else -#define XXX3 +#define XXX2 #endif np->script0->dataphase[XXX] = cpu_to_scr(SCR_JUMP); -- Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]> "I wanted to play hopscotch with the impenetrable mystery of existence, but he stepped in a wormhole and had to go in early." // MST3K - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 2.2: Support O_NONBLOCK for SCSI disks
Unless I misunderstood Eric Youngdale's reply, he agrees that the
below patch is OK.
Index: drivers/scsi/sd.c
--- drivers/scsi/sd.c.prev
+++ drivers/scsi/sd.c Fri Jun 23 12:50:23 2000
@@ -151,34 +151,41 @@ static int sd_open(struct inode * inode,
* is being re-read.
*/
-
while (rscsi_disks[target].device->busy)
barrier();
-if(rscsi_disks[target].device->removable) {
+
+/*
+ * When opening removable disks, we check media...
+ * ... unless media don't matter, due to O_NONBLOCK.
+ */
+if ( rscsi_disks[target].device->removable
+ && !(filp->f_flags & O_NONBLOCK) )
+{
+/*
+ * Note disk change and/or removal.
+ * Also try to read new partition table (if any).
+ */
check_disk_change(inode->i_rdev);
- /*
-* If the drive is empty, just let the open fail.
-*/
+/*
+ * If the drive is empty, let the open fail.
+ */
if ( !rscsi_disks[target].ready )
- return -ENXIO;
+return -ENXIO;
- /*
-* Similarly, if the device has the write protect tab set,
-* have the open fail if the user expects to be able to write
-* to the thing.
-*/
- if ( (rscsi_disks[target].write_prot) && (filp->f_mode & 2) )
- return -EROFS;
+/*
+ * If the device has the write protect tab set,
+ * let the open fail if the user expects to be able to write.
+ */
+if ( (rscsi_disks[target].write_prot) && (filp->f_mode & 2) )
+return -EROFS;
}
/*
- * It is possible that the disk changing stuff resulted in the device being taken
- * offline. If this is the case, report this to the user, and don't pretend that
- * the open actually succeeded.
+ * It is possible that the disk changing stuff (or something
+ * else?) resulted in the device being taken offline.
+ * If so, let the open fail.
*/
-if( !rscsi_disks[target].device->online )
-{
+if ( !rscsi_disks[target].device->online )
return -ENXIO;
-}
/*
@@ -1069,5 +1076,4 @@ static int check_scsidisk_media_change(k
int target;
struct inode inode;
-int flag = 0;
target = DEVICE_NR(full_dev);
@@ -1121,9 +1127,9 @@ static int check_scsidisk_media_change(k
* struct and tested at open ! Daniel Roche ( [EMAIL PROTECTED] )
*/
-
rscsi_disks[target].ready = 1; /* FLOPTICAL */
retval = rscsi_disks[target].device->changed;
-if(!flag) rscsi_disks[target].device->changed = 0;
+rscsi_disks[target].device->changed = 0;
+
return retval;
}
--
Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]>
"I wanted to play hopscotch with the impenetrable mystery of existence,
but he stepped in a wormhole and had to go in early." // MST3K
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: If loadable modules are covered by Linux GPL?
In article <[EMAIL PROTECTED]>, Simon Richter <[EMAIL PROTECTED]> wrote: >On Tue, 29 Aug 2000, Mike A. Harris wrote: > >> #include'ing header files is not necessarily ok. Some headers >> include "inline functions" which is GPL code. Such inclusion in >> a module makes that module have to comply with GPL. > >I think this needs to be resolved ASAP. I don't have kernel sources handy, >so I cannot tell you whether the functions are actually worth being >protected (inb/outb doesn't belong to this group really), If it is in the header file I think it should be open for use. Not allowing inline code to be used just adds another hoop to jump. Just compile with that function explicitly defined. Define another version in the kernel and use that in your module instead. Etc. There was another thread a few days ago commenting that modern processors may actually be a bit faster with less inlined code and unrolled loops. Which may mean that a lot of what is now inlined may be better off compiled in. -- __O Fireplug - a Lineo company_-\<,_ PGP Fingerprint: 28 E2 A0 15 99 62 9A 00 (_)/ (_) 88 EC A3 EE 2D 1C 15 68 Stuart Lynne <[EMAIL PROTECTED]> www.fireplug.net604-461-7532 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 2.2: /proc/config.gz
This is a 2.2.17pre20 refresh of the /proc/config.gz patch originally
created by, well, here are the credits:
Oliver Xymoron <[EMAIL PROTECTED]> Jan 15 1999
Derived from a patch by Nicholas Leon <[EMAIL PROTECTED]> with
suggestions from Michael Chastain <[EMAIL PROTECTED]> and Peter T. Breuer
I've been using it for at least a year and it's great
Index: Documentation/Configure.help
--- Documentation/Configure.help.prev
+++ Documentation/Configure.helpFri Aug 4 18:52:48 2000
@@ -7816,4 +7816,12 @@
programs depend on this, so everyone should say Y here.
+/proc/config.gz support
+CONFIG_PROC_CONFIG
+ Say Y here if you want a copy of your current kernel configuration
+ saved in the kernel that you build. This is extremely useful if you
+ ever build more than one kernel. The cost is around 1K-4K of running
+ memory. Only say no if you really can't spare this. You can sneeze
+ and lose more on memory than this.
+
NFS filesystem support
CONFIG_NFS_FS
Index: include/linux/proc_fs.h
--- include/linux/proc_fs.h.prev
+++ include/linux/proc_fs.h Fri Aug 4 18:52:48 2000
@@ -52,5 +52,6 @@
PROC_STRAM,
PROC_SOUND,
- PROC_MTRR, /* whether enabled or not */
+ PROC_MTRR, /* whether enabled or not */
+ PROC_CONFIG,/* whether enabled or not */
PROC_FS
};
Index: Makefile
--- Makefile.prev
+++ MakefileFri Aug 4 18:52:48 2000
@@ -264,4 +264,15 @@
@ touch include/config/MARKER
+cloneconfig: symlinks scripts/split-include
+ @if [ -f "/proc/config.gz" ]; then \
+ mv -f .config .config.bak; \
+ gzip -d < /proc/config.gz > .config; \
+ if [ -r include/linux/autoconf.h ]; then \
+ scripts/split-include include/linux/autoconf.h include/config; \
+ fi; \
+ else \
+ echo "Your current kernel does not support cloning."; \
+ fi
+
linuxsubdirs: $(patsubst %, _dir_%, $(SUBDIRS))
@@ -297,4 +308,7 @@
@mv -f .ver $@
+include/linux/config_data.h: newversion scripts/bin2c
+ gzip -9 < .config | scripts/bin2c kernel_config_data > $@
+
include/linux/version.h: ./Makefile
@echo \#define UTS_RELEASE \"$(KERNELRELEASE)\" > .ver
@@ -303,5 +317,5 @@
@mv -f .ver $@
-init/version.o: init/version.c include/linux/compile.h include/config/MARKER
+init/version.o: init/version.c include/linux/compile.h include/linux/config_data.h
+include/config/MARKER
$(CC) $(CFLAGS) -DUTS_MACHINE='"$(ARCH)"' -c -o init/version.o init/version.c
@@ -375,5 +389,5 @@
rm -f core `find . -type f -name 'core' -print`
rm -f core `find . -name '.*.flags' -print`
- rm -f vmlinux System.map
+ rm -f vmlinux System.map include/linux/config_data.h
rm -f .tmp*
rm -f drivers/char/consolemap_deftbl.c drivers/video/promcon_tbl.c
@@ -406,5 +420,5 @@
rm -f .depend `find . -name .depend -print`
rm -f core `find . -size 0 -print`
- rm -f .hdepend scripts/mkdep scripts/split-include
+ rm -f .hdepend scripts/mkdep scripts/split-include scripts/bin2c
rm -f $(TOPDIR)/include/linux/modversions.h
rm -rf $(TOPDIR)/include/linux/modules
@@ -488,2 +502,5 @@
scripts/split-include: scripts/split-include.c
$(HOSTCC) $(HOSTCFLAGS) -o scripts/split-include scripts/split-include.c
+
+scripts/bin2c: scripts/bin2c.c
+ $(HOSTCC) $(HOSTCFLAGS) -o scripts/bin2c scripts/bin2c.c
Index: fs/Config.in
--- fs/Config.in.prev
+++ fs/Config.inFri Aug 4 18:52:48 2000
@@ -35,4 +35,7 @@
tristate 'OS/2 HPFS filesystem support (read only)' CONFIG_HPFS_FS
bool '/proc filesystem support' CONFIG_PROC_FS
+if [ "$CONFIG_PROC_FS" = "y" ] ; then
+ bool '/proc/config.gz (kernel configuration)' CONFIG_PROC_CONFIG
+fi
if [ "$CONFIG_UNIX98_PTYS" = "y" ]; then
# It compiles as a module for testing only. It should not be used
Index: fs/proc/array.c
--- fs/proc/array.c.prev
+++ fs/proc/array.c Fri Aug 4 18:52:48 2000
@@ -415,4 +415,15 @@ static int get_version(char * buffer)
}
+#ifdef CONFIG_PROC_CONFIG
+static int get_proc_config(char *buffer)
+{
+ extern char *kernel_config_data;
+ extern int kernel_config_data_size;
+
+ memcpy(buffer, kernel_config_data, kernel_config_data_size);
+ return kernel_config_data_size;
+}
+#endif
+
static int get_cmdline(char * buffer)
{
@@ -1461,4 +1472,9 @@ static long get_root_array(char * page,
return get_stram_list(page);
#endif
+#ifdef CONFIG_PROC_CONFIG
+ case PROC_CONFIG:
+ return get_proc_config(page);
+#endif
+
}
return -EBADF;
Index: fs/proc/root.c
--- fs/proc/root.c.prev
+++ fs/proc/root.c Fri Aug 4 18:52:48 2000
@@ -691,4 +691,11 @@ static struct proc_dir_entry proc_root_p
};
#endif
+#ifdef CONFIG_PROC_CONFIG
+static struct proc_dir_entry proc_root_config = {
+ PROC_CONFIG, 9, "config.gz",
+ S_IFREG | S_IRUGO,
[PATCH] 2.2: vfat filename creation rules
This patch originated with "H. Kawaguchi" <[EMAIL PROTECTED]>,
but I've tweaked it somewhat. It's seen fairly heavy use since.
--
Hi,
I think that a file name generation rule on VFAT is
different from Windows.
Long name is not generated when I make 8+3 file name
in capital letters on Windows. But Linux generates it.
This patch does the following revisions.
o It makes a file name generation rule same as Windows
o By default, it shows short name in capital letters
o By "small" option, it shows short name with small letters
o By "forcelong" option, it always generates long name
--
Index: include/linux/msdos_fs_sb.h
--- include/linux/msdos_fs_sb.h.prev
+++ include/linux/msdos_fs_sb.h Sat Jun 17 17:48:32 2000
@@ -25,5 +25,7 @@
numtail:1, /* Does first alias have a numeric '~1' type tail? */
atari:1, /* Use Atari GEMDOS variation of MS-DOS fs */
-fat32:1; /* Is this a FAT32 partition? */
+fat32:1, /* Is this a FAT32 partition? */
+small_letter:1, /* Use small letters for short name */
+force_long:1;/* Force create longname */
};
Index: fs/fat/dir.c
--- fs/fat/dir.c.prev
+++ fs/fat/dir.cSat Jun 17 17:48:32 2000
@@ -140,4 +140,5 @@ int fat_search_long(
int uni_xlate = MSDOS_SB(sb)->options.unicode_xlate;
int utf8 = MSDOS_SB(sb)->options.utf8;
+ int small_letter = MSDOS_SB(sb)->options.small_letter;
unsigned char *unicode = NULL;
struct nls_table *nls = MSDOS_SB(sb)->nls_io;
@@ -227,5 +228,5 @@ parse_long:
for (i = 0, last = 0; i < 8;) {
if (!(c = de->name[i])) break;
- if (c >= 'A' && c <= 'Z') c += 32;
+ if (small_letter) c = tolower(c);
if (c == 0x05) c = 0xE5;
if ((bufname[i++] = c) != ' ')
@@ -236,5 +237,5 @@ parse_long:
for (i2 = 0; i2 < 3; i2++) {
if (!(c = de->ext[i2])) break;
- if (c >= 'A' && c <= 'Z') c += 32;
+ if (small_letter) c = tolower(c);
if ((bufname[i++] = c) != ' ')
last = i;
@@ -302,4 +303,5 @@ static int fat_readdirx(
int uni_xlate = MSDOS_SB(sb)->options.unicode_xlate;
int utf8 = MSDOS_SB(sb)->options.utf8;
+ int small_letter = MSDOS_SB(sb)->options.small_letter;
unsigned char *unicode = NULL;
struct nls_table *nls = MSDOS_SB(sb)->nls_io;
@@ -420,5 +422,5 @@ ParseLong:
for (i = 0, last = 0; i < 8;) {
if (!(c = de->name[i])) break;
- if (c >= 'A' && c <= 'Z') c += 32;
+ if (small_letter) c = tolower(c);
/* see namei.c, msdos_format_name */
if (c == 0x05) c = 0xE5;
@@ -430,5 +432,5 @@ ParseLong:
for (i2 = 0; i2 < 3; i2++) {
if (!(c = de->ext[i2])) break;
- if (c >= 'A' && c <= 'Z') c += 32;
+ if (small_letter) c = tolower(c);
if ((ptname[i++] = c) != ' ')
last = i;
Index: fs/fat/inode.c
--- fs/fat/inode.c.prev
+++ fs/fat/inode.c Sat Jun 17 17:48:32 2000
@@ -217,4 +217,5 @@ static int parse_options(char *options,i
opts->codepage = 0;
opts->utf8 = 0;
+ opts->small_letter = 0;
opts->iocharset = NULL;
*debug = *fat = 0;
@@ -261,4 +262,7 @@ static int parse_options(char *options,i
else if (!strcmp(this_char,"showexec")) {
opts->showexec = 1;
+ }
+ else if (!strcmp(this_char,"small")) {
+ opts->small_letter = 1;
}
else if (!strcmp(this_char,"dotsOK") && value) {
Index: fs/vfat/namei.c
--- fs/vfat/namei.c.prev
+++ fs/vfat/namei.c Sat Jun 17 17:48:32 2000
@@ -121,4 +121,5 @@ static int parse_options(char *options,
opts->numtail = 1;
opts->utf8 = 0;
+ opts->force_long = 0;
if (!options) return 1;
@@ -143,7 +144,8 @@ static int parse_options(char *options,
} else if (!strcmp(this_char,"nonumtail")) {
ret = simple_getbool(value, );
- if (ret) {
- opts->numtail = !val;
- }
+ if (ret) opts->numtail = !val;
+ } else if (!strcmp(this_char,"forcelong") ||
+ !strcmp(this_char,"force_long")) {
+ opts->force_long = 1;
}
if (this_char != options)
@@ -384,5 +386,5 @@ static int vfat_valid_shortname(const ch
if (utf8 && (c & 0x80)) return -EINVAL;
[PATCH] 2.2: Consistency in ext2 error setting
This is a patch from Andreas Dilger <[EMAIL PROTECTED]>.
It claims to fix some corner cases where an error code may not be
returned properly. Here's the description:
--
ext2_bread always sets err to some sane value. I traced this through:
ext2_bread() calls ext2_getblk to set *err or sets *err = -EIO;
ext2_getblk() calls ext2_get_block to set *err;
ext2_get_block() returns 0, -EIO, or {inode,block}_getblk _may_ set err;
The inode_getblk and block_getblk functions themselves do not always set *err,
although err = 0 before they are called from ext2_get_block(), so there is
_always_ a return value set from ext2_get_block().
The ext2_get_block() function may call block_getblk() several times without
checking the return value, so it _appears_ it would overwrite the last error
value. However, one (non-obvious) thing to note is that bh = NULL on error
return* from {inode,block}_getblk(), and calls to block_getblk() are a no-op
if bh == NULL.
(*) There was one (probably very rare) error case where block_getblk()
might return non-NULL: after bforget(result) jumps back to repeat: and
then we get an error with ext2_alloc_block() - we return a bad result.
I also fixed this in the attached patch.
I also found that ext2_alloc_block() did not set a return code in the
(#undef'd) PREALLOC path, and inode_getblk() set a return value instead
of using the error from ext2_alloc_block(). I also verified that
ext2_alloc_block() itself always sets an error code.
--
Index: fs/ext2/balloc.c
--- fs/ext2/balloc.c.prev
+++ fs/ext2/balloc.cSat Jun 17 17:48:19 2000
@@ -479,9 +479,6 @@ repeat:
i = 0;
gdp = ext2_get_group_desc (sb, i, );
- if (!gdp) {
- *err = -EIO;
- unlock_super (sb);
- return 0;
- }
+ if (!gdp)
+ goto io_error;
if (le16_to_cpu(gdp->bg_free_blocks_count) > 0)
break;
Index: fs/ext2/inode.c
--- fs/ext2/inode.c.prev
+++ fs/ext2/inode.c Sat Jun 17 17:48:19 2000
@@ -132,4 +132,5 @@ static int ext2_alloc_block (struct inod
mark_buffer_dirty(bh, 1);
brelse (bh);
+ *err = 0;
} else {
ext2_discard_prealloc (inode);
@@ -207,4 +208,5 @@ int ext2_bmap (struct inode * inode, int
}
+/* must return NULL on error */
static struct buffer_head * inode_getblk (struct inode * inode, int nr,
int create, int new_block, int * err)
@@ -219,5 +221,5 @@ repeat:
tmp = *p;
if (tmp) {
- struct buffer_head * result = getblk (inode->i_dev, tmp,
inode->i_sb->s_blocksize);
+ result = getblk (inode->i_dev, tmp, inode->i_sb->s_blocksize);
if (tmp == *p)
return result;
--
Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]>
"I wanted to play hopscotch with the impenetrable mystery of existence,
but he stepped in a wormhole and had to go in early." // MST3K
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: hfs support for blocksize != 512
Hi, > > hfs. For example reading from a file might require a read from a btree > > file (extent file), with what another file write can be busy with (e.g. > > reordering the btree nodes). > > And? The point is: the thing I like about Linux is its simple interfaces, it's the basic idea of unix - keep it simple. That is true for most parts - the basic idea is simple and the real complexity is hidden behind it. But that's currently not true for vfs interface, a fs maintainer has to fight right now with fscking complex vfs interface and with a possible fscking complex fs implementation. E2fs or affs have a pretty simple structure and I believe you that it's not that hard to fix, maybe there is also a simple solution for hfs. But I'd like you to forget about that and think about the big picture (how Linus nicely states it). What we should aim at with the vfs interface is simplicity, I want to use a fscking simple semaphore to protect something like anywhere else, I don't want to juggle with lots blocks wich have to be updated atomically. Maybe you get once right, but it will follow you as a nightmare, you add one feature (e.g. quota), you add another feature (like btrees), you so still damned fscking sure to get and keeping it right? So and? What I'd really like to see from you is to be a bit more supportive for other peoples problems, I really don't expect you to solve these problems, but if someone approaches a different solution, you're pretty quick to refuse it. So lets get back to the vfs interface, fs currently have to do pretty much all there changes atomically, they have to grab all the buffers they need and do all changes at once. How can you be sure that this is possible for every possible fs? How do you make sure you don't create other problems like livelocks? We currently have problem that things like kswapd require an asynchronous interface, but fs prefer to synchronize it. Currently you pushing all the burden of an asynchronous interface into the fs, which want to rather avoid that. Why don't you think for a moment in the other direction? Currently I'm playing with the idea of a kernel thread for asynchronous io (maybe one per fs), that thread takes the io requests e.g. from kswapd and the io thread can safely sleep on it, while kswapd can continue its job, but I don't know yet, where to put, whether in the fs specific part or whether it can be made generic enough to be put into the generic part. Can we please think for a moment in that direction? At some point you have to synchronize the io anyway (at latest when it hits the device), but I would pretty much prefer if a fs would get some help at some earlier point. (Anyway, I need some sleep now as well... :) ) bye, Roman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 2.2: Rusty's fasync patch backported
2.2 currently ignores the return value of f_op->fasync().
This patch fixes that oversight.
Index: fs/ioctl.c
--- fs/ioctl.c.prev
+++ fs/ioctl.c Sat Jun 17 17:48:10 2000
@@ -85,6 +85,10 @@ asmlinkage int sys_ioctl(unsigned int fd
if ((flag ^ filp->f_flags) & FASYNC) {
if (filp->f_op && filp->f_op->fasync)
- filp->f_op->fasync(fd, filp, on);
+ error = filp->f_op->fasync(fd, filp, on);
+ else error = -ENOTTY;
}
+ if (error != 0)
+ break;
+
if (on)
filp->f_flags |= FASYNC;
--
Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]>
"I wanted to play hopscotch with the impenetrable mystery of existence,
but he stepped in a wormhole and had to go in early." // MST3K
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 2.2 vs. CAP_CHOWN and CAP_FOWNER
CAP_CHOWN relaxes the BSD-style restrictions on chowning a file to a
user id other than yourself (a restriction instituted to enforce
quotas).
CAP_FOWNER relaxes the normal restriction on performing operations on
files that belong to someone other than yourself.
This patch corrects the implementation of these capabilities.
Index: fs/attr.c
--- fs/attr.c.prev
+++ fs/attr.c Tue Aug 29 18:02:40 2000
@@ -23,18 +23,22 @@ int inode_change_ok(struct inode *inode,
/* Make sure a caller can chown. */
- if ((ia_valid & ATTR_UID) &&
- (current->fsuid != inode->i_uid ||
-attr->ia_uid != inode->i_uid) && !capable(CAP_CHOWN))
- goto error;
+ if ((ia_valid & ATTR_UID) && attr->ia_uid != inode->i_uid) {
+ if (current->fsuid != inode->i_uid && !capable(CAP_FOWNER))
+ goto error;
+ if (current->fsuid != attr->ia_uid && !capable(CAP_CHOWN))
+ goto error;
+ }
/* Make sure caller can chgrp. */
- if ((ia_valid & ATTR_GID) &&
- (!in_group_p(attr->ia_gid) && attr->ia_gid != inode->i_gid) &&
- !capable(CAP_CHOWN))
- goto error;
+ if ((ia_valid & ATTR_GID) && attr->ia_gid != inode->i_gid) {
+ if (current->fsuid != inode->i_uid && !capable(CAP_FOWNER))
+ goto error;
+ if (!in_group_p(attr->ia_gid) && !capable(CAP_CHOWN))
+ goto error;
+ }
/* Make sure a caller can chmod. */
if (ia_valid & ATTR_MODE) {
- if ((current->fsuid != inode->i_uid) && !capable(CAP_FOWNER))
+ if (current->fsuid != inode->i_uid && !capable(CAP_FOWNER))
goto error;
/* Also check the setgid bit! */
--
Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]>
"I wanted to play hopscotch with the impenetrable mystery of existence,
but he stepped in a wormhole and had to go in early." // MST3K
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix disk statistic reporting to include all disks
On Wed, 30 Aug 2000, Jens Axboe wrote:
>
> Maybe I wasn't very clear... What I mean is that drivers that use
> blk_queue_make_request (such as md) are handed buffers directly and
> don't get requests added to their queues in the regular sense, instead
> they remap b_rdev before ll_rw_blk gets the queue for the device and
> adds them to the destination queue.
Ho humm.. I actually kind of expected the statistics to be done in
generic_make_request(), so that we'd have
.
do {
q = blk_get_queue(bh->b_rdev);
if (!q) {
... no such device ..
}
+ statistics(q, rw, bh->b_size);
} while (q->make_request_fn(q, rw, bh)));
...
and just remove the drive_stat_acct() thing completely.
That way, we'd have a per-queue "this many reads, this many writes".
The /proc code would have to find all the queues, but that shouldn't be
too bad either. At least we wouldn't have the current silly disk_index()
stuff (which is all done in a timing-critical routine).
Then, as we get saner and saner queues, we'll get saner and saner
statistics automatically. The above should already be quite sane for IDE.
No?
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Lockups in X-Windows login screen
Hello! Val Henson <[EMAIL PROTECTED]> writes: > Sounds hardware related. Try removing cards or switching motherboards. As I already mentioned, the problem persits over all of the described hardware changes (that's what I meant to say with the "upgraded" and "installed later" in the hardware descriptions). Even in face of the obvious similarities mine and my friends' machine do not have anything "significant" in common; meaning that the PCB revisions/manufacturers of all otherwise identical components differ in every case (Motherboard, RAM, Power Supply, Plextor CD-ROM) as they were bought at least 6 months apart. The described problem is the *only* instability we experience, besides during X startup the machines run rock-solid as long as they're turned on under Linux and more stable than can usually be expected under Windows 98 and Windows 2000. If it should really be hardware then I think it is a quirk that only gets tickled in the situation described (meaning it would be a bug present in all configurations similar enough) and should be avoidable. So long, Joe -- "I use emacs, which might be thought of as a thermonuclear word processor." -- Neal Stephenson, "In the beginning... was the command line" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 on SPARC: Some warnings squashed
Date:Tue, 29 Aug 2000 20:14:58 -0400 From: Horst von Brand <[EMAIL PROTECTED]> --- linux-2.4.0-test/kernel/signal.c.dist-2.4.0-test8-pre1 Tue Aug 29 18:27:38 2000 +++ linux-2.4.0-test/kernel/signal.c Tue Aug 29 18:27:46 2000 This fix already sent to Linus last night. --- linux-2.4.0-test/include/asm-sparc/sbus.h.dist-2.4.0-test8-pre1 Tue Aug 29 18:09:13 2000 +++ linux-2.4.0-test/include/asm-sparc/sbus.hTue Aug 29 18:09:20 2000 @@ -112,7 +112,7 @@ /* All the rest use streaming mode mappings. */ extern u32 sbus_map_single(struct sbus_dev *, void *, long, int); -extern void sbus_unmap_single(struct sbus_dev *, u32, long, int); +extern void sbus_unmap_single(struct sbus_dev *, dma_addr_t, size_t, int); extern int sbus_map_sg(struct sbus_dev *, struct scatterlist *, int, int); extern void sbus_unmap_sg(struct sbus_dev *, struct scatterlist *, int, int); Now the extern decl for sbus_unmap_single does not match the actual argument types in the definition of it in arch/sparc/kernel/ioport.c If this fixes warnings else where, it also creates a new one for ioport.c This change makes no sense, not applied. --- linux-2.4.0-test/drivers/sbus/audio/amd7930.c.dist-2.4.0-test8-pre1 Tue Aug 29 15:03:23 2000 +++ linux-2.4.0-test/drivers/sbus/audio/amd7930.cTue Aug 29 15:32:40 2000 This patch did not apply cleanly, not applied. --- linux-2.4.0-test/drivers/sbus/audio/dbri.c.dist-2.4.0-test8-pre1 Fri Feb 18 20:07:20 2000 +++ linux-2.4.0-test/drivers/sbus/audio/dbri.c Tue Aug 29 18:03:03 2000 Applied. --- linux-2.4.0-test/arch/sparc/mm/init.c.dist-2.4.0-test8-pre1 Thu Aug 24 09:51:33 2000 +++ linux-2.4.0-test/arch/sparc/mm/init.cTue Aug 29 14:50:40 2000 Applied. Thanks. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.4.0-test8-pre1 on SPARC: Some warnings squashed
This fixes most warnings I see on SPARC. There are some more (and using
gcc-2.96 gives _loads_ of them!), will try to fix the rest later.
The wrong types of the callbacks in drivers/sbus/audio/amd7930.c trouble me
a bit.
--- linux-2.4.0-test/kernel/signal.c.dist-2.4.0-test8-pre1 Tue Aug 29 18:27:38
2000
+++ linux-2.4.0-test/kernel/signal.cTue Aug 29 18:27:46 2000
@@ -364,7 +364,6 @@
recalc_sigpending(t);
break;
}
-return 0;
}
static int deliver_signal(int sig, struct siginfo *info, struct task_struct *t)
--- linux-2.4.0-test/include/asm-sparc/sbus.h.dist-2.4.0-test8-pre1 Tue Aug 29
18:09:13 2000
+++ linux-2.4.0-test/include/asm-sparc/sbus.h Tue Aug 29 18:09:20 2000
@@ -112,7 +112,7 @@
/* All the rest use streaming mode mappings. */
extern u32 sbus_map_single(struct sbus_dev *, void *, long, int);
-extern void sbus_unmap_single(struct sbus_dev *, u32, long, int);
+extern void sbus_unmap_single(struct sbus_dev *, dma_addr_t, size_t, int);
extern int sbus_map_sg(struct sbus_dev *, struct scatterlist *, int, int);
extern void sbus_unmap_sg(struct sbus_dev *, struct scatterlist *, int, int);
--- linux-2.4.0-test/drivers/sbus/audio/amd7930.c.dist-2.4.0-test8-pre1 Tue Aug 29
15:03:23 2000
+++ linux-2.4.0-test/drivers/sbus/audio/amd7930.c Tue Aug 29 15:32:40 2000
@@ -140,7 +140,7 @@
u8 xmit_idle_char;
/* Callback routine (and argument) when output is done on */
- void (*output_callback)(void *, unsigned char);
+ void (*output_callback)(void *, int);
void * output_callback_arg;
/* Current buffer that the driver is recording on channel */
@@ -149,7 +149,7 @@
volatile u32 input_limit;
/* Callback routine (and argument) when input is done on */
- void (*input_callback)(void *, unsigned char, unsigned long);
+ void (*input_callback)(void *, int, unsigned int);
void * input_callback_arg;
int input_format;
@@ -1156,7 +1156,7 @@
return info->liu_state;
}
-static void amd7930_liu_init(int dev, void (*callback)(), void *callback_arg)
+static void amd7930_liu_init(int dev, void (*callback)(void *), void *callback_arg)
{
struct amd7930_info *info;
unsigned long flags;
@@ -1242,7 +1242,8 @@
}
static void amd7930_dxmit(int dev, __u8 *buffer, unsigned int count,
- void (*callback)(void *), void *callback_arg)
+ void (*callback)(void *, int),
+ void *callback_arg)
{
struct amd7930_info *info;
unsigned long flags;
@@ -1286,7 +1287,7 @@
}
static void amd7930_drecv(int dev, __u8 *buffer, unsigned int size,
- void (*callback)(void *),
+ void (*callback)(void *, int, unsigned int),
void *callback_arg)
{
struct amd7930_info *info;
--- linux-2.4.0-test/drivers/sbus/audio/dbri.c.dist-2.4.0-test8-pre1Fri Feb 18
20:07:20 2000
+++ linux-2.4.0-test/drivers/sbus/audio/dbri.c Tue Aug 29 18:03:03 2000
@@ -2228,7 +2228,6 @@
{
struct dbri *dbri;
struct linux_prom_irqs irq;
-__u32 dma_dvma;
int err;
if (sdev->prom_name[9] < 'e') {
--- linux-2.4.0-test/arch/sparc/mm/init.c.dist-2.4.0-test8-pre1 Thu Aug 24 09:51:33
2000
+++ linux-2.4.0-test/arch/sparc/mm/init.c Tue Aug 29 14:50:40 2000
@@ -89,8 +89,6 @@
void __init kmap_init(void)
{
- unsigned long pteval;
-
/* cache the first kmap pte */
kmap_pte = kmap_get_fixed_pte(FIX_KMAP_BEGIN);
kmap_prot = __pgprot(SRMMU_ET_PTE | SRMMU_PRIV | SRMMU_CACHE);
--
Dr. Horst H. von Brand mailto:[EMAIL PROTECTED]
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, ChileFax: +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix disk statistic reporting to include all disks
On Tue, 29 Aug 2000, Linus Torvalds wrote: > On Wed, 30 Aug 2000, Jens Axboe wrote: > > > On Wed, Aug 30 2000, Jens Axboe wrote: > > > Sounds sane, but what about drivers that don't really use the request > > > queue structure? Stuff like lvm, md, rd (with Neil's patch to fix the > > > lru_list deadlock), and probably new loop. > > > > Of course lvm and md get statistics accounted for the low devices... > > No, I think you actually want to double-count here: I think it is sensible > to have both a low-level statistics _and_ a "md" statistic. It could be > useful for showing clearly how the requests are distributed. double-counting is good. with the veritas tools you can pull up the stats on a fs, volume, or disk basis. at each level you can get number of r/w, number of blocks r/w, and avg. latencies. extremely useful for finding hotspots and moving them elsewhere. -dean - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix disk statistic reporting to include all disks
On Wed, Aug 30 2000, Jens Axboe wrote: > > I'm not sure what you mean about lvm/md/rd not having request queues. > > Maybe I wasn't very clear... What I mean is that drivers that use Of course they have the queue associated with the blk dev, so maybe I should just stop writing mails for today. The statistics thing still counts though ;-). So lets just do it earlier and catch md and such too. -- * Jens Axboe <[EMAIL PROTECTED]> * SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix disk statistic reporting to include all disks
On Tue, Aug 29 2000, Linus Torvalds wrote: > > Sounds sane, but what about drivers that don't really use the request > > queue structure? Stuff like lvm, md, rd (with Neil's patch to fix the > > lru_list deadlock), and probably new loop. > > Every single driver must have a request_queue: as far as the ll_rw_block > layer is concerned, a NULL request-queue means that the device doesn't > exist. It will even print out a message saying so.. > > I'm not sure what you mean about lvm/md/rd not having request queues. Maybe I wasn't very clear... What I mean is that drivers that use blk_queue_make_request (such as md) are handed buffers directly and don't get requests added to their queues in the regular sense, instead they remap b_rdev before ll_rw_blk gets the queue for the device and adds them to the destination queue. So per request accounting isn't done for md currently, although (as per your next mail) I do agree that having statistics for both makes sense. -- * Jens Axboe <[EMAIL PROTECTED]> * SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix disk statistic reporting to include all disks
On Wed, 30 Aug 2000, Jens Axboe wrote: > On Wed, Aug 30 2000, Jens Axboe wrote: > > Sounds sane, but what about drivers that don't really use the request > > queue structure? Stuff like lvm, md, rd (with Neil's patch to fix the > > lru_list deadlock), and probably new loop. > > Of course lvm and md get statistics accounted for the low devices... No, I think you actually want to double-count here: I think it is sensible to have both a low-level statistics _and_ a "md" statistic. It could be useful for showing clearly how the requests are distributed. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix disk statistic reporting to include all disks
On Wed, 30 Aug 2000, Jens Axboe wrote: > > Sounds sane, but what about drivers that don't really use the request > queue structure? Stuff like lvm, md, rd (with Neil's patch to fix the > lru_list deadlock), and probably new loop. Every single driver must have a request_queue: as far as the ll_rw_block layer is concerned, a NULL request-queue means that the device doesn't exist. It will even print out a message saying so.. I'm not sure what you mean about lvm/md/rd not having request queues. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: If loadable modules are covered by Linux GPL?
Mike Coleman wrote: > "Richard B. Johnson" <[EMAIL PROTECTED]> writes: > > Even M$ doesn't require that I give proprietary information away. > > If Linux wants to become the new standard for the computing industry, > > GPL or whatever can't claim any ownership of the work a company > > has done while using it. > > This almost seems like a troll. We who write GPLed software don't claim > ownership of other's work--we just specify the conditions under which the > others can use *our* work. What's wrong with that? Are you saying we should > just give our work away to you with compensation at all? You Communist! ;-) The GNU GPL is reasonable, but ... I would re-iterate the need for a clear definition as to how to add proprietary functionality into the kernel without violating the GNU GPL. The syntax and inclusion issues I mentioned in my previous post (along with I'm sure many others I left out) need to be addressed. The document doesn't need to be complex; it just has to be clear and concise enough for people to use as a guideline. Modules, drivers, system calls, include files, memory subsystem replacements, whatever. I can imagine many people are wary of extending the Linux kernel's functionality for fear that including their code might potentially lead to GNU GPL violation, inevitably leading to license, royalty or patent problems. And I'm sure most people want to do the right thing, but don't have the luxury of exploring every possible violation simply for the sake of a change or two in a kernel subsystem. This is particularly concerning for cross-license issues between people and/or companies. ... or am I way off-base here? --Matt (who writes GPL'd software) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix disk statistic reporting to include all disks
On Wed, Aug 30 2000, Jens Axboe wrote: > Sounds sane, but what about drivers that don't really use the request > queue structure? Stuff like lvm, md, rd (with Neil's patch to fix the > lru_list deadlock), and probably new loop. Of course lvm and md get statistics accounted for the low devices... -- * Jens Axboe <[EMAIL PROTECTED]> * SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix disk statistic reporting to include all disks
On Tue, Aug 29 2000, Linus Torvalds wrote: > > This patch fixes the enhanced disk statistics to report all drives > > so IDE1 - IDE3 (/dev/hdc - /dev/hdh) can be monitored. > > Why not just do this right, and move the statistics into the "queue > structure". Get rid of that ugly kstat thing. Get rid of all the special > case lookups. We already need to have the queue structure to do the > queuing (surprise, surprise), so suddenly statistics are (a) cheap and (b) > right. > > So then /proc just needs to be changed to look at the queues instead of > looking at this kstat thing. Sounds sane, but what about drivers that don't really use the request queue structure? Stuff like lvm, md, rd (with Neil's patch to fix the lru_list deadlock), and probably new loop. Come to think of it, regular disk stat accounting doesn't work there atm anyway... -- * Jens Axboe <[EMAIL PROTECTED]> * SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Raid 1/upgrade to 2.2.16
On 29 Aug, Alan Cox wrote: > http://people.redhat.com/~mingo Looks like you typoed, that gives a forbidden but both http://people.redhat.com/mingo and http://www.rehdat.com/~mingo work (actually it redirects to people.redhat.com/mingo) -- Mike Marion - Unix SysAdmin/Engineer, Qualcomm Inc. - http://miguelito.org "In the closed-source world, Version 1.0 means "Don't touch this if you're prudent."; in the open-source world it reads more like "The developers are willing to bet their reputations on this." - Eric Raymond - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ll_rw_blk.c fails to merge requests. Help!
On Tue, Aug 29 2000, David Mansfield wrote:
> > This one works even better.
Good to know, thanks for testing.
> > + list_add(>table, >pending_freelist);
> > + if (++q->pending_free > 64) {
And you are right, this is best a fractional value of the total number
of requests.
> I have two comments about this patch. (the reqfree-batching-3)
>
> First. Couldn't it end up indefinitely starving a writer?
Yes, that is right. I have a newer version in my tree, that uses the
complete split pending lists (and nr pending counter) along with
separate wait queues. I'm just doing some testing on it now, to make
sure it is 100% safe. This makes performance even better than the -3
patch here.
> Second. At queue destroy time (blk_cleanup_queue) the pending_list
> should be spliced into the free_list so they won't get leaked.
> Alternatively,
> add a 'count -= blk_cleanup_queue(>pending_list)'.
Naturally, -3 was never a proposal for inclusion, just a quick test
patch ;-). This is also in my current tree.
--
* Jens Axboe <[EMAIL PROTECTED]>
* SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Suggestion for laptop suspension
From: Linda Walsh <[EMAIL PROTECTED]> > > You might want to reread what I previously wrote. Is there any > reason to think that your program is doing anything other than forcing all dirty > buffers out to disk? Yes. 1) I didn't actually respond to what you said, but to what Richard asked. 2) My program is creating a large area of memory entirely filled with zeros. 3) My program was merely an experiment to see if having most of memory set to zero would speed up the BIOS's save to disk feature. Just flushing buffers to disk cannot achieve anything as far as the BIOS is concerned. I agree with others that swsusp is probably the way to go (especially for machines with ACPI but no S4BIOS support), but I though I might be able to provide Richard with a quick and (only slightly) dirty solution to his immediate problem. Cheers, Stephen Rothwell[EMAIL PROTECTED] Linux APM guy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [2.4.0test6] IPv6 link-local TCP still slightly broken
Date:Wed, 30 Aug 2000 00:52:59 +0200 From: Felix von Leitner <[EMAIL PROTECTED]> Due to another bug that I haven't isolated yet, the packets are actually received twice by tcpdump. This is not a bug at all. Over loopback, you will see the packet twice because it is captured at two points 1) where it is transmitted over loopback 2) where it is received over loopback, just as it would be for ethernet transmit/receive. This behavior is consistent with how every other interface captures packets and it isn't going to change or be "fixed". Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] t8p1: Fix input driver configuration
Resent as per Linus request. Franz. Hi, the attached patch does the following: * move input/Config.in in front of char/Config.in in all arch/*/config.in (already done in t7p7 for x86) * fix a small uncleanliness in char/keyboard.c, replace plain_map with key_maps[0] to enable correct runtime switching of tables * update keycode translation table in input/keybdev.c (checked with Vojtech) Linus, please apply. Franz. diff -uprN linux-2.4.0-test7-pre7-clean/arch/alpha/config.in linux-2.4.0-test7-pre7/arch/alpha/config.in --- linux-2.4.0-test7-pre7-clean/arch/alpha/config.in Tue Aug 22 23:50:39 2000 +++ linux-2.4.0-test7-pre7/arch/alpha/config.in Wed Aug 23 20:10:21 2000 @@ -300,6 +300,8 @@ if [ "$CONFIG_CD_NO_IDESCSI" != "n" ]; t fi endmenu +source drivers/input/Config.in + source drivers/char/Config.in #source drivers/misc/Config.in @@ -335,7 +337,6 @@ fi endmenu source drivers/usb/Config.in -source drivers/input/Config.in mainmenu_option next_comment comment 'Kernel hacking' diff -uprN linux-2.4.0-test7-pre7-clean/arch/arm/config.in linux-2.4.0-test7-pre7/arch/arm/config.in --- linux-2.4.0-test7-pre7-clean/arch/arm/config.in Tue Aug 22 23:50:39 2000 +++ linux-2.4.0-test7-pre7/arch/arm/config.in Wed Aug 23 20:11:02 2000 @@ -312,6 +312,8 @@ if [ "$CONFIG_ISDN" != "n" ]; then fi endmenu +source drivers/input/Config.in + source drivers/char/Config.in if [ "$CONFIG_ARCH_ACORN" = "y" -a \ "$CONFIG_BUSMOUSE" = "y" ]; then @@ -354,8 +356,6 @@ if [ "$CONFIG_ARCH_ACORN" = "y" -o \ fi source drivers/usb/Config.in -source drivers/input/Config.in - mainmenu_option next_comment comment 'Kernel hacking' diff -uprN linux-2.4.0-test7-pre7-clean/arch/ia64/config.in linux-2.4.0-test7-pre7/arch/ia64/config.in --- linux-2.4.0-test7-pre7-clean/arch/ia64/config.inTue Aug 22 23:50:39 2000 +++ linux-2.4.0-test7-pre7/arch/ia64/config.in Wed Aug 23 20:12:08 2000 @@ -160,6 +160,8 @@ endmenu fi # !HP_SIM +source drivers/input/Config.in + source drivers/char/Config.in #source drivers/misc/Config.in @@ -191,7 +193,6 @@ fi endmenu source drivers/usb/Config.in -source drivers/input/Config.in fi # !HP_SIM diff -uprN linux-2.4.0-test7-pre7-clean/arch/mips/config.in linux-2.4.0-test7-pre7/arch/mips/config.in --- linux-2.4.0-test7-pre7-clean/arch/mips/config.inTue Aug 22 23:50:39 2000 +++ linux-2.4.0-test7-pre7/arch/mips/config.in Wed Aug 23 20:13:27 2000 @@ -293,6 +293,8 @@ if [ "$CONFIG_ISA" = "y" -o "$CONFIG_PCI endmenu fi +source drivers/input/Config.in + if [ "$CONFIG_DECSTATION" != "y" -a \ "$CONFIG_SGI_IP22" != "y" ]; then source drivers/char/Config.in @@ -378,7 +380,6 @@ if [ "$CONFIG_SGI_IP22" = "y" ]; then fi source drivers/usb/Config.in -source drivers/input/Config.in mainmenu_option next_comment comment 'Kernel hacking' diff -uprN linux-2.4.0-test7-pre7-clean/arch/mips64/config.in linux-2.4.0-test7-pre7/arch/mips64/config.in --- linux-2.4.0-test7-pre7-clean/arch/mips64/config.in Tue Aug 22 23:50:40 2000 +++ linux-2.4.0-test7-pre7/arch/mips64/config.inWed Aug 23 20:14:08 2000 @@ -208,6 +208,8 @@ if [ "$CONFIG_CD_NO_IDESCSI" != "n" ]; t fi endmenu +source drivers/input/Config.in + source drivers/char/Config.in #source drivers/misc/Config.in @@ -248,7 +250,6 @@ if [ "$CONFIG_SGI_IP22" = "y" ]; then fi source drivers/usb/Config.in -source drivers/input/Config.in mainmenu_option next_comment comment 'Kernel hacking' diff -uprN linux-2.4.0-test7-pre7-clean/arch/ppc/config.in linux-2.4.0-test7-pre7/arch/ppc/config.in --- linux-2.4.0-test7-pre7-clean/arch/ppc/config.in Tue Aug 22 23:50:40 2000 +++ linux-2.4.0-test7-pre7/arch/ppc/config.in Wed Aug 23 20:14:32 2000 @@ -262,6 +262,8 @@ comment 'Console drivers' source drivers/video/Config.in endmenu +source drivers/input/Config.in + source drivers/char/Config.in source drivers/media/Config.in @@ -287,7 +289,6 @@ source arch/ppc/8260_io/Config.in fi source drivers/usb/Config.in -source drivers/input/Config.in mainmenu_option next_comment comment 'Kernel hacking' diff -uprN linux-2.4.0-test7-pre7-clean/drivers/char/keyboard.c linux-2.4.0-test7-pre7/drivers/char/keyboard.c --- linux-2.4.0-test7-pre7-clean/drivers/char/keyboard.cTue Aug 1 04:36:10 2000 +++ linux-2.4.0-test7-pre7/drivers/char/keyboard.c Wed Aug 23 20:06:21 2000 @@ -322,7 +322,7 @@ void handle_scancode(unsigned char scanc compute_shiftstate(); kbd->slockstate = 0; /* play it safe */ #else - keysym = U(plain_map[keycode]); + keysym = U(key_maps[0][keycode]); type = KTYP(keysym); if (type == KT_SHIFT) (*key_handler[type])(keysym & 0xff, up_flag); @@ -750,7 +750,7 @@ void compute_shiftstate(void) k = i*BITS_PER_LONG; for(j=0; j
[2.4.0test6] IPv6 link-local TCP still slightly broken
The application that triggers this problem is npoll (to be found at http://www.fefe.de/ncp/). Basically, it consists of two parts, npush and npoll. npush will send IPv6 multicast packets to the network and npoll will use them to see where it has to connect(). The multicast packets are send out on eth0, and (I had a bug report about this earlier) the IPv6 scope_id now signals the interface as eth0, too. npoll then tries to connect to my own link local address on eth0. This fails horribly. Here is a tcpdump: 00:14:38.506140 ::1.32796 > fe80::260:67ff:fe33:d15b.8002: S 3266263975:3266263975(0) win 32144 00:14:38.506180 fe80::260:67ff:fe33:d15b.8002 > ::1.32796: S 3269115708:3269115708(0) ack 3266263976 win 32144 00:14:38.506191 ::1.32796 > fe80::260:67ff:fe33:d15b.8002: R 3266263976:3266263976(0) win 0 00:14:41.502287 ::1.32796 > fe80::260:67ff:fe33:d15b.8002: S 3266263975:3266263975(0) win 32144 00:14:41.502316 fe80::260:67ff:fe33:d15b.8002 > ::1.32796: R 1025851588:1025851588(0) ack 1 win 0 Due to another bug that I haven't isolated yet, the packets are actually received twice by tcpdump. I edited the duplicates away. Please note that this traffic was captured off lo, not eth0, so although I specified eth0 as interface, the SYN packet is sent over lo. And, the source IP is ::1, the loopback IP. Apparently, through some major kludge somewhere, the kernel is allowed to send a packet from an eth0 link-local address to ::1 on lo, but the receiver code understands that this can't be right and tries to reset the connection. Please note that the reset is apparently never seen by the other side, though, so the connect() system call eventually times out. This is just a dump of the first seconds. I don't think that "::1" is the proper source address. This should be changed to fe80::260:67ff:fe33:d15b, my link-local address. Then, the lo code should be changed to allow packets to and from any of my link-local addresses. Any comments? Does this make any sense? I am not sure if my resubscription on linux-kernel worked (haven't received a confirmation yet), and I am not subscribed to netdev yet, so please carbon-copy comments to me. Thanks. Felix - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: If loadable modules are covered by Linux GPL?
On Tue, Aug 29, 2000 at 05:11:04PM -0400, "Richard B. Johnson" <[EMAIL PROTECTED]> wrote: > Really? "inline functions" were done by Borland, Microsoft, Intermetrics, > and probably every other compiler vendor, starting with Pascal, then > doing the same thing with 'C'. This is hardly a GNU-ism. Yes, and functions were also used before, but still the GPL applies to *some* functions, just as it applies to some *inline* functions. > Note from "COPYING": which does not apply to functions from header files (and the GPL includes these, a common problem). -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: If loadable modules are covered by Linux GPL?
"Richard B. Johnson" <[EMAIL PROTECTED]> writes: > Even M$ doesn't require that I give proprietary information away. > If Linux wants to become the new standard for the computing industry, > GPL or whatever can't claim any ownership of the work a company > has done while using it. This almost seems like a troll. We who write GPLed software don't claim ownership of other's work--we just specify the conditions under which the others can use *our* work. What's wrong with that? Are you saying we should just give our work away to you with compensation at all? You Communist! ;-) Regarding Microsoft, I suppose that's true. Microsoft is about taking control away from users and giving it to vendors, and the GPL is, to a degree, the reverse. The smart user will gravitate towards GPLed software, and in a fair and competitive marketplace, the smart vendors will follow. --Mike -- [O]ne of the features of the Internet [...] is that small groups of people can greatly disturb large organizations. --Charles C. Mann - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Raid 1/upgrade to 2.2.16
On Tue, 29 Aug 2000, David Lang wrote: > One thing is that Redhat patches their kernels so the stock kernels > willnot work with the tools that redhat ships. Nope. You need the RAID patches, even without RH kernels. > another problem appears to be the fact that your new kernel is attempting > to load the modules created for the old kernel. > > I can't tell you the redhat way of doing a kernel upgrade (things like > this are one of the resons I don't use redhat) but if you are useing the > stock kernel you will need to first apply the raid-0.9x patches (I don't > have the location handy, it is in the recent archive if they are available > somewhere) and for the modules issue, when you compile a new kernel you > will need to do a 'make modules' and 'make modules_install' unless you > configure the kernel include everything you need for your server and not > use modules. The patches are on the site of Ingo. www.redhat.com/ingo/ or something close like that. Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[patchlet] Documentation fix for MultiGate/COMX
Hi. The COMX driver does an #error (in drivers/net/wan/comx.c) if procfs support is not enabled. This is not reflected in the help text. The following patch updates the help text to say the Right Thing. --- linux-240test8-pre1/Documentation/Configure.helpTue Aug 29 22:20:51 2000 +++ linux/Documentation/Configure.help Wed Aug 30 00:14:24 2000 @@ -7864,6 +7864,9 @@ and using COMX interfaces. Further info on these cards can be found at http://www.itc.hu or <[EMAIL PROTECTED]>. + You must say Y to "/proc file system support" (CONFIG_PROC_FS) to + use this driver. + If you want to compile this as a module, say M and read Documentation/modules.txt. The module will be called comx.o. -- Regards, Rasmus([EMAIL PROTECTED]) ``When the president does it, that means that it is not illegal.'' --Richard M. Nixon, TV interview with David Frost, 1977 May 4 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Problem booting 2.4.0-test series
I have seen strange problems sometimes with using menuconfig or xconfig completely go away when creating my config as simply `make config` Sometimes a strange dependency comes in.. Since your problem is a little vague, and seems to be on a generic paltform, I would suggest that it is a problem with the compilation procedures. Narrow that down first. On Wed, 31 Dec 1969, root wrote: > With all of 2.4.0-test series, and at least 2.3.51, I've been unable to > boot. I'm in the process of getting other 2.3 kernels, to see where the > problem was introduced. > > My PC hangs after "OK, booting the kernel". I have a pentium, but this > problem occurs whether I configure the kernel as pentium, 486 or 386. > > I've never had a problem with the 2.2 series, and currently use 2.2.16. Can > anyone suggest a way for me to track down this problem. I cant really debug > tanything, since I hang before the boot process is anywhere near complete. > > Any suggestions gratefully received. -- Michael Peddemors - Senior Consultant Unix Administration - WebSite Hosting Network Services - Programming Wizard Internet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604) 589-0037 Beautiful British Columbia, Canada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] af_rose.c: s/suser/capable/ + micro cleanups
Em Tue, Aug 29, 2000 at 10:31:22PM +0100, Philipp Rumpf escreveu: > On Sun, Aug 27, 2000 at 10:28:14PM +0200, Kenneth Johansson wrote: > > Arnaldo Carvalho de Melo wrote: > > > > > #include > > > @@ -510,10 +511,7 @@ > > > if (put_user(len, optlen)) > > > return -EFAULT; > > > > > > - if (copy_to_user(optval, , len)) > > > - return -EFAULT; > > > - > > > - return 0; > > > + return copy_to_user(optval, , len) ? -EFAULT : 0; > > > } > > > > What is this are you trying to compress the source code ? > > I like the old way better. I think it is faster to read and understand. > > Same here. Linus, I didn't actually interpret your mail on the subject as > proposing changes like the one above. Care to enlighten this a bit ? I understood it as: don't use copy.*user_ret, use it as: return copy_to_user(...) ? -EFAULT : 0; which doesn't mean that we should send patches _just_ to make it use ?:, but in the process of doing other needed cleanups (s/suser/capable/, checking put_user return, getting rid of check_region to avoid races, and other things that I've posted as being my current TODO list) we could do this as well to make the source code smaller and more easier to read (yes, this is debatable, I think it becomes more clean, other think otherwise, I'm just following what Linus said he prefer). Again, I apreciate a lot receiving feedbacks like this, it helps me in deciding what to do next to help clean and fix parts of the kernel that I can with the knowledge I have, which will be enhanced (I'm learning a lot doing these things, thank you for allowing me to do this) when I receive feedback 8) - Arnaldo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Uninterruptible Sleep ???
Hi, Before calling get_pid the state of child is set to TASK_UNINTERRUPTIBLE and after get_pid it is changed to TASK_RUNNNING.Why ?? Is it possbile that a process may leave the CPU during get_pid? Can any body tell me how linux is ensuring that scheduling can not happen when a process is executing in a system call and timer interrupt has occured. Please do a CC to me also. Thanks in advance Ashish __ Do You Yahoo!? Yahoo! Mail - Free email you can access from anywhere! http://mail.yahoo.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Problem booting 2.4.0-test series
> > > My PC hangs after "OK, booting the kernel". I have a pentium, but this problem >occurs whether I configure the kernel as pentium, 486 or 386. > > it's worth asking: what compiler are you using? gcc 2.95.2 I don't really know what other info is needed to track down the bug. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Raid 1/upgrade to 2.2.16
On Tue, 29 Aug 2000, Alan Cox wrote: > the full details are in the support db http://www.redhat.com/support/docs/howto/kernel-upgrade/kernel-upgrade.html to be exact. _ Richard H. Fifarek [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to [EMAIL PROTECTED]
Re: [patch] scheduler bugfix, SMP, 2.4.0-test7
David S. Miller writes: > The problem not FASTCALL, which is a NOP on sparc anyways. The > problem is the fact that people expect the following to work: ... > And it doesn't on Sparc because the flags are stored in the same CPU > register as the current register window. > > Therefore you cannot restore irq flags in a different function than > the one in which you obtained them. So you need an alternate calling convention that works right. Surely something like the Alpha calling convention will work. Call it "FASTCALL". :-) The window can sit right where it is. Nobody put a gun to your head and said "you will use the register window hardware". Well, I hope not. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Raid 1/upgrade to 2.2.16
David Lang wrote: > > One thing is that Redhat patches their kernels so the stock kernels > willnot work with the tools that redhat ships. > > another problem appears to be the fact that your new kernel is attempting > to load the modules created for the old kernel. > Yes. You need to run mkinitrd in order to create a ram disk with the new 2.2.16 modules that you just made. There's a man page for mkinitrd that should help... Paul > I can't tell you the redhat way of doing a kernel upgrade (things like > this are one of the resons I don't use redhat) but if you are useing the > stock kernel you will need to first apply the raid-0.9x patches (I don't > have the location handy, it is in the recent archive if they are available > somewhere) and for the modules issue, when you compile a new kernel you > will need to do a 'make modules' and 'make modules_install' unless you > configure the kernel include everything you need for your server and not > use modules. > > David Lang > > On Tue, 29 Aug 2000, Kevin Jones wrote: > > > Date: Tue, 29 Aug 2000 15:09:01 -0600 > > From: Kevin Jones <[EMAIL PROTECTED]> > > To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>, > > "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>, > > "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> > > Subject: Raid 1/upgrade to 2.2.16 > > > > Installed Redhat 6.2. Set up 6 md's as Raid 1 during installation going > > across two 9 gig scsi drives. Installation went perfectly. Decided to > > upgrade to 2.2.16. Went through the regular steps to installing a kernel. > > Included the Raid 1 support, SCSI support, and initrd support in xconfig. > > Made the 2.2.16 kernel as "newlinux" in lilo. Copied initrd-2.2.14-5.0.img > > to init-2.2.16.0.img for the ramdisk. Relinked System.map to the System.map > > made by the make dep. Relinked Linux in /usr/src to the new kernel area. > > > > Now, all that being said, when I boot up the newlinux in lilo, I get this: > > > > > > Loading ncr53c8xx module > > /lib/ncr53c8xx.o: kernel-module version mismatch > > /lib/ncr53c8xx.o was compiled for kernel version 2.2.14-5.0 > > while this kernel version is 2.2.16. > > > > Loading raid1 module > > /lib/raid1.o: kernel-module version mismatch > > /lib/raid1.o was compiled for kernel version 2.2.14-5.0 > > while this kernel version is 2.2.16. > > > > Opps! Unable to load md0 > > KERNEL PANIC: Unable to load root filesystem at 09:00 > > > > > > I have tried a few things to "attempt" and patch the raid and scsi drivers, > > but nothing seems to work. Have a missed a step somewhere or are there new > > drivers/patches I should be looking for? I have tried installing > > raidtools-19990824-0.90, but to no avail. > > > > The Software-Raid-HOWTO does explain somethings, however it is based upon > > making the raid from scratch once you are logged into the system on regular > > sdaX or hdaX partitions. Do I have to set raid up in this manner in order to > > get this working? > > > > Sorry for posting this to 3 different mailing lists, but this seems to > > relate to all three. > > > > \\|// > > (o^o) > > +-+-+-+-+-+-+-+-oOOo-(_)-oOOo-+-+-+-+-+--+-+ > > Kevin C Jones > > System Administrator - NOC (Engineering) > > Shaw Cablesystems G.P. [EMAIL PROTECTED] > > Voice:(403)303-4812Fax:(403)750-4504 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > > - > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > > the body of a message to [EMAIL PROTECTED] > > Please read the FAQ at http://www.tux.org/lkml/ > > > - > To unsubscribe from this list: send the line "unsubscribe linux-scsi" in > the body of a message to [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] af_rose.c: s/suser/capable/ + micro cleanups
On Sun, Aug 27, 2000 at 10:28:14PM +0200, Kenneth Johansson wrote: > Arnaldo Carvalho de Melo wrote: > > > #include > > @@ -510,10 +511,7 @@ > > if (put_user(len, optlen)) > > return -EFAULT; > > > > - if (copy_to_user(optval, , len)) > > - return -EFAULT; > > - > > - return 0; > > + return copy_to_user(optval, , len) ? -EFAULT : 0; > > } > > What is this are you trying to compress the source code ? > I like the old way better. I think it is faster to read and understand. Same here. Linus, I didn't actually interpret your mail on the subject as proposing changes like the one above. Care to enlighten this a bit ? Philipp Rumpf - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Raid 1/upgrade to 2.2.16
> I can't tell you the redhat way of doing a kernel upgrade (things like > this are one of the resons I don't use redhat) but if you are useing the Mostly rpm -Uvh kernel-foo.i386.rpm the full details are in the support db > stock kernel you will need to first apply the raid-0.9x patches (I don't > have the location handy, it is in the recent archive if they are available http://people.redhat.com/~mingo - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to [EMAIL PROTECTED]
Re: [PATCH] Fix disk statistic reporting to include all disks
On Tue, 29 Aug 2000, Bill Wilson wrote: > > This patch fixes the enhanced disk statistics to report all drives > so IDE1 - IDE3 (/dev/hdc - /dev/hdh) can be monitored. Why not just do this right, and move the statistics into the "queue structure". Get rid of that ugly kstat thing. Get rid of all the special case lookups. We already need to have the queue structure to do the queuing (surprise, surprise), so suddenly statistics are (a) cheap and (b) right. So then /proc just needs to be changed to look at the queues instead of looking at this kstat thing. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Raid 1/upgrade to 2.2.16
One thing is that Redhat patches their kernels so the stock kernels willnot work with the tools that redhat ships. another problem appears to be the fact that your new kernel is attempting to load the modules created for the old kernel. I can't tell you the redhat way of doing a kernel upgrade (things like this are one of the resons I don't use redhat) but if you are useing the stock kernel you will need to first apply the raid-0.9x patches (I don't have the location handy, it is in the recent archive if they are available somewhere) and for the modules issue, when you compile a new kernel you will need to do a 'make modules' and 'make modules_install' unless you configure the kernel include everything you need for your server and not use modules. David Lang On Tue, 29 Aug 2000, Kevin Jones wrote: > Date: Tue, 29 Aug 2000 15:09:01 -0600 > From: Kevin Jones <[EMAIL PROTECTED]> > To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>, > "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>, > "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> > Subject: Raid 1/upgrade to 2.2.16 > > Installed Redhat 6.2. Set up 6 md's as Raid 1 during installation going > across two 9 gig scsi drives. Installation went perfectly. Decided to > upgrade to 2.2.16. Went through the regular steps to installing a kernel. > Included the Raid 1 support, SCSI support, and initrd support in xconfig. > Made the 2.2.16 kernel as "newlinux" in lilo. Copied initrd-2.2.14-5.0.img > to init-2.2.16.0.img for the ramdisk. Relinked System.map to the System.map > made by the make dep. Relinked Linux in /usr/src to the new kernel area. > > Now, all that being said, when I boot up the newlinux in lilo, I get this: > > > Loading ncr53c8xx module > /lib/ncr53c8xx.o: kernel-module version mismatch > /lib/ncr53c8xx.o was compiled for kernel version 2.2.14-5.0 > while this kernel version is 2.2.16. > > Loading raid1 module > /lib/raid1.o: kernel-module version mismatch > /lib/raid1.o was compiled for kernel version 2.2.14-5.0 > while this kernel version is 2.2.16. > > Opps! Unable to load md0 > KERNEL PANIC: Unable to load root filesystem at 09:00 > > > I have tried a few things to "attempt" and patch the raid and scsi drivers, > but nothing seems to work. Have a missed a step somewhere or are there new > drivers/patches I should be looking for? I have tried installing > raidtools-19990824-0.90, but to no avail. > > The Software-Raid-HOWTO does explain somethings, however it is based upon > making the raid from scratch once you are logged into the system on regular > sdaX or hdaX partitions. Do I have to set raid up in this manner in order to > get this working? > > Sorry for posting this to 3 different mailing lists, but this seems to > relate to all three. > > \\|// > (o^o) > +-+-+-+-+-+-+-+-oOOo-(_)-oOOo-+-+-+-+-+--+-+ > Kevin C Jones > System Administrator - NOC (Engineering) > Shaw Cablesystems G.P. [EMAIL PROTECTED] > Voice:(403)303-4812Fax:(403)750-4504 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to [EMAIL PROTECTED]
Re: www.crucial.com won't talk to 2.4.0-test7 system
Date:Tue, 29 Aug 2000 17:35:59 +0200 From: "Andi Kleen" <[EMAIL PROTECTED]> Try echo 0 > /proc/sys/net/ipv4/tcp_ecn And if this makes it work send a very large and loud complaint to [EMAIL PROTECTED] telling them to fix their firewalls not to block IP traffic from hosts implementing ECN. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: SCO: "thread creation is about a thousand times faster than on
Alexander Viro writes: > On Tue, 29 Aug 2000, Albert D. Cahalan wrote: [interaction w/ setuid, close-on-exec, and personality pseudo-roots] > We _have_ this interaction. In case you've missed it, sys_personality() > that really happens to change personality unshares fs_struct. Has to. > Rule: you do crap, _you_ pay with inconveniences. Point-blank restriction > of sharing anything to the beasts that run the same binary is *CRAP*. BTW, I've yet to see a good use for all-but-VM sharing after exec. Unsharing everything in the exec lets one avoid a system call. Unsharing nothing makes exec smaller and faster. > Same > moronic "it's a part of process" approach. Totally unjustified in case > of Linux, because here thread == process. Get over the POSIX model. I'm very much not obsessed with kernel-enforced POSIX, but it is good to reduce the hoops glibc has to jump through. Reality involves getting pthreads to be half-way fast. If a pthread_exec() system call would really help, why not? As a separate system call it shouldn't be too offensive. > VM is > just one of the resources. There are legitimate uses for sharing between > different programs. Your proposal prohibits them. Proposal 'c' is that way. If you agree that "VM is just one of the resources" but think that there are "uses for sharing between different programs", proposal 'a' is for you. Want to unshare VM? Do it, with the new unshare() call. Want rope to hang yourself? Do an exec while multiple threads are running, most of which will crash when the VM changes right under them. If a close-on-exec shared with the child would hurt, Don't Do That. Personalities make life fun when you randomly exec unknown executables into your thread group. This is clean and fast. Only the setuid wart needs to be handled. All the other kernel bloat just goes away. >> The explanation still sucks quite severely. The personality and setuid >> problems are particulary gross, because they depend on what executable >> is being started. Behavior changes drasticly when one merely >> recompiles with an alternate personality. > > Which is kinda the point of personality, no? Sure, but normally this disease only afflicts one task. With the personality code doing an unshare, there is no way for the original thread group to know what will remain shared after the exec. For an app, getting back an error code may be most desirable. (not saying the implementation would be trivial) >> If you simply unshare on exec, all this special-case crap goes away. >> The "kill other threads" option also has this nice property, and the >> "let user shoot foot" option only suffers from the setuid wart. > > Look: your sematics can be trivially achieved with the > share-whatever-we-can one. Noting could be easier, > unshare(CLONE_ALL); > execve(...); > and that's it - precisely what were asking for, unambiguous, > works regardless of the execve() details. Now, try to get the > other way round. Can't do it. Hey, that works for the VM too. An "unshare if you like" policy lets one have plenty of clean and fast rope. > "If we shove this box into the car half of us will have to take > the bus" is fine and sane. > "... so let's make everyone always take the bus" is straight from > the Dilbert-land. Fine, plan 'a' then: "If you are stupid enough to pack a full load of people into a car that is already half full, some of the people might get injured or killed. Don't do that." Either plan will reduce the special-case crap. The POSIX way also works, if you're into that sort of thing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] scheduler bugfix, SMP, 2.4.0-test7
Date: Tue, 29 Aug 2000 16:13:22 +0100 (BST)
From: Alan Cox <[EMAIL PROTECTED]>
> Ingo, the local flags stuff on Sparc, remember?
Maybe its time to have FASTCALLFLAGS that is different for sparc ?
The problem not FASTCALL, which is a NOP on sparc anyways. The
problem is the fact that people expect the following to work:
void foo(unsigned long flags)
{
restore_flags(flags);
}
void bar(void)
{
unsigned long flags;
save_flags(flags);
foo(flags);
}
And it doesn't on Sparc because the flags are stored in the same CPU
register as the current register window.
Therefore you cannot restore irq flags in a different function than
the one in which you obtained them.
Later,
David S. Miller
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: df -k shows WRONG information
Hi, (removed linux-smp as irrelevant) sorry, I haven't read your message but 99.99% of claims that "df doesn't work" originate from people who don't suspect about old good minroot thing, i.e. check out -m option of mke2fs(8) command. Regards, Tigran On Mon, 28 Aug 2000, Joe wrote: > FYI: I am sending this to both SMP and kernel as I have an SMP > machine. I don't know if there is a list for the ext2 filesystem > as I suspect that is where the problem is/was. > > Machine 'Dual' 233MMX with 128 Meg of RAM. Kernel 2.2.14, WD > 6Gig drive as hdb, Seagate 2.1 as hda. Linux is on hdb. > > Last night I did an rm -f on 4 files. The files sizes were 35M, > 390M, 250M, and 150M. After doing this I did a df -k. df -k > showed me having used 68 percent of my hard drive. So I then > did a du -s /* to see why. A few days earlier I had only used > 32% and had not installed ANYTHING. > du -s showed a file that was 2.6 Gig. It was .xsession-errors. > I then did an rm -f on this file. > > I again did a df -k and it still showed 68 percent of my disk > being used. So I repeated the du -s /*. This time du -s and df > -k did not add up. When I added up the output from du -s I had > about 35 % of my disk used. > > I rebooted the system, (windows thinking that this would help.) > It did not. du -s and df -k still showed different amounts of > disk spaced being used. I then did a full shutdown and waited a > few minutes then restarted. For some reason this time it told > me my disk was corrupt, and it ran fsck. After this completed > and I logged in, I did a df -k and it now showed 35% being used. > > I thought that you all should know that this happened and do not > know if it had something to do with smp or what part of the > kernel as I am NOT a kernel programmer. > > My only guess is that the pointers to these files got removed > but the kernel /fs never removed some internel pointer or some > reference to this data somewhere??? > > thanks Joe > > > > __ > Do You Yahoo!? > Yahoo! Mail - Free email you can access from anywhere! > http://mail.yahoo.com/ > - > To unsubscribe from this list: send the line "unsubscribe linux-smp" in > the body of a message to [EMAIL PROTECTED] > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Problem booting 2.4.0-test series
On Tue, 29 Aug 100, root wrote: > With all of 2.4.0-test series, and at least 2.3.51, I've been unable to boot. I'm in >the process of getting other 2.3 kernels, to see where the problem was introduced. > > My PC hangs after "OK, booting the kernel". I have a pentium, but this problem >occurs whether I configure the kernel as pentium, 486 or 386. > > I've never had a problem with the 2.2 series, and currently use 2.2.16. Can anyone >suggest a way for me to track down this problem. I cant really debug tanything, since >I hang before the boot process is anywhere near complete. > > Any suggestions gratefully received. > Yes, put a `mem=whatever` parameter in your /etc/lilo.conf, i.e., append="mem=128M" ... then install/reboot. There have been some problems with the amount of BIOS reported memory being scrambled during boot. This should work around the problem. Cheers, Dick Johnson Penguin : Linux version 2.2.15 on an i686 machine (797.90 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: If loadable modules are covered by Linux GPL?
On Tue, 29 Aug 2000, Matt D. Robinson wrote: > I agree with Simon here. I'd personally like to see some form of > GNU GPL Loadable Module Compliance Standard for all loadable modules. > It isn't enough to go with the loose interpretation of the GNU GPL as > it applies to inclusion of header files, system call interfaces, > re-defined function pointers for operations tables, inline functions, > macro #defines, etc. > > Who is best qualified to judge whether something must be released > as GPL or not? In addition, are there specific lawyers to speak with > about kernel related GPL concerns before releasing a driver/module? > > --Matt > > Simon Richter wrote: > > On Tue, 29 Aug 2000, Mike A. Harris wrote: > > > #include'ing header files is not necessarily ok. Some headers > > > include "inline functions" which is GPL code. Such inclusion in > > > a module makes that module have to comply with GPL. > > > > I think this needs to be resolved ASAP. I don't have kernel sources handy, > > so I cannot tell you whether the functions are actually worth being > > protected (inb/outb doesn't belong to this group really), > > > >Simon Really? "inline functions" were done by Borland, Microsoft, Intermetrics, and probably every other compiler vendor, starting with Pascal, then doing the same thing with 'C'. This is hardly a GNU-ism. Note from "COPYING": NOTE! This copyright does *not* cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does *not* fall under the heading of "derived work". Also note that the GPL below is copyrighted by the Free Software Foundation, but the instance of code that it refers to (the Linux kernel) is copyrighted by me and others who actually wrote it. Linus Torvalds If I make a module, that cost my company hundreds of thousands of dollars to develop (back-projector for a CAT Scanner comes to mind), there is no way in hell that I will give this to a competitor by releasing the source-code. Even though a competitor will find it useless without the hardware to which it interfaces, the competitor will gain knowledge of my product(s), build them without investing in any Engineering costs, and put me out of business. Even M$ doesn't require that I give proprietary information away. If Linux wants to become the new standard for the computing industry, GPL or whatever can't claim any ownership of the work a company has done while using it. The Linux kernel didn't come with a "back-projector" module. Therefore, when I invest the time and money to make one, I certainly don't have to give it away. It is quite different if, for instance, I need to use a built-in system such as TCP/IP or SCSI and in the progress of my work I add functionality or fix bugs. Under GPL, I am required to supply any such changes (if asked). Cheers, Dick Johnson Penguin : Linux version 2.2.15 on an i686 machine (797.90 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Problem booting 2.4.0-test series
With all of 2.4.0-test series, and at least 2.3.51, I've been unable to boot. I'm in the process of getting other 2.3 kernels, to see where the problem was introduced. My PC hangs after "OK, booting the kernel". I have a pentium, but this problem occurs whether I configure the kernel as pentium, 486 or 386. I've never had a problem with the 2.2 series, and currently use 2.2.16. Can anyone suggest a way for me to track down this problem. I cant really debug tanything, since I hang before the boot process is anywhere near complete. Any suggestions gratefully received. -- Craig Wilkie [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ll_rw_blk.c fails to merge requests. Help!
>
> >reqfree-batching-3Name: reqfree-batching-3
> > Type: Plain Text (text/plain)
>
> This one works even better.
>
>
> + list_add(>table, >pending_freelist);
> + if (++q->pending_free > 64) {
>^
I have two comments about this patch. (the reqfree-batching-3)
First. Couldn't it end up indefinitely starving a writer?
Assume the free_list is empty (all requests in use), and the
pending_freelist is empty. (So q->queue_requests ==
QUEUE_NR_REQUESTS). A write request
comes in and is blocked in __get_request_wait. Now 64 ( 64 == 1/4 of
QUEUE_NR_REQUESTS ) requests complete. The pending_freelist is spliced
into the free_list and the wait_queue is woken. Now the writer will
wake
up in __get_request_wait, but will not succeed in get_request so it
will
go back to sleep (queue_requests == 3/4 of QUEUE_NR_REQUESTS which is >
than 1/2 of QUEUE_NR_REQUESTS). Meanwhile the 64 requests can be used
up
by a) readers that were blocking, or b) new readers. This could
continue
ad infinitum...
Second. At queue destroy time (blk_cleanup_queue) the pending_list
should
be spliced into the free_list so they won't get leaked.
Alternatively,
add a 'count -= blk_cleanup_queue(>pending_list)'.
David Mansfield
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
RE: [patch] scheduler bugfix, SMP, 2.4.0-test7
On 29-Aug-2000 Ingo Molnar wrote: > i agree fully. The attached patch against test8-pre1 changes > schedule_idle() from inline to FASTCALL - things look much nicer with this > one applied. > > -static inline void reschedule_idle(struct task_struct * p, unsigned long flags) > +static FASTCALL(void reschedule_idle(struct task_struct *, unsigned long)); You can't do this. SPARC requires you to restore the flags in the same function where you saved them because they contain register window status. You *have* to inline the part that drops the run queue lock. The bulk of the function though doesn't need to be inlined. See how it is done in my scheduler patch. -- Dimitris Michailidis[EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: If loadable modules are covered by Linux GPL?
I agree with Simon here. I'd personally like to see some form of GNU GPL Loadable Module Compliance Standard for all loadable modules. It isn't enough to go with the loose interpretation of the GNU GPL as it applies to inclusion of header files, system call interfaces, re-defined function pointers for operations tables, inline functions, macro #defines, etc. Who is best qualified to judge whether something must be released as GPL or not? In addition, are there specific lawyers to speak with about kernel related GPL concerns before releasing a driver/module? --Matt Simon Richter wrote: > On Tue, 29 Aug 2000, Mike A. Harris wrote: > > #include'ing header files is not necessarily ok. Some headers > > include "inline functions" which is GPL code. Such inclusion in > > a module makes that module have to comply with GPL. > > I think this needs to be resolved ASAP. I don't have kernel sources handy, > so I cannot tell you whether the functions are actually worth being > protected (inb/outb doesn't belong to this group really), > >Simon - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ll_rw_blk.c fails to merge requests. Help!
> > Aug 26 18:09:19 Jay kernel: W 914680 252 > > Aug 26 18:09:19 Jay kernel: W 914932 8 > > Aug 26 18:09:19 Jay kernel: W 851976 4 > > Aug 26 18:09:19 Jay kernel: W 914940 252 > > Aug 26 18:09:19 Jay kernel: W 915192 4 > > Aug 26 18:09:19 Jay kernel: W 915196 252 > > Aug 26 18:09:19 Jay kernel: W 915448 12 > > Aug 26 18:09:19 Jay kernel: W 915460 252 > > Aug 26 18:09:19 Jay kernel: W 915712 4 > > Aug 26 18:09:19 Jay kernel: W 915716 252 > > As you have 2K blocks, 252 is the largest number of sectors that can > fit into a request (MAX_SECTORS == 254). > So it looks like you are getting 128k synchronous IO requests, which > are being broken into one 126K request and one 2K request. > > If these were READ requests, I would blame the read-ahead code. It > currently always does synchronous read-ahead (I sent a patch to > linux-kernel a while back but it hasn't made it into test7. I'll > resubmit to Linus. But I assume that the 'W' means that these are > write requests. Yes. > If you are writing out to the block device (cat > /dev/sdxx) then > you would get 128k synchronous requests: block_dev.c(block_write) > collects 64 buffers together and writes them out syncronously. > With a 2k block size, that is 128k. No, I'm doing "cat /dev/zero >file" as usual and it writes a block a time. > > > It also contains some (fairly ugly) code inside #ifdef > > > STRICT_REQUEST_ORDERING which should encourage a strict ordering for > > > threads to get the request structures they are waiting for. > > > > It makes no difference. > > I didn't expect it to, but thanks for checking. I too, but why not to try ? Bye. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ll_rw_blk.c fails to merge requests. Help!
>reqfree-batching-3Name: reqfree-batching-3
> Type: Plain Text (text/plain)
This one works even better.
+ list_add(>table, >pending_freelist);
+ if (++q->pending_free > 64) {
^
I think a fraction of QUEUE_NR_REQUESTS should be better than a fixed
quantity.
Bye.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: DRAM to CPU Frequency Ratio (Athlon)
You also might want to check out Ars Technica's Guide to RAM technologies: http://arstechnica.com/paedia/r/ram_guide/ram_guide.part2-1.html On Tue, 29 Aug 2000, Marc Mutz wrote: > Ookhoi wrote: > > > > Hi Marc, > > > > > > I have two exactly the same Athlon systems at 750MHz and 512 meg memory > > > > (@ 133MHz). In the BIOS there is a option: "DRAM to CPU Frequency > > > > Ratio", which can be 3:3 or 4:3. The Help says: "Using this item to set > > > > the operating frequency of DRAM". > > > > > > > > I just installed Debian on the machines, rebooted, changed one machine > > > > to 3:3, the other was 4:3, and compiled a kernel on both of them. The > > > > time it took was almost exactly the same (about 5 min 32 sec). The 3:3 > > > > one was 0.24 seconds faster. > > > > > > > > Does Linux ignore the DRAM to CPU Frequency Ratio (if at all possible), > > > > is it just a useless BIOS option (because of hardware limits or > > > > something), or is it not supposed to make the machine faster (if, what > > > > _does_ it do then ;-) ? (the book that came with the machine doesn't > > > > tell me much about the option). > > > > > > > > > > > > > You have PC133-333 RAM installed (PC133-222 SDRAM is still hard to find) > > > which may also be run as PC100-222. So, when you select a ratio of 3:3, > > > then the RAM runs in PC100-222 mode, which is not too much slower than > > > PC133-333: > > > > > > 2*1/100e6 = 1/50e6 is actually smaller than 3*1/133e6 = 1/44e6. > > > > > > There are _many_ factors to SDRAM timing, but the bottomline is that you > > > will only see a difference (of then ca. 5%, which sounds tiny, but is > > > approximately the same gain as when going from a 600 to a 650 MHz CPU) > > > if you use PC133-222 SDRAM. > > > > Thank you for your reaction. Others on the list also said that with a > > kernel compile, disk speed is a bottleneck, not memory. > > > > What is the difference between PC133-333 and PC133-222, and is that also > > the difference between RAM and SDRAM? Do you have an url to more info > > about this (and other factors to SDRAM timing)? TIA! > > > > The full spec: > http://developer.intel.com/technology/memory/pcsdram/spec/index.html > > The most important parameters (from approx. 30?) > > PARAMETER SYMBOL > cycle period t_CK > CAS Latency CL > RAS-to-CAS Delay t_RCD > RAS Precharge Timet_RP > Output Valid from Clock t_AC > RAS Cycle Timet_RC > RAS Active Time t_RAS > > The PC-blah-blah convention is also spec'ed in the above document, but > here comes the short story: > > PC<1/t_CK>- > > where 1/t_CK is in MHz, CL, t_RCD and t_RP are in units of t_CK. > > If you speak German, you can read all that in c't, issue 17/00, pp.166. > > Marc > > -- > Marc Mutz <[EMAIL PROTECTED]>http://marc.mutz.com/Encryption-HOWTO/ > University of Bielefeld, Dep. of Mathematics / Dep. of Physics > > PGP-keyID's: 0xd46ce9ab (RSA), 0x7ae55b9e (DSS/DH) > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Suggestion for laptop suspension
Hi! >> is how to mark memory as "unused". I had a theory that the APM BIOS >> suspend code was checking if the memory was all zero's, and not writing >> such pages to disk. This was a while ago, but a quick test didn't seem >> to bear out this theory. > >Are you sure? Maybe the block of zero memory must be continuous at the >end, in which case fragmentation would certainly spoil this. > > No, I'm not sure. As I said, I did a quick test, and when the obvious > thing didn't bear fruit, I lost interest and dropped it. It could have > been that I screwed up the test somehow. It also could have been that > the BIOS was using some other flag value (0xFF, etc.). There's a lot of > really easy tests that could have been done, that I didn't have time to > do. > > There still is the question of whether anything we do to speed this up > would be laptop specific or not. I'm not an APM BIOS expert, so someone > like Stephen Rothwell would be much better equipped to comment on this > issue. You *dont* need bios support to do suspend-to-disk, as swsusp shows. That is generic across all machines. I believe improving swsusp (it is pretty slow these days, partly because it trashes all caches: it does so by applying artifical memory pressure) is much better project than trying to find out what value do you need in order for BIOS to compress ram. 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] Please read the FAQ at http://www.tux.org/lkml/
avenrun and TASK_UNINTERRUPTIBLE
Hi, Why does (2.2.14) linux/kernel/sched.c::count_active_tasks() consider tasks sleeping with the TASK_UNINTERRUPTIBLE flag to be the same as TASK_RUNNABLE for the avenrun computation? (In 2.3.x the code is in linux/kernel/timer.c) It would seem that a sleeping task shouldn't contribute to the load avg... Thanks in advance, Jim Garlick - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: DRAM to CPU Frequency Ratio (Athlon)
Ookhoi wrote: > > Hi Marc, > > > > I have two exactly the same Athlon systems at 750MHz and 512 meg memory > > > (@ 133MHz). In the BIOS there is a option: "DRAM to CPU Frequency > > > Ratio", which can be 3:3 or 4:3. The Help says: "Using this item to set > > > the operating frequency of DRAM". > > > > > > I just installed Debian on the machines, rebooted, changed one machine > > > to 3:3, the other was 4:3, and compiled a kernel on both of them. The > > > time it took was almost exactly the same (about 5 min 32 sec). The 3:3 > > > one was 0.24 seconds faster. > > > > > > Does Linux ignore the DRAM to CPU Frequency Ratio (if at all possible), > > > is it just a useless BIOS option (because of hardware limits or > > > something), or is it not supposed to make the machine faster (if, what > > > _does_ it do then ;-) ? (the book that came with the machine doesn't > > > tell me much about the option). > > > > > > > > > You have PC133-333 RAM installed (PC133-222 SDRAM is still hard to find) > > which may also be run as PC100-222. So, when you select a ratio of 3:3, > > then the RAM runs in PC100-222 mode, which is not too much slower than > > PC133-333: > > > > 2*1/100e6 = 1/50e6 is actually smaller than 3*1/133e6 = 1/44e6. > > > > There are _many_ factors to SDRAM timing, but the bottomline is that you > > will only see a difference (of then ca. 5%, which sounds tiny, but is > > approximately the same gain as when going from a 600 to a 650 MHz CPU) > > if you use PC133-222 SDRAM. > > Thank you for your reaction. Others on the list also said that with a > kernel compile, disk speed is a bottleneck, not memory. > > What is the difference between PC133-333 and PC133-222, and is that also > the difference between RAM and SDRAM? Do you have an url to more info > about this (and other factors to SDRAM timing)? TIA! > The full spec: http://developer.intel.com/technology/memory/pcsdram/spec/index.html The most important parameters (from approx. 30?) PARAMETER SYMBOL cycle periodt_CK CAS Latency CL RAS-to-CAS Delayt_RCD RAS Precharge Time t_RP Output Valid from Clock t_AC RAS Cycle Time t_RC RAS Active Time t_RAS The PC-blah-blah convention is also spec'ed in the above document, but here comes the short story: PC<1/t_CK>- where 1/t_CK is in MHz, CL, t_RCD and t_RP are in units of t_CK. If you speak German, you can read all that in c't, issue 17/00, pp.166. Marc -- Marc Mutz <[EMAIL PROTECTED]>http://marc.mutz.com/Encryption-HOWTO/ University of Bielefeld, Dep. of Mathematics / Dep. of Physics PGP-keyID's: 0xd46ce9ab (RSA), 0x7ae55b9e (DSS/DH) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: hfs support for blocksize != 512
On Tue, 29 Aug 2000, Roman Zippel wrote: > hfs. For example reading from a file might require a read from a btree > file (extent file), with what another file write can be busy with (e.g. > reordering the btree nodes). And? > I really would prefer that a fs could sleep _and_ can use semaphores, > that would keep locking simple, otherwise it gets only a fscking mess. WTF? HFS does not allow holes. _ALL_ allocations there are process synchronous. What's the problem? Pageout on HFS can not allocate blocks and that's the only process-async method. If you want to sleep at completely arbitrary moments while you are modifying the btree (i.e. in the moments when it's in the inconsistent state and hfs_get_block() would fail) - too bad, you are going to have problems. And not from me - power failure will take care of making your life _very_ painful. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch-2.4.0-test8-pre1] bugfix for init_proc_fs() (fwd)
old habits never die - I keep cc'ing vger.rutgers.edu
-- Forwarded message --
Date: Tue, 29 Aug 2000 19:21:26 +0100 (BST)
From: Tigran Aivazian <[EMAIL PROTECTED]>
To: Linus Torvalds <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Subject: Re: [patch-2.4.0-test8-pre1] bugfix for init_proc_fs()
ok, ok, I admit I cut and pasted my fix from pipefs into procfs TOO
LITERALLY :)
Here is the fixed fix:
--- linux/fs/proc/procfs_syms.c Sat May 13 09:32:35 2000
+++ work/fs/proc/procfs_syms.c Tue Aug 29 19:11:51 2000
@@ -28,7 +28,9 @@
if (!err) {
proc_mnt = kern_mount(_fs_type);
err = PTR_ERR(proc_mnt);
- if (!IS_ERR(proc_mnt))
+ if (IS_ERR(proc_mnt))
+ unregister_filesystem(_fs_type);
+ else
err = 0;
}
return err;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: hfs support for blocksize != 512
Hi, > Darnit, documentation on filesystem locking is there for purpose. First > folks complain about its absence, then they don't bother to read the > bloody thing once it is there. Furrfu... It's great that it's there, but still doesn't tell you everything. > Said that, handling of indirect blocks used to be badly b0rken on all > normal filesystems and it had been fixed only on ext2, so I wouldn't be > amazed if regular files were bad on B-tree style filesystems. Directories > are easy - all requests are process-synchronous (no pageout), no > truncate() in sight, so the life is better. I don't think that files are that easy, at least from what I know now from hfs. For example reading from a file might require a read from a btree file (extent file), with what another file write can be busy with (e.g. reordering the btree nodes). I really would prefer that a fs could sleep _and_ can use semaphores, that would keep locking simple, otherwise it gets only a fscking mess. bye, Roman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: SCO: "thread creation is about a thousand times faster than on
From: "David Howells" <[EMAIL PROTECTED]> > > Would it be possible to make fork() or clone() from a process whose tgid!=pid > reparent the child to the thread group leader automatically? Thus, when the > creating thread goes away, the child is still a child of the "process", and > SIGCHLD is still going to go to the process (leader thread). > No need--- it's userspace-solvable; we just need a rule that says "fork() in a thread is actually a clone(...|CLONE_PARENT,...)" and the magic happens all by itself. > Also all child "processes" and "threads" are then logically children of the > "process", given that a "process" is then defined by the tgid. > > Also my 2p on the execve() problem: if the master thread does an execve(), > there must be a point of no return, at which point all the child threads > should be deleted, IMHO, otherwise they turn into full processes in their own > right, and the thread-signalling framework goes out the window. > > And for a further thought on the subject, is it possible for when a child > thread does an execve(), to wangle the master thread into making this call, > with all other threads SIGSTOP'd until completion (& death) or failure (& > resumption)? (though that's probably better done in userspace) Exactly. Userspace is the key. (We just probably need a 'parent has exec()ed' notification signal in the children, like the current 'parent has exit()ed' one). -az - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.4.0-test4&6 scsi tape problem
Hi, I'm using a sony 12/24GB scsi tape drive on an adaptec scsi controller (on the mainboard) "SCSI storage controller: Adaptec AIC-7890/1 (rev 0)." When i'm using the 2.4.0-test4 or test6 kernels and I run a backup either with tar or with amanda it stops after about 2GB with a tape i/o error, and "mt offline" won't release the tape, I have to reboot to get it out .. even the button on the tapedrive itself won't release the tape. All of this works fine with linux-2.2.16, this is a Dual PII-400 with 256M memory, two 4.5G LVD drives (which seem to work fine under any kernel) and one 9GB ide drive. the Scsi controller is on the Asus mainboard (as i said before) . If you need more info, or I forgot something, or if you want me to test something, just drop me a line .. On a completely unrelated sidenote, how do you debug deadlocks ? My computer seems to hardlock itself on a fairly regular basis when messing with my USB webcam.. It got so irritating that i'm ready to debug it myself, or at least identify the problem, but i have no idea where to start, any information/websites/tools etc. would be very much appreciated.. ps. please CC me on any replies if possible Thanks, Gerard Saraber [EMAIL PROTECTED] http://www.rarcoa.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: cat seem to record with an es1371
On Aug 28, 10:31pm, Alan Cox wrote: } Subject: Re: cat seem to record with an es1371 > > All, I get is silence and the file created when i do record has all 7f > > and 0x80 in > > it. Does anybody have any ideas? > > That sounds like the es1371 is working but your codec or microphone input > has problems. You might want to check the docs for the hardware if you have > access to them and see if the external pre-amps for the input channels are > wired to codec gpio pins or similar. The es137x based cards seem to vary in their handling of input impedance with respect to the microphone. You may want to try flipping the input impedance of the microphone input from its default value. Use the micbias directive to the module load, e.g.: insmod es1371 micbias=1 Also make sure that the microphone is selected as the recording source and the level is turned up. > Alan Greg }-- End of excerpt from Alan Cox As always, Dr. G.W. Wettstein, Ph.D. Enjellic Systems Development, LLC. 4206 N. 19th Ave. Specializing in information infra-structure Fargo, ND 58102development. PH: 701-281-4950WWW: http://www.enjellic.com FAX: 701-281-3949 EMAIL: [EMAIL PROTECTED] -- "According to the philosopher Ly Tin Wheedle, chaos is found in greatest abundance wherever order is being sought. It always defeats order, because it is better organized." -- Terry Pratchett Interesting Times - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] waitqueue optimization, 2.4.0-test7
On Tue, 29 Aug 2000, Richard Henderson wrote: >Actually, if you'll look elsewhere you'll see that you cannot mismatch >the two addresses and expect it to work on all implementations. Good to know, thanks. I guessed the block size depends on the cacheline size that's going to be more than 16bytes. It didn't looked sane anyway ;). Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Adaptec AAA-114UDMA with chipset AIC-7890AB
What is the status of support for the Adaptec AAA-114UDMA with chipset AIC-7890AB under Linux (2.2.16+)? Under RH6.2 and mdk 7.0-2 the aic7xxx module loads with the following problems: scsi0 Adaptec AHA//... (...SCSI) 5.1.28/3.2.4 scsi:1 Host .. (detects 1 hdd that has 0 cyl 0 head 0 mb) ... (does some other things) scsi: Aborting command due to timeout ... being reset, device just continually resets. Since the card is a 4-channel IDE RAID card (but I wouldn't even mind using it without the raid features and doing sw raid myself), I'm not sure if this is supposed to go to the SCSI aic7xxx maintainer or the IDE maintainer. Thanks for any help, Dan Browning Network & Database Administrator Cyclone Computer Systems - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
OT: linux-kernel-announce
Quick question.. when the lists were moved, was linux-kernel-announce moved as well? the lists that majordomo sends out for vger.kernel.org doesn't show it in there. Will that list be coming back? BL. -- Brad Littlejohn | Email:[EMAIL PROTECTED] Unix Systems Administrator, | [EMAIL PROTECTED] Web + NewsMaster, BOFH.. Smeghead! :) | http://www.wizard.com/~tyketto PGP: 1024D/E319F0BF 6980 AAD6 7329 E9E6 D569 F620 C819 199A E319 F0BF - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: hfs support for blocksize != 512
On Tue, 29 Aug 2000, Matthew Wilcox wrote: > On Tue, Aug 29, 2000 at 06:08:04PM +0200, Roman Zippel wrote: > > Anyway, I'm happy about any bug reports, that you can't reproduce with > > hfs on a drive with 512 byte sectors (for that I still trying to fully > > understand hfs btrees :-) ). I don't think this patch should be included > > last time i looked (somewhere around 2.3.4x), all the B-tree directory > implementations in the kernel were broken. That's HFS, HPFS and NTFS. > None of them consider the race where an insert occurs into the tree > while you're doing a readdir. I thought about how to fix it for ext2 > btrees but I haven't come up with a satisfactory solution yet. readdir() holds ->both i_sem and ->i_zombie, so I'm not sure what other exclusion do you need. Darnit, documentation on filesystem locking is there for purpose. First folks complain about its absence, then they don't bother to read the bloody thing once it is there. Furrfu... Said that, handling of indirect blocks used to be badly b0rken on all normal filesystems and it had been fixed only on ext2, so I wouldn't be amazed if regular files were bad on B-tree style filesystems. Directories are easy - all requests are process-synchronous (no pageout), no truncate() in sight, so the life is better. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.4.0-test: atomic_t unsafe on UP systems?
Hi,
While looking at the atomic_t definition for i386, I found the fact that
"counter" isn't volatile is rather strange. Especially since a
volatile_read() doesn't add the "volatile" which would make the (probably
bogus example):
while (atomic_read(_var));
dangerous as gcc might optimize it into registers... [1]
Granted, the example is probably not a good one, but I hope it shows the
problem.
Stranger things might happen if the variable is also modified from
interrupt-context... as there is nothing that stops gcc from optimizing
the variable in the the non-interrupt code into registers.
The patch below will make the counter always volatile; it seems to be the
correct thing to do.
Greetings,
Arjan van de Ven
[1] No doubt the crusoe will handle this nicely
--- linux/include/asm-i386/atomic.h.org Tue Aug 29 18:44:42 2000
+++ linux/include/asm-i386/atomic.h Tue Aug 29 18:44:59 2000
@@ -19,11 +19,7 @@
*/
#define __atomic_fool_gcc(x) (*(volatile struct { int a[100]; } *)x)
-#ifdef __SMP__
typedef struct { volatile int counter; } atomic_t;
-#else
-typedef struct { int counter; } atomic_t;
-#endif
#define ATOMIC_INIT(i) { (i) }
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] waitqueue optimization, 2.4.0-test7
On Tue, Aug 29, 2000 at 04:26:18AM +0200, Andrea Arcangeli wrote: > Just to make a fun example if the virtual address of ld_l/st_c are > different but within the same 16bytes natuarlly aligned block you have to > put an mb() in __between__ ld_l/st_c to make sure that they are not > reordered and that none write happened in between from another CPU. Actually, if you'll look elsewhere you'll see that you cannot mismatch the two addresses and expect it to work on all implementations. r~ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel Debugging
"Amit S. Kale" wrote: > > George Anzinger wrote: > > I took a look at this and it looks very messy. The whole notion is that > > the stack is available to put the call on and then proceed. The > > question then is what does the stack look like after the call to the > > inferior function which, one way or another get back to the kgdb. I > > think the back trace should show the frames that kgdb put on the stack > > and then trace back to the orgional stack. If gdb is some how not on > > the same stack, we will not see it. In fact the inferior trap/break > > would leave a bit of a mess to clean up. We would have to move the > > stack again, but to a new place, etc. > > Yes. putting new parameters etc. on top of the stack inside kgdb > makes back trace show called function, kgdb function calls and then > original kernel function calls. This creates > 1. Reentrancy problems. > 2. Called function can corrupt kgdb data. > > > An alternative solution is to put the call in a seperate memory area and > > put the parameters, etc. on the stack. This would unwind cleanly and > > gdb already drops the inferior call from being useful when it ends other > > than by returning. Some systems do not allow execution from the stack, > > so code already exists in gdb to do this. Problem is a) how to turn it > > on, and b) how to tell gdb where the real sp is so it can lay down the > > call parameters correctly. Of course, even this may be a problem as the > > stub still needs to make calls to get characters from the interface, but > > this could be covered by boosting the stack address given to gdb for the > > inverior function call. > > In this case the stack would be broken. > 1. It again has reentrancy problems > 2. back trace is not clean it's broken. > > IMO a better option is to make kgdb intelligent to recognize the fact > that gdb is pushing parameters and calling another function. Save all > this in some other area and put parameters and the call just before > returning from kgdb. This solution does not have reentrancy problems > as artificially constructed call looks similar to a normal call from > called function. No kgdb frames appear in between original function. > kgdb does not need to remember that it has executed a function call. Well I guess I am up for the chalange. Is there a clue when this is happening other than a write to the stack area? I assume gdb expects, on return, to be able to just continue to resume the program. How is the completion of the inferior function recognized? Could be a breakpoint or some return to the gdb. Hm, lets see, in a ptrace environment the only available option is a breakpoint. Right? George - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: hfs support for blocksize != 512
On Tue, Aug 29, 2000 at 06:08:04PM +0200, Roman Zippel wrote: > Anyway, I'm happy about any bug reports, that you can't reproduce with > hfs on a drive with 512 byte sectors (for that I still trying to fully > understand hfs btrees :-) ). I don't think this patch should be included last time i looked (somewhere around 2.3.4x), all the B-tree directory implementations in the kernel were broken. That's HFS, HPFS and NTFS. None of them consider the race where an insert occurs into the tree while you're doing a readdir. I thought about how to fix it for ext2 btrees but I haven't come up with a satisfactory solution yet. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Small cleanup in fs/ext2/ialloc.c
Hello.
Following patch against 2.4.0-test7 does a small cleanup in ext2/ialloc.c.
ext2_new_inode() now initializes quota on inode - I think this is more error
proof than initializing quota all over the place. Now it also uses DQUOT_DROP()
macro (which is usual way) instead of direct function call.
Honza
--- fs/ext2/ialloc.cWed Jun 28 20:32:09 2000
+++ fs/ext2/ialloc.cSat Jul 22 23:53:51 2000
@@ -459,8 +459,9 @@
mark_inode_dirty(inode);
unlock_super (sb);
+ DQUOT_INIT(inode);
if(DQUOT_ALLOC_INODE(sb, inode)) {
- sb->dq_op->drop(inode);
+ DQUOT_DROP(inode);
inode->i_nlink = 0;
iput(inode);
*err = -EDQUOT;
hfs support for blocksize != 512
Hi, Here is a patch for anyone who needs to access HFS on e.g. an MO drive. It's only for 2.2.16, but I was able to do that as part of my job as we need that functionality. Anyway, I've read also a bit through HFS+ spec and IMO basically most of the current hfs needs to rewritten for 2.4, e.g. its special files should better go into the page cache and hfs basically assumes everywhere 512 byte blocks, what isn't true anymore with hfs+. This 512 bytes block problem is also the reason that the perfomance of this patch will suck badly on MOs, since _every_ write (of a 512 byte block) requires a read (of a 1024 byte sector). Anyway, I'm happy about any bug reports, that you can't reproduce with hfs on a drive with 512 byte sectors (for that I still trying to fully understand hfs btrees :-) ). I don't think this patch should be included into standard 2.2, but on the other hand it also shouldn't make anything worse than it already is. bye, Roman hfs1024.diff.gz
Re: 2.2.17pre16 VM: do_try_to_free_pages failed
Le Tue, Aug 29, 2000 at 09:17:53AM +1000, Jim Woodward a écrit: > Aug 26 20:10:18 jim kernel: VM: do_try_to_free_pages failed for pine... > I've never seen this error before but it doesnt seem to cause any > problems. Any ideas? AFAIK, it comes from memory and swap extreme shortage. Arnaud. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
NFS and two NICs
Is there a way to run NFS only on one NIC in a two-NIC box? I know IPchains can be used to deny access from one card or another, but is there a way to bind NFS specifically to one card and not the other? -M - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Fix disk statistic reporting to include all disks
This patch fixes the enhanced disk statistics to report all drives
so IDE1 - IDE3 (/dev/hdc - /dev/hdh) can be monitored.
It is also more efficient when scanning the kstat disk tables
during a read of /proc/stat because entries in the table are looked
at only if a disk has registered any activity.
Bill
Bill Wilson <[EMAIL PROTECTED]>
diff -ur linux-2.4.0-test7/drivers/block/ll_rw_blk.c
linux/drivers/block/ll_rw_blk.c
--- linux-2.4.0-test7/drivers/block/ll_rw_blk.c Sat Aug 26 12:28:23 2000
+++ linux/drivers/block/ll_rw_blk.c Tue Aug 29 07:58:18 2000
@@ -551,19 +551,26 @@
unsigned long nr_sectors, int new_io)
{
unsigned int major = MAJOR(dev);
- unsigned int index;
+ unsigned int disk;
+ int index;
- index = disk_index(dev);
- if ((index >= DK_MAX_DISK) || (major >= DK_MAX_MAJOR))
+ disk = disk_index(dev);
+ if ((disk >= DK_MAX_DISK) || (major >= MAX_BLKDEV))
return;
-
- kstat.dk_drive[major][index] += new_io;
+ if ((index = kstat.dk_drive_map[major] - 1) < 0) {
+ if (kstat.dk_drive_max >= DK_MAX_MAJOR)
+ return;
+ index = kstat.dk_drive_max++;
+ kstat.dk_drive_map[major] = index + 1;
+ kstat.dk_drive_major[index] = (int) major;
+ }
+ kstat.dk_drive[index][disk] += new_io;
if (rw == READ) {
- kstat.dk_drive_rio[major][index] += new_io;
- kstat.dk_drive_rblk[major][index] += nr_sectors;
+ kstat.dk_drive_rio[index][disk] += new_io;
+ kstat.dk_drive_rblk[index][disk] += nr_sectors;
} else if (rw == WRITE) {
- kstat.dk_drive_wio[major][index] += new_io;
- kstat.dk_drive_wblk[major][index] += nr_sectors;
+ kstat.dk_drive_wio[index][disk] += new_io;
+ kstat.dk_drive_wblk[index][disk] += nr_sectors;
} else
printk(KERN_ERR "drive_stat_acct: cmd not R/W?\n");
}
diff -ur linux-2.4.0-test7/drivers/block/md.c linux/drivers/block/md.c
--- linux-2.4.0-test7/drivers/block/md.cSat Aug 26 12:28:23 2000
+++ linux/drivers/block/md.cTue Aug 29 07:58:18 2000
@@ -3218,6 +3218,7 @@
struct md_list_head *tmp;
int idle;
unsigned long curr_events;
+ int index;
idle = 1;
ITERATE_RDEV(mddev,rdev,tmp) {
@@ -3226,9 +3227,11 @@
if ((idx >= DK_MAX_DISK) || (major >= DK_MAX_MAJOR))
continue;
-
- curr_events = kstat.dk_drive_rblk[major][idx] +
- kstat.dk_drive_wblk[major][idx]
;
+ if ((index = kstat.dk_drive_map[major] - 1) < 0)
+ curr_events = 0;
+ else
+ curr_events = kstat.dk_drive_rblk[index][idx] +
+ kstat.dk_drive_wblk[index][idx]
;
curr_events -= sync_io[major][idx];
// printk("events(major: %d, idx: %d): %ld\n", major, idx,
curr_events);
if (curr_events != rdev->last_events) {
diff -ur linux-2.4.0-test7/fs/proc/proc_misc.c linux/fs/proc/proc_misc.c
--- linux-2.4.0-test7/fs/proc/proc_misc.c Mon Aug 7 13:20:10 2000
+++ linux/fs/proc/proc_misc.c Tue Aug 29 07:58:18 2000
@@ -288,7 +288,7 @@
extern unsigned long total_forks;
unsigned long jif = jiffies;
unsigned int sum = 0, user = 0, nice = 0, system = 0;
- int major, disk;
+ int index, major, disk;
for (i = 0 ; i < smp_num_cpus; i++) {
int cpu = cpu_logical_map(i), j;
@@ -326,20 +326,22 @@
len += sprintf(page + len, "\ndisk_io: ");
- for (major = 0; major < DK_MAX_MAJOR; major++) {
+ for (index = 0; index < kstat.dk_drive_max; index++) {
+ if ((major = kstat.dk_drive_major[index]) == 0)
+ continue;
for (disk = 0; disk < DK_MAX_DISK; disk++) {
- int active = kstat.dk_drive_rio[major][disk] +
- kstat.dk_drive_rblk[major][disk] +
- kstat.dk_drive_wio[major][disk] +
- kstat.dk_drive_wblk[major][disk];
+ int active = kstat.dk_drive_rio[index][disk] +
+ kstat.dk_drive_rblk[index][disk] +
+ kstat.dk_drive_wio[index][disk] +
+ kstat.dk_drive_wblk[index][disk];
if (active)
len += sprintf(page + len,
"(%u,%u):(%u,%u,%u,%u) ",
major, disk,
- kstat.dk_drive_rio[major][disk],
- kstat.dk_drive_rblk[major][disk],
-
Re: www.crucial.com won't talk to 2.4.0-test7 system
On Tue, Aug 29, 2000 at 08:39:48AM -0500, Bob_Tracy wrote: > I *thought* I wanted to buy some memory from Crucial :-). Can't > get there from here with my 2.4.0-test7 machine, but Win95 seems > to be ok, and 2.4.0-test5 worked ok from a different location > yesterday. Has anyone else seen this kind of thing that might shed > some light on the matter? Here's what tcpdump saw: Try echo 0 > /proc/sys/net/ipv4/tcp_ecn -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] cleanup on selection.c
Em Mon, Aug 28, 2000 at 11:40:06PM -0700, David S. Miller escreveu: >Date: Mon, 28 Aug 2000 17:36:55 -0700 >From: Richard Henderson <[EMAIL PROTECTED]> > >On Fri, Aug 25, 2000 at 10:07:03AM -0700, Linus Torvalds wrote: >> The copy_from_user_ret() define is both BUGGY and UGLY: it's buggy because >> it is done as a statement expression even though it's not actually an >> expression at all. > >In fact, there's been talk about adjusting the definition of statement >expressions such that you cannot branch into or out of them at all. > > I've sent Linus a patch which kills all of this xxx_ret user access > routine crapola. good to know, myTODO-- :) - Arnaldo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
ANN: CML2+OS, Integrated Kernel & Operating System Configuration and Generation
CML2+OS === Integrated Kernel & Operating System Configuration and Generation August 29, 2000 --- The Embedded Debian Project is pleased to announce the availability of the first of a series of DEVELOPMENT releases of CML2+OS, a system for the configuration and generation of both a Linux kernel *AND* an operating system (i.e. root filesystem). CML2+OS is being designed to assist embedded Linux developers in configuring and generating small (1 to 10Mb) Linux target systems. CML2+OS is based on CML2, (CML stands for Configuration Menu Language) currently under development to replace the existing Linux kernel configuration system. See http://www.tuxedo.org/~esr/kbuild for more information on CML2. Some of the goals of CML2+OS are 0. Open Source. 1. Run on Debian, RPM based, or any other Linux development host. 2. Cross development; i.e. build an ARM target system on an x86 development host. 3. Support a wide range of target architectures (e.g. ARM, PowerPC, MIPS, SPARC, Intel x86, Alpha and Motorola 680x0). 4. Fully integrated kernel *and* OS (i.e. root filesystem) configuration and generation. For instance, if loadable module support isn't configured in the kernel, then the user won't (by default) be presented with the option to include 'modutils' in the OS. If SCSI support isn't configured into the kernel, then SCSI /dev nodes won't be created. 5. Ability to generate a system in a number of ways, such as to a directory tree for NFS root, to a compressed initial ramdisk, etc. 6. Support for profiles, which are pre-designed configurations for various target boards and target functions (e.g. firewalls, routers, file servers, web servers, etc.). 7. The ability to generate systems from binary packages (for convenience) and/or source packages (for flexibility). The home page for CML2+OS can be found at the Embedded Debian web site: http://www.emdebian.org As I mentioned, this is a DEVELOPMENT release. This means that it doesn't fully work yet, and a lot of what does work still needs work. However, it *HAS* actually built a few small systems that have booted on a PowerPC VME board. I don't recommend using it at this stage unless you're willing to get your hands dirty. CML2+OS is expected to be ready for beta testing in one to two months. ARCHITECTURE The architecture of CML2+OS consists of a front end (the Configurator) and a back end (the Generator). The Configurator (front end) is based on extending the CML2 rulebase with configuration rules for the operating system. It produces a standard Linux '.config' file augmented with OS configuration information. The Generator (back end) takes this config file, and generates a file system containing the OS. There are many conceivable ways of building such a filesystem. The first implementation will be based on a simple, yet powerful technique of extracting pre-built binaries from existing Debian binary packages. This will enable the building of minimal operating systems for ARM, PowerPC, SPARC, Intel x86, Alpha and Motorola 680x0 architectures. ACKNOWLEDGEMENTS CML2+OS has been developed as part of the Embedded Debian Project (http://www.emdebian.org), and is being released under the GPL. Funding for this project is being provided by AMIRIX Systems Inc. (http://www.amirixlinux.com) TO PARTICIPATE -- If you're interested in participating in the development of CML2+OS, you should join the 'emdebian-discuss' mailing list. Instructions on how to join the list can be found on the Embedded Debian web site: http://www.emdebian.org For companies in the embedded Linux business, participation in the Embedded Debian Project is a viable way of having a voice in the design and implementation of an embedded Linux distribution which can be used as the basis of their own products. -- Frank Smith <[EMAIL PROTECTED]> Embedded Debian Project $Id: ANNOUNCEMENT.OS,v 1.7 2000/08/29 12:41:00 fismith Exp $ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] scheduler bugfix, SMP, 2.4.0-test7
>i agree fully. The attached patch against test8-pre1 changes >schedule_idle() from inline to FASTCALL - things look much nicer with this >one applied. > > Ingo, the local flags stuff on Sparc, remember? Maybe its time to have FASTCALLFLAGS that is different for sparc ? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: SCO: "thread creation is about a thousand times faster than on
Would it be possible to make fork() or clone() from a process whose tgid!=pid reparent the child to the thread group leader automatically? Thus, when the creating thread goes away, the child is still a child of the "process", and SIGCHLD is still going to go to the process (leader thread). Also all child "processes" and "threads" are then logically children of the "process", given that a "process" is then defined by the tgid. Also my 2p on the execve() problem: if the master thread does an execve(), there must be a point of no return, at which point all the child threads should be deleted, IMHO, otherwise they turn into full processes in their own right, and the thread-signalling framework goes out the window. And for a further thought on the subject, is it possible for when a child thread does an execve(), to wangle the master thread into making this call, with all other threads SIGSTOP'd until completion (& death) or failure (& resumption)? (though that's probably better done in userspace) David Howells - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: www.crucial.com won't talk to 2.4.0-test7 system
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 29 Aug 2000, Bob_Tracy wrote: > I *thought* I wanted to buy some memory from Crucial :-). Can't > get there from here with my 2.4.0-test7 machine, but Win95 seems > to be ok, and 2.4.0-test5 worked ok from a different location > yesterday. Has anyone else seen this kind of thing that might shed > some light on the matter? Here's what tcpdump saw: > > 2.4.0-test7 trial > > 08:16:50.800511 gherkin.sa.wlk.com.3337 > www.crucial.com.www: S >3556516453:3556516453(0) win 5840 (DF) > 4500 003c 4000 4006 010f c09e fe31 > 89c9 f113 0d09 0050 d3fc 2265 > a0c2 16d0 1a35 0204 05b4 0402 080a > 01d5 d704 > 08:16:50.970196 www.crucial.com.www > gherkin.sa.wlk.com.3337: R 0:0(0) ack >3556516454 win 5840 (DF) > 4500 003c 4000 2906 180f 89c9 f113 > c09e fe31 0050 0d09 d3fc 2266 > a0d4 16d0 1a22 0204 05b4 0402 080a > 01d5 d704 [*lots* snipped away] With 2.4.0-test6 I don't experience this problem. I can't reproduce it whatsoever :) Richard -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.2 (GNU/Linux) Comment: Made with pgp4pine 1.75 iD8DBQE5q8qaUSLExYo23RsRAg3rAKDTCw+6nEajhTZ/b0etLyj8uuxeuwCfbjCu WaepckWuuAI1raiCPsV5fsw= =H3vp -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
PCI bridge problems?
Hello! It seems, that we have problems with the resource allocation of some cards behind a 21152 bridge. The 2.4.0-test1 kernel gives the following messages during startup: PCI: PCI BIOS revision 2.10 entry at 0xfb280, last bus=2 PCI: Using configuration type 1 PCI: Probing PCI hardware PCI: Using IRQ router VIA [1106/0596] at 00:07.0 PCI: Cannot allocate resource region 1 of device 02:0d.0 PCI: Cannot allocate resource region 2 of device 02:0d.0 PCI: Cannot allocate resource region 0 of device 02:0e.0 PCI: Cannot allocate resource region 1 of device 02:0e.0 PCI: Failed to allocate resource 2 for PCI device 112f:0004 (Imaging Technology Inc) PCI: I/O Region 02:0e.0/0 too large (12288 bytes) PCI: I/O Region 02:0e.0/0 too large (12288 bytes) PCI: Failed to allocate resource 0 for 3Com Corporation 3c905C-TX [Fast Etherlink] PCI: Failed to allocate resource 1 for 3Com Corporation 3c905C-TX [Fast Etherlink] PCI: BIOS reporting unknown device 02:60 PCI: Device 02:68 not found by BIOS I have attached some lspci (-t) (-v) (-v -b) output. If this is not the right place to ask, I apologize and hopefully someone can give me some hints, WHERE to ask for help. Thank's matthias --- GOM mbH Tel.: ++49 531/3804-330 Gesellschaft fuer optische Messtechnik Fax.: ++49 531/3804-333 Rebenring 33Mail: [EMAIL PROTECTED] 38106 Braunschweig GERMANY http://www.gom.com --- 00:00.0 Host bridge: VIA Technologies, Inc. VT82C691 [Apollo PRO] (rev 22) Flags: bus master, medium devsel, latency 0 Memory at e400 (32-bit, prefetchable) Capabilities: [a0] AGP version 1.0 00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598 [Apollo MVP3 AGP] Flags: bus master, 66Mhz, medium devsel, latency 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 Memory behind bridge: e000-e1ff 00:07.0 ISA bridge: VIA Technologies, Inc.: Unknown device 0686 (rev 14) Subsystem: VIA Technologies, Inc.: Unknown device 0686 Flags: bus master, stepping, medium devsel, latency 0 00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 06) (prog-if 8a [Master SecP PriP]) Flags: bus master, medium devsel, latency 32, IRQ 255 I/O ports at ec00 00:07.4 Host bridge: VIA Technologies, Inc.: Unknown device 3057 (rev 10) Flags: medium devsel 00:0a.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RT8139 (rev 10) Subsystem: Realtek Semiconductor Co., Ltd. RT8139 Flags: bus master, medium devsel, latency 32, IRQ 10 I/O ports at e800 Memory at e440 (32-bit, non-prefetchable) Capabilities: [50] Power Management version 2 Capabilities: [60] Vital Product Data 00:14.0 PCI bridge: Digital Equipment Corporation DECchip 21152 (rev 03) Flags: bus master, medium devsel, latency 32 Bus: primary=00, secondary=02, subordinate=02, sec-latency=32 I/O behind bridge: d000-dfff Memory behind bridge: e200-e3ff Capabilities: [dc] Power Management version 1 01:07.0 VGA compatible controller: Chips and Technologies F69000 HiQVideo (rev 64) Subsystem: Chips and Technologies: Unknown device 00c0 Flags: stepping, medium devsel, IRQ 11 Memory at e000 (32-bit, non-prefetchable) 02:0c.0 SCSI storage controller: Adaptec 7892A (rev 02) Subsystem: Adaptec: Unknown device 0080 Flags: bus master, 66Mhz, medium devsel, latency 32, IRQ 10 BIST result: 00 I/O ports at d000 Memory at e3ff7000 (64-bit, non-prefetchable) Capabilities: [dc] Power Management version 2 02:0d.0 Multimedia video controller: Imaging Technology Inc: Unknown device 0004 (rev 03) Flags: bus master, fast devsel, latency 32, IRQ 5 Memory at e300 (32-bit, non-prefetchable) Memory at e200 (32-bit, non-prefetchable) Memory at e380 (32-bit, non-prefetchable) 02:0e.0 Ethernet controller: 3Com Corporation 3c905C-TX [Fast Etherlink] (rev 74) Subsystem: 3Com Corporation: Unknown device 9200 Flags: bus master, medium devsel, latency 32, IRQ 11 I/O ports at d400 Memory at e3ff8000 (32-bit, non-prefetchable) Capabilities: [dc] Power Management version 2 00:00.0 Host bridge: VIA Technologies, Inc. VT82C691 [Apollo PRO] (rev 22) Flags: bus master, medium devsel, latency 0 Memory at e400 (32-bit, prefetchable) [size=4M] Capabilities: [a0] AGP version 1.0 00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598 [Apollo
Re: [patch] waitqueue optimization, 2.4.0-test7
On Tue, 29 Aug 2000, David S. Miller wrote:
> Date: Tue, 29 Aug 2000 04:26:18 +0200 (CEST)
> From: Andrea Arcangeli <[EMAIL PROTECTED]>
>
> Alpha definitely needs mb(), ld_l/st_c doesn't imply any memory
> barrier (yes, alpha is very aggressive in SMP 8).
>
>I wonder if it then makes sense to just provide a set of bitops
>interfaces then which enforces the barrier. Or perhaps the other way
And where do you want to enforce the barrier? Before or after clear_bit,
or both? Do you think we should add mb_clear_bit() and clear_bit_mb() and
mb_clear_bit_mb()? I'm not sure that's cleaner than using mb();
clear_bit(); mb(), however I see that only alpha due its SMP capability
would get the explicit mb() at zero additinal cost. Oh well...
Anyway what we call now clear_bit() should not have any implicit memory
barrier. clear_bit is just an atomic function, it doesn't have anything to
do with memory barriers. (I dislike the __clear_bit approch)
I'd prefer to have things like UnlockPage implemented as the architecture
prefers (with a safe SMP common code default) instead of exporting zillons
of mb_clear_bit_mb and friends variant (same for set_bit and other
friends). Maybe the architecture can do even more deep assumption than
what we can export via an API bloating mb_clear_bit_mb().
Note that actually we just now enforce an implicit memory barrier _after_
test_and_set/clear/change_bit (to be able to use them like spinlocks to
build a critical section). For example mm/filemap.c:lock_page() relys on
test_and_set_bit (in TryLockPage) to do a mb() _after_ setting the
PG_locked bitflag and of course the alpha port is doing it see:
__asm__ __volatile__(
"1: ldl_l %0,%1\n"
" and %0,%3,%2\n"
" bne %2,2f\n"
" xor %0,%3,%0\n"
" stl_c %0,%1\n"
" beq %0,3f\n"
" mb\n"
^^
"2:\n"
".subsection 2\n"
"3: br 1b\n"
".previous"
:"=" (temp), "=m" (*m), "=" (oldbit)
:"Ir" (1UL << (nr & 31)), "m" (*m));
And surprise: I found a SMP race in UnlockPage. What we're doing now it's
of the kind of:
long lock = 0; (page->flags)
while (test_and_set_bit(, 0)) (TryLockPage())
wait_unlock();
-- critical section --
lock = 0; (clear_bit())
And the above will allow the `lock = 0' (in our case clear_bit) to be
reordered inside the critical section causing a plain SMP race. To fix it
we do need an explicit mb() _before_ clear_bit() (and after the critical
section of course). And for using the wake_up optimization
(waitqueue_active()) we need mb() _after_ clear_bit(). Fun ;). So we need
both before and after for two very different reasons (first mb is for
closing the critical section before releasing the lock, second mb is for
ordering rules of the wait event interface :)
Furthmore what we need aren't really mb() but smb_mb() that are noops in
an UP compilation.
Talking about common code the code I'd prefer to write is this:
lock_page() {
long lock = 0;
while (TryLockPAge(page)) /* test_and_set_bit doesn't include implicit mb() */
wait_unlock();
smp_mb();
}
-- critical section --
UnlockPage() {
smp_mb();
clear_bit();
smp_mb();
if (waitqueue_active())
wakeup()
}
The above would fix the SMP race and it would be the most finegrined
implementation that also avoids suprious mb() in the slow path of
lock_page(). It would be also the most efficient implementation for the
alpha :)) IMHO it also tends to be less misleading since there will be a
smb_mb() at the start of the critical section too so we won't forgot of
the second _necessary_ one. And we won't do a suprious mb while doing the
test_and_set_bit(PG_referenced) that doesn't need the mb.
However with the above common code to optimize lock_page we should
re-implemented per-arch (ala string.h with overriding #define) for IA32
and sparc64 to avoid wasting cycles in suprious mb() that happen to be
implicit in the bitops at least for such two architectures.
I'm checking if it's not a pain to audit all the
test_and_set/clear/change_bit to avoid adding the implicit barrier in them
and move the stuff that we want to be optimized in the arch section.
Meanwhile hints and comments are welcome.
If you prefer a zillon of mb_clear_bit_mb and all other possible
combinations we can do that of course too (optimizing the slow path of
lock_page shouldn't be very worthwhile optimization, I see).
BTW, (changing topic a bit) after your lesson about the meaning of sparc64
membar I seen you never use the rmb/wmb inside the sparc64 code so I think
you can just optimize sparc64 to be more finegrined (and yes wmb should
have the alpha asm("wmb") meaning :) and rmb should be the exact
counterpart to avoid obvious mistakes where nobody knows anymore what such
two macros means :).
---
