Re: ufs related panic with latest current

2003-09-11 Thread Dag-Erling Smørgrav
Tomi Vainio - Sun Finland <[EMAIL PROTECTED]> writes:
> If you could just give instructions what you wanna get when system
> panics I might be able to persuade the other that we should crash our
> system once more.

I already have.

DES
-- 
Dag-Erling Smørgrav - [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: ufs related panic with latest current

2003-09-10 Thread Tomi Vainio - Sun Finland
Dag-Erling Smørgrav writes:
 > 
 > It would be really useful to know where the fault lies.  We might even
 > (God forbid!) figure out a way to fix it.  You can easily force the
 > system to boot with less than the full amount of memory by setting
 > hw.physmem to e.g. "64m" in /boot/loader.conf or at the loader prompt.
 > 
If you could just give instructions what you wanna get when system
panics I might be able to persuade the other that we should crash our
system once more.

What scripts should we run continously until system panics?
What you want to check with kdb after system panics?

  Tomppa
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: ufs related panic with latest current

2003-09-10 Thread Dag-Erling Smørgrav
Tomi Vainio - Sun Finland <[EMAIL PROTECTED]> writes:
> Second trace didn't have anything to do with fs only fork system calls
> there so your expanation sounds reasonable.  We probably don't see this
> problem again because system now has enough memory (256M).

It would be really useful to know where the fault lies.  We might even
(God forbid!) figure out a way to fix it.  You can easily force the
system to boot with less than the full amount of memory by setting
hw.physmem to e.g. "64m" in /boot/loader.conf or at the loader prompt.

DES
-- 
Dag-Erling Smørgrav - [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: ufs related panic with latest current

2003-09-10 Thread Tomi Vainio - Sun Finland
Dag-Erling Smørgrav writes:
 > 
 > The backtrace you showed seems to indicate that the panic happened
 > somewhere in the softupdates code, but IIRC that code has a fairly
 > conservative built-in limit on memory consumption and degrades
 > gracefully when it hits that limit.  It's likely that something else
 > gobbled up all available kernel memory, and the mallloc() call from
 > softupdates was simply the straw that broke the camel's back.
 > 
 > If you have a serial console hooked up, you could try running
 > 
 > while :; do vmstat -m ; sleep 1 ; done
 > 
Second trace didn't have anything to do with fs only fork system calls
there so your expanation sounds reasonable.  We probably don't see this
problem again because system now has enough memory (256M).

  Tomppa
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: ufs related panic with latest current

2003-09-10 Thread Dag-Erling Smørgrav
Tomi Vainio - Sun Finland <[EMAIL PROTECTED]> writes:
> Dag-Erling Smørgrav writes:
>  > Tomi Vainio - Sun Finland <[EMAIL PROTECTED]> writes:
>  > > First maxusers was 0 then when changed it to 8.
>  > That's a regression.  Keep it at 0.
> I understood that there is a bug on new kmem allocator and this was an
> attempt to reduce kmem allocations but it didn't help.  Do you know if
> this is going to fixed somehow or should people just install more
> memory to get system stay up?

Well, reducing maxusers isn't going to help much as it only controls a
small part of kernel memory, and setting it too low may render the
system unusable.

The backtrace you showed seems to indicate that the panic happened
somewhere in the softupdates code, but IIRC that code has a fairly
conservative built-in limit on memory consumption and degrades
gracefully when it hits that limit.  It's likely that something else
gobbled up all available kernel memory, and the mallloc() call from
softupdates was simply the straw that broke the camel's back.

If you have a serial console hooked up, you could try running

while :; do vmstat -m ; sleep 1 ; done

on the serial console while doing whatever it is you do that causes
the problem.  This will tell you how much kernel memory was in use at
the time of the panic and what it was used for.

DES
-- 
Dag-Erling Smørgrav - [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: ufs related panic with latest current

2003-09-10 Thread Tomi Vainio - Sun Finland
Dag-Erling Smørgrav writes:
 > Tomi Vainio - Sun Finland <[EMAIL PROTECTED]> writes:
 > > First maxusers was 0 then when changed it to 8.
 > 
 > That's a regression.  Keep it at 0.
 > 
I understood that there is a bug on new kmem allocator and this was an
attempt to reduce kmem allocations but it didn't help.  Do you know if
this is going to fixed somehow or should people just install more
memory to get system stay up?

  Tomppa
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: ufs related panic with latest current

2003-09-10 Thread Dag-Erling Smørgrav
Tomi Vainio - Sun Finland <[EMAIL PROTECTED]> writes:
> First maxusers was 0 then when changed it to 8.

That's a regression.  Keep it at 0.

DES
-- 
Dag-Erling Smørgrav - [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: ufs related panic with latest current

2003-09-10 Thread Tomi Vainio - Sun Finland
Doug White writes:
 > On Tue, 9 Sep 2003, Tomi Vainio - Sun Finland wrote:
 > 
 > > Tomi Vainio - Sun Finland writes:
 > >  > Our system died when using iozone -a to ~300G vinum partition made
 > >  > from four disks.  Sources were cvsupped 7.9.2003.
 > >  >
 > > Second panic an hour later.  Any good ideas how to fix this?
 > >
 > >   Tomppa
 > >
 > > panic: kmem_malloc(4096): kmem_map too small: 28229632 total allocated
 > 
 > How much RAM is in the system? What do you have maxusers set to?
 > 
First maxusers was 0 then when changed it to 8.  When system was still
unstable we added memory from 64M to 256M.  Now uptime is already 7
hours and we are waiting results.

  Tomppa
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: ufs related panic with latest current

2003-09-10 Thread Doug White
On Tue, 9 Sep 2003, Tomi Vainio - Sun Finland wrote:

> Tomi Vainio - Sun Finland writes:
>  > Our system died when using iozone -a to ~300G vinum partition made
>  > from four disks.  Sources were cvsupped 7.9.2003.
>  >
> Second panic an hour later.  Any good ideas how to fix this?
>
>   Tomppa
>
> panic: kmem_malloc(4096): kmem_map too small: 28229632 total allocated

How much RAM is in the system? What do you have maxusers set to?



> trace
> Debugger(c03cc728,c0429ce0,c03db0bd,ca3c6a80,100) at Debugger+0x54
> panic(c03db0bd,1000,1aec000,ca3c6ab0,ca3c6aa0) at panic+0xd5
> kmem_malloc(c082f0b0,1000,2,ca3c6b28,c034d1c5) at kmem_malloc+0x100
> page_alloc(c083aee0,1000,ca3c6b13,2,0) at page_alloc+0x27
> slab_zalloc(c083aee0,102,c09fc900,8108000,ca3c6cb8) at slab_zalloc+0xc5
> uma_zone_slab(c083aee0,102,ca3c6bbf,ca3c6bc0,a4) at uma_zone_slab+0xe8
> uma_zalloc_bucket(c083aee0,102,0,f,1) at uma_zalloc_bucket+0x185
> uma_zalloc_arg(c083aee0,0,102,ca3c6bfc,c083aee0) at uma_zalloc_arg+0x2c7
> malloc(adc,c03f8480,102,384,384) at malloc+0x5c
> sigacts_alloc(c0429b00,0,0,280f3000,c026af9d) at sigacts_alloc+0x25
> fork1(c1224be0,14,0,ca3c6ccc,c022c226) at fork1+0x7ab
> fork(c1224be0,ca3c6d10,2,c,0) at fork+0x2b
> syscall(2f,2f,2f,0,8108000) at syscall+0x2b0
> Xint0x80_syscall() at Xint0x80_syscall+0x1d
> --- syscall (2, FreeBSD ELF32, fork), eip = 0x807c3a7, esp = 0xbfbffb5c, ebp = 0
> xbfbffb88 ---
> db>
> ___
> [EMAIL PROTECTED] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
>

-- 
Doug White|  FreeBSD: The Power to Serve
[EMAIL PROTECTED]  |  www.FreeBSD.org
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"