Is send-pr the best way to report a kernel crash?

G

Gemini

My FreeBSD 8.2-RC2 system is repeatedly generating kernel panics. I'm about ready to submit a report via the send-pr system, but I'd like to know what I should do with the core file. The various how-to guides over on the main FreeBSD site mainly discuss attaching patches, not multi-gigabyte files.

What is the best way to report a kernel crash?
 
Code: 
Fatal trap 9: general protection fault while in kernel mode
cpuid = 0; apic id = 00
instruction pointer     = 0x20:0xffffffff80649f27
stack pointer           = 0x28:0xffffff808a3f69d0
frame pointer           = 0x28:0xffffff808a3f6a00
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 21 (syncer)
trap number             = 9
panic: general protection fault
cpuid = 0
KDB: stack backtrace:
#0 0xffffffff805f556e at kdb_backtrace+0x5e
#1 0xffffffff805c3467 at panic+0x187
#2 0xffffffff808acd30 at trap_fatal+0x290
#3 0xffffffff808ad319 at trap+0x109
#4 0xffffffff808956e4 at calltrap+0x8
#5 0xffffffff806547bc at vfs_msync+0x13c
#6 0xffffffff80654a6a at sync_fsync+0x15a
#7 0xffffffff80652c1e at sync_vnode+0x15e
#8 0xffffffff80652f11 at sched_sync+0x1d1
#9 0xffffffff80599c58 at fork_exit+0x118
 
Did you build your kernel with any CFLAGS or similar in /etc/make.conf?
And did you use the standard compiler?
Does this happen with GENERIC or is it a custom kernel?
 
Here are all of the combinations I've used where I've had a kernel panic:

8.1-RELEASE/i386 - GENERIC kernel (panics)
8.1-RELEASE/i386 - custom kernel (panics)
8.2-RC2/i386 - custom kernel (panics)
8.2-RC2/amd64 - GENERIC kernel (panics)
8.2-RC2/amd64 custom kernel (panics)

When building a custom kernel, here is my make.conf file:

Code: 
CPUTYPE= native
CFLAGS= -O2 -pipe -ffast-math
CXXFLAGS+= -fconserve-space
COPTFLAGS= -O -pipe -ffast-math

I'm using the default version of GCC that came with the system (GCC 4.2.1 for 8.2-RC2).
 
Gemini said:
The crash I listed was using a GENERIC amd64 kernel. I generally build my own kernels with the flags below using the native GCC. I've had similar crashes under the i386 build, too.

Code: 
CPUTYPE= native
CFLAGS= -O2 -pipe -ffast-math
CXXFLAGS+= -fconserve-space
COPTFLAGS= -O -pipe -ffast-math
Click to expand...

Comment those last three lines (custom CFLAGS are bad, mmkay?), rebuild and install--probably should do a full world/kernel install. Then test for crashes again.
 
wblock said:
Comment those last three lines (custom CFLAGS are bad, mmkay?), rebuild and install--probably should do a full world/kernel install. Then test for crashes again.
Click to expand...

Two notes:
1) The default GENERIC kernel that came with the installation ISO also panics
2) I've used this make.conf file since FreeBSD 3.x with no other issues

Are you suggesting that I am hitting a bug that manifests itself with the default packaged kernel and custom CFLAG kernels, but that a custom kernel with stock CFLAGs would work? That doesn't sound likely.
 
Gemini said:
Two notes:
1) The default GENERIC kernel that came with the installation ISO also panics
Click to expand...

Just to be sure: that's the GENERIC kernel binary, not a GENERIC config file that you compiled with custom CFLAGS? That would shift the blame away from custom CFLAGS.

2) I've used this make.conf file since FreeBSD 3.x with no other issues
Click to expand...

Custom CFLAGS have been a source of problems for a lot of people. Also, things change.

Are you suggesting that I am hitting a bug that manifests itself with the default packaged kernel and custom CFLAG kernels, but that a custom kernel with stock CFLAGs would work? That doesn't sound likely.
Click to expand...

No, it looked like you were referring in post #5 to a GENERIC you compiled, not the one that came with the CD.
 
wblock said:
Just to be sure: that's the GENERIC kernel binary, not a GENERIC config file that you compiled with custom CFLAGS?
Click to expand...

Correct, it is the GENERIC binary straight off the ISO image.


wblock said:
Custom CFLAGS have been a source of problems for a lot of people.
Click to expand...

Understood, which is why I keep my CFLAGS fairly conservative, and my COPTFLAGS even more so. And if something I build does puke, one of the first things I do is grab the pre-compiled package/binary to see if something in my build environment is at fault.
 
Where is the preferred location to upload the core files, or should I just host them on a 3rd party site and include the URL in the problem report?
 
&quot said:
Boot drive used to be part of a software based array (note "ar0: FAILURE - RAID0 array broken" messages)
Code: 
ATA PseudoRAID loaded
********** ATA PseudoRAID ar0 Metadata **********
=================================================
format              nVidia MediaShield
type                RAID0
flags               0x01 1<READY>
magic_0             0x44d0566f495a42b0
magic_1             0x358dbb4d49dab4b4
generation          0
total_sectors       40011264
offset_sectors      0
heads               255
sectors             63
cylinders           2490
width               2
interleave          128
total_disks         2
    disk 0:      flags = 0x0b b<ONLINE,ASSIGNED,PRESENT>
        ad0:  sectors 20005632
    disk 1:      flags = 0x00 0
=================================================
ar0: FAILURE - RAID0 array broken
ar0: writing of nVidia MediaShield metadata is NOT supported yet
ar0: 19536MB <nVidia MediaShield RAID0 (stripe 64 KB)> status: BROKEN
ar0: 40011264 sectors [2490C/255H/63S] <> subdisks defined as:
ar0: disk0 READY using ad0 at ata0-master
ar0: disk1 DOWN no device found for this subdisk
Click to expand...
Did you create raid0 (stripe) and forgot to destroy it via "raid bios"? And does the system panic if you compile out ataraid(4)? This info is missing in the PR.

My guess, ar0 (even BROKEN) interferes with syncer that runs directly on ad0s1a (ufs).
 
No, I destroyed the array using the RAID BIOS management utilities. It is currently a stand alone drive. I also wiped the drive prior to installation, although the RAID watermark made it past.

I removed all of my make.conf options except for the -march tuning and rebuilt a new kernel without the ataraid device. If that doesn't fix things, I will use a more robust drive wiper and reinstall.
 
Little improvement. Kernel panicked with the ataraid device removed and again after wiping the drive completely and reinstalling. However, the /dev/ar0 warnings are now gone.
 
You must log in or register to reply here.
Back
Top