Re: Argh, Stray interrupts 2006
--- Scott Ullrich [EMAIL PROTECTED] wrote: Scott Ullrich wrote: Gergo Szakal wrote: FYI, the leader of m0n0wall, talking about the feature of his OS mentioned that DragonFlyBSD is not even taken into consideration by him to base his system on, 'cause it's 'desktop oriented.' Actually that is partially untrue. Fred Wright said this... Sorry, meant to show the URL: http://m0n0.ch/wall/list-dev/showmsg.php?id=12/75 this guy needs to come up for air and join the 21st century. Most of his ideas are 10 years out of date. Without tearing him to shreds bit by bit, the commercial pull of using *nix for routing is that the economies of scale of using off-the-shelf PC hardware allow you to use so much horsepower for such a small amount of money (relative to dedicated hardware solutions), that the inefficiencies of the design become a positive. Rather than running microkernels on stripped down hardware, you can run full-featured systems and they perform as well or even better than dedicated hardware solutions, for 1/3 the cost. Once you go to specialized hardware, you've lost the key advantage of using the free OS in the first place, which is the rich feature set of the entire O/S. Everything he says is exactly backwards. And the whole fanless, diskless moving parts BS is just so stupid I can't stand it. Its like a bunch of college kids sitting around thinking of things to complain about. The guy is using crap hardware, stripped down os and has to put all the design effort into shrinking everything down, and for what? To avoid one failure every 2-3 years? Its just plain stupid, both fiscally and from an engineering standpoint. The guy is still living in the MFM, $2 fan days. I have 1000s of systems in the field with like zero failures. Build the system right and modern hardware doesn't fail that easily. He's also not looking for performance, so you can't expect him to get excited about MP. And why is he whining about driver support? On an appliance type platform you only need a few drivers to work well. Who cares if the mobo-wonder ethernet card is supported or not? DT __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Argh, Stray interrupts 2006
--- W B Hacker [EMAIL PROTECTED] wrote: Danial Thom wrote: Same as always: 1) ALT-F2 (3, 4, etc.) before logging in. 2) Edit /etc/syslog.conf to send soem/all console messages elsewhere - after which (1) is no longer necessary. Bill Thats not really a solution - you asked for a 'workaround'. This is such. Covering your ears is not a workaround. I know I've been told that its a bios configuration problem, Actually a MB wiring (PCB trace) or *bridge design flaw that a BIOS has to work around. Used to occur much more frequently, and with OS/2 and Slackware as well as 3.X and early 4.X *BSD. however I don't get stray interrupts if I pop a FreeBSD disk on the exact same hardware. *BSD added a workaround somewhere around 4.6 IIRC. - Prior to that, one had to either swap MB, (*BSD) or set printing to polled, not interrupt-driven (OS/2). At one time, some MB even had the problem on the TTY ports, i.e. - shortly after rebooting from install, the console simply streamed IRQ error messages from getty. So why is it a misconfiguration in DFLY but not in FreeBSD? Probably becasue current drivers no longer use a (supposedly) obsolete workaround. One would have to inspect the par Port drivers with T86 (or some other trace tool) to ID it - then a binary patch should be all that it takes to fix it (the drivers involved are dirt-simple, about 240 Bytes in FORTH, perhaps 2K in ASM source ~ 1K in machine-code) - but I last wrote such for the George Morrow Design 'Empire' S-100 I/O board - which used the same chips for Serial and parallel later adopted for the IBM PC-1, just different base addresses. Same FORTH code ran on the PC1 thru AT, (112 Kbps serial when IBM was limited to 9.6 or 19.2 Kbps). - TRY THIS: - enter the BIOS and *disable* the parallel port. - if no joy, also disable any on-board sound. There is no parallel port on the machine. A lot of new motherboards are eliminating it. There is also no sound card or on-board audio. Its a server for pete's sake! Too often, some idjut has made the support I/O inter-dependent, or has such anomalies in the BIOS. Nobody seems to work in machine-code anymore, and that is the best way to do this low-level stuff w/o surprises. What MB are you using, and whose name is on the bIOS? Its a Supermicro H8SSL-i. Im not sure of the bios, the machine is quite far away from me at the moment. DT __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Argh, Stray interrupts 2006
:And the whole fanless, diskless moving parts BS :is just so stupid I can't stand it. Its like a :bunch of college kids sitting around thinking of :things to complain about. The guy is using crap :hardware, stripped down os and has to put all the :design effort into shrinking everything down, and :for what? To avoid one failure every 2-3 years? :Its just plain stupid, both fiscally and from an :engineering standpoint. The guy is still living :in the MFM, $2 fan days. I have 1000s of systems :in the field with like zero failures. Build the :system right and modern hardware doesn't fail :that easily. Thousands, eh? So, million's of dollars and thousands of unspecified installed piece of equipment. And, what is it EXACTLY that you do, Danial? Because you don't seem to know the most basic facts about field installations and hardware longevity. But I certainly do. I have equipment that has been operating at a major utility district at Lake Tahoe for 20 years. Not 1 year, not 2 years, not 5 years... *20* years, and I can tell you with some assurance that Fanless and Diskless makes a *HUGE* difference in hardware longevity and maintainance requirements. Using a dedicated micro operating system also makes a huge difference when you need to measure uptime in years rather then months. It is absolutely and most definitively *NOT* BS. In anycase, this is yet another ridiculous twisting of the facts. You seem to twist facts quite often to fit your view of reality. Maybe you should actually try *UNDERSTANDING* other people's viewpoints before you insult them. -Matt
Re: Argh, Stray interrupts 2006
--- Matthew Dillon [EMAIL PROTECTED] wrote: :And the whole fanless, diskless moving parts BS :is just so stupid I can't stand it. Its like a :bunch of college kids sitting around thinking of :things to complain about. The guy is using crap :hardware, stripped down os and has to put all the :design effort into shrinking everything down, and :for what? To avoid one failure every 2-3 years? :Its just plain stupid, both fiscally and from an :engineering standpoint. The guy is still living :in the MFM, $2 fan days. I have 1000s of systems :in the field with like zero failures. Build the :system right and modern hardware doesn't fail :that easily. Thousands, eh? So, million's of dollars and thousands of unspecified installed piece of equipment. And, what is it EXACTLY that you do, Danial? Because you don't seem to know the most basic facts about field installations and hardware longevity. But I certainly do. I have equipment that has been operating at a major utility district at Lake Tahoe for 20 years. Not 1 year, not 2 years, not 5 years... *20* years, and I can tell you with some assurance that Fanless and Diskless makes a *HUGE* difference in hardware longevity and maintainance requirements. Using a dedicated micro operating system also makes a huge difference when you need to measure uptime in years rather then months. It is absolutely and most definitively *NOT* BS. In anycase, this is yet another ridiculous twisting of the facts. You seem to twist facts quite often to fit your view of reality. Maybe you should actually try *UNDERSTANDING* other people's viewpoints before you insult them. know the basics? How many network appliances have you sold on modern hardware? You still think the PCI-X bus is new for pete's sake. I have about 2000 boxes in the field with Celerons, P4s and Opterons with blowers and IDE hard drives and guess how many of them have come back in the last 2 years? Zippo. Its clowns like you that convince other clowns that things that might have mattered 10 years ago still matter. Who out there are running fanless servers? Nobody. How many of the guys that reported dragonfly uptimes of a year are running on fanless, diskless systems? None of them. The entire concept is a joke conceived by guys who live in a Lab like yourself. Yes, millions of dollars. And the reason is that you can't push 500K pps with a box without a fan or a disk. You have to make too many trade offs, and for no reason whatsoever. The features and functionality you get by using a large disk drive by far outweighs the negatives. The corporate world is not a science project where you get points for doing cool shit. Its about making decisions that make sense. I can't remember the last time I lost a sale because some buffoon required no moving parts. Thats like so 1998. People aren't that stupid. DT __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Argh, Stray interrupts 2006
Danial Thom wrote: My tech tried firing up 1.4 on an opteron MB with an HT1000 chipset and, although it seems to work, the console is literally flooding with stray irq 7 messages. Freebsd at least suppressed these after a few, but when is someone actually going to FIX this in BSD? Someone told me years ago that this was an Intel chipset bug and there was nothing that could be done, but clearly that isn't the case here. whats the workaround solution as the console is unusable in its current state? DT Same as always: 1) ALT-F2 (3, 4, etc.) before logging in. 2) Edit /etc/syslog.conf to send soem/all console messages elsewhere - after which (1) is no longer necessary. Bill
Re: Argh, Stray interrupts 2006
On 6/3/06, Danial Thom [EMAIL PROTECTED] wrote: --- Bill Hacker [EMAIL PROTECTED] wrote: Danial Thom wrote: My tech tried firing up 1.4 on an opteron MB with an HT1000 chipset and, although it seems to work, the console is literally flooding with stray irq 7 messages. Freebsd at least suppressed these after a few, but when is someone actually going to FIX this in BSD? Someone told me years ago that this was an Intel chipset bug and there was nothing that could be done, but clearly that isn't the case here. whats the workaround solution as the console is unusable in its current state? DT Same as always: 1) ALT-F2 (3, 4, etc.) before logging in. 2) Edit /etc/syslog.conf to send soem/all console messages elsewhere - after which (1) is no longer necessary. Bill Thats not really a solution as I don't want a system thats processing 100s of interrupts per second for no reason. I previously reported that these were gone, but now that I put another card in the box (a dual port intel ethernet), they're back. I know I've been told that its a bios configuration problem, however I don't get stray interrupts if I pop a FreeBSD disk on the exact same hardware. So why is it a misconfiguration in DFLY but not in FreeBSD? http://www.myspace.com/danialt - is this you ? DT __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it.
Re: Argh, Stray interrupts 2006
:Thats not really a solution as I don't want a :system thats processing 100s of interrupts per :second for no reason. I previously reported that :these were gone, but now that I put another card :in the box (a dual port intel ethernet), they're :back. : :I know I've been told that its a bios :configuration problem, however I don't get stray :interrupts if I pop a FreeBSD disk on the exact :same hardware. So why is it a misconfiguration in :DFLY but not in FreeBSD? : :DT I like how you always twist things so it's somehow our fault. The BIOS/MB issue is that some motherboards route all system interrupts to a single PIC IRQ line in order to allow the BIOS to implement things like USB keyboard support and NetBoot during boot. The chipset manufacturers do not publish how to turn it off, and on some motherboards there is no way to turn it off short of turning off the PIC itself, and even then it is sometimes not possible to turn it off. It might be possible to bypass the issue using the SMP + APIC_IO option, but chipset vendors have also had the keen idea of doing the same sort of shit for IOAPIC interrupts too. Some of Intel's own chipsets completely break IOAPIC pin masking by causing the chip to route to a default vector if a pin is masked. Sometimes it is possible to bypass the problem by not using IOAPIC interrupt masking (and sometimes it isn't), and sometimes it is possible to bypass the problem by masking the pin representing the default vector. Or not. FreeBSD has recently moved away from using the PIC alltogether, primarily by using the LAPIC timer instead of the i2854. I think its a good idea, but it represents quite a chunk of work. It may or may not solve this particular issue (it is just one of many related to broken BIOSes and motherboards that pop up). In anycase, if you want to solve the problem the source code is right there, start coding! You seem to want to simplify problems down to one-liner's, and blame us for all your woes in the process, but the reality is that it is a far more complex issue then you seem to want to believe. -Matt
Re: Argh, Stray interrupts 2006
--- Matthew Dillon [EMAIL PROTECTED] wrote: :Thats not really a solution as I don't want a :system thats processing 100s of interrupts per :second for no reason. I previously reported that :these were gone, but now that I put another card :in the box (a dual port intel ethernet), they're :back. : :I know I've been told that its a bios :configuration problem, however I don't get stray :interrupts if I pop a FreeBSD disk on the exact :same hardware. So why is it a misconfiguration in :DFLY but not in FreeBSD? : :DT I like how you always twist things so it's somehow our fault. The BIOS/MB issue is that some motherboards route all system interrupts to a single PIC IRQ line in order to allow the BIOS to implement things like USB keyboard support and NetBoot during boot. The chipset manufacturers do not publish how to turn it off, and on some motherboards there is no way to turn it off short of turning off the PIC itself, and even then it is sometimes not possible to turn it off. It might be possible to bypass the issue using the SMP + APIC_IO option, but chipset vendors have also had the keen idea of doing the same sort of shit for IOAPIC interrupts too. Some of Intel's own chipsets completely break IOAPIC pin masking by causing the chip to route to a default vector if a pin is masked. Sometimes it is possible to bypass the problem by not using IOAPIC interrupt masking (and sometimes it isn't), and sometimes it is possible to bypass the problem by masking the pin representing the default vector. Or not. FreeBSD has recently moved away from using the PIC alltogether, primarily by using the LAPIC timer instead of the i2854. I think its a good idea, but it represents quite a chunk of work. It may or may not solve this particular issue (it is just one of many related to broken BIOSes and motherboards that pop up). In anycase, if you want to solve the problem the source code is right there, start coding! You seem to want to simplify problems down to one-liner's, and blame us for all your woes in the process, but the reality is that it is a far more complex issue then you seem to want to believe. You can call it twisting, but your OS is based on Freebsd 4.8, and it doesn't happen with FreeBSD 4.9. So unless its something that they fixed in 4.9, its likely something that you folks changed or do differently. In fact I've never seen so MANY stray interrupts on any box on any OS in the 23 years or so that I've been using one un*x or another. Not to be negative, but those are the facts. My view is that its the responsibility of the programmer to mask hardware quirks and bios bugs. You don't explain that an ethernet controller has a bug so it locks up all the time; you figure out a way to make it so that it either doesn't lock up or so that it is restarts as tranparently as possible. Lazy programmers complain about how difficult it is to do things, and good ones come up with solutions. Its fairly clear that whatever the bug is, you've made it worse, or removed some work-around. As more and more people use DFLY, you'll spend more and more time explaining to people that its not your fault. Its probably less effort in the long run to just figure something out that corrects it. Turning on SMP stopped the stray irq messages. I get one stray IRQ message immediately after loading the acpi.ko module, and then no more. If you think of something that might fix it in UP mode, I'm happy to try it out. Is there a performance cost of running an smp kernel on a UP machine? I don't intend to run DFLY UP anyway, but just interested in knowing if it shuts off the SMP modes when only 1 cpu is detected. DT Its been suggested that I turn acpi off, and there doesn't seem to be a toggle in the bios, and dfly insists on loading the module __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Argh, Stray interrupts 2006
These comments are really unfair. You have to consider that people who work on projects like DFly or FreeBSD - they dont have access to every single motherboard every made. And the Bios quirks can be like fixing leaky pipes. You fix a leak in one spot, and it causes a new leak somewhere else. People who decide to use OS's like FreeBSD, NetBSD, DFly, etc.,. have to understand that compatibility is not gauranteed. If you want that, go with Solaris or Windows. I just built a system for a customer. I had to go through 3 different motherboards. The first two simple wouldn't work on FreeBSD. Things have changed, the old PII and PIII days are gone. Chipsets and Bios's are getting more and more complex, and more separate. Shit, back in the late 90's - several motherboard manufactures all used the same Bios and all used the same 2 or 3 available chipsets. Nowaday's, every motherboard bios is different, every chipset is different, motherboards themselves are phased out faster. I bought some real nice Tyan single P4 boards back in 8/05, 64bit PCI - real nice - real compatible. Tyan stopped making them after 4 months, and replaced them with something else with a new chipset. I sure hope nobody wasted time in tweaking code for those boards! -John On Jun 3, 2006, at 2:16 PM, Danial Thom wrote: --- Matthew Dillon [EMAIL PROTECTED] wrote: :Thats not really a solution as I don't want a :system thats processing 100s of interrupts per :second for no reason. I previously reported that :these were gone, but now that I put another card :in the box (a dual port intel ethernet), they're :back. : :I know I've been told that its a bios :configuration problem, however I don't get stray :interrupts if I pop a FreeBSD disk on the exact :same hardware. So why is it a misconfiguration in :DFLY but not in FreeBSD? : :DT I like how you always twist things so it's somehow our fault. The BIOS/MB issue is that some motherboards route all system interrupts to a single PIC IRQ line in order to allow the BIOS to implement things like USB keyboard support and NetBoot during boot. The chipset manufacturers do not publish how to turn it off, and on some motherboards there is no way to turn it off short of turning off the PIC itself, and even then it is sometimes not possible to turn it off. It might be possible to bypass the issue using the SMP + APIC_IO option, but chipset vendors have also had the keen idea of doing the same sort of shit for IOAPIC interrupts too. Some of Intel's own chipsets completely break IOAPIC pin masking by causing the chip to route to a default vector if a pin is masked. Sometimes it is possible to bypass the problem by not using IOAPIC interrupt masking (and sometimes it isn't), and sometimes it is possible to bypass the problem by masking the pin representing the default vector. Or not. FreeBSD has recently moved away from using the PIC alltogether, primarily by using the LAPIC timer instead of the i2854. I think its a good idea, but it represents quite a chunk of work. It may or may not solve this particular issue (it is just one of many related to broken BIOSes and motherboards that pop up). In anycase, if you want to solve the problem the source code is right there, start coding! You seem to want to simplify problems down to one-liner's, and blame us for all your woes in the process, but the reality is that it is a far more complex issue then you seem to want to believe. You can call it twisting, but your OS is based on Freebsd 4.8, and it doesn't happen with FreeBSD 4.9. So unless its something that they fixed in 4.9, its likely something that you folks changed or do differently. In fact I've never seen so MANY stray interrupts on any box on any OS in the 23 years or so that I've been using one un*x or another. Not to be negative, but those are the facts. My view is that its the responsibility of the programmer to mask hardware quirks and bios bugs. You don't explain that an ethernet controller has a bug so it locks up all the time; you figure out a way to make it so that it either doesn't lock up or so that it is restarts as tranparently as possible. Lazy programmers complain about how difficult it is to do things, and good ones come up with solutions. Its fairly clear that whatever the bug is, you've made it worse, or removed some work-around. As more and more people use DFLY, you'll spend more and more time explaining to people that its not your fault. Its probably less effort in the long run to just figure something out that corrects it. Turning on SMP stopped the stray irq messages. I get one stray IRQ message immediately after loading the acpi.ko module, and then no more. If you think of something that might fix it in UP mode, I'm happy to try it out. Is there a performance cost of running an smp kernel on a UP machine? I don't intend to run DFLY UP anyway, but
Re: Argh, Stray interrupts 2006
O_o You guys sure waste a lot of time on trolls. Too bad Danial didn't post any official title, he's starting to remind me of the Jerry Taylor incident. It's pretty clear this guy is too ignorant to have 23 years of life experience, let alone that much time using unixes. I vote for the ban :) - BC
Re: Argh, Stray interrupts 2006
Thats why you need a substantial staff to do what you're attempting to do. Whats going to happen when your customer base grows to beyond the 32 guys who think you're God? You've clearly made the problem worse, and you'll have to decide whether you want to fix it, or have people reject using your OS. Thats what product development is all about. People don't want to hear why it doesn't work right. They just want it to work. At some point you'll have to come to terms with that, or you'll fail. DT --- Matthew Dillon [EMAIL PROTECTED] wrote: Er. Danial, you are just being an idiot now. Programmers are lazy? Why don't YOU try to reverse engineer an ethernet card with half a dozen HARDWARE bugs in it without vendor documentation! Vendors not only do not provide documentation, they also tend to hide hardware bugs and deny their existance. In fact, *MOST* general purpose PC chipsets these days are chock full of hardware bugs, nearly ALL undocumented by the vendor. Vendors come out with chip revs every other month, each with their own set of quirks. There are over *200* ATA chipsets out there, probably even more, and just as many ethernet chipsets. Hundreds of chipsets containing tens of hundreds of undocumented hardware bugs. Buggy BIOSes. Buggy firmware. Even buggy CPUs (but at least Intel and AMD document those bugs)! You seem to believe that this stuff is somehow easy to figure out. And, worse, you seem to believe that we somehow have an obligation to drop everything at your whim and spend all our time solving your problems. Well, I got news for you... it is NOT easy to figure out, and we have no such obligation. Open source works because the people involved are willing to spend their own time and money solving problems, and because both programmers and users alike enjoy a sense of community. EVERYONE works hard to achieve their goals. But you don't seem to think that you have any obligation at all as an end-user. You seem to believe that you can denigrate people and make accusations, call people lazy, etc etc etc, and you STILL expect people to solve your problems? That's pretty stupid, dude! I will tell you straight out that I have no desire whatsoever to help you. In fact, I am very close to banning you from the mailing lists alltogether because you are becoming seriously harmful to our community. You seem to believe that you are somehow owed help and that you don't have to give anything back in return (not even a friendly conversation, apparently). You seem to believe that a programmer can sit down and in a few hour solve your worst nightmare of a problem, and you seem to believe that you can put down people and then still expect them to drop everything to help you. You seem to believe that hardware is somehow simple and obvious and easy to decipher. Well, I got news for you, Danial. That isn't reality. The reality is that sometimes the simplest bug.. a one line error in code for example, is the hardest to find. The reality is that the 60 seconds you spend in your armchair writing out yet another stupid email is nothing compared to the MAN-WEEKS it can sometimes take a real programmer to track down a bug. The reality is that third party vendors in the general purpose PC arena don't give a flying crap about open source or open operating systems and tend to be more interested in covering their own asses then in actually producing reliable hardware. The reality is that hardware is COMPLEX. Do you think an ethernet chipset just pushes packets and pulls packets in? That's just the tip of the iceberg. That isn't reality. If you want your problems solved, then you have to get down and dirty and help track them down on your own time. And I'm not talking about spending 60 seconds writing yet another armchair email. I'm talking about dedicating real time to solving your problems, just like *WE* do. And that is my last word on the subject. -Matt __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Argh, Stray interrupts 2006
On 6/4/06, Ben Cadieux [EMAIL PROTECTED] wrote: O_o You guys sure waste a lot of time on trolls. Too bad Danial didn't post any official title, he's starting to remind me of the Jerry Taylor incident. It's pretty clear this guy is too ignorant to have 23 years of life experience, let alone that much time using unixes. Let's do detective work! He seems to have first appeared (at least by Google's omniscient perception) around about here: http://lkml.org/lkml/2005/9/20/129 This is a typical we've broken XYZ so let's start developing hacks lkml thread. He participated with less harassment intensity than here, but a little nonetheless. I think that case was justified. Shortly after (well ok, three months), he posted here: http://leaf.dragonflybsd.org/mailarchive/users/2005-12/msg7.html This is on a surprisingly similar topic, so I figured it was something close to his heart. Still no abuse! He might not be a pure troll. http://leaf.dragonflybsd.org/mailarchive/users/2005-12/msg00017.html Arguing with Matt. It happens I suppose. Maybe he does know something, who knows? http://leaf.dragonflybsd.org/mailarchive/users/2005-12/msg00108.html Now that's insulting. So his modus operandi is changing. At first he made seemingly innocuous responses in other threads (there are probably more, that's the first example I found, and it's a good one) and escalated to insults as soon as it seemed to him that he could undermine a core developer. Now he goes out and starts escalating in a fresh thread. He's a troll, but a devious one, and probably actually knows something. He *doesn't* know that there is no point in DragonFly working to be a user-friendly desktop OS now, since such efforts often get in the way of Real Work like the heroic effort Matt has applied to the kernel architecture, and so would defeat the point of DragonFly. We already have DesktopBSD and PC-BSD, and they're comparable to Linux in overall quality, so what's the problem? A lot of corporations and zealots won't take up anything with a BSD license because of the past brain-dead GPL preaching of ESR and RMS, and no level of awesome installer will change their minds. If people voluntarily used Linux instead of BSD back when Linux was barely usable for anything at all (http://www.spatula.net/proc/linux/index.src), who could reasonably expect that the situation will reverse now, when Linux has billions of dollars of momentum towards becoming usable, and BSDs are still focusing on the much less marketable task of actually working properly? Heck, in a perfect world, users wouldn't have been brain-damaged by Microsoft and Apple and their ideas for how an interface should work, which is clearly the polar opposite of anything actually usable. Then BSDs and other real unices would be the natural choice because of their grand devotion to sanity and maintainability. But because users expect the same level of brokeness, security holes and frequent architectural failures of Windows in everything they run these days, they must turn to Linux distributions to suit their expectations. Put someone like that in front of a truly stable, logical and secure operating system and they think it's smoke and mirrors. Bah. -- Dmitri Nikulin
Re: Argh, Stray interrupts 2006
On Sun, 4 Jun 2006 08:50:25 +1000 Dmitri Nikulin [EMAIL PROTECTED] wrote: there is no point in DragonFly working to be a user-friendly desktop OS now, since such efforts often get in the way of Real Work like the heroic effort Matt has applied to the kernel architecture, and so would defeat the point of DragonFly. We already have DesktopBSD and PC-BSD, and they're comparable to Linux in overall quality, so what's the problem? FYI, the leader of m0n0wall, talking about the feature of his OS mentioned that DragonFlyBSD is not even taken into consideration by him to base his system on, 'cause it's 'desktop oriented.'
Re: Argh, Stray interrupts 2006
Talk about wasting a lot of time! lol --- Dmitri Nikulin [EMAIL PROTECTED] wrote: On 6/4/06, Ben Cadieux [EMAIL PROTECTED] wrote: O_o You guys sure waste a lot of time on trolls. Too bad Danial didn't post any official title, he's starting to remind me of the Jerry Taylor incident. It's pretty clear this guy is too ignorant to have 23 years of life experience, let alone that much time using unixes. Let's do detective work! He seems to have first appeared (at least by Google's omniscient perception) around about here: http://lkml.org/lkml/2005/9/20/129 This is a typical we've broken XYZ so let's start developing hacks lkml thread. He participated with less harassment intensity than here, but a little nonetheless. I think that case was justified. Shortly after (well ok, three months), he posted here: http://leaf.dragonflybsd.org/mailarchive/users/2005-12/msg7.html This is on a surprisingly similar topic, so I figured it was something close to his heart. Still no abuse! He might not be a pure troll. http://leaf.dragonflybsd.org/mailarchive/users/2005-12/msg00017.html Arguing with Matt. It happens I suppose. Maybe he does know something, who knows? http://leaf.dragonflybsd.org/mailarchive/users/2005-12/msg00108.html Now that's insulting. So his modus operandi is changing. At first he made seemingly innocuous responses in other threads (there are probably more, that's the first example I found, and it's a good one) and escalated to insults as soon as it seemed to him that he could undermine a core developer. Now he goes out and starts escalating in a fresh thread. He's a troll, but a devious one, and probably actually knows something. He *doesn't* know that there is no point in DragonFly working to be a user-friendly desktop OS now, since such efforts often get in the way of Real Work like the heroic effort Matt has applied to the kernel architecture, and so would defeat the point of DragonFly. We already have DesktopBSD and PC-BSD, and they're comparable to Linux in overall quality, so what's the problem? A lot of corporations and zealots won't take up anything with a BSD license because of the past brain-dead GPL preaching of ESR and RMS, and no level of awesome installer will change their minds. If people voluntarily used Linux instead of BSD back when Linux was barely usable for anything at all (http://www.spatula.net/proc/linux/index.src), who could reasonably expect that the situation will reverse now, when Linux has billions of dollars of momentum towards becoming usable, and BSDs are still focusing on the much less marketable task of actually working properly? Heck, in a perfect world, users wouldn't have been brain-damaged by Microsoft and Apple and their ideas for how an interface should work, which is clearly the polar opposite of anything actually usable. Then BSDs and other real unices would be the natural choice because of their grand devotion to sanity and maintainability. But because users expect the same level of brokeness, security holes and frequent architectural failures of Windows in everything they run these days, they must turn to Linux distributions to suit their expectations. Put someone like that in front of a truly stable, logical and secure operating system and they think it's smoke and mirrors. Bah. -- Dmitri Nikulin __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Argh, Stray interrupts 2006
Gergo Szakal wrote: FYI, the leader of m0n0wall, talking about the feature of his OS mentioned that DragonFlyBSD is not even taken into consideration by him to base his system on, 'cause it's 'desktop oriented.' Actually that is partially untrue. Fred Wright said this... Manuel still hasn't really weighed in on DragonFly from what I have gathered. And you can say that I somewhat pay close attention to m0n0wall due to starting the pfSense project ;) At any rate, this is now getting way off topic, sorry for the noise. Scott
Re: Argh, Stray interrupts 2006
Scott Ullrich wrote: Gergo Szakal wrote: FYI, the leader of m0n0wall, talking about the feature of his OS mentioned that DragonFlyBSD is not even taken into consideration by him to base his system on, 'cause it's 'desktop oriented.' Actually that is partially untrue. Fred Wright said this... Sorry, meant to show the URL: http://m0n0.ch/wall/list-dev/showmsg.php?id=12/75 Manuel still hasn't really weighed in on DragonFly from what I have gathered. And you can say that I somewhat pay close attention to m0n0wall due to starting the pfSense project ;) At any rate, this is now getting way off topic, sorry for the noise. Scott
Re: Argh, Stray interrupts 2006
On 2006-06-01 15:49, Danial Thom wrote: My tech tried firing up 1.4 on an opteron MB with an HT1000 chipset and, although it seems to work, the console is literally flooding with stray irq 7 messages. Freebsd at least suppressed these after a few, but when is someone actually going to FIX this in BSD? Someone told me years ago that this was an Intel chipset bug and there was nothing that could be done, but clearly that isn't the case here. whats the workaround solution as the console is unusable in its current state? Tried booting with ACPI disabled? Erik Wikström -- I have always wished for my computer to be as easy to use as my telephone; my wish has come true because I can no longer figure out how to use my telephone -- Bjarne Stroustrup
Re: Argh, Stray interrupts 2006
A flood of stray irq 7 messages is typically indicative of a BIOS SMP configuration problem. It usually means that the PIC is sending EXT interrupt acknowledgement requests to several cpus at once (or to one dual-core cpu), and the BIOS hasn't setup the hardware to properly direct the interrupts to just one cpu pin. What happens is that one cpu acks the interrupt and clears the pending bit, then the other cpu tries to ack the no longer pending interrupt and gets the stray interrupt vector. The stray interrupt vector is typically an undocumented hardware vector number, usually 7 or 15. Hence stray irq 7's. If you are running dual-core cpu's you can try adding this option to work around the BIOS misconfiguration: options CPU_AMD64X2_INTR_SPAM But it may not work on opterons. The problem is most commonly on systems with DUAL-CORE cpu's and BIOSes that don't quite configure them properly. -Matt
Re: Argh, Stray interrupts 2006
--- Erik Wikström [EMAIL PROTECTED] wrote: On 2006-06-01 15:49, Danial Thom wrote: My tech tried firing up 1.4 on an opteron MB with an HT1000 chipset and, although it seems to work, the console is literally flooding with stray irq 7 messages. Freebsd at least suppressed these after a few, but when is someone actually going to FIX this in BSD? Someone told me years ago that this was an Intel chipset bug and there was nothing that could be done, but clearly that isn't the case here. whats the workaround solution as the console is unusable in its current state? Tried booting with ACPI disabled? Erik Wikström ACPI is disabled in the kernel. What causes this? Its been an issue since the beginning of time and only seems to occur in 'BSD. DT __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Argh, Stray interrupts 2006
--- Matthew Dillon [EMAIL PROTECTED] wrote: A flood of stray irq 7 messages is typically indicative of a BIOS SMP configuration problem. It usually means that the PIC is sending EXT interrupt acknowledgement requests to several cpus at once (or to one dual-core cpu), and the BIOS hasn't setup the hardware to properly direct the interrupts to just one cpu pin. What happens is that one cpu acks the interrupt and clears the pending bit, then the other cpu tries to ack the no longer pending interrupt and gets the stray interrupt vector. The stray interrupt vector is typically an undocumented hardware vector number, usually 7 or 15. Hence stray irq 7's. If you are running dual-core cpu's you can try adding this option to work around the BIOS misconfiguration: options CPU_AMD64X2_INTR_SPAM But it may not work on opterons. The problem is most commonly on systems with DUAL-CORE cpu's and BIOSes that don't quite configure them properly. This is a single core 100-series opteron. I don't have any dual-cores to test with at the moment. Its basically a GENERIC kernel (1.5.3-PREVIEW) with smp disabled. DT __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Argh, Stray interrupts 2006
OK, it seems that enabling the printer got rid of the messages. We usually disable the printer port and remove the printer device and it seems that DFLY doesn't like that too much. DT --- Danial Thom [EMAIL PROTECTED] wrote: --- Matthew Dillon [EMAIL PROTECTED] wrote: A flood of stray irq 7 messages is typically indicative of a BIOS SMP configuration problem. It usually means that the PIC is sending EXT interrupt acknowledgement requests to several cpus at once (or to one dual-core cpu), and the BIOS hasn't setup the hardware to properly direct the interrupts to just one cpu pin. What happens is that one cpu acks the interrupt and clears the pending bit, then the other cpu tries to ack the no longer pending interrupt and gets the stray interrupt vector. The stray interrupt vector is typically an undocumented hardware vector number, usually 7 or 15. Hence stray irq 7's. If you are running dual-core cpu's you can try adding this option to work around the BIOS misconfiguration: options CPU_AMD64X2_INTR_SPAM But it may not work on opterons. The problem is most commonly on systems with DUAL-CORE cpu's and BIOSes that don't quite configure them properly. This is a single core 100-series opteron. I don't have any dual-cores to test with at the moment. Its basically a GENERIC kernel (1.5.3-PREVIEW) with smp disabled. DT __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Argh, Stray interrupts 2006
On 01.06.2006, at 20:42, Danial Thom wrote: OK, it seems that enabling the printer got rid of the messages. We usually disable the printer port and remove the printer device and it seems that DFLY doesn't like that too much. Now that you're talking about it: I also experienced some of those strange problems, and on my box i still get stray ints (11 I think) when switching virtual consoles or pressing any *lock key (!?). It basically means: something fishy is happening, DragonFly/FreeBSD did notice that, continued working, but told you. Maybe we can add a sysctl which rate-limits those messages to a reasonable amount? cheers simon -- Serve - BSD +++ RENT this banner advert +++ASCII Ribbon /\ Work - Mac +++ space for low €€€ NOW!1 +++ Campaign \ / Party Enjoy Relax | http://dragonflybsd.org Against HTML \ Dude 2c 2 the max ! http://golden-apple.biz Mail + News / \ PGP.sig Description: This is a digitally signed message part
Re: Argh, Stray interrupts 2006
--- Simon 'corecode' Schubert [EMAIL PROTECTED] wrote: On 01.06.2006, at 20:42, Danial Thom wrote: OK, it seems that enabling the printer got rid of the messages. We usually disable the printer port and remove the printer device and it seems that DFLY doesn't like that too much. Now that you're talking about it: I also experienced some of those strange problems, and on my box i still get stray ints (11 I think) when switching virtual consoles or pressing any *lock key (!?). It basically means: something fishy is happening, DragonFly/FreeBSD did notice that, continued working, but told you. Maybe we can add a sysctl which rate-limits those messages to a reasonable amount? cheers simon FreeBSD (4.9+ at least) quashes them after the first dozen or so. But I still don't get why ints are getting generated when no device on that irq has been enabled. DT __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
