Re: panic in propagate_priority w/ postgresql under heavy load

2005-11-04 Thread Koen Martens
Robert Watson wrote: > > On Sun, 2 Oct 2005, Koen Martens wrote: > >> kernel trap 12 with interrupts disabled >> >> >> Fatal trap 12: page fault while in kernel mode >> cpuid = 1; apic id = 06 >> fault virtual address = 0x24 >> fault code = supervisor read, page not present >> instr

Re: panic in propagate_priority w/ postgresql under heavy load

2005-11-04 Thread Koen Martens
Robert Watson wrote: On Sun, 2 Oct 2005, Koen Martens wrote: kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 06 fault virtual address = 0x24 fault code = supervisor read, page not present instruction pointer = 0x

Re: panic in propagate_priority w/ postgresql under heavy load

2005-10-05 Thread Robert Watson
On Sun, 2 Oct 2005, Koen Martens wrote: kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 06 fault virtual address = 0x24 fault code = supervisor read, page not present instruction pointer = 0x8:0xc051c253 stack poin

Re: panic in propagate_priority w/ postgresql under heavy load

2005-10-02 Thread Koen Martens
Robert Watson wrote: > I can't speak to the problem with the core dumps, as it sounds like that > is device/firmware related. However, I probably can lend a hand in > debugging the problems you're seeing. I don't think the dump problem is device/firmware related, as a reboot -d gives me a dump j

Re: panic in propagate_priority w/ postgresql under heavy load

2005-09-20 Thread John Baldwin
On Monday 19 September 2005 03:35 pm, Koen Martens wrote: > Vinod Kashyap wrote: > > You seem to be booting off of a 9000 (twa) controller and not 7000/8000 > > (twe). > > It could be because of a 9000 firmware bug that you are not being able > > to > > get the dump. The firmware wrongly interpret

Re: panic in propagate_priority w/ postgresql under heavy load

2005-09-20 Thread Robert Watson
On Mon, 19 Sep 2005, Koen Martens wrote: Without the debug stuff in the kernel, it crashed within 2 days, same story: postgresql process, function propagate_priority. However, no dump was written to disk :( Furthermore, i've been seeing the same crash (in propagate_priority) on another box

Re: panic in propagate_priority w/ postgresql under heavy load

2005-09-19 Thread Koen Martens
Vinod Kashyap wrote: > You seem to be booting off of a 9000 (twa) controller and not 7000/8000 > (twe). > It could be because of a 9000 firmware bug that you are not being able > to > get the dump. The firmware wrongly interprets physical address 0x0 as > invalid > during dumps, and fails the oper

Re: panic in propagate_priority w/ postgresql under heavy load

2005-09-08 Thread Mike Meyer
In <[EMAIL PROTECTED]>, Gary Jennejohn <[EMAIL PROTECTED]> typed: > Koen Martens writes: > > (Note: swap is 2048mb, physical memory is also 2048mb). > IIRC swap has to be a little (64kB?) bigger than memory because the > kernel writes a header containing necessary information about the > dump to sw

Re: panic in propagate_priority w/ postgresql under heavy load

2005-09-08 Thread Gary Jennejohn
Koen Martens writes: > (Note: swap is 2048mb, physical memory is also 2048mb). > IIRC swap has to be a little (64kB?) bigger than memory because the kernel writes a header containing necessary information about the dump to swap. --- Gary Jennejohn / garyjATjennejohnDOTorg gjATfreebsdDOTorg garyj

Re: panic in propagate_priority w/ postgresql under heavy load

2005-09-07 Thread Koen Martens
Vinod Kashyap wrote: > You seem to be booting off of a 9000 (twa) controller and not 7000/8000 > (twe). > It could be because of a 9000 firmware bug that you are not being able > to > get the dump. The firmware wrongly interprets physical address 0x0 as > invalid > during dumps, and fails the oper

Re: panic in propagate_priority w/ postgresql under heavy load

2005-09-02 Thread John Baldwin
On Thursday 01 September 2005 06:04 pm, Koen Martens wrote: > John Baldwin wrote: > > On Thursday 01 September 2005 01:02 pm, Koen Martens wrote: > >>I've had a little chat with neologism on ircnet/#freebsd about this > >>already, and done as he suggested: compile a debug kernel to obtain > >>a sta

RE: panic in propagate_priority w/ postgresql under heavy load

2005-09-01 Thread Vinod Kashyap
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Koen Martens > Sent: Thursday, September 01, 2005 3:11 PM > To: Dimitry Andric > Cc: freebsd-hackers@freebsd.org > Subject: Re: panic in propagate_priority w/ postgresql under >

Re: panic in propagate_priority w/ postgresql under heavy load

2005-09-01 Thread Koen Martens
Hi Dim, Dimitry Andric wrote: > On 2005-09-01 at 19:02:06 Koen Martens wrote: > >>Anyway, it seems the dump should've gone to the swap partition, but >>i'm into multi-user mode again so i guess i'll have to wait for >>another panic to obtain it? > > In RELENG_6, the dump device is chosen automa

Re: panic in propagate_priority w/ postgresql under heavy load

2005-09-01 Thread Koen Martens
John Baldwin wrote: > On Thursday 01 September 2005 01:02 pm, Koen Martens wrote: > >>I've had a little chat with neologism on ircnet/#freebsd about this >>already, and done as he suggested: compile a debug kernel to obtain >>a stack trace. > > Can you reproduce it with a kernel that has INVARIAN

Re: panic in propagate_priority w/ postgresql under heavy load

2005-09-01 Thread Dimitry Andric
On 2005-09-01 at 19:02:06 Koen Martens wrote: > Anyway, it seems the dump should've gone to the swap partition, but > i'm into multi-user mode again so i guess i'll have to wait for > another panic to obtain it? Yes. By now, if any dump was ever written to your swap partition, it will most proba

Re: panic in propagate_priority w/ postgresql under heavy load

2005-09-01 Thread John Baldwin
On Thursday 01 September 2005 01:02 pm, Koen Martens wrote: > Hi Hackers, > > I've had a little chat with neologism on ircnet/#freebsd about this > already, and done as he suggested: compile a debug kernel to obtain > a stack trace. Can you reproduce it with a kernel that has INVARIANTS and INVARI