Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 28 Dec 2006 17:24:04 -0500
From:      Jan Knepper <jan@digitaldaemon.com>
To:        Jan Knepper <jan@digitaldaemon.com>
Cc:        Tim McCullagh <tim@halenet.com.au>, FreeBSD ISP <FreeBSD-ISP@FreeBSD.org>, FreeBSD Hackers <FreeBSD-Hackers@FreeBSD.org>, Kris Kennaway <kris@obsecurity.org>
Subject:   Re: 6.1-RELEASE / 6.2 Kernel Crash...
Message-ID:  <45944404.8050301@digitaldaemon.com>
In-Reply-To: <4593552E.80400@digitaldaemon.com>
References:  <45918F6E.90006@digitaldaemon.com>	<004c01c7293b$d5e03b40$6500a8c0@laptopt>	<4591CB3C.1060902@digitaldaemon.com>	<20061227033742.GA9706@xor.obsecurity.org> <4593552E.80400@digitaldaemon.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Jan Knepper wrote:
> Kris Kennaway wrote:
>> On Tue, Dec 26, 2006 at 08:24:12PM -0500, Jan Knepper wrote:
>>  
>>> Tried that and started
>>>
>>> dd if=/dev/ad4 if=/dev/ad6 bs=1m
>>>
>>> Kernel went in panic and automatic reboot in about an hour... <sigh>
>>>
>>> It gets worse... when it does reboot the disk drive will not show in 
>>> the BIOS, nor does FreeBSD recognize it during boot. The system 
>>> actually has to be turned off to reset the drive...
>>>
>>> This is bad...
>>>
>>> Any other suggestions?
>>>     
>>
>> Sounds like a bug in the support for your ATA hardware, or your
>> hardware is broken.  The very least you'll need to do is to obtain a
>> crashdump and debugging backtrace (see the developers handbook) and CC
>> it to sos@
>>
>>   
> This is getting funnier...
> I added:
> dumpdev="AUTO"
> to: rc.conf
> Rebooted the system and tried to get it to crash again...
> And indeed it does in process 9: taskq
>
> Then it starts dumping which takes a couple of seconds as the machine 
> has 2 GB Ram...
>
> Than it reboots... and the next thing you know... savecore does NOT 
> recognize a dump on the swap file system. If does not save anything to 
> /var/crash... <sigh>
> Tried this about 10 times... No luck...
>
> Any other idea's?
>
Well... since capturing a kernel debug dump does not seem to be working 
I had an other crash (is not that difficult to reproduce) and copied the 
console screen with the information...
Here it is, for whatever this is worth...

Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0x50
fault code              = supervisor read, page not present
instruction pointer     = 0x8:0xffffffff80289d6d
stack pointer           = 0x10:0xffffffffb1b06af0
frame pointer           = 0x10:0xffffff00468d9400
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 processor            = 9 (thread taskq)
trap number                    = 12
panic: page fault
cpuid = 0
Uptime: 16h56m17s
Dumping 2047 MB (2 chunks)
  chunk 0: 1MB (156 pages) .. ok
  chunk 1: 2047MB (524016 pages) 2031 2015 1999 1983 1967 1951 1935 1919 
1903 18
  87 ...
  ... 47 31 15 ... ok
 
 
  Dump complete
  Automatic reboot in 15 seconds - press a key on console ot abort
          



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?45944404.8050301>