Bug #13

Buildworld error/panic

Added by mchamm3r almost 9 years ago. Updated almost 8 years ago.

Status:ClosedStart date:
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Target version:-

Description

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.

Fatal trap 12: page fault while in kernel mode
mp_lock = 00000000; cpuid = 0; lapic.id = 00000000
fault virtual address = 0xdeadc0fa
fault code = supervisor read, page not present
instruction pointer = 0x8 :0xc029c734
stack pointer = 0x10:0xcfb2e9c0
frame pointer = 0x10:0xcfb2e9e0
code segment = base 0x0, limit 0xfffff, type 0x1b
DPL 0, pres 1, def32 1, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 39982 (nm)
current thread = pri 70 (CRIT)
<- SMP: XXX
kernel: type 12 trap, code=0

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)

Thanks,
Farid Kamarudin

History

#1 Updated by corecode almost 9 years ago

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

#2 Updated by dillon almost 9 years ago

: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
<>

#3 Updated by mchamm3r almost 9 years ago

On 12/13/05, Matthew Dillon <> 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
> <>
>

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

#4 Updated by corecode almost 9 years ago

originator suspects bad hardware

#5 Updated by dillon almost 9 years ago

: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
<>

#6 Updated by jason almost 9 years ago

> 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

#7 Updated by hmp almost 9 years ago

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

Also available in: Atom PDF