Re: ufs related panic with latest current
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
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
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
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
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
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
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
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
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]"