Re: [OFFTOPIC] Re: [PATCH] Single user linux
Tomas Telensky [EMAIL PROTECTED] On Tue, 24 Apr 2001, Alexander Viro wrote: On Tue, 24 Apr 2001, Tomas Telensky wrote: of linux distributions the standard daemons (httpd, sendmail) are run as root! Having multi-user system or not! Why? For only listening to a port 1024? Is there any elegant solution? Sendmail is old. Consider it as a remnant of times when network was more... friendly. Security considerations were mostly ignored - and not only by sendmail. It used to be choke-full of holes. They were essentially debugged out of it in late 90s. It seems to be more or less OK these days, but it's full of old cruft. And splitting the thing into reasonable parts and leaving them with minaml privileges they need is large and painful work. Actually, if you view sendmail as being an expert system it is very cutting edge :-) It can identify a user from very skimpy data if it is allowed to (fuzzy matching user names). It identifies local hosts (with FQDN or partial name, or only host name). Thanks for the comment. And why not just let it listen to 25 and then being run as uid=nobody, gid=mail? Because then everybodys mail would be owned by user nobody. There are some ways to do this, but they are unreliable. 1. If the users mail is delivered to /var/mail/username; then the file /var/mail/username must always exist. This requires ALL MUAs to truncate the file. Some MUAs use file existance to determine if there is new mail. If it doesn't exist, then no new mail... ever. 2. sendmail will not be able to create the /var/mail/username mail box. 3. sendmail will not be able to process forwarding mail. User nobody should not be able to read files in users home directory... .forward files are private to the user... 4. sendmail will not be able to process user mail filters (same problem as forwarding). Note: these filters are applied on receipt of mail (saves time and disk space since the filter can discard mail immediately or put it in appropriate folders immediately). - Jesse I Pollard, II Email: [EMAIL PROTECTED] Any opinions expressed are solely my own. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OFFTOPIC] Re: [PATCH] Single user linux
On Wed, 25 Apr 2001, CaT wrote: On Tue, Apr 24, 2001 at 04:49:57PM +0200, Pjotr Kourzanoff wrote: use port 2525 as SMTP port in your MTA. I've succeed to setup such a configuration. This requires you to ensure that your MTA is started first on that port...Might be difficult to achieve reliably in an automatic way without root privileges :-( mailuser@foo% /etc/rc.d/init.d/sendmail stop badguy@foo% ./suck 2525 mailuser@foo% /etc/rc.d/init.d/sendmail start Not necessarily. While I have no yet used the feature, iptables permits firewalling on userid. I presume this includes wether or man iptables. not a program can listen on a port, right? (and all the other fun things). If so then all you'd have to do is deny external access to port 2525 and only permit mailuser to listen etc on it and you're set. For this to work, you need to hack up iptables on the mail server itself as -m owner only works for locally generated packets. And even then ./suck will receive on 2525 but will not be able to reply. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PIO disk writes using 100% system time and performing poorly with VIA vt82c686b on kernels 2.2 2.4
Thomas Ford wrote: Heavy disc writes (eg. unzipping linux kernel source) cause the system processor usage (as reported by top/xosview) to jump to 100%, making the X mouse/audio freeze etc. Such problems occur with the drives connected to VIA vt82c686b south bridge: the same drives on a mvp3 show no such problems. The behaviour is the same on kernels 2.2.17 2.4.3 (both hand compiled RedHat's 2.4.2-2 2.2.17-14 in case I was doing something wrong). The problem is easily demonstrated by hdparm -t. The CPU use jumps to system 100% as above and all my drives report ~1.9 MB/sec in PIO mode which is far lower than PIO on the mvp3 (~10MB/s). DMA mode appears to work fine but I am not using it due to publicised potential problems. Regards, Tom Ford - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ Can you share a link to the publicised potential problems for DMA mode? I'm running VIA686A using DMA mode and haven't had any problems. However, the disk isn't operating as efficiently as I thought it would (hdparm -t reports 16.3 MB/sec even though I'm using an 80w cable with an ATA100 drive). I believe that this is due in part to corrective measures taken by RedHat to fix potential problems with the VIA chipset; I saw it reported somewhere that the same configuration will work 20+ MB/sec on distros like Debian). -- -o) j o h n e w e b e r / \ aspiring computer scientist lover of pengiuns _\_v - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Greetings!
well... the book sounds good... but... I am still thinking... what it has to do with linux kernel ?? [EMAIL PROTECTED] on 04/24/2001 04:27:56 PM To: [EMAIL PROTECTED] cc:(bcc: Amol Lad/HSS) Subject: Greetings! 1 in 6 children are victimized before the age of 16. Hello, my name is Jason Colgan and I am writing to you about my father's unique book on child safety. I hope you don't mind me emailing you, but I found your email address on a website that was related to children, so I figured you would definitely be interested in this. My father, a retired police Captain, authored a children's book using his unique experience with child safety. My father has investigated, arrested and taken confessions from child molesters, kidnappers, murderers and some of the most dangerous people in the world. He often spoke and interacted with them before they had the chance to speak with lawyers or others, so he was able to gain an honest understanding of the way they think and the manner in which they victimize children. My father put his 23 years of experience to work for a good cause and developed a children's book, written in a storybook fashion starring a small family of bunnies. The book has already caused quite a stir and has been featured in local newspapers and even the news. Even more important, the people who have purchased the book love it and so do their children. It truly presents a simplified way to educate your child on matters that are difficult for parents, grandparents, or guardians to discuss. I would like you to learn more about my father's book by visiting www.SafeStory.com If you are curious to see what others think, there is a link on that web site which has some customer opinions and even shows you the write-ups the book has received on Amazon.com. Thank you so much for your time and if you have any questions at all, please email me or call and I would love to answer them! My sincerest thanks, Jason http://www.SafeStory.com P.S. Please email me at [EMAIL PROTECTED] or call me anytime. My home phone number is 401-463-2856. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] rw_semaphores, optimisations try #3
On Tue, 24 Apr 2001, David Howells wrote: Yes but the struct rwsem_waiter batch would have to be entirely deleted from the list before any of them are woken, otherwise the waking processes may destroy their rwsem_waiter blocks before they are dequeued (this destruction is not guarded by a spinlock). Look again. Yes, they may destroy the list, but nobody cares. Why? - nobody will look up the list because we do have the spinlock at this point, so a destroyed list doesn't actually _matter_ to anybody You were actually depending on this earlier, although maybe not on purpose. - list_remove_between() doesn't care about the integrity of the entries it destroys. It only uses, and only changes, the entries that are still on the list. Subtlety is fine. It might warrant a comment, though. Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problem with i810_audio driver
Eugene Kuznetsov wrote: The whole thing sounds to my mind as having some kind of resource, register, etc. which is supposed to be initialized during loading of drivers, but it's not done by i810_audio driver. Sounds that way to me too. I didn't write that portion of the code, so it will take me a little bit to figure out where it is screwing up at. -- Doug Ledford [EMAIL PROTECTED] http://people.redhat.com/dledford Please check my web site for aic7xxx updates/answers before e-mailing me about problems - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problem with i810_audio driver
On Mon, Apr 23, 2001 at 10:54:35PM -0400, Doug Ledford wrote: [...] Both B and C are cases of the whole chip acting flat busted. I would suspect that possibly Win2k drivers set this thing up some way that we don't recover from. H... quite possible. It's certainly true that a soft reboot from win2k leaves the cs42xx stuff screwed on my Thinkpad T20 so it wouldn't be surprising to hear of issues with other sound chips. I need to get around to dumping the registers in the good and bad case to determine what on earth it futzed with and undo it. Tim -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ Nobody ever said I was charming, they said Rimmer, you're a git! RD VI - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: rwsem benchmark [was Re: [PATCH] rw_semaphores, optimisationstry #3]
On Tue, 24 Apr 2001, Andrea Arcangeli wrote: Again it's not a performance issue, the +a (sem) is a correctness issue because the slow path will clobber it. There must be a performance issue too, otherwise our read up/down fastpaths are the same. Which clearly they're not. I guess I'm faster because I avoid the pipeline stall using +m (sem-count) that is written as a constant, that was definitely intentional idea. Guys. You're arguing over stalls that are (a) compiler-dependent and (b) in code that doesn't hapeen _anywhere_ except in the specific benchmark you're using. Get over it. - The benchmark may use constant addresses. None of the kernel does. The benchmark is fairly meaningless in this regard. - the stalls will almost certainly depend on the code around the thing, and will also depend on the compiler version. If you're down to haggling about issues like that, then there is no real difference between the code. So calm down guys. And improving the benchmark might not be a bad idea. Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OFFTOPIC] Re: [PATCH] Single user linux
1. email - sendmail 2. sendmail figures out what it has to do with it. turns out it's deliver ... Now, in order for step 4 to be done safely, procmail should be running as the user it's meant to deliver the mail for. for this to happen sendmail needs to start it as that user in step 3 and to do that it needs extra privs, above and beyond that of a normal user. email - sendmail sendmail 'its local' - spool user: get_mail | procmail mutt The mail server doesnt need to run procmail. If you wanted to run mail batches through on a regular basis you can use cron for it, or leave a daemon running - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OFFTOPIC] Re: [PATCH] Single user linux
On Tue, Apr 24, 2001 at 04:53:10PM +0100, Alan Cox wrote: 1. email - sendmail 2. sendmail figures out what it has to do with it. turns out it's deliver ... Now, in order for step 4 to be done safely, procmail should be running as the user it's meant to deliver the mail for. for this to happen sendmail needs to start it as that user in step 3 and to do that it needs extra privs, above and beyond that of a normal user. email - sendmail sendmail 'its local' - spool Isn't this a good thing to have spam filtered out before it will be written in spool? Alex Riesen - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Can't read SCSI TAPE
Dear sirs, Although 'tar' can write to SCSI-TAPE, can't read from. 'tar' reports .. -rw-r--r-- root/rootx 2001-xx-xx 01:23 usr/bin/xx tar: Skipping to next file header--"A" -rw-r--r-- root/rootx 2001-xx-xx 01:23 usr/bin/xxx .. "A" means written data is wrong, doesn't it??? Thanks for any help. -- Detailed - System... Kernel : 2.2.11 + raid0145-19990824-2.2.11.gz or 2.2.11 tar: GNU tar 1.12 mt : mt-st v. 0.4 glibc2 : glibc-2.0.7pre6 Hardware... Mother : Intel Celeron x2 (SMP) TAPE drv : SONY SDT-9000 TAPE : DDS1 DDS2 DDS3 SCSI card: AHA-1542 Cable: SCSI-2 Hi-impeadance , length 0.5m -- -- Masaki Tsuji - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Idea: Encryption plugin architecture for file-systems
On Mon, Apr 23, 2001 at 09:54:34PM -0500, David L. Nicol wrote: why not port one of the twenty or thirty preexisting tools that let you mount a filesystem from an encrypted file instead of making a generic layer? That way you could have inter-os portability. The steganographic ones make really impressive claims. I'm doing an 18GB raid file system. The standard loopback is working fine. What I am unsure of is the bobustness against lost blocks when running on the metal vs interposing another file system layer. I suspect the answer is that each block is individually encrypted, so that the worst case data loss is the same; that an ext2 on top of an encrypted partition would be no worse off than the same file system without the interposed layer. Both would find a bad block and do their best. But my knowledge of how the loopbacks are structured is not good enough for me to say this with confidence. That's why I'm asking here: in hopes that someone who really does know can say something about the worst case data loses. -- -- Use Linux: A computerDale Amon, CEO/MD is a terrible thing Village Networking Ltd to waste.Belfast, Northern Ireland -- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Can't read SCSI TAPE
Dear sirs, Although 'tar' can write to SCSI-TAPE, can't read from. 'tar' reports .. -rw-r--r-- root/rootx 2001-xx-xx 01:23 usr/bin/xx tar: Skipping to next file header--"A" -rw-r--r-- root/rootx 2001-xx-xx 01:23 usr/bin/xxx .. "A" means written data is wrong, doesn't it??? Thanks for any help. -- Detailed - System... Kernel : 2.2.11 + raid0145-19990824-2.2.11.gz or 2.2.11 tar: GNU tar 1.12 mt : mt-st v. 0.4 glibc2 : glibc-2.0.7pre6 Hardware... Mother : Intel Celeron x2 (SMP) TAPE drv : SONY SDT-9000 TAPE : DDS1 DDS2 DDS3 SCSI card: AHA-1542 Cable: SCSI-2 Hi-impeadance , length 0.5m -- -- Masaki Tsuji - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: Global FPU corruption in 2.2
In article [EMAIL PROTECTED], Christian Ehrhardt [EMAIL PROTECTED] wrote: 1.) If I'm not mistaken switch_to changes current-flags without atomic operations and without any locks and sys_ptrace changes child-flags only protected by the big kernel lock. ptrace only operates on processes that are stopped. So there are no locking issues - we've synchronized on a much higher level than a spinlock or semaphore. That said, it does look like 2.2.x has a real bug, and maybe the ptrace task stopping sycnhronization is broken.. Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
random reboots
Help! My machine seems to be rebooting at random. Actually, it's more like the screen blanks, and suddenly the BIOS is going through POST. There may be a reset-button gnome in my case putting a jumper over the reset pins, but I seriously doubt it. ;-) I recently tried to switch from APM to ACPI, when i upgraded from ac9 to ac11, so I thought that might be the cause. So I switched back to APM with ac13 (I had the same ac12 compile problems as the rest of the world). It's still rebooting, without any aparent cause. I upgraded the BIOS on this Asus A7V sometime in the past week, but I honestly don't remember when. From 1005C to 1007. This was released in march, so I assumed it was pretty stable, but it could be the cause. I'm going to go downgrade now, but is this more likely to be a kernel bug, or a hardware bug/new bios bug? Thanks, Nathan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: Global FPU corruption in 2.2
1.) If I'm not mistaken switch_to changes current-flags without atomic operations and without any locks and sys_ptrace changes child-flags only protected by the big kernel lock. ptrace only operates on processes that are stopped. So there are no locking issues - we've synchronized on a much higher level than a spinlock or semaphore. In the 2.2 case the ptrace flags themselves are in the same flag set as the PF_ flags. In 2.4 that was fixed. That means there are some bizarre cases where current-flags might not be handled perfectly. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: Global FPU corruption in 2.2
[ Alan, I'm lazy and only have 2.2.14 sources on-line. Maybe this has been fixed already and there's something else going on. Worth a look ] In article [EMAIL PROTECTED], Victor Zandy [EMAIL PROTECTED] wrote: Someone else here traced the process flags of a FP-intensive program on a machine before and after it is put in the faulty FPU state. He periodically sampled /proc/pid/stat while the program was running. He found that PF_USEDFPU was always set before the machine was broken. After he found that it was set about 70% of the time. [ Looks closer at the ptrace synchronization ] Ahh.. This actually _does_ look like a race on current-flags: PTRACE_ATTACH will do a child-flags |= PF_PTRACED; without waiting for the child to have stopped. (Aside: thinking more about the stopping logic - I'm not actually sure the ptrace synchronization is complete wrt scheduling, as there will be a window when the process has set the task state to TASK_STOPPED but hasn't actually yet scheduled away. Oh, well). All other ptrace operations (not counting killing the child) will check that the child is quiescent. But PTRACE_ATTACH will not, as we're just setting up the stopping. In 2.4.x, this bug doesn't happen because flags was split up into current-ptrace and current-flags. Exactly because of locking concerns. Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] rw_semaphores, optimisations try #3
Linus Torvalds [EMAIL PROTECTED] wrote: - nobody will look up the list because we do have the spinlock at this point, so a destroyed list doesn't actually _matter_ to anybody I suppose that it'll be okay, provided I take care not to access a block for a task I've just woken up. - list_remove_between() doesn't care about the integrity of the entries it destroys. It only uses, and only changes, the entries that are still on the list. True. Okay, I can change it to use that. David - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hundreds of mount --bind mountpoints?
Christoph Rohland wrote: OK I will do that for tmpfs soon. And I will do the symlink inlining with that patch. Wow, this thread really exploded, eh? But thanks, Christoph, I look forward to seeing your patch. 4k symlinks really suck for embedders who never swap out pages. ;-) regards, David -- David L. Parsley Network Administrator Roanoke College - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] swap-speedup-2.4.3-B3
On Tue, 24 Apr 2001, Ingo Molnar wrote:
the latest swap-speedup patch can be found at:
Please don't add more of those horrible wait arguments.
Make two different versions of a function instead. It's going to clean up
and simplify the code, and there really isn't any reason to do what you're
doing.
You should split up the logic differently: if you want to wait for the
page, then DO so:
page = lookup_swap_cache(..);
if (page) {
wait_for_swap_cache:valid(page);
.. use page ..
}
Note how much more readable and UNDERSTANDABLE the above is, compared to
page = lookup_swap_cache(..., 1);
if (page) {
...
and note also how splitting up the waiting will
- simplify the swap cache lookup function, making it faster for people
who do _NOT_ want to wait.
- make it easier to statically check the correctness of programs by just
eye-balling them (Hey, he's calling 'wait' with the spinlock held).
- more easily moving the wait around, allowing for more concurrency.
Basically, I don't want to mix synchronous and asynchronous
interfaces. Everything should be asynchronous by default, and waiting
should be explicit.
Linus
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: Global FPU corruption in 2.2
On Tue, Apr 24, 2001 at 08:05:15AM -0500, Victor Zandy wrote: He found that PF_USEDFPU was always set before the machine was broken. After he found that it was set about 70% of the time. If I'm not mistaken this actully can cause GLOBAL FPU corruption. Here's why: Assyme for a moment that we lose either the PF_USEDFPU flag of one process. This not only means that the current process won't have its state saved, it also means that the next process won't have the TS bit set. This in turn means that this new process won't get PF_USEDFPU set and suddenly we have a second process with a corrupted FPU state. Victor: Could you try to reproduce the system wide corruption if you add an explicit call to stts(); at the very end of __switch_to? This should prevent the FPU corruption from spreading. NOTE: This is just to prove my theory, it is not and isn't meant to be a fix for the actual problem. regards Christian Ehrhardt -- THAT'S ALL FOLKS! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Device Registry (DevReg) Patch 0.2.0
The Linux Device Registry (devreg) is a kernel patch that adds a device database in XML format to the /proc filesystem. It collects all OH SHIT!! ^^^ Why don't you just add postscript output to /proc? XML wasn't my first choice. The 0.1.x versions used simple name/value pairs, I gave this up after trying to fit the complex USB configuration/interface/endpoint data into name/value pairs. Thinking about text file formats that allow me to display hierarchical information, XML was the obvious choice for me. Are there alternatives to get complex and extendable information out to user space? (see http://www.tjansen.de/devreg/devreg.output.txt for a example /proc/devreg output) My other ideas were: - using a simple binary format, just dump structs. This would break all applications every time somebody changes the format, and this should happen very often because of the nature of the format - using a complicated, extendable binary format, for example chunk-based like (a|r)iff file formats. This would add more code in the kernel than XML output, is difficult to understand and requires more work in user space (because XML parsers are already available) - making up a new text-based format with properties similar to XML because I knew that many people dont like the idea of XML output in the kernel.. I really thought about it, but it does not make much sense. What about indenting? I think of 0 spaces before the device name, 1 space before properties which belong to the device. (Is one level enough? I'm currently offline so didn't check the sample) Structure per entry: [Space] Name colon property It also could be an equality sign, but then we could use no indention at all and [] for the sections, which leaves us at .INI format, which after all still is lotta more readable after cat than XML. The actual code overhead of XML output compared to a format like /proc/bus/usb/devices is almost zero, XML is only a little bit more verbose. I agree that XML is not perfect for this kind of data, but it is simple to generate, well known and I dont see a better alternative. bye.. -mirabilos - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
shm_open doesn't work (fix maybe).
I have been chasing all around trying to find out why shm_open always returns ENOSYS. It is implemented in glibc-2.2.2, and seems the 2.4.3 kernel knows about shmfs. It seems the file linux/mm/shmem.c has: #define SHMEM_MAGIC 0x01021994 And the glibc-2.2.2/sysdeps/unix/sysv/linux/linux_fsinfo.h has: #define SHMFS_SUPER_MAGIC 0x02011994 Well, which is correct? Looking for (trouble?) the reason, I found a patch http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg16996.html where there seems to be a typo, the remove line is correct: -#define SHM_FS_MAGIC 0x02011994 but the insert line has the 0201 reversed: +#define SHMEM_MAGIC0x01021994 Has anyone else run into this? (It seems the documentation on shmfs is sparse, so I don't think too many folks are even messing with it). Initially I thought, hey simple, just fix the kernel source, and everyone will be happy. But, then I thought, ooof! code I build for someone without a patched kernel will surely break. So then I thought simple I'll fix glibc and statically link. Of course, then someone will fix this, and all my binaries will be broken. Help! what is the right fix. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Device Registry (DevReg) Patch 0.2.0
Tim Jansen wrote: On Tuesday 24 April 2001 11:40, Martin Dalecki wrote: Tim Jansen wrote: The Linux Device Registry (devreg) is a kernel patch that adds a device database in XML format to the /proc filesystem. It collects all OH SHIT!! ^^^ Why don't you just add postscript output to /proc? XML wasn't my first choice. The 0.1.x versions used simple name/value pairs, I gave this up after trying to fit the complex USB configuration/interface/endpoint data into name/value pairs. Thinking about text file formats that allow me to display hierarchical information, XML was the obvious choice for me. Are there alternatives to get complex and extendable information out to user space? (see http://www.tjansen.de/devreg/devreg.output.txt for a example /proc/devreg output) Yes filesystem structures. Or just simple parsing in the user space plain binary data. My other ideas were: - using a simple binary format, just dump structs. This would break all applications every time somebody changes the format, and this should happen very often because of the nature of the format - using a complicated, extendable binary format, for example chunk-based like (a|r)iff file formats. This would add more code in the kernel than XML output, is difficult to understand and requires more work in user space (because XML parsers are already available) - making up a new text-based format with properties similar to XML because I knew that many people dont like the idea of XML output in the kernel.. I really thought about it, but it does not make much sense. The actual code overhead of XML output compared to a format like /proc/bus/usb/devices is almost zero, XML is only a little bit more verbose. I agree that XML is not perfect for this kind of data, but it is simple to generate, well known and I dont see a better alternative. bye.. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- - phone: +49 214 8656 283 - job: eVision-Ventures AG, LEV .de (MY OPINIONS ARE MY OWN!) - langs: de_DE.ISO8859-1, en_US, pl_PL.ISO8859-2, last ressort: ru_RU.KOI8-R - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Can't read SCSI TAPE
On Wed, 25 Apr 2001, Masaki Tsuji wrote:
Dear sirs,
Hmmm...
Masaki Tsuji [EMAIL PROTECTED]
This address
... was the address that did the CA-2000-17 attack on one of
our machines a few weeks ago.
This is not an accusation, only an observation. You might
want to tell your network administrator. Sombody at your
site may be hacking systems.
SCSI tape problems or your kind are usually caused by a different
tape compression being used during record and playback. You should
try to use `mt` to set the compression to something you like
before you record, and the same compression when you play back
the tape.
You can use `cat` and `od` to read/write from a tape before you
waste a lot file time with `tar`. You can even do:
ls /dev/tape
takes a lot of time..
cat /dev/tape # Read back.
Blocking/deblocking is done in the driver so you can treat it as
a slow-to-start FIFO.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.1 on an i686 machine (799.53 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]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] Single user linux
think about personal devices. something like the nokia communicator. a system security passwd is acceptable, but that's it. no those- device-user would like to know about user account, file ownership, etc. they just want to use it. If you are making a personal device, like an appliance, there is no need to patch the kernel - at least not to remove the concept of users. Instead, change your startup scripts. In that situation, you will have a custom application that is automatically started at boot and runs with enough privileges to do whatever it needs. The user never sees a login prompt. If you want a Windows-95 style setup for Linux, you can do that too - but don't run as root! Just have the startup scripts auto-login as an unprivileged user. Kernel patches to do this are completely unnecessary, and a bad idea. Permissions are important to have on an appliance-like system, as they can be used to help prevent the end user from accessing the guts of the system which should be off limits for them. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: Global FPU corruption in 2.2
On Tue, Apr 24, 2001 at 09:10:07AM -0700, Linus Torvalds wrote: ptrace only operates on processes that are stopped. So there are no locking issues - we've synchronized on a much higher level than a spinlock or semaphore. This is only true for requests other than PTRACE_ATTACH and PTRACE_ATTACH is exactly what I'm worried about. regards Christian -- THAT'S ALL FOLKS! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OFFTOPIC] Re: [PATCH] Single user linux
- Received message begins Here - 1. email - sendmail 2. sendmail figures out what it has to do with it. turns out it's deliver ... Now, in order for step 4 to be done safely, procmail should be running as the user it's meant to deliver the mail for. for this to happen sendmail needs to start it as that user in step 3 and to do that it needs extra privs, above and beyond that of a normal user. email - sendmail sendmail 'its local' - spool user: get_mail | procmail mutt The mail server doesnt need to run procmail. If you wanted to run mail batches through on a regular basis you can use cron for it, or leave a daemon running And get_mail must have elevated privileges to search for the users mail... or sendmail must have already switched user on reciept to put it in the users inbox which also requires privleges... And an additional daemon (owned by the user) is yet another attack point... Cron could be used to batch message handling... as long as it runs before the users quota is used up. This becomes the same as using IMAP or fetchmail to download it. It's much more efficent to process each mail as it arrives. All this does is move the program that requires privileges to somewhere else. It doesn't eliminate it. Granted, sendmail could use a better implementation of a security model. - Jesse I Pollard, II Email: [EMAIL PROTECTED] Any opinions expressed are solely my own. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OFFTOPIC] Re: [PATCH] Single user linux
Hello, On Tue, 24 Apr 2001, Alan Cox wrote: Now, in order for step 4 to be done safely, procmail should be running as the user it's meant to deliver the mail for. for this to happen sendmail needs to start it as that user in step 3 and to do that it needs extra privs, above and beyond that of a normal user. email - sendmail sendmail 'its local' - spool user: get_mail | procmail mutt The mail server doesnt need to run procmail. If you wanted to run mail batches through on a regular basis you can use cron for it, or leave a daemon running Oh, well, cron is just another suid program. This example would just be the ideal scenario for posix- or novell-style ACLs in the filesystem. You run the MDA/MTA under some mailerdaemon uid. And then a user can explicitly give this daemon read access to .procmail etc. You can also give the MTA (and nobody else) write access to /var/spool/mail. The MDA then gives the specifical user full access to the spoolfile when creating it, or adding mail to it. And the user can fetch his mail and truncate or delete the file just as he and his software is used to. There are much more things with ACLs, especially in workgroup environments (That's why I loved the old Novel server in our university), but they never got into the kernel. And as far as I (as a non-hacker) understand, the fields reserved for this feature were dropped for the large file support, so we may never see ACLs. Gruß, Markus -- | Gluecklich ist, wer vergisst, was nicht aus ihm geworden ist. +---. , http://www.uni-ulm.de/~s_mschab/ \ / mailto:[EMAIL PROTECTED] \_/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PIO disk writes using 100% system time and performing poorly with VIA vt82c686b on kernels 2.2 2.4
Hi. I have VIA686a too and a UDMA100 hard disk. This is my cat /proc/ide/via: --VIA BusMastering IDE Configuration Driver Version: 3.23 South Bridge: VIA vt82c686a Revision: ISA 0x22 IDE 0x10 Highest DMA rate: UDMA66 BM-DMA base:0xb800 PCI clock: 33MHz Master Read Cycle IRDY:0ws Master Write Cycle IRDY:0ws BM IDE Status Register Read Retry: yes Max DRDY Pulse Width: No limit ---Primary IDE---Secondary IDE-- Read DMA FIFO flush: yes yes End Sector FIFO flush: no no Prefetch Buffer: no no Post Write Buffer: no no Enabled: yes yes Simplex only: no no Cable Type: 40w 40w ---drive0drive1drive2drive3- Transfer Mode:DMA UDMA PIO PIO Address Setup: 30ns 30ns 120ns 120ns Cmd Active: 90ns 90ns 480ns 480ns Cmd Recovery:30ns 30ns 480ns 480ns Data Active: 90ns 90ns 330ns 330ns Data Recovery: 30ns 30ns 270ns 270ns Cycle Time: 120ns 60ns 600ns 600ns Transfer Rate: 16.5MB/s 33.0MB/s 3.3MB/s 3.3MB/s As you can see, l use UDMA66 instead UDMA100. I don't know why. Maybe VIA vt82c686a doesn't support it? I have answering in this list a days ago about this problem. but none seems to have a question. Like you, my system goes down when I try to compile something (I have a 394 Mb of RAM and a 1 Ghz processor). Although, my hdparm output is this: /dev/hde2: Timing buffer-cache reads: 128 MB in 0.79 seconds =162.03 MB/sec Timing buffered disk reads: 64 MB in 2.44 seconds = 26.23 MB/sec and sometime looks better. I don't know is this is a problem with the VIA kernel driver or not. But the system doesn't seem to work fine since 2.4.2 or 2.4.1 kernel. I hope (plz!) this problem will be fixed in future. Luck. PS: in cat /proc/ide/via I see Cable Type: 40w 40w... Is it right? I have a 80w cable, not 40. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Single user linux
On Tue, Apr 24, 2001 at 07:44:17PM +0700, [EMAIL PROTECTED] wrote: come on, it's hard for me as it's hard for you. not everybody expect a computer to be like people here thinks how a computer should be. I'm sorry, you're looking at the problem the wrong way around. Its not a kernel problem, but a user space problem. think about personal devices. something like the nokia communicator. a system security passwd is acceptable, but that's it. no those- device-user would like to know about user account, file ownership, etc. they just want to use it. If you do everything as one user, then you are effectively in a single-user mode. Just make sure that the user owns all the files that they might need. Your change still doesn't get rid of the /bin/login program - you still have to do that, so why not do it anyway? Also, I know of no personal device that gives you access to system software (which is effectively what giving a user 'root' access gives you). How many users do you know who can copy the firmware in their phone or organiser? that also explain why win95 user doesn't want to use NT. not because they can't afford it (belive me, here NT costs only us$2), but additional headache isn't acceptable. I'm sorry, that's a different problem, and _even_ Windows 95 and 98 has a User Logon. Only if you use the system in a single user mode does it not have a logon. You can do the same with Linux again without making kernel modifications. I'd like to point out that RedHat have thought about this, and they have some of the infrastructure in there to automatically log you on at boot time in (within X). As I say, this is a user space issue, and distributions are addressing it adequately. -- Russell King ([EMAIL PROTECTED])The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Problem with DHCP when using tokenring on 2.4.x
Hello, I have a problem with DHCP when using tokenring card on 2.4.x kernel . When I am using IBM tokenring adapter( all) and trying to hook on to the lan n/w using DHCP ,I get an error message operation failed from the dhcp client . The dhcp server is getting the broadcast message when the dhcp client is run. I am using pump that comes with 6.2 redhat distribution . There is no problem when using static IP. I could experience this problem only on 2.4.x . I am able to get a valid IP address on 2.2.x kernel when using tokenring adapter. And also there is no problem when using ethernet adapter on 2.4.x . . Has anyone experienced this problem on 2.4.x . Can any one help me to resolve this problem. Thanks Regards Shiju - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Greetings!
Because there was a mail whose subject is Children first in fork. On Tue, 24 Apr 2001 [EMAIL PROTECTED] wrote: well... the book sounds good... but... I am still thinking... what it has to do with linux kernel ?? [EMAIL PROTECTED] on 04/24/2001 04:27:56 PM To: [EMAIL PROTECTED] cc:(bcc: Amol Lad/HSS) Subject: Greetings! 1 in 6 children are victimized before the age of 16. Hello, my name is Jason Colgan and I am writing to you about my father's unique book on child safety. I hope you don't mind me emailing you, but I found your email address on a website that was related to children, so I figured you would definitely be interested in this. My father, a retired police Captain, authored a children's book using his unique experience with child safety. My father has investigated, arrested and taken confessions from child molesters, kidnappers, murderers and some of the most dangerous people in the world. He often spoke and interacted with them before they had the chance to speak with lawyers or others, so he was able to gain an honest understanding of the way they think and the manner in which they victimize children. My father put his 23 years of experience to work for a good cause and developed a children's book, written in a storybook fashion starring a small family of bunnies. The book has already caused quite a stir and has been featured in local newspapers and even the news. Even more important, the people who have purchased the book love it and so do their children. It truly presents a simplified way to educate your child on matters that are difficult for parents, grandparents, or guardians to discuss. I would like you to learn more about my father's book by visiting www.SafeStory.com If you are curious to see what others think, there is a link on that web site which has some customer opinions and even shows you the write-ups the book has received on Amazon.com. Thank you so much for your time and if you have any questions at all, please email me or call and I would love to answer them! My sincerest thanks, Jason http://www.SafeStory.com P.S. Please email me at [EMAIL PROTECTED] or call me anytime. My home phone number is 401-463-2856. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Single user linux
[EMAIL PROTECTED] wrote: hi, a friend of my asked me on how to make linux easier to use for personal/casual win user. from that, i also found out that it is very awkward to type username and password every time i use my computer. so here's a patch. Neet hack, but maybe the kernel isn't the best place to do this - For instance, you can simply use the KDE 2.1.1 login manager, with the current kernel intact, to automatically log in and start the X session of a specific user, upon entering runlevel 5 - Might this not be a better direction? cu jjs - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Greetings!
On Tue, 24 Apr 2001, Chin-Tser Huang wrote: Because there was a mail whose subject is Children first in fork. 1 in 6 children are victimized before the age of 16. Considering these statistics, I'm all for running children first after fork ... Rik -- Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Greetings! kill children first
On Tue, 24 Apr 2001, Chin-Tser Huang wrote: Because there was a mail whose subject is Children first in fork. Gotta watch out for source-code that uses a 'reaper' to kill children from SIGCHLD. We'll get auto-mail from pervert.snuffer.com. Cheers, Dick Johnson Penguin : Linux version 2.4.1 on an i686 machine (799.53 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] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: Global FPU corruption in 2.2
Christian Ehrhardt [EMAIL PROTECTED] writes: Victor: Could you try to reproduce the system wide corruption if you add an explicit call to stts(); at the very end of __switch_to? This should prevent the FPU corruption from spreading. After adding this call, I cannot reproduce the global corruption. There is still occasional local corruption of individual pi processes while pt is running. Vic - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Greetings! kill children first
On Tue, Apr 24, 2001 at 02:03:44PM -0400, Richard B. Johnson wrote: On Tue, 24 Apr 2001, Chin-Tser Huang wrote: Because there was a mail whose subject is Children first in fork. Gotta watch out for source-code that uses a 'reaper' to kill children from SIGCHLD. We'll get auto-mail from pervert.snuffer.com. :-)I added @safestory.com to be forbidden in headers. This topic WILL die ;) Cheers, Dick Johnson /Matti Aarnio - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Problem with DHCP when using tokenring on 2.4.x
Hello, I have a problem with DHCP when using tokenring card on 2.4.x kernel . When I am using IBM tokenring adapter( all) and trying to hook on to the lan n/w using DHCP ,I get an error message operation failed from the dhcp client . The dhcp server is getting the broadcast message when the dhcp client is run. I am using pump that comes with 6.2 redhat distribution . There is no problem when using static IP. I could experience this problem only on 2.4.x . I am able to get a valid IP address on 2.2.x kernel when using tokenring adapter. And also there is no problem when using ethernet adapter on 2.4.x . . Has anyone experienced this problem on 2.4.x . Can any one help me to resolve this problem. Thanks Regards Shiju - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: Global FPU corruption in 2.2
child-flags |= PF_PTRACED; without waiting for the child to have stopped. I can see how this could case PF_USEDFPU to be cleared inadvertently, but I do not have any ideas for testing this. Is it clear that this is the source of the problem? There is no guarantee that |= is implemented atomically - in fact its quite likely to read get child-flags or PF_PTRACED write child-flags and a PF_USEDFPU on another processor at the same instant -would- end up being lost. There are two fixes 1. Make all the ops atomic (foo_bit()) 2. Split the flags The preferable one for performance is certainly to backport the 2.4 changes - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Single user linux
that also explain why win95 user doesn't want to use NT. not because they can't afford it (belive me, here NT costs only us$2), but additional headache isn't acceptable. I'm going to speak from experience: My mother, who is the biggest windoze fan on the face of the universe, got fed up with win98 and decided to move to win2k. The hole multi-user thing doesn't bother her in the slightest. She has a non-admin account for herself karen. You want a better example? My little cousin is not much into computers but he uses one enough to check mail, surf the web etc... Like many win98 users he was re-installing it about once a month. He finally got so fed up he asked me to install Linux for him! He is now very happy. He doesn't care about the fact that he has to type in his user name. He even doesn't know any shell commands. He would probably actually get concerned if he had to use root always because that would reveal the same problems that he was having with win98. There's a lot of things you can do to make Linux easier for newbies. None of them involve hacking the kernel. Have you tried Linux-Mandrake 8.0 yet? -- Garett Spencley - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
orinoco_cs IrDA
Hi Linus, I've got a question... I would like where to send my driver patches... One month ago, I sent a small update for the orinoco_cs driver and Wireless Extensions. I didn't put all the changes I had for orinoco_cs because I believe in small incremental updates limited to a specific area (even if all the changes are trivial). You ignored my patch (without feedback), whereas Alan picked it up (if I remember correctly it was included in his 'patch-2.4.2-ac28'). So now, what should I do with the rest of my updates and the new one that have accumulated since ? Should I wait until you grab the first patch from Alan's tree ? Should I send the new patches directly to Alan so that he can accumulate a monster patch ? Should I just accumulate the patches on my web page ? Another day, I will also tell you about the IrDA patches... Have fun... Jean - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hundreds of mount --bind mountpoints?
Al writes: Encapsulation part is definitely worth doing - it cleans the code up and doesn't change the result of compile. Adding allocation/freeing/ cache initialization/cache removal and chaninging FOOFS_I() definition - well, it's probably worth to keep such patches around, but whether to switch any individual filesystem during 2.4 is a policy decision. Up to maintainer, indeed. Notice that these patches (separate allocation per se) are going to be within 3-4Kb per filesystem _and_ completely straightforward. One thing to watch out for is that the current code zeros the u. struct for us (as you pointed out to me previously), but allocating from the slab cache will not... This could be an interesting source of bugs for some filesystems that assume zero'd inode_info structs. Fortunately, it doesn't appear that my patch to clean out all of the duplicate zero initializers in the fs-specific code was accepted... What I would like to avoid is scenario like: Maintainers of filesystems with large private inodes: Why would we separate them? We would only waste memory, since the other filesystems stay in -u and keep it large. Well, if we get rid of NFS (50 x __u32) and HFS (44 * __u32) (sizes are approximate for 32-bit arches - I was just counting by hand and not strictly checking alignment), then almost all other filesystems are below 25 * __u32 (i.e. half of the previous size). For large-private-inode filesystems, we are wasting memory in EVERY inode in the slab cache, not just ones in use with the large private inode. If it were the most common filesystem (ext2, maybe reiser, msdos next) then it wouldn't make much difference. At some point reducing the union size is not efficient to have separate slab allocations from a memory usage standpoint. The remaining info structs are (approx. for 32-bit arch) (size in __u32): ext227 affs26 ufs 25 socket 24 shmem 22 coda20 qnx418 minix 16 umsdos 15 hpfs15 efs 14 sysv13 reiser 12 udf 12 ntfs11 ncp 10 msdos 9 adfs7 smb 6 usbdev 5 proc4 iso 4 bfs 3 romfs 2 Maintainers of the rest of filesystems: Since there's no patches that would take large stuff out of -u, why would we bother? Maybe the size of the union can depend on CONFIG_*_FS? There should be an absolute minimum size (16 * __u32 or so), but then people who want reiserfs as their primary fs do not need to pay the memory penalty of ext2. For ext2 (the next largest and most common fs), we could make it part of the union if it is compiled in, and on a slab cache if it is a module? Should uncommon-but-widely-used things like socket and shmem have their own slab cache, or should they just allocate from the generic size-32 slab? Cheers, Andreas -- Andreas Dilger \ If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry? http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hundreds of mount --bind mountpoints?
On Tue, 24 Apr 2001, Andreas Dilger wrote: One thing to watch out for is that the current code zeros the u. struct for us (as you pointed out to me previously), but allocating from the slab cache will not... This could be an interesting source of bugs for some filesystems that assume zero'd inode_info structs. True, but easy to catch. Well, if we get rid of NFS (50 x __u32) and HFS (44 * __u32) (sizes are approximate for 32-bit arches - I was just counting by hand and not strictly checking alignment), then almost all other filesystems are below 25 * __u32 (i.e. half of the previous size). Yeah, but NFS suddenly takes 25+50 words... That's the type of complaints I'm thinking about. Maybe the size of the union can depend on CONFIG_*_FS? There should be an absolute minimum size (16 * __u32 or so), but then people who want reiserfs as their primary fs do not need to pay the memory penalty of ext2. For ext2 (the next largest and most common fs), we could make it part of the union if it is compiled in, and on a slab cache if it is a module? NO. Sorry about shouting, but that's the way to madness. I can understand code depending on SMP vs. UP and similar beasts, but presense of specific filesystems shudder Should uncommon-but-widely-used things like socket and shmem have their own slab cache, or should they just allocate from the generic size-32 slab? That's pretty interesting - especially for sockets. I wonder whether we would get problems with separate allocation of these - we don't go from inode to socket all that often, but... - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hundreds of mount --bind mountpoints?
Eric Mouw writes: Al is right, it is no rocket science. Here is a patch against 2.4.4-pre6 for procfs and isofs. It took me an hour to do because I'm not familiar with the fs code. It compiles, and the procfs code even runs (sorry, no CDROM player availeble on my embedded StrongARM system), though it is possible that there are some bugs in it. While I applaud your initiative, you made an unfortunate choice of filesystems to convert. The iso_inode_info is only 4*__u32, as is proc_inode_info. Given that we still need to keep a pointer to the external info structs, and the overhead of the slab cache itself (both CPU usage and memory overhead, however small), I don't think it is worthwhile to have isofs and procfs in separate slabs. On the other hand, sockets and shmem are both relatively large... Watch out that the *_inode_info structs have all of the fields initialized, because the union field is zeroed for us, but slab is not. Cheers, Andreas -- Andreas Dilger \ If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry? http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hundreds of mount --bind mountpoints?
On Tue, 24 Apr 2001, Andreas Dilger wrote: While I applaud your initiative, you made an unfortunate choice of filesystems to convert. The iso_inode_info is only 4*__u32, as is proc_inode_info. Given that we still need to keep a pointer to the external info structs, and the overhead of the slab cache itself (both CPU usage and memory overhead, however small), I don't think it is worthwhile to have isofs and procfs in separate slabs. On the other hand, sockets and shmem are both relatively large... Watch out that the *_inode_info structs have all of the fields initialized, because the union field is zeroed for us, but slab is not. Frankly, I'd rather start with encapsulation part. It's easy to verify, it can go in right now and it makes separate allocation part uncluttered. Besides, it simply makes code cleaner, so it makes sense even if don't want to go for separate allocation for that particular fs. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Device Registry (DevReg) Patch 0.2.0
On Tuesday 24 April 2001 18:43, mirabilos wrote: What about indenting? I think of 0 spaces before the device name, 1 space before properties which belong to the device. Structure per entry: [Space] Name colon property But what is the advantage? Its not less work in the kernel, and in user-space you need to write a parser for this. You would have made a new format for hierarchical data that no one else uses only to avoid using XML in the kernel. Is one level enough? I'm currently offline so didn't check the sample No, for example for USB you have the levels devices/configurations/interfaces/endpoints. bye... - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OFFTOPIC] Re: [PATCH] Single user linux
On Tue, 24 Apr 2001, Tomas Telensky wrote: But, what I should say to the network security, is that AFAIK in the most of linux distributions the standard daemons (httpd, sendmail) are run as root! Having multi-user system or not! Why? For only listening to a port 1024? Is there any elegant solution? httpd as root ? that's what i call a clueless network admin. sendmail has an OBSOLETE design. Use a good MTA like qmail. Exim or smail are ok, but they're still sendmailish. David Gómez The question of whether computers can think is just like the question of whether submarines can swim. -- Edsger W. Dijkstra - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hundreds of mount --bind mountpoints?
Al writes: Well, if we get rid of NFS (50 x __u32) and HFS (44 * __u32) (sizes are approximate for 32-bit arches - I was just counting by hand and not strictly checking alignment), then almost all other filesystems are below 25 * __u32 (i.e. half of the previous size). Yeah, but NFS suddenly takes 25+50 words... That's the type of complaints I'm thinking about. But then again, you are saving 50-25 words for every non-NFS inode, and I think _most_ systems will have more local inodes than NFS inodes. Even NFS servers will have local inodes, only clients (AFAIK) use nfs_inode_info. Maybe the size of the union can depend on CONFIG_*_FS? There should be an absolute minimum size (16 * __u32 or so), but then people who want reiserfs as their primary fs do not need to pay the memory penalty of ext2. For ext2 (the next largest and most common fs), we could make it part of the union if it is compiled in, and on a slab cache if it is a module? NO. Sorry about shouting, but that's the way to madness. I can understand code depending on SMP vs. UP and similar beasts, but presense of specific filesystems shudder But then again, if the size of nfs_inode_info changes, it is the same problem... sizeof(struct inode) may have changed (depends if slab has some padding between inodes or not). If we stick to a minimum size (16 words or maybe even 8), then it will never change anymore, and we do not have overhead for small inode_info structs. Should uncommon-but-widely-used things like socket and shmem have their own slab cache, or should they just allocate from the generic size-32 slab? That's pretty interesting - especially for sockets. I wonder whether we would get problems with separate allocation of these - we don't go from inode to socket all that often, but... I never thought of that. I guess the socket code does not know which fs the inode_info was allocated from, so it cannot free it from the slab (even if it had access to these slabs, which it does not). In that case, each fs would have struct socket as the minimum size allocatable, which is unfortunately one of the largest inode_info sizes. It is smaller than ext2, but... Any ideas? Do we ever get back into fs-specific clear_inode() from a socket? In that case, the socket would just hold a pointer to the fs-specific inode_info inside its own struct socket until the inode is dropped. Cheers, Andreas -- Andreas Dilger \ If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry? http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: Global FPU corruption in 2.2
Alan Cox [EMAIL PROTECTED] writes: The preferable one for performance is certainly to backport the 2.4 changes Is it any more substantial than changing all uses of the ptrace flags to the new variable? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lkml]Re: Matrox FB console driver
On Tue, Apr 24, 2001 at 06:19:31AM -0500, Andy Carlson wrote: time prime before x real1m23.535s user0m40.550s sys 0m42.980s /proc/mtrr before x reg00: base=0x ( 0MB), size= 256MB: write-back, count=1 reg01: base=0xfd80 (4056MB), size= 4MB: write-combining, count=1 time prime after x real0m48.732s user0m41.070s sys 0m7.690s /proc/mtrr after x reg00: base=0x ( 0MB), size= 256MB: write-back, count=1 reg01: base=0xfd80 (4056MB), size= 4MB: write-combining, count=1 time prime in X real0m42.835s user0m41.180s sys 0m1.710s Well, it isn't that. Still, it was recently discussed that X might leave some settings in the video-card (Matrox). So I tried the following: time spdtest.sh before X with spdtest.sh: #!/bin/sh i=1 while [ $i -lt 500 ] do clear echo $i cat test.out; i=`expr $i + 1` done and after X, no change. This is a G400/32 Mb with framebuffer @ 1600x1200x16bpp, and X 4.0.3, same resolution. Kernel 2.4.3-ac12, Abit VP6 dual P3/866. There was no significant change in any of the reported times. I don't know. Your problem is interesting. Do other programs have this too? Jurriaan -- And the gosts of hope walk silent halls At the death of the promised land All is gone, all is gone But these changing winds can turn cold and hostile New Model Army GNU/Linux 2.4.3-ac12 SMP/ReiserFS 2x1743 bogomips load av: 0.00 0.03 0.01 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Page_alloc / Swap 2.4.3 kernel BUG with system idle
Here is a bug report in the format requested by linux/REPORTING-BUGS. [1] Page_alloc / Swap 2.4.3 kernel BUG with system idle [2] The System was idle for 1h or so while I was away, and coming back I found it frozen. It was responding to ping, but telnet and relogin weren't working. According to /var/log/messages, it was running ( /sbin/rmmod -as) and (run-parts /etc/cron.hourly). Possibly it was running in background xmms but it was stopped, and multiple nedit windows were active. Xscreensaver 3.28 from tar.gz was running when I left the machine and it wasn't on when I came back. [3] Kernel Page_alloc/Swap [4] Linux version 2.4.3 (gcc version 2.96 2731 (Red Hat Linux 7.0)) #2 SMP Sun Apr 22 11:26:34 CEST 2001 [5] Apr 24 14:41:27 patagarro kernel: kernel BUG at page_alloc.c:73! Apr 24 14:41:27 patagarro kernel: invalid operand: Apr 24 14:41:27 patagarro kernel: CPU:1 Apr 24 14:41:27 patagarro kernel: EIP:0010:[__free_pages_ok+35/800] Apr 24 14:41:27 patagarro kernel: EFLAGS: 00010286 Apr 24 14:41:27 patagarro kernel: eax: 001f ebx: c1122908 ecx: 0082 edx: 0100 Apr 24 14:41:27 patagarro kernel: esi: c1122908 edi: ebp: c3775aa0 esp: c30dfdf8 Apr 24 14:41:27 patagarro kernel: ds: 0018 es: 0018 ss: 0018 Apr 24 14:41:27 patagarro kernel: Process rubik (pid: 1576, stackpage=c30df000) Apr 24 14:41:27 patagarro kernel: Stack: c023ad4b c023ae79 0049 6212 c1044010 c0291e80 0206 Apr 24 14:41:27 patagarro kernel:c1122908 c1122908 000f9000 c2a07c7c c012e2c5 c0a23620 c0101d1c d1936000 Apr 24 14:41:27 patagarro kernel:c0110691 c1122908 00e1 c0121e25 c1122908 0225 0040 Apr 24 14:41:27 patagarro kernel: Call Trace: [free_page_and_swap_cache+197/208] [swapper_pg_dir+3356/4096] [d1936000] [flush_tlb_all+17/96] [zap_page_range+453/624] [d1933004] [cc8c4020] Apr 24 14:41:27 patagarro kernel:[cc83f8e0] [d1933004] [exit_mmap+201/304] [mmput+55/96] [do_exit+213/656] [dequeue_signal+109/176] [do_signal+569/684] [sys_select+1138/1152] Apr 24 14:41:27 patagarro kernel:[sys_ioctl+521/528] [signal_return+20/24] Apr 24 14:41:27 patagarro kernel: Apr 24 14:41:27 patagarro kernel: Code: 0f 0b 83 c4 0c 8b 73 08 85 f6 74 16 6a 4b 68 79 ae 23 c0 68 Apr 24 14:45:40 patagarro kernel: kernel BUG at swap.c:183! Apr 24 14:45:40 patagarro kernel: invalid operand: Apr 24 14:45:40 patagarro kernel: CPU:0 Apr 24 14:45:40 patagarro kernel: EIP: 0010:[deactivate_page_nolock+184/336] Apr 24 14:45:40 patagarro kernel: EFLAGS: 00013282 Apr 24 14:45:40 patagarro kernel: eax: 001a ebx: c1122908 ecx: edx: 0002 Apr 24 14:45:40 patagarro kernel: esi: c1122908 edi: 0003 ebp: 0001 esp: cbf69fa0 Apr 24 14:45:40 patagarro kernel: ds: 0018 es: 0018 ss: 0018 Apr 24 14:45:40 patagarro kernel: Process kswapd (pid: 3, stackpage=cbf69000) Apr 24 14:45:40 patagarro kernel: Stack: c023a6eb c023a806 00b7 c1122924 c012cb79 c1122908 00010f00 c0296c80 Apr 24 14:45:40 patagarro kernel:0006 0008e000 c012cef6 0006 c0105000 0008e000 [6] No clue about the triggering effect [7] 2 smp PII-350 linux box based on Gigabyte GA-6bxd ( chipset 440bx, bios version f2). 4 dimm socket: 1 64 pc100, 1 128 pc100, 2 free. Asus 3400tnt/tv 16 MB , agp 2X. Other information in dmesg: Linux version 2.4.3 (gcc version 2.96 2731 (Red Hat Linux 7.0)) #2 SMP Sun Apr 22 11:26:34 CEST 2001 BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: fec0 - fec01000 (reserved) BIOS-e820: fee0 - fee01000 (reserved) BIOS-e820: - 0001 (reserved) BIOS-e820: 0010 - 0bff (usable) BIOS-e820: 0bff3000 - 0c00 (ACPI data) BIOS-e820: 0bff - 0bff3000 (ACPI NVS) Scan SMP from c000 for 1024 bytes. Scan SMP from c009fc00 for 1024 bytes. Scan SMP from c00f for 65536 bytes. found SMP MP-table at 000f5b30 hm, page 000f5000 reserved twice. hm, page 000f6000 reserved twice. hm, page 000f1000 reserved twice. hm, page 000f2000 reserved twice. On node 0 totalpages: 49136 zone(0): 4096 pages. zone(1): 45040 pages. zone(2): 0 pages. Intel MultiProcessor Specification v1.1 Virtual Wire compatibility mode. OEM ID: OEM0 Product ID: PROD APIC at: 0xFEE0 Processor #0 Pentium(tm) Pro APIC version 17 Floating point unit present. Machine Exception supported. 64 bit compare exchange supported. Internal APIC present. SEP present. MTRR present. PGE present. MCA present. CMOV present. Bootup CPU Processor #1 Pentium(tm) Pro APIC version 17 Floating point unit present. Machine Exception supported. 64
Re: Spurious interrupts for UP w/ IO-APIC on ServerWorks
I've got a dual-processor system built around the Intel SBT2 motherboard, which uses the ServerWorks LE chipset. 2.4.3 SMP works fine. When I build a UP kernel with IO-APIC support, I get this during boot: Turn off the OSB4 driver - bet that helps 2.4.3 has this behavior, 2.4.3-ac9 works fine. I found this in the -ac changelog; perhaps it's relevant: 2.4.2-ac12 [...] o Remove serverworks handling. The BIOS is our (me) best (and right now only) hope for that chip Yep. Thats the bug fix you need. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: orinoco_cs IrDA
patch (without feedback), whereas Alan picked it up (if I remember correctly it was included in his 'patch-2.4.2-ac28'). So now, what should I do with the rest of my updates and the new one that have accumulated since ? Should I wait until you grab the first patch from Alan's tree ? Should I send the new patches directly to Alan so that he can accumulate a monster patch ? Should I just accumulate the patches on my web page ? Im happy to accumulate them but please send them to Linus too. I tend not to submit stuff on to Linus where there is an active maintainer and assume the maintainer will do it when ready. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: Global FPU corruption in 2.2
On Tue, Apr 24, 2001 at 06:56:32PM +0200, Christian Ehrhardt wrote: On Tue, Apr 24, 2001 at 09:10:07AM -0700, Linus Torvalds wrote: ptrace only operates on processes that are stopped. So there are no locking issues - we've synchronized on a much higher level than a spinlock or semaphore. This is only true for requests other than PTRACE_ATTACH and PTRACE_ATTACH is exactly what I'm worried about. May I remind everybody that at the beginning of this thread I posted another example, from an SMP Alpha, of FPU problems. It certainly was not exactly like the one under discussion but it looked that it had a similar smell to it. It looks like that to reproduce this Alpha example one needs processors with a rather fast clock and this hardware version is not yet very widely available. Michal - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sym53c875 error
On Tue, 24 Apr 2001, Hamilton, Eamonn wrote: Hi Folks. Under all of the kernels I have access to try ( 2.2.19, 2.4.X 2.4.X-ac* ), when I try and write an image in XA2 format to my SCSI writer ( Yamaha CDR-400t ), I get a DMA overrun. When I try with a kernel patched with the beta symbios driver ( 2.1.9 ), it works just fine. Interesting. Note that sym-2.1.9 status is probably far better than beta. I just haven't information enough to know how reliable this driver version actually is. FYI, I use sym-2.1.x under Linux and FreeBSD since several months. The NetBSD port is still work in progress, but the driver works just fine for me under this O/S too. This is on a Debian woody system, using cdrecord 1.10 ( also 1.9 and 1.8 with the same symptoms ) attached to a Tekram DC390F. Transcript as follows : cdrecord dev=0,3,0 -dummy -xa2 firmware.iso Cdrecord 1.10a18 (i686-pc-linux-gnu) Copyright (C) 1995-2001 Jörg Schilling scsidev: '0,3,0' scsibus: 0 target: 3 lun: 0 Linux sg driver version: 3.1.17 Using libscg version 'schily-0.5' Device type: Removable CD-ROM Version: 2 Response Format: 2 Capabilities : Vendor_info: 'YAMAHA ' Identifikation : 'CDR400t ' Revision : '1.0q' Device seems to be: Yamaha CDR-400. Using generic SCSI-3/mmc CD-R driver (mmc_cdr). Driver flags : SWABAUDIO Starting to write CD/DVD at speed 1 in dummy mode for single session. Last chance to quit, starting dummy write in 1 seconds. cdrecord: Input/output error. write_g1: scsi sendcmd: retryable error CDB: 2A 00 00 00 01 C2 00 00 1F 00 status: 0x0 (GOOD STATUS) DMA overrun, resid: -248 Would be interesting to know how cdrecord calculates the residual. It should probably use the return value from read()/write(). Does it ? cmd finished after 0.579s timeout 40s write track data: error after 0 bytes Sense Bytes: 70 00 00 00 00 00 00 0A 00 00 00 00 00 00 00 00 00 00 And while that lot happens, I get sym53c875-0-3,*: target did not report SYNC. This message is not normal given the device that for sure supports synchronous data transfers. I will look into this problem, first. sym53c875-0-3,*: extraneous data discarded. sym53c875-0-3,*: COMMAND FAILED (89 0) @c12a3800. This one could have been triggerred by previous errors ???. Standard burns work ok, it's just the xa2 stuff I have a problem with so far. I also tried using the old NCR driver with the same results. If you mean that the ncr53c8xx driver gets the same error, then the cause can be a either common bug in sym53c8xx and ncr53c8xx, or caused by a difference between sym53c8xx/ncr53c8xx and sym-2.1.9. The main difference that comes to mind is that sym-2 uses the new error handling interface but sym53c8xx/ncr53c8xx use the old one. If it is the cause, then the sg driver might get involved in the failure. Anybody got any ideas? No more than the above for now. Will let you know if I get better ones. Regards, Gérard. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.2.19 and file lock on NFS?
Hi, Recently upgraded to 2.2.19, along with new nfs-utils(0.3.1). But I have a program that requires a exclusive write lock on a NFSed directory. When I was using 2.2.17 all was ok, but now it returns ENOLCK. Does anybody else have the same problem? Thanks -Andrew - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Spurious interrupts for UP w/ IO-APIC on ServerWorks
Alan Cox wrote: I've got a dual-processor system built around the Intel SBT2 motherboard, which uses the ServerWorks LE chipset. 2.4.3 SMP works fine. When I build a UP kernel with IO-APIC support, I get this during boot: Turn off the OSB4 driver - bet that helps It does -- no more spurious interrupts. Thanks -- Jim -- Jim Schutt [EMAIL PROTECTED] Sandia National Laboratories, Albuquerque, New Mexico USA - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hundreds of mount --bind mountpoints?
On Tue, Apr 24, 2001 at 12:47:38PM -0600, Andreas Dilger wrote: While I applaud your initiative, you made an unfortunate choice of filesystems to convert. The iso_inode_info is only 4*__u32, as is proc_inode_info. Given that we still need to keep a pointer to the external info structs, and the overhead of the slab cache itself (both CPU usage and memory overhead, however small), I don't think it is worthwhile to have isofs and procfs in separate slabs. Well, I know a little bit about procfs because I'm currently documenting it, so that's why I picked it first. After I got the idea, isofs was quite easy. In retrospect it would have been more effective to pick a filesystem with a larger *_inode_info field, but then again: Al is right. Struct inode is cluttered with *_inode_info fields, while we use anonymous data entries in other parts of the kernel (like the data pointer in struct proc_dir_entry, or the priv pointer in struct net_device). There is another advantage: suppose you're hacking on a filesystem and change it's *_fs_i.h header. With Al's proposal you only have to recompile the filesystem you're hacking on, while you have to recompile the complete kernel in the current situation. Erik -- J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department of Electrical Engineering, Faculty of Information Technology and Systems, Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [EMAIL PROTECTED] WWW: http://www-ict.its.tudelft.nl/~erik/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
BUG: USB/Reboot
If USB is disabled on a server works MB reboots hang in 2.2.x - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: USB/Reboot
If USB is disabled on a server works MB reboots hang in 2.2.x In almost all cases a hang after Linux reboots the system and it not coming back to the BIOS is a BIOS bug. You can confirm this by asking the kernel to do a real bios reboot with the reboot= option - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hundreds of mount --bind mountpoints?
== Alexander Viro [EMAIL PROTECTED] writes:
On Mon, 23 Apr 2001, Jan Harkes wrote:
On Mon, Apr 23, 2001 at 10:45:05PM +0200, Ingo Oeser wrote:
BTW: Is it still less than one page? Then it doesn't make me
nervous. Why? Guess what granularity we allocate at, if we
just store pointers instead of the inode.u. Or do you like
every FS creating his own slab cache?
Oh, for crying out loud. All it takes is half an hour per
filesystem. Here - completely untested patch that does it for
NFS. Took about that long. Absolutely straightforward, very
easy to verify correctness.
Some stuff may need tweaking, but not much (e.g. some functions
should take nfs_inode_info instead of inodes, etc.). From the
look of flushd cache it seems that we would be better off with
cyclic lists instead of single-linked ones for the hash, but I
didn't look deep enough.
So consider the patch below as proof-of-concept. Enjoy:
Hi Al,
I believe your patch introduces a race for the NFS case. The problem
lies in the fact that nfs_find_actor() needs to read several of the
fields from nfs_inode_info. By adding an allocation after the inode
has been hashed, you are creating a window during which the inode can
be found by find_inode(), but during which you aren't even guaranteed
that the nfs_inode_info exists let alone that it's been initialized
by nfs_fill_inode().
One solution could be to have find_inode sleep on encountering a
locked inode. It would have to be something along the lines of
static struct inode * find_inode(struct super_block * sb, unsigned long ino, struct
list_head *head, find_inode_t find_actor, void *opaque)
{
struct list_head *tmp;
struct inode * inode;
tmp = head;
for (;;) {
tmp = tmp-next;
inode = NULL;
if (tmp == head)
break;
inode = list_entry(tmp, struct inode, i_hash);
if (inode-i_ino != ino)
continue;
if (inode-i_sb != sb)
continue;
if (find_actor) {
if (inode-i_state I_LOCK) {
spin_unlock(inode_lock);
__wait_on_inode(inode);
spin_lock(inode_lock);
tmp = head;
continue;
}
if (!find_actor(inode, ino, opaque))
continue;
}
break;
}
return inode;
}
Cheers,
Trond
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: hundreds of mount --bind mountpoints?
On Tue, Apr 24, 2001 at 02:49:23PM -0400, Alexander Viro wrote: On Tue, 24 Apr 2001, Andreas Dilger wrote: One thing to watch out for is that the current code zeros the u. struct for us (as you pointed out to me previously), but allocating from the slab cache will not... This could be an interesting source of bugs for some filesystems that assume zero'd inode_info structs. True, but easy to catch. Jepp. Just request SLAB_ZERO (still to be implemented) instead of SLAB_POISON or provide an constructor. A nice set of macros for this would make it quite easy. The ctor is the way to handle it. May be we could even put all the fs specific initalizers into it (e.g. magics, zeroes). Regards Ingo Oeser -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag http://www.tu-chemnitz.de/linux/tag been there and had much fun - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hundreds of mount --bind mountpoints?
On 24 Apr 2001, Trond Myklebust wrote: Hi Al, I believe your patch introduces a race for the NFS case. The problem lies in the fact that nfs_find_actor() needs to read several of the fields from nfs_inode_info. By adding an allocation after the inode has been hashed, you are creating a window during which the inode can be found by find_inode(), but during which you aren't even guaranteed that the nfs_inode_info exists let alone that it's been initialized by nfs_fill_inode(). _Ouch_. So what are you going to do if another iget4() comes between the moment when you hash the inode and set these fields? You are filling them only after you drop inode_lock, so AFAICS the current code has the same problem. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: orinoco_cs IrDA
On Tue, Apr 24, 2001 at 08:47:30PM +0100, Alan Cox wrote: patch (without feedback), whereas Alan picked it up (if I remember correctly it was included in his 'patch-2.4.2-ac28'). So now, what should I do with the rest of my updates and the new one that have accumulated since ? Should I wait until you grab the first patch from Alan's tree ? Should I send the new patches directly to Alan so that he can accumulate a monster patch ? Should I just accumulate the patches on my web page ? Im happy to accumulate them but please send them to Linus too. I tend not to submit stuff on to Linus where there is an active maintainer and assume the maintainer will do it when ready. Oups ! Big mea culpa ! Apologies. While trying to compile my kernel, I've just realised the the patch I've downloaded wasn't complete. My browser cut it in the middle claiming that it was 100% complete. Downloaded the patch again (patch-2.4.4-pre6), checked that it was complete, my patch is in. Oups ! Do I feel stupid... Apologies to everybody... Sorry for the confusion... Jean - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: how does linux support domino?
Xiong Zhao wrote: hello.on linux we will see a new domino server process/thread is created for each client.how does linux do this?does it use pthread?using fork or clone or someway else?what's the common way of linux to support apps like lotus domino that will have lots of concurrent users which are served by seperate server process/thread? regards james Well, in Linux there is no separate concept of threads, so each thread is a separate process with it's own PID and the PPID of the main thread. In fact pthread_create() sits just on top of clone(). The way each program handles multiple conections is up to the program, for example apache 1.3 and below does a fork(), mozilla does a pthread_create(), BOA does a select() in only one process, and apache 2.0 and up does both a fork() and pthread_create(). -- Jorge Nerin [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Compiled sound causes loss of scrollback console : 2.4.4-p6
While tracking down a sound problem, I decided to compile in the soundblaster rather than use modules. It's been a long time since I ran sound under linux, but that used to work fine. I watched the reboot, noticed the usual isapnp stuff (part of problem) ... PCI: Probing PCI hardware Limiting direct PCI/PCI transfers. Activating ISA DMA hang workarounds. isapnp: Scanning for PnP cards... isapnp: Calling quirk for 01:00 isapnp: SB audio device quirk - increasing port range isapnp: Card 'Creative SB16 PnP' isapnp: 1 Plug Play card detected total ... and then noticed that there were no soundblaster messages and tried to scrollback to verify. Pressing Shift-PageUp did absolutely nothing. The only change was to move from modules to compiled for sound, OSS, and soundblaster. Booting the previous kernel(s) showed a working scrollback. 2.4.4-pre6 compiled under gcc 2.95.3 20010315 release. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] properly detect ActionTec modem of PCI_CLASS_COMMUNICATION_OTHER
On Tue, Apr 24, 2001 at 05:18:36PM -0400, Brian Gerst wrote:
Steven Walter wrote:
This patch allows the serial driver to properly detect and set up the
ActionTec PCI modem. This modem has a PCI class of COMMUNICATION_OTHER,
which is why this modem is not otherwise detected.
Any suggestions on the patch are welcome. Thanks
A small suggestion: Vendor/device id are sufficient to identify the
device. You can change PCI_CLASS_COMMUNICATION_OTHER 8 to 0.
Excellent suggestion. Follows is the amended patch. Compiled and
tested to work. BTW: patch is against 2.4.3.
--
-Steven
In a time of universal deceit, telling the truth is a revolutionary act.
-- George Orwell
--- clean-2.4.3/drivers/char/serial.c Fri Mar 30 23:15:33 2001
+++ linux/drivers/char/serial.c Tue Apr 24 16:32:02 2001
@@ -4706,6 +4728,8 @@
static struct pci_device_id serial_pci_tbl[] __devinitdata = {
+ { PCI_VENDOR_ID_ATT, PCI_DEVICE_ID_ATT_VENUS_MODEM,
+ PCI_ANY_ID, PCI_ANY_ID, },
{ PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
PCI_CLASS_COMMUNICATION_SERIAL 8, 0x00, },
{ 0, }
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: hundreds of mount --bind mountpoints?
== Alexander Viro [EMAIL PROTECTED] writes: _Ouch_. So what are you going to do if another iget4() comes between the moment when you hash the inode and set these fields? You are filling them only after you drop inode_lock, so AFAICS the current code has the same problem. The entire call to iget4() is protected by the BKL in all relevant instances. As long as we don't sleep between find_inode() and nfs_fill_inode(), we're safe. In fact the BKL protection is needed also for another reason: we don't actually initialize the inode in the I_LOCK-protected read_inode() but instead rely on the caller of iget4 to do it for us. The reason is that one we would need to pass the struct nfs_fattr to read_inode() and this wasn't possible until the ReiserFS people introduced read_inode2(). Cheers, Trond - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.19 and file lock on NFS?
== apark [EMAIL PROTECTED] writes: Hi, Recently upgraded to 2.2.19, along with new nfs-utils(0.3.1). But I have a program that requires a exclusive write lock on a NFSed directory. When I was using 2.2.17 all was ok, but now it returns ENOLCK. Does anybody else have the same problem? Thanks Hi, You are probably failing to run the statd daemon or you may have set up over-restrictive /etc/hosts.(allow|deny). See the latest NFS-HOWTO for a full description on how to set up locking. Cheers, Trond - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: orinoco_cs IrDA
On Tue, Apr 24, 2001 at 03:15:08PM -0700, Jean Tourrilhes wrote:
[...]
Downloaded the patch again (patch-2.4.4-pre6), checked that it
was complete, my patch is in. Oups ! Do I feel stupid...
Let's finish this story. As indicated above, the first
fragment of the patch I sent on month ago is in the kernel. The two
other fragments didn't make it. They are attached...
wireless.v11b.diff :
--
Update the various wireless LAN driver in the kernel to
version 11 (definition already in the kernel). This update is
necessary to avoid crashes in the user space utilities.
orinoco_w11.diff :
Same deal for the new orinoco_cs driver.
I've also added the retry limit setting, but this feature is
not enabled (priv-has_retry = 0).
Alan : those two are already in your last kernel, please ignore.
Linus : those are not in your kernel.
That's it...
Jean
diff -u -p linux/drivers/net/wireless.25/wavelan.c linux/drivers/net/wavelan.c
--- linux/drivers/net/wireless.25/wavelan.c Wed Mar 28 17:27:27 2001
+++ linux/drivers/net/wavelan.c Wed Mar 28 17:28:34 2001
@@ -2028,8 +2028,17 @@ static int wavelan_ioctl(struct net_devi
if (wrq-u.data.pointer != (caddr_t) 0) {
struct iw_range range;
- /* Set the length (useless: it's constant). */
+ /* Set the length (very important for backward
+* compatibility) */
wrq-u.data.length = sizeof(struct iw_range);
+
+ /* Set all the info we don't care or don't know
+* about to zero */
+ memset(range, 0, sizeof(range));
+
+ /* Set the Wireless Extension versions */
+ range.we_version_compiled = WIRELESS_EXT;
+ range.we_version_source = 9;
/* Set information in the range struct. */
range.throughput = 1.6 * 1000 * 1000; /* don't argue on this
! */
diff -u -p linux/drivers/net/pcmcia/wireless.25/wavelan_cs.c
linux/drivers/net/pcmcia/wavelan_cs.c
--- linux/drivers/net/pcmcia/wireless.25/wavelan_cs.c Wed Mar 28 17:21:02 2001
+++ linux/drivers/net/pcmcia/wavelan_cs.c Wed Mar 28 17:23:19 2001
@@ -2239,8 +2239,15 @@ wavelan_ioctl(struct net_device *dev,/
{
struct iw_range range;
- /* Set the length (useless : its constant...) */
+ /* Set the length (very important for backward compatibility) */
wrq-u.data.length = sizeof(struct iw_range);
+
+ /* Set all the info we don't care or don't know about to zero */
+ memset(range, 0, sizeof(range));
+
+ /* Set the Wireless Extension versions */
+ range.we_version_compiled = WIRELESS_EXT;
+ range.we_version_source = 9; /* Nothing for us in v10 and v11 */
/* Set information in the range struct */
range.throughput = 1.4 * 1000 * 1000; /* don't argue on this ! */
diff -u -p linux/drivers/net/pcmcia/wireless.25/netwave_cs.c
linux/drivers/net/pcmcia/netwave_cs.c
--- linux/drivers/net/pcmcia/wireless.25/netwave_cs.c Wed Mar 28 17:24:40 2001
+++ linux/drivers/net/pcmcia/netwave_cs.c Wed Mar 28 17:29:39 2001
@@ -710,8 +710,17 @@ static int netwave_ioctl(struct net_devi
if(wrq-u.data.pointer != (caddr_t) 0) {
struct iw_range range;
- /* Set the length (useless : its constant...) */
+ /* Set the length (very important for backward compatibility) */
wrq-u.data.length = sizeof(struct iw_range);
+
+ /* Set all the info we don't care or don't know about to zero */
+ memset(range, 0, sizeof(range));
+
+#if WIRELESS_EXT 10
+ /* Set the Wireless Extension versions */
+ range.we_version_compiled = WIRELESS_EXT;
+ range.we_version_source = 9; /* Nothing for us in v10 and v11 */
+#endif /* WIRELESS_EXT 10 */
/* Set information in the range struct */
range.throughput = 450 * 1000; /* don't argue on this ! */
diff -u -p linux/drivers/net/pcmcia/wireless.25/ray_cs.c
linux/drivers/net/pcmcia/ray_cs.c
--- linux/drivers/net/pcmcia/wireless.25/ray_cs.c Wed Mar 28 17:21:57 2001
+++ linux/drivers/net/pcmcia/ray_cs.c Wed Mar 28 17:30:16 2001
@@ -1332,8 +1332,14 @@ static int ray_dev_ioctl(struct net_devi
struct iw_range range;
memset((char *) range, 0, sizeof(struct iw_range));
- /* Set the length (useless : its constant...) */
+ /* Set the length (very important for backward compatibility) */
wrq-u.data.length = sizeof(struct iw_range);
+
+#if WIRELESS_EXT 10
+ /* Set the Wireless Extension versions */
+ range.we_version_compiled = WIRELESS_EXT;
+ range.we_version_source
Re: [PATCH] Longstanding elf fix (2.4.3 fix)
On 23 Apr 2001 12:54:22 -0600, Eric W. Biederman [EMAIL PROTECTED] wrote: I'll include it again. I had it attached as a plain text attachment, I don't know if that is a problem or not. Actually it was attached as text/x-patch, not as text/plain... so pine certainly refused to display it inline. Ion -- It is better to keep your mouth shut and be thought a fool, than to open it and remove all doubt. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] adding PCI bus information to SCSI layer
Thanks everyone for your input again. I've made the changes suggested, and would appreciate this being applied to Linus' and Alan's trees. This is necessary for solving the what disk does BIOS think is my boot disk problem on IA-64, and I hope to extend it to IA-32 when BIOSs permit. Jeff Garzik recommended the IOCTL return pci_dev::slot_name, so now it does, and this simplifies the ioctl greatly. Doug Gilbert recommended wrapping things in #ifdef's, so I created a new CONFIG_SCSI_PCI_INFO define. Patches against 2.4.4-pre6 are available at http://domsch.com/linux/scsi/. linux-2.4.4-pre6-scsi-pci-info-010424.patch - Adds the IOCTL and CONFIG_SCSI_PCI_INFO, and touches a bunch of SCSI drivers. scsimon_243_1_pci-010424.patch - Changes scsimon Makefile and sm_test.c to support this. scsimon_243_1_pci_driver.patch - Changes scsimon.[ch] to support this. When this goes in, I request the assistance of the SCSI driver maintainers. I've changed quite a few drivers, but couldn't easily see how to change a few others. I am bcc'ing the maintainers of drivers I changed or need help from. Drivers that I changed: 3w-.c AM53C974.c advansys.c aic7xxx_old.c atp870u.c cpqfcTSinit.c dmx3191d.c fdomain.c gdth.c ips.c ncr53c8xx.c qla1280.c qlogicfc.c qlogicisp.c sym53c8xx.c tmscsim.c megaraid.c 53c7,8xx.c pci2000.c pci2220i.c Non-trivial drivers that I didn't change, but request their maintainers do so: BusLogic.c aic7xxx.c eata.c eata_dma.c eata_pio.c ini9100u.c inia100.c Drivers I didn't need to change (they're not PCI devices, best as I can tell): NCR53C9x.c NCR53c406a.c aha152x.c aha1542.c aha1740.c esp.c fd_mcs.c ibmmca.c ide-scsi.c imm.c in2000.c mac53c94.c mesh.c ppa.c qlogicfas.c qlogicpti.c sgiwd93.c sim710.c sym53c416.c u14-34f.c ultrastor.c 53c7xx.c a2091.c a3000.c atari_scsi.c dtc.c fcal.c g_NCR5380.c gvp11.c mac_scsi.c mvme147.c pas16.c pluto.c psi240i.c seagate.c sun3_scsi.c t128.c wd7000.c Thanks, Matt -- Matt Domsch Sr. Software Engineer Dell Linux Systems Group Linux OS Development www.dell.com/linux - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2001-04-24 release of hotplug scripts
I've just packaged up the latest Linux hotplug scripts into a release, which can be found at: http://sourceforge.net/project/showfiles.php?group_id=17679 This release adds the Debian scripts to the tarball, although all of the debian specific changes were not merged into the main scripts, it would have caused too much conflict, sorry. But the Debian patch is now much smaller :) It also adds a hotplug manpage donated by Debian developer Fumitoshi UKAI. Numerous little changes were also added to the scripts, here is the full changelog: - added debian hotplug.8 manpage by Fumitoshi UKAI - bugfixes to modprobing - make sure setup scripts run even when there is no module - event not supported only seen if debugging - added debian directory filled with things needed to package the scripts for a debian release. - make sure setup scripts (for usermode drivers/apps) will run even without a kernel driver - bugfix match_flags support from Gioele Barabuci; might require bash2-isms - add kernel 2.2.18 bcdDevice bug workaround (Ben Woodard) - cleanups from Gioele Barabuci - tweaked the post and preun sections to fix problem of hotplug not starting automatically when the package is upgraded. I've built RedHat 6.x and 7.x specific rpms due to some small differences in where the two version place their documentation. The individual releases are at: For RedHat 6.x: http://prdownloads.sourceforge.net/linux-hotplug/hotplug-2001_04_24-1_6.x.noarch.rpm http://prdownloads.sourceforge.net/linux-hotplug/hotplug-2001_04_24-1_6.x.src.rpm For RedHat 7.x: http://prdownloads.sourceforge.net/linux-hotplug/hotplug-2001_04_24-1_7.x.noarch.rpm http://prdownloads.sourceforge.net/linux-hotplug/hotplug-2001_04_24-1_7.x.src.rpm Source tarball: http://prdownloads.sourceforge.net/linux-hotplug/hotplug-2001_04_24.tar.gz greg k-h - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Semi-OT] Dual Athlon support in kernel
On Tue, Apr 24, 2001 at 01:22:15AM -0400, Mike A. Harris wrote: Also, what is a good rock solid SCSI RAID controller? Money is no object. Reliability, performance and Linux compatibility are though. I have very good experiences with the Mylex controllers/drivers! But then again I also have good experiences with the new-style SW-RAID; it performs very well indead and it is quite cheap :) Regards, Martin -- There's no place like ~ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] adding PCI bus information to SCSI layer
At 3:59 PM -0600 4/24/01, Richard Gooch wrote: The plan I have (which I hope to get started on soon, now that I'm back from travels), is to change /dev/scsi/host# from a directory into a symbolic link to a directory called: /dev/bus/pci0/slot1/function0. Thus, to access a partition via location, one would use the path: /dev/bus/pci0/slot1/function0/bus0/target1/lun2/part3. A minor PCI terminology point: PCI buses are subdivided into devices, not (necessarily) slots. So, for example, a multiple-device PCI card (say, two SCSI controllers) might have a PCI bridge creating a new bus, and two devices (not slots) on that bus. (It could alternatively be implemented as a single device with two functions, given a dual-interface chip, but not necessarily.) So a better name would be /dev/bus/pci0/dev1/fcn0/bus0/tgt1/lun2/part3 (taking the liberty of abbreviating some of the other names). How, if at all, would RAID devices, using more than one physical device, or SCSI bus, or PCI card, fit into this naming scheme? -- /Jonathan Lundell. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Single user linux
Quit being a naysayer. UNIX on a PDA is a wet dream. What real value does it have, apart from the geek look at me, I'm using bash value? It means I can do anything on my ipaq I can do anywhere else. I can run multiple apps at a time. I can run X11. I can run the palm emulator even ;) Its the same reason Linux is valuable on an S/390 mainframe. Its a common pool of apps, environments and tools. Anything your PC can do, my ipaq can do. Alan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Single user linux
On Wed, Apr 25, 2001 at 10:07:48AM +1000, Daniel Stone wrote: What real value does it have, apart from the geek look at me, I'm using bash value? I don't really want to get into it at the moment, but imagine hacking netfilter without lugging a laptop around. PDA's are sleek and cool, and using UNIX on them lets you write shell scripts to sort your addresses and stuff like that. Basically it's everything that's cool about Unix as a workstation OS scaled down to PDA-size. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Mail boucing...
Sorry if my mail has been bouncing. I've been experimenting with some configurations and I am moving tomorrow so my domain/IP will be changing. Whoever, deleted me from list, thanks. Please don't block sh0n.net though from posting. I'll read myself when my new IP is added to my domain. Thank you. Shawn. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Single user linux
At 5:01 PM -0700 2001-04-24, Aaron Lehmann wrote: On Tue, Apr 24, 2001 at 11:38:01PM +1000, Daniel Stone wrote: And UNIX on a phone is pure overkill. Quit being a naysayer. UNIX on a PDA is a wet dream. http://www.agendacomputing.com/ (not that the reviews have been very kind) -- /Jonathan Lundell. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Single user linux
On Tue, Apr 24, 2001 at 05:20:27PM -0700, Aaron Lehmann wrote: On Wed, Apr 25, 2001 at 10:07:48AM +1000, Daniel Stone wrote: What real value does it have, apart from the geek look at me, I'm using bash value? I don't really want to get into it at the moment, but imagine hacking netfilter without lugging a laptop around. PDA's are sleek and cool, and using UNIX on them lets you write shell scripts to sort your addresses and stuff like that. Basically it's everything that's cool about Unix as a workstation OS scaled down to PDA-size. True, but then imagine trying to hack C (no, that's a CURLY BRACE, and a tab! not space! you just broke my makefiles! aargh!), and compiling Netfilter (it takes HOW MANY hours to compile init/main.c?!?) on a PDA. Hrmz. -- Daniel Stone Linux Kernel Developer [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Single user linux
On Tue, Apr 24, 2001 at 05:35:10PM -0700, Aaron Lehmann wrote: On Wed, Apr 25, 2001 at 10:32:46AM +1000, Daniel Stone wrote: True, but then imagine trying to hack C (no, that's a CURLY BRACE, and a tab! not space! you just broke my makefiles! aargh!), and compiling Netfilter (it takes HOW MANY hours to compile init/main.c?!?) on a PDA. Hrmz. I didn't say it was practical. But those PDA's are getting downright speedy. Much faster than UNIX workstations from days of old. Please, oh please, tell me my machine would beat it on a time make bzImage. Else I'll do something really stupid. Like, get one for my workstation and feel the improvement ;) Input is a big problem, but we'll leave that to technology (speech? microkeyboards?) Aye - difference between space and tab. Broken Makefiles, anyone? -- Daniel Stone Linux Kernel Developer [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Single user linux
In article [EMAIL PROTECTED], Alan Cox [EMAIL PROTECTED] wrote: Quit being a naysayer. UNIX on a PDA is a wet dream. What real value does it have, apart from the geek look at me, I'm using bash value? It means I can do anything on my ipaq I can do anywhere else. I can run multiple apps at a time. I can run X11. I can run the palm emulator even ;) Its the same reason Linux is valuable on an S/390 mainframe. Its a common pool of apps, environments and tools. Anything your PC can do, my ipaq can do. Or even if you only ever use the builtin apps on your Linux PDA, it means you didn't subsidize Microsoft. -- __O Lineo - For Embedded Linux Solutions _-\,_ 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] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Event tools, do they exist
This is an attempt to look in the wheel locker. I need a simple event sub system for use in the kernel. I envision at least two types of events: the history event and the timing event. The timing event would keep track of start/stop times by class. If, for example, I wanted to know how much time the kernel spends doing the recalc in schedule() I would put and event start in front of it and an end at the other end. The sub system would note the first event time and the cumulative time between all starts and stops on the same event. When reported by /proc/ it would give the total event time, the elapsed time and the % of processor time for each of the possibly several classes. The history event would record each events time, location, data1, data2. It would keep N of these (the last N) and report M (M=N) via /proc/. This list should also be kept in a format that a simple debugger can easily examine. Somebody must have written these routines and have them in their library. Sure would help if I could have a peek. George - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Single user linux
On Wed, 25 Apr 2001, Daniel Stone wrote: OK. time make bzImage. Of course, mine's really slow (and I will consider myself publically humiliated if my only Linux machine is beaten on a kernel compile by an iPAQ). I 'spose, if it only goes into suspend, the ability to write uptime on it constitutes a walking penis extension after a while? When I first started I compiled my linux kernels on a 386 dx with 8 mb ram heh. I think a lot of the current PDAs are faster. Gerhard -- Gerhard Mack [EMAIL PROTECTED] As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Process start times moving in reverse on 2.4.x
I've been having continual unexplained lockup problems since converting one of my outgoing qmail servers to 2.4.x. This has been discussed before on this list, where the symptoms are that anything typed on console takes forever to actually come up, and after a few minutes the machine is so unresponsive it requires a powercycle. Noticed that when this box is in its state of unresponsiveness, the process start times in ps gradually move backwards. The following listings were taken over about a 1.5 hour timespan. First root 1 0 0 11:04 ?00:00:09 init root 2 1 0 11:04 ?00:00:00 [keventd] root 3 1 0 11:04 ?00:00:00 [kswapd] root 4 1 0 11:04 ?00:00:00 [kreclaimd] root 5 1 0 11:04 ?00:00:00 [bdflush] root 6 1 0 11:04 ?00:00:02 [kupdated] root96 1 0 11:06 ?00:00:00 [kreiserfsd] root 356 1 0 11:06 ?00:00:02 syslogd -m 0 root 366 1 0 11:06 ?00:00:00 klogd Second root 1 0 0 10:54 ?00:00:09 init root 2 1 0 10:54 ?00:00:00 [keventd] root 3 1 0 10:54 ?00:00:00 [kswapd] root 4 1 0 10:54 ?00:00:00 [kreclaimd] root 5 1 0 10:54 ?00:00:00 [bdflush] root 6 1 0 10:54 ?00:00:02 [kupdated] root96 1 0 10:56 ?00:00:00 [kreiserfsd] root 356 1 0 10:56 ?00:00:02 syslogd -m 0 root 366 1 0 10:56 ?00:00:00 klogd Third root 1 0 0 10:03 ?00:00:09 init root 2 1 0 10:03 ?00:00:00 [keventd] root 3 1 0 10:03 ?00:00:00 [kswapd] root 4 1 0 10:03 ?00:00:00 [kreclaimd] root 5 1 0 10:03 ?00:00:00 [bdflush] root 6 1 0 10:03 ?00:00:02 [kupdated] root96 1 0 10:06 ?00:00:00 [kreiserfsd] root 356 1 0 10:06 ?00:00:02 syslogd -m 0 root 366 1 0 10:06 ?00:00:00 klogd Fourth root 1 0 0 09:53 ?00:00:09 init root 2 1 0 09:53 ?00:00:00 [keventd] root 3 1 0 09:53 ?00:00:00 [kswapd] root 4 1 0 09:53 ?00:00:00 [kreclaimd] root 5 1 0 09:53 ?00:00:00 [bdflush] root 6 1 0 09:53 ?00:00:02 [kupdated] root96 1 0 09:55 ?00:00:00 [kreiserfsd] root 356 1 0 09:55 ?00:00:02 syslogd -m 0 root 366 1 0 09:55 ?00:00:00 klogd Thoughts? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.19 Realaudio masq problem
I've been running masquerading unchanged from 2.2.13, currently 2.2.19 as: real IP + masq. 192.168.1.NNN DSL - gateway - switch - client 1 server - client 2 ... - client n There was some general slowness over the last few days (Bay Area, California - US East Coast) including realaudio being unable to locate servers and/or content. This one is working right now: RealPlayer v 7.0.3.338 abit:~ cat On24ram.asp rtsp://rm.on24.com/media/news/04192001/palumbo_ted6.rm --stop-- http://rm.on24.com/media/news/04192001/palumbo_ted6.rm Try '# strace /usr/bin/X11/realplay On24ram.asp log' and see where the connect fails if you aren't getting specific error messages. rgds, tim. Whit Blauvelt wrote: The Release Notes say Fix problems with realaudio masquerading. Looked promising, since with 2.2.17 one masqueraded system (but not another) was having occassional problems with realaudio at some (but not all) sites. Compiled 2.2.19 with 'make oldconfig,' no to new options. Otherwise running with the same firewall and masquerading settings (and yes I built and installed ip_masq_raudio.o). Masquerading is otherwise working, but now neither masqueraded system can connect with realaudio - the realplay routine to find a way to make a connection automatically fails for both. rgds, tim. -- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Can't read SCSI TAPE
mt : mt-st v. 0.4 Also mt-st v0.5b were fairly broken especially with positioning. rgds, tim. -- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.3ac13
Also, I initially built ac13 with: make mrproper make menuconfig and it doesn't ask whether I want to build the normal USHI USB driver either as a module or builtin to the kernel, only whether I want to build the alternative USHI USB dirver (the JE driver). Make xconfig asks whether you want to build both drivers. I'm not sure whether this was a bug in previous versions or not. It is an old problem, probably caused by ugly hack in drivers/usb/Config.in (using a variable before it is defined). The following patch should fix it in some way... diff -u drivers/usb/Config.in~ drivers/usb/Config.in --- drivers/usb/Config.in~ Sat Feb 10 23:16:30 2001 +++ drivers/usb/Config.in Sat Feb 17 00:06:34 2001 @@ -22,6 +22,8 @@ fi if [ $CONFIG_USB_UHCI != y ]; then dep_tristate ' UHCI Alternate Driver (JE) support' CONFIG_USB_UHCI_ALT $CONFIG_USB + else + define_bool CONFIG_USB_UHCI_ALT n fi dep_tristate ' OHCI (Compaq, iMacs, OPTi, SiS, ALi, ...) support' CONFIG_USB_OHCI $CONFIG_USB Andrzej -- === Andrzej M. Krzysztofowicz [EMAIL PROTECTED] phone (48)(58) 347 14 61 Faculty of Applied Phys. Math., Technical University of Gdansk - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
CML2 Transition experiences
1. If I install CML2 and go directly to make xconfig, it deduces it needs to set top level options because some of the low level options are set. For example SCSI enabled because some SCSI device is set or hot plug because PCMCIA is set...because some PCMCIA device is set. The _problem_ is...none of these options were set in the CML1 generated .config file... and it _extremely_ tedious to use xconfig to clear out all the cruft. A much better (but not yet right) way is to use make ttyconfig to quickly generate config.out from .config relatively fewer errors and ability to say no at a top level and cause all the lower level stuff to go away. make ttyconfig seems to parse the .config file in a different (and better) order. Suggestion: On the first pass of CML2 processing through .config, before first config.out created, trust the top level setting and ignore lower level settings if top setting off. 2. So after some playing around, I want to go back to CML1. But the .config generated by CML2 is not compatible. I don't know if it's supposed to be but there's lots of problems. Suggestion: Save your .config before you play with this stuff. Bottom line: looks promising but I still haven't gotten a good compile from it, yet. jeff - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: orinoco_cs IrDA
On Tue, Apr 24, 2001 at 03:56:37PM -0700, Jean Tourrilhes wrote: On Tue, Apr 24, 2001 at 03:15:08PM -0700, Jean Tourrilhes wrote: [...] Downloaded the patch again (patch-2.4.4-pre6), checked that it was complete, my patch is in. Oups ! Do I feel stupid... Let's finish this story. As indicated above, the first fragment of the patch I sent on month ago is in the kernel. The two other fragments didn't make it. They are attached... Ok, now to the second chapter. These are all the changes accumulated since the patch I sent one month ago (cf previous e-mail). Changes : o more Prism2/Symbol compatibility goodies o Tested D-Link cards and Lucent firmware 7.28 o Cleanup, bug fixes from David Gibson The whole is tested, as usual... 75% of the patch was on my web pages for the last month and people seem to have liked it. I've made 2 patches, one for 2.4.4-pre6 and one for 2.4.3-ac13. The difference between the two is minor (one line). Linus : please have a look at orinoco_v4b.diff (first attachement). Of course, this patch will apply and work only if you have applied the patch in my previous e-mail. Alan : orinoco_v4b-alan.diff is for you (second attachement). Have fun... Jean - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: orinoco_cs IrDA
On Tue, Apr 24, 2001 at 06:25:50PM -0700, Jean Tourrilhes wrote: Ok, now to the second chapter. These are all the changes accumulated since the patch I sent one month ago (cf previous e-mail). Changes : o more Prism2/Symbol compatibility goodies o Tested D-Link cards and Lucent firmware 7.28 o Cleanup, bug fixes from David Gibson The whole is tested, as usual... 75% of the patch was on my web pages for the last month and people seem to have liked it. I've made 2 patches, one for 2.4.4-pre6 and one for 2.4.3-ac13. The difference between the two is minor (one line). Linus : please have a look at orinoco_v4b.diff (first attachement). Of course, this patch will apply and work only if you have applied the patch in my previous e-mail. Alan : orinoco_v4b-alan.diff is for you (second attachement). Have fun... Jean File attached this time... Jean diff -u -p linux/drivers/net/pcmcia/wireless.25b/hermes.h linux/drivers/net/pcmcia/hermes.h --- linux/drivers/net/pcmcia/wireless.25b/hermes.h Tue Apr 24 15:57:48 2001 +++ linux/drivers/net/pcmcia/hermes.h Tue Apr 24 16:04:34 2001 @@ -35,18 +35,18 @@ /* * Limits and constants */ -#defineHERMES_ALLOC_LEN_MIN((uint16_t)4) -#defineHERMES_ALLOC_LEN_MAX((uint16_t)2400) +#defineHERMES_ALLOC_LEN_MIN(4) +#defineHERMES_ALLOC_LEN_MAX(2400) #defineHERMES_LTV_LEN_MAX (34) -#defineHERMES_BAP_DATALEN_MAX ((uint16_t)4096) -#defineHERMES_BAP_OFFSET_MAX ((uint16_t)4096) -#defineHERMES_PORTID_MAX ((uint16_t)7) -#defineHERMES_NUMPORTS_MAX ((uint16_t)(HERMES_PORTID_MAX+1)) -#defineHERMES_PDR_LEN_MAX ((uint16_t)260) /* in bytes, from EK */ -#defineHERMES_PDA_RECS_MAX ((uint16_t)200) /* a guess */ -#defineHERMES_PDA_LEN_MAX ((uint16_t)1024)/* in bytes, from EK */ -#defineHERMES_SCANRESULT_MAX ((uint16_t)35) -#defineHERMES_CHINFORESULT_MAX ((uint16_t)8) +#defineHERMES_BAP_DATALEN_MAX (4096) +#defineHERMES_BAP_OFFSET_MAX (4096) +#defineHERMES_PORTID_MAX (7) +#defineHERMES_NUMPORTS_MAX (HERMES_PORTID_MAX+1) +#defineHERMES_PDR_LEN_MAX (260) /* in bytes, from EK */ +#defineHERMES_PDA_RECS_MAX (200) /* a guess */ +#defineHERMES_PDA_LEN_MAX (1024) /* in bytes, from EK */ +#defineHERMES_SCANRESULT_MAX (35) +#defineHERMES_CHINFORESULT_MAX (8) #defineHERMES_FRAME_LEN_MAX(2304) #defineHERMES_MAX_MULTICAST(16) #defineHERMES_MAGIC(0x7d1f) @@ -86,122 +86,125 @@ /* * CMD register bitmasks */ -#defineHERMES_CMD_BUSY ((uint16_t)0x8000) -#defineHERMES_CMD_AINFO((uint16_t)0x7f00) -#defineHERMES_CMD_MACPORT ((uint16_t)0x0700) -#defineHERMES_CMD_RECL ((uint16_t)0x0100) -#defineHERMES_CMD_WRITE((uint16_t)0x0100) -#defineHERMES_CMD_PROGMODE ((uint16_t)0x0300) -#defineHERMES_CMD_CMDCODE ((uint16_t)0x003f) +#defineHERMES_CMD_BUSY (0x8000) +#defineHERMES_CMD_AINFO(0x7f00) +#defineHERMES_CMD_MACPORT (0x0700) +#defineHERMES_CMD_RECL (0x0100) +#defineHERMES_CMD_WRITE(0x0100) +#defineHERMES_CMD_PROGMODE (0x0300) +#defineHERMES_CMD_CMDCODE (0x003f) /* * STATUS register bitmasks */ -#defineHERMES_STATUS_RESULT((uint16_t)0x7f00) -#defineHERMES_STATUS_CMDCODE ((uint16_t)0x003f) +#defineHERMES_STATUS_RESULT(0x7f00) +#defineHERMES_STATUS_CMDCODE (0x003f) /* * OFFSET refister bitmasks */ -#defineHERMES_OFFSET_BUSY ((uint16_t)0x8000) -#defineHERMES_OFFSET_ERR ((uint16_t)0x4000) -#defineHERMES_OFFSET_DATAOFF ((uint16_t)0x0ffe) +#defineHERMES_OFFSET_BUSY (0x8000) +#defineHERMES_OFFSET_ERR (0x4000) +#defineHERMES_OFFSET_DATAOFF (0x0ffe) /*
Re: Scheduling bug for SCHED_FIFO and SCHED_RR
On Fri, 20 Apr 2001, Nigel Gamble wrote:
A SCHED_FIFO or SCHED_RR task with priority n+1 will not preempt a
running task with priority n. You need to give the higher priority task
a priority of at least n+2 for it to be chosen by the scheduler.
The problem is caused by reschedule_idle(), uniprocessor version:
if (preemption_goodness(tsk, p, this_cpu) 1)
tsk-need_resched = 1;
For real-time scheduling to work correctly, need_resched should be set
whenever preemption_goodness() is greater than 0, not 1.
This bug is also in the SMP version of reschedule_idle(). The
corresponding fix (against 2.4.3-ac14) is:
--- 2.4.3-ac14/kernel/sched.c Tue Apr 24 18:40:15 2001
+++ linux/kernel/sched.cTue Apr 24 18:41:32 2001
@@ -246,7 +246,7 @@
*/
oldest_idle = (cycles_t) -1;
target_tsk = NULL;
- max_prio = 1;
+ max_prio = 0;
for (i = 0; i smp_num_cpus; i++) {
cpu = cpu_logical_map(i);
Nigel Gamble[EMAIL PROTECTED]
Mountain View, CA, USA. http://www.nrg.org/
MontaVista Software [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Event tools, do they exist
george anzinger wrote: This is an attempt to look in the wheel locker. I need a simple event sub system for use in the kernel. I envision at least two types of events: the history event and the timing event. The timing event would keep track of start/stop times by class. If, for example, I wanted to know how much time the kernel spends doing the recalc in schedule() I would put and event start in front of it and an end at the other end. The sub system would note the first event time and the cumulative time between all starts and stops on the same event. When reported by /proc/ it would give the total event time, the elapsed time and the % of processor time for each of the possibly several classes. http://www.uow.edu.au/~andrewm/linux/#timepegs (The patch against 2.4.1-pre10 still applies!) The history event would record each events time, location, data1, data2. It would keep N of these (the last N) and report M (M=N) via /proc/. This list should also be kept in a format that a simple debugger can easily examine. Linux Trace Toolkit may be able to do this. - - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Request for comment -- a better attribution system
Roger Gammans [EMAIL PROTECTED]: On Tue, Apr 24, 2001 at 09:14:41AM -0400, Horst von Brand wrote: People who want to take over because it is s00 k3w1 to be a maintainer with no real interest in the code, just in the fact that it is orphaned... No. People who want to give something back to the linux community and want to find an option within their ability and time constariants. Indeed. Beware elitism. If lkml become a closed society, it will become a dead one shortly thereafter. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a The great object is, that every man be armed. [...] Every one who is able may have a gun. -- Patrick Henry, speech of June 14 1788 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
