It seems Alfred Perlstein wrote:
Now this is "interesting", I booted on your kernel, and it has run
through make world 4 times in a row...
So I felt lucky, checked out a new fresh src/sys tree, and made a new
kernel from the config file you used, reboot, starts test, and *HANG*
On 18-Jan-01 Alfred Perlstein wrote:
* Soren Schmidt [EMAIL PROTECTED] [010118 00:03] wrote:
It seems John Baldwin wrote:
Anyhow, I have asked before to have you guys supply me with
a kernel that has been compiled "the right way" and I'll test
it out here just to make sure I dont do
It seems John Baldwin wrote:
So the only thing I can think of is that you guys have something in
your src trees that cvs I dont...
Now what ?
What are the compile flags you are using?
I actually used this:
CFLAGS ?= -O -pipe -mcpu=i686 -march=i686
COPTFLAGS
[EMAIL PROTECTED] wrote:
The enclosed patch implements a virtual NMI pushbutton by programming
the IOAPIC to deliver an NMI when sio1 generates an interrupt.
This would be a nice kernel option... :-)
--
Daniel C. Sobral(8-DCS)
[EMAIL PROTECTED]
[EMAIL PROTECTED]
It seems Soren Schmidt wrote:
I actually used this:
CFLAGS ?= -O -pipe -mcpu=i686 -march=i686
COPTFLAGS ?= -O -pipe -mcpu=i686 -march=i686
All the diffs in sys/ on the box I built this kernel on are at
http://www.FreeBSD.org/~jhb/patches/sys-mutex.patch. One
On Wed, 17 Jan 2001, Garrett Wollman wrote:
On Tue, 16 Jan 2001 19:10:10 -0800, Alfred Perlstein [EMAIL PROTECTED] said:
Just wondering, can't you use 'LOCK addl' and then use 'LOCK addc'?
add longword, add longword with carry? I know it would be pretty
ugly, but it should work, no?
On Wed, Jan 17, 2001 at 11:34:09PM -0700, Warner Losh wrote:
That's a red herring. The new features thing is what I mean. If I
were creating a product, I'd want one that is supported. So even if I
don't *NEED* a feature in 5.x, I might migrate my product to 5.x so
that I can continue to
It seems Peter Wemm wrote:
Hmm. with the mp_machdep.c fix committed, that leaves the only other
significant difference being the re-enable of HLT when a cpu goes idle
in i386/i386/machdep.c.
That still lockups, tried a freshly checked out sys...
The refcount.[ch] stuff is not relevant to
Soren Schmidt wrote:
It seems Peter Wemm wrote:
Hmm. with the mp_machdep.c fix committed, that leaves the only other
significant difference being the re-enable of HLT when a cpu goes idle
in i386/i386/machdep.c.
That still lockups, tried a freshly checked out sys...
The
Hello!
This is an old 486 of mine which never ran FreeBSD before.
It has only ISA and VL bus.
When booting a trimmed down GENEIRC kernel from today, it shows the
copyright lines and then this:
panic: spin lock (null) held by 0x0 for 5 seconds.
This line repeats approx. every 30 seconds
This
It seems Peter Wemm wrote:
I'll try adding the forward_signal stuff see if that helps...
But John committed that! it should be in the fresh checkout you tried
above Of course, that is assuming you cvsup'ed very recently..
Sorry that was not what I meant, I meant this patch to
how about to have in a distribution two version of GENERIC kernel
(and modules of course) and let sysinstall choose right set ?
In article [EMAIL PROTECTED] you wrote:
On Tuesday, 16 January 2001 at 9:28:43 -0500, Will Andrews wrote:
On Tue, Jan 16, 2001 at 09:16:14AM -0500, Kenneth Wayne
In message [EMAIL PROTECTED] Will Andrews writes:
: Well, Warner, I've never done embedded systems. So, tell me, do they
: actually use any C++ code in embedded systems? C++ has a rather high
: overhead as far as disk space memory goes. I would imagine that 99%+
: of embedded systems do not
Will Andrews [EMAIL PROTECTED] writes:
Well, Warner, I've never done embedded systems. So, tell me, do they
actually use any C++ code in embedded systems? C++ has a rather high
overhead as far as disk space memory goes.
That's a myth.
I would
Got a nice crash while running XMMS under X11 and running a 'make world -j
128 -DNOCLEAN' on ttyv0
Current was cvsupped on the 17th in the morning (Central European Time) IIRC.
Attached: script(1) output of gdb kernel trace
Kernel config file
dmesg(8)
After enabling ACPI in my kernel I get these messages in dmesg:
---snip---
VESA: v2.0, 2496k memory, flags:0x0, mode table:0xc03b82e2 (122)
VESA: MagicGraph 256 AV 44K PRELIMINARY
ACPI-0299: *** Warning: Invalid table signature found
ACPI-0170: *** Error: AcpiLoadTables: Could not
Will Andrews [EMAIL PROTECTED] writes:
Well, Warner, I've never done embedded systems. So, tell me, do they
actually use any C++ code in embedded systems? C++ has a rather high
overhead as far as disk space memory goes.
That's a myth.
It seems Peter Wemm wrote:
Soren, can you retest a buildworld with the currently committed kernel
with no other changes? Let us see if the forward_signal() stuff is the
culprit, and if not, try adding just the i386/i386/machdep.c patch to HLT
the idle CPU. (if *that* makes a difference
[EMAIL PROTECTED] wrote:
Again I'll offer to run any and all code or patches to -current you
guys can come up with, but I simply dont have the time to sit down
and analyze into details what you have been doing...
The enclosed patch implements a virtual NMI pushbutton by programming
cool.
What are the instructions for using this?
should something have sio1 open?
I use conserver
conserver conserver hostnull-modem serial cables test machine
label
testport AA - sio0 serial console
testnmi port BB
On 18-Jan-01 Soren Schmidt wrote:
It seems Soren Schmidt wrote:
I actually used this:
CFLAGS ?= -O -pipe -mcpu=i686 -march=i686
COPTFLAGS ?= -O -pipe -mcpu=i686 -march=i686
All the diffs in sys/ on the box I built this kernel on are at
On 18-Jan-01 Soren Schmidt wrote:
It seems Peter Wemm wrote:
I'll try adding the forward_signal stuff see if that helps...
But John committed that! it should be in the fresh checkout you tried
above Of course, that is assuming you cvsup'ed very recently..
Sorry that was not what I
Soren Schmidt wrote:
It seems Peter Wemm wrote:
Soren, can you retest a buildworld with the currently committed kernel
with no other changes? Let us see if the forward_signal() stuff is the
culprit, and if not, try adding just the i386/i386/machdep.c patch to HLT
the idle CPU. (if
On 18-Jan-01 Rogier Mulhuijzen wrote:
Got a nice crash while running XMMS under X11 and running a 'make world -j
128 -DNOCLEAN' on ttyv0
Current was cvsupped on the 17th in the morning (Central European Time) IIRC.
Attached: script(1) output of gdb kernel trace
Kernel
On 18-Jan-01 Julian Elischer wrote:
Soren Schmidt wrote:
It seems Peter Wemm wrote:
Soren, can you retest a buildworld with the currently committed kernel
with no other changes? Let us see if the forward_signal() stuff is the
culprit, and if not, try adding just the
If you look at the traceback, vref() was called with a NULL vnode as its
parameter, so the panic is due to dereferencing a NULL pointer, not a bug in
the atomic ops. :) As to why the kernel was vref()'ing a NULL pointer, I have
no idea.
#11 0xc01c057f in vref (vp=0x0) at machine/atomic.h:332
That's one of the big reasons that we're 4.x based right now rather
than 3.x based, despite 4.x's slightly larger memory footprint. That
and 4.x's much better c++ compiler.
Well, Warner, I've never done embedded systems. So, tell me, do they
actually use any C++ code in embedded
On 18-Jan-01 Will Andrews wrote:
Well, Warner, I've never done embedded systems. So, tell me, do they
actually use any C++ code in embedded systems? C++ has a rather high
overhead as far as disk space memory goes. I would imagine that 99%+
of embedded systems do not use C++ code except
Rogier Mulhuijzen [EMAIL PROTECTED] writes:
My next question is, where are those ??'s from in #12 - #15? Could they be
addresses in kernel modules?
Quite possibly.
If so, how do I readable output from that, save compiling everything into
the kernel statically?
Read the handbook section
On Thu, Jan 18, 2001 at 11:44:18AM -0800, Mike Smith wrote:
You have a very vivid imagination.
It's not easy to replace imagination with experience. This takes years,
which I have yet to come upon. :-)
Unfortunately, imagination isn't very helpful here; the whole idea is to
do stuff
ccccccccccccccccccccccccc
@@@Cu`bgVXeĮ̀mç¹
ccccccccccccccccccccccccc
zÌïpª©©ÁÄ¢½®æÌVXeðA±Ìx
á¿iÅÌ·éÉÈèܵ½B
Cu`bgVXeÆÍEEE
ccccccccccccccccccccccccc
@@@Cu`bgVXeĮ̀mç¹
ccccccccccccccccccccccccc
zÌïpª©©ÁÄ¢½®æÌVXeðA±Ìx
á¿iÅÌ·éÉÈèܵ½B
Cu`bgVXeÆÍEEE
On 18-Jan-01 Rogier Mulhuijzen wrote:
If you look at the traceback, vref() was called with a NULL vnode as its
parameter, so the panic is due to dereferencing a NULL pointer, not a bug in
the atomic ops. :) As to why the kernel was vref()'ing a NULL pointer, I
have
no idea.
#11 0xc01c057f
Submitter-Id: current-users
Originator: Crist J. Clark
Organization:
Confidential: no
Synopsis: syslogd(8) does not update hostname
Severity: non-critical
Priority: medium
Category: bin
Release:FreeBSD 5.0-CURRENT i386
Class: sw-bug
Hello,
A few hours ago, this has been committed to -CURRENT:
Commit log:
[...]
Log:
Implement MTX_RECURSE flag for mtx_init().
All calls to mtx_init() for mutexes that recurse must now include
the MTX_RECURSE bit in the flag argument variable. This change is in
preparation
Howdy,
Since the sysinstall move, make release on FreeBSD-stable (as of 3 hrs ago)
breaks when building sysinstall. The output is:
=== usr.sbin/sysinstall
cc -o rtermcap /usr/src/usr.sbin/sysinstall/rtermcap.c -ltermcap
rm -f makedevs.tmp
echo '#include sys/types.h' makedevs.tmp
./rtermcap
Soren Schmidt wrote:
It seems Peter Wemm wrote:
Soren, can you retest a buildworld with the currently committed kernel
with no other changes? Let us see if the forward_signal() stuff is the
culprit, and if not, try adding just the i386/i386/machdep.c patch to HLT
the idle CPU. (if
It seems Peter Wemm wrote:
Soren Schmidt wrote:
It seems Peter Wemm wrote:
Soren, can you retest a buildworld with the currently committed kernel
with no other changes? Let us see if the forward_signal() stuff is the
culprit, and if not, try adding just the i386/i386/machdep.c
38 matches
Mail list logo
