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



## Gemini (Feb 1, 2011)

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?


----------



## SirDice (Feb 1, 2011)

What is the panic you're getting?


----------



## Gemini (Feb 2, 2011)

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


----------



## SirDice (Feb 2, 2011)

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?


----------



## Gemini (Feb 6, 2011)

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:


```
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).


----------



## wblock@ (Feb 6, 2011)

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.
> 
> 
> ```
> ...



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.


----------



## Gemini (Feb 6, 2011)

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.



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.


----------



## wblock@ (Feb 6, 2011)

Gemini said:
			
		

> Two notes:
> 1) The default GENERIC kernel that came with the installation ISO also panics



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



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.



No, it looked like you were referring in post #5 to a GENERIC you compiled, not the one that came with the CD.


----------



## Gemini (Feb 6, 2011)

wblock said:
			
		

> Just to be sure: that's the GENERIC kernel binary, not a GENERIC config file that you compiled with custom CFLAGS?



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.



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.


----------



## dennylin93 (Feb 8, 2011)

Submit a PR and post it to the mailing list as well.


----------



## Gemini (Feb 8, 2011)

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?


----------



## dennylin93 (Feb 9, 2011)

As far as I know, there isn't a preferred location. Including the URL is what most people do.


----------



## Gemini (Feb 10, 2011)

Problem report PR amd64/154629 submitted and awaiting moderator approval.


----------



## dandelion (Feb 13, 2011)

&quot said:
			
		

> Boot drive used to be part of a software based array (note "ar0: FAILURE - RAID0 array broken" messages)
> 
> 
> 
> ...


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).


----------



## Gemini (Feb 17, 2011)

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.


----------



## Gemini (Feb 22, 2011)

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.


----------

