On Mon, 4 Apr 2011 09:57:13 +0400
Yuri Pankov wrote:
> http://lists.freebsd.org/pipermail/freebsd-ports/2011-March/066146.html
>
> The workaround is `ln -sf j /etc/malloc.conf`.
Thanks a lot. It solved the issue. :-)
Sincerely,
Gour
--
“In the material world, conceptions of good and bad are
On Sat, Apr 2, 2011 at 1:44 AM, Pawel Jakub Dawidek wrote:
> On Thu, Mar 24, 2011 at 01:36:32PM -0700, Freddie Cash wrote:
>> [Not sure which list is most appropriate since it's using HAST + ZFS
>> on -RELEASE, -STABLE, and -CURRENT. Feel free to trim the CC: on
>> replies.]
>>
>> I'm having a he
Someone suggested I might get better results including the actual panic:
panic: Freeing unused sector 4918950 6 c41f
Meanwhile the core.txt.1 file is in my home directory on freefall.
Doug
#0 sched_switch (td=dwarf2_read_address: Corrupted DWARF expression.
) at /home/svn/head/sys/kern/
On Fri Apr 1 11, John Baldwin wrote:
> On Thursday, March 31, 2011 6:33:39 pm Alexander Best wrote:
> > hi there,
> >
> > i think there are multiple issues with devstat. i found the following in
> > devicestat.h:
> >
> > /*
> > * These types are intended to aid statistics gathering/display prog
I'm running into a bootup crash under sched_4bsd on HEAD. The crash
happens when I have a thread bound to a single CPU that isn't the BSP,
and that thread is scheduled. If the AP that the thread is bound
hasn't been started up, kick_other_cpu() crashes because
pcpu->pc_curthread is NULL for the A
On Monday, April 04, 2011 4:43:16 pm Alexander Best wrote:
> On Fri Apr 1 11, John Baldwin wrote:
> > This is probably due to the hard drives being IDE (really ATA) rather than
> > SCSI. I agree this should show the pass devices.
>
> h...one could argue. the drives are ATA, however they are
On Mon, Apr 04, 2011 at 01:09:32PM -0700, Doug Barton wrote:
> Someone suggested I might get better results including the actual panic:
>
> panic: Freeing unused sector 4918950 6 c41f
>
> Meanwhile the core.txt.1 file is in my home directory on freefall.
>
>
> Doug
>
>
> #0 sched_switch
currently in kernel stack traces I see:
[Switching to Thread 100246]
0x814617f3 in fio_local_to_global_packet () from
x/mumble.ko
(kgdb) bt
#0 0x814617f3 in () from x/mumble.ko
#1 0x8146171f in () from x/mumble.ko
[...]
#14 0x8
Hi All,
Is there some way I can setup a running FreeBSD - (I use PCBSD7.2) - to break
into kgdb when the system panics. I am trying to get a stack trace when "Fatal
trap 12: page fault while in kernel mode" happens.
thanks
david S.
This message and any attached d
On Mon, Apr 4, 2011 at 7:35 PM, David Somayajulu
wrote:
> Hi All,
> Is there some way I can setup a running FreeBSD - (I use PCBSD7.2) - to break
> into kgdb when the system panics. I am trying to get a stack trace when
> "Fatal trap 12: page fault while in kernel mode" happens.
debug.debugger_
On 4/4/11 4:35 PM, David Somayajulu wrote:
Hi All,
Is there some way I can setup a running FreeBSD - (I use PCBSD7.2) - to break into kgdb
when the system panics. I am trying to get a stack trace when "Fatal trap 12: page
fault while in kernel mode" happens.
thanks
david S.
sure but firstly h
On Mon, Apr 4, 2011 at 5:26 PM, Julian Elischer wrote:
> On 4/4/11 4:35 PM, David Somayajulu wrote:
>>
>> Hi All,
>> Is there some way I can setup a running FreeBSD - (I use PCBSD7.2) - to
>> break into kgdb when the system panics. I am trying to get a stack trace
>> when "Fatal trap 12: page faul
On Apr 4, 2011, at 6:57 PM, Julian Elischer wrote:
is there anyone here with enough gdb/kgdb source experience to know
what
we would need to put on the stack at fork_exit() to make it stop
when it
gets there?
not only is it annoying but it slows down debugging because kgdb and
the ddd
fron
13 matches
Mail list logo
