* VM/VFS bug with large amount of memory and file systems? @ 2007-09-15 7:27 ` Anton Altaparmakov 0 siblings, 0 replies; 47+ messages in thread From: Anton Altaparmakov @ 2007-09-15 7:27 UTC (permalink / raw) To: Linux Kernel Mailing List, Linux Memory Management List; +Cc: marc.smith Hi, Mark Smith reported a OOM condition when he copies a large (46GiB) file from an NTFS partition (using the stock kernel driver) to /dev/ null (or to a file on ext3, same result). The machine this runs on has an i386 kernel with 12GiB RAM (yes this is not a typo it is 12GiB!). When you do: escabot CAD # ls -ltrh total 49G -r-------- 1 root root 2.0G Oct 7 2004 RTC26001.GHS -r-------- 1 root root 2.0G Oct 7 2004 RTC26002.GHS -r-------- 1 root root 2.0G Oct 7 2004 RTC2604.GHO -r-------- 1 root root 620M Oct 7 2004 RTC26003.GHS -r-------- 1 root root 4 Sep 14 09:32 asdf.txt -r-------- 1 root root 8 Sep 14 09:33 rty.txt -r-------- 1 root root 42G Sep 14 10:36 bigfile.gho escabot CAD # cp bigfile.gho /dev/null It dies with OOM and eventual panic with the message: "Kernel panic - not syncing: Out of memory and no killable processes." If Mark boots with "mem=2G" on the kernel command line and he then repeat thes above copy, then the copy succeeds just fine so there is nothing inherently wrong with NTFS. So the OOM happens with 12GiB RAM but not with 2GiB RAM. I guess this is why I have never seen this in my testing. My laptop only has 2GiB RAM... Below are relevant parts of the dmesg output that Mark sent that show what the kernel messages are when this happens. (I have taken out the NTFS debug output to make the log shorter but that does not show anything untoward and I can send it on request but it really just shows the file being read in and that's all!) Does anyone have any ideas / want to work with Mark (he is CC:-ed) to try and figure out the bug and get it fixed? I am sure Mark will be happy to provide further information/try things out... If it turns out to be something NTFS is doing wrong I am happy to try and fix it but at the moment I assume it is something the VM is doing wrong when there is so much RAM available... Best regards, Anton -- Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @) Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK Linux NTFS maintainer, http://www.linux-ntfs.org/ <quote from dmesg output> Sep 13 15:00:22 escabot Linux version 2.6.21-gentoo-r4 (root@escabot) (gcc version 4.1.2 (Gentoo 4.1.2 p1.0.1)) #3 SMP PREEMPT Thu Sep 13 14:44:12 EDT 2007 Sep 13 15:00:22 escabot BIOS-provided physical RAM map: Sep 13 15:00:22 escabot sanitize start Sep 13 15:00:22 escabot sanitize end Sep 13 15:00:22 escabot copy_e820_map() start: 0000000000000000 size: 000000000009ec00 end: 000000000009ec00 type: 1 Sep 13 15:00:22 escabot copy_e820_map() type is E820_RAM Sep 13 15:00:22 escabot copy_e820_map() start: 000000000009ec00 size: 0000000000001400 end: 00000000000a0000 type: 2 Sep 13 15:00:22 escabot copy_e820_map() start: 00000000000f0000 size: 0000000000010000 end: 0000000000100000 type: 2 Sep 13 15:00:22 escabot copy_e820_map() start: 0000000000100000 size: 00000000f56f8000 end: 00000000f57f8000 type: 1 Sep 13 15:00:22 escabot copy_e820_map() type is E820_RAM Sep 13 15:00:22 escabot copy_e820_map() start: 00000000f57f8000 size: 0000000000008000 end: 00000000f5800000 type: 3 Sep 13 15:00:22 escabot copy_e820_map() start: 00000000fdc00000 size: 0000000000001000 end: 00000000fdc01000 type: 2 Sep 13 15:00:22 escabot copy_e820_map() start: 00000000fdc10000 size: 0000000000001000 end: 00000000fdc11000 type: 2 Sep 13 15:00:22 escabot copy_e820_map() start: 00000000fec00000 size: 0000000000001000 end: 00000000fec01000 type: 2 Sep 13 15:00:22 escabot copy_e820_map() start: 00000000fec10000 size: 0000000000001000 end: 00000000fec11000 type: 2 Sep 13 15:00:22 escabot copy_e820_map() start: 00000000fec20000 size: 0000000000001000 end: 00000000fec21000 type: 2 Sep 13 15:00:22 escabot copy_e820_map() start: 00000000fee00000 size: 0000000000010000 end: 00000000fee10000 type: 2 Sep 13 15:00:22 escabot copy_e820_map() start: 00000000ff800000 size: 0000000000800000 end: 0000000100000000 type: 2 Sep 13 15:00:22 escabot copy_e820_map() start: 0000000100000000 size: 00000001fffff000 end: 00000002fffff000 type: 1 Sep 13 15:00:22 escabot copy_e820_map() type is E820_RAM Sep 13 15:00:22 escabot BIOS-e820: 0000000000000000 - 000000000009ec00 (usable) Sep 13 15:00:22 escabot BIOS-e820: 000000000009ec00 - 00000000000a0000 (reserved) Sep 13 15:00:22 escabot BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved) Sep 13 15:00:22 escabot BIOS-e820: 0000000000100000 - 00000000f57f8000 (usable) Sep 13 15:00:22 escabot BIOS-e820: 00000000f57f8000 - 00000000f5800000 (ACPI data) Sep 13 15:00:22 escabot BIOS-e820: 00000000fdc00000 - 00000000fdc01000 (reserved) Sep 13 15:00:22 escabot BIOS-e820: 00000000fdc10000 - 00000000fdc11000 (reserved) Sep 13 15:00:22 escabot BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved) Sep 13 15:00:22 escabot BIOS-e820: 00000000fec10000 - 00000000fec11000 (reserved) Sep 13 15:00:22 escabot BIOS-e820: 00000000fec20000 - 00000000fec21000 (reserved) Sep 13 15:00:22 escabot BIOS-e820: 00000000fee00000 - 00000000fee10000 (reserved) Sep 13 15:00:22 escabot BIOS-e820: 00000000ff800000 - 0000000100000000 (reserved) Sep 13 15:00:22 escabot BIOS-e820: 0000000100000000 - 00000002fffff000 (usable) Sep 13 15:00:22 escabot 11391MB HIGHMEM available. Sep 13 15:00:22 escabot 896MB LOWMEM available. Sep 13 15:00:22 escabot found SMP MP-table at 000f4fa0 Sep 13 15:00:22 escabot NX (Execute Disable) protection: active Sep 13 15:00:22 escabot Entering add_active_range(0, 0, 3145727) 0 entries of 256 used Sep 13 15:00:22 escabot Zone PFN ranges: Sep 13 15:00:22 escabot DMA 0 -> 4096 Sep 13 15:00:22 escabot Normal 4096 -> 229376 Sep 13 15:00:22 escabot HighMem 229376 -> 3145727 Sep 13 15:00:22 escabot early_node_map[1] active PFN ranges Sep 13 15:00:22 escabot 0: 0 -> 3145727 Sep 13 15:00:22 escabot On node 0 totalpages: 3145727 Sep 13 15:00:22 escabot DMA zone: 32 pages used for memmap Sep 13 15:00:22 escabot DMA zone: 0 pages reserved Sep 13 15:00:22 escabot DMA zone: 4064 pages, LIFO batch:0 Sep 13 15:00:22 escabot Normal zone: 1760 pages used for memmap Sep 13 15:00:22 escabot Normal zone: 223520 pages, LIFO batch:31 Sep 13 15:00:22 escabot HighMem zone: 22783 pages used for memmap Sep 13 15:00:22 escabot HighMem zone: 2893568 pages, LIFO batch:31 Sep 13 15:00:22 escabot DMI 2.3 present. Sep 13 15:00:22 escabot ACPI: RSDP 000F4F20, 0024 (r2 HP ) Sep 13 15:00:22 escabot ACPI: XSDT F57F83E0, 0044 (r1 HP A05 2 “\x04 162E) Sep 13 15:00:22 escabot ACPI: FACP F57F8460, 00F4 (r3 HP A05 2 “\x04 162E) Sep 13 15:00:22 escabot ACPI: DSDT F57F8560, 422D (r1 HP DSDT 1 MSFT 2000001) Sep 13 15:00:22 escabot ACPI: FACS F57F80C0, 0040 Sep 13 15:00:22 escabot ACPI: APIC F57F8100, 00B8 (r1 HP 00000083 2 0) Sep 13 15:00:22 escabot ACPI: SPCR F57F81E0, 0050 (r1 HP SPCRRBSU 1 “\x04 162E) Sep 13 15:00:22 escabot ACPI: SRAT F57F8260, 0150 (r1 HP A05 1 0) Sep 13 15:00:22 escabot ACPI: PM-Timer IO Port: 0x908 Sep 13 15:00:22 escabot ACPI: Local APIC address 0xfee00000 Sep 13 15:00:22 escabot ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Sep 13 15:00:22 escabot Processor #0 15:1 APIC version 16 Sep 13 15:00:22 escabot ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled) Sep 13 15:00:22 escabot Processor #2 15:1 APIC version 16 Sep 13 15:00:22 escabot ACPI: LAPIC (acpi_id[0x04] lapic_id[0x04] disabled) Sep 13 15:00:22 escabot ACPI: LAPIC (acpi_id[0x06] lapic_id[0x06] disabled) Sep 13 15:00:22 escabot ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled) Sep 13 15:00:22 escabot Processor #1 15:1 APIC version 16 Sep 13 15:00:22 escabot ACPI: LAPIC (acpi_id[0x03] lapic_id[0x03] enabled) Sep 13 15:00:22 escabot Processor #3 15:1 APIC version 16 Sep 13 15:00:22 escabot ACPI: LAPIC (acpi_id[0x05] lapic_id[0x05] disabled) Sep 13 15:00:22 escabot ACPI: LAPIC (acpi_id[0x07] lapic_id[0x07] disabled) Sep 13 15:00:22 escabot ACPI: LAPIC_NMI (acpi_id[0xff] high edge lint [0x1]) Sep 13 15:00:22 escabot ACPI: IOAPIC (id[0x04] address[0xfec00000] gsi_base[0]) Sep 13 15:00:22 escabot IOAPIC[0]: apic_id 4, version 17, address 0xfec00000, GSI 0-23 Sep 13 15:00:22 escabot ACPI: IOAPIC (id[0x05] address[0xfec10000] gsi_base[24]) Sep 13 15:00:22 escabot IOAPIC[1]: apic_id 5, version 17, address 0xfec10000, GSI 24-27 Sep 13 15:00:22 escabot ACPI: IOAPIC (id[0x06] address[0xfec20000] gsi_base[28]) Sep 13 15:00:22 escabot IOAPIC[2]: apic_id 6, version 17, address 0xfec20000, GSI 28-31 Sep 13 15:00:22 escabot ACPI: IOAPIC (id[0x07] address[0xfdc00000] gsi_base[32]) Sep 13 15:00:22 escabot IOAPIC[3]: apic_id 7, version 17, address 0xfdc00000, GSI 32-35 Sep 13 15:00:22 escabot ACPI: IOAPIC (id[0x08] address[0xfdc10000] gsi_base[36]) Sep 13 15:00:22 escabot IOAPIC[4]: apic_id 8, version 17, address 0xfdc10000, GSI 36-39 Sep 13 15:00:22 escabot ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge) Sep 13 15:00:22 escabot ACPI: IRQ0 used by override. Sep 13 15:00:22 escabot ACPI: IRQ2 used by override. Sep 13 15:00:22 escabot ACPI: IRQ9 used by override. Sep 13 15:00:22 escabot Enabling APIC mode: Flat. Using 5 I/O APICs Sep 13 15:00:22 escabot Using ACPI (MADT) for SMP configuration information Sep 13 15:00:22 escabot Allocating PCI resources starting at f6000000 (gap: f5800000:08400000) Sep 13 15:00:22 escabot Built 1 zonelists. Total pages: 3121152 Sep 13 15:00:22 escabot Kernel command line: debug_msgs=1 Sep 13 15:00:22 escabot mapped APIC to ffffd000 (fee00000) Sep 13 15:00:22 escabot mapped IOAPIC to ffffc000 (fec00000) Sep 13 15:00:22 escabot mapped IOAPIC to ffffb000 (fec10000) Sep 13 15:00:22 escabot mapped IOAPIC to ffffa000 (fec20000) Sep 13 15:00:22 escabot mapped IOAPIC to ffff9000 (fdc00000) Sep 13 15:00:22 escabot mapped IOAPIC to ffff8000 (fdc10000) Sep 13 15:00:22 escabot Enabling fast FPU save and restore... done. Sep 13 15:00:22 escabot Enabling unmasked SIMD FPU exception support... done. Sep 13 15:00:22 escabot Initializing CPU#0 Sep 13 15:00:22 escabot PID hash table entries: 4096 (order: 12, 16384 bytes) Sep 13 15:00:22 escabot Detected 2405.604 MHz processor. Sep 13 15:00:22 escabot Console: colour VGA+ 80x25 Sep 13 15:00:22 escabot Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Sep 13 15:00:22 escabot Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Sep 13 15:00:22 escabot Memory: 12304772k/12582908k available (3439k kernel code, 104940k reserved, 977k data, 240k init, 11493340k highmem) Sep 13 15:00:22 escabot virtual kernel memory layout: Sep 13 15:00:22 escabot fixmap : 0xfff4f000 - 0xfffff000 ( 704 kB) Sep 13 15:00:22 escabot pkmap : 0xffc00000 - 0xffe00000 (2048 kB) Sep 13 15:00:22 escabot vmalloc : 0xf8800000 - 0xffbfe000 ( 115 MB) Sep 13 15:00:22 escabot lowmem : 0xc0000000 - 0xf8000000 ( 896 MB) Sep 13 15:00:22 escabot .init : 0xc0558000 - 0xc0594000 ( 240 kB) Sep 13 15:00:22 escabot .data : 0xc045bce5 - 0xc055014c ( 977 kB) Sep 13 15:00:22 escabot .text : 0xc0100000 - 0xc045bce5 (3439 kB) Sep 13 15:00:22 escabot Checking if this processor honours the WP bit even in supervisor mode... Ok. Sep 13 15:00:22 escabot Calibrating delay using timer specific routine.. 4815.63 BogoMIPS (lpj=9631263) Sep 13 15:00:22 escabot Mount-cache hash table entries: 512 Sep 13 15:00:22 escabot CPU: After generic identify, caps: 178bfbff e3d3fbff 00000000 00000000 00000001 00000000 00000002 Sep 13 15:00:22 escabot CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) Sep 13 15:00:22 escabot CPU: L2 Cache: 1024K (64 bytes/line) Sep 13 15:00:22 escabot CPU 0(2) -> Core 0 Sep 13 15:00:22 escabot CPU: After all inits, caps: 178bfbff e3d3fbff 00000000 00000410 00000001 00000000 00000002 Sep 13 15:00:22 escabot Intel machine check architecture supported. Sep 13 15:00:22 escabot Intel machine check reporting enabled on CPU#0. Sep 13 15:00:22 escabot Compat vDSO mapped to ffffe000. Sep 13 15:00:22 escabot Checking 'hlt' instruction... OK. Sep 13 15:00:22 escabot Freeing SMP alternatives: 15k freed Sep 13 15:00:22 escabot ACPI: Core revision 20070126 Sep 13 15:00:22 escabot CPU0: AMD Opteron(tm) Processor 280 stepping 02 Sep 13 15:00:22 escabot Booting processor 1/1 eip 2000 Sep 13 15:00:22 escabot Initializing CPU#1 Sep 13 15:00:22 escabot Calibrating delay using timer specific routine.. 4811.22 BogoMIPS (lpj=9622459) Sep 13 15:00:22 escabot CPU: After generic identify, caps: 178bfbff e3d3fbff 00000000 00000000 00000001 00000000 00000002 Sep 13 15:00:22 escabot CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) Sep 13 15:00:22 escabot CPU: L2 Cache: 1024K (64 bytes/line) Sep 13 15:00:22 escabot CPU 1(2) -> Core 1 Sep 13 15:00:22 escabot CPU: After all inits, caps: 178bfbff e3d3fbff 00000000 00000410 00000001 00000000 00000002 Sep 13 15:00:22 escabot Intel machine check architecture supported. Sep 13 15:00:22 escabot Intel machine check reporting enabled on CPU#1. Sep 13 15:00:22 escabot CPU1: AMD Opteron(tm) Processor 280 stepping 02 Sep 13 15:00:22 escabot Booting processor 2/2 eip 2000 Sep 13 15:00:22 escabot Initializing CPU#2 Sep 13 15:00:22 escabot Calibrating delay using timer specific routine.. 4811.19 BogoMIPS (lpj=9622384) Sep 13 15:00:22 escabot CPU: After generic identify, caps: 178bfbff e3d3fbff 00000000 00000000 00000001 00000000 00000002 Sep 13 15:00:22 escabot CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) Sep 13 15:00:22 escabot CPU: L2 Cache: 1024K (64 bytes/line) Sep 13 15:00:22 escabot CPU 2(2) -> Core 0 Sep 13 15:00:22 escabot CPU: After all inits, caps: 178bfbff e3d3fbff 00000000 00000410 00000001 00000000 00000002 Sep 13 15:00:22 escabot Intel machine check architecture supported. Sep 13 15:00:22 escabot Intel machine check reporting enabled on CPU#2. Sep 13 15:00:22 escabot CPU2: AMD Opteron(tm) Processor 280 stepping 02 Sep 13 15:00:22 escabot Booting processor 3/3 eip 2000 Sep 13 15:00:22 escabot Initializing CPU#3 Sep 13 15:00:22 escabot Calibrating delay using timer specific routine.. 4811.27 BogoMIPS (lpj=9622546) Sep 13 15:00:22 escabot CPU: After generic identify, caps: 178bfbff e3d3fbff 00000000 00000000 00000001 00000000 00000002 Sep 13 15:00:22 escabot CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) Sep 13 15:00:22 escabot CPU: L2 Cache: 1024K (64 bytes/line) Sep 13 15:00:22 escabot CPU 3(2) -> Core 1 Sep 13 15:00:22 escabot CPU: After all inits, caps: 178bfbff e3d3fbff 00000000 00000410 00000001 00000000 00000002 Sep 13 15:00:22 escabot Intel machine check architecture supported. Sep 13 15:00:22 escabot Intel machine check reporting enabled on CPU#3. Sep 13 15:00:22 escabot CPU3: AMD Opteron(tm) Processor 280 stepping 02 Sep 13 15:00:22 escabot Total of 4 processors activated (19249.32 BogoMIPS). Sep 13 15:00:22 escabot ENABLING IO-APIC IRQs Sep 13 15:00:22 escabot ..TIMER: vector=0x31 apic1=0 pin1=2 apic2=0 pin2=0 Sep 13 15:00:22 escabot Brought up 4 CPUs Sep 13 15:00:22 escabot migration_cost=4000 Sep 13 15:00:22 escabot NET: Registered protocol family 16 Sep 13 15:00:22 escabot ACPI: bus type pci registered Sep 13 15:00:22 escabot PCI: PCI BIOS revision 2.10 entry at 0xf0096, last bus=6 Sep 13 15:00:22 escabot PCI: Using configuration type 1 Sep 13 15:00:22 escabot Setting up standard PCI resources Sep 13 15:00:22 escabot ACPI: SSDT F57FD000, 059D (r1 HP SSDT0 1 MSFT 2000001) Sep 13 15:00:22 escabot ACPI: SSDT F57FD700, 059D (r1 HP SSDT1 1 MSFT 2000001) Sep 13 15:00:22 escabot ACPI: SSDT F57FDE00, 059D (r1 HP SSDT2 1 MSFT 2000001) Sep 13 15:00:22 escabot ACPI: SSDT F57FE500, 059D (r1 HP SSDT3 1 MSFT 2000001) Sep 13 15:00:22 escabot ACPI: Interpreter enabled Sep 13 15:00:22 escabot ACPI: Using IOAPIC for interrupt routing Sep 13 15:00:22 escabot ACPI: PCI Root Bridge [CFG0] (0000:00) Sep 13 15:00:22 escabot PCI: Probing PCI hardware (bus 00) Sep 13 15:00:22 escabot Boot video device is 0000:01:03.0 Sep 13 15:00:22 escabot ACPI: PCI Interrupt Routing Table [\_SB_.CFG0._PRT] Sep 13 15:00:22 escabot ACPI: PCI Interrupt Routing Table [\_SB_.CFG0.PCI0._PRT] Sep 13 15:00:22 escabot ACPI: PCI Interrupt Routing Table [\_SB_.CFG0.PCI1._PRT] Sep 13 15:00:22 escabot ACPI: PCI Interrupt Routing Table [\_SB_.CFG0.PCI2._PRT] Sep 13 15:00:22 escabot ACPI: PCI Root Bridge [CFG1] (0000:04) Sep 13 15:00:22 escabot PCI: Probing PCI hardware (bus 04) Sep 13 15:00:22 escabot ACPI: PCI Interrupt Routing Table [\_SB_.CFG1.PCI3._PRT] Sep 13 15:00:22 escabot ACPI: PCI Interrupt Routing Table [\_SB_.CFG1.PCI4._PRT] Sep 13 15:00:22 escabot ACPI: PCI Interrupt Link [LNKA] (IRQs 3 5 *7 10 11) Sep 13 15:00:22 escabot ACPI: PCI Interrupt Link [LNKB] (IRQs 3 5 7 10 11) *15 Sep 13 15:00:22 escabot ACPI: PCI Interrupt Link [LNKC] (IRQs 3 5 7 *10 11) Sep 13 15:00:22 escabot ACPI: PCI Interrupt Link [LNKD] (IRQs 3 *5 7 10 11) Sep 13 15:00:22 escabot Linux Plug and Play Support v0.97 (c) Adam Belay Sep 13 15:00:22 escabot pnp: PnP ACPI init Sep 13 15:00:22 escabot pnp: PnP ACPI: found 10 devices Sep 13 15:00:22 escabot SCSI subsystem initialized Sep 13 15:00:22 escabot usbcore: registered new interface driver usbfs Sep 13 15:00:22 escabot usbcore: registered new interface driver hub Sep 13 15:00:22 escabot usbcore: registered new device driver usb Sep 13 15:00:22 escabot PCI: Using ACPI for IRQ routing Sep 13 15:00:22 escabot PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report Sep 13 15:00:22 escabot pnp: 00:01: ioport range 0x230-0x233 has been reserved Sep 13 15:00:22 escabot pnp: 00:01: ioport range 0x260-0x267 has been reserved Sep 13 15:00:22 escabot pnp: 00:01: ioport range 0x4d0-0x4d1 has been reserved Sep 13 15:00:22 escabot PCI: Bridge: 0000:00:03.0 Sep 13 15:00:22 escabot IO window: 4000-4fff Sep 13 15:00:22 escabot MEM window: f5f00000-f7bfffff Sep 13 15:00:22 escabot PREFETCH window: f8000000-f80fffff Sep 13 15:00:22 escabot PCI: Bridge: 0000:00:07.0 Sep 13 15:00:22 escabot IO window: 5000-5fff Sep 13 15:00:22 escabot MEM window: f7c00000-f7cfffff Sep 13 15:00:22 escabot PREFETCH window: f8100000-f81fffff Sep 13 15:00:22 escabot Time: acpi_pm clocksource has been installed. Sep 13 15:00:22 escabot PCI: Bridge: 0000:00:08.0 Sep 13 15:00:22 escabot IO window: disabled. Sep 13 15:00:22 escabot MEM window: f7d00000-f7dfffff Sep 13 15:00:22 escabot PREFETCH window: disabled. Sep 13 15:00:22 escabot PCI: Bridge: 0000:04:09.0 Sep 13 15:00:22 escabot IO window: 6000-6fff Sep 13 15:00:22 escabot MEM window: f7e00000-f7efffff Sep 13 15:00:22 escabot PREFETCH window: f8200000-f82fffff Sep 13 15:00:22 escabot PCI: Bridge: 0000:04:0a.0 Sep 13 15:00:22 escabot IO window: 7000-7fff Sep 13 15:00:22 escabot MEM window: f7f00000-f7ffffff Sep 13 15:00:22 escabot PREFETCH window: f8300000-f83fffff Sep 13 15:00:22 escabot NET: Registered protocol family 2 Sep 13 15:00:22 escabot IP route cache hash table entries: 32768 (order: 5, 131072 bytes) Sep 13 15:00:22 escabot TCP established hash table entries: 131072 (order: 9, 2097152 bytes) Sep 13 15:00:22 escabot TCP bind hash table entries: 65536 (order: 7, 786432 bytes) Sep 13 15:00:22 escabot TCP: Hash tables configured (established 131072 bind 65536) Sep 13 15:00:22 escabot TCP reno registered Sep 13 15:00:22 escabot checking if image is initramfs...it isn't (no cpio magic); looks like an initrd Sep 13 15:00:22 escabot Freeing initrd memory: 689k freed Sep 13 15:00:22 escabot Machine check exception polling timer started. Sep 13 15:00:22 escabot audit: initializing netlink socket (disabled) Sep 13 15:00:22 escabot audit(1189695589.692:1): initialized Sep 13 15:00:22 escabot highmem bounce pool size: 64 pages Sep 13 15:00:22 escabot Installing knfsd (copyright (C) 1996 okir@monad.swb.de). Sep 13 15:00:22 escabot NTFS driver 2.1.28 [Flags: R/W DEBUG]. Sep 13 15:00:22 escabot SGI XFS with ACLs, large block numbers, no debug enabled Sep 13 15:00:22 escabot SGI XFS Quota Management subsystem Sep 13 15:00:22 escabot io scheduler noop registered Sep 13 15:00:22 escabot io scheduler anticipatory registered (default) Sep 13 15:00:22 escabot io scheduler deadline registered Sep 13 15:00:22 escabot io scheduler cfq registered Sep 13 15:00:22 escabot Linux agpgart interface v0.102 (c) Dave Jones Sep 13 15:00:22 escabot [drm] Initialized drm 1.1.0 20060810 Sep 13 15:00:22 escabot input: Power Button (FF) as /class/input/input0 Sep 13 15:00:22 escabot ACPI: Power Button (FF) [PWRF] Sep 13 15:00:22 escabot Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled Sep 13 15:00:22 escabot serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A Sep 13 15:00:22 escabot serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A Sep 13 15:00:22 escabot 00:07: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A Sep 13 15:00:22 escabot Floppy drive(s): fd0 is 1.44M Sep 13 15:00:22 escabot FDC 0 is a National Semiconductor PC87306 Sep 13 15:00:22 escabot RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize Sep 13 15:00:22 escabot loop: loaded (max 8 devices) Sep 13 15:00:22 escabot Intel(R) PRO/1000 Network Driver - version 7.3.20-k2 Sep 13 15:00:22 escabot Copyright (c) 1999-2006 Intel Corporation. Sep 13 15:00:22 escabot ACPI: PCI Interrupt 0000:05:07.0[A] -> GSI 34 (level, low) -> IRQ 16 Sep 13 15:00:22 escabot e1000: 0000:05:07.0: e1000_probe: (PCI-X: 100MHz:64-bit) 00:11:0a:5b:21:98 Sep 13 15:00:22 escabot e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection Sep 13 15:00:22 escabot ACPI: PCI Interrupt 0000:05:07.1[B] -> GSI 35 (level, low) -> IRQ 17 Sep 13 15:00:22 escabot e1000: 0000:05:07.1: e1000_probe: (PCI-X: 100MHz:64-bit) 00:11:0a:5b:21:99 Sep 13 15:00:22 escabot e1000: eth1: e1000_probe: Intel(R) PRO/1000 Network Connection Sep 13 15:00:22 escabot tg3.c:v3.75.2 (June 5, 2007) Sep 13 15:00:22 escabot ACPI: PCI Interrupt 0000:03:06.0[A] -> GSI 28 (level, low) -> IRQ 18 Sep 13 15:00:22 escabot eth2: Tigon3 [partno(N/A) rev 2100 PHY(5704)] (PCIX:133MHz:64-bit) 10/100/1000Base-T Ethernet 00:16:35:3b:6b:74 Sep 13 15:00:22 escabot eth2: RXcsums[1] LinkChgREG[0] MIirq[0] ASF [1] WireSpeed[1] TSOcap[0] Sep 13 15:00:22 escabot eth2: dma_rwctrl[769f4000] dma_mask[64-bit] Sep 13 15:00:22 escabot ACPI: PCI Interrupt 0000:03:06.1[B] -> GSI 29 (level, low) -> IRQ 19 Sep 13 15:00:22 escabot eth3: Tigon3 [partno(N/A) rev 2100 PHY(5704)] (PCIX:133MHz:64-bit) 10/100/1000Base-T Ethernet 00:16:35:3b:6b:73 Sep 13 15:00:22 escabot eth3: RXcsums[1] LinkChgREG[0] MIirq[0] ASF [0] WireSpeed[1] TSOcap[1] Sep 13 15:00:22 escabot eth3: dma_rwctrl[769f4000] dma_mask[64-bit] Sep 13 15:00:22 escabot Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 Sep 13 15:00:22 escabot ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx Sep 13 15:00:22 escabot Probing IDE interface ide0... Sep 13 15:00:22 escabot hda: CD-224E, ATAPI CD/DVD-ROM drive Sep 13 15:00:22 escabot Probing IDE interface ide1... Sep 13 15:00:22 escabot ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 Sep 13 15:00:22 escabot hda: ATAPI 24X CD-ROM drive, 128kB Cache Sep 13 15:00:22 escabot Uniform CD-ROM driver Revision: 3.20 Sep 13 15:00:22 escabot megaraid cmm: 2.20.2.7 (Release Date: Sun Jul 16 00:01:03 EST 2006) Sep 13 15:00:22 escabot megaraid: 2.20.5.1 (Release Date: Thu Nov 16 15:32:35 EST 2006) Sep 13 15:00:22 escabot st: Version 20070203, fixed bufsize 32768, s/ g segs 256 Sep 13 15:00:22 escabot SCSI Media Changer driver v0.25 Sep 13 15:00:22 escabot usbmon: debugfs is not available Sep 13 15:00:22 escabot ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller (OHCI) Driver Sep 13 15:00:22 escabot ACPI: PCI Interrupt 0000:01:00.0[D] -> GSI 19 (level, low) -> IRQ 20 Sep 13 15:00:22 escabot ohci_hcd 0000:01:00.0: OHCI Host Controller Sep 13 15:00:22 escabot ohci_hcd 0000:01:00.0: new USB bus registered, assigned bus number 1 Sep 13 15:00:22 escabot ohci_hcd 0000:01:00.0: irq 20, io mem 0xf7bf0000 Sep 13 15:00:22 escabot usb usb1: configuration #1 chosen from 1 choice Sep 13 15:00:22 escabot hub 1-0:1.0: USB hub found Sep 13 15:00:22 escabot hub 1-0:1.0: 3 ports detected Sep 13 15:00:22 escabot ACPI: PCI Interrupt 0000:01:00.1[D] -> GSI 19 (level, low) -> IRQ 20 Sep 13 15:00:22 escabot ohci_hcd 0000:01:00.1: OHCI Host Controller Sep 13 15:00:22 escabot ohci_hcd 0000:01:00.1: new USB bus registered, assigned bus number 2 Sep 13 15:00:22 escabot ohci_hcd 0000:01:00.1: irq 20, io mem 0xf7be0000 Sep 13 15:00:22 escabot usb usb2: configuration #1 chosen from 1 choice Sep 13 15:00:22 escabot hub 2-0:1.0: USB hub found Sep 13 15:00:22 escabot hub 2-0:1.0: 3 ports detected Sep 13 15:00:22 escabot usbcore: registered new interface driver usblp Sep 13 15:00:22 escabot drivers/usb/class/usblp.c: v0.13: USB Printer Device Class driver Sep 13 15:00:22 escabot Initializing USB Mass Storage driver... Sep 13 15:00:22 escabot usbcore: registered new interface driver usb- storage Sep 13 15:00:22 escabot USB Mass Storage support registered. Sep 13 15:00:22 escabot usbcore: registered new interface driver usbhid Sep 13 15:00:22 escabot drivers/usb/input/hid-core.c: v2.6:USB HID core driver Sep 13 15:00:22 escabot PNP: PS/2 Controller [PNP0303:KBD,PNP0f0e:PS2M] at 0x60,0x64 irq 1,12 Sep 13 15:00:22 escabot serio: i8042 KBD port at 0x60,0x64 irq 1 Sep 13 15:00:22 escabot serio: i8042 AUX port at 0x60,0x64 irq 12 Sep 13 15:00:22 escabot mice: PS/2 mouse device common for all mice Sep 13 15:00:22 escabot input: AT Translated Set 2 keyboard as /class/ input/input1 Sep 13 15:00:22 escabot oprofile: using NMI interrupt. Sep 13 15:00:22 escabot TCP cubic registered Sep 13 15:00:22 escabot NET: Registered protocol family 1 Sep 13 15:00:22 escabot NET: Registered protocol family 17 Sep 13 15:00:22 escabot Starting balanced_irq Sep 13 15:00:22 escabot Using IPI Shortcut mode Sep 13 15:00:22 escabot input: ImExPS/2 Logitech Explorer Mouse as / class/input/input2 Sep 13 15:00:22 escabot RAMDISK: Compressed image found at block 0 Sep 13 15:00:22 escabot VFS: Mounted root (ext2 filesystem). Sep 13 15:00:22 escabot QLogic Fibre Channel HBA Driver Sep 13 15:00:22 escabot ACPI: PCI Interrupt 0000:05:08.0[A] -> GSI 32 (level, low) -> IRQ 21 Sep 13 15:00:22 escabot qla2300 0000:05:08.0: Found an ISP2312, irq 21, iobase 0xf8834000 Sep 13 15:00:22 escabot qla2300 0000:05:08.0: Configuring PCI space... Sep 13 15:00:22 escabot qla2300 0000:05:08.0: Configure NVRAM parameters... Sep 13 15:00:22 escabot qla2300 0000:05:08.0: Verifying loaded RISC code... Sep 13 15:00:22 escabot qla2300 0000:05:08.0: Allocated (412 KB) for firmware dump... Sep 13 15:00:22 escabot qla2300 0000:05:08.0: Waiting for LIP to complete... Sep 13 15:00:22 escabot qla2300 0000:05:08.0: LOOP UP detected (2 Gbps). Sep 13 15:00:22 escabot qla2300 0000:05:08.0: Topology - (F_Port), Host Loop address 0xffff Sep 13 15:00:22 escabot scsi0 : qla2xxx Sep 13 15:00:22 escabot qla2300 0000:05:08.0: Sep 13 15:00:22 escabot QLogic Fibre Channel HBA Driver: 8.01.07-fo Sep 13 15:00:22 escabot QLogic QLA2340 - Sep 13 15:00:22 escabot ISP2312: PCI-X (100 MHz) @ 0000:05:08.0 hdma +, host#=0, fw=3.03.19 IPX Sep 13 15:00:22 escabot scsi 0:0:0:0: Direct-Access SUN CSM200_R 0619 PQ: 0 ANSI: 5 Sep 13 15:00:22 escabot qla2300 0000:05:08.0: scsi(0:0:0:0): Enabled tagged queuing, queue depth 32. Sep 13 15:00:22 escabot sd 0:0:0:0: [sda] 104857600 512-byte hardware sectors (53687 MB) Sep 13 15:00:22 escabot sd 0:0:0:0: [sda] Write Protect is off Sep 13 15:00:22 escabot sd 0:0:0:0: [sda] Mode Sense: 77 00 10 08 Sep 13 15:00:22 escabot sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, supports DPO and FUA Sep 13 15:00:22 escabot sd 0:0:0:0: [sda] 104857600 512-byte hardware sectors (53687 MB) Sep 13 15:00:22 escabot sd 0:0:0:0: [sda] Write Protect is off Sep 13 15:00:22 escabot sd 0:0:0:0: [sda] Mode Sense: 77 00 10 08 Sep 13 15:00:22 escabot sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, supports DPO and FUA Sep 13 15:00:22 escabot sda: sda1 sda2 sda3 Sep 13 15:00:22 escabot sd 0:0:0:0: [sda] Attached SCSI disk Sep 13 15:00:22 escabot sd 0:0:0:0: Attached scsi generic sg0 type 0 Sep 13 15:00:22 escabot scsi 0:0:0:1: Direct-Access SUN CSM200_R 0619 PQ: 0 ANSI: 5 Sep 13 15:00:22 escabot qla2300 0000:05:08.0: scsi(0:0:0:1): Enabled tagged queuing, queue depth 32. Sep 13 15:00:22 escabot sd 0:0:0:1: [sdb] 104857600 512-byte hardware sectors (53687 MB) Sep 13 15:00:22 escabot sd 0:0:0:1: [sdb] Write Protect is off Sep 13 15:00:22 escabot sd 0:0:0:1: [sdb] Mode Sense: 77 00 10 08 Sep 13 15:00:22 escabot sd 0:0:0:1: [sdb] Write cache: enabled, read cache: enabled, supports DPO and FUA Sep 13 15:00:22 escabot sd 0:0:0:1: [sdb] 104857600 512-byte hardware sectors (53687 MB) Sep 13 15:00:22 escabot sd 0:0:0:1: [sdb] Write Protect is off Sep 13 15:00:22 escabot sd 0:0:0:1: [sdb] Mode Sense: 77 00 10 08 Sep 13 15:00:22 escabot sd 0:0:0:1: [sdb] Write cache: enabled, read cache: enabled, supports DPO and FUA Sep 13 15:00:22 escabot sdb: sdb1 Sep 13 15:00:22 escabot sd 0:0:0:1: [sdb] Attached SCSI disk Sep 13 15:00:22 escabot sd 0:0:0:1: Attached scsi generic sg1 type 0 Sep 13 15:00:22 escabot ACPI: PCI Interrupt 0000:06:09.0[A] -> GSI 36 (level, low) -> IRQ 22 Sep 13 15:00:22 escabot qla2300 0000:06:09.0: Found an ISP2312, irq 22, iobase 0xf8836000 Sep 13 15:00:22 escabot qla2300 0000:06:09.0: Configuring PCI space... Sep 13 15:00:22 escabot qla2300 0000:06:09.0: Configure NVRAM parameters... Sep 13 15:00:22 escabot qla2300 0000:06:09.0: Verifying loaded RISC code... Sep 13 15:00:22 escabot qla2300 0000:06:09.0: Allocated (412 KB) for firmware dump... Sep 13 15:00:22 escabot qla2300 0000:06:09.0: Waiting for LIP to complete... Sep 13 15:00:22 escabot qla2300 0000:06:09.0: LIP reset occured (f8f7). Sep 13 15:00:22 escabot qla2300 0000:06:09.0: LIP occured (f8f7). Sep 13 15:00:22 escabot qla2300 0000:06:09.0: LIP reset occured (f7f7). Sep 13 15:00:22 escabot qla2300 0000:06:09.0: LOOP UP detected (2 Gbps). Sep 13 15:00:22 escabot qla2300 0000:06:09.0: Topology - (F_Port), Host Loop address 0xffff Sep 13 15:00:22 escabot scsi1 : qla2xxx Sep 13 15:00:22 escabot qla2300 0000:06:09.0: Sep 13 15:00:22 escabot QLogic Fibre Channel HBA Driver: 8.01.07-fo Sep 13 15:00:22 escabot QLogic QLA2340 - Sep 13 15:00:22 escabot ISP2312: PCI-X (133 MHz) @ 0000:06:09.0 hdma +, host#=1, fw=3.03.19 IPX Sep 13 15:00:22 escabot scsi 1:0:0:0: Sequential-Access IBM ULTRIUM-TD3 54K1 PQ: 0 ANSI: 3 Sep 13 15:00:22 escabot qla2300 0000:06:09.0: scsi(1:0:0:0): Enabled tagged queuing, queue depth 32. Sep 13 15:00:22 escabot st 1:0:0:0: Attached scsi tape st0 Sep 13 15:00:22 escabot st 1:0:0:0: st0: try direct i/o: yes (alignment 512 B) Sep 13 15:00:22 escabot st 1:0:0:0: Attached scsi generic sg2 type 1 Sep 13 15:00:22 escabot scsi 1:0:0:1: Medium Changer SPECTRA PYTHON 2000 PQ: 0 ANSI: 3 Sep 13 15:00:22 escabot ch0: type #1 (mt): 0x1+1 [medium transport] Sep 13 15:00:22 escabot ch0: type #2 (st): 0x1000+30 [storage] Sep 13 15:00:22 escabot ch0: type #3 (ie): 0x10+0 [import/export] Sep 13 15:00:22 escabot ch0: type #4 (dt): 0x100+2 [data transfer] Sep 13 15:00:22 escabot ch0: dt 0x100: ID/LUN unknown Sep 13 15:00:22 escabot ch0: dt 0x101: ID/LUN unknown Sep 13 15:00:22 escabot ch0: INITIALIZE ELEMENT STATUS, may take some time ... Sep 13 15:00:22 escabot ch0: ... finished Sep 13 15:00:22 escabot ch 1:0:0:1: Attached scsi changer ch0 Sep 13 15:00:22 escabot ch 1:0:0:1: Attached scsi generic sg3 type 8 Sep 13 15:00:22 escabot scsi 1:0:1:0: Sequential-Access IBM ULTRIUM-TD3 54K1 PQ: 0 ANSI: 3 Sep 13 15:00:22 escabot qla2300 0000:06:09.0: scsi(1:0:1:0): Enabled tagged queuing, queue depth 32. Sep 13 15:00:22 escabot st 1:0:1:0: Attached scsi tape st1 Sep 13 15:00:22 escabot st 1:0:1:0: st1: try direct i/o: yes (alignment 512 B) Sep 13 15:00:22 escabot st 1:0:1:0: Attached scsi generic sg4 type 1 Sep 13 15:00:22 escabot kjournald starting. Commit interval 5 seconds Sep 13 15:00:22 escabot EXT3-fs: mounted filesystem with ordered data mode. Sep 13 15:00:22 escabot Freeing unused kernel memory: 240k freed Sep 13 15:00:22 escabot EXT3 FS on sda3, internal journal Sep 13 15:00:22 escabot kjournald starting. Commit interval 5 seconds Sep 13 15:00:22 escabot EXT3 FS on sdb1, internal journal Sep 13 15:00:22 escabot EXT3-fs: mounted filesystem with ordered data mode. Sep 13 15:00:22 escabot Adding 2008116k swap on /dev/sda2. Priority:-1 extents:1 across:2008116k Sep 13 15:00:22 escabot PM: Writing back config space on device 0000:03:06.0 at offset b (was 164814e4, writing d00e11) Sep 13 15:00:22 escabot PM: Writing back config space on device 0000:03:06.0 at offset 3 (was 804000, writing 804010) Sep 13 15:00:22 escabot PM: Writing back config space on device 0000:03:06.0 at offset 2 (was 2000000, writing 2000010) Sep 13 15:00:22 escabot PM: Writing back config space on device 0000:03:06.0 at offset 1 (was 2b00000, writing 2b00146) Sep 13 15:00:22 escabot tg3: eth2: Link is up at 1000 Mbps, full duplex. Sep 13 15:00:22 escabot tg3: eth2: Flow control is on for TX and on for RX. Sep 13 15:00:22 escabot PM: Writing back config space on device 0000:03:06.1 at offset b (was 164814e4, writing d00e11) Sep 13 15:00:22 escabot PM: Writing back config space on device 0000:03:06.1 at offset 3 (was 804000, writing 804010) Sep 13 15:00:22 escabot PM: Writing back config space on device 0000:03:06.1 at offset 2 (was 2000000, writing 2000010) Sep 13 15:00:22 escabot PM: Writing back config space on device 0000:03:06.1 at offset 1 (was 2b00000, writing 2b00146) Sep 13 15:00:25 escabot st0: Block limits 1 - 16777215 bytes. Sep 13 15:00:25 escabot st1: Block limits 1 - 16777215 bytes. Sep 13 15:00:25 escabot tg3: eth3: Link is up at 1000 Mbps, full duplex. Sep 13 15:00:25 escabot tg3: eth3: Flow control is on for TX and on for RX. Sep 13 15:04:16 escabot scsi 0:0:0:2: Direct-Access SUN CSM200_R 0619 PQ: 0 ANSI: 5 Sep 13 15:04:16 escabot qla2300 0000:05:08.0: scsi(0:0:0:2): Enabled tagged queuing, queue depth 32. Sep 13 15:04:16 escabot sd 0:0:0:2: [sdc] 1048576000 512-byte hardware sectors (536871 MB) Sep 13 15:04:16 escabot sd 0:0:0:2: [sdc] Write Protect is off Sep 13 15:04:16 escabot sd 0:0:0:2: [sdc] Mode Sense: 77 00 10 08 Sep 13 15:04:16 escabot sd 0:0:0:2: [sdc] Write cache: enabled, read cache: enabled, supports DPO and FUA Sep 13 15:04:16 escabot sd 0:0:0:2: [sdc] 1048576000 512-byte hardware sectors (536871 MB) Sep 13 15:04:16 escabot sd 0:0:0:2: [sdc] Write Protect is off Sep 13 15:04:16 escabot sd 0:0:0:2: [sdc] Mode Sense: 77 00 10 08 Sep 13 15:04:16 escabot sd 0:0:0:2: [sdc] Write cache: enabled, read cache: enabled, supports DPO and FUA Sep 13 15:04:19 escabot sdc: sdc1 Sep 13 15:04:19 escabot sd 0:0:0:2: [sdc] Attached SCSI disk Sep 13 15:04:19 escabot sd 0:0:0:2: Attached scsi generic sg5 type 0 Sep 13 15:04:24 escabot sd 0:0:0:2: [sdc] 1048576000 512-byte hardware sectors (536871 MB) Sep 13 15:04:24 escabot sd 0:0:0:2: [sdc] Write Protect is off Sep 13 15:04:24 escabot sd 0:0:0:2: [sdc] Mode Sense: 77 00 10 08 Sep 13 15:04:24 escabot sd 0:0:0:2: [sdc] Write cache: enabled, read cache: enabled, supports DPO and FUA Sep 13 15:04:24 escabot sdc: sdc1 Sep 13 15:04:29 escabot NTFS volume version 3.1. Sep 13 15:31:25 escabot init invoked oom-killer: gfp_mask=0xd0, order=0, oomkilladj=0 Sep 13 15:31:25 escabot [<c0149ea8>] out_of_memory+0x158/0x1b0 Sep 13 15:31:25 escabot [<c014b7b0>] __alloc_pages+0x2a0/0x300 Sep 13 15:31:25 escabot [<c01729aa>] core_sys_select+0x1fa/0x2f0 Sep 13 15:31:25 escabot [<c0162a21>] cache_alloc_refill+0x2e1/0x500 Sep 13 15:31:25 escabot [<c0162736>] kmem_cache_alloc+0x46/0x50 Sep 13 15:31:25 escabot [<c016e238>] getname+0x28/0xf0 Sep 13 15:31:25 escabot [<c016fe5e>] __user_walk_fd+0x1e/0x60 Sep 13 15:31:25 escabot [<c0168e29>] cp_new_stat64+0xf9/0x110 Sep 13 15:31:25 escabot [<c0169152>] vfs_stat_fd+0x22/0x60 Sep 13 15:31:25 escabot [<c016922f>] sys_stat64+0xf/0x30 Sep 13 15:31:25 escabot [<c0124956>] do_gettimeofday+0x36/0xf0 Sep 13 15:31:25 escabot [<c0120bbf>] sys_time+0xf/0x30 Sep 13 15:31:25 escabot [<c0102b10>] sysenter_past_esp+0x5d/0x81 Sep 13 15:31:25 escabot ======================= Sep 13 15:31:25 escabot Mem-info: Sep 13 15:31:25 escabot DMA per-cpu: Sep 13 15:31:25 escabot CPU 0: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Sep 13 15:31:25 escabot CPU 1: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Sep 13 15:31:25 escabot CPU 2: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Sep 13 15:31:25 escabot CPU 3: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Sep 13 15:31:25 escabot Normal per-cpu: Sep 13 15:31:25 escabot CPU 0: Hot: hi: 186, btch: 31 usd: 143 Cold: hi: 62, btch: 15 usd: 56 Sep 13 15:31:25 escabot CPU 1: Hot: hi: 186, btch: 31 usd: 31 Cold: hi: 62, btch: 15 usd: 53 Sep 13 15:31:25 escabot CPU 2: Hot: hi: 186, btch: 31 usd: 8 Cold: hi: 62, btch: 15 usd: 54 Sep 13 15:31:25 escabot CPU 3: Hot: hi: 186, btch: 31 usd: 99 Cold: hi: 62, btch: 15 usd: 58 Sep 13 15:31:25 escabot HighMem per-cpu: Sep 13 15:31:25 escabot CPU 0: Hot: hi: 186, btch: 31 usd: 1 Cold: hi: 62, btch: 15 usd: 10 Sep 13 15:31:25 escabot CPU 1: Hot: hi: 186, btch: 31 usd: 23 Cold: hi: 62, btch: 15 usd: 1 Sep 13 15:31:25 escabot CPU 2: Hot: hi: 186, btch: 31 usd: 18 Cold: hi: 62, btch: 15 usd: 1 Sep 13 15:31:25 escabot CPU 3: Hot: hi: 186, btch: 31 usd: 9 Cold: hi: 62, btch: 15 usd: 12 Sep 13 15:31:25 escabot Active:8078 inactive:1776744 dirty:10338 writeback:0 unstable:0 Sep 13 15:31:25 escabot free:1090395 slab:198893 mapped:988 pagetables:129 bounce:0 Sep 13 15:31:25 escabot DMA free:3560kB min:68kB low:84kB high:100kB active:0kB inactive:0kB present:16256kB pages_scanned:0 all_unreclaimable? yes Sep 13 15:31:25 escabot lowmem_reserve[]: 0 873 12176 Sep 13 15:31:25 escabot Normal free:3648kB min:3744kB low:4680kB high: 5616kB active:0kB inactive:3160kB present:894080kB pages_scanned:5336 all_unreclaimable? yes Sep 13 15:31:25 escabot lowmem_reserve[]: 0 0 90424 Sep 13 15:31:25 escabot HighMem free:4354372kB min:512kB low:12640kB high:24768kB active:32312kB inactive:7103816kB present:11574272kB pages_scanned:0 all_unreclaimable? no Sep 13 15:31:25 escabot lowmem_reserve[]: 0 0 0 Sep 13 15:31:25 escabot DMA: 4*4kB 3*8kB 0*16kB 0*32kB 1*64kB 1*128kB 1*256kB 0*512kB 1*1024kB 1*2048kB 0*4096kB = 3560kB Sep 13 15:31:25 escabot Normal: 44*4kB 18*8kB 6*16kB 1*32kB 6*64kB 2*128kB 0*256kB 1*512kB 0*1024kB 1*2048kB 0*4096kB = 3648kB Sep 13 15:31:25 escabot HighMem: 1*4kB 0*8kB 0*16kB 37914*32kB 43188*64kB 1628*128kB 5*256kB 247*512kB 30*1024kB 1*2048kB 2*4096kB = 4354372kB Sep 13 15:31:25 escabot Swap cache: add 983, delete 972, find 0/1, race 0+0 Sep 13 15:31:25 escabot Free swap = 2004216kB Sep 13 15:31:25 escabot Total swap = 2008116kB Sep 13 15:31:25 escabot Free swap: 2004216kB Sep 13 15:31:25 escabot syslog-ng invoked oom-killer: gfp_mask=0xd0, order=0, oomkilladj=0 Sep 13 15:31:25 escabot [<c0149ea8>] out_of_memory+0x158/0x1b0 Sep 13 15:31:25 escabot [<c014b7b0>] __alloc_pages+0x2a0/0x300 Sep 13 15:31:25 escabot [<c0162a21>] cache_alloc_refill+0x2e1/0x500 Sep 13 15:31:25 escabot [<c0162736>] kmem_cache_alloc+0x46/0x50 Sep 13 15:31:25 escabot [<c016e238>] getname+0x28/0xf0 Sep 13 15:31:25 escabot [<c016fe5e>] __user_walk_fd+0x1e/0x60 Sep 13 15:31:25 escabot [<c0169152>] vfs_stat_fd+0x22/0x60 Sep 13 15:31:25 escabot [<c012f460>] autoremove_wake_function+0x0/0x50 Sep 13 15:31:25 escabot [<c0123928>] __capable+0x8/0x20 Sep 13 15:31:25 escabot [<c02d02ef>] cap_syslog+0x1f/0x30 Sep 13 15:31:25 escabot [<c0123928>] __capable+0x8/0x20 Sep 13 15:31:25 escabot [<c011d026>] do_syslog+0x3b6/0x3e0 Sep 13 15:31:25 escabot [<c016922f>] sys_stat64+0xf/0x30 Sep 13 15:31:25 escabot [<c0124956>] do_gettimeofday+0x36/0xf0 Sep 13 15:31:25 escabot [<c0120bbf>] sys_time+0xf/0x30 Sep 13 15:31:25 escabot [<c0102b10>] sysenter_past_esp+0x5d/0x81 Sep 13 15:31:25 escabot ======================= Sep 13 15:31:25 escabot Mem-info: Sep 13 15:31:25 escabot DMA per-cpu: Sep 13 15:31:25 escabot CPU 0: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Sep 13 15:31:25 escabot CPU 1: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Sep 13 15:31:25 escabot CPU 2: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Sep 13 15:31:25 escabot CPU 3: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Sep 13 15:31:25 escabot Normal per-cpu: Sep 13 15:31:25 escabot CPU 0: Hot: hi: 186, btch: 31 usd: 143 Cold: hi: 62, btch: 15 usd: 56 Sep 13 15:31:25 escabot CPU 1: Hot: hi: 186, btch: 31 usd: 31 Cold: hi: 62, btch: 15 usd: 53 Sep 13 15:31:25 escabot CPU 2: Hot: hi: 186, btch: 31 usd: 8 Cold: hi: 62, btch: 15 usd: 54 Sep 13 15:31:25 escabot CPU 3: Hot: hi: 186, btch: 31 usd: 99 Cold: hi: 62, btch: 15 usd: 58 Sep 13 15:31:25 escabot HighMem per-cpu: Sep 13 15:31:25 escabot CPU 0: Hot: hi: 186, btch: 31 usd: 1 Cold: hi: 62, btch: 15 usd: 10 Sep 13 15:31:25 escabot CPU 1: Hot: hi: 186, btch: 31 usd: 23 Cold: hi: 62, btch: 15 usd: 1 Sep 13 15:31:25 escabot CPU 2: Hot: hi: 186, btch: 31 usd: 18 Cold: hi: 62, btch: 15 usd: 1 Sep 13 15:31:25 escabot CPU 3: Hot: hi: 186, btch: 31 usd: 9 Cold: hi: 62, btch: 15 usd: 12 Sep 13 15:31:25 escabot Active:8078 inactive:1776744 dirty:10338 writeback:0 unstable:0 Sep 13 15:31:25 escabot free:1090395 slab:198893 mapped:988 pagetables:129 bounce:0 Sep 13 15:31:25 escabot DMA free:3560kB min:68kB low:84kB high:100kB active:0kB inactive:0kB present:16256kB pages_scanned:0 all_unreclaimable? yes Sep 13 15:31:25 escabot lowmem_reserve[]: 0 873 12176 Sep 13 15:31:25 escabot Normal free:3648kB min:3744kB low:4680kB high: 5616kB active:0kB inactive:3160kB present:894080kB pages_scanned:5336 all_unreclaimable? yes Sep 13 15:31:25 escabot lowmem_reserve[]: 0 0 90424 Sep 13 15:31:25 escabot HighMem free:4354372kB min:512kB low:12640kB high:24768kB active:32312kB inactive:7103816kB present:11574272kB pages_scanned:0 all_unreclaimable? no Sep 13 15:31:25 escabot lowmem_reserve[]: 0 0 0 Sep 13 15:31:25 escabot DMA: 4*4kB 3*8kB 0*16kB 0*32kB 1*64kB 1*128kB 1*256kB 0*512kB 1*1024kB 1*2048kB 0*4096kB = 3560kB Sep 13 15:31:25 escabot Normal: 44*4kB 18*8kB 6*16kB 1*32kB 6*64kB 2*128kB 0*256kB 1*512kB 0*1024kB 1*2048kB 0*4096kB = 3648kB Sep 13 15:31:25 escabot HighMem: 1*4kB 0*8kB 0*16kB 37914*32kB 43188*64kB 1628*128kB 5*256kB 247*512kB 30*1024kB 1*2048kB 2*4096kB = 4354372kB Sep 13 15:31:25 escabot Swap cache: add 983, delete 972, find 0/1, race 0+0 Sep 13 15:31:25 escabot Free swap = 2004216kB Sep 13 15:31:25 escabot Total swap = 2008116kB Sep 13 15:31:25 escabot Free swap: 2004216kB Sep 13 15:31:25 escabot 3145727 pages of RAM Sep 13 15:31:25 escabot 2916351 pages of HIGHMEM Sep 13 15:31:25 escabot 69112 reserved pages Sep 13 15:31:25 escabot 1781351 pages shared Sep 13 15:31:25 escabot 11 pages swap cached Sep 13 15:31:25 escabot 10338 pages dirty Sep 13 15:31:25 escabot 0 pages writeback Sep 13 15:31:25 escabot 988 pages mapped Sep 13 15:31:25 escabot 198893 pages slab Sep 13 15:31:25 escabot 129 pages pagetables Sep 13 15:31:25 escabot Out of memory: kill process 5771 (mysqld) score 35692 or a child Sep 13 15:31:25 escabot Killed process 5771 (mysqld) Sep 13 15:31:25 escabot init invoked oom-killer: gfp_mask=0xd0, order=0, oomkilladj=0 Sep 13 15:31:25 escabot [<c0149ea8>] out_of_memory+0x158/0x1b0 Sep 13 15:31:25 escabot [<c014b7b0>] __alloc_pages+0x2a0/0x300 Sep 13 15:31:25 escabot [<c01729aa>] core_sys_select+0x1fa/0x2f0 Sep 13 15:31:25 escabot [<c0162a21>] cache_alloc_refill+0x2e1/0x500 Sep 13 15:31:25 escabot [<c0162736>] kmem_cache_alloc+0x46/0x50 Sep 13 15:31:25 escabot [<c016e238>] getname+0x28/0xf0 Sep 13 15:31:25 escabot [<c016fe5e>] __user_walk_fd+0x1e/0x60 Sep 13 15:31:25 escabot [<c0168e29>] cp_new_stat64+0xf9/0x110 Sep 13 15:31:25 escabot [<c0169152>] vfs_stat_fd+0x22/0x60 Sep 13 15:31:25 escabot [<c016922f>] sys_stat64+0xf/0x30 Sep 13 15:31:25 escabot [<c0124956>] do_gettimeofday+0x36/0xf0 Sep 13 15:31:25 escabot [<c0120bbf>] sys_time+0xf/0x30 Sep 13 15:31:25 escabot [<c0102b10>] sysenter_past_esp+0x5d/0x81 Sep 13 15:31:25 escabot ======================= Sep 13 15:31:25 escabot Mem-info: Sep 13 15:31:25 escabot DMA per-cpu: Sep 13 15:31:25 escabot CPU 0: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Sep 13 15:31:25 escabot CPU 1: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Sep 13 15:31:25 escabot CPU 2: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Sep 13 15:31:25 escabot CPU 3: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Sep 13 15:31:25 escabot Normal per-cpu: Sep 13 15:31:25 escabot CPU 0: Hot: hi: 186, btch: 31 usd: 143 Cold: hi: 62, btch: 15 usd: 56 Sep 13 15:31:25 escabot CPU 1: Hot: hi: 186, btch: 31 usd: 31 Cold: hi: 62, btch: 15 usd: 53 Sep 13 15:31:25 escabot CPU 2: Hot: hi: 186, btch: 31 usd: 8 Cold: hi: 62, btch: 15 usd: 54 Sep 13 15:31:25 escabot CPU 3: Hot: hi: 186, btch: 31 usd: 99 Cold: hi: 62, btch: 15 usd: 58 Sep 13 15:31:25 escabot HighMem per-cpu: Sep 13 15:31:25 escabot CPU 0: Hot: hi: 186, btch: 31 usd: 1 Cold: hi: 62, btch: 15 usd: 10 Sep 13 15:31:25 escabot CPU 1: Hot: hi: 186, btch: 31 usd: 23 Cold: hi: 62, btch: 15 usd: 1 Sep 13 15:31:25 escabot CPU 2: Hot: hi: 186, btch: 31 usd: 18 Cold: hi: 62, btch: 15 usd: 1 Sep 13 15:31:25 escabot CPU 3: Hot: hi: 186, btch: 31 usd: 9 Cold: hi: 62, btch: 15 usd: 12 Sep 13 15:31:25 escabot Active:8078 inactive:1776744 dirty:10338 writeback:0 unstable:0 Sep 13 15:31:25 escabot free:1090395 slab:198893 mapped:988 pagetables:129 bounce:0 Sep 13 15:31:25 escabot DMA free:3560kB min:68kB low:84kB high:100kB active:0kB inactive:0kB present:16256kB pages_scanned:0 all_unreclaimable? yes Sep 13 15:31:25 escabot lowmem_reserve[]: 0 873 12176 Sep 13 15:31:25 escabot Normal free:3648kB min:3744kB low:4680kB high: 5616kB active:0kB inactive:3160kB present:894080kB pages_scanned:5336 all_unreclaimable? yes Sep 13 15:31:25 escabot lowmem_reserve[]: 0 0 90424 Sep 13 15:31:25 escabot HighMem free:4354372kB min:512kB low:12640kB high:24768kB active:32312kB inactive:7103816kB present:11574272kB pages_scanned:0 all_unreclaimable? no Sep 13 15:31:25 escabot lowmem_reserve[]: 0 0 0 Sep 13 15:31:25 escabot DMA: 4*4kB 3*8kB 0*16kB 0*32kB 1*64kB 1*128kB 1*256kB 0*512kB 1*1024kB 1*2048kB 0*4096kB = 3560kB Sep 13 15:31:25 escabot Normal: 44*4kB 18*8kB 6*16kB 1*32kB 6*64kB 2*128kB 0*256kB 1*512kB 0*1024kB 1*2048kB 0*4096kB = 3648kB Sep 13 15:31:25 escabot HighMem: 1*4kB 0*8kB 0*16kB 37914*32kB 43188*64kB 1628*128kB 5*256kB 247*512kB 30*1024kB 1*2048kB 2*4096kB = 4354372kB Sep 13 15:31:25 escabot Swap cache: add 983, delete 972, find 0/1, race 0+0 Sep 13 15:31:25 escabot Free swap = 2004216kB Sep 13 15:31:25 escabot Total swap = 2008116kB Sep 13 15:31:25 escabot Free swap: 2004216kB Sep 13 15:31:25 escabot 3145727 pages of RAM Sep 13 15:31:25 escabot 2916351 pages of HIGHMEM Sep 13 15:31:25 escabot 69112 reserved pages Sep 13 15:31:25 escabot 1781351 pages shared Sep 13 15:31:25 escabot 11 pages swap cached Sep 13 15:31:25 escabot 10338 pages dirty Sep 13 15:31:25 escabot 0 pages writeback Sep 13 15:31:25 escabot 988 pages mapped Sep 13 15:31:25 escabot 198893 pages slab Sep 13 15:31:25 escabot 129 pages pagetables Sep 13 15:31:25 escabot Out of memory: kill process 5789 (mysqld) score 35692 or a child Sep 13 15:31:25 escabot Killed process 5789 (mysqld) Sep 13 15:31:25 escabot syslog-ng invoked oom-killer: gfp_mask=0xd0, order=0, oomkilladj=0 Sep 13 15:31:25 escabot [<c0149ea8>] out_of_memory+0x158/0x1b0 Sep 13 15:31:25 escabot [<c014b7b0>] __alloc_pages+0x2a0/0x300 Sep 13 15:31:25 escabot [<c0162a21>] cache_alloc_refill+0x2e1/0x500 Sep 13 15:31:25 escabot [<c0162736>] kmem_cache_alloc+0x46/0x50 Sep 13 15:31:25 escabot [<c016e238>] getname+0x28/0xf0 Sep 13 15:31:25 escabot [<c016fe5e>] __user_walk_fd+0x1e/0x60 Sep 13 15:31:25 escabot [<c0169152>] vfs_stat_fd+0x22/0x60 Sep 13 15:31:25 escabot [<c012f460>] autoremove_wake_function+0x0/0x50 Sep 13 15:31:25 escabot [<c0123928>] __capable+0x8/0x20 Sep 13 15:31:25 escabot [<c02d02ef>] cap_syslog+0x1f/0x30 Sep 13 15:31:25 escabot [<c0123928>] __capable+0x8/0x20 Sep 13 15:31:25 escabot [<c011d026>] do_syslog+0x3b6/0x3e0 Sep 13 15:31:25 escabot [<c016922f>] sys_stat64+0xf/0x30 Sep 13 15:31:25 escabot [<c0124956>] do_gettimeofday+0x36/0xf0 Sep 13 15:31:25 escabot [<c0120bbf>] sys_time+0xf/0x30 Sep 13 15:31:25 escabot [<c0102b10>] sysenter_past_esp+0x5d/0x81 Sep 13 15:31:25 escabot ======================= Sep 13 15:31:25 escabot Mem-info: Sep 13 15:31:25 escabot DMA per-cpu: Sep 13 15:31:25 escabot CPU 0: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Sep 13 15:31:25 escabot CPU 1: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Sep 13 15:31:25 escabot CPU 2: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Sep 13 15:31:25 escabot CPU 3: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Sep 13 15:31:25 escabot Normal per-cpu: Sep 13 15:31:25 escabot CPU 0: Hot: hi: 186, btch: 31 usd: 143 Cold: hi: 62, btch: 15 usd: 56 Sep 13 15:31:25 escabot CPU 1: Hot: hi: 186, btch: 31 usd: 31 Cold: hi: 62, btch: 15 usd: 53 Sep 13 15:31:25 escabot CPU 2: Hot: hi: 186, btch: 31 usd: 8 Cold: hi: 62, btch: 15 usd: 54 Sep 13 15:31:25 escabot CPU 3: Hot: hi: 186, btch: 31 usd: 130 Cold: hi: 62, btch: 15 usd: 58 Sep 13 15:31:25 escabot HighMem per-cpu: Sep 13 15:31:25 escabot CPU 0: Hot: hi: 186, btch: 31 usd: 1 Cold: hi: 62, btch: 15 usd: 10 Sep 13 15:31:25 escabot CPU 1: Hot: hi: 186, btch: 31 usd: 23 Cold: hi: 62, btch: 15 usd: 1 Sep 13 15:31:25 escabot CPU 2: Hot: hi: 186, btch: 31 usd: 18 Cold: hi: 62, btch: 15 usd: 1 Sep 13 15:31:25 escabot CPU 3: Hot: hi: 186, btch: 31 usd: 162 Cold: hi: 62, btch: 15 usd: 12 Sep 13 15:31:25 escabot Active:2311 inactive:1776744 dirty:10338 writeback:0 unstable:0 Sep 13 15:31:25 escabot free:1096030 slab:198893 mapped:915 pagetables:92 bounce:0 Sep 13 15:31:25 escabot DMA free:3560kB min:68kB low:84kB high:100kB active:0kB inactive:0kB present:16256kB pages_scanned:0 all_unreclaimable? yes Sep 13 15:31:25 escabot lowmem_reserve[]: 0 873 12176 Sep 13 15:31:25 escabot Normal free:3648kB min:3744kB low:4680kB high: 5616kB active:0kB inactive:3160kB present:894080kB pages_scanned:5336 all_unreclaimable? yes Sep 13 15:31:25 escabot lowmem_reserve[]: 0 0 90424 Sep 13 15:31:25 escabot HighMem free:4376912kB min:512kB low:12640kB high:24768kB active:9244kB inactive:7103816kB present:11574272kB pages_scanned:0 all_unreclaimable? no Sep 13 15:31:25 escabot lowmem_reserve[]: 0 0 0 Sep 13 15:31:25 escabot DMA: 4*4kB 3*8kB 0*16kB 0*32kB 1*64kB 1*128kB 1*256kB 0*512kB 1*1024kB 1*2048kB 0*4096kB = 3560kB Sep 13 15:31:25 escabot Normal: 44*4kB 18*8kB 6*16kB 1*32kB 6*64kB 2*128kB 0*256kB 1*512kB 0*1024kB 1*2048kB 0*4096kB = 3648kB Sep 13 15:31:25 escabot HighMem: 107*4kB 42*8kB 39*16kB 37944*32kB 43216*64kB 1640*128kB 15*256kB 253*512kB 35*1024kB 2*2048kB 3*4096kB = 4376940kB Sep 13 15:31:25 escabot Swap cache: add 983, delete 972, find 0/1, race 0+0 Sep 13 15:31:25 escabot Free swap = 2004216kB Sep 13 15:31:25 escabot Total swap = 2008116kB Sep 13 15:31:25 escabot Free swap: 2004216kB Sep 13 15:31:25 escabot 3145727 pages of RAM Sep 13 15:31:25 escabot 2916351 pages of HIGHMEM Sep 13 15:31:25 escabot 69112 reserved pages Sep 13 15:31:25 escabot 1780992 pages shared Sep 13 15:31:25 escabot 11 pages swap cached Sep 13 15:31:25 escabot 10338 pages dirty Sep 13 15:31:25 escabot 0 pages writeback Sep 13 15:31:25 escabot 915 pages mapped Sep 13 15:31:25 escabot 198893 pages slab Sep 13 15:31:25 escabot 92 pages pagetables Sep 13 15:31:25 escabot Out of memory: kill process 5857 (bacula-dir) score 379 or a child Sep 13 15:31:25 escabot Killed process 5857 (bacula-dir) Sep 13 15:31:25 escabot init invoked oom-killer: gfp_mask=0xd0, order=0, oomkilladj=0 Sep 13 15:31:25 escabot [<c0149ea8>] out_of_memory+0x158/0x1b0 Sep 13 15:31:25 escabot [<c014b7b0>] __alloc_pages+0x2a0/0x300 Sep 13 15:31:25 escabot [<c01729aa>] core_sys_select+0x1fa/0x2f0 Sep 13 15:31:25 escabot [<c0162a21>] cache_alloc_refill+0x2e1/0x500 Sep 13 15:31:25 escabot [<c0162736>] kmem_cache_alloc+0x46/0x50 Sep 13 15:31:25 escabot [<c016e238>] getname+0x28/0xf0 Sep 13 15:31:25 escabot [<c016fe5e>] __user_walk_fd+0x1e/0x60 Sep 13 15:31:25 escabot [<c0168e29>] cp_new_stat64+0xf9/0x110 Sep 13 15:31:25 escabot [<c0169152>] vfs_stat_fd+0x22/0x60 Sep 13 15:31:25 escabot [<c016922f>] sys_stat64+0xf/0x30 Sep 13 15:31:25 escabot [<c0124956>] do_gettimeofday+0x36/0xf0 Sep 13 15:31:25 escabot [<c0120bbf>] sys_time+0xf/0x30 Sep 13 15:31:25 escabot [<c0102b10>] sysenter_past_esp+0x5d/0x81 Sep 13 15:31:25 escabot ======================= Sep 13 15:31:25 escabot Mem-info: Sep 13 15:31:25 escabot DMA per-cpu: Sep 13 15:31:25 escabot CPU 0: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Sep 13 15:31:25 escabot CPU 1: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Sep 13 15:31:25 escabot CPU 2: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Sep 13 15:31:25 escabot CPU 3: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Sep 13 15:31:25 escabot Normal per-cpu: Sep 13 15:31:25 escabot CPU 0: Hot: hi: 186, btch: 31 usd: 151 Cold: hi: 62, btch: 15 usd: 56 Sep 13 15:31:25 escabot CPU 1: Hot: hi: 186, btch: 31 usd: 31 Cold: hi: 62, btch: 15 usd: 53 Sep 13 15:31:25 escabot CPU 2: Hot: hi: 186, btch: 31 usd: 8 Cold: hi: 62, btch: 15 usd: 54 Sep 13 15:31:25 escabot CPU 3: Hot: hi: 186, btch: 31 usd: 130 Cold: hi: 62, btch: 15 usd: 58 Sep 13 15:31:25 escabot HighMem per-cpu: Sep 13 15:31:25 escabot CPU 0: Hot: hi: 186, btch: 31 usd: 63 Cold: hi: 62, btch: 15 usd: 10 Sep 13 15:31:25 escabot CPU 1: Hot: hi: 186, btch: 31 usd: 23 Cold: hi: 62, btch: 15 usd: 1 Sep 13 15:31:25 escabot CPU 2: Hot: hi: 186, btch: 31 usd: 18 Cold: hi: 62, btch: 15 usd: 1 Sep 13 15:31:25 escabot CPU 3: Hot: hi: 186, btch: 31 usd: 162 Cold: hi: 62, btch: 15 usd: 12 Sep 13 15:31:25 escabot Active:2238 inactive:1776744 dirty:10338 writeback:0 unstable:0 Sep 13 15:31:25 escabot free:1096030 slab:198893 mapped:842 pagetables:92 bounce:0 Sep 13 15:31:25 escabot DMA free:3560kB min:68kB low:84kB high:100kB active:0kB inactive:0kB present:16256kB pages_scanned:0 all_unreclaimable? yes Sep 13 15:31:25 escabot lowmem_reserve[]: 0 873 12176 Sep 13 15:31:25 escabot Normal free:3648kB min:3744kB low:4680kB high: 5616kB active:0kB inactive:3160kB present:894080kB pages_scanned:5336 all_unreclaimable? yes Sep 13 15:31:25 escabot lowmem_reserve[]: 0 0 90424 Sep 13 15:31:25 escabot HighMem free:4376912kB min:512kB low:12640kB high:24768kB active:8952kB inactive:7103816kB present:11574272kB pages_scanned:0 all_unreclaimable? no Sep 13 15:31:25 escabot lowmem_reserve[]: 0 0 0 Sep 13 15:31:25 escabot DMA: 4*4kB 3*8kB 0*16kB 0*32kB 1*64kB 1*128kB 1*256kB 0*512kB 1*1024kB 1*2048kB 0*4096kB = 3560kB Sep 13 15:31:25 escabot Normal: 44*4kB 18*8kB 6*16kB 1*32kB 6*64kB 2*128kB 0*256kB 1*512kB 0*1024kB 1*2048kB 0*4096kB = 3648kB Sep 13 15:31:25 escabot HighMem: 107*4kB 42*8kB 39*16kB 37944*32kB 43216*64kB 1640*128kB 15*256kB 253*512kB 35*1024kB 2*2048kB 3*4096kB = 4376940kB Sep 13 15:31:25 escabot Swap cache: add 983, delete 972, find 0/1, race 0+0 Sep 13 15:31:25 escabot Free swap = 2004644kB Sep 13 15:31:25 escabot Total swap = 2008116kB Sep 13 15:31:25 escabot Free swap: 2004644kB Sep 13 15:31:25 escabot 3145727 pages of RAM Sep 13 15:31:25 escabot 2916351 pages of HIGHMEM Sep 13 15:31:25 escabot 69112 reserved pages Sep 13 15:31:25 escabot 1780742 pages shared Sep 13 15:31:25 escabot 11 pages swap cached Sep 13 15:31:25 escabot 10338 pages dirty Sep 13 15:31:25 escabot 0 pages writeback Sep 13 15:31:25 escabot 842 pages mapped Sep 13 15:31:25 escabot 198893 pages slab Sep 13 15:31:25 escabot 92 pages pagetables Sep 13 15:31:25 escabot Out of memory: kill process 5868 (bacula-sd) score 350 or a child Sep 13 15:31:25 escabot Killed process 5868 (bacula-sd) Sep 13 15:31:25 escabot 3145727 pages of RAM Sep 13 15:31:25 escabot 2916351 pages of HIGHMEM Sep 13 15:31:25 escabot 69112 reserved pages Sep 13 15:31:25 escabot 1780407 pages shared Sep 13 15:31:25 escabot 11 pages swap cached Sep 13 15:31:25 escabot 10338 pages dirty Sep 13 15:31:25 escabot 0 pages writeback Sep 13 15:31:25 escabot 842 pages mapped Sep 13 15:31:25 escabot 198893 pages slab Sep 13 15:31:25 escabot 92 pages pagetables Sep 13 15:31:25 escabot Out of memory: kill process 6032 (sshd) score 223 or a child Sep 13 15:31:25 escabot Killed process 6180 (sshd) </quote> ^ permalink raw reply [flat|nested] 47+ messages in thread
* VM/VFS bug with large amount of memory and file systems? @ 2007-09-15 7:27 ` Anton Altaparmakov 0 siblings, 0 replies; 47+ messages in thread From: Anton Altaparmakov @ 2007-09-15 7:27 UTC (permalink / raw) To: Linux Kernel Mailing List, Linux Memory Management List; +Cc: marc.smith Hi, Mark Smith reported a OOM condition when he copies a large (46GiB) file from an NTFS partition (using the stock kernel driver) to /dev/ null (or to a file on ext3, same result). The machine this runs on has an i386 kernel with 12GiB RAM (yes this is not a typo it is 12GiB!). When you do: escabot CAD # ls -ltrh total 49G -r-------- 1 root root 2.0G Oct 7 2004 RTC26001.GHS -r-------- 1 root root 2.0G Oct 7 2004 RTC26002.GHS -r-------- 1 root root 2.0G Oct 7 2004 RTC2604.GHO -r-------- 1 root root 620M Oct 7 2004 RTC26003.GHS -r-------- 1 root root 4 Sep 14 09:32 asdf.txt -r-------- 1 root root 8 Sep 14 09:33 rty.txt -r-------- 1 root root 42G Sep 14 10:36 bigfile.gho escabot CAD # cp bigfile.gho /dev/null It dies with OOM and eventual panic with the message: "Kernel panic - not syncing: Out of memory and no killable processes." If Mark boots with "mem=2G" on the kernel command line and he then repeat thes above copy, then the copy succeeds just fine so there is nothing inherently wrong with NTFS. So the OOM happens with 12GiB RAM but not with 2GiB RAM. I guess this is why I have never seen this in my testing. My laptop only has 2GiB RAM... Below are relevant parts of the dmesg output that Mark sent that show what the kernel messages are when this happens. (I have taken out the NTFS debug output to make the log shorter but that does not show anything untoward and I can send it on request but it really just shows the file being read in and that's all!) Does anyone have any ideas / want to work with Mark (he is CC:-ed) to try and figure out the bug and get it fixed? I am sure Mark will be happy to provide further information/try things out... If it turns out to be something NTFS is doing wrong I am happy to try and fix it but at the moment I assume it is something the VM is doing wrong when there is so much RAM available... Best regards, Anton -- Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @) Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK Linux NTFS maintainer, http://www.linux-ntfs.org/ <quote from dmesg output> Sep 13 15:00:22 escabot Linux version 2.6.21-gentoo-r4 (root@escabot) (gcc version 4.1.2 (Gentoo 4.1.2 p1.0.1)) #3 SMP PREEMPT Thu Sep 13 14:44:12 EDT 2007 Sep 13 15:00:22 escabot BIOS-provided physical RAM map: Sep 13 15:00:22 escabot sanitize start Sep 13 15:00:22 escabot sanitize end Sep 13 15:00:22 escabot copy_e820_map() start: 0000000000000000 size: 000000000009ec00 end: 000000000009ec00 type: 1 Sep 13 15:00:22 escabot copy_e820_map() type is E820_RAM Sep 13 15:00:22 escabot copy_e820_map() start: 000000000009ec00 size: 0000000000001400 end: 00000000000a0000 type: 2 Sep 13 15:00:22 escabot copy_e820_map() start: 00000000000f0000 size: 0000000000010000 end: 0000000000100000 type: 2 Sep 13 15:00:22 escabot copy_e820_map() start: 0000000000100000 size: 00000000f56f8000 end: 00000000f57f8000 type: 1 Sep 13 15:00:22 escabot copy_e820_map() type is E820_RAM Sep 13 15:00:22 escabot copy_e820_map() start: 00000000f57f8000 size: 0000000000008000 end: 00000000f5800000 type: 3 Sep 13 15:00:22 escabot copy_e820_map() start: 00000000fdc00000 size: 0000000000001000 end: 00000000fdc01000 type: 2 Sep 13 15:00:22 escabot copy_e820_map() start: 00000000fdc10000 size: 0000000000001000 end: 00000000fdc11000 type: 2 Sep 13 15:00:22 escabot copy_e820_map() start: 00000000fec00000 size: 0000000000001000 end: 00000000fec01000 type: 2 Sep 13 15:00:22 escabot copy_e820_map() start: 00000000fec10000 size: 0000000000001000 end: 00000000fec11000 type: 2 Sep 13 15:00:22 escabot copy_e820_map() start: 00000000fec20000 size: 0000000000001000 end: 00000000fec21000 type: 2 Sep 13 15:00:22 escabot copy_e820_map() start: 00000000fee00000 size: 0000000000010000 end: 00000000fee10000 type: 2 Sep 13 15:00:22 escabot copy_e820_map() start: 00000000ff800000 size: 0000000000800000 end: 0000000100000000 type: 2 Sep 13 15:00:22 escabot copy_e820_map() start: 0000000100000000 size: 00000001fffff000 end: 00000002fffff000 type: 1 Sep 13 15:00:22 escabot copy_e820_map() type is E820_RAM Sep 13 15:00:22 escabot BIOS-e820: 0000000000000000 - 000000000009ec00 (usable) Sep 13 15:00:22 escabot BIOS-e820: 000000000009ec00 - 00000000000a0000 (reserved) Sep 13 15:00:22 escabot BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved) Sep 13 15:00:22 escabot BIOS-e820: 0000000000100000 - 00000000f57f8000 (usable) Sep 13 15:00:22 escabot BIOS-e820: 00000000f57f8000 - 00000000f5800000 (ACPI data) Sep 13 15:00:22 escabot BIOS-e820: 00000000fdc00000 - 00000000fdc01000 (reserved) Sep 13 15:00:22 escabot BIOS-e820: 00000000fdc10000 - 00000000fdc11000 (reserved) Sep 13 15:00:22 escabot BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved) Sep 13 15:00:22 escabot BIOS-e820: 00000000fec10000 - 00000000fec11000 (reserved) Sep 13 15:00:22 escabot BIOS-e820: 00000000fec20000 - 00000000fec21000 (reserved) Sep 13 15:00:22 escabot BIOS-e820: 00000000fee00000 - 00000000fee10000 (reserved) Sep 13 15:00:22 escabot BIOS-e820: 00000000ff800000 - 0000000100000000 (reserved) Sep 13 15:00:22 escabot BIOS-e820: 0000000100000000 - 00000002fffff000 (usable) Sep 13 15:00:22 escabot 11391MB HIGHMEM available. Sep 13 15:00:22 escabot 896MB LOWMEM available. Sep 13 15:00:22 escabot found SMP MP-table at 000f4fa0 Sep 13 15:00:22 escabot NX (Execute Disable) protection: active Sep 13 15:00:22 escabot Entering add_active_range(0, 0, 3145727) 0 entries of 256 used Sep 13 15:00:22 escabot Zone PFN ranges: Sep 13 15:00:22 escabot DMA 0 -> 4096 Sep 13 15:00:22 escabot Normal 4096 -> 229376 Sep 13 15:00:22 escabot HighMem 229376 -> 3145727 Sep 13 15:00:22 escabot early_node_map[1] active PFN ranges Sep 13 15:00:22 escabot 0: 0 -> 3145727 Sep 13 15:00:22 escabot On node 0 totalpages: 3145727 Sep 13 15:00:22 escabot DMA zone: 32 pages used for memmap Sep 13 15:00:22 escabot DMA zone: 0 pages reserved Sep 13 15:00:22 escabot DMA zone: 4064 pages, LIFO batch:0 Sep 13 15:00:22 escabot Normal zone: 1760 pages used for memmap Sep 13 15:00:22 escabot Normal zone: 223520 pages, LIFO batch:31 Sep 13 15:00:22 escabot HighMem zone: 22783 pages used for memmap Sep 13 15:00:22 escabot HighMem zone: 2893568 pages, LIFO batch:31 Sep 13 15:00:22 escabot DMI 2.3 present. Sep 13 15:00:22 escabot ACPI: RSDP 000F4F20, 0024 (r2 HP ) Sep 13 15:00:22 escabot ACPI: XSDT F57F83E0, 0044 (r1 HP A05 2 ?\x04 162E) Sep 13 15:00:22 escabot ACPI: FACP F57F8460, 00F4 (r3 HP A05 2 ?\x04 162E) Sep 13 15:00:22 escabot ACPI: DSDT F57F8560, 422D (r1 HP DSDT 1 MSFT 2000001) Sep 13 15:00:22 escabot ACPI: FACS F57F80C0, 0040 Sep 13 15:00:22 escabot ACPI: APIC F57F8100, 00B8 (r1 HP 00000083 2 0) Sep 13 15:00:22 escabot ACPI: SPCR F57F81E0, 0050 (r1 HP SPCRRBSU 1 ?\x04 162E) Sep 13 15:00:22 escabot ACPI: SRAT F57F8260, 0150 (r1 HP A05 1 0) Sep 13 15:00:22 escabot ACPI: PM-Timer IO Port: 0x908 Sep 13 15:00:22 escabot ACPI: Local APIC address 0xfee00000 Sep 13 15:00:22 escabot ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Sep 13 15:00:22 escabot Processor #0 15:1 APIC version 16 Sep 13 15:00:22 escabot ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled) Sep 13 15:00:22 escabot Processor #2 15:1 APIC version 16 Sep 13 15:00:22 escabot ACPI: LAPIC (acpi_id[0x04] lapic_id[0x04] disabled) Sep 13 15:00:22 escabot ACPI: LAPIC (acpi_id[0x06] lapic_id[0x06] disabled) Sep 13 15:00:22 escabot ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled) Sep 13 15:00:22 escabot Processor #1 15:1 APIC version 16 Sep 13 15:00:22 escabot ACPI: LAPIC (acpi_id[0x03] lapic_id[0x03] enabled) Sep 13 15:00:22 escabot Processor #3 15:1 APIC version 16 Sep 13 15:00:22 escabot ACPI: LAPIC (acpi_id[0x05] lapic_id[0x05] disabled) Sep 13 15:00:22 escabot ACPI: LAPIC (acpi_id[0x07] lapic_id[0x07] disabled) Sep 13 15:00:22 escabot ACPI: LAPIC_NMI (acpi_id[0xff] high edge lint [0x1]) Sep 13 15:00:22 escabot ACPI: IOAPIC (id[0x04] address[0xfec00000] gsi_base[0]) Sep 13 15:00:22 escabot IOAPIC[0]: apic_id 4, version 17, address 0xfec00000, GSI 0-23 Sep 13 15:00:22 escabot ACPI: IOAPIC (id[0x05] address[0xfec10000] gsi_base[24]) Sep 13 15:00:22 escabot IOAPIC[1]: apic_id 5, version 17, address 0xfec10000, GSI 24-27 Sep 13 15:00:22 escabot ACPI: IOAPIC (id[0x06] address[0xfec20000] gsi_base[28]) Sep 13 15:00:22 escabot IOAPIC[2]: apic_id 6, version 17, address 0xfec20000, GSI 28-31 Sep 13 15:00:22 escabot ACPI: IOAPIC (id[0x07] address[0xfdc00000] gsi_base[32]) Sep 13 15:00:22 escabot IOAPIC[3]: apic_id 7, version 17, address 0xfdc00000, GSI 32-35 Sep 13 15:00:22 escabot ACPI: IOAPIC (id[0x08] address[0xfdc10000] gsi_base[36]) Sep 13 15:00:22 escabot IOAPIC[4]: apic_id 8, version 17, address 0xfdc10000, GSI 36-39 Sep 13 15:00:22 escabot ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge) Sep 13 15:00:22 escabot ACPI: IRQ0 used by override. Sep 13 15:00:22 escabot ACPI: IRQ2 used by override. Sep 13 15:00:22 escabot ACPI: IRQ9 used by override. Sep 13 15:00:22 escabot Enabling APIC mode: Flat. Using 5 I/O APICs Sep 13 15:00:22 escabot Using ACPI (MADT) for SMP configuration information Sep 13 15:00:22 escabot Allocating PCI resources starting at f6000000 (gap: f5800000:08400000) Sep 13 15:00:22 escabot Built 1 zonelists. Total pages: 3121152 Sep 13 15:00:22 escabot Kernel command line: debug_msgs=1 Sep 13 15:00:22 escabot mapped APIC to ffffd000 (fee00000) Sep 13 15:00:22 escabot mapped IOAPIC to ffffc000 (fec00000) Sep 13 15:00:22 escabot mapped IOAPIC to ffffb000 (fec10000) Sep 13 15:00:22 escabot mapped IOAPIC to ffffa000 (fec20000) Sep 13 15:00:22 escabot mapped IOAPIC to ffff9000 (fdc00000) Sep 13 15:00:22 escabot mapped IOAPIC to ffff8000 (fdc10000) Sep 13 15:00:22 escabot Enabling fast FPU save and restore... done. Sep 13 15:00:22 escabot Enabling unmasked SIMD FPU exception support... done. Sep 13 15:00:22 escabot Initializing CPU#0 Sep 13 15:00:22 escabot PID hash table entries: 4096 (order: 12, 16384 bytes) Sep 13 15:00:22 escabot Detected 2405.604 MHz processor. Sep 13 15:00:22 escabot Console: colour VGA+ 80x25 Sep 13 15:00:22 escabot Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Sep 13 15:00:22 escabot Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Sep 13 15:00:22 escabot Memory: 12304772k/12582908k available (3439k kernel code, 104940k reserved, 977k data, 240k init, 11493340k highmem) Sep 13 15:00:22 escabot virtual kernel memory layout: Sep 13 15:00:22 escabot fixmap : 0xfff4f000 - 0xfffff000 ( 704 kB) Sep 13 15:00:22 escabot pkmap : 0xffc00000 - 0xffe00000 (2048 kB) Sep 13 15:00:22 escabot vmalloc : 0xf8800000 - 0xffbfe000 ( 115 MB) Sep 13 15:00:22 escabot lowmem : 0xc0000000 - 0xf8000000 ( 896 MB) Sep 13 15:00:22 escabot .init : 0xc0558000 - 0xc0594000 ( 240 kB) Sep 13 15:00:22 escabot .data : 0xc045bce5 - 0xc055014c ( 977 kB) Sep 13 15:00:22 escabot .text : 0xc0100000 - 0xc045bce5 (3439 kB) Sep 13 15:00:22 escabot Checking if this processor honours the WP bit even in supervisor mode... Ok. Sep 13 15:00:22 escabot Calibrating delay using timer specific routine.. 4815.63 BogoMIPS (lpj=9631263) Sep 13 15:00:22 escabot Mount-cache hash table entries: 512 Sep 13 15:00:22 escabot CPU: After generic identify, caps: 178bfbff e3d3fbff 00000000 00000000 00000001 00000000 00000002 Sep 13 15:00:22 escabot CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) Sep 13 15:00:22 escabot CPU: L2 Cache: 1024K (64 bytes/line) Sep 13 15:00:22 escabot CPU 0(2) -> Core 0 Sep 13 15:00:22 escabot CPU: After all inits, caps: 178bfbff e3d3fbff 00000000 00000410 00000001 00000000 00000002 Sep 13 15:00:22 escabot Intel machine check architecture supported. Sep 13 15:00:22 escabot Intel machine check reporting enabled on CPU#0. Sep 13 15:00:22 escabot Compat vDSO mapped to ffffe000. Sep 13 15:00:22 escabot Checking 'hlt' instruction... OK. Sep 13 15:00:22 escabot Freeing SMP alternatives: 15k freed Sep 13 15:00:22 escabot ACPI: Core revision 20070126 Sep 13 15:00:22 escabot CPU0: AMD Opteron(tm) Processor 280 stepping 02 Sep 13 15:00:22 escabot Booting processor 1/1 eip 2000 Sep 13 15:00:22 escabot Initializing CPU#1 Sep 13 15:00:22 escabot Calibrating delay using timer specific routine.. 4811.22 BogoMIPS (lpj=9622459) Sep 13 15:00:22 escabot CPU: After generic identify, caps: 178bfbff e3d3fbff 00000000 00000000 00000001 00000000 00000002 Sep 13 15:00:22 escabot CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) Sep 13 15:00:22 escabot CPU: L2 Cache: 1024K (64 bytes/line) Sep 13 15:00:22 escabot CPU 1(2) -> Core 1 Sep 13 15:00:22 escabot CPU: After all inits, caps: 178bfbff e3d3fbff 00000000 00000410 00000001 00000000 00000002 Sep 13 15:00:22 escabot Intel machine check architecture supported. Sep 13 15:00:22 escabot Intel machine check reporting enabled on CPU#1. Sep 13 15:00:22 escabot CPU1: AMD Opteron(tm) Processor 280 stepping 02 Sep 13 15:00:22 escabot Booting processor 2/2 eip 2000 Sep 13 15:00:22 escabot Initializing CPU#2 Sep 13 15:00:22 escabot Calibrating delay using timer specific routine.. 4811.19 BogoMIPS (lpj=9622384) Sep 13 15:00:22 escabot CPU: After generic identify, caps: 178bfbff e3d3fbff 00000000 00000000 00000001 00000000 00000002 Sep 13 15:00:22 escabot CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) Sep 13 15:00:22 escabot CPU: L2 Cache: 1024K (64 bytes/line) Sep 13 15:00:22 escabot CPU 2(2) -> Core 0 Sep 13 15:00:22 escabot CPU: After all inits, caps: 178bfbff e3d3fbff 00000000 00000410 00000001 00000000 00000002 Sep 13 15:00:22 escabot Intel machine check architecture supported. Sep 13 15:00:22 escabot Intel machine check reporting enabled on CPU#2. Sep 13 15:00:22 escabot CPU2: AMD Opteron(tm) Processor 280 stepping 02 Sep 13 15:00:22 escabot Booting processor 3/3 eip 2000 Sep 13 15:00:22 escabot Initializing CPU#3 Sep 13 15:00:22 escabot Calibrating delay using timer specific routine.. 4811.27 BogoMIPS (lpj=9622546) Sep 13 15:00:22 escabot CPU: After generic identify, caps: 178bfbff e3d3fbff 00000000 00000000 00000001 00000000 00000002 Sep 13 15:00:22 escabot CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) Sep 13 15:00:22 escabot CPU: L2 Cache: 1024K (64 bytes/line) Sep 13 15:00:22 escabot CPU 3(2) -> Core 1 Sep 13 15:00:22 escabot CPU: After all inits, caps: 178bfbff e3d3fbff 00000000 00000410 00000001 00000000 00000002 Sep 13 15:00:22 escabot Intel machine check architecture supported. Sep 13 15:00:22 escabot Intel machine check reporting enabled on CPU#3. Sep 13 15:00:22 escabot CPU3: AMD Opteron(tm) Processor 280 stepping 02 Sep 13 15:00:22 escabot Total of 4 processors activated (19249.32 BogoMIPS). Sep 13 15:00:22 escabot ENABLING IO-APIC IRQs Sep 13 15:00:22 escabot ..TIMER: vector=0x31 apic1=0 pin1=2 apic2=0 pin2=0 Sep 13 15:00:22 escabot Brought up 4 CPUs Sep 13 15:00:22 escabot migration_cost=4000 Sep 13 15:00:22 escabot NET: Registered protocol family 16 Sep 13 15:00:22 escabot ACPI: bus type pci registered Sep 13 15:00:22 escabot PCI: PCI BIOS revision 2.10 entry at 0xf0096, last bus=6 Sep 13 15:00:22 escabot PCI: Using configuration type 1 Sep 13 15:00:22 escabot Setting up standard PCI resources Sep 13 15:00:22 escabot ACPI: SSDT F57FD000, 059D (r1 HP SSDT0 1 MSFT 2000001) Sep 13 15:00:22 escabot ACPI: SSDT F57FD700, 059D (r1 HP SSDT1 1 MSFT 2000001) Sep 13 15:00:22 escabot ACPI: SSDT F57FDE00, 059D (r1 HP SSDT2 1 MSFT 2000001) Sep 13 15:00:22 escabot ACPI: SSDT F57FE500, 059D (r1 HP SSDT3 1 MSFT 2000001) Sep 13 15:00:22 escabot ACPI: Interpreter enabled Sep 13 15:00:22 escabot ACPI: Using IOAPIC for interrupt routing Sep 13 15:00:22 escabot ACPI: PCI Root Bridge [CFG0] (0000:00) Sep 13 15:00:22 escabot PCI: Probing PCI hardware (bus 00) Sep 13 15:00:22 escabot Boot video device is 0000:01:03.0 Sep 13 15:00:22 escabot ACPI: PCI Interrupt Routing Table [\_SB_.CFG0._PRT] Sep 13 15:00:22 escabot ACPI: PCI Interrupt Routing Table [\_SB_.CFG0.PCI0._PRT] Sep 13 15:00:22 escabot ACPI: PCI Interrupt Routing Table [\_SB_.CFG0.PCI1._PRT] Sep 13 15:00:22 escabot ACPI: PCI Interrupt Routing Table [\_SB_.CFG0.PCI2._PRT] Sep 13 15:00:22 escabot ACPI: PCI Root Bridge [CFG1] (0000:04) Sep 13 15:00:22 escabot PCI: Probing PCI hardware (bus 04) Sep 13 15:00:22 escabot ACPI: PCI Interrupt Routing Table [\_SB_.CFG1.PCI3._PRT] Sep 13 15:00:22 escabot ACPI: PCI Interrupt Routing Table [\_SB_.CFG1.PCI4._PRT] Sep 13 15:00:22 escabot ACPI: PCI Interrupt Link [LNKA] (IRQs 3 5 *7 10 11) Sep 13 15:00:22 escabot ACPI: PCI Interrupt Link [LNKB] (IRQs 3 5 7 10 11) *15 Sep 13 15:00:22 escabot ACPI: PCI Interrupt Link [LNKC] (IRQs 3 5 7 *10 11) Sep 13 15:00:22 escabot ACPI: PCI Interrupt Link [LNKD] (IRQs 3 *5 7 10 11) Sep 13 15:00:22 escabot Linux Plug and Play Support v0.97 (c) Adam Belay Sep 13 15:00:22 escabot pnp: PnP ACPI init Sep 13 15:00:22 escabot pnp: PnP ACPI: found 10 devices Sep 13 15:00:22 escabot SCSI subsystem initialized Sep 13 15:00:22 escabot usbcore: registered new interface driver usbfs Sep 13 15:00:22 escabot usbcore: registered new interface driver hub Sep 13 15:00:22 escabot usbcore: registered new device driver usb Sep 13 15:00:22 escabot PCI: Using ACPI for IRQ routing Sep 13 15:00:22 escabot PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report Sep 13 15:00:22 escabot pnp: 00:01: ioport range 0x230-0x233 has been reserved Sep 13 15:00:22 escabot pnp: 00:01: ioport range 0x260-0x267 has been reserved Sep 13 15:00:22 escabot pnp: 00:01: ioport range 0x4d0-0x4d1 has been reserved Sep 13 15:00:22 escabot PCI: Bridge: 0000:00:03.0 Sep 13 15:00:22 escabot IO window: 4000-4fff Sep 13 15:00:22 escabot MEM window: f5f00000-f7bfffff Sep 13 15:00:22 escabot PREFETCH window: f8000000-f80fffff Sep 13 15:00:22 escabot PCI: Bridge: 0000:00:07.0 Sep 13 15:00:22 escabot IO window: 5000-5fff Sep 13 15:00:22 escabot MEM window: f7c00000-f7cfffff Sep 13 15:00:22 escabot PREFETCH window: f8100000-f81fffff Sep 13 15:00:22 escabot Time: acpi_pm clocksource has been installed. Sep 13 15:00:22 escabot PCI: Bridge: 0000:00:08.0 Sep 13 15:00:22 escabot IO window: disabled. Sep 13 15:00:22 escabot MEM window: f7d00000-f7dfffff Sep 13 15:00:22 escabot PREFETCH window: disabled. Sep 13 15:00:22 escabot PCI: Bridge: 0000:04:09.0 Sep 13 15:00:22 escabot IO window: 6000-6fff Sep 13 15:00:22 escabot MEM window: f7e00000-f7efffff Sep 13 15:00:22 escabot PREFETCH window: f8200000-f82fffff Sep 13 15:00:22 escabot PCI: Bridge: 0000:04:0a.0 Sep 13 15:00:22 escabot IO window: 7000-7fff Sep 13 15:00:22 escabot MEM window: f7f00000-f7ffffff Sep 13 15:00:22 escabot PREFETCH window: f8300000-f83fffff Sep 13 15:00:22 escabot NET: Registered protocol family 2 Sep 13 15:00:22 escabot IP route cache hash table entries: 32768 (order: 5, 131072 bytes) Sep 13 15:00:22 escabot TCP established hash table entries: 131072 (order: 9, 2097152 bytes) Sep 13 15:00:22 escabot TCP bind hash table entries: 65536 (order: 7, 786432 bytes) Sep 13 15:00:22 escabot TCP: Hash tables configured (established 131072 bind 65536) Sep 13 15:00:22 escabot TCP reno registered Sep 13 15:00:22 escabot checking if image is initramfs...it isn't (no cpio magic); looks like an initrd Sep 13 15:00:22 escabot Freeing initrd memory: 689k freed Sep 13 15:00:22 escabot Machine check exception polling timer started. Sep 13 15:00:22 escabot audit: initializing netlink socket (disabled) Sep 13 15:00:22 escabot audit(1189695589.692:1): initialized Sep 13 15:00:22 escabot highmem bounce pool size: 64 pages Sep 13 15:00:22 escabot Installing knfsd (copyright (C) 1996 okir@monad.swb.de). Sep 13 15:00:22 escabot NTFS driver 2.1.28 [Flags: R/W DEBUG]. Sep 13 15:00:22 escabot SGI XFS with ACLs, large block numbers, no debug enabled Sep 13 15:00:22 escabot SGI XFS Quota Management subsystem Sep 13 15:00:22 escabot io scheduler noop registered Sep 13 15:00:22 escabot io scheduler anticipatory registered (default) Sep 13 15:00:22 escabot io scheduler deadline registered Sep 13 15:00:22 escabot io scheduler cfq registered Sep 13 15:00:22 escabot Linux agpgart interface v0.102 (c) Dave Jones Sep 13 15:00:22 escabot [drm] Initialized drm 1.1.0 20060810 Sep 13 15:00:22 escabot input: Power Button (FF) as /class/input/input0 Sep 13 15:00:22 escabot ACPI: Power Button (FF) [PWRF] Sep 13 15:00:22 escabot Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled Sep 13 15:00:22 escabot serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A Sep 13 15:00:22 escabot serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A Sep 13 15:00:22 escabot 00:07: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A Sep 13 15:00:22 escabot Floppy drive(s): fd0 is 1.44M Sep 13 15:00:22 escabot FDC 0 is a National Semiconductor PC87306 Sep 13 15:00:22 escabot RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize Sep 13 15:00:22 escabot loop: loaded (max 8 devices) Sep 13 15:00:22 escabot Intel(R) PRO/1000 Network Driver - version 7.3.20-k2 Sep 13 15:00:22 escabot Copyright (c) 1999-2006 Intel Corporation. Sep 13 15:00:22 escabot ACPI: PCI Interrupt 0000:05:07.0[A] -> GSI 34 (level, low) -> IRQ 16 Sep 13 15:00:22 escabot e1000: 0000:05:07.0: e1000_probe: (PCI-X: 100MHz:64-bit) 00:11:0a:5b:21:98 Sep 13 15:00:22 escabot e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection Sep 13 15:00:22 escabot ACPI: PCI Interrupt 0000:05:07.1[B] -> GSI 35 (level, low) -> IRQ 17 Sep 13 15:00:22 escabot e1000: 0000:05:07.1: e1000_probe: (PCI-X: 100MHz:64-bit) 00:11:0a:5b:21:99 Sep 13 15:00:22 escabot e1000: eth1: e1000_probe: Intel(R) PRO/1000 Network Connection Sep 13 15:00:22 escabot tg3.c:v3.75.2 (June 5, 2007) Sep 13 15:00:22 escabot ACPI: PCI Interrupt 0000:03:06.0[A] -> GSI 28 (level, low) -> IRQ 18 Sep 13 15:00:22 escabot eth2: Tigon3 [partno(N/A) rev 2100 PHY(5704)] (PCIX:133MHz:64-bit) 10/100/1000Base-T Ethernet 00:16:35:3b:6b:74 Sep 13 15:00:22 escabot eth2: RXcsums[1] LinkChgREG[0] MIirq[0] ASF [1] WireSpeed[1] TSOcap[0] Sep 13 15:00:22 escabot eth2: dma_rwctrl[769f4000] dma_mask[64-bit] Sep 13 15:00:22 escabot ACPI: PCI Interrupt 0000:03:06.1[B] -> GSI 29 (level, low) -> IRQ 19 Sep 13 15:00:22 escabot eth3: Tigon3 [partno(N/A) rev 2100 PHY(5704)] (PCIX:133MHz:64-bit) 10/100/1000Base-T Ethernet 00:16:35:3b:6b:73 Sep 13 15:00:22 escabot eth3: RXcsums[1] LinkChgREG[0] MIirq[0] ASF [0] WireSpeed[1] TSOcap[1] Sep 13 15:00:22 escabot eth3: dma_rwctrl[769f4000] dma_mask[64-bit] Sep 13 15:00:22 escabot Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 Sep 13 15:00:22 escabot ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx Sep 13 15:00:22 escabot Probing IDE interface ide0... Sep 13 15:00:22 escabot hda: CD-224E, ATAPI CD/DVD-ROM drive Sep 13 15:00:22 escabot Probing IDE interface ide1... Sep 13 15:00:22 escabot ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 Sep 13 15:00:22 escabot hda: ATAPI 24X CD-ROM drive, 128kB Cache Sep 13 15:00:22 escabot Uniform CD-ROM driver Revision: 3.20 Sep 13 15:00:22 escabot megaraid cmm: 2.20.2.7 (Release Date: Sun Jul 16 00:01:03 EST 2006) Sep 13 15:00:22 escabot megaraid: 2.20.5.1 (Release Date: Thu Nov 16 15:32:35 EST 2006) Sep 13 15:00:22 escabot st: Version 20070203, fixed bufsize 32768, s/ g segs 256 Sep 13 15:00:22 escabot SCSI Media Changer driver v0.25 Sep 13 15:00:22 escabot usbmon: debugfs is not available Sep 13 15:00:22 escabot ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller (OHCI) Driver Sep 13 15:00:22 escabot ACPI: PCI Interrupt 0000:01:00.0[D] -> GSI 19 (level, low) -> IRQ 20 Sep 13 15:00:22 escabot ohci_hcd 0000:01:00.0: OHCI Host Controller Sep 13 15:00:22 escabot ohci_hcd 0000:01:00.0: new USB bus registered, assigned bus number 1 Sep 13 15:00:22 escabot ohci_hcd 0000:01:00.0: irq 20, io mem 0xf7bf0000 Sep 13 15:00:22 escabot usb usb1: configuration #1 chosen from 1 choice Sep 13 15:00:22 escabot hub 1-0:1.0: USB hub found Sep 13 15:00:22 escabot hub 1-0:1.0: 3 ports detected Sep 13 15:00:22 escabot ACPI: PCI Interrupt 0000:01:00.1[D] -> GSI 19 (level, low) -> IRQ 20 Sep 13 15:00:22 escabot ohci_hcd 0000:01:00.1: OHCI Host Controller Sep 13 15:00:22 escabot ohci_hcd 0000:01:00.1: new USB bus registered, assigned bus number 2 Sep 13 15:00:22 escabot ohci_hcd 0000:01:00.1: irq 20, io mem 0xf7be0000 Sep 13 15:00:22 escabot usb usb2: configuration #1 chosen from 1 choice Sep 13 15:00:22 escabot hub 2-0:1.0: USB hub found Sep 13 15:00:22 escabot hub 2-0:1.0: 3 ports detected Sep 13 15:00:22 escabot usbcore: registered new interface driver usblp Sep 13 15:00:22 escabot drivers/usb/class/usblp.c: v0.13: USB Printer Device Class driver Sep 13 15:00:22 escabot Initializing USB Mass Storage driver... Sep 13 15:00:22 escabot usbcore: registered new interface driver usb- storage Sep 13 15:00:22 escabot USB Mass Storage support registered. Sep 13 15:00:22 escabot usbcore: registered new interface driver usbhid Sep 13 15:00:22 escabot drivers/usb/input/hid-core.c: v2.6:USB HID core driver Sep 13 15:00:22 escabot PNP: PS/2 Controller [PNP0303:KBD,PNP0f0e:PS2M] at 0x60,0x64 irq 1,12 Sep 13 15:00:22 escabot serio: i8042 KBD port at 0x60,0x64 irq 1 Sep 13 15:00:22 escabot serio: i8042 AUX port at 0x60,0x64 irq 12 Sep 13 15:00:22 escabot mice: PS/2 mouse device common for all mice Sep 13 15:00:22 escabot input: AT Translated Set 2 keyboard as /class/ input/input1 Sep 13 15:00:22 escabot oprofile: using NMI interrupt. Sep 13 15:00:22 escabot TCP cubic registered Sep 13 15:00:22 escabot NET: Registered protocol family 1 Sep 13 15:00:22 escabot NET: Registered protocol family 17 Sep 13 15:00:22 escabot Starting balanced_irq Sep 13 15:00:22 escabot Using IPI Shortcut mode Sep 13 15:00:22 escabot input: ImExPS/2 Logitech Explorer Mouse as / class/input/input2 Sep 13 15:00:22 escabot RAMDISK: Compressed image found at block 0 Sep 13 15:00:22 escabot VFS: Mounted root (ext2 filesystem). Sep 13 15:00:22 escabot QLogic Fibre Channel HBA Driver Sep 13 15:00:22 escabot ACPI: PCI Interrupt 0000:05:08.0[A] -> GSI 32 (level, low) -> IRQ 21 Sep 13 15:00:22 escabot qla2300 0000:05:08.0: Found an ISP2312, irq 21, iobase 0xf8834000 Sep 13 15:00:22 escabot qla2300 0000:05:08.0: Configuring PCI space... Sep 13 15:00:22 escabot qla2300 0000:05:08.0: Configure NVRAM parameters... Sep 13 15:00:22 escabot qla2300 0000:05:08.0: Verifying loaded RISC code... Sep 13 15:00:22 escabot qla2300 0000:05:08.0: Allocated (412 KB) for firmware dump... Sep 13 15:00:22 escabot qla2300 0000:05:08.0: Waiting for LIP to complete... Sep 13 15:00:22 escabot qla2300 0000:05:08.0: LOOP UP detected (2 Gbps). Sep 13 15:00:22 escabot qla2300 0000:05:08.0: Topology - (F_Port), Host Loop address 0xffff Sep 13 15:00:22 escabot scsi0 : qla2xxx Sep 13 15:00:22 escabot qla2300 0000:05:08.0: Sep 13 15:00:22 escabot QLogic Fibre Channel HBA Driver: 8.01.07-fo Sep 13 15:00:22 escabot QLogic QLA2340 - Sep 13 15:00:22 escabot ISP2312: PCI-X (100 MHz) @ 0000:05:08.0 hdma +, host#=0, fw=3.03.19 IPX Sep 13 15:00:22 escabot scsi 0:0:0:0: Direct-Access SUN CSM200_R 0619 PQ: 0 ANSI: 5 Sep 13 15:00:22 escabot qla2300 0000:05:08.0: scsi(0:0:0:0): Enabled tagged queuing, queue depth 32. Sep 13 15:00:22 escabot sd 0:0:0:0: [sda] 104857600 512-byte hardware sectors (53687 MB) Sep 13 15:00:22 escabot sd 0:0:0:0: [sda] Write Protect is off Sep 13 15:00:22 escabot sd 0:0:0:0: [sda] Mode Sense: 77 00 10 08 Sep 13 15:00:22 escabot sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, supports DPO and FUA Sep 13 15:00:22 escabot sd 0:0:0:0: [sda] 104857600 512-byte hardware sectors (53687 MB) Sep 13 15:00:22 escabot sd 0:0:0:0: [sda] Write Protect is off Sep 13 15:00:22 escabot sd 0:0:0:0: [sda] Mode Sense: 77 00 10 08 Sep 13 15:00:22 escabot sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, supports DPO and FUA Sep 13 15:00:22 escabot sda: sda1 sda2 sda3 Sep 13 15:00:22 escabot sd 0:0:0:0: [sda] Attached SCSI disk Sep 13 15:00:22 escabot sd 0:0:0:0: Attached scsi generic sg0 type 0 Sep 13 15:00:22 escabot scsi 0:0:0:1: Direct-Access SUN CSM200_R 0619 PQ: 0 ANSI: 5 Sep 13 15:00:22 escabot qla2300 0000:05:08.0: scsi(0:0:0:1): Enabled tagged queuing, queue depth 32. Sep 13 15:00:22 escabot sd 0:0:0:1: [sdb] 104857600 512-byte hardware sectors (53687 MB) Sep 13 15:00:22 escabot sd 0:0:0:1: [sdb] Write Protect is off Sep 13 15:00:22 escabot sd 0:0:0:1: [sdb] Mode Sense: 77 00 10 08 Sep 13 15:00:22 escabot sd 0:0:0:1: [sdb] Write cache: enabled, read cache: enabled, supports DPO and FUA Sep 13 15:00:22 escabot sd 0:0:0:1: [sdb] 104857600 512-byte hardware sectors (53687 MB) Sep 13 15:00:22 escabot sd 0:0:0:1: [sdb] Write Protect is off Sep 13 15:00:22 escabot sd 0:0:0:1: [sdb] Mode Sense: 77 00 10 08 Sep 13 15:00:22 escabot sd 0:0:0:1: [sdb] Write cache: enabled, read cache: enabled, supports DPO and FUA Sep 13 15:00:22 escabot sdb: sdb1 Sep 13 15:00:22 escabot sd 0:0:0:1: [sdb] Attached SCSI disk Sep 13 15:00:22 escabot sd 0:0:0:1: Attached scsi generic sg1 type 0 Sep 13 15:00:22 escabot ACPI: PCI Interrupt 0000:06:09.0[A] -> GSI 36 (level, low) -> IRQ 22 Sep 13 15:00:22 escabot qla2300 0000:06:09.0: Found an ISP2312, irq 22, iobase 0xf8836000 Sep 13 15:00:22 escabot qla2300 0000:06:09.0: Configuring PCI space... Sep 13 15:00:22 escabot qla2300 0000:06:09.0: Configure NVRAM parameters... Sep 13 15:00:22 escabot qla2300 0000:06:09.0: Verifying loaded RISC code... Sep 13 15:00:22 escabot qla2300 0000:06:09.0: Allocated (412 KB) for firmware dump... Sep 13 15:00:22 escabot qla2300 0000:06:09.0: Waiting for LIP to complete... Sep 13 15:00:22 escabot qla2300 0000:06:09.0: LIP reset occured (f8f7). Sep 13 15:00:22 escabot qla2300 0000:06:09.0: LIP occured (f8f7). Sep 13 15:00:22 escabot qla2300 0000:06:09.0: LIP reset occured (f7f7). Sep 13 15:00:22 escabot qla2300 0000:06:09.0: LOOP UP detected (2 Gbps). Sep 13 15:00:22 escabot qla2300 0000:06:09.0: Topology - (F_Port), Host Loop address 0xffff Sep 13 15:00:22 escabot scsi1 : qla2xxx Sep 13 15:00:22 escabot qla2300 0000:06:09.0: Sep 13 15:00:22 escabot QLogic Fibre Channel HBA Driver: 8.01.07-fo Sep 13 15:00:22 escabot QLogic QLA2340 - Sep 13 15:00:22 escabot ISP2312: PCI-X (133 MHz) @ 0000:06:09.0 hdma +, host#=1, fw=3.03.19 IPX Sep 13 15:00:22 escabot scsi 1:0:0:0: Sequential-Access IBM ULTRIUM-TD3 54K1 PQ: 0 ANSI: 3 Sep 13 15:00:22 escabot qla2300 0000:06:09.0: scsi(1:0:0:0): Enabled tagged queuing, queue depth 32. Sep 13 15:00:22 escabot st 1:0:0:0: Attached scsi tape st0 Sep 13 15:00:22 escabot st 1:0:0:0: st0: try direct i/o: yes (alignment 512 B) Sep 13 15:00:22 escabot st 1:0:0:0: Attached scsi generic sg2 type 1 Sep 13 15:00:22 escabot scsi 1:0:0:1: Medium Changer SPECTRA PYTHON 2000 PQ: 0 ANSI: 3 Sep 13 15:00:22 escabot ch0: type #1 (mt): 0x1+1 [medium transport] Sep 13 15:00:22 escabot ch0: type #2 (st): 0x1000+30 [storage] Sep 13 15:00:22 escabot ch0: type #3 (ie): 0x10+0 [import/export] Sep 13 15:00:22 escabot ch0: type #4 (dt): 0x100+2 [data transfer] Sep 13 15:00:22 escabot ch0: dt 0x100: ID/LUN unknown Sep 13 15:00:22 escabot ch0: dt 0x101: ID/LUN unknown Sep 13 15:00:22 escabot ch0: INITIALIZE ELEMENT STATUS, may take some time ... Sep 13 15:00:22 escabot ch0: ... finished Sep 13 15:00:22 escabot ch 1:0:0:1: Attached scsi changer ch0 Sep 13 15:00:22 escabot ch 1:0:0:1: Attached scsi generic sg3 type 8 Sep 13 15:00:22 escabot scsi 1:0:1:0: Sequential-Access IBM ULTRIUM-TD3 54K1 PQ: 0 ANSI: 3 Sep 13 15:00:22 escabot qla2300 0000:06:09.0: scsi(1:0:1:0): Enabled tagged queuing, queue depth 32. Sep 13 15:00:22 escabot st 1:0:1:0: Attached scsi tape st1 Sep 13 15:00:22 escabot st 1:0:1:0: st1: try direct i/o: yes (alignment 512 B) Sep 13 15:00:22 escabot st 1:0:1:0: Attached scsi generic sg4 type 1 Sep 13 15:00:22 escabot kjournald starting. Commit interval 5 seconds Sep 13 15:00:22 escabot EXT3-fs: mounted filesystem with ordered data mode. Sep 13 15:00:22 escabot Freeing unused kernel memory: 240k freed Sep 13 15:00:22 escabot EXT3 FS on sda3, internal journal Sep 13 15:00:22 escabot kjournald starting. Commit interval 5 seconds Sep 13 15:00:22 escabot EXT3 FS on sdb1, internal journal Sep 13 15:00:22 escabot EXT3-fs: mounted filesystem with ordered data mode. Sep 13 15:00:22 escabot Adding 2008116k swap on /dev/sda2. Priority:-1 extents:1 across:2008116k Sep 13 15:00:22 escabot PM: Writing back config space on device 0000:03:06.0 at offset b (was 164814e4, writing d00e11) Sep 13 15:00:22 escabot PM: Writing back config space on device 0000:03:06.0 at offset 3 (was 804000, writing 804010) Sep 13 15:00:22 escabot PM: Writing back config space on device 0000:03:06.0 at offset 2 (was 2000000, writing 2000010) Sep 13 15:00:22 escabot PM: Writing back config space on device 0000:03:06.0 at offset 1 (was 2b00000, writing 2b00146) Sep 13 15:00:22 escabot tg3: eth2: Link is up at 1000 Mbps, full duplex. Sep 13 15:00:22 escabot tg3: eth2: Flow control is on for TX and on for RX. Sep 13 15:00:22 escabot PM: Writing back config space on device 0000:03:06.1 at offset b (was 164814e4, writing d00e11) Sep 13 15:00:22 escabot PM: Writing back config space on device 0000:03:06.1 at offset 3 (was 804000, writing 804010) Sep 13 15:00:22 escabot PM: Writing back config space on device 0000:03:06.1 at offset 2 (was 2000000, writing 2000010) Sep 13 15:00:22 escabot PM: Writing back config space on device 0000:03:06.1 at offset 1 (was 2b00000, writing 2b00146) Sep 13 15:00:25 escabot st0: Block limits 1 - 16777215 bytes. Sep 13 15:00:25 escabot st1: Block limits 1 - 16777215 bytes. Sep 13 15:00:25 escabot tg3: eth3: Link is up at 1000 Mbps, full duplex. Sep 13 15:00:25 escabot tg3: eth3: Flow control is on for TX and on for RX. Sep 13 15:04:16 escabot scsi 0:0:0:2: Direct-Access SUN CSM200_R 0619 PQ: 0 ANSI: 5 Sep 13 15:04:16 escabot qla2300 0000:05:08.0: scsi(0:0:0:2): Enabled tagged queuing, queue depth 32. Sep 13 15:04:16 escabot sd 0:0:0:2: [sdc] 1048576000 512-byte hardware sectors (536871 MB) Sep 13 15:04:16 escabot sd 0:0:0:2: [sdc] Write Protect is off Sep 13 15:04:16 escabot sd 0:0:0:2: [sdc] Mode Sense: 77 00 10 08 Sep 13 15:04:16 escabot sd 0:0:0:2: [sdc] Write cache: enabled, read cache: enabled, supports DPO and FUA Sep 13 15:04:16 escabot sd 0:0:0:2: [sdc] 1048576000 512-byte hardware sectors (536871 MB) Sep 13 15:04:16 escabot sd 0:0:0:2: [sdc] Write Protect is off Sep 13 15:04:16 escabot sd 0:0:0:2: [sdc] Mode Sense: 77 00 10 08 Sep 13 15:04:16 escabot sd 0:0:0:2: [sdc] Write cache: enabled, read cache: enabled, supports DPO and FUA Sep 13 15:04:19 escabot sdc: sdc1 Sep 13 15:04:19 escabot sd 0:0:0:2: [sdc] Attached SCSI disk Sep 13 15:04:19 escabot sd 0:0:0:2: Attached scsi generic sg5 type 0 Sep 13 15:04:24 escabot sd 0:0:0:2: [sdc] 1048576000 512-byte hardware sectors (536871 MB) Sep 13 15:04:24 escabot sd 0:0:0:2: [sdc] Write Protect is off Sep 13 15:04:24 escabot sd 0:0:0:2: [sdc] Mode Sense: 77 00 10 08 Sep 13 15:04:24 escabot sd 0:0:0:2: [sdc] Write cache: enabled, read cache: enabled, supports DPO and FUA Sep 13 15:04:24 escabot sdc: sdc1 Sep 13 15:04:29 escabot NTFS volume version 3.1. Sep 13 15:31:25 escabot init invoked oom-killer: gfp_mask=0xd0, order=0, oomkilladj=0 Sep 13 15:31:25 escabot [<c0149ea8>] out_of_memory+0x158/0x1b0 Sep 13 15:31:25 escabot [<c014b7b0>] __alloc_pages+0x2a0/0x300 Sep 13 15:31:25 escabot [<c01729aa>] core_sys_select+0x1fa/0x2f0 Sep 13 15:31:25 escabot [<c0162a21>] cache_alloc_refill+0x2e1/0x500 Sep 13 15:31:25 escabot [<c0162736>] kmem_cache_alloc+0x46/0x50 Sep 13 15:31:25 escabot [<c016e238>] getname+0x28/0xf0 Sep 13 15:31:25 escabot [<c016fe5e>] __user_walk_fd+0x1e/0x60 Sep 13 15:31:25 escabot [<c0168e29>] cp_new_stat64+0xf9/0x110 Sep 13 15:31:25 escabot [<c0169152>] vfs_stat_fd+0x22/0x60 Sep 13 15:31:25 escabot [<c016922f>] sys_stat64+0xf/0x30 Sep 13 15:31:25 escabot [<c0124956>] do_gettimeofday+0x36/0xf0 Sep 13 15:31:25 escabot [<c0120bbf>] sys_time+0xf/0x30 Sep 13 15:31:25 escabot [<c0102b10>] sysenter_past_esp+0x5d/0x81 Sep 13 15:31:25 escabot ======================= Sep 13 15:31:25 escabot Mem-info: Sep 13 15:31:25 escabot DMA per-cpu: Sep 13 15:31:25 escabot CPU 0: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Sep 13 15:31:25 escabot CPU 1: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Sep 13 15:31:25 escabot CPU 2: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Sep 13 15:31:25 escabot CPU 3: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Sep 13 15:31:25 escabot Normal per-cpu: Sep 13 15:31:25 escabot CPU 0: Hot: hi: 186, btch: 31 usd: 143 Cold: hi: 62, btch: 15 usd: 56 Sep 13 15:31:25 escabot CPU 1: Hot: hi: 186, btch: 31 usd: 31 Cold: hi: 62, btch: 15 usd: 53 Sep 13 15:31:25 escabot CPU 2: Hot: hi: 186, btch: 31 usd: 8 Cold: hi: 62, btch: 15 usd: 54 Sep 13 15:31:25 escabot CPU 3: Hot: hi: 186, btch: 31 usd: 99 Cold: hi: 62, btch: 15 usd: 58 Sep 13 15:31:25 escabot HighMem per-cpu: Sep 13 15:31:25 escabot CPU 0: Hot: hi: 186, btch: 31 usd: 1 Cold: hi: 62, btch: 15 usd: 10 Sep 13 15:31:25 escabot CPU 1: Hot: hi: 186, btch: 31 usd: 23 Cold: hi: 62, btch: 15 usd: 1 Sep 13 15:31:25 escabot CPU 2: Hot: hi: 186, btch: 31 usd: 18 Cold: hi: 62, btch: 15 usd: 1 Sep 13 15:31:25 escabot CPU 3: Hot: hi: 186, btch: 31 usd: 9 Cold: hi: 62, btch: 15 usd: 12 Sep 13 15:31:25 escabot Active:8078 inactive:1776744 dirty:10338 writeback:0 unstable:0 Sep 13 15:31:25 escabot free:1090395 slab:198893 mapped:988 pagetables:129 bounce:0 Sep 13 15:31:25 escabot DMA free:3560kB min:68kB low:84kB high:100kB active:0kB inactive:0kB present:16256kB pages_scanned:0 all_unreclaimable? yes Sep 13 15:31:25 escabot lowmem_reserve[]: 0 873 12176 Sep 13 15:31:25 escabot Normal free:3648kB min:3744kB low:4680kB high: 5616kB active:0kB inactive:3160kB present:894080kB pages_scanned:5336 all_unreclaimable? yes Sep 13 15:31:25 escabot lowmem_reserve[]: 0 0 90424 Sep 13 15:31:25 escabot HighMem free:4354372kB min:512kB low:12640kB high:24768kB active:32312kB inactive:7103816kB present:11574272kB pages_scanned:0 all_unreclaimable? no Sep 13 15:31:25 escabot lowmem_reserve[]: 0 0 0 Sep 13 15:31:25 escabot DMA: 4*4kB 3*8kB 0*16kB 0*32kB 1*64kB 1*128kB 1*256kB 0*512kB 1*1024kB 1*2048kB 0*4096kB = 3560kB Sep 13 15:31:25 escabot Normal: 44*4kB 18*8kB 6*16kB 1*32kB 6*64kB 2*128kB 0*256kB 1*512kB 0*1024kB 1*2048kB 0*4096kB = 3648kB Sep 13 15:31:25 escabot HighMem: 1*4kB 0*8kB 0*16kB 37914*32kB 43188*64kB 1628*128kB 5*256kB 247*512kB 30*1024kB 1*2048kB 2*4096kB = 4354372kB Sep 13 15:31:25 escabot Swap cache: add 983, delete 972, find 0/1, race 0+0 Sep 13 15:31:25 escabot Free swap = 2004216kB Sep 13 15:31:25 escabot Total swap = 2008116kB Sep 13 15:31:25 escabot Free swap: 2004216kB Sep 13 15:31:25 escabot syslog-ng invoked oom-killer: gfp_mask=0xd0, order=0, oomkilladj=0 Sep 13 15:31:25 escabot [<c0149ea8>] out_of_memory+0x158/0x1b0 Sep 13 15:31:25 escabot [<c014b7b0>] __alloc_pages+0x2a0/0x300 Sep 13 15:31:25 escabot [<c0162a21>] cache_alloc_refill+0x2e1/0x500 Sep 13 15:31:25 escabot [<c0162736>] kmem_cache_alloc+0x46/0x50 Sep 13 15:31:25 escabot [<c016e238>] getname+0x28/0xf0 Sep 13 15:31:25 escabot [<c016fe5e>] __user_walk_fd+0x1e/0x60 Sep 13 15:31:25 escabot [<c0169152>] vfs_stat_fd+0x22/0x60 Sep 13 15:31:25 escabot [<c012f460>] autoremove_wake_function+0x0/0x50 Sep 13 15:31:25 escabot [<c0123928>] __capable+0x8/0x20 Sep 13 15:31:25 escabot [<c02d02ef>] cap_syslog+0x1f/0x30 Sep 13 15:31:25 escabot [<c0123928>] __capable+0x8/0x20 Sep 13 15:31:25 escabot [<c011d026>] do_syslog+0x3b6/0x3e0 Sep 13 15:31:25 escabot [<c016922f>] sys_stat64+0xf/0x30 Sep 13 15:31:25 escabot [<c0124956>] do_gettimeofday+0x36/0xf0 Sep 13 15:31:25 escabot [<c0120bbf>] sys_time+0xf/0x30 Sep 13 15:31:25 escabot [<c0102b10>] sysenter_past_esp+0x5d/0x81 Sep 13 15:31:25 escabot ======================= Sep 13 15:31:25 escabot Mem-info: Sep 13 15:31:25 escabot DMA per-cpu: Sep 13 15:31:25 escabot CPU 0: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Sep 13 15:31:25 escabot CPU 1: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Sep 13 15:31:25 escabot CPU 2: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Sep 13 15:31:25 escabot CPU 3: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Sep 13 15:31:25 escabot Normal per-cpu: Sep 13 15:31:25 escabot CPU 0: Hot: hi: 186, btch: 31 usd: 143 Cold: hi: 62, btch: 15 usd: 56 Sep 13 15:31:25 escabot CPU 1: Hot: hi: 186, btch: 31 usd: 31 Cold: hi: 62, btch: 15 usd: 53 Sep 13 15:31:25 escabot CPU 2: Hot: hi: 186, btch: 31 usd: 8 Cold: hi: 62, btch: 15 usd: 54 Sep 13 15:31:25 escabot CPU 3: Hot: hi: 186, btch: 31 usd: 99 Cold: hi: 62, btch: 15 usd: 58 Sep 13 15:31:25 escabot HighMem per-cpu: Sep 13 15:31:25 escabot CPU 0: Hot: hi: 186, btch: 31 usd: 1 Cold: hi: 62, btch: 15 usd: 10 Sep 13 15:31:25 escabot CPU 1: Hot: hi: 186, btch: 31 usd: 23 Cold: hi: 62, btch: 15 usd: 1 Sep 13 15:31:25 escabot CPU 2: Hot: hi: 186, btch: 31 usd: 18 Cold: hi: 62, btch: 15 usd: 1 Sep 13 15:31:25 escabot CPU 3: Hot: hi: 186, btch: 31 usd: 9 Cold: hi: 62, btch: 15 usd: 12 Sep 13 15:31:25 escabot Active:8078 inactive:1776744 dirty:10338 writeback:0 unstable:0 Sep 13 15:31:25 escabot free:1090395 slab:198893 mapped:988 pagetables:129 bounce:0 Sep 13 15:31:25 escabot DMA free:3560kB min:68kB low:84kB high:100kB active:0kB inactive:0kB present:16256kB pages_scanned:0 all_unreclaimable? yes Sep 13 15:31:25 escabot lowmem_reserve[]: 0 873 12176 Sep 13 15:31:25 escabot Normal free:3648kB min:3744kB low:4680kB high: 5616kB active:0kB inactive:3160kB present:894080kB pages_scanned:5336 all_unreclaimable? yes Sep 13 15:31:25 escabot lowmem_reserve[]: 0 0 90424 Sep 13 15:31:25 escabot HighMem free:4354372kB min:512kB low:12640kB high:24768kB active:32312kB inactive:7103816kB present:11574272kB pages_scanned:0 all_unreclaimable? no Sep 13 15:31:25 escabot lowmem_reserve[]: 0 0 0 Sep 13 15:31:25 escabot DMA: 4*4kB 3*8kB 0*16kB 0*32kB 1*64kB 1*128kB 1*256kB 0*512kB 1*1024kB 1*2048kB 0*4096kB = 3560kB Sep 13 15:31:25 escabot Normal: 44*4kB 18*8kB 6*16kB 1*32kB 6*64kB 2*128kB 0*256kB 1*512kB 0*1024kB 1*2048kB 0*4096kB = 3648kB Sep 13 15:31:25 escabot HighMem: 1*4kB 0*8kB 0*16kB 37914*32kB 43188*64kB 1628*128kB 5*256kB 247*512kB 30*1024kB 1*2048kB 2*4096kB = 4354372kB Sep 13 15:31:25 escabot Swap cache: add 983, delete 972, find 0/1, race 0+0 Sep 13 15:31:25 escabot Free swap = 2004216kB Sep 13 15:31:25 escabot Total swap = 2008116kB Sep 13 15:31:25 escabot Free swap: 2004216kB Sep 13 15:31:25 escabot 3145727 pages of RAM Sep 13 15:31:25 escabot 2916351 pages of HIGHMEM Sep 13 15:31:25 escabot 69112 reserved pages Sep 13 15:31:25 escabot 1781351 pages shared Sep 13 15:31:25 escabot 11 pages swap cached Sep 13 15:31:25 escabot 10338 pages dirty Sep 13 15:31:25 escabot 0 pages writeback Sep 13 15:31:25 escabot 988 pages mapped Sep 13 15:31:25 escabot 198893 pages slab Sep 13 15:31:25 escabot 129 pages pagetables Sep 13 15:31:25 escabot Out of memory: kill process 5771 (mysqld) score 35692 or a child Sep 13 15:31:25 escabot Killed process 5771 (mysqld) Sep 13 15:31:25 escabot init invoked oom-killer: gfp_mask=0xd0, order=0, oomkilladj=0 Sep 13 15:31:25 escabot [<c0149ea8>] out_of_memory+0x158/0x1b0 Sep 13 15:31:25 escabot [<c014b7b0>] __alloc_pages+0x2a0/0x300 Sep 13 15:31:25 escabot [<c01729aa>] core_sys_select+0x1fa/0x2f0 Sep 13 15:31:25 escabot [<c0162a21>] cache_alloc_refill+0x2e1/0x500 Sep 13 15:31:25 escabot [<c0162736>] kmem_cache_alloc+0x46/0x50 Sep 13 15:31:25 escabot [<c016e238>] getname+0x28/0xf0 Sep 13 15:31:25 escabot [<c016fe5e>] __user_walk_fd+0x1e/0x60 Sep 13 15:31:25 escabot [<c0168e29>] cp_new_stat64+0xf9/0x110 Sep 13 15:31:25 escabot [<c0169152>] vfs_stat_fd+0x22/0x60 Sep 13 15:31:25 escabot [<c016922f>] sys_stat64+0xf/0x30 Sep 13 15:31:25 escabot [<c0124956>] do_gettimeofday+0x36/0xf0 Sep 13 15:31:25 escabot [<c0120bbf>] sys_time+0xf/0x30 Sep 13 15:31:25 escabot [<c0102b10>] sysenter_past_esp+0x5d/0x81 Sep 13 15:31:25 escabot ======================= Sep 13 15:31:25 escabot Mem-info: Sep 13 15:31:25 escabot DMA per-cpu: Sep 13 15:31:25 escabot CPU 0: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Sep 13 15:31:25 escabot CPU 1: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Sep 13 15:31:25 escabot CPU 2: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Sep 13 15:31:25 escabot CPU 3: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Sep 13 15:31:25 escabot Normal per-cpu: Sep 13 15:31:25 escabot CPU 0: Hot: hi: 186, btch: 31 usd: 143 Cold: hi: 62, btch: 15 usd: 56 Sep 13 15:31:25 escabot CPU 1: Hot: hi: 186, btch: 31 usd: 31 Cold: hi: 62, btch: 15 usd: 53 Sep 13 15:31:25 escabot CPU 2: Hot: hi: 186, btch: 31 usd: 8 Cold: hi: 62, btch: 15 usd: 54 Sep 13 15:31:25 escabot CPU 3: Hot: hi: 186, btch: 31 usd: 99 Cold: hi: 62, btch: 15 usd: 58 Sep 13 15:31:25 escabot HighMem per-cpu: Sep 13 15:31:25 escabot CPU 0: Hot: hi: 186, btch: 31 usd: 1 Cold: hi: 62, btch: 15 usd: 10 Sep 13 15:31:25 escabot CPU 1: Hot: hi: 186, btch: 31 usd: 23 Cold: hi: 62, btch: 15 usd: 1 Sep 13 15:31:25 escabot CPU 2: Hot: hi: 186, btch: 31 usd: 18 Cold: hi: 62, btch: 15 usd: 1 Sep 13 15:31:25 escabot CPU 3: Hot: hi: 186, btch: 31 usd: 9 Cold: hi: 62, btch: 15 usd: 12 Sep 13 15:31:25 escabot Active:8078 inactive:1776744 dirty:10338 writeback:0 unstable:0 Sep 13 15:31:25 escabot free:1090395 slab:198893 mapped:988 pagetables:129 bounce:0 Sep 13 15:31:25 escabot DMA free:3560kB min:68kB low:84kB high:100kB active:0kB inactive:0kB present:16256kB pages_scanned:0 all_unreclaimable? yes Sep 13 15:31:25 escabot lowmem_reserve[]: 0 873 12176 Sep 13 15:31:25 escabot Normal free:3648kB min:3744kB low:4680kB high: 5616kB active:0kB inactive:3160kB present:894080kB pages_scanned:5336 all_unreclaimable? yes Sep 13 15:31:25 escabot lowmem_reserve[]: 0 0 90424 Sep 13 15:31:25 escabot HighMem free:4354372kB min:512kB low:12640kB high:24768kB active:32312kB inactive:7103816kB present:11574272kB pages_scanned:0 all_unreclaimable? no Sep 13 15:31:25 escabot lowmem_reserve[]: 0 0 0 Sep 13 15:31:25 escabot DMA: 4*4kB 3*8kB 0*16kB 0*32kB 1*64kB 1*128kB 1*256kB 0*512kB 1*1024kB 1*2048kB 0*4096kB = 3560kB Sep 13 15:31:25 escabot Normal: 44*4kB 18*8kB 6*16kB 1*32kB 6*64kB 2*128kB 0*256kB 1*512kB 0*1024kB 1*2048kB 0*4096kB = 3648kB Sep 13 15:31:25 escabot HighMem: 1*4kB 0*8kB 0*16kB 37914*32kB 43188*64kB 1628*128kB 5*256kB 247*512kB 30*1024kB 1*2048kB 2*4096kB = 4354372kB Sep 13 15:31:25 escabot Swap cache: add 983, delete 972, find 0/1, race 0+0 Sep 13 15:31:25 escabot Free swap = 2004216kB Sep 13 15:31:25 escabot Total swap = 2008116kB Sep 13 15:31:25 escabot Free swap: 2004216kB Sep 13 15:31:25 escabot 3145727 pages of RAM Sep 13 15:31:25 escabot 2916351 pages of HIGHMEM Sep 13 15:31:25 escabot 69112 reserved pages Sep 13 15:31:25 escabot 1781351 pages shared Sep 13 15:31:25 escabot 11 pages swap cached Sep 13 15:31:25 escabot 10338 pages dirty Sep 13 15:31:25 escabot 0 pages writeback Sep 13 15:31:25 escabot 988 pages mapped Sep 13 15:31:25 escabot 198893 pages slab Sep 13 15:31:25 escabot 129 pages pagetables Sep 13 15:31:25 escabot Out of memory: kill process 5789 (mysqld) score 35692 or a child Sep 13 15:31:25 escabot Killed process 5789 (mysqld) Sep 13 15:31:25 escabot syslog-ng invoked oom-killer: gfp_mask=0xd0, order=0, oomkilladj=0 Sep 13 15:31:25 escabot [<c0149ea8>] out_of_memory+0x158/0x1b0 Sep 13 15:31:25 escabot [<c014b7b0>] __alloc_pages+0x2a0/0x300 Sep 13 15:31:25 escabot [<c0162a21>] cache_alloc_refill+0x2e1/0x500 Sep 13 15:31:25 escabot [<c0162736>] kmem_cache_alloc+0x46/0x50 Sep 13 15:31:25 escabot [<c016e238>] getname+0x28/0xf0 Sep 13 15:31:25 escabot [<c016fe5e>] __user_walk_fd+0x1e/0x60 Sep 13 15:31:25 escabot [<c0169152>] vfs_stat_fd+0x22/0x60 Sep 13 15:31:25 escabot [<c012f460>] autoremove_wake_function+0x0/0x50 Sep 13 15:31:25 escabot [<c0123928>] __capable+0x8/0x20 Sep 13 15:31:25 escabot [<c02d02ef>] cap_syslog+0x1f/0x30 Sep 13 15:31:25 escabot [<c0123928>] __capable+0x8/0x20 Sep 13 15:31:25 escabot [<c011d026>] do_syslog+0x3b6/0x3e0 Sep 13 15:31:25 escabot [<c016922f>] sys_stat64+0xf/0x30 Sep 13 15:31:25 escabot [<c0124956>] do_gettimeofday+0x36/0xf0 Sep 13 15:31:25 escabot [<c0120bbf>] sys_time+0xf/0x30 Sep 13 15:31:25 escabot [<c0102b10>] sysenter_past_esp+0x5d/0x81 Sep 13 15:31:25 escabot ======================= Sep 13 15:31:25 escabot Mem-info: Sep 13 15:31:25 escabot DMA per-cpu: Sep 13 15:31:25 escabot CPU 0: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Sep 13 15:31:25 escabot CPU 1: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Sep 13 15:31:25 escabot CPU 2: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Sep 13 15:31:25 escabot CPU 3: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Sep 13 15:31:25 escabot Normal per-cpu: Sep 13 15:31:25 escabot CPU 0: Hot: hi: 186, btch: 31 usd: 143 Cold: hi: 62, btch: 15 usd: 56 Sep 13 15:31:25 escabot CPU 1: Hot: hi: 186, btch: 31 usd: 31 Cold: hi: 62, btch: 15 usd: 53 Sep 13 15:31:25 escabot CPU 2: Hot: hi: 186, btch: 31 usd: 8 Cold: hi: 62, btch: 15 usd: 54 Sep 13 15:31:25 escabot CPU 3: Hot: hi: 186, btch: 31 usd: 130 Cold: hi: 62, btch: 15 usd: 58 Sep 13 15:31:25 escabot HighMem per-cpu: Sep 13 15:31:25 escabot CPU 0: Hot: hi: 186, btch: 31 usd: 1 Cold: hi: 62, btch: 15 usd: 10 Sep 13 15:31:25 escabot CPU 1: Hot: hi: 186, btch: 31 usd: 23 Cold: hi: 62, btch: 15 usd: 1 Sep 13 15:31:25 escabot CPU 2: Hot: hi: 186, btch: 31 usd: 18 Cold: hi: 62, btch: 15 usd: 1 Sep 13 15:31:25 escabot CPU 3: Hot: hi: 186, btch: 31 usd: 162 Cold: hi: 62, btch: 15 usd: 12 Sep 13 15:31:25 escabot Active:2311 inactive:1776744 dirty:10338 writeback:0 unstable:0 Sep 13 15:31:25 escabot free:1096030 slab:198893 mapped:915 pagetables:92 bounce:0 Sep 13 15:31:25 escabot DMA free:3560kB min:68kB low:84kB high:100kB active:0kB inactive:0kB present:16256kB pages_scanned:0 all_unreclaimable? yes Sep 13 15:31:25 escabot lowmem_reserve[]: 0 873 12176 Sep 13 15:31:25 escabot Normal free:3648kB min:3744kB low:4680kB high: 5616kB active:0kB inactive:3160kB present:894080kB pages_scanned:5336 all_unreclaimable? yes Sep 13 15:31:25 escabot lowmem_reserve[]: 0 0 90424 Sep 13 15:31:25 escabot HighMem free:4376912kB min:512kB low:12640kB high:24768kB active:9244kB inactive:7103816kB present:11574272kB pages_scanned:0 all_unreclaimable? no Sep 13 15:31:25 escabot lowmem_reserve[]: 0 0 0 Sep 13 15:31:25 escabot DMA: 4*4kB 3*8kB 0*16kB 0*32kB 1*64kB 1*128kB 1*256kB 0*512kB 1*1024kB 1*2048kB 0*4096kB = 3560kB Sep 13 15:31:25 escabot Normal: 44*4kB 18*8kB 6*16kB 1*32kB 6*64kB 2*128kB 0*256kB 1*512kB 0*1024kB 1*2048kB 0*4096kB = 3648kB Sep 13 15:31:25 escabot HighMem: 107*4kB 42*8kB 39*16kB 37944*32kB 43216*64kB 1640*128kB 15*256kB 253*512kB 35*1024kB 2*2048kB 3*4096kB = 4376940kB Sep 13 15:31:25 escabot Swap cache: add 983, delete 972, find 0/1, race 0+0 Sep 13 15:31:25 escabot Free swap = 2004216kB Sep 13 15:31:25 escabot Total swap = 2008116kB Sep 13 15:31:25 escabot Free swap: 2004216kB Sep 13 15:31:25 escabot 3145727 pages of RAM Sep 13 15:31:25 escabot 2916351 pages of HIGHMEM Sep 13 15:31:25 escabot 69112 reserved pages Sep 13 15:31:25 escabot 1780992 pages shared Sep 13 15:31:25 escabot 11 pages swap cached Sep 13 15:31:25 escabot 10338 pages dirty Sep 13 15:31:25 escabot 0 pages writeback Sep 13 15:31:25 escabot 915 pages mapped Sep 13 15:31:25 escabot 198893 pages slab Sep 13 15:31:25 escabot 92 pages pagetables Sep 13 15:31:25 escabot Out of memory: kill process 5857 (bacula-dir) score 379 or a child Sep 13 15:31:25 escabot Killed process 5857 (bacula-dir) Sep 13 15:31:25 escabot init invoked oom-killer: gfp_mask=0xd0, order=0, oomkilladj=0 Sep 13 15:31:25 escabot [<c0149ea8>] out_of_memory+0x158/0x1b0 Sep 13 15:31:25 escabot [<c014b7b0>] __alloc_pages+0x2a0/0x300 Sep 13 15:31:25 escabot [<c01729aa>] core_sys_select+0x1fa/0x2f0 Sep 13 15:31:25 escabot [<c0162a21>] cache_alloc_refill+0x2e1/0x500 Sep 13 15:31:25 escabot [<c0162736>] kmem_cache_alloc+0x46/0x50 Sep 13 15:31:25 escabot [<c016e238>] getname+0x28/0xf0 Sep 13 15:31:25 escabot [<c016fe5e>] __user_walk_fd+0x1e/0x60 Sep 13 15:31:25 escabot [<c0168e29>] cp_new_stat64+0xf9/0x110 Sep 13 15:31:25 escabot [<c0169152>] vfs_stat_fd+0x22/0x60 Sep 13 15:31:25 escabot [<c016922f>] sys_stat64+0xf/0x30 Sep 13 15:31:25 escabot [<c0124956>] do_gettimeofday+0x36/0xf0 Sep 13 15:31:25 escabot [<c0120bbf>] sys_time+0xf/0x30 Sep 13 15:31:25 escabot [<c0102b10>] sysenter_past_esp+0x5d/0x81 Sep 13 15:31:25 escabot ======================= Sep 13 15:31:25 escabot Mem-info: Sep 13 15:31:25 escabot DMA per-cpu: Sep 13 15:31:25 escabot CPU 0: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Sep 13 15:31:25 escabot CPU 1: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Sep 13 15:31:25 escabot CPU 2: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Sep 13 15:31:25 escabot CPU 3: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Sep 13 15:31:25 escabot Normal per-cpu: Sep 13 15:31:25 escabot CPU 0: Hot: hi: 186, btch: 31 usd: 151 Cold: hi: 62, btch: 15 usd: 56 Sep 13 15:31:25 escabot CPU 1: Hot: hi: 186, btch: 31 usd: 31 Cold: hi: 62, btch: 15 usd: 53 Sep 13 15:31:25 escabot CPU 2: Hot: hi: 186, btch: 31 usd: 8 Cold: hi: 62, btch: 15 usd: 54 Sep 13 15:31:25 escabot CPU 3: Hot: hi: 186, btch: 31 usd: 130 Cold: hi: 62, btch: 15 usd: 58 Sep 13 15:31:25 escabot HighMem per-cpu: Sep 13 15:31:25 escabot CPU 0: Hot: hi: 186, btch: 31 usd: 63 Cold: hi: 62, btch: 15 usd: 10 Sep 13 15:31:25 escabot CPU 1: Hot: hi: 186, btch: 31 usd: 23 Cold: hi: 62, btch: 15 usd: 1 Sep 13 15:31:25 escabot CPU 2: Hot: hi: 186, btch: 31 usd: 18 Cold: hi: 62, btch: 15 usd: 1 Sep 13 15:31:25 escabot CPU 3: Hot: hi: 186, btch: 31 usd: 162 Cold: hi: 62, btch: 15 usd: 12 Sep 13 15:31:25 escabot Active:2238 inactive:1776744 dirty:10338 writeback:0 unstable:0 Sep 13 15:31:25 escabot free:1096030 slab:198893 mapped:842 pagetables:92 bounce:0 Sep 13 15:31:25 escabot DMA free:3560kB min:68kB low:84kB high:100kB active:0kB inactive:0kB present:16256kB pages_scanned:0 all_unreclaimable? yes Sep 13 15:31:25 escabot lowmem_reserve[]: 0 873 12176 Sep 13 15:31:25 escabot Normal free:3648kB min:3744kB low:4680kB high: 5616kB active:0kB inactive:3160kB present:894080kB pages_scanned:5336 all_unreclaimable? yes Sep 13 15:31:25 escabot lowmem_reserve[]: 0 0 90424 Sep 13 15:31:25 escabot HighMem free:4376912kB min:512kB low:12640kB high:24768kB active:8952kB inactive:7103816kB present:11574272kB pages_scanned:0 all_unreclaimable? no Sep 13 15:31:25 escabot lowmem_reserve[]: 0 0 0 Sep 13 15:31:25 escabot DMA: 4*4kB 3*8kB 0*16kB 0*32kB 1*64kB 1*128kB 1*256kB 0*512kB 1*1024kB 1*2048kB 0*4096kB = 3560kB Sep 13 15:31:25 escabot Normal: 44*4kB 18*8kB 6*16kB 1*32kB 6*64kB 2*128kB 0*256kB 1*512kB 0*1024kB 1*2048kB 0*4096kB = 3648kB Sep 13 15:31:25 escabot HighMem: 107*4kB 42*8kB 39*16kB 37944*32kB 43216*64kB 1640*128kB 15*256kB 253*512kB 35*1024kB 2*2048kB 3*4096kB = 4376940kB Sep 13 15:31:25 escabot Swap cache: add 983, delete 972, find 0/1, race 0+0 Sep 13 15:31:25 escabot Free swap = 2004644kB Sep 13 15:31:25 escabot Total swap = 2008116kB Sep 13 15:31:25 escabot Free swap: 2004644kB Sep 13 15:31:25 escabot 3145727 pages of RAM Sep 13 15:31:25 escabot 2916351 pages of HIGHMEM Sep 13 15:31:25 escabot 69112 reserved pages Sep 13 15:31:25 escabot 1780742 pages shared Sep 13 15:31:25 escabot 11 pages swap cached Sep 13 15:31:25 escabot 10338 pages dirty Sep 13 15:31:25 escabot 0 pages writeback Sep 13 15:31:25 escabot 842 pages mapped Sep 13 15:31:25 escabot 198893 pages slab Sep 13 15:31:25 escabot 92 pages pagetables Sep 13 15:31:25 escabot Out of memory: kill process 5868 (bacula-sd) score 350 or a child Sep 13 15:31:25 escabot Killed process 5868 (bacula-sd) Sep 13 15:31:25 escabot 3145727 pages of RAM Sep 13 15:31:25 escabot 2916351 pages of HIGHMEM Sep 13 15:31:25 escabot 69112 reserved pages Sep 13 15:31:25 escabot 1780407 pages shared Sep 13 15:31:25 escabot 11 pages swap cached Sep 13 15:31:25 escabot 10338 pages dirty Sep 13 15:31:25 escabot 0 pages writeback Sep 13 15:31:25 escabot 842 pages mapped Sep 13 15:31:25 escabot 198893 pages slab Sep 13 15:31:25 escabot 92 pages pagetables Sep 13 15:31:25 escabot Out of memory: kill process 6032 (sshd) score 223 or a child Sep 13 15:31:25 escabot Killed process 6180 (sshd) </quote> -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: VM/VFS bug with large amount of memory and file systems? 2007-09-15 7:27 ` Anton Altaparmakov @ 2007-09-15 10:08 ` Peter Zijlstra -1 siblings, 0 replies; 47+ messages in thread From: Peter Zijlstra @ 2007-09-15 10:08 UTC (permalink / raw) To: Anton Altaparmakov Cc: Linux Kernel Mailing List, Linux Memory Management List, marc.smith On Sat, 2007-09-15 at 08:27 +0100, Anton Altaparmakov wrote: Please, don't word wrap log-files, they're hard enough to read without it :-( ( I see people do this more and more often, *WHY*? is that because we like 80 char lines, in code and email? ) Anyway, looks like all of zone_normal is pinned in kernel allocations: > Sep 13 15:31:25 escabot Normal free:3648kB min:3744kB low:4680kB high: 5616kB active:0kB inactive:3160kB present:894080kB pages_scanned:5336 all_unreclaimable? yes Out of the 870 odd mb only 3 is on the lru. Would be grand it you could have a look at slabinfo and the like. Peter --- > Sep 13 15:31:25 escabot init invoked oom-killer: gfp_mask=0xd0, > order=0, oomkilladj=0 > Sep 13 15:31:25 escabot [<c0149ea8>] out_of_memory+0x158/0x1b0 > Sep 13 15:31:25 escabot [<c014b7b0>] __alloc_pages+0x2a0/0x300 > Sep 13 15:31:25 escabot [<c01729aa>] core_sys_select+0x1fa/0x2f0 > Sep 13 15:31:25 escabot [<c0162a21>] cache_alloc_refill+0x2e1/0x500 > Sep 13 15:31:25 escabot [<c0162736>] kmem_cache_alloc+0x46/0x50 > Sep 13 15:31:25 escabot [<c016e238>] getname+0x28/0xf0 > Sep 13 15:31:25 escabot [<c016fe5e>] __user_walk_fd+0x1e/0x60 > Sep 13 15:31:25 escabot [<c0168e29>] cp_new_stat64+0xf9/0x110 > Sep 13 15:31:25 escabot [<c0169152>] vfs_stat_fd+0x22/0x60 > Sep 13 15:31:25 escabot [<c016922f>] sys_stat64+0xf/0x30 > Sep 13 15:31:25 escabot [<c0124956>] do_gettimeofday+0x36/0xf0 > Sep 13 15:31:25 escabot [<c0120bbf>] sys_time+0xf/0x30 > Sep 13 15:31:25 escabot [<c0102b10>] sysenter_past_esp+0x5d/0x81 > Sep 13 15:31:25 escabot ======================= > Sep 13 15:31:25 escabot Mem-info: > Sep 13 15:31:25 escabot DMA per-cpu: > Sep 13 15:31:25 escabot CPU 0: Hot: hi: 0, btch: 1 usd: 0 > Cold: hi: 0, btch: 1 usd: 0 > Sep 13 15:31:25 escabot CPU 1: Hot: hi: 0, btch: 1 usd: 0 > Cold: hi: 0, btch: 1 usd: 0 > Sep 13 15:31:25 escabot CPU 2: Hot: hi: 0, btch: 1 usd: 0 > Cold: hi: 0, btch: 1 usd: 0 > Sep 13 15:31:25 escabot CPU 3: Hot: hi: 0, btch: 1 usd: 0 > Cold: hi: 0, btch: 1 usd: 0 > Sep 13 15:31:25 escabot Normal per-cpu: > Sep 13 15:31:25 escabot CPU 0: Hot: hi: 186, btch: 31 usd: 143 > Cold: hi: 62, btch: 15 usd: 56 > Sep 13 15:31:25 escabot CPU 1: Hot: hi: 186, btch: 31 usd: 31 > Cold: hi: 62, btch: 15 usd: 53 > Sep 13 15:31:25 escabot CPU 2: Hot: hi: 186, btch: 31 usd: 8 > Cold: hi: 62, btch: 15 usd: 54 > Sep 13 15:31:25 escabot CPU 3: Hot: hi: 186, btch: 31 usd: 99 > Cold: hi: 62, btch: 15 usd: 58 > Sep 13 15:31:25 escabot HighMem per-cpu: > Sep 13 15:31:25 escabot CPU 0: Hot: hi: 186, btch: 31 usd: 1 > Cold: hi: 62, btch: 15 usd: 10 > Sep 13 15:31:25 escabot CPU 1: Hot: hi: 186, btch: 31 usd: 23 > Cold: hi: 62, btch: 15 usd: 1 > Sep 13 15:31:25 escabot CPU 2: Hot: hi: 186, btch: 31 usd: 18 > Cold: hi: 62, btch: 15 usd: 1 > Sep 13 15:31:25 escabot CPU 3: Hot: hi: 186, btch: 31 usd: 9 > Cold: hi: 62, btch: 15 usd: 12 > Sep 13 15:31:25 escabot Active:8078 inactive:1776744 dirty:10338 > writeback:0 unstable:0 > Sep 13 15:31:25 escabot free:1090395 slab:198893 mapped:988 > pagetables:129 bounce:0 > Sep 13 15:31:25 escabot DMA free:3560kB min:68kB low:84kB high:100kB > active:0kB inactive:0kB present:16256kB pages_scanned:0 > all_unreclaimable? yes > Sep 13 15:31:25 escabot lowmem_reserve[]: 0 873 12176 > Sep 13 15:31:25 escabot Normal free:3648kB min:3744kB low:4680kB high: > 5616kB active:0kB inactive:3160kB present:894080kB pages_scanned:5336 > all_unreclaimable? yes > Sep 13 15:31:25 escabot lowmem_reserve[]: 0 0 90424 > Sep 13 15:31:25 escabot HighMem free:4354372kB min:512kB low:12640kB > high:24768kB active:32312kB inactive:7103816kB present:11574272kB > pages_scanned:0 all_unreclaimable? no > Sep 13 15:31:25 escabot lowmem_reserve[]: 0 0 0 > Sep 13 15:31:25 escabot DMA: 4*4kB 3*8kB 0*16kB 0*32kB 1*64kB 1*128kB > 1*256kB 0*512kB 1*1024kB 1*2048kB 0*4096kB = 3560kB > Sep 13 15:31:25 escabot Normal: 44*4kB 18*8kB 6*16kB 1*32kB 6*64kB > 2*128kB 0*256kB 1*512kB 0*1024kB 1*2048kB 0*4096kB = 3648kB > Sep 13 15:31:25 escabot HighMem: 1*4kB 0*8kB 0*16kB 37914*32kB > 43188*64kB 1628*128kB 5*256kB 247*512kB 30*1024kB 1*2048kB 2*4096kB = > 4354372kB > Sep 13 15:31:25 escabot Swap cache: add 983, delete 972, find 0/1, > race 0+0 > Sep 13 15:31:25 escabot Free swap = 2004216kB > Sep 13 15:31:25 escabot Total swap = 2008116kB > Sep 13 15:31:25 escabot Free swap: 2004216kB ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: VM/VFS bug with large amount of memory and file systems? @ 2007-09-15 10:08 ` Peter Zijlstra 0 siblings, 0 replies; 47+ messages in thread From: Peter Zijlstra @ 2007-09-15 10:08 UTC (permalink / raw) To: Anton Altaparmakov Cc: Linux Kernel Mailing List, Linux Memory Management List, marc.smith On Sat, 2007-09-15 at 08:27 +0100, Anton Altaparmakov wrote: Please, don't word wrap log-files, they're hard enough to read without it :-( ( I see people do this more and more often, *WHY*? is that because we like 80 char lines, in code and email? ) Anyway, looks like all of zone_normal is pinned in kernel allocations: > Sep 13 15:31:25 escabot Normal free:3648kB min:3744kB low:4680kB high: 5616kB active:0kB inactive:3160kB present:894080kB pages_scanned:5336 all_unreclaimable? yes Out of the 870 odd mb only 3 is on the lru. Would be grand it you could have a look at slabinfo and the like. Peter --- > Sep 13 15:31:25 escabot init invoked oom-killer: gfp_mask=0xd0, > order=0, oomkilladj=0 > Sep 13 15:31:25 escabot [<c0149ea8>] out_of_memory+0x158/0x1b0 > Sep 13 15:31:25 escabot [<c014b7b0>] __alloc_pages+0x2a0/0x300 > Sep 13 15:31:25 escabot [<c01729aa>] core_sys_select+0x1fa/0x2f0 > Sep 13 15:31:25 escabot [<c0162a21>] cache_alloc_refill+0x2e1/0x500 > Sep 13 15:31:25 escabot [<c0162736>] kmem_cache_alloc+0x46/0x50 > Sep 13 15:31:25 escabot [<c016e238>] getname+0x28/0xf0 > Sep 13 15:31:25 escabot [<c016fe5e>] __user_walk_fd+0x1e/0x60 > Sep 13 15:31:25 escabot [<c0168e29>] cp_new_stat64+0xf9/0x110 > Sep 13 15:31:25 escabot [<c0169152>] vfs_stat_fd+0x22/0x60 > Sep 13 15:31:25 escabot [<c016922f>] sys_stat64+0xf/0x30 > Sep 13 15:31:25 escabot [<c0124956>] do_gettimeofday+0x36/0xf0 > Sep 13 15:31:25 escabot [<c0120bbf>] sys_time+0xf/0x30 > Sep 13 15:31:25 escabot [<c0102b10>] sysenter_past_esp+0x5d/0x81 > Sep 13 15:31:25 escabot ======================= > Sep 13 15:31:25 escabot Mem-info: > Sep 13 15:31:25 escabot DMA per-cpu: > Sep 13 15:31:25 escabot CPU 0: Hot: hi: 0, btch: 1 usd: 0 > Cold: hi: 0, btch: 1 usd: 0 > Sep 13 15:31:25 escabot CPU 1: Hot: hi: 0, btch: 1 usd: 0 > Cold: hi: 0, btch: 1 usd: 0 > Sep 13 15:31:25 escabot CPU 2: Hot: hi: 0, btch: 1 usd: 0 > Cold: hi: 0, btch: 1 usd: 0 > Sep 13 15:31:25 escabot CPU 3: Hot: hi: 0, btch: 1 usd: 0 > Cold: hi: 0, btch: 1 usd: 0 > Sep 13 15:31:25 escabot Normal per-cpu: > Sep 13 15:31:25 escabot CPU 0: Hot: hi: 186, btch: 31 usd: 143 > Cold: hi: 62, btch: 15 usd: 56 > Sep 13 15:31:25 escabot CPU 1: Hot: hi: 186, btch: 31 usd: 31 > Cold: hi: 62, btch: 15 usd: 53 > Sep 13 15:31:25 escabot CPU 2: Hot: hi: 186, btch: 31 usd: 8 > Cold: hi: 62, btch: 15 usd: 54 > Sep 13 15:31:25 escabot CPU 3: Hot: hi: 186, btch: 31 usd: 99 > Cold: hi: 62, btch: 15 usd: 58 > Sep 13 15:31:25 escabot HighMem per-cpu: > Sep 13 15:31:25 escabot CPU 0: Hot: hi: 186, btch: 31 usd: 1 > Cold: hi: 62, btch: 15 usd: 10 > Sep 13 15:31:25 escabot CPU 1: Hot: hi: 186, btch: 31 usd: 23 > Cold: hi: 62, btch: 15 usd: 1 > Sep 13 15:31:25 escabot CPU 2: Hot: hi: 186, btch: 31 usd: 18 > Cold: hi: 62, btch: 15 usd: 1 > Sep 13 15:31:25 escabot CPU 3: Hot: hi: 186, btch: 31 usd: 9 > Cold: hi: 62, btch: 15 usd: 12 > Sep 13 15:31:25 escabot Active:8078 inactive:1776744 dirty:10338 > writeback:0 unstable:0 > Sep 13 15:31:25 escabot free:1090395 slab:198893 mapped:988 > pagetables:129 bounce:0 > Sep 13 15:31:25 escabot DMA free:3560kB min:68kB low:84kB high:100kB > active:0kB inactive:0kB present:16256kB pages_scanned:0 > all_unreclaimable? yes > Sep 13 15:31:25 escabot lowmem_reserve[]: 0 873 12176 > Sep 13 15:31:25 escabot Normal free:3648kB min:3744kB low:4680kB high: > 5616kB active:0kB inactive:3160kB present:894080kB pages_scanned:5336 > all_unreclaimable? yes > Sep 13 15:31:25 escabot lowmem_reserve[]: 0 0 90424 > Sep 13 15:31:25 escabot HighMem free:4354372kB min:512kB low:12640kB > high:24768kB active:32312kB inactive:7103816kB present:11574272kB > pages_scanned:0 all_unreclaimable? no > Sep 13 15:31:25 escabot lowmem_reserve[]: 0 0 0 > Sep 13 15:31:25 escabot DMA: 4*4kB 3*8kB 0*16kB 0*32kB 1*64kB 1*128kB > 1*256kB 0*512kB 1*1024kB 1*2048kB 0*4096kB = 3560kB > Sep 13 15:31:25 escabot Normal: 44*4kB 18*8kB 6*16kB 1*32kB 6*64kB > 2*128kB 0*256kB 1*512kB 0*1024kB 1*2048kB 0*4096kB = 3648kB > Sep 13 15:31:25 escabot HighMem: 1*4kB 0*8kB 0*16kB 37914*32kB > 43188*64kB 1628*128kB 5*256kB 247*512kB 30*1024kB 1*2048kB 2*4096kB = > 4354372kB > Sep 13 15:31:25 escabot Swap cache: add 983, delete 972, find 0/1, > race 0+0 > Sep 13 15:31:25 escabot Free swap = 2004216kB > Sep 13 15:31:25 escabot Total swap = 2008116kB > Sep 13 15:31:25 escabot Free swap: 2004216kB -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: VM/VFS bug with large amount of memory and file systems? 2007-09-15 10:08 ` Peter Zijlstra @ 2007-09-15 10:50 ` Anton Altaparmakov -1 siblings, 0 replies; 47+ messages in thread From: Anton Altaparmakov @ 2007-09-15 10:50 UTC (permalink / raw) To: marc.smith, Peter Zijlstra Cc: Linux Kernel Mailing List, Linux Memory Management List Hi, Thanks for looking into this. On 15 Sep 2007, at 11:08, Peter Zijlstra wrote: > On Sat, 2007-09-15 at 08:27 +0100, Anton Altaparmakov wrote: > > Please, don't word wrap log-files, they're hard enough to read without > it :-( > > ( I see people do this more and more often, *WHY*? is that because we > like 80 char lines, in code and email? ) I haven't word wrapped it at all. The lines appear as whole lines in Apple Mail (my email client). It must be your email client that is wrapping them... > Anyway, looks like all of zone_normal is pinned in kernel allocations: > >> Sep 13 15:31:25 escabot Normal free:3648kB min:3744kB low:4680kB >> high: 5616kB active:0kB inactive:3160kB present:894080kB >> pages_scanned:5336 all_unreclaimable? yes > > Out of the 870 odd mb only 3 is on the lru. > > Would be grand it you could have a look at slabinfo and the like. Ok, Marc, would you be able to do the copy to /dev/null again (booted without the ram=2G option) and when you see that most of the memory has gone run: cat /proc/slabinfo > slabinfo.txt cat /proc/meminfo > meminfo.txt cat /proc/vmstat > vmstat.txt cat /proc/zoneinfo > zoneinfo.txt Then quickly abort the copy with "Ctrl+C" so hopefully you will not get a kernel panic... Please send the content of the generated files. Thanks. That should hopefully show what in the kernel has eaten all the low memory... Best regards, Anton -- Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @) Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK Linux NTFS maintainer, http://www.linux-ntfs.org/ ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: VM/VFS bug with large amount of memory and file systems? @ 2007-09-15 10:50 ` Anton Altaparmakov 0 siblings, 0 replies; 47+ messages in thread From: Anton Altaparmakov @ 2007-09-15 10:50 UTC (permalink / raw) To: marc.smith, Peter Zijlstra Cc: Linux Kernel Mailing List, Linux Memory Management List Hi, Thanks for looking into this. On 15 Sep 2007, at 11:08, Peter Zijlstra wrote: > On Sat, 2007-09-15 at 08:27 +0100, Anton Altaparmakov wrote: > > Please, don't word wrap log-files, they're hard enough to read without > it :-( > > ( I see people do this more and more often, *WHY*? is that because we > like 80 char lines, in code and email? ) I haven't word wrapped it at all. The lines appear as whole lines in Apple Mail (my email client). It must be your email client that is wrapping them... > Anyway, looks like all of zone_normal is pinned in kernel allocations: > >> Sep 13 15:31:25 escabot Normal free:3648kB min:3744kB low:4680kB >> high: 5616kB active:0kB inactive:3160kB present:894080kB >> pages_scanned:5336 all_unreclaimable? yes > > Out of the 870 odd mb only 3 is on the lru. > > Would be grand it you could have a look at slabinfo and the like. Ok, Marc, would you be able to do the copy to /dev/null again (booted without the ram=2G option) and when you see that most of the memory has gone run: cat /proc/slabinfo > slabinfo.txt cat /proc/meminfo > meminfo.txt cat /proc/vmstat > vmstat.txt cat /proc/zoneinfo > zoneinfo.txt Then quickly abort the copy with "Ctrl+C" so hopefully you will not get a kernel panic... Please send the content of the generated files. Thanks. That should hopefully show what in the kernel has eaten all the low memory... Best regards, Anton -- Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @) Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK Linux NTFS maintainer, http://www.linux-ntfs.org/ -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: VM/VFS bug with large amount of memory and file systems? 2007-09-15 10:50 ` Anton Altaparmakov @ 2007-09-15 11:19 ` Peter Zijlstra -1 siblings, 0 replies; 47+ messages in thread From: Peter Zijlstra @ 2007-09-15 11:19 UTC (permalink / raw) To: Anton Altaparmakov Cc: marc.smith, Linux Kernel Mailing List, Linux Memory Management List On Sat, 2007-09-15 at 11:50 +0100, Anton Altaparmakov wrote: > Hi, > > Thanks for looking into this. > > On 15 Sep 2007, at 11:08, Peter Zijlstra wrote: > > On Sat, 2007-09-15 at 08:27 +0100, Anton Altaparmakov wrote: > > > > Please, don't word wrap log-files, they're hard enough to read without > > it :-( > > > > ( I see people do this more and more often, *WHY*? is that because we > > like 80 char lines, in code and email? ) > > I haven't word wrapped it at all. The lines appear as whole lines in > Apple Mail (my email client). It must be your email client that is > wrapping them... > > > Anyway, looks like all of zone_normal is pinned in kernel allocations: > > > >> Sep 13 15:31:25 escabot Normal free:3648kB min:3744kB low:4680kB > >> high: 5616kB active:0kB inactive:3160kB present:894080kB > >> pages_scanned:5336 all_unreclaimable? yes > > Oddly, this line is still long in Andrew's reply but wrapped in yours. Must be some odd mailer interaction. /me apologises. I guess I really have to start looking for a hackable GUI email client that has semi proper IMAP support. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: VM/VFS bug with large amount of memory and file systems? @ 2007-09-15 11:19 ` Peter Zijlstra 0 siblings, 0 replies; 47+ messages in thread From: Peter Zijlstra @ 2007-09-15 11:19 UTC (permalink / raw) To: Anton Altaparmakov Cc: marc.smith, Linux Kernel Mailing List, Linux Memory Management List On Sat, 2007-09-15 at 11:50 +0100, Anton Altaparmakov wrote: > Hi, > > Thanks for looking into this. > > On 15 Sep 2007, at 11:08, Peter Zijlstra wrote: > > On Sat, 2007-09-15 at 08:27 +0100, Anton Altaparmakov wrote: > > > > Please, don't word wrap log-files, they're hard enough to read without > > it :-( > > > > ( I see people do this more and more often, *WHY*? is that because we > > like 80 char lines, in code and email? ) > > I haven't word wrapped it at all. The lines appear as whole lines in > Apple Mail (my email client). It must be your email client that is > wrapping them... > > > Anyway, looks like all of zone_normal is pinned in kernel allocations: > > > >> Sep 13 15:31:25 escabot Normal free:3648kB min:3744kB low:4680kB > >> high: 5616kB active:0kB inactive:3160kB present:894080kB > >> pages_scanned:5336 all_unreclaimable? yes > > Oddly, this line is still long in Andrew's reply but wrapped in yours. Must be some odd mailer interaction. /me apologises. I guess I really have to start looking for a hackable GUI email client that has semi proper IMAP support. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: VM/VFS bug with large amount of memory and file systems? 2007-09-15 11:19 ` Peter Zijlstra @ 2007-09-16 7:22 ` Kyle Moffett -1 siblings, 0 replies; 47+ messages in thread From: Kyle Moffett @ 2007-09-16 7:22 UTC (permalink / raw) To: Peter Zijlstra Cc: Anton Altaparmakov, marc.smith, Linux Kernel Mailing List, Linux Memory Management List On Sep 15, 2007, at 07:19:01, Peter Zijlstra wrote: > On Sat, 2007-09-15 at 11:50 +0100, Anton Altaparmakov wrote: >> I haven't word wrapped it at all. The lines appear as whole lines >> in Apple Mail (my email client). It must be your email client >> that is wrapping them... > > Oddly, this line is still long in Andrew's reply but wrapped in > yours. Must be some odd mailer interaction. Actually Apple Mail.app sends format=flowed wrapped to 73 characters. So a wrapped line has a single space character right before each 'wrapping' newline. If your mail client supports format=flowed viewing and sends without format=flowed (like AKPM's mailer appears to), then it will properly unwrap the lines and resend without the wrapping. Mailers which *DONT* support format=flowed will see the wrapped version. Normally this is what you want but it's a PITA for patches and logfiles. I believe with Mail.app if you attach a .txt file it will be unmangled and sent as "Content-Type: text/plain" and "Content- Disposition: inline", so most email-clients will display it as part of the message. Cheers, Kyle Moffett ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: VM/VFS bug with large amount of memory and file systems? @ 2007-09-16 7:22 ` Kyle Moffett 0 siblings, 0 replies; 47+ messages in thread From: Kyle Moffett @ 2007-09-16 7:22 UTC (permalink / raw) To: Peter Zijlstra Cc: Anton Altaparmakov, marc.smith, Linux Kernel Mailing List, Linux Memory Management List On Sep 15, 2007, at 07:19:01, Peter Zijlstra wrote: > On Sat, 2007-09-15 at 11:50 +0100, Anton Altaparmakov wrote: >> I haven't word wrapped it at all. The lines appear as whole lines >> in Apple Mail (my email client). It must be your email client >> that is wrapping them... > > Oddly, this line is still long in Andrew's reply but wrapped in > yours. Must be some odd mailer interaction. Actually Apple Mail.app sends format=flowed wrapped to 73 characters. So a wrapped line has a single space character right before each 'wrapping' newline. If your mail client supports format=flowed viewing and sends without format=flowed (like AKPM's mailer appears to), then it will properly unwrap the lines and resend without the wrapping. Mailers which *DONT* support format=flowed will see the wrapped version. Normally this is what you want but it's a PITA for patches and logfiles. I believe with Mail.app if you attach a .txt file it will be unmangled and sent as "Content-Type: text/plain" and "Content- Disposition: inline", so most email-clients will display it as part of the message. Cheers, Kyle Moffett -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: VM/VFS bug with large amount of memory and file systems? 2007-09-16 7:22 ` Kyle Moffett @ 2007-09-16 16:16 ` Peter Zijlstra -1 siblings, 0 replies; 47+ messages in thread From: Peter Zijlstra @ 2007-09-16 16:16 UTC (permalink / raw) To: Kyle Moffett Cc: Anton Altaparmakov, marc.smith, Linux Kernel Mailing List, Linux Memory Management List On Sun, 16 Sep 2007 03:22:11 -0400 Kyle Moffett <mrmacman_g4@mac.com> wrote: > On Sep 15, 2007, at 07:19:01, Peter Zijlstra wrote: > > On Sat, 2007-09-15 at 11:50 +0100, Anton Altaparmakov wrote: > >> I haven't word wrapped it at all. The lines appear as whole lines > >> in Apple Mail (my email client). It must be your email client > >> that is wrapping them... > > > > Oddly, this line is still long in Andrew's reply but wrapped in > > yours. Must be some odd mailer interaction. > > Actually Apple Mail.app sends format=flowed wrapped to 73 > characters. So a wrapped line has a single space character right > before each 'wrapping' newline. If your mail client supports > format=flowed viewing and sends without format=flowed (like AKPM's > mailer appears to), then it will properly unwrap the lines and resend > without the wrapping. Mailers which *DONT* support format=flowed > will see the wrapped version. Normally this is what you want but > it's a PITA for patches and logfiles. > > I believe with Mail.app if you attach a .txt file it will be > unmangled and sent as "Content-Type: text/plain" and "Content- > Disposition: inline", so most email-clients will display it as part > of the message. Ah, thanks for the hint. I've switched mailer to claws-mail-3.0.0 and hacked the thing a bit so its useful. One of the things I added was a menu entry for respect_flowed_format. So I can now flip between flowed and non-flowed with a key. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: VM/VFS bug with large amount of memory and file systems? @ 2007-09-16 16:16 ` Peter Zijlstra 0 siblings, 0 replies; 47+ messages in thread From: Peter Zijlstra @ 2007-09-16 16:16 UTC (permalink / raw) To: Kyle Moffett Cc: Anton Altaparmakov, marc.smith, Linux Kernel Mailing List, Linux Memory Management List On Sun, 16 Sep 2007 03:22:11 -0400 Kyle Moffett <mrmacman_g4@mac.com> wrote: > On Sep 15, 2007, at 07:19:01, Peter Zijlstra wrote: > > On Sat, 2007-09-15 at 11:50 +0100, Anton Altaparmakov wrote: > >> I haven't word wrapped it at all. The lines appear as whole lines > >> in Apple Mail (my email client). It must be your email client > >> that is wrapping them... > > > > Oddly, this line is still long in Andrew's reply but wrapped in > > yours. Must be some odd mailer interaction. > > Actually Apple Mail.app sends format=flowed wrapped to 73 > characters. So a wrapped line has a single space character right > before each 'wrapping' newline. If your mail client supports > format=flowed viewing and sends without format=flowed (like AKPM's > mailer appears to), then it will properly unwrap the lines and resend > without the wrapping. Mailers which *DONT* support format=flowed > will see the wrapped version. Normally this is what you want but > it's a PITA for patches and logfiles. > > I believe with Mail.app if you attach a .txt file it will be > unmangled and sent as "Content-Type: text/plain" and "Content- > Disposition: inline", so most email-clients will display it as part > of the message. Ah, thanks for the hint. I've switched mailer to claws-mail-3.0.0 and hacked the thing a bit so its useful. One of the things I added was a menu entry for respect_flowed_format. So I can now flip between flowed and non-flowed with a key. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: VM/VFS bug with large amount of memory and file systems? 2007-09-15 10:08 ` Peter Zijlstra @ 2007-09-15 10:52 ` Andrew Morton -1 siblings, 0 replies; 47+ messages in thread From: Andrew Morton @ 2007-09-15 10:52 UTC (permalink / raw) To: Peter Zijlstra Cc: Anton Altaparmakov, Linux Kernel Mailing List, Linux Memory Management List, marc.smith On Sat, 15 Sep 2007 12:08:17 +0200 Peter Zijlstra <peterz@infradead.org> wrote: > On Sat, 2007-09-15 at 08:27 +0100, Anton Altaparmakov wrote: > > Please, don't word wrap log-files, they're hard enough to read without > it :-( > > ( I see people do this more and more often, *WHY*? is that because we > like 80 char lines, in code and email? ) Isn't it? > > Anyway, looks like all of zone_normal is pinned in kernel allocations: > > > Sep 13 15:31:25 escabot Normal free:3648kB min:3744kB low:4680kB high: 5616kB active:0kB inactive:3160kB present:894080kB pages_scanned:5336 all_unreclaimable? yes > > Out of the 870 odd mb only 3 is on the lru. > > Would be grand it you could have a look at slabinfo and the like. Definitely. > > Sep 13 15:31:25 escabot free:1090395 slab:198893 mapped:988 > > pagetables:129 bounce:0 814,665,728 bytes of slab. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: VM/VFS bug with large amount of memory and file systems? @ 2007-09-15 10:52 ` Andrew Morton 0 siblings, 0 replies; 47+ messages in thread From: Andrew Morton @ 2007-09-15 10:52 UTC (permalink / raw) To: Peter Zijlstra Cc: Anton Altaparmakov, Linux Kernel Mailing List, Linux Memory Management List, marc.smith On Sat, 15 Sep 2007 12:08:17 +0200 Peter Zijlstra <peterz@infradead.org> wrote: > On Sat, 2007-09-15 at 08:27 +0100, Anton Altaparmakov wrote: > > Please, don't word wrap log-files, they're hard enough to read without > it :-( > > ( I see people do this more and more often, *WHY*? is that because we > like 80 char lines, in code and email? ) Isn't it? > > Anyway, looks like all of zone_normal is pinned in kernel allocations: > > > Sep 13 15:31:25 escabot Normal free:3648kB min:3744kB low:4680kB high: 5616kB active:0kB inactive:3160kB present:894080kB pages_scanned:5336 all_unreclaimable? yes > > Out of the 870 odd mb only 3 is on the lru. > > Would be grand it you could have a look at slabinfo and the like. Definitely. > > Sep 13 15:31:25 escabot free:1090395 slab:198893 mapped:988 > > pagetables:129 bounce:0 814,665,728 bytes of slab. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: VM/VFS bug with large amount of memory and file systems? 2007-09-15 10:52 ` Andrew Morton (?) @ 2007-09-17 14:04 ` Anton Altaparmakov 2007-09-17 14:09 ` Anton Altaparmakov 2007-09-17 14:32 ` Peter Zijlstra -1 siblings, 2 replies; 47+ messages in thread From: Anton Altaparmakov @ 2007-09-17 14:04 UTC (permalink / raw) To: Andrew Morton, Peter Zijlstra Cc: Linux Kernel Mailing List, Linux Memory Management List, marc.smith [-- Attachment #1: Type: text/plain, Size: 1999 bytes --] On 15 Sep 2007, at 11:52, Andrew Morton wrote: > On Sat, 15 Sep 2007 12:08:17 +0200 Peter Zijlstra > <peterz@infradead.org> wrote: >> Anyway, looks like all of zone_normal is pinned in kernel >> allocations: >> >>> Sep 13 15:31:25 escabot Normal free:3648kB min:3744kB low:4680kB >>> high: 5616kB active:0kB inactive:3160kB present:894080kB >>> pages_scanned:5336 all_unreclaimable? yes >> >> Out of the 870 odd mb only 3 is on the lru. >> >> Would be grand it you could have a look at slabinfo and the like. > > Definitely. > >>> Sep 13 15:31:25 escabot free:1090395 slab:198893 mapped:988 >>> pagetables:129 bounce:0 > > 814,665,728 bytes of slab. Marc emailed me the contents of /proc/ {slabinfo,meminfo,vmstat,zoneinfo} taken just a few seconds before the machine panic()ed due to running OOM completely... They files are attached this time rather than inlined so people don't complain about line wrapping! (No doubt people will not complain about them being attached! )-:) If I read it correctly it appears all of low memory is eaten up by buffer_heads. <quote> # name <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab> : tunables <limit> <batchcount> <sharedfactor> : slabdata <active_slabs> <num_s labs> <sharedavail> buffer_head 12569528 12569535 56 67 1 : tunables 120 60 8 : slabdata 187605 187605 0 </quote> That is 671MiB of low memory in buffer_heads. But why is the kernel not reclaiming them by getting rid of the page cache pages they are attached to or even leaving the pages around but killing their buffers? I don't think I am doing anything in NTFS to cause this problem to happen... Other than using buffer heads for my page cache pages that is but that is hardly a crime! /-; Best regards, Anton -- Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @) Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK Linux NTFS maintainer, http://www.linux-ntfs.org/ [-- Attachment #2: slabinfo.txt --] [-- Type: text/plain, Size: 16276 bytes --] slabinfo - version: 2.1 # name <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab> : tunables <limit> <batchcount> <sharedfactor> : slabdata <active_slabs> <num_slabs> <sharedavail> jbd_4k 0 0 4096 1 1 : tunables 24 12 8 : slabdata 0 0 0 scsi_cmd_cache 48 48 320 12 1 : tunables 54 27 8 : slabdata 4 4 0 qla2xxx_srbs 283 330 128 30 1 : tunables 120 60 8 : slabdata 11 11 0 rpc_buffers 8 8 2048 2 1 : tunables 24 12 8 : slabdata 4 4 0 rpc_tasks 8 20 192 20 1 : tunables 120 60 8 : slabdata 1 1 0 rpc_inode_cache 0 0 448 9 1 : tunables 54 27 8 : slabdata 0 0 0 UNIX 4 27 448 9 1 : tunables 54 27 8 : slabdata 3 3 0 flow_cache 0 0 128 30 1 : tunables 120 60 8 : slabdata 0 0 0 cfq_ioc_pool 0 0 88 44 1 : tunables 120 60 8 : slabdata 0 0 0 cfq_pool 0 0 96 40 1 : tunables 120 60 8 : slabdata 0 0 0 mqueue_inode_cache 1 7 576 7 1 : tunables 54 27 8 : slabdata 1 1 0 xfs_chashlist 0 0 24 145 1 : tunables 120 60 8 : slabdata 0 0 0 xfs_ili 0 0 140 28 1 : tunables 120 60 8 : slabdata 0 0 0 xfs_inode 0 0 448 9 1 : tunables 54 27 8 : slabdata 0 0 0 xfs_efi_item 0 0 260 15 1 : tunables 54 27 8 : slabdata 0 0 0 xfs_efd_item 0 0 260 15 1 : tunables 54 27 8 : slabdata 0 0 0 xfs_buf_item 0 0 148 26 1 : tunables 120 60 8 : slabdata 0 0 0 xfs_acl 0 0 304 13 1 : tunables 54 27 8 : slabdata 0 0 0 xfs_ifork 0 0 56 67 1 : tunables 120 60 8 : slabdata 0 0 0 xfs_dabuf 0 0 16 203 1 : tunables 120 60 8 : slabdata 0 0 0 xfs_da_state 0 0 336 11 1 : tunables 54 27 8 : slabdata 0 0 0 xfs_trans 0 0 636 6 1 : tunables 54 27 8 : slabdata 0 0 0 xfs_btree_cur 0 0 140 28 1 : tunables 120 60 8 : slabdata 0 0 0 xfs_bmap_free_item 0 0 16 203 1 : tunables 120 60 8 : slabdata 0 0 0 xfs_buf 0 0 256 15 1 : tunables 120 60 8 : slabdata 0 0 0 xfs_ioend 32 67 56 67 1 : tunables 120 60 8 : slabdata 1 1 0 xfs_vnode 0 0 384 10 1 : tunables 54 27 8 : slabdata 0 0 0 udf_inode_cache 0 0 404 9 1 : tunables 54 27 8 : slabdata 0 0 0 ntfs_big_inode_cache 23 28 576 7 1 : tunables 54 27 8 : slabdata 4 4 0 ntfs_inode_cache 0 0 184 21 1 : tunables 120 60 8 : slabdata 0 0 0 ntfs_name_cache 0 0 512 8 1 : tunables 54 27 8 : slabdata 0 0 0 ntfs_attr_ctx_cache 0 0 32 113 1 : tunables 120 60 8 : slabdata 0 0 0 ntfs_index_ctx_cache 0 0 64 59 1 : tunables 120 60 8 : slabdata 0 0 0 nfs_write_data 36 36 448 9 1 : tunables 54 27 8 : slabdata 4 4 0 nfs_read_data 32 36 448 9 1 : tunables 54 27 8 : slabdata 4 4 0 nfs_inode_cache 0 0 612 6 1 : tunables 54 27 8 : slabdata 0 0 0 nfs_page 0 0 64 59 1 : tunables 120 60 8 : slabdata 0 0 0 isofs_inode_cache 0 0 376 10 1 : tunables 54 27 8 : slabdata 0 0 0 fat_inode_cache 0 0 408 9 1 : tunables 54 27 8 : slabdata 0 0 0 fat_cache 0 0 20 169 1 : tunables 120 60 8 : slabdata 0 0 0 ext2_inode_cache 2 16 464 8 1 : tunables 54 27 8 : slabdata 2 2 0 journal_handle 32 169 20 169 1 : tunables 120 60 8 : slabdata 1 1 0 journal_head 40 72 52 72 1 : tunables 120 60 8 : slabdata 1 1 0 revoke_table 4 254 12 254 1 : tunables 120 60 8 : slabdata 1 1 0 revoke_record 0 0 16 203 1 : tunables 120 60 8 : slabdata 0 0 0 ext3_inode_cache 324 368 500 8 1 : tunables 54 27 8 : slabdata 46 46 0 ext3_xattr 0 0 48 78 1 : tunables 120 60 8 : slabdata 0 0 0 reiser_inode_cache 0 0 452 8 1 : tunables 54 27 8 : slabdata 0 0 0 dnotify_cache 0 0 20 169 1 : tunables 120 60 8 : slabdata 0 0 0 eventpoll_pwq 0 0 36 101 1 : tunables 120 60 8 : slabdata 0 0 0 eventpoll_epi 0 0 128 30 1 : tunables 120 60 8 : slabdata 0 0 0 inotify_event_cache 0 0 28 127 1 : tunables 120 60 8 : slabdata 0 0 0 inotify_watch_cache 1 92 40 92 1 : tunables 120 60 8 : slabdata 1 1 0 kioctx 0 0 192 20 1 : tunables 120 60 8 : slabdata 0 0 0 kiocb 0 0 192 20 1 : tunables 120 60 8 : slabdata 0 0 0 fasync_cache 0 0 16 203 1 : tunables 120 60 8 : slabdata 0 0 0 shmem_inode_cache 1443 1476 448 9 1 : tunables 54 27 8 : slabdata 164 164 0 posix_timers_cache 0 0 96 40 1 : tunables 120 60 8 : slabdata 0 0 0 uid_cache 0 0 64 59 1 : tunables 120 60 8 : slabdata 0 0 0 UDP-Lite 0 0 576 7 1 : tunables 54 27 8 : slabdata 0 0 0 tcp_bind_bucket 1 203 16 203 1 : tunables 120 60 8 : slabdata 1 1 0 inet_peer_cache 0 0 64 59 1 : tunables 120 60 8 : slabdata 0 0 0 secpath_cache 0 0 32 113 1 : tunables 120 60 8 : slabdata 0 0 0 xfrm_dst_cache 0 0 256 15 1 : tunables 120 60 8 : slabdata 0 0 0 ip_fib_alias 14 113 32 113 1 : tunables 120 60 8 : slabdata 1 1 0 ip_fib_hash 14 113 32 113 1 : tunables 120 60 8 : slabdata 1 1 0 ip_dst_cache 10 30 256 15 1 : tunables 120 60 8 : slabdata 2 2 0 arp_cache 3 20 192 20 1 : tunables 120 60 8 : slabdata 1 1 0 RAW 5 7 512 7 1 : tunables 54 27 8 : slabdata 1 1 0 UDP 0 0 576 7 1 : tunables 54 27 8 : slabdata 0 0 0 tw_sock_TCP 0 0 128 30 1 : tunables 120 60 8 : slabdata 0 0 0 request_sock_TCP 0 0 64 59 1 : tunables 120 60 8 : slabdata 0 0 0 TCP 4 7 1152 7 2 : tunables 24 12 8 : slabdata 1 1 0 sgpool-128 39 42 2560 3 2 : tunables 24 12 8 : slabdata 14 14 0 sgpool-64 44 51 1280 3 1 : tunables 24 12 8 : slabdata 16 17 0 sgpool-32 34 54 640 6 1 : tunables 54 27 8 : slabdata 8 9 0 sgpool-16 57 60 320 12 1 : tunables 54 27 8 : slabdata 5 5 0 sgpool-8 57 80 192 20 1 : tunables 120 60 8 : slabdata 3 4 0 scsi_io_context 0 0 104 37 1 : tunables 120 60 8 : slabdata 0 0 0 blkdev_ioc 31 127 28 127 1 : tunables 120 60 8 : slabdata 1 1 0 blkdev_queue 32 32 956 4 1 : tunables 54 27 8 : slabdata 8 8 0 blkdev_requests 100 126 184 21 1 : tunables 120 60 8 : slabdata 6 6 0 biovec-256 7 8 3072 2 2 : tunables 24 12 8 : slabdata 4 4 0 biovec-128 7 10 1536 5 2 : tunables 24 12 8 : slabdata 2 2 0 biovec-64 7 10 768 5 1 : tunables 54 27 8 : slabdata 2 2 0 biovec-16 7 20 192 20 1 : tunables 120 60 8 : slabdata 1 1 0 biovec-4 7 59 64 59 1 : tunables 120 60 8 : slabdata 1 1 0 biovec-1 596 812 16 203 1 : tunables 120 60 8 : slabdata 4 4 0 bio 862 1110 128 30 1 : tunables 120 60 8 : slabdata 37 37 0 sock_inode_cache 23 45 448 9 1 : tunables 54 27 8 : slabdata 5 5 0 skbuff_fclone_cache 24 24 320 12 1 : tunables 54 27 8 : slabdata 2 2 0 skbuff_head_cache 461 580 192 20 1 : tunables 120 60 8 : slabdata 29 29 0 file_lock_cache 15 39 100 39 1 : tunables 120 60 8 : slabdata 1 1 0 Acpi-Operand 1107 1196 40 92 1 : tunables 120 60 8 : slabdata 13 13 0 Acpi-ParseExt 0 0 44 84 1 : tunables 120 60 8 : slabdata 0 0 0 Acpi-Parse 0 0 28 127 1 : tunables 120 60 8 : slabdata 0 0 0 Acpi-State 0 0 44 84 1 : tunables 120 60 8 : slabdata 0 0 0 Acpi-Namespace 797 845 20 169 1 : tunables 120 60 8 : slabdata 5 5 0 proc_inode_cache 418 418 364 11 1 : tunables 54 27 8 : slabdata 38 38 0 sigqueue 0 0 144 27 1 : tunables 120 60 8 : slabdata 0 0 0 radix_tree_node 25298 25298 288 13 1 : tunables 54 27 8 : slabdata 1946 1946 0 bdev_cache 10 21 512 7 1 : tunables 54 27 8 : slabdata 3 3 0 sysfs_dir_cache 7276 7308 44 84 1 : tunables 120 60 8 : slabdata 87 87 0 mnt_cache 25 90 128 30 1 : tunables 120 60 8 : slabdata 3 3 0 inode_cache 1968 2057 348 11 1 : tunables 54 27 8 : slabdata 187 187 0 dentry_cache 4266 5452 136 29 1 : tunables 120 60 8 : slabdata 188 188 0 filp 413 740 192 20 1 : tunables 120 60 8 : slabdata 37 37 0 names_cache 3 3 4096 1 1 : tunables 24 12 8 : slabdata 3 3 0 idr_layer_cache 98 116 136 29 1 : tunables 120 60 8 : slabdata 4 4 0 buffer_head 12569528 12569535 56 67 1 : tunables 120 60 8 : slabdata 187605 187605 0 mm_struct 63 63 512 7 1 : tunables 54 27 8 : slabdata 9 9 0 vm_area_struct 761 1716 88 44 1 : tunables 120 60 8 : slabdata 39 39 0 fs_cache 54 177 64 59 1 : tunables 120 60 8 : slabdata 3 3 0 files_cache 55 90 256 15 1 : tunables 120 60 8 : slabdata 6 6 0 signal_cache 100 110 384 10 1 : tunables 54 27 8 : slabdata 11 11 0 sighand_cache 81 81 1344 3 1 : tunables 24 12 8 : slabdata 27 27 0 task_struct 87 87 1296 3 1 : tunables 24 12 8 : slabdata 29 29 0 anon_vma 359 609 16 203 1 : tunables 120 60 8 : slabdata 3 3 0 pgd 112 226 32 113 1 : tunables 120 60 8 : slabdata 2 2 0 pmd 72 72 4096 1 1 : tunables 24 12 8 : slabdata 72 72 0 pid 97 505 36 101 1 : tunables 120 60 8 : slabdata 5 5 0 size-131072(DMA) 0 0 131072 1 32 : tunables 8 4 0 : slabdata 0 0 0 size-131072 0 0 131072 1 32 : tunables 8 4 0 : slabdata 0 0 0 size-65536(DMA) 0 0 65536 1 16 : tunables 8 4 0 : slabdata 0 0 0 size-65536 1 1 65536 1 16 : tunables 8 4 0 : slabdata 1 1 0 size-32768(DMA) 0 0 32768 1 8 : tunables 8 4 0 : slabdata 0 0 0 size-32768 5 5 32768 1 8 : tunables 8 4 0 : slabdata 5 5 0 size-16384(DMA) 0 0 16384 1 4 : tunables 8 4 0 : slabdata 0 0 0 size-16384 4 4 16384 1 4 : tunables 8 4 0 : slabdata 4 4 0 size-8192(DMA) 0 0 8192 1 2 : tunables 8 4 0 : slabdata 0 0 0 size-8192 84 84 8192 1 2 : tunables 8 4 0 : slabdata 84 84 0 size-4096(DMA) 0 0 4096 1 1 : tunables 24 12 8 : slabdata 0 0 0 size-4096 36 36 4096 1 1 : tunables 24 12 8 : slabdata 36 36 0 size-2048(DMA) 0 0 2048 2 1 : tunables 24 12 8 : slabdata 0 0 0 size-2048 575 580 2048 2 1 : tunables 24 12 8 : slabdata 290 290 0 size-1024(DMA) 0 0 1024 4 1 : tunables 54 27 8 : slabdata 0 0 0 size-1024 196 196 1024 4 1 : tunables 54 27 8 : slabdata 49 49 0 size-512(DMA) 0 0 512 8 1 : tunables 54 27 8 : slabdata 0 0 0 size-512 1096 1208 512 8 1 : tunables 54 27 8 : slabdata 151 151 0 size-256(DMA) 0 0 256 15 1 : tunables 120 60 8 : slabdata 0 0 0 size-256 256 270 256 15 1 : tunables 120 60 8 : slabdata 18 18 0 size-192(DMA) 0 0 192 20 1 : tunables 120 60 8 : slabdata 0 0 0 size-192 140 140 192 20 1 : tunables 120 60 8 : slabdata 7 7 0 size-128(DMA) 0 0 128 30 1 : tunables 120 60 8 : slabdata 0 0 0 size-128 700 780 128 30 1 : tunables 120 60 8 : slabdata 26 26 0 size-64(DMA) 0 0 64 59 1 : tunables 120 60 8 : slabdata 0 0 0 size-32(DMA) 0 0 32 113 1 : tunables 120 60 8 : slabdata 0 0 0 size-64 2388 2478 64 59 1 : tunables 120 60 8 : slabdata 42 42 0 size-32 4299 5198 32 113 1 : tunables 120 60 8 : slabdata 46 46 0 kmem_cache 149 180 128 30 1 : tunables 120 60 8 : slabdata 6 6 0 [-- Attachment #3: Type: text/plain, Size: 1 bytes --] [-- Attachment #4: meminfo.txt --] [-- Type: text/plain, Size: 728 bytes --] MemTotal: 12306460 kB MemFree: 5228260 kB Buffers: 3968 kB Cached: 6293928 kB SwapCached: 0 kB Active: 10756 kB Inactive: 6291416 kB HighTotal: 11493340 kB HighFree: 5191416 kB LowTotal: 813120 kB LowFree: 36844 kB SwapTotal: 2008116 kB SwapFree: 2008116 kB Dirty: 4 kB Writeback: 0 kB AnonPages: 4328 kB Mapped: 3100 kB Slab: 766572 kB SReclaimable: 752292 kB SUnreclaim: 14280 kB PageTables: 320 kB NFS_Unstable: 0 kB Bounce: 0 kB CommitLimit: 8161344 kB Committed_AS: 19520 kB VmallocTotal: 118776 kB VmallocUsed: 3028 kB VmallocChunk: 115384 kB [-- Attachment #5: vmstat.txt --] [-- Type: text/plain, Size: 808 bytes --] nr_free_pages 1307065 nr_active 1572854 nr_inactive 2689 nr_anon_pages 1082 nr_mapped 775 nr_file_pages 1574474 nr_dirty 1 nr_writeback 0 nr_slab_reclaimable 188073 nr_slab_unreclaimable 3570 nr_page_table_pages 80 nr_unstable 0 nr_bounce 0 nr_vmscan_write 10 pgpgin 12847034 pgpgout 3501 pswpin 0 pswpout 0 pgalloc_dma 1944 pgalloc_normal 465694 pgalloc_high 3432418 pgfree 5207478 pgactivate 17439 pgdeactivate 13952 pgfault 1211997 pgmajfault 695 pgrefill_dma 0 pgrefill_normal 13952 pgrefill_high 0 pgsteal_dma 0 pgsteal_normal 1074 pgsteal_high 0 pgscan_kswapd_dma 0 pgscan_kswapd_normal 14688 pgscan_kswapd_high 0 pgscan_direct_dma 0 pgscan_direct_normal 3808 pgscan_direct_high 0 pginodesteal 0 slabs_scanned 8448 kswapd_steal 1007 kswapd_inodesteal 1637276 pageoutrun 609 allocstall 271 pgrotated 10 [-- Attachment #6: zoneinfo.txt --] [-- Type: text/plain, Size: 4283 bytes --] Node 0, zone DMA pages free 2828 min 17 low 21 high 25 scanned 0 (a: 14 i: 14) spanned 4096 present 4064 nr_free_pages 2828 nr_active 0 nr_inactive 0 nr_anon_pages 0 nr_mapped 1 nr_file_pages 0 nr_dirty 0 nr_writeback 0 nr_slab_reclaimable 0 nr_slab_unreclaimable 0 nr_page_table_pages 0 nr_unstable 0 nr_bounce 0 nr_vmscan_write 0 protection: (0, 873, 12176) pagesets cpu: 0 pcp: 0 count: 0 high: 0 batch: 1 cpu: 0 pcp: 1 count: 0 high: 0 batch: 1 vm stats threshold: 6 cpu: 1 pcp: 0 count: 0 high: 0 batch: 1 cpu: 1 pcp: 1 count: 0 high: 0 batch: 1 vm stats threshold: 6 cpu: 2 pcp: 0 count: 0 high: 0 batch: 1 cpu: 2 pcp: 1 count: 0 high: 0 batch: 1 vm stats threshold: 6 cpu: 3 pcp: 0 count: 0 high: 0 batch: 1 cpu: 3 pcp: 1 count: 0 high: 0 batch: 1 vm stats threshold: 6 all_unreclaimable: 0 prev_priority: 12 start_pfn: 0 Node 0, zone Normal pages free 6383 min 936 low 1170 high 1404 scanned 0 (a: 20 i: 20) spanned 225280 present 223520 nr_free_pages 6383 nr_active 489 nr_inactive 495 nr_anon_pages 0 nr_mapped 0 nr_file_pages 988 nr_dirty 1 nr_writeback 0 nr_slab_reclaimable 188073 nr_slab_unreclaimable 3570 nr_page_table_pages 80 nr_unstable 0 nr_bounce 0 nr_vmscan_write 10 protection: (0, 0, 90424) pagesets cpu: 0 pcp: 0 count: 19 high: 186 batch: 31 cpu: 0 pcp: 1 count: 1 high: 62 batch: 15 vm stats threshold: 24 cpu: 1 pcp: 0 count: 25 high: 186 batch: 31 cpu: 1 pcp: 1 count: 0 high: 62 batch: 15 vm stats threshold: 24 cpu: 2 pcp: 0 count: 13 high: 186 batch: 31 cpu: 2 pcp: 1 count: 54 high: 62 batch: 15 vm stats threshold: 24 cpu: 3 pcp: 0 count: 21 high: 186 batch: 31 cpu: 3 pcp: 1 count: 45 high: 62 batch: 15 vm stats threshold: 24 all_unreclaimable: 0 prev_priority: 12 start_pfn: 4096 Node 0, zone HighMem pages free 1297805 min 128 low 3160 high 6192 scanned 0 (a: 0 i: 0) spanned 2916351 present 2893568 nr_free_pages 1297805 nr_active 1572438 nr_inactive 2194 nr_anon_pages 1082 nr_mapped 774 nr_file_pages 1573559 nr_dirty 0 nr_writeback 0 nr_slab_reclaimable 0 nr_slab_unreclaimable 0 nr_page_table_pages 0 nr_unstable 0 nr_bounce 0 nr_vmscan_write 0 protection: (0, 0, 0) pagesets cpu: 0 pcp: 0 count: 19 high: 186 batch: 31 cpu: 0 pcp: 1 count: 12 high: 62 batch: 15 vm stats threshold: 48 cpu: 1 pcp: 0 count: 6 high: 186 batch: 31 cpu: 1 pcp: 1 count: 9 high: 62 batch: 15 vm stats threshold: 48 cpu: 2 pcp: 0 count: 151 high: 186 batch: 31 cpu: 2 pcp: 1 count: 8 high: 62 batch: 15 vm stats threshold: 48 cpu: 3 pcp: 0 count: 55 high: 186 batch: 31 cpu: 3 pcp: 1 count: 4 high: 62 batch: 15 vm stats threshold: 48 all_unreclaimable: 0 prev_priority: 12 start_pfn: 229376 ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: VM/VFS bug with large amount of memory and file systems? 2007-09-17 14:04 ` Anton Altaparmakov @ 2007-09-17 14:09 ` Anton Altaparmakov 2007-09-17 14:32 ` Peter Zijlstra 1 sibling, 0 replies; 47+ messages in thread From: Anton Altaparmakov @ 2007-09-17 14:09 UTC (permalink / raw) To: Andrew Morton, Peter Zijlstra Cc: Linux Kernel Mailing List, Linux Memory Management List, marc.smith On 17 Sep 2007, at 15:04, Anton Altaparmakov wrote: > On 15 Sep 2007, at 11:52, Andrew Morton wrote: >> On Sat, 15 Sep 2007 12:08:17 +0200 Peter Zijlstra >> <peterz@infradead.org> wrote: >>> Anyway, looks like all of zone_normal is pinned in kernel >>> allocations: >>> >>>> Sep 13 15:31:25 escabot Normal free:3648kB min:3744kB low:4680kB >>>> high: 5616kB active:0kB inactive:3160kB present:894080kB >>>> pages_scanned:5336 all_unreclaimable? yes >>> >>> Out of the 870 odd mb only 3 is on the lru. >>> >>> Would be grand it you could have a look at slabinfo and the like. >> >> Definitely. >> >>>> Sep 13 15:31:25 escabot free:1090395 slab:198893 mapped:988 >>>> pagetables:129 bounce:0 >> >> 814,665,728 bytes of slab. > > Marc emailed me the contents of /proc/ > {slabinfo,meminfo,vmstat,zoneinfo} taken just a few seconds before > the machine panic()ed due to running OOM completely... They files > are attached this time rather than inlined so people don't complain > about line wrapping! (No doubt people will not complain about them > being attached! )-:) > > If I read it correctly it appears all of low memory is eaten up by > buffer_heads. > > <quote> > # name <active_objs> <num_objs> <objsize> <objperslab> > <pagesperslab> > : tunables <limit> <batchcount> <sharedfactor> : slabdata > <active_slabs> <num_s > labs> <sharedavail> > buffer_head 12569528 12569535 56 67 1 : tunables > 120 60 8 : > slabdata 187605 187605 0 > </quote> > > That is 671MiB of low memory in buffer_heads. I meant that is 732MiB of low memory in buffer_heads. (12569535 num_objs / 67 objperslab * 1 pagesperslab * 4096 PAGE_SIZE) > But why is the kernel not reclaiming them by getting rid of the > page cache pages they are attached to or even leaving the pages > around but killing their buffers? > > I don't think I am doing anything in NTFS to cause this problem to > happen... Other than using buffer heads for my page cache pages > that is but that is hardly a crime! /-; Best regards, Anton -- Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @) Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK Linux NTFS maintainer, http://www.linux-ntfs.org/ ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: VM/VFS bug with large amount of memory and file systems? @ 2007-09-17 14:09 ` Anton Altaparmakov 0 siblings, 0 replies; 47+ messages in thread From: Anton Altaparmakov @ 2007-09-17 14:09 UTC (permalink / raw) To: Andrew Morton, Peter Zijlstra Cc: Linux Kernel Mailing List, Linux Memory Management List, marc.smith On 17 Sep 2007, at 15:04, Anton Altaparmakov wrote: > On 15 Sep 2007, at 11:52, Andrew Morton wrote: >> On Sat, 15 Sep 2007 12:08:17 +0200 Peter Zijlstra >> <peterz@infradead.org> wrote: >>> Anyway, looks like all of zone_normal is pinned in kernel >>> allocations: >>> >>>> Sep 13 15:31:25 escabot Normal free:3648kB min:3744kB low:4680kB >>>> high: 5616kB active:0kB inactive:3160kB present:894080kB >>>> pages_scanned:5336 all_unreclaimable? yes >>> >>> Out of the 870 odd mb only 3 is on the lru. >>> >>> Would be grand it you could have a look at slabinfo and the like. >> >> Definitely. >> >>>> Sep 13 15:31:25 escabot free:1090395 slab:198893 mapped:988 >>>> pagetables:129 bounce:0 >> >> 814,665,728 bytes of slab. > > Marc emailed me the contents of /proc/ > {slabinfo,meminfo,vmstat,zoneinfo} taken just a few seconds before > the machine panic()ed due to running OOM completely... They files > are attached this time rather than inlined so people don't complain > about line wrapping! (No doubt people will not complain about them > being attached! )-:) > > If I read it correctly it appears all of low memory is eaten up by > buffer_heads. > > <quote> > # name <active_objs> <num_objs> <objsize> <objperslab> > <pagesperslab> > : tunables <limit> <batchcount> <sharedfactor> : slabdata > <active_slabs> <num_s > labs> <sharedavail> > buffer_head 12569528 12569535 56 67 1 : tunables > 120 60 8 : > slabdata 187605 187605 0 > </quote> > > That is 671MiB of low memory in buffer_heads. I meant that is 732MiB of low memory in buffer_heads. (12569535 num_objs / 67 objperslab * 1 pagesperslab * 4096 PAGE_SIZE) > But why is the kernel not reclaiming them by getting rid of the > page cache pages they are attached to or even leaving the pages > around but killing their buffers? > > I don't think I am doing anything in NTFS to cause this problem to > happen... Other than using buffer heads for my page cache pages > that is but that is hardly a crime! /-; Best regards, Anton -- Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @) Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK Linux NTFS maintainer, http://www.linux-ntfs.org/ -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: VM/VFS bug with large amount of memory and file systems? 2007-09-17 14:09 ` Anton Altaparmakov @ 2007-09-16 22:28 ` Nick Piggin -1 siblings, 0 replies; 47+ messages in thread From: Nick Piggin @ 2007-09-16 22:28 UTC (permalink / raw) To: Anton Altaparmakov, Andrew Morton Cc: Andrew Morton, Peter Zijlstra, Linux Kernel Mailing List, Linux Memory Management List, marc.smith On Tuesday 18 September 2007 00:09, Anton Altaparmakov wrote: > On 17 Sep 2007, at 15:04, Anton Altaparmakov wrote: > > On 15 Sep 2007, at 11:52, Andrew Morton wrote: > >> On Sat, 15 Sep 2007 12:08:17 +0200 Peter Zijlstra > >> > >> <peterz@infradead.org> wrote: > >>> Anyway, looks like all of zone_normal is pinned in kernel > >>> > >>> allocations: > >>>> Sep 13 15:31:25 escabot Normal free:3648kB min:3744kB low:4680kB > >>>> high: 5616kB active:0kB inactive:3160kB present:894080kB > >>>> pages_scanned:5336 all_unreclaimable? yes > >>> > >>> Out of the 870 odd mb only 3 is on the lru. > >>> > >>> Would be grand it you could have a look at slabinfo and the like. > >> > >> Definitely. > >> > >>>> Sep 13 15:31:25 escabot free:1090395 slab:198893 mapped:988 > >>>> pagetables:129 bounce:0 > >> > >> 814,665,728 bytes of slab. > > > > Marc emailed me the contents of /proc/ > > {slabinfo,meminfo,vmstat,zoneinfo} taken just a few seconds before > > the machine panic()ed due to running OOM completely... They files > > are attached this time rather than inlined so people don't complain > > about line wrapping! (No doubt people will not complain about them > > being attached! )-:) > > > > If I read it correctly it appears all of low memory is eaten up by > > buffer_heads. > > > > <quote> > > # name <active_objs> <num_objs> <objsize> <objperslab> > > <pagesperslab> > > > > : tunables <limit> <batchcount> <sharedfactor> : slabdata > > > > <active_slabs> <num_s > > labs> <sharedavail> > > buffer_head 12569528 12569535 56 67 1 : tunables > > 120 60 8 : > > slabdata 187605 187605 0 > > </quote> > > > > That is 671MiB of low memory in buffer_heads. > > I meant that is 732MiB of low memory in buffer_heads. (12569535 > num_objs / 67 objperslab * 1 pagesperslab * 4096 PAGE_SIZE) There is a sledgehammer in there which is supposed to alleviate this problem. vmscan.c has buffer_heads_over_limit (could you check if that is kicking in? (add a line in mm/page_alloc.c:show_free_areas() to check it). However, I'd guess the logic should be pretty robust. So it looks like highmem is not getting scanned, so the buffer heads are not ever getting a chance to be stripped off highmem pages! (Rik has a patch sitting in -mm I believe which would make this problem even worse, by doing even less highmem scanning in response to lowmem allocations). However your user isn't using that kernel, so I wonder why it isn't scanning highmem... it's been a while since I looked at reclaim, but AFAIR it *should* be scanning it. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: VM/VFS bug with large amount of memory and file systems? @ 2007-09-16 22:28 ` Nick Piggin 0 siblings, 0 replies; 47+ messages in thread From: Nick Piggin @ 2007-09-16 22:28 UTC (permalink / raw) To: Anton Altaparmakov, Andrew Morton Cc: Peter Zijlstra, Linux Kernel Mailing List, Linux Memory Management List, marc.smith On Tuesday 18 September 2007 00:09, Anton Altaparmakov wrote: > On 17 Sep 2007, at 15:04, Anton Altaparmakov wrote: > > On 15 Sep 2007, at 11:52, Andrew Morton wrote: > >> On Sat, 15 Sep 2007 12:08:17 +0200 Peter Zijlstra > >> > >> <peterz@infradead.org> wrote: > >>> Anyway, looks like all of zone_normal is pinned in kernel > >>> > >>> allocations: > >>>> Sep 13 15:31:25 escabot Normal free:3648kB min:3744kB low:4680kB > >>>> high: 5616kB active:0kB inactive:3160kB present:894080kB > >>>> pages_scanned:5336 all_unreclaimable? yes > >>> > >>> Out of the 870 odd mb only 3 is on the lru. > >>> > >>> Would be grand it you could have a look at slabinfo and the like. > >> > >> Definitely. > >> > >>>> Sep 13 15:31:25 escabot free:1090395 slab:198893 mapped:988 > >>>> pagetables:129 bounce:0 > >> > >> 814,665,728 bytes of slab. > > > > Marc emailed me the contents of /proc/ > > {slabinfo,meminfo,vmstat,zoneinfo} taken just a few seconds before > > the machine panic()ed due to running OOM completely... They files > > are attached this time rather than inlined so people don't complain > > about line wrapping! (No doubt people will not complain about them > > being attached! )-:) > > > > If I read it correctly it appears all of low memory is eaten up by > > buffer_heads. > > > > <quote> > > # name <active_objs> <num_objs> <objsize> <objperslab> > > <pagesperslab> > > > > : tunables <limit> <batchcount> <sharedfactor> : slabdata > > > > <active_slabs> <num_s > > labs> <sharedavail> > > buffer_head 12569528 12569535 56 67 1 : tunables > > 120 60 8 : > > slabdata 187605 187605 0 > > </quote> > > > > That is 671MiB of low memory in buffer_heads. > > I meant that is 732MiB of low memory in buffer_heads. (12569535 > num_objs / 67 objperslab * 1 pagesperslab * 4096 PAGE_SIZE) There is a sledgehammer in there which is supposed to alleviate this problem. vmscan.c has buffer_heads_over_limit (could you check if that is kicking in? (add a line in mm/page_alloc.c:show_free_areas() to check it). However, I'd guess the logic should be pretty robust. So it looks like highmem is not getting scanned, so the buffer heads are not ever getting a chance to be stripped off highmem pages! (Rik has a patch sitting in -mm I believe which would make this problem even worse, by doing even less highmem scanning in response to lowmem allocations). However your user isn't using that kernel, so I wonder why it isn't scanning highmem... it's been a while since I looked at reclaim, but AFAIR it *should* be scanning it. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: VM/VFS bug with large amount of memory and file systems? 2007-09-16 22:28 ` Nick Piggin @ 2007-09-17 17:04 ` Rik van Riel -1 siblings, 0 replies; 47+ messages in thread From: Rik van Riel @ 2007-09-17 17:04 UTC (permalink / raw) To: Nick Piggin Cc: Anton Altaparmakov, Andrew Morton, Peter Zijlstra, Linux Kernel Mailing List, Linux Memory Management List, marc.smith Nick Piggin wrote: > (Rik has a patch sitting in -mm I believe which would make this problem > even worse, by doing even less highmem scanning in response to lowmem > allocations). My patch should not make any difference here, since balance_pgdat() already scans the zones from high to low and sets an end_zone variable that determines the highest zone to scan. All my patch does is make sure that we do not try to reclaim excessive amounts of dma or low memory when a higher zone is full. -- Politics is the struggle between those who want to make their country the best in the world, and those who believe it already is. Each group calls the other unpatriotic. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: VM/VFS bug with large amount of memory and file systems? @ 2007-09-17 17:04 ` Rik van Riel 0 siblings, 0 replies; 47+ messages in thread From: Rik van Riel @ 2007-09-17 17:04 UTC (permalink / raw) To: Nick Piggin Cc: Anton Altaparmakov, Andrew Morton, Peter Zijlstra, Linux Kernel Mailing List, Linux Memory Management List, marc.smith Nick Piggin wrote: > (Rik has a patch sitting in -mm I believe which would make this problem > even worse, by doing even less highmem scanning in response to lowmem > allocations). My patch should not make any difference here, since balance_pgdat() already scans the zones from high to low and sets an end_zone variable that determines the highest zone to scan. All my patch does is make sure that we do not try to reclaim excessive amounts of dma or low memory when a higher zone is full. -- Politics is the struggle between those who want to make their country the best in the world, and those who believe it already is. Each group calls the other unpatriotic. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: VM/VFS bug with large amount of memory and file systems? 2007-09-17 17:04 ` Rik van Riel @ 2007-09-17 17:12 ` Nick Piggin -1 siblings, 0 replies; 47+ messages in thread From: Nick Piggin @ 2007-09-17 17:12 UTC (permalink / raw) To: Rik van Riel Cc: Anton Altaparmakov, Andrew Morton, Peter Zijlstra, Linux Kernel Mailing List, Linux Memory Management List, marc.smith On Tuesday 18 September 2007 03:04, Rik van Riel wrote: > Nick Piggin wrote: > > (Rik has a patch sitting in -mm I believe which would make this problem > > even worse, by doing even less highmem scanning in response to lowmem > > allocations). > > My patch should not make any difference here, since > balance_pgdat() already scans the zones from high to > low and sets an end_zone variable that determines the > highest zone to scan. > > All my patch does is make sure that we do not try to > reclaim excessive amounts of dma or low memory when > a higher zone is full. Sorry, yeah I had it the wrong way around. Your patch would not increase the probability of this problem. We could have some logic in there to scan highmem when buffer heads are over limit. But that really kind of sucks in that it introduces some arbitrary point where reclaim behaviour completely changes... Adding a shrinker for buffer heads is the "logical" approach that we take for other non-page caches. That also kind of sucks because we normally don't want to do this out of band buffer reclaiming and just have it work from page reclaim (it will introduce extra locking and list scanning). Maybe when the machine is near OOM, we can just change the scanning to do all zones -- a change in scanning behaviour at that point is better than oom kill. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: VM/VFS bug with large amount of memory and file systems? @ 2007-09-17 17:12 ` Nick Piggin 0 siblings, 0 replies; 47+ messages in thread From: Nick Piggin @ 2007-09-17 17:12 UTC (permalink / raw) To: Rik van Riel Cc: Anton Altaparmakov, Andrew Morton, Peter Zijlstra, Linux Kernel Mailing List, Linux Memory Management List, marc.smith On Tuesday 18 September 2007 03:04, Rik van Riel wrote: > Nick Piggin wrote: > > (Rik has a patch sitting in -mm I believe which would make this problem > > even worse, by doing even less highmem scanning in response to lowmem > > allocations). > > My patch should not make any difference here, since > balance_pgdat() already scans the zones from high to > low and sets an end_zone variable that determines the > highest zone to scan. > > All my patch does is make sure that we do not try to > reclaim excessive amounts of dma or low memory when > a higher zone is full. Sorry, yeah I had it the wrong way around. Your patch would not increase the probability of this problem. We could have some logic in there to scan highmem when buffer heads are over limit. But that really kind of sucks in that it introduces some arbitrary point where reclaim behaviour completely changes... Adding a shrinker for buffer heads is the "logical" approach that we take for other non-page caches. That also kind of sucks because we normally don't want to do this out of band buffer reclaiming and just have it work from page reclaim (it will introduce extra locking and list scanning). Maybe when the machine is near OOM, we can just change the scanning to do all zones -- a change in scanning behaviour at that point is better than oom kill. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: VM/VFS bug with large amount of memory and file systems? 2007-09-17 17:12 ` Nick Piggin @ 2007-09-18 14:41 ` Rik van Riel -1 siblings, 0 replies; 47+ messages in thread From: Rik van Riel @ 2007-09-18 14:41 UTC (permalink / raw) To: Nick Piggin Cc: Anton Altaparmakov, Andrew Morton, Peter Zijlstra, Linux Kernel Mailing List, Linux Memory Management List, marc.smith Nick Piggin wrote: > On Tuesday 18 September 2007 03:04, Rik van Riel wrote: >> Nick Piggin wrote: >>> (Rik has a patch sitting in -mm I believe which would make this problem >>> even worse, by doing even less highmem scanning in response to lowmem >>> allocations). >> My patch should not make any difference here, since >> balance_pgdat() already scans the zones from high to >> low and sets an end_zone variable that determines the >> highest zone to scan. >> >> All my patch does is make sure that we do not try to >> reclaim excessive amounts of dma or low memory when >> a higher zone is full. > > Sorry, yeah I had it the wrong way around. Your patch would not > increase the probability of this problem. > > We could have some logic in there to scan highmem when buffer > heads are over limit. But that really kind of sucks in that it introduces > some arbitrary point where reclaim behaviour completely changes... > Adding a shrinker for buffer heads is the "logical" approach Christoph Lameter's slab defragmenting patch set does this. One reason Andrew has not merged that code yet is a lack of reviewers, so I am going through it with a fine comb and hope to have the patches reviewed by the end of today. Lets get this bug fixed the right way. -- Politics is the struggle between those who want to make their country the best in the world, and those who believe it already is. Each group calls the other unpatriotic. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: VM/VFS bug with large amount of memory and file systems? @ 2007-09-18 14:41 ` Rik van Riel 0 siblings, 0 replies; 47+ messages in thread From: Rik van Riel @ 2007-09-18 14:41 UTC (permalink / raw) To: Nick Piggin Cc: Anton Altaparmakov, Andrew Morton, Peter Zijlstra, Linux Kernel Mailing List, Linux Memory Management List, marc.smith Nick Piggin wrote: > On Tuesday 18 September 2007 03:04, Rik van Riel wrote: >> Nick Piggin wrote: >>> (Rik has a patch sitting in -mm I believe which would make this problem >>> even worse, by doing even less highmem scanning in response to lowmem >>> allocations). >> My patch should not make any difference here, since >> balance_pgdat() already scans the zones from high to >> low and sets an end_zone variable that determines the >> highest zone to scan. >> >> All my patch does is make sure that we do not try to >> reclaim excessive amounts of dma or low memory when >> a higher zone is full. > > Sorry, yeah I had it the wrong way around. Your patch would not > increase the probability of this problem. > > We could have some logic in there to scan highmem when buffer > heads are over limit. But that really kind of sucks in that it introduces > some arbitrary point where reclaim behaviour completely changes... > Adding a shrinker for buffer heads is the "logical" approach Christoph Lameter's slab defragmenting patch set does this. One reason Andrew has not merged that code yet is a lack of reviewers, so I am going through it with a fine comb and hope to have the patches reviewed by the end of today. Lets get this bug fixed the right way. -- Politics is the struggle between those who want to make their country the best in the world, and those who believe it already is. Each group calls the other unpatriotic. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: VM/VFS bug with large amount of memory and file systems? 2007-09-17 14:04 ` Anton Altaparmakov @ 2007-09-17 14:32 ` Peter Zijlstra 2007-09-17 14:32 ` Peter Zijlstra 1 sibling, 0 replies; 47+ messages in thread From: Peter Zijlstra @ 2007-09-17 14:32 UTC (permalink / raw) To: Anton Altaparmakov Cc: Andrew Morton, Linux Kernel Mailing List, Linux Memory Management List, marc.smith On Mon, 17 Sep 2007 15:04:05 +0100 Anton Altaparmakov <aia21@cam.ac.uk> wrote: > They files > are attached this time rather than inlined so people don't complain > about line wrapping! (No doubt people will not complain about them > being attached! )-:) I switched mailer after I learnt about flowed stuffs. Still, appreciated. > If I read it correctly it appears all of low memory is eaten up by > buffer_heads. > > <quote> > # name <active_objs> <num_objs> <objsize> <objperslab> > <pagesperslab> > : tunables <limit> <batchcount> <sharedfactor> : slabdata > <active_slabs> <num_s > labs> <sharedavail> > buffer_head 12569528 12569535 56 67 1 : tunables > 120 60 8 : > slabdata 187605 187605 0 > </quote> > > That is 671MiB of low memory in buffer_heads. > > But why is the kernel not reclaiming them by getting rid of the page > cache pages they are attached to or even leaving the pages around but > killing their buffers? Well, you see, you have this very odd configuration where: 11GB highmem 1GB normal pagecache pages go into highmem buggerheads go into normal I'm guessing there is no pressure at all on zone_highmem so the kernel will not try to reclaim pagecache. And because the pagecache pages are happily sitting there, the buggerheads are pinned and do not get reclaimed. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: VM/VFS bug with large amount of memory and file systems? @ 2007-09-17 14:32 ` Peter Zijlstra 0 siblings, 0 replies; 47+ messages in thread From: Peter Zijlstra @ 2007-09-17 14:32 UTC (permalink / raw) To: Anton Altaparmakov Cc: Andrew Morton, Linux Kernel Mailing List, Linux Memory Management List, marc.smith On Mon, 17 Sep 2007 15:04:05 +0100 Anton Altaparmakov <aia21@cam.ac.uk> wrote: > They files > are attached this time rather than inlined so people don't complain > about line wrapping! (No doubt people will not complain about them > being attached! )-:) I switched mailer after I learnt about flowed stuffs. Still, appreciated. > If I read it correctly it appears all of low memory is eaten up by > buffer_heads. > > <quote> > # name <active_objs> <num_objs> <objsize> <objperslab> > <pagesperslab> > : tunables <limit> <batchcount> <sharedfactor> : slabdata > <active_slabs> <num_s > labs> <sharedavail> > buffer_head 12569528 12569535 56 67 1 : tunables > 120 60 8 : > slabdata 187605 187605 0 > </quote> > > That is 671MiB of low memory in buffer_heads. > > But why is the kernel not reclaiming them by getting rid of the page > cache pages they are attached to or even leaving the pages around but > killing their buffers? Well, you see, you have this very odd configuration where: 11GB highmem 1GB normal pagecache pages go into highmem buggerheads go into normal I'm guessing there is no pressure at all on zone_highmem so the kernel will not try to reclaim pagecache. And because the pagecache pages are happily sitting there, the buggerheads are pinned and do not get reclaimed. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: VM/VFS bug with large amount of memory and file systems? 2007-09-17 14:32 ` Peter Zijlstra @ 2007-09-17 17:11 ` Rik van Riel -1 siblings, 0 replies; 47+ messages in thread From: Rik van Riel @ 2007-09-17 17:11 UTC (permalink / raw) To: Peter Zijlstra Cc: Anton Altaparmakov, Andrew Morton, Linux Kernel Mailing List, Linux Memory Management List, marc.smith Peter Zijlstra wrote: > On Mon, 17 Sep 2007 15:04:05 +0100 Anton Altaparmakov <aia21@cam.ac.uk> > wrote: > >> They files >> are attached this time rather than inlined so people don't complain >> about line wrapping! (No doubt people will not complain about them >> being attached! )-:) > > I switched mailer after I learnt about flowed stuffs. Still, > appreciated. > >> If I read it correctly it appears all of low memory is eaten up by >> buffer_heads. >> >> <quote> >> # name <active_objs> <num_objs> <objsize> <objperslab> >> <pagesperslab> >> : tunables <limit> <batchcount> <sharedfactor> : slabdata >> <active_slabs> <num_s >> labs> <sharedavail> >> buffer_head 12569528 12569535 56 67 1 : tunables >> 120 60 8 : >> slabdata 187605 187605 0 >> </quote> >> >> That is 671MiB of low memory in buffer_heads. >> >> But why is the kernel not reclaiming them by getting rid of the page >> cache pages they are attached to or even leaving the pages around but >> killing their buffers? > > Well, you see, you have this very odd configuration where: > > 11GB highmem > 1GB normal > > pagecache pages go into highmem > buggerheads go into normal > > I'm guessing there is no pressure at all on zone_highmem so the > kernel will not try to reclaim pagecache. And because the pagecache > pages are happily sitting there, the buggerheads are pinned and do not > get reclaimed. I've got code for this in RHEL 3, but never bothered to merge it upstream since I thought people with large memory systems would be running 64 bit kernels by now. Obviously I was wrong. Andrew, are you interested in a fix for this problem? IIRC I simply kept a list of all buffer heads and walked that to reclaim pages when the number of buffer heads is too high (and we need memory). This list can be maintained in places where we already hold the lock for the buffer head freelist, so there should be no additional locking overhead (again, IIRC). -- Politics is the struggle between those who want to make their country the best in the world, and those who believe it already is. Each group calls the other unpatriotic. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: VM/VFS bug with large amount of memory and file systems? @ 2007-09-17 17:11 ` Rik van Riel 0 siblings, 0 replies; 47+ messages in thread From: Rik van Riel @ 2007-09-17 17:11 UTC (permalink / raw) To: Peter Zijlstra Cc: Anton Altaparmakov, Andrew Morton, Linux Kernel Mailing List, Linux Memory Management List, marc.smith Peter Zijlstra wrote: > On Mon, 17 Sep 2007 15:04:05 +0100 Anton Altaparmakov <aia21@cam.ac.uk> > wrote: > >> They files >> are attached this time rather than inlined so people don't complain >> about line wrapping! (No doubt people will not complain about them >> being attached! )-:) > > I switched mailer after I learnt about flowed stuffs. Still, > appreciated. > >> If I read it correctly it appears all of low memory is eaten up by >> buffer_heads. >> >> <quote> >> # name <active_objs> <num_objs> <objsize> <objperslab> >> <pagesperslab> >> : tunables <limit> <batchcount> <sharedfactor> : slabdata >> <active_slabs> <num_s >> labs> <sharedavail> >> buffer_head 12569528 12569535 56 67 1 : tunables >> 120 60 8 : >> slabdata 187605 187605 0 >> </quote> >> >> That is 671MiB of low memory in buffer_heads. >> >> But why is the kernel not reclaiming them by getting rid of the page >> cache pages they are attached to or even leaving the pages around but >> killing their buffers? > > Well, you see, you have this very odd configuration where: > > 11GB highmem > 1GB normal > > pagecache pages go into highmem > buggerheads go into normal > > I'm guessing there is no pressure at all on zone_highmem so the > kernel will not try to reclaim pagecache. And because the pagecache > pages are happily sitting there, the buggerheads are pinned and do not > get reclaimed. I've got code for this in RHEL 3, but never bothered to merge it upstream since I thought people with large memory systems would be running 64 bit kernels by now. Obviously I was wrong. Andrew, are you interested in a fix for this problem? IIRC I simply kept a list of all buffer heads and walked that to reclaim pages when the number of buffer heads is too high (and we need memory). This list can be maintained in places where we already hold the lock for the buffer head freelist, so there should be no additional locking overhead (again, IIRC). -- Politics is the struggle between those who want to make their country the best in the world, and those who believe it already is. Each group calls the other unpatriotic. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: VM/VFS bug with large amount of memory and file systems? 2007-09-17 17:11 ` Rik van Riel @ 2007-09-17 20:15 ` Andrew Morton -1 siblings, 0 replies; 47+ messages in thread From: Andrew Morton @ 2007-09-17 20:15 UTC (permalink / raw) To: Rik van Riel Cc: Peter Zijlstra, Anton Altaparmakov, Linux Kernel Mailing List, Linux Memory Management List, marc.smith On Mon, 17 Sep 2007 13:11:14 -0400 Rik van Riel <riel@redhat.com> wrote: > > I'm guessing there is no pressure at all on zone_highmem so the > > kernel will not try to reclaim pagecache. And because the pagecache > > pages are happily sitting there, the buggerheads are pinned and do not > > get reclaimed. yeah, this got pretty unavoidably broken when we killed the global LRU in 2.5.early. It's odd that it took this long for someone to hit it. > I've got code for this in RHEL 3, but never bothered to > merge it upstream since I thought people with large memory > systems would be running 64 bit kernels by now. > > Obviously I was wrong. Andrew, are you interested in a > fix for this problem? > > IIRC I simply kept a list of all buffer heads and walked > that to reclaim pages when the number of buffer heads is > too high (and we need memory). This list can be maintained > in places where we already hold the lock for the buffer head > freelist, so there should be no additional locking overhead > (again, IIRC). Christoph's slab defragmentation code should permit us to fix this: grab a page of buffer_heads off the slab lists, trylock the page, strip the buffer_heads. I think that would be a better approach if we can get it going because it's more general. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: VM/VFS bug with large amount of memory and file systems? @ 2007-09-17 20:15 ` Andrew Morton 0 siblings, 0 replies; 47+ messages in thread From: Andrew Morton @ 2007-09-17 20:15 UTC (permalink / raw) To: Rik van Riel Cc: Peter Zijlstra, Anton Altaparmakov, Linux Kernel Mailing List, Linux Memory Management List, marc.smith On Mon, 17 Sep 2007 13:11:14 -0400 Rik van Riel <riel@redhat.com> wrote: > > I'm guessing there is no pressure at all on zone_highmem so the > > kernel will not try to reclaim pagecache. And because the pagecache > > pages are happily sitting there, the buggerheads are pinned and do not > > get reclaimed. yeah, this got pretty unavoidably broken when we killed the global LRU in 2.5.early. It's odd that it took this long for someone to hit it. > I've got code for this in RHEL 3, but never bothered to > merge it upstream since I thought people with large memory > systems would be running 64 bit kernels by now. > > Obviously I was wrong. Andrew, are you interested in a > fix for this problem? > > IIRC I simply kept a list of all buffer heads and walked > that to reclaim pages when the number of buffer heads is > too high (and we need memory). This list can be maintained > in places where we already hold the lock for the buffer head > freelist, so there should be no additional locking overhead > (again, IIRC). Christoph's slab defragmentation code should permit us to fix this: grab a page of buffer_heads off the slab lists, trylock the page, strip the buffer_heads. I think that would be a better approach if we can get it going because it's more general. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: VM/VFS bug with large amount of memory and file systems? 2007-09-17 20:15 ` Andrew Morton @ 2007-09-17 20:46 ` Rik van Riel -1 siblings, 0 replies; 47+ messages in thread From: Rik van Riel @ 2007-09-17 20:46 UTC (permalink / raw) To: Andrew Morton Cc: Peter Zijlstra, Anton Altaparmakov, Linux Kernel Mailing List, Linux Memory Management List, marc.smith Andrew Morton wrote: > On Mon, 17 Sep 2007 13:11:14 -0400 > Rik van Riel <riel@redhat.com> wrote: >> IIRC I simply kept a list of all buffer heads and walked >> that to reclaim pages when the number of buffer heads is >> too high (and we need memory). This list can be maintained >> in places where we already hold the lock for the buffer head >> freelist, so there should be no additional locking overhead >> (again, IIRC). > > Christoph's slab defragmentation code should permit us to fix this: > grab a page of buffer_heads off the slab lists, trylock the page, > strip the buffer_heads. I think that would be a better approach > if we can get it going because it's more general. Is the slab defragmentation code in -mm or upstream already or can I find it on the mailing list? I've implemented code like you describe already, just give me a few days to become familiar with the slab defragmentation code and I'll get you a patch. -- Politics is the struggle between those who want to make their country the best in the world, and those who believe it already is. Each group calls the other unpatriotic. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: VM/VFS bug with large amount of memory and file systems? @ 2007-09-17 20:46 ` Rik van Riel 0 siblings, 0 replies; 47+ messages in thread From: Rik van Riel @ 2007-09-17 20:46 UTC (permalink / raw) To: Andrew Morton Cc: Peter Zijlstra, Anton Altaparmakov, Linux Kernel Mailing List, Linux Memory Management List, marc.smith Andrew Morton wrote: > On Mon, 17 Sep 2007 13:11:14 -0400 > Rik van Riel <riel@redhat.com> wrote: >> IIRC I simply kept a list of all buffer heads and walked >> that to reclaim pages when the number of buffer heads is >> too high (and we need memory). This list can be maintained >> in places where we already hold the lock for the buffer head >> freelist, so there should be no additional locking overhead >> (again, IIRC). > > Christoph's slab defragmentation code should permit us to fix this: > grab a page of buffer_heads off the slab lists, trylock the page, > strip the buffer_heads. I think that would be a better approach > if we can get it going because it's more general. Is the slab defragmentation code in -mm or upstream already or can I find it on the mailing list? I've implemented code like you describe already, just give me a few days to become familiar with the slab defragmentation code and I'll get you a patch. -- Politics is the struggle between those who want to make their country the best in the world, and those who believe it already is. Each group calls the other unpatriotic. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: VM/VFS bug with large amount of memory and file systems? 2007-09-17 20:46 ` Rik van Riel @ 2007-09-17 21:11 ` Andrew Morton -1 siblings, 0 replies; 47+ messages in thread From: Andrew Morton @ 2007-09-17 21:11 UTC (permalink / raw) To: Rik van Riel Cc: Peter Zijlstra, Anton Altaparmakov, Linux Kernel Mailing List, Linux Memory Management List, marc.smith On Mon, 17 Sep 2007 16:46:47 -0400 Rik van Riel <riel@redhat.com> wrote: > Andrew Morton wrote: > > On Mon, 17 Sep 2007 13:11:14 -0400 > > Rik van Riel <riel@redhat.com> wrote: > > >> IIRC I simply kept a list of all buffer heads and walked > >> that to reclaim pages when the number of buffer heads is > >> too high (and we need memory). This list can be maintained > >> in places where we already hold the lock for the buffer head > >> freelist, so there should be no additional locking overhead > >> (again, IIRC). > > > > Christoph's slab defragmentation code should permit us to fix this: > > grab a page of buffer_heads off the slab lists, trylock the page, > > strip the buffer_heads. I think that would be a better approach > > if we can get it going because it's more general. > > Is the slab defragmentation code in -mm or upstream already > or can I find it on the mailing list? Is on lkml and linux-mm: http://lkml.org/lkml/2007/8/31/329 > I've implemented code like you describe already, just give me > a few days to become familiar with the slab defragmentation > code and I'll get you a patch. The patchset does buffer_heads: http://lkml.org/lkml/2007/8/31/348 I think the whole approach is reasonable. It's mainly a matter of going through it all with a toothcomb and getting it all merged up, tested and integrated. There's considerable potential for nasty and rarely-occurring surprises in this stuff because it tends to approach locking in the reversed order. <checks the archives> There were a few desultory comments, but I see no sign that the bulk of the patches have had any serious review and testing from anyone yet. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: VM/VFS bug with large amount of memory and file systems? @ 2007-09-17 21:11 ` Andrew Morton 0 siblings, 0 replies; 47+ messages in thread From: Andrew Morton @ 2007-09-17 21:11 UTC (permalink / raw) To: Rik van Riel Cc: Peter Zijlstra, Anton Altaparmakov, Linux Kernel Mailing List, Linux Memory Management List, marc.smith On Mon, 17 Sep 2007 16:46:47 -0400 Rik van Riel <riel@redhat.com> wrote: > Andrew Morton wrote: > > On Mon, 17 Sep 2007 13:11:14 -0400 > > Rik van Riel <riel@redhat.com> wrote: > > >> IIRC I simply kept a list of all buffer heads and walked > >> that to reclaim pages when the number of buffer heads is > >> too high (and we need memory). This list can be maintained > >> in places where we already hold the lock for the buffer head > >> freelist, so there should be no additional locking overhead > >> (again, IIRC). > > > > Christoph's slab defragmentation code should permit us to fix this: > > grab a page of buffer_heads off the slab lists, trylock the page, > > strip the buffer_heads. I think that would be a better approach > > if we can get it going because it's more general. > > Is the slab defragmentation code in -mm or upstream already > or can I find it on the mailing list? Is on lkml and linux-mm: http://lkml.org/lkml/2007/8/31/329 > I've implemented code like you describe already, just give me > a few days to become familiar with the slab defragmentation > code and I'll get you a patch. The patchset does buffer_heads: http://lkml.org/lkml/2007/8/31/348 I think the whole approach is reasonable. It's mainly a matter of going through it all with a toothcomb and getting it all merged up, tested and integrated. There's considerable potential for nasty and rarely-occurring surprises in this stuff because it tends to approach locking in the reversed order. <checks the archives> There were a few desultory comments, but I see no sign that the bulk of the patches have had any serious review and testing from anyone yet. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: VM/VFS bug with large amount of memory and file systems? 2007-09-17 21:11 ` Andrew Morton @ 2007-09-19 22:12 ` Rik van Riel -1 siblings, 0 replies; 47+ messages in thread From: Rik van Riel @ 2007-09-19 22:12 UTC (permalink / raw) To: Andrew Morton Cc: Peter Zijlstra, Anton Altaparmakov, Linux Kernel Mailing List, Linux Memory Management List, marc.smith Andrew Morton wrote: > On Mon, 17 Sep 2007 16:46:47 -0400 > Rik van Riel <riel@redhat.com> wrote: >> Is the slab defragmentation code in -mm or upstream already >> or can I find it on the mailing list? > > Is on lkml and linux-mm: http://lkml.org/lkml/2007/8/31/329 > I think the whole approach is reasonable. It's mainly a matter of going > through it all with a toothcomb I've spent the last two days combing through the patches. Except for the one doubt I had (resolved in email), and one function name comment (on patch 18/26) the code looks good to me. -- Politics is the struggle between those who want to make their country the best in the world, and those who believe it already is. Each group calls the other unpatriotic. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: VM/VFS bug with large amount of memory and file systems? @ 2007-09-19 22:12 ` Rik van Riel 0 siblings, 0 replies; 47+ messages in thread From: Rik van Riel @ 2007-09-19 22:12 UTC (permalink / raw) To: Andrew Morton Cc: Peter Zijlstra, Anton Altaparmakov, Linux Kernel Mailing List, Linux Memory Management List, marc.smith Andrew Morton wrote: > On Mon, 17 Sep 2007 16:46:47 -0400 > Rik van Riel <riel@redhat.com> wrote: >> Is the slab defragmentation code in -mm or upstream already >> or can I find it on the mailing list? > > Is on lkml and linux-mm: http://lkml.org/lkml/2007/8/31/329 > I think the whole approach is reasonable. It's mainly a matter of going > through it all with a toothcomb I've spent the last two days combing through the patches. Except for the one doubt I had (resolved in email), and one function name comment (on patch 18/26) the code looks good to me. -- Politics is the struggle between those who want to make their country the best in the world, and those who believe it already is. Each group calls the other unpatriotic. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: VM/VFS bug with large amount of memory and file systems? 2007-09-19 22:12 ` Rik van Riel @ 2007-09-19 22:45 ` Andrew Morton -1 siblings, 0 replies; 47+ messages in thread From: Andrew Morton @ 2007-09-19 22:45 UTC (permalink / raw) To: Rik van Riel Cc: Peter Zijlstra, Anton Altaparmakov, Linux Kernel Mailing List, Linux Memory Management List, marc.smith, Christoph Lameter On Wed, 19 Sep 2007 18:12:38 -0400 Rik van Riel <riel@redhat.com> wrote: > Andrew Morton wrote: > > On Mon, 17 Sep 2007 16:46:47 -0400 > > Rik van Riel <riel@redhat.com> wrote: > > >> Is the slab defragmentation code in -mm or upstream already > >> or can I find it on the mailing list? > > > > Is on lkml and linux-mm: http://lkml.org/lkml/2007/8/31/329 > > > I think the whole approach is reasonable. It's mainly a matter of going > > through it all with a toothcomb > > I've spent the last two days combing through the patches. Thanks. So would it be appropriate for Christoph to add the thus-far-undefined reviewed-by tag to the next version? > Except for the one doubt I had (resolved in email), and > one function name comment (on patch 18/26) yeah. Basic rule: if the reviewer had to ask a question then others will later ask themselves the same question when reading the code. So this is a very good indicator that there is a missing code comment. > the code looks > good to me. Cool. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: VM/VFS bug with large amount of memory and file systems? @ 2007-09-19 22:45 ` Andrew Morton 0 siblings, 0 replies; 47+ messages in thread From: Andrew Morton @ 2007-09-19 22:45 UTC (permalink / raw) To: Rik van Riel Cc: Peter Zijlstra, Anton Altaparmakov, Linux Kernel Mailing List, Linux Memory Management List, marc.smith, Christoph Lameter On Wed, 19 Sep 2007 18:12:38 -0400 Rik van Riel <riel@redhat.com> wrote: > Andrew Morton wrote: > > On Mon, 17 Sep 2007 16:46:47 -0400 > > Rik van Riel <riel@redhat.com> wrote: > > >> Is the slab defragmentation code in -mm or upstream already > >> or can I find it on the mailing list? > > > > Is on lkml and linux-mm: http://lkml.org/lkml/2007/8/31/329 > > > I think the whole approach is reasonable. It's mainly a matter of going > > through it all with a toothcomb > > I've spent the last two days combing through the patches. Thanks. So would it be appropriate for Christoph to add the thus-far-undefined reviewed-by tag to the next version? > Except for the one doubt I had (resolved in email), and > one function name comment (on patch 18/26) yeah. Basic rule: if the reviewer had to ask a question then others will later ask themselves the same question when reading the code. So this is a very good indicator that there is a missing code comment. > the code looks > good to me. Cool. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: VM/VFS bug with large amount of memory and file systems? 2007-09-19 22:45 ` Andrew Morton @ 2007-09-19 22:50 ` Rik van Riel -1 siblings, 0 replies; 47+ messages in thread From: Rik van Riel @ 2007-09-19 22:50 UTC (permalink / raw) To: Andrew Morton Cc: Peter Zijlstra, Anton Altaparmakov, Linux Kernel Mailing List, Linux Memory Management List, marc.smith, Christoph Lameter Andrew Morton wrote: > On Wed, 19 Sep 2007 18:12:38 -0400 > Rik van Riel <riel@redhat.com> wrote: > >> Andrew Morton wrote: >>> On Mon, 17 Sep 2007 16:46:47 -0400 >>> Rik van Riel <riel@redhat.com> wrote: >>>> Is the slab defragmentation code in -mm or upstream already >>>> or can I find it on the mailing list? >>> Is on lkml and linux-mm: http://lkml.org/lkml/2007/8/31/329 >>> I think the whole approach is reasonable. It's mainly a matter of going >>> through it all with a toothcomb >> I've spent the last two days combing through the patches. > > Thanks. So would it be appropriate for Christoph to add the > thus-far-undefined reviewed-by tag to the next version? Absolutely. Some of the code was not obvious at first, but the more I looked at it the better it looked - that's always a good sign, since most of the code seems to be the other way around :) -- Politics is the struggle between those who want to make their country the best in the world, and those who believe it already is. Each group calls the other unpatriotic. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: VM/VFS bug with large amount of memory and file systems? @ 2007-09-19 22:50 ` Rik van Riel 0 siblings, 0 replies; 47+ messages in thread From: Rik van Riel @ 2007-09-19 22:50 UTC (permalink / raw) To: Andrew Morton Cc: Peter Zijlstra, Anton Altaparmakov, Linux Kernel Mailing List, Linux Memory Management List, marc.smith, Christoph Lameter Andrew Morton wrote: > On Wed, 19 Sep 2007 18:12:38 -0400 > Rik van Riel <riel@redhat.com> wrote: > >> Andrew Morton wrote: >>> On Mon, 17 Sep 2007 16:46:47 -0400 >>> Rik van Riel <riel@redhat.com> wrote: >>>> Is the slab defragmentation code in -mm or upstream already >>>> or can I find it on the mailing list? >>> Is on lkml and linux-mm: http://lkml.org/lkml/2007/8/31/329 >>> I think the whole approach is reasonable. It's mainly a matter of going >>> through it all with a toothcomb >> I've spent the last two days combing through the patches. > > Thanks. So would it be appropriate for Christoph to add the > thus-far-undefined reviewed-by tag to the next version? Absolutely. Some of the code was not obvious at first, but the more I looked at it the better it looked - that's always a good sign, since most of the code seems to be the other way around :) -- Politics is the struggle between those who want to make their country the best in the world, and those who believe it already is. Each group calls the other unpatriotic. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: VM/VFS bug with large amount of memory and file systems? 2007-09-19 22:45 ` Andrew Morton @ 2007-09-19 23:29 ` Christoph Lameter -1 siblings, 0 replies; 47+ messages in thread From: Christoph Lameter @ 2007-09-19 23:29 UTC (permalink / raw) To: Andrew Morton Cc: Rik van Riel, Peter Zijlstra, Anton Altaparmakov, Linux Kernel Mailing List, Linux Memory Management List, marc.smith On Wed, 19 Sep 2007, Andrew Morton wrote: > Cool. Should I rediff on top of rc6-mm1 for submission? When will you be able to take it? ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: VM/VFS bug with large amount of memory and file systems? @ 2007-09-19 23:29 ` Christoph Lameter 0 siblings, 0 replies; 47+ messages in thread From: Christoph Lameter @ 2007-09-19 23:29 UTC (permalink / raw) To: Andrew Morton Cc: Rik van Riel, Peter Zijlstra, Anton Altaparmakov, Linux Kernel Mailing List, Linux Memory Management List, marc.smith On Wed, 19 Sep 2007, Andrew Morton wrote: > Cool. Should I rediff on top of rc6-mm1 for submission? When will you be able to take it? -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: VM/VFS bug with large amount of memory and file systems? 2007-09-19 23:29 ` Christoph Lameter @ 2007-09-19 23:37 ` Andrew Morton -1 siblings, 0 replies; 47+ messages in thread From: Andrew Morton @ 2007-09-19 23:37 UTC (permalink / raw) To: Christoph Lameter Cc: Rik van Riel, Peter Zijlstra, Anton Altaparmakov, Linux Kernel Mailing List, Linux Memory Management List, marc.smith On Wed, 19 Sep 2007 16:29:02 -0700 (PDT) Christoph Lameter <clameter@sgi.com> wrote: > On Wed, 19 Sep 2007, Andrew Morton wrote: > > > Cool. > > Should I rediff on top of rc6-mm1 for submission? When will you be able to > take it? > erm, I spose we should be concentrating on stabilising the current pile of crud for 2.6.24 - it sure needs it. Sometime around 2.6.24-rc1 would suit. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: VM/VFS bug with large amount of memory and file systems? @ 2007-09-19 23:37 ` Andrew Morton 0 siblings, 0 replies; 47+ messages in thread From: Andrew Morton @ 2007-09-19 23:37 UTC (permalink / raw) To: Christoph Lameter Cc: Rik van Riel, Peter Zijlstra, Anton Altaparmakov, Linux Kernel Mailing List, Linux Memory Management List, marc.smith On Wed, 19 Sep 2007 16:29:02 -0700 (PDT) Christoph Lameter <clameter@sgi.com> wrote: > On Wed, 19 Sep 2007, Andrew Morton wrote: > > > Cool. > > Should I rediff on top of rc6-mm1 for submission? When will you be able to > take it? > erm, I spose we should be concentrating on stabilising the current pile of crud for 2.6.24 - it sure needs it. Sometime around 2.6.24-rc1 would suit. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: VM/VFS bug with large amount of memory and file systems? 2007-09-15 7:27 ` Anton Altaparmakov @ 2007-10-03 10:51 ` Pavel Machek -1 siblings, 0 replies; 47+ messages in thread From: Pavel Machek @ 2007-10-03 10:51 UTC (permalink / raw) To: Anton Altaparmakov Cc: Linux Kernel Mailing List, Linux Memory Management List, marc.smith On Sat 2007-09-15 08:27:23, Anton Altaparmakov wrote: > Hi, > > Mark Smith reported a OOM condition when he copies a > large (46GiB) file from an NTFS partition (using the > stock kernel driver) to /dev/ null (or to a file on > ext3, same result). > > The machine this runs on has an i386 kernel with 12GiB > RAM (yes this is not a typo it is 12GiB!). Yes, that's known broken. 32bit machines with to much memory just do not work properly. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: VM/VFS bug with large amount of memory and file systems? @ 2007-10-03 10:51 ` Pavel Machek 0 siblings, 0 replies; 47+ messages in thread From: Pavel Machek @ 2007-10-03 10:51 UTC (permalink / raw) To: Anton Altaparmakov Cc: Linux Kernel Mailing List, Linux Memory Management List, marc.smith On Sat 2007-09-15 08:27:23, Anton Altaparmakov wrote: > Hi, > > Mark Smith reported a OOM condition when he copies a > large (46GiB) file from an NTFS partition (using the > stock kernel driver) to /dev/ null (or to a file on > ext3, same result). > > The machine this runs on has an i386 kernel with 12GiB > RAM (yes this is not a typo it is 12GiB!). Yes, that's known broken. 32bit machines with to much memory just do not work properly. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 47+ messages in thread
end of thread, other threads:[~2007-10-03 10:51 UTC | newest] Thread overview: 47+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2007-09-15 7:27 VM/VFS bug with large amount of memory and file systems? Anton Altaparmakov 2007-09-15 7:27 ` Anton Altaparmakov 2007-09-15 10:08 ` Peter Zijlstra 2007-09-15 10:08 ` Peter Zijlstra 2007-09-15 10:50 ` Anton Altaparmakov 2007-09-15 10:50 ` Anton Altaparmakov 2007-09-15 11:19 ` Peter Zijlstra 2007-09-15 11:19 ` Peter Zijlstra 2007-09-16 7:22 ` Kyle Moffett 2007-09-16 7:22 ` Kyle Moffett 2007-09-16 16:16 ` Peter Zijlstra 2007-09-16 16:16 ` Peter Zijlstra 2007-09-15 10:52 ` Andrew Morton 2007-09-15 10:52 ` Andrew Morton 2007-09-17 14:04 ` Anton Altaparmakov 2007-09-17 14:09 ` Anton Altaparmakov 2007-09-17 14:09 ` Anton Altaparmakov 2007-09-16 22:28 ` Nick Piggin 2007-09-16 22:28 ` Nick Piggin 2007-09-17 17:04 ` Rik van Riel 2007-09-17 17:04 ` Rik van Riel 2007-09-17 17:12 ` Nick Piggin 2007-09-17 17:12 ` Nick Piggin 2007-09-18 14:41 ` Rik van Riel 2007-09-18 14:41 ` Rik van Riel 2007-09-17 14:32 ` Peter Zijlstra 2007-09-17 14:32 ` Peter Zijlstra 2007-09-17 17:11 ` Rik van Riel 2007-09-17 17:11 ` Rik van Riel 2007-09-17 20:15 ` Andrew Morton 2007-09-17 20:15 ` Andrew Morton 2007-09-17 20:46 ` Rik van Riel 2007-09-17 20:46 ` Rik van Riel 2007-09-17 21:11 ` Andrew Morton 2007-09-17 21:11 ` Andrew Morton 2007-09-19 22:12 ` Rik van Riel 2007-09-19 22:12 ` Rik van Riel 2007-09-19 22:45 ` Andrew Morton 2007-09-19 22:45 ` Andrew Morton 2007-09-19 22:50 ` Rik van Riel 2007-09-19 22:50 ` Rik van Riel 2007-09-19 23:29 ` Christoph Lameter 2007-09-19 23:29 ` Christoph Lameter 2007-09-19 23:37 ` Andrew Morton 2007-09-19 23:37 ` Andrew Morton 2007-10-03 10:51 ` Pavel Machek 2007-10-03 10:51 ` Pavel Machek
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.