Re: NET-SNMP kvm_read errors
Thanks, Ive done that too, but it still gives me those errors. Any other ideas people? On Thursday 01 June 2006 19:05, Emiel Kollof wrote: Op donderdag 1 juni 2006 06:59, schreef [EMAIL PROTECTED]: Running 1.4.4 here and net-snmp. Im getting lots of these errors: [snip] Now googling tells me that it might be because kernel/userland are not in sync. It can't be, because I built the kernel from the same sources as userland. How do I fix it? Recompile net-snmp? I think net-snmp is not in sync with your kernel, since it links in libkvm. Cheers, Emiel
Re: NET-SNMP kvm_read errors
Thanks, Ive done that too, but it still gives me those errors. Any other ideas people? On Thursday 01 June 2006 19:05, Emiel Kollof wrote: Op donderdag 1 juni 2006 06:59, schreef [EMAIL PROTECTED]: Running 1.4.4 here and net-snmp. Im getting lots of these errors: [snip] Now googling tells me that it might be because kernel/userland are not in sync. It can't be, because I built the kernel from the same sources as userland. How do I fix it? Recompile net-snmp? I think net-snmp is not in sync with your kernel, since it links in libkvm. Cheers, Emiel
Re: NET-SNMP kvm_read errors
On Thu, Jun 01, 2006 at 02:59:58PM +1000, [EMAIL PROTECTED] wrote: Running 1.4.4 here and net-snmp. Im getting lots of these errors: FINALLY!!! A TESTER! I'll look at it. Joerg
Argh, Stray interrupts 2006
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 __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
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: [OT] C pointers: BSD versus Linux?
Simon 'corecode' Schubert wrote: On 31.05.2006, at 20:37, [EMAIL PROTECTED] wrote: Style 1: time_t t*; time(t); [...] Also, style 1 is technically incorrect since you never allocated the memory that t is pointing to before passing it into time(). maybe the compiler on BSD by chance put NULL into t and thus made it a valid parameter? First, thanks to all who replied! I've been playing with gdb and I'm seeing a significant difference between linux and *BSD. I added a dummy variable to my program, like this: time_t t*, d; and then ran the program in gdb. I printed out t and d and compared the two values under *BSD and linux. What I see in linux is that the two values are miles apart, but in *BSD they differ by only a few bytes. I *assume* this means that in *BSD, t is pointing to a valid memory location very close to d, whereas in linux t is pointing to some random number. Does this seem a reasonable idea? Thanks again for everyone's help.
Re: [OT] C pointers: BSD versus Linux?
On 2006-06-01 17:21, walt wrote: Simon 'corecode' Schubert wrote: On 31.05.2006, at 20:37, [EMAIL PROTECTED] wrote: Style 1: time_t t*; time(t); [...] Also, style 1 is technically incorrect since you never allocated the memory that t is pointing to before passing it into time(). maybe the compiler on BSD by chance put NULL into t and thus made it a valid parameter? First, thanks to all who replied! I've been playing with gdb and I'm seeing a significant difference between linux and *BSD. I added a dummy variable to my program, like this: time_t t*, d; and then ran the program in gdb. I printed out t and d and compared the two values under *BSD and linux. What I see in linux is that the two values are miles apart, but in *BSD they differ by only a few bytes. I *assume* this means that in *BSD, t is pointing to a valid memory location very close to d, whereas in linux t is pointing to some random number. Does this seem a reasonable idea? In general when dealing with uninitialized variables any value is reasonable since there's no guarantee what their value will be. Thus you shall never write an application that depends on the behavior of uninitialized variables since this behavior can change between different architectures, compilers and OS'es. In this case the fact that t points to an address near d does not make that address valid, since d is allocated on the stack and the only valid addresses for t to point to would be a variable on the stack or some allocaed area on the heap 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: [OT] C pointers: BSD versus Linux?
:What I see in linux is that the two values are miles apart, :but in *BSD they differ by only a few bytes. I *assume* this :means that in *BSD, t is pointing to a valid memory location :very close to d, whereas in linux t is pointing to some :random number. Does this seem a reasonable idea? : :Thanks again for everyone's help. Yes. Because the variables are not initialized, the contents of the stack representing the variables is whatever happened to be on the stack. If you are doing any serious programming I recommend always using: -Wall -Wstrict-prototypes Which will catch most common programming errors, such as using uninitialized variables. -Matt Matthew Dillon [EMAIL PROTECTED]
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: Any serious production servers yet?
On 2006-06-01 18:46, Danial Thom wrote: --- Sascha Wildner [EMAIL PROTECTED] wrote: Danial Thom wrote: Surely it makes sense to begin developing O/S applications (which is what I need to do), however I need an OS that is production ready, even if its not as good as its going to be, because I can't reasonably test the performance of an application on an OS that can't handle production loads. *sigh* Is this going to be another of those half-yearly Danial vs. the rest threads? How about this: You restrain yourself from stealing people's time with your annoying discussion for discussion's sake and I promise to get back to you in personal email as soon as I think that DragonFly has reached the point where it could be interesting to you? Sascha I don't see that its me vs anything. I have to chose an MP OS for a big project and I just asked if the project is production-ready yet, and instead of getting an answer, I get a lot of pointers to personal web pages and routers that aren't even pushing a T1. A simple answer like No, DFLY isn't ready for prime time yet, and we don't expect it will be until Sept '07. would have avoided wasting your time. Well, the definition of production-ready differs with the needs of the production server. You've got lots of examples of DF being used in production but none of them happens to be the kind of environment that you'll use. Regardless of the type of services one would use an OS for there's only one reliable way to determine if a particular solution is the one you want or not, and that is testing it yourself under the same conditions that it will encounter in production. In short the only way to know is to test it yourself. To ask if someone has done X using Y and Z under conditions A, B and C is often pointless since no setup or requirement is identical to another unless it's very simple. 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: Any serious production servers yet?
Danial Thom wrote: ...I just asked if the project is production-ready yet, and instead of getting an answer... Well, I'm a hobbyist who doesn't even own a MP machine, so of course I'll be happy to answer ;o) Matt is right in the middle of a major revision of the SMP parts of the kernel even as we speak [see other recent threads in this group]. My prediction: whatever the performance of recent DragonFly releases may be -- it's about to change again. Most likely for the better. But I could be wrong.
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: Any serious production servers yet?
Danial Thom [EMAIL PROTECTED] writes: You're thinking like an engineer, and not a marketeer. Yes. This is an excellent reason to use DragonFly. :) -- Dave Hayes - Consultant - Altadena CA, USA - [EMAIL PROTECTED] The opinions expressed above are entirely my own Wisdom (n.) - 1. Something you can learn without knowing it.
Sound question.
Sorry for a somewhat open question here. I have just installed Dragonfly on my machine and am considering which directions to take with sound. Can anyone tell me which sound server they would recommend (I saw JACK in the pkgsrc list) and have heard good things about it. However im somewhat daunted about getting ALSA to work... Any hints would be really cool. Thanks, Max.
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: Sound question.
On Thu, June 1, 2006 12:31 pm, Max von Seibold wrote: Sorry for a somewhat open question here. I have just installed Dragonfly on my machine and am considering which directions to take with sound. Can anyone tell me which sound server they would recommend (I saw JACK in the pkgsrc list) and have heard good things about it. However im somewhat daunted about getting ALSA to work... ALSA == Advanced Linux Sound Architecture. ie: it's not available on anything but Linux. :) Getting sound working on BSD is much simpler. Just load the kernel module for all the sound drivers, run cat /dev/sndstat to see if the kernel detected your sound chipset, then add a line to /boot/loader.conf to autoload that kernel module at boot. I do not remember what the kernel module name is to load all the sound drivers on FreeBSD4/DFlyBSD, though. I think it's just snd (kldload snd; cat /dev/sndstat). Anyway, read through the snd(4) man page, and all the man pages referenced by it. Getting sound working on BSD is easy, if the chipset is supported. :) Freddie Cash, LPCI-1 CCNT CCLPHelpdesk / Network Support Tech. School District 73(250) 377-HELP [377-4357] [EMAIL PROTECTED]
RE: Any serious production servers yet?
I guess I should have qualified my question. If you're pushing less than 100Kb/s then there's really no reason to spend 3X the dollars on a multi-core system. So the only real value of an As of NOW, the price differential between a single core 2.6ghz Opteron and a dual-core one is about 120%. I can't think of many applications that are going to push a 2.6Ghz opteron that justify spending more than twice as much. Of While I'd agree that in general CPUs today are really pretty fast, I think this '3X' and '120%' pitch suggests borked thinking, at least for the case of whether to buy a dual core socket 939 or 940 chip - because while the cost differential is quite steep, its only the CPU and in effect you get a lot more bang for an incremental change in system bucks - you don't even need a pricey mobo. If you're saving pennies, get a cheap Intel D920 system. Can't argue with the amount of grunt you get for 200 bucks (well, 140 quid including VAT). And the D805 is only 85 quid! Might be last year's FSB speed etc and hot compared to AMD, but if you compare the bang you get from a cheap mobo and one of these things with the breakthrough price performance we got from dual PPro systems in their day, its just laughable. Of course, it would be nice if one of the BSDs could actually have a working pthread system that scaled well and had a decent malloc too. How about it guys? ;-) How many do FreeBSD have now? 3? And do any of them work properly? James
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
RE: Any serious production servers yet?
--- James Mansion [EMAIL PROTECTED] wrote: I guess I should have qualified my question. If you're pushing less than 100Kb/s then there's really no reason to spend 3X the dollars on a multi-core system. So the only real value of an As of NOW, the price differential between a single core 2.6ghz Opteron and a dual-core one is about 120%. I can't think of many applications that are going to push a 2.6Ghz opteron that justify spending more than twice as much. Of While I'd agree that in general CPUs today are really pretty fast, I think this '3X' and '120%' pitch suggests borked thinking, at least for the case of whether to buy a dual core socket 939 or 940 chip - because while the cost differential is quite steep, its only the CPU and in effect you get a lot more bang for an incremental change in system bucks - you don't even need a pricey mobo. A dual-core 2.6 Opteron is about US$1079. whereas a single core is about $460. So for about $200. more I can build 2 2.6Ghz systems that give me a lot more bang for my buck than 1 dual-core system. Intel isn't quite in play yet, since a dual-core Pentium D doesn't give me the performance of a single 2.6Ghz Opteron, so there's no point in even considering it. Woodcrest/Conroe will change things, of course. Again, I'm talking about getting past the wall, so the lower end stuff doesn't buy me anything. DT __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Compiling: Whats the trick?
Ok, since the beginning of time, the following
has worked in every known unix:
/* hello_world.c */
#include /usr/include/stdio.h
main()
{
printf(hello world\n);
}
cc -o hello_world hello_world.c
except it barfs pretty badly in DFLY. What's the
trick?
DT
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: Compiling: Whats the trick?
On Thu, Jun 01, 2006 at 04:32:41PM -0700, Danial Thom wrote: Ok, since the beginning of time, the following has worked in every known unix: *snip* and works on the pkgsrc build machine. So what is do you expect from us? Joerg
Re: Compiling: Whats the trick?
On 02.06.2006, at 01:32, Danial Thom wrote: except it barfs pretty badly in DFLY. What's the trick? just do it[tm]? works perfectly here. besides, your error report lacks major information, but I guess you know that already. oh, of course except if you mean the return value of ./hello_world. that's a programming error then (no return/exit()). 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: Any serious production servers yet?
A dual-core 2.6 Opteron is about US$1079. whereas a single core is about $460. So for about $200. more I can build 2 2.6Ghz systems that give me a lot more bang for my buck than 1 dual-core system. Well, the bleeding edge is always at a premium. But you mention a wall. A wall doing what? Single threaded monte-carlo? Single postgres query? Almost any real-world load that will stress a modern server box comes from multiple requests. As for pf performance - who the hell cares? Are you routing between two 10GBit LANs? If you're using that much CPU, then if you care what OS you're using, your app is badly written, cos you should first avoid entering the kernel anyway as much as you can. Personally I value a good pthread/libc much higher than parallelism in the kernel for exactly this reason.
