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
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]
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
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
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: 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: 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: 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: 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]
ufs related panic with latest current
Our system died when using iozone -a to ~300G vinum partition made from four disks. Sources were cvsupped 7.9.2003. Tomppa kmem_malloc(8192): kmem_map too small: 28229632 total allocated db trace Debugger(c03cc728,c0429ce0,c03db0bd,ca6c4800,100) at Debugger+0x54 panic(c03db0bd,1000,1aec000,ca6c4830,c15ee720) at panic+0xd5 kmem_malloc(c082f0b0,1000,402,ca6c48a8,c034d1c5) at kmem_malloc+0x100 page_alloc(c083a9a0,1000,ca6c4893,402,c1416640) at page_alloc+0x27 slab_zalloc(c083a9a0,502,0,c03463cb,c0934738) at slab_zalloc+0xc5 uma_zone_slab(c083a9a0,502,c288c000,c24f8c90,4) at uma_zone_slab+0xe8 uma_zalloc_bucket(c083a9a0,502,c24f52a8,c17557fc,c24f8b60) at uma_zalloc_bucket+ 0x185 uma_zalloc_arg(c083a9a0,0,502,0,c083a9a0) at uma_zalloc_arg+0x2c7 malloc(3c,c0407640,502,0,1a180) at malloc+0x5c newallocindir(c1a0ae38,38e,1a180,0,0) at newallocindir+0x37 softdep_setup_allocindir_page(c1a0ae38,39a,0,c2516ae8,38e) at softdep_setup_allo cindir_page+0x3d ffs_balloc_ufs1(c17557fc,e68000,0,4000,c146a500) at ffs_balloc_ufs1+0xee9 ffs_write(ca6c4bc4,20002,c15ee720,0,ca6c4c70) at ffs_write+0x447 vn_write(c16b3594,ca6c4c70,c146a500,0,c15ee720) at vn_write+0x233 dofilewrite(c15ee720,c16b3594,3,810,8) at dofilewrite+0xf8 write(c15ee720,ca6c4d10,c,c15ee720,3) at write+0x6e syscall(4002f,2817002f,bfbf002f,8,bfbff7c0) at syscall+0x2b0 Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (4, FreeBSD ELF32, write), eip = 0x280e5b3f, esp = 0xbfbff70c, ebp = 0xbfbff728 --- db Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.1-CURRENT #7: Mon Sep 8 17:09:29 EEST 2003 Preloaded elf kernel /boot/kernel/kernel at 0xc04ec000. Calibrating clock(s) ... i8254 clock: 1193374 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter i8254 frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 601365089 Hz CPU: Intel Celeron (601.37-MHz 686-class CPU) Origin = GenuineIntel Id = 0x683 Stepping = 3 Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE real memory = 67108864 (64 MB) Physical memory chunk(s): 0x1000 - 0x0009, 651264 bytes (159 pages) 0x00513000 - 0x03eb9fff, 60452864 bytes (14759 pages) avail memory = 59953152 (57 MB) bios32: Found BIOS32 Service Directory header at 0xc00fb080 bios32: Entry = 0xfb4f0 (c00fb4f0) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf+0xb520 pnpbios: Found PnP BIOS data at 0xc00fbed0 pnpbios: Entry = f:bf00 Rev = 1.0 Other BIOS signatures found: random: entropy source netsmb_dev: loaded null: null device, zero device mem: memory I/O Pentium Pro MTRR support enabled npx0: [FAST] npx0: math processor on motherboard npx0: INT 16 interface pci_open(1):mode 1 addr port (0x0cf8) is 0x8058 pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=71908086) pcibios: BIOS version 2.10 Using $PIR table, 9 entries at 0xc00fde70 PCI-Only Interrupts: 5 10 11 12 Location Bus Device Pin Link IRQs slot 1 0 19A 0x62 3 4 5 7 9 10 11 12 14 15 slot 1 0 19B 0x63 3 4 5 7 9 10 11 12 14 15 slot 1 0 19C 0x60 3 4 5 7 9 10 11 12 14 15 slot 1 0 19D 0x61 3 4 5 7 9 10 11 12 14 15 slot 2 0 17A 0x60 3 4 5 7 9 10 11 12 14 15 slot 2 0 17B 0x61 3 4 5 7 9 10 11 12 14 15 slot 2 0 17C 0x62 3 4 5 7 9 10 11 12 14 15 slot 2 0 17D 0x63 3 4 5 7 9 10 11 12 14 15 slot 3 0 15A 0x61 3 4 5 7 9 10 11 12 14 15 slot 3 0 15B 0x63 3 4 5 7 9 10 11 12 14 15 slot 3 0 15C 0x62 3 4 5 7 9 10 11 12 14 15 slot 3 0 15D 0x60 3 4 5 7 9 10 11 12 14 15 slot 4 0 13A 0x62 3 4 5 7 9 10 11 12 14 15 slot 4 0 13B 0x63 3 4 5 7 9 10 11 12 14 15 slot 4 0 13C 0x60 3 4 5 7 9 10 11 12 14 15 slot 4 0 13D 0x61 3 4 5 7 9 10 11 12 14 15 slot 5 0 11A 0x63 3 4 5 7 9 10 11 12 14 15 slot 5 0 11B 0x60 3 4 5 7 9 10 11 12 14 15 slot 5 0 11C 0x61 3 4 5 7 9 10 11 12 14 15 slot 5 0 11D 0x62 3 4 5 7 9 10 11 12 14 15 slot 6 09A 0x61 3 4 5 7 9 10 11 12 14 15 slot 6 09B 0x60 3 4 5 7 9 10 11 12 14 15 slot 6 09C 0x63 3 4 5 7 9 10 11 12 14 15 slot 6 09D 0x62 3 4 5 7 9 10 11 12 14 15 slot 7 08A 0x62 3 4 5 7 9 10 11 12 14 15 slot 7 08B 0x63 3 4 5 7 9 10 11 12 14 15 slot 7 08C 0x60 3 4 5 7 9 10 11 12 14 15 slot 7 08D 0x61 3 4 5 7 9 10 11 12 14 15 embedded07A 0x60 3 4 5 7 9 10 11 12 14 15 embedded07B 0x61 3 4 5 7 9 10 11 12 14 15 embedded07C 0x62 3 4 5 7 9 10 11 12 14 15 embedded07
ufs related panic with latest current
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 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]
