Re: Linux Kernel 2.2.19 Available Memory Bug
"John L. Males" <[EMAIL PROTECTED]> writes: > The bug I am reporting is that when one sets the amount of memory, > i.e. 128M, 256M; at the time of booting the 2.2.19 kernel the "Total > Memory" as reported by KDE, "free", etc is short by a important > amount. To be more specific I will detail the results of "free" > below against the "mem" value passed to the kernel. Please note for > the purposes of this test I always had 256MB or ram (2x128MB) > installed in my system. The BIOS reports total system memory as > 262144K. Not really a bug--the "free" report leaves out the memory devoted to the kernel, which is unpageable and therefore unavailable to user apps. -Doug -- The rain man gave me two cures; he said jump right in, The first was Texas medicine--the second was just railroad gin, And like a fool I mixed them, and it strangled up my mind, Now people just get uglier, and I got no sense of time... --Dylan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel 2.2.19 Available Memory Bug
John L. Males [EMAIL PROTECTED] writes: The bug I am reporting is that when one sets the amount of memory, i.e. 128M, 256M; at the time of booting the 2.2.19 kernel the Total Memory as reported by KDE, free, etc is short by a important amount. To be more specific I will detail the results of free below against the mem value passed to the kernel. Please note for the purposes of this test I always had 256MB or ram (2x128MB) installed in my system. The BIOS reports total system memory as 262144K. Not really a bug--the free report leaves out the memory devoted to the kernel, which is unpageable and therefore unavailable to user apps. -Doug -- The rain man gave me two cures; he said jump right in, The first was Texas medicine--the second was just railroad gin, And like a fool I mixed them, and it strangled up my mind, Now people just get uglier, and I got no sense of time... --Dylan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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: Any limitations on bigmem usage?
Matt Nelson <[EMAIL PROTECTED]> writes: > I am about to embark on a data processing software project that will require a > LOT of memory (about, ohhh, 6GB or so), and I was wondering if there are any > limitations to how one can use very large chunks of memory under > Linux. Specifically, is there anything to prevent me from malloc()ing 6GB of > memory, then accessing that memory as I would any other buffer? FYI, the > application > > will be buffering a stream of data, then performing a variety of calculations > on large blocks of data at a time, before writing it out to a socket. Pointers on IA32 are still 32 bits, so (as I understand it) each process can address a maximum of 4GB. You would have to allocate multiple chunks (in shared memory or mmap()ed files, so they're persistent) and map them in and out as needed (which could get hairy). > I've been eyeing an 8-way Intel box with gobs of memory, but if there are > subtle issues with using that much memory, I need to know now. Best bet is probably to buy an Alpha machine, if you don't want to spend time working around the 4GB limitation. -Doug -- The rain man gave me two cures; he said jump right in, The first was Texas medicine--the second was just railroad gin, And like a fool I mixed them, and it strangled up my mind, Now people just get uglier, and I got no sense of time... --Dylan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Any limitations on bigmem usage?
Matt Nelson [EMAIL PROTECTED] writes: I am about to embark on a data processing software project that will require a LOT of memory (about, ohhh, 6GB or so), and I was wondering if there are any limitations to how one can use very large chunks of memory under Linux. Specifically, is there anything to prevent me from malloc()ing 6GB of memory, then accessing that memory as I would any other buffer? FYI, the application will be buffering a stream of data, then performing a variety of calculations on large blocks of data at a time, before writing it out to a socket. Pointers on IA32 are still 32 bits, so (as I understand it) each process can address a maximum of 4GB. You would have to allocate multiple chunks (in shared memory or mmap()ed files, so they're persistent) and map them in and out as needed (which could get hairy). I've been eyeing an 8-way Intel box with gobs of memory, but if there are subtle issues with using that much memory, I need to know now. Best bet is probably to buy an Alpha machine, if you don't want to spend time working around the 4GB limitation. -Doug -- The rain man gave me two cures; he said jump right in, The first was Texas medicine--the second was just railroad gin, And like a fool I mixed them, and it strangled up my mind, Now people just get uglier, and I got no sense of time... --Dylan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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: [newbie] NFS broken in 2.4.4?
Roland Kuhn <[EMAIL PROTECTED]> writes: > Hi folks! > > When a process tries to lstat64 a file on nfs and the reply is not > received it gets blocked forever. Should it be that way? If it's a hard nfs mount, yes. Mount soft if you want timeouts. -Doug -- The rain man gave me two cures; he said jump right in, The first was Texas medicine--the second was just railroad gin, And like a fool I mixed them, and it strangled up my mind, Now people just get uglier, and I got no sense of time... --Dylan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [newbie] NFS broken in 2.4.4?
Roland Kuhn [EMAIL PROTECTED] writes: Hi folks! When a process tries to lstat64 a file on nfs and the reply is not received it gets blocked forever. Should it be that way? If it's a hard nfs mount, yes. Mount soft if you want timeouts. -Doug -- The rain man gave me two cures; he said jump right in, The first was Texas medicine--the second was just railroad gin, And like a fool I mixed them, and it strangled up my mind, Now people just get uglier, and I got no sense of time... --Dylan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux + Compaq Presario Laptop
Erik Mouw <[EMAIL PROTECTED]> writes: > Try linux-2.2.19, it contains BIOS e820 support. If you don't want to > compile a kernel, check if Red Hat has RPMs available somewhere on > their site. They do; there was a kernel errata release of 2.2.19 for security reasons. On updates.redhat.com or a mirror. -Doug -- The rain man gave me two cures; he said jump right in, The first was Texas medicine--the second was just railroad gin, And like a fool I mixed them, and it strangled up my mind, Now people just get uglier, and I got no sense of time... --Dylan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux + Compaq Presario Laptop
Erik Mouw [EMAIL PROTECTED] writes: Try linux-2.2.19, it contains BIOS e820 support. If you don't want to compile a kernel, check if Red Hat has RPMs available somewhere on their site. They do; there was a kernel errata release of 2.2.19 for security reasons. On updates.redhat.com or a mirror. -Doug -- The rain man gave me two cures; he said jump right in, The first was Texas medicine--the second was just railroad gin, And like a fool I mixed them, and it strangled up my mind, Now people just get uglier, and I got no sense of time... --Dylan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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: /proc format (was Device Registry (DevReg) Patch 0.2.0)
"J . A . Magallon" <[EMAIL PROTECTED]> writes: > Question: it is possible to redirect the same fs call (say read) to different > implementations, based on the open mode of the file descriptor ? So, if > you open the entry in binary, you just get the number chunk, if you open > it in ascii you get a pretty printed version, or a format description like There is no distinction between "text" and "binary" modes on a file descriptor. The distinction exists in the C stdio layer, but is a no-op on Unix systems. -Doug -- The rain man gave me two cures; he said jump right in, The first was Texas medicine--the second was just railroad gin, And like a fool I mixed them, and it strangled up my mind, Now people just get uglier, and I got no sense of time... --Dylan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: /proc format (was Device Registry (DevReg) Patch 0.2.0)
J . A . Magallon [EMAIL PROTECTED] writes: Question: it is possible to redirect the same fs call (say read) to different implementations, based on the open mode of the file descriptor ? So, if you open the entry in binary, you just get the number chunk, if you open it in ascii you get a pretty printed version, or a format description like There is no distinction between text and binary modes on a file descriptor. The distinction exists in the C stdio layer, but is a no-op on Unix systems. -Doug -- The rain man gave me two cures; he said jump right in, The first was Texas medicine--the second was just railroad gin, And like a fool I mixed them, and it strangled up my mind, Now people just get uglier, and I got no sense of time... --Dylan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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: Current status of NTFS support
Lee Leahu <[EMAIL PROTECTED]> writes: > would somebody be kind enough to explain why writing to > the ntfs file system is extremely dangerous, and what are the > developers doing to make writing to ntfs filesystem safe? It's dangerous because NTFS is a proprietary format, and the full rules for updating it (including journals etc) are known only to Microsoft and those that have signed Microsoft NDAs. If you update it incorrectly it gets corrupted and you will lose data. It's certainly possible to reverse-engineer these rules, but very difficult and time-consuming. -Doug -- The rain man gave me two cures; he said jump right in, The first was Texas medicine--the second was just railroad gin, And like a fool I mixed them, and it strangled up my mind, Now people just get uglier, and I got no sense of time... --Dylan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [repost] Announce: Linux-OpenLVM mailing list
Miles Lane <[EMAIL PROTECTED]> writes: > Gosh, this seems like a bit of a red herring, IMHO. Do you think the > LKML gets a "lot" of spam? Or, how about the linux-usb-devel or > linux-hotplug-devel lists? None of these lists are moderated and the > occasional spam gets sent to them, but I haven't noticed there being > enough spam to hinder the usefulness of these lists. That's partly because davem and Matti are rabid anti-spam weasels and very good at it. ;) There are all kinds of filters (including content-based ones) on l-k, otherwise we'd be inundated in processed pork... -Doug -- The rain man gave me two cures; he said jump right in, The first was Texas medicine--the second was just railroad gin, And like a fool I mixed them, and it strangled up my mind, Now people just get uglier, and I got no sense of time... --Dylan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [repost] Announce: Linux-OpenLVM mailing list
Miles Lane [EMAIL PROTECTED] writes: Gosh, this seems like a bit of a red herring, IMHO. Do you think the LKML gets a "lot" of spam? Or, how about the linux-usb-devel or linux-hotplug-devel lists? None of these lists are moderated and the occasional spam gets sent to them, but I haven't noticed there being enough spam to hinder the usefulness of these lists. That's partly because davem and Matti are rabid anti-spam weasels and very good at it. ;) There are all kinds of filters (including content-based ones) on l-k, otherwise we'd be inundated in processed pork... -Doug -- The rain man gave me two cures; he said jump right in, The first was Texas medicine--the second was just railroad gin, And like a fool I mixed them, and it strangled up my mind, Now people just get uglier, and I got no sense of time... --Dylan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Current status of NTFS support
Lee Leahu [EMAIL PROTECTED] writes: would somebody be kind enough to explain why writing to the ntfs file system is extremely dangerous, and what are the developers doing to make writing to ntfs filesystem safe? It's dangerous because NTFS is a proprietary format, and the full rules for updating it (including journals etc) are known only to Microsoft and those that have signed Microsoft NDAs. If you update it incorrectly it gets corrupted and you will lose data. It's certainly possible to reverse-engineer these rules, but very difficult and time-consuming. -Doug -- The rain man gave me two cures; he said jump right in, The first was Texas medicine--the second was just railroad gin, And like a fool I mixed them, and it strangled up my mind, Now people just get uglier, and I got no sense of time... --Dylan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Your response is requested
Dave Zarzycki <[EMAIL PROTECTED]> writes: > On Tue, 17 Apr 2001 [EMAIL PROTECTED] wrote: > ^^ > > Arrggg!!! Mumble... grumble... F*cking spammer using my hostname as the > from address for sending spam... Not true. The From: address was simply "J.I."; your mailhost tacked on your local domain since it was unqualified. Gave me a turn, too, until I figured it out. -Doug - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Your response is requested
Dave Zarzycki [EMAIL PROTECTED] writes: On Tue, 17 Apr 2001 [EMAIL PROTECTED] wrote: ^^ Arrggg!!! Mumble... grumble... F*cking spammer using my hostname as the from address for sending spam... Not true. The From: address was simply "J.I."; your mailhost tacked on your local domain since it was unqualified. Gave me a turn, too, until I figured it out. -Doug - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Data-corruption bug in VIA chipsets
Alan Cox <[EMAIL PROTECTED]> writes: > > Is this problem likely to affect 2.2.X? I have a VIA-based board on > > order (Tyan Trinity) and I don't plan to run 2.4 on it anytime soon > > (it's upgrading a stock RH6.2 box). > > > > Am I safe if I stay in PIO mode? > > I have received exactly zero reports of 2.2 problems, and as the 2.2 > maintainer I would have expected more (I delete 2.2 + ide-patch > reports). My suspicion is the problem requires UDMA to occur, or to > occur with any probability. This is good to know. I'll stay away from UDMA and the ide-patches until things seem clearer then. > The real concern (as with all of these things) is going to be what the > workaround does to performance - as measured in frames/second for most folks ;) Well, this is a compile server (and will have a lot of RAM) so running PIO for a while shouldn't have much impact. Thanks, Alan. -Doug - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Data-corruption bug in VIA chipsets
Alan Cox <[EMAIL PROTECTED]> writes: > > Here might be one of the resons for the trouble with VIA chipsets: > > > > http://www.theregister.co.uk/content/3/18267.html > > > > Some DMA error corrupting data, sounds like a really nasty bug. The > > information is minimal on that page. > > What annoys me is that we've known about the problem for _ages_. If you look > the 2.4 kernel has experimental workarounds for this problem. VIA never once > even returned an email to say 'we are looking into this'. Instead people sat > there flashing multiple BIOS images and seeing what made the difference. Is this problem likely to affect 2.2.X? I have a VIA-based board on order (Tyan Trinity) and I don't plan to run 2.4 on it anytime soon (it's upgrading a stock RH6.2 box). Am I safe if I stay in PIO mode? -Doug - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Data-corruption bug in VIA chipsets
Alan Cox [EMAIL PROTECTED] writes: Here might be one of the resons for the trouble with VIA chipsets: http://www.theregister.co.uk/content/3/18267.html Some DMA error corrupting data, sounds like a really nasty bug. The information is minimal on that page. What annoys me is that we've known about the problem for _ages_. If you look the 2.4 kernel has experimental workarounds for this problem. VIA never once even returned an email to say 'we are looking into this'. Instead people sat there flashing multiple BIOS images and seeing what made the difference. Is this problem likely to affect 2.2.X? I have a VIA-based board on order (Tyan Trinity) and I don't plan to run 2.4 on it anytime soon (it's upgrading a stock RH6.2 box). Am I safe if I stay in PIO mode? -Doug - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Data-corruption bug in VIA chipsets
Alan Cox [EMAIL PROTECTED] writes: Is this problem likely to affect 2.2.X? I have a VIA-based board on order (Tyan Trinity) and I don't plan to run 2.4 on it anytime soon (it's upgrading a stock RH6.2 box). Am I safe if I stay in PIO mode? I have received exactly zero reports of 2.2 problems, and as the 2.2 maintainer I would have expected more (I delete 2.2 + ide-patch reports). My suspicion is the problem requires UDMA to occur, or to occur with any probability. This is good to know. I'll stay away from UDMA and the ide-patches until things seem clearer then. The real concern (as with all of these things) is going to be what the workaround does to performance - as measured in frames/second for most folks ;) Well, this is a compile server (and will have a lot of RAM) so running PIO for a while shouldn't have much impact. Thanks, Alan. -Doug - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Incorect signal handling ?
Daniel Podlejski <[EMAIL PROTECTED]> writes: > Hi, > > there is litlle programm: > > signal (SIGALRM, empty); > alarm (1); > > a = read(fd, buf, 511); > > while (a && a != -1) a = read(fd, buf, 511); > I open /tmp/nic and run compiled program. > There should be error EINTR in read, but isn't. "Fast" system calls (eg reads from disk) are generally uninterruptible; thus the signal will be deferred until the read() returns. -Doug - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Incorect signal handling ?
Daniel Podlejski [EMAIL PROTECTED] writes: Hi, there is litlle programm: signal (SIGALRM, empty); alarm (1); a = read(fd, buf, 511); while (a a != -1) a = read(fd, buf, 511); I open /tmp/nic and run compiled program. There should be error EINTR in read, but isn't. "Fast" system calls (eg reads from disk) are generally uninterruptible; thus the signal will be deferred until the read() returns. -Doug - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 find modules after moving to 2.4.2
Marcus Ramos <[EMAIL PROTECTED]> writes: > Hello, > > I've moved from kernel 2.2.16 to 2.4.2 (RH7) and its boots OK, except > for the fact that none of the modules in "/etc/modules.conf" are loaded > anymore (although modules were enabled in kernel config). In > "/lib/modules" I see two directories: 2.2.16 and 2.4.2 (which I assume > is the default for modules.conf). However, the "/lib/modules/2.4.2" > contains almost no files, differently from 2.2.16. I guess I've missed > some important step during the installation of 2.4.2, but now I am > confused and can't recover. Can anyboy point me what the missing step is > ? I will be most grateful. Upgrade your modutils. See Documentation/CHANGES. -Doug - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: menuconfig snafu?
Dennis <[EMAIL PROTECTED]> writes: > I also find it interesting that the default at kernel.org wont boot on a > Pentium...generic should be the default. The default config is what boots on Linus' machine. Once you realise that your life get a lot easier. ;) -Doug - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: menuconfig snafu?
Dennis [EMAIL PROTECTED] writes: I also find it interesting that the default at kernel.org wont boot on a Pentium...generic should be the default. The default config is what boots on Linus' machine. Once you realise that your life get a lot easier. ;) -Doug - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 find modules after moving to 2.4.2
Marcus Ramos [EMAIL PROTECTED] writes: Hello, I've moved from kernel 2.2.16 to 2.4.2 (RH7) and its boots OK, except for the fact that none of the modules in "/etc/modules.conf" are loaded anymore (although modules were enabled in kernel config). In "/lib/modules" I see two directories: 2.2.16 and 2.4.2 (which I assume is the default for modules.conf). However, the "/lib/modules/2.4.2" contains almost no files, differently from 2.2.16. I guess I've missed some important step during the installation of 2.4.2, but now I am confused and can't recover. Can anyboy point me what the missing step is ? I will be most grateful. Upgrade your modutils. See Documentation/CHANGES. -Doug - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [OT] Linux Worm (fwd)
Gerhard Mack <[EMAIL PROTECTED]> writes: > On Fri, 23 Mar 2001, Bob Lorenzini wrote: > > > I'm annoyed when persons post virus alerts to unrelated lists but this > > is a serious threat. If your offended flame away. > > This should be a wake up call... distributions need to stop using product > with consistently bad security records. Is there an alternative to BIND that's free software? Never seen one. -Doug (who doesn't think this is a Good Thing) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [OT] Linux Worm (fwd)
Gerhard Mack [EMAIL PROTECTED] writes: On Fri, 23 Mar 2001, Bob Lorenzini wrote: I'm annoyed when persons post virus alerts to unrelated lists but this is a serious threat. If your offended flame away. This should be a wake up call... distributions need to stop using product with consistently bad security records. Is there an alternative to BIND that's free software? Never seen one. -Doug (who doesn't think this is a Good Thing) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: fork and pthreads
[EMAIL PROTECTED] writes: > I am having a strange problem. > > I have a big daemon program to which I am trying to add multi-threading. > > At the begining, after some sanity check, this program does a double fork to > create a deamon. > > After that it listens for the client on the port. Whenever the client > connects, it creates a new thread using > pthread-create. > > The problem is, the thread (main thread) calling pthread-create hangs > indefinetely in __sigsuspend. The newly created thread however, runs > normally to completion. Just a guess--are you calling setsid() to establish a new session? Omitting this *might* cause signal-delivery problems in pthreads. -Doug - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: fork and pthreads
[EMAIL PROTECTED] writes: I am having a strange problem. I have a big daemon program to which I am trying to add multi-threading. At the begining, after some sanity check, this program does a double fork to create a deamon. After that it listens for the client on the port. Whenever the client connects, it creates a new thread using pthread-create. The problem is, the thread (main thread) calling pthread-create hangs indefinetely in __sigsuspend. The newly created thread however, runs normally to completion. Just a guess--are you calling setsid() to establish a new session? Omitting this *might* cause signal-delivery problems in pthreads. -Doug - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: 242-ac3 loop bug
Mark Swanson <[EMAIL PROTECTED]> writes: > --- Doug McNaught <[EMAIL PROTECTED]> wrote: > > It's just an artifact of the fact that processes in state D > > (uninterruptible sleep) are included in the load average calculation. > > Since the loop thread apparently sits in state D waiting for events > > on its device, you get a load average of 1 for each mounted loop > > device. > > My thought was that the calculation seems to be misleading. The loop > process isn't taking up any CPU time. My applications are running > faster than ever. I'm guessing that ps (and /proc/loadavg) need to make > the distinction between: > 1. uninterruptable sleep - where the process is blocking but taking > 0CPU > 2. uninterruptable sleep - I/O is happening using CPU > > But I may not understand what uninterruptable sleep is supposed to > mean. Well, "sleep" means we're not using CPU at all; we're waiting for something. Remember, "load average" isn't purely a CPU measure. Historically, state D has meant "fast" i/o--reading from disk or tape, where the result is supposed to be available very soon and it's not worth doing the extra housekeeping to sleep interruptibly. Processes aren't supposed to sit in state D for more than a fraction of a second. This being the case, Unix has always factored state D processes into the load average. For your distinction to work, there would have to be an extra flag somewhere saying "I'm in state D, but don't factor me into the load average", with corresponding code in the load average calculation routine to honor the flag. Doable, but not useful up to now, and only (possibly) worth doing if we get more threads like the loop driver that sit in D state for a long time. This is the first example I've seen in Linux of something sitting in state D for a long time on purpose. I agree that IMHO it's not ideal (for the reason you outline below, mainly). > Take sendmail for example. Its default configuration for Linux won't > send attachments if the machine's load is too high. If I have 8 loop > devices in use and the load is at least 8, this may affect how sendmail > operates. Yup. The whole Sendmail/load average thing needs careful thought anyway when setting up a production system--a load average of 8 on an 8-way system, for example, is a much lighter load than a load of 8 on a single-CPU machine. -Doug - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: 242-ac3 loop bug
Mark Swanson <[EMAIL PROTECTED]> writes: > > ps -aux | grep loop > 1674 tty1 DW< 0:00 [loop0] > > The system is doing nothing to the loop filesystem. > Strange that the process isn't logging any cpu usage time. It's > definately responsible for the 1.00 load. It's just an artifact of the fact that processes in state D (uninterruptible sleep) are included in the load average calculation. Since the loop thread apparently sits in state D waiting for events on its device, you get a load average of 1 for each mounted loop device. I know nothing about the implementation of the loop thread so won't presume to say whether/how it can be "fixed". -Doug - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: 242-ac3 loop bug
Mark Swanson [EMAIL PROTECTED] writes: ps -aux | grep loop 1674 tty1 DW 0:00 [loop0] The system is doing nothing to the loop filesystem. Strange that the process isn't logging any cpu usage time. It's definately responsible for the 1.00 load. It's just an artifact of the fact that processes in state D (uninterruptible sleep) are included in the load average calculation. Since the loop thread apparently sits in state D waiting for events on its device, you get a load average of 1 for each mounted loop device. I know nothing about the implementation of the loop thread so won't presume to say whether/how it can be "fixed". -Doug - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: 242-ac3 loop bug
Mark Swanson [EMAIL PROTECTED] writes: --- Doug McNaught [EMAIL PROTECTED] wrote: It's just an artifact of the fact that processes in state D (uninterruptible sleep) are included in the load average calculation. Since the loop thread apparently sits in state D waiting for events on its device, you get a load average of 1 for each mounted loop device. My thought was that the calculation seems to be misleading. The loop process isn't taking up any CPU time. My applications are running faster than ever. I'm guessing that ps (and /proc/loadavg) need to make the distinction between: 1. uninterruptable sleep - where the process is blocking but taking 0CPU 2. uninterruptable sleep - I/O is happening using CPU But I may not understand what uninterruptable sleep is supposed to mean. Well, "sleep" means we're not using CPU at all; we're waiting for something. Remember, "load average" isn't purely a CPU measure. Historically, state D has meant "fast" i/o--reading from disk or tape, where the result is supposed to be available very soon and it's not worth doing the extra housekeeping to sleep interruptibly. Processes aren't supposed to sit in state D for more than a fraction of a second. This being the case, Unix has always factored state D processes into the load average. For your distinction to work, there would have to be an extra flag somewhere saying "I'm in state D, but don't factor me into the load average", with corresponding code in the load average calculation routine to honor the flag. Doable, but not useful up to now, and only (possibly) worth doing if we get more threads like the loop driver that sit in D state for a long time. This is the first example I've seen in Linux of something sitting in state D for a long time on purpose. I agree that IMHO it's not ideal (for the reason you outline below, mainly). Take sendmail for example. Its default configuration for Linux won't send attachments if the machine's load is too high. If I have 8 loop devices in use and the load is at least 8, this may affect how sendmail operates. Yup. The whole Sendmail/load average thing needs careful thought anyway when setting up a production system--a load average of 8 on an 8-way system, for example, is a much lighter load than a load of 8 on a single-CPU machine. -Doug - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: bidirectional named pipe?
"David L. Nicol" <[EMAIL PROTECTED]> writes: > According to the Understanding the Linux Kernel book I > plowed through yesterday afternoon the EXT2 file system > has a defined file type "socket," distinct from fifo. > > How does one set up a named socket in a file system? Is it > a legacy constant that has never been supported or what? > Call bind() on an AF_LOCAL (aka AF_UNIX) socket. About as far from legacy as you can get... -Doug - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bidirectional named pipe?
"David L. Nicol" [EMAIL PROTECTED] writes: According to the Understanding the Linux Kernel book I plowed through yesterday afternoon the EXT2 file system has a defined file type "socket," distinct from fifo. How does one set up a named socket in a file system? Is it a legacy constant that has never been supported or what? Call bind() on an AF_LOCAL (aka AF_UNIX) socket. About as far from legacy as you can get... -Doug - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: System unresponsitive when copying HD/HD
Delta <[EMAIL PROTECTED]> writes: > While cp is copying from the second hard disk to the first hard disk, > I find my system performance > drop VERY sharply. X is sloppy, even bash takes many seconds to > respond. I using two > recent IDE disk (Fudjisu 13 gig, Maxtor 20 Gig), so I'm wondering why > the system is so slow? My mobo is a FIC SD11 and I have an athlon > 550 Mhz. You don't say what kernel you're running. Some versions (2.2.16ish) have very bad interactive response under I/O load. 2.2.18 is supposed to be better, or try 2.2.19pre. Also 'hdparm -u' may help, and turning on DMA if you're not using it. -Doug - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: System unresponsitive when copying HD/HD
Delta [EMAIL PROTECTED] writes: While cp is copying from the second hard disk to the first hard disk, I find my system performance drop VERY sharply. X is sloppy, even bash takes many seconds to respond. I using two recent IDE disk (Fudjisu 13 gig, Maxtor 20 Gig), so I'm wondering why the system is so slow? My mobo is a FIC SD11 and I have an athlon 550 Mhz. You don't say what kernel you're running. Some versions (2.2.16ish) have very bad interactive response under I/O load. 2.2.18 is supposed to be better, or try 2.2.19pre. Also 'hdparm -u' may help, and turning on DMA if you're not using it. -Doug - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Serious reproducible 2.4.x kernel hang
Chris Evans <[EMAIL PROTECTED]> writes: > [cc: davem because of the severity] > > On Thu, 1 Feb 2001, Malcolm Beattie wrote: > > > rid of the hang. So it looks as though some combination of > > shutdown(2) and SIGABRT is at fault. After the hang the kernel-side > > Nope - I've nailed it to a _really_ simple test case. It looks like a > read() on a shutdown() unix dgram socket just kills the kernel. Demo code > below. I wonder if this affects UP or is SMP only? Kills my UP K6-2 dead as a doornail (except for pings, as you say). -Doug - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Serious reproducible 2.4.x kernel hang
Chris Evans [EMAIL PROTECTED] writes: [cc: davem because of the severity] On Thu, 1 Feb 2001, Malcolm Beattie wrote: rid of the hang. So it looks as though some combination of shutdown(2) and SIGABRT is at fault. After the hang the kernel-side Nope - I've nailed it to a _really_ simple test case. It looks like a read() on a shutdown() unix dgram socket just kills the kernel. Demo code below. I wonder if this affects UP or is SMP only? Kills my UP K6-2 dead as a doornail (except for pings, as you say). -Doug - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[OT] Re: Version 2.4.1 cannot be built.
"Richard B. Johnson" <[EMAIL PROTECTED]> writes: > On Wed, 31 Jan 2001, Sean Hunter wrote: > > Okay! I'm answering the guy who gave me the kindest response. > The rest of you guys can just hold your belly. > > Right. I'm getting blind. Been typing the same error > every time I tried the site. As one of the guys who just flamed you, I'll admit to having spent at least 15 minutes scratching my head over this very problem (at a different site, that *didn't* have an automatically displayed README that explained the potential problem in very clear terms). This one will never bite you again, unless you have a very bad memory. ;) -Doug - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Version 2.4.1 cannot be built.
"Richard B. Johnson" <[EMAIL PROTECTED]> writes: > See attached. "Just because you can see the candy doesn't mean > they'll let you have any" [output of README when you connect:] > Please note that the directory structure on ftp.gnu.org was redisorganzied > fairly recently, such that there is a directory for each program. One side > effect of this is that if you cd into the gnu directory, and do > > ls emacs* > you will get a list of all the files in the emacs directory, but it will not > be obvious from the ls output that you have to `cd emacs' before you can > download those files. Now, > ftp> cd gnu > ftp> ls mak* > 200 PORT command successful. > 150 Opening ASCII mode data connection for file list. > -rw-r--r-- 1 ftp ftp 1095 Jul 14 1997 makeinfo.README > > make: > -rw-r--r-- 1 ftp ftp 27010 Sep 23 1989 make-3.55-3.56.diff.gz [...] > -rw-r--r-- 1 ftp ftp 1030393 Jun 24 2000 make-3.79.1.tar.gz > -rw-r--r-- 1 ftp ftp959005 Apr 11 2000 make-3.79.tar.gz > 226 Transfer complete. > ftp> bin > 200 Type set to I. > ftp> get make-3.79.1.tar.gz > local: make-3.79.1.tar.gz remote: make-3.79.1.tar.gz > 200 PORT command successful. > 550 make-3.79.1.tar.gz: No such file or directory Duh. Read the README next time; that's what it's there for. -Doug - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Off-Topic: how do I trace a PID over double-forks?
Jesse Pollard <[EMAIL PROTECTED]> writes: > Ummm ... basicly a "respawn" entry in the inittab is enough for that. Nope, see below. > If you wanted sendmail then: > > sndm:234:respawn:/usr/lib/sendmail -bd -q15m > > Will restart sendmail whenever it aborts in runleves 2,3, or 4. Sendmail in daemon mode forks right away, and the child is the daemon. All init will know is that the process it started exited right away, and you'll get a "respawning too fast" message. I don't recall if there's an option to sendmail that says "be a daemon, but run in the foreground." Probably is, for debugging. -Doug - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Off-Topic: how do I trace a PID over double-forks?
Jesse Pollard [EMAIL PROTECTED] writes: Ummm ... basicly a "respawn" entry in the inittab is enough for that. Nope, see below. If you wanted sendmail then: sndm:234:respawn:/usr/lib/sendmail -bd -q15m Will restart sendmail whenever it aborts in runleves 2,3, or 4. Sendmail in daemon mode forks right away, and the child is the daemon. All init will know is that the process it started exited right away, and you'll get a "respawning too fast" message. I don't recall if there's an option to sendmail that says "be a daemon, but run in the foreground." Probably is, for debugging. -Doug - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4 and ipmasq modules
Aaron Lehmann <[EMAIL PROTECTED]> writes: > On Sun, Jan 21, 2001 at 11:08:00AM +1100, Daniel Stone wrote: > > "I'd rather stay with my friendly old pushbike than my car!" > > So don't complain when you can't use cruise control. > > ipfwadm used to support the modules. Why have the modules for ipfwadm > been removed from the kernel source? Umm, because the underlying infrastructure is completely different? You're confusing 'ipfwadm' (a program that uses an old API that is emulated by the new kernel) and the kernel ipfw code, which is gone, gone, gone. -Doug - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4 and ipmasq modules
Aaron Lehmann [EMAIL PROTECTED] writes: On Sun, Jan 21, 2001 at 11:08:00AM +1100, Daniel Stone wrote: "I'd rather stay with my friendly old pushbike than my car!" So don't complain when you can't use cruise control. ipfwadm used to support the modules. Why have the modules for ipfwadm been removed from the kernel source? Umm, because the underlying infrastructure is completely different? You're confusing 'ipfwadm' (a program that uses an old API that is emulated by the new kernel) and the kernel ipfw code, which is gone, gone, gone. -Doug - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: IDE DMA problems on 2.4.0 with vt82c686a driver
James Brents <[EMAIL PROTECTED]> writes:
> Hello,
> Since this looks like either a chipset, drive, or driver problem, I am
> submitting this.
>
> I have recently started using DMA mode on my harddisk. However, I occasionally
> (not often/constant, but sometimes) get CRC errors:
>
> hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
You might try testing with a different drive if you can get hold of
one--if that works OK, that'll narrow it down to either a drive or
drive-chipset interaction. The above error message could very well
mean that you're starting to lose the drive, so keep backups!
-Doug
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: es1371 module dependencies problem
David <[EMAIL PROTECTED]> writes: > kernel: 2.4.0 > modutils: 2.3.23 > > loading the es1371 module gives me the following error: > /lib/modules/2.4.0/kernel/drivers/sound/es1371.o: unresolved symbol > ac97_probe_codec_Rsmp_1c61c357 It works for me (tm). Kernel 2.4.0, modutils 2.3.23-2 (Debian woody). 'modprobe' loads the module quite happily. I'm running UP, not SMP, so maybe that's the issue. You might try a complete rebuild starting from 'make mrproper', and turn off SMP if you only have one processor. -Doug - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: es1371 module dependencies problem
David [EMAIL PROTECTED] writes: kernel: 2.4.0 modutils: 2.3.23 loading the es1371 module gives me the following error: /lib/modules/2.4.0/kernel/drivers/sound/es1371.o: unresolved symbol ac97_probe_codec_Rsmp_1c61c357 It works for me (tm). Kernel 2.4.0, modutils 2.3.23-2 (Debian woody). 'modprobe' loads the module quite happily. I'm running UP, not SMP, so maybe that's the issue. You might try a complete rebuild starting from 'make mrproper', and turn off SMP if you only have one processor. -Doug - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: IDE DMA problems on 2.4.0 with vt82c686a driver
James Brents [EMAIL PROTECTED] writes:
Hello,
Since this looks like either a chipset, drive, or driver problem, I am
submitting this.
I have recently started using DMA mode on my harddisk. However, I occasionally
(not often/constant, but sometimes) get CRC errors:
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
You might try testing with a different drive if you can get hold of
one--if that works OK, that'll narrow it down to either a drive or
drive-chipset interaction. The above error message could very well
mean that you're starting to lose the drive, so keep backups!
-Doug
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0 tcp over firewall - no connection
[EMAIL PROTECTED] (Eugene Crosser) writes: > I noticed rather strange behavior: stock 2.4.0 with old ISA 3Com > on UP compiled as UP cannot open TCP connection to hosts behind a > firewall. E.g. it is impossible to go to http://www.etrade.com/ - > connect just never finishes. 2.2.17 on the same hardware works > right. 2.4.0 on SMP over PPP connection works right too. MTU > is 1500 in both cases. In both cases, kernel is compiled with > netfilter as modules, but those are not loaded. Known problem, exhaustively discussed on the list, and not related to your NIC. Disable ECN (explicit congestion notification), either in your kernel compile or in /proc/sys/. -Doug - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: unexplained high load
<[EMAIL PROTECTED]> writes: > think this, but problem, machine is running ok > no slow response, only load 1.00 (it's not getting lower) Process stuck in D state? -Doug - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: unexplained high load
[EMAIL PROTECTED] writes: think this, but problem, machine is running ok no slow response, only load 1.00 (it's not getting lower) Process stuck in D state? -Doug - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0 tcp over firewall - no connection
[EMAIL PROTECTED] (Eugene Crosser) writes: I noticed rather strange behavior: stock 2.4.0 with old ISA 3Com on UP compiled as UP cannot open TCP connection to hosts behind a firewall. E.g. it is impossible to go to http://www.etrade.com/ - connect just never finishes. 2.2.17 on the same hardware works right. 2.4.0 on SMP over PPP connection works right too. MTU is 1500 in both cases. In both cases, kernel is compiled with netfilter as modules, but those are not loaded. Known problem, exhaustively discussed on the list, and not related to your NIC. Disable ECN (explicit congestion notification), either in your kernel compile or in /proc/sys/something. -Doug - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] cramfs is ro only, so honour this in inode->mode
"Albert D. Cahalan" <[EMAIL PROTECTED]> writes: > Doug writes: > > bash-2.03$ cd /tmp > > bash-2.03$ cat >foo > > This is a test. > > bash-2.03$ chmod u-r foo > > No, you zeroed the owner's read bit. When the bit isn't > implemented it must be always set. > > By "(owner may read own files)" I refer to what happens > after you steal the bit, causing it to always appear set. Ahh, OK, thanks for the clarification. -Doug - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: adding a system call
Mihai Moise <[EMAIL PROTECTED]> writes: > My system call idea is to allow a superuser process to request a mmap on > behalf of an user process. To see how this would be useful, let us consider > svgalib. [...] > With my new system call, a superuser process can set the graphics mode in a > safe manner and then ask for an mmap of the video array into the application > data segment. Ummm, couldn't the the root process open the video device, then pass the file descriptor (via AF_UNIX socket) to the user process? The user process would then call mmap() on the open file descriptor. I'm not *completely* sure this would work, but it would avoid creating a new system call if so. -Doug - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] cramfs is ro only, so honour this in inode->mode
"Albert D. Cahalan" <[EMAIL PROTECTED]> writes: > Shane Nay writes: > > > but the bits are useless in the "normal interpretation" of it, > ... > > But then you pull out the write bits, > > If you need to steal a bit, grab one that won't hurt. > Take the owner's read bit. (owner may read own files) Er, bash-2.03$ cd /tmp bash-2.03$ cat >foo This is a test. bash-2.03$ chmod u-r foo bash-2.03$ cat foo cat: foo: Permission denied bash-2.03$ ls -l foo --w-r--r--1 doug doug 16 Jan 9 09:16 foo bash-2.03$ This is Linux 2.4.0. -Doug - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] cramfs is ro only, so honour this in inode-mode
"Albert D. Cahalan" [EMAIL PROTECTED] writes: Shane Nay writes: but the bits are useless in the "normal interpretation" of it, ... But then you pull out the write bits, If you need to steal a bit, grab one that won't hurt. Take the owner's read bit. (owner may read own files) Er, bash-2.03$ cd /tmp bash-2.03$ cat foo This is a test. bash-2.03$ chmod u-r foo bash-2.03$ cat foo cat: foo: Permission denied bash-2.03$ ls -l foo --w-r--r--1 doug doug 16 Jan 9 09:16 foo bash-2.03$ This is Linux 2.4.0. -Doug - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: adding a system call
Mihai Moise [EMAIL PROTECTED] writes: My system call idea is to allow a superuser process to request a mmap on behalf of an user process. To see how this would be useful, let us consider svgalib. [...] With my new system call, a superuser process can set the graphics mode in a safe manner and then ask for an mmap of the video array into the application data segment. Ummm, couldn't the the root process open the video device, then pass the file descriptor (via AF_UNIX socket) to the user process? The user process would then call mmap() on the open file descriptor. I'm not *completely* sure this would work, but it would avoid creating a new system call if so. -Doug - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] cramfs is ro only, so honour this in inode-mode
"Albert D. Cahalan" [EMAIL PROTECTED] writes: Doug writes: bash-2.03$ cd /tmp bash-2.03$ cat foo This is a test. bash-2.03$ chmod u-r foo No, you zeroed the owner's read bit. When the bit isn't implemented it must be always set. By "(owner may read own files)" I refer to what happens after you steal the bit, causing it to always appear set. Ahh, OK, thanks for the clarification. -Doug - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] prevention of syscalls from writable segments, breaking bug exploits
Dan Hollis <[EMAIL PROTECTED]> writes: > On Wed, 3 Jan 2001, Alexander Viro wrote: > > On Wed, 3 Jan 2001, Dan Aloni wrote: > > > without breaking anything. It also reports of such calls by using printk. > > Get real. > > Why do you always have to be insulting alex? Sheesh. I was thinking it's about time this flamewar^Wthread came up again. Shall we start a pool on total # of messages, first invocation of Godwin's law, etc? -Doug - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: SHM Not working in 2.4.0-prerelease
Shawn Starr <[EMAIL PROTECTED]> writes:
> [spstarr@coredump /etc]$ free
> total used free sharedbuffers
> cached
> Mem: 62496 61264 1232 0 1248
> 28848
>
>
> There's no shared memory being used?
[...]
> the shmfs is mounted. Is there any configuration i need to get shm
> memory activiated?
The 'shared' field in /proc/meminfo (source for 'top' and 'free') has
nothing to do with {SysV,POSIX} shared memory. The 'shared' field
referred to memory that was used by more than one process (shared
libraries, shared text segments etc). As I understand it, under 2.4
the 'shared' field is very expensive to calculate, so we don't--the
zero value is there to avoid breaking programs that parse
/proc/meminfo.
-Doug
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: SHM Not working in 2.4.0-prerelease
Shawn Starr [EMAIL PROTECTED] writes:
[spstarr@coredump /etc]$ free
total used free sharedbuffers
cached
Mem: 62496 61264 1232 0 1248
28848
There's no shared memory being used?
[...]
the shmfs is mounted. Is there any configuration i need to get shm
memory activiated?
The 'shared' field in /proc/meminfo (source for 'top' and 'free') has
nothing to do with {SysV,POSIX} shared memory. The 'shared' field
referred to memory that was used by more than one process (shared
libraries, shared text segments etc). As I understand it, under 2.4
the 'shared' field is very expensive to calculate, so we don't--the
zero value is there to avoid breaking programs that parse
/proc/meminfo.
-Doug
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] prevention of syscalls from writable segments, breaking bug exploits
Dan Hollis [EMAIL PROTECTED] writes: On Wed, 3 Jan 2001, Alexander Viro wrote: On Wed, 3 Jan 2001, Dan Aloni wrote: without breaking anything. It also reports of such calls by using printk. Get real. Why do you always have to be insulting alex? Sheesh. I was thinking it's about time this flamewar^Wthread came up again. Shall we start a pool on total # of messages, first invocation of Godwin's law, etc? -Doug - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Applying crypto patch to recent 2.2.18pre
I am trying to get an up-to-date stable kernel (2.2.18pre19, with PowerPC changes, downloaded from the PowerPC BitKeeper archive) compiled with the international patch (patch-int-2.2.17-9 which is the latest in the crypto/ directory). The patch applies fine (with some offsets, but all hunks succeed) but when linking vmlinux, I get the following: ld -T arch/ppc/vmlinux.lds -Ttext 0xc000 -Bstatic arch/ppc/kernel/head.o init/main.o init/version.o \ --start-group \ arch/ppc/kernel/kernel.o arch/ppc/mm/mm.o arch/ppc/lib/lib.o kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o \ fs/filesystems.a \ net/network.a \ drivers/block/block.a drivers/char/char.o drivers/misc/misc.a drivers/net/net.a drivers/cdrom/cdrom.a drivers/sound/sounddrivers.o drivers/pci/pci.a drivers/macintosh/macintosh.o drivers/video/video.a \ /usr/src/linuxppc_2_2/lib/lib.a \ --end-group \ -o vmlinux init/main.o: In function `do_basic_setup': init/main.o(.text.init+0x9f0): undefined reference to `cryptoapi_init' init/main.o(.text.init+0x9f0): relocation truncated to fit: R_PPC_REL24 cryptoapi_init drivers/block/block.a(loop_gen.o): In function `loop_gen_init2': loop_gen.o(.text+0x104): undefined reference to `find_transform_by_id' loop_gen.o(.text+0x104): relocation truncated to fit: R_PPC_REL24 find_transform_by_id make: *** [vmlinux] Error 1 This happened somewhere between 2.2.18pre3 (which compiles successfully with the 2.2.17 crypto patch) and vanilla (from people/alan) pre9, which fails with the same error as above. I'm guessing something changed in the conventions for subsystem initialization. If someone can give me a quick summary of what to change, I'll try to fix it. Otherwise I'll grovel through the 2.2.18pre patches and try to figure out what to do myself, but I'm not looking forward to that option... Thanks in advance, Doug - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: modular kernel
FORT David <[EMAIL PROTECTED]> writes: > Taco Witte wrote: > > I think it's a very good idea, because it would make it easier to > > get more people work at the same moment, development would go > > faster. It would be possible to make groups for a certain part of > > the kernel (for example sound, or filesystems, or main) with own > > group pages with status info and todo's and own mailinglists (it > > would divide this enourmous flow of mail into smaller parts). It > > would decrease the download size. I believe it would make bug > > tracking easier as well. I'm sure I forgot to mention something.. > Looks like the beginning of a new flame war. s/a new/an old and well-trodden/ HTH. -Doug - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: modular kernel
FORT David [EMAIL PROTECTED] writes: Taco Witte wrote: I think it's a very good idea, because it would make it easier to get more people work at the same moment, development would go faster. It would be possible to make groups for a certain part of the kernel (for example sound, or filesystems, or main) with own group pages with status info and todo's and own mailinglists (it would divide this enourmous flow of mail into smaller parts). It would decrease the download size. I believe it would make bug tracking easier as well. I'm sure I forgot to mention something.. Looks like the beginning of a new flame war. s/a new/an old and well-trodden/ HTH. -Doug - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Applying crypto patch to recent 2.2.18pre
I am trying to get an up-to-date stable kernel (2.2.18pre19, with PowerPC changes, downloaded from the PowerPC BitKeeper archive) compiled with the international patch (patch-int-2.2.17-9 which is the latest in the crypto/ directory). The patch applies fine (with some offsets, but all hunks succeed) but when linking vmlinux, I get the following: ld -T arch/ppc/vmlinux.lds -Ttext 0xc000 -Bstatic arch/ppc/kernel/head.o init/main.o init/version.o \ --start-group \ arch/ppc/kernel/kernel.o arch/ppc/mm/mm.o arch/ppc/lib/lib.o kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o \ fs/filesystems.a \ net/network.a \ drivers/block/block.a drivers/char/char.o drivers/misc/misc.a drivers/net/net.a drivers/cdrom/cdrom.a drivers/sound/sounddrivers.o drivers/pci/pci.a drivers/macintosh/macintosh.o drivers/video/video.a \ /usr/src/linuxppc_2_2/lib/lib.a \ --end-group \ -o vmlinux init/main.o: In function `do_basic_setup': init/main.o(.text.init+0x9f0): undefined reference to `cryptoapi_init' init/main.o(.text.init+0x9f0): relocation truncated to fit: R_PPC_REL24 cryptoapi_init drivers/block/block.a(loop_gen.o): In function `loop_gen_init2': loop_gen.o(.text+0x104): undefined reference to `find_transform_by_id' loop_gen.o(.text+0x104): relocation truncated to fit: R_PPC_REL24 find_transform_by_id make: *** [vmlinux] Error 1 This happened somewhere between 2.2.18pre3 (which compiles successfully with the 2.2.17 crypto patch) and vanilla (from people/alan) pre9, which fails with the same error as above. I'm guessing something changed in the conventions for subsystem initialization. If someone can give me a quick summary of what to change, I'll try to fix it. Otherwise I'll grovel through the 2.2.18pre patches and try to figure out what to do myself, but I'm not looking forward to that option... Thanks in advance, Doug - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
