DragonFlyBSD

farid wrote:

CPU0 stopping CPUs: 0x00000002
stopped
Stopped at inodedep_lookup+0x55: movl 0x1c(%ebx),%edx

I have tried couple of times and got almost the same errors.
I have uploaded kernel dump to http://www.msav.org/farid/dfbsd/
vmcore is on the way (my internet connection is not so good)

Did you try with a clean filesystem? I.e. fsck all fs one time?

It could be as well that this bug was fixed, matt committed a fix to the
RB scan code some days ago. Could you try with a recent snapshot? (You
should be able to just update the binaries/kernel) Snapshots building
works since yesterday again.

cheers
simon

:Hi guys,
:
:This is my first attempt to use DragonFlyBSD. I am using snapshot
:2CSNAP-20051130-2330-Devel.iso.bz2. After cvsup'ed to latest -HEAD, I
:tried to do buildworld but it keep failing on me. I don't have problem
:with 'buildkernel' ( cd /usr/src/sys/i386/conf ; config MYKERNEL ; cd
:../../compile/MYKERNEL ; make depend && make && make install ; reboot)
:though. Here are the errors I got from buildworld. Please take a look
:at it.
:
:...
:I have tried couple of times and got almost the same errors.
:I have uploaded kernel dump to http://www.msav.org/farid/dfbsd/
:vmcore is on the way (my internet connection is not so good)
:
:Thanks,
:Farid Kamarudin

Definitely try the latest snapshot.  The kernels around ~30 november
    were fairly buggy.

There was a vnode scanning issue fixed on 5 December but I can't say
    for sure that your crash is due to one of those bugs.

I downloaded the kernel and core you had at that URL, but the vmcore
    looks incomplete.  If its supposed to be larger then 92.8M then email
    me when you've got the whole thing uploaded and I'll download it again.

-Matt
                    Matthew Dillon 
                    <dillon@backplane.com>

On 12/13/05, Matthew Dillon <dillon@apollo.backplane.com> wrote:

:Hi guys,
:
:This is my first attempt to use DragonFlyBSD. I am using snapshot
:2CSNAP-20051130-2330-Devel.iso.bz2. After cvsup'ed to latest -HEAD, I
:tried to do buildworld but it keep failing on me. I don't have problem
:with 'buildkernel' ( cd /usr/src/sys/i386/conf ; config MYKERNEL ; cd
:../../compile/MYKERNEL ; make depend && make && make install ; reboot)
:though. Here are the errors I got from buildworld. Please take a look
:at it.
:
:...
:I have tried couple of times and got almost the same errors.
:I have uploaded kernel dump to http://www.msav.org/farid/dfbsd/
:vmcore is on the way (my internet connection is not so good)
:
:Thanks,
:Farid Kamarudin

Definitely try the latest snapshot. The kernels around ~30 november
were fairly buggy.

There was a vnode scanning issue fixed on 5 December but I can't say
for sure that your crash is due to one of those bugs.

I downloaded the kernel and core you had at that URL, but the vmcore
looks incomplete. If its supposed to be larger then 92.8M then email
me when you've got the whole thing uploaded and I'll download it again.

-Matt
Matthew Dillon
<dillon@backplane.com>

Ok, I have tried the latest snapshot. With it, I got panic on
buildkernel, buildworld and even during the xorg compilation. All I
did is keep trying building the kernel/world with the hope I don't hit
the panic. Sometimes it takes couple of panic (occurs at different
places for each build) before it actually build without panic. For
xorg, I only tried once but it also gave me panic. After that I gave
up.

I think this has something to do with unstable hardware, (bad hard
disk for example), so I try to install FreeBSD 6.0-release but it
always failed when trying to copy the base into the hard disk (during
the installation process) but no panic. The hard disk also takes a
'very' long time to transfer big files (~500MB).

Maybe the problem is caused by the bad hard disk but not the code.
Right now I'm using Windows XP and it works 'OK' but I can hear
uncommon sound comes from the hard disk especially during heavy I/O
operation though. I think I am going to stick to Windows XP for a
while until the hard disk is totally broken or maybe I should get a
new hard disk for my dual-core xpc shuttle :-)

Thanks.

Farid Kamarudin

originator suspects bad hardware

:Ok, I have tried the latest snapshot. With it, I got panic on
:buildkernel, buildworld and even during the xorg compilation. All I
:did is keep trying building the kernel/world with the hope I don't hit
:the panic. Sometimes it takes couple of panic (occurs at different
:places for each build) before it actually build without panic. For
:xorg, I only tried once but it also gave me panic. After that I gave
:up.

We need to know what the panic actually was, and a ddb> backtrace
    if possible.

Generally speaking if you are getting different panics it is probably
    hardware.  If you are getting the same panics over and over again
    then it is likely software.

:Maybe the problem is caused by the bad hard disk but not the code.
:Right now I'm using Windows XP and it works 'OK' but I can hear
:uncommon sound comes from the hard disk especially during heavy I/O
:operation though. I think I am going to stick to Windows XP for a
:while until the hard disk is totally broken or maybe I should get a
:new hard disk for my dual-core xpc shuttle :-)
:
:Thanks.
:
:Farid Kamarudin

If you have a dual-core Shuttle XPC then you need to do two things:

(1) Update to the latest BIOS from shuttle, if you haven't already.

(2) Any SMP DragonFly kernel you build must be built with:

options         CPU_AMD64X2_INTR_SPAM

In the kernel config file.

-Matt
                    Matthew Dillon 
                    <dillon@backplane.com>

We need to know what the panic actually was, and a ddb> backtrace
if possible.

Would it be a good idea to display a URL when the kernel panics? Such a
URL would direct the user to information about how to obtain and report
information about the panic?

Perhaps an extended URL could also be displayed that allows the bug
tracking database to auto search for related panics? Reguardless,
perhaps the bug database could be extended to search for panics that are
already resolved with information inputed from the panic.

- Jason

Jason,

Sorry I just came across this thread right now, but what you have
suggested is a brilliant idea! It's similar to the way GCC and how some
other applications behave during aborts/panics.

I think this would be something nice to work at, and we can have a
page on the Wiki that explains how to generate core dumps, detailed
and brief back traces (including kernel module trace data etc); and
various other bits and pieces of information on how it should
be done so we don't need to keep repeating it on the lists all the
time.

One of the other key information to provide during panic-time would
be about basic checks that should be done such as, hardware faults
or wrongly compiled kernels etc.

The second thing about searching similar bugs would be nice,
provided that we had a bug database system in active use, but until
that happens we should keep it in mind.

Let me see if I can do something about this after holidays. If it
works well then we can always merge back to the release and stable
branches/tags.

Kind regards,

Hiten Pandya
hmp at dragonflybsd.org

Jason Smethers wrote:

We need to know what the panic actually was, and a ddb> backtrace
if possible.

Would it be a good idea to display a URL when the kernel panics? Such a
URL would direct the user to information about how to obtain and report
information about the panic?

Perhaps an extended URL could also be displayed that allows the bug
tracking database to auto search for related panics? Reguardless,
perhaps the bug database could be extended to search for panics that are
already resolved with information inputed from the panic.

- Jason