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
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 -marc
[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.
On Wed, 17 Jan 2001, Garrett Wollman wrote:
> < 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?
>
> The two bus cycles are independent, so there is a race cond
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
> > > http://www.Free
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 relevan
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...
>
> >
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 mach
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 Wa
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
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) outpu
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 l
> 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 differenc
[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 program
> 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
>> > http://w
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
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
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
>
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:33
> > 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 embedd
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 exce
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 sect
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 tha
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
>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
>E
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
> preparatio
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 ' > makedevs.tmp
./rtermcap ansi | file2
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 C
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/i38
39 matches
Mail list logo
