linux crashes

[DasFox]

What's a gcc bug?

I'm not talking about any gcc bugs, I'm talking about compiling options incorrect, or anding in hardware support that doesn't work as well as it should for your hardware or missing something that will help.

I'm not talking about anything to do with gcc bugs.

ALOHA

 

[DasFox]

Nothinman it's far from pointless.

Ok I didn't hit on the issue of things being compiled as a module.

Now here is the problem with all modules compiled in.

Your hardware is suppose to support something, then it loads it at boot up, BUT the support isn't all the great for your hardware, or your hardware is flaky with dealing with this support and you have a problem.

ACPI is a FINE example of this.

NO just because everything is in as a module doesn't help, because poorly supported, or flaky hardware will still try to load and run these mods and cause problems.

That is why I also mentioned it's best to compile your own ESPECIALLY in cases like this.

If you've been around Linux for any length of time you should understand this very clearly.

There is no such thing as perfect hardware or a perfect kernel I never said there was and because of these issues with everything either compiled in or as a module people will run across issues with their hardware, and when they do, they need to compile a kernel to remove these problems. I've seen this all the time over the years since Linux has been around it's just the way it is.

ALOHA

 

[n0cmonkey]

Originally posted by: DasFox
What's a gcc bug?

I'm not talking about any gcc bugs, I'm talking about compiling options incorrect, or anding in hardware support that doesn't work as well as it should for your hardware or missing something that will help.

I'm not talking about anything to do with gcc bugs.

ALOHA

And you answered my question. Nothinman just provided a slightly different interpretation of your statement.

 

[Brazen]

Originally posted by: DasFox

Originally posted by: Cogman

Linux doesn't crash, do you guys even know what you are talking about?

Linux, or GNU/Linux, refers to any Unix-like computer operating system which uses the Linux kernel. It is one of the most prominent examples of open source development and free software; its underlying source code is available for anyone to use, modify, and redistribute freely.

wiki.

Basicly you are half right. Linux has a linux kernel just like windows has a windows kernel. to say windows crashed would probibly be wrong as well as the windows kernel is usually not what crashes but the application or some layer of application crashing.

BTW yes I do know what Im talking about, Ive used linux quite frequently (look at the avitar...)

Sorry don't mean to be rude here, what is your half right suppose to suggest? Where was I half wrong?

I think he was just being polite. I won't see anywhere you could've been considered right, either. I would have considered it more ownage, but he should have provided a link to be thorough.

 

[Nothinman]

I'm not talking about any gcc bugs, I'm talking about compiling options incorrect, or anding in hardware support that doesn't work as well as it should for your hardware or missing something that will help.

Most compiler options are overridden by the makefiles, if you go to the trouble to change them yourself you deserve what you get. And missing hardware support in a custom kernel is your own fault, that would be like not plugging in a mouse and then complaining that browsing the web is difficult.

ACPI is a FINE example of this.

I take if you've never heard of the 'acpi=off' kernel option?

NO just because everything is in as a module doesn't help, because poorly supported, or flaky hardware will still try to load and run these mods and cause problems.

If it's really that bad just add an alias to /etc/modprobe.d/aliases to disable it.

If you've been around Linux for any length of time you should understand this very clearly.

I understand that it's really rare these days to have a module be so broken that you have to compile it out for your system to work. Can you even name one module or one such piece of hardware besides ACPI which can be disable at runtime?

 

[DasFox]

Yes true you can go around and turn things off, disable mods at load up and OFF options in the boot up, BUT you won't know what to turn off or disable until you figure out what's going on.

Yes either way turning off, or recompile with options off, I guess it depends on what you favor.

Personally with experience a kernel recompile shutting off all things suspect with an experienced Linux user takes no more then 15 mins, that is why I suggested a recompile. You can accomplish just about as quick as going around turning off.

OH and why I would highly suggest a recompile is because go back in and look at one of these, one size fits all kernels with just about every option compiled as a module, there are many others a flaky system can load besides ACPI.

Off the top of my head I can't think of all the other ones that can also cause an issue but there are many, and this why by the time you figure them out and disable them, you could of recompiled a kernel.

There are many modules that can cause issues that get loaded, and going back in to the kernel looking them over trying to figure them out can be a long process, searching them out one by one. But if you're experienced with the kernel and know what works for you from previous attempts then you basically just do what you've done before, granted newer kernels have some newer options but then if you didn't use them before you won't again.

Sometimes it's easier to just do what you've done before, whether is a recompile or shutting things off. Just do what you've done before, and are comfortable with.

It's 50/50 call, some people will recompile, some will disable options it's whatever you find easier.

For me either way works.

ALOHA

 

[n0cmonkey]

Wow, I didn't realize there were so many broken Linux kernel drivers. Guess it's another reason to make me glad I use BSD. ;P

 

[DasFox]

Originally posted by: n0cmonkey
Wow, I didn't realize there were so many broken Linux kernel drivers. Guess it's another reason to make me glad I use BSD. ;P

I never said anything about broken mods. I said some kernel support might not support hardware that well, and that some hardware is just flaky is all.

BSD isn't any better in fact worse with hardware support. I had a nForce2 motherboard and right now FreeBSD support on that board isn't very good. That was one time I had kernel panics in BSD over hardware support.

Nope sorry Linux has better hardware support then BSD, actually I'm surprised as a Unix user you'd say such a thing or not even be aware that Linux has better hardware support over Unix?

Now what makes the differences here is Linux is putting more bleeding edge into their kernel over Unix, but if you stay away from that, or know how to use it, you don't run into problems.

ALOHA

 

[n0cmonkey]

Originally posted by: DasFox

Originally posted by: n0cmonkey
Wow, I didn't realize there were so many broken Linux kernel drivers. Guess it's another reason to make me glad I use BSD. ;P

I never said anything about broken mods. I said some kernel support might not support hardware that well, and that some hardware is just flaky is all.

BSD isn't any better in fact worse with hardware support. I had a nForce2 motherboard and right now FreeBSD support on that board isn't very good. That was one time I had kernel panics in BSD over hardware support.

Nope sorry Linux has better hardware support then BSD, actually I'm surprised as a Unix user you'd say such a thing or not even be aware that Linux has better hardware support over Unix?

ALOHA

I disagree. I think OpenBSD has better hardware support than Linux.

 

[DasFox]

n0cmonkey I'm sorry I'm not talking about my opinions or your opinions it's a fact in the Unix/Linux world that Linux has greater hardware support then Unix.

This isn't a shooting match over who said, this is just a proven fact, why don't you go out there and do some home work.

Yes true Unix has great support no one said they didn't, but if you think Unix supports a wider range of Hardware then Linux then you're in for a big surprise.

Now the only Unix FREE that is, as a BSD that supports a WIDE range of OS platforms is NetBSD, but that is PLATFORMS, again, not hardware either.

n0cmonkey how long have you been using Unix/Linux?


ALOHA

 

[DasFox]

Again so we're clear here, I'm talking about what system supports the, "Widest Range of Hardware", and that is Linux.

As far as system stability goes I personally think Unix has a better kernel, but if you know what you're doing then you can make a damm good Linux kernel perform just as well.

Now when you say Unix has better hardware support, what do you mean exactly?

Are you talking stability? A wide range of support for many types of hardware?

What?

ALOHA

 

[n0cmonkey]

I'm putting these two together to make replying easier.

Originally posted by: DasFox
n0cmonkey I'm sorry I'm not talking about my opinions or your opinions it's a fact in the Unix/Linux world that Linux has greater hardware support then Unix.

This isn't a shooting match over who said, this is just a proven fact, why don't you go out there and do some home work.

Yes true Unix has great support no one said they didn't, but if you think Unix supports a wider range of Hardware then Linux then you're in for a big surprise.

Now the only Unix FREE that is, as a BSD that supports a WIDE range of OS platforms is NetBSD, but that is PLATFORMS, again, not hardware either.

n0cmonkey how long have you been using Unix/Linux?


ALOHA

So you're saying that if I download the linux kernel from kernel.org it will provide support for:
ralink, atheros, PrismGT, Intel 3945, Marvell Libertas, TI ACX100/ACX111, and Realtek RTL8180 wireless adapters (in usb, cardbus, and various forms of PCI where available)?

Does it support 10Gb Ethernet? What about T1/E1 hardware?

And hardware platforms are important and do count. We're talking about the range of hardware supported right? (I'll go easy on ya) So, if I pick up a Mac SE30 I can run a vanilla kernel on it?

Again so we're clear here, I'm talking about what system supports the, "Widest Range of Hardware", and that is Linux.

As far as system stability goes I personally think Unix has a better kernel, but if you know what you're doing then you make a damm good Linux kernel perform just as well.

Now when you say Unix has better hardware support, what do you mean exactly?

ALOHA

I meant that OpenBSD supports my hardware out of the box, where as Linux generally does not.

Send me an nForce system, I'll give Open a shot on it.

EDIT:

Are you talking stability? A wide range of support for many types of hardware?

What?

Yes, and yes. Out of the box my systems are better supported through OpenBSD than through Linux. I've tried it.

 

[DasFox]

And one last thing if we're talking about the "Widest Range of Hardware" support and you thought that was BSD, if that was true gave the widest range, then everyone would be using them over Linux, and FreeBSD, NetBSD, OpenBSD, etc.. would be the Unix systems of choice, not Ubuntu, Fedora, Suse, Manriva, etc...

Linux is popular simply because it has better support, AGAIN across the widest range of hardware. Now at times for what hardware support Unix offers it might have better stability, but if you know what you are doing you can make Linux just as stable as Unix.

Slackware in the hands of the experienced is just as good as Unix when it comes to stability.

ALOHA

 

[DasFox]

Now your talking about DIFFERENT support. YES true what Unix supports doesn't mean Linux supports and vice versus.

But that still doesn't change the FACT that Linux SUPPORTS THE WIDEST RANGE OF HARDWARE OVER UNIX.

Sorry for caps not yelling just trying to get your attention to the facts is all.

Are we clear now?

ALOHA

 

[DasFox]

As for the nForce2 support on FreeBSD this is the board that has issues with FreeBSD, the Abit NF7-S2

http://www.abit-usa.com/products/mb/products.php?categories=1&model=204

Now this is Nforce2 yes old, but that's not the issue. The Nvidia series boards where well supported in Linux, and have been since they came out, yet for whatever reason the support for this board and from what I was also told by a FreeBSD developer is that Nvidia support in FreeBSD isn't that well supported yet.

Now look at how long Nvidia boards have been around and still to this date FreeBSD doesn't support them that good.

ALOHA

 

[Nothinman]

Yes true you can go around and turn things off, disable mods at load up and OFF options in the boot up, BUT you won't know what to turn off or disable until you figure out what's going on.

Same is true with recompiling only it'll take a lot longer to do the testing to figure out if you're right.

Personally with experience a kernel recompile shutting off all things suspect with an experienced Linux user takes no more then 15 mins, that is why I suggested a recompile. You can accomplish just about as quick as going around turning off.

I take it that 15 minutes doesn't include the compile time itself? A full kernel compile just took ~26m here and that's on a FX!60 with 2G memory. Using modules and just disabling them and recompiling will obviously be faster but if you're not using modules and are compiling everything in statically you'll be recompiling huge chunks of code whever you make changes.

Off the top of my head I can't think of all the other ones that can also cause an issue but there are many, and this why by the time you figure them out and disable them, you could of recompiled a kernel.

The reason you can't think of any is because there aren't many. 9 times out of 10 either the hardware works or it doesn't, it's pretty rare for a module to load and the crap out later. Even the IDE drivers which are unmaintained and have been for like half of the 2.6.x series work just fine. The only troublesome module I can think of that I've used is the rt2x00 ones because they're not SMP-safe, if you have more than one CPU they'll lock up on you pretty quick. But they're not in mainline either so they're even a bad example.

 

[DasFox]

Your blurring lines you said ----> So, if I pick up a Mac SE30 I can run a vanilla kernel on it?

A MAC is a OS platform, now that is different hardware on a different system, that's another story, so what are you talking about?

So what are we talking about now Architectures or hardware in general?

Again for the widest range of Architectures supported in Unix I said that is NetBSD

You don't have to go easy on me, I've been using Unix/Linux for 10 years I'm far from being a newbie.

ALOHA

 

[DasFox]

Originally posted by: Nothinman

Yes true you can go around and turn things off, disable mods at load up and OFF options in the boot up, BUT you won't know what to turn off or disable until you figure out what's going on.

Same is true with recompiling only it'll take a lot longer to do the testing to figure out if you're right.

Personally with experience a kernel recompile shutting off all things suspect with an experienced Linux user takes no more then 15 mins, that is why I suggested a recompile. You can accomplish just about as quick as going around turning off.

I take it that 15 minutes doesn't include the compile time itself? A full kernel compile just took ~26m here and that's on a FX!60 with 2G memory. Using modules and just disabling them and recompiling will obviously be faster but if you're not using modules and are compiling everything in statically you'll be recompiling huge chunks of code whever you make changes.

Off the top of my head I can't think of all the other ones that can also cause an issue but there are many, and this why by the time you figure them out and disable them, you could of recompiled a kernel.

The reason you can't think of any is because there aren't many. 9 times out of 10 either the hardware works or it doesn't, it's pretty rare for a module to load and the crap out later. Even the IDE drivers which are unmaintained and have been for like half of the 2.6.x series work just fine. The only troublesome module I can think of that I've used is the rt2x00 ones because they're not SMP-safe, if you have more than one CPU they'll lock up on you pretty quick. But they're not in mainline either so they're even a bad example.

Same is true with recompiling only it'll take a lot longer to do the testing to figure out if you're right.
I said before if you know what you're doing with compiling then you're not going to have to test anything.


I take it that 15 minutes doesn't include the compile time itself?
Well that depends on your system, and how much you compile in, yes I must admit that was not a fair average to say in time. Personally, but now that's my box and requirements, I can configure and compile ALL in like 10-15mins.

The reason you can't think of any is because there aren't many.
Sure there are, why because after using Linux 10 years you don't think I know by now, and you need me to start going off with a list of all of them?

I'm not on my Linux box, but maybe you better have another look at a kernel and go through what you might think are all the possibilities.

In numbers I can't say, but I can name off if I had to look over the kernel quite a few that can cause issues.

Now when you say troublesome modules, I'm not just talking about mods being the issue, I'm always talking about having flaky hardware even if the modules are all 100% correct.

I'll give you a hint, there is even in the kernel HELP section a module listed that says if you have FLAKY hardware not to use it.

ALOHA

 

[DasFox]

I've looked at every kernel version, and I've compiled every kernel version that has come out for the past 10 years, I know every piece of it. You should really look it over to see what all these possible problems could be.

Again this all gets down to not being a problem with a module, BUT ---> FLAKY HARDWARE.

With flaky hardware you'd be amazed at all the things in the kernel that could be a problem.

ALOHA

 

[Nothinman]

ralink, atheros, PrismGT, Intel 3945, Marvell Libertas, TI ACX100/ACX111, and Realtek RTL8180 wireless adapters (in usb, cardbus, and various forms of PCI where available)?

Does it support 10Gb Ethernet? What about T1/E1 hardware?

No, yes and not sure. If by T1/E1 hardware you're talking about WAN ports that support T1 frames, then yes but I don't know the extent of the support. But you picked wifi because you know it's an area that Linux is lacking compared to OpenBSD and it's probably the only area. Is there a driver for the broadcom wifi chipsets in OpenBSD yet?

So, if I pick up a Mac SE30 I can run a vanilla kernel on it?

Maybe, there is a m68k port but I can't imagine why you'd put yourself though the pain of using that machine.

I said before if you know what you're doing with compiling then you're not going to have to test anything.

Right, because you automatically know which module is causing the problem if you're compiling but if you're just disabling modules you don't?

Well that depends on your system, and how much you compile in, yes I must admit that was not a fair average to say in time. Personally, but now that's my box and requirements, I can configure and compile ALL in like 10-15mins.

Then you've either got a machine roughly twice as fast as mine or you're leaving out support for a lot of stuff. I turned up the build concurrency to 3 and got it down to 15m, but I still don't see a good reason for doing that. What happens if you buy some new hardware tomorrow? You've got to recompile again and hope you got everything required for it, it's just not worth it.

Sure there are, why because after using Linux 10 years you don't think I know by now, and you need me to start going off with a list of all of them?

I've been using Linux for almost as long as you and I don't seem to have half of the problems that you're worried about. If you had all of the problems that you say you did I would assume you'd have an anecdote or two to tell, I know I can come up with some.

Now when you say troublesome modules, I'm not just talking about mods being the issue, I'm always talking about having flaky hardware even if the modules are all 100% correct.

Flaky hardware doesn't count, if your hardware is suspect the software running on it can't be counted on to do anything reliably.

 

[DasFox]

Originally posted by: Nothinman

ralink, atheros, PrismGT, Intel 3945, Marvell Libertas, TI ACX100/ACX111, and Realtek RTL8180 wireless adapters (in usb, cardbus, and various forms of PCI where available)?

Does it support 10Gb Ethernet? What about T1/E1 hardware?

No, yes and not sure. If by T1/E1 hardware you're talking about WAN ports that support T1 frames, then yes but I don't know the extent of the support. But you picked wifi because you know it's an area that Linux is lacking compared to OpenBSD and it's probably the only area. Is there a driver for the broadcom wifi chipsets in OpenBSD yet?

So, if I pick up a Mac SE30 I can run a vanilla kernel on it?

Maybe, there is a m68k port but I can't imagine why you'd put yourself though the pain of using that machine.

I said before if you know what you're doing with compiling then you're not going to have to test anything.

Right, because you automatically know which module is causing the problem if you're compiling but if you're just disabling modules you don't?

No you don't because you can be a newbie that has a problem, asks for help and someone tells them to disable it this way. I was talking more from a background of compiling experience, where being a newbie you're not going to get away with this so easy.

Either way you can be a newbie getting help for disabling a mod or compiling the kernel, but it's not what I meant. Now just because you've complied the kernel, it's not going to mean you know every module by heart, so when you have a problem trying to track it down, it might turn into a bit of a hunt to figure it out and disable it. But if you compile what you know, what works, then you can escape this issue of doing a module hunt. Again this all really gets down to what you are comfortable doing.

Well that depends on your system, and how much you compile in, yes I must admit that was not a fair average to say in time. Personally, but now that's my box and requirements, I can configure and compile ALL in like 10-15mins.

Then you've either got a machine roughly twice as fast as mine or you're leaving out support for a lot of stuff. I turned up the build concurrency to 3 and got it down to 15m, but I still don't see a good reason for doing that. What happens if you buy some new hardware tomorrow? You've got to recompile again and hope you got everything required for it, it's just not worth it.

AMD XP 3000+ I just don't use or need a lot of things in the computer for what I use Linux for. And for a recompile being not worth it, well that really gets down to someones experience level. When you've compiled year after year almost day in and day out, it's no worse then compiling a piece of software, this just depends on experience. People can recompile a box on new hardware with experience in 20-30 mins.

Sure there are, why because after using Linux 10 years you don't think I know by now, and you need me to start going off with a list of all of them?

I've been using Linux for almost as long as you and I don't seem to have half of the problems that you're worried about. If you had all of the problems that you say you did I would assume you'd have an anecdote or two to tell, I know I can come up with some.

Bugs, flaky hardware, etc.. don't excuse the facts that even though they don't happen for everyone means it should be totally dismissed. They are bugs for a reason because they are there, some more then others and flaky hardware and not perfect software will always be around. All the problems I'm worried about? LOL. Have you ever used the IRC Freenode network?

If you have then you know I'm not the only one that sees problems all the time. I've been on Freenode when it started from the beginning when it was the Open Projects Network.

It the past I wasn't just your average Linux user I was the hardcore geek 24/7 and I use to run a Slackware support site, building custom slackpacks for Slackware.

For almost 7 years I use to give Linux support, and let me tell you there are thousands of people on a daily basis that have issues. This has nothing to do with worry, it's just a fact of life with hardware and software and Linux is no exception when it comes to this.

Now when you say troublesome modules, I'm not just talking about mods being the issue, I'm always talking about having flaky hardware even if the modules are all 100% correct.

Flaky hardware doesn't count, if your hardware is suspect the software running on it can't be counted on to do anything reliably.

Sure flaky hardware counts, I didn't mean to say this meant Linux was a problem, that's not the point. I'm just saying when you are using hardware that doesn't work well then you have to change things around sometimes to get past the problem is all, and there will be many times people will have hardware that isn't the best and Linux is giving them issues, and they're not sure what's going on, bad software, bad kernel, or their hardware, that's all I meant

ALOHA

 

[Brazen]

Originally posted by: DasFox

I said before if you know what you're doing with compiling then you're not going to have to test anything.

:laugh::laugh::laugh:

 

[DasFox]

Originally posted by: Brazen

Originally posted by: DasFox

I said before if you know what you're doing with compiling then you're not going to have to test anything.

:laugh::laugh::laugh:

Brazen, LOL

Are you laughing at me, or with me?

Honestly in 7 years of compiling I've never once had to test anything, but then again I've compiled my ass off with kernels and software almost 24/7 for the past 7 years too, so compiling a kernel or software isn't an issue for me.

ALOHA

 

[Brazen]

well, I guess if you are not admin'ing servers, you can get away with that. In my world though, you test test test test everything. I probably think it's especially funny, because a guy here always says testing is a waste of time if you already know how the software works... I've cleaned up a lot of his messes.

I remember just a few weeks ago I overheard him saying he was going to go do something on the SQL server (he is not supposed to touch the servers, but he is the bosses lap-dog so anyway). I asked him about it and told him I don't think that would be a good idea and if he gave me a few days I can have a test environment set up for him. He said, "ok" like he was going to do what I say. 5 minutes later, the SQL server was dead.

 

[Nothinman]

But if you compile what you know, what works, then you can escape this issue of doing a module hunt.

But if you have hardware for the module that's causing you problems chances are that you're going to compile it at least once before you notice the problem.

Bugs, flaky hardware, etc.. don't excuse the facts that even though they don't happen for everyone means it should be totally dismissed.

I know, but in that regard it's not the kernel's fault and chances are you'll have a much harder time figuring out what's wrong. Have you seen the lkml thread about the buggy IOMMU's on some AM64 boards? If you have flaky hardware and there isn't a workaround in Linux yet, then you probably just plain don't want to use Linux on that hardware yet.

When you've compiled year after year almost day in and day out, it's no worse then compiling a piece of software, this just depends on experience.

And in both cases I consider it a waste of time, I use a distribution with binary packages for a reason. I don't want to waste my time compiling things that other people, who usually know the software better than I, already do for me.

I'll give you a hint, there is even in the kernel HELP section a module listed that says if you have FLAKY hardware not to use it.

I just looked through the source for kernel 2.6.18 and the only mention I can find in the kbuild help is in drivers/ide/Kconfig and it's only for the automatic DMA tuning for IDE devices and the fact that the help mentions kernel 2.1.112 will tell you just how old the warning really is.