Re: SCSI Problems
Interestingly, LinuxWorld has an article called The Kernel of Pain regarding the 2.4 kernel. http://www.idg.net/go.cgi?id=628921 Derek D. Martin wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 At some point hitherto, Ken D'Ambrosio hath spake thusly: On Mon, 2002-01-14 at 12:09, Benjamin Scott wrote: On Mon, 14 Jan 2002, Paul Lussier wrote: Adaptec has had a lot of problems, especially with Linux drivers. There was one person maintaining his own drivers for linux, then Adaptec came along and said ... Yet another reason to avoid 2.4. I am starting to think that 2.4 is the Ford Edsel of Linux. At the rate things are going, 2.6 might be stable before 2.4 is. I have to disagree. I remember 1.0.0, 1.2.0, 2.0.0, and 2.2.0 -- *all* of them had their share of nay-sayers. And I have to disagree with you. I've generally found that if you want your system to actually work well and reliably, you'll want to wait until at least the point where Linus has passed the kernel on to the stable maintainer. Even then, you can have problems. The 2.2 series didn't really solidify until 2.2.18, which had a security problem which caused 2.2.19 to be released soon after. Unfortunately, the fix didn't, and 2.2.20 was eventually released to finally (hopefully) fix the hole. And Linus has never hidden the fact that he has no problem publishing kernels that break drivers, his opinion being that, if the code is needed, someone'll fix it, and if it isn't, it'll eventually get deprecated and then removed. Alas, I've seen many discussions about how stupid Adaptec's been lately (~ 2 years) with regards to drivers, be it making their own, or publishing specs. When it came to SCSI, my mantra used to be There is no adapter but Adaptec, and I am their prophet, but this has, alas, changed... and it's not 2.4's fault if Adaptec's made this happen. I'm familiar with the arguments, and they make some sense. As for whether or not it's the kernel developer's fault the Adaptec drivers don't work: No, but it doesn't much matter either if you have Adaptec hardware, does it? If it don't work, it don't work. Plain and simple. BTW, a suggestion for people who have this problem: Build an SMP kernel, even if you only have one CPU, or make sure IO-APIC support is turned on. This MAY help. Or may not. It worked for me with the Red Hat supplied version of 2.4.7 which comes with RH 7.2. As for other issues with 2.4 -- they're getting worked on. After the fiasco that was 2.4.15, I think they're pretty much to the point where it's a usable, production-ready kernel. Maybe... but would you bet your company's life on it? - -- Derek Martin [EMAIL PROTECTED] - - I prefer mail encrypted with PGP/GPG! GnuPG Key ID: 0x81CFE75D Retrieve my public key at http://pgp.mit.edu Learn more about it at http://www.gnupg.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8Q4JVdjdlQoHP510RAh+LAJ4g+1frfXYGXhmSFm9U914phayufwCfQxt6 BIXhCCh72Y22IJRwjc2P8uw= =Lu6K -END PGP SIGNATURE- * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. * * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Kernel 2.4 debate (was: SCSI Problems)
On Mon, 14 Jan 2002, Ken Ambrose wrote: Indeed. But this has held true for ages. Go read the 1.x ethernet notes on the 3c501 ethernet card ... Okay, this is starting to get ridiculous, but as far as *that* goes, the 3C501 was shunned not because of the kernel driver, but because it was a lump of sh*t. We're talking an 8-bit programmed I/O Ethernet card with a *SINGLE*, *SHARED* TX/RX buffer. It was designed to receive data at the rate a PC-XT could transmit it, and got overwhelmed for just about anything else. Ask me how I felt when XFree86 4.0 dropped support for my spiffy SGI flatpanel digital display video card... Which begs the question: Then why did you run XFree 4.0? :-) ... rather the fact that for the vast majority of users, it's likely to be pretty much as stable as 2.2... Perhaps the new VM will help in that department, but prior to the new VM, I can say that 2.4 was *not* suitable for the vast majority of users. It would randomly go into swap storms that left the system unusable for minutes at a time. ... 2.4 has some pretty nifty features, to boot. As near as I can tell, the only legitimately useful feature is the better firewalling code. If you want a kernel that takes better advantage of multi-processor hardware ... The vast majority of users have an eight CPU box? ;-) ... larger filesizes ... The vast majority of users have single files larger than 2 GB? ;-) ... in-kernel HTTP server of static pages ... Oh, come on. The only reason *that* was put in was to increase benchmark scores. If I wanted crap like that, I'd run NT. :-) ... a somewhat flakier VM ... Not that anyone uses the memory manager anyway. ;-) -- Ben Scott [EMAIL PROTECTED] | The opinions expressed in this message are those of the author and do not | | necessarily represent the views or policy of any other person, entity or | | organization. All information is provided without warranty of any kind. | * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
SCSI Problems
Well, FWIW, I built a 2.2.21-pre2 kernel, and was unable to boot it with the Plextor SCSI CDRW drive on the bus. The P2L97DS/Adaptec BIOS does see it, and depending on whether I enable LUNs in the Adaptec BIOS, I get slightly differing results. However, I also noticed that the Adaptec driver is 6.2.something, and is therefore basically the same thing that's in the 2.4/2.5 kernels. It is an SMP box (dual P-II's at 333MHz), and I do have the APIC stuff enabled (thanks, Kenny), and it's still barfing. My suspicion is that LUN 1 is raising the ATN bit and the driver can't cope with it, and no amount of SCSI bus resets clears it and therefore the driver loops, resetting the bus and getting nowhere. I'm not able to download the new firmware under SCU (the SCSI Configuration Utility) available under Tru64 and Linux (the latter if-and-only-if you've compiled in the sg* driver), so it appears that I'll have to plop in a spare spindle, and dust off my Neolithic Technology CD and pay brief homage to the Evil Empire and pump new firmware into it that way. Hopefully, it won't take too long and I can get it done before I have to defragment the disk. Thanks for the help, pointers, and suggestions. I'll let y'all know how things turned out! Cheers, Bayard --- Bayard R. Coolidge N1HODISCLAIMER: The opinions expressed are Compaq Computer Corp. solely those of the author, and not Nashua, New Hampshire, USA those of Compaq Computer Corporation [EMAIL PROTECTED] (DEC '77-'98) or any other entity. Brake for Moose - It could save your life - N.H. Fish Game Dept. -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS/CC d+ s:+ a++ C+++$ UO++$L++$ P L++$ E-@ W+ N++ o- K? w--- O? M? V-- PS+ PE+ Y+ PGP- t++ 5? X? R* tv b++ DI+++ D? G e++ h-- r++ y? UF++ -END GEEK CODE BLOCK- --- * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: Kernel 2.4 debate (was: SCSI Problems)
On Tue, 2002-01-15 at 08:30, Benjamin Scott wrote: On Mon, 14 Jan 2002, Ken Ambrose wrote: Indeed. But this has held true for ages. Go read the 1.x ethernet notes on the 3c501 ethernet card ... Okay, this is starting to get ridiculous, but as far as *that* goes, the 3C501 was shunned not because of the kernel driver, but because it was a lump of sh*t. We're talking an 8-bit programmed I/O Ethernet card with a *SINGLE*, *SHARED* TX/RX buffer. It was designed to receive data at the rate a PC-XT could transmit it, and got overwhelmed for just about anything else. Okay, okay -- so I picked an interesting example. I was using it to illustrate, though, and I think I made the point. Other vendors have either been dropped from the kernel, or never been well supported, for lack of docs -- just like Adaptec. Ask me how often the embeded ATA-66 controller on my BP-6 motherboard (under 2.2, no less) caused my system to crash. Enough that I finally had to go out and buy a different card (and this was after I did something I'd never done before, or since: I e-mailed Alan, and that was his official opinion). These things (a la the Adaptec fiasco) happen. Sometimes they get fixed, sometimes they don't. Ask me how I felt when XFree86 4.0 dropped support for my spiffy SGI flatpanel digital display video card... Which begs the question: Then why did you run XFree 4.0? :-) Because various DVD-playing software required it, and I wasn't about to back-port. Not to mention that, once it was dropped from 4.0, I'd assumed (incorrectly, thankfully) that it would never be seen again, and figured I'd have to have some sort of solution to go forward with. ... rather the fact that for the vast majority of users, it's likely to be pretty much as stable as 2.2... Perhaps the new VM will help in that department, but prior to the new VM, I can say that 2.4 was *not* suitable for the vast majority of users. It would randomly go into swap storms that left the system unusable for minutes at a time. If so, I am yet to see this happen. Of course, I am using RH kernels, which have been heavily massaged by AC (who was a strong proponent of stabilizing the VM), which might explain why. Perhaps I should have been more explicit -- I don't really trust the Linus/Marcello non-Alan-ized kernels... leastwise, not yet, though apparently .14 and above is doing much better. ... 2.4 has some pretty nifty features, to boot. As near as I can tell, the only legitimately useful feature is the better firewalling code. How do you define legitimately useful? I certainly consider merged native JFS code, native wireless support, native PCMCIA (which hadn't been native since 2.0.x), etc., to be legitimately useful. Not to mention, as you point out, stateful firewalling code... though I haven't yet gotten that under my belt. ;-) If you want a kernel that takes better advantage of multi-processor hardware ... The vast majority of users have an eight CPU box? ;-) No... but even on my dual-processor boxen, I have seen bettter benchmarks on kernel compiles. A quick sidenote: I *love* MP boxes. Even a substantially slower (say, dual 500 MHz Celeron, my first MP box) can *appear* faster than a more powerful (eg. 1 GHz Athlon) box. Why? Because one processor can be sitting there, munching on your DivX ;-) playback, and the other will happily say, Oh! Look! Ken's mouse has an interrupt to process! I'll go do that right now. So, unless you're doing intensive number crunching (in which case one fast CPU definitely wins out over two slower ones), I highly recommend MP boxen. And 2.4 is demonstrably better at MP functionality. Granted, it becomes more obvious with N processors, where N is fairly large -- but I won't overlook it for where N equals two, thanks. If I did that, I'd run NT :-). ... larger filesizes ... The vast majority of users have single files larger than 2 GB? ;-) No... leastwise, not usually. But more than once, I've been tarring some directory or other... and found that my tar finished at 2147483647 bytes. Whereupon I had to go and find some other way to do what I was doing. Go ahead and tell me that this hasn't happened to you. With 2.4, it suddenly becomes a non-issue, which is *very* nice. ... in-kernel HTTP server of static pages ... Oh, come on. The only reason *that* was put in was to increase benchmark scores. If I wanted crap like that, I'd run NT. :-) Yes, it was *driven* by benchmark scores... this doesn't, however, invalidate it as a cool feature. ... a somewhat flakier VM ... Not that anyone uses the memory manager anyway. ;-) See earlier comments re: -ac/Red Hat kernels. -Ken * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body.
Re: Kernel 2.4 debate (was: SCSI Problems)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 At some point hitherto, Ken D'Ambrosio hath spake thusly: On Tue, 2002-01-15 at 08:30, Benjamin Scott wrote: Okay, okay -- so I picked an interesting example. I was using it to illustrate, though, and I think I made the point. Other vendors have either been dropped from the kernel, or never been well supported, for lack of docs -- just like Adaptec. Ask me how often the embeded ATA-66 controller on my BP-6 motherboard (under 2.2, no less) caused my system to crash. Well, I believe that if your system was freezing up (i.e. not panicing), that the cause was something else. That's a well-documented BIOS problem, not a kernel problem. There ARE BIOS updates for the BP-6 that fix this problem. I know, because I have one too, and went through this. But, BTW, I never used the ATA-66 interfaces on the motherboard. Enough that I finally had to go out and buy a different card (and this was after I did something I'd never done before, or since: I e-mailed Alan, and that was his official opinion). These things (a la the Adaptec fiasco) happen. Sometimes they get fixed, sometimes they don't. I talked to Alan about this problem as well, and also posted stuff on LKML. At the time, the consensus was a BIOS problem, and sure enough flashing the BIOS fixed it. I got my BP-6 quite some time after they'd been out, so it may be that you contacted Alan before the problem was well understood. Various people reported different symptoms, and it seems that different configurations tweak the problem differently. Ask me how I felt when XFree86 4.0 dropped support for my spiffy SGI flatpanel digital display video card... Which begs the question: Then why did you run XFree 4.0? :-) Because various DVD-playing software required it, and I wasn't about to back-port. Not to mention that, once it was dropped from 4.0, I'd assumed (incorrectly, thankfully) that it would never be seen again, and figured I'd have to have some sort of solution to go forward with. This really has nothing to do with the debate about the kernel... But when X4.0 was released, the XFree86 team was quite clear that a LOT of drivers weren't done, others weren't even started, but would eventually be gotten to. ... rather the fact that for the vast majority of users, it's likely to be pretty much as stable as 2.2... Perhaps the new VM will help in that department, but prior to the new VM, I can say that 2.4 was *not* suitable for the vast majority of users. It would randomly go into swap storms that left the system unusable for minutes at a time. If so, I am yet to see this happen. I have. I've had it happen to me every time I've used my systems running a 2.4 kernel for any lenght of time without rebooting. Usually takes about 3-5 days of uptime before it becomes a problem. But once it does, pretty much only a reboot will fix it, IME. Of course, I am using RH kernels, which have been heavily massaged by AC (who was a strong proponent of stabilizing the VM) Yep, RH kernels are much different from the standard kernel, and I personally won't run them, because they're much less well-understood than the standard kernel. If you're not a kernel hacker, and don't know any, the only way you can get support on RH kernels is to pay someone (most likely Red Hat). For that reason, I don't consider that they count for this discussion. , which might explain why. Perhaps I should have been more explicit -- I don't really trust the Linus/Marcello non-Alan-ized kernels... leastwise, not yet, though apparently .14 and above is doing much better. Well, that's basically what Ben and I have been saying! - -- Derek Martin [EMAIL PROTECTED] - - I prefer mail encrypted with PGP/GPG! GnuPG Key ID: 0x81CFE75D Retrieve my public key at http://pgp.mit.edu Learn more about it at http://www.gnupg.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8RHXpdjdlQoHP510RAgJaAJ4iSsGmmWh29Qn80VtRT0tRVoWwwACeNjpb rCnM/IF++WrGg/Ek8rj/KQQ= =Qo79 -END PGP SIGNATURE- * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: Kernel 2.4 debate (was: SCSI Problems)
In a message dated: 15 Jan 2002 10:48:53 EST Ken D'Ambrosio said: The vast majority of users have single files larger than 2 GB? ;-) No... leastwise, not usually. But more than once, I've been tarring some directory or other... and found that my tar finished at 2147483647 bytes. Whereupon I had to go and find some other way to do what I was doing. Go ahead and tell me that this hasn't happened to you. With 2.4, it suddenly becomes a non-issue, which is *very* nice. And to add to that, if you have a network of systems you want to back up, it's really nice to have a few spare gig to use as a holding disk to store dumps on. I set amanda to use 4 and 6 gig chunks for file storage. I will probably bump this up to equal the average size of my file systems if I can, since the few files you have to flush to tape the more efficient things are. -- Seeya, Paul God Bless America! If you're not having fun, you're not doing it right! ...we don't need to be perfect to be the best around, and we never stop trying to be better. Tom Clancy, The Bear and The Dragon * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: SCSI Problems
Benjamin Scott [EMAIL PROTECTED] asked: Have you tried a kernel that works? I have seen similar weird problems trying to install 2.4-based distros at home, which promptly disappeared when I switched back to 2.2. No, I'd long since upgraded my entire infrastructure to support 2.4, and I suppose I could build a 2.2 kernel, but have never tried running one on a system that expects a 2.4 kernel. (I.e., all the stuff documented in the CHANGES file, e.g. http://www.linuxhq.com/kernel/v2.4/doc/Changes.html). As I said, my current gameplan is to build a new box from the table-up, but with a TekRam board, or get myself a Qlogic board that I can pop in my current system and see if I can add the Plextor on a SCSI bus of its own (which might not be a bad idea anyway, for performance enhancement). There was a discussion on the LKML a few weeks ago about issues with other SCSI devices, which highlighted some of these seemingly Adaptec-specific quirks. Hence, my shopping list for the new system included a TekRam SCSI board, rather than Adaptec. Thanks, Bayard --- Bayard R. Coolidge N1HODISCLAIMER: The opinions expressed are Compaq Computer Corp. solely those of the author, and not Nashua, New Hampshire, USA those of Compaq Computer Corporation [EMAIL PROTECTED] (DEC '77-'98) or any other entity. Brake for Moose - It could save your life - N.H. Fish Game Dept. -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS/CC d+ s:+ a++ C+++$ UO++$L++$ P L++$ E-@ W+ N++ o- K? w--- O? M? V-- PS+ PE+ Y+ PGP- t++ 5? X? R* tv b++ DI+++ D? G e++ h-- r++ y? UF++ -END GEEK CODE BLOCK- --- * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: SCSI Problems
On Mon, 2002-01-14 at 12:09, Benjamin Scott wrote: On Mon, 14 Jan 2002, Paul Lussier wrote: Adaptec has had a lot of problems, especially with Linux drivers. There was one person maintaining his own drivers for linux, then Adaptec came along and said ... Yet another reason to avoid 2.4. I am starting to think that 2.4 is the Ford Edsel of Linux. At the rate things are going, 2.6 might be stable before 2.4 is. I have to disagree. I remember 1.0.0, 1.2.0, 2.0.0, and 2.2.0 -- *all* of them had their share of nay-sayers. And Linus has never hidden the fact that he has no problem publishing kernels that break drivers, his opinion being that, if the code is needed, someone'll fix it, and if it isn't, it'll eventually get deprecated and then removed. Alas, I've seen many discussions about how stupid Adaptec's been lately (~ 2 years) with regards to drivers, be it making their own, or publishing specs. When it came to SCSI, my mantra used to be There is no adapter but Adaptec, and I am their prophet, but this has, alas, changed... and it's not 2.4's fault if Adaptec's made this happen. As for other issues with 2.4 -- they're getting worked on. After the fiasco that was 2.4.15, I think they're pretty much to the point where it's a usable, production-ready kernel. $.02, -Ken HP has built their tape drive units to explicitly work with only Adaptec cards! You're kidding me. They actually came out and said this? So much for SCSI being an open standard. There is no cause so just or so right that one cannot find an idiot following it. -- Larry Niven -- Ben Scott [EMAIL PROTECTED] | The opinions expressed in this message are those of the author and do not | | necessarily represent the views or policy of any other person, entity or | | organization. All information is provided without warranty of any kind. | * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. * * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: SCSI Problems
On 14 Jan 2002, Ken D'Ambrosio wrote: ... And Linus has never hidden the fact that he has no problem publishing kernels that break drivers ... ... it's not 2.4's fault if Adaptec's made this happen ... ... As for other issues with 2.4 -- they're getting worked on ... I'm not trying to lay blame, or point to this or that. Nor am I taking issue with Linus's well-known policy, which I actually agree with. Nor am I denying that Adaptec's developer information policies are stupid -- they are, as are most vendors. The only thing I am saying is that reasons not to use 2.4 appear to out-number reasons to use it. The how or why of it is immaterial. While I am wearing my system administrator's hat, I don't care *why* the Adaptec SCSI drivers are broken in 2.4, just that they are. Putting on my Open Source Armchair Quarterback hat instead, I believe these problems *will* eventually be solved. Open Source is good at that. However, nothing in Open Source says they will be solved before 2.6 is released (although I don't expect it to take *that* long). It is quite acceptable for Open Source to throw out things that don't work. ... the fiasco that was 2.4.15, I think they're pretty much to the point where it's a usable, production-ready kernel. Last I heard (a week or two ago), there was still significant in-fighting going on over the memory manager. -- Ben Scott [EMAIL PROTECTED] | The opinions expressed in this message are those of the author and do not | | necessarily represent the views or policy of any other person, entity or | | organization. All information is provided without warranty of any kind. | * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: SCSI Problems
In a message dated: Mon, 14 Jan 2002 12:09:33 EST Benjamin Scott said: On Mon, 14 Jan 2002, Paul Lussier wrote: Adaptec has had a lot of problems, especially with Linux drivers. There was one person maintaining his own drivers for linux, then Adaptec came along and said ... Yet another reason to avoid 2.4. I am starting to think that 2.4 is the Ford Edsel of Linux. At the rate things are going, 2.6 might be stable before 2.4 is. This isn't specific to the 2.4 tree. HP has built their tape drive units to explicitly work with only Adaptec cards! You're kidding me. They actually came out and said this? Actually, their wording was The Adaptec HBA shipped with your unit is the the only one we've tested and support. Others *might* work, but we have not tested them and do not support them! -- Seeya, Paul God Bless America! If you're not having fun, you're not doing it right! ...we don't need to be perfect to be the best around, and we never stop trying to be better. Tom Clancy, The Bear and The Dragon * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: SCSI Problems
Quoting Benjamin Scott [EMAIL PROTECTED]: Have you tried a kernel that works? I have seen similar weird problems trying to install 2.4-based distros at home, which promptly disappeared when I switched back to 2.2. I had this problem a few weeks ago with a SCSI tape drive. I added the Adaptec card, recompiled the 2.4.x kernel, and the SCSI card worked, but the system just refused to see the drive. I ended up compiling a 2.2.20 kernel, and it worked just fine. C-Ya, Kenny - There's nothing you shouldn't speak of if you've got something to say, and there's no one to be scared of, just get them out of your way. -- The Alarm * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: SCSI Problems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 At some point hitherto, Ken D'Ambrosio hath spake thusly: On Mon, 2002-01-14 at 12:09, Benjamin Scott wrote: On Mon, 14 Jan 2002, Paul Lussier wrote: Adaptec has had a lot of problems, especially with Linux drivers. There was one person maintaining his own drivers for linux, then Adaptec came along and said ... Yet another reason to avoid 2.4. I am starting to think that 2.4 is the Ford Edsel of Linux. At the rate things are going, 2.6 might be stable before 2.4 is. I have to disagree. I remember 1.0.0, 1.2.0, 2.0.0, and 2.2.0 -- *all* of them had their share of nay-sayers. And I have to disagree with you. I've generally found that if you want your system to actually work well and reliably, you'll want to wait until at least the point where Linus has passed the kernel on to the stable maintainer. Even then, you can have problems. The 2.2 series didn't really solidify until 2.2.18, which had a security problem which caused 2.2.19 to be released soon after. Unfortunately, the fix didn't, and 2.2.20 was eventually released to finally (hopefully) fix the hole. And Linus has never hidden the fact that he has no problem publishing kernels that break drivers, his opinion being that, if the code is needed, someone'll fix it, and if it isn't, it'll eventually get deprecated and then removed. Alas, I've seen many discussions about how stupid Adaptec's been lately (~ 2 years) with regards to drivers, be it making their own, or publishing specs. When it came to SCSI, my mantra used to be There is no adapter but Adaptec, and I am their prophet, but this has, alas, changed... and it's not 2.4's fault if Adaptec's made this happen. I'm familiar with the arguments, and they make some sense. As for whether or not it's the kernel developer's fault the Adaptec drivers don't work: No, but it doesn't much matter either if you have Adaptec hardware, does it? If it don't work, it don't work. Plain and simple. BTW, a suggestion for people who have this problem: Build an SMP kernel, even if you only have one CPU, or make sure IO-APIC support is turned on. This MAY help. Or may not. It worked for me with the Red Hat supplied version of 2.4.7 which comes with RH 7.2. As for other issues with 2.4 -- they're getting worked on. After the fiasco that was 2.4.15, I think they're pretty much to the point where it's a usable, production-ready kernel. Maybe... but would you bet your company's life on it? - -- Derek Martin [EMAIL PROTECTED] - - I prefer mail encrypted with PGP/GPG! GnuPG Key ID: 0x81CFE75D Retrieve my public key at http://pgp.mit.edu Learn more about it at http://www.gnupg.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8Q4JVdjdlQoHP510RAh+LAJ4g+1frfXYGXhmSFm9U914phayufwCfQxt6 BIXhCCh72Y22IJRwjc2P8uw= =Lu6K -END PGP SIGNATURE- * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: SCSI Problems
I have to disagree. I remember 1.0.0, 1.2.0, 2.0.0, and 2.2.0 -- *all* of them had their share of nay-sayers. And I have to disagree with you. I've generally found that if you want your system to actually work well and reliably, you'll want to wait until at least the point where Linus has passed the kernel on to the stable maintainer. Even then, you can have problems. The 2.2 series didn't really solidify until 2.2.18, which had a security problem which caused 2.2.19 to be released soon after. Unfortunately, the fix didn't, and 2.2.20 was eventually released to finally (hopefully) fix the hole. I wasn't arguing that dot-oh releases were stable. I *was* arguing that there's always been a crowd who hearkens for yesteryear, and wants the current major rev. thrown in the garbage. specs. When it came to SCSI, my mantra used to be There is no adapter but Adaptec, and I am their prophet, but this has, alas, changed... and it's not 2.4's fault if Adaptec's made this happen. I'm familiar with the arguments, and they make some sense. As for whether or not it's the kernel developer's fault the Adaptec drivers don't work: No, but it doesn't much matter either if you have Adaptec hardware, does it? If it don't work, it don't work. Plain and simple. Indeed. But this has held true for ages. Go read the 1.x ethernet notes on the 3c501 ethernet card, where the NIC code author, *in writing*, offers $5 for each 3c501 sent to him, and thus taken off the market. (He was willing to accept the PROMs off the board, just in case anyone thought he was in the second-hand NIC market.) Sometimes buggy stuff gets out -- either hardware or software. And, sometimes, the answer is: tough luck. Ask me how I felt when XFree86 4.0 dropped support for my spiffy SGI flatpanel digital display video card... and how amazingly happy I was when it returned with 4.1. By which point I'd already spent $500 for an amazingly unsatisfactory analog solution. As for other issues with 2.4 -- they're getting worked on. After the fiasco that was 2.4.15, I think they're pretty much to the point where it's a usable, production-ready kernel. Maybe... but would you bet your company's life on it? Oh, come, come: now we're devolving into histrionics. You're beginning to sound like an MS FUD-meister. As *always*, with *any* OS, you try as best you can to understand the risks, and how it would impact your company were something bad to happen, and work with it. I *have* been running my company on 2.4 code, with (almost) no glitches. (In early 2.4 series stuff, I found eepro100 virtual interfaces to disappear after some five or so hours. Annoying.) Would I want to run a life-support system on it? Well, no, probably not. But truth be told, I'm not sure what I *would* want to run a life-support system on. I am, however, reasonably confident in the fact that, were one of the systems to have a kernel panic, thanks to the joy that is journaling filesystems, I would have about a three-minute downtime, and no corrupted data. So far, though, I've only had one system pull a kernel panic on me: a 2.2 system, three times, before I ironed out the ReiserFS bug... that, yes, had already been banished from the 2.4-series kernels (it was a max filesize-related issue). Like security, stability is an ongoing process -- if I may borrow from those stupid posters, it's a journey, not a destination. And please note that I'm *not* defending 2.4's track record, per-se, but rather the fact that for the vast majority of users, it's likely to be pretty much as stable as 2.2... and, perhaps in some cases (*gasp*) moreso. And let's not forget -- 2.4 has some pretty nifty features, to boot. So, if you want a fairly mature kernel, with the majority of glitches dispatched, 2.2.x is probably your baby. If you want a kernel that takes better advantage of multi-processor hardware, larger filesizes, in-kernel HTTP server of static pages, blah, blah, blah, but a somewhat flakier VM, etc., etc., etc., then 2.4 is a more likely choice. So long as your choice is an informed one, and takes your company's needs into account, it's probably the right choice -- despite the lack of absolutes. $2*10^-2 -Ken * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
