* iwlagn: order 2 page allocation failures
@ 2009-09-06 7:40 Frans Pop
2009-09-06 8:14 ` Pekka Enberg
0 siblings, 1 reply; 66+ messages in thread
From: Frans Pop @ 2009-09-06 7:40 UTC (permalink / raw)
To: linux-kernel; +Cc: linux-wireless, ipw3945-devel
Got a couple of page allocation failures today while viewing fairly
large images. System was struggling for a bit to reorganize memory
and swap, but nothing really serious. Everything recovered fairly
quickly.
Anything to look into?
System: HP 2510p; 2.6.31-rc7-56-g7c0a57d; Debian stable, KDE desktop
10:00.0 Network controller [0280]: Intel Corporation PRO/Wireless 4965 AG or AGN
[Kedron] Network Connection [8086:4229] (rev 61)
Cheers,
FJP
kernel: swapper: page allocation failure. order:2, mode:0x4020
kernel: Pid: 0, comm: swapper Not tainted 2.6.31-rc7 #15
kernel: Call Trace:
kernel: <IRQ> [<ffffffff8107909a>] __alloc_pages_nodemask+0x542/0x58a
kernel: [<ffffffff811d8a29>] ? skb_queue_tail+0x41/0x4a
kernel: [<ffffffff812568c2>] ? _spin_unlock+0x9/0xb
kernel: [<ffffffff811da2e1>] ? __alloc_skb+0x3c/0x15b
kernel: [<ffffffffa0356644>] ? iwl_rx_allocate+0xac/0x208 [iwlcore]
kernel: [<ffffffff8107913d>] __get_free_pages+0x12/0x41
kernel: [<ffffffff810982b1>] __kmalloc_track_caller+0x3b/0xec
kernel: [<ffffffff811da30b>] __alloc_skb+0x66/0x15b
kernel: [<ffffffffa0356644>] iwl_rx_allocate+0xac/0x208 [iwlcore]
kernel: [<ffffffffa03567b6>] iwl_rx_replenish_now+0x16/0x23 [iwlcore]
kernel: [<ffffffffa037d8e3>] iwl_rx_handle+0x356/0x39a [iwlagn]
kernel: [<ffffffffa00212a2>] ? scsi_io_completion+0x3a8/0x3d1 [scsi_mod]
kernel: [<ffffffffa037de27>] iwl_irq_tasklet_legacy+0x500/0x74f [iwlagn]
kernel: [<ffffffff8103dff0>] tasklet_action+0x71/0xbc
kernel: [<ffffffff8103e877>] __do_softirq+0x9b/0x12c
kernel: [<ffffffff8100cb7c>] call_softirq+0x1c/0x28
kernel: [<ffffffff8100e694>] do_softirq+0x34/0x72
kernel: [<ffffffff8103e601>] irq_exit+0x3f/0x79
kernel: [<ffffffff8100dd95>] do_IRQ+0xa3/0xba
kernel: [<ffffffff8100c413>] ret_from_intr+0x0/0xa
kernel: <EOI> [<ffffffffa0262720>] ? acpi_idle_enter_simple+0x101/0x12f [processor]
kernel: [<ffffffffa0262716>] ? acpi_idle_enter_simple+0xf7/0x12f [processor]
kernel: [<ffffffff811cd6d8>] ? cpuidle_idle_call+0x8c/0xc4
kernel: [<ffffffff8100ae0f>] ? cpu_idle+0x52/0x93
kernel: [<ffffffff81245f4d>] ? rest_init+0x61/0x63
kernel: [<ffffffff81411c3f>] ? start_kernel+0x348/0x353
kernel: [<ffffffff8141129a>] ? x86_64_start_reservations+0xaa/0xae
kernel: [<ffffffff8141137f>] ? x86_64_start_kernel+0xe1/0xe8
kernel: Mem-Info:
kernel: DMA per-cpu:
kernel: CPU 0: hi: 0, btch: 1 usd: 0
kernel: CPU 1: hi: 0, btch: 1 usd: 0
kernel: DMA32 per-cpu:
kernel: CPU 0: hi: 186, btch: 31 usd: 172
kernel: CPU 1: hi: 186, btch: 31 usd: 86
kernel: Active_anon:314043 active_file:2401 inactive_anon:105396
kernel: inactive_file:2026 unevictable:407 dirty:0 writeback:3949 unstable:0
kernel: free:10313 slab:10486 mapped:2860 pagetables:4100 bounce:0
kernel: DMA free:7924kB min:40kB low:48kB high:60kB active_anon:2828kB inactive_anon:3296kB
active_file:736kB inactive_file:664kB unevictable:0kB present:15336kB pages_scanned:0
all_unreclaimable? no
kernel: lowmem_reserve[]: 0 1976 1976 1976
kernel: DMA32 free:33328kB min:5664kB low:7080kB high:8496kB active_anon:1253344kB inactive_anon:418288kB
active_file:8868kB inactive_file:7440kB unevictable:1628kB present:2023748kB pages_scanned:0
all_unreclaimable? no
kernel: lowmem_reserve[]: 0 0 0 0
kernel: DMA: 913*4kB 36*8kB 1*16kB 0*32kB 0*64kB 1*128kB 1*256kB 1*512kB 1*1024kB 1*2048kB 0*4096kB = 7924kB
kernel: DMA32: 7198*4kB 501*8kB 1*16kB 0*32kB 0*64kB 0*128kB 0*256kB 1*512kB 0*1024kB 0*2048kB 0*4096kB = 33328kB
kernel: 63958 total pagecache pages
kernel: 59163 pages in swap cache
kernel: Swap cache stats: add 310806, delete 251643, find 16810381/16825997
kernel: Free swap = 1534944kB
kernel: Total swap = 2097144kB
kernel: 518064 pages RAM
kernel: 10324 pages reserved
kernel: 78783 pages shared
kernel: 442988 pages non-shared
kernel: iwlagn 0000:10:00.0: Can not allocate SKB buffers
kernel: swapper: page allocation failure. order:2, mode:0x4020
kernel: Pid: 0, comm: swapper Not tainted 2.6.31-rc7 #15
kernel: Call Trace:
kernel: <IRQ> [<ffffffff8107909a>] __alloc_pages_nodemask+0x542/0x58a
kernel: [<ffffffff812545d1>] ? printk+0x67/0x6e
kernel: [<ffffffffa0356644>] ? iwl_rx_allocate+0xac/0x208 [iwlcore]
kernel: [<ffffffff8107913d>] __get_free_pages+0x12/0x41
kernel: [<ffffffff810982b1>] __kmalloc_track_caller+0x3b/0xec
kernel: [<ffffffff811da30b>] __alloc_skb+0x66/0x15b
kernel: [<ffffffffa0356644>] iwl_rx_allocate+0xac/0x208 [iwlcore]
kernel: [<ffffffffa03567b6>] iwl_rx_replenish_now+0x16/0x23 [iwlcore]
kernel: [<ffffffffa037d90e>] iwl_rx_handle+0x381/0x39a [iwlagn]
kernel: [<ffffffffa00212a2>] ? scsi_io_completion+0x3a8/0x3d1 [scsi_mod]
kernel: [<ffffffffa037de27>] iwl_irq_tasklet_legacy+0x500/0x74f [iwlagn]
kernel: [<ffffffff8103dff0>] tasklet_action+0x71/0xbc
kernel: [<ffffffff8103e877>] __do_softirq+0x9b/0x12c
kernel: [<ffffffff8100cb7c>] call_softirq+0x1c/0x28
kernel: [<ffffffff8100e694>] do_softirq+0x34/0x72
kernel: [<ffffffff8103e601>] irq_exit+0x3f/0x79
kernel: [<ffffffff8100dd95>] do_IRQ+0xa3/0xba
kernel: [<ffffffff8100c413>] ret_from_intr+0x0/0xa
kernel: <EOI> [<ffffffffa0262720>] ? acpi_idle_enter_simple+0x101/0x12f [processor]
kernel: [<ffffffffa0262716>] ? acpi_idle_enter_simple+0xf7/0x12f [processor]
kernel: [<ffffffff811cd6d8>] ? cpuidle_idle_call+0x8c/0xc4
kernel: [<ffffffff8100ae0f>] ? cpu_idle+0x52/0x93
kernel: [<ffffffff81245f4d>] ? rest_init+0x61/0x63
kernel: [<ffffffff81411c3f>] ? start_kernel+0x348/0x353
kernel: [<ffffffff8141129a>] ? x86_64_start_reservations+0xaa/0xae
kernel: [<ffffffff8141137f>] ? x86_64_start_kernel+0xe1/0xe8
kernel: Mem-Info:
kernel: DMA per-cpu:
kernel: CPU 0: hi: 0, btch: 1 usd: 0
kernel: CPU 1: hi: 0, btch: 1 usd: 0
kernel: DMA32 per-cpu:
kernel: CPU 0: hi: 186, btch: 31 usd: 172
kernel: CPU 1: hi: 186, btch: 31 usd: 86
kernel: Active_anon:314043 active_file:2401 inactive_anon:105396
kernel: inactive_file:2026 unevictable:407 dirty:0 writeback:3949 unstable:0
kernel: free:10313 slab:10486 mapped:2860 pagetables:4100 bounce:0
kernel: DMA free:7924kB min:40kB low:48kB high:60kB active_anon:2828kB inactive_anon:3296kB
active_file:736kB inactive_file:664kB unevictable:0kB present:15336kB pages_scanned:0
all_unreclaimable? no
kernel: lowmem_reserve[]: 0 1976 1976 1976
kernel: DMA32 free:33328kB min:5664kB low:7080kB high:8496kB active_anon:1253344kB inactive_anon:418288kB
active_file:8868kB inactive_file:7440kB unevictable:1628kB present:2023748kB pages_scanned:0
all_unreclaimable? no
kernel: lowmem_reserve[]: 0 0 0 0
kernel: DMA: 913*4kB 36*8kB 1*16kB 0*32kB 0*64kB 1*128kB 1*256kB 1*512kB 1*1024kB 1*2048kB 0*4096kB = 7924kB
kernel: DMA32: 7198*4kB 501*8kB 1*16kB 0*32kB 0*64kB 0*128kB 0*256kB 1*512kB 0*1024kB 0*2048kB 0*4096kB = 33328kB
kernel: 63958 total pagecache pages
kernel: 59163 pages in swap cache
kernel: Swap cache stats: add 310806, delete 251643, find 16810381/16825997
kernel: Free swap = 1534944kB
kernel: Total swap = 2097144kB
kernel: 518064 pages RAM
kernel: 10324 pages reserved
kernel: 78783 pages shared
kernel: 442988 pages non-shared
kernel: iwlagn 0000:10:00.0: Can not allocate SKB buffers
^ permalink raw reply [flat|nested] 66+ messages in thread* Re: iwlagn: order 2 page allocation failures 2009-09-06 7:40 iwlagn: order 2 page allocation failures Frans Pop @ 2009-09-06 8:14 ` Pekka Enberg 2009-09-06 8:28 ` Frans Pop 0 siblings, 1 reply; 66+ messages in thread From: Pekka Enberg @ 2009-09-06 8:14 UTC (permalink / raw) To: Frans Pop Cc: linux-kernel, linux-wireless, ipw3945-devel, Mel Gorman, Andrew Morton On Sun, Sep 6, 2009 at 10:40 AM, Frans Pop<elendil@planet.nl> wrote: > Got a couple of page allocation failures today while viewing fairly > large images. System was struggling for a bit to reorganize memory > and swap, but nothing really serious. Everything recovered fairly > quickly. > > Anything to look into? > > System: HP 2510p; 2.6.31-rc7-56-g7c0a57d; Debian stable, KDE desktop > > 10:00.0 Network controller [0280]: Intel Corporation PRO/Wireless 4965 AG or AGN > [Kedron] Network Connection [8086:4229] (rev 61) Can you post your .config, please? > kernel: swapper: page allocation failure. order:2, mode:0x4020 > kernel: Pid: 0, comm: swapper Not tainted 2.6.31-rc7 #15 > kernel: Call Trace: > kernel: <IRQ> [<ffffffff8107909a>] __alloc_pages_nodemask+0x542/0x58a > kernel: [<ffffffff811d8a29>] ? skb_queue_tail+0x41/0x4a > kernel: [<ffffffff812568c2>] ? _spin_unlock+0x9/0xb > kernel: [<ffffffff811da2e1>] ? __alloc_skb+0x3c/0x15b > kernel: [<ffffffffa0356644>] ? iwl_rx_allocate+0xac/0x208 [iwlcore] > kernel: [<ffffffff8107913d>] __get_free_pages+0x12/0x41 > kernel: [<ffffffff810982b1>] __kmalloc_track_caller+0x3b/0xec > kernel: [<ffffffff811da30b>] __alloc_skb+0x66/0x15b > kernel: [<ffffffffa0356644>] iwl_rx_allocate+0xac/0x208 [iwlcore] > kernel: [<ffffffffa03567b6>] iwl_rx_replenish_now+0x16/0x23 [iwlcore] > kernel: [<ffffffffa037d8e3>] iwl_rx_handle+0x356/0x39a [iwlagn] > kernel: [<ffffffffa00212a2>] ? scsi_io_completion+0x3a8/0x3d1 [scsi_mod] > kernel: [<ffffffffa037de27>] iwl_irq_tasklet_legacy+0x500/0x74f [iwlagn] > kernel: [<ffffffff8103dff0>] tasklet_action+0x71/0xbc > kernel: [<ffffffff8103e877>] __do_softirq+0x9b/0x12c > kernel: [<ffffffff8100cb7c>] call_softirq+0x1c/0x28 > kernel: [<ffffffff8100e694>] do_softirq+0x34/0x72 > kernel: [<ffffffff8103e601>] irq_exit+0x3f/0x79 > kernel: [<ffffffff8100dd95>] do_IRQ+0xa3/0xba > kernel: [<ffffffff8100c413>] ret_from_intr+0x0/0xa > kernel: <EOI> [<ffffffffa0262720>] ? acpi_idle_enter_simple+0x101/0x12f [processor] > kernel: [<ffffffffa0262716>] ? acpi_idle_enter_simple+0xf7/0x12f [processor] > kernel: [<ffffffff811cd6d8>] ? cpuidle_idle_call+0x8c/0xc4 > kernel: [<ffffffff8100ae0f>] ? cpu_idle+0x52/0x93 > kernel: [<ffffffff81245f4d>] ? rest_init+0x61/0x63 > kernel: [<ffffffff81411c3f>] ? start_kernel+0x348/0x353 > kernel: [<ffffffff8141129a>] ? x86_64_start_reservations+0xaa/0xae > kernel: [<ffffffff8141137f>] ? x86_64_start_kernel+0xe1/0xe8 > kernel: Mem-Info: > kernel: DMA per-cpu: > kernel: CPU 0: hi: 0, btch: 1 usd: 0 > kernel: CPU 1: hi: 0, btch: 1 usd: 0 > kernel: DMA32 per-cpu: > kernel: CPU 0: hi: 186, btch: 31 usd: 172 > kernel: CPU 1: hi: 186, btch: 31 usd: 86 > kernel: Active_anon:314043 active_file:2401 inactive_anon:105396 > kernel: inactive_file:2026 unevictable:407 dirty:0 writeback:3949 unstable:0 > kernel: free:10313 slab:10486 mapped:2860 pagetables:4100 bounce:0 > kernel: DMA free:7924kB min:40kB low:48kB high:60kB active_anon:2828kB inactive_anon:3296kB > active_file:736kB inactive_file:664kB unevictable:0kB present:15336kB pages_scanned:0 > all_unreclaimable? no > kernel: lowmem_reserve[]: 0 1976 1976 1976 > kernel: DMA32 free:33328kB min:5664kB low:7080kB high:8496kB active_anon:1253344kB inactive_anon:418288kB > active_file:8868kB inactive_file:7440kB unevictable:1628kB present:2023748kB pages_scanned:0 > all_unreclaimable? no > kernel: lowmem_reserve[]: 0 0 0 0 > kernel: DMA: 913*4kB 36*8kB 1*16kB 0*32kB 0*64kB 1*128kB 1*256kB 1*512kB 1*1024kB 1*2048kB 0*4096kB = 7924kB > kernel: DMA32: 7198*4kB 501*8kB 1*16kB 0*32kB 0*64kB 0*128kB 0*256kB 1*512kB 0*1024kB 0*2048kB 0*4096kB = 33328kB > kernel: 63958 total pagecache pages > kernel: 59163 pages in swap cache > kernel: Swap cache stats: add 310806, delete 251643, find 16810381/16825997 > kernel: Free swap = 1534944kB > kernel: Total swap = 2097144kB > kernel: 518064 pages RAM > kernel: 10324 pages reserved > kernel: 78783 pages shared > kernel: 442988 pages non-shared > kernel: iwlagn 0000:10:00.0: Can not allocate SKB buffers > > kernel: swapper: page allocation failure. order:2, mode:0x4020 > kernel: Pid: 0, comm: swapper Not tainted 2.6.31-rc7 #15 > kernel: Call Trace: > kernel: <IRQ> [<ffffffff8107909a>] __alloc_pages_nodemask+0x542/0x58a > kernel: [<ffffffff812545d1>] ? printk+0x67/0x6e > kernel: [<ffffffffa0356644>] ? iwl_rx_allocate+0xac/0x208 [iwlcore] > kernel: [<ffffffff8107913d>] __get_free_pages+0x12/0x41 > kernel: [<ffffffff810982b1>] __kmalloc_track_caller+0x3b/0xec > kernel: [<ffffffff811da30b>] __alloc_skb+0x66/0x15b > kernel: [<ffffffffa0356644>] iwl_rx_allocate+0xac/0x208 [iwlcore] > kernel: [<ffffffffa03567b6>] iwl_rx_replenish_now+0x16/0x23 [iwlcore] > kernel: [<ffffffffa037d90e>] iwl_rx_handle+0x381/0x39a [iwlagn] > kernel: [<ffffffffa00212a2>] ? scsi_io_completion+0x3a8/0x3d1 [scsi_mod] > kernel: [<ffffffffa037de27>] iwl_irq_tasklet_legacy+0x500/0x74f [iwlagn] > kernel: [<ffffffff8103dff0>] tasklet_action+0x71/0xbc > kernel: [<ffffffff8103e877>] __do_softirq+0x9b/0x12c > kernel: [<ffffffff8100cb7c>] call_softirq+0x1c/0x28 > kernel: [<ffffffff8100e694>] do_softirq+0x34/0x72 > kernel: [<ffffffff8103e601>] irq_exit+0x3f/0x79 > kernel: [<ffffffff8100dd95>] do_IRQ+0xa3/0xba > kernel: [<ffffffff8100c413>] ret_from_intr+0x0/0xa > kernel: <EOI> [<ffffffffa0262720>] ? acpi_idle_enter_simple+0x101/0x12f [processor] > kernel: [<ffffffffa0262716>] ? acpi_idle_enter_simple+0xf7/0x12f [processor] > kernel: [<ffffffff811cd6d8>] ? cpuidle_idle_call+0x8c/0xc4 > kernel: [<ffffffff8100ae0f>] ? cpu_idle+0x52/0x93 > kernel: [<ffffffff81245f4d>] ? rest_init+0x61/0x63 > kernel: [<ffffffff81411c3f>] ? start_kernel+0x348/0x353 > kernel: [<ffffffff8141129a>] ? x86_64_start_reservations+0xaa/0xae > kernel: [<ffffffff8141137f>] ? x86_64_start_kernel+0xe1/0xe8 > kernel: Mem-Info: > kernel: DMA per-cpu: > kernel: CPU 0: hi: 0, btch: 1 usd: 0 > kernel: CPU 1: hi: 0, btch: 1 usd: 0 > kernel: DMA32 per-cpu: > kernel: CPU 0: hi: 186, btch: 31 usd: 172 > kernel: CPU 1: hi: 186, btch: 31 usd: 86 > kernel: Active_anon:314043 active_file:2401 inactive_anon:105396 > kernel: inactive_file:2026 unevictable:407 dirty:0 writeback:3949 unstable:0 > kernel: free:10313 slab:10486 mapped:2860 pagetables:4100 bounce:0 > kernel: DMA free:7924kB min:40kB low:48kB high:60kB active_anon:2828kB inactive_anon:3296kB > active_file:736kB inactive_file:664kB unevictable:0kB present:15336kB pages_scanned:0 > all_unreclaimable? no > kernel: lowmem_reserve[]: 0 1976 1976 1976 > kernel: DMA32 free:33328kB min:5664kB low:7080kB high:8496kB active_anon:1253344kB inactive_anon:418288kB > active_file:8868kB inactive_file:7440kB unevictable:1628kB present:2023748kB pages_scanned:0 > all_unreclaimable? no > kernel: lowmem_reserve[]: 0 0 0 0 > kernel: DMA: 913*4kB 36*8kB 1*16kB 0*32kB 0*64kB 1*128kB 1*256kB 1*512kB 1*1024kB 1*2048kB 0*4096kB = 7924kB > kernel: DMA32: 7198*4kB 501*8kB 1*16kB 0*32kB 0*64kB 0*128kB 0*256kB 1*512kB 0*1024kB 0*2048kB 0*4096kB = 33328kB > kernel: 63958 total pagecache pages > kernel: 59163 pages in swap cache > kernel: Swap cache stats: add 310806, delete 251643, find 16810381/16825997 > kernel: Free swap = 1534944kB > kernel: Total swap = 2097144kB > kernel: 518064 pages RAM > kernel: 10324 pages reserved > kernel: 78783 pages shared > kernel: 442988 pages non-shared > kernel: iwlagn 0000:10:00.0: Can not allocate SKB buffers > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: iwlagn: order 2 page allocation failures 2009-09-06 8:14 ` Pekka Enberg @ 2009-09-06 8:28 ` Frans Pop 2009-09-06 8:35 ` Pekka Enberg 0 siblings, 1 reply; 66+ messages in thread From: Frans Pop @ 2009-09-06 8:28 UTC (permalink / raw) To: Pekka Enberg Cc: linux-kernel, linux-wireless, ipw3945-devel, Mel Gorman, Andrew Morton [-- Attachment #1: Type: text/plain, Size: 655 bytes --] On Sunday 06 September 2009, Pekka Enberg wrote: > On Sun, Sep 6, 2009 at 10:40 AM, Frans Pop<elendil@planet.nl> wrote: > > Got a couple of page allocation failures today while viewing fairly > > large images. System was struggling for a bit to reorganize memory > > and swap, but nothing really serious. Everything recovered fairly > > quickly. > > > > Anything to look into? > > > > System: HP 2510p; 2.6.31-rc7-56-g7c0a57d; Debian stable, KDE desktop > > > > 10:00.0 Network controller [0280]: Intel Corporation PRO/Wireless > > 4965 AG or AGN [Kedron] Network Connection [8086:4229] (rev 61) > > Can you post your .config, please? Attached. Thanks. [-- Attachment #2: config-2.6.31-rc7 --] [-- Type: text/plain, Size: 70214 bytes --] # # Automatically generated make config: don't edit # Linux kernel version: 2.6.31-rc6 # Thu Aug 20 13:09:17 2009 # CONFIG_64BIT=y # CONFIG_X86_32 is not set CONFIG_X86_64=y CONFIG_X86=y CONFIG_OUTPUT_FORMAT="elf64-x86-64" CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig" CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_FAST_CMPXCHG_LOCAL=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_RWSEM_GENERIC_SPINLOCK=y # CONFIG_RWSEM_XCHGADD_ALGORITHM is not set CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_DEFAULT_IDLE=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_HAVE_DYNAMIC_PER_CPU_AREA=y CONFIG_HAVE_CPUMASK_OF_CPU_MAP=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ZONE_DMA32=y CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_AUDIT_ARCH=y CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_PENDING_IRQ=y CONFIG_USE_GENERIC_SMP_HELPERS=y CONFIG_X86_64_SMP=y CONFIG_X86_HT=y CONFIG_X86_TRAMPOLINE=y # CONFIG_KTIME_SCALAR is not set CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" CONFIG_CONSTRUCTORS=y # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_KERNEL_GZIP=y # CONFIG_KERNEL_BZIP2 is not set # CONFIG_KERNEL_LZMA is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_POSIX_MQUEUE_SYSCTL=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y CONFIG_TASKSTATS=y CONFIG_TASK_DELAY_ACCT=y CONFIG_TASK_XACCT=y CONFIG_TASK_IO_ACCOUNTING=y CONFIG_AUDIT=y # CONFIG_AUDITSYSCALL is not set # # RCU Subsystem # CONFIG_CLASSIC_RCU=y # CONFIG_TREE_RCU is not set # CONFIG_PREEMPT_RCU is not set # CONFIG_TREE_RCU_TRACE is not set # CONFIG_PREEMPT_RCU_TRACE is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=17 CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y # CONFIG_GROUP_SCHED is not set # CONFIG_CGROUPS is not set CONFIG_SYSFS_DEPRECATED=y CONFIG_SYSFS_DEPRECATED_V2=y CONFIG_RELAY=y CONFIG_NAMESPACES=y # CONFIG_UTS_NS is not set # CONFIG_IPC_NS is not set # CONFIG_USER_NS is not set # CONFIG_PID_NS is not set # CONFIG_NET_NS is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_RD_GZIP=y CONFIG_RD_BZIP2=y CONFIG_RD_LZMA=y CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_ANON_INODES=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_PCSPKR_PLATFORM=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_AIO=y CONFIG_HAVE_PERF_COUNTERS=y # # Performance Counters # # CONFIG_PERF_COUNTERS is not set CONFIG_VM_EVENT_COUNTERS=y CONFIG_PCI_QUIRKS=y CONFIG_SLUB_DEBUG=y CONFIG_STRIP_ASM_SYMS=y # CONFIG_COMPAT_BRK is not set # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLOB is not set # CONFIG_PROFILING is not set # CONFIG_MARKERS is not set CONFIG_HAVE_OPROFILE=y # CONFIG_KPROBES is not set CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y CONFIG_HAVE_IOREMAP_PROT=y CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_ARCH_TRACEHOOK=y CONFIG_HAVE_DMA_ATTRS=y CONFIG_HAVE_DMA_API_DEBUG=y # # GCOV-based kernel profiling # # CONFIG_GCOV_KERNEL is not set # CONFIG_SLOW_WORK is not set # CONFIG_HAVE_GENERIC_DMA_COHERENT is not set CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y CONFIG_BASE_SMALL=0 CONFIG_MODULES=y # CONFIG_MODULE_FORCE_LOAD is not set CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_MODVERSIONS=y # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y # CONFIG_BLK_DEV_BSG is not set # CONFIG_BLK_DEV_INTEGRITY is not set CONFIG_BLOCK_COMPAT=y # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="cfq" CONFIG_FREEZER=y # # Processor type and features # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_SMP=y # CONFIG_SPARSE_IRQ is not set # CONFIG_X86_MPPARSE is not set # CONFIG_X86_EXTENDED_PLATFORM is not set CONFIG_SCHED_OMIT_FRAME_POINTER=y # CONFIG_PARAVIRT_GUEST is not set # CONFIG_MEMTEST is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_MVIAC7 is not set # CONFIG_MPSC is not set # CONFIG_MCORE2 is not set CONFIG_GENERIC_CPU=y CONFIG_X86_CPU=y CONFIG_X86_L1_CACHE_BYTES=64 CONFIG_X86_INTERNODE_CACHE_BYTES=64 CONFIG_X86_CMPXCHG=y CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_TSC=y CONFIG_X86_CMPXCHG64=y CONFIG_X86_CMOV=y CONFIG_X86_MINIMUM_CPU_FAMILY=64 CONFIG_X86_DEBUGCTLMSR=y CONFIG_CPU_SUP_INTEL=y CONFIG_CPU_SUP_AMD=y CONFIG_CPU_SUP_CENTAUR=y # CONFIG_X86_DS is not set CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y CONFIG_DMI=y CONFIG_GART_IOMMU=y # CONFIG_CALGARY_IOMMU is not set # CONFIG_AMD_IOMMU is not set CONFIG_SWIOTLB=y CONFIG_IOMMU_HELPER=y # CONFIG_IOMMU_API is not set # CONFIG_MAXSMP is not set CONFIG_NR_CPUS=8 # CONFIG_SCHED_SMT is not set CONFIG_SCHED_MC=y # CONFIG_PREEMPT_NONE is not set CONFIG_PREEMPT_VOLUNTARY=y # CONFIG_PREEMPT is not set CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y # CONFIG_X86_REROUTE_FOR_BROKEN_BOOT_IRQS is not set CONFIG_X86_MCE=y CONFIG_X86_NEW_MCE=y CONFIG_X86_MCE_INTEL=y # CONFIG_X86_MCE_AMD is not set CONFIG_X86_MCE_THRESHOLD=y # CONFIG_X86_MCE_INJECT is not set CONFIG_X86_THERMAL_VECTOR=y # CONFIG_I8K is not set # CONFIG_MICROCODE is not set CONFIG_X86_MSR=m CONFIG_X86_CPUID=m CONFIG_X86_CPU_DEBUG=m CONFIG_ARCH_PHYS_ADDR_T_64BIT=y CONFIG_DIRECT_GBPAGES=y # CONFIG_NUMA is not set CONFIG_ARCH_SPARSEMEM_DEFAULT=y CONFIG_ARCH_SPARSEMEM_ENABLE=y CONFIG_ARCH_SELECT_MEMORY_MODEL=y CONFIG_SELECT_MEMORY_MODEL=y # CONFIG_FLATMEM_MANUAL is not set # CONFIG_DISCONTIGMEM_MANUAL is not set CONFIG_SPARSEMEM_MANUAL=y CONFIG_SPARSEMEM=y CONFIG_HAVE_MEMORY_PRESENT=y CONFIG_SPARSEMEM_EXTREME=y CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y CONFIG_SPARSEMEM_VMEMMAP=y # # Memory hotplug is currently incompatible with Software Suspend # CONFIG_PAGEFLAGS_EXTENDED=y CONFIG_SPLIT_PTLOCK_CPUS=4 CONFIG_PHYS_ADDR_T_64BIT=y CONFIG_ZONE_DMA_FLAG=1 CONFIG_BOUNCE=y CONFIG_VIRT_TO_BUS=y CONFIG_HAVE_MLOCK=y CONFIG_HAVE_MLOCKED_PAGE_BIT=y CONFIG_DEFAULT_MMAP_MIN_ADDR=4096 # CONFIG_X86_CHECK_BIOS_CORRUPTION is not set # CONFIG_X86_RESERVE_LOW_64K is not set CONFIG_MTRR=y CONFIG_MTRR_SANITIZER=y CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=0 CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1 CONFIG_X86_PAT=y # CONFIG_EFI is not set CONFIG_SECCOMP=y # CONFIG_CC_STACKPROTECTOR is not set # CONFIG_HZ_100 is not set CONFIG_HZ_250=y # CONFIG_HZ_300 is not set # CONFIG_HZ_1000 is not set CONFIG_HZ=250 CONFIG_SCHED_HRTICK=y CONFIG_KEXEC=y # CONFIG_CRASH_DUMP is not set # CONFIG_KEXEC_JUMP is not set CONFIG_PHYSICAL_START=0x1000000 # CONFIG_RELOCATABLE is not set CONFIG_PHYSICAL_ALIGN=0x1000000 CONFIG_HOTPLUG_CPU=y CONFIG_COMPAT_VDSO=y # CONFIG_CMDLINE_BOOL is not set CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y # # Power management and ACPI options # CONFIG_ARCH_HIBERNATION_HEADER=y CONFIG_PM=y # CONFIG_PM_DEBUG is not set CONFIG_PM_SLEEP_SMP=y CONFIG_PM_SLEEP=y CONFIG_SUSPEND=y CONFIG_SUSPEND_FREEZER=y CONFIG_HIBERNATION_NVS=y CONFIG_HIBERNATION=y CONFIG_PM_STD_PARTITION="" CONFIG_ACPI=y CONFIG_ACPI_SLEEP=y CONFIG_ACPI_PROCFS=y CONFIG_ACPI_PROCFS_POWER=y CONFIG_ACPI_SYSFS_POWER=y CONFIG_ACPI_PROC_EVENT=y CONFIG_ACPI_AC=m CONFIG_ACPI_BATTERY=m CONFIG_ACPI_BUTTON=m CONFIG_ACPI_VIDEO=m CONFIG_ACPI_FAN=m CONFIG_ACPI_DOCK=y CONFIG_ACPI_PROCESSOR=m CONFIG_ACPI_HOTPLUG_CPU=y CONFIG_ACPI_THERMAL=m # CONFIG_ACPI_CUSTOM_DSDT is not set CONFIG_ACPI_CUSTOM_DSDT_INITRD=y CONFIG_ACPI_BLACKLIST_YEAR=0 # CONFIG_ACPI_DEBUG is not set # CONFIG_ACPI_PCI_SLOT is not set CONFIG_X86_PM_TIMER=y CONFIG_ACPI_CONTAINER=m CONFIG_ACPI_SBS=m # # CPU Frequency scaling # CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_TABLE=y # CONFIG_CPU_FREQ_DEBUG is not set CONFIG_CPU_FREQ_STAT=m # CONFIG_CPU_FREQ_STAT_DETAILS is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y # CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set CONFIG_CPU_FREQ_GOV_PERFORMANCE=y CONFIG_CPU_FREQ_GOV_POWERSAVE=m CONFIG_CPU_FREQ_GOV_USERSPACE=m CONFIG_CPU_FREQ_GOV_ONDEMAND=y CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m # # CPUFreq processor drivers # CONFIG_X86_ACPI_CPUFREQ=m # CONFIG_X86_POWERNOW_K8 is not set # CONFIG_X86_SPEEDSTEP_CENTRINO is not set # CONFIG_X86_P4_CLOCKMOD is not set # # shared options # # CONFIG_X86_SPEEDSTEP_LIB is not set CONFIG_CPU_IDLE=y CONFIG_CPU_IDLE_GOV_LADDER=y CONFIG_CPU_IDLE_GOV_MENU=y # # Memory power savings # # CONFIG_I7300_IDLE is not set # # Bus options (PCI etc.) # CONFIG_PCI=y CONFIG_PCI_DIRECT=y CONFIG_PCI_MMCONFIG=y CONFIG_PCI_DOMAINS=y # CONFIG_DMAR is not set # CONFIG_INTR_REMAP is not set CONFIG_PCIEPORTBUS=y CONFIG_PCIEAER=y # CONFIG_PCIE_ECRC is not set # CONFIG_PCIEAER_INJECT is not set # CONFIG_PCIEASPM is not set CONFIG_ARCH_SUPPORTS_MSI=y CONFIG_PCI_MSI=y # CONFIG_PCI_LEGACY is not set # CONFIG_PCI_DEBUG is not set # CONFIG_PCI_STUB is not set CONFIG_HT_IRQ=y # CONFIG_PCI_IOV is not set CONFIG_ISA_DMA_API=y CONFIG_K8_NB=y CONFIG_PCCARD=m # CONFIG_PCMCIA_DEBUG is not set CONFIG_PCMCIA=m CONFIG_PCMCIA_LOAD_CIS=y CONFIG_PCMCIA_IOCTL=y CONFIG_CARDBUS=y # # PC-card bridges # CONFIG_YENTA=m CONFIG_YENTA_O2=y CONFIG_YENTA_RICOH=y CONFIG_YENTA_TI=y CONFIG_YENTA_ENE_TUNE=y CONFIG_YENTA_TOSHIBA=y # CONFIG_PD6729 is not set # CONFIG_I82092 is not set CONFIG_PCCARD_NONSTATIC=m # CONFIG_HOTPLUG_PCI is not set # # Executable file formats / Emulations # CONFIG_BINFMT_ELF=y CONFIG_COMPAT_BINFMT_ELF=y # CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set # CONFIG_HAVE_AOUT is not set CONFIG_BINFMT_MISC=m CONFIG_IA32_EMULATION=y CONFIG_IA32_AOUT=y CONFIG_COMPAT=y CONFIG_COMPAT_FOR_U64_ALIGNMENT=y CONFIG_SYSVIPC_COMPAT=y CONFIG_NET=y # # Networking options # CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_UNIX=y CONFIG_XFRM=y CONFIG_XFRM_USER=m # CONFIG_XFRM_SUB_POLICY is not set # CONFIG_XFRM_MIGRATE is not set # CONFIG_XFRM_STATISTICS is not set CONFIG_XFRM_IPCOMP=m CONFIG_NET_KEY=m # CONFIG_NET_KEY_MIGRATE is not set CONFIG_INET=y CONFIG_IP_MULTICAST=y CONFIG_IP_ADVANCED_ROUTER=y CONFIG_ASK_IP_FIB_HASH=y # CONFIG_IP_FIB_TRIE is not set CONFIG_IP_FIB_HASH=y CONFIG_IP_MULTIPLE_TABLES=y CONFIG_IP_ROUTE_MULTIPATH=y CONFIG_IP_ROUTE_VERBOSE=y # CONFIG_IP_PNP is not set CONFIG_NET_IPIP=m CONFIG_NET_IPGRE=m CONFIG_NET_IPGRE_BROADCAST=y CONFIG_IP_MROUTE=y CONFIG_IP_PIMSM_V1=y CONFIG_IP_PIMSM_V2=y # CONFIG_ARPD is not set CONFIG_SYN_COOKIES=y CONFIG_INET_AH=m CONFIG_INET_ESP=m CONFIG_INET_IPCOMP=m CONFIG_INET_XFRM_TUNNEL=m CONFIG_INET_TUNNEL=m CONFIG_INET_XFRM_MODE_TRANSPORT=m CONFIG_INET_XFRM_MODE_TUNNEL=m CONFIG_INET_XFRM_MODE_BEET=m CONFIG_INET_LRO=y CONFIG_INET_DIAG=m CONFIG_INET_TCP_DIAG=m # CONFIG_TCP_CONG_ADVANCED is not set CONFIG_TCP_CONG_CUBIC=y CONFIG_DEFAULT_TCP_CONG="cubic" # CONFIG_TCP_MD5SIG is not set CONFIG_IPV6=m CONFIG_IPV6_PRIVACY=y # CONFIG_IPV6_ROUTER_PREF is not set # CONFIG_IPV6_OPTIMISTIC_DAD is not set CONFIG_INET6_AH=m CONFIG_INET6_ESP=m CONFIG_INET6_IPCOMP=m # CONFIG_IPV6_MIP6 is not set CONFIG_INET6_XFRM_TUNNEL=m CONFIG_INET6_TUNNEL=m CONFIG_INET6_XFRM_MODE_TRANSPORT=m CONFIG_INET6_XFRM_MODE_TUNNEL=m CONFIG_INET6_XFRM_MODE_BEET=m CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION=m CONFIG_IPV6_SIT=m CONFIG_IPV6_NDISC_NODETYPE=y CONFIG_IPV6_TUNNEL=m # CONFIG_IPV6_MULTIPLE_TABLES is not set # CONFIG_IPV6_MROUTE is not set # CONFIG_NETLABEL is not set CONFIG_NETWORK_SECMARK=y CONFIG_NETFILTER=y # CONFIG_NETFILTER_DEBUG is not set CONFIG_NETFILTER_ADVANCED=y CONFIG_BRIDGE_NETFILTER=y # # Core Netfilter Configuration # CONFIG_NETFILTER_NETLINK=m CONFIG_NETFILTER_NETLINK_QUEUE=m CONFIG_NETFILTER_NETLINK_LOG=m CONFIG_NF_CONNTRACK=m CONFIG_NF_CT_ACCT=y CONFIG_NF_CONNTRACK_MARK=y CONFIG_NF_CONNTRACK_SECMARK=y CONFIG_NF_CONNTRACK_EVENTS=y # CONFIG_NF_CT_PROTO_DCCP is not set CONFIG_NF_CT_PROTO_GRE=m CONFIG_NF_CT_PROTO_SCTP=m # CONFIG_NF_CT_PROTO_UDPLITE is not set CONFIG_NF_CONNTRACK_AMANDA=m CONFIG_NF_CONNTRACK_FTP=m CONFIG_NF_CONNTRACK_H323=m CONFIG_NF_CONNTRACK_IRC=m CONFIG_NF_CONNTRACK_NETBIOS_NS=m CONFIG_NF_CONNTRACK_PPTP=m CONFIG_NF_CONNTRACK_SANE=m CONFIG_NF_CONNTRACK_SIP=m CONFIG_NF_CONNTRACK_TFTP=m CONFIG_NF_CT_NETLINK=m CONFIG_NETFILTER_TPROXY=m CONFIG_NETFILTER_XTABLES=m CONFIG_NETFILTER_XT_TARGET_CLASSIFY=m CONFIG_NETFILTER_XT_TARGET_CONNMARK=m CONFIG_NETFILTER_XT_TARGET_CONNSECMARK=m CONFIG_NETFILTER_XT_TARGET_DSCP=m CONFIG_NETFILTER_XT_TARGET_HL=m # CONFIG_NETFILTER_XT_TARGET_LED is not set CONFIG_NETFILTER_XT_TARGET_MARK=m CONFIG_NETFILTER_XT_TARGET_NFLOG=m CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m CONFIG_NETFILTER_XT_TARGET_NOTRACK=m CONFIG_NETFILTER_XT_TARGET_RATEEST=m CONFIG_NETFILTER_XT_TARGET_TPROXY=m CONFIG_NETFILTER_XT_TARGET_TRACE=m CONFIG_NETFILTER_XT_TARGET_SECMARK=m CONFIG_NETFILTER_XT_TARGET_TCPMSS=m CONFIG_NETFILTER_XT_TARGET_TCPOPTSTRIP=m # CONFIG_NETFILTER_XT_MATCH_CLUSTER is not set CONFIG_NETFILTER_XT_MATCH_COMMENT=m CONFIG_NETFILTER_XT_MATCH_CONNBYTES=m CONFIG_NETFILTER_XT_MATCH_CONNLIMIT=m CONFIG_NETFILTER_XT_MATCH_CONNMARK=m CONFIG_NETFILTER_XT_MATCH_CONNTRACK=m CONFIG_NETFILTER_XT_MATCH_DCCP=m CONFIG_NETFILTER_XT_MATCH_DSCP=m CONFIG_NETFILTER_XT_MATCH_ESP=m CONFIG_NETFILTER_XT_MATCH_HASHLIMIT=m CONFIG_NETFILTER_XT_MATCH_HELPER=m CONFIG_NETFILTER_XT_MATCH_HL=m CONFIG_NETFILTER_XT_MATCH_IPRANGE=m CONFIG_NETFILTER_XT_MATCH_LENGTH=m CONFIG_NETFILTER_XT_MATCH_LIMIT=m CONFIG_NETFILTER_XT_MATCH_MAC=m CONFIG_NETFILTER_XT_MATCH_MARK=m CONFIG_NETFILTER_XT_MATCH_MULTIPORT=m CONFIG_NETFILTER_XT_MATCH_OWNER=m CONFIG_NETFILTER_XT_MATCH_POLICY=m CONFIG_NETFILTER_XT_MATCH_PHYSDEV=m CONFIG_NETFILTER_XT_MATCH_PKTTYPE=m CONFIG_NETFILTER_XT_MATCH_QUOTA=m CONFIG_NETFILTER_XT_MATCH_RATEEST=m CONFIG_NETFILTER_XT_MATCH_REALM=m CONFIG_NETFILTER_XT_MATCH_RECENT=m # CONFIG_NETFILTER_XT_MATCH_RECENT_PROC_COMPAT is not set CONFIG_NETFILTER_XT_MATCH_SCTP=m CONFIG_NETFILTER_XT_MATCH_SOCKET=m CONFIG_NETFILTER_XT_MATCH_STATE=m CONFIG_NETFILTER_XT_MATCH_STATISTIC=m CONFIG_NETFILTER_XT_MATCH_STRING=m CONFIG_NETFILTER_XT_MATCH_TCPMSS=m CONFIG_NETFILTER_XT_MATCH_TIME=m CONFIG_NETFILTER_XT_MATCH_U32=m CONFIG_NETFILTER_XT_MATCH_OSF=m # CONFIG_IP_VS is not set # # IP: Netfilter Configuration # CONFIG_NF_DEFRAG_IPV4=m CONFIG_NF_CONNTRACK_IPV4=m CONFIG_NF_CONNTRACK_PROC_COMPAT=y CONFIG_IP_NF_QUEUE=m CONFIG_IP_NF_IPTABLES=m CONFIG_IP_NF_MATCH_ADDRTYPE=m CONFIG_IP_NF_MATCH_AH=m CONFIG_IP_NF_MATCH_ECN=m CONFIG_IP_NF_MATCH_TTL=m CONFIG_IP_NF_FILTER=m CONFIG_IP_NF_TARGET_REJECT=m CONFIG_IP_NF_TARGET_LOG=m CONFIG_IP_NF_TARGET_ULOG=m CONFIG_NF_NAT=m CONFIG_NF_NAT_NEEDED=y CONFIG_IP_NF_TARGET_MASQUERADE=m CONFIG_IP_NF_TARGET_NETMAP=m CONFIG_IP_NF_TARGET_REDIRECT=m CONFIG_NF_NAT_SNMP_BASIC=m CONFIG_NF_NAT_PROTO_GRE=m CONFIG_NF_NAT_PROTO_SCTP=m CONFIG_NF_NAT_FTP=m CONFIG_NF_NAT_IRC=m CONFIG_NF_NAT_TFTP=m CONFIG_NF_NAT_AMANDA=m CONFIG_NF_NAT_PPTP=m CONFIG_NF_NAT_H323=m CONFIG_NF_NAT_SIP=m CONFIG_IP_NF_MANGLE=m CONFIG_IP_NF_TARGET_CLUSTERIP=m CONFIG_IP_NF_TARGET_ECN=m CONFIG_IP_NF_TARGET_TTL=m CONFIG_IP_NF_RAW=m # CONFIG_IP_NF_SECURITY is not set CONFIG_IP_NF_ARPTABLES=m CONFIG_IP_NF_ARPFILTER=m CONFIG_IP_NF_ARP_MANGLE=m # # IPv6: Netfilter Configuration # CONFIG_NF_CONNTRACK_IPV6=m CONFIG_IP6_NF_QUEUE=m CONFIG_IP6_NF_IPTABLES=m CONFIG_IP6_NF_MATCH_AH=m CONFIG_IP6_NF_MATCH_EUI64=m CONFIG_IP6_NF_MATCH_FRAG=m CONFIG_IP6_NF_MATCH_OPTS=m CONFIG_IP6_NF_MATCH_HL=m CONFIG_IP6_NF_MATCH_IPV6HEADER=m CONFIG_IP6_NF_MATCH_MH=m CONFIG_IP6_NF_MATCH_RT=m CONFIG_IP6_NF_TARGET_HL=m CONFIG_IP6_NF_TARGET_LOG=m CONFIG_IP6_NF_FILTER=m CONFIG_IP6_NF_TARGET_REJECT=m CONFIG_IP6_NF_MANGLE=m CONFIG_IP6_NF_RAW=m # CONFIG_IP6_NF_SECURITY is not set # CONFIG_BRIDGE_NF_EBTABLES is not set CONFIG_IP_DCCP=m CONFIG_INET_DCCP_DIAG=m # # DCCP CCIDs Configuration (EXPERIMENTAL) # # CONFIG_IP_DCCP_CCID2_DEBUG is not set CONFIG_IP_DCCP_CCID3=y # CONFIG_IP_DCCP_CCID3_DEBUG is not set CONFIG_IP_DCCP_CCID3_RTO=100 CONFIG_IP_DCCP_TFRC_LIB=y # # DCCP Kernel Hacking # # CONFIG_IP_DCCP_DEBUG is not set CONFIG_IP_SCTP=m # CONFIG_SCTP_DBG_MSG is not set # CONFIG_SCTP_DBG_OBJCNT is not set # CONFIG_SCTP_HMAC_NONE is not set # CONFIG_SCTP_HMAC_SHA1 is not set CONFIG_SCTP_HMAC_MD5=y # CONFIG_TIPC is not set # CONFIG_ATM is not set CONFIG_STP=m CONFIG_BRIDGE=m # CONFIG_NET_DSA is not set CONFIG_VLAN_8021Q=m # CONFIG_VLAN_8021Q_GVRP is not set # CONFIG_DECNET is not set CONFIG_LLC=m # CONFIG_LLC2 is not set # CONFIG_IPX is not set # CONFIG_ATALK is not set # CONFIG_X25 is not set # CONFIG_LAPB is not set # CONFIG_ECONET is not set # CONFIG_WAN_ROUTER is not set # CONFIG_PHONET is not set # CONFIG_IEEE802154 is not set CONFIG_NET_SCHED=y # # Queueing/Scheduling # CONFIG_NET_SCH_CBQ=m CONFIG_NET_SCH_HTB=m CONFIG_NET_SCH_HFSC=m CONFIG_NET_SCH_PRIO=m # CONFIG_NET_SCH_MULTIQ is not set CONFIG_NET_SCH_RED=m CONFIG_NET_SCH_SFQ=m CONFIG_NET_SCH_TEQL=m CONFIG_NET_SCH_TBF=m CONFIG_NET_SCH_GRED=m CONFIG_NET_SCH_DSMARK=m CONFIG_NET_SCH_NETEM=m # CONFIG_NET_SCH_DRR is not set CONFIG_NET_SCH_INGRESS=m # # Classification # CONFIG_NET_CLS=y CONFIG_NET_CLS_BASIC=m CONFIG_NET_CLS_TCINDEX=m CONFIG_NET_CLS_ROUTE4=m CONFIG_NET_CLS_ROUTE=y CONFIG_NET_CLS_FW=m CONFIG_NET_CLS_U32=m CONFIG_CLS_U32_PERF=y CONFIG_CLS_U32_MARK=y CONFIG_NET_CLS_RSVP=m CONFIG_NET_CLS_RSVP6=m # CONFIG_NET_CLS_FLOW is not set CONFIG_NET_EMATCH=y CONFIG_NET_EMATCH_STACK=32 CONFIG_NET_EMATCH_CMP=m CONFIG_NET_EMATCH_NBYTE=m CONFIG_NET_EMATCH_U32=m CONFIG_NET_EMATCH_META=m CONFIG_NET_EMATCH_TEXT=m CONFIG_NET_CLS_ACT=y CONFIG_NET_ACT_POLICE=m CONFIG_NET_ACT_GACT=m CONFIG_GACT_PROB=y CONFIG_NET_ACT_MIRRED=m CONFIG_NET_ACT_IPT=m CONFIG_NET_ACT_NAT=m CONFIG_NET_ACT_PEDIT=m CONFIG_NET_ACT_SIMP=m # CONFIG_NET_ACT_SKBEDIT is not set CONFIG_NET_CLS_IND=y CONFIG_NET_SCH_FIFO=y # CONFIG_DCB is not set # # Network testing # CONFIG_NET_PKTGEN=m # CONFIG_HAMRADIO is not set # CONFIG_CAN is not set # CONFIG_IRDA is not set CONFIG_BT=m CONFIG_BT_L2CAP=m CONFIG_BT_SCO=m CONFIG_BT_RFCOMM=m CONFIG_BT_RFCOMM_TTY=y CONFIG_BT_BNEP=m CONFIG_BT_BNEP_MC_FILTER=y CONFIG_BT_BNEP_PROTO_FILTER=y CONFIG_BT_HIDP=m # # Bluetooth device drivers # CONFIG_BT_HCIBTUSB=m # CONFIG_BT_HCIBTSDIO is not set # CONFIG_BT_HCIUART is not set # CONFIG_BT_HCIBCM203X is not set # CONFIG_BT_HCIBPA10X is not set # CONFIG_BT_HCIBFUSB is not set # CONFIG_BT_HCIDTL1 is not set # CONFIG_BT_HCIBT3C is not set # CONFIG_BT_HCIBLUECARD is not set # CONFIG_BT_HCIBTUART is not set # CONFIG_BT_HCIVHCI is not set CONFIG_AF_RXRPC=m # CONFIG_AF_RXRPC_DEBUG is not set CONFIG_RXKAD=m CONFIG_FIB_RULES=y CONFIG_WIRELESS=y CONFIG_CFG80211=m # CONFIG_CFG80211_REG_DEBUG is not set # CONFIG_CFG80211_DEBUGFS is not set CONFIG_WIRELESS_OLD_REGULATORY=y CONFIG_WIRELESS_EXT=y CONFIG_WIRELESS_EXT_SYSFS=y CONFIG_LIB80211=m # CONFIG_LIB80211_DEBUG is not set CONFIG_MAC80211=m CONFIG_MAC80211_DEFAULT_PS=y CONFIG_MAC80211_DEFAULT_PS_VALUE=1 # # Rate control algorithm selection # CONFIG_MAC80211_RC_MINSTREL=y # CONFIG_MAC80211_RC_DEFAULT_PID is not set CONFIG_MAC80211_RC_DEFAULT_MINSTREL=y CONFIG_MAC80211_RC_DEFAULT="minstrel" CONFIG_MAC80211_LEDS=y # CONFIG_MAC80211_DEBUGFS is not set # CONFIG_MAC80211_DEBUG_MENU is not set # CONFIG_WIMAX is not set CONFIG_RFKILL=m CONFIG_RFKILL_LEDS=y CONFIG_RFKILL_INPUT=y # CONFIG_NET_9P is not set # # Device Drivers # # # Generic Driver Options # CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" CONFIG_STANDALONE=y CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_FW_LOADER=y CONFIG_FIRMWARE_IN_KERNEL=y CONFIG_EXTRA_FIRMWARE="" # CONFIG_DEBUG_DRIVER is not set # CONFIG_DEBUG_DEVRES is not set # CONFIG_SYS_HYPERVISOR is not set CONFIG_CONNECTOR=m CONFIG_MTD=m # CONFIG_MTD_DEBUG is not set # CONFIG_MTD_CONCAT is not set # CONFIG_MTD_PARTITIONS is not set # CONFIG_MTD_TESTS is not set # # User Modules And Translation Layers # # CONFIG_MTD_CHAR is not set # CONFIG_MTD_BLKDEVS is not set # CONFIG_MTD_BLOCK is not set # CONFIG_MTD_BLOCK_RO is not set # CONFIG_FTL is not set # CONFIG_NFTL is not set # CONFIG_INFTL is not set # CONFIG_RFD_FTL is not set # CONFIG_SSFDC is not set # CONFIG_MTD_OOPS is not set # # RAM/ROM/Flash chip drivers # # CONFIG_MTD_CFI is not set # CONFIG_MTD_JEDECPROBE is not set CONFIG_MTD_MAP_BANK_WIDTH_1=y CONFIG_MTD_MAP_BANK_WIDTH_2=y CONFIG_MTD_MAP_BANK_WIDTH_4=y # CONFIG_MTD_MAP_BANK_WIDTH_8 is not set # CONFIG_MTD_MAP_BANK_WIDTH_16 is not set # CONFIG_MTD_MAP_BANK_WIDTH_32 is not set CONFIG_MTD_CFI_I1=y CONFIG_MTD_CFI_I2=y # CONFIG_MTD_CFI_I4 is not set # CONFIG_MTD_CFI_I8 is not set # CONFIG_MTD_RAM is not set # CONFIG_MTD_ROM is not set # CONFIG_MTD_ABSENT is not set # # Mapping drivers for chip access # # CONFIG_MTD_COMPLEX_MAPPINGS is not set # CONFIG_MTD_TS5500 is not set # CONFIG_MTD_INTEL_VR_NOR is not set # CONFIG_MTD_PLATRAM is not set # # Self-contained MTD device drivers # # CONFIG_MTD_PMC551 is not set # CONFIG_MTD_SLRAM is not set # CONFIG_MTD_PHRAM is not set # CONFIG_MTD_MTDRAM is not set # CONFIG_MTD_BLOCK2MTD is not set # # Disk-On-Chip Device Drivers # # CONFIG_MTD_DOC2000 is not set # CONFIG_MTD_DOC2001 is not set # CONFIG_MTD_DOC2001PLUS is not set # CONFIG_MTD_NAND is not set # CONFIG_MTD_ONENAND is not set # # LPDDR flash memory drivers # # CONFIG_MTD_LPDDR is not set # # UBI - Unsorted block images # # CONFIG_MTD_UBI is not set CONFIG_PARPORT=m CONFIG_PARPORT_PC=m CONFIG_PARPORT_SERIAL=m CONFIG_PARPORT_PC_FIFO=y # CONFIG_PARPORT_PC_SUPERIO is not set # CONFIG_PARPORT_PC_PCMCIA is not set # CONFIG_PARPORT_GSC is not set CONFIG_PARPORT_AX88796=m CONFIG_PARPORT_1284=y CONFIG_PARPORT_NOT_PC=y CONFIG_PNP=y # CONFIG_PNP_DEBUG_MESSAGES is not set # # Protocols # CONFIG_PNPACPI=y CONFIG_BLK_DEV=y CONFIG_BLK_DEV_FD=m # CONFIG_PARIDE is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set # CONFIG_BLK_DEV_UMEM is not set # CONFIG_BLK_DEV_COW_COMMON is not set CONFIG_BLK_DEV_LOOP=m CONFIG_BLK_DEV_CRYPTOLOOP=m CONFIG_BLK_DEV_NBD=m # CONFIG_BLK_DEV_SX8 is not set # CONFIG_BLK_DEV_UB is not set CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_COUNT=16 CONFIG_BLK_DEV_RAM_SIZE=65536 # CONFIG_BLK_DEV_XIP is not set CONFIG_CDROM_PKTCDVD=m CONFIG_CDROM_PKTCDVD_BUFFERS=8 # CONFIG_CDROM_PKTCDVD_WCACHE is not set # CONFIG_ATA_OVER_ETH is not set # CONFIG_BLK_DEV_HD is not set CONFIG_MISC_DEVICES=y # CONFIG_IBM_ASM is not set # CONFIG_PHANTOM is not set # CONFIG_SGI_IOC4 is not set # CONFIG_TIFM_CORE is not set # CONFIG_ICS932S401 is not set # CONFIG_ENCLOSURE_SERVICES is not set # CONFIG_HP_ILO is not set # CONFIG_ISL29003 is not set # CONFIG_C2PORT is not set # # EEPROM support # # CONFIG_EEPROM_AT24 is not set # CONFIG_EEPROM_LEGACY is not set # CONFIG_EEPROM_MAX6875 is not set # CONFIG_EEPROM_93CX6 is not set # CONFIG_CB710_CORE is not set CONFIG_HAVE_IDE=y CONFIG_IDE=m # # Please see Documentation/ide/ide.txt for help/info on IDE drives # CONFIG_IDE_XFER_MODE=y CONFIG_IDE_ATAPI=y # CONFIG_BLK_DEV_IDE_SATA is not set CONFIG_IDE_GD=m CONFIG_IDE_GD_ATA=y # CONFIG_IDE_GD_ATAPI is not set # CONFIG_BLK_DEV_IDECS is not set # CONFIG_BLK_DEV_DELKIN is not set CONFIG_BLK_DEV_IDECD=m CONFIG_BLK_DEV_IDECD_VERBOSE_ERRORS=y CONFIG_BLK_DEV_IDETAPE=m # CONFIG_BLK_DEV_IDEACPI is not set # CONFIG_IDE_TASK_IOCTL is not set CONFIG_IDE_PROC_FS=y # # IDE chipset support/bugfixes # CONFIG_IDE_GENERIC=m # CONFIG_BLK_DEV_PLATFORM is not set # CONFIG_BLK_DEV_CMD640 is not set CONFIG_BLK_DEV_IDEPNP=m CONFIG_BLK_DEV_IDEDMA_SFF=y # # PCI IDE chipsets support # CONFIG_BLK_DEV_IDEPCI=y # CONFIG_BLK_DEV_OFFBOARD is not set CONFIG_BLK_DEV_GENERIC=m # CONFIG_BLK_DEV_OPTI621 is not set # CONFIG_BLK_DEV_RZ1000 is not set CONFIG_BLK_DEV_IDEDMA_PCI=y # CONFIG_BLK_DEV_AEC62XX is not set # CONFIG_BLK_DEV_ALI15X3 is not set # CONFIG_BLK_DEV_AMD74XX is not set # CONFIG_BLK_DEV_ATIIXP is not set # CONFIG_BLK_DEV_CMD64X is not set # CONFIG_BLK_DEV_TRIFLEX is not set # CONFIG_BLK_DEV_CS5520 is not set # CONFIG_BLK_DEV_CS5530 is not set # CONFIG_BLK_DEV_HPT366 is not set # CONFIG_BLK_DEV_JMICRON is not set # CONFIG_BLK_DEV_SC1200 is not set CONFIG_BLK_DEV_PIIX=m # CONFIG_BLK_DEV_IT8172 is not set # CONFIG_BLK_DEV_IT8213 is not set # CONFIG_BLK_DEV_IT821X is not set # CONFIG_BLK_DEV_NS87415 is not set # CONFIG_BLK_DEV_PDC202XX_OLD is not set # CONFIG_BLK_DEV_PDC202XX_NEW is not set # CONFIG_BLK_DEV_SVWKS is not set # CONFIG_BLK_DEV_SIIMAGE is not set # CONFIG_BLK_DEV_SIS5513 is not set # CONFIG_BLK_DEV_SLC90E66 is not set # CONFIG_BLK_DEV_TRM290 is not set # CONFIG_BLK_DEV_VIA82CXXX is not set # CONFIG_BLK_DEV_TC86C001 is not set CONFIG_BLK_DEV_IDEDMA=y # # SCSI device support # CONFIG_RAID_ATTRS=m CONFIG_SCSI=m CONFIG_SCSI_DMA=y CONFIG_SCSI_TGT=m # CONFIG_SCSI_NETLINK is not set CONFIG_SCSI_PROC_FS=y # # SCSI support type (disk, tape, CD-ROM) # CONFIG_BLK_DEV_SD=m # CONFIG_CHR_DEV_ST is not set # CONFIG_CHR_DEV_OSST is not set CONFIG_BLK_DEV_SR=m # CONFIG_BLK_DEV_SR_VENDOR is not set CONFIG_CHR_DEV_SG=m # CONFIG_CHR_DEV_SCH is not set CONFIG_SCSI_MULTI_LUN=y CONFIG_SCSI_CONSTANTS=y CONFIG_SCSI_LOGGING=y CONFIG_SCSI_SCAN_ASYNC=y CONFIG_SCSI_WAIT_SCAN=m # # SCSI Transports # CONFIG_SCSI_SPI_ATTRS=m # CONFIG_SCSI_FC_ATTRS is not set CONFIG_SCSI_ISCSI_ATTRS=m # CONFIG_SCSI_SAS_LIBSAS is not set # CONFIG_SCSI_SRP_ATTRS is not set # CONFIG_SCSI_LOWLEVEL is not set # CONFIG_SCSI_LOWLEVEL_PCMCIA is not set # CONFIG_SCSI_DH is not set # CONFIG_SCSI_OSD_INITIATOR is not set CONFIG_ATA=m # CONFIG_ATA_NONSTANDARD is not set CONFIG_ATA_ACPI=y CONFIG_SATA_PMP=y CONFIG_SATA_AHCI=m # CONFIG_SATA_SIL24 is not set CONFIG_ATA_SFF=y # CONFIG_SATA_SVW is not set CONFIG_ATA_PIIX=m # CONFIG_SATA_MV is not set # CONFIG_SATA_NV is not set # CONFIG_PDC_ADMA is not set # CONFIG_SATA_QSTOR is not set # CONFIG_SATA_PROMISE is not set # CONFIG_SATA_SX4 is not set # CONFIG_SATA_SIL is not set # CONFIG_SATA_SIS is not set # CONFIG_SATA_ULI is not set # CONFIG_SATA_VIA is not set # CONFIG_SATA_VITESSE is not set # CONFIG_SATA_INIC162X is not set CONFIG_PATA_ACPI=m # CONFIG_PATA_ALI is not set # CONFIG_PATA_AMD is not set # CONFIG_PATA_ARTOP is not set # CONFIG_PATA_ATIIXP is not set # CONFIG_PATA_CMD640_PCI is not set # CONFIG_PATA_CMD64X is not set # CONFIG_PATA_CS5520 is not set # CONFIG_PATA_CS5530 is not set # CONFIG_PATA_CYPRESS is not set # CONFIG_PATA_EFAR is not set CONFIG_ATA_GENERIC=m # CONFIG_PATA_HPT366 is not set # CONFIG_PATA_HPT37X is not set # CONFIG_PATA_HPT3X2N is not set # CONFIG_PATA_HPT3X3 is not set # CONFIG_PATA_IT821X is not set # CONFIG_PATA_IT8213 is not set # CONFIG_PATA_JMICRON is not set # CONFIG_PATA_TRIFLEX is not set # CONFIG_PATA_MARVELL is not set # CONFIG_PATA_MPIIX is not set # CONFIG_PATA_OLDPIIX is not set # CONFIG_PATA_NETCELL is not set # CONFIG_PATA_NINJA32 is not set # CONFIG_PATA_NS87410 is not set # CONFIG_PATA_NS87415 is not set # CONFIG_PATA_OPTI is not set # CONFIG_PATA_OPTIDMA is not set # CONFIG_PATA_PCMCIA is not set # CONFIG_PATA_PDC_OLD is not set # CONFIG_PATA_RADISYS is not set # CONFIG_PATA_RZ1000 is not set # CONFIG_PATA_SC1200 is not set # CONFIG_PATA_SERVERWORKS is not set # CONFIG_PATA_PDC2027X is not set # CONFIG_PATA_SIL680 is not set # CONFIG_PATA_SIS is not set # CONFIG_PATA_VIA is not set # CONFIG_PATA_WINBOND is not set # CONFIG_PATA_SCH is not set CONFIG_MD=y CONFIG_BLK_DEV_MD=m CONFIG_MD_LINEAR=m CONFIG_MD_RAID0=m CONFIG_MD_RAID1=m CONFIG_MD_RAID10=m CONFIG_MD_RAID456=m CONFIG_MD_RAID6_PQ=m CONFIG_MD_MULTIPATH=m CONFIG_MD_FAULTY=m CONFIG_BLK_DEV_DM=m # CONFIG_DM_DEBUG is not set CONFIG_DM_CRYPT=m CONFIG_DM_SNAPSHOT=m CONFIG_DM_MIRROR=m # CONFIG_DM_LOG_USERSPACE is not set CONFIG_DM_ZERO=m CONFIG_DM_MULTIPATH=m # CONFIG_DM_MULTIPATH_QL is not set # CONFIG_DM_MULTIPATH_ST is not set CONFIG_DM_DELAY=m # CONFIG_DM_UEVENT is not set # CONFIG_FUSION is not set # # IEEE 1394 (FireWire) support # # # You can enable one or both FireWire driver stacks. # # # See the help texts for more information. # # CONFIG_FIREWIRE is not set CONFIG_IEEE1394=m CONFIG_IEEE1394_OHCI1394=m # CONFIG_IEEE1394_PCILYNX is not set CONFIG_IEEE1394_SBP2=m # CONFIG_IEEE1394_SBP2_PHYS_DMA is not set CONFIG_IEEE1394_ETH1394_ROM_ENTRY=y CONFIG_IEEE1394_ETH1394=m CONFIG_IEEE1394_RAWIO=m CONFIG_IEEE1394_VIDEO1394=m # CONFIG_IEEE1394_DV1394 is not set # CONFIG_IEEE1394_VERBOSEDEBUG is not set CONFIG_I2O=m CONFIG_I2O_LCT_NOTIFY_ON_CHANGES=y CONFIG_I2O_EXT_ADAPTEC=y CONFIG_I2O_EXT_ADAPTEC_DMA64=y CONFIG_I2O_CONFIG=m CONFIG_I2O_CONFIG_OLD_IOCTL=y CONFIG_I2O_BUS=m CONFIG_I2O_BLOCK=m CONFIG_I2O_SCSI=m CONFIG_I2O_PROC=m # CONFIG_MACINTOSH_DRIVERS is not set CONFIG_NETDEVICES=y CONFIG_IFB=m CONFIG_DUMMY=m CONFIG_BONDING=m # CONFIG_MACVLAN is not set CONFIG_EQUALIZER=m CONFIG_TUN=m # CONFIG_VETH is not set # CONFIG_NET_SB1000 is not set # CONFIG_ARCNET is not set # CONFIG_PHYLIB is not set CONFIG_NET_ETHERNET=y CONFIG_MII=m # CONFIG_HAPPYMEAL is not set # CONFIG_SUNGEM is not set # CONFIG_CASSINI is not set # CONFIG_NET_VENDOR_3COM is not set # CONFIG_ETHOC is not set # CONFIG_DNET is not set # CONFIG_NET_TULIP is not set # CONFIG_HP100 is not set # CONFIG_IBM_NEW_EMAC_ZMII is not set # CONFIG_IBM_NEW_EMAC_RGMII is not set # CONFIG_IBM_NEW_EMAC_TAH is not set # CONFIG_IBM_NEW_EMAC_EMAC4 is not set # CONFIG_IBM_NEW_EMAC_NO_FLOW_CTRL is not set # CONFIG_IBM_NEW_EMAC_MAL_CLR_ICINTSTAT is not set # CONFIG_IBM_NEW_EMAC_MAL_COMMON_ERR is not set CONFIG_NET_PCI=y # CONFIG_PCNET32 is not set # CONFIG_AMD8111_ETH is not set # CONFIG_ADAPTEC_STARFIRE is not set # CONFIG_B44 is not set # CONFIG_FORCEDETH is not set # CONFIG_E100 is not set # CONFIG_FEALNX is not set # CONFIG_NATSEMI is not set # CONFIG_NE2K_PCI is not set # CONFIG_8139CP is not set # CONFIG_8139TOO is not set # CONFIG_R6040 is not set # CONFIG_SIS900 is not set # CONFIG_EPIC100 is not set # CONFIG_SMSC9420 is not set # CONFIG_SUNDANCE is not set # CONFIG_TLAN is not set # CONFIG_KS8842 is not set CONFIG_VIA_RHINE=m CONFIG_VIA_RHINE_MMIO=y # CONFIG_SC92031 is not set # CONFIG_NET_POCKET is not set # CONFIG_ATL2 is not set CONFIG_NETDEV_1000=y # CONFIG_ACENIC is not set # CONFIG_DL2K is not set CONFIG_E1000=m CONFIG_E1000E=m # CONFIG_IP1000 is not set # CONFIG_IGB is not set # CONFIG_IGBVF is not set # CONFIG_NS83820 is not set # CONFIG_HAMACHI is not set # CONFIG_YELLOWFIN is not set # CONFIG_R8169 is not set # CONFIG_SIS190 is not set # CONFIG_SKGE is not set # CONFIG_SKY2 is not set # CONFIG_VIA_VELOCITY is not set # CONFIG_TIGON3 is not set # CONFIG_BNX2 is not set # CONFIG_CNIC is not set # CONFIG_QLA3XXX is not set # CONFIG_ATL1 is not set # CONFIG_ATL1E is not set # CONFIG_ATL1C is not set # CONFIG_JME is not set # CONFIG_NETDEV_10000 is not set # CONFIG_TR is not set # # Wireless LAN # # CONFIG_WLAN_PRE80211 is not set CONFIG_WLAN_80211=y # CONFIG_PCMCIA_RAYCS is not set # CONFIG_LIBERTAS is not set # CONFIG_LIBERTAS_THINFIRM is not set # CONFIG_AIRO is not set # CONFIG_ATMEL is not set # CONFIG_AT76C50X_USB is not set # CONFIG_AIRO_CS is not set # CONFIG_PCMCIA_WL3501 is not set # CONFIG_PRISM54 is not set # CONFIG_USB_ZD1201 is not set # CONFIG_USB_NET_RNDIS_WLAN is not set # CONFIG_RTL8180 is not set # CONFIG_RTL8187 is not set # CONFIG_ADM8211 is not set # CONFIG_MAC80211_HWSIM is not set # CONFIG_MWL8K is not set # CONFIG_P54_COMMON is not set CONFIG_ATH_COMMON=m CONFIG_ATH5K=m # CONFIG_ATH5K_DEBUG is not set # CONFIG_ATH9K is not set # CONFIG_AR9170_USB is not set # CONFIG_IPW2100 is not set # CONFIG_IPW2200 is not set CONFIG_IWLWIFI=m CONFIG_IWLWIFI_LEDS=y # CONFIG_IWLWIFI_SPECTRUM_MEASUREMENT is not set CONFIG_IWLWIFI_DEBUG=y CONFIG_IWLAGN=m CONFIG_IWL4965=y # CONFIG_IWL5000 is not set # CONFIG_IWL3945 is not set # CONFIG_HOSTAP is not set # CONFIG_B43 is not set # CONFIG_B43LEGACY is not set # CONFIG_ZD1211RW is not set # CONFIG_RT2X00 is not set # CONFIG_HERMES is not set # CONFIG_IWM is not set # # Enable WiMAX (Networking options) to see the WiMAX drivers # # # USB Network Adapters # # CONFIG_USB_CATC is not set # CONFIG_USB_KAWETH is not set # CONFIG_USB_PEGASUS is not set # CONFIG_USB_RTL8150 is not set # CONFIG_USB_USBNET is not set # CONFIG_USB_HSO is not set # CONFIG_NET_PCMCIA is not set # CONFIG_WAN is not set # CONFIG_FDDI is not set # CONFIG_HIPPI is not set CONFIG_PLIP=m CONFIG_PPP=m CONFIG_PPP_MULTILINK=y CONFIG_PPP_FILTER=y CONFIG_PPP_ASYNC=m CONFIG_PPP_SYNC_TTY=m CONFIG_PPP_DEFLATE=m CONFIG_PPP_BSDCOMP=m CONFIG_PPP_MPPE=m CONFIG_PPPOE=m # CONFIG_PPPOL2TP is not set CONFIG_SLIP=m CONFIG_SLIP_COMPRESSED=y CONFIG_SLHC=m CONFIG_SLIP_SMART=y # CONFIG_SLIP_MODE_SLIP6 is not set # CONFIG_NET_FC is not set CONFIG_NETCONSOLE=m CONFIG_NETCONSOLE_DYNAMIC=y CONFIG_NETPOLL=y # CONFIG_NETPOLL_TRAP is not set CONFIG_NET_POLL_CONTROLLER=y # CONFIG_ISDN is not set # CONFIG_PHONE is not set # # Input device support # CONFIG_INPUT=y CONFIG_INPUT_FF_MEMLESS=m CONFIG_INPUT_POLLDEV=m # # Userland interfaces # CONFIG_INPUT_MOUSEDEV=y CONFIG_INPUT_MOUSEDEV_PSAUX=y CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 CONFIG_INPUT_JOYDEV=m CONFIG_INPUT_EVDEV=m # CONFIG_INPUT_EVBUG is not set # # Input Device Drivers # CONFIG_INPUT_KEYBOARD=y CONFIG_KEYBOARD_ATKBD=y # CONFIG_KEYBOARD_LKKBD is not set # CONFIG_KEYBOARD_LM8323 is not set # CONFIG_KEYBOARD_NEWTON is not set # CONFIG_KEYBOARD_STOWAWAY is not set # CONFIG_KEYBOARD_SUNKBD is not set # CONFIG_KEYBOARD_XTKBD is not set CONFIG_INPUT_MOUSE=y CONFIG_MOUSE_PS2=m CONFIG_MOUSE_PS2_ALPS=y CONFIG_MOUSE_PS2_LOGIPS2PP=y CONFIG_MOUSE_PS2_SYNAPTICS=y CONFIG_MOUSE_PS2_LIFEBOOK=y CONFIG_MOUSE_PS2_TRACKPOINT=y # CONFIG_MOUSE_PS2_ELANTECH is not set # CONFIG_MOUSE_PS2_TOUCHKIT is not set # CONFIG_MOUSE_SERIAL is not set # CONFIG_MOUSE_APPLETOUCH is not set # CONFIG_MOUSE_BCM5974 is not set # CONFIG_MOUSE_VSXXXAA is not set # CONFIG_MOUSE_SYNAPTICS_I2C is not set CONFIG_INPUT_JOYSTICK=y # CONFIG_JOYSTICK_ANALOG is not set # CONFIG_JOYSTICK_A3D is not set # CONFIG_JOYSTICK_ADI is not set # CONFIG_JOYSTICK_COBRA is not set # CONFIG_JOYSTICK_GF2K is not set # CONFIG_JOYSTICK_GRIP is not set # CONFIG_JOYSTICK_GRIP_MP is not set # CONFIG_JOYSTICK_GUILLEMOT is not set # CONFIG_JOYSTICK_INTERACT is not set CONFIG_JOYSTICK_SIDEWINDER=m # CONFIG_JOYSTICK_TMDC is not set # CONFIG_JOYSTICK_IFORCE is not set # CONFIG_JOYSTICK_WARRIOR is not set # CONFIG_JOYSTICK_MAGELLAN is not set # CONFIG_JOYSTICK_SPACEORB is not set # CONFIG_JOYSTICK_SPACEBALL is not set # CONFIG_JOYSTICK_STINGER is not set # CONFIG_JOYSTICK_TWIDJOY is not set # CONFIG_JOYSTICK_ZHENHUA is not set # CONFIG_JOYSTICK_DB9 is not set # CONFIG_JOYSTICK_GAMECON is not set # CONFIG_JOYSTICK_TURBOGRAFX is not set # CONFIG_JOYSTICK_JOYDUMP is not set # CONFIG_JOYSTICK_XPAD is not set # CONFIG_JOYSTICK_WALKERA0701 is not set # CONFIG_INPUT_TABLET is not set # CONFIG_INPUT_TOUCHSCREEN is not set CONFIG_INPUT_MISC=y CONFIG_INPUT_PCSPKR=m # CONFIG_INPUT_APANEL is not set # CONFIG_INPUT_ATLAS_BTNS is not set # CONFIG_INPUT_ATI_REMOTE is not set # CONFIG_INPUT_ATI_REMOTE2 is not set # CONFIG_INPUT_KEYSPAN_REMOTE is not set # CONFIG_INPUT_POWERMATE is not set # CONFIG_INPUT_YEALINK is not set # CONFIG_INPUT_CM109 is not set CONFIG_INPUT_UINPUT=m # # Hardware I/O ports # CONFIG_SERIO=y CONFIG_SERIO_I8042=y CONFIG_SERIO_SERPORT=m CONFIG_SERIO_CT82C710=m CONFIG_SERIO_PARKBD=m CONFIG_SERIO_PCIPS2=m CONFIG_SERIO_LIBPS2=y CONFIG_SERIO_RAW=m CONFIG_GAMEPORT=m CONFIG_GAMEPORT_NS558=m # CONFIG_GAMEPORT_L4 is not set # CONFIG_GAMEPORT_EMU10K1 is not set # CONFIG_GAMEPORT_FM801 is not set # # Character devices # CONFIG_VT=y CONFIG_CONSOLE_TRANSLATIONS=y CONFIG_VT_CONSOLE=y CONFIG_HW_CONSOLE=y # CONFIG_VT_HW_CONSOLE_BINDING is not set # CONFIG_DEVKMEM is not set # CONFIG_SERIAL_NONSTANDARD is not set # CONFIG_NOZOMI is not set # # Serial drivers # CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_FIX_EARLYCON_MEM=y CONFIG_SERIAL_8250_PCI=y CONFIG_SERIAL_8250_PNP=y # CONFIG_SERIAL_8250_CS is not set CONFIG_SERIAL_8250_NR_UARTS=16 CONFIG_SERIAL_8250_RUNTIME_UARTS=4 CONFIG_SERIAL_8250_EXTENDED=y CONFIG_SERIAL_8250_MANY_PORTS=y CONFIG_SERIAL_8250_SHARE_IRQ=y # CONFIG_SERIAL_8250_DETECT_IRQ is not set CONFIG_SERIAL_8250_RSA=y # # Non-8250 serial port support # CONFIG_SERIAL_CORE=y CONFIG_SERIAL_CORE_CONSOLE=y # CONFIG_SERIAL_JSM is not set CONFIG_UNIX98_PTYS=y # CONFIG_DEVPTS_MULTIPLE_INSTANCES is not set # CONFIG_LEGACY_PTYS is not set CONFIG_PRINTER=m # CONFIG_LP_CONSOLE is not set CONFIG_PPDEV=m CONFIG_IPMI_HANDLER=m # CONFIG_IPMI_PANIC_EVENT is not set CONFIG_IPMI_DEVICE_INTERFACE=m CONFIG_IPMI_SI=m CONFIG_IPMI_WATCHDOG=m CONFIG_IPMI_POWEROFF=m CONFIG_HW_RANDOM=m CONFIG_HW_RANDOM_TIMERIOMEM=m CONFIG_HW_RANDOM_INTEL=m # CONFIG_HW_RANDOM_AMD is not set # CONFIG_HW_RANDOM_VIA is not set CONFIG_NVRAM=m # CONFIG_R3964 is not set # CONFIG_APPLICOM is not set # # PCMCIA character devices # # CONFIG_SYNCLINK_CS is not set # CONFIG_CARDMAN_4000 is not set # CONFIG_CARDMAN_4040 is not set # CONFIG_IPWIRELESS is not set # CONFIG_MWAVE is not set # CONFIG_PC8736x_GPIO is not set CONFIG_RAW_DRIVER=m CONFIG_MAX_RAW_DEVS=256 CONFIG_HPET=y CONFIG_HPET_MMAP=y CONFIG_HANGCHECK_TIMER=m CONFIG_TCG_TPM=m CONFIG_TCG_TIS=m # CONFIG_TCG_NSC is not set # CONFIG_TCG_ATMEL is not set CONFIG_TCG_INFINEON=m CONFIG_TELCLOCK=m CONFIG_DEVPORT=y CONFIG_I2C=m CONFIG_I2C_BOARDINFO=y CONFIG_I2C_CHARDEV=m CONFIG_I2C_HELPER_AUTO=y CONFIG_I2C_ALGOBIT=m # # I2C Hardware Bus support # # # PC SMBus host controller drivers # # CONFIG_I2C_ALI1535 is not set # CONFIG_I2C_ALI1563 is not set # CONFIG_I2C_ALI15X3 is not set # CONFIG_I2C_AMD756 is not set # CONFIG_I2C_AMD8111 is not set CONFIG_I2C_I801=m # CONFIG_I2C_ISCH is not set CONFIG_I2C_PIIX4=m # CONFIG_I2C_NFORCE2 is not set # CONFIG_I2C_SIS5595 is not set # CONFIG_I2C_SIS630 is not set # CONFIG_I2C_SIS96X is not set # CONFIG_I2C_VIA is not set # CONFIG_I2C_VIAPRO is not set # # I2C system bus drivers (mostly embedded / system-on-chip) # # CONFIG_I2C_OCORES is not set # CONFIG_I2C_SIMTEC is not set # # External I2C/SMBus adapter drivers # # CONFIG_I2C_PARPORT is not set # CONFIG_I2C_PARPORT_LIGHT is not set # CONFIG_I2C_TAOS_EVM is not set # CONFIG_I2C_TINY_USB is not set # # Graphics adapter I2C/DDC channel drivers # # CONFIG_I2C_VOODOO3 is not set # # Other I2C/SMBus bus drivers # # CONFIG_I2C_PCA_PLATFORM is not set # CONFIG_I2C_STUB is not set # # Miscellaneous I2C Chip support # # CONFIG_DS1682 is not set # CONFIG_SENSORS_PCF8574 is not set # CONFIG_PCF8575 is not set # CONFIG_SENSORS_PCA9539 is not set # CONFIG_SENSORS_TSL2550 is not set # CONFIG_I2C_DEBUG_CORE is not set # CONFIG_I2C_DEBUG_ALGO is not set # CONFIG_I2C_DEBUG_BUS is not set # CONFIG_I2C_DEBUG_CHIP is not set # CONFIG_SPI is not set # # PPS support # # CONFIG_PPS is not set CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y # CONFIG_GPIOLIB is not set # CONFIG_W1 is not set CONFIG_POWER_SUPPLY=y # CONFIG_POWER_SUPPLY_DEBUG is not set # CONFIG_PDA_POWER is not set # CONFIG_BATTERY_DS2760 is not set # CONFIG_BATTERY_DS2782 is not set # CONFIG_BATTERY_BQ27x00 is not set # CONFIG_BATTERY_MAX17040 is not set CONFIG_HWMON=y CONFIG_HWMON_VID=m CONFIG_SENSORS_ABITUGURU=y CONFIG_SENSORS_ABITUGURU3=y # CONFIG_SENSORS_AD7414 is not set # CONFIG_SENSORS_AD7418 is not set # CONFIG_SENSORS_ADM1021 is not set # CONFIG_SENSORS_ADM1025 is not set # CONFIG_SENSORS_ADM1026 is not set # CONFIG_SENSORS_ADM1029 is not set # CONFIG_SENSORS_ADM1031 is not set # CONFIG_SENSORS_ADM9240 is not set # CONFIG_SENSORS_ADT7462 is not set # CONFIG_SENSORS_ADT7470 is not set # CONFIG_SENSORS_ADT7473 is not set # CONFIG_SENSORS_ADT7475 is not set # CONFIG_SENSORS_K8TEMP is not set # CONFIG_SENSORS_ASB100 is not set # CONFIG_SENSORS_ATK0110 is not set # CONFIG_SENSORS_ATXP1 is not set # CONFIG_SENSORS_DS1621 is not set # CONFIG_SENSORS_I5K_AMB is not set # CONFIG_SENSORS_F71805F is not set # CONFIG_SENSORS_F71882FG is not set # CONFIG_SENSORS_F75375S is not set # CONFIG_SENSORS_FSCHER is not set # CONFIG_SENSORS_FSCPOS is not set # CONFIG_SENSORS_FSCHMD is not set # CONFIG_SENSORS_G760A is not set # CONFIG_SENSORS_GL518SM is not set # CONFIG_SENSORS_GL520SM is not set CONFIG_SENSORS_CORETEMP=m # CONFIG_SENSORS_IBMAEM is not set # CONFIG_SENSORS_IBMPEX is not set # CONFIG_SENSORS_IT87 is not set # CONFIG_SENSORS_LM63 is not set # CONFIG_SENSORS_LM75 is not set # CONFIG_SENSORS_LM77 is not set # CONFIG_SENSORS_LM78 is not set # CONFIG_SENSORS_LM80 is not set # CONFIG_SENSORS_LM83 is not set CONFIG_SENSORS_LM85=m # CONFIG_SENSORS_LM87 is not set # CONFIG_SENSORS_LM90 is not set # CONFIG_SENSORS_LM92 is not set # CONFIG_SENSORS_LM93 is not set # CONFIG_SENSORS_LTC4215 is not set # CONFIG_SENSORS_LTC4245 is not set # CONFIG_SENSORS_LM95241 is not set # CONFIG_SENSORS_MAX1619 is not set # CONFIG_SENSORS_MAX6650 is not set # CONFIG_SENSORS_PC87360 is not set # CONFIG_SENSORS_PC87427 is not set # CONFIG_SENSORS_PCF8591 is not set # CONFIG_SENSORS_SIS5595 is not set # CONFIG_SENSORS_DME1737 is not set # CONFIG_SENSORS_SMSC47M1 is not set # CONFIG_SENSORS_SMSC47M192 is not set # CONFIG_SENSORS_SMSC47B397 is not set CONFIG_SENSORS_ADS7828=m # CONFIG_SENSORS_THMC50 is not set # CONFIG_SENSORS_TMP401 is not set # CONFIG_SENSORS_VIA686A is not set # CONFIG_SENSORS_VT1211 is not set # CONFIG_SENSORS_VT8231 is not set # CONFIG_SENSORS_W83781D is not set # CONFIG_SENSORS_W83791D is not set # CONFIG_SENSORS_W83792D is not set # CONFIG_SENSORS_W83793 is not set # CONFIG_SENSORS_W83L785TS is not set # CONFIG_SENSORS_W83L786NG is not set # CONFIG_SENSORS_W83627HF is not set # CONFIG_SENSORS_W83627EHF is not set # CONFIG_SENSORS_HDAPS is not set CONFIG_SENSORS_LIS3LV02D=m # CONFIG_SENSORS_APPLESMC is not set # CONFIG_HWMON_DEBUG_CHIP is not set CONFIG_THERMAL=m CONFIG_THERMAL_HWMON=y CONFIG_WATCHDOG=y # CONFIG_WATCHDOG_NOWAYOUT is not set # # Watchdog Device Drivers # CONFIG_SOFT_WATCHDOG=m # CONFIG_ACQUIRE_WDT is not set # CONFIG_ADVANTECH_WDT is not set # CONFIG_ALIM1535_WDT is not set # CONFIG_ALIM7101_WDT is not set # CONFIG_SC520_WDT is not set # CONFIG_EUROTECH_WDT is not set # CONFIG_IB700_WDT is not set # CONFIG_IBMASR is not set # CONFIG_WAFER_WDT is not set # CONFIG_I6300ESB_WDT is not set CONFIG_ITCO_WDT=m # CONFIG_ITCO_VENDOR_SUPPORT is not set # CONFIG_IT8712F_WDT is not set # CONFIG_IT87_WDT is not set # CONFIG_HP_WATCHDOG is not set # CONFIG_SC1200_WDT is not set # CONFIG_PC87413_WDT is not set # CONFIG_60XX_WDT is not set # CONFIG_SBC8360_WDT is not set # CONFIG_CPU5_WDT is not set # CONFIG_SMSC_SCH311X_WDT is not set # CONFIG_SMSC37B787_WDT is not set # CONFIG_W83627HF_WDT is not set # CONFIG_W83697HF_WDT is not set # CONFIG_W83697UG_WDT is not set # CONFIG_W83877F_WDT is not set # CONFIG_W83977F_WDT is not set # CONFIG_MACHZ_WDT is not set # CONFIG_SBC_EPX_C3_WATCHDOG is not set # # PCI-based Watchdog Cards # # CONFIG_PCIPCWATCHDOG is not set # CONFIG_WDTPCI is not set # # USB-based Watchdog Cards # # CONFIG_USBPCWATCHDOG is not set CONFIG_SSB_POSSIBLE=y # # Sonics Silicon Backplane # # CONFIG_SSB is not set # # Multifunction device drivers # # CONFIG_MFD_CORE is not set # CONFIG_MFD_SM501 is not set # CONFIG_HTC_PASIC3 is not set # CONFIG_MFD_TMIO is not set # CONFIG_MFD_WM8400 is not set # CONFIG_MFD_WM8350_I2C is not set # CONFIG_MFD_PCF50633 is not set # CONFIG_AB3100_CORE is not set # CONFIG_REGULATOR is not set # CONFIG_MEDIA_SUPPORT is not set # # Graphics support # CONFIG_AGP=y CONFIG_AGP_AMD64=y CONFIG_AGP_INTEL=m # CONFIG_AGP_SIS is not set # CONFIG_AGP_VIA is not set CONFIG_DRM=m # CONFIG_DRM_TDFX is not set # CONFIG_DRM_R128 is not set # CONFIG_DRM_RADEON is not set CONFIG_DRM_I810=m CONFIG_DRM_I830=m CONFIG_DRM_I915=m # CONFIG_DRM_I915_KMS is not set # CONFIG_DRM_MGA is not set # CONFIG_DRM_SIS is not set # CONFIG_DRM_VIA is not set # CONFIG_DRM_SAVAGE is not set CONFIG_VGASTATE=m CONFIG_VIDEO_OUTPUT_CONTROL=m CONFIG_FB=y CONFIG_FIRMWARE_EDID=y # CONFIG_FB_DDC is not set CONFIG_FB_BOOT_VESA_SUPPORT=y CONFIG_FB_CFB_FILLRECT=y CONFIG_FB_CFB_COPYAREA=y CONFIG_FB_CFB_IMAGEBLIT=y # CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set # CONFIG_FB_SYS_FILLRECT is not set # CONFIG_FB_SYS_COPYAREA is not set # CONFIG_FB_SYS_IMAGEBLIT is not set # CONFIG_FB_FOREIGN_ENDIAN is not set # CONFIG_FB_SYS_FOPS is not set # CONFIG_FB_SVGALIB is not set # CONFIG_FB_MACMODES is not set # CONFIG_FB_BACKLIGHT is not set CONFIG_FB_MODE_HELPERS=y CONFIG_FB_TILEBLITTING=y # # Frame buffer hardware drivers # # CONFIG_FB_CIRRUS is not set # CONFIG_FB_PM2 is not set # CONFIG_FB_CYBER2000 is not set # CONFIG_FB_ARC is not set # CONFIG_FB_ASILIANT is not set # CONFIG_FB_IMSTT is not set CONFIG_FB_VGA16=m # CONFIG_FB_UVESA is not set CONFIG_FB_VESA=y # CONFIG_FB_N411 is not set # CONFIG_FB_HGA is not set # CONFIG_FB_S1D13XXX is not set # CONFIG_FB_NVIDIA is not set # CONFIG_FB_RIVA is not set # CONFIG_FB_LE80578 is not set # CONFIG_FB_MATROX is not set # CONFIG_FB_RADEON is not set # CONFIG_FB_ATY128 is not set # CONFIG_FB_ATY is not set # CONFIG_FB_S3 is not set # CONFIG_FB_SAVAGE is not set # CONFIG_FB_SIS is not set # CONFIG_FB_VIA is not set # CONFIG_FB_NEOMAGIC is not set # CONFIG_FB_KYRO is not set # CONFIG_FB_3DFX is not set # CONFIG_FB_VOODOO1 is not set # CONFIG_FB_VT8623 is not set # CONFIG_FB_TRIDENT is not set # CONFIG_FB_ARK is not set # CONFIG_FB_PM3 is not set # CONFIG_FB_CARMINE is not set # CONFIG_FB_GEODE is not set # CONFIG_FB_VIRTUAL is not set # CONFIG_FB_METRONOME is not set # CONFIG_FB_MB862XX is not set # CONFIG_FB_BROADSHEET is not set CONFIG_BACKLIGHT_LCD_SUPPORT=y # CONFIG_LCD_CLASS_DEVICE is not set CONFIG_BACKLIGHT_CLASS_DEVICE=y CONFIG_BACKLIGHT_GENERIC=y # CONFIG_BACKLIGHT_PROGEAR is not set # CONFIG_BACKLIGHT_MBP_NVIDIA is not set # CONFIG_BACKLIGHT_SAHARA is not set # # Display device support # CONFIG_DISPLAY_SUPPORT=m # # Display hardware drivers # # # Console display driver support # CONFIG_VGA_CONSOLE=y CONFIG_VGACON_SOFT_SCROLLBACK=y CONFIG_VGACON_SOFT_SCROLLBACK_SIZE=64 CONFIG_DUMMY_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y # CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set # CONFIG_FONTS is not set CONFIG_FONT_8x8=y CONFIG_FONT_8x16=y CONFIG_LOGO=y # CONFIG_LOGO_LINUX_MONO is not set # CONFIG_LOGO_LINUX_VGA16 is not set CONFIG_LOGO_LINUX_CLUT224=y CONFIG_SOUND=m CONFIG_SOUND_OSS_CORE=y CONFIG_SND=m CONFIG_SND_TIMER=m CONFIG_SND_PCM=m CONFIG_SND_RAWMIDI=m CONFIG_SND_JACK=y CONFIG_SND_SEQUENCER=m CONFIG_SND_SEQ_DUMMY=m CONFIG_SND_OSSEMUL=y CONFIG_SND_MIXER_OSS=m CONFIG_SND_PCM_OSS=m CONFIG_SND_PCM_OSS_PLUGINS=y CONFIG_SND_SEQUENCER_OSS=y CONFIG_SND_HRTIMER=m CONFIG_SND_SEQ_HRTIMER_DEFAULT=y CONFIG_SND_DYNAMIC_MINORS=y CONFIG_SND_SUPPORT_OLD_API=y CONFIG_SND_VERBOSE_PROCFS=y # CONFIG_SND_VERBOSE_PRINTK is not set # CONFIG_SND_DEBUG is not set CONFIG_SND_VMASTER=y CONFIG_SND_RAWMIDI_SEQ=m # CONFIG_SND_OPL3_LIB_SEQ is not set # CONFIG_SND_OPL4_LIB_SEQ is not set # CONFIG_SND_SBAWE_SEQ is not set # CONFIG_SND_EMU10K1_SEQ is not set CONFIG_SND_MPU401_UART=m CONFIG_SND_AC97_CODEC=m CONFIG_SND_DRIVERS=y # CONFIG_SND_PCSP is not set # CONFIG_SND_DUMMY is not set CONFIG_SND_VIRMIDI=m # CONFIG_SND_MTPAV is not set # CONFIG_SND_MTS64 is not set CONFIG_SND_SERIAL_U16550=m CONFIG_SND_MPU401=m # CONFIG_SND_PORTMAN2X4 is not set # CONFIG_SND_AC97_POWER_SAVE is not set CONFIG_SND_PCI=y # CONFIG_SND_AD1889 is not set # CONFIG_SND_ALS300 is not set # CONFIG_SND_ALS4000 is not set # CONFIG_SND_ALI5451 is not set # CONFIG_SND_ATIIXP is not set # CONFIG_SND_ATIIXP_MODEM is not set # CONFIG_SND_AU8810 is not set # CONFIG_SND_AU8820 is not set # CONFIG_SND_AU8830 is not set # CONFIG_SND_AW2 is not set # CONFIG_SND_AZT3328 is not set # CONFIG_SND_BT87X is not set # CONFIG_SND_CA0106 is not set # CONFIG_SND_CMIPCI is not set # CONFIG_SND_OXYGEN is not set # CONFIG_SND_CS4281 is not set # CONFIG_SND_CS46XX is not set # CONFIG_SND_CS5530 is not set # CONFIG_SND_CTXFI is not set # CONFIG_SND_DARLA20 is not set # CONFIG_SND_GINA20 is not set # CONFIG_SND_LAYLA20 is not set # CONFIG_SND_DARLA24 is not set # CONFIG_SND_GINA24 is not set # CONFIG_SND_LAYLA24 is not set # CONFIG_SND_MONA is not set # CONFIG_SND_MIA is not set # CONFIG_SND_ECHO3G is not set # CONFIG_SND_INDIGO is not set # CONFIG_SND_INDIGOIO is not set # CONFIG_SND_INDIGODJ is not set # CONFIG_SND_INDIGOIOX is not set # CONFIG_SND_INDIGODJX is not set # CONFIG_SND_EMU10K1 is not set # CONFIG_SND_EMU10K1X is not set # CONFIG_SND_ENS1370 is not set # CONFIG_SND_ENS1371 is not set # CONFIG_SND_ES1938 is not set # CONFIG_SND_ES1968 is not set # CONFIG_SND_FM801 is not set CONFIG_SND_HDA_INTEL=m # CONFIG_SND_HDA_HWDEP is not set CONFIG_SND_HDA_INPUT_BEEP=y CONFIG_SND_HDA_INPUT_JACK=y # CONFIG_SND_HDA_CODEC_REALTEK is not set CONFIG_SND_HDA_CODEC_ANALOG=y CONFIG_SND_HDA_CODEC_SIGMATEL=y # CONFIG_SND_HDA_CODEC_VIA is not set # CONFIG_SND_HDA_CODEC_ATIHDMI is not set # CONFIG_SND_HDA_CODEC_NVHDMI is not set # CONFIG_SND_HDA_CODEC_INTELHDMI is not set # CONFIG_SND_HDA_CODEC_CONEXANT is not set # CONFIG_SND_HDA_CODEC_CA0110 is not set # CONFIG_SND_HDA_CODEC_CMEDIA is not set # CONFIG_SND_HDA_CODEC_SI3054 is not set CONFIG_SND_HDA_GENERIC=y CONFIG_SND_HDA_POWER_SAVE=y CONFIG_SND_HDA_POWER_SAVE_DEFAULT=60 # CONFIG_SND_HDSP is not set # CONFIG_SND_HDSPM is not set # CONFIG_SND_HIFIER is not set # CONFIG_SND_ICE1712 is not set # CONFIG_SND_ICE1724 is not set CONFIG_SND_INTEL8X0=m # CONFIG_SND_INTEL8X0M is not set # CONFIG_SND_KORG1212 is not set # CONFIG_SND_LX6464ES is not set # CONFIG_SND_MAESTRO3 is not set # CONFIG_SND_MIXART is not set # CONFIG_SND_NM256 is not set # CONFIG_SND_PCXHR is not set # CONFIG_SND_RIPTIDE is not set # CONFIG_SND_RME32 is not set # CONFIG_SND_RME96 is not set # CONFIG_SND_RME9652 is not set # CONFIG_SND_SONICVIBES is not set # CONFIG_SND_TRIDENT is not set # CONFIG_SND_VIA82XX is not set # CONFIG_SND_VIA82XX_MODEM is not set # CONFIG_SND_VIRTUOSO is not set # CONFIG_SND_VX222 is not set # CONFIG_SND_YMFPCI is not set # CONFIG_SND_USB is not set # CONFIG_SND_PCMCIA is not set # CONFIG_SND_SOC is not set # CONFIG_SOUND_PRIME is not set CONFIG_AC97_BUS=m CONFIG_HID_SUPPORT=y CONFIG_HID=m # CONFIG_HID_DEBUG is not set # CONFIG_HIDRAW is not set # # USB Input Devices # CONFIG_USB_HID=m # CONFIG_HID_PID is not set CONFIG_USB_HIDDEV=y # # Special HID drivers # CONFIG_HID_A4TECH=m CONFIG_HID_APPLE=m CONFIG_HID_BELKIN=m CONFIG_HID_CHERRY=m CONFIG_HID_CHICONY=m CONFIG_HID_CYPRESS=m CONFIG_HID_DRAGONRISE=m # CONFIG_DRAGONRISE_FF is not set CONFIG_HID_EZKEY=m CONFIG_HID_KYE=m CONFIG_HID_GYRATION=m CONFIG_HID_KENSINGTON=m CONFIG_HID_LOGITECH=m # CONFIG_LOGITECH_FF is not set # CONFIG_LOGIRUMBLEPAD2_FF is not set CONFIG_HID_MICROSOFT=m CONFIG_HID_MONTEREY=m CONFIG_HID_NTRIG=m CONFIG_HID_PANTHERLORD=m # CONFIG_PANTHERLORD_FF is not set CONFIG_HID_PETALYNX=m CONFIG_HID_SAMSUNG=m CONFIG_HID_SONY=m CONFIG_HID_SUNPLUS=m CONFIG_HID_GREENASIA=m # CONFIG_GREENASIA_FF is not set CONFIG_HID_SMARTJOYPLUS=m # CONFIG_SMARTJOYPLUS_FF is not set CONFIG_HID_TOPSEED=m CONFIG_HID_THRUSTMASTER=m # CONFIG_THRUSTMASTER_FF is not set CONFIG_HID_WACOM=m CONFIG_HID_ZEROPLUS=m # CONFIG_ZEROPLUS_FF is not set CONFIG_USB_SUPPORT=y CONFIG_USB_ARCH_HAS_HCD=y CONFIG_USB_ARCH_HAS_OHCI=y CONFIG_USB_ARCH_HAS_EHCI=y CONFIG_USB=y # CONFIG_USB_DEBUG is not set # CONFIG_USB_ANNOUNCE_NEW_DEVICES is not set # # Miscellaneous USB options # # CONFIG_USB_DEVICEFS is not set CONFIG_USB_DEVICE_CLASS=y # CONFIG_USB_DYNAMIC_MINORS is not set CONFIG_USB_SUSPEND=y # CONFIG_USB_OTG is not set CONFIG_USB_MON=y # CONFIG_USB_WUSB is not set # CONFIG_USB_WUSB_CBAF is not set # # USB Host Controller Drivers # # CONFIG_USB_C67X00_HCD is not set # CONFIG_USB_XHCI_HCD is not set CONFIG_USB_EHCI_HCD=m CONFIG_USB_EHCI_ROOT_HUB_TT=y # CONFIG_USB_EHCI_TT_NEWSCHED is not set # CONFIG_USB_OXU210HP_HCD is not set # CONFIG_USB_ISP116X_HCD is not set # CONFIG_USB_ISP1760_HCD is not set CONFIG_USB_OHCI_HCD=m # CONFIG_USB_OHCI_BIG_ENDIAN_DESC is not set # CONFIG_USB_OHCI_BIG_ENDIAN_MMIO is not set CONFIG_USB_OHCI_LITTLE_ENDIAN=y CONFIG_USB_UHCI_HCD=m CONFIG_USB_SL811_HCD=m # CONFIG_USB_SL811_CS is not set # CONFIG_USB_R8A66597_HCD is not set # CONFIG_USB_WHCI_HCD is not set # CONFIG_USB_HWA_HCD is not set # # USB Device Class drivers # CONFIG_USB_ACM=m CONFIG_USB_PRINTER=m # CONFIG_USB_WDM is not set # CONFIG_USB_TMC is not set # # NOTE: USB_STORAGE depends on SCSI but BLK_DEV_SD may # # # also be needed; see USB_STORAGE Help for more info # CONFIG_USB_STORAGE=m # CONFIG_USB_STORAGE_DEBUG is not set # CONFIG_USB_STORAGE_DATAFAB is not set # CONFIG_USB_STORAGE_FREECOM is not set # CONFIG_USB_STORAGE_ISD200 is not set CONFIG_USB_STORAGE_USBAT=m # CONFIG_USB_STORAGE_SDDR09 is not set # CONFIG_USB_STORAGE_SDDR55 is not set # CONFIG_USB_STORAGE_JUMPSHOT is not set # CONFIG_USB_STORAGE_ALAUDA is not set # CONFIG_USB_STORAGE_ONETOUCH is not set # CONFIG_USB_STORAGE_KARMA is not set # CONFIG_USB_STORAGE_CYPRESS_ATACB is not set # CONFIG_USB_LIBUSUAL is not set # # USB Imaging devices # # CONFIG_USB_MDC800 is not set # CONFIG_USB_MICROTEK is not set # # USB port drivers # CONFIG_USB_USS720=m # CONFIG_USB_SERIAL is not set # # USB Miscellaneous drivers # # CONFIG_USB_EMI62 is not set # CONFIG_USB_EMI26 is not set # CONFIG_USB_ADUTUX is not set # CONFIG_USB_SEVSEG is not set # CONFIG_USB_RIO500 is not set # CONFIG_USB_LEGOTOWER is not set # CONFIG_USB_LCD is not set # CONFIG_USB_BERRY_CHARGE is not set CONFIG_USB_LED=m # CONFIG_USB_CYPRESS_CY7C63 is not set # CONFIG_USB_CYTHERM is not set # CONFIG_USB_IDMOUSE is not set # CONFIG_USB_FTDI_ELAN is not set # CONFIG_USB_APPLEDISPLAY is not set CONFIG_USB_SISUSBVGA=m CONFIG_USB_SISUSBVGA_CON=y CONFIG_USB_LD=m # CONFIG_USB_TRANCEVIBRATOR is not set # CONFIG_USB_IOWARRIOR is not set # CONFIG_USB_TEST is not set # CONFIG_USB_ISIGHTFW is not set # CONFIG_USB_VST is not set # CONFIG_USB_GADGET is not set # # OTG and related infrastructure # # CONFIG_NOP_USB_XCEIV is not set # CONFIG_UWB is not set CONFIG_MMC=m # CONFIG_MMC_DEBUG is not set # CONFIG_MMC_UNSAFE_RESUME is not set # # MMC/SD/SDIO Card Drivers # CONFIG_MMC_BLOCK=m CONFIG_MMC_BLOCK_BOUNCE=y CONFIG_SDIO_UART=m # CONFIG_MMC_TEST is not set # # MMC/SD/SDIO Host Controller Drivers # CONFIG_MMC_SDHCI=m CONFIG_MMC_SDHCI_PCI=m CONFIG_MMC_RICOH_MMC=m # CONFIG_MMC_SDHCI_PLTFM is not set # CONFIG_MMC_WBSD is not set # CONFIG_MMC_TIFM_SD is not set # CONFIG_MMC_SDRICOH_CS is not set # CONFIG_MMC_CB710 is not set # CONFIG_MMC_VIA_SDMMC is not set # CONFIG_MEMSTICK is not set CONFIG_NEW_LEDS=y CONFIG_LEDS_CLASS=m # # LED drivers # # CONFIG_LEDS_ALIX2 is not set # CONFIG_LEDS_PCA9532 is not set # CONFIG_LEDS_LP3944 is not set # CONFIG_LEDS_CLEVO_MAIL is not set # CONFIG_LEDS_PCA955X is not set # CONFIG_LEDS_BD2802 is not set # # LED Triggers # CONFIG_LEDS_TRIGGERS=y CONFIG_LEDS_TRIGGER_TIMER=m CONFIG_LEDS_TRIGGER_IDE_DISK=y CONFIG_LEDS_TRIGGER_HEARTBEAT=m # CONFIG_LEDS_TRIGGER_BACKLIGHT is not set CONFIG_LEDS_TRIGGER_DEFAULT_ON=m # # iptables trigger is under Netfilter config (LED target) # # CONFIG_ACCESSIBILITY is not set # CONFIG_INFINIBAND is not set # CONFIG_EDAC is not set CONFIG_RTC_LIB=y CONFIG_RTC_CLASS=y CONFIG_RTC_HCTOSYS=y CONFIG_RTC_HCTOSYS_DEVICE="rtc0" # CONFIG_RTC_DEBUG is not set # # RTC interfaces # CONFIG_RTC_INTF_SYSFS=y CONFIG_RTC_INTF_PROC=y CONFIG_RTC_INTF_DEV=y CONFIG_RTC_INTF_DEV_UIE_EMUL=y # CONFIG_RTC_DRV_TEST is not set # # I2C RTC drivers # # CONFIG_RTC_DRV_DS1307 is not set # CONFIG_RTC_DRV_DS1374 is not set # CONFIG_RTC_DRV_DS1672 is not set # CONFIG_RTC_DRV_MAX6900 is not set # CONFIG_RTC_DRV_RS5C372 is not set # CONFIG_RTC_DRV_ISL1208 is not set # CONFIG_RTC_DRV_X1205 is not set # CONFIG_RTC_DRV_PCF8563 is not set # CONFIG_RTC_DRV_PCF8583 is not set # CONFIG_RTC_DRV_M41T80 is not set # CONFIG_RTC_DRV_S35390A is not set # CONFIG_RTC_DRV_FM3130 is not set # CONFIG_RTC_DRV_RX8581 is not set # CONFIG_RTC_DRV_RX8025 is not set # # SPI RTC drivers # # # Platform RTC drivers # CONFIG_RTC_DRV_CMOS=y # CONFIG_RTC_DRV_DS1286 is not set # CONFIG_RTC_DRV_DS1511 is not set # CONFIG_RTC_DRV_DS1553 is not set # CONFIG_RTC_DRV_DS1742 is not set # CONFIG_RTC_DRV_STK17TA8 is not set # CONFIG_RTC_DRV_M48T86 is not set # CONFIG_RTC_DRV_M48T35 is not set # CONFIG_RTC_DRV_M48T59 is not set # CONFIG_RTC_DRV_BQ4802 is not set # CONFIG_RTC_DRV_V3020 is not set # # on-CPU RTC drivers # # CONFIG_DMADEVICES is not set # CONFIG_AUXDISPLAY is not set # CONFIG_UIO is not set # # TI VLYNQ # # CONFIG_STAGING is not set CONFIG_X86_PLATFORM_DEVICES=y # CONFIG_ACER_WMI is not set # CONFIG_ACERHDF is not set # CONFIG_ASUS_LAPTOP is not set # CONFIG_DELL_WMI is not set # CONFIG_FUJITSU_LAPTOP is not set CONFIG_HP_WMI=m # CONFIG_MSI_LAPTOP is not set # CONFIG_PANASONIC_LAPTOP is not set # CONFIG_COMPAL_LAPTOP is not set # CONFIG_SONY_LAPTOP is not set # CONFIG_THINKPAD_ACPI is not set # CONFIG_INTEL_MENLOW is not set CONFIG_ACPI_WMI=m # CONFIG_ACPI_ASUS is not set # CONFIG_ACPI_TOSHIBA is not set # # Firmware Drivers # # CONFIG_EDD is not set CONFIG_FIRMWARE_MEMMAP=y # CONFIG_DELL_RBU is not set # CONFIG_DCDBAS is not set CONFIG_DMIID=y # CONFIG_ISCSI_IBFT_FIND is not set # # File systems # CONFIG_EXT2_FS=m CONFIG_EXT2_FS_XATTR=y CONFIG_EXT2_FS_POSIX_ACL=y CONFIG_EXT2_FS_SECURITY=y # CONFIG_EXT2_FS_XIP is not set CONFIG_EXT3_FS=m CONFIG_EXT3_DEFAULTS_TO_ORDERED=y CONFIG_EXT3_FS_XATTR=y CONFIG_EXT3_FS_POSIX_ACL=y CONFIG_EXT3_FS_SECURITY=y # CONFIG_EXT4_FS is not set CONFIG_JBD=m # CONFIG_JBD_DEBUG is not set CONFIG_FS_MBCACHE=m # CONFIG_REISERFS_FS is not set # CONFIG_JFS_FS is not set CONFIG_FS_POSIX_ACL=y # CONFIG_XFS_FS is not set # CONFIG_GFS2_FS is not set # CONFIG_OCFS2_FS is not set # CONFIG_BTRFS_FS is not set CONFIG_FILE_LOCKING=y CONFIG_FSNOTIFY=y CONFIG_DNOTIFY=y CONFIG_INOTIFY=y CONFIG_INOTIFY_USER=y CONFIG_QUOTA=y # CONFIG_QUOTA_NETLINK_INTERFACE is not set CONFIG_PRINT_QUOTA_WARNING=y CONFIG_QUOTA_TREE=m CONFIG_QFMT_V1=m CONFIG_QFMT_V2=m CONFIG_QUOTACTL=y CONFIG_AUTOFS_FS=m CONFIG_AUTOFS4_FS=m CONFIG_FUSE_FS=m # CONFIG_CUSE is not set CONFIG_GENERIC_ACL=y # # Caches # # CONFIG_FSCACHE is not set # # CD-ROM/DVD Filesystems # CONFIG_ISO9660_FS=m CONFIG_JOLIET=y CONFIG_ZISOFS=y CONFIG_UDF_FS=m CONFIG_UDF_NLS=y # # DOS/FAT/NT Filesystems # CONFIG_FAT_FS=m CONFIG_MSDOS_FS=m CONFIG_VFAT_FS=m CONFIG_FAT_DEFAULT_CODEPAGE=437 CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1" CONFIG_NTFS_FS=m # CONFIG_NTFS_DEBUG is not set CONFIG_NTFS_RW=y # # Pseudo filesystems # CONFIG_PROC_FS=y CONFIG_PROC_KCORE=y CONFIG_PROC_SYSCTL=y CONFIG_PROC_PAGE_MONITOR=y CONFIG_SYSFS=y CONFIG_TMPFS=y CONFIG_TMPFS_POSIX_ACL=y # CONFIG_HUGETLBFS is not set # CONFIG_HUGETLB_PAGE is not set CONFIG_CONFIGFS_FS=m CONFIG_MISC_FILESYSTEMS=y # CONFIG_ADFS_FS is not set # CONFIG_AFFS_FS is not set CONFIG_ECRYPT_FS=m CONFIG_HFS_FS=m CONFIG_HFSPLUS_FS=m # CONFIG_BEFS_FS is not set # CONFIG_BFS_FS is not set # CONFIG_EFS_FS is not set # CONFIG_JFFS2_FS is not set # CONFIG_CRAMFS is not set # CONFIG_SQUASHFS is not set # CONFIG_VXFS_FS is not set # CONFIG_MINIX_FS is not set # CONFIG_OMFS_FS is not set # CONFIG_HPFS_FS is not set # CONFIG_QNX4FS_FS is not set CONFIG_ROMFS_FS=m CONFIG_ROMFS_BACKED_BY_BLOCK=y # CONFIG_ROMFS_BACKED_BY_MTD is not set # CONFIG_ROMFS_BACKED_BY_BOTH is not set CONFIG_ROMFS_ON_BLOCK=y # CONFIG_SYSV_FS is not set # CONFIG_UFS_FS is not set # CONFIG_NILFS2_FS is not set CONFIG_NETWORK_FILESYSTEMS=y CONFIG_NFS_FS=m CONFIG_NFS_V3=y CONFIG_NFS_V3_ACL=y CONFIG_NFS_V4=y # CONFIG_NFS_V4_1 is not set CONFIG_NFSD=m CONFIG_NFSD_V2_ACL=y CONFIG_NFSD_V3=y CONFIG_NFSD_V3_ACL=y CONFIG_NFSD_V4=y CONFIG_LOCKD=m CONFIG_LOCKD_V4=y CONFIG_EXPORTFS=m CONFIG_NFS_ACL_SUPPORT=m CONFIG_NFS_COMMON=y CONFIG_SUNRPC=m CONFIG_SUNRPC_GSS=m CONFIG_RPCSEC_GSS_KRB5=m CONFIG_RPCSEC_GSS_SPKM3=m # CONFIG_SMB_FS is not set CONFIG_CIFS=m # CONFIG_CIFS_STATS is not set # CONFIG_CIFS_WEAK_PW_HASH is not set # CONFIG_CIFS_UPCALL is not set # CONFIG_CIFS_XATTR is not set # CONFIG_CIFS_DEBUG2 is not set # CONFIG_CIFS_DFS_UPCALL is not set # CONFIG_CIFS_EXPERIMENTAL is not set # CONFIG_NCP_FS is not set # CONFIG_CODA_FS is not set # CONFIG_AFS_FS is not set # # Partition Types # CONFIG_PARTITION_ADVANCED=y # CONFIG_ACORN_PARTITION is not set # CONFIG_OSF_PARTITION is not set # CONFIG_AMIGA_PARTITION is not set # CONFIG_ATARI_PARTITION is not set # CONFIG_MAC_PARTITION is not set CONFIG_MSDOS_PARTITION=y CONFIG_BSD_DISKLABEL=y CONFIG_MINIX_SUBPARTITION=y CONFIG_SOLARIS_X86_PARTITION=y CONFIG_UNIXWARE_DISKLABEL=y CONFIG_LDM_PARTITION=y # CONFIG_LDM_DEBUG is not set # CONFIG_SGI_PARTITION is not set # CONFIG_ULTRIX_PARTITION is not set # CONFIG_SUN_PARTITION is not set # CONFIG_KARMA_PARTITION is not set # CONFIG_EFI_PARTITION is not set # CONFIG_SYSV68_PARTITION is not set CONFIG_NLS=y CONFIG_NLS_DEFAULT="iso8859-1" CONFIG_NLS_CODEPAGE_437=m # CONFIG_NLS_CODEPAGE_737 is not set # CONFIG_NLS_CODEPAGE_775 is not set CONFIG_NLS_CODEPAGE_850=m # CONFIG_NLS_CODEPAGE_852 is not set # CONFIG_NLS_CODEPAGE_855 is not set # CONFIG_NLS_CODEPAGE_857 is not set # CONFIG_NLS_CODEPAGE_860 is not set # CONFIG_NLS_CODEPAGE_861 is not set # CONFIG_NLS_CODEPAGE_862 is not set # CONFIG_NLS_CODEPAGE_863 is not set # CONFIG_NLS_CODEPAGE_864 is not set # CONFIG_NLS_CODEPAGE_865 is not set # CONFIG_NLS_CODEPAGE_866 is not set # CONFIG_NLS_CODEPAGE_869 is not set # CONFIG_NLS_CODEPAGE_936 is not set # CONFIG_NLS_CODEPAGE_950 is not set # CONFIG_NLS_CODEPAGE_932 is not set # CONFIG_NLS_CODEPAGE_949 is not set # CONFIG_NLS_CODEPAGE_874 is not set # CONFIG_NLS_ISO8859_8 is not set # CONFIG_NLS_CODEPAGE_1250 is not set # CONFIG_NLS_CODEPAGE_1251 is not set CONFIG_NLS_ASCII=m CONFIG_NLS_ISO8859_1=m # CONFIG_NLS_ISO8859_2 is not set # CONFIG_NLS_ISO8859_3 is not set # CONFIG_NLS_ISO8859_4 is not set # CONFIG_NLS_ISO8859_5 is not set # CONFIG_NLS_ISO8859_6 is not set # CONFIG_NLS_ISO8859_7 is not set # CONFIG_NLS_ISO8859_9 is not set # CONFIG_NLS_ISO8859_13 is not set # CONFIG_NLS_ISO8859_14 is not set CONFIG_NLS_ISO8859_15=m # CONFIG_NLS_KOI8_R is not set # CONFIG_NLS_KOI8_U is not set CONFIG_NLS_UTF8=m CONFIG_DLM=m CONFIG_DLM_DEBUG=y # # Kernel hacking # CONFIG_TRACE_IRQFLAGS_SUPPORT=y # CONFIG_PRINTK_TIME is not set CONFIG_ENABLE_WARN_DEPRECATED=y CONFIG_ENABLE_MUST_CHECK=y CONFIG_FRAME_WARN=2048 CONFIG_MAGIC_SYSRQ=y CONFIG_UNUSED_SYMBOLS=y CONFIG_DEBUG_FS=y # CONFIG_HEADERS_CHECK is not set CONFIG_DEBUG_KERNEL=y # CONFIG_DEBUG_SHIRQ is not set CONFIG_DETECT_SOFTLOCKUP=y # CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC is not set CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC_VALUE=0 CONFIG_DETECT_HUNG_TASK=y # CONFIG_BOOTPARAM_HUNG_TASK_PANIC is not set CONFIG_BOOTPARAM_HUNG_TASK_PANIC_VALUE=0 CONFIG_SCHED_DEBUG=y CONFIG_SCHEDSTATS=y CONFIG_TIMER_STATS=y # CONFIG_DEBUG_OBJECTS is not set # CONFIG_SLUB_DEBUG_ON is not set # CONFIG_SLUB_STATS is not set # CONFIG_DEBUG_KMEMLEAK is not set # CONFIG_DEBUG_RT_MUTEXES is not set # CONFIG_RT_MUTEX_TESTER is not set CONFIG_DEBUG_SPINLOCK=y CONFIG_DEBUG_MUTEXES=y # CONFIG_DEBUG_LOCK_ALLOC is not set # CONFIG_PROVE_LOCKING is not set # CONFIG_LOCK_STAT is not set CONFIG_DEBUG_SPINLOCK_SLEEP=y # CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set CONFIG_STACKTRACE=y # CONFIG_DEBUG_KOBJECT is not set CONFIG_DEBUG_BUGVERBOSE=y # CONFIG_DEBUG_INFO is not set # CONFIG_DEBUG_VM is not set # CONFIG_DEBUG_VIRTUAL is not set # CONFIG_DEBUG_WRITECOUNT is not set CONFIG_DEBUG_MEMORY_INIT=y # CONFIG_DEBUG_LIST is not set # CONFIG_DEBUG_SG is not set # CONFIG_DEBUG_NOTIFIERS is not set CONFIG_ARCH_WANT_FRAME_POINTERS=y CONFIG_FRAME_POINTER=y # CONFIG_BOOT_PRINTK_DELAY is not set # CONFIG_RCU_TORTURE_TEST is not set # CONFIG_RCU_CPU_STALL_DETECTOR is not set # CONFIG_BACKTRACE_SELF_TEST is not set # CONFIG_DEBUG_BLOCK_EXT_DEVT is not set # CONFIG_FAULT_INJECTION is not set CONFIG_LATENCYTOP=y CONFIG_SYSCTL_SYSCALL_CHECK=y # CONFIG_DEBUG_PAGEALLOC is not set CONFIG_USER_STACKTRACE_SUPPORT=y CONFIG_HAVE_FUNCTION_TRACER=y CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y CONFIG_HAVE_FUNCTION_GRAPH_FP_TEST=y CONFIG_HAVE_FUNCTION_TRACE_MCOUNT_TEST=y CONFIG_HAVE_DYNAMIC_FTRACE=y CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y CONFIG_HAVE_FTRACE_SYSCALLS=y CONFIG_TRACING_SUPPORT=y # CONFIG_FTRACE is not set # CONFIG_PROVIDE_OHCI1394_DMA_INIT is not set # CONFIG_DYNAMIC_DEBUG is not set # CONFIG_DMA_API_DEBUG is not set # CONFIG_SAMPLES is not set CONFIG_HAVE_ARCH_KGDB=y # CONFIG_KGDB is not set CONFIG_HAVE_ARCH_KMEMCHECK=y CONFIG_STRICT_DEVMEM=y CONFIG_X86_VERBOSE_BOOTUP=y CONFIG_EARLY_PRINTK=y # CONFIG_EARLY_PRINTK_DBGP is not set # CONFIG_DEBUG_STACKOVERFLOW is not set # CONFIG_DEBUG_STACK_USAGE is not set # CONFIG_DEBUG_PER_CPU_MAPS is not set # CONFIG_X86_PTDUMP is not set # CONFIG_DEBUG_RODATA is not set # CONFIG_DEBUG_NX_TEST is not set # CONFIG_IOMMU_DEBUG is not set # CONFIG_IOMMU_STRESS is not set CONFIG_HAVE_MMIOTRACE_SUPPORT=y CONFIG_IO_DELAY_TYPE_0X80=0 CONFIG_IO_DELAY_TYPE_0XED=1 CONFIG_IO_DELAY_TYPE_UDELAY=2 CONFIG_IO_DELAY_TYPE_NONE=3 CONFIG_IO_DELAY_0X80=y # CONFIG_IO_DELAY_0XED is not set # CONFIG_IO_DELAY_UDELAY is not set # CONFIG_IO_DELAY_NONE is not set CONFIG_DEFAULT_IO_DELAY_TYPE=0 # CONFIG_DEBUG_BOOT_PARAMS is not set # CONFIG_CPA_DEBUG is not set CONFIG_OPTIMIZE_INLINING=y # # Security options # CONFIG_KEYS=y # CONFIG_KEYS_DEBUG_PROC_KEYS is not set CONFIG_SECURITY=y CONFIG_SECURITYFS=y CONFIG_SECURITY_NETWORK=y CONFIG_SECURITY_NETWORK_XFRM=y # CONFIG_SECURITY_PATH is not set # CONFIG_SECURITY_FILE_CAPABILITIES is not set # CONFIG_SECURITY_ROOTPLUG is not set CONFIG_LSM_MMAP_MIN_ADDR=65536 CONFIG_SECURITY_SELINUX=y CONFIG_SECURITY_SELINUX_BOOTPARAM=y CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=0 CONFIG_SECURITY_SELINUX_DISABLE=y CONFIG_SECURITY_SELINUX_DEVELOP=y CONFIG_SECURITY_SELINUX_AVC_STATS=y CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=1 # CONFIG_SECURITY_SELINUX_POLICYDB_VERSION_MAX is not set # CONFIG_SECURITY_TOMOYO is not set # CONFIG_IMA is not set CONFIG_XOR_BLOCKS=m CONFIG_ASYNC_CORE=m CONFIG_ASYNC_MEMCPY=m CONFIG_ASYNC_XOR=m CONFIG_CRYPTO=y # # Crypto core or helper # CONFIG_CRYPTO_FIPS=y CONFIG_CRYPTO_ALGAPI=y CONFIG_CRYPTO_ALGAPI2=y CONFIG_CRYPTO_AEAD=m CONFIG_CRYPTO_AEAD2=y CONFIG_CRYPTO_BLKCIPHER=m CONFIG_CRYPTO_BLKCIPHER2=y CONFIG_CRYPTO_HASH=y CONFIG_CRYPTO_HASH2=y CONFIG_CRYPTO_RNG=m CONFIG_CRYPTO_RNG2=y CONFIG_CRYPTO_PCOMP=y CONFIG_CRYPTO_MANAGER=y CONFIG_CRYPTO_MANAGER2=y CONFIG_CRYPTO_GF128MUL=m CONFIG_CRYPTO_NULL=m CONFIG_CRYPTO_WORKQUEUE=y CONFIG_CRYPTO_CRYPTD=m CONFIG_CRYPTO_AUTHENC=m CONFIG_CRYPTO_TEST=m # # Authenticated Encryption with Associated Data # # CONFIG_CRYPTO_CCM is not set # CONFIG_CRYPTO_GCM is not set # CONFIG_CRYPTO_SEQIV is not set # # Block modes # CONFIG_CRYPTO_CBC=m # CONFIG_CRYPTO_CTR is not set # CONFIG_CRYPTO_CTS is not set CONFIG_CRYPTO_ECB=m CONFIG_CRYPTO_LRW=m CONFIG_CRYPTO_PCBC=m CONFIG_CRYPTO_XTS=m CONFIG_CRYPTO_FPU=m # # Hash modes # CONFIG_CRYPTO_HMAC=y CONFIG_CRYPTO_XCBC=m # # Digest # CONFIG_CRYPTO_CRC32C=m # CONFIG_CRYPTO_CRC32C_INTEL is not set CONFIG_CRYPTO_MD4=m CONFIG_CRYPTO_MD5=y CONFIG_CRYPTO_MICHAEL_MIC=m # CONFIG_CRYPTO_RMD128 is not set # CONFIG_CRYPTO_RMD160 is not set # CONFIG_CRYPTO_RMD256 is not set # CONFIG_CRYPTO_RMD320 is not set CONFIG_CRYPTO_SHA1=m CONFIG_CRYPTO_SHA256=m CONFIG_CRYPTO_SHA512=m CONFIG_CRYPTO_TGR192=m CONFIG_CRYPTO_WP512=m # # Ciphers # CONFIG_CRYPTO_AES=m CONFIG_CRYPTO_AES_X86_64=m CONFIG_CRYPTO_AES_NI_INTEL=m CONFIG_CRYPTO_ANUBIS=m CONFIG_CRYPTO_ARC4=m CONFIG_CRYPTO_BLOWFISH=m CONFIG_CRYPTO_CAMELLIA=m CONFIG_CRYPTO_CAST5=m CONFIG_CRYPTO_CAST6=m CONFIG_CRYPTO_DES=m CONFIG_CRYPTO_FCRYPT=m CONFIG_CRYPTO_KHAZAD=m # CONFIG_CRYPTO_SALSA20 is not set # CONFIG_CRYPTO_SALSA20_X86_64 is not set CONFIG_CRYPTO_SEED=m CONFIG_CRYPTO_SERPENT=m CONFIG_CRYPTO_TEA=m CONFIG_CRYPTO_TWOFISH=m CONFIG_CRYPTO_TWOFISH_COMMON=m CONFIG_CRYPTO_TWOFISH_X86_64=m # # Compression # CONFIG_CRYPTO_DEFLATE=m CONFIG_CRYPTO_ZLIB=m # CONFIG_CRYPTO_LZO is not set # # Random Number Generation # CONFIG_CRYPTO_ANSI_CPRNG=m # CONFIG_CRYPTO_HW is not set CONFIG_HAVE_KVM=y CONFIG_HAVE_KVM_IRQCHIP=y # CONFIG_VIRTUALIZATION is not set # CONFIG_BINARY_PRINTF is not set # # Library routines # CONFIG_BITREVERSE=y CONFIG_GENERIC_FIND_FIRST_BIT=y CONFIG_GENERIC_FIND_NEXT_BIT=y CONFIG_GENERIC_FIND_LAST_BIT=y CONFIG_CRC_CCITT=m CONFIG_CRC16=m CONFIG_CRC_T10DIF=m CONFIG_CRC_ITU_T=m CONFIG_CRC32=y CONFIG_CRC7=m CONFIG_LIBCRC32C=m CONFIG_ZLIB_INFLATE=y CONFIG_ZLIB_DEFLATE=m CONFIG_DECOMPRESS_GZIP=y CONFIG_DECOMPRESS_BZIP2=y CONFIG_DECOMPRESS_LZMA=y CONFIG_TEXTSEARCH=y CONFIG_TEXTSEARCH_KMP=m CONFIG_TEXTSEARCH_BM=m CONFIG_TEXTSEARCH_FSM=m CONFIG_HAS_IOMEM=y CONFIG_HAS_IOPORT=y CONFIG_HAS_DMA=y CONFIG_NLATTR=y ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: iwlagn: order 2 page allocation failures 2009-09-06 8:28 ` Frans Pop @ 2009-09-06 8:35 ` Pekka Enberg 2009-09-08 10:54 ` Mel Gorman 0 siblings, 1 reply; 66+ messages in thread From: Pekka Enberg @ 2009-09-06 8:35 UTC (permalink / raw) To: Frans Pop Cc: linux-kernel, linux-wireless, ipw3945-devel, Mel Gorman, Andrew Morton, cl On Sun, 2009-09-06 at 10:28 +0200, Frans Pop wrote: > On Sunday 06 September 2009, Pekka Enberg wrote: > > On Sun, Sep 6, 2009 at 10:40 AM, Frans Pop<elendil@planet.nl> wrote: > > > Got a couple of page allocation failures today while viewing fairly > > > large images. System was struggling for a bit to reorganize memory > > > and swap, but nothing really serious. Everything recovered fairly > > > quickly. > > > > > > Anything to look into? > > > > > > System: HP 2510p; 2.6.31-rc7-56-g7c0a57d; Debian stable, KDE desktop > > > > > > 10:00.0 Network controller [0280]: Intel Corporation PRO/Wireless > > > 4965 AG or AGN [Kedron] Network Connection [8086:4229] (rev 61) > > > > Can you post your .config, please? > > Attached. Thanks. OK, so SLUB_DEBUG_ON is disabled so it's probably not a SLUB problem. Mel, there's quite a few page allocation failure reports recently which makes me wonder if we broke something with the page allocator optimization patches? Do you think the anti-fragmentation fixlet you did for nommu would help here? Pekka ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: iwlagn: order 2 page allocation failures 2009-09-06 8:35 ` Pekka Enberg @ 2009-09-08 10:54 ` Mel Gorman 2009-09-08 11:11 ` Pekka Enberg 0 siblings, 1 reply; 66+ messages in thread From: Mel Gorman @ 2009-09-08 10:54 UTC (permalink / raw) To: Pekka Enberg Cc: Frans Pop, linux-kernel, linux-wireless, ipw3945-devel, Andrew Morton, cl On Sun, Sep 06, 2009 at 11:35:16AM +0300, Pekka Enberg wrote: > On Sun, 2009-09-06 at 10:28 +0200, Frans Pop wrote: > > On Sunday 06 September 2009, Pekka Enberg wrote: > > > On Sun, Sep 6, 2009 at 10:40 AM, Frans Pop<elendil@planet.nl> wrote: > > > > Got a couple of page allocation failures today while viewing fairly > > > > large images. System was struggling for a bit to reorganize memory > > > > and swap, but nothing really serious. Everything recovered fairly > > > > quickly. > > > > > > > > Anything to look into? > > > > > > > > System: HP 2510p; 2.6.31-rc7-56-g7c0a57d; Debian stable, KDE desktop > > > > > > > > 10:00.0 Network controller [0280]: Intel Corporation PRO/Wireless > > > > 4965 AG or AGN [Kedron] Network Connection [8086:4229] (rev 61) > > > > > > Can you post your .config, please? > > > > Attached. Thanks. > > OK, so SLUB_DEBUG_ON is disabled so it's probably not a SLUB problem. > Mel, there's quite a few page allocation failure reports recently which > makes me wonder if we broke something with the page allocator > optimization patches? Do you think the anti-fragmentation fixlet you did > for nommu would help here? > No, because that change only affected the case where the system had very little memory. The last time that there was a sudden major increase in allocation failures, it was actually was page reclaim was broken - specifically kswapd was no longer doing the job that was expected of it. The symptoms where applications stalling because they were entering direct reclaim. I haven't looked very closely at this bug report yet (catching up from being offline the last 5 days). Have there been any reclaim changes that might account for something like this? My feeling is also that a number of these page allocation failures have been related to wireless drivers. Is that accurate? If so, have there been changes made to the wireless stack in this cycle that would have increased the order of pages allocated? -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: iwlagn: order 2 page allocation failures 2009-09-08 10:54 ` Mel Gorman @ 2009-09-08 11:11 ` Pekka Enberg 2009-09-08 14:17 ` John W. Linville 0 siblings, 1 reply; 66+ messages in thread From: Pekka Enberg @ 2009-09-08 11:11 UTC (permalink / raw) To: Mel Gorman Cc: Frans Pop, linux-kernel, linux-wireless, ipw3945-devel, Andrew Morton, cl On Tue, Sep 8, 2009 at 1:54 PM, Mel Gorman<mel@csn.ul.ie> wrote: > My feeling is also that a number of these page allocation failures have > been related to wireless drivers. Is that accurate? If so, have there > been changes made to the wireless stack in this cycle that would have > increased the order of pages allocated? That's my general feeling as well. We have linux-wireless CC'd so maybe this rings a bell for them. ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: iwlagn: order 2 page allocation failures 2009-09-08 11:11 ` Pekka Enberg @ 2009-09-08 14:17 ` John W. Linville 2009-09-08 14:59 ` Larry Finger 0 siblings, 1 reply; 66+ messages in thread From: John W. Linville @ 2009-09-08 14:17 UTC (permalink / raw) To: Pekka Enberg Cc: Mel Gorman, Frans Pop, linux-kernel, linux-wireless, ipw3945-devel, Andrew Morton, cl On Tue, Sep 08, 2009 at 02:11:35PM +0300, Pekka Enberg wrote: > On Tue, Sep 8, 2009 at 1:54 PM, Mel Gorman<mel@csn.ul.ie> wrote: > > My feeling is also that a number of these page allocation failures have > > been related to wireless drivers. Is that accurate? If so, have there > > been changes made to the wireless stack in this cycle that would have > > increased the order of pages allocated? > > That's my general feeling as well. We have linux-wireless CC'd so > maybe this rings a bell for them. AFAIK, this is only the second separate report. The other related to ipw2200, which actually shares no code with the iwlagn driver and is not based on the mac80211 stack. Hth! John -- John W. Linville Someday the world will need a hero, and you linville@tuxdriver.com might be all we have. Be ready. ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: iwlagn: order 2 page allocation failures 2009-09-08 14:17 ` John W. Linville @ 2009-09-08 14:59 ` Larry Finger 2009-09-09 15:04 ` Mel Gorman 0 siblings, 1 reply; 66+ messages in thread From: Larry Finger @ 2009-09-08 14:59 UTC (permalink / raw) To: John W. Linville Cc: Pekka Enberg, Mel Gorman, Frans Pop, linux-kernel, linux-wireless, ipw3945-devel, Andrew Morton, cl John W. Linville wrote: > On Tue, Sep 08, 2009 at 02:11:35PM +0300, Pekka Enberg wrote: >> On Tue, Sep 8, 2009 at 1:54 PM, Mel Gorman<mel@csn.ul.ie> wrote: >>> My feeling is also that a number of these page allocation failures have >>> been related to wireless drivers. Is that accurate? If so, have there >>> been changes made to the wireless stack in this cycle that would have >>> increased the order of pages allocated? >> That's my general feeling as well. We have linux-wireless CC'd so >> maybe this rings a bell for them. > > AFAIK, this is only the second separate report. The other related > to ipw2200, which actually shares no code with the iwlagn driver and > is not based on the mac80211 stack. A previous issue concerned the interaction between wireless and SLUB debugging that caused O(0) allocations to get bumped to O(1), but that was not relevant to this case either. I'm not aware of any other page allocation problems with wireless. Larry ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: iwlagn: order 2 page allocation failures 2009-09-08 14:59 ` Larry Finger @ 2009-09-09 15:04 ` Mel Gorman 2009-09-09 15:59 ` Frans Pop 0 siblings, 1 reply; 66+ messages in thread From: Mel Gorman @ 2009-09-09 15:04 UTC (permalink / raw) To: Larry Finger Cc: John W. Linville, Pekka Enberg, Frans Pop, linux-kernel, linux-wireless, ipw3945-devel, Andrew Morton, cl On Tue, Sep 08, 2009 at 09:59:05AM -0500, Larry Finger wrote: > John W. Linville wrote: > > On Tue, Sep 08, 2009 at 02:11:35PM +0300, Pekka Enberg wrote: > >> On Tue, Sep 8, 2009 at 1:54 PM, Mel Gorman<mel@csn.ul.ie> wrote: > >>> My feeling is also that a number of these page allocation failures have > >>> been related to wireless drivers. Is that accurate? If so, have there > >>> been changes made to the wireless stack in this cycle that would have > >>> increased the order of pages allocated? > >> That's my general feeling as well. We have linux-wireless CC'd so > >> maybe this rings a bell for them. > > > > AFAIK, this is only the second separate report. The other related > > to ipw2200, which actually shares no code with the iwlagn driver and > > is not based on the mac80211 stack. > > A previous issue concerned the interaction between wireless and SLUB > debugging that caused O(0) allocations to get bumped to O(1), but that Ok, but now they are getting bumped to order-2 because that is the allocation failure that's happening here. That's pretty risky for a __GFP_HIGH|__GFP_COMP allocation - i.e. high-priority and atomic allocation. > was not relevant to this case either. I'm not aware of any other page > allocation problems with wireless. > Are atomic order-2 allocations really expected in wireless or has something else changed recently? Other than slub-debug, what options have been recently added that can push kmalloc() requests up slightly and possible make an order-1 allocation an order-2? If it's not in wireless, has there been additional padding added to skbuffs in the networking layer that might have pushed an allocation over an order-1 boundary increasing the size of the allocation to order-2? The reporter says that the machine grinds for a bit and recovers which is consistent with kswapd kicking in to reclaim the contiguous pages but it's hardly desirable. Franz, in the full dmesg was there any mention of "SLUB: Unable to allocate memory on node"? If so, could you post the contents of that as well because it should tell us more about the slab allocation that failed which vaguely looks like the path that went splat. Also, did you have any slub debug options enabled on the command line? Thanks -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: iwlagn: order 2 page allocation failures 2009-09-09 15:04 ` Mel Gorman @ 2009-09-09 15:59 ` Frans Pop 2009-09-09 16:55 ` Mel Gorman 0 siblings, 1 reply; 66+ messages in thread From: Frans Pop @ 2009-09-09 15:59 UTC (permalink / raw) To: Mel Gorman Cc: Larry Finger, John W. Linville, Pekka Enberg, linux-kernel, linux-wireless, ipw3945-devel, Andrew Morton, cl On Wednesday 09 September 2009, Mel Gorman wrote: > Franz, in the full dmesg was there any mention of "SLUB: Unable to > allocate memory on node"? No, nothing at all. I double checked the kernel log, but it was completely quiet in the hours before and after the messages I already posted. > Also, did you have any slub debug options enabled on the command line? Nope. Cheers, FJP ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: iwlagn: order 2 page allocation failures 2009-09-09 15:59 ` Frans Pop @ 2009-09-09 16:55 ` Mel Gorman 2009-09-09 17:19 ` Frans Pop ` (2 more replies) 0 siblings, 3 replies; 66+ messages in thread From: Mel Gorman @ 2009-09-09 16:55 UTC (permalink / raw) To: Frans Pop Cc: Larry Finger, John W. Linville, Pekka Enberg, linux-kernel, linux-wireless, ipw3945-devel, Andrew Morton, cl, Assaf Krauss, Johannes Berg, Mohamed Abbas On Wed, Sep 09, 2009 at 05:59:30PM +0200, Frans Pop wrote: > On Wednesday 09 September 2009, Mel Gorman wrote: > > Franz, in the full dmesg was there any mention of "SLUB: Unable to > > allocate memory on node"? > > No, nothing at all. I double checked the kernel log, but it was completely > quiet in the hours before and after the messages I already posted. > Ok, that in itself is unexpected. Pekka, it looks from the stack trace that the failure is from __alloc_skb and I am guessing the failure path is around here size = SKB_DATA_ALIGN(size); data = kmalloc_node_track_caller(size + sizeof(struct skb_shared_info), gfp_mask, node); if (!data) goto nodata; Why would the SLUB out-of-memory message not appear? It's hardly tripping up on printk_ratelimit() is it? > > Also, did you have any slub debug options enabled on the command line? > > Nope. > Ok, just best to rule it out. Apologies for the scattershot approach to figuring out where the order-2 failures are coming from and am not familiar at all with the driver. According to the logs, the card is a 4965 AG so I can only assume the relevant driver code is iwl4965. Since commit 1ea8739648cfff4027c3db0f4cee5de87bfd3886, this has enabled by default a module option called amsdu_size_8K. At a glance, it looks like this will guarantee that at least order-1 allocations will be required. Assaf and other wireless folks, is that intentional? What are the consequences of defaulting that to being off? What might have made this worse is commit 4018517a1a69a85c3d61b20fa02f187b80773137 which intends to fix an RX skb alignment problem but looks like it would have the side-effect of 8192 byte allocations becoming 8448 byte allocations and kmalloc() having to do an order-2 allocation instead of order-1. The problem with this theory is that the patches have been in since Nov 2008 but reports are only showing up now. Frans, how sure are you that this is a recent problem? Is it readily reproducible? Conceivably a better candidate for this problem is commit 4752c93c30441f98f7ed723001b1a5e3e5619829 introduced in May 2009. If there are less than RX_QUEUE_SIZE/2 left, it starts replenishing buffers. Mohamed, is it absolutly necessary it use GFP_ATOMIC there? If an allocation fails, does it always mean frames are dropped or could it just replenish what it can and try again later printing a warning only if allocation failures are resulting in packet loss? -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: iwlagn: order 2 page allocation failures 2009-09-09 16:55 ` Mel Gorman @ 2009-09-09 17:19 ` Frans Pop 2009-09-16 14:36 ` Frans Pop 2009-09-09 20:05 ` reinette chatre 2009-09-10 8:18 ` Pekka Enberg 2 siblings, 1 reply; 66+ messages in thread From: Frans Pop @ 2009-09-09 17:19 UTC (permalink / raw) To: Mel Gorman Cc: Larry Finger, John W. Linville, Pekka Enberg, linux-kernel, linux-wireless, ipw3945-devel, Andrew Morton, cl, Assaf Krauss, Johannes Berg, Mohamed Abbas On Wednesday 09 September 2009, you wrote: > The problem with this theory is that the patches have been in since Nov > 2008 but reports are only showing up now. Frans, how sure are you that > this is a recent problem? Is it readily reproducible? The only thing I can say here is that I've never seen the issue before (and thanks to logcheck I certainly would have). The laptop is in constant use, but I rarely stress the memory like that. Swap is almost always at 0. I would have to make an effort to try and reproduce it, probably by again creating some very large images and loading those in konqueror, maybe while streaming a movie over wireless or something. Thanks for your efforts, FJP ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: iwlagn: order 2 page allocation failures 2009-09-09 17:19 ` Frans Pop @ 2009-09-16 14:36 ` Frans Pop 2009-09-16 15:02 ` Mel Gorman 0 siblings, 1 reply; 66+ messages in thread From: Frans Pop @ 2009-09-16 14:36 UTC (permalink / raw) To: Mel Gorman Cc: Larry Finger, John W. Linville, Pekka Enberg, linux-kernel, linux-wireless, ipw3945-devel, Andrew Morton, cl, Assaf Krauss, Johannes Berg, Mohamed Abbas On Wednesday 09 September 2009, Frans Pop wrote: > On Wednesday 09 September 2009, you wrote: > > The problem with this theory is that the patches have been in since > > Nov 2008 but reports are only showing up now. Frans, how sure are you > > that this is a recent problem? Is it readily reproducible? > > The only thing I can say here is that I've never seen the issue before > (and thanks to logcheck I certainly would have). > The laptop is in constant use, but I rarely stress the memory like that. > Swap is almost always at 0. JFYI, it happened again yesterday. The first time it was swapper, here it's kcryptd. The top part of the trace is the same. kcryptd: page allocation failure. order:2, mode:0x4020 Pid: 1347, comm: kcryptd Not tainted 2.6.31-rc9 #16 Call Trace: <IRQ> [<ffffffff810790b0>] __alloc_pages_nodemask+0x542/0x58a [<ffffffff81256a62>] ? _spin_unlock+0x9/0xb [<ffffffff811da481>] ? __alloc_skb+0x3c/0x15b [<ffffffffa0355644>] ? iwl_rx_allocate+0xac/0x208 [iwlcore] [<ffffffff81079153>] __get_free_pages+0x12/0x41 [<ffffffff810982c5>] __kmalloc_track_caller+0x3b/0xec [<ffffffff811da4ab>] __alloc_skb+0x66/0x15b [<ffffffffa0355644>] iwl_rx_allocate+0xac/0x208 [iwlcore] [<ffffffffa03557b6>] iwl_rx_replenish_now+0x16/0x23 [iwlcore] [<ffffffffa037c8e3>] iwl_rx_handle+0x356/0x39a [iwlagn] [<ffffffffa00212a2>] ? scsi_io_completion+0x3a8/0x3d1 [scsi_mod] [<ffffffffa037ce27>] iwl_irq_tasklet_legacy+0x500/0x74f [iwlagn] [<ffffffffa001a81b>] ? scsi_finish_command+0xec/0xf5 [scsi_mod] [<ffffffff8103dff0>] tasklet_action+0x71/0xbc [<ffffffff8103e877>] __do_softirq+0x9b/0x12c [<ffffffff8100cb7c>] call_softirq+0x1c/0x28 [<ffffffff8100e694>] do_softirq+0x34/0x72 [<ffffffff8103e601>] irq_exit+0x3f/0x79 [<ffffffff8100dd95>] do_IRQ+0xa3/0xba [<ffffffff8100c413>] ret_from_intr+0x0/0xa <EOI> [<ffffffffa01fb5b8>] ? enc128+0x243/0x80b [aes_x86_64] [<ffffffffa01fc72b>] ? aes_encrypt+0xd/0xf [aes_x86_64] [<ffffffffa01e92b6>] ? crypto_cbc_encrypt+0x12c/0x18e [cbc] [<ffffffff81078c9b>] ? __alloc_pages_nodemask+0x12d/0x58a [<ffffffffa01fc71e>] ? aes_encrypt+0x0/0xf [aes_x86_64] [<ffffffff81113ea0>] ? async_encrypt+0x38/0x3a [<ffffffff81075a94>] ? mempool_alloc+0x5b/0x113 [<ffffffffa01c5b53>] ? crypt_convert+0x1f9/0x278 [dm_crypt] [<ffffffffa01c5ff5>] ? kcryptd_crypt+0x423/0x449 [dm_crypt] [<ffffffffa01c5bd2>] ? kcryptd_crypt+0x0/0x449 [dm_crypt] [<ffffffff81048bc5>] ? worker_thread+0x132/0x1ca [<ffffffff8104c647>] ? autoremove_wake_function+0x0/0x38 [<ffffffff81048a93>] ? worker_thread+0x0/0x1ca [<ffffffff8104c325>] ? kthread+0x8f/0x97 [<ffffffff8100ca7a>] ? child_rip+0xa/0x20 [<ffffffff8104c296>] ? kthread+0x0/0x97 [<ffffffff8100ca70>] ? child_rip+0x0/0x20 Mem-Info: DMA per-cpu: CPU 0: hi: 0, btch: 1 usd: 0 CPU 1: hi: 0, btch: 1 usd: 0 DMA32 per-cpu: CPU 0: hi: 186, btch: 31 usd: 172 CPU 1: hi: 186, btch: 31 usd: 163 Active_anon:278449 active_file:18846 inactive_anon:93192 inactive_file:18343 unevictable:407 dirty:0 writeback:7726 unstable:0 free:25175 slab:10409 mapped:34634 pagetables:4385 bounce:0 DMA free:7924kB min:40kB low:48kB high:60kB active_anon:2220kB inactive_anon:2464kB active_file:1084kB inactive_file:1608kB unevictable:0kB present:15336kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 1976 1976 1976 DMA32 free:92776kB min:5664kB low:7080kB high:8496kB active_anon:1111448kB inactive_anon:370432kB active_file:74300kB inactive_file:71764kB unevictable:1628kB present:2023748kB pages_scanned:32 all_unreclaimable? no lowmem_reserve[]: 0 0 0 0 DMA: 63*4kB 59*8kB 26*16kB 34*32kB 23*64kB 1*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 1*4096kB = 7924kB DMA32: 18882*4kB 2076*8kB 10*16kB 1*32kB 1*64kB 1*128kB 1*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 92776kB 82554 total pagecache pages 44961 pages in swap cache Swap cache stats: add 160004, delete 115046, find 2431510/2434120 Free swap = 1549576kB Total swap = 2097144kB 518064 pages RAM 10323 pages reserved 117029 pages shared 398165 pages non-shared iwlagn 0000:10:00.0: Can not allocate SKB buffers kcryptd: page allocation failure. order:2, mode:0x4020 Pid: 1347, comm: kcryptd Not tainted 2.6.31-rc9 #16 Call Trace: <IRQ> [<ffffffff810790b0>] __alloc_pages_nodemask+0x542/0x58a [<ffffffff81256a62>] ? _spin_unlock+0x9/0xb [<ffffffff811da481>] ? __alloc_skb+0x3c/0x15b [<ffffffffa0355644>] ? iwl_rx_allocate+0xac/0x208 [iwlcore] [<ffffffff81079153>] __get_free_pages+0x12/0x41 [<ffffffff810982c5>] __kmalloc_track_caller+0x3b/0xec [<ffffffff811da4ab>] __alloc_skb+0x66/0x15b [<ffffffffa0355644>] iwl_rx_allocate+0xac/0x208 [iwlcore] [<ffffffffa03557b6>] iwl_rx_replenish_now+0x16/0x23 [iwlcore] [<ffffffffa037c90e>] iwl_rx_handle+0x381/0x39a [iwlagn] [<ffffffffa00212a2>] ? scsi_io_completion+0x3a8/0x3d1 [scsi_mod] [<ffffffffa037ce27>] iwl_irq_tasklet_legacy+0x500/0x74f [iwlagn] [<ffffffffa001a81b>] ? scsi_finish_command+0xec/0xf5 [scsi_mod] [<ffffffff8103dff0>] tasklet_action+0x71/0xbc [<ffffffff8103e877>] __do_softirq+0x9b/0x12c [<ffffffff8100cb7c>] call_softirq+0x1c/0x28 [<ffffffff8100e694>] do_softirq+0x34/0x72 [<ffffffff8103e601>] irq_exit+0x3f/0x79 [<ffffffff8100dd95>] do_IRQ+0xa3/0xba [<ffffffff8100c413>] ret_from_intr+0x0/0xa <EOI> [<ffffffffa01fb5b8>] ? enc128+0x243/0x80b [aes_x86_64] [<ffffffffa01fc72b>] ? aes_encrypt+0xd/0xf [aes_x86_64] [<ffffffffa01e92b6>] ? crypto_cbc_encrypt+0x12c/0x18e [cbc] [<ffffffff81078c9b>] ? __alloc_pages_nodemask+0x12d/0x58a [<ffffffffa01fc71e>] ? aes_encrypt+0x0/0xf [aes_x86_64] [<ffffffff81113ea0>] ? async_encrypt+0x38/0x3a [<ffffffff81075a94>] ? mempool_alloc+0x5b/0x113 [<ffffffffa01c5b53>] ? crypt_convert+0x1f9/0x278 [dm_crypt] [<ffffffffa01c5ff5>] ? kcryptd_crypt+0x423/0x449 [dm_crypt] [<ffffffffa01c5bd2>] ? kcryptd_crypt+0x0/0x449 [dm_crypt] [<ffffffff81048bc5>] ? worker_thread+0x132/0x1ca [<ffffffff8104c647>] ? autoremove_wake_function+0x0/0x38 [<ffffffff81048a93>] ? worker_thread+0x0/0x1ca [<ffffffff8104c325>] ? kthread+0x8f/0x97 [<ffffffff8100ca7a>] ? child_rip+0xa/0x20 [<ffffffff8104c296>] ? kthread+0x0/0x97 [<ffffffff8100ca70>] ? child_rip+0x0/0x20 Mem-Info: DMA per-cpu: CPU 0: hi: 0, btch: 1 usd: 0 CPU 1: hi: 0, btch: 1 usd: 0 DMA32 per-cpu: CPU 0: hi: 186, btch: 31 usd: 172 CPU 1: hi: 186, btch: 31 usd: 173 Active_anon:277951 active_file:18714 inactive_anon:93068 inactive_file:18252 unevictable:407 dirty:0 writeback:7726 unstable:0 free:25861 slab:10409 mapped:34634 pagetables:4385 bounce:0 DMA free:7924kB min:40kB low:48kB high:60kB active_anon:2220kB inactive_anon:2464kB active_file:1084kB inactive_file:1608kB unevictable:0kB present:15336kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 1976 1976 1976 DMA32 free:95520kB min:5664kB low:7080kB high:8496kB active_anon:1109584kB inactive_anon:369808kB active_file:73772kB inactive_file:71400kB unevictable:1628kB present:2023748kB pages_scanned:66 all_unreclaimable? no lowmem_reserve[]: 0 0 0 0 DMA: 63*4kB 59*8kB 26*16kB 34*32kB 23*64kB 1*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 1*4096kB = 7924kB DMA32: 19178*4kB 2285*8kB 3*16kB 1*32kB 1*64kB 1*128kB 1*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 95520kB 81717 total pagecache pages 44349 pages in swap cache Swap cache stats: add 160008, delete 115659, find 2431510/2434120 Free swap = 1549560kB Total swap = 2097144kB 518064 pages RAM 10323 pages reserved 117031 pages shared 398265 pages non-shared iwlagn 0000:10:00.0: Can not allocate SKB buffers ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: iwlagn: order 2 page allocation failures 2009-09-16 14:36 ` Frans Pop @ 2009-09-16 15:02 ` Mel Gorman 2009-09-16 15:37 ` Frans Pop 2009-09-16 16:26 ` reinette chatre 0 siblings, 2 replies; 66+ messages in thread From: Mel Gorman @ 2009-09-16 15:02 UTC (permalink / raw) To: Frans Pop Cc: Larry Finger, John W. Linville, Pekka Enberg, linux-kernel, linux-wireless, ipw3945-devel, Andrew Morton, cl, Assaf Krauss, Johannes Berg, Mohamed Abbas On Wed, Sep 16, 2009 at 04:36:16PM +0200, Frans Pop wrote: > On Wednesday 09 September 2009, Frans Pop wrote: > > On Wednesday 09 September 2009, you wrote: > > > The problem with this theory is that the patches have been in since > > > Nov 2008 but reports are only showing up now. Frans, how sure are you > > > that this is a recent problem? Is it readily reproducible? > > > > The only thing I can say here is that I've never seen the issue before > > (and thanks to logcheck I certainly would have). > > The laptop is in constant use, but I rarely stress the memory like that. > > Swap is almost always at 0. > > JFYI, it happened again yesterday. > The first time it was swapper, here it's kcryptd. The top part of the > trace is the same. > > kcryptd: page allocation failure. order:2, mode:0x4020 > Pid: 1347, comm: kcryptd Not tainted 2.6.31-rc9 #16 Is this with Reinette Chatre's patch applied or vanilla? If vanilla, Reinette, is your patch already upstream or in a subsystem tree somewhere? > Call Trace: > <IRQ> [<ffffffff810790b0>] __alloc_pages_nodemask+0x542/0x58a > [<ffffffff81256a62>] ? _spin_unlock+0x9/0xb > [<ffffffff811da481>] ? __alloc_skb+0x3c/0x15b > [<ffffffffa0355644>] ? iwl_rx_allocate+0xac/0x208 [iwlcore] > [<ffffffff81079153>] __get_free_pages+0x12/0x41 > [<ffffffff810982c5>] __kmalloc_track_caller+0x3b/0xec > [<ffffffff811da4ab>] __alloc_skb+0x66/0x15b > [<ffffffffa0355644>] iwl_rx_allocate+0xac/0x208 [iwlcore] > [<ffffffffa03557b6>] iwl_rx_replenish_now+0x16/0x23 [iwlcore] > [<ffffffffa037c8e3>] iwl_rx_handle+0x356/0x39a [iwlagn] > [<ffffffffa00212a2>] ? scsi_io_completion+0x3a8/0x3d1 [scsi_mod] > [<ffffffffa037ce27>] iwl_irq_tasklet_legacy+0x500/0x74f [iwlagn] > [<ffffffffa001a81b>] ? scsi_finish_command+0xec/0xf5 [scsi_mod] > [<ffffffff8103dff0>] tasklet_action+0x71/0xbc > [<ffffffff8103e877>] __do_softirq+0x9b/0x12c > [<ffffffff8100cb7c>] call_softirq+0x1c/0x28 > [<ffffffff8100e694>] do_softirq+0x34/0x72 > [<ffffffff8103e601>] irq_exit+0x3f/0x79 > [<ffffffff8100dd95>] do_IRQ+0xa3/0xba > [<ffffffff8100c413>] ret_from_intr+0x0/0xa > <EOI> [<ffffffffa01fb5b8>] ? enc128+0x243/0x80b [aes_x86_64] > [<ffffffffa01fc72b>] ? aes_encrypt+0xd/0xf [aes_x86_64] > [<ffffffffa01e92b6>] ? crypto_cbc_encrypt+0x12c/0x18e [cbc] > [<ffffffff81078c9b>] ? __alloc_pages_nodemask+0x12d/0x58a > [<ffffffffa01fc71e>] ? aes_encrypt+0x0/0xf [aes_x86_64] > [<ffffffff81113ea0>] ? async_encrypt+0x38/0x3a > [<ffffffff81075a94>] ? mempool_alloc+0x5b/0x113 > [<ffffffffa01c5b53>] ? crypt_convert+0x1f9/0x278 [dm_crypt] > [<ffffffffa01c5ff5>] ? kcryptd_crypt+0x423/0x449 [dm_crypt] > [<ffffffffa01c5bd2>] ? kcryptd_crypt+0x0/0x449 [dm_crypt] > [<ffffffff81048bc5>] ? worker_thread+0x132/0x1ca > [<ffffffff8104c647>] ? autoremove_wake_function+0x0/0x38 > [<ffffffff81048a93>] ? worker_thread+0x0/0x1ca > [<ffffffff8104c325>] ? kthread+0x8f/0x97 > [<ffffffff8100ca7a>] ? child_rip+0xa/0x20 > [<ffffffff8104c296>] ? kthread+0x0/0x97 > [<ffffffff8100ca70>] ? child_rip+0x0/0x20 > Mem-Info: > DMA per-cpu: > CPU 0: hi: 0, btch: 1 usd: 0 > CPU 1: hi: 0, btch: 1 usd: 0 > DMA32 per-cpu: > CPU 0: hi: 186, btch: 31 usd: 172 > CPU 1: hi: 186, btch: 31 usd: 163 > Active_anon:278449 active_file:18846 inactive_anon:93192 > inactive_file:18343 unevictable:407 dirty:0 writeback:7726 unstable:0 > free:25175 slab:10409 mapped:34634 pagetables:4385 bounce:0 > DMA free:7924kB min:40kB low:48kB high:60kB active_anon:2220kB inactive_anon:2464kB > active_file:1084kB inactive_file:1608kB unevictable:0kB present:15336kB pages_scanned:0 > all_unreclaimable? no > lowmem_reserve[]: 0 1976 1976 1976 > DMA32 free:92776kB min:5664kB low:7080kB high:8496kB active_anon:1111448kB inactive_anon:370432kB > active_file:74300kB inactive_file:71764kB unevictable:1628kB present:2023748kB pages_scanned:32 > all_unreclaimable? no > lowmem_reserve[]: 0 0 0 0 > DMA: 63*4kB 59*8kB 26*16kB 34*32kB 23*64kB 1*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 1*4096kB = 7924kB > DMA32: 18882*4kB 2076*8kB 10*16kB 1*32kB 1*64kB 1*128kB 1*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 92776kB > 82554 total pagecache pages > 44961 pages in swap cache > Swap cache stats: add 160004, delete 115046, find 2431510/2434120 > Free swap = 1549576kB > Total swap = 2097144kB > 518064 pages RAM > 10323 pages reserved > 117029 pages shared > 398165 pages non-shared > iwlagn 0000:10:00.0: Can not allocate SKB buffers > kcryptd: page allocation failure. order:2, mode:0x4020 > Pid: 1347, comm: kcryptd Not tainted 2.6.31-rc9 #16 > Call Trace: > <IRQ> [<ffffffff810790b0>] __alloc_pages_nodemask+0x542/0x58a > [<ffffffff81256a62>] ? _spin_unlock+0x9/0xb > [<ffffffff811da481>] ? __alloc_skb+0x3c/0x15b > [<ffffffffa0355644>] ? iwl_rx_allocate+0xac/0x208 [iwlcore] > [<ffffffff81079153>] __get_free_pages+0x12/0x41 > [<ffffffff810982c5>] __kmalloc_track_caller+0x3b/0xec > [<ffffffff811da4ab>] __alloc_skb+0x66/0x15b > [<ffffffffa0355644>] iwl_rx_allocate+0xac/0x208 [iwlcore] > [<ffffffffa03557b6>] iwl_rx_replenish_now+0x16/0x23 [iwlcore] > [<ffffffffa037c90e>] iwl_rx_handle+0x381/0x39a [iwlagn] > [<ffffffffa00212a2>] ? scsi_io_completion+0x3a8/0x3d1 [scsi_mod] > [<ffffffffa037ce27>] iwl_irq_tasklet_legacy+0x500/0x74f [iwlagn] > [<ffffffffa001a81b>] ? scsi_finish_command+0xec/0xf5 [scsi_mod] > [<ffffffff8103dff0>] tasklet_action+0x71/0xbc > [<ffffffff8103e877>] __do_softirq+0x9b/0x12c > [<ffffffff8100cb7c>] call_softirq+0x1c/0x28 > [<ffffffff8100e694>] do_softirq+0x34/0x72 > [<ffffffff8103e601>] irq_exit+0x3f/0x79 > [<ffffffff8100dd95>] do_IRQ+0xa3/0xba > [<ffffffff8100c413>] ret_from_intr+0x0/0xa > <EOI> [<ffffffffa01fb5b8>] ? enc128+0x243/0x80b [aes_x86_64] > [<ffffffffa01fc72b>] ? aes_encrypt+0xd/0xf [aes_x86_64] > [<ffffffffa01e92b6>] ? crypto_cbc_encrypt+0x12c/0x18e [cbc] > [<ffffffff81078c9b>] ? __alloc_pages_nodemask+0x12d/0x58a > [<ffffffffa01fc71e>] ? aes_encrypt+0x0/0xf [aes_x86_64] > [<ffffffff81113ea0>] ? async_encrypt+0x38/0x3a > [<ffffffff81075a94>] ? mempool_alloc+0x5b/0x113 > [<ffffffffa01c5b53>] ? crypt_convert+0x1f9/0x278 [dm_crypt] > [<ffffffffa01c5ff5>] ? kcryptd_crypt+0x423/0x449 [dm_crypt] > [<ffffffffa01c5bd2>] ? kcryptd_crypt+0x0/0x449 [dm_crypt] > [<ffffffff81048bc5>] ? worker_thread+0x132/0x1ca > [<ffffffff8104c647>] ? autoremove_wake_function+0x0/0x38 > [<ffffffff81048a93>] ? worker_thread+0x0/0x1ca > [<ffffffff8104c325>] ? kthread+0x8f/0x97 > [<ffffffff8100ca7a>] ? child_rip+0xa/0x20 > [<ffffffff8104c296>] ? kthread+0x0/0x97 > [<ffffffff8100ca70>] ? child_rip+0x0/0x20 > Mem-Info: > DMA per-cpu: > CPU 0: hi: 0, btch: 1 usd: 0 > CPU 1: hi: 0, btch: 1 usd: 0 > DMA32 per-cpu: > CPU 0: hi: 186, btch: 31 usd: 172 > CPU 1: hi: 186, btch: 31 usd: 173 > Active_anon:277951 active_file:18714 inactive_anon:93068 > inactive_file:18252 unevictable:407 dirty:0 writeback:7726 unstable:0 > free:25861 slab:10409 mapped:34634 pagetables:4385 bounce:0 > DMA free:7924kB min:40kB low:48kB high:60kB active_anon:2220kB inactive_anon:2464kB > active_file:1084kB inactive_file:1608kB unevictable:0kB present:15336kB pages_scanned:0 > all_unreclaimable? no > lowmem_reserve[]: 0 1976 1976 1976 > DMA32 free:95520kB min:5664kB low:7080kB high:8496kB active_anon:1109584kB inactive_anon:369808kB > active_file:73772kB inactive_file:71400kB unevictable:1628kB present:2023748kB pages_scanned:66 > all_unreclaimable? no > lowmem_reserve[]: 0 0 0 0 > DMA: 63*4kB 59*8kB 26*16kB 34*32kB 23*64kB 1*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 1*4096kB = 7924kB > DMA32: 19178*4kB 2285*8kB 3*16kB 1*32kB 1*64kB 1*128kB 1*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 95520kB > 81717 total pagecache pages > 44349 pages in swap cache > Swap cache stats: add 160008, delete 115659, find 2431510/2434120 > Free swap = 1549560kB > Total swap = 2097144kB > 518064 pages RAM > 10323 pages reserved > 117031 pages shared > 398265 pages non-shared > iwlagn 0000:10:00.0: Can not allocate SKB buffers > -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: iwlagn: order 2 page allocation failures 2009-09-16 15:02 ` Mel Gorman @ 2009-09-16 15:37 ` Frans Pop 2009-09-16 16:26 ` reinette chatre 1 sibling, 0 replies; 66+ messages in thread From: Frans Pop @ 2009-09-16 15:37 UTC (permalink / raw) To: Mel Gorman Cc: Larry Finger, John W. Linville, Pekka Enberg, linux-kernel, linux-wireless, ipw3945-devel, Andrew Morton, cl, Assaf Krauss, Johannes Berg, Mohamed Abbas On Wednesday 16 September 2009, Mel Gorman wrote: > > kcryptd: page allocation failure. order:2, mode:0x4020 > > Pid: 1347, comm: kcryptd Not tainted 2.6.31-rc9 #16 > > Is this with Reinette Chatre's patch applied or vanilla? Vanilla. ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: iwlagn: order 2 page allocation failures 2009-09-16 15:02 ` Mel Gorman @ 2009-09-16 16:26 ` reinette chatre 2009-09-16 16:26 ` reinette chatre 1 sibling, 0 replies; 66+ messages in thread From: reinette chatre @ 2009-09-16 16:26 UTC (permalink / raw) To: Mel Gorman Cc: Frans Pop, Larry Finger, John W. Linville, Pekka Enberg, linux-kernel, linux-wireless, ipw3945-devel, Andrew Morton, cl, Krauss, Assaf, Johannes Berg, Abbas, Mohamed On Wed, 2009-09-16 at 08:02 -0700, Mel Gorman wrote: > If vanilla, Reinette, is your patch already upstream or in a subsystem > tree somewhere? Not yet. Reinette ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: iwlagn: order 2 page allocation failures @ 2009-09-16 16:26 ` reinette chatre 0 siblings, 0 replies; 66+ messages in thread From: reinette chatre @ 2009-09-16 16:26 UTC (permalink / raw) To: Mel Gorman Cc: Frans Pop, Larry Finger, John W. Linville, Pekka Enberg, linux-kernel, linux-wireless, ipw3945-devel, Andrew Morton, cl, Krauss, Assaf, Johannes Berg, Abbas, Mohamed On Wed, 2009-09-16 at 08:02 -0700, Mel Gorman wrote: > If vanilla, Reinette, is your patch already upstream or in a subsystem > tree somewhere? Not yet. Reinette ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: iwlagn: order 2 page allocation failures 2009-09-09 16:55 ` Mel Gorman @ 2009-09-09 20:05 ` reinette chatre 2009-09-09 20:05 ` reinette chatre 2009-09-10 8:18 ` Pekka Enberg 2 siblings, 0 replies; 66+ messages in thread From: reinette chatre @ 2009-09-09 20:05 UTC (permalink / raw) To: Mel Gorman Cc: Frans Pop, Larry Finger, John W. Linville, Pekka Enberg, linux-kernel, linux-wireless, ipw3945-devel, Andrew Morton, cl, Krauss, Assaf, Johannes Berg, Abbas, Mohamed Mel and Frans, Thank you very much for digging into this. On Wed, 2009-09-09 at 09:55 -0700, Mel Gorman wrote: > Conceivably a better candidate for this problem is commit > 4752c93c30441f98f7ed723001b1a5e3e5619829 introduced in May 2009. If there > are less than RX_QUEUE_SIZE/2 left, it starts replenishing buffers. Mohamed, > is it absolutly necessary it use GFP_ATOMIC there? If an allocation fails, > does it always mean frames are dropped or could it just replenish what it > can and try again later printing a warning only if allocation failures are > resulting in packet loss? I agree that this patch may be the reason we are seeing this issue. We would like to keep using GFP_ATOMIC here, but it is not necessary for an allocation failure to be so noisy since the function doing the allocation (iwl_rx_allocate) is always followed by a call to iwl_rx_queue_restock which will schedule a refill if the buffers are running low. We can thus use ___GFP_NOWARN for the allocations in iwl_rx_allocate and leave it to the restocking to find the needed memory when it tried its allocations using GFP_KERNEL. I do think it is useful to let user know about these allocation failures, even if it does not result in packet loss. Wrapping it in net_ratelimit() will help though. How about the patch below? diff --git a/drivers/net/wireless/iwlwifi/iwl-rx.c b/drivers/net/wireless/iwlwifi/iwl-rx.c index b90adcb..f0ee72e 100644 --- a/drivers/net/wireless/iwlwifi/iwl-rx.c +++ b/drivers/net/wireless/iwlwifi/iwl-rx.c @@ -252,10 +252,11 @@ void iwl_rx_allocate(struct iwl_priv *priv, gfp_t priority) /* Alloc a new receive buffer */ skb = alloc_skb(priv->hw_params.rx_buf_size + 256, - priority); + priority | __GFP_NOWARN); if (!skb) { - IWL_CRIT(priv, "Can not allocate SKB buffers\n"); + if (net_ratelimit()) + IWL_CRIT(priv, "Can not allocate SKB buffer.\n"); /* We don't reschedule replenish work here -- we will * call the restock method and if it still needs * more buffers it will schedule replenish */ diff --git a/drivers/net/wireless/iwlwifi/iwl3945-base.c b/drivers/net/wireless/iwlwifi/iwl3945-base.c index 0909668..5d9fb78 100644 --- a/drivers/net/wireless/iwlwifi/iwl3945-base.c +++ b/drivers/net/wireless/iwlwifi/iwl3945-base.c @@ -1147,10 +1147,10 @@ static void iwl3945_rx_allocate(struct iwl_priv *priv, gfp_t priority) spin_unlock_irqrestore(&rxq->lock, flags); /* Alloc a new receive buffer */ - skb = alloc_skb(priv->hw_params.rx_buf_size, priority); + skb = alloc_skb(priv->hw_params.rx_buf_size, priority | __GFP_NOWARN); if (!skb) { if (net_ratelimit()) - IWL_CRIT(priv, ": Can not allocate SKB buffers\n"); + IWL_CRIT(priv, "Can not allocate SKB buffer.\n"); /* We don't reschedule replenish work here -- we will * call the restock method and if it still needs * more buffers it will schedule replenish */ ^ permalink raw reply related [flat|nested] 66+ messages in thread
* Re: iwlagn: order 2 page allocation failures @ 2009-09-09 20:05 ` reinette chatre 0 siblings, 0 replies; 66+ messages in thread From: reinette chatre @ 2009-09-09 20:05 UTC (permalink / raw) To: Mel Gorman Cc: Frans Pop, Larry Finger, John W. Linville, Pekka Enberg, linux-kernel, linux-wireless, ipw3945-devel, Andrew Morton, cl, Krauss, Assaf, Johannes Berg, Abbas, Mohamed Mel and Frans, Thank you very much for digging into this. On Wed, 2009-09-09 at 09:55 -0700, Mel Gorman wrote: > Conceivably a better candidate for this problem is commit > 4752c93c30441f98f7ed723001b1a5e3e5619829 introduced in May 2009. If there > are less than RX_QUEUE_SIZE/2 left, it starts replenishing buffers. Mohamed, > is it absolutly necessary it use GFP_ATOMIC there? If an allocation fails, > does it always mean frames are dropped or could it just replenish what it > can and try again later printing a warning only if allocation failures are > resulting in packet loss? I agree that this patch may be the reason we are seeing this issue. We would like to keep using GFP_ATOMIC here, but it is not necessary for an allocation failure to be so noisy since the function doing the allocation (iwl_rx_allocate) is always followed by a call to iwl_rx_queue_restock which will schedule a refill if the buffers are running low. We can thus use ___GFP_NOWARN for the allocations in iwl_rx_allocate and leave it to the restocking to find the needed memory when it tried its allocations using GFP_KERNEL. I do think it is useful to let user know about these allocation failures, even if it does not result in packet loss. Wrapping it in net_ratelimit() will help though. How about the patch below? diff --git a/drivers/net/wireless/iwlwifi/iwl-rx.c b/drivers/net/wireless/iwlwifi/iwl-rx.c index b90adcb..f0ee72e 100644 --- a/drivers/net/wireless/iwlwifi/iwl-rx.c +++ b/drivers/net/wireless/iwlwifi/iwl-rx.c @@ -252,10 +252,11 @@ void iwl_rx_allocate(struct iwl_priv *priv, gfp_t priority) /* Alloc a new receive buffer */ skb = alloc_skb(priv->hw_params.rx_buf_size + 256, - priority); + priority | __GFP_NOWARN); if (!skb) { - IWL_CRIT(priv, "Can not allocate SKB buffers\n"); + if (net_ratelimit()) + IWL_CRIT(priv, "Can not allocate SKB buffer.\n"); /* We don't reschedule replenish work here -- we will * call the restock method and if it still needs * more buffers it will schedule replenish */ diff --git a/drivers/net/wireless/iwlwifi/iwl3945-base.c b/drivers/net/wireless/iwlwifi/iwl3945-base.c index 0909668..5d9fb78 100644 --- a/drivers/net/wireless/iwlwifi/iwl3945-base.c +++ b/drivers/net/wireless/iwlwifi/iwl3945-base.c @@ -1147,10 +1147,10 @@ static void iwl3945_rx_allocate(struct iwl_priv *priv, gfp_t priority) spin_unlock_irqrestore(&rxq->lock, flags); /* Alloc a new receive buffer */ - skb = alloc_skb(priv->hw_params.rx_buf_size, priority); + skb = alloc_skb(priv->hw_params.rx_buf_size, priority | __GFP_NOWARN); if (!skb) { if (net_ratelimit()) - IWL_CRIT(priv, ": Can not allocate SKB buffers\n"); + IWL_CRIT(priv, "Can not allocate SKB buffer.\n"); /* We don't reschedule replenish work here -- we will * call the restock method and if it still needs * more buffers it will schedule replenish */ ^ permalink raw reply related [flat|nested] 66+ messages in thread
* Re: iwlagn: order 2 page allocation failures 2009-09-09 20:05 ` reinette chatre @ 2009-09-10 1:48 ` Frans Pop -1 siblings, 0 replies; 66+ messages in thread From: Frans Pop @ 2009-09-10 1:48 UTC (permalink / raw) To: reinette chatre Cc: Mel Gorman, Larry Finger, John W. Linville, Pekka Enberg, linux-kernel, linux-wireless, ipw3945-devel, Andrew Morton, cl, Krauss, Assaf, Johannes Berg, Abbas, Mohamed Hi Reinette, On Wednesday 09 September 2009, reinette chatre wrote: > I agree that this patch may be the reason we are seeing this issue. We > would like to keep using GFP_ATOMIC here, but it is not necessary for > an allocation failure to be so noisy since the function doing the > allocation (iwl_rx_allocate) is always followed by a call to > iwl_rx_queue_restock which will schedule a refill if the buffers are > running low. We can thus use ___GFP_NOWARN for the allocations in > iwl_rx_allocate and leave it to the restocking to find the needed > memory when it tried its allocations using GFP_KERNEL. > > I do think it is useful to let user know about these allocation > failures, even if it does not result in packet loss. Wrapping it in > net_ratelimit() will help though. > > How about the patch below? A couple of comments/suggestions. If the driver recovers cleanly from the error, shouldn't the priority of the message be lowered from CRIT to INFO. Or maybe even DEBUG; AFAIK most distros will have DEBUG_KERNEL enabled by default. This means it will still show up in logs, but not the console. Shouldn't the message include some indication that the driver will recover by itself and that no user action is needed? This will help avoid users (unnecessarily) reporting this as a bug when it does occur. I expect that users would still report it if they get flooded with the message (or ratelimit warnings for it), which I think is what you'd want. And maybe s/Can not/Cannot/ or s/Can not/Failed to/. Cheers, FJP ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: iwlagn: order 2 page allocation failures @ 2009-09-10 1:48 ` Frans Pop 0 siblings, 0 replies; 66+ messages in thread From: Frans Pop @ 2009-09-10 1:48 UTC (permalink / raw) To: reinette chatre Cc: Mel Gorman, Larry Finger, John W. Linville, Pekka Enberg, linux-kernel, linux-wireless, ipw3945-devel, Andrew Morton, cl, Krauss, Assaf, Johannes Berg, Abbas, Mohamed Hi Reinette, On Wednesday 09 September 2009, reinette chatre wrote: > I agree that this patch may be the reason we are seeing this issue. We > would like to keep using GFP_ATOMIC here, but it is not necessary for > an allocation failure to be so noisy since the function doing the > allocation (iwl_rx_allocate) is always followed by a call to > iwl_rx_queue_restock which will schedule a refill if the buffers are > running low. We can thus use ___GFP_NOWARN for the allocations in > iwl_rx_allocate and leave it to the restocking to find the needed > memory when it tried its allocations using GFP_KERNEL. > > I do think it is useful to let user know about these allocation > failures, even if it does not result in packet loss. Wrapping it in > net_ratelimit() will help though. > > How about the patch below? A couple of comments/suggestions. If the driver recovers cleanly from the error, shouldn't the priority of the message be lowered from CRIT to INFO. Or maybe even DEBUG; AFAIK most distros will have DEBUG_KERNEL enabled by default. This means it will still show up in logs, but not the console. Shouldn't the message include some indication that the driver will recover by itself and that no user action is needed? This will help avoid users (unnecessarily) reporting this as a bug when it does occur. I expect that users would still report it if they get flooded with the message (or ratelimit warnings for it), which I think is what you'd want. And maybe s/Can not/Cannot/ or s/Can not/Failed to/. Cheers, FJP ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: iwlagn: order 2 page allocation failures 2009-09-09 20:05 ` reinette chatre @ 2009-09-10 9:02 ` Mel Gorman -1 siblings, 0 replies; 66+ messages in thread From: Mel Gorman @ 2009-09-10 9:02 UTC (permalink / raw) To: reinette chatre Cc: Frans Pop, Larry Finger, John W. Linville, Pekka Enberg, linux-kernel, linux-wireless, ipw3945-devel, Andrew Morton, cl, Krauss, Assaf, Johannes Berg, Abbas, Mohamed On Wed, Sep 09, 2009 at 01:05:38PM -0700, reinette chatre wrote: > Mel and Frans, > > Thank you very much for digging into this. > > On Wed, 2009-09-09 at 09:55 -0700, Mel Gorman wrote: > > Conceivably a better candidate for this problem is commit > > 4752c93c30441f98f7ed723001b1a5e3e5619829 introduced in May 2009. If there > > are less than RX_QUEUE_SIZE/2 left, it starts replenishing buffers. Mohamed, > > is it absolutly necessary it use GFP_ATOMIC there? If an allocation fails, > > does it always mean frames are dropped or could it just replenish what it > > can and try again later printing a warning only if allocation failures are > > resulting in packet loss? > > I agree that this patch may be the reason we are seeing this issue. We > would like to keep using GFP_ATOMIC here, but it is not necessary for an > allocation failure to be so noisy since the function doing the > allocation (iwl_rx_allocate) is always followed by a call to > iwl_rx_queue_restock which will schedule a refill if the buffers are > running low. Right, so it's a "refill now if you can and defer further refilling until later". > We can thus use ___GFP_NOWARN for the allocations in > iwl_rx_allocate and leave it to the restocking to find the needed memory > when it tried its allocations using GFP_KERNEL. > Would it be possible to use __GFP_NOWARN *unless* this allocation is necessary to receive the packet? > I do think it is useful to let user know about these allocation > failures, even if it does not result in packet loss. Wrapping it in > net_ratelimit() will help though. > If it does not distinguish between failures causing packet loss and just a temporary issue, I'd be worried the messages would generate bug reports and we genuinely won't know if it's a real problem or not. As a total aside, there is still the problem that the driver is depending on order-2 allocations. On systems without swap, the allocation problem could be more severe as there are fewer pages the system can use to regain contiguity. > How about the patch below? > > diff --git a/drivers/net/wireless/iwlwifi/iwl-rx.c b/drivers/net/wireless/iwlwifi/iwl-rx.c > index b90adcb..f0ee72e 100644 > --- a/drivers/net/wireless/iwlwifi/iwl-rx.c > +++ b/drivers/net/wireless/iwlwifi/iwl-rx.c > @@ -252,10 +252,11 @@ void iwl_rx_allocate(struct iwl_priv *priv, gfp_t priority) > > /* Alloc a new receive buffer */ > skb = alloc_skb(priv->hw_params.rx_buf_size + 256, > - priority); > + priority | __GFP_NOWARN); > So, would it be possible here to only remove __GFP_NOWARN if this is GFP_ATOMIC (implying we have to refill now) and the rxq->free_count is really small e.g. <= 2? > if (!skb) { > - IWL_CRIT(priv, "Can not allocate SKB buffers\n"); > + if (net_ratelimit()) > + IWL_CRIT(priv, "Can not allocate SKB buffer.\n"); Similarly, could the message either be supressed when there is enough buffers in the RX queue or differenciate between enough buffers and things getting tight possibly causing packet loss? The IWL_CRIT() part even is a hint - there is no guarantee that the allocation failure is really a critical problem. > /* We don't reschedule replenish work here -- we will > * call the restock method and if it still needs > * more buffers it will schedule replenish */ > diff --git a/drivers/net/wireless/iwlwifi/iwl3945-base.c b/drivers/net/wireless/iwlwifi/iwl3945-base.c > index 0909668..5d9fb78 100644 > --- a/drivers/net/wireless/iwlwifi/iwl3945-base.c > +++ b/drivers/net/wireless/iwlwifi/iwl3945-base.c > @@ -1147,10 +1147,10 @@ static void iwl3945_rx_allocate(struct iwl_priv *priv, gfp_t priority) > spin_unlock_irqrestore(&rxq->lock, flags); > > /* Alloc a new receive buffer */ > - skb = alloc_skb(priv->hw_params.rx_buf_size, priority); > + skb = alloc_skb(priv->hw_params.rx_buf_size, priority | __GFP_NOWARN); > if (!skb) { > if (net_ratelimit()) > - IWL_CRIT(priv, ": Can not allocate SKB buffers\n"); > + IWL_CRIT(priv, "Can not allocate SKB buffer.\n"); > /* We don't reschedule replenish work here -- we will > * call the restock method and if it still needs > * more buffers it will schedule replenish */ > > -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: iwlagn: order 2 page allocation failures @ 2009-09-10 9:02 ` Mel Gorman 0 siblings, 0 replies; 66+ messages in thread From: Mel Gorman @ 2009-09-10 9:02 UTC (permalink / raw) To: reinette chatre Cc: Frans Pop, Larry Finger, John W. Linville, Pekka Enberg, linux-kernel, linux-wireless, ipw3945-devel, Andrew Morton, cl, Krauss, Assaf, Johannes Berg, Abbas, Mohamed On Wed, Sep 09, 2009 at 01:05:38PM -0700, reinette chatre wrote: > Mel and Frans, > > Thank you very much for digging into this. > > On Wed, 2009-09-09 at 09:55 -0700, Mel Gorman wrote: > > Conceivably a better candidate for this problem is commit > > 4752c93c30441f98f7ed723001b1a5e3e5619829 introduced in May 2009. If there > > are less than RX_QUEUE_SIZE/2 left, it starts replenishing buffers. Mohamed, > > is it absolutly necessary it use GFP_ATOMIC there? If an allocation fails, > > does it always mean frames are dropped or could it just replenish what it > > can and try again later printing a warning only if allocation failures are > > resulting in packet loss? > > I agree that this patch may be the reason we are seeing this issue. We > would like to keep using GFP_ATOMIC here, but it is not necessary for an > allocation failure to be so noisy since the function doing the > allocation (iwl_rx_allocate) is always followed by a call to > iwl_rx_queue_restock which will schedule a refill if the buffers are > running low. Right, so it's a "refill now if you can and defer further refilling until later". > We can thus use ___GFP_NOWARN for the allocations in > iwl_rx_allocate and leave it to the restocking to find the needed memory > when it tried its allocations using GFP_KERNEL. > Would it be possible to use __GFP_NOWARN *unless* this allocation is necessary to receive the packet? > I do think it is useful to let user know about these allocation > failures, even if it does not result in packet loss. Wrapping it in > net_ratelimit() will help though. > If it does not distinguish between failures causing packet loss and just a temporary issue, I'd be worried the messages would generate bug reports and we genuinely won't know if it's a real problem or not. As a total aside, there is still the problem that the driver is depending on order-2 allocations. On systems without swap, the allocation problem could be more severe as there are fewer pages the system can use to regain contiguity. > How about the patch below? > > diff --git a/drivers/net/wireless/iwlwifi/iwl-rx.c b/drivers/net/wireless/iwlwifi/iwl-rx.c > index b90adcb..f0ee72e 100644 > --- a/drivers/net/wireless/iwlwifi/iwl-rx.c > +++ b/drivers/net/wireless/iwlwifi/iwl-rx.c > @@ -252,10 +252,11 @@ void iwl_rx_allocate(struct iwl_priv *priv, gfp_t priority) > > /* Alloc a new receive buffer */ > skb = alloc_skb(priv->hw_params.rx_buf_size + 256, > - priority); > + priority | __GFP_NOWARN); > So, would it be possible here to only remove __GFP_NOWARN if this is GFP_ATOMIC (implying we have to refill now) and the rxq->free_count is really small e.g. <= 2? > if (!skb) { > - IWL_CRIT(priv, "Can not allocate SKB buffers\n"); > + if (net_ratelimit()) > + IWL_CRIT(priv, "Can not allocate SKB buffer.\n"); Similarly, could the message either be supressed when there is enough buffers in the RX queue or differenciate between enough buffers and things getting tight possibly causing packet loss? The IWL_CRIT() part even is a hint - there is no guarantee that the allocation failure is really a critical problem. > /* We don't reschedule replenish work here -- we will > * call the restock method and if it still needs > * more buffers it will schedule replenish */ > diff --git a/drivers/net/wireless/iwlwifi/iwl3945-base.c b/drivers/net/wireless/iwlwifi/iwl3945-base.c > index 0909668..5d9fb78 100644 > --- a/drivers/net/wireless/iwlwifi/iwl3945-base.c > +++ b/drivers/net/wireless/iwlwifi/iwl3945-base.c > @@ -1147,10 +1147,10 @@ static void iwl3945_rx_allocate(struct iwl_priv *priv, gfp_t priority) > spin_unlock_irqrestore(&rxq->lock, flags); > > /* Alloc a new receive buffer */ > - skb = alloc_skb(priv->hw_params.rx_buf_size, priority); > + skb = alloc_skb(priv->hw_params.rx_buf_size, priority | __GFP_NOWARN); > if (!skb) { > if (net_ratelimit()) > - IWL_CRIT(priv, ": Can not allocate SKB buffers\n"); > + IWL_CRIT(priv, "Can not allocate SKB buffer.\n"); > /* We don't reschedule replenish work here -- we will > * call the restock method and if it still needs > * more buffers it will schedule replenish */ > > -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: iwlagn: order 2 page allocation failures 2009-09-10 9:02 ` Mel Gorman @ 2009-09-10 18:15 ` reinette chatre -1 siblings, 0 replies; 66+ messages in thread From: reinette chatre @ 2009-09-10 18:15 UTC (permalink / raw) To: Mel Gorman Cc: Frans Pop, Larry Finger, John W. Linville, Pekka Enberg, linux-kernel, linux-wireless, ipw3945-devel, Andrew Morton, cl, Krauss, Assaf, Johannes Berg, Abbas, Mohamed On Thu, 2009-09-10 at 02:02 -0700, Mel Gorman wrote: > > We can thus use ___GFP_NOWARN for the allocations in > > iwl_rx_allocate and leave it to the restocking to find the needed memory > > when it tried its allocations using GFP_KERNEL. > > > > Would it be possible to use __GFP_NOWARN *unless* this allocation is > necessary to receive the packet? I think so. > > I do think it is useful to let user know about these allocation > > failures, even if it does not result in packet loss. Wrapping it in > > net_ratelimit() will help though. > > > > If it does not distinguish between failures causing packet loss and just a > temporary issue, I'd be worried the messages would generate bug reports and > we genuinely won't know if it's a real problem or not. Good point. > > As a total aside, there is still the problem that the driver is depending on > order-2 allocations. On systems without swap, the allocation problem could be > more severe as there are fewer pages the system can use to regain contiguity. It seems that somebody did think about this in the initialization of max_pkt_size (which is priv->hw_params.rx_buf_size - 256). If we use max_pkt_size in the code that allocates the skb then the 256 added for alignment will not cause it to go to an order-2 allocation. I do not know why max_pkt_size is not used at the moment and will have to do some digging to find out. > > > How about the patch below? > > > > diff --git a/drivers/net/wireless/iwlwifi/iwl-rx.c b/drivers/net/wireless/iwlwifi/iwl-rx.c > > index b90adcb..f0ee72e 100644 > > --- a/drivers/net/wireless/iwlwifi/iwl-rx.c > > +++ b/drivers/net/wireless/iwlwifi/iwl-rx.c > > @@ -252,10 +252,11 @@ void iwl_rx_allocate(struct iwl_priv *priv, gfp_t priority) > > > > /* Alloc a new receive buffer */ > > skb = alloc_skb(priv->hw_params.rx_buf_size + 256, > > - priority); > > + priority | __GFP_NOWARN); > > > > So, would it be possible here to only remove __GFP_NOWARN if this is GFP_ATOMIC > (implying we have to refill now) and the rxq->free_count is really small > e.g. <= 2? I like your suggestion. Considering the issue I would like to remove __GFP_NOWARN even if it is GFP_KERNEL ... I think it is actually even more of a problem if we are in GFP_KERNEL and not able to allocate memory when running low on buffers. Also, with the queue size of 256 I think we can use RX_LOW_WATERMARK here, which is 8. > > > if (!skb) { > > - IWL_CRIT(priv, "Can not allocate SKB buffers\n"); > > + if (net_ratelimit()) > > + IWL_CRIT(priv, "Can not allocate SKB buffer.\n"); > > Similarly, could the message either be supressed when there is enough > buffers in the RX queue or differenciate between enough buffers and > things getting tight possibly causing packet loss? Frans also had comments in this regard. Will do. > > The IWL_CRIT() part even is a hint - there is no guarantee that the allocation > failure is really a critical problem. Right. How about this: >From bd2153dd9e4a0ad588adec38c580d67023d5587e Mon Sep 17 00:00:00 2001 From: Reinette Chatre <reinette.chatre@intel.com> Date: Wed, 9 Sep 2009 15:41:00 -0700 Subject: [PATCH] iwlwifi: reduce noise when skb allocation fails Replenishment of receive buffers is done in the tasklet handling received frames as well as in a workqueue. When we are in the tasklet we cannot sleep and thus attempt atomic skb allocations. It is generally not a big problem if this fails since iwl_rx_allocate is always followed by a call to iwl_rx_queue_restock which will queue the work to replenish the buffers at a time when sleeping is allowed. We thus add the __GFP_NOWARN to the skb allocation in iwl_rx_allocate to reduce the noise if such an allocation fails while we still have enough buffers. We do maintain the warning and the error message when we are low on buffers to communicate to the user that there is a potential problem with memory availability on system This addresses issue reported upstream in thread "iwlagn: order 2 page allocation failures" in http://thread.gmane.org/gmane.linux.kernel.wireless.general/39187 Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> --- drivers/net/wireless/iwlwifi/iwl-rx.c | 12 +++++++++--- drivers/net/wireless/iwlwifi/iwl3945-base.c | 8 +++++++- 2 files changed, 16 insertions(+), 4 deletions(-) diff --git a/drivers/net/wireless/iwlwifi/iwl-rx.c b/drivers/net/wireless/iwlwifi/iwl-rx.c index b90adcb..cb50cc7 100644 --- a/drivers/net/wireless/iwlwifi/iwl-rx.c +++ b/drivers/net/wireless/iwlwifi/iwl-rx.c @@ -250,12 +250,18 @@ void iwl_rx_allocate(struct iwl_priv *priv, gfp_t priority) } spin_unlock_irqrestore(&rxq->lock, flags); + if (rxq->free_count > RX_LOW_WATERMARK) + priority |= __GFP_NOWARN; /* Alloc a new receive buffer */ - skb = alloc_skb(priv->hw_params.rx_buf_size + 256, - priority); + skb = alloc_skb(priv->hw_params.rx_buf_size + 256, priority); if (!skb) { - IWL_CRIT(priv, "Can not allocate SKB buffers\n"); + if (net_ratelimit()) + IWL_DEBUG_INFO("Failed to allocate SKB buffer.\n"); + if ((rxq->free_count <= RX_LOW_WATERMARK) && + net_ratelimit()) + IWL_CRIT(priv, "Failed to allocate SKB buffer. Only %u free buffers remaining\n", + rxq->free_count); /* We don't reschedule replenish work here -- we will * call the restock method and if it still needs * more buffers it will schedule replenish */ diff --git a/drivers/net/wireless/iwlwifi/iwl3945-base.c b/drivers/net/wireless/iwlwifi/iwl3945-base.c index 0909668..0d96b17 100644 --- a/drivers/net/wireless/iwlwifi/iwl3945-base.c +++ b/drivers/net/wireless/iwlwifi/iwl3945-base.c @@ -1146,11 +1146,17 @@ static void iwl3945_rx_allocate(struct iwl_priv *priv, gfp_t priority) } spin_unlock_irqrestore(&rxq->lock, flags); + if (rxq->free_count > RX_LOW_WATERMARK) + priority |= __GFP_NOWARN; /* Alloc a new receive buffer */ skb = alloc_skb(priv->hw_params.rx_buf_size, priority); if (!skb) { if (net_ratelimit()) - IWL_CRIT(priv, ": Can not allocate SKB buffers\n"); + IWL_DEBUG_INFO("Failed to allocate SKB buffer.\n"); + if ((rxq->free_count <= RX_LOW_WATERMARK) && + net_ratelimit()) + IWL_CRIT(priv, "Failed to allocate SKB buffer. Only %u free buffers remaining\n", + rxq->free_count); /* We don't reschedule replenish work here -- we will * call the restock method and if it still needs * more buffers it will schedule replenish */ -- 1.5.6.3 ^ permalink raw reply related [flat|nested] 66+ messages in thread
* Re: iwlagn: order 2 page allocation failures @ 2009-09-10 18:15 ` reinette chatre 0 siblings, 0 replies; 66+ messages in thread From: reinette chatre @ 2009-09-10 18:15 UTC (permalink / raw) To: Mel Gorman Cc: Frans Pop, Larry Finger, John W. Linville, Pekka Enberg, linux-kernel, linux-wireless, ipw3945-devel, Andrew Morton, cl, Krauss, Assaf, Johannes Berg, Abbas, Mohamed On Thu, 2009-09-10 at 02:02 -0700, Mel Gorman wrote: > > We can thus use ___GFP_NOWARN for the allocations in > > iwl_rx_allocate and leave it to the restocking to find the needed memory > > when it tried its allocations using GFP_KERNEL. > > > > Would it be possible to use __GFP_NOWARN *unless* this allocation is > necessary to receive the packet? I think so. > > I do think it is useful to let user know about these allocation > > failures, even if it does not result in packet loss. Wrapping it in > > net_ratelimit() will help though. > > > > If it does not distinguish between failures causing packet loss and just a > temporary issue, I'd be worried the messages would generate bug reports and > we genuinely won't know if it's a real problem or not. Good point. > > As a total aside, there is still the problem that the driver is depending on > order-2 allocations. On systems without swap, the allocation problem could be > more severe as there are fewer pages the system can use to regain contiguity. It seems that somebody did think about this in the initialization of max_pkt_size (which is priv->hw_params.rx_buf_size - 256). If we use max_pkt_size in the code that allocates the skb then the 256 added for alignment will not cause it to go to an order-2 allocation. I do not know why max_pkt_size is not used at the moment and will have to do some digging to find out. > > > How about the patch below? > > > > diff --git a/drivers/net/wireless/iwlwifi/iwl-rx.c b/drivers/net/wireless/iwlwifi/iwl-rx.c > > index b90adcb..f0ee72e 100644 > > --- a/drivers/net/wireless/iwlwifi/iwl-rx.c > > +++ b/drivers/net/wireless/iwlwifi/iwl-rx.c > > @@ -252,10 +252,11 @@ void iwl_rx_allocate(struct iwl_priv *priv, gfp_t priority) > > > > /* Alloc a new receive buffer */ > > skb = alloc_skb(priv->hw_params.rx_buf_size + 256, > > - priority); > > + priority | __GFP_NOWARN); > > > > So, would it be possible here to only remove __GFP_NOWARN if this is GFP_ATOMIC > (implying we have to refill now) and the rxq->free_count is really small > e.g. <= 2? I like your suggestion. Considering the issue I would like to remove __GFP_NOWARN even if it is GFP_KERNEL ... I think it is actually even more of a problem if we are in GFP_KERNEL and not able to allocate memory when running low on buffers. Also, with the queue size of 256 I think we can use RX_LOW_WATERMARK here, which is 8. > > > if (!skb) { > > - IWL_CRIT(priv, "Can not allocate SKB buffers\n"); > > + if (net_ratelimit()) > > + IWL_CRIT(priv, "Can not allocate SKB buffer.\n"); > > Similarly, could the message either be supressed when there is enough > buffers in the RX queue or differenciate between enough buffers and > things getting tight possibly causing packet loss? Frans also had comments in this regard. Will do. > > The IWL_CRIT() part even is a hint - there is no guarantee that the allocation > failure is really a critical problem. Right. How about this: >From bd2153dd9e4a0ad588adec38c580d67023d5587e Mon Sep 17 00:00:00 2001 From: Reinette Chatre <reinette.chatre@intel.com> Date: Wed, 9 Sep 2009 15:41:00 -0700 Subject: [PATCH] iwlwifi: reduce noise when skb allocation fails Replenishment of receive buffers is done in the tasklet handling received frames as well as in a workqueue. When we are in the tasklet we cannot sleep and thus attempt atomic skb allocations. It is generally not a big problem if this fails since iwl_rx_allocate is always followed by a call to iwl_rx_queue_restock which will queue the work to replenish the buffers at a time when sleeping is allowed. We thus add the __GFP_NOWARN to the skb allocation in iwl_rx_allocate to reduce the noise if such an allocation fails while we still have enough buffers. We do maintain the warning and the error message when we are low on buffers to communicate to the user that there is a potential problem with memory availability on system This addresses issue reported upstream in thread "iwlagn: order 2 page allocation failures" in http://thread.gmane.org/gmane.linux.kernel.wireless.general/39187 Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> --- drivers/net/wireless/iwlwifi/iwl-rx.c | 12 +++++++++--- drivers/net/wireless/iwlwifi/iwl3945-base.c | 8 +++++++- 2 files changed, 16 insertions(+), 4 deletions(-) diff --git a/drivers/net/wireless/iwlwifi/iwl-rx.c b/drivers/net/wireless/iwlwifi/iwl-rx.c index b90adcb..cb50cc7 100644 --- a/drivers/net/wireless/iwlwifi/iwl-rx.c +++ b/drivers/net/wireless/iwlwifi/iwl-rx.c @@ -250,12 +250,18 @@ void iwl_rx_allocate(struct iwl_priv *priv, gfp_t priority) } spin_unlock_irqrestore(&rxq->lock, flags); + if (rxq->free_count > RX_LOW_WATERMARK) + priority |= __GFP_NOWARN; /* Alloc a new receive buffer */ - skb = alloc_skb(priv->hw_params.rx_buf_size + 256, - priority); + skb = alloc_skb(priv->hw_params.rx_buf_size + 256, priority); if (!skb) { - IWL_CRIT(priv, "Can not allocate SKB buffers\n"); + if (net_ratelimit()) + IWL_DEBUG_INFO("Failed to allocate SKB buffer.\n"); + if ((rxq->free_count <= RX_LOW_WATERMARK) && + net_ratelimit()) + IWL_CRIT(priv, "Failed to allocate SKB buffer. Only %u free buffers remaining\n", + rxq->free_count); /* We don't reschedule replenish work here -- we will * call the restock method and if it still needs * more buffers it will schedule replenish */ diff --git a/drivers/net/wireless/iwlwifi/iwl3945-base.c b/drivers/net/wireless/iwlwifi/iwl3945-base.c index 0909668..0d96b17 100644 --- a/drivers/net/wireless/iwlwifi/iwl3945-base.c +++ b/drivers/net/wireless/iwlwifi/iwl3945-base.c @@ -1146,11 +1146,17 @@ static void iwl3945_rx_allocate(struct iwl_priv *priv, gfp_t priority) } spin_unlock_irqrestore(&rxq->lock, flags); + if (rxq->free_count > RX_LOW_WATERMARK) + priority |= __GFP_NOWARN; /* Alloc a new receive buffer */ skb = alloc_skb(priv->hw_params.rx_buf_size, priority); if (!skb) { if (net_ratelimit()) - IWL_CRIT(priv, ": Can not allocate SKB buffers\n"); + IWL_DEBUG_INFO("Failed to allocate SKB buffer.\n"); + if ((rxq->free_count <= RX_LOW_WATERMARK) && + net_ratelimit()) + IWL_CRIT(priv, "Failed to allocate SKB buffer. Only %u free buffers remaining\n", + rxq->free_count); /* We don't reschedule replenish work here -- we will * call the restock method and if it still needs * more buffers it will schedule replenish */ -- 1.5.6.3 ^ permalink raw reply related [flat|nested] 66+ messages in thread
* Re: iwlagn: order 2 page allocation failures 2009-09-10 18:15 ` reinette chatre @ 2009-09-10 18:43 ` Frans Pop -1 siblings, 0 replies; 66+ messages in thread From: Frans Pop @ 2009-09-10 18:43 UTC (permalink / raw) To: reinette chatre Cc: Mel Gorman, Larry Finger, John W. Linville, Pekka Enberg, linux-kernel, linux-wireless, ipw3945-devel, Andrew Morton, cl, Krauss, Assaf, Johannes Berg, Abbas, Mohamed On Thursday 10 September 2009, reinette chatre wrote: > From: Reinette Chatre <reinette.chatre@intel.com> > Date: Wed, 9 Sep 2009 15:41:00 -0700 > Subject: [PATCH] iwlwifi: reduce noise when skb allocation fails Looks good to me (from a user's perspective). IIUC the first message is now only displayed if IWL debugging is explicitly enabled, and the second only if there really is danger of it affecting data transfer and has been made more informative too. It seems to me that, with debugging enabled, the "Failed to allocate SKB buffer." message may get repeated, but I guess that's minor. One nitpick. As you've made the message into sentences, "Only %u free buffers remaining" should IMO also end with a period. Thanks, FJP ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: iwlagn: order 2 page allocation failures @ 2009-09-10 18:43 ` Frans Pop 0 siblings, 0 replies; 66+ messages in thread From: Frans Pop @ 2009-09-10 18:43 UTC (permalink / raw) To: reinette chatre Cc: Mel Gorman, Larry Finger, John W. Linville, Pekka Enberg, linux-kernel, linux-wireless, ipw3945-devel, Andrew Morton, cl, Krauss, Assaf, Johannes Berg, Abbas, Mohamed On Thursday 10 September 2009, reinette chatre wrote: > From: Reinette Chatre <reinette.chatre@intel.com> > Date: Wed, 9 Sep 2009 15:41:00 -0700 > Subject: [PATCH] iwlwifi: reduce noise when skb allocation fails Looks good to me (from a user's perspective). IIUC the first message is now only displayed if IWL debugging is explicitly enabled, and the second only if there really is danger of it affecting data transfer and has been made more informative too. It seems to me that, with debugging enabled, the "Failed to allocate SKB buffer." message may get repeated, but I guess that's minor. One nitpick. As you've made the message into sentences, "Only %u free buffers remaining" should IMO also end with a period. Thanks, FJP ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: iwlagn: order 2 page allocation failures 2009-09-10 18:43 ` Frans Pop @ 2009-09-10 18:50 ` reinette chatre -1 siblings, 0 replies; 66+ messages in thread From: reinette chatre @ 2009-09-10 18:50 UTC (permalink / raw) To: Frans Pop Cc: Mel Gorman, Larry Finger, John W. Linville, Pekka Enberg, linux-kernel, linux-wireless, ipw3945-devel, Andrew Morton, cl, Krauss, Assaf, Johannes Berg, Abbas, Mohamed On Thu, 2009-09-10 at 11:43 -0700, Frans Pop wrote: > Looks good to me (from a user's perspective). Thank you very much for looking at it. > IIUC the first message is now only displayed if IWL debugging is > explicitly enabled, Correct. User will have to enable debug flag of 0x1. > It seems to me that, with debugging enabled, the "Failed to allocate SKB > buffer." message may get repeated, but I guess that's minor. Yes, it will be repeated. I did add a "net_ratelimit()" to it so it should not be too overwhelming. I did not care to limit it even more since we are now talking about a debug message as opposed to an error message on the console. > One nitpick. As you've made the message into sentences, "Only %u free > buffers remaining" should IMO also end with a period. Sorry - will fix. I will not post a new version to this thread for this issue, but it will be fixed in the next version I send out. Reinette ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: iwlagn: order 2 page allocation failures @ 2009-09-10 18:50 ` reinette chatre 0 siblings, 0 replies; 66+ messages in thread From: reinette chatre @ 2009-09-10 18:50 UTC (permalink / raw) To: Frans Pop Cc: Mel Gorman, Larry Finger, John W. Linville, Pekka Enberg, linux-kernel, linux-wireless, ipw3945-devel, Andrew Morton, cl, Krauss, Assaf, Johannes Berg, Abbas, Mohamed On Thu, 2009-09-10 at 11:43 -0700, Frans Pop wrote: > Looks good to me (from a user's perspective). Thank you very much for looking at it. > IIUC the first message is now only displayed if IWL debugging is > explicitly enabled, Correct. User will have to enable debug flag of 0x1. > It seems to me that, with debugging enabled, the "Failed to allocate SKB > buffer." message may get repeated, but I guess that's minor. Yes, it will be repeated. I did add a "net_ratelimit()" to it so it should not be too overwhelming. I did not care to limit it even more since we are now talking about a debug message as opposed to an error message on the console. > One nitpick. As you've made the message into sentences, "Only %u free > buffers remaining" should IMO also end with a period. Sorry - will fix. I will not post a new version to this thread for this issue, but it will be fixed in the next version I send out. Reinette ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: iwlagn: order 2 page allocation failures 2009-09-10 18:15 ` reinette chatre @ 2009-09-11 8:45 ` Mel Gorman -1 siblings, 0 replies; 66+ messages in thread From: Mel Gorman @ 2009-09-11 8:45 UTC (permalink / raw) To: reinette chatre Cc: Frans Pop, Larry Finger, John W. Linville, Pekka Enberg, linux-kernel, linux-wireless, ipw3945-devel, Andrew Morton, cl, Krauss, Assaf, Johannes Berg, Abbas, Mohamed On Thu, Sep 10, 2009 at 11:15:47AM -0700, reinette chatre wrote: > > > We can thus use ___GFP_NOWARN for the allocations in > > > iwl_rx_allocate and leave it to the restocking to find the needed memory > > > when it tried its allocations using GFP_KERNEL. > > > > > > > Would it be possible to use __GFP_NOWARN *unless* this allocation is > > necessary to receive the packet? > > I think so. > > > > I do think it is useful to let user know about these allocation > > > failures, even if it does not result in packet loss. Wrapping it in > > > net_ratelimit() will help though. > > > > > > > If it does not distinguish between failures causing packet loss and just a > > temporary issue, I'd be worried the messages would generate bug reports and > > we genuinely won't know if it's a real problem or not. > > Good point. > > > > > As a total aside, there is still the problem that the driver is depending on > > order-2 allocations. On systems without swap, the allocation problem could be > > more severe as there are fewer pages the system can use to regain contiguity. > > It seems that somebody did think about this in the initialization of > max_pkt_size (which is priv->hw_params.rx_buf_size - 256). If we use > max_pkt_size in the code that allocates the skb then the 256 added for > alignment will not cause it to go to an order-2 allocation. I do not > know why max_pkt_size is not used at the moment and will have to do some > digging to find out. > Thanks > > > How about the patch below? > > > > > > diff --git a/drivers/net/wireless/iwlwifi/iwl-rx.c b/drivers/net/wireless/iwlwifi/iwl-rx.c > > > index b90adcb..f0ee72e 100644 > > > --- a/drivers/net/wireless/iwlwifi/iwl-rx.c > > > +++ b/drivers/net/wireless/iwlwifi/iwl-rx.c > > > @@ -252,10 +252,11 @@ void iwl_rx_allocate(struct iwl_priv *priv, gfp_t priority) > > > > > > /* Alloc a new receive buffer */ > > > skb = alloc_skb(priv->hw_params.rx_buf_size + 256, > > > - priority); > > > + priority | __GFP_NOWARN); > > > > > > > So, would it be possible here to only remove __GFP_NOWARN if this is GFP_ATOMIC > > (implying we have to refill now) and the rxq->free_count is really small > > e.g. <= 2? > > I like your suggestion. Considering the issue I would like to remove > __GFP_NOWARN even if it is GFP_KERNEL ... I think it is actually even > more of a problem if we are in GFP_KERNEL and not able to allocate > memory when running low on buffers. Also, with the queue size of 256 I > think we can use RX_LOW_WATERMARK here, which is 8. > RX_LOW_WATERMARK sounds reasonable as if that watermark is reached, the buffer count is pretty low. With order-2 allocations, I bet the system is beginning to grind a bit to find contiguous pages at that point as well. I agree that it's a greater problem if the system is unable to allocate the pages as GFP_KERNEL - prehaps to the extent where it's worth distinguishing between GFP_KERNEL and GFP_ATOMIC failures. If GFP_KERNEL allocations are failure, packet loss is likely and the system may not recover, particularly if there is no swap configured. > > > > > > > > if (!skb) { > > > - IWL_CRIT(priv, "Can not allocate SKB buffers\n"); > > > + if (net_ratelimit()) > > > + IWL_CRIT(priv, "Can not allocate SKB buffer.\n"); > > > > Similarly, could the message either be supressed when there is enough > > buffers in the RX queue or differenciate between enough buffers and > > things getting tight possibly causing packet loss? > > Frans also had comments in this regard. Will do. > > > > > The IWL_CRIT() part even is a hint - there is no guarantee that the allocation > > failure is really a critical problem. > > Right. > > How about this: > > >From bd2153dd9e4a0ad588adec38c580d67023d5587e Mon Sep 17 00:00:00 2001 > From: Reinette Chatre <reinette.chatre@intel.com> > Date: Wed, 9 Sep 2009 15:41:00 -0700 > Subject: [PATCH] iwlwifi: reduce noise when skb allocation fails > > Replenishment of receive buffers is done in the tasklet handling > received frames as well as in a workqueue. When we are in the tasklet > we cannot sleep and thus attempt atomic skb allocations. It is generally > not a big problem if this fails since iwl_rx_allocate is always followed > by a call to iwl_rx_queue_restock which will queue the work to replenish > the buffers at a time when sleeping is allowed. > > We thus add the __GFP_NOWARN to the skb allocation in iwl_rx_allocate to > reduce the noise if such an allocation fails while we still have enough > buffers. We do maintain the warning and the error message when we are low > on buffers to communicate to the user that there is a potential problem with > memory availability on system > > This addresses issue reported upstream in thread "iwlagn: order 2 page > allocation failures" in > http://thread.gmane.org/gmane.linux.kernel.wireless.general/39187 > > Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> > --- > drivers/net/wireless/iwlwifi/iwl-rx.c | 12 +++++++++--- > drivers/net/wireless/iwlwifi/iwl3945-base.c | 8 +++++++- > 2 files changed, 16 insertions(+), 4 deletions(-) > > diff --git a/drivers/net/wireless/iwlwifi/iwl-rx.c b/drivers/net/wireless/iwlwifi/iwl-rx.c > index b90adcb..cb50cc7 100644 > --- a/drivers/net/wireless/iwlwifi/iwl-rx.c > +++ b/drivers/net/wireless/iwlwifi/iwl-rx.c > @@ -250,12 +250,18 @@ void iwl_rx_allocate(struct iwl_priv *priv, gfp_t priority) > } > spin_unlock_irqrestore(&rxq->lock, flags); > > + if (rxq->free_count > RX_LOW_WATERMARK) > + priority |= __GFP_NOWARN; Seems very reasonable. > /* Alloc a new receive buffer */ > - skb = alloc_skb(priv->hw_params.rx_buf_size + 256, > - priority); > + skb = alloc_skb(priv->hw_params.rx_buf_size + 256, priority); > This change appears superflous. It don't change any functionality. Looks like the style is just being made consistent with a similar code block elsewhere. > if (!skb) { > - IWL_CRIT(priv, "Can not allocate SKB buffers\n"); > + if (net_ratelimit()) > + IWL_DEBUG_INFO("Failed to allocate SKB buffer.\n"); > + if ((rxq->free_count <= RX_LOW_WATERMARK) && > + net_ratelimit()) > + IWL_CRIT(priv, "Failed to allocate SKB buffer. Only %u free buffers remaining\n", > + rxq->free_count); To get a good idea of how screwed we really are, how about? IWL_CRIT(priv, "Failed to allocate SKB buffer with %s. Only %u free buffers remaining\n", priority == GFP_ATOMIC ? "GFP_ATOMIC" : "GFP_KERNEL", rxq->free_count); > /* We don't reschedule replenish work here -- we will > * call the restock method and if it still needs > * more buffers it will schedule replenish */ > diff --git a/drivers/net/wireless/iwlwifi/iwl3945-base.c b/drivers/net/wireless/iwlwifi/iwl3945-base.c > index 0909668..0d96b17 100644 > --- a/drivers/net/wireless/iwlwifi/iwl3945-base.c > +++ b/drivers/net/wireless/iwlwifi/iwl3945-base.c > @@ -1146,11 +1146,17 @@ static void iwl3945_rx_allocate(struct iwl_priv *priv, gfp_t priority) > } > spin_unlock_irqrestore(&rxq->lock, flags); > > + if (rxq->free_count > RX_LOW_WATERMARK) > + priority |= __GFP_NOWARN; > /* Alloc a new receive buffer */ > skb = alloc_skb(priv->hw_params.rx_buf_size, priority); > if (!skb) { > if (net_ratelimit()) > - IWL_CRIT(priv, ": Can not allocate SKB buffers\n"); > + IWL_DEBUG_INFO("Failed to allocate SKB buffer.\n"); > + if ((rxq->free_count <= RX_LOW_WATERMARK) && > + net_ratelimit()) > + IWL_CRIT(priv, "Failed to allocate SKB buffer. Only %u free buffers remaining\n", > + rxq->free_count); > /* We don't reschedule replenish work here -- we will > * call the restock method and if it still needs > * more buffers it will schedule replenish */ Otherwise, it looks just the finest and I think it will address the problem to some extent - in that it won't print alarming messages when they are not needed. The additional changes with respect to GFP_ATOMIC are optional. Whether you do it or not. Acked-by: Mel Gorman <mel@csn.ul.ie> Thanks very much. -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: iwlagn: order 2 page allocation failures @ 2009-09-11 8:45 ` Mel Gorman 0 siblings, 0 replies; 66+ messages in thread From: Mel Gorman @ 2009-09-11 8:45 UTC (permalink / raw) To: reinette chatre Cc: Frans Pop, Larry Finger, John W. Linville, Pekka Enberg, linux-kernel, linux-wireless, ipw3945-devel, Andrew Morton, cl, Krauss, Assaf, Johannes Berg, Abbas, Mohamed On Thu, Sep 10, 2009 at 11:15:47AM -0700, reinette chatre wrote: > > > We can thus use ___GFP_NOWARN for the allocations in > > > iwl_rx_allocate and leave it to the restocking to find the needed memory > > > when it tried its allocations using GFP_KERNEL. > > > > > > > Would it be possible to use __GFP_NOWARN *unless* this allocation is > > necessary to receive the packet? > > I think so. > > > > I do think it is useful to let user know about these allocation > > > failures, even if it does not result in packet loss. Wrapping it in > > > net_ratelimit() will help though. > > > > > > > If it does not distinguish between failures causing packet loss and just a > > temporary issue, I'd be worried the messages would generate bug reports and > > we genuinely won't know if it's a real problem or not. > > Good point. > > > > > As a total aside, there is still the problem that the driver is depending on > > order-2 allocations. On systems without swap, the allocation problem could be > > more severe as there are fewer pages the system can use to regain contiguity. > > It seems that somebody did think about this in the initialization of > max_pkt_size (which is priv->hw_params.rx_buf_size - 256). If we use > max_pkt_size in the code that allocates the skb then the 256 added for > alignment will not cause it to go to an order-2 allocation. I do not > know why max_pkt_size is not used at the moment and will have to do some > digging to find out. > Thanks > > > How about the patch below? > > > > > > diff --git a/drivers/net/wireless/iwlwifi/iwl-rx.c b/drivers/net/wireless/iwlwifi/iwl-rx.c > > > index b90adcb..f0ee72e 100644 > > > --- a/drivers/net/wireless/iwlwifi/iwl-rx.c > > > +++ b/drivers/net/wireless/iwlwifi/iwl-rx.c > > > @@ -252,10 +252,11 @@ void iwl_rx_allocate(struct iwl_priv *priv, gfp_t priority) > > > > > > /* Alloc a new receive buffer */ > > > skb = alloc_skb(priv->hw_params.rx_buf_size + 256, > > > - priority); > > > + priority | __GFP_NOWARN); > > > > > > > So, would it be possible here to only remove __GFP_NOWARN if this is GFP_ATOMIC > > (implying we have to refill now) and the rxq->free_count is really small > > e.g. <= 2? > > I like your suggestion. Considering the issue I would like to remove > __GFP_NOWARN even if it is GFP_KERNEL ... I think it is actually even > more of a problem if we are in GFP_KERNEL and not able to allocate > memory when running low on buffers. Also, with the queue size of 256 I > think we can use RX_LOW_WATERMARK here, which is 8. > RX_LOW_WATERMARK sounds reasonable as if that watermark is reached, the buffer count is pretty low. With order-2 allocations, I bet the system is beginning to grind a bit to find contiguous pages at that point as well. I agree that it's a greater problem if the system is unable to allocate the pages as GFP_KERNEL - prehaps to the extent where it's worth distinguishing between GFP_KERNEL and GFP_ATOMIC failures. If GFP_KERNEL allocations are failure, packet loss is likely and the system may not recover, particularly if there is no swap configured. > > > > > > > > if (!skb) { > > > - IWL_CRIT(priv, "Can not allocate SKB buffers\n"); > > > + if (net_ratelimit()) > > > + IWL_CRIT(priv, "Can not allocate SKB buffer.\n"); > > > > Similarly, could the message either be supressed when there is enough > > buffers in the RX queue or differenciate between enough buffers and > > things getting tight possibly causing packet loss? > > Frans also had comments in this regard. Will do. > > > > > The IWL_CRIT() part even is a hint - there is no guarantee that the allocation > > failure is really a critical problem. > > Right. > > How about this: > > >From bd2153dd9e4a0ad588adec38c580d67023d5587e Mon Sep 17 00:00:00 2001 > From: Reinette Chatre <reinette.chatre@intel.com> > Date: Wed, 9 Sep 2009 15:41:00 -0700 > Subject: [PATCH] iwlwifi: reduce noise when skb allocation fails > > Replenishment of receive buffers is done in the tasklet handling > received frames as well as in a workqueue. When we are in the tasklet > we cannot sleep and thus attempt atomic skb allocations. It is generally > not a big problem if this fails since iwl_rx_allocate is always followed > by a call to iwl_rx_queue_restock which will queue the work to replenish > the buffers at a time when sleeping is allowed. > > We thus add the __GFP_NOWARN to the skb allocation in iwl_rx_allocate to > reduce the noise if such an allocation fails while we still have enough > buffers. We do maintain the warning and the error message when we are low > on buffers to communicate to the user that there is a potential problem with > memory availability on system > > This addresses issue reported upstream in thread "iwlagn: order 2 page > allocation failures" in > http://thread.gmane.org/gmane.linux.kernel.wireless.general/39187 > > Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> > --- > drivers/net/wireless/iwlwifi/iwl-rx.c | 12 +++++++++--- > drivers/net/wireless/iwlwifi/iwl3945-base.c | 8 +++++++- > 2 files changed, 16 insertions(+), 4 deletions(-) > > diff --git a/drivers/net/wireless/iwlwifi/iwl-rx.c b/drivers/net/wireless/iwlwifi/iwl-rx.c > index b90adcb..cb50cc7 100644 > --- a/drivers/net/wireless/iwlwifi/iwl-rx.c > +++ b/drivers/net/wireless/iwlwifi/iwl-rx.c > @@ -250,12 +250,18 @@ void iwl_rx_allocate(struct iwl_priv *priv, gfp_t priority) > } > spin_unlock_irqrestore(&rxq->lock, flags); > > + if (rxq->free_count > RX_LOW_WATERMARK) > + priority |= __GFP_NOWARN; Seems very reasonable. > /* Alloc a new receive buffer */ > - skb = alloc_skb(priv->hw_params.rx_buf_size + 256, > - priority); > + skb = alloc_skb(priv->hw_params.rx_buf_size + 256, priority); > This change appears superflous. It don't change any functionality. Looks like the style is just being made consistent with a similar code block elsewhere. > if (!skb) { > - IWL_CRIT(priv, "Can not allocate SKB buffers\n"); > + if (net_ratelimit()) > + IWL_DEBUG_INFO("Failed to allocate SKB buffer.\n"); > + if ((rxq->free_count <= RX_LOW_WATERMARK) && > + net_ratelimit()) > + IWL_CRIT(priv, "Failed to allocate SKB buffer. Only %u free buffers remaining\n", > + rxq->free_count); To get a good idea of how screwed we really are, how about? IWL_CRIT(priv, "Failed to allocate SKB buffer with %s. Only %u free buffers remaining\n", priority == GFP_ATOMIC ? "GFP_ATOMIC" : "GFP_KERNEL", rxq->free_count); > /* We don't reschedule replenish work here -- we will > * call the restock method and if it still needs > * more buffers it will schedule replenish */ > diff --git a/drivers/net/wireless/iwlwifi/iwl3945-base.c b/drivers/net/wireless/iwlwifi/iwl3945-base.c > index 0909668..0d96b17 100644 > --- a/drivers/net/wireless/iwlwifi/iwl3945-base.c > +++ b/drivers/net/wireless/iwlwifi/iwl3945-base.c > @@ -1146,11 +1146,17 @@ static void iwl3945_rx_allocate(struct iwl_priv *priv, gfp_t priority) > } > spin_unlock_irqrestore(&rxq->lock, flags); > > + if (rxq->free_count > RX_LOW_WATERMARK) > + priority |= __GFP_NOWARN; > /* Alloc a new receive buffer */ > skb = alloc_skb(priv->hw_params.rx_buf_size, priority); > if (!skb) { > if (net_ratelimit()) > - IWL_CRIT(priv, ": Can not allocate SKB buffers\n"); > + IWL_DEBUG_INFO("Failed to allocate SKB buffer.\n"); > + if ((rxq->free_count <= RX_LOW_WATERMARK) && > + net_ratelimit()) > + IWL_CRIT(priv, "Failed to allocate SKB buffer. Only %u free buffers remaining\n", > + rxq->free_count); > /* We don't reschedule replenish work here -- we will > * call the restock method and if it still needs > * more buffers it will schedule replenish */ Otherwise, it looks just the finest and I think it will address the problem to some extent - in that it won't print alarming messages when they are not needed. The additional changes with respect to GFP_ATOMIC are optional. Whether you do it or not. Acked-by: Mel Gorman <mel@csn.ul.ie> Thanks very much. -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: iwlagn: order 2 page allocation failures 2009-09-11 8:45 ` Mel Gorman @ 2009-09-11 16:14 ` reinette chatre -1 siblings, 0 replies; 66+ messages in thread From: reinette chatre @ 2009-09-11 16:14 UTC (permalink / raw) To: Mel Gorman Cc: Frans Pop, Larry Finger, John W. Linville, Pekka Enberg, linux-kernel, linux-wireless, ipw3945-devel, Andrew Morton, cl, Krauss, Assaf, Johannes Berg, Abbas, Mohamed On Fri, 2009-09-11 at 01:45 -0700, Mel Gorman wrote: > Otherwise, it looks just the finest and I think it will address the > problem to some extent - in that it won't print alarming messages when > they are not needed. > > The additional changes with respect to GFP_ATOMIC are optional. Whether > you do it or not. > > Acked-by: Mel Gorman <mel@csn.ul.ie> Thank you very much. I'll make the changes you suggested. Reinette ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: iwlagn: order 2 page allocation failures @ 2009-09-11 16:14 ` reinette chatre 0 siblings, 0 replies; 66+ messages in thread From: reinette chatre @ 2009-09-11 16:14 UTC (permalink / raw) To: Mel Gorman Cc: Frans Pop, Larry Finger, John W. Linville, Pekka Enberg, linux-kernel, linux-wireless, ipw3945-devel, Andrew Morton, cl, Krauss, Assaf, Johannes Berg, Abbas, Mohamed On Fri, 2009-09-11 at 01:45 -0700, Mel Gorman wrote: > Otherwise, it looks just the finest and I think it will address the > problem to some extent - in that it won't print alarming messages when > they are not needed. > > The additional changes with respect to GFP_ATOMIC are optional. Whether > you do it or not. > > Acked-by: Mel Gorman <mel@csn.ul.ie> Thank you very much. I'll make the changes you suggested. Reinette ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: iwlagn: order 2 page allocation failures 2009-09-10 9:02 ` Mel Gorman @ 2009-09-10 21:14 ` reinette chatre -1 siblings, 0 replies; 66+ messages in thread From: reinette chatre @ 2009-09-10 21:14 UTC (permalink / raw) To: Mel Gorman Cc: Frans Pop, Larry Finger, John W. Linville, Pekka Enberg, linux-kernel, linux-wireless, ipw3945-devel, Andrew Morton, cl, Krauss, Assaf, Johannes Berg, Abbas, Mohamed On Thu, 2009-09-10 at 02:02 -0700, Mel Gorman wrote: > > As a total aside, there is still the problem that the driver is depending on > order-2 allocations. On systems without swap, the allocation problem could be > more severe as there are fewer pages the system can use to regain contiguity. I looked more at the implementation and hardware interface but I do not see a way around this. We have to provide 8k buffer to device, and we have to make sure it is aligned. Do you have any suggestions? Reinette ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: iwlagn: order 2 page allocation failures @ 2009-09-10 21:14 ` reinette chatre 0 siblings, 0 replies; 66+ messages in thread From: reinette chatre @ 2009-09-10 21:14 UTC (permalink / raw) To: Mel Gorman Cc: Frans Pop, Larry Finger, John W. Linville, Pekka Enberg, linux-kernel, linux-wireless, ipw3945-devel, Andrew Morton, cl, Krauss, Assaf, Johannes Berg, Abbas, Mohamed On Thu, 2009-09-10 at 02:02 -0700, Mel Gorman wrote: > > As a total aside, there is still the problem that the driver is depending on > order-2 allocations. On systems without swap, the allocation problem could be > more severe as there are fewer pages the system can use to regain contiguity. I looked more at the implementation and hardware interface but I do not see a way around this. We have to provide 8k buffer to device, and we have to make sure it is aligned. Do you have any suggestions? Reinette ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: iwlagn: order 2 page allocation failures 2009-09-10 21:14 ` reinette chatre @ 2009-09-11 8:47 ` Mel Gorman -1 siblings, 0 replies; 66+ messages in thread From: Mel Gorman @ 2009-09-11 8:47 UTC (permalink / raw) To: reinette chatre Cc: Frans Pop, Larry Finger, John W. Linville, Pekka Enberg, linux-kernel, linux-wireless, ipw3945-devel, Andrew Morton, cl, Krauss, Assaf, Johannes Berg, Abbas, Mohamed On Thu, Sep 10, 2009 at 02:14:50PM -0700, reinette chatre wrote: > On Thu, 2009-09-10 at 02:02 -0700, Mel Gorman wrote: > > > > > As a total aside, there is still the problem that the driver is depending on > > order-2 allocations. On systems without swap, the allocation problem could be > > more severe as there are fewer pages the system can use to regain contiguity. > > I looked more at the implementation and hardware interface but I do not > see a way around this. We have to provide 8k buffer to device, and we > have to make sure it is aligned. > That would imply an order-1 allocation instead of an order-2 though so it would appear than we are being worse than we have to. It would appear to be because of this +256 bytes that goes onto every buffer. > Do you have any suggestions? > Nothing concrete. Finding an alternative to having the socket buffer 8192+256 to make it an order-1 allocation would be an improvement but I don't know how that should be tackled. Lacking the hardware, I can't experiment myself :( -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: iwlagn: order 2 page allocation failures @ 2009-09-11 8:47 ` Mel Gorman 0 siblings, 0 replies; 66+ messages in thread From: Mel Gorman @ 2009-09-11 8:47 UTC (permalink / raw) To: reinette chatre Cc: Frans Pop, Larry Finger, John W. Linville, Pekka Enberg, linux-kernel, linux-wireless, ipw3945-devel, Andrew Morton, cl, Krauss, Assaf, Johannes Berg, Abbas, Mohamed On Thu, Sep 10, 2009 at 02:14:50PM -0700, reinette chatre wrote: > On Thu, 2009-09-10 at 02:02 -0700, Mel Gorman wrote: > > > > > As a total aside, there is still the problem that the driver is depending on > > order-2 allocations. On systems without swap, the allocation problem could be > > more severe as there are fewer pages the system can use to regain contiguity. > > I looked more at the implementation and hardware interface but I do not > see a way around this. We have to provide 8k buffer to device, and we > have to make sure it is aligned. > That would imply an order-1 allocation instead of an order-2 though so it would appear than we are being worse than we have to. It would appear to be because of this +256 bytes that goes onto every buffer. > Do you have any suggestions? > Nothing concrete. Finding an alternative to having the socket buffer 8192+256 to make it an order-1 allocation would be an improvement but I don't know how that should be tackled. Lacking the hardware, I can't experiment myself :( -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: iwlagn: order 2 page allocation failures 2009-09-11 8:47 ` Mel Gorman @ 2009-09-14 3:01 ` Zhu Yi -1 siblings, 0 replies; 66+ messages in thread From: Zhu Yi @ 2009-09-14 3:01 UTC (permalink / raw) To: Mel Gorman Cc: Chatre, Reinette, Frans Pop, Larry Finger, John W. Linville, Pekka Enberg, linux-kernel, linux-wireless, ipw3945-devel, Andrew Morton, cl, Krauss, Assaf, Johannes Berg, Abbas, Mohamed On Fri, 2009-09-11 at 16:47 +0800, Mel Gorman wrote: > On Thu, Sep 10, 2009 at 02:14:50PM -0700, reinette chatre wrote: > > On Thu, 2009-09-10 at 02:02 -0700, Mel Gorman wrote: > > > > > > > > As a total aside, there is still the problem that the driver is depending on > > > order-2 allocations. On systems without swap, the allocation problem could be > > > more severe as there are fewer pages the system can use to regain contiguity. > > > > I looked more at the implementation and hardware interface but I do not > > see a way around this. We have to provide 8k buffer to device, and we > > have to make sure it is aligned. > > > > That would imply an order-1 allocation instead of an order-2 though so > it would appear than we are being worse than we have to. It would appear > to be because of this +256 bytes that goes onto every buffer. > > > Do you have any suggestions? > > > > Nothing concrete. Finding an alternative to having the socket buffer > 8192+256 to make it an order-1 allocation would be an improvement but I > don't know how that should be tackled. Lacking the hardware, I can't > experiment myself :( Essentially, the hardware only requires an order-1 allocation aligned on 256 bytes boundary. But as it is used as an SKB, a trailing struct skb_shared_info is added. This forces us to both increase the order and do alignment ourselves. I believe some improvement could be done here. But it should not be an easy one. BTW, does SLAB/SLUB guarantee size of multiple PAGE_SIZE __kmalloc() allocation align on PAGE_SIZE (or 256 bytes) boundary? Thanks, -yi ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: iwlagn: order 2 page allocation failures @ 2009-09-14 3:01 ` Zhu Yi 0 siblings, 0 replies; 66+ messages in thread From: Zhu Yi @ 2009-09-14 3:01 UTC (permalink / raw) To: Mel Gorman Cc: Chatre, Reinette, Frans Pop, Larry Finger, John W. Linville, Pekka Enberg, linux-kernel, linux-wireless, ipw3945-devel, Andrew Morton, cl, Krauss, Assaf, Johannes Berg, Abbas, Mohamed On Fri, 2009-09-11 at 16:47 +0800, Mel Gorman wrote: > On Thu, Sep 10, 2009 at 02:14:50PM -0700, reinette chatre wrote: > > On Thu, 2009-09-10 at 02:02 -0700, Mel Gorman wrote: > > > > > > > > As a total aside, there is still the problem that the driver is depending on > > > order-2 allocations. On systems without swap, the allocation problem could be > > > more severe as there are fewer pages the system can use to regain contiguity. > > > > I looked more at the implementation and hardware interface but I do not > > see a way around this. We have to provide 8k buffer to device, and we > > have to make sure it is aligned. > > > > That would imply an order-1 allocation instead of an order-2 though so > it would appear than we are being worse than we have to. It would appear > to be because of this +256 bytes that goes onto every buffer. > > > Do you have any suggestions? > > > > Nothing concrete. Finding an alternative to having the socket buffer > 8192+256 to make it an order-1 allocation would be an improvement but I > don't know how that should be tackled. Lacking the hardware, I can't > experiment myself :( Essentially, the hardware only requires an order-1 allocation aligned on 256 bytes boundary. But as it is used as an SKB, a trailing struct skb_shared_info is added. This forces us to both increase the order and do alignment ourselves. I believe some improvement could be done here. But it should not be an easy one. BTW, does SLAB/SLUB guarantee size of multiple PAGE_SIZE __kmalloc() allocation align on PAGE_SIZE (or 256 bytes) boundary? Thanks, -yi ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: iwlagn: order 2 page allocation failures 2009-09-14 3:01 ` Zhu Yi @ 2009-09-14 13:06 ` Mel Gorman -1 siblings, 0 replies; 66+ messages in thread From: Mel Gorman @ 2009-09-14 13:06 UTC (permalink / raw) To: Zhu Yi Cc: Chatre, Reinette, Frans Pop, Larry Finger, John W. Linville, Pekka Enberg, linux-kernel, linux-wireless, ipw3945-devel, Andrew Morton, cl, Krauss, Assaf, Johannes Berg, Abbas, Mohamed On Mon, Sep 14, 2009 at 11:01:10AM +0800, Zhu Yi wrote: > On Fri, 2009-09-11 at 16:47 +0800, Mel Gorman wrote: > > On Thu, Sep 10, 2009 at 02:14:50PM -0700, reinette chatre wrote: > > > On Thu, 2009-09-10 at 02:02 -0700, Mel Gorman wrote: > > > > > > > > > > > As a total aside, there is still the problem that the driver is depending on > > > > order-2 allocations. On systems without swap, the allocation problem could be > > > > more severe as there are fewer pages the system can use to regain contiguity. > > > > > > I looked more at the implementation and hardware interface but I do not > > > see a way around this. We have to provide 8k buffer to device, and we > > > have to make sure it is aligned. > > > > > > > That would imply an order-1 allocation instead of an order-2 though so > > it would appear than we are being worse than we have to. It would appear > > to be because of this +256 bytes that goes onto every buffer. > > > > > Do you have any suggestions? > > > > > > > Nothing concrete. Finding an alternative to having the socket buffer > > 8192+256 to make it an order-1 allocation would be an improvement but I > > don't know how that should be tackled. Lacking the hardware, I can't > > experiment myself :( > > Essentially, the hardware only requires an order-1 allocation aligned on > 256 bytes boundary. But as it is used as an SKB, a trailing struct > skb_shared_info is added. This forces us to both increase the order and > do alignment ourselves. I believe some improvement could be done here. > But it should not be an easy one. > Probably not. I can only assume that moving the location of skb_shared_info such that it is sometimes located after the buffer and sometimes allocated via a separate kmalloc() would be a significant undertaking. > BTW, does SLAB/SLUB guarantee size of multiple PAGE_SIZE __kmalloc() > allocation align on PAGE_SIZE (or 256 bytes) boundary? > Page-aligned. -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: iwlagn: order 2 page allocation failures @ 2009-09-14 13:06 ` Mel Gorman 0 siblings, 0 replies; 66+ messages in thread From: Mel Gorman @ 2009-09-14 13:06 UTC (permalink / raw) To: Zhu Yi Cc: Chatre, Reinette, Frans Pop, Larry Finger, John W. Linville, Pekka Enberg, linux-kernel, linux-wireless, ipw3945-devel, Andrew Morton, cl, Krauss, Assaf, Johannes Berg, Abbas, Mohamed On Mon, Sep 14, 2009 at 11:01:10AM +0800, Zhu Yi wrote: > On Fri, 2009-09-11 at 16:47 +0800, Mel Gorman wrote: > > On Thu, Sep 10, 2009 at 02:14:50PM -0700, reinette chatre wrote: > > > On Thu, 2009-09-10 at 02:02 -0700, Mel Gorman wrote: > > > > > > > > > > > As a total aside, there is still the problem that the driver is depending on > > > > order-2 allocations. On systems without swap, the allocation problem could be > > > > more severe as there are fewer pages the system can use to regain contiguity. > > > > > > I looked more at the implementation and hardware interface but I do not > > > see a way around this. We have to provide 8k buffer to device, and we > > > have to make sure it is aligned. > > > > > > > That would imply an order-1 allocation instead of an order-2 though so > > it would appear than we are being worse than we have to. It would appear > > to be because of this +256 bytes that goes onto every buffer. > > > > > Do you have any suggestions? > > > > > > > Nothing concrete. Finding an alternative to having the socket buffer > > 8192+256 to make it an order-1 allocation would be an improvement but I > > don't know how that should be tackled. Lacking the hardware, I can't > > experiment myself :( > > Essentially, the hardware only requires an order-1 allocation aligned on > 256 bytes boundary. But as it is used as an SKB, a trailing struct > skb_shared_info is added. This forces us to both increase the order and > do alignment ourselves. I believe some improvement could be done here. > But it should not be an easy one. > Probably not. I can only assume that moving the location of skb_shared_info such that it is sometimes located after the buffer and sometimes allocated via a separate kmalloc() would be a significant undertaking. > BTW, does SLAB/SLUB guarantee size of multiple PAGE_SIZE __kmalloc() > allocation align on PAGE_SIZE (or 256 bytes) boundary? > Page-aligned. -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab ^ permalink raw reply [flat|nested] 66+ messages in thread
* alloc skb based on a given data buffer 2009-09-14 13:06 ` Mel Gorman @ 2009-09-15 8:30 ` Zhu Yi -1 siblings, 0 replies; 66+ messages in thread From: Zhu Yi @ 2009-09-15 8:30 UTC (permalink / raw) To: Mel Gorman Cc: Chatre, Reinette, Frans Pop, Larry Finger, John W. Linville, Pekka Enberg, linux-kernel, linux-wireless, ipw3945-devel, Andrew Morton, cl, Krauss, Assaf, Johannes Berg, Abbas, Mohamed, netdev [ Cc netdev and change the subject ] On Mon, 2009-09-14 at 21:06 +0800, Mel Gorman wrote: > > Essentially, the hardware only requires an order-1 allocation aligned on > > 256 bytes boundary. But as it is used as an SKB, a trailing struct > > skb_shared_info is added. This forces us to both increase the order and > > do alignment ourselves. I believe some improvement could be done here. > > But it should not be an easy one. > > > > Probably not. I can only assume that moving the location of > skb_shared_info such that it is sometimes located after the buffer and > sometimes allocated via a separate kmalloc() would be a significant > undertaking. Shall I propose below function as a variant to alloc_skb()? struct sk_buff *alloc_skb_attach_buff(void *data_buff, unsigned int real_size, unsigned int size, gfp_t mask); If real_size >= size + sizeof(struct skb_shared_info), we can still put the shinfo at the end of the buffer. Otherwise we can allocate from a new slab that put sk_buff and shinfo together. Of course, kfree_skbmem() needs to recognize it. This way, device drivers can allocate the Rx buffers with their own size and alignment requirement. i.e. do an order-1 page allocation directly with free_pages() in the iwlagn driver for a 256 bytes aligned 8K Rx buffer. After DMA is finished, drivers can use the above function to assemble an skb based on the Rx buffer. It should resolve the problem for requiring an order-2 allocation by alloc_skb() in the first place. Comments are welcome. Thanks, -yi ^ permalink raw reply [flat|nested] 66+ messages in thread
* alloc skb based on a given data buffer @ 2009-09-15 8:30 ` Zhu Yi 0 siblings, 0 replies; 66+ messages in thread From: Zhu Yi @ 2009-09-15 8:30 UTC (permalink / raw) To: Mel Gorman Cc: Chatre, Reinette, Frans Pop, Larry Finger, John W. Linville, Pekka Enberg, linux-kernel, linux-wireless, ipw3945-devel, Andrew Morton, cl, Krauss, Assaf, Johannes Berg, Abbas, Mohamed, netdev [ Cc netdev and change the subject ] On Mon, 2009-09-14 at 21:06 +0800, Mel Gorman wrote: > > Essentially, the hardware only requires an order-1 allocation aligned on > > 256 bytes boundary. But as it is used as an SKB, a trailing struct > > skb_shared_info is added. This forces us to both increase the order and > > do alignment ourselves. I believe some improvement could be done here. > > But it should not be an easy one. > > > > Probably not. I can only assume that moving the location of > skb_shared_info such that it is sometimes located after the buffer and > sometimes allocated via a separate kmalloc() would be a significant > undertaking. Shall I propose below function as a variant to alloc_skb()? struct sk_buff *alloc_skb_attach_buff(void *data_buff, unsigned int real_size, unsigned int size, gfp_t mask); If real_size >= size + sizeof(struct skb_shared_info), we can still put the shinfo at the end of the buffer. Otherwise we can allocate from a new slab that put sk_buff and shinfo together. Of course, kfree_skbmem() needs to recognize it. This way, device drivers can allocate the Rx buffers with their own size and alignment requirement. i.e. do an order-1 page allocation directly with free_pages() in the iwlagn driver for a 256 bytes aligned 8K Rx buffer. After DMA is finished, drivers can use the above function to assemble an skb based on the Rx buffer. It should resolve the problem for requiring an order-2 allocation by alloc_skb() in the first place. Comments are welcome. Thanks, -yi ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: alloc skb based on a given data buffer 2009-09-15 8:30 ` Zhu Yi @ 2009-09-15 8:33 ` David Miller -1 siblings, 0 replies; 66+ messages in thread From: David Miller @ 2009-09-15 8:33 UTC (permalink / raw) To: yi.zhu Cc: mel, reinette.chatre, elendil, Larry.Finger, linville, penberg, linux-kernel, linux-wireless, ipw3945-devel, akpm, cl, assaf.krauss, johannes, mohamed.abbas, netdev From: Zhu Yi <yi.zhu@intel.com> Date: Tue, 15 Sep 2009 16:30:20 +0800 > This way, device drivers can allocate the Rx buffers with their own size > and alignment requirement. i.e. do an order-1 page allocation directly > with free_pages() in the iwlagn driver for a 256 bytes aligned 8K Rx > buffer. After DMA is finished, drivers can use the above function to > assemble an skb based on the Rx buffer. It should resolve the problem > for requiring an order-2 allocation by alloc_skb() in the first place. You can create paged RX skbs just like drivers such as niu.c and others already do, there is no need for special APIs for this. ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: alloc skb based on a given data buffer @ 2009-09-15 8:33 ` David Miller 0 siblings, 0 replies; 66+ messages in thread From: David Miller @ 2009-09-15 8:33 UTC (permalink / raw) To: yi.zhu-ral2JQCrhuEAvxtiuMwx3w Cc: mel-wPRd99KPJ+uzQB+pC5nmwQ, reinette.chatre-ral2JQCrhuEAvxtiuMwx3w, elendil-EIBgga6/0yRmR6Xm/wNWPw, Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ, linville-2XuSBdqkA4R54TAoqtyWWQ, penberg-bbCR+/B0CizivPeTLB3BmA, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-wireless-u79uwXL29TY76Z2rM5mHXA, ipw3945-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b, cl-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b, assaf.krauss-ral2JQCrhuEAvxtiuMwx3w, johannes-cdvu00un1VgdHxzADdlk8Q, mohamed.abbas-ral2JQCrhuEAvxtiuMwx3w, netdev-u79uwXL29TY76Z2rM5mHXA From: Zhu Yi <yi.zhu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> Date: Tue, 15 Sep 2009 16:30:20 +0800 > This way, device drivers can allocate the Rx buffers with their own size > and alignment requirement. i.e. do an order-1 page allocation directly > with free_pages() in the iwlagn driver for a 256 bytes aligned 8K Rx > buffer. After DMA is finished, drivers can use the above function to > assemble an skb based on the Rx buffer. It should resolve the problem > for requiring an order-2 allocation by alloc_skb() in the first place. You can create paged RX skbs just like drivers such as niu.c and others already do, there is no need for special APIs for this. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: alloc skb based on a given data buffer 2009-09-15 8:33 ` David Miller @ 2009-09-15 8:57 ` Zhu Yi -1 siblings, 0 replies; 66+ messages in thread From: Zhu Yi @ 2009-09-15 8:57 UTC (permalink / raw) To: David Miller Cc: mel, Chatre, Reinette, elendil, Larry.Finger, linville, penberg, linux-kernel, linux-wireless, ipw3945-devel, akpm, cl, Krauss, Assaf, johannes, Abbas, Mohamed, netdev On Tue, 2009-09-15 at 16:33 +0800, David Miller wrote: > From: Zhu Yi <yi.zhu@intel.com> > Date: Tue, 15 Sep 2009 16:30:20 +0800 > > > This way, device drivers can allocate the Rx buffers with their own size > > and alignment requirement. i.e. do an order-1 page allocation directly > > with free_pages() in the iwlagn driver for a 256 bytes aligned 8K Rx > > buffer. After DMA is finished, drivers can use the above function to > > assemble an skb based on the Rx buffer. It should resolve the problem > > for requiring an order-2 allocation by alloc_skb() in the first place. > > You can create paged RX skbs just like drivers such as niu.c > and others already do, there is no need for special APIs for > this. Thanks. So we can put the 8K buffer into 2 skb_shinfo()->frags[] slots and set nr_frags to 2, right? Is this supported allover the network code already? At a first glance, I didn't find any frags handling in mac80211 stack. Thanks, -yi ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: alloc skb based on a given data buffer @ 2009-09-15 8:57 ` Zhu Yi 0 siblings, 0 replies; 66+ messages in thread From: Zhu Yi @ 2009-09-15 8:57 UTC (permalink / raw) To: David Miller Cc: mel, Chatre, Reinette, elendil, Larry.Finger, linville, penberg, linux-kernel, linux-wireless, ipw3945-devel, akpm, cl, Krauss, Assaf, johannes, Abbas, Mohamed, netdev On Tue, 2009-09-15 at 16:33 +0800, David Miller wrote: > From: Zhu Yi <yi.zhu@intel.com> > Date: Tue, 15 Sep 2009 16:30:20 +0800 > > > This way, device drivers can allocate the Rx buffers with their own size > > and alignment requirement. i.e. do an order-1 page allocation directly > > with free_pages() in the iwlagn driver for a 256 bytes aligned 8K Rx > > buffer. After DMA is finished, drivers can use the above function to > > assemble an skb based on the Rx buffer. It should resolve the problem > > for requiring an order-2 allocation by alloc_skb() in the first place. > > You can create paged RX skbs just like drivers such as niu.c > and others already do, there is no need for special APIs for > this. Thanks. So we can put the 8K buffer into 2 skb_shinfo()->frags[] slots and set nr_frags to 2, right? Is this supported allover the network code already? At a first glance, I didn't find any frags handling in mac80211 stack. Thanks, -yi ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: alloc skb based on a given data buffer 2009-09-15 8:57 ` Zhu Yi (?) @ 2009-09-15 9:09 ` David Miller 2009-09-15 9:15 ` Zhu Yi -1 siblings, 1 reply; 66+ messages in thread From: David Miller @ 2009-09-15 9:09 UTC (permalink / raw) To: yi.zhu Cc: mel, reinette.chatre, elendil, Larry.Finger, linville, penberg, linux-kernel, linux-wireless, ipw3945-devel, akpm, cl, assaf.krauss, johannes, mohamed.abbas, netdev From: Zhu Yi <yi.zhu@intel.com> Date: Tue, 15 Sep 2009 16:57:29 +0800 > Thanks. So we can put the 8K buffer into 2 skb_shinfo()->frags[] slots > and set nr_frags to 2, right? Is this supported allover the network code > already? At a first glance, I didn't find any frags handling in mac80211 > stack. You have to pre-pull the link level protocol headers into the linear area, but that's it. Again, see niu.c for details, it does: static void niu_rx_skb_append(struct sk_buff *skb, struct page *page, u32 offset, u32 size) { int i = skb_shinfo(skb)->nr_frags; skb_frag_t *frag = &skb_shinfo(skb)->frags[i]; frag->page = page; frag->page_offset = offset; frag->size = size; skb->len += size; skb->data_len += size; skb->truesize += size; skb_shinfo(skb)->nr_frags = i + 1; } to add pages to SKBs and then at the end it goes: skb_reserve(skb, NET_IP_ALIGN); __pskb_pull_tail(skb, min(len, NIU_RXPULL_MAX)); Right before giving the SKB to the networking stack. NIU_RXPULL_MAX should be a value that will be large enough to cover the largest possible link level header. ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: alloc skb based on a given data buffer 2009-09-15 9:09 ` David Miller @ 2009-09-15 9:15 ` Zhu Yi 0 siblings, 0 replies; 66+ messages in thread From: Zhu Yi @ 2009-09-15 9:15 UTC (permalink / raw) To: David Miller Cc: mel, Chatre, Reinette, elendil, Larry.Finger, linville, penberg, linux-kernel, linux-wireless, ipw3945-devel, akpm, cl, Krauss, Assaf, johannes, Abbas, Mohamed, netdev On Tue, 2009-09-15 at 17:09 +0800, David Miller wrote: > From: Zhu Yi <yi.zhu@intel.com> > Date: Tue, 15 Sep 2009 16:57:29 +0800 > > > Thanks. So we can put the 8K buffer into 2 skb_shinfo()->frags[] slots > > and set nr_frags to 2, right? Is this supported allover the network code > > already? At a first glance, I didn't find any frags handling in mac80211 > > stack. > > You have to pre-pull the link level protocol headers into the > linear area, but that's it. > > Again, see niu.c for details, it does: > > static void niu_rx_skb_append(struct sk_buff *skb, struct page *page, > u32 offset, u32 size) > { > int i = skb_shinfo(skb)->nr_frags; > skb_frag_t *frag = &skb_shinfo(skb)->frags[i]; > > frag->page = page; > frag->page_offset = offset; > frag->size = size; > > skb->len += size; > skb->data_len += size; > skb->truesize += size; > > skb_shinfo(skb)->nr_frags = i + 1; > } > > to add pages to SKBs and then at the end it goes: > > skb_reserve(skb, NET_IP_ALIGN); > __pskb_pull_tail(skb, min(len, NIU_RXPULL_MAX)); > > Right before giving the SKB to the networking stack. NIU_RXPULL_MAX > should be a value that will be large enough to cover the largest > possible link level header. I see. Thanks for this info. I'll try implementing the same for iwlagn. Thanks, -yi ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: alloc skb based on a given data buffer @ 2009-09-15 9:15 ` Zhu Yi 0 siblings, 0 replies; 66+ messages in thread From: Zhu Yi @ 2009-09-15 9:15 UTC (permalink / raw) To: David Miller Cc: mel, Chatre, Reinette, elendil, Larry.Finger, linville, penberg, linux-kernel, linux-wireless, ipw3945-devel, akpm, cl, Krauss, Assaf, johannes, Abbas, Mohamed, netdev On Tue, 2009-09-15 at 17:09 +0800, David Miller wrote: > From: Zhu Yi <yi.zhu@intel.com> > Date: Tue, 15 Sep 2009 16:57:29 +0800 > > > Thanks. So we can put the 8K buffer into 2 skb_shinfo()->frags[] slots > > and set nr_frags to 2, right? Is this supported allover the network code > > already? At a first glance, I didn't find any frags handling in mac80211 > > stack. > > You have to pre-pull the link level protocol headers into the > linear area, but that's it. > > Again, see niu.c for details, it does: > > static void niu_rx_skb_append(struct sk_buff *skb, struct page *page, > u32 offset, u32 size) > { > int i = skb_shinfo(skb)->nr_frags; > skb_frag_t *frag = &skb_shinfo(skb)->frags[i]; > > frag->page = page; > frag->page_offset = offset; > frag->size = size; > > skb->len += size; > skb->data_len += size; > skb->truesize += size; > > skb_shinfo(skb)->nr_frags = i + 1; > } > > to add pages to SKBs and then at the end it goes: > > skb_reserve(skb, NET_IP_ALIGN); > __pskb_pull_tail(skb, min(len, NIU_RXPULL_MAX)); > > Right before giving the SKB to the networking stack. NIU_RXPULL_MAX > should be a value that will be large enough to cover the largest > possible link level header. I see. Thanks for this info. I'll try implementing the same for iwlagn. Thanks, -yi ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: alloc skb based on a given data buffer 2009-09-15 9:15 ` Zhu Yi (?) @ 2009-09-15 15:30 ` Johannes Berg -1 siblings, 0 replies; 66+ messages in thread From: Johannes Berg @ 2009-09-15 15:30 UTC (permalink / raw) To: Zhu Yi Cc: David Miller, mel, Chatre, Reinette, elendil, Larry.Finger, linville, penberg, linux-kernel, linux-wireless, ipw3945-devel, akpm, cl, Krauss, Assaf, Abbas, Mohamed, netdev [-- Attachment #1: Type: text/plain, Size: 1581 bytes --] On Tue, 2009-09-15 at 17:15 +0800, Zhu Yi wrote: > On Tue, 2009-09-15 at 17:09 +0800, David Miller wrote: > > From: Zhu Yi <yi.zhu@intel.com> > > Date: Tue, 15 Sep 2009 16:57:29 +0800 > > > > > Thanks. So we can put the 8K buffer into 2 skb_shinfo()->frags[] slots > > > and set nr_frags to 2, right? Is this supported allover the network code > > > already? At a first glance, I didn't find any frags handling in mac80211 > > > stack. > > > > You have to pre-pull the link level protocol headers into the > > linear area, but that's it. > > > > Again, see niu.c for details, it does: > > > > static void niu_rx_skb_append(struct sk_buff *skb, struct page *page, > > u32 offset, u32 size) > > { > > int i = skb_shinfo(skb)->nr_frags; > > skb_frag_t *frag = &skb_shinfo(skb)->frags[i]; > > > > frag->page = page; > > frag->page_offset = offset; > > frag->size = size; > > > > skb->len += size; > > skb->data_len += size; > > skb->truesize += size; > > > > skb_shinfo(skb)->nr_frags = i + 1; > > } > > > > to add pages to SKBs and then at the end it goes: > > > > skb_reserve(skb, NET_IP_ALIGN); > > __pskb_pull_tail(skb, min(len, NIU_RXPULL_MAX)); > > > > Right before giving the SKB to the networking stack. NIU_RXPULL_MAX > > should be a value that will be large enough to cover the largest > > possible link level header. > > I see. Thanks for this info. I'll try implementing the same for iwlagn. Hold, mac80211 can't cope with that at this point for sw crypto and possibly other things. johannes [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 801 bytes --] ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: alloc skb based on a given data buffer @ 2009-09-15 15:30 ` Johannes Berg 0 siblings, 0 replies; 66+ messages in thread From: Johannes Berg @ 2009-09-15 15:30 UTC (permalink / raw) To: Zhu Yi Cc: David Miller, mel-wPRd99KPJ+uzQB+pC5nmwQ, Chatre, Reinette, elendil-EIBgga6/0yRmR6Xm/wNWPw, Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ, linville-2XuSBdqkA4R54TAoqtyWWQ, penberg-bbCR+/B0CizivPeTLB3BmA, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-wireless-u79uwXL29TY76Z2rM5mHXA, ipw3945-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b, cl-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b, Krauss, Assaf, Abbas, Mohamed, netdev-u79uwXL29TY76Z2rM5mHXA [-- Attachment #1: Type: text/plain, Size: 1611 bytes --] On Tue, 2009-09-15 at 17:15 +0800, Zhu Yi wrote: > On Tue, 2009-09-15 at 17:09 +0800, David Miller wrote: > > From: Zhu Yi <yi.zhu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> > > Date: Tue, 15 Sep 2009 16:57:29 +0800 > > > > > Thanks. So we can put the 8K buffer into 2 skb_shinfo()->frags[] slots > > > and set nr_frags to 2, right? Is this supported allover the network code > > > already? At a first glance, I didn't find any frags handling in mac80211 > > > stack. > > > > You have to pre-pull the link level protocol headers into the > > linear area, but that's it. > > > > Again, see niu.c for details, it does: > > > > static void niu_rx_skb_append(struct sk_buff *skb, struct page *page, > > u32 offset, u32 size) > > { > > int i = skb_shinfo(skb)->nr_frags; > > skb_frag_t *frag = &skb_shinfo(skb)->frags[i]; > > > > frag->page = page; > > frag->page_offset = offset; > > frag->size = size; > > > > skb->len += size; > > skb->data_len += size; > > skb->truesize += size; > > > > skb_shinfo(skb)->nr_frags = i + 1; > > } > > > > to add pages to SKBs and then at the end it goes: > > > > skb_reserve(skb, NET_IP_ALIGN); > > __pskb_pull_tail(skb, min(len, NIU_RXPULL_MAX)); > > > > Right before giving the SKB to the networking stack. NIU_RXPULL_MAX > > should be a value that will be large enough to cover the largest > > possible link level header. > > I see. Thanks for this info. I'll try implementing the same for iwlagn. Hold, mac80211 can't cope with that at this point for sw crypto and possibly other things. johannes [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 801 bytes --] ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: alloc skb based on a given data buffer @ 2009-09-15 15:30 ` Johannes Berg 0 siblings, 0 replies; 66+ messages in thread From: Johannes Berg @ 2009-09-15 15:30 UTC (permalink / raw) To: Zhu Yi Cc: David Miller, mel, Chatre, Reinette, elendil, Larry.Finger, linville, penberg, linux-kernel, linux-wireless, ipw3945-devel, akpm, cl, Krauss, Assaf, Abbas, Mohamed, netdev [-- Attachment #1: Type: text/plain, Size: 1581 bytes --] On Tue, 2009-09-15 at 17:15 +0800, Zhu Yi wrote: > On Tue, 2009-09-15 at 17:09 +0800, David Miller wrote: > > From: Zhu Yi <yi.zhu@intel.com> > > Date: Tue, 15 Sep 2009 16:57:29 +0800 > > > > > Thanks. So we can put the 8K buffer into 2 skb_shinfo()->frags[] slots > > > and set nr_frags to 2, right? Is this supported allover the network code > > > already? At a first glance, I didn't find any frags handling in mac80211 > > > stack. > > > > You have to pre-pull the link level protocol headers into the > > linear area, but that's it. > > > > Again, see niu.c for details, it does: > > > > static void niu_rx_skb_append(struct sk_buff *skb, struct page *page, > > u32 offset, u32 size) > > { > > int i = skb_shinfo(skb)->nr_frags; > > skb_frag_t *frag = &skb_shinfo(skb)->frags[i]; > > > > frag->page = page; > > frag->page_offset = offset; > > frag->size = size; > > > > skb->len += size; > > skb->data_len += size; > > skb->truesize += size; > > > > skb_shinfo(skb)->nr_frags = i + 1; > > } > > > > to add pages to SKBs and then at the end it goes: > > > > skb_reserve(skb, NET_IP_ALIGN); > > __pskb_pull_tail(skb, min(len, NIU_RXPULL_MAX)); > > > > Right before giving the SKB to the networking stack. NIU_RXPULL_MAX > > should be a value that will be large enough to cover the largest > > possible link level header. > > I see. Thanks for this info. I'll try implementing the same for iwlagn. Hold, mac80211 can't cope with that at this point for sw crypto and possibly other things. johannes [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 801 bytes --] ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: alloc skb based on a given data buffer @ 2009-09-15 21:16 ` David Miller 0 siblings, 0 replies; 66+ messages in thread From: David Miller @ 2009-09-15 21:16 UTC (permalink / raw) To: johannes Cc: yi.zhu, mel, reinette.chatre, elendil, Larry.Finger, linville, penberg, linux-kernel, linux-wireless, ipw3945-devel, akpm, cl, assaf.krauss, mohamed.abbas, netdev From: Johannes Berg <johannes@sipsolutions.net> Date: Tue, 15 Sep 2009 08:30:31 -0700 > Hold, mac80211 can't cope with that at this point for sw crypto and > possibly other things. Then it should skb_linearize() at input, or similar. ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: alloc skb based on a given data buffer @ 2009-09-15 21:16 ` David Miller 0 siblings, 0 replies; 66+ messages in thread From: David Miller @ 2009-09-15 21:16 UTC (permalink / raw) To: johannes-cdvu00un1VgdHxzADdlk8Q Cc: yi.zhu-ral2JQCrhuEAvxtiuMwx3w, mel-wPRd99KPJ+uzQB+pC5nmwQ, reinette.chatre-ral2JQCrhuEAvxtiuMwx3w, elendil-EIBgga6/0yRmR6Xm/wNWPw, Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ, linville-2XuSBdqkA4R54TAoqtyWWQ, penberg-bbCR+/B0CizivPeTLB3BmA, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-wireless-u79uwXL29TY76Z2rM5mHXA, ipw3945-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b, cl-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b, assaf.krauss-ral2JQCrhuEAvxtiuMwx3w, mohamed.abbas-ral2JQCrhuEAvxtiuMwx3w, netdev-u79uwXL29TY76Z2rM5mHXA From: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> Date: Tue, 15 Sep 2009 08:30:31 -0700 > Hold, mac80211 can't cope with that at this point for sw crypto and > possibly other things. Then it should skb_linearize() at input, or similar. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: alloc skb based on a given data buffer 2009-09-15 21:16 ` David Miller (?) @ 2009-09-19 5:56 ` Johannes Berg -1 siblings, 0 replies; 66+ messages in thread From: Johannes Berg @ 2009-09-19 5:56 UTC (permalink / raw) To: David Miller Cc: yi.zhu, mel, reinette.chatre, elendil, Larry.Finger, linville, penberg, linux-kernel, linux-wireless, ipw3945-devel, akpm, cl, assaf.krauss, mohamed.abbas, netdev [-- Attachment #1: Type: text/plain, Size: 473 bytes --] On Tue, 2009-09-15 at 14:16 -0700, David Miller wrote: > From: Johannes Berg <johannes@sipsolutions.net> > Date: Tue, 15 Sep 2009 08:30:31 -0700 > > > Hold, mac80211 can't cope with that at this point for sw crypto and > > possibly other things. > > Then it should skb_linearize() at input, or similar. Not all that much won then since that again means an order-2 allocation. Fewer, certainly, as most packets are actually much smaller than that. johannes [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 801 bytes --] ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: iwlagn: order 2 page allocation failures 2009-09-14 3:01 ` Zhu Yi @ 2009-09-14 15:42 ` Christoph Lameter -1 siblings, 0 replies; 66+ messages in thread From: Christoph Lameter @ 2009-09-14 15:42 UTC (permalink / raw) To: Zhu Yi Cc: Mel Gorman, Chatre, Reinette, Frans Pop, Larry Finger, John W. Linville, Pekka Enberg, linux-kernel, linux-wireless, ipw3945-devel, Andrew Morton, Krauss, Assaf, Johannes Berg, Abbas, Mohamed On Mon, 14 Sep 2009, Zhu Yi wrote: > BTW, does SLAB/SLUB guarantee size of multiple PAGE_SIZE __kmalloc() > allocation align on PAGE_SIZE (or 256 bytes) boundary? Page allocators guarantee page aligned data. Slab allocators do not. You can create a slab that aligns objects on 256 byte boundary if you want. ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: iwlagn: order 2 page allocation failures @ 2009-09-14 15:42 ` Christoph Lameter 0 siblings, 0 replies; 66+ messages in thread From: Christoph Lameter @ 2009-09-14 15:42 UTC (permalink / raw) To: Zhu Yi Cc: Mel Gorman, Chatre, Reinette, Frans Pop, Larry Finger, John W. Linville, Pekka Enberg, linux-kernel, linux-wireless, ipw3945-devel, Andrew Morton, Krauss, Assaf, Johannes Berg, Abbas, Mohamed On Mon, 14 Sep 2009, Zhu Yi wrote: > BTW, does SLAB/SLUB guarantee size of multiple PAGE_SIZE __kmalloc() > allocation align on PAGE_SIZE (or 256 bytes) boundary? Page allocators guarantee page aligned data. Slab allocators do not. You can create a slab that aligns objects on 256 byte boundary if you want. ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: iwlagn: order 2 page allocation failures 2009-09-14 15:42 ` Christoph Lameter @ 2009-09-14 17:59 ` Mel Gorman -1 siblings, 0 replies; 66+ messages in thread From: Mel Gorman @ 2009-09-14 17:59 UTC (permalink / raw) To: Christoph Lameter Cc: Zhu Yi, Chatre, Reinette, Frans Pop, Larry Finger, John W. Linville, Pekka Enberg, linux-kernel, linux-wireless, ipw3945-devel, Andrew Morton, Krauss, Assaf, Johannes Berg, Abbas, Mohamed On Mon, Sep 14, 2009 at 11:42:15AM -0400, Christoph Lameter wrote: > On Mon, 14 Sep 2009, Zhu Yi wrote: > > > BTW, does SLAB/SLUB guarantee size of multiple PAGE_SIZE __kmalloc() > > allocation align on PAGE_SIZE (or 256 bytes) boundary? > > Page allocators guarantee page aligned data. Slab allocators do not. > > You can create a slab that aligns objects on 256 byte boundary if you > want. > The allocation of buffers >= PAGE_SIZE even when allocated with kmalloc() are page-aligned though right? It's not an explicit guarantee but is it not always the case? -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: iwlagn: order 2 page allocation failures @ 2009-09-14 17:59 ` Mel Gorman 0 siblings, 0 replies; 66+ messages in thread From: Mel Gorman @ 2009-09-14 17:59 UTC (permalink / raw) To: Christoph Lameter Cc: Zhu Yi, Chatre, Reinette, Frans Pop, Larry Finger, John W. Linville, Pekka Enberg, linux-kernel, linux-wireless, ipw3945-devel, Andrew Morton, Krauss, Assaf, Johannes Berg, Abbas, Mohamed On Mon, Sep 14, 2009 at 11:42:15AM -0400, Christoph Lameter wrote: > On Mon, 14 Sep 2009, Zhu Yi wrote: > > > BTW, does SLAB/SLUB guarantee size of multiple PAGE_SIZE __kmalloc() > > allocation align on PAGE_SIZE (or 256 bytes) boundary? > > Page allocators guarantee page aligned data. Slab allocators do not. > > You can create a slab that aligns objects on 256 byte boundary if you > want. > The allocation of buffers >= PAGE_SIZE even when allocated with kmalloc() are page-aligned though right? It's not an explicit guarantee but is it not always the case? -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: iwlagn: order 2 page allocation failures 2009-09-14 17:59 ` Mel Gorman @ 2009-09-14 18:04 ` Christoph Lameter -1 siblings, 0 replies; 66+ messages in thread From: Christoph Lameter @ 2009-09-14 18:04 UTC (permalink / raw) To: Mel Gorman Cc: Zhu Yi, Chatre, Reinette, Frans Pop, Larry Finger, John W. Linville, Pekka Enberg, linux-kernel, linux-wireless, ipw3945-devel, Andrew Morton, Krauss, Assaf, Johannes Berg, Abbas, Mohamed On Mon, 14 Sep 2009, Mel Gorman wrote: > The allocation of buffers >= PAGE_SIZE even when allocated with > kmalloc() are page-aligned though right? It's not an explicit guarantee > but is it not always the case? Its typically the case but debug options may misalign the object. The guarantee for kmalloc caches is to be cacheline aligned. ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: iwlagn: order 2 page allocation failures @ 2009-09-14 18:04 ` Christoph Lameter 0 siblings, 0 replies; 66+ messages in thread From: Christoph Lameter @ 2009-09-14 18:04 UTC (permalink / raw) To: Mel Gorman Cc: Zhu Yi, Chatre, Reinette, Frans Pop, Larry Finger, John W. Linville, Pekka Enberg, linux-kernel, linux-wireless, ipw3945-devel, Andrew Morton, Krauss, Assaf, Johannes Berg, Abbas, Mohamed On Mon, 14 Sep 2009, Mel Gorman wrote: > The allocation of buffers >= PAGE_SIZE even when allocated with > kmalloc() are page-aligned though right? It's not an explicit guarantee > but is it not always the case? Its typically the case but debug options may misalign the object. The guarantee for kmalloc caches is to be cacheline aligned. ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: iwlagn: order 2 page allocation failures 2009-09-09 16:55 ` Mel Gorman 2009-09-09 17:19 ` Frans Pop 2009-09-09 20:05 ` reinette chatre @ 2009-09-10 8:18 ` Pekka Enberg 2009-09-10 12:34 ` Mel Gorman 2 siblings, 1 reply; 66+ messages in thread From: Pekka Enberg @ 2009-09-10 8:18 UTC (permalink / raw) To: Mel Gorman Cc: Frans Pop, Larry Finger, John W. Linville, linux-kernel, linux-wireless, ipw3945-devel, Andrew Morton, cl, Assaf Krauss, Johannes Berg, Mohamed Abbas On Wed, 2009-09-09 at 17:55 +0100, Mel Gorman wrote: > On Wed, Sep 09, 2009 at 05:59:30PM +0200, Frans Pop wrote: > > On Wednesday 09 September 2009, Mel Gorman wrote: > > > Franz, in the full dmesg was there any mention of "SLUB: Unable to > > > allocate memory on node"? > > > > No, nothing at all. I double checked the kernel log, but it was completely > > quiet in the hours before and after the messages I already posted. > > > > Ok, that in itself is unexpected. > > Pekka, it looks from the stack trace that the failure is from > __alloc_skb and I am guessing the failure path is around here > > size = SKB_DATA_ALIGN(size); > data = kmalloc_node_track_caller(size + sizeof(struct skb_shared_info), > gfp_mask, node); > if (!data) > goto nodata; > > Why would the SLUB out-of-memory message not appear? It's hardly > tripping up on printk_ratelimit() is it? That's because it's a large allocation that's passed directly to the page allocator. See kmalloc_large_node(), for example. Pekka ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: iwlagn: order 2 page allocation failures 2009-09-10 8:18 ` Pekka Enberg @ 2009-09-10 12:34 ` Mel Gorman 2009-09-10 12:39 ` Pekka Enberg 0 siblings, 1 reply; 66+ messages in thread From: Mel Gorman @ 2009-09-10 12:34 UTC (permalink / raw) To: Pekka Enberg Cc: Frans Pop, Larry Finger, John W. Linville, linux-kernel, linux-wireless, ipw3945-devel, Andrew Morton, cl, Assaf Krauss, Johannes Berg, Mohamed Abbas On Thu, Sep 10, 2009 at 11:18:42AM +0300, Pekka Enberg wrote: > On Wed, 2009-09-09 at 17:55 +0100, Mel Gorman wrote: > > On Wed, Sep 09, 2009 at 05:59:30PM +0200, Frans Pop wrote: > > > On Wednesday 09 September 2009, Mel Gorman wrote: > > > > Franz, in the full dmesg was there any mention of "SLUB: Unable to > > > > allocate memory on node"? > > > > > > No, nothing at all. I double checked the kernel log, but it was completely > > > quiet in the hours before and after the messages I already posted. > > > > > > > Ok, that in itself is unexpected. > > > > Pekka, it looks from the stack trace that the failure is from > > __alloc_skb and I am guessing the failure path is around here > > > > size = SKB_DATA_ALIGN(size); > > data = kmalloc_node_track_caller(size + sizeof(struct skb_shared_info), > > gfp_mask, node); > > if (!data) > > goto nodata; > > > > Why would the SLUB out-of-memory message not appear? It's hardly > > tripping up on printk_ratelimit() is it? > > That's because it's a large allocation that's passed directly to the > page allocator. See kmalloc_large_node(), for example. > Pants. Is there any chance that could be fixed so that allocation failures within SLUB get consistently reported? -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: iwlagn: order 2 page allocation failures 2009-09-10 12:34 ` Mel Gorman @ 2009-09-10 12:39 ` Pekka Enberg 2009-09-10 12:58 ` Mel Gorman 0 siblings, 1 reply; 66+ messages in thread From: Pekka Enberg @ 2009-09-10 12:39 UTC (permalink / raw) To: Mel Gorman Cc: Frans Pop, Larry Finger, John W. Linville, linux-kernel, linux-wireless, ipw3945-devel, Andrew Morton, cl, Assaf Krauss, Johannes Berg, Mohamed Abbas Hi Mel, On Thu, 2009-09-10 at 13:34 +0100, Mel Gorman wrote: > > That's because it's a large allocation that's passed directly to the > > page allocator. See kmalloc_large_node(), for example. > > Pants. Is there any chance that could be fixed so that allocation > failures within SLUB get consistently reported? Did you have something specific in mind? I am not sure it's worth it, really. The kmalloc_large() function is a static inline in include/linux/slub_def.h that gets inlined nicely to a get_order() + __get_free_pages() pair in the caller for production configs. I'm not sure what we should print either. There's no known "object size" or "buffer size" nor do we any of the variable order things or backing struct kmem_cache_nodes. Pekka ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: iwlagn: order 2 page allocation failures 2009-09-10 12:39 ` Pekka Enberg @ 2009-09-10 12:58 ` Mel Gorman 0 siblings, 0 replies; 66+ messages in thread From: Mel Gorman @ 2009-09-10 12:58 UTC (permalink / raw) To: Pekka Enberg Cc: Frans Pop, Larry Finger, John W. Linville, linux-kernel, linux-wireless, ipw3945-devel, Andrew Morton, cl, Assaf Krauss, Johannes Berg, Mohamed Abbas On Thu, Sep 10, 2009 at 03:39:36PM +0300, Pekka Enberg wrote: > Hi Mel, > > On Thu, 2009-09-10 at 13:34 +0100, Mel Gorman wrote: > > > That's because it's a large allocation that's passed directly to the > > > page allocator. See kmalloc_large_node(), for example. > > > > Pants. Is there any chance that could be fixed so that allocation > > failures within SLUB get consistently reported? > > Did you have something specific in mind? I am not sure it's worth it, > really. > > The kmalloc_large() function is a static inline in > include/linux/slub_def.h that gets inlined nicely to a get_order() + > __get_free_pages() pair in the caller for production configs. I'm not > sure what we should print either. There's no known "object size" or > "buffer size" nor do we any of the variable order things or backing > struct kmem_cache_nodes. > All I had in mind really was to grab the size of the buffer that was passed into kmalloc such as here; void *__kmalloc(size_t size, gfp_t flags) { struct kmem_cache *s; void *ret; if (unlikely(size > SLUB_MAX_SIZE)) return kmalloc_large(size, flags); and to have consistent reporting of slub-allocation failures but if you reckon it's not worth it, I wouldn't push strongly on it. -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab ^ permalink raw reply [flat|nested] 66+ messages in thread
end of thread, other threads:[~2009-09-19 5:56 UTC | newest] Thread overview: 66+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2009-09-06 7:40 iwlagn: order 2 page allocation failures Frans Pop 2009-09-06 8:14 ` Pekka Enberg 2009-09-06 8:28 ` Frans Pop 2009-09-06 8:35 ` Pekka Enberg 2009-09-08 10:54 ` Mel Gorman 2009-09-08 11:11 ` Pekka Enberg 2009-09-08 14:17 ` John W. Linville 2009-09-08 14:59 ` Larry Finger 2009-09-09 15:04 ` Mel Gorman 2009-09-09 15:59 ` Frans Pop 2009-09-09 16:55 ` Mel Gorman 2009-09-09 17:19 ` Frans Pop 2009-09-16 14:36 ` Frans Pop 2009-09-16 15:02 ` Mel Gorman 2009-09-16 15:37 ` Frans Pop 2009-09-16 16:26 ` reinette chatre 2009-09-16 16:26 ` reinette chatre 2009-09-09 20:05 ` reinette chatre 2009-09-09 20:05 ` reinette chatre 2009-09-10 1:48 ` Frans Pop 2009-09-10 1:48 ` Frans Pop 2009-09-10 9:02 ` Mel Gorman 2009-09-10 9:02 ` Mel Gorman 2009-09-10 18:15 ` reinette chatre 2009-09-10 18:15 ` reinette chatre 2009-09-10 18:43 ` Frans Pop 2009-09-10 18:43 ` Frans Pop 2009-09-10 18:50 ` reinette chatre 2009-09-10 18:50 ` reinette chatre 2009-09-11 8:45 ` Mel Gorman 2009-09-11 8:45 ` Mel Gorman 2009-09-11 16:14 ` reinette chatre 2009-09-11 16:14 ` reinette chatre 2009-09-10 21:14 ` reinette chatre 2009-09-10 21:14 ` reinette chatre 2009-09-11 8:47 ` Mel Gorman 2009-09-11 8:47 ` Mel Gorman 2009-09-14 3:01 ` Zhu Yi 2009-09-14 3:01 ` Zhu Yi 2009-09-14 13:06 ` Mel Gorman 2009-09-14 13:06 ` Mel Gorman 2009-09-15 8:30 ` alloc skb based on a given data buffer Zhu Yi 2009-09-15 8:30 ` Zhu Yi 2009-09-15 8:33 ` David Miller 2009-09-15 8:33 ` David Miller 2009-09-15 8:57 ` Zhu Yi 2009-09-15 8:57 ` Zhu Yi 2009-09-15 9:09 ` David Miller 2009-09-15 9:15 ` Zhu Yi 2009-09-15 9:15 ` Zhu Yi 2009-09-15 15:30 ` Johannes Berg 2009-09-15 15:30 ` Johannes Berg 2009-09-15 15:30 ` Johannes Berg 2009-09-15 21:16 ` David Miller 2009-09-15 21:16 ` David Miller 2009-09-19 5:56 ` Johannes Berg 2009-09-14 15:42 ` iwlagn: order 2 page allocation failures Christoph Lameter 2009-09-14 15:42 ` Christoph Lameter 2009-09-14 17:59 ` Mel Gorman 2009-09-14 17:59 ` Mel Gorman 2009-09-14 18:04 ` Christoph Lameter 2009-09-14 18:04 ` Christoph Lameter 2009-09-10 8:18 ` Pekka Enberg 2009-09-10 12:34 ` Mel Gorman 2009-09-10 12:39 ` Pekka Enberg 2009-09-10 12:58 ` Mel Gorman
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.