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
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
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
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
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
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
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
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
: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?
:
--- 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
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,
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
--- 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),
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
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.
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
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
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
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
--- 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.
--- 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
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
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
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
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
25 matches
Mail list logo
