PIO disk writes using 100% system time and performing poorly with VIA vt82c686b on kernels 2.2 & 2.4
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/
Re: [PATCH] Single user linux
> so what the hell is transmeta doing with mobile linux (midori). > is it going to teach multi-user thing to tablet owners? Thats you problem. Distinguish the OS from the user interface. > surely mortals expect midori to behave like their pc. lets say > on redhat, they have to login as root to access their files, > they don't even know what a root is! Even my digital tv box has multiple users. The fact you cannot figure out how to make your UI present that to the end user in a suitable manner is not the kernels problem. Get a real UI designer - 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 found (was Re: [PATCH] Single user linux)
On Tue, 24 Apr 2001, Daniel Stone wrote: > Aah. I see. Where was this? I never saw it. psst, it's a proto. > That may be so, so hack up your own OS. It's a MOBILE PHONE, it needs to be > absolutely *rock solid*. Look at the 5110, that's just about perfect. The > 7110, on the other hand ... mobile phone to you! already, people has put linux on pdas. > There are Linux advocates, but I'd say most of us are sane enough to use the > right-tool-for-the-job approach. And UNIX on a phone is pure overkill. problem is you guys are to unix-centric, try to be user-centric a little. it's not like it ruins everything. that patch basically do something like allowing access to port <1024 to everybody, someone just need to bring a notebook to get passwd from nis. multi-user security is useless at home as physical access is there. imel - 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: > Thanks for the comment. And why not just let it listen to 25 and then > being run as uid=nobody, gid=mail? Handling of .forward, for one thing. Or pipe aliases, or... None of this stuff is unsolvable (e.g. handling of .forward belongs to MDA, not MTA), but changing that will break existing setups. - 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: [kbuild-devel] Request for comment -- a better attribution system
Alan Cox wrote:
>
> > Well, would it be possible to create some module under LGPL, and then
> > have included it into the kernel? Maybe it needs to maintain the LGPL
> > version out of the kernel, and transform a copy to the GPL before
> > submitting?
>
> There is kernel code under a whole variety of licenses. When linked together
> the resulting work is GPL but many of the pieces used on their own or in
> conjunction with different code are not GPL.
Unfortunatelly there are exeptions:
the old ppp driver (only lickable to GPL kernel).
and drivers/usb/serial/keyspan_usa18x_fw.h:
1 /* keyspan_usa18x_fw.h
2
3Generated from Keyspan firmware image Wed Jul 5 09:18:29
2000 EST
4This firmware is for the Keyspan USA-18X Serial Adaptor
5
6"The firmware contained herein as keyspan_usa18x_fw.h is
7Copyright (C) 1999-2000 Keyspan, A division of InnoSys
Incorporated
8("Keyspan"), as an unpublished work. This notice does
not imply
9unrestricted or public access to this firmware which is a
trade secret of
10Keyspan, and which may not be reproduced, used, sold or
transferred to any
11third party without Keyspan's prior written consent.
All Rights Reserved.
12
13This firmware may not be modified and may only be used
with the Keyspan
14USA-18X Serial Adapter. Distribution and/or
Modification of the
15keyspan.c driver which includes this firmware, in whole
or in part,
16requires the inclusion of this statement."
17
18 */
with a surelly non-free/non-GPL license.
Maybe we should, as in tetex, check every license in every
file, to remove
the non-free files.
[But anyone (not-M$) will sue us?]
giacomo
-
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, 24 Apr 2001, Alan Cox wrote: > > so what the hell is transmeta doing with mobile linux (midori). > > is it going to teach multi-user thing to tablet owners? > > Thats you problem. Distinguish the OS from the user interface. sigh. is that mean the little thing had to do capable() check each time it access something? > Even my digital tv box has multiple users. The fact you cannot figure out how > to make your UI present that to the end user in a suitable manner is not > the kernels problem. Get a real UI designer if it's useful, it's okay. if not, what is it doing there? imel - 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 found (was Re: [PATCH] Single user linux)
On Tue, Apr 24, 2001 at 09:04:02PM +0700, [EMAIL PROTECTED] wrote: > > What's with all these blank lines? Everywhere! > On Tue, 24 Apr 2001, Daniel Stone wrote: > > Aah. I see. Where was this? I never saw it. > > psst, it's a proto. Right-o. In the news, you say. Hrm. > > That may be so, so hack up your own OS. It's a MOBILE PHONE, it needs to be > > absolutely *rock solid*. Look at the 5110, that's just about perfect. The > > 7110, on the other hand ... > > mobile phone to you! already, people has put linux on pdas. True, but I don't see what's so l33t about having bash on an Agenda, except for, say, the novelty value of opening it up and writing "date" to get the date in UNIX format, when someone asks you the time. > > There are Linux advocates, but I'd say most of us are sane enough to use the > > right-tool-for-the-job approach. And UNIX on a phone is pure overkill. > > problem is you guys are to unix-centric, try to be user-centric a little. We're too UNIX-centric, yet you're the one trying to put UNIX on a phone? Come on ... Al Viro made some excellent points there. If you want to run single-user, hack /sbin/login. Hack /sbin/init. But it's not the kernel's job, what you do. > it's not like it ruins everything. that patch basically do something > like allowing access to port <1024 to everybody, someone just need > to bring a notebook to get passwd from nis. > multi-user security is useless at home as physical access is there. Well, not really, because what if I run single-user, but I also need to get in from home? So, everyone who connects, gets in? What if I run BIND, and forget to update before an exploit? Whoops, there goes my entire system, exploited like that. Single-user is absolutely stupid, IMNSHO. Unless, of course, if you're using something that will *never* be connected, like a watch. In a rabbithole. A rabbithole which is B2 secure. -- 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/
sym53c875 error
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. 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 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. sym53c875-0-<3,*>: extraneous data discarded. sym53c875-0-<3,*>: COMMAND FAILED (89 0) @c12a3800. 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. Anybody got any ideas? Cheers, Eamonn - 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, Mohammad A. Haque wrote: > > Correct. <1024 requires root to bind to the port. > ... And nothing says that it should be done by daemon itself. Or that you shouldnt let inetd do it for you And that you shouldn't drop the capabilities except that bind It is possible to implement the entire mail system without anything running as root but xinetd. - 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/
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/
Re: [kbuild-devel] Request for comment -- a better attribution system
> Well, would it be possible to create some module under LGPL, and then > have included it into the kernel? Maybe it needs to maintain the LGPL > version out of the kernel, and transform a copy to the GPL before > submitting? There is kernel code under a whole variety of licenses. When linked together the resulting work is GPL but many of the pieces used on their own or in conjunction with different code are not GPL. 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: [OFFTOPIC] Re: [PATCH] Single user linux
On Tue, 24 Apr 2001, Alan Cox wrote: > > On Tue, 24 Apr 2001, Mohammad A. Haque wrote: > > > Correct. <1024 requires root to bind to the port. > > ... And nothing says that it should be done by daemon itself. > > Or that you shouldnt let inetd do it for you > And that you shouldn't drop the capabilities except that bind > > It is possible to implement the entire mail system without anything running > as root but xinetd. You want an MDA with elevated privileges, though... - 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, 24 Apr 2001 [EMAIL PROTECTED] wrote: >> Even my digital tv box has multiple users. The fact you cannot figure out how >> to make your UI present that to the end user in a suitable manner is not >> the kernels problem. Get a real UI designer > >if it's useful, it's okay. if not, what is it doing there? Serving it's purpose? ;o) Here is a useful command for you to add to your toolkit: chmod -R 777 / GPL of course. ;o) -- Mike A. Harris - Linux advocate - Free Software advocate This message is copyright 2001, all rights reserved. Views expressed are my own, not necessarily shared by my employer. -- - 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 03:18:11PM +0100, Alan Cox wrote: > > On Tue, 24 Apr 2001, Mohammad A. Haque wrote: > > > Correct. <1024 requires root to bind to the port. > > ... And nothing says that it should be done by daemon itself. > > Or that you shouldnt let inetd do it for you > And that you shouldn't drop the capabilities except that bind > > It is possible to implement the entire mail system without anything running > as root but xinetd. Or even without xinetd. Just use local port forwarding eg 2525 -> 25, and use port 2525 as SMTP port in your MTA. I've succeed to setup such a configuration. -- --[ Gábor Lénárt ]---[ Vivendi Telecom Hungary ]-[ [EMAIL PROTECTED] ]-- U have 8 bit comp or chip of them and it's unused or to be sold? Call me! ---[ +36 30 2270823 ]--> LGB <-[ Linux/UNIX/8bit 4ever ]- - 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
> > Even my digital tv box has multiple users. The fact you cannot figure out how > > to make your UI present that to the end user in a suitable manner is not > > the kernels problem. Get a real UI designer > > if it's useful, it's okay. if not, what is it doing there? For one it allowing you to build enough of a security model to prevent your phone user from deleting critical system files by accident. Something incredibly basic that I cannot believe anyone could overlook Take a look why my Digital TV has multiple users - It can charge pay per view films to multiple accounts (think about multiple SIM cards) - It remembers personal barriers (so I can require passwords to watch adult rated films for example) (For a phone think about call barring - set the phone user and loan it for calls home only to children) - It remembers preferences. (Currently only useful for junk sky interactive stuff like email) (think about multiple email accounts) And it has a perfectly sane UI for all of this. In fact most people have probably never realised their set top box even has the concept of users in it because they've never set more than one up. Another reason your device needs good security models is that if I can't store digital credit card data safely on it, its a dead product line soon. If it can't do internet its an ex product. How do you plan to do internet without a security model in your OS. How are you going to protect credit card data from web browser bugs. How are you going to protect that data from sms parsing bugs ? How do you plan to deal with synchronizing data between multiple systems when you have no user model ? The questions you should be asking are not 'Why do I need a security model' they are 'Is the model provided good enough'. 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/
Network driver: problem with insane (ported in 2.4.3)
Hi all,
Has anybody ported insane or snull from Rubini to kernel 2.4.3?
I'm porting Rubini's example: "insane".
/* --
* definition of the "private" data structure used by this interface
*/
struct insane_private {
struct net_device_stats priv_stats;
struct net_device *priv_device; /* interface used to xmit data */
int priv_mode; /* how to drop packets */
int priv_arg1; /* arguments to the dropping mode */
int priv_arg2;
};
int insane_open(struct net_device *dev)
{
/* mark the device as operational */
/*dev->start = 1;
dev->tbusy = 0;*/
netif_start_queue(dev);
MOD_INC_USE_COUNT;
return 0;
}
int insane_close(struct net_device *dev)
{
/*dev->start = 0;
dev->tbusy = 1;*/
netif_stop_queue(dev);
MOD_DEC_USE_COUNT;
return 0;
}
int insane_xmit(struct sk_buff *skb, struct net_device *dev)
{
... /* state if the packet must be transmit or nor, and if it must */
skb->dev = priv->priv_device;
skb->priority = 1;
printk("enqueue len=%d\n", skb->len);
{
int ret = dev_queue_xmit (skb);
printk("enqueue ret=%d\n", ret);
}
return 0;
}
Everything looks OK, dev_queue_xmit returns 0, but nothing comes back when I
ping through insane.
Has anybody ported insane or snull from Rubini to kernel 2.4.3?
Thanks a lot
Stephane
--
Stéphane LIST -- <[EMAIL PROTECTED]>
Alcôve, liberating software --
Re: [kbuild-devel] Request for comment -- a better attribution system
> 14USA-18X Serial Adapter. Distribution and/or > Modification of the > 15keyspan.c driver which includes this firmware, in whole > or in part, > 16requires the inclusion of this statement." > 17 > 18 */ > with a surelly non-free/non-GPL license. That one is being sorted out currently. The firmware itself is fine (its mere aggregation) but there are some problems with the firmware distribution aspects of it. Going through checking licensing is generally a good idea. Its something that becomes more important over time and people become more fussy about with unclear cases (trn, tin, getty-ps for example are probably non free apps but people assume they are 'free software'). Older versions of glibc (2.1 etc) have some odd licensing bits in one area - 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, Alan Cox wrote: > > > It is possible to implement the entire mail system without anything running > > > as root but xinetd. > > > > You want an MDA with elevated privileges, though... ^ > What role requires priviledge once the port is open ? .forward handling may, depending on how much do you want to put into it. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OFFTOPIC] Re: [PATCH] Single user linux
> > It is possible to implement the entire mail system without anything running > > as root but xinetd. > > You want an MDA with elevated privileges, though... What role requires priviledge once the port is open ? DNS lookup does not Spooling to disk does not Accepting a connection from a client does not Doing peercred auth with a client does not Copying spool articles matching the peercred to the client does not 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/
where can I find the IP address ?
I'm dealing with a driver wich need the IP address for specifics using. I've read in the linux device driver (o'reilly) that I can use the field pa_addr in the struct device. but it doesn't exist on my computer. so I don't understand why ? Is anybody could tell me where finding the IP address in the kernel ? thanks a lot. nb :my kernel version is 2.2.14, as it is my first driver I am starting on the current kernel I've got but I'll also need informations for kernel 2.4.X sebastien person - 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/
capabilities carried over execve()
I am attempting to write an init replacement that is capability-smart. Though I'm pleased that prctl() lets me keep capabilities across a setreuid(), maintaining caps over execve() seems impossible to do right. I currently see a few options: - use the CLOEXEC-pipe hack that execcap uses (parent notices when pipe closes then rushes to set caps on child before child notices they're gone). This looks like a race to me. - tweak linux/fs/exec.c (prepare_binprm) to pretend that all files have cap_inheritable and cap_effective fully set. This seems a more elegant solution, but requires a kernel patch. - exec the child in a stopped state, mess with caps, then send it SIGCONT. AFAIK, there is no way to do execve_and_stop. Is there a better solution available, or one in the works? I think capabilites may be a key to achieving Pretty Good (tm) security - but then again, so is running bind as non-root, and nobody even bothers to do that... -Eric - 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, [iso-8859-2] Gábor Lénárt wrote: > > Or even without xinetd. Just use local port forwarding eg 2525 -> 25, and This is more like 25 -> 2525 :-) > 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 ... - 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: high-res-timers start code.
Gabriel Paubert wrote: > > On Mon, 23 Apr 2001, george anzinger wrote: > > > "Robert H. de Vries" wrote: > > > > > > On Monday 23 April 2001 19:45, you wrote: > > > > > > > By the way, is the user land stuff the same for all "arch"s? > > > > > > Not if you plan to handle the CPU cycle counter in user space. That is at > > > least what I would propose. > > > > Just got interesting, lets let the world look in. > > > > What did you have in mind here? I suspect that on some archs the cycle > > counter is not available to user code. I know that on parisc it is > > optionally available (kernel can set a bit to make it available), but by > > it self it is only good for intervals. You need to peg some value to a > > CLOCK to use it to get timeofday, for instance. > > On Intel there is a also bit to disable unprivileged RDTSC, IIRC. On PPC > the timebase is always available (but the old 601 needs spacial casing: it > uses different registers and does not count in binary :-(). > > > On the other hand, if there is an area of memory that both users and > > system can read but only system can write, one might put the soft clock > > there. This would allow gettimeofday (with the cycle counter) to work > > without a system call. To the best of my knowledge the system does not > > have such an area as yet. > > > > comments? > > Well, there may be work in this area, since x86-64 will not enter kernel > mode for gettimeofday() if I understand correctly what Andrea said. Linus > hinted once at exporting (kernel) code to user space. > > Some data also will also need to be accessible but as long as you don't > guarantee compatibility on data layout, only AFAIU on interface for these > calls (it was not clear to me if it would be a fixed address forever or > dynamic linking with kernel exported symbols), it's not a problem. HPUX passes some kernel addresses to programs on the initial start up, i.e. the primary entry point where exec starts the task. In this case the addresses are in registers. I think HPUX also passes addresses back to the kernel at this time, but those are done with a system call. In any case, such a change requires a user land relink, something that may want the kernel to move from 2.x.x to 3.x.x (depending on version conventions :). I think the real problem has more to do with the "minor" variations on various archs, for example the 601 ppc above and the i386 TSC is only available in the "newer" machines. This would require user land configuration based on fine points of the arch, stuff "only the kernel knows for sure". So what do we do in the meantime? Comments? George > > Of course it will SIGSEGV instead of returning -EFAULT but this is a good > thing IMHO, nobody checks for -EFAULT from gettimeofday(). I think > that system calls should rather force SIGSEGV than return -EFAULT anyway, > to make syscalls indistinguishable from pure library calls. > > Regards, > Gabriel. - 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
On Tue, Apr 24, 2001 at 09:14:41AM -0400, Horst von Brand wrote: > Roger Gammans <[EMAIL PROTECTED]> said: > > 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. TTFN -- Roger Think of the mess on the carpet. Sensible people do all their demon-summoning in the garage, which you can just hose down afterwards. -- [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: [OFFTOPIC] Re: [PATCH] Single user linux
On Tue, 24 Apr 2001, Alan Cox wrote: > > On Tue, 24 Apr 2001, Mohammad A. Haque wrote: > > > Correct. <1024 requires root to bind to the port. > > ... And nothing says that it should be done by daemon itself. > > Or that you shouldnt let inetd do it for you > And that you shouldn't drop the capabilities except that bind > > It is possible to implement the entire mail system without anything running > as root but xinetd. > Qmail does exactly this afik. I've always found the root < 1024 to be quite limmited and find myself wishing I could assign permissions based on ip/port. 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/
Re: [OFFTOPIC] Re: [PATCH] Single user linux
On Tue, Apr 24, 2001 at 03:37:34PM +0100, Alan Cox wrote: > What role requires priviledge once the port is open ? > > DNS lookup does not > Spooling to disk does not > Accepting a connection from a client does not > Doing peercred auth with a client does not > Copying spool articles matching the peercred to the client does not Running procmail as the user who is to receive the email for local mail delivery as running it with gid mail (for eg) would allow one user to modify another's mail. (just a thought - the above's valid with sendmail at least) -- CaT ([EMAIL PROTECTED])*** Jenna has joined the channel. speaking of mental giants.. me, a giant, bullshit And i'm not mental - An IRC session, 20/12/2000 - 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
> > Copying spool articles matching the peercred to the client does not > > Running procmail as the user who is to receive the email for local mail > delivery as running it with gid mail (for eg) would allow one user to > modify another's mail. What is this gid mail crap ? You don't need priviledge. You get the mail by asking the daemon for it. procmail needs no priviledge either if it is done right. You just need to think about the security models in the right way. Linux gives you the ability to do authenticated uid/gid checking over a socket connection. That is an incredibly powerful model for real compartmentalisation. 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: [OFFTOPIC] Re: [PATCH] Single user linux
> I've always found the root < 1024 to be quite limmited and find myself > wishing I could assign permissions based on ip/port. Its been done. Search for 'sockfs' I believe it was called. - 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 found (was Re: [PATCH] Single user linux)
Le 25 Apr 2001 00:06:57 +1000, Daniel Stone a écrit : > > problem is you guys are to unix-centric, try to be user-centric a little. > > We're too UNIX-centric, yet you're the one trying to put UNIX on a phone? > Come on ... Hey ! We already put uClinux on a phone ! Full-fledge linux is not far, beware ! Cheers, Xav - 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:49:57PM +0200, Pjotr Kourzanoff wrote: > On Tue, 24 Apr 2001, [iso-8859-2] Gábor Lénárt wrote: > > > > Or even without xinetd. Just use local port forwarding eg 2525 -> 25, and > > This is more like 25 -> 2525 :-) OK, that was a hard night for me, I need some sleep :) > > 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 Yes, you're right. But this is a mail server without any user on it (even users are authenticated from LDAP). -- --[ Gábor Lénárt ]---[ Vivendi Telecom Hungary ]-[ [EMAIL PROTECTED] ]-- U have 8 bit comp or chip of them and it's unused or to be sold? Call me! ---[ +36 30 2270823 ]--> LGB <-[ Linux/UNIX/8bit 4ever ]- - 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: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 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. -- CaT ([EMAIL PROTECTED])*** Jenna has joined the channel. speaking of mental giants.. me, a giant, bullshit And i'm not mental - An IRC session, 20/12/2000 - 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: capabilities carried over execve()
I personnaly use this simple patch which allows me to keep caps over execve(). It allows me to give a few more rights to some trusted users, such as kill, insmod... without risking unlink, chown or so. I couldn't find any other way to achieve this. If needed, I can send you the complete prog which sets the requested capabilities upon login, eventually asking for a password and limited in time of day. Regards, Willy --- linux-2.2.18-wt11/fs/exec.c Fri Feb 16 23:11:52 2001 +++ linux-2.2.18-wt11+caps/fs/exec.cThu Feb 22 20:45:33 2001 @@ -702,7 +702,10 @@ cap_clear(bprm->cap_inheritable); cap_clear(bprm->cap_permitted); cap_clear(bprm->cap_effective); - +/*** FIXME: just a test : keep permitted and effective **/ +bprm->cap_permitted = cap_intersect(current->cap_inheritable,current->cap_permitted); +bprm->cap_effective = cap_intersect(current->cap_inheritable,current->cap_effective); +/*** /FIXME / /* To support inheritance of root-permissions and suid-root * executables under compatibility mode, we raise all three * capability sets for the file. ___ Do You Yahoo!? -- Pour faire vos courses sur le Net, Yahoo! Shopping : http://fr.shopping.yahoo.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: [OFFTOPIC] Re: [PATCH] Single user linux
On Tue, Apr 24, 2001 at 03:59:28PM +0100, Alan Cox wrote: > What is this gid mail crap ? You don't need priviledge. You get the mail by > asking the daemon for it. procmail needs no priviledge either if it is done > right. > > You just need to think about the security models in the right way. Linux gives > you the ability to do authenticated uid/gid checking over a socket connection. > That is an incredibly powerful model for real compartmentalisation. Ok. My experience isn't all that great so I may well be missing something here. But what? 1. email -> sendmail 2. sendmail figures out what it has to do with it. turns out it's deliver it locally for user blah 3. sendmail starts procmail so that it delivers the email. 4. procmail goes through the recepie list for user blah and eventually delivers the email (one way or another) 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. Now as I said, I'm not a UNIX God[tm] and so I may well be missing something vital. If so, what is it? This sounds like something that would be way useful to learn. :) -- CaT ([EMAIL PROTECTED])*** Jenna has joined the channel. speaking of mental giants.. me, a giant, bullshit And i'm not mental - An IRC session, 20/12/2000 - 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/
ncurses 2.4.3
Hi, I'm running 2.2.16-22 (Redhat Guiness) on a PC and wanna upgrade to 2.4.3. Unfourtunately I get Unable to open Ncurses libraries Error 1 if I make make menuconfig. I read around the web and found that I've to install the devel pack of ncurses too. No results, even if I do a make clean all in /usr/src/linux/scripts/lxdialog. If I make a make xconfig I get an tkpares.o not found error 127. Can anyone point me to a page or give me some hints how to fix this? Thanks Tom please cc. me on all replys, cause' I'm not on the list at the moment. - 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
Alan Cox wrote: > > so what the hell is transmeta doing with mobile linux (midori). > > is it going to teach multi-user thing to tablet owners? > > Thats you problem. Distinguish the OS from the user interface. > > > surely mortals expect midori to behave like their pc. lets say > > on redhat, they have to login as root to access their files, > > they don't even know what a root is! > > Even my digital tv box has multiple users. The fact you cannot figure out how > to make your UI present that to the end user in a suitable manner is not > the kernels problem. Get a real UI designer. Quote of the day: Never engage in a battle of wits with an idiot; they will bring you down to their level, then beat you with experience. Cheers! Jeremy - 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
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/; then the file /var/mail/ 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/ 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: shm_open doesn't work (fix maybe).
On Tue, Apr 24, 2001 at 11:46:20AM -0500, Tom Brusehaver (N-Sysdyne Corporation) wrote: > > 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? Update your glibc, 2.2.3pre* matches 2.4.x kernel: 2001-03-03 Ulrich Drepper <[EMAIL PROTECTED]> * sysdeps/unix/sysv/linux/linux_fsinfo.h (SHMFS_SUPER_MAGIC): Update for real 2.4 kernels. Jakub - 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: [PATCH] Single user linux
"Thinking out of the box," you don't need to modify the kernel or the userland utilities to make Linux automatically launch a dedicated terminal for embedded applications. All you need to do is look at the file /etc/inittab and read the man pages for this file. For console access, you merely make a shell the first program launched, and you specify RESPAWN as the restart type so that if the shell crashes you get your shell back. The invocation may need to be put in a wrapper so that standard input, standard output, and standard error are set properly, as are the environment variables. The security model of Unix need not be sacrificed. The wrapper can set the user ID to a default non-zero user so that there is more security than the all-root solution that others have suggested. For administrative duties, the user would use su (and appropriate password) to acquire the appropriate permissions. Back when Unix was first given out by Bell Labs in the '70s, several Bell people wrote papers describing exactly how to do this sort of thing in Version 7. In the thirty years since the technique was described, the underlying structure -- init/getty/login -- hasn't changed. I suspect that many people here haven't explored the power of inittab, especially given the discussion about dying daemons a few months back and how the problem was solved in the beginning and the solution ignored today. (For those of you interested, you might want to check the archives for the tangent in the OOMkiller discussion.) (Sorry, I've not found those papers on-line, and my copies were lost about seven moves ago.) Satch At 06:44 PM 4/24/01 +0700, [EMAIL PROTECTED] wrote: >hi, > >a friend of my asked me on how to make linux easier to use >for personal/casual win user. > >i found out that one of the big problem with linux and most >other operating system is the multi-user thing. > >i think, no personal computer user should know about what's >an operating system idea of a user. they just want to use >the computer, that's it. > >by a personal computer i mean home pc, notebook, tablet, >pda, and communicator. only one user will use those devices, >or maybe his/her friend/family. do you think that user want >to know about user account? > >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. i also have removed the user_struct from >my kernel, but i don't think you'd like #ifdef's. >may be it'll be good for midori too. > > > imel > > > >--- sched.h Mon Apr 2 18:57:06 2001 >+++ sched.h~Tue Apr 24 17:32:33 2001 >@@ -655,6 +655,12 @@ >unsigned long, const char *, void *); > extern void free_irq(unsigned int, void *); > >+#ifdef CONFIG_NOUSER >+#define capable(x) 1 >+#define suser()1 >+#define fsuser() 1 >+#else >+ > /* > * This has now become a routine instead of a macro, it sets a flag if > * it returns true (to do BSD-style accounting where the process is flagged >@@ -706,6 +712,8 @@ > } > return 0; > } >+ >+#endif /* CONFIG_NOUSER */ > > /* > * Routines for handling mm_structs > >diff -ur linux/Documentation/Configure.help >nouser/Documentation/Configure.help >--- linux/Documentation/Configure.help Mon Apr 2 18:53:29 2001 >+++ nouser/Documentation/Configure.help Tue Apr 24 18:08:49 2001 >@@ -13626,6 +13626,14 @@ >a work-around for a number of buggy BIOSes. Switch this option on if >your computer crashes instead of powering off properly. > >+Disable Multi-user (DANGEROUS) >+CONFIG_NOUSER >+ Disable kernel multi-user support. Normally, we treat each user >+ differently, depending on his/her permissions. If you _really_ >+ think that you're not going to use your computer in a hostile >+ environment and would like to cut a few bytes, say Y. >+ Most people should say N. >+ > Watchdog Timer Support > CONFIG_WATCHDOG >If you say Y here (and to one of the following options) and create a >diff -ur linux/arch/i386/config.in nouser/arch/i386/config.in >--- linux/arch/i386/config.in Mon Feb 5 18:50:27 2001 >+++ nouser/arch/i386/config.in Tue Apr 24 17:53:42 2001 >@@ -244,6 +244,8 @@ > bool 'Use real mode APM BIOS call to power off' > CONFIG_APM_REAL_MODE_POWER_OFF > fi > >+bool 'Disable Multi-user (DANGEROUS)' CONFIG_NOUSER >+ > endmenu > > source drivers/mtd/Config.in > >- >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: [OFFTOPIC] Re: [PATCH] Single user linux
> 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...
No. Think instead of blindly following existing implementation
socket(AF_UNIX, SOCK_STREAM, 0);
connect("/var/run/mailservice");
write("GIMMEMYMAIL\n");
read("200 CATCH..");
read(all my mail)
The daemon needs no priviledge. The client needs no priviledge. The
PEERCRED authentication on AF_UNIX sockets does the work. I can even pass you
back the file handle of the mailbox if I was using an old style non database
indexed mail spool.
> It's much more efficent to process each mail as it arrives.
You are doing a lot more exec() calls that way. If you get enough mail
to make spool space an issue you want a daemon.
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/
Kernel Oops when using the Netfilter QUEUE target
Hi there!
I have encountered a problem (perhaps a bug)! The attached code makes my kernel oops
in some cases when injecting new packets through Netfilter's QUEUE target. The problem
only appears when the original packet is a TCP packet; i have tried with ICMP and UDP
packets
also but this does not trigger any oops. I have tried to code on several computers and
they
all oops. The following description regards the case when submitting new packets
instead
of TCP packets.
It seems that new packets can not have a length greater than 92 bytes under 2.4.2-ac21
and 76 under 2.4.3; these sizes may vary but the oops can be triggered by choosing
a larger packet size.
Netfilter is configured the following way:
[root@lwb7 ipsecd]# modprobe iptable_filter
[root@lwb7 ipsecd]# modprobe ip_queue
[root@lwb7 ipsecd]# iptables -t mangle -A OUTPUT -d lwb5 -j LOG
[root@lwb7 ipsecd]# iptables -t mangle -A OUTPUT -d lwb5 -j QUEUE
[root@lwb7 ipsecd]# lsmod
Module Size Used by
ipt_LOG 4063 1 (autoclean)
iptable_mangle 2542 0 (autoclean) (unused)
ip_queue5946 0 (unused)
iptable_filter 2533 0 (unused)
ip_tables 14936 3 [ipt_LOG iptable_mangle iptable_filter]
NVdriver 688003 12 (autoclean)
8139too16845 1 (autoclean)
[root@lwb7 ipsecd]# iptables -t mangle -L
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
LOGall -- anywhere lwb5.it.dtu.dk LOG level warning
QUEUE all -- anywhere lwb5.it.dtu.dk
I have added some printk's in net/code/netfilter.c in nf_reinject() and i seems that
the kernel oops' in info->okfn(skb) (i added printk before and after):
IN= OUT=eth0 SRC=130.225.76.37 DST=130.225.76.35 LEN=60 TOS=0x00 PREC=0x00 TTL=64
ID=173 PROTO=TCP SPT=1025 DPT=23 WINDOW=5840 RES=0x00 SYN URGP=0
nf_hook: Verdict = QUEUE.
In nf_reinject() before info->okfn(skb) line 521
Unable to handle kernel NULL pointer dereference at virtual address 02b4
printing eip:
c01e7456
*pde =
Entering kdb (current=0xc68f6000, pid 884) Oops: Oops
due to oops @ 0xc01e7456
eax = 0x05dc ebx = 0xc7acf224 ecx = 0x000e edx = 0xc72f8440
esi = 0xc7cee740 edi = 0x esp = 0xc68f7c90 eip = 0xc01e7456
ebp = 0xc68f7cb0 xss = 0x0018 xcs = 0x0010 eflags = 0x00010287
xds = 0x0018 xes = 0x0018 origeax = 0x ®s = 0xc68f7c5c
kdb>
I will be glad to submit som more (debug) information?!
I really hope someone can help me :)
Best regards,
Martin Clausen
--
There's no place like ~
/* Compile: gcc -o nfcrash nfcrash.c -lipq
*/
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
/* For CRASH_ME <= 32 everything seems to work (2.4.2-ac21).
* For CRASH_ME > 32 the kernel oops'es in case of TCP traffic (2.4.2-ac21)?!
*
* For CRASH_ME <= 16 everything seems to work (2.4.3).
* For CRASH_ME > 16 the kernel oops'es in case of TCP traffic (2.4.3)?!
*
*/
const int CRASH_ME = 17;
const int ESP_OFF = 0;
unsigned short in_cksum(unsigned short *addr, int len)
{
int nleft = len;
int sum = 0;
unsigned short *w = addr;
unsigned short answer = 0;
while (nleft > 1) {
sum += *w++;
nleft -= 2;
}
if (nleft == 1) {
*(unsigned char *)(&answer) = *(unsigned char *) w;
sum += answer;
}
sum = (sum >> 16) + (sum & 0x);
sum += (sum >> 16);
answer = ~sum;
return answer;
}
int main(int argc, char **argv)
{
struct ipq_handle *qh;
struct ipq_packet_msg *qpkt;
struct iphdr *iph;
unsigned char buff[8192];
unsigned char *esppkt;
int esppkt_len;
int type;
int len;
/* Init first (flags are not implemented; yet) */
if ( (qh = ipq_create_handle(0)) == NULL) {
/* Run away... */
ipq_perror("create_handle()");
exit(1);
}
/* We would like to receive not only metadata... */
if (ipq_set_mode(qh, IPQ_COPY_PACKET, sizeof(buff)) < 0) {
ipq_perror("set_mode()");
goto cleanup;
}
/* Now real fun begins... Just stay in loop, read packets,
* accept them if they are IP. */
while (1) {
len = ipq_read(qh, buff, sizeof buff, 0);
if (len == 0) {
fprintf(stderr, "read():
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!
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!
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/
Re: BUG: Global FPU corruption in 2.2
Linus Torvalds writes: > 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. 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? What would be involved in backporting the split ptrace flags to 2.2? Are there other solutions? 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: Device Registry (DevReg) Patch 0.2.0
On Tuesday 24 April 2001 18:39, Martin Dalecki wrote: > Are there alternatives to get complex and extendable information out to > user space? > Yes filesystem structures. How exactly can this work? A single value per file is not very helpful if you have a thousand values. You could cluster them (for example one level in the XML hierarchy == one file), but this will soon get very complicated. Its much more work to implement in the kernel, its painful in user-space and you cant just use a text editor to look at it (because you always have to look at 10 files per device). IMHO only a single XML file per physical device is an option, but I do not know how to name the files... > Or just simple parsing in the user space plain binary data. This would be a compatibility nightmare and hard to maintain. Once you decided for a binary format you cannot change or extend it without breaking user-space apps. This may save a few lines code, but not many. All you need to add a line to XML output is a sprintf and a call to devreg_write_line(). One of the ideas of devreg is that while it has a common format for generic information, like the name and topology of physical devices, every driver can add additional data (this is why XML namespaces are used). Currently only the USB and PCI subsystems add data to devreg, but in future versions the device driver itself or other subsystems should do this, too. 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/
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 > 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 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/
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? It affects asm blocks and offsets on some ports. Its not too bad tho - 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: compile error 2.4.4pre6: inconsistent operand constraints in an
With the __builtin_expect patch [EMAIL PROTECTED] posted, both 2.4.4-pre6 and 2.4.3-ac12 compile with egcs-2.91.66. Also, 2.4.3-ac13 builds without any further patches needed. Wayne Alan Cox <[EMAIL PROTECTED]> on 04/23/2001 05:58:47 PM To: [EMAIL PROTECTED] (axel) cc: [EMAIL PROTECTED] (bcc: Wayne Brown/Corporate/Altec) Subject: Re: compile error 2.4.4pre6: inconsistent operand constraints in an > after having had trouble with compilation due to old gcc version, i have > updated to gcc 3.0 and received the following error: 2.4.4pre6 only builds with gcc 2.96. If you apply the __builtin_expect fixes it builds and runs fine with 2.95. Not tried egcs. The gcc 3.0 asm constraints one I've yet to see a fix for. - 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/
Spurious interrupts for UP w/ IO-APIC on ServerWorks
Hi, 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: [... everything seems ok until ...] Uniform Multi-Platform E-IDE driver Revision: 6.31 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx ServerWorks OSB4: IDE controller on PCI bus 00 dev 79 ServerWorks OSB4: chipset revision 0 ServerWorks OSB4: not 100% native mode: will probe irqs later ide0: BM-DMA at 0x0840-0x0847, BIOS settings: hda:DMA, hdb:DMA ide1: BM-DMA at 0x0848-0x084f, BIOS settings: hdc:DMA, hdd:DMA spurious APIC interrupt on CPU#0, should never happen. spurious APIC interrupt on CPU#0, should never happen. hda: CD-ROM 52X/AKH, ATAPI CD/DVD-ROM drive spurious APIC interrupt on CPU#0, should never happen. spurious APIC interrupt on CPU#0, should never happen. ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 spurious APIC interrupt on CPU#0, should never happen. spurious APIC interrupt on CPU#0, should never happen. hda: lost interrupt spurious APIC interrupt on CPU#0, should never happen. hda: lost interrupt hda: ATAPI 52X CD-ROM drive, 192kB Cache, UDMA(33) Uniform CD-ROM driver Revision: 3.12 Floppy drive(s): fd0 is 1.44M spurious APIC interrupt on CPU#0, should never happen. spurious APIC interrupt on CPU#0, should never happen. floppy0: no floppy controllers found Serial driver version 5.05 (2000-12-13) with MANY_PORTS SHARE_IRQ SERIAL_PCI ISAPNP enabled ttyS00 at 0x03f8 (irq = 4) is a 16550A ttyS01 at 0x02f8 (irq = 3) is a 16550A SCSI subsystem driver Revision: 1.00 (scsi0) found at PCI 1/4/0 (scsi0) Wide Channel A, SCSI ID=7, 32/255 SCBs (scsi0) Downloading sequencer code... 392 instructions downloaded (scsi1) found at PCI 1/4/1 (scsi1) Wide Channel B, SCSI ID=7, 32/255 SCBs (scsi1) Downloading sequencer code... 392 instructions downloaded scsi0 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 5.2.1/5.2.0 scsi1 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 5.2.1/5.2.0 scsi : aborting command due to timeout : pid 0, scsi0, channel 0, id 0, lun 0 Inquiry 00 00 00 ff 00 spurious APIC interrupt on CPU#0, should never happen. SCSI host 0 abort (pid 0) timed out - resetting SCSI bus is being reset for host 0 channel 0. spurious APIC interrupt on CPU#0, should never happen. SCSI host 0 channel 0 reset (pid 0) timed out - trying harder SCSI bus is being reset for host 0 channel 0. [... repeat above 6 lines until I reset hw ...] 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 Here's the pertinent (I think) part of 2.4.3 .config: CONFIG_MPENTIUMIII=y CONFIG_X86_GOOD_APIC=y # CONFIG_SMP is not set CONFIG_X86_UP_IOAPIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y Details available on request. 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/
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] [] [flush_tlb_all+17/96] [zap_page_range+453/624] [] [] Apr 24 14:41:27 patagarro kernel:[] [] [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 bit compare & exchange supported. Inte
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/
