Re: Kernel SCM saga.. (bk license?)
On Tue, 12 Apr 2005, Kedar Sovani wrote: >I was wondering if working on git, is in anyway, in violation of the >Bitkeeper license, which states that you cannot work on any other SCM >(SCM-like?) tool for "x" amount of time after using Bitkeeper ? Technically, yes, it is. However, as BitMover has given the community little other choice, I don't see how they could hold anyone to it. They'd have a hard time making that 1year clause stick given their abandonment of the free product and refusal to grant licenses to OSDL employees. Plus, there's nothing in the bkl specifically granting BitMover the right to revoke the license and thus use of BK/Free at their whim. They have every right to stop developing, supporting, and distributing BK/Free, but recending all BK/Free licenses just for spite does not appear to be within their legal rights. (Sorry Larry, but that's what you're doing. Tridge was working on taking your toys apart -- he does that, what can I say. He explicitly lied and said he would stop, but of course didn't. And then you got all pissed at OSDL for not smiting him when, technically, they can't -- an employer is not responsible for the actions of their employees on their own time, on their own property, unrelated to their employ. Sorry, but I know that one by heart :-)) --Ricky - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Digi Neo 8: linux-2.6.12_r2 jsm driver
On Tue, 12 Apr 2005, Christoph Hellwig wrote: >On Tue, Apr 12, 2005 at 10:30:19AM -0500, Kilau, Scott wrote: >> However, when the copyright holder says "No, please don't add that >> code", >> and gives *GOOD* reasons why, you should respect that decision. > >You didn't not give a single good reason. Only political bullshit. As an outside observer, I think he's given you plenty of reason to not include this "hack". You, however, appear to only want to make a mess. >> So if I don't sign off on this change, does the matter? > >No. Could you possibly be any more of an ass? Don't bother answer that. This is entirely the attitude the denouncers of open source live for. It shows the complete lake of respect for the wishes of the maintainer(s). And it's even worse because, as you and various others state, if it's not in the kernel, it might as well not exist -- OSS, GPL, or not. So, what's the point of maintainers submitting code for inclusion in the kernel if they are going to be ignored the instant it's excepted? And the code's maintainer(s) and/or authors are the only ones that *can* submit new code. On one hand you're honoring their wishes, but then basically ignoring them the instant they "give" you their code. (If it's already GPL'd, there's nothing legally stopping the code from being included in the first place, so why must they ask for and/or ok inclusion? Answer: good will within the community which you are now pissing all over.) Am I the only one with his eyes open here? When I read the first reply from Scott, I was thinking, "why not just make it a config option? What's the big f***ing deal?" Make it a config option with help text pointing people to the "better" driver with improved features and support for that board. Or something as simple as "don't enable this if you're going to use this other dirver." The mere fact that you are unwilling to accept the desires of the maintainers subtracts substantial credability from the entire kernel development process and stands as a powerful deterent to getting manufacturers to submit drivers to the kernel. I'd be interested to hear Linus' take on this BS, but he's busy digging out of the bullshit some other stuborn, self-absorbed nut has buried him under. --Ricky "Kernel hacker for over 10 years" (but we know how much that's worth) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Digi Neo 8: linux-2.6.12_r2 jsm driver
On Tue, 12 Apr 2005, Christoph Hellwig wrote: On Tue, Apr 12, 2005 at 10:30:19AM -0500, Kilau, Scott wrote: However, when the copyright holder says No, please don't add that code, and gives *GOOD* reasons why, you should respect that decision. You didn't not give a single good reason. Only political bullshit. As an outside observer, I think he's given you plenty of reason to not include this hack. You, however, appear to only want to make a mess. So if I don't sign off on this change, does the matter? No. Could you possibly be any more of an ass? Don't bother answer that. This is entirely the attitude the denouncers of open source live for. It shows the complete lake of respect for the wishes of the maintainer(s). And it's even worse because, as you and various others state, if it's not in the kernel, it might as well not exist -- OSS, GPL, or not. So, what's the point of maintainers submitting code for inclusion in the kernel if they are going to be ignored the instant it's excepted? And the code's maintainer(s) and/or authors are the only ones that *can* submit new code. On one hand you're honoring their wishes, but then basically ignoring them the instant they give you their code. (If it's already GPL'd, there's nothing legally stopping the code from being included in the first place, so why must they ask for and/or ok inclusion? Answer: good will within the community which you are now pissing all over.) Am I the only one with his eyes open here? When I read the first reply from Scott, I was thinking, why not just make it a config option? What's the big f***ing deal? Make it a config option with help text pointing people to the better driver with improved features and support for that board. Or something as simple as don't enable this if you're going to use this other dirver. The mere fact that you are unwilling to accept the desires of the maintainers subtracts substantial credability from the entire kernel development process and stands as a powerful deterent to getting manufacturers to submit drivers to the kernel. I'd be interested to hear Linus' take on this BS, but he's busy digging out of the bullshit some other stuborn, self-absorbed nut has buried him under. --Ricky Kernel hacker for over 10 years (but we know how much that's worth) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel SCM saga.. (bk license?)
On Tue, 12 Apr 2005, Kedar Sovani wrote: I was wondering if working on git, is in anyway, in violation of the Bitkeeper license, which states that you cannot work on any other SCM (SCM-like?) tool for x amount of time after using Bitkeeper ? Technically, yes, it is. However, as BitMover has given the community little other choice, I don't see how they could hold anyone to it. They'd have a hard time making that 1year clause stick given their abandonment of the free product and refusal to grant licenses to OSDL employees. Plus, there's nothing in the bkl specifically granting BitMover the right to revoke the license and thus use of BK/Free at their whim. They have every right to stop developing, supporting, and distributing BK/Free, but recending all BK/Free licenses just for spite does not appear to be within their legal rights. (Sorry Larry, but that's what you're doing. Tridge was working on taking your toys apart -- he does that, what can I say. He explicitly lied and said he would stop, but of course didn't. And then you got all pissed at OSDL for not smiting him when, technically, they can't -- an employer is not responsible for the actions of their employees on their own time, on their own property, unrelated to their employ. Sorry, but I know that one by heart :-)) --Ricky - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AT keyboard optional on i386?
On Tue, 29 May 2001, Pavel Roskin wrote: >> You can a few nice tricks with it like plug in two PS/2 keyboards. I >> have this for my home setup. The only thing is make sure you don't >> have both keyboards plugged in when you turn your PC on. I found BIOS >> get confused by two PS/2 keyboards. As you can it is very easy to >> multiplex many keyboards with the above design. I have had 4 different >> keyboards hooked up to my system and functioning at the same time. We >> even got a Sun keyboard to work on a intel box :-) > >That's what we like Linux for. It doesn't get confused when everything >else does :-) Heh, that's funny. I must admit I'd never thought of that. Anyway, the bios gets confused because it's trying to figure out (in a very simple way) where the keyboard and mouse are. It's true there's lots of voodoo in PC BIOSes; keyboard/mouse detection isn't one of them. (As I recall, I have to have something in the port to get it enabled. Linux doesn't seem to know how to enable it.) --Ricky - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AT keyboard optional on i386?
On Tue, 29 May 2001, Pavel Roskin wrote: You can a few nice tricks with it like plug in two PS/2 keyboards. I have this for my home setup. The only thing is make sure you don't have both keyboards plugged in when you turn your PC on. I found BIOS get confused by two PS/2 keyboards. As you can it is very easy to multiplex many keyboards with the above design. I have had 4 different keyboards hooked up to my system and functioning at the same time. We even got a Sun keyboard to work on a intel box :-) That's what we like Linux for. It doesn't get confused when everything else does :-) Heh, that's funny. I must admit I'd never thought of that. Anyway, the bios gets confused because it's trying to figure out (in a very simple way) where the keyboard and mouse are. It's true there's lots of voodoo in PC BIOSes; keyboard/mouse detection isn't one of them. (As I recall, I have to have something in the port to get it enabled. Linux doesn't seem to know how to enable it.) --Ricky - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.4.5] buz.c won't compile
On Sat, 26 May 2001, Jan Sembera wrote: >i've got a problem compiling drivers/media/video/buz.c as module. When >i'm trying to compile, i get couple of errors: ... Actually, it broke at 2.4.3. Go look at the first change to buz.c from that patch. --Ricky PS: I really hate it when people break "functional" things in the "stable" tree. (functional and stable are both open to debate.) PPS: Yes, I know Linus doesn't bother compling most of the stuff :-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.4.5] buz.c won't compile
On Sat, 26 May 2001, Jan Sembera wrote: i've got a problem compiling drivers/media/video/buz.c as module. When i'm trying to compile, i get couple of errors: ... Actually, it broke at 2.4.3. Go look at the first change to buz.c from that patch. --Ricky PS: I really hate it when people break functional things in the stable tree. (functional and stable are both open to debate.) PPS: Yes, I know Linus doesn't bother compling most of the stuff :-) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [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] 2.4.1 Detects 64 MB RAM, actual 192MB
On Mon, 5 Feb 2001, Ricky Beam wrote: >Interesting... I just checked my machine (2.4.1-SMP) to see it only saw >64MB when it has 256MB. ... >Nothing at all has changed in either the BIOS setup, compiler, etc. All I >did was reboot (and not pay it any attention.) The configuration was the >same (make oldconfig.) Dammit. Ok, all better now. I guess that fruit fly managed to get into more than just the slot-1 connector. We can thank Tyan and AMI for not checking the contents of ESCD nor giving me a way to reset it without nuking CMOS. (It would appear ACPI, when re-enabled, powered the RAID controller down. That makes it Really Hard (tm) to boot.) --Ricky - 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: Matrox Marvell G400
On Mon, 5 Feb 2001, Alan Olsen wrote: >The capture features are undocumented and unsupported (to my knowledge). (your knowledge is incorrect.) >As far as I have heard, the Rainbow Runner card is not supported in Linux >and Matrox has no plans of doing it. Unsupported by whom? Matrox? That would assume they support it under Windows (they barely do -- or used to.) However, you are correct in that Matrox has no intentions of creating Linux drivers for the video capture capabilities of the card. And they are not extremely forthcoming with information -- it would appear both MacroVision and DVDCCA have nukes wired into their offices :-) >This is more of a question for the xpert list on xfree86.org. Or the marvel list or the livid list... --Ricky - 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: [BUG] 2.4.1 Detects 64 MB RAM, actual 192MB
On Wed, 31 Jan 2001, Dunlap, Randy wrote: ... Interesting... I just checked my machine (2.4.1-SMP) to see it only saw 64MB when it has 256MB. >From 2.4.0-test5: Linux version 2.4.0-test5-SMP (root@chickenboo) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #12 SMP Thu Aug 10 12:56:38 EDT 2000 BIOS-provided physical RAM map: e820: 0009fc00 @ (usable) e820: 0400 @ 0009fc00 (reserved) e820: 0002 @ 000e (reserved) e820: 0fee @ 0010 (usable) e820: 00018000 @ 0ffe (ACPI data) e820: 8000 @ 0fff8000 (ACPI NVS) e820: 1000 @ fec0 (reserved) e820: 1000 @ fee0 (reserved) e820: 0004 @ fffc (reserved) Scan SMP from c000 for 1024 bytes. Scan SMP from c009fc00 for 1024 bytes. Scan SMP from c00f for 65536 bytes. found SMP MP-table at 000fb560 hm, page 000fb000 reserved twice. hm, page 000fc000 reserved twice. hm, page 000f6000 reserved twice. hm, page 000f7000 reserved twice. On node 0 totalpages: 65504 zone(0): 4096 pages. zone(1): 61408 pages. zone(2): 0 pages. >From 2.4.1: Linux version 2.4.1-SMP (root@chickenboo) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 SMP Tue Jan 30 17:13:07 EST 2001 BIOS-provided physical RAM map: BIOS-e820: 0009fc00 @ (usable) BIOS-e820: 0400 @ 0009fc00 (reserved) BIOS-e820: 0002 @ 000e (reserved) BIOS-e820: 03f0 @ 0010 (usable) BIOS-e820: 1000 @ fec0 (reserved) BIOS-e820: 1000 @ fee0 (reserved) BIOS-e820: 0004 @ fffc (reserved) Scan SMP from c000 for 1024 bytes. Scan SMP from c009fc00 for 1024 bytes. Scan SMP from c00f for 65536 bytes. found SMP MP-table at 000fb560 hm, page 000fb000 reserved twice. hm, page 000fc000 reserved twice. hm, page 000f6000 reserved twice. hm, page 000f7000 reserved twice. On node 0 totalpages: 16384 zone(0): 4096 pages. zone(1): 12288 pages. zone(2): 0 pages. Nothing at all has changed in either the BIOS setup, compiler, etc. All I did was reboot (and not pay it any attention.) The configuration was the same (make oldconfig.) --Ricky - 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: [BUG] 2.4.1 Detects 64 MB RAM, actual 192MB
On Wed, 31 Jan 2001, Dunlap, Randy wrote: ... Interesting... I just checked my machine (2.4.1-SMP) to see it only saw 64MB when it has 256MB. From 2.4.0-test5: Linux version 2.4.0-test5-SMP (root@chickenboo) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #12 SMP Thu Aug 10 12:56:38 EDT 2000 BIOS-provided physical RAM map: e820: 0009fc00 @ (usable) e820: 0400 @ 0009fc00 (reserved) e820: 0002 @ 000e (reserved) e820: 0fee @ 0010 (usable) e820: 00018000 @ 0ffe (ACPI data) e820: 8000 @ 0fff8000 (ACPI NVS) e820: 1000 @ fec0 (reserved) e820: 1000 @ fee0 (reserved) e820: 0004 @ fffc (reserved) Scan SMP from c000 for 1024 bytes. Scan SMP from c009fc00 for 1024 bytes. Scan SMP from c00f for 65536 bytes. found SMP MP-table at 000fb560 hm, page 000fb000 reserved twice. hm, page 000fc000 reserved twice. hm, page 000f6000 reserved twice. hm, page 000f7000 reserved twice. On node 0 totalpages: 65504 zone(0): 4096 pages. zone(1): 61408 pages. zone(2): 0 pages. From 2.4.1: Linux version 2.4.1-SMP (root@chickenboo) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 SMP Tue Jan 30 17:13:07 EST 2001 BIOS-provided physical RAM map: BIOS-e820: 0009fc00 @ (usable) BIOS-e820: 0400 @ 0009fc00 (reserved) BIOS-e820: 0002 @ 000e (reserved) BIOS-e820: 03f0 @ 0010 (usable) BIOS-e820: 1000 @ fec0 (reserved) BIOS-e820: 1000 @ fee0 (reserved) BIOS-e820: 0004 @ fffc (reserved) Scan SMP from c000 for 1024 bytes. Scan SMP from c009fc00 for 1024 bytes. Scan SMP from c00f for 65536 bytes. found SMP MP-table at 000fb560 hm, page 000fb000 reserved twice. hm, page 000fc000 reserved twice. hm, page 000f6000 reserved twice. hm, page 000f7000 reserved twice. On node 0 totalpages: 16384 zone(0): 4096 pages. zone(1): 12288 pages. zone(2): 0 pages. Nothing at all has changed in either the BIOS setup, compiler, etc. All I did was reboot (and not pay it any attention.) The configuration was the same (make oldconfig.) --Ricky - 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: Matrox Marvell G400
On Mon, 5 Feb 2001, Alan Olsen wrote: The capture features are undocumented and unsupported (to my knowledge). (your knowledge is incorrect.) As far as I have heard, the Rainbow Runner card is not supported in Linux and Matrox has no plans of doing it. Unsupported by whom? Matrox? That would assume they support it under Windows (they barely do -- or used to.) However, you are correct in that Matrox has no intentions of creating Linux drivers for the video capture capabilities of the card. And they are not extremely forthcoming with information -- it would appear both MacroVision and DVDCCA have nukes wired into their offices :-) This is more of a question for the xpert list on xfree86.org. Or the marvel list or the livid list... --Ricky - 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: [BUG] 2.4.1 Detects 64 MB RAM, actual 192MB
On Mon, 5 Feb 2001, Ricky Beam wrote: Interesting... I just checked my machine (2.4.1-SMP) to see it only saw 64MB when it has 256MB. ... Nothing at all has changed in either the BIOS setup, compiler, etc. All I did was reboot (and not pay it any attention.) The configuration was the same (make oldconfig.) Dammit. Ok, all better now. I guess that fruit fly managed to get into more than just the slot-1 connector. We can thank Tyan and AMI for not checking the contents of ESCD nor giving me a way to reset it without nuking CMOS. (It would appear ACPI, when re-enabled, powered the RAID controller down. That makes it Really Hard (tm) to boot.) --Ricky - 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: Dual XEON - >>SLOW<< on SMP
On Fri, 3 Nov 2000, bert hubert wrote: >> Thanks! That patch did the trick - our machine is now running lovely. > >Your very rare problem was solved in 3 hours and 50 minutes. Most commercial >support shops try and fail to deliver 4 hour response times - this makes me >feel warm inside :-) To be fair, the _problem_ wasn't solved in under 4 hours. He was given an answer to a known problem in less than 4 hours. However, you are correct in implying linux support is, in many respects, far better than that of any commercial OS. Anyone tried explaining to Microsoft or Sun that something is broken? They both immidiately assume you are an idiot (I;m sure that's true more offen than not) and proceed with an attitude of "how dare you suggest our OS is broken." --Ricky - 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: Dual XEON - SLOW on SMP
On Fri, 3 Nov 2000, bert hubert wrote: Thanks! That patch did the trick - our machine is now running lovely. Your very rare problem was solved in 3 hours and 50 minutes. Most commercial support shops try and fail to deliver 4 hour response times - this makes me feel warm inside :-) To be fair, the _problem_ wasn't solved in under 4 hours. He was given an answer to a known problem in less than 4 hours. However, you are correct in implying linux support is, in many respects, far better than that of any commercial OS. Anyone tried explaining to Microsoft or Sun that something is broken? They both immidiately assume you are an idiot (I;m sure that's true more offen than not) and proceed with an attitude of "how dare you suggest our OS is broken." Insert stories about USR here. I was just dealing with RADIUS. God help us if their modem code looks like that crap. --Ricky - 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: syslog() blocks on glibc 2.1.3 with kernel 2.2.x
On Thu, 26 Oct 2000, Igmar Palsenberg wrote: >> Per chance are you running the name service caching daemon (nscd)? I'd >> also guess you aren't disabling fsync() for your sysylog files (it's part >> of the syslog.conf format) -- this is a conciderable drain on syslogd. > >Agree. It is there for a reason : I case the system hangs, you at least >get the last messages. But it is indeed a major drain. I've send Patrick a >small path that makes reverse lookups a config option. Sadly, you WILL still lose entries if the system crashes before fs metadata has been flushed to disk. Unless the inode has the correct size stored, the crap fsync()ed to disk doesn't make much difference. (This is amplified by dcache.) --Ricky - 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: syslog() blocks on glibc 2.1.3 with kernel 2.2.x
On Thu, 26 Oct 2000, Igmar Palsenberg wrote: Per chance are you running the name service caching daemon (nscd)? I'd also guess you aren't disabling fsync() for your sysylog files (it's part of the syslog.conf format) -- this is a conciderable drain on syslogd. Agree. It is there for a reason : I case the system hangs, you at least get the last messages. But it is indeed a major drain. I've send Patrick a small path that makes reverse lookups a config option. Sadly, you WILL still lose entries if the system crashes before fs metadata has been flushed to disk. Unless the inode has the correct size stored, the crap fsync()ed to disk doesn't make much difference. (This is amplified by dcache.) --Ricky - 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: syslog() blocks on glibc 2.1.3 with kernel 2.2.x
On 23 Oct 2000, Patrick J. LoPresti wrote: >Once the name resolution times out, you might expect things to become >unstuck. But they don't. Negative. Things have been queued. The deadlock will only go away if the very next message processed is the named local message. And then it would have to process a few more local messages so it wouldn't stall again so soon. >> Per chance are you running the name service caching daemon (nscd)? > >No. Please do. That will reduce the ammount of traffic to the name server. >> I'd also guess you aren't disabling fsync() for your sysylog files >> (it's part of the syslog.conf format) -- this is a conciderable >> drain on syslogd. > >I see no documentation for such an option in the syslog.conf man page. >This is with the current Red Hat 6.2 syslogd (package >sysklogd-1.3.31-17). It's in the syslogd and syslog.conf man page (sysklogd-1.3.31-16): (syslog.conf) Regular File Typically messages are logged to real files. The file has to be specified with full pathname, beginning with a slash ``/''. You may prefix each entry with the minus ``-'' sign to omit syncing the file after every logging. Note that you might lose information if the system crashes right behind a write attempt. Nevertheless this might give you back some performance, especially if you run programs that use logging in a very verbose manner. --Ricky PS: as a side note, you can/will lose information even if sync is enabled. (fsync() will not flush metadata so the file is truncated on restart.) - 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: syslog() blocks on glibc 2.1.3 with kernel 2.2.x
On 23 Oct 2000, Patrick J. LoPresti wrote: >So I have the glibc maintainer (and others) saying that syslog >messages should never be dropped, and you saying that named should be >dropping its syslog messages. No, I didn't say they "should" be dropped but merely that dropping them would fix your problem. Personally, I'd look closely at your setup to determine exactly why this has become a problem. named is being blocked on writing to /dev/log. This should only happen if there is sufficient _local_ syslog traffic to fill the buffer or syslogd has too much remote traffic to ever read from /dev/log. Per chance are you running the name service caching daemon (nscd)? I'd also guess you aren't disabling fsync() for your sysylog files (it's part of the syslog.conf format) -- this is a conciderable drain on syslogd. --Ricky - 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: syslog() blocks on glibc 2.1.3 with kernel 2.2.x
On 23 Oct 2000, Patrick J. LoPresti wrote: >Turning down the DNS timeout would affect *all* name resolution on the >system, right? That is not acceptable. You should be able to set it on a per-process basis (via an ENV var.) >As I said, I already have a workaround, which is to have named log to >a flat file. I agree that this is a poor workaround, and the "right >fix" is to modify syslogd not to perform blocking operations. My only >quibble is that SOCK_DGRAM is an odd transport to use here, even over >AF_UNIX. syslogd isn't the blocker. The syslog functions in glibc being called by named are the problem. Stop named from blocking on syslog writes and the world will be happy again. I've gotta ask what kind of "load" can cause this to happen. And for the record, syslogd shouldn't be doing DNS lookups for things arriving via /dev/log -- that's always the local machine. --Ricky - 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: syslog() blocks on glibc 2.1.3 with kernel 2.2.x
On 23 Oct 2000, Patrick J. LoPresti wrote: >Ulrich Drepper <[EMAIL PROTECTED]> writes: >> If anything has to be changed it's (as suggested) the configuration >> or even the implementation of syslogd. Make it robust. > >OK, but my current syslogd only listens to /dev/log as a SOCK_DGRAM. >If I wanted reliable syslogging, it would be listening on it as a >SOCK_STREAM. Maybe I care more about performance and backwards >compatibility than reliable syslogging. But whatever my reasons, my >connection to syslogd is already unreliable and therefore *should not >block*. You obviously don't understand the communication channel being used. "/dev/log" is a UNIX DOMAIN SOCKET -- AF_UNIX. Datagrams are unreliable for _IP_ (AF_INET). Traffic on an AF_UNIX socket is always reliable. Ok, smarty, go change the syslogd source to open /dev/log as SOCK_STREAM and watch it fail. (syslog wasn't invented yesturday.) I would suggest disabling name resolution for syslog, but that's an ugly option. There's no way to stop a glibc system from doing a DNS query for a reverse lookup. HOWEVER, you can set the DNS timeout to 1 second and set the resolver options to prevent recursion (answer from cache only.) --Ricky PS: Technically, this is not a lockup. syslogd should eventually timeout waiting for the DNS query and go about it's business. Of course, that may be upwards of 45 seconds -- very annoying. - 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: syslog() blocks on glibc 2.1.3 with kernel 2.2.x
On 23 Oct 2000, Patrick J. LoPresti wrote: Ulrich Drepper [EMAIL PROTECTED] writes: If anything has to be changed it's (as suggested) the configuration or even the implementation of syslogd. Make it robust. OK, but my current syslogd only listens to /dev/log as a SOCK_DGRAM. If I wanted reliable syslogging, it would be listening on it as a SOCK_STREAM. Maybe I care more about performance and backwards compatibility than reliable syslogging. But whatever my reasons, my connection to syslogd is already unreliable and therefore *should not block*. You obviously don't understand the communication channel being used. "/dev/log" is a UNIX DOMAIN SOCKET -- AF_UNIX. Datagrams are unreliable for _IP_ (AF_INET). Traffic on an AF_UNIX socket is always reliable. Ok, smarty, go change the syslogd source to open /dev/log as SOCK_STREAM and watch it fail. (syslog wasn't invented yesturday.) I would suggest disabling name resolution for syslog, but that's an ugly option. There's no way to stop a glibc system from doing a DNS query for a reverse lookup. HOWEVER, you can set the DNS timeout to 1 second and set the resolver options to prevent recursion (answer from cache only.) --Ricky PS: Technically, this is not a lockup. syslogd should eventually timeout waiting for the DNS query and go about it's business. Of course, that may be upwards of 45 seconds -- very annoying. - 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: syslog() blocks on glibc 2.1.3 with kernel 2.2.x
On 23 Oct 2000, Patrick J. LoPresti wrote: Turning down the DNS timeout would affect *all* name resolution on the system, right? That is not acceptable. You should be able to set it on a per-process basis (via an ENV var.) As I said, I already have a workaround, which is to have named log to a flat file. I agree that this is a poor workaround, and the "right fix" is to modify syslogd not to perform blocking operations. My only quibble is that SOCK_DGRAM is an odd transport to use here, even over AF_UNIX. syslogd isn't the blocker. The syslog functions in glibc being called by named are the problem. Stop named from blocking on syslog writes and the world will be happy again. I've gotta ask what kind of "load" can cause this to happen. And for the record, syslogd shouldn't be doing DNS lookups for things arriving via /dev/log -- that's always the local machine. --Ricky - 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: syslog() blocks on glibc 2.1.3 with kernel 2.2.x
On 23 Oct 2000, Patrick J. LoPresti wrote: So I have the glibc maintainer (and others) saying that syslog messages should never be dropped, and you saying that named should be dropping its syslog messages. No, I didn't say they "should" be dropped but merely that dropping them would fix your problem. Personally, I'd look closely at your setup to determine exactly why this has become a problem. named is being blocked on writing to /dev/log. This should only happen if there is sufficient _local_ syslog traffic to fill the buffer or syslogd has too much remote traffic to ever read from /dev/log. Per chance are you running the name service caching daemon (nscd)? I'd also guess you aren't disabling fsync() for your sysylog files (it's part of the syslog.conf format) -- this is a conciderable drain on syslogd. --Ricky - 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: syslog() blocks on glibc 2.1.3 with kernel 2.2.x
On 23 Oct 2000, Patrick J. LoPresti wrote: Once the name resolution times out, you might expect things to become unstuck. But they don't. Negative. Things have been queued. The deadlock will only go away if the very next message processed is the named local message. And then it would have to process a few more local messages so it wouldn't stall again so soon. Per chance are you running the name service caching daemon (nscd)? No. Please do. That will reduce the ammount of traffic to the name server. I'd also guess you aren't disabling fsync() for your sysylog files (it's part of the syslog.conf format) -- this is a conciderable drain on syslogd. I see no documentation for such an option in the syslog.conf man page. This is with the current Red Hat 6.2 syslogd (package sysklogd-1.3.31-17). It's in the syslogd and syslog.conf man page (sysklogd-1.3.31-16): (syslog.conf) Regular File Typically messages are logged to real files. The file has to be specified with full pathname, beginning with a slash ``/''. You may prefix each entry with the minus ``-'' sign to omit syncing the file after every logging. Note that you might lose information if the system crashes right behind a write attempt. Nevertheless this might give you back some performance, especially if you run programs that use logging in a very verbose manner. --Ricky PS: as a side note, you can/will lose information even if sync is enabled. (fsync() will not flush metadata so the file is truncated on restart.) - 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: TRACED] Re: "Tux" is the wrong logo for Linux
On Thu, 19 Oct 2000, Richard B. Johnson wrote: >Cary, NC. can't be very large. There are, probably, three persons in Why "can't" it? Just because it's in NC and not CA? Even CA has it's sparse areas (ok, maybe that's "a sparse area" now-a-days.) FYI, most of Cary is a townhouse/strip mall meca. It has always been my opinion the Cary city planners have never seen much less played SimCity. >the whole county than have computers. Two haven't been booted since If that were really true, then the world is in trouble... one of Cisco's largest offices is here. Nortel has a large footprint as well. (You should know better anyway as RedHat's offices are near Cary.) "We ain't all stewpid." --Ricky - 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: TRACED] Re: Tux is the wrong logo for Linux
On Thu, 19 Oct 2000, Richard B. Johnson wrote: Cary, NC. can't be very large. There are, probably, three persons in Why "can't" it? Just because it's in NC and not CA? Even CA has it's sparse areas (ok, maybe that's "a sparse area" now-a-days.) FYI, most of Cary is a townhouse/strip mall meca. It has always been my opinion the Cary city planners have never seen much less played SimCity. the whole county than have computers. Two haven't been booted since If that were really true, then the world is in trouble... one of Cisco's largest offices is here. Nortel has a large footprint as well. (You should know better anyway as RedHat's offices are near Cary.) "We ain't all stewpid." --Ricky - 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: failure to blank CDRWs (2.2.18pre15 smp ide-scsi hp7100i)
On Mon, 16 Oct 2000, Alan Cox wrote: >> Umm, doesn't cdrecord know how to address IDE devices directly? > >IDE cd burners talk ATAPI. ATAPI is just a scsi variant. SCSI won the battle >at the protocol level ... Yeah yeah yeah. What I meant was "you don't have to use ide-scsi." However, after reading the notes for the latest cdrecord, it does use ide-scsi. In theory, it doesn't _have_ to as you can send packet commands directly to CD-ROM devices (ide disks and floppies, saddly cannot -- how the f*** am I supposed to format a floppy?) There are specific notes about the HP 7100 drives not working corectly due to bad command translations. That was supposed to have been fixed years ago. --Ricky - 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: failure to blank CDRWs (2.2.18pre15 smp ide-scsi hp7100i)
On Mon, 16 Oct 2000, Alan Cox wrote: >> is in cdrecord itself, since I have seen that if the FIFO ever hits 0% >> during CD burning, cdrecord has a tendency to bomb. =20 > >If you empty the fifo and the drive fifo you burn a coaster. Thats a feature >of CD burning and one reason I use 640Mb magneto opticals for testing CD >stuff Not entirely... there's a patented little thing called "BurnProof" that allows the drive to continue burning after exhausting the buffer. And if you look at the error most (some?) CD burners send on buffer underflow, the error is "correctable". (Nothing ever _does_ correct it, tho') >Its a message from the drive politely requesting cd-record to talk valid >commands. But as ide-scsi touches some commands (remapping old ones that are >not supported on ATAPI) its possible to be kernel Umm, doesn't cdrecord know how to address IDE devices directly? --Ricky - 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: failure to blank CDRWs (2.2.18pre15 smp ide-scsi hp7100i)
On Mon, 16 Oct 2000, Alan Cox wrote: is in cdrecord itself, since I have seen that if the FIFO ever hits 0% during CD burning, cdrecord has a tendency to bomb. =20 If you empty the fifo and the drive fifo you burn a coaster. Thats a feature of CD burning and one reason I use 640Mb magneto opticals for testing CD stuff Not entirely... there's a patented little thing called "BurnProof" that allows the drive to continue burning after exhausting the buffer. And if you look at the error most (some?) CD burners send on buffer underflow, the error is "correctable". (Nothing ever _does_ correct it, tho') Its a message from the drive politely requesting cd-record to talk valid commands. But as ide-scsi touches some commands (remapping old ones that are not supported on ATAPI) its possible to be kernel Umm, doesn't cdrecord know how to address IDE devices directly? --Ricky - 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: failure to blank CDRWs (2.2.18pre15 smp ide-scsi hp7100i)
On Mon, 16 Oct 2000, Alan Cox wrote: Umm, doesn't cdrecord know how to address IDE devices directly? IDE cd burners talk ATAPI. ATAPI is just a scsi variant. SCSI won the battle at the protocol level ... Yeah yeah yeah. What I meant was "you don't have to use ide-scsi." However, after reading the notes for the latest cdrecord, it does use ide-scsi. In theory, it doesn't _have_ to as you can send packet commands directly to CD-ROM devices (ide disks and floppies, saddly cannot -- how the f*** am I supposed to format a floppy?) There are specific notes about the HP 7100 drives not working corectly due to bad command translations. That was supposed to have been fixed years ago. --Ricky - 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: Compiling Ricky Beam's patched dpt_i2o.c into the kernel in2.4.0.0-21
On Thu, 28 Sep 2000, Nick Loman wrote: >I'm trying to compile in Ricky Beam's patched dpt_i2o.c file (for DPT >SmartRAID V support) into the kernel. I got it working as a module, but >now I want it compiled directly in. I run with it compiled in (I boot from the SR-V.) I've put diffs for 2.4.0-test5 and 2.4.0-test7 up. That's exactly what I'm running. The .config (config.cramer) is in there for reference. >The problem I have is that at link stage (make bzImage) it is complaining >about undefined references to many simple functions such as printk() and >sprintf(). This is a configuration mismatch. It's looking for versioned symbols. Do you have module versioning enabled? Did you rerun "make dep" after changing from a module to built-in? --Ricky - 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: Compiling Ricky Beam's patched dpt_i2o.c into the kernel in2.4.0.0-21
On Thu, 28 Sep 2000, Nick Loman wrote: I'm trying to compile in Ricky Beam's patched dpt_i2o.c file (for DPT SmartRAID V support) into the kernel. I got it working as a module, but now I want it compiled directly in. I run with it compiled in (I boot from the SR-V.) I've put diffs for 2.4.0-test5 and 2.4.0-test7 up. That's exactly what I'm running. The .config (config.cramer) is in there for reference. The problem I have is that at link stage (make bzImage) it is complaining about undefined references to many simple functions such as printk() and sprintf(). This is a configuration mismatch. It's looking for versioned symbols. Do you have module versioning enabled? Did you rerun "make dep" after changing from a module to built-in? --Ricky - 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: DPT SmartRAID V and Linux 2.4-
On Mon, 25 Sep 2000, Nick Loman wrote: >So as far as I can tell, the i2o stack in Linux 2.4 doesn't support the >DPT SmartRAID V i2o controller. "We know." It never has. (and arguablly never will.) >Am I right in thinking then the only option is to combine DPT's drivers >into the kernel by hand? Is this feasible/easy to do, or better, has >someone already done it? If "by hand" means with 'patch', then yes. Some people have no problem and others commit suicide as a result of the process. (YMWV.) Getting the DPT supplied driver to work in 2.3 will require some work -- spinlock semantics and the scsi host structure changed. I'm running a SRV in my system with 2.4.0-test5 right now, so it is doable. (http://chickenboo.bluetopia.net/~jfbeam/DPT/) --Ricky - 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: DPT SmartRAID V and Linux 2.4-
On Mon, 25 Sep 2000, Nick Loman wrote: So as far as I can tell, the i2o stack in Linux 2.4 doesn't support the DPT SmartRAID V i2o controller. "We know." It never has. (and arguablly never will.) Am I right in thinking then the only option is to combine DPT's drivers into the kernel by hand? Is this feasible/easy to do, or better, has someone already done it? If "by hand" means with 'patch', then yes. Some people have no problem and others commit suicide as a result of the process. (YMWV.) Getting the DPT supplied driver to work in 2.3 will require some work -- spinlock semantics and the scsi host structure changed. I'm running a SRV in my system with 2.4.0-test5 right now, so it is doable. (http://chickenboo.bluetopia.net/~jfbeam/DPT/) --Ricky - 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: Sol 8 Sparc / Linux 2.2.17 TCP interoperability problems
On Sat, 23 Sep 2000, Horst von Brand wrote: >Some other funny stuf is happening, I'll try on monday without NFSv3 in >kernel, and mounting from the PC. I will add, Solaris ignores the capabilities of mountd and will attempt an NFSv3 connection if it sees a v3 nfsd registered. You can tell mountd to not register for v3, but knfsd registers everything it knows. BTW, Solaris 8 is likely attempting to use web-nfs -- even if you tell it not to. --Ricky - 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: Sol 8 Sparc / Linux 2.2.17 TCP interoperability problems
On Sat, 23 Sep 2000, Horst von Brand wrote: Some other funny stuf is happening, I'll try on monday without NFSv3 in kernel, and mounting from the PC. I will add, Solaris ignores the capabilities of mountd and will attempt an NFSv3 connection if it sees a v3 nfsd registered. You can tell mountd to not register for v3, but knfsd registers everything it knows. BTW, Solaris 8 is likely attempting to use web-nfs -- even if you tell it not to. --Ricky - 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: Question: Using floating point in the kernel
On Wed, 20 Sep 2000, Lyle Coder wrote: >You cannot use MMX registers in the kernel either, since the kernel doesen't >save and restore FX state (fxsave, fxrstor) either (just like >(fsave/frstor). You might want to tell the software RAID maintainers that... RAID5 CRC calculations can be done with MMX. (I'm sure they save and restore the FPU state, however. Yes, the save/restore cycle is _damned_ expensive.) --Ricky - 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: Question: Using floating point in the kernel
On Wed, 20 Sep 2000, Lyle Coder wrote: You cannot use MMX registers in the kernel either, since the kernel doesen't save and restore FX state (fxsave, fxrstor) either (just like (fsave/frstor). You might want to tell the software RAID maintainers that... RAID5 CRC calculations can be done with MMX. (I'm sure they save and restore the FPU state, however. Yes, the save/restore cycle is _damned_ expensive.) --Ricky - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: RAID HW Questions...
On Sun, 17 Sep 2000, Bryan Whitehead wrote: >A guy in the down under (.au) sent me this driver. Aparently Adaptec >developes their OpenSource driver privatly and only gives out copies to >"special" customers. You've never had to deal with Adaptec. I'd rather build my own SCSI controller out of transisters than deal with those [censored]. I used to have the respect for DPT. Well, there's one more fine company ruined. >It works in 2.2.16 and 2.2.17 :)) 6 months of hell has come (mostly) to >an end. The published 1.09 driver works as well with a bit of hand holding. The root problem is that you don't know what to do to get it working. There's nothing wrong with that aside from you storming into lkml as if you knew what you were doing (your little "resumette") but couldn't get anything to work "for 6 months." [2.2.15 was the latest kernel six months ago. The 1.09 driver from DPT drops directly into 2.2.15 without modification.] Has anyone thought about including the DPT I2O driver in the main kernel? The license in the files don't preclude doing this. Yeah, I'm more than aware of the source code being "b-slapped ugly", but then we wouldn't have to deal with Adaptec screwing all of DPT's customers. --Ricky PS: I'd really like to see the native I2O drivers running this card. (I'd need another card to continue development as my only system with a SRV is "live".) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: RAID HW Questions...
On Sun, 17 Sep 2000, Alan Cox wrote: >> It might be a problem for places like Redhat, Suse, etc. that sell linux >> distributions. Of course, the GPL has the same clause and no one's had >> a problem with selling linux distributions so far. > >The GPL allows commercial sale. I threw the i2o sig stuff at real lawyers >and they said 'avoid' - so I did Hah! When was this? The SIG has changed their "rules" over the years. I remember when you had to pay 5k$US to see the "specs" (it was like 15k$US for the tar file of headers.) Back then, you weren't even allowed to say "I2O" without permission. Personally, I think I2O is a good idea. The I2O SIG's execution, however, leaves everything to be desired. (Kind of reminds me of MPEG.) --Ricky - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: RAID HW Questions...
On Sun, 17 Sep 2000, Alan Cox wrote: >> Has anyone thought about including the DPT I2O driver in the main kernel? >> The license in the files don't preclude doing this. Yeah, I'm more than > >They do. The i2o headers can only be distributed by someone who is an >i2o sig member. Have you read the headers to the .../i2o/*.h files DPT provided? Sounds clear to me: + * I2O SIG grants the user of this header file a license to copy, distribute, + * and modify it, for any purpose, under the following terms. Any copying, + * distribution, or modification of this header file must not delete or alter + * the copyright notice of I2O SIG or any of these Terms and Conditions. ... It goes on to stipluate no "selling" the headers, leave the I2O SIG copyright and license terms intact, mark what has been changed from the I2O SIG's, etc. No where does it say I cannot distribute those headers as is or with modifications. I know there are (or were) restriction on distributing the I2O headers directly from I2O. I haven't cared to read the terms in the last few years. (What kind of idiot writes specs without numbers in them?) --Ricky - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: RAID HW Questions...
On Sun, 17 Sep 2000, Alan Cox wrote: >They do. The i2o headers can only be distributed by someone who is an >i2o sig member. Ah, here's the magic clause: + * This information is provided for the purpose of recompilation of the + * driver code provided by Distributed Processing Technology only. It is + * NOT to be used for any other purpose. + * + * To develop other products based upon I2O definitions, it is necessary to + * become a "Registered Developer" of the I2O SIG. This can be done by calling + * 415-750-8352 in the US, or via http://www.i2osig.org. (and only i2odep.h has that clause. And it's a 1998 I2O version. Version 1.5.1 of the header files changed the "disclaimer" (read: license)) --Ricky - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: RAID HW Questions...
On Sun, 17 Sep 2000, Alan Cox wrote: >> It goes on to stipluate no "selling" the headers, leave the I2O SIG copyright > >Selling covers distributing for money. I've been talking to them about using >the linux/i2o.h headers which are not so encumbered but heard nothing for >a month or so now (well, DPT doesn't exist anymore and we all know how talkative Adaptec isn't) Last time I checked my bank accounts, I wasn't making any money from supporting linux. Of course, I'm a registered I2O developer. And, the I2O SIG has alot of money to use in chasing after people. It might be a problem for places like Redhat, Suse, etc. that sell linux distributions. Of course, the GPL has the same clause and no one's had a problem with selling linux distributions so far. --Ricky - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: RAID HW Questions...
On Sun, 17 Sep 2000, Bryan Whitehead wrote: A guy in the down under (.au) sent me this driver. Aparently Adaptec developes their OpenSource driver privatly and only gives out copies to "special" customers. You've never had to deal with Adaptec. I'd rather build my own SCSI controller out of transisters than deal with those [censored]. I used to have the respect for DPT. Well, there's one more fine company ruined. It works in 2.2.16 and 2.2.17 :)) 6 months of hell has come (mostly) to an end. The published 1.09 driver works as well with a bit of hand holding. The root problem is that you don't know what to do to get it working. There's nothing wrong with that aside from you storming into lkml as if you knew what you were doing (your little "resumette") but couldn't get anything to work "for 6 months." [2.2.15 was the latest kernel six months ago. The 1.09 driver from DPT drops directly into 2.2.15 without modification.] Has anyone thought about including the DPT I2O driver in the main kernel? The license in the files don't preclude doing this. Yeah, I'm more than aware of the source code being "b-slapped ugly", but then we wouldn't have to deal with Adaptec screwing all of DPT's customers. --Ricky PS: I'd really like to see the native I2O drivers running this card. (I'd need another card to continue development as my only system with a SRV is "live".) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: RAID HW Questions...
On Sat, 16 Sep 2000, Bryan Whitehead wrote: >> Have you bothered tell us what that error is? I've not seen anything on >> dpt's mail-list. (Which is where this should be discussed.) > >I've emailed [EMAIL PROTECTED] (that's what the linuxi2oreadme.txt says to >do for help) MANY times pleading for help. i asked for Phone#'s, web >pages, ftp sites, and yes email lists. I've yet to get a reply in 6 months >of asking. Gez, Adaptec has made a fscking mess out of this -- I knew those *sses would. >> Yes they do. You just are talking to the right people. (Maybe those "right >> people" aren't there anymore. DPT is now an Adaptec company, remember.) > >If I can call and email for 6 months and never get a reply that means they >DON'T care in my book. ([EMAIL PROTECTED] is the mail list, btw) The people I talked to in April: "Salyzyn, Mark" <[EMAIL PROTECTED]> "Tran, Huy" <[EMAIL PROTECTED]> At the time, they had someone "starting on monday" to handle the linux driver. I guess they never made it to work that Monday :-) >> I'm the one who made it work at 2.3.33... I sent those changes to DPT and >> mailed several lists. >> >> (http://chickenboo.bluetopia.net/~jfbeam/DPT/) > >Great! What about 2.2.17? ot 2.4.0(test) ? I really don't care much >about 2.3.33. I don't run 2.2. And I showed you the driver (that very 2.3.33 driver) running on 2.4.0-test... I've put a README in there to deal with alot of these questions (and I knew you where gonna bitch about it being 2.3.33) Why are people always to inflexable as to require everything to match up atom to atom (bit for bit) before they will try anything? Did you look at the patches at all? They hardly touch the kernel sources at all. The changes necessary are to the dpt_i2o driver itself. As I've stated in the README, I do not have explicit permission to distribute their driver. >Vendor: DPT Model: PM2554U2 Rev: 211D, scsi 1: First, get the latest firmware (I have no clue where adaptec might have hidden them.) >Q: When attempting to compile my kernel, I am getting lots >of error such as: > drivers/scsi/scsi.a(dpt_i2o.o): In function `dpt_add_timer': > dpt_i2o.o(.text+0x10): undefined reference to > `del_timer_Rsmp_5811f067' >A: This is an error seen when using a compiler newer than gcc 2.7.2. Use > gcc 2.7.2 or older. Right. This is caused by the compiler... *cough*bullshit*cough*. Either del_timer isn't exported or the dpt driver didn't load the right include file. I'll go play with 2.2.17 later. (Some companies have a negative clue level.) >Another wierd thing is even though they have a "patch" for this card they >give instructions to manually edit it a .h file they forgot to include. See above about "clue". --Ricky PS: Ignore the mis-information from Adaptec/DPT. If you're as smart as you should be, you can fix this yourself (assuming you know much about the linux kernel and how it gets built.) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: RAID HW Questions...
On Sat, 16 Sep 2000, Bryan Whitehead wrote: >> The driver should be on DPT's site. Im not sure on the current state with the (The driver _IS_ on DPT's site. It always has been.) >The driver directory is on thier web site. true. But it only works for >specific versions of kernel's from RH. They do have the sources available This is true of _any_ binary module. That's why I never use binary modules. >also. The problem comes when compiling. They specifically say not to use >Linux's i2o stuff. Fine. They claim they have their "own" i2o >implementaion. But it won't build, actually it won;t link. After looking >at the FAQ more they say I need to build with gcc version 2.7.2. Becasue >their driver only works with that. So i remove the gcc from my system and >install an old gcc / linker. no change. Still the same damn error. Have you bothered tell us what that error is? I've not seen anything on dpt's mail-list. (Which is where this should be discussed.) >not like I'm some stupid moron (i wish that were the case then I'd be able ... >development for Mission and Control for NASA's Deep Space network. So i'm (you aren't inspiring any confidence here...) >I need to have at LEAST 2.2.16 for security resons. But they don't give a >crap. Yes they do. You just are talking to the right people. (Maybe those "right people" aren't there anymore. DPT is now an Adaptec company, remember.) >If Linux can get the card working with they native i2o drivers then >great. One of the primary reasons for use the DPT driver is to use the DPT RAID mananger. The Linux I2O code doesn't (currently) have that support. It could be added later, but someone's got to get the card to work with the existing I2O code. (And I'll add the standard warning about SCSI card HW RAID solutions... all of them require mucking about with the SCSI core to prevent command timeouts. In the case of the DPT card, it can take over 2 MINUTES to signal command completion -- my card will queue 210 commands in an instant.) >I'm to the point I don't mind blowing another $10,000 in taxpayers money >to get the fsck'n RAID working in 2.2.17 land and hopefully 2.4 soon. Point of fact: There _are_ people using >2.2.12 with the DPT driver. Point of fact: There _are_ people usin 2.4 with the DPT driver. I'm the one who made it work at 2.3.33... I sent those changes to DPT and mailed several lists. (http://chickenboo.bluetopia.net/~jfbeam/DPT/) [jfbeam:pts/0]chickenboo:~/[2:05pm]:uname -a Linux chickenboo 2.4.0-test5-SMP #13 SMP Thu Aug 24 16:23:36 EDT 2000 i686 unknown [jfbeam:pts/0]chickenboo:~/[2:05pm]:gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/specs gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) [jfbeam:pts/0]chickenboo:~/[2:10pm]:cat /proc/scsi/dpt_i2o/0 Vendor: DPT Model: PM1554U2 Rev: 3013, scsi 0: DPT I2O Driver Version: 1.09.1-cramer/1.2: cmd_per_lun = 210, max_id = 15, max_lun = 7, max_channel = 1 sg_tablesize = 39, irq = 16, OutstandingMsgs = 0 maxfromiopmsgs = 64, maxtoiopmsgs = 210 Devices: Channel = 0, Target = 0, Lun = 0 Channel = 1, Target = 4, Lun = 0 [jfbeam:pts/0]chickenboo:~/[2:11pm]:cat /proc/scsi/scsi Attached devices: Host: scsi0 Channel: 00 Id: 00 Lun: 00 Vendor: DPT Model: CHICKENBOO Rev: 3013 Type: Direct-AccessANSI SCSI revision: 02 Host: scsi0 Channel: 01 Id: 04 Lun: 00 Vendor: SONY Model: SDT-1Rev: 0101 Type: Sequential-AccessANSI SCSI revision: 02 It's currently booting from that controller. The driver also works as a module. >All I gatta say is thier driver is a piece of crap. I'll use Linux's i2o Yes, it's hideous... it was originally a SCO driver. But it works. >If you would like me to try *ANYTHING* out to aid in getting the Card >working I'm all yours. I'm a bit burned out but hell, If you think it's >not that far away. Then who am i to argue? For starters, you can tell us exactly what the hell your problem is. Blow off all the steam you want, but no one can help you until you tell us your specific problem. --Ricky PS: I've had my difficulties with Mylex as well -- as if replacing the RTC battery is going to fix a parity calculation fault in the firmware. They knew damn well that battery had nothing to do with that card crashing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: RAID HW Questions...
On Sat, 16 Sep 2000, Bryan Whitehead wrote: The driver should be on DPT's site. Im not sure on the current state with the (The driver _IS_ on DPT's site. It always has been.) The driver directory is on thier web site. true. But it only works for specific versions of kernel's from RH. They do have the sources available This is true of _any_ binary module. That's why I never use binary modules. also. The problem comes when compiling. They specifically say not to use Linux's i2o stuff. Fine. They claim they have their "own" i2o implementaion. But it won't build, actually it won;t link. After looking at the FAQ more they say I need to build with gcc version 2.7.2. Becasue their driver only works with that. So i remove the gcc from my system and install an old gcc / linker. no change. Still the same damn error. Have you bothered tell us what that error is? I've not seen anything on dpt's mail-list. (Which is where this should be discussed.) not like I'm some stupid moron (i wish that were the case then I'd be able ... development for Mission and Control for NASA's Deep Space network. So i'm (you aren't inspiring any confidence here...) I need to have at LEAST 2.2.16 for security resons. But they don't give a crap. Yes they do. You just are talking to the right people. (Maybe those "right people" aren't there anymore. DPT is now an Adaptec company, remember.) If Linux can get the card working with they native i2o drivers then great. One of the primary reasons for use the DPT driver is to use the DPT RAID mananger. The Linux I2O code doesn't (currently) have that support. It could be added later, but someone's got to get the card to work with the existing I2O code. (And I'll add the standard warning about SCSI card HW RAID solutions... all of them require mucking about with the SCSI core to prevent command timeouts. In the case of the DPT card, it can take over 2 MINUTES to signal command completion -- my card will queue 210 commands in an instant.) I'm to the point I don't mind blowing another $10,000 in taxpayers money to get the fsck'n RAID working in 2.2.17 land and hopefully 2.4 soon. Point of fact: There _are_ people using 2.2.12 with the DPT driver. Point of fact: There _are_ people usin 2.4 with the DPT driver. I'm the one who made it work at 2.3.33... I sent those changes to DPT and mailed several lists. (http://chickenboo.bluetopia.net/~jfbeam/DPT/) [jfbeam:pts/0]chickenboo:~/[2:05pm]:uname -a Linux chickenboo 2.4.0-test5-SMP #13 SMP Thu Aug 24 16:23:36 EDT 2000 i686 unknown [jfbeam:pts/0]chickenboo:~/[2:05pm]:gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/specs gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) [jfbeam:pts/0]chickenboo:~/[2:10pm]:cat /proc/scsi/dpt_i2o/0 Vendor: DPT Model: PM1554U2 Rev: 3013, scsi 0: DPT I2O Driver Version: 1.09.1-cramer/1.2: cmd_per_lun = 210, max_id = 15, max_lun = 7, max_channel = 1 sg_tablesize = 39, irq = 16, OutstandingMsgs = 0 maxfromiopmsgs = 64, maxtoiopmsgs = 210 Devices: Channel = 0, Target = 0, Lun = 0 Channel = 1, Target = 4, Lun = 0 [jfbeam:pts/0]chickenboo:~/[2:11pm]:cat /proc/scsi/scsi Attached devices: Host: scsi0 Channel: 00 Id: 00 Lun: 00 Vendor: DPT Model: CHICKENBOO Rev: 3013 Type: Direct-AccessANSI SCSI revision: 02 Host: scsi0 Channel: 01 Id: 04 Lun: 00 Vendor: SONY Model: SDT-1Rev: 0101 Type: Sequential-AccessANSI SCSI revision: 02 It's currently booting from that controller. The driver also works as a module. All I gatta say is thier driver is a piece of crap. I'll use Linux's i2o Yes, it's hideous... it was originally a SCO driver. But it works. If you would like me to try *ANYTHING* out to aid in getting the Card working I'm all yours. I'm a bit burned out but hell, If you think it's not that far away. Then who am i to argue? For starters, you can tell us exactly what the hell your problem is. Blow off all the steam you want, but no one can help you until you tell us your specific problem. --Ricky PS: I've had my difficulties with Mylex as well -- as if replacing the RTC battery is going to fix a parity calculation fault in the firmware. They knew damn well that battery had nothing to do with that card crashing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: RAID HW Questions...
On Sat, 16 Sep 2000, Bryan Whitehead wrote: Have you bothered tell us what that error is? I've not seen anything on dpt's mail-list. (Which is where this should be discussed.) I've emailed [EMAIL PROTECTED] (that's what the linuxi2oreadme.txt says to do for help) MANY times pleading for help. i asked for Phone#'s, web pages, ftp sites, and yes email lists. I've yet to get a reply in 6 months of asking. Gez, Adaptec has made a fscking mess out of this -- I knew those *sses would. Yes they do. You just are talking to the right people. (Maybe those "right people" aren't there anymore. DPT is now an Adaptec company, remember.) If I can call and email for 6 months and never get a reply that means they DON'T care in my book. ([EMAIL PROTECTED] is the mail list, btw) The people I talked to in April: "Salyzyn, Mark" [EMAIL PROTECTED] "Tran, Huy" [EMAIL PROTECTED] At the time, they had someone "starting on monday" to handle the linux driver. I guess they never made it to work that Monday :-) I'm the one who made it work at 2.3.33... I sent those changes to DPT and mailed several lists. (http://chickenboo.bluetopia.net/~jfbeam/DPT/) Great! What about 2.2.17? ot 2.4.0(test) ? I really don't care much about 2.3.33. I don't run 2.2. And I showed you the driver (that very 2.3.33 driver) running on 2.4.0-test... I've put a README in there to deal with alot of these questions (and I knew you where gonna bitch about it being 2.3.33) Why are people always to inflexable as to require everything to match up atom to atom (bit for bit) before they will try anything? Did you look at the patches at all? They hardly touch the kernel sources at all. The changes necessary are to the dpt_i2o driver itself. As I've stated in the README, I do not have explicit permission to distribute their driver. Vendor: DPT Model: PM2554U2 Rev: 211D, scsi 1: First, get the latest firmware (I have no clue where adaptec might have hidden them.) Q: When attempting to compile my kernel, I am getting lots of error such as: drivers/scsi/scsi.a(dpt_i2o.o): In function `dpt_add_timer': dpt_i2o.o(.text+0x10): undefined reference to `del_timer_Rsmp_5811f067' A: This is an error seen when using a compiler newer than gcc 2.7.2. Use gcc 2.7.2 or older. Right. This is caused by the compiler... *cough*bullshit*cough*. Either del_timer isn't exported or the dpt driver didn't load the right include file. I'll go play with 2.2.17 later. (Some companies have a negative clue level.) Another wierd thing is even though they have a "patch" for this card they give instructions to manually edit it a .h file they forgot to include. See above about "clue". --Ricky PS: Ignore the mis-information from Adaptec/DPT. If you're as smart as you should be, you can fix this yourself (assuming you know much about the linux kernel and how it gets built.) - 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: Proc fs limit workaround?
On Thu, 14 Sep 2000, Nick Pollitt wrote: ... >And second, why is the 4K limit there in the first place? Primarily because it was never designed for 90% of the crap that's in there now. I have long hated the BS required to get more than 4k worth of stuff out of /proc. The way around the limit is not a solution, it's a hack. There's not atomicy for processing more than one page unless you go out of your way to deal with it. I've banged my head on the desk a few times because of this -- what happens when there's any delay between read()'s? *sigh* #ifdef RANT In case you haven't noticed a lot of present-day linux is a nice collection of hacks. This is the nature of code evilution -- I have to deal with this everyday (of course, I'm paid to.) procfs was actually a Very Good Thing(r) six or seven years ago when it was _designed_. Now look at it. I'm a perfectionist. I like things to be well planned, designed, and emplimented to do what they were designed to do. If you want it to do something else, return to the planning stage. For example, 747's weren't designed to clear cut forests. While they can be used for such a task, they are quite inefficient at it. #endif --Ricky - 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: Proc fs limit workaround?
On Thu, 14 Sep 2000, Nick Pollitt wrote: ... And second, why is the 4K limit there in the first place? Primarily because it was never designed for 90% of the crap that's in there now. I have long hated the BS required to get more than 4k worth of stuff out of /proc. The way around the limit is not a solution, it's a hack. There's not atomicy for processing more than one page unless you go out of your way to deal with it. I've banged my head on the desk a few times because of this -- what happens when there's any delay between read()'s? *sigh* #ifdef RANT In case you haven't noticed a lot of present-day linux is a nice collection of hacks. This is the nature of code evilution -- I have to deal with this everyday (of course, I'm paid to.) procfs was actually a Very Good Thing(r) six or seven years ago when it was _designed_. Now look at it. I'm a perfectionist. I like things to be well planned, designed, and emplimented to do what they were designed to do. If you want it to do something else, return to the planning stage. For example, 747's weren't designed to clear cut forests. While they can be used for such a task, they are quite inefficient at it. #endif --Ricky - 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-required!] Recent kernels show problems in handling VERYlarge HDs
On Fri, 8 Sep 2000, Andreas Eibach wrote:
...
>ide0: BM-DMA at 0x4000-0x4007, BIOS settings: hda:pio, hdb:pio
>ide1: BM-DMA at 0x4008-0x400f, BIOS settings: hdc:pio, hdd:pio
...
>hda: 120060864 sectors (61471 MB) w/2048KiB Cache, CHS=7473/255/63, UDMA(33)
> hda:hda: timeout waiting for DMA
>ide_dmaproc: chipset supported ide_dma_timeout func only: 14
>hda: irq timeout: status=0x58 { DriveReady SeekComplete DataRequest }
>hda: status timeout: status=0xd8 { Busy }
...
It would appear the system does know how big the drive is. The big problem
is the DMA failure. The system attempted to use DMA mode when the chipset
wasn't set for DMA mode. Note the "hda:pio" part. Either rebuild the kernel
to disable DMA mode, turn it off by default, or force the BIOS to enable DMA
for that drive. Unfortunately, there's no kernel commandline for turning
DMA off -- you can turn it on, but not off.
Once you fix that, I'm betting everything will work just fine.
--Ricky
PS: I've "hot plugged" this type of drive into running systems. It wasn't
there during POST. DMA has to be disabled as the kernel doesn't appear
to know how or isn't willing to enable DMA mode for the drive. It will,
however, gladly turn it off. (My TiVo hackbed disables DMA to handle
byteswaping.)
-
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: modules_install?
On 8 Sep 2000, Juan J. Quintela wrote: >Could we make it _easy_ to put all the >modules/System.map/bzImage/ in boot/ and make it easy to do >a tar of that directory and make easy to install that dir in another >machine (perhaps puting a tiny Makefile/script there to do that). Well, one can certainly do this. The "make install" dream is just that, a dream. You can set a standard saying the kernel belongs in /boot, but that doesn't mean everyone will put it there. In my opinion, the process of installing a kernel should require a certain IQ from the installer. That means no button for a trained monkey to push. (You would be amazed the mount of shit I've had to clean up following the pushing of that button by a "trained" (huge assumtion) monkey.) --Ricky - 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: modules_install?
On Thu, 7 Sep 2000, Michael Elizabeth Chastain wrote: >> However, NO ONE has taken the time (I'm talking weeks of doing nothing >> but screwing with Makefiles) to completely rewrite the build system. > >I have done exactly that. And how much did RedHat pay you to do it? >And I gave you the URL. You want to read it, or you want to keep whining >that "NO ONE" is doing the work I am pointing you directly to? What you point at and what's in the kernel tree still isn't complete. And it's still a load of hackish crap. Rules.make is still an enormous pile of goo -- highly condition and hard to follow. (Not that it's ever been anything else.) Some of the hackishness is inescapable -- flag tracking for one. The ugly "ifeq ... endif" blocks in Makefiles need to be gone. All of them. Everywhere. NO exceptions. The additional (redundant clone) build rules need to be gone. The "boilerplate" sections should be in one place, not cloned in every Makefile. Actually, they shouldn't be necessary if the "old-style" is gone. I should be able to cd to any directory anywhere in the tree and build anything. (That's always been a toughy.) Shall I continue? >> What's the point in making processors faster if everyone just >> wastes the increase being "correct and simple"? > >I've also benchmarked my Makefiles against the stock kernel Makefiles. >The "correct and simple" Makefiles run in 1/2 the time. Simple corrections to a few places can account for 90% of this speed up simply by correcting the erronious recompliations -- and yes, I fixed those in my source tree long ago. Optimizing the Makefiles certainly make them easier for a human to deal with but doesn't make order of magnitude differences to "make". Try running your benchmark with "make -n" to see the speed of the Makefile processing instead of compilations. (If you really wanna speed up make, then disable all of it's implicit rules and suffix mapping.) >Honestly, it's like talking to a wall here. Rick[y], you don't know what >you're talking about, and you show too much unwillingness to learn. >I'm not interested in your prejudices any more. Oh, I know more than you think I do. Perfection is a hard thing to find. Finding anyone who knows how to actually write a Makefile is just as hard. (Just because I tend to keep my toys to myself is my business.) It is my opinion that one should not tweak, hack, evolve, fix, or even otherwise look at the spooge that has served as the build system for years. Burn it to the ground, bulldoze the asses out of the way, and actually _design_ a _new_ system. Enumerate what functions and requirment there are and build 'em. No "backwards compat."; no hold overs from the days of the Roman Empire; no "new way" and "old way", simply "THE way". Take a lesson from Mother Nature: Forest fires are a Good Thing (tm) --Ricky PS: How the hell did we go from complaining about the "stubby modules tree" to relative speeds of make? I stand by my original comments: one file per directory is no better (worse even) than all files in one directory. - 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: modules_install?
On Thu, 7 Sep 2000, Michael Elizabeth Chastain wrote: >> Well, there's butt-loads of ugly Makefile shit all over the place. It >> isn't going away. > >Some of it went away when Keith Owens rewrote modules-install. Some, but not all. Some of the things necessary/desired for the kernel build requires some ugly "neat hacks" to be put in there. (like the recorded compile flags -- what would be called a configuration record in Clearcase.) >More of it went away between 2.2 and 2.4. Check out drivers/net/Makefile >or drivers/scsi/Makefile or lots of other Makefiles, for instance. >They are 1/3 the size they used to be. Yes, and they _still_ needlessly rebuild somethings every time make is called. >Here's my contribution to making it go away: ... >Where is yours? On my machines. I've stared at the Makefile spooge for a decade, as have a lot of people. However, NO ONE has taken the time (I'm talking weeks of doing nothing but screwing with Makefiles) to completely rewrite the build system. I do not enjoying doing such things even when I _am_ paid to do it. >> (BTW, the current modutils (2.3.15) won't see all the modules from a >> modules_install.) > >Oh? That would be a bug. Which modules does it fail to see? ALL of them. Everything is under subdirs of kernel which depmod isn't scanning. (pcmcia is there by symlinks) >So, go benchmark "insmods per second". I want to see a %age from some >controlled test where the only differences are the module arrangement >and the version of modutils used. > >Then tell us about what use case you have where this metric matters. It's attitudes like that that have made Microsoft products a laughing stock. A millisecond here and there adds up over time. In case you've forgotten, Linux _used_ to run very well on 386 and 486 systems (in the 25 to 50 MHz range.) What's the point in making processors faster if everyone just wastes the increase being "correct and simple"? --Ricky - 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: modules_install?
On Thu, 7 Sep 2000, Michael Elizabeth Chastain wrote: >(1) Rules.make had a load of ugly code to translate from the source tree >to the symlink farm. This code had plenty of bugs and race conditions >(e.g. if two subdirectories have the same MOD_LIST_NAME and make >runs in parallel). > >(2) The top Makefile had a butt-load of even uglier code to translate >from the symlink farm to the install tree. This code needed to >be coordinated with modutils releases. It also suffered from bugs, >such as configuration changes leaving stale files around. Well, there's butt-loads of ugly Makefile shit all over the place. It isn't going away. I'll agree the symlink farm was a bad idea. However, the mass of one file per directory crap is no better an idea. >(3) Module names had to be unique across the entire kernel tree, >which is a silly limitation. Yes and no. You can only insmod _one_ serial.o so the name does have to be unique at the time it's loaded. This is the "serial.o" vs. "usb serial.o" problem. If you need both modules loaded at the same time then they still have to be unique. >So now, the module installation code is simple and correct and doesn't >need to be updated in tandem with modutils every two weeks. WRONG. The current system will be slinging directories left and right. If someone doesn't tell modutils about them, then it doesn't work. There's already been heated arguements about the modutils scaling the directory tree in search of modules. It was generally conceeded to be a bad idea. (BTW, the current modutils (2.3.15) won't see all the modules from a modules_install.) >From an efficiency standpoint, one file per directory is a hideous waste of both filesystem space (one inode and one block) and system resources (file access times, dcache, et. al.) --Ricky - 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/
modules_install?
What's the point of running depmod at the end of modules_install? The System.map doesn't contain any versioned symbols so it just bitches about everything as being undefined. (depmod needs a "-i" to temporarily ignore versioning and it still bitches) And looking at the System.map is a bad way to judge missing symbols -- unless depmod knows to look for the exported tags. And what's up with the explosion of directories? People bitch because things aren't being divided up -- everything pilling up in misc. Other's bitch in favor of a flat directory. And the answer is this?!? I'm all for organization and the removal of the intermidary "symlink farm", but this is INSANE. (did I miss a memo or something?) Hmm, /lib/modules//kernel/fs/*... only ONE directory has more than one file in it and it (nls) _isn't_ a file system. --Ricky PS: Gez, the linux build system has become the largest pile of rotting spaghetti I've ever seen. (It's like watching the old Spam Cam.) - 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/
modules_install?
What's the point of running depmod at the end of modules_install? The System.map doesn't contain any versioned symbols so it just bitches about everything as being undefined. (depmod needs a "-i" to temporarily ignore versioning and it still bitches) And looking at the System.map is a bad way to judge missing symbols -- unless depmod knows to look for the exported tags. And what's up with the explosion of directories? People bitch because things aren't being divided up -- everything pilling up in misc. Other's bitch in favor of a flat directory. And the answer is this?!? I'm all for organization and the removal of the intermidary "symlink farm", but this is INSANE. (did I miss a memo or something?) Hmm, /lib/modules/version/kernel/fs/*... only ONE directory has more than one file in it and it (nls) _isn't_ a file system. --Ricky PS: Gez, the linux build system has become the largest pile of rotting spaghetti I've ever seen. (It's like watching the old Spam Cam.) - 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: modules_install?
On Thu, 7 Sep 2000, Michael Elizabeth Chastain wrote: (1) Rules.make had a load of ugly code to translate from the source tree to the symlink farm. This code had plenty of bugs and race conditions (e.g. if two subdirectories have the same MOD_LIST_NAME and make runs in parallel). (2) The top Makefile had a butt-load of even uglier code to translate from the symlink farm to the install tree. This code needed to be coordinated with modutils releases. It also suffered from bugs, such as configuration changes leaving stale files around. Well, there's butt-loads of ugly Makefile shit all over the place. It isn't going away. I'll agree the symlink farm was a bad idea. However, the mass of one file per directory crap is no better an idea. (3) Module names had to be unique across the entire kernel tree, which is a silly limitation. Yes and no. You can only insmod _one_ serial.o so the name does have to be unique at the time it's loaded. This is the "serial.o" vs. "usb serial.o" problem. If you need both modules loaded at the same time then they still have to be unique. So now, the module installation code is simple and correct and doesn't need to be updated in tandem with modutils every two weeks. WRONG. The current system will be slinging directories left and right. If someone doesn't tell modutils about them, then it doesn't work. There's already been heated arguements about the modutils scaling the directory tree in search of modules. It was generally conceeded to be a bad idea. (BTW, the current modutils (2.3.15) won't see all the modules from a modules_install.) From an efficiency standpoint, one file per directory is a hideous waste of both filesystem space (one inode and one block) and system resources (file access times, dcache, et. al.) --Ricky - 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: modules_install?
On Thu, 7 Sep 2000, Michael Elizabeth Chastain wrote: However, NO ONE has taken the time (I'm talking weeks of doing nothing but screwing with Makefiles) to completely rewrite the build system. I have done exactly that. And how much did RedHat pay you to do it? And I gave you the URL. You want to read it, or you want to keep whining that "NO ONE" is doing the work I am pointing you directly to? What you point at and what's in the kernel tree still isn't complete. And it's still a load of hackish crap. Rules.make is still an enormous pile of goo -- highly condition and hard to follow. (Not that it's ever been anything else.) Some of the hackishness is inescapable -- flag tracking for one. The ugly "ifeq ... endif" blocks in Makefiles need to be gone. All of them. Everywhere. NO exceptions. The additional (redundant clone) build rules need to be gone. The "boilerplate" sections should be in one place, not cloned in every Makefile. Actually, they shouldn't be necessary if the "old-style" is gone. I should be able to cd to any directory anywhere in the tree and build anything. (That's always been a toughy.) Shall I continue? What's the point in making processors faster if everyone just wastes the increase being "correct and simple"? I've also benchmarked my Makefiles against the stock kernel Makefiles. The "correct and simple" Makefiles run in 1/2 the time. Simple corrections to a few places can account for 90% of this speed up simply by correcting the erronious recompliations -- and yes, I fixed those in my source tree long ago. Optimizing the Makefiles certainly make them easier for a human to deal with but doesn't make order of magnitude differences to "make". Try running your benchmark with "make -n" to see the speed of the Makefile processing instead of compilations. (If you really wanna speed up make, then disable all of it's implicit rules and suffix mapping.) Honestly, it's like talking to a wall here. Rick[y], you don't know what you're talking about, and you show too much unwillingness to learn. I'm not interested in your prejudices any more. Oh, I know more than you think I do. Perfection is a hard thing to find. Finding anyone who knows how to actually write a Makefile is just as hard. (Just because I tend to keep my toys to myself is my business.) It is my opinion that one should not tweak, hack, evolve, fix, or even otherwise look at the spooge that has served as the build system for years. Burn it to the ground, bulldoze the asses out of the way, and actually _design_ a _new_ system. Enumerate what functions and requirment there are and build 'em. No "backwards compat."; no hold overs from the days of the Roman Empire; no "new way" and "old way", simply "THE way". Take a lesson from Mother Nature: Forest fires are a Good Thing (tm) --Ricky PS: How the hell did we go from complaining about the "stubby modules tree" to relative speeds of make? I stand by my original comments: one file per directory is no better (worse even) than all files in one directory. - 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: modules_install?
On 8 Sep 2000, Juan J. Quintela wrote: Could we make it _easy_ to put all the modules/System.map/bzImage/whatever in boot/ and make it easy to do a tar of that directory and make easy to install that dir in another machine (perhaps puting a tiny Makefile/script there to do that). Well, one can certainly do this. The "make install" dream is just that, a dream. You can set a standard saying the kernel belongs in /boot, but that doesn't mean everyone will put it there. In my opinion, the process of installing a kernel should require a certain IQ from the installer. That means no button for a trained monkey to push. (You would be amazed the mount of shit I've had to clean up following the pushing of that button by a "trained" (huge assumtion) monkey.) --Ricky - 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: What the Heck? [Fwd: Returned mail: User unknown]
On Tue, 5 Sep 2000, Albert D. Cahalan wrote: >First of all, the "250,000" is wrong: I was just making up a number. I can go scan ARIN for all their netblocks and give you the exact number of address that would have to be scanned. (I won't. It's alot.) >Second, dialup users don't have enough bandwidth to matter. >Bouncing SPAM across a 42 or 24 kb/s modem link is insignificant. Oh hell yes they do. I've seen a single 28.8 user kill an email server. (Ok, I'll admit Netscape Messenger Server is mostly to blame, but still.) Mail isn't coming back to that address. Let's see 1000 4k messages with 50 people per... that's about 22min to send spam to 50k addresses. Hang up, dialup with a differenat address, and send another 1000. (Granted, the cable modem would take about 2 minutes, but it'd be hard to hide.) >Tell me, would you like this done to you? You may assume typical >corporate enhancements: no PGP, filter runs on Windows 2000, any >unknown headers get stripped out, etc. ... message size restrictions, attachment mangling, false virus detection... --Ricky - 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: [OFFTOPIC] Re: What the Heck? [Fwd: Returned mail: User unknown]
On Mon, 4 Sep 2000, Gregory Maxwell wrote: >> Then they need more competant admins. It isnt _hard_ to transproxy outgoing >> smtp traffic via a spamtrapper that checks for valid src/destination and >> headers. > >I can't believe that you are suggesting this. Mindspring did this (maybe still does.) I think they successfully pissed off every one of their (then) customers doing this shit. They lost an unreported number of users as a result. As an aside, they also have/had agressive transparent web proxying in the network... everything on port 80 coming and going is/was cached. EVERYTHING. >The moment you being to start encouraging commercial ISPs to start >meddling with the packets you destroy end-to-end transparency and shatter >the freedom the Internet has previously experienced from the meddling of >corporate money grabbers. One could say this about SPAM in general. SMTP was designed as on open transport. Now we have to go around and board up the windows so no one can see inside. >The moment I detect my provider changing anything beyond a TTL is the >moment I find a new provider. They aren't rewriting your packects; they just simply force you to connect to _their_ mail servers for incoming and outgoing mail. >As far as broadband service goes, just give the damn users fixed IPs and >let the opt-in blacklists handle them. ARIN (and other registries) don't like "static IP" ISPs. Besides, the provider wants to be able to charge a s***load for a static address even when their DHCP hardware already is configured to prefer reassigning the same address -- people have been known to have the same address for months even after prolonged down time. --Ricky - 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: What the Heck? [Fwd: Returned mail: User unknown]
On Mon, 4 Sep 2000, Alan Cox wrote: >FreeServe in the UK have over 3 million dialup users and no spam problem. Well, the economics of the UK is very different than the US. Besides, aren't their laws against that sorta stuff over there? >> It's the same problem EVERY ISP has. RR is just higher profile because >> of the number of users. Cable/DSL are unlike traditional dialup in that >> you are always connected as long as the machine is on. > >Then they need more competant admins. It isnt _hard_ to transproxy outgoing >smtp traffic via a spamtrapper that checks for valid src/destination and >headers. It's not admins, it's less stupid users -- you can group "less" and "stupid" however you want. As for trapping SMTP traffic... uh, HELL NO. If you ever want to piss off your customers, start getting in their way. I'd like to see just how you think you could validate the src/dst/headers? The "From" address doesn't have to match the network provider to be valid and only the end-point can validate the "To". Are you gonna reject my mail because my clock is wrong so the dates in the header are off? Don't get me wrong, I hate spam. The only simple way to prevent spam is to kill the people from whom it is originating -- that means the monkey with the keyboard pushing the send button. --Ricky - 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: why am i seeing a ~60-second network connection delay with2.4.0test*?
On Mon, 4 Sep 2000, John Kennedy wrote:
> Ping seems to be spending its time in a sendto()/poll() loop:
>
> sendto(3, "U\3Z\241\0\0\0\0\0\0\0\2\0\1\206\240\0\0\0\2\0\0\0\3\0"..., 56, 0,
>{sin_family=AF_INET, sin_port=htons(111), sin_addr=inet_addr("127.0.0.1")}}, 16) = 56
> poll([{fd=3, events=POLLIN}], 1, 5000) = 0
port 111 is the rpc portmap. My guess is you aren't running portmap and
your /etc/nsswitch.conf has "nis" and "nisplus" references in it. (Damn you
redhat and glibc.)
> Is looks like it might be trying to talk to the portmapper for some
>reason. I don't have the portmapper running on either kernel version.
>It is going to take me a bit to make a non-pcmcia system to hop back
>and forth between 2.2.x and 2.4.x, but I thought I would spit that out.
This was hashed about long ago. I think it's documented somewhere. I
usually remove all the damned NIS/NIS+ BS from the system configuration
(including the libraries) after installing the system. (I have _one_ machine
with NIS capabilities as it was once integrated into the office network.)
--Ricky
-
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: What the Heck? [Fwd: Returned mail: User unknown]
On Sun, 3 Sep 2000, Horst von Brand wrote: >"Albert D. Cahalan" <[EMAIL PROTECTED]> said: >> The rr.com service is expanding across the US. It is a cable >> service recently bought by AT It serves areas without ISDN >> or DSL, so the only alternative is a POTS modem. The rr.com >> service is much cheaper and usually faster than ISDN and DSL. > >Much more of a reason to get them to clean up their act! Excuse me? How the hell do you expect them to "clean up their act" when their "dialup" users are the problem? Are you gonna scan 250,000 machines to make sure they aren't running SMTP servers? Trap all port 25 traffic? It's the same problem EVERY ISP has. RR is just higher profile because of the number of users. Cable/DSL are unlike traditional dialup in that you are always connected as long as the machine is on. Nobody at rr.com can send Alan email, so be it. If Alan want's to be an ass, he's entitled to -- he is British after all *grin* --Ricky - 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: Linux 2.2 - BSD/OS 4.1 ARP incompatibility
(OK, I've read enough of this crap.)
On Sat, 2 Sep 2000, David Luyer wrote:
>I'm seeing a problem between Linux 2.2 and BSD/OS 4.1 in the situation on one
>of our backbones.
Why is it the people placed in charge of networks usually have no clue
how they work? (don't answer that.)
[broken network topology deleted]
>Which d.e.f.2 promptly ignores, presumably because the IP stack in BSD/OS
>throws it away at a low level, or possibly simply because BSD/OS has no
>idea where to send the ARP response.
Or both. Both _are_ true.
>Is this already fixed in 2.4 or it is something which needs investigation
>and a patch?
Neither. The problem is your network topology. What you have is something
Cisco should include in their training -- even cisco certified nuts often
cannot figure this out. Every network engineer will eventually lose a toe
on this one.
You have multiple subnets on the same physical network. However, the machines
within those subnets don't know about the other subnets. As long as there
aren't any machines in both subnets -- as you have -- then everything will
function more or less as long as the router ignores a few basic routing rules
("never retransmit a packet onto the interface onwhich it was received.")
The INSTANT you have a machine in (or even aware of) the other subnets,
you see the problem you currently have.
IF (that's a big if) the source is unbound, then the system is free to
choose any "valid" interface address. Logically, it should choose an
address within the dest network. However, I am unaware of any RFC stating
that as a MUST. Technically, ANY address within that physical network is
valid. However, the machines in the other subnets don't know about the
other subnets and thus cannot answer a "martian" arp. (Even if they wanted
to answer, they don't have a physical route.)
If the source is bound, then you're screwed. The system has no choice but
to send the arp with the bound address.
As a general rule, EVERY MACHINE SHOULD BE AWARE OF THE TRAFFIC ON IT'S
CABLE. What you (and everyone else I've ever known) have created is an
unstable network. It's not limited to Linux and BSD. I've seen this crap
between an assortment of OSes.
While a kernel patch might help, it will not prevent this. The kernel cannot
stop you from making bad networks.
As a case study, the ISP I used to work for had, at one point, 11 (yes,
eleven) logic networks on one physical network -- two private networks,
three office networks, the core network, a bridged customer network, the
entire web farm, etc. Some of those networks used to be isolated
physical networks -- and my workstation has an interface in all three. We
constantly had odd problems because no machine (aside from the router)
knew exactly what was where. The helpdesk machines couldn't access the
web farm until I added a route to all the machines (solaris web servers
ad win95 pc's.)
--Ricky
PS: I'm saddened to see the number of router vendors ignoring the specs
because their customers are building bad networks (read: "idiots")
-
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: Linux 2.2 - BSD/OS 4.1 ARP incompatibility
(OK, I've read enough of this crap.)
On Sat, 2 Sep 2000, David Luyer wrote:
I'm seeing a problem between Linux 2.2 and BSD/OS 4.1 in the situation on one
of our backbones.
Why is it the people placed in charge of networks usually have no clue
how they work? (don't answer that.)
[broken network topology deleted]
Which d.e.f.2 promptly ignores, presumably because the IP stack in BSD/OS
throws it away at a low level, or possibly simply because BSD/OS has no
idea where to send the ARP response.
Or both. Both _are_ true.
Is this already fixed in 2.4 or it is something which needs investigation
and a patch?
Neither. The problem is your network topology. What you have is something
Cisco should include in their training -- even cisco certified nuts often
cannot figure this out. Every network engineer will eventually lose a toe
on this one.
You have multiple subnets on the same physical network. However, the machines
within those subnets don't know about the other subnets. As long as there
aren't any machines in both subnets -- as you have -- then everything will
function more or less as long as the router ignores a few basic routing rules
("never retransmit a packet onto the interface onwhich it was received.")
The INSTANT you have a machine in (or even aware of) the other subnets,
you see the problem you currently have.
IF (that's a big if) the source is unbound, then the system is free to
choose any "valid" interface address. Logically, it should choose an
address within the dest network. However, I am unaware of any RFC stating
that as a MUST. Technically, ANY address within that physical network is
valid. However, the machines in the other subnets don't know about the
other subnets and thus cannot answer a "martian" arp. (Even if they wanted
to answer, they don't have a physical route.)
If the source is bound, then you're screwed. The system has no choice but
to send the arp with the bound address.
As a general rule, EVERY MACHINE SHOULD BE AWARE OF THE TRAFFIC ON IT'S
CABLE. What you (and everyone else I've ever known) have created is an
unstable network. It's not limited to Linux and BSD. I've seen this crap
between an assortment of OSes.
While a kernel patch might help, it will not prevent this. The kernel cannot
stop you from making bad networks.
As a case study, the ISP I used to work for had, at one point, 11 (yes,
eleven) logic networks on one physical network -- two private networks,
three office networks, the core network, a bridged customer network, the
entire web farm, etc. Some of those networks used to be isolated
physical networks -- and my workstation has an interface in all three. We
constantly had odd problems because no machine (aside from the router)
knew exactly what was where. The helpdesk machines couldn't access the
web farm until I added a route to all the machines (solaris web servers
ad win95 pc's.)
--Ricky
PS: I'm saddened to see the number of router vendors ignoring the specs
because their customers are building bad networks (read: "idiots")
-
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: What the Heck? [Fwd: Returned mail: User unknown]
On Sun, 3 Sep 2000, Horst von Brand wrote: "Albert D. Cahalan" [EMAIL PROTECTED] said: The rr.com service is expanding across the US. It is a cable service recently bought by ATT. It serves areas without ISDN or DSL, so the only alternative is a POTS modem. The rr.com service is much cheaper and usually faster than ISDN and DSL. Much more of a reason to get them to clean up their act! Excuse me? How the hell do you expect them to "clean up their act" when their "dialup" users are the problem? Are you gonna scan 250,000 machines to make sure they aren't running SMTP servers? Trap all port 25 traffic? It's the same problem EVERY ISP has. RR is just higher profile because of the number of users. Cable/DSL are unlike traditional dialup in that you are always connected as long as the machine is on. Nobody at rr.com can send Alan email, so be it. If Alan want's to be an ass, he's entitled to -- he is British after all *grin* --Ricky - 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: why am i seeing a ~60-second network connection delay with2.4.0test*?
On Mon, 4 Sep 2000, John Kennedy wrote:
Ping seems to be spending its time in a sendto()/poll() loop:
sendto(3, "U\3Z\241\0\0\0\0\0\0\0\2\0\1\206\240\0\0\0\2\0\0\0\3\0"..., 56, 0,
{sin_family=AF_INET, sin_port=htons(111), sin_addr=inet_addr("127.0.0.1")}}, 16) = 56
poll([{fd=3, events=POLLIN}], 1, 5000) = 0
port 111 is the rpc portmap. My guess is you aren't running portmap and
your /etc/nsswitch.conf has "nis" and "nisplus" references in it. (Damn you
redhat and glibc.)
Is looks like it might be trying to talk to the portmapper for some
reason. I don't have the portmapper running on either kernel version.
It is going to take me a bit to make a non-pcmcia system to hop back
and forth between 2.2.x and 2.4.x, but I thought I would spit that out.
This was hashed about long ago. I think it's documented somewhere. I
usually remove all the damned NIS/NIS+ BS from the system configuration
(including the libraries) after installing the system. (I have _one_ machine
with NIS capabilities as it was once integrated into the office network.)
--Ricky
-
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: What the Heck? [Fwd: Returned mail: User unknown]
On Mon, 4 Sep 2000, Alan Cox wrote: FreeServe in the UK have over 3 million dialup users and no spam problem. Well, the economics of the UK is very different than the US. Besides, aren't their laws against that sorta stuff over there? It's the same problem EVERY ISP has. RR is just higher profile because of the number of users. Cable/DSL are unlike traditional dialup in that you are always connected as long as the machine is on. Then they need more competant admins. It isnt _hard_ to transproxy outgoing smtp traffic via a spamtrapper that checks for valid src/destination and headers. It's not admins, it's less stupid users -- you can group "less" and "stupid" however you want. As for trapping SMTP traffic... uh, HELL NO. If you ever want to piss off your customers, start getting in their way. I'd like to see just how you think you could validate the src/dst/headers? The "From" address doesn't have to match the network provider to be valid and only the end-point can validate the "To". Are you gonna reject my mail because my clock is wrong so the dates in the header are off? Don't get me wrong, I hate spam. The only simple way to prevent spam is to kill the people from whom it is originating -- that means the monkey with the keyboard pushing the send button. --Ricky - 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: What the Heck? [Fwd: Returned mail: User unknown]
On Tue, 5 Sep 2000, Albert D. Cahalan wrote: First of all, the "250,000" is wrong: I was just making up a number. I can go scan ARIN for all their netblocks and give you the exact number of address that would have to be scanned. (I won't. It's alot.) Second, dialup users don't have enough bandwidth to matter. Bouncing SPAM across a 42 or 24 kb/s modem link is insignificant. Oh hell yes they do. I've seen a single 28.8 user kill an email server. (Ok, I'll admit Netscape Messenger Server is mostly to blame, but still.) Mail isn't coming back to that address. Let's see 1000 4k messages with 50 people per... that's about 22min to send spam to 50k addresses. Hang up, dialup with a differenat address, and send another 1000. (Granted, the cable modem would take about 2 minutes, but it'd be hard to hide.) Tell me, would you like this done to you? You may assume typical corporate enhancements: no PGP, filter runs on Windows 2000, any unknown headers get stripped out, etc. ... message size restrictions, attachment mangling, false virus detection... --Ricky - 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: 2T for i386
On Tue, 29 Aug 2000, Alan Cox wrote: >At 2Tb in a single partition you might well start hitting barriers. I think >there is a 1Tb limit per device somewhere. You also need to ask yourself how >long 2Tb would take to fsck on a power failure. Right now 2.2 doesnt support >journalling over software raid so that would stop you using reiserfs and ext3. Who said he was going to use software RAID? For that matter, he didn't say he was going to use ext2 either. (However, that seems to be a logical assumption.) >You might be able to do that with hardware IDE raid controllers and the like >such as the 3ware 8 port cards, or scsi raid controllers and then run ext3 >or reiserfs. If you're building a 2TB array, you're not gonna do it with bloody IDE hardware. (I hope you're joking.) --Ricky PS: fsck is very expensive on a full filesystem. - 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: 2T for i386
On Tue, 29 Aug 2000, Alan Cox wrote: At 2Tb in a single partition you might well start hitting barriers. I think there is a 1Tb limit per device somewhere. You also need to ask yourself how long 2Tb would take to fsck on a power failure. Right now 2.2 doesnt support journalling over software raid so that would stop you using reiserfs and ext3. Who said he was going to use software RAID? For that matter, he didn't say he was going to use ext2 either. (However, that seems to be a logical assumption.) You might be able to do that with hardware IDE raid controllers and the like such as the 3ware 8 port cards, or scsi raid controllers and then run ext3 or reiserfs. If you're building a 2TB array, you're not gonna do it with bloody IDE hardware. (I hope you're joking.) --Ricky PS: fsck is very expensive on a full filesystem. - 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/
