linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* 3.9-rc1: crash kernel panic - not syncing: Can not allocate SWIOTLB buffer earlier and can't now provide you with the DMA bounce buffer
@ 2013-03-08  5:54 WANG Chao
  2013-03-08  6:03 ` CAI Qian
  0 siblings, 1 reply; 101+ messages in thread
From: WANG Chao @ 2013-03-08  5:54 UTC (permalink / raw)
  To: LKML; +Cc: CAI Qian

Hi, All

On 3.9-rc1, I load crash kernel with latest kexec-tools(up to 28d413a), but
2nd kernel panic at early time:
[    2.948076] Kernel panic - not syncing: Can not allocate SWIOTLB buffer earlier and can't now provide you with the DMA bounce buffer
[    2.959958] Pid: 53, comm: khubd Not tainted 3.9.0-rc1+ #1
[    2.965426] Call Trace:
[    2.967866]  [<ffffffff81619acd>] panic+0xc1/0x1d0
[    2.972644]  [<ffffffff8131e50c>] swiotlb_tbl_map_single+0x27c/0x280
[    2.978991]  [<ffffffff8131ed59>] map_single+0x19/0x20
[    2.984115]  [<ffffffff8131ef1e>] swiotlb_map_page+0x6e/0x160
[    2.989845]  [<ffffffff81447e40>] usb_hcd_map_urb_for_dma+0x230/0x4a0
[    2.996268]  [<ffffffff81448345>] usb_hcd_submit_urb+0x295/0x8e0
[    3.002258]  [<ffffffff8109b90f>] ? __dequeue_entity+0x2f/0x50
[    3.008076]  [<ffffffff8101358e>] ? __switch_to+0x13e/0x4a0
[    3.013632]  [<ffffffff81449a2f>] usb_submit_urb+0xff/0x3d0
[    3.019186]  [<ffffffff816241be>] ? __schedule+0x3de/0x7e0
[    3.024657]  [<ffffffff8144ab6a>] usb_start_wait_urb+0x6a/0x160
[    3.030560]  [<ffffffff81189d15>] ? __kmalloc+0x55/0x210
[    3.035856]  [<ffffffff8144977e>] ? usb_alloc_urb+0x1e/0x50
[    3.041411]  [<ffffffff8144aece>] usb_control_msg+0xde/0x140
[    3.047056]  [<ffffffff81440680>] ? hub_port_init+0x310/0xaf0
[    3.052785]  [<ffffffff8144065b>] ? hub_port_init+0x2eb/0xaf0
[    3.058515]  [<ffffffff814406a8>] hub_port_init+0x338/0xaf0
[    3.064071]  [<ffffffff81407679>] ? update_autosuspend+0x39/0x60
[    3.070062]  [<ffffffff81407759>] ? pm_runtime_set_autosuspend_delay+0x49/0x70
[    3.077264]  [<ffffffff814438ba>] hub_port_connect_change+0x24a/0xaa0
[    3.083684]  [<ffffffff814443fa>] hub_events+0x2ea/0x910
[    3.088981]  [<ffffffff816241be>] ? __schedule+0x3de/0x7e0
[    3.094451]  [<ffffffff81444a55>] hub_thread+0x35/0x1e0
[    3.099661]  [<ffffffff81087480>] ? wake_up_bit+0x40/0x40
[    3.105045]  [<ffffffff81444a20>] ? hub_events+0x910/0x910
[    3.110514]  [<ffffffff81086a70>] kthread+0xc0/0xd0
[    3.115378]  [<ffffffff810869b0>] ? kthread_create_on_node+0x120/0x120
[    3.121887]  [<ffffffff8162e86c>] ret_from_fork+0x7c/0xb0
[    3.127271]  [<ffffffff810869b0>] ? kthread_create_on_node+0x120/0x120


Here's the full log:
# grep 'Crash' /proc/iomem
  146000000-14dffffff : Crash kernel

# dmesg | grep -i reserving
[    0.000000] Reserving 128MB of memory at 5216MB for crashkernel (System RAM: 3977MB)

# kexec -p /boot/vmlinuz-3.9.0-rc1+ --command-line='console=ttyS0,115200n81'
# echo c > /proc/sysrq-trigger

[  217.879315] SysRq : Trigger a crash
[  217.882836] BUG: unable to handle kernel NULL pointer dereference at           (null)
[  217.890674] IP: [<ffffffff813c19a6>] sysrq_handle_crash+0x16/0x20
[  217.896773] PGD 13df22067 PUD 139726067 PMD 0
[  217.901244] Oops: 0002 [#1] SMP
[  217.904491] Modules linked in: lockd sunrpc nf_conntrack_netbios_ns nf_conntrack_broadcast ipt_MASQUERADE ip6table_mangle ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 iptable_nat nf_nat_ip
v4 nf_nat iptable_mangle ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter ip_tables sg coretemp kvm_inte
l kvm e1000e iTCO_wdt crc32c_intel iTCO_vendor_support ptp ghash_clmulni_intel pps_core mei microcode pcspkr i2c_i801 lpc_ich mfd_core xfs libcrc32c sr_mod sd_mod cdrom crc_t10dif i915 i2c_al
go_bit drm_kms_helper drm ahci libahci libata i2c_core video dm_mirror dm_region_hash dm_log dm_mod
[  217.963690] CPU 0
[  217.965526] Pid: 1206, comm: bash Not tainted 3.9.0-rc1+ #1 Intel Corporation 2012 Client Platform/Emerald Lake 2
[  217.975948] RIP: 0010:[<ffffffff813c19a6>]  [<ffffffff813c19a6>] sysrq_handle_crash+0x16/0x20
[  217.984468] RSP: 0018:ffff8801367e9e38  EFLAGS: 00010092
[  217.989765] RAX: 000000000000000f RBX: ffffffff819b67c0 RCX: ffff88014e20ffe8
[  217.996881] RDX: 0000000000000000 RSI: ffff88014e20e3b8 RDI: 0000000000000063
[  218.003998] RBP: ffff8801367e9e38 R08: ffffffff81c06280 R09: 0000000000000419
[  218.011113] R10: 0000000000000002 R11: 0000000000000418 R12: 0000000000000063
[  218.018230] R13: 0000000000000286 R14: 0000000000000000 R15: 0000000000000007
[  218.025346] FS:  00007fdd48ace740(0000) GS:ffff88014e200000(0000) knlGS:0000000000000000
[  218.033416] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  218.039147] CR2: 0000000000000000 CR3: 000000013a67c000 CR4: 00000000001407f0
[  218.046263] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  218.053379] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[  218.060496] Process bash (pid: 1206, threadinfo ffff8801367e8000, task ffff88013e8ae5c0)
[  218.068564] Stack:
[  218.070570]  ffff8801367e9e78 ffffffff813c2147 ffff88013e8ae5c0 0000000000000002
[  218.078001]  ffff88013c4f9200 00007fdd48ad1000 0000000000000002 ffff8801367e9f50
[  218.085427]  ffff8801367e9ea8 ffffffff813c21fa ffff88013c4f9200 00007fdd48ad1000
[  218.092854] Call Trace:
[  218.095298]  [<ffffffff813c2147>] __handle_sysrq+0x127/0x190
[  218.100947]  [<ffffffff813c21fa>] write_sysrq_trigger+0x4a/0x50
[  218.106854]  [<ffffffff812064d5>] proc_reg_write+0x75/0xb0
[  218.112329]  [<ffffffff811a1d2c>] vfs_write+0xac/0x180
[  218.117456]  [<ffffffff811a2072>] sys_write+0x52/0xa0
[  218.122499]  [<ffffffff8162a23e>] ? do_page_fault+0xe/0x10
[  218.127977]  [<ffffffff8162e919>] system_call_fastpath+0x16/0x1b
[  218.133970] Code: 89 ef e8 ee f7 ff ff eb c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 0f 1f 44 00 00 55 c7 05 64 44 84 00 01 00 00 00 48 89 e5 0f ae f8 <c6> 04 25 00 00 00 00 01 5d c3 0f 1f 44 
00 00 55 48 89 e5 53 48
[  218.153653] RIP  [<ffffffff813c19a6>] sysrq_handle_crash+0x16/0x20
[  218.159834]  RSP <ffff8801367e9e38>
[  218.163311] CR2: 0000000000000000
I'm in purgatory
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 3.9.0-rc1+ (root@localhost) (gcc version 4.7.2 20121109 (Red Hat 4.7.2-8) (GCC) ) #1 SMP Wed Mar 6 23:38:21 EST 2013
[    0.000000] Command line: console=ttyS0,115200n81 memmap=exactmap memmap=615K@4K memmap=130432K@5341184K elfcorehdr=5471616K memmap=2560K#2799016K memmap=84K#2801576K
[    0.000000] e820: BIOS-provided physical RAM map:
[    0.000000] BIOS-e820: [mem 0x0000000000000100-0x000000000009abff] usable
[    0.000000] BIOS-e820: [mem 0x000000000009ac00-0x000000000009ffff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000000e0000-0x00000000000fffff] reserved
[    0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000001fffffff] usable
[    0.000000] BIOS-e820: [mem 0x0000000020000000-0x00000000201fffff] reserved
[    0.000000] BIOS-e820: [mem 0x0000000020200000-0x0000000040003fff] usable
[    0.000000] BIOS-e820: [mem 0x0000000040004000-0x0000000040004fff] reserved
[    0.000000] BIOS-e820: [mem 0x0000000040005000-0x00000000a8aaefff] usable
[    0.000000] BIOS-e820: [mem 0x00000000a8aaf000-0x00000000a8af1fff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000a8af2000-0x00000000aa5c3fff] usable
[    0.000000] BIOS-e820: [mem 0x00000000aa5c4000-0x00000000aad69fff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000aad6a000-0x00000000aafe9fff] ACPI NVS
[    0.000000] BIOS-e820: [mem 0x00000000aafea000-0x00000000aaffefff] ACPI data
[    0.000000] BIOS-e820: [mem 0x00000000aafff000-0x00000000aaffffff] usable
[    0.000000] BIOS-e820: [mem 0x00000000ab000000-0x00000000af9fffff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000f8000000-0x00000000fbffffff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000fec00000-0x00000000fec00fff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000fed10000-0x00000000fed13fff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000fed18000-0x00000000fed19fff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000fed1c000-0x00000000fed1ffff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000fee00000-0x00000000fee00fff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000ff900000-0x00000000ffbfffff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000ffd00000-0x00000000ffffffff] reserved
[    0.000000] BIOS-e820: [mem 0x0000000100000000-0x000000014e5fffff] usable
[    0.000000] e820: last_pfn = 0x14e600 max_arch_pfn = 0x400000000
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] e820: user-defined physical RAM map:
[    0.000000] user: [mem 0x0000000000001000-0x000000000009abff] usable
[    0.000000] user: [mem 0x00000000aad6a000-0x00000000aaffefff] ACPI data
[    0.000000] user: [mem 0x0000000146000000-0x000000014df5ffff] usable
[    0.000000] SMBIOS 2.6 present.
[    0.000000] No AGP bridge found
[    0.000000] e820: last_pfn = 0x14df60 max_arch_pfn = 0x400000000
[    0.000000] x86 PAT enabled: cpu 0, old 0x7010600070106, new 0x7010600070106
[    0.000000] total RAM covered: 3990M
[    0.000000]  gran_size: 64K  chunk_size: 64K         num_reg: 10     lose cover RAM: 2M
[    0.000000]  gran_size: 64K  chunk_size: 128K        num_reg: 10     lose cover RAM: 2M
[    0.000000]  gran_size: 64K  chunk_size: 256K        num_reg: 10     lose cover RAM: 2M
[    0.000000]  gran_size: 64K  chunk_size: 512K        num_reg: 10     lose cover RAM: 2M
[    0.000000]  gran_size: 64K  chunk_size: 1M  num_reg: 10     lose cover RAM: 2M
[    0.000000]  gran_size: 64K  chunk_size: 2M  num_reg: 10     lose cover RAM: 2M
[    0.000000] *BAD*gran_size: 64K      chunk_size: 4M  num_reg: 10     lose cover RAM: -2M
[    0.000000] *BAD*gran_size: 64K      chunk_size: 8M  num_reg: 10     lose cover RAM: -2M
[    0.000000] *BAD*gran_size: 64K      chunk_size: 16M         num_reg: 10     lose cover RAM: -10M
[    0.000000]  gran_size: 64K  chunk_size: 32M         num_reg: 10     lose cover RAM: 0G
[    0.000000]  gran_size: 64K  chunk_size: 64M         num_reg: 10     lose cover RAM: 0G
[    0.000000]  gran_size: 64K  chunk_size: 128M        num_reg: 10     lose cover RAM: 0G
[    0.000000]  gran_size: 64K  chunk_size: 256M        num_reg: 10     lose cover RAM: 0G
[    0.000000] *BAD*gran_size: 64K      chunk_size: 512M        num_reg: 10     lose cover RAM: -256M
[    0.000000] *BAD*gran_size: 64K      chunk_size: 1G  num_reg: 10     lose cover RAM: -512M
[    0.000000] *BAD*gran_size: 64K      chunk_size: 2G  num_reg: 10     lose cover RAM: -512M
[    0.000000]  gran_size: 128K         chunk_size: 128K        num_reg: 10     lose cover RAM: 2M
[    0.000000]  gran_size: 128K         chunk_size: 256K        num_reg: 10     lose cover RAM: 2M
[    0.000000]  gran_size: 128K         chunk_size: 512K        num_reg: 10     lose cover RAM: 2M
[    0.000000]  gran_size: 128K         chunk_size: 1M  num_reg: 10     lose cover RAM: 2M
[    0.000000]  gran_size: 128K         chunk_size: 2M  num_reg: 10     lose cover RAM: 2M
[    0.000000] *BAD*gran_size: 128K     chunk_size: 4M  num_reg: 10     lose cover RAM: -2M
[    0.000000] *BAD*gran_size: 128K     chunk_size: 8M  num_reg: 10     lose cover RAM: -2M
[    0.000000] *BAD*gran_size: 128K     chunk_size: 16M         num_reg: 10     lose cover RAM: -10M
[    0.000000]  gran_size: 128K         chunk_size: 32M         num_reg: 10     lose cover RAM: 0G
[    0.000000]  gran_size: 128K         chunk_size: 64M         num_reg: 10     lose cover RAM: 0G
[    0.000000]  gran_size: 128K         chunk_size: 128M        num_reg: 10     lose cover RAM: 0G
[    0.000000]  gran_size: 128K         chunk_size: 256M        num_reg: 10     lose cover RAM: 0G
[    0.000000] *BAD*gran_size: 128K     chunk_size: 512M        num_reg: 10     lose cover RAM: -256M
[    0.000000] *BAD*gran_size: 128K     chunk_size: 1G  num_reg: 10     lose cover RAM: -512M
[    0.000000] *BAD*gran_size: 128K     chunk_size: 2G  num_reg: 10     lose cover RAM: -512M
[    0.000000]  gran_size: 256K         chunk_size: 256K        num_reg: 10     lose cover RAM: 2M
[    0.000000]  gran_size: 256K         chunk_size: 512K        num_reg: 10     lose cover RAM: 2M
[    0.000000]  gran_size: 256K         chunk_size: 1M  num_reg: 10     lose cover RAM: 2M
[    0.000000]  gran_size: 256K         chunk_size: 2M  num_reg: 10     lose cover RAM: 2M
[    0.000000] *BAD*gran_size: 256K     chunk_size: 4M  num_reg: 10     lose cover RAM: -2M
[    0.000000] *BAD*gran_size: 256K     chunk_size: 8M  num_reg: 10     lose cover RAM: -2M
[    0.000000] *BAD*gran_size: 256K     chunk_size: 16M         num_reg: 10     lose cover RAM: -10M
[    0.000000]  gran_size: 256K         chunk_size: 32M         num_reg: 10     lose cover RAM: 0G
[    0.000000]  gran_size: 256K         chunk_size: 64M         num_reg: 10     lose cover RAM: 0G
[    0.000000]  gran_size: 256K         chunk_size: 128M        num_reg: 10     lose cover RAM: 0G
[    0.000000]  gran_size: 256K         chunk_size: 256M        num_reg: 10     lose cover RAM: 0G
[    0.000000] *BAD*gran_size: 256K     chunk_size: 512M        num_reg: 10     lose cover RAM: -256M
[    0.000000] *BAD*gran_size: 256K     chunk_size: 1G  num_reg: 10     lose cover RAM: -512M
[    0.000000] *BAD*gran_size: 256K     chunk_size: 2G  num_reg: 10     lose cover RAM: -512M
[    0.000000]  gran_size: 512K         chunk_size: 512K        num_reg: 10     lose cover RAM: 2M
[    0.000000]  gran_size: 512K         chunk_size: 1M  num_reg: 10     lose cover RAM: 2M
[    0.000000]  gran_size: 512K         chunk_size: 2M  num_reg: 10     lose cover RAM: 2M
[    0.000000] *BAD*gran_size: 512K     chunk_size: 4M  num_reg: 10     lose cover RAM: -2M
[    0.000000] *BAD*gran_size: 512K     chunk_size: 8M  num_reg: 10     lose cover RAM: -2M
[    0.000000] *BAD*gran_size: 512K     chunk_size: 16M         num_reg: 10     lose cover RAM: -10M
[    0.000000]  gran_size: 512K         chunk_size: 32M         num_reg: 10     lose cover RAM: 0G
[    0.000000]  gran_size: 512K         chunk_size: 64M         num_reg: 10     lose cover RAM: 0G
[    0.000000]  gran_size: 512K         chunk_size: 128M        num_reg: 10     lose cover RAM: 0G
[    0.000000]  gran_size: 512K         chunk_size: 256M        num_reg: 10     lose cover RAM: 0G
[    0.000000] *BAD*gran_size: 512K     chunk_size: 512M        num_reg: 10     lose cover RAM: -256M
[    0.000000] *BAD*gran_size: 512K     chunk_size: 1G  num_reg: 10     lose cover RAM: -512M
[    0.000000] *BAD*gran_size: 512K     chunk_size: 2G  num_reg: 10     lose cover RAM: -512M
[    0.000000]  gran_size: 1M   chunk_size: 1M  num_reg: 10     lose cover RAM: 2M
[    0.000000]  gran_size: 1M   chunk_size: 2M  num_reg: 10     lose cover RAM: 2M
[    0.000000] *BAD*gran_size: 1M       chunk_size: 4M  num_reg: 10     lose cover RAM: -2M
[    0.000000] *BAD*gran_size: 1M       chunk_size: 8M  num_reg: 10     lose cover RAM: -2M
[    0.000000] *BAD*gran_size: 1M       chunk_size: 16M         num_reg: 10     lose cover RAM: -10M
[    0.000000]  gran_size: 1M   chunk_size: 32M         num_reg: 10     lose cover RAM: 0G
[    0.000000]  gran_size: 1M   chunk_size: 64M         num_reg: 10     lose cover RAM: 0G
[    0.000000]  gran_size: 1M   chunk_size: 128M        num_reg: 10     lose cover RAM: 0G
[    0.000000]  gran_size: 1M   chunk_size: 256M        num_reg: 10     lose cover RAM: 0G
[    0.000000] *BAD*gran_size: 1M       chunk_size: 512M        num_reg: 10     lose cover RAM: -256M
[    0.000000] *BAD*gran_size: 1M       chunk_size: 1G  num_reg: 10     lose cover RAM: -512M
[    0.000000] *BAD*gran_size: 1M       chunk_size: 2G  num_reg: 10     lose cover RAM: -512M
[    0.000000]  gran_size: 2M   chunk_size: 2M  num_reg: 10     lose cover RAM: 2M
[    0.000000] *BAD*gran_size: 2M       chunk_size: 4M  num_reg: 10     lose cover RAM: -2M
[    0.000000] *BAD*gran_size: 2M       chunk_size: 8M  num_reg: 10     lose cover RAM: -2M
[    0.000000] *BAD*gran_size: 2M       chunk_size: 16M         num_reg: 10     lose cover RAM: -10M
[    0.000000]  gran_size: 2M   chunk_size: 32M         num_reg: 10     lose cover RAM: 0G
[    0.000000]  gran_size: 2M   chunk_size: 64M         num_reg: 10     lose cover RAM: 0G
[    0.000000]  gran_size: 2M   chunk_size: 128M        num_reg: 10     lose cover RAM: 0G
[    0.000000]  gran_size: 2M   chunk_size: 256M        num_reg: 10     lose cover RAM: 0G
[    0.000000] *BAD*gran_size: 2M       chunk_size: 512M        num_reg: 10     lose cover RAM: -256M
[    0.000000] *BAD*gran_size: 2M       chunk_size: 1G  num_reg: 10     lose cover RAM: -512M
[    0.000000] *BAD*gran_size: 2M       chunk_size: 2G  num_reg: 10     lose cover RAM: -512M
[    0.000000]  gran_size: 4M   chunk_size: 4M  num_reg: 10     lose cover RAM: 2M
[    0.000000] *BAD*gran_size: 4M       chunk_size: 8M  num_reg: 10     lose cover RAM: -2M
[    0.000000] *BAD*gran_size: 4M       chunk_size: 16M         num_reg: 10     lose cover RAM: -10M
[    0.000000]  gran_size: 4M   chunk_size: 32M         num_reg: 10     lose cover RAM: 2M
[    0.000000]  gran_size: 4M   chunk_size: 64M         num_reg: 10     lose cover RAM: 2M
[    0.000000]  gran_size: 4M   chunk_size: 128M        num_reg: 10     lose cover RAM: 2M
[    0.000000]  gran_size: 4M   chunk_size: 256M        num_reg: 10     lose cover RAM: 2M
[    0.000000] *BAD*gran_size: 4M       chunk_size: 512M        num_reg: 10     lose cover RAM: -254M
[    0.000000] *BAD*gran_size: 4M       chunk_size: 1G  num_reg: 10     lose cover RAM: -510M
[    0.000000] *BAD*gran_size: 4M       chunk_size: 2G  num_reg: 10     lose cover RAM: -510M
[    0.000000]  gran_size: 8M   chunk_size: 8M  num_reg: 9      lose cover RAM: 6M
[    0.000000]  gran_size: 8M   chunk_size: 16M         num_reg: 9      lose cover RAM: 6M
[    0.000000]  gran_size: 8M   chunk_size: 32M         num_reg: 9      lose cover RAM: 6M
[    0.000000]  gran_size: 8M   chunk_size: 64M         num_reg: 8      lose cover RAM: 6M
[    0.000000]  gran_size: 8M   chunk_size: 128M        num_reg: 8      lose cover RAM: 6M
[    0.000000]  gran_size: 8M   chunk_size: 256M        num_reg: 8      lose cover RAM: 6M
[    0.000000]  gran_size: 8M   chunk_size: 512M        num_reg: 9      lose cover RAM: 6M
[    0.000000]  gran_size: 8M   chunk_size: 1G  num_reg: 9      lose cover RAM: 6M
[    0.000000]  gran_size: 8M   chunk_size: 2G  num_reg: 9      lose cover RAM: 6M
[    0.000000]  gran_size: 16M  chunk_size: 16M         num_reg: 9      lose cover RAM: 6M
[    0.000000]  gran_size: 16M  chunk_size: 32M         num_reg: 9      lose cover RAM: 6M
[    0.000000]  gran_size: 16M  chunk_size: 64M         num_reg: 8      lose cover RAM: 6M
[    0.000000]  gran_size: 16M  chunk_size: 128M        num_reg: 8      lose cover RAM: 6M
[    0.000000]  gran_size: 16M  chunk_size: 256M        num_reg: 8      lose cover RAM: 6M
[    0.000000]  gran_size: 16M  chunk_size: 512M        num_reg: 9      lose cover RAM: 6M
[    0.000000]  gran_size: 16M  chunk_size: 1G  num_reg: 9      lose cover RAM: 6M
[    0.000000]  gran_size: 16M  chunk_size: 2G  num_reg: 9      lose cover RAM: 6M
[    0.000000]  gran_size: 32M  chunk_size: 32M         num_reg: 8      lose cover RAM: 22M
[    0.000000]  gran_size: 32M  chunk_size: 64M         num_reg: 8      lose cover RAM: 22M
[    0.000000]  gran_size: 32M  chunk_size: 128M        num_reg: 8      lose cover RAM: 22M
[    0.000000]  gran_size: 32M  chunk_size: 256M        num_reg: 8      lose cover RAM: 22M
[    0.000000]  gran_size: 32M  chunk_size: 512M        num_reg: 9      lose cover RAM: 22M
[    0.000000]  gran_size: 32M  chunk_size: 1G  num_reg: 9      lose cover RAM: 22M
[    0.000000]  gran_size: 32M  chunk_size: 2G  num_reg: 9      lose cover RAM: 22M
[    0.000000]  gran_size: 64M  chunk_size: 64M         num_reg: 6      lose cover RAM: 86M
[    0.000000]  gran_size: 64M  chunk_size: 128M        num_reg: 6      lose cover RAM: 86M
[    0.000000]  gran_size: 64M  chunk_size: 256M        num_reg: 7      lose cover RAM: 86M
[    0.000000]  gran_size: 64M  chunk_size: 512M        num_reg: 8      lose cover RAM: 86M
[    0.000000]  gran_size: 64M  chunk_size: 1G  num_reg: 8      lose cover RAM: 86M
[    0.000000]  gran_size: 64M  chunk_size: 2G  num_reg: 8      lose cover RAM: 86M
[    0.000000]  gran_size: 128M         chunk_size: 128M        num_reg: 5      lose cover RAM: 150M
[    0.000000]  gran_size: 128M         chunk_size: 256M        num_reg: 7      lose cover RAM: 150M
[    0.000000]  gran_size: 128M         chunk_size: 512M        num_reg: 8      lose cover RAM: 150M
[    0.000000]  gran_size: 128M         chunk_size: 1G  num_reg: 8      lose cover RAM: 150M
[    0.000000]  gran_size: 128M         chunk_size: 2G  num_reg: 8      lose cover RAM: 150M
[    0.000000]  gran_size: 256M         chunk_size: 256M        num_reg: 3      lose cover RAM: 406M
[    0.000000]  gran_size: 256M         chunk_size: 512M        num_reg: 3      lose cover RAM: 406M
[    0.000000]  gran_size: 256M         chunk_size: 1G  num_reg: 4      lose cover RAM: 406M
[    0.000000]  gran_size: 256M         chunk_size: 2G  num_reg: 4      lose cover RAM: 406M
[    0.000000]  gran_size: 512M         chunk_size: 512M        num_reg: 3      lose cover RAM: 406M
[    0.000000]  gran_size: 512M         chunk_size: 1G  num_reg: 4      lose cover RAM: 406M
[    0.000000]  gran_size: 512M         chunk_size: 2G  num_reg: 4      lose cover RAM: 406M
[    0.000000]  gran_size: 1G   chunk_size: 1G  num_reg: 2      lose cover RAM: 918M
[    0.000000]  gran_size: 1G   chunk_size: 2G  num_reg: 2      lose cover RAM: 918M
[    0.000000]  gran_size: 2G   chunk_size: 2G  num_reg: 1      lose cover RAM: 1942M
[    0.000000] mtrr_cleanup: can not find optimal value
[    0.000000] please specify mtrr_gran_size/mtrr_chunk_size
[    0.000000] x2apic enabled by BIOS, switching to x2apic ops
[    0.000000] e820: last_pfn = 0x9a max_arch_pfn = 0x400000000
[    0.000000] found SMP MP-table at [mem 0x000fc9f0-0x000fc9ff] mapped at [ffff8800000fc9f0]
[    0.000000] init_memory_mapping: [mem 0x00000000-0x000fffff]
[    0.000000] init_memory_mapping: [mem 0x14de00000-0x14df5ffff]
[    0.000000] init_memory_mapping: [mem 0x14c000000-0x14ddfffff]
[    0.000000] init_memory_mapping: [mem 0x146000000-0x14bffffff]
[    0.000000] ACPI: RSDP 00000000000f0410 00024 (v02  INTEL)
[    0.000000] ACPI: XSDT 00000000aaffde18 00074 (v01  INTEL  IVB-PPT 06222004 MSFT 00010013)
[    0.000000] ACPI: FACP 00000000aafe3d98 000F4 (v04  INTEL  IVB-PPT 06222004 MSFT 00010013)
[    0.000000] ACPI: DSDT 00000000aafbe018 0FD25 (v02  INTEL  IVB-PPT 00000000 INTL 20110623)
[    0.000000] ACPI: FACS 00000000aafe9e40 00040
[    0.000000] ACPI: APIC 00000000aaffcf18 000CC (v02  INTEL  IVB-PPT 06222004 MSFT 00010013)
[    0.000000] ACPI: HPET 00000000aafe8f18 00038 (v01 A M I   PCHHPET 06222004 AMI. 00000003)
[    0.000000] ACPI: SSDT 00000000aafe5018 010A8 (v01 TrmRef PtidDevc 00001000 INTL 20110623)
[    0.000000] ACPI: SSDT 00000000aafe4a18 00461 (v01    AMI PerfTune 00001000 INTL 20110623)
[    0.000000] ACPI: MCFG 00000000aafe8e98 0003C (v01 INTEL  SNDYBRDG 06222004 MSFT 00000097)
[    0.000000] ACPI: SSDT 00000000aafd2018 009AA (v01  PmRef  Cpu0Ist 00003000 INTL 20110623)
[    0.000000] ACPI: SSDT 00000000aafd1018 00A92 (v01  PmRef    CpuPm 00003000 INTL 20110623)
[    0.000000] ACPI: DMAR 00000000aafe4f18 000B8 (v01 INTEL      SNB  00000001 INTL 00000001)
[    0.000000] ACPI: FPDT 00000000aaff4018 00064 (v01  INTEL  IVB-CPT 00010000 INTL 20111107)
[    0.000000] Setting APIC routing to cluster x2apic.
[    0.000000] No NUMA configuration found
[    0.000000] Faking a node at [mem 0x0000000000000000-0x000000014df5ffff]
[    0.000000] Initmem setup node 0 [mem 0x00000000-0x14df5ffff]
[    0.000000]   NODE_DATA [mem 0x14df39000-0x14df5ffff]
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x00001000-0x00ffffff]
[    0.000000]   DMA32    [mem 0x01000000-0xffffffff]
[    0.000000]   Normal   [mem 0x100000000-0x14df5ffff]
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x00001000-0x00099fff]
[    0.000000]   node   0: [mem 0x146000000-0x14df5ffff]
[    0.000000] ACPI: PM-Timer IO Port: 0x408
[    0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x04] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x05] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x06] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x08] lapic_id[0x07] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x09] lapic_id[0x08] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x09] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x0a] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x0b] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x0c] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x0d] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0f] lapic_id[0x0e] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x10] lapic_id[0x0f] disabled)
[    0.000000] ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
[    0.000000] IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[    0.000000] Using ACPI (MADT) for SMP configuration information
[    0.000000] ACPI: HPET id: 0x8086a701 base: 0xfed00000
[    0.000000] smpboot: Allowing 16 CPUs, 8 hotplug CPUs
[    0.000000] PM: Registered nosave memory: 000000000009a000 - 00000000aad6a000
[    0.000000] PM: Registered nosave memory: 00000000aad6a000 - 00000000aafff000
[    0.000000] PM: Registered nosave memory: 00000000aafff000 - 0000000146000000
[    0.000000] e820: [mem 0x0009ac00-0xaad69fff] available for PCI devices
[    0.000000] Booting paravirtualized kernel on bare hardware
[    0.000000] setup_percpu: NR_CPUS:4096 nr_cpumask_bits:16 nr_cpu_ids:16 nr_node_ids:1
[    0.000000] PERCPU: Embedded 29 pages/cpu @ffff88014dc00000 s86272 r8192 d24320 u131072
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 32227
[    0.000000] Policy zone: Normal
[    0.000000] Kernel command line: console=ttyS0,115200n81 memmap=exactmap memmap=615K@4K memmap=130432K@5341184K elfcorehdr=5471616K memmap=2560K#2799016K memmap=84K#2801576K
[    0.000000] PID hash table entries: 512 (order: 0, 4096 bytes)
[    0.000000] __ex_table already sorted, skipping sort
[    0.000000] xsave: enabled xstate_bv 0x7, cntxt size 0x340
[    0.000000] Cannot allocate SWIOTLB buffer
[    0.000000] Checking aperture...
[    0.000000] No AGP bridge found
[    0.000000] Memory: 108184k/5471616k available (6346k kernel code, 5340572k absent, 22860k reserved, 3983k data, 1484k init)
[    0.000000] SLUB: Genslabs=15, HWalign=64, Order=0-3, MinObjects=0, CPUs=16, Nodes=1
[    0.000000] Hierarchical RCU implementation.
[    0.000000]  RCU restricting CPUs from NR_CPUS=4096 to nr_cpu_ids=16.
[    0.000000] NR_IRQS:262400 nr_irqs:808 16
[    0.000000] Spurious LAPIC timer interrupt on cpu 0
[    0.000000] Console: colour VGA+ 80x25
[    0.000000] console [ttyS0] enabled
[    0.000000] allocated 1572864 bytes of page_cgroup
[    0.000000] please try 'cgroup_disable=memory' option if you don't want memory cgroups
[    0.001000] tsc: Fast TSC calibration using PIT
[    0.002000] tsc: Detected 2593.881 MHz processor
[    0.000005] Calibrating delay loop (skipped), value calculated using timer frequency.. 5187.76 BogoMIPS (lpj=2593881)
[    0.010628] pid_max: default: 32768 minimum: 301
[    0.015311] Security Framework initialized
[    0.019418] SELinux:  Initializing.
[    0.023012] Dentry cache hash table entries: 16384 (order: 5, 131072 bytes)
[    0.030043] Inode-cache hash table entries: 8192 (order: 4, 65536 bytes)
[    0.036777] Mount-cache hash table entries: 256
[    0.041629] Initializing cgroup subsys cpuacct
[    0.046079] Initializing cgroup subsys memory
[    0.050447] Initializing cgroup subsys devices
[    0.054891] Initializing cgroup subsys freezer
[    0.059335] Initializing cgroup subsys net_cls
[    0.063777] Initializing cgroup subsys blkio
[    0.068045] Initializing cgroup subsys perf_event
[    0.072794] CPU: Physical Processor ID: 0
[    0.076806] CPU: Processor Core ID: 0
[    0.081210] mce: CPU supports 9 MCE banks
[    0.085254] Last level iTLB entries: 4KB 512, 2MB 0, 4MB 0
[    0.085254] Last level dTLB entries: 4KB 512, 2MB 32, 4MB 32
[    0.085254] tlb_flushall_shift: 1
[    0.099844] Freeing SMP alternatives: 24k freed
[    0.106487] ACPI: Core revision 20130117
[    0.122586] ACPI: All ACPI Tables successfully acquired
[    0.127868] ftrace: allocating 23601 entries in 93 pages
[    0.154031] dmar: Host address width 36
[    0.157876] dmar: DRHD base: 0x000000fed90000 flags: 0x0
[    0.163194] dmar: IOMMU 0: reg_base_addr fed90000 ver 1:0 cap c0000020e60262 ecap f0101a
[    0.171277] dmar: DRHD base: 0x000000fed91000 flags: 0x1
[    0.176590] dmar: IOMMU 1: reg_base_addr fed91000 ver 1:0 cap c9008020660262 ecap f010da
[    0.184672] dmar: RMRR base: 0x000000aac95000 end: 0x000000aacb2fff
[    0.190934] dmar: RMRR base: 0x000000ab800000 end: 0x000000af9fffff
[    0.197268] IOAPIC id 2 under DRHD base  0xfed91000 IOMMU 1
[    0.202825] HPET id 0 under DRHD base 0xfed91000
[    0.207714] Enabled IRQ remapping in x2apic mode
[    0.212866] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
[    0.228870] smpboot: CPU0: Intel(R) Core(TM) i7-3720QM CPU @ 2.60GHz (fam: 06, model: 3a, stepping: 09)
[    0.238319] Performance Events: PEBS fmt1+, 16-deep LBR, IvyBridge events, Broken BIOS detected, complain to your hardware vendor.
[    0.250098] [Firmware Bug]: the BIOS has corrupted hw-PMU resources (MSR 38d is b0)
[    0.257739] Intel PMU driver.
[    0.260701] ... version:                3
[    0.264704] ... bit width:              48
[    0.268790] ... generic registers:      4
[    0.272791] ... value mask:             0000ffffffffffff
[    0.278092] ... max period:             000000007fffffff
[    0.283391] ... fixed-purpose events:   3
[    0.287391] ... event mask:             000000070000000f
[    0.294917] smpboot: Booting Node   0, Processors  #1[    0.314489] NMI watchdog: enabled on all CPUs, permanently consumes one hw-PMU counter.
 #2 #3 #4 #5 #6 #7
[    0.408750] Brought up 8 CPUs
[    0.411901] smpboot: Total of 8 processors activated (41502.09 BogoMIPS)
[    0.432134] devtmpfs: initialized
[    0.437882] atomic64 test passed for x86-64 platform with CX8 and with SSE
[    0.444833] NET: Registered protocol family 16
[    0.449455] ACPI FADT declares the system doesn't support PCIe ASPM, so disable it
[    0.457010] ACPI: bus type pci registered
[    0.461122] PCI: MMCONFIG for domain 0000 [bus 00-3f] at [mem 0xf8000000-0xfbffffff] (base 0xf8000000)
[    0.470411] PCI: not using MMCONFIG
[    0.473897] PCI: Using configuration type 1 for base access
[    0.480792] bio: create slab <bio-0> at 0
[    0.484937] ACPI: Added _OSI(Module Device)
[    0.489116] ACPI: Added _OSI(Processor Device)
[    0.493554] ACPI: Added _OSI(3.0 _SCP Extensions)
[    0.498254] ACPI: Added _OSI(Processor Aggregator Device)
[    0.509686] ACPI: Executed 1 blocks of module-level executable AML code
[    0.529844] ACPI: SSDT 00000000aaccd018 00A4F (v01  PmRef  Cpu0Cst 00003001 INTL 20110623)
[    0.538912] ACPI: Dynamic OEM Table Load:
[    0.542947] ACPI: SSDT           (null) 00A4F (v01  PmRef  Cpu0Cst 00003001 INTL 20110623)
[    0.556403] ACPI: SSDT 00000000aaccea98 00303 (v01  PmRef    ApIst 00003000 INTL 20110623)
[    0.565515] ACPI: Dynamic OEM Table Load:
[    0.569549] ACPI: SSDT           (null) 00303 (v01  PmRef    ApIst 00003000 INTL 20110623)
[    0.582778] ACPI: SSDT 00000000aacccd98 00119 (v01  PmRef    ApCst 00003000 INTL 20110623)
[    0.591819] ACPI: Dynamic OEM Table Load:
[    0.595855] ACPI: SSDT           (null) 00119 (v01  PmRef    ApCst 00003000 INTL 20110623)
[    1.418743] ACPI: Interpreter enabled
[    1.422408] ACPI: (supports S0 S1ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\\_S2_] (20130117/hwxface-568)
[    1.433515]  S3 S4 S5)
[    1.435935] ACPI: Using IOAPIC for interrupt routing
[    1.440920] PCI: MMCONFIG for domain 0000 [bus 00-3f] at [mem 0xf8000000-0xfbffffff] (base 0xf8000000)
[    1.451100] PCI: MMCONFIG at [mem 0xf8000000-0xfbffffff] reserved in ACPI motherboard resources
[    1.464742] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
[    1.488550] ACPI: Power Resource [FN00] (off)
[    1.493020] ACPI: Power Resource [FN01] (off)
[    1.497481] ACPI: Power Resource [FN02] (on)
[    1.502241] ACPI: Power Resource [FN03] (on)
[    1.506935] ACPI: Power Resource [FN04] (on)
[    1.512503] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-3e])
[    1.519005] acpi PNP0A08:00: ACPI _OSC support notification failed, disabling PCIe ASPM
[    1.526995] acpi PNP0A08:00: Unable to request _OSC control (_OSC support mask: 0x08)
[    1.535557] PCI host bridge to bus 0000:00
[    1.539653] pci_bus 0000:00: root bus resource [bus 00-3e]
[    1.545132] pci_bus 0000:00: root bus resource [io  0x0000-0x0cf7]
[    1.551304] pci_bus 0000:00: root bus resource [io  0x0d00-0xffff]
[    1.557474] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff]
[    1.564338] pci_bus 0000:00: root bus resource [mem 0x000d0000-0x000d3fff]
[    1.571201] pci_bus 0000:00: root bus resource [mem 0x000d4000-0x000d7fff]
[    1.578064] pci_bus 0000:00: root bus resource [mem 0x000d8000-0x000dbfff]
[    1.584923] pci_bus 0000:00: root bus resource [mem 0x000dc000-0x000dffff]
[    1.591784] pci_bus 0000:00: root bus resource [mem 0x000e0000-0x000e3fff]
[    1.598644] pci_bus 0000:00: root bus resource [mem 0x000e4000-0x000e7fff]
[    1.605503] pci_bus 0000:00: root bus resource [mem 0xafa00000-0xfeafffff]
[    1.613008] pci 0000:00:14.0: System wakeup disabled by ACPI
[    1.619582] pci 0000:00:19.0: System wakeup disabled by ACPI
[    1.625584] pci 0000:00:1a.0: System wakeup disabled by ACPI
[    1.631518] pci 0000:00:1c.0: System wakeup disabled by ACPI
[    1.637463] pci 0000:00:1c.6: System wakeup disabled by ACPI
[    1.643459] pci 0000:00:1d.0: System wakeup disabled by ACPI
[    1.650069] pci 0000:00:1c.0: PCI bridge to [bus 01]
[    1.655146] pci 0000:00:1c.6: PCI bridge to [bus 02-09]
[    1.660411] ACPI _OSC control for PCIe not granted, disabling ASPM
[    1.668220] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 10 *11 12 14 15), disabled.
[    1.676298] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 10 11 12 14 15) *0, disabled.
[    1.684560] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 10 *11 12 14 15), disabled.
[    1.692628] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 *10 11 12 14 15), disabled.
[    1.700698] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 *5 6 10 11 12 14 15), disabled.
[    1.708765] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 10 11 12 14 15) *0, disabled.
[    1.717023] ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 10 11 12 14 15) *0, disabled.
[    1.725280] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 *10 11 12 14 15), disabled.
[    1.733756] ACPI: Enabled 5 GPEs in block 00 to 3F
[    1.738777] ACPI: EC: GPE = 0x17, I/O: command/status = 0x66, data = 0x62
[    1.746393] ACPI: ACPI Dock Station Driver: 1 docks/bays found
[    1.752307] vgaarb: device added: PCI:0000:00:02.0,decodes=io+mem,owns=io+mem,locks=none
[    1.760387] vgaarb: loaded
[    1.763093] vgaarb: bridge control possible 0000:00:02.0
[    1.768498] SCSI subsystem initialized
[    1.772270] ACPI: bus type usb registered
[    1.776297] usbcore: registered new interface driver usbfs
[    1.781783] usbcore: registered new interface driver hub
[    1.787122] usbcore: registered new device driver usb
[    1.792242] PCI: Using ACPI for IRQ routing
[    1.800410] NetLabel: Initializing
[    1.803809] NetLabel:  domain hash size = 128
[    1.808159] NetLabel:  protocols = UNLABELED CIPSOv4
[    1.813125] NetLabel:  unlabeled traffic allowed by default
[    1.818736] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0, 0, 0, 0, 0, 0
[    1.825032] hpet0: 8 comparators, 64-bit 14.318180 MHz counter
[    1.832871] Switching to clocksource hpet
[    1.845000] pnp: PnP ACPI init
[    1.848089] ACPI: bus type pnp registered
[    1.852490] system 00:00: [io  0x06a4] has been reserved
[    1.857802] system 00:00: [io  0x06a0] has been reserved
[    1.863449] system 00:05: [io  0x0680-0x069f] has been reserved
[    1.869370] system 00:05: [io  0x1004-0x1013] has been reserved
[    1.875291] system 00:05: [io  0xffff] has been reserved
[    1.880604] system 00:05: [io  0xffff] has been reserved
[    1.885918] system 00:05: [io  0x0400-0x0453] has been reserved
[    1.891836] system 00:05: [io  0x0458-0x047f] has been reserved
[    1.897754] system 00:05: [io  0x0500-0x057f] has been reserved
[    1.903673] system 00:05: [io  0x164e-0x164f] has been reserved
[    1.909718] system 00:07: [io  0x0454-0x0457] has been reserved
[    1.916807] system 00:0b: [mem 0xfed1c000-0xfed1ffff] has been reserved
[    1.923425] system 00:0b: [mem 0xfed10000-0xfed17fff] has been reserved
[    1.930043] system 00:0b: [mem 0xfed18000-0xfed18fff] has been reserved
[    1.936656] system 00:0b: [mem 0xfed19000-0xfed19fff] has been reserved
[    1.943267] system 00:0b: [mem 0xf8000000-0xfbffffff] has been reserved
[    1.949879] system 00:0b: [mem 0xfed20000-0xfed3ffff] has been reserved
[    1.956492] system 00:0b: [mem 0xfed90000-0xfed93fff] could not be reserved
[    1.963449] system 00:0b: [mem 0xfed45000-0xfed8ffff] has been reserved
[    1.970062] system 00:0b: [mem 0xff000000-0xffffffff] has been reserved
[    1.976677] system 00:0b: [mem 0xfee00000-0xfeefffff] has been reserved
[    1.983292] system 00:0b: [mem 0xafa00000-0xafa00fff] has been reserved
[    1.990474] system 00:0c: [mem 0x00000000-0x0009cfff] could not be reserved
[    1.997547] system 00:0d: [mem 0x20000000-0x201fffff] has been reserved
[    2.004160] system 00:0d: [mem 0x40004000-0x40004fff] has been reserved
[    2.010844] pnp: PnP ACPI: found 14 devices
[    2.015025] ACPI: ACPI bus type pnp unregistered
[    2.027290] pci 0000:00:1c.0: PCI bridge to [bus 01]
[    2.032277] pci 0000:00:1c.6: PCI bridge to [bus 02-09]
[    2.037501] pci 0000:00:1c.6:   bridge window [io  0x2000-0x5fff]
[    2.043599] pci 0000:00:1c.6:   bridge window [mem 0xb0000000-0xb10fffff]
[    2.050391] pci 0000:00:1c.6:   bridge window [mem 0xd0000000-0xd10fffff 64bit pref]
[    2.058446] NET: Registered protocol family 2
[    2.063068] TCP established hash table entries: 1024 (order: 2, 16384 bytes)
[    2.070133] TCP bind hash table entries: 1024 (order: 2, 16384 bytes)
[    2.076578] TCP: Hash tables configured (established 1024 bind 1024)
[    2.082996] TCP: reno registered
[    2.086255] UDP hash table entries: 256 (order: 1, 8192 bytes)
[    2.092092] UDP-Lite hash table entries: 256 (order: 1, 8192 bytes)
[    2.098509] NET: Registered protocol family 1
[    2.103710] PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
[    2.110160] software IO TLB: No low mem
[    2.116187] alg: No test for __gcm-aes-aesni (__driver-gcm-aes-aesni)
[    2.123111] Initialise module verification
[    2.127274] audit: initializing netlink socket (disabled)
[    2.132684] type=2000 audit(1362698281.479:1): initialized
[    2.185575] HugeTLB registered 2 MB page size, pre-allocated 0 pages
[    2.193943] VFS: Disk quotas dquot_6.5.2
[    2.197950] Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[    2.205330] msgmni has been set to 211
[    2.210287] alg: No test for stdrng (krng)
[    2.214402] NET: Registered protocol family 38
[    2.218851] Key type asymmetric registered
[    2.222951] Asymmetric key parser 'x509' registered
[    2.227888] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 252)
[    2.235322] io scheduler noop registered
[    2.239247] io scheduler deadline registered (default)
[    2.244403] io scheduler cfq registered
[    2.248531] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
[    2.254132] pciehp: PCI Express Hot Plug Controller Driver version: 0.4
[    2.260741] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
[    2.267305] acpiphp_glue: can't evaluate _ADR (0x5)
[    2.272577] ACPI: AC Adapter [ADP1] (on-line)
[    2.277080] input: Lid Switch as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0D:00/input/input0
[    2.285391] ACPI: Lid Switch [LID0]
[    2.288954] input: Power Button as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input1
[    2.297299] ACPI: Power Button [PWRB]
[    2.301017] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input2
[    2.308410] ACPI: Power Button [PWRF]
[    2.312155] ACPI: Fan [FAN0] (off)
[    2.315615] ACPI: Fan [FAN1] (off)
[    2.319067] ACPI: Fan [FAN2] (on)
[    2.322435] ACPI: Fan [FAN3] (on)
[    2.325793] ACPI: Fan [FAN4] (on)
[    2.329202] ACPI: Requesting acpi_cpufreq
[    2.340021] thermal LNXTHERM:00: registered as thermal_zone0
[    2.345688] ACPI: Thermal Zone [TZ00] (32 C)
[    2.351008] thermal LNXTHERM:01: registered as thermal_zone1
[    2.356672] ACPI: Thermal Zone [TZ01] (33 C)
[    2.364912] GHES: HEST is not enabled!
[    2.365203] ACPI: Battery Slot [BAT0] (battery present)
[    2.365238] ACPI: Battery Slot [BAT1] (battery absent)
[    2.365350] ACPI: Battery Slot [BAT2] (battery absent)
[    2.384217] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[    2.411446] 00:08: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[    2.438082] serial8250: ttyS2 at I/O 0x3e8 (irq = 4) is a 16550A
[    2.464897] 0000:00:16.3: ttyS1 at I/O 0x60e0 (irq = 19) is a 16550A
[    2.471729] Non-volatile memory driver v1.3
[    2.475917] Linux agpgart interface v0.103
[    2.481169] loop: module loaded
[    2.484342] rdac: device handler registered
[    2.488599] hp_sw: device handler registered
[    2.492869] emc: device handler registered
[    2.496970] alua: device handler registered
[    2.501205] libphy: Fixed MDIO Bus: probed
[    2.505370] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    2.511893] ehci-pci: EHCI PCI platform driver
[    2.516470] ehci-pci 0000:00:1a.0: EHCI Host Controller
[    2.521763] ehci-pci 0000:00:1a.0: new USB bus registered, assigned bus number 1
[    2.529178] ehci-pci 0000:00:1a.0: debug port 2
[    2.537665] ehci-pci 0000:00:1a.0: irq 16, io mem 0xb1160000
[    2.548387] ehci-pci 0000:00:1a.0: USB 2.0 started, EHCI 1.00
[    2.554157] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[    2.560941] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    2.568161] usb usb1: Product: EHCI Host Controller
[    2.573041] usb usb1: Manufacturer: Linux 3.9.0-rc1+ ehci_hcd
[    2.578784] usb usb1: SerialNumber: 0000:00:1a.0
[    2.583547] hub 1-0:1.0: USB hub found
[    2.587305] hub 1-0:1.0: 3 ports detected
[    2.591639] ehci-pci 0000:00:1d.0: EHCI Host Controller
[    2.596930] ehci-pci 0000:00:1d.0: new USB bus registered, assigned bus number 2
[    2.604343] ehci-pci 0000:00:1d.0: debug port 2
[    2.612811] ehci-pci 0000:00:1d.0: irq 23, io mem 0xb1150000
[    2.624437] ehci-pci 0000:00:1d.0: USB 2.0 started, EHCI 1.00
[    2.630204] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002
[    2.636987] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    2.644206] usb usb2: Product: EHCI Host Controller
[    2.649084] usb usb2: Manufacturer: Linux 3.9.0-rc1+ ehci_hcd
[    2.654830] usb usb2: SerialNumber: 0000:00:1d.0
[    2.659586] hub 2-0:1.0: USB hub found
[    2.663345] hub 2-0:1.0: 3 ports detected
[    2.667593] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[    2.673792] uhci_hcd: USB Universal Host Controller Interface driver
[    2.680291] xhci_hcd 0000:00:14.0: xHCI Host Controller
[    2.685578] xhci_hcd 0000:00:14.0: new USB bus registered, assigned bus number 3
[    2.693119] xhci_hcd 0000:00:14.0: irq 16, io mem 0xb11a0000
[    2.698942] usb usb3: New USB device found, idVendor=1d6b, idProduct=0002
[    2.705729] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    2.712948] usb usb3: Product: xHCI Host Controller
[    2.717823] usb usb3: Manufacturer: Linux 3.9.0-rc1+ xhci_hcd
[    2.723564] usb usb3: SerialNumber: 0000:00:14.0
[    2.728328] hub 3-0:1.0: USB hub found
[    2.732094] hub 3-0:1.0: 4 ports detected
[    2.736783] xhci_hcd 0000:00:14.0: xHCI Host Controller
[    2.742078] xhci_hcd 0000:00:14.0: new USB bus registered, assigned bus number 4
[    2.749514] usb usb4: New USB device found, idVendor=1d6b, idProduct=0003
[    2.756299] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    2.763516] usb usb4: Product: xHCI Host Controller
[    2.768400] usb usb4: Manufacturer: Linux 3.9.0-rc1+ xhci_hcd
[    2.774148] usb usb4: SerialNumber: 0000:00:14.0
[    2.778964] hub 4-0:1.0: USB hub found
[    2.782737] hub 4-0:1.0: 4 ports detected
[    2.791587] usbcore: registered new interface driver usbserial
[    2.797430] usbcore: registered new interface driver usbserial_generic
[    2.803956] usbserial: USB Serial support registered for generic
[    2.810001] i8042: PNP: PS/2 Controller [PNP0303:PS2K] at 0x60,0x64 irq 1
[    2.816782] i8042: PNP: PS/2 appears to have AUX port disabled, if this is incorrect please boot with i8042.nopnp
[    2.827473] serio: i8042 KBD port at 0x60,0x64 irq 1
[    2.832534] mousedev: PS/2 mouse device common for all mice
[    2.838423] rtc_cmos 00:06: RTC can wake from S4
[    2.843292] rtc_cmos 00:06: rtc core: registered rtc_cmos as rtc0
[    2.849434] rtc_cmos 00:06: alarms up to one month, y3k, 242 bytes nvram, hpet irqs
[    2.857324] cpuidle: using governor ladder
[    2.861761] cpuidle: using governor menu
[    2.866158] EFI Variables Facility v0.08 2004-May-17
[    2.871140] hidraw: raw HID events driver (C) Jiri Kosina
[    2.873905] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input3
[    2.885248] usbcore: registered new interface driver usbhid
[    2.890818] usbhid: USB HID core driver
[    2.894647] usb 1-1: new high-speed USB device number 2 using ehci-pci
[    2.894695] drop_monitor: Initializing network drop monitor service
[    2.894813] TCP: cubic registered
[    2.894815] Initializing XFRM netlink socket
[    2.894988] NET: Registered protocol family 10
[    2.895269] NET: Registered protocol family 17
[    2.895770] Loading module verification certificates
[    2.897372] MODSIGN: Loaded cert 'Magrathea: Glacier signing key: b14fa6fba81316fe0bb193bbf458deba6d430978'
[    2.897384] registered taskstats version 1
[    2.897388] IMA: No TPM chip found, activating TPM-bypass!
[    2.948076] Kernel panic - not syncing: Can not allocate SWIOTLB buffer earlier and can't now provide you with the DMA bounce buffer
[    2.959958] Pid: 53, comm: khubd Not tainted 3.9.0-rc1+ #1
[    2.965426] Call Trace:
[    2.967866]  [<ffffffff81619acd>] panic+0xc1/0x1d0
[    2.972644]  [<ffffffff8131e50c>] swiotlb_tbl_map_single+0x27c/0x280
[    2.978991]  [<ffffffff8131ed59>] map_single+0x19/0x20
[    2.984115]  [<ffffffff8131ef1e>] swiotlb_map_page+0x6e/0x160
[    2.989845]  [<ffffffff81447e40>] usb_hcd_map_urb_for_dma+0x230/0x4a0
[    2.996268]  [<ffffffff81448345>] usb_hcd_submit_urb+0x295/0x8e0
[    3.002258]  [<ffffffff8109b90f>] ? __dequeue_entity+0x2f/0x50
[    3.008076]  [<ffffffff8101358e>] ? __switch_to+0x13e/0x4a0
[    3.013632]  [<ffffffff81449a2f>] usb_submit_urb+0xff/0x3d0
[    3.019186]  [<ffffffff816241be>] ? __schedule+0x3de/0x7e0
[    3.024657]  [<ffffffff8144ab6a>] usb_start_wait_urb+0x6a/0x160
[    3.030560]  [<ffffffff81189d15>] ? __kmalloc+0x55/0x210
[    3.035856]  [<ffffffff8144977e>] ? usb_alloc_urb+0x1e/0x50
[    3.041411]  [<ffffffff8144aece>] usb_control_msg+0xde/0x140
[    3.047056]  [<ffffffff81440680>] ? hub_port_init+0x310/0xaf0
[    3.052785]  [<ffffffff8144065b>] ? hub_port_init+0x2eb/0xaf0
[    3.058515]  [<ffffffff814406a8>] hub_port_init+0x338/0xaf0
[    3.064071]  [<ffffffff81407679>] ? update_autosuspend+0x39/0x60
[    3.070062]  [<ffffffff81407759>] ? pm_runtime_set_autosuspend_delay+0x49/0x70
[    3.077264]  [<ffffffff814438ba>] hub_port_connect_change+0x24a/0xaa0
[    3.083684]  [<ffffffff814443fa>] hub_events+0x2ea/0x910
[    3.088981]  [<ffffffff816241be>] ? __schedule+0x3de/0x7e0
[    3.094451]  [<ffffffff81444a55>] hub_thread+0x35/0x1e0
[    3.099661]  [<ffffffff81087480>] ? wake_up_bit+0x40/0x40
[    3.105045]  [<ffffffff81444a20>] ? hub_events+0x910/0x910
[    3.110514]  [<ffffffff81086a70>] kthread+0xc0/0xd0
[    3.115378]  [<ffffffff810869b0>] ? kthread_create_on_node+0x120/0x120
[    3.121887]  [<ffffffff8162e86c>] ret_from_fork+0x7c/0xb0
[    3.127271]  [<ffffffff810869b0>] ? kthread_create_on_node+0x120/0x120

-- 
Thanks,
WANG Chao

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: 3.9-rc1: crash kernel panic - not syncing: Can not allocate SWIOTLB buffer earlier and can't now provide you with the DMA bounce buffer
  2013-03-08  5:54 3.9-rc1: crash kernel panic - not syncing: Can not allocate SWIOTLB buffer earlier and can't now provide you with the DMA bounce buffer WANG Chao
@ 2013-03-08  6:03 ` CAI Qian
  2013-03-08  6:32   ` Yinghai Lu
  0 siblings, 1 reply; 101+ messages in thread
From: CAI Qian @ 2013-03-08  6:03 UTC (permalink / raw)
  To: LKML, kexec 
  Cc: Dave Young, Vivek Goyal, Yinghai Lu, H. Peter Anvin, WANG Chao

CC'ing kexec ML. Also mentioned that 3.8 has no such issue.

This message looks suspicious and out of range while 3.8 reservation
looks within the range.

[    0.000000] Reserving 128MB of memory at 5216MB for crashkernel
(System RAM: 3977MB)

Wondering if anything to do with memblock again...

CAI Qian

----- Original Message -----
> From: "WANG Chao" <chaowang@redhat.com>
> To: "LKML" vger.kernel.org>
> Cc: "CAI Qian" <caiqian@redhat.com>
> Sent: Friday, March 8, 2013 1:54:37 PM
> Subject: 3.9-rc1: crash kernel panic - not syncing: Can not allocate SWIOTLB buffer earlier and can't now provide you
> with the DMA bounce buffer
> 
> Hi, All
> 
> On 3.9-rc1, I load crash kernel with latest kexec-tools(up to
> 28d413a), but
> 2nd kernel panic at early time:
> [    2.948076] Kernel panic - not syncing: Can not allocate SWIOTLB
> buffer earlier and can't now provide you with the DMA bounce buffer
> [    2.959958] Pid: 53, comm: khubd Not tainted 3.9.0-rc1+ #1
> [    2.965426] Call Trace:
> [    2.967866]  [] panic+0xc1/0x1d0
> [    2.972644]  []
> swiotlb_tbl_map_single+0x27c/0x280
> [    2.978991]  [] map_single+0x19/0x20
> [    2.984115]  [] swiotlb_map_page+0x6e/0x160
> [    2.989845]  []
> usb_hcd_map_urb_for_dma+0x230/0x4a0
> [    2.996268]  [] usb_hcd_submit_urb+0x295/0x8e0
> [    3.002258]  [] ? __dequeue_entity+0x2f/0x50
> [    3.008076]  [] ? __switch_to+0x13e/0x4a0
> [    3.013632]  [] usb_submit_urb+0xff/0x3d0
> [    3.019186]  [] ? __schedule+0x3de/0x7e0
> [    3.024657]  [] usb_start_wait_urb+0x6a/0x160
> [    3.030560]  [] ? __kmalloc+0x55/0x210
> [    3.035856]  [] ? usb_alloc_urb+0x1e/0x50
> [    3.041411]  [] usb_control_msg+0xde/0x140
> [    3.047056]  [] ? hub_port_init+0x310/0xaf0
> [    3.052785]  [] ? hub_port_init+0x2eb/0xaf0
> [    3.058515]  [] hub_port_init+0x338/0xaf0
> [    3.064071]  [] ? update_autosuspend+0x39/0x60
> [    3.070062]  [] ?
> pm_runtime_set_autosuspend_delay+0x49/0x70
> [    3.077264]  []
> hub_port_connect_change+0x24a/0xaa0
> [    3.083684]  [] hub_events+0x2ea/0x910
> [    3.088981]  [] ? __schedule+0x3de/0x7e0
> [    3.094451]  [] hub_thread+0x35/0x1e0
> [    3.099661]  [] ? wake_up_bit+0x40/0x40
> [    3.105045]  [] ? hub_events+0x910/0x910
> [    3.110514]  [] kthread+0xc0/0xd0
> [    3.115378]  [] ?
> kthread_create_on_node+0x120/0x120
> [    3.121887]  [] ret_from_fork+0x7c/0xb0
> [    3.127271]  [] ?
> kthread_create_on_node+0x120/0x120
> 
> 
> Here's the full log:
> # grep 'Crash' /proc/iomem
>   146000000-14dffffff : Crash kernel
> 
> # dmesg | grep -i reserving
> [    0.000000] Reserving 128MB of memory at 5216MB for crashkernel
> (System RAM: 3977MB)
> 
> # kexec -p /boot/vmlinuz-3.9.0-rc1+
> --command-line='console=ttyS0,115200n81'
> # echo c > /proc/sysrq-trigger
> 
> [  217.879315] SysRq : Trigger a crash
> [  217.882836] BUG: unable to handle kernel NULL pointer dereference
> at           (null)
> [  217.890674] IP: [] sysrq_handle_crash+0x16/0x20
> [  217.896773] PGD 13df22067 PUD 139726067 PMD 0
> [  217.901244] Oops: 0002 [#1] SMP
> [  217.904491] Modules linked in: lockd sunrpc
> nf_conntrack_netbios_ns nf_conntrack_broadcast ipt_MASQUERADE
> ip6table_mangle ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6
> iptable_nat nf_nat_ip
> v4 nf_nat iptable_mangle ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4
> xt_conntrack nf_conntrack ebtable_filter ebtables ip6table_filter
> ip6_tables iptable_filter ip_tables sg coretemp kvm_inte
> l kvm e1000e iTCO_wdt crc32c_intel iTCO_vendor_support ptp
> ghash_clmulni_intel pps_core mei microcode pcspkr i2c_i801 lpc_ich
> mfd_core xfs libcrc32c sr_mod sd_mod cdrom crc_t10dif i915 i2c_al
> go_bit drm_kms_helper drm ahci libahci libata i2c_core video
> dm_mirror dm_region_hash dm_log dm_mod
> [  217.963690] CPU 0
> [  217.965526] Pid: 1206, comm: bash Not tainted 3.9.0-rc1+ #1 Intel
> Corporation 2012 Client Platform/Emerald Lake 2
> [  217.975948] RIP: 0010:[]  []
> sysrq_handle_crash+0x16/0x20
> [  217.984468] RSP: 0018:ffff8801367e9e38  EFLAGS: 00010092
> [  217.989765] RAX: 000000000000000f RBX: ffffffff819b67c0 RCX:
> ffff88014e20ffe8
> [  217.996881] RDX: 0000000000000000 RSI: ffff88014e20e3b8 RDI:
> 0000000000000063
> [  218.003998] RBP: ffff8801367e9e38 R08: ffffffff81c06280 R09:
> 0000000000000419
> [  218.011113] R10: 0000000000000002 R11: 0000000000000418 R12:
> 0000000000000063
> [  218.018230] R13: 0000000000000286 R14: 0000000000000000 R15:
> 0000000000000007
> [  218.025346] FS:  00007fdd48ace740(0000) GS:ffff88014e200000(0000)
> knlGS:0000000000000000
> [  218.033416] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [  218.039147] CR2: 0000000000000000 CR3: 000000013a67c000 CR4:
> 00000000001407f0
> [  218.046263] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
> 0000000000000000
> [  218.053379] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
> 0000000000000400
> [  218.060496] Process bash (pid: 1206, threadinfo ffff8801367e8000,
> task ffff88013e8ae5c0)
> [  218.068564] Stack:
> [  218.070570]  ffff8801367e9e78 ffffffff813c2147 ffff88013e8ae5c0
> 0000000000000002
> [  218.078001]  ffff88013c4f9200 00007fdd48ad1000 0000000000000002
> ffff8801367e9f50
> [  218.085427]  ffff8801367e9ea8 ffffffff813c21fa ffff88013c4f9200
> 00007fdd48ad1000
> [  218.092854] Call Trace:
> [  218.095298]  [] __handle_sysrq+0x127/0x190
> [  218.100947]  [] write_sysrq_trigger+0x4a/0x50
> [  218.106854]  [] proc_reg_write+0x75/0xb0
> [  218.112329]  [] vfs_write+0xac/0x180
> [  218.117456]  [] sys_write+0x52/0xa0
> [  218.122499]  [] ? do_page_fault+0xe/0x10
> [  218.127977]  [] system_call_fastpath+0x16/0x1b
> [  218.133970] Code: 89 ef e8 ee f7 ff ff eb c3 66 2e 0f 1f 84 00 00
> 00 00 00 66 90 0f 1f 44 00 00 55 c7 05 64 44 84 00 01 00 00 00 48 89
> e5 0f ae f8  04 25 00 00 00 00 01 5d c3 0f 1f 44
> 00 00 55 48 89 e5 53 48
> [  218.153653] RIP  [] sysrq_handle_crash+0x16/0x20
> [  218.159834]  RSP 
> [  218.163311] CR2: 0000000000000000
> I'm in purgatory
> [    0.000000] Initializing cgroup subsys cpuset
> [    0.000000] Initializing cgroup subsys cpu
> [    0.000000] Linux version 3.9.0-rc1+ (root@localhost) (gcc version
> 4.7.2 20121109 (Red Hat 4.7.2-8) (GCC) ) #1 SMP Wed Mar 6 23:38:21
> EST 2013
> [    0.000000] Command line: console=ttyS0,115200n81 memmap=exactmap
> memmap=615K@4K memmap=130432K@5341184K elfcorehdr=5471616K
> memmap=2560K#2799016K memmap=84K#2801576K
> [    0.000000] e820: BIOS-provided physical RAM map:
> [    0.000000] BIOS-e820: [mem 0x0000000000000100-0x000000000009abff]
> usable
> [    0.000000] BIOS-e820: [mem 0x000000000009ac00-0x000000000009ffff]
> reserved
> [    0.000000] BIOS-e820: [mem 0x00000000000e0000-0x00000000000fffff]
> reserved
> [    0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000001fffffff]
> usable
> [    0.000000] BIOS-e820: [mem 0x0000000020000000-0x00000000201fffff]
> reserved
> [    0.000000] BIOS-e820: [mem 0x0000000020200000-0x0000000040003fff]
> usable
> [    0.000000] BIOS-e820: [mem 0x0000000040004000-0x0000000040004fff]
> reserved
> [    0.000000] BIOS-e820: [mem 0x0000000040005000-0x00000000a8aaefff]
> usable
> [    0.000000] BIOS-e820: [mem 0x00000000a8aaf000-0x00000000a8af1fff]
> reserved
> [    0.000000] BIOS-e820: [mem 0x00000000a8af2000-0x00000000aa5c3fff]
> usable
> [    0.000000] BIOS-e820: [mem 0x00000000aa5c4000-0x00000000aad69fff]
> reserved
> [    0.000000] BIOS-e820: [mem 0x00000000aad6a000-0x00000000aafe9fff]
> ACPI NVS
> [    0.000000] BIOS-e820: [mem 0x00000000aafea000-0x00000000aaffefff]
> ACPI data
> [    0.000000] BIOS-e820: [mem 0x00000000aafff000-0x00000000aaffffff]
> usable
> [    0.000000] BIOS-e820: [mem 0x00000000ab000000-0x00000000af9fffff]
> reserved
> [    0.000000] BIOS-e820: [mem 0x00000000f8000000-0x00000000fbffffff]
> reserved
> [    0.000000] BIOS-e820: [mem 0x00000000fec00000-0x00000000fec00fff]
> reserved
> [    0.000000] BIOS-e820: [mem 0x00000000fed10000-0x00000000fed13fff]
> reserved
> [    0.000000] BIOS-e820: [mem 0x00000000fed18000-0x00000000fed19fff]
> reserved
> [    0.000000] BIOS-e820: [mem 0x00000000fed1c000-0x00000000fed1ffff]
> reserved
> [    0.000000] BIOS-e820: [mem 0x00000000fee00000-0x00000000fee00fff]
> reserved
> [    0.000000] BIOS-e820: [mem 0x00000000ff900000-0x00000000ffbfffff]
> reserved
> [    0.000000] BIOS-e820: [mem 0x00000000ffd00000-0x00000000ffffffff]
> reserved
> [    0.000000] BIOS-e820: [mem 0x0000000100000000-0x000000014e5fffff]
> usable
> [    0.000000] e820: last_pfn = 0x14e600 max_arch_pfn = 0x400000000
> [    0.000000] NX (Execute Disable) protection: active
> [    0.000000] e820: user-defined physical RAM map:
> [    0.000000] user: [mem 0x0000000000001000-0x000000000009abff]
> usable
> [    0.000000] user: [mem 0x00000000aad6a000-0x00000000aaffefff] ACPI
> data
> [    0.000000] user: [mem 0x0000000146000000-0x000000014df5ffff]
> usable
> [    0.000000] SMBIOS 2.6 present.
> [    0.000000] No AGP bridge found
> [    0.000000] e820: last_pfn = 0x14df60 max_arch_pfn = 0x400000000
> [    0.000000] x86 PAT enabled: cpu 0, old 0x7010600070106, new
> 0x7010600070106
> [    0.000000] total RAM covered: 3990M
> [    0.000000]  gran_size: 64K  chunk_size: 64K         num_reg: 10
>     lose cover RAM: 2M
> [    0.000000]  gran_size: 64K  chunk_size: 128K        num_reg: 10
>     lose cover RAM: 2M
> [    0.000000]  gran_size: 64K  chunk_size: 256K        num_reg: 10
>     lose cover RAM: 2M
> [    0.000000]  gran_size: 64K  chunk_size: 512K        num_reg: 10
>     lose cover RAM: 2M
> [    0.000000]  gran_size: 64K  chunk_size: 1M  num_reg: 10     lose
> cover RAM: 2M
> [    0.000000]  gran_size: 64K  chunk_size: 2M  num_reg: 10     lose
> cover RAM: 2M
> [    0.000000] *BAD*gran_size: 64K      chunk_size: 4M  num_reg: 10
>     lose cover RAM: -2M
> [    0.000000] *BAD*gran_size: 64K      chunk_size: 8M  num_reg: 10
>     lose cover RAM: -2M
> [    0.000000] *BAD*gran_size: 64K      chunk_size: 16M
>         num_reg: 10     lose cover RAM: -10M
> [    0.000000]  gran_size: 64K  chunk_size: 32M         num_reg: 10
>     lose cover RAM: 0G
> [    0.000000]  gran_size: 64K  chunk_size: 64M         num_reg: 10
>     lose cover RAM: 0G
> [    0.000000]  gran_size: 64K  chunk_size: 128M        num_reg: 10
>     lose cover RAM: 0G
> [    0.000000]  gran_size: 64K  chunk_size: 256M        num_reg: 10
>     lose cover RAM: 0G
> [    0.000000] *BAD*gran_size: 64K      chunk_size: 512M
>        num_reg: 10     lose cover RAM: -256M
> [    0.000000] *BAD*gran_size: 64K      chunk_size: 1G  num_reg: 10
>     lose cover RAM: -512M
> [    0.000000] *BAD*gran_size: 64K      chunk_size: 2G  num_reg: 10
>     lose cover RAM: -512M
> [    0.000000]  gran_size: 128K         chunk_size: 128K
>        num_reg: 10     lose cover RAM: 2M
> [    0.000000]  gran_size: 128K         chunk_size: 256K
>        num_reg: 10     lose cover RAM: 2M
> [    0.000000]  gran_size: 128K         chunk_size: 512K
>        num_reg: 10     lose cover RAM: 2M
> [    0.000000]  gran_size: 128K         chunk_size: 1M  num_reg: 10
>     lose cover RAM: 2M
> [    0.000000]  gran_size: 128K         chunk_size: 2M  num_reg: 10
>     lose cover RAM: 2M
> [    0.000000] *BAD*gran_size: 128K     chunk_size: 4M  num_reg: 10
>     lose cover RAM: -2M
> [    0.000000] *BAD*gran_size: 128K     chunk_size: 8M  num_reg: 10
>     lose cover RAM: -2M
> [    0.000000] *BAD*gran_size: 128K     chunk_size: 16M
>         num_reg: 10     lose cover RAM: -10M
> [    0.000000]  gran_size: 128K         chunk_size: 32M
>         num_reg: 10     lose cover RAM: 0G
> [    0.000000]  gran_size: 128K         chunk_size: 64M
>         num_reg: 10     lose cover RAM: 0G
> [    0.000000]  gran_size: 128K         chunk_size: 128M
>        num_reg: 10     lose cover RAM: 0G
> [    0.000000]  gran_size: 128K         chunk_size: 256M
>        num_reg: 10     lose cover RAM: 0G
> [    0.000000] *BAD*gran_size: 128K     chunk_size: 512M
>        num_reg: 10     lose cover RAM: -256M
> [    0.000000] *BAD*gran_size: 128K     chunk_size: 1G  num_reg: 10
>     lose cover RAM: -512M
> [    0.000000] *BAD*gran_size: 128K     chunk_size: 2G  num_reg: 10
>     lose cover RAM: -512M
> [    0.000000]  gran_size: 256K         chunk_size: 256K
>        num_reg: 10     lose cover RAM: 2M
> [    0.000000]  gran_size: 256K         chunk_size: 512K
>        num_reg: 10     lose cover RAM: 2M
> [    0.000000]  gran_size: 256K         chunk_size: 1M  num_reg: 10
>     lose cover RAM: 2M
> [    0.000000]  gran_size: 256K         chunk_size: 2M  num_reg: 10
>     lose cover RAM: 2M
> [    0.000000] *BAD*gran_size: 256K     chunk_size: 4M  num_reg: 10
>     lose cover RAM: -2M
> [    0.000000] *BAD*gran_size: 256K     chunk_size: 8M  num_reg: 10
>     lose cover RAM: -2M
> [    0.000000] *BAD*gran_size: 256K     chunk_size: 16M
>         num_reg: 10     lose cover RAM: -10M
> [    0.000000]  gran_size: 256K         chunk_size: 32M
>         num_reg: 10     lose cover RAM: 0G
> [    0.000000]  gran_size: 256K         chunk_size: 64M
>         num_reg: 10     lose cover RAM: 0G
> [    0.000000]  gran_size: 256K         chunk_size: 128M
>        num_reg: 10     lose cover RAM: 0G
> [    0.000000]  gran_size: 256K         chunk_size: 256M
>        num_reg: 10     lose cover RAM: 0G
> [    0.000000] *BAD*gran_size: 256K     chunk_size: 512M
>        num_reg: 10     lose cover RAM: -256M
> [    0.000000] *BAD*gran_size: 256K     chunk_size: 1G  num_reg: 10
>     lose cover RAM: -512M
> [    0.000000] *BAD*gran_size: 256K     chunk_size: 2G  num_reg: 10
>     lose cover RAM: -512M
> [    0.000000]  gran_size: 512K         chunk_size: 512K
>        num_reg: 10     lose cover RAM: 2M
> [    0.000000]  gran_size: 512K         chunk_size: 1M  num_reg: 10
>     lose cover RAM: 2M
> [    0.000000]  gran_size: 512K         chunk_size: 2M  num_reg: 10
>     lose cover RAM: 2M
> [    0.000000] *BAD*gran_size: 512K     chunk_size: 4M  num_reg: 10
>     lose cover RAM: -2M
> [    0.000000] *BAD*gran_size: 512K     chunk_size: 8M  num_reg: 10
>     lose cover RAM: -2M
> [    0.000000] *BAD*gran_size: 512K     chunk_size: 16M
>         num_reg: 10     lose cover RAM: -10M
> [    0.000000]  gran_size: 512K         chunk_size: 32M
>         num_reg: 10     lose cover RAM: 0G
> [    0.000000]  gran_size: 512K         chunk_size: 64M
>         num_reg: 10     lose cover RAM: 0G
> [    0.000000]  gran_size: 512K         chunk_size: 128M
>        num_reg: 10     lose cover RAM: 0G
> [    0.000000]  gran_size: 512K         chunk_size: 256M
>        num_reg: 10     lose cover RAM: 0G
> [    0.000000] *BAD*gran_size: 512K     chunk_size: 512M
>        num_reg: 10     lose cover RAM: -256M
> [    0.000000] *BAD*gran_size: 512K     chunk_size: 1G  num_reg: 10
>     lose cover RAM: -512M
> [    0.000000] *BAD*gran_size: 512K     chunk_size: 2G  num_reg: 10
>     lose cover RAM: -512M
> [    0.000000]  gran_size: 1M   chunk_size: 1M  num_reg: 10     lose
> cover RAM: 2M
> [    0.000000]  gran_size: 1M   chunk_size: 2M  num_reg: 10     lose
> cover RAM: 2M
> [    0.000000] *BAD*gran_size: 1M       chunk_size: 4M  num_reg: 10
>     lose cover RAM: -2M
> [    0.000000] *BAD*gran_size: 1M       chunk_size: 8M  num_reg: 10
>     lose cover RAM: -2M
> [    0.000000] *BAD*gran_size: 1M       chunk_size: 16M
>         num_reg: 10     lose cover RAM: -10M
> [    0.000000]  gran_size: 1M   chunk_size: 32M         num_reg: 10
>     lose cover RAM: 0G
> [    0.000000]  gran_size: 1M   chunk_size: 64M         num_reg: 10
>     lose cover RAM: 0G
> [    0.000000]  gran_size: 1M   chunk_size: 128M        num_reg: 10
>     lose cover RAM: 0G
> [    0.000000]  gran_size: 1M   chunk_size: 256M        num_reg: 10
>     lose cover RAM: 0G
> [    0.000000] *BAD*gran_size: 1M       chunk_size: 512M
>        num_reg: 10     lose cover RAM: -256M
> [    0.000000] *BAD*gran_size: 1M       chunk_size: 1G  num_reg: 10
>     lose cover RAM: -512M
> [    0.000000] *BAD*gran_size: 1M       chunk_size: 2G  num_reg: 10
>     lose cover RAM: -512M
> [    0.000000]  gran_size: 2M   chunk_size: 2M  num_reg: 10     lose
> cover RAM: 2M
> [    0.000000] *BAD*gran_size: 2M       chunk_size: 4M  num_reg: 10
>     lose cover RAM: -2M
> [    0.000000] *BAD*gran_size: 2M       chunk_size: 8M  num_reg: 10
>     lose cover RAM: -2M
> [    0.000000] *BAD*gran_size: 2M       chunk_size: 16M
>         num_reg: 10     lose cover RAM: -10M
> [    0.000000]  gran_size: 2M   chunk_size: 32M         num_reg: 10
>     lose cover RAM: 0G
> [    0.000000]  gran_size: 2M   chunk_size: 64M         num_reg: 10
>     lose cover RAM: 0G
> [    0.000000]  gran_size: 2M   chunk_size: 128M        num_reg: 10
>     lose cover RAM: 0G
> [    0.000000]  gran_size: 2M   chunk_size: 256M        num_reg: 10
>     lose cover RAM: 0G
> [    0.000000] *BAD*gran_size: 2M       chunk_size: 512M
>        num_reg: 10     lose cover RAM: -256M
> [    0.000000] *BAD*gran_size: 2M       chunk_size: 1G  num_reg: 10
>     lose cover RAM: -512M
> [    0.000000] *BAD*gran_size: 2M       chunk_size: 2G  num_reg: 10
>     lose cover RAM: -512M
> [    0.000000]  gran_size: 4M   chunk_size: 4M  num_reg: 10     lose
> cover RAM: 2M
> [    0.000000] *BAD*gran_size: 4M       chunk_size: 8M  num_reg: 10
>     lose cover RAM: -2M
> [    0.000000] *BAD*gran_size: 4M       chunk_size: 16M
>         num_reg: 10     lose cover RAM: -10M
> [    0.000000]  gran_size: 4M   chunk_size: 32M         num_reg: 10
>     lose cover RAM: 2M
> [    0.000000]  gran_size: 4M   chunk_size: 64M         num_reg: 10
>     lose cover RAM: 2M
> [    0.000000]  gran_size: 4M   chunk_size: 128M        num_reg: 10
>     lose cover RAM: 2M
> [    0.000000]  gran_size: 4M   chunk_size: 256M        num_reg: 10
>     lose cover RAM: 2M
> [    0.000000] *BAD*gran_size: 4M       chunk_size: 512M
>        num_reg: 10     lose cover RAM: -254M
> [    0.000000] *BAD*gran_size: 4M       chunk_size: 1G  num_reg: 10
>     lose cover RAM: -510M
> [    0.000000] *BAD*gran_size: 4M       chunk_size: 2G  num_reg: 10
>     lose cover RAM: -510M
> [    0.000000]  gran_size: 8M   chunk_size: 8M  num_reg: 9      lose
> cover RAM: 6M
> [    0.000000]  gran_size: 8M   chunk_size: 16M         num_reg: 9
>      lose cover RAM: 6M
> [    0.000000]  gran_size: 8M   chunk_size: 32M         num_reg: 9
>      lose cover RAM: 6M
> [    0.000000]  gran_size: 8M   chunk_size: 64M         num_reg: 8
>      lose cover RAM: 6M
> [    0.000000]  gran_size: 8M   chunk_size: 128M        num_reg: 8
>      lose cover RAM: 6M
> [    0.000000]  gran_size: 8M   chunk_size: 256M        num_reg: 8
>      lose cover RAM: 6M
> [    0.000000]  gran_size: 8M   chunk_size: 512M        num_reg: 9
>      lose cover RAM: 6M
> [    0.000000]  gran_size: 8M   chunk_size: 1G  num_reg: 9      lose
> cover RAM: 6M
> [    0.000000]  gran_size: 8M   chunk_size: 2G  num_reg: 9      lose
> cover RAM: 6M
> [    0.000000]  gran_size: 16M  chunk_size: 16M         num_reg: 9
>      lose cover RAM: 6M
> [    0.000000]  gran_size: 16M  chunk_size: 32M         num_reg: 9
>      lose cover RAM: 6M
> [    0.000000]  gran_size: 16M  chunk_size: 64M         num_reg: 8
>      lose cover RAM: 6M
> [    0.000000]  gran_size: 16M  chunk_size: 128M        num_reg: 8
>      lose cover RAM: 6M
> [    0.000000]  gran_size: 16M  chunk_size: 256M        num_reg: 8
>      lose cover RAM: 6M
> [    0.000000]  gran_size: 16M  chunk_size: 512M        num_reg: 9
>      lose cover RAM: 6M
> [    0.000000]  gran_size: 16M  chunk_size: 1G  num_reg: 9      lose
> cover RAM: 6M
> [    0.000000]  gran_size: 16M  chunk_size: 2G  num_reg: 9      lose
> cover RAM: 6M
> [    0.000000]  gran_size: 32M  chunk_size: 32M         num_reg: 8
>      lose cover RAM: 22M
> [    0.000000]  gran_size: 32M  chunk_size: 64M         num_reg: 8
>      lose cover RAM: 22M
> [    0.000000]  gran_size: 32M  chunk_size: 128M        num_reg: 8
>      lose cover RAM: 22M
> [    0.000000]  gran_size: 32M  chunk_size: 256M        num_reg: 8
>      lose cover RAM: 22M
> [    0.000000]  gran_size: 32M  chunk_size: 512M        num_reg: 9
>      lose cover RAM: 22M
> [    0.000000]  gran_size: 32M  chunk_size: 1G  num_reg: 9      lose
> cover RAM: 22M
> [    0.000000]  gran_size: 32M  chunk_size: 2G  num_reg: 9      lose
> cover RAM: 22M
> [    0.000000]  gran_size: 64M  chunk_size: 64M         num_reg: 6
>      lose cover RAM: 86M
> [    0.000000]  gran_size: 64M  chunk_size: 128M        num_reg: 6
>      lose cover RAM: 86M
> [    0.000000]  gran_size: 64M  chunk_size: 256M        num_reg: 7
>      lose cover RAM: 86M
> [    0.000000]  gran_size: 64M  chunk_size: 512M        num_reg: 8
>      lose cover RAM: 86M
> [    0.000000]  gran_size: 64M  chunk_size: 1G  num_reg: 8      lose
> cover RAM: 86M
> [    0.000000]  gran_size: 64M  chunk_size: 2G  num_reg: 8      lose
> cover RAM: 86M
> [    0.000000]  gran_size: 128M         chunk_size: 128M
>        num_reg: 5      lose cover RAM: 150M
> [    0.000000]  gran_size: 128M         chunk_size: 256M
>        num_reg: 7      lose cover RAM: 150M
> [    0.000000]  gran_size: 128M         chunk_size: 512M
>        num_reg: 8      lose cover RAM: 150M
> [    0.000000]  gran_size: 128M         chunk_size: 1G  num_reg: 8
>      lose cover RAM: 150M
> [    0.000000]  gran_size: 128M         chunk_size: 2G  num_reg: 8
>      lose cover RAM: 150M
> [    0.000000]  gran_size: 256M         chunk_size: 256M
>        num_reg: 3      lose cover RAM: 406M
> [    0.000000]  gran_size: 256M         chunk_size: 512M
>        num_reg: 3      lose cover RAM: 406M
> [    0.000000]  gran_size: 256M         chunk_size: 1G  num_reg: 4
>      lose cover RAM: 406M
> [    0.000000]  gran_size: 256M         chunk_size: 2G  num_reg: 4
>      lose cover RAM: 406M
> [    0.000000]  gran_size: 512M         chunk_size: 512M
>        num_reg: 3      lose cover RAM: 406M
> [    0.000000]  gran_size: 512M         chunk_size: 1G  num_reg: 4
>      lose cover RAM: 406M
> [    0.000000]  gran_size: 512M         chunk_size: 2G  num_reg: 4
>      lose cover RAM: 406M
> [    0.000000]  gran_size: 1G   chunk_size: 1G  num_reg: 2      lose
> cover RAM: 918M
> [    0.000000]  gran_size: 1G   chunk_size: 2G  num_reg: 2      lose
> cover RAM: 918M
> [    0.000000]  gran_size: 2G   chunk_size: 2G  num_reg: 1      lose
> cover RAM: 1942M
> [    0.000000] mtrr_cleanup: can not find optimal value
> [    0.000000] please specify mtrr_gran_size/mtrr_chunk_size
> [    0.000000] x2apic enabled by BIOS, switching to x2apic ops
> [    0.000000] e820: last_pfn = 0x9a max_arch_pfn = 0x400000000
> [    0.000000] found SMP MP-table at [mem 0x000fc9f0-0x000fc9ff]
> mapped at [ffff8800000fc9f0]
> [    0.000000] init_memory_mapping: [mem 0x00000000-0x000fffff]
> [    0.000000] init_memory_mapping: [mem 0x14de00000-0x14df5ffff]
> [    0.000000] init_memory_mapping: [mem 0x14c000000-0x14ddfffff]
> [    0.000000] init_memory_mapping: [mem 0x146000000-0x14bffffff]
> [    0.000000] ACPI: RSDP 00000000000f0410 00024 (v02  INTEL)
> [    0.000000] ACPI: XSDT 00000000aaffde18 00074 (v01  INTEL  IVB-PPT
> 06222004 MSFT 00010013)
> [    0.000000] ACPI: FACP 00000000aafe3d98 000F4 (v04  INTEL  IVB-PPT
> 06222004 MSFT 00010013)
> [    0.000000] ACPI: DSDT 00000000aafbe018 0FD25 (v02  INTEL  IVB-PPT
> 00000000 INTL 20110623)
> [    0.000000] ACPI: FACS 00000000aafe9e40 00040
> [    0.000000] ACPI: APIC 00000000aaffcf18 000CC (v02  INTEL  IVB-PPT
> 06222004 MSFT 00010013)
> [    0.000000] ACPI: HPET 00000000aafe8f18 00038 (v01 A M I   PCHHPET
> 06222004 AMI. 00000003)
> [    0.000000] ACPI: SSDT 00000000aafe5018 010A8 (v01 TrmRef PtidDevc
> 00001000 INTL 20110623)
> [    0.000000] ACPI: SSDT 00000000aafe4a18 00461 (v01    AMI PerfTune
> 00001000 INTL 20110623)
> [    0.000000] ACPI: MCFG 00000000aafe8e98 0003C (v01 INTEL  SNDYBRDG
> 06222004 MSFT 00000097)
> [    0.000000] ACPI: SSDT 00000000aafd2018 009AA (v01  PmRef  Cpu0Ist
> 00003000 INTL 20110623)
> [    0.000000] ACPI: SSDT 00000000aafd1018 00A92 (v01  PmRef    CpuPm
> 00003000 INTL 20110623)
> [    0.000000] ACPI: DMAR 00000000aafe4f18 000B8 (v01 INTEL      SNB
>  00000001 INTL 00000001)
> [    0.000000] ACPI: FPDT 00000000aaff4018 00064 (v01  INTEL  IVB-CPT
> 00010000 INTL 20111107)
> [    0.000000] Setting APIC routing to cluster x2apic.
> [    0.000000] No NUMA configuration found
> [    0.000000] Faking a node at [mem
> 0x0000000000000000-0x000000014df5ffff]
> [    0.000000] Initmem setup node 0 [mem 0x00000000-0x14df5ffff]
> [    0.000000]   NODE_DATA [mem 0x14df39000-0x14df5ffff]
> [    0.000000] Zone ranges:
> [    0.000000]   DMA      [mem 0x00001000-0x00ffffff]
> [    0.000000]   DMA32    [mem 0x01000000-0xffffffff]
> [    0.000000]   Normal   [mem 0x100000000-0x14df5ffff]
> [    0.000000] Movable zone start for each node
> [    0.000000] Early memory node ranges
> [    0.000000]   node   0: [mem 0x00001000-0x00099fff]
> [    0.000000]   node   0: [mem 0x146000000-0x14df5ffff]
> [    0.000000] ACPI: PM-Timer IO Port: 0x408
> [    0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
> [    0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
> [    0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled)
> [    0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled)
> [    0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x04] enabled)
> [    0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x05] enabled)
> [    0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x06] enabled)
> [    0.000000] ACPI: LAPIC (acpi_id[0x08] lapic_id[0x07] enabled)
> [    0.000000] ACPI: LAPIC (acpi_id[0x09] lapic_id[0x08] disabled)
> [    0.000000] ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x09] disabled)
> [    0.000000] ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x0a] disabled)
> [    0.000000] ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x0b] disabled)
> [    0.000000] ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x0c] disabled)
> [    0.000000] ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x0d] disabled)
> [    0.000000] ACPI: LAPIC (acpi_id[0x0f] lapic_id[0x0e] disabled)
> [    0.000000] ACPI: LAPIC (acpi_id[0x10] lapic_id[0x0f] disabled)
> [    0.000000] ACPI: IOAPIC (id[0x02] address[0xfec00000]
> gsi_base[0])
> [    0.000000] IOAPIC[0]: apic_id 2, version 32, address 0xfec00000,
> GSI 0-23
> [    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl
> dfl)
> [    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high
> level)
> [    0.000000] Using ACPI (MADT) for SMP configuration information
> [    0.000000] ACPI: HPET id: 0x8086a701 base: 0xfed00000
> [    0.000000] smpboot: Allowing 16 CPUs, 8 hotplug CPUs
> [    0.000000] PM: Registered nosave memory: 000000000009a000 -
> 00000000aad6a000
> [    0.000000] PM: Registered nosave memory: 00000000aad6a000 -
> 00000000aafff000
> [    0.000000] PM: Registered nosave memory: 00000000aafff000 -
> 0000000146000000
> [    0.000000] e820: [mem 0x0009ac00-0xaad69fff] available for PCI
> devices
> [    0.000000] Booting paravirtualized kernel on bare hardware
> [    0.000000] setup_percpu: NR_CPUS:4096 nr_cpumask_bits:16
> nr_cpu_ids:16 nr_node_ids:1
> [    0.000000] PERCPU: Embedded 29 pages/cpu @ffff88014dc00000 s86272
> r8192 d24320 u131072
> [    0.000000] Built 1 zonelists in Zone order, mobility grouping on.
>  Total pages: 32227
> [    0.000000] Policy zone: Normal
> [    0.000000] Kernel command line: console=ttyS0,115200n81
> memmap=exactmap memmap=615K@4K memmap=130432K@5341184K
> elfcorehdr=5471616K memmap=2560K#2799016K memmap=84K#2801576K
> [    0.000000] PID hash table entries: 512 (order: 0, 4096 bytes)
> [    0.000000] __ex_table already sorted, skipping sort
> [    0.000000] xsave: enabled xstate_bv 0x7, cntxt size 0x340
> [    0.000000] Cannot allocate SWIOTLB buffer
> [    0.000000] Checking aperture...
> [    0.000000] No AGP bridge found
> [    0.000000] Memory: 108184k/5471616k available (6346k kernel code,
> 5340572k absent, 22860k reserved, 3983k data, 1484k init)
> [    0.000000] SLUB: Genslabs=15, HWalign=64, Order=0-3,
> MinObjects=0, CPUs=16, Nodes=1
> [    0.000000] Hierarchical RCU implementation.
> [    0.000000]  RCU restricting CPUs from NR_CPUS=4096 to
> nr_cpu_ids=16.
> [    0.000000] NR_IRQS:262400 nr_irqs:808 16
> [    0.000000] Spurious LAPIC timer interrupt on cpu 0
> [    0.000000] Console: colour VGA+ 80x25
> [    0.000000] console [ttyS0] enabled
> [    0.000000] allocated 1572864 bytes of page_cgroup
> [    0.000000] please try 'cgroup_disable=memory' option if you don't
> want memory cgroups
> [    0.001000] tsc: Fast TSC calibration using PIT
> [    0.002000] tsc: Detected 2593.881 MHz processor
> [    0.000005] Calibrating delay loop (skipped), value calculated
> using timer frequency.. 5187.76 BogoMIPS (lpj=2593881)
> [    0.010628] pid_max: default: 32768 minimum: 301
> [    0.015311] Security Framework initialized
> [    0.019418] SELinux:  Initializing.
> [    0.023012] Dentry cache hash table entries: 16384 (order: 5,
> 131072 bytes)
> [    0.030043] Inode-cache hash table entries: 8192 (order: 4, 65536
> bytes)
> [    0.036777] Mount-cache hash table entries: 256
> [    0.041629] Initializing cgroup subsys cpuacct
> [    0.046079] Initializing cgroup subsys memory
> [    0.050447] Initializing cgroup subsys devices
> [    0.054891] Initializing cgroup subsys freezer
> [    0.059335] Initializing cgroup subsys net_cls
> [    0.063777] Initializing cgroup subsys blkio
> [    0.068045] Initializing cgroup subsys perf_event
> [    0.072794] CPU: Physical Processor ID: 0
> [    0.076806] CPU: Processor Core ID: 0
> [    0.081210] mce: CPU supports 9 MCE banks
> [    0.085254] Last level iTLB entries: 4KB 512, 2MB 0, 4MB 0
> [    0.085254] Last level dTLB entries: 4KB 512, 2MB 32, 4MB 32
> [    0.085254] tlb_flushall_shift: 1
> [    0.099844] Freeing SMP alternatives: 24k freed
> [    0.106487] ACPI: Core revision 20130117
> [    0.122586] ACPI: All ACPI Tables successfully acquired
> [    0.127868] ftrace: allocating 23601 entries in 93 pages
> [    0.154031] dmar: Host address width 36
> [    0.157876] dmar: DRHD base: 0x000000fed90000 flags: 0x0
> [    0.163194] dmar: IOMMU 0: reg_base_addr fed90000 ver 1:0 cap
> c0000020e60262 ecap f0101a
> [    0.171277] dmar: DRHD base: 0x000000fed91000 flags: 0x1
> [    0.176590] dmar: IOMMU 1: reg_base_addr fed91000 ver 1:0 cap
> c9008020660262 ecap f010da
> [    0.184672] dmar: RMRR base: 0x000000aac95000 end:
> 0x000000aacb2fff
> [    0.190934] dmar: RMRR base: 0x000000ab800000 end:
> 0x000000af9fffff
> [    0.197268] IOAPIC id 2 under DRHD base  0xfed91000 IOMMU 1
> [    0.202825] HPET id 0 under DRHD base 0xfed91000
> [    0.207714] Enabled IRQ remapping in x2apic mode
> [    0.212866] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
> [    0.228870] smpboot: CPU0: Intel(R) Core(TM) i7-3720QM CPU @
> 2.60GHz (fam: 06, model: 3a, stepping: 09)
> [    0.238319] Performance Events: PEBS fmt1+, 16-deep LBR, IvyBridge
> events, Broken BIOS detected, complain to your hardware vendor.
> [    0.250098] [Firmware Bug]: the BIOS has corrupted hw-PMU
> resources (MSR 38d is b0)
> [    0.257739] Intel PMU driver.
> [    0.260701] ... version:                3
> [    0.264704] ... bit width:              48
> [    0.268790] ... generic registers:      4
> [    0.272791] ... value mask:             0000ffffffffffff
> [    0.278092] ... max period:             000000007fffffff
> [    0.283391] ... fixed-purpose events:   3
> [    0.287391] ... event mask:             000000070000000f
> [    0.294917] smpboot: Booting Node   0, Processors  #1[
>    0.314489] NMI watchdog: enabled on all CPUs, permanently consumes
> one hw-PMU counter.
>  #2 #3 #4 #5 #6 #7
> [    0.408750] Brought up 8 CPUs
> [    0.411901] smpboot: Total of 8 processors activated (41502.09
> BogoMIPS)
> [    0.432134] devtmpfs: initialized
> [    0.437882] atomic64 test passed for x86-64 platform with CX8 and
> with SSE
> [    0.444833] NET: Registered protocol family 16
> [    0.449455] ACPI FADT declares the system doesn't support PCIe
> ASPM, so disable it
> [    0.457010] ACPI: bus type pci registered
> [    0.461122] PCI: MMCONFIG for domain 0000 [bus 00-3f] at [mem
> 0xf8000000-0xfbffffff] (base 0xf8000000)
> [    0.470411] PCI: not using MMCONFIG
> [    0.473897] PCI: Using configuration type 1 for base access
> [    0.480792] bio: create slab  at 0
> [    0.484937] ACPI: Added _OSI(Module Device)
> [    0.489116] ACPI: Added _OSI(Processor Device)
> [    0.493554] ACPI: Added _OSI(3.0 _SCP Extensions)
> [    0.498254] ACPI: Added _OSI(Processor Aggregator Device)
> [    0.509686] ACPI: Executed 1 blocks of module-level executable AML
> code
> [    0.529844] ACPI: SSDT 00000000aaccd018 00A4F (v01  PmRef  Cpu0Cst
> 00003001 INTL 20110623)
> [    0.538912] ACPI: Dynamic OEM Table Load:
> [    0.542947] ACPI: SSDT           (null) 00A4F (v01  PmRef  Cpu0Cst
> 00003001 INTL 20110623)
> [    0.556403] ACPI: SSDT 00000000aaccea98 00303 (v01  PmRef    ApIst
> 00003000 INTL 20110623)
> [    0.565515] ACPI: Dynamic OEM Table Load:
> [    0.569549] ACPI: SSDT           (null) 00303 (v01  PmRef    ApIst
> 00003000 INTL 20110623)
> [    0.582778] ACPI: SSDT 00000000aacccd98 00119 (v01  PmRef    ApCst
> 00003000 INTL 20110623)
> [    0.591819] ACPI: Dynamic OEM Table Load:
> [    0.595855] ACPI: SSDT           (null) 00119 (v01  PmRef    ApCst
> 00003000 INTL 20110623)
> [    1.418743] ACPI: Interpreter enabled
> [    1.422408] ACPI: (supports S0 S1ACPI Exception: AE_NOT_FOUND,
> While evaluating Sleep State [\\_S2_] (20130117/hwxface-568)
> [    1.433515]  S3 S4 S5)
> [    1.435935] ACPI: Using IOAPIC for interrupt routing
> [    1.440920] PCI: MMCONFIG for domain 0000 [bus 00-3f] at [mem
> 0xf8000000-0xfbffffff] (base 0xf8000000)
> [    1.451100] PCI: MMCONFIG at [mem 0xf8000000-0xfbffffff] reserved
> in ACPI motherboard resources
> [    1.464742] PCI: Using host bridge windows from ACPI; if
> necessary, use "pci=nocrs" and report a bug
> [    1.488550] ACPI: Power Resource [FN00] (off)
> [    1.493020] ACPI: Power Resource [FN01] (off)
> [    1.497481] ACPI: Power Resource [FN02] (on)
> [    1.502241] ACPI: Power Resource [FN03] (on)
> [    1.506935] ACPI: Power Resource [FN04] (on)
> [    1.512503] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-3e])
> [    1.519005] acpi PNP0A08:00: ACPI _OSC support notification
> failed, disabling PCIe ASPM
> [    1.526995] acpi PNP0A08:00: Unable to request _OSC control (_OSC
> support mask: 0x08)
> [    1.535557] PCI host bridge to bus 0000:00
> [    1.539653] pci_bus 0000:00: root bus resource [bus 00-3e]
> [    1.545132] pci_bus 0000:00: root bus resource [io  0x0000-0x0cf7]
> [    1.551304] pci_bus 0000:00: root bus resource [io  0x0d00-0xffff]
> [    1.557474] pci_bus 0000:00: root bus resource [mem
> 0x000a0000-0x000bffff]
> [    1.564338] pci_bus 0000:00: root bus resource [mem
> 0x000d0000-0x000d3fff]
> [    1.571201] pci_bus 0000:00: root bus resource [mem
> 0x000d4000-0x000d7fff]
> [    1.578064] pci_bus 0000:00: root bus resource [mem
> 0x000d8000-0x000dbfff]
> [    1.584923] pci_bus 0000:00: root bus resource [mem
> 0x000dc000-0x000dffff]
> [    1.591784] pci_bus 0000:00: root bus resource [mem
> 0x000e0000-0x000e3fff]
> [    1.598644] pci_bus 0000:00: root bus resource [mem
> 0x000e4000-0x000e7fff]
> [    1.605503] pci_bus 0000:00: root bus resource [mem
> 0xafa00000-0xfeafffff]
> [    1.613008] pci 0000:00:14.0: System wakeup disabled by ACPI
> [    1.619582] pci 0000:00:19.0: System wakeup disabled by ACPI
> [    1.625584] pci 0000:00:1a.0: System wakeup disabled by ACPI
> [    1.631518] pci 0000:00:1c.0: System wakeup disabled by ACPI
> [    1.637463] pci 0000:00:1c.6: System wakeup disabled by ACPI
> [    1.643459] pci 0000:00:1d.0: System wakeup disabled by ACPI
> [    1.650069] pci 0000:00:1c.0: PCI bridge to [bus 01]
> [    1.655146] pci 0000:00:1c.6: PCI bridge to [bus 02-09]
> [    1.660411] ACPI _OSC control for PCIe not granted, disabling ASPM
> [    1.668220] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 10 *11
> 12 14 15), disabled.
> [    1.676298] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 10 11 12
> 14 15) *0, disabled.
> [    1.684560] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 10 *11
> 12 14 15), disabled.
> [    1.692628] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 *10 11
> 12 14 15), disabled.
> [    1.700698] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 *5 6 10 11
> 12 14 15), disabled.
> [    1.708765] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 10 11 12
> 14 15) *0, disabled.
> [    1.717023] ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 10 11 12
> 14 15) *0, disabled.
> [    1.725280] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 *10 11
> 12 14 15), disabled.
> [    1.733756] ACPI: Enabled 5 GPEs in block 00 to 3F
> [    1.738777] ACPI: EC: GPE = 0x17, I/O: command/status = 0x66, data
> = 0x62
> [    1.746393] ACPI: ACPI Dock Station Driver: 1 docks/bays found
> [    1.752307] vgaarb: device added:
> PCI:0000:00:02.0,decodes=io+mem,owns=io+mem,locks=none
> [    1.760387] vgaarb: loaded
> [    1.763093] vgaarb: bridge control possible 0000:00:02.0
> [    1.768498] SCSI subsystem initialized
> [    1.772270] ACPI: bus type usb registered
> [    1.776297] usbcore: registered new interface driver usbfs
> [    1.781783] usbcore: registered new interface driver hub
> [    1.787122] usbcore: registered new device driver usb
> [    1.792242] PCI: Using ACPI for IRQ routing
> [    1.800410] NetLabel: Initializing
> [    1.803809] NetLabel:  domain hash size = 128
> [    1.808159] NetLabel:  protocols = UNLABELED CIPSOv4
> [    1.813125] NetLabel:  unlabeled traffic allowed by default
> [    1.818736] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0, 0, 0, 0, 0, 0
> [    1.825032] hpet0: 8 comparators, 64-bit 14.318180 MHz counter
> [    1.832871] Switching to clocksource hpet
> [    1.845000] pnp: PnP ACPI init
> [    1.848089] ACPI: bus type pnp registered
> [    1.852490] system 00:00: [io  0x06a4] has been reserved
> [    1.857802] system 00:00: [io  0x06a0] has been reserved
> [    1.863449] system 00:05: [io  0x0680-0x069f] has been reserved
> [    1.869370] system 00:05: [io  0x1004-0x1013] has been reserved
> [    1.875291] system 00:05: [io  0xffff] has been reserved
> [    1.880604] system 00:05: [io  0xffff] has been reserved
> [    1.885918] system 00:05: [io  0x0400-0x0453] has been reserved
> [    1.891836] system 00:05: [io  0x0458-0x047f] has been reserved
> [    1.897754] system 00:05: [io  0x0500-0x057f] has been reserved
> [    1.903673] system 00:05: [io  0x164e-0x164f] has been reserved
> [    1.909718] system 00:07: [io  0x0454-0x0457] has been reserved
> [    1.916807] system 00:0b: [mem 0xfed1c000-0xfed1ffff] has been
> reserved
> [    1.923425] system 00:0b: [mem 0xfed10000-0xfed17fff] has been
> reserved
> [    1.930043] system 00:0b: [mem 0xfed18000-0xfed18fff] has been
> reserved
> [    1.936656] system 00:0b: [mem 0xfed19000-0xfed19fff] has been
> reserved
> [    1.943267] system 00:0b: [mem 0xf8000000-0xfbffffff] has been
> reserved
> [    1.949879] system 00:0b: [mem 0xfed20000-0xfed3ffff] has been
> reserved
> [    1.956492] system 00:0b: [mem 0xfed90000-0xfed93fff] could not be
> reserved
> [    1.963449] system 00:0b: [mem 0xfed45000-0xfed8ffff] has been
> reserved
> [    1.970062] system 00:0b: [mem 0xff000000-0xffffffff] has been
> reserved
> [    1.976677] system 00:0b: [mem 0xfee00000-0xfeefffff] has been
> reserved
> [    1.983292] system 00:0b: [mem 0xafa00000-0xafa00fff] has been
> reserved
> [    1.990474] system 00:0c: [mem 0x00000000-0x0009cfff] could not be
> reserved
> [    1.997547] system 00:0d: [mem 0x20000000-0x201fffff] has been
> reserved
> [    2.004160] system 00:0d: [mem 0x40004000-0x40004fff] has been
> reserved
> [    2.010844] pnp: PnP ACPI: found 14 devices
> [    2.015025] ACPI: ACPI bus type pnp unregistered
> [    2.027290] pci 0000:00:1c.0: PCI bridge to [bus 01]
> [    2.032277] pci 0000:00:1c.6: PCI bridge to [bus 02-09]
> [    2.037501] pci 0000:00:1c.6:   bridge window [io  0x2000-0x5fff]
> [    2.043599] pci 0000:00:1c.6:   bridge window [mem
> 0xb0000000-0xb10fffff]
> [    2.050391] pci 0000:00:1c.6:   bridge window [mem
> 0xd0000000-0xd10fffff 64bit pref]
> [    2.058446] NET: Registered protocol family 2
> [    2.063068] TCP established hash table entries: 1024 (order: 2,
> 16384 bytes)
> [    2.070133] TCP bind hash table entries: 1024 (order: 2, 16384
> bytes)
> [    2.076578] TCP: Hash tables configured (established 1024 bind
> 1024)
> [    2.082996] TCP: reno registered
> [    2.086255] UDP hash table entries: 256 (order: 1, 8192 bytes)
> [    2.092092] UDP-Lite hash table entries: 256 (order: 1, 8192
> bytes)
> [    2.098509] NET: Registered protocol family 1
> [    2.103710] PCI-DMA: Using software bounce buffering for IO
> (SWIOTLB)
> [    2.110160] software IO TLB: No low mem
> [    2.116187] alg: No test for __gcm-aes-aesni
> (__driver-gcm-aes-aesni)
> [    2.123111] Initialise module verification
> [    2.127274] audit: initializing netlink socket (disabled)
> [    2.132684] type=2000 audit(1362698281.479:1): initialized
> [    2.185575] HugeTLB registered 2 MB page size, pre-allocated 0
> pages
> [    2.193943] VFS: Disk quotas dquot_6.5.2
> [    2.197950] Dquot-cache hash table entries: 512 (order 0, 4096
> bytes)
> [    2.205330] msgmni has been set to 211
> [    2.210287] alg: No test for stdrng (krng)
> [    2.214402] NET: Registered protocol family 38
> [    2.218851] Key type asymmetric registered
> [    2.222951] Asymmetric key parser 'x509' registered
> [    2.227888] Block layer SCSI generic (bsg) driver version 0.4
> loaded (major 252)
> [    2.235322] io scheduler noop registered
> [    2.239247] io scheduler deadline registered (default)
> [    2.244403] io scheduler cfq registered
> [    2.248531] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
> [    2.254132] pciehp: PCI Express Hot Plug Controller Driver
> version: 0.4
> [    2.260741] acpiphp: ACPI Hot Plug PCI Controller Driver version:
> 0.5
> [    2.267305] acpiphp_glue: can't evaluate _ADR (0x5)
> [    2.272577] ACPI: AC Adapter [ADP1] (on-line)
> [    2.277080] input: Lid Switch as
> /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0D:00/input/input0
> [    2.285391] ACPI: Lid Switch [LID0]
> [    2.288954] input: Power Button as
> /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input1
> [    2.297299] ACPI: Power Button [PWRB]
> [    2.301017] input: Power Button as
> /devices/LNXSYSTM:00/LNXPWRBN:00/input/input2
> [    2.308410] ACPI: Power Button [PWRF]
> [    2.312155] ACPI: Fan [FAN0] (off)
> [    2.315615] ACPI: Fan [FAN1] (off)
> [    2.319067] ACPI: Fan [FAN2] (on)
> [    2.322435] ACPI: Fan [FAN3] (on)
> [    2.325793] ACPI: Fan [FAN4] (on)
> [    2.329202] ACPI: Requesting acpi_cpufreq
> [    2.340021] thermal LNXTHERM:00: registered as thermal_zone0
> [    2.345688] ACPI: Thermal Zone [TZ00] (32 C)
> [    2.351008] thermal LNXTHERM:01: registered as thermal_zone1
> [    2.356672] ACPI: Thermal Zone [TZ01] (33 C)
> [    2.364912] GHES: HEST is not enabled!
> [    2.365203] ACPI: Battery Slot [BAT0] (battery present)
> [    2.365238] ACPI: Battery Slot [BAT1] (battery absent)
> [    2.365350] ACPI: Battery Slot [BAT2] (battery absent)
> [    2.384217] Serial: 8250/16550 driver, 4 ports, IRQ sharing
> enabled
> [    2.411446] 00:08: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
> [    2.438082] serial8250: ttyS2 at I/O 0x3e8 (irq = 4) is a 16550A
> [    2.464897] 0000:00:16.3: ttyS1 at I/O 0x60e0 (irq = 19) is a
> 16550A
> [    2.471729] Non-volatile memory driver v1.3
> [    2.475917] Linux agpgart interface v0.103
> [    2.481169] loop: module loaded
> [    2.484342] rdac: device handler registered
> [    2.488599] hp_sw: device handler registered
> [    2.492869] emc: device handler registered
> [    2.496970] alua: device handler registered
> [    2.501205] libphy: Fixed MDIO Bus: probed
> [    2.505370] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI)
> Driver
> [    2.511893] ehci-pci: EHCI PCI platform driver
> [    2.516470] ehci-pci 0000:00:1a.0: EHCI Host Controller
> [    2.521763] ehci-pci 0000:00:1a.0: new USB bus registered,
> assigned bus number 1
> [    2.529178] ehci-pci 0000:00:1a.0: debug port 2
> [    2.537665] ehci-pci 0000:00:1a.0: irq 16, io mem 0xb1160000
> [    2.548387] ehci-pci 0000:00:1a.0: USB 2.0 started, EHCI 1.00
> [    2.554157] usb usb1: New USB device found, idVendor=1d6b,
> idProduct=0002
> [    2.560941] usb usb1: New USB device strings: Mfr=3, Product=2,
> SerialNumber=1
> [    2.568161] usb usb1: Product: EHCI Host Controller
> [    2.573041] usb usb1: Manufacturer: Linux 3.9.0-rc1+ ehci_hcd
> [    2.578784] usb usb1: SerialNumber: 0000:00:1a.0
> [    2.583547] hub 1-0:1.0: USB hub found
> [    2.587305] hub 1-0:1.0: 3 ports detected
> [    2.591639] ehci-pci 0000:00:1d.0: EHCI Host Controller
> [    2.596930] ehci-pci 0000:00:1d.0: new USB bus registered,
> assigned bus number 2
> [    2.604343] ehci-pci 0000:00:1d.0: debug port 2
> [    2.612811] ehci-pci 0000:00:1d.0: irq 23, io mem 0xb1150000
> [    2.624437] ehci-pci 0000:00:1d.0: USB 2.0 started, EHCI 1.00
> [    2.630204] usb usb2: New USB device found, idVendor=1d6b,
> idProduct=0002
> [    2.636987] usb usb2: New USB device strings: Mfr=3, Product=2,
> SerialNumber=1
> [    2.644206] usb usb2: Product: EHCI Host Controller
> [    2.649084] usb usb2: Manufacturer: Linux 3.9.0-rc1+ ehci_hcd
> [    2.654830] usb usb2: SerialNumber: 0000:00:1d.0
> [    2.659586] hub 2-0:1.0: USB hub found
> [    2.663345] hub 2-0:1.0: 3 ports detected
> [    2.667593] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
> [    2.673792] uhci_hcd: USB Universal Host Controller Interface
> driver
> [    2.680291] xhci_hcd 0000:00:14.0: xHCI Host Controller
> [    2.685578] xhci_hcd 0000:00:14.0: new USB bus registered,
> assigned bus number 3
> [    2.693119] xhci_hcd 0000:00:14.0: irq 16, io mem 0xb11a0000
> [    2.698942] usb usb3: New USB device found, idVendor=1d6b,
> idProduct=0002
> [    2.705729] usb usb3: New USB device strings: Mfr=3, Product=2,
> SerialNumber=1
> [    2.712948] usb usb3: Product: xHCI Host Controller
> [    2.717823] usb usb3: Manufacturer: Linux 3.9.0-rc1+ xhci_hcd
> [    2.723564] usb usb3: SerialNumber: 0000:00:14.0
> [    2.728328] hub 3-0:1.0: USB hub found
> [    2.732094] hub 3-0:1.0: 4 ports detected
> [    2.736783] xhci_hcd 0000:00:14.0: xHCI Host Controller
> [    2.742078] xhci_hcd 0000:00:14.0: new USB bus registered,
> assigned bus number 4
> [    2.749514] usb usb4: New USB device found, idVendor=1d6b,
> idProduct=0003
> [    2.756299] usb usb4: New USB device strings: Mfr=3, Product=2,
> SerialNumber=1
> [    2.763516] usb usb4: Product: xHCI Host Controller
> [    2.768400] usb usb4: Manufacturer: Linux 3.9.0-rc1+ xhci_hcd
> [    2.774148] usb usb4: SerialNumber: 0000:00:14.0
> [    2.778964] hub 4-0:1.0: USB hub found
> [    2.782737] hub 4-0:1.0: 4 ports detected
> [    2.791587] usbcore: registered new interface driver usbserial
> [    2.797430] usbcore: registered new interface driver
> usbserial_generic
> [    2.803956] usbserial: USB Serial support registered for generic
> [    2.810001] i8042: PNP: PS/2 Controller [PNP0303:PS2K] at
> 0x60,0x64 irq 1
> [    2.816782] i8042: PNP: PS/2 appears to have AUX port disabled, if
> this is incorrect please boot with i8042.nopnp
> [    2.827473] serio: i8042 KBD port at 0x60,0x64 irq 1
> [    2.832534] mousedev: PS/2 mouse device common for all mice
> [    2.838423] rtc_cmos 00:06: RTC can wake from S4
> [    2.843292] rtc_cmos 00:06: rtc core: registered rtc_cmos as rtc0
> [    2.849434] rtc_cmos 00:06: alarms up to one month, y3k, 242 bytes
> nvram, hpet irqs
> [    2.857324] cpuidle: using governor ladder
> [    2.861761] cpuidle: using governor menu
> [    2.866158] EFI Variables Facility v0.08 2004-May-17
> [    2.871140] hidraw: raw HID events driver (C) Jiri Kosina
> [    2.873905] input: AT Translated Set 2 keyboard as
> /devices/platform/i8042/serio0/input/input3
> [    2.885248] usbcore: registered new interface driver usbhid
> [    2.890818] usbhid: USB HID core driver
> [    2.894647] usb 1-1: new high-speed USB device number 2 using
> ehci-pci
> [    2.894695] drop_monitor: Initializing network drop monitor
> service
> [    2.894813] TCP: cubic registered
> [    2.894815] Initializing XFRM netlink socket
> [    2.894988] NET: Registered protocol family 10
> [    2.895269] NET: Registered protocol family 17
> [    2.895770] Loading module verification certificates
> [    2.897372] MODSIGN: Loaded cert 'Magrathea: Glacier signing key:
> b14fa6fba81316fe0bb193bbf458deba6d430978'
> [    2.897384] registered taskstats version 1
> [    2.897388] IMA: No TPM chip found, activating TPM-bypass!
> [    2.948076] Kernel panic - not syncing: Can not allocate SWIOTLB
> buffer earlier and can't now provide you with the DMA bounce buffer
> [    2.959958] Pid: 53, comm: khubd Not tainted 3.9.0-rc1+ #1
> [    2.965426] Call Trace:
> [    2.967866]  [] panic+0xc1/0x1d0
> [    2.972644]  []
> swiotlb_tbl_map_single+0x27c/0x280
> [    2.978991]  [] map_single+0x19/0x20
> [    2.984115]  [] swiotlb_map_page+0x6e/0x160
> [    2.989845]  []
> usb_hcd_map_urb_for_dma+0x230/0x4a0
> [    2.996268]  [] usb_hcd_submit_urb+0x295/0x8e0
> [    3.002258]  [] ? __dequeue_entity+0x2f/0x50
> [    3.008076]  [] ? __switch_to+0x13e/0x4a0
> [    3.013632]  [] usb_submit_urb+0xff/0x3d0
> [    3.019186]  [] ? __schedule+0x3de/0x7e0
> [    3.024657]  [] usb_start_wait_urb+0x6a/0x160
> [    3.030560]  [] ? __kmalloc+0x55/0x210
> [    3.035856]  [] ? usb_alloc_urb+0x1e/0x50
> [    3.041411]  [] usb_control_msg+0xde/0x140
> [    3.047056]  [] ? hub_port_init+0x310/0xaf0
> [    3.052785]  [] ? hub_port_init+0x2eb/0xaf0
> [    3.058515]  [] hub_port_init+0x338/0xaf0
> [    3.064071]  [] ? update_autosuspend+0x39/0x60
> [    3.070062]  [] ?
> pm_runtime_set_autosuspend_delay+0x49/0x70
> [    3.077264]  []
> hub_port_connect_change+0x24a/0xaa0
> [    3.083684]  [] hub_events+0x2ea/0x910
> [    3.088981]  [] ? __schedule+0x3de/0x7e0
> [    3.094451]  [] hub_thread+0x35/0x1e0
> [    3.099661]  [] ? wake_up_bit+0x40/0x40
> [    3.105045]  [] ? hub_events+0x910/0x910
> [    3.110514]  [] kthread+0xc0/0xd0
> [    3.115378]  [] ?
> kthread_create_on_node+0x120/0x120
> [    3.121887]  [] ret_from_fork+0x7c/0xb0
> [    3.127271]  [] ?
> kthread_create_on_node+0x120/0x120
> 
> --
> Thanks,
> WANG Chao
> 

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: 3.9-rc1: crash kernel panic - not syncing: Can not allocate SWIOTLB buffer earlier and can't now provide you with the DMA bounce buffer
  2013-03-08  6:03 ` CAI Qian
@ 2013-03-08  6:32   ` Yinghai Lu
  2013-03-08  6:36     ` Yinghai Lu
  0 siblings, 1 reply; 101+ messages in thread
From: Yinghai Lu @ 2013-03-08  6:32 UTC (permalink / raw)
  To: CAI Qian; +Cc: LKML, kexec, Dave Young, Vivek Goyal, H. Peter Anvin, WANG Chao

On Thu, Mar 7, 2013 at 10:03 PM, CAI Qian <caiqian@redhat.com> wrote:
> CC'ing kexec ML. Also mentioned that 3.8 has no such issue.
>
> This message looks suspicious and out of range while 3.8 reservation
> looks within the range.
>
> [    0.000000] Reserving 128MB of memory at 5216MB for crashkernel
> (System RAM: 3977MB)
>
> Wondering if anything to do with memblock again...

that is intended...

> ----- Original Message -----
>> From: "WANG Chao" <chaowang@redhat.com>
>> To: "LKML" vger.kernel.org>
>> Cc: "CAI Qian" <caiqian@redhat.com>
>> Sent: Friday, March 8, 2013 1:54:37 PM
>> Subject: 3.9-rc1: crash kernel panic - not syncing: Can not allocate SWIOTLB buffer earlier and can't now provide you
>> with the DMA bounce buffer
>>
>> Hi, All
>>
>> On 3.9-rc1, I load crash kernel with latest kexec-tools(up to
>> 28d413a), but
>> 2nd kernel panic at early time:
>> [    2.948076] Kernel panic - not syncing: Can not allocate SWIOTLB
>> buffer earlier and can't now provide you with the DMA bounce buffer
>> [    2.959958] Pid: 53, comm: khubd Not tainted 3.9.0-rc1+ #1

You need to add crashkernel_low=64M in first kernel.

As your system does not support DMA remapping.

Thanks

Yinghai

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: 3.9-rc1: crash kernel panic - not syncing: Can not allocate SWIOTLB buffer earlier and can't now provide you with the DMA bounce buffer
  2013-03-08  6:32   ` Yinghai Lu
@ 2013-03-08  6:36     ` Yinghai Lu
  2013-03-08  7:20       ` WANG Chao
  0 siblings, 1 reply; 101+ messages in thread
From: Yinghai Lu @ 2013-03-08  6:36 UTC (permalink / raw)
  To: CAI Qian; +Cc: LKML, kexec, Dave Young, Vivek Goyal, H. Peter Anvin, WANG Chao

On Thu, Mar 7, 2013 at 10:32 PM, Yinghai Lu <yinghai@kernel.org> wrote:
> On Thu, Mar 7, 2013 at 10:03 PM, CAI Qian <caiqian@redhat.com> wrote:
>> CC'ing kexec ML. Also mentioned that 3.8 has no such issue.
>>
>> This message looks suspicious and out of range while 3.8 reservation
>> looks within the range.
>>
>> [    0.000000] Reserving 128MB of memory at 5216MB for crashkernel
>> (System RAM: 3977MB)
>>
>> Wondering if anything to do with memblock again...
>
> that is intended...
>
>> ----- Original Message -----
>>> From: "WANG Chao" <chaowang@redhat.com>
>>> To: "LKML" vger.kernel.org>
>>> Cc: "CAI Qian" <caiqian@redhat.com>
>>> Sent: Friday, March 8, 2013 1:54:37 PM
>>> Subject: 3.9-rc1: crash kernel panic - not syncing: Can not allocate SWIOTLB buffer earlier and can't now provide you
>>> with the DMA bounce buffer
>>>
>>> Hi, All
>>>
>>> On 3.9-rc1, I load crash kernel with latest kexec-tools(up to
>>> 28d413a), but
>>> 2nd kernel panic at early time:
>>> [    2.948076] Kernel panic - not syncing: Can not allocate SWIOTLB
>>> buffer earlier and can't now provide you with the DMA bounce buffer
>>> [    2.959958] Pid: 53, comm: khubd Not tainted 3.9.0-rc1+ #1
>
> You need to add crashkernel_low=64M in first kernel.
>
> As your system does not support DMA remapping.

looks like your system DO have DMAR table, please enable dmar
remapping in your kernel config.

Yinghai

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: 3.9-rc1: crash kernel panic - not syncing: Can not allocate SWIOTLB buffer earlier and can't now provide you with the DMA bounce buffer
  2013-03-08  6:36     ` Yinghai Lu
@ 2013-03-08  7:20       ` WANG Chao
  2013-03-08  7:27         ` Yinghai Lu
  0 siblings, 1 reply; 101+ messages in thread
From: WANG Chao @ 2013-03-08  7:20 UTC (permalink / raw)
  To: Yinghai Lu; +Cc: CAI Qian, LKML, kexec, Dave Young, Vivek Goyal, H. Peter Anvin

On 03/08/2013 02:36 PM, Yinghai Lu wrote:
> On Thu, Mar 7, 2013 at 10:32 PM, Yinghai Lu <yinghai@kernel.org> wrote:
>> On Thu, Mar 7, 2013 at 10:03 PM, CAI Qian <caiqian@redhat.com> wrote:
>>> CC'ing kexec ML. Also mentioned that 3.8 has no such issue.
>>>
>>> This message looks suspicious and out of range while 3.8 reservation
>>> looks within the range.
>>>
>>> [    0.000000] Reserving 128MB of memory at 5216MB for crashkernel
>>> (System RAM: 3977MB)
>>>
>>> Wondering if anything to do with memblock again...
>>
>> that is intended...
>>
>>> ----- Original Message -----
>>>> From: "WANG Chao" <chaowang@redhat.com>
>>>> To: "LKML" vger.kernel.org>
>>>> Cc: "CAI Qian" <caiqian@redhat.com>
>>>> Sent: Friday, March 8, 2013 1:54:37 PM
>>>> Subject: 3.9-rc1: crash kernel panic - not syncing: Can not allocate SWIOTLB buffer earlier and can't now provide you
>>>> with the DMA bounce buffer
>>>>
>>>> Hi, All
>>>>
>>>> On 3.9-rc1, I load crash kernel with latest kexec-tools(up to
>>>> 28d413a), but
>>>> 2nd kernel panic at early time:
>>>> [    2.948076] Kernel panic - not syncing: Can not allocate SWIOTLB
>>>> buffer earlier and can't now provide you with the DMA bounce buffer
>>>> [    2.959958] Pid: 53, comm: khubd Not tainted 3.9.0-rc1+ #1
>>
>> You need to add crashkernel_low=64M in first kernel.
>>
>> As your system does not support DMA remapping.
> 
> looks like your system DO have DMAR table, please enable dmar
> remapping in your kernel config.

I've already got following config:
CONFIG_DMAR_TABLE=y
CONFIG_INTEL_IOMMU=y
CONFIG_IRQ_REMAP=y

but I don't have intel_iommu=on in kernel cmdline. IIRC, iommu will prevent
2nd kernel from booting ...

I tested crashkernel=128M and crashkernel_low=64M, seems 2nd-kernel/kexec only
works when two params are used in combination.

Thanks,
WANG Chao

> 
> Yinghai
> 

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: 3.9-rc1: crash kernel panic - not syncing: Can not allocate SWIOTLB buffer earlier and can't now provide you with the DMA bounce buffer
  2013-03-08  7:20       ` WANG Chao
@ 2013-03-08  7:27         ` Yinghai Lu
  2013-03-08  7:33           ` WANG Chao
  0 siblings, 1 reply; 101+ messages in thread
From: Yinghai Lu @ 2013-03-08  7:27 UTC (permalink / raw)
  To: WANG Chao; +Cc: CAI Qian, LKML, kexec, Dave Young, Vivek Goyal, H. Peter Anvin

On Thu, Mar 7, 2013 at 11:20 PM, WANG Chao <chaowang@redhat.com> wrote:
>>
>> looks like your system DO have DMAR table, please enable dmar
>> remapping in your kernel config.
>
> I've already got following config:
> CONFIG_DMAR_TABLE=y
> CONFIG_INTEL_IOMMU=y
> CONFIG_IRQ_REMAP=y
>
> but I don't have intel_iommu=on in kernel cmdline. IIRC, iommu will prevent
> 2nd kernel from booting ...

Did you put intel_iommu=on on first and second cpu both?

Thanks

Yinghai

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: 3.9-rc1: crash kernel panic - not syncing: Can not allocate SWIOTLB buffer earlier and can't now provide you with the DMA bounce buffer
  2013-03-08  7:27         ` Yinghai Lu
@ 2013-03-08  7:33           ` WANG Chao
  2013-03-08  7:50             ` Yinghai Lu
  2013-03-08  7:52             ` Takao Indoh
  0 siblings, 2 replies; 101+ messages in thread
From: WANG Chao @ 2013-03-08  7:33 UTC (permalink / raw)
  To: Yinghai Lu; +Cc: CAI Qian, LKML, kexec, Dave Young, Vivek Goyal, H. Peter Anvin

On 03/08/2013 03:27 PM, Yinghai Lu wrote:
> On Thu, Mar 7, 2013 at 11:20 PM, WANG Chao <chaowang@redhat.com> wrote:
>>>
>>> looks like your system DO have DMAR table, please enable dmar
>>> remapping in your kernel config.
>>
>> I've already got following config:
>> CONFIG_DMAR_TABLE=y
>> CONFIG_INTEL_IOMMU=y
>> CONFIG_IRQ_REMAP=y
>>
>> but I don't have intel_iommu=on in kernel cmdline. IIRC, iommu will prevent
>> 2nd kernel from booting ...
> 
> Did you put intel_iommu=on on first and second cpu both?

I tried, 2nd kernel didn't boot and keep splitting errors like these:
[    2.106939] DMAR: No ATSR found
[    2.110121] IOMMU 0 0xfed90000: using Queued invalidation
[    2.115522] IOMMU 1 0xfed91000: using Queued invalidation
[    2.120919] IOMMU: Setting RMRR:
[    2.124162] IOMMU: Setting identity map for device 0000:00:02.0 [0xab800000
- 0xaf9fffff]
[    2.133099] IOMMU: Setting identity map for device 0000:00:1d.0 [0xaac95000
- 0xaacb2fff]
[    2.141305] IOMMU: Setting identity map for device 0000:00:1a.0 [0xaac95000
- 0xaacb2fff]
[    2.149503] IOMMU: Setting identity map for device 0000:00:14.0 [0xaac95000
- 0xaacb2fff]
[    2.157690] IOMMU: Prepare 0-16MiB unity mapping for LPC
[    2.163011] IOMMU: Setting identity map for device 0000:00:1f.0 [0x0 - 0xffffff
[Errors, here we go]
[    2.170932] dmar: DRHD: handling fault status reg 3
[    2.170933] PCI-DMA: Intel(R) Virtualization Technology for Directed I/O
[    2.182486] dmar: DMAR:[DMA Write] Request device [00:02.0] fault addr ffffe000
[    2.182486] DMAR:[fault reason 05] PTE Write access is not set
[    2.195705] dmar: DRHD: handling fault status reg 3
[    2.200570] dmar: DMAR:[DMA Read] Request device [00:02.0] fault addr ff873000
[    2.200570] DMAR:[fault reason 06] PTE Read access is not set
[    2.213618] dmar: DRHD: handling fault status reg 3
[..]

Thanks,
WANG Chao
> 
> Thanks
> 
> Yinghai
> 


^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: 3.9-rc1: crash kernel panic - not syncing: Can not allocate SWIOTLB buffer earlier and can't now provide you with the DMA bounce buffer
  2013-03-08  7:33           ` WANG Chao
@ 2013-03-08  7:50             ` Yinghai Lu
  2013-03-08 12:12               ` WANG Chao
  2013-03-08  7:52             ` Takao Indoh
  1 sibling, 1 reply; 101+ messages in thread
From: Yinghai Lu @ 2013-03-08  7:50 UTC (permalink / raw)
  To: WANG Chao; +Cc: CAI Qian, LKML, kexec, Dave Young, Vivek Goyal, H. Peter Anvin

On Thu, Mar 7, 2013 at 11:33 PM, WANG Chao <chaowang@redhat.com> wrote:
> On 03/08/2013 03:27 PM, Yinghai Lu wrote:
>> On Thu, Mar 7, 2013 at 11:20 PM, WANG Chao <chaowang@redhat.com> wrote:
>>>>
>>>> looks like your system DO have DMAR table, please enable dmar
>>>> remapping in your kernel config.
>>>
>>> I've already got following config:
>>> CONFIG_DMAR_TABLE=y
>>> CONFIG_INTEL_IOMMU=y
>>> CONFIG_IRQ_REMAP=y
>>>
>>> but I don't have intel_iommu=on in kernel cmdline. IIRC, iommu will prevent
>>> 2nd kernel from booting ...
>>
>> Did you put intel_iommu=on on first and second cpu both?
>
> I tried, 2nd kernel didn't boot and keep splitting errors like these:
> [    2.106939] DMAR: No ATSR found
> [    2.110121] IOMMU 0 0xfed90000: using Queued invalidation
> [    2.115522] IOMMU 1 0xfed91000: using Queued invalidation
> [    2.120919] IOMMU: Setting RMRR:
> [    2.124162] IOMMU: Setting identity map for device 0000:00:02.0 [0xab800000
> - 0xaf9fffff]
> [    2.133099] IOMMU: Setting identity map for device 0000:00:1d.0 [0xaac95000
> - 0xaacb2fff]
> [    2.141305] IOMMU: Setting identity map for device 0000:00:1a.0 [0xaac95000
> - 0xaacb2fff]
> [    2.149503] IOMMU: Setting identity map for device 0000:00:14.0 [0xaac95000
> - 0xaacb2fff]
> [    2.157690] IOMMU: Prepare 0-16MiB unity mapping for LPC
> [    2.163011] IOMMU: Setting identity map for device 0000:00:1f.0 [0x0 - 0xffffff
> [Errors, here we go]
> [    2.170932] dmar: DRHD: handling fault status reg 3
> [    2.170933] PCI-DMA: Intel(R) Virtualization Technology for Directed I/O
> [    2.182486] dmar: DMAR:[DMA Write] Request device [00:02.0] fault addr ffffe000
> [    2.182486] DMAR:[fault reason 05] PTE Write access is not set
> [    2.195705] dmar: DRHD: handling fault status reg 3
> [    2.200570] dmar: DMAR:[DMA Read] Request device [00:02.0] fault addr ff873000
> [    2.200570] DMAR:[fault reason 06] PTE Read access is not set
> [    2.213618] dmar: DRHD: handling fault status reg 3

my Nehalem-EX and Westmere-EX is working with iommu enabled in second kernel.

what is 00:02.0 in your system?

Is your kernel upsteam kernel or redhat flavor one?

Thanks

Yinghai

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: 3.9-rc1: crash kernel panic - not syncing: Can not allocate SWIOTLB buffer earlier and can't now provide you with the DMA bounce buffer
  2013-03-08  7:33           ` WANG Chao
  2013-03-08  7:50             ` Yinghai Lu
@ 2013-03-08  7:52             ` Takao Indoh
  1 sibling, 0 replies; 101+ messages in thread
From: Takao Indoh @ 2013-03-08  7:52 UTC (permalink / raw)
  To: chaowang; +Cc: yinghai, caiqian, linux-kernel, kexec, dyoung, vgoyal, hpa

(2013/03/08 16:33), WANG Chao wrote:
> On 03/08/2013 03:27 PM, Yinghai Lu wrote:
>> On Thu, Mar 7, 2013 at 11:20 PM, WANG Chao <chaowang@redhat.com> wrote:
>>>>
>>>> looks like your system DO have DMAR table, please enable dmar
>>>> remapping in your kernel config.
>>>
>>> I've already got following config:
>>> CONFIG_DMAR_TABLE=y
>>> CONFIG_INTEL_IOMMU=y
>>> CONFIG_IRQ_REMAP=y
>>>
>>> but I don't have intel_iommu=on in kernel cmdline. IIRC, iommu will prevent
>>> 2nd kernel from booting ...
>>
>> Did you put intel_iommu=on on first and second cpu both?
>
> I tried, 2nd kernel didn't boot and keep splitting errors like these:
> [    2.106939] DMAR: No ATSR found
> [    2.110121] IOMMU 0 0xfed90000: using Queued invalidation
> [    2.115522] IOMMU 1 0xfed91000: using Queued invalidation
> [    2.120919] IOMMU: Setting RMRR:
> [    2.124162] IOMMU: Setting identity map for device 0000:00:02.0 [0xab800000
> - 0xaf9fffff]
> [    2.133099] IOMMU: Setting identity map for device 0000:00:1d.0 [0xaac95000
> - 0xaacb2fff]
> [    2.141305] IOMMU: Setting identity map for device 0000:00:1a.0 [0xaac95000
> - 0xaacb2fff]
> [    2.149503] IOMMU: Setting identity map for device 0000:00:14.0 [0xaac95000
> - 0xaacb2fff]
> [    2.157690] IOMMU: Prepare 0-16MiB unity mapping for LPC
> [    2.163011] IOMMU: Setting identity map for device 0000:00:1f.0 [0x0 - 0xffffff
> [Errors, here we go]
> [    2.170932] dmar: DRHD: handling fault status reg 3
> [    2.170933] PCI-DMA: Intel(R) Virtualization Technology for Directed I/O
> [    2.182486] dmar: DMAR:[DMA Write] Request device [00:02.0] fault addr ffffe000
> [    2.182486] DMAR:[fault reason 05] PTE Write access is not set
> [    2.195705] dmar: DRHD: handling fault status reg 3
> [    2.200570] dmar: DMAR:[DMA Read] Request device [00:02.0] fault addr ff873000
> [    2.200570] DMAR:[fault reason 06] PTE Read access is not set
> [    2.213618] dmar: DRHD: handling fault status reg 3
> [..]

This is the problem I'm working on.
https://lkml.org/lkml/2012/11/26/814

Thansk,
Takao Indoh


^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: 3.9-rc1: crash kernel panic - not syncing: Can not allocate SWIOTLB buffer earlier and can't now provide you with the DMA bounce buffer
  2013-03-08  7:50             ` Yinghai Lu
@ 2013-03-08 12:12               ` WANG Chao
  2013-03-08 18:24                 ` Yinghai Lu
  0 siblings, 1 reply; 101+ messages in thread
From: WANG Chao @ 2013-03-08 12:12 UTC (permalink / raw)
  To: Yinghai Lu
  Cc: CAI Qian, LKML, kexec, Dave Young, Vivek Goyal, H. Peter Anvin,
	Takao Indoh

[-- Attachment #1: Type: text/plain, Size: 3385 bytes --]

On 03/08/2013 03:50 PM, Yinghai Lu wrote:
> On Thu, Mar 7, 2013 at 11:33 PM, WANG Chao <chaowang@redhat.com> wrote:
>> On 03/08/2013 03:27 PM, Yinghai Lu wrote:
>>> On Thu, Mar 7, 2013 at 11:20 PM, WANG Chao <chaowang@redhat.com> wrote:
>>>>>
>>>>> looks like your system DO have DMAR table, please enable dmar
>>>>> remapping in your kernel config.
>>>>
>>>> I've already got following config:
>>>> CONFIG_DMAR_TABLE=y
>>>> CONFIG_INTEL_IOMMU=y
>>>> CONFIG_IRQ_REMAP=y
>>>>
>>>> but I don't have intel_iommu=on in kernel cmdline. IIRC, iommu will prevent
>>>> 2nd kernel from booting ...
>>>
>>> Did you put intel_iommu=on on first and second cpu both?
>>
>> I tried, 2nd kernel didn't boot and keep splitting errors like these:
>> [    2.106939] DMAR: No ATSR found
>> [    2.110121] IOMMU 0 0xfed90000: using Queued invalidation
>> [    2.115522] IOMMU 1 0xfed91000: using Queued invalidation
>> [    2.120919] IOMMU: Setting RMRR:
>> [    2.124162] IOMMU: Setting identity map for device 0000:00:02.0 [0xab800000
>> - 0xaf9fffff]
>> [    2.133099] IOMMU: Setting identity map for device 0000:00:1d.0 [0xaac95000
>> - 0xaacb2fff]
>> [    2.141305] IOMMU: Setting identity map for device 0000:00:1a.0 [0xaac95000
>> - 0xaacb2fff]
>> [    2.149503] IOMMU: Setting identity map for device 0000:00:14.0 [0xaac95000
>> - 0xaacb2fff]
>> [    2.157690] IOMMU: Prepare 0-16MiB unity mapping for LPC
>> [    2.163011] IOMMU: Setting identity map for device 0000:00:1f.0 [0x0 - 0xffffff
>> [Errors, here we go]
>> [    2.170932] dmar: DRHD: handling fault status reg 3
>> [    2.170933] PCI-DMA: Intel(R) Virtualization Technology for Directed I/O
>> [    2.182486] dmar: DMAR:[DMA Write] Request device [00:02.0] fault addr ffffe000
>> [    2.182486] DMAR:[fault reason 05] PTE Write access is not set
>> [    2.195705] dmar: DRHD: handling fault status reg 3
>> [    2.200570] dmar: DMAR:[DMA Read] Request device [00:02.0] fault addr ff873000
>> [    2.200570] DMAR:[fault reason 06] PTE Read access is not set
>> [    2.213618] dmar: DRHD: handling fault status reg 3
> 
> my Nehalem-EX and Westmere-EX is working with iommu enabled in second kernel.
> 
> what is 00:02.0 in your system?
This IOMMU issue is related to https://lkml.org/lkml/2012/11/26/814. We can
discuss this IOMMU issue in that thread.
Anyway 00:02.0 is a video card, the box is Ivy Bridge.
# lspci -s 00:02.0 -v
00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor
Graphics Controller (rev 09) (prog-if 00 [VGA controller])
        Subsystem: Intel Corporation Device 2211
        Flags: bus master, fast devsel, latency 0, IRQ 44
        Memory at afc00000 (64-bit, non-prefetchable) [size=4M]
        Memory at c0000000 (64-bit, prefetchable) [size=256M]
        I/O ports at 6000 [size=64]
        Expansion ROM at <unassigned> [disabled]
        Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
        Capabilities: [d0] Power Management version 2
        Capabilities: [a4] PCI Advanced Features
        Kernel driver in use: i915
> 
> Is your kernel upsteam kernel or redhat flavor one?
I'm using upstream vanilla kernel.
I put kernel config in attachment.


Is it expected to intel_iommu=on or crashkernel_low to make 2nd kernel boot in
3.9? Back in 3.8, it works just fine w/ only crashkernel param.

BTW, Have a good weekend!

Thanks,
WANG Chao

> 
> Thanks
> 
> Yinghai
> 


[-- Attachment #2: config --]
[-- Type: text/plain, Size: 122278 bytes --]

#
# Automatically generated file; DO NOT EDIT.
# Linux/x86 3.9.0-rc1 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_DEFAULT_IDLE=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_ARCH_HAS_CPU_AUTOPROBE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_HAVE_INTEL_TXT=y
CONFIG_X86_64_SMP=y
CONFIG_X86_HT=y
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx -fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 -fcall-saved-r11"
CONFIG_ARCH_CPU_PROBE_RELEASE=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
CONFIG_FHANDLE=y
CONFIG_AUDIT=y
CONFIG_AUDITSYSCALL=y
CONFIG_AUDIT_WATCH=y
CONFIG_AUDIT_TREE=y
# CONFIG_AUDIT_LOGINUID_IMMUTABLE is not set
CONFIG_HAVE_GENERIC_HARDIRQS=y

#
# IRQ subsystem
#
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_IRQ_DOMAIN=y
# CONFIG_IRQ_DOMAIN_DEBUG is not set
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_ALWAYS_USE_PERSISTENT_CLOCK=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y

#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y

#
# CPU/Task time and stats accounting
#
# CONFIG_TICK_CPU_ACCOUNTING is not set
# CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set
CONFIG_IRQ_TIME_ACCOUNTING=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

#
# RCU Subsystem
#
CONFIG_TREE_RCU=y
# CONFIG_PREEMPT_RCU is not set
CONFIG_RCU_STALL_COMMON=y
# CONFIG_RCU_USER_QS is not set
CONFIG_RCU_FANOUT=64
CONFIG_RCU_FANOUT_LEAF=16
# CONFIG_RCU_FANOUT_EXACT is not set
# CONFIG_RCU_FAST_NO_HZ is not set
# CONFIG_TREE_RCU_TRACE is not set
# CONFIG_RCU_NOCB_CPU is not set
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=19
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y
CONFIG_ARCH_WANTS_PROT_NUMA_PROT_NONE=y
# CONFIG_NUMA_BALANCING is not set
CONFIG_CGROUPS=y
# CONFIG_CGROUP_DEBUG is not set
CONFIG_CGROUP_FREEZER=y
CONFIG_CGROUP_DEVICE=y
CONFIG_CPUSETS=y
CONFIG_PROC_PID_CPUSET=y
CONFIG_CGROUP_CPUACCT=y
CONFIG_RESOURCE_COUNTERS=y
CONFIG_MEMCG=y
CONFIG_MEMCG_SWAP=y
CONFIG_MEMCG_SWAP_ENABLED=y
CONFIG_MEMCG_KMEM=y
# CONFIG_CGROUP_HUGETLB is not set
CONFIG_CGROUP_PERF=y
CONFIG_CGROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
CONFIG_CFS_BANDWIDTH=y
CONFIG_RT_GROUP_SCHED=y
CONFIG_BLK_CGROUP=y
# CONFIG_DEBUG_BLK_CGROUP is not set
# CONFIG_CHECKPOINT_RESTORE is not set
CONFIG_NAMESPACES=y
CONFIG_UTS_NS=y
CONFIG_IPC_NS=y
CONFIG_PID_NS=y
CONFIG_NET_NS=y
CONFIG_SCHED_AUTOGROUP=y
CONFIG_MM_OWNER=y
# CONFIG_SYSFS_DEPRECATED is not set
CONFIG_RELAY=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_RD_GZIP=y
CONFIG_RD_BZIP2=y
CONFIG_RD_LZMA=y
CONFIG_RD_XZ=y
CONFIG_RD_LZO=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
# CONFIG_EXPERT is not set
CONFIG_HAVE_UID16=y
CONFIG_UID16=y
# CONFIG_SYSCTL_SYSCALL is not set
CONFIG_SYSCTL_EXCEPTION_TRACE=y
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_PCSPKR_PLATFORM=y
CONFIG_HAVE_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_EMBEDDED is not set
CONFIG_HAVE_PERF_EVENTS=y

#
# Kernel Performance Events And Counters
#
CONFIG_PERF_EVENTS=y
# CONFIG_DEBUG_PERF_USE_VMALLOC is not set
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_PCI_QUIRKS=y
CONFIG_SLUB_DEBUG=y
# CONFIG_COMPAT_BRK is not set
# CONFIG_SLAB is not set
CONFIG_SLUB=y
CONFIG_PROFILING=y
CONFIG_TRACEPOINTS=y
CONFIG_OPROFILE=m
CONFIG_OPROFILE_EVENT_MULTIPLEX=y
CONFIG_HAVE_OPROFILE=y
CONFIG_OPROFILE_NMI_TIMER=y
CONFIG_KPROBES=y
CONFIG_JUMP_LABEL=y
CONFIG_OPTPROBES=y
CONFIG_KPROBES_ON_FTRACE=y
CONFIG_UPROBES=y
# CONFIG_HAVE_64BIT_ALIGNED_ACCESS is not set
CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y
CONFIG_ARCH_USE_BUILTIN_BSWAP=y
CONFIG_KRETPROBES=y
CONFIG_USER_RETURN_NOTIFIER=y
CONFIG_HAVE_IOREMAP_PROT=y
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_HAVE_OPTPROBES=y
CONFIG_HAVE_KPROBES_ON_FTRACE=y
CONFIG_HAVE_ARCH_TRACEHOOK=y
CONFIG_HAVE_DMA_ATTRS=y
CONFIG_USE_GENERIC_SMP_HELPERS=y
CONFIG_GENERIC_SMP_IDLE_THREAD=y
CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y
CONFIG_HAVE_DMA_API_DEBUG=y
CONFIG_HAVE_HW_BREAKPOINT=y
CONFIG_HAVE_MIXED_BREAKPOINTS_REGS=y
CONFIG_HAVE_USER_RETURN_NOTIFIER=y
CONFIG_HAVE_PERF_EVENTS_NMI=y
CONFIG_HAVE_PERF_REGS=y
CONFIG_HAVE_PERF_USER_STACK_DUMP=y
CONFIG_HAVE_ARCH_JUMP_LABEL=y
CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG=y
CONFIG_HAVE_ALIGNED_STRUCT_PAGE=y
CONFIG_HAVE_CMPXCHG_LOCAL=y
CONFIG_HAVE_CMPXCHG_DOUBLE=y
CONFIG_ARCH_WANT_COMPAT_IPC_PARSE_VERSION=y
CONFIG_ARCH_WANT_OLD_COMPAT_IPC=y
CONFIG_HAVE_VIRT_TO_BUS=y
CONFIG_HAVE_ARCH_SECCOMP_FILTER=y
CONFIG_HAVE_CONTEXT_TRACKING=y
CONFIG_HAVE_IRQ_TIME_ACCOUNTING=y
CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE=y
CONFIG_MODULES_USE_ELF_RELA=y
CONFIG_OLD_SIGSUSPEND3=y
CONFIG_COMPAT_OLD_SIGACTION=y

#
# GCOV-based kernel profiling
#
# CONFIG_GCOV_KERNEL 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=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
CONFIG_MODVERSIONS=y
CONFIG_MODULE_SRCVERSION_ALL=y
CONFIG_MODULE_SIG=y
# CONFIG_MODULE_SIG_FORCE is not set
CONFIG_MODULE_SIG_ALL=y
# CONFIG_MODULE_SIG_SHA1 is not set
# CONFIG_MODULE_SIG_SHA224 is not set
CONFIG_MODULE_SIG_SHA256=y
# CONFIG_MODULE_SIG_SHA384 is not set
# CONFIG_MODULE_SIG_SHA512 is not set
CONFIG_MODULE_SIG_HASH="sha256"
CONFIG_STOP_MACHINE=y
CONFIG_BLOCK=y
CONFIG_BLK_DEV_BSG=y
CONFIG_BLK_DEV_BSGLIB=y
CONFIG_BLK_DEV_INTEGRITY=y
CONFIG_BLK_DEV_THROTTLING=y

#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
CONFIG_OSF_PARTITION=y
CONFIG_AMIGA_PARTITION=y
# CONFIG_ATARI_PARTITION is not set
CONFIG_MAC_PARTITION=y
CONFIG_MSDOS_PARTITION=y
CONFIG_BSD_DISKLABEL=y
CONFIG_MINIX_SUBPARTITION=y
CONFIG_SOLARIS_X86_PARTITION=y
CONFIG_UNIXWARE_DISKLABEL=y
# CONFIG_LDM_PARTITION is not set
CONFIG_SGI_PARTITION=y
# CONFIG_ULTRIX_PARTITION is not set
CONFIG_SUN_PARTITION=y
CONFIG_KARMA_PARTITION=y
CONFIG_EFI_PARTITION=y
# CONFIG_SYSV68_PARTITION is not set
CONFIG_BLOCK_COMPAT=y

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
CONFIG_CFQ_GROUP_IOSCHED=y
CONFIG_DEFAULT_DEADLINE=y
# CONFIG_DEFAULT_CFQ is not set
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="deadline"
CONFIG_PREEMPT_NOTIFIERS=y
CONFIG_PADATA=y
CONFIG_ASN1=y
CONFIG_INLINE_SPIN_UNLOCK_IRQ=y
CONFIG_INLINE_READ_UNLOCK=y
CONFIG_INLINE_READ_UNLOCK_IRQ=y
CONFIG_INLINE_WRITE_UNLOCK=y
CONFIG_INLINE_WRITE_UNLOCK_IRQ=y
CONFIG_MUTEX_SPIN_ON_OWNER=y
CONFIG_FREEZER=y

#
# Processor type and features
#
CONFIG_ZONE_DMA=y
CONFIG_SMP=y
CONFIG_X86_X2APIC=y
CONFIG_X86_MPPARSE=y
CONFIG_X86_EXTENDED_PLATFORM=y
# CONFIG_X86_NUMACHIP is not set
# CONFIG_X86_VSMP is not set
CONFIG_X86_UV=y
# CONFIG_X86_INTEL_LPSS is not set
CONFIG_X86_SUPPORTS_MEMORY_FAILURE=y
CONFIG_SCHED_OMIT_FRAME_POINTER=y
CONFIG_PARAVIRT_GUEST=y
CONFIG_PARAVIRT_TIME_ACCOUNTING=y
CONFIG_XEN=y
CONFIG_XEN_DOM0=y
CONFIG_XEN_PRIVILEGED_GUEST=y
CONFIG_XEN_PVHVM=y
CONFIG_XEN_MAX_DOMAIN_MEMORY=500
CONFIG_XEN_SAVE_RESTORE=y
# CONFIG_XEN_DEBUG_FS is not set
CONFIG_KVM_GUEST=y
CONFIG_PARAVIRT=y
# CONFIG_PARAVIRT_SPINLOCKS is not set
CONFIG_PARAVIRT_CLOCK=y
# CONFIG_PARAVIRT_DEBUG is not set
CONFIG_NO_BOOTMEM=y
# CONFIG_MEMTEST is not set
# CONFIG_MK8 is not set
# CONFIG_MPSC is not set
# CONFIG_MCORE2 is not set
# CONFIG_MATOM is not set
CONFIG_GENERIC_CPU=y
CONFIG_X86_INTERNODE_CACHE_SHIFT=6
CONFIG_X86_L1_CACHE_SHIFT=6
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_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
CONFIG_DMI=y
CONFIG_GART_IOMMU=y
# CONFIG_CALGARY_IOMMU is not set
CONFIG_SWIOTLB=y
CONFIG_IOMMU_HELPER=y
CONFIG_MAXSMP=y
CONFIG_NR_CPUS=4096
CONFIG_SCHED_SMT=y
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=y
CONFIG_X86_MCE=y
CONFIG_X86_MCE_INTEL=y
CONFIG_X86_MCE_AMD=y
CONFIG_X86_MCE_THRESHOLD=y
CONFIG_X86_MCE_INJECT=m
CONFIG_X86_THERMAL_VECTOR=y
CONFIG_I8K=m
CONFIG_MICROCODE=m
CONFIG_MICROCODE_INTEL=y
CONFIG_MICROCODE_AMD=y
CONFIG_MICROCODE_OLD_INTERFACE=y
CONFIG_MICROCODE_INTEL_LIB=y
CONFIG_MICROCODE_INTEL_EARLY=y
CONFIG_MICROCODE_EARLY=y
CONFIG_X86_MSR=y
CONFIG_X86_CPUID=y
CONFIG_ARCH_PHYS_ADDR_T_64BIT=y
CONFIG_ARCH_DMA_ADDR_T_64BIT=y
CONFIG_DIRECT_GBPAGES=y
CONFIG_NUMA=y
CONFIG_AMD_NUMA=y
CONFIG_X86_64_ACPI_NUMA=y
CONFIG_NODES_SPAN_OTHER_NODES=y
# CONFIG_NUMA_EMU is not set
CONFIG_NODES_SHIFT=10
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_SPARSEMEM_DEFAULT=y
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
CONFIG_ARCH_MEMORY_PROBE=y
CONFIG_ARCH_PROC_KCORE_TEXT=y
CONFIG_ILLEGAL_POINTER_VALUE=0xdead000000000000
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_SPARSEMEM_MANUAL=y
CONFIG_SPARSEMEM=y
CONFIG_NEED_MULTIPLE_NODES=y
CONFIG_HAVE_MEMORY_PRESENT=y
CONFIG_SPARSEMEM_EXTREME=y
CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y
CONFIG_SPARSEMEM_ALLOC_MEM_MAP_TOGETHER=y
CONFIG_SPARSEMEM_VMEMMAP=y
CONFIG_HAVE_MEMBLOCK=y
CONFIG_HAVE_MEMBLOCK_NODE_MAP=y
CONFIG_ARCH_DISCARD_MEMBLOCK=y
CONFIG_MEMORY_ISOLATION=y
# CONFIG_MOVABLE_NODE is not set
CONFIG_HAVE_BOOTMEM_INFO_NODE=y
CONFIG_MEMORY_HOTPLUG=y
CONFIG_MEMORY_HOTPLUG_SPARSE=y
CONFIG_MEMORY_HOTREMOVE=y
CONFIG_PAGEFLAGS_EXTENDED=y
CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_BALLOON_COMPACTION=y
CONFIG_COMPACTION=y
CONFIG_MIGRATION=y
CONFIG_PHYS_ADDR_T_64BIT=y
CONFIG_ZONE_DMA_FLAG=1
CONFIG_BOUNCE=y
CONFIG_VIRT_TO_BUS=y
CONFIG_MMU_NOTIFIER=y
CONFIG_KSM=y
CONFIG_DEFAULT_MMAP_MIN_ADDR=4096
CONFIG_ARCH_SUPPORTS_MEMORY_FAILURE=y
CONFIG_MEMORY_FAILURE=y
CONFIG_HWPOISON_INJECT=m
CONFIG_TRANSPARENT_HUGEPAGE=y
CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y
# CONFIG_TRANSPARENT_HUGEPAGE_MADVISE is not set
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_CLEANCACHE=y
CONFIG_FRONTSWAP=y
CONFIG_X86_CHECK_BIOS_CORRUPTION=y
# CONFIG_X86_BOOTPARAM_MEMORY_CORRUPTION_CHECK is not set
CONFIG_X86_RESERVE_LOW=64
CONFIG_MTRR=y
CONFIG_MTRR_SANITIZER=y
CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=1
CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1
CONFIG_X86_PAT=y
CONFIG_ARCH_USES_PG_UNCACHED=y
CONFIG_ARCH_RANDOM=y
CONFIG_X86_SMAP=y
CONFIG_EFI=y
CONFIG_EFI_STUB=y
# CONFIG_SECCOMP is not set
CONFIG_CC_STACKPROTECTOR=y
# CONFIG_HZ_100 is not set
# CONFIG_HZ_250 is not set
# CONFIG_HZ_300 is not set
CONFIG_HZ_1000=y
CONFIG_HZ=1000
CONFIG_SCHED_HRTICK=y
CONFIG_KEXEC=y
CONFIG_CRASH_DUMP=y
CONFIG_KEXEC_JUMP=y
CONFIG_PHYSICAL_START=0x1000000
CONFIG_RELOCATABLE=y
CONFIG_PHYSICAL_ALIGN=0x1000000
CONFIG_HOTPLUG_CPU=y
# CONFIG_BOOTPARAM_HOTPLUG_CPU0 is not set
# CONFIG_DEBUG_HOTPLUG_CPU0 is not set
# CONFIG_COMPAT_VDSO is not set
# CONFIG_CMDLINE_BOOL is not set
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
CONFIG_ARCH_ENABLE_MEMORY_HOTREMOVE=y
CONFIG_USE_PERCPU_NUMA_NODE_ID=y

#
# Power management and ACPI options
#
CONFIG_ARCH_HIBERNATION_HEADER=y
CONFIG_SUSPEND=y
CONFIG_SUSPEND_FREEZER=y
CONFIG_HIBERNATE_CALLBACKS=y
CONFIG_HIBERNATION=y
CONFIG_PM_STD_PARTITION=""
CONFIG_PM_SLEEP=y
CONFIG_PM_SLEEP_SMP=y
# CONFIG_PM_AUTOSLEEP is not set
# CONFIG_PM_WAKELOCKS is not set
CONFIG_PM_RUNTIME=y
CONFIG_PM=y
# CONFIG_PM_DEBUG is not set
CONFIG_ACPI=y
CONFIG_ACPI_SLEEP=y
CONFIG_ACPI_PROCFS=y
# CONFIG_ACPI_PROCFS_POWER is not set
CONFIG_ACPI_EC_DEBUGFS=m
# CONFIG_ACPI_PROC_EVENT is not set
CONFIG_ACPI_AC=y
CONFIG_ACPI_BATTERY=y
CONFIG_ACPI_BUTTON=y
CONFIG_ACPI_VIDEO=m
CONFIG_ACPI_FAN=y
CONFIG_ACPI_DOCK=y
CONFIG_ACPI_I2C=m
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_IPMI=m
CONFIG_ACPI_HOTPLUG_CPU=y
CONFIG_ACPI_PROCESSOR_AGGREGATOR=m
CONFIG_ACPI_THERMAL=y
CONFIG_ACPI_NUMA=y
# CONFIG_ACPI_CUSTOM_DSDT is not set
# CONFIG_ACPI_INITRD_TABLE_OVERRIDE is not set
CONFIG_ACPI_BLACKLIST_YEAR=0
# CONFIG_ACPI_DEBUG is not set
CONFIG_ACPI_PCI_SLOT=y
CONFIG_X86_PM_TIMER=y
CONFIG_ACPI_CONTAINER=y
CONFIG_ACPI_HOTPLUG_MEMORY=y
CONFIG_ACPI_SBS=m
CONFIG_ACPI_HED=y
CONFIG_ACPI_CUSTOM_METHOD=m
CONFIG_ACPI_BGRT=y
CONFIG_ACPI_APEI=y
CONFIG_ACPI_APEI_GHES=y
CONFIG_ACPI_APEI_PCIEAER=y
CONFIG_ACPI_APEI_MEMORY_FAILURE=y
# CONFIG_ACPI_APEI_EINJ is not set
# CONFIG_ACPI_APEI_ERST_DEBUG is not set
CONFIG_SFI=y

#
# CPU Frequency scaling
#
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_TABLE=y
CONFIG_CPU_FREQ_GOV_COMMON=y
CONFIG_CPU_FREQ_STAT=m
CONFIG_CPU_FREQ_STAT_DETAILS=y
# CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE 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=y
CONFIG_CPU_FREQ_GOV_USERSPACE=y
CONFIG_CPU_FREQ_GOV_ONDEMAND=y
CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y

#
# x86 CPU frequency scaling drivers
#
# CONFIG_X86_INTEL_PSTATE is not set
CONFIG_X86_PCC_CPUFREQ=m
CONFIG_X86_ACPI_CPUFREQ=y
CONFIG_X86_ACPI_CPUFREQ_CPB=y
CONFIG_X86_POWERNOW_K8=y
# CONFIG_X86_SPEEDSTEP_CENTRINO is not set
CONFIG_X86_P4_CLOCKMOD=y

#
# shared options
#
CONFIG_X86_SPEEDSTEP_LIB=y
CONFIG_CPU_IDLE=y
# CONFIG_CPU_IDLE_MULTIPLE_DRIVERS is not set
CONFIG_CPU_IDLE_GOV_LADDER=y
CONFIG_CPU_IDLE_GOV_MENU=y
# CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED is not set
CONFIG_INTEL_IDLE=y

#
# Memory power savings
#
CONFIG_I7300_IDLE_IOAT_CHANNEL=y
CONFIG_I7300_IDLE=m

#
# Bus options (PCI etc.)
#
CONFIG_PCI=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_MMCONFIG=y
CONFIG_PCI_XEN=y
CONFIG_PCI_DOMAINS=y
CONFIG_PCIEPORTBUS=y
CONFIG_HOTPLUG_PCI_PCIE=y
CONFIG_PCIEAER=y
CONFIG_PCIE_ECRC=y
CONFIG_PCIEAER_INJECT=m
CONFIG_PCIEASPM=y
# CONFIG_PCIEASPM_DEBUG is not set
CONFIG_PCIEASPM_DEFAULT=y
# CONFIG_PCIEASPM_POWERSAVE is not set
# CONFIG_PCIEASPM_PERFORMANCE is not set
CONFIG_PCIE_PME=y
CONFIG_ARCH_SUPPORTS_MSI=y
CONFIG_PCI_MSI=y
# CONFIG_PCI_DEBUG is not set
# CONFIG_PCI_REALLOC_ENABLE_AUTO is not set
CONFIG_PCI_STUB=y
# CONFIG_XEN_PCIDEV_FRONTEND is not set
CONFIG_HT_IRQ=y
CONFIG_PCI_ATS=y
CONFIG_PCI_IOV=y
CONFIG_PCI_PRI=y
CONFIG_PCI_PASID=y
CONFIG_PCI_IOAPIC=y
CONFIG_PCI_LABEL=y
CONFIG_ISA_DMA_API=y
CONFIG_AMD_NB=y
CONFIG_PCCARD=y
CONFIG_PCMCIA=y
CONFIG_PCMCIA_LOAD_CIS=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=y
CONFIG_HOTPLUG_PCI=y
CONFIG_HOTPLUG_PCI_ACPI=y
CONFIG_HOTPLUG_PCI_ACPI_IBM=m
# CONFIG_HOTPLUG_PCI_CPCI is not set
CONFIG_HOTPLUG_PCI_SHPC=m
# CONFIG_RAPIDIO is not set

#
# Executable file formats / Emulations
#
CONFIG_BINFMT_ELF=y
CONFIG_COMPAT_BINFMT_ELF=y
CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE=y
CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS=y
# CONFIG_HAVE_AOUT is not set
CONFIG_BINFMT_MISC=m
CONFIG_COREDUMP=y
CONFIG_IA32_EMULATION=y
# CONFIG_IA32_AOUT is not set
# CONFIG_X86_X32 is not set
CONFIG_COMPAT=y
CONFIG_COMPAT_FOR_U64_ALIGNMENT=y
CONFIG_SYSVIPC_COMPAT=y
CONFIG_KEYS_COMPAT=y
CONFIG_HAVE_TEXT_POKE_SMP=y
CONFIG_X86_DEV_DMA_OPS=y
CONFIG_NET=y
CONFIG_COMPAT_NETLINK_MESSAGES=y

#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_DIAG is not set
CONFIG_UNIX=y
CONFIG_UNIX_DIAG=m
CONFIG_XFRM=y
CONFIG_XFRM_ALGO=y
CONFIG_XFRM_USER=y
CONFIG_XFRM_SUB_POLICY=y
CONFIG_XFRM_MIGRATE=y
CONFIG_XFRM_STATISTICS=y
CONFIG_XFRM_IPCOMP=m
CONFIG_NET_KEY=m
CONFIG_NET_KEY_MIGRATE=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_IP_FIB_TRIE_STATS=y
CONFIG_IP_MULTIPLE_TABLES=y
CONFIG_IP_ROUTE_MULTIPATH=y
CONFIG_IP_ROUTE_VERBOSE=y
CONFIG_IP_ROUTE_CLASSID=y
# CONFIG_IP_PNP is not set
CONFIG_NET_IPIP=m
CONFIG_NET_IPGRE_DEMUX=m
CONFIG_NET_IPGRE=m
CONFIG_NET_IPGRE_BROADCAST=y
CONFIG_IP_MROUTE=y
CONFIG_IP_MROUTE_MULTIPLE_TABLES=y
CONFIG_IP_PIMSM_V1=y
CONFIG_IP_PIMSM_V2=y
# CONFIG_ARPD is not set
CONFIG_SYN_COOKIES=y
CONFIG_NET_IPVTI=m
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_INET_UDP_DIAG=m
CONFIG_TCP_CONG_ADVANCED=y
CONFIG_TCP_CONG_BIC=m
CONFIG_TCP_CONG_CUBIC=y
CONFIG_TCP_CONG_WESTWOOD=m
CONFIG_TCP_CONG_HTCP=m
CONFIG_TCP_CONG_HSTCP=m
CONFIG_TCP_CONG_HYBLA=m
CONFIG_TCP_CONG_VEGAS=m
CONFIG_TCP_CONG_SCALABLE=m
CONFIG_TCP_CONG_LP=m
CONFIG_TCP_CONG_VENO=m
CONFIG_TCP_CONG_YEAH=m
CONFIG_TCP_CONG_ILLINOIS=m
CONFIG_DEFAULT_CUBIC=y
# CONFIG_DEFAULT_RENO is not set
CONFIG_DEFAULT_TCP_CONG="cubic"
CONFIG_TCP_MD5SIG=y
CONFIG_IPV6=y
CONFIG_IPV6_PRIVACY=y
CONFIG_IPV6_ROUTER_PREF=y
CONFIG_IPV6_ROUTE_INFO=y
CONFIG_IPV6_OPTIMISTIC_DAD=y
CONFIG_INET6_AH=m
CONFIG_INET6_ESP=m
CONFIG_INET6_IPCOMP=m
CONFIG_IPV6_MIP6=m
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_SIT_6RD=y
CONFIG_IPV6_NDISC_NODETYPE=y
CONFIG_IPV6_TUNNEL=m
# CONFIG_IPV6_GRE is not set
CONFIG_IPV6_MULTIPLE_TABLES=y
# CONFIG_IPV6_SUBTREES is not set
CONFIG_IPV6_MROUTE=y
CONFIG_IPV6_MROUTE_MULTIPLE_TABLES=y
CONFIG_IPV6_PIMSM_V2=y
CONFIG_NETLABEL=y
CONFIG_NETWORK_SECMARK=y
CONFIG_NETWORK_PHY_TIMESTAMPING=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_ACCT=m
CONFIG_NETFILTER_NETLINK_QUEUE=m
CONFIG_NETFILTER_NETLINK_LOG=m
CONFIG_NF_CONNTRACK=m
CONFIG_NF_CONNTRACK_MARK=y
CONFIG_NF_CONNTRACK_SECMARK=y
CONFIG_NF_CONNTRACK_ZONES=y
CONFIG_NF_CONNTRACK_PROCFS=y
CONFIG_NF_CONNTRACK_EVENTS=y
# CONFIG_NF_CONNTRACK_TIMEOUT is not set
CONFIG_NF_CONNTRACK_TIMESTAMP=y
CONFIG_NF_CT_PROTO_DCCP=m
CONFIG_NF_CT_PROTO_GRE=m
CONFIG_NF_CT_PROTO_SCTP=m
CONFIG_NF_CT_PROTO_UDPLITE=m
CONFIG_NF_CONNTRACK_AMANDA=m
CONFIG_NF_CONNTRACK_FTP=m
CONFIG_NF_CONNTRACK_H323=m
CONFIG_NF_CONNTRACK_IRC=m
CONFIG_NF_CONNTRACK_BROADCAST=m
CONFIG_NF_CONNTRACK_NETBIOS_NS=m
CONFIG_NF_CONNTRACK_SNMP=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_NF_CT_NETLINK_TIMEOUT is not set
CONFIG_NF_CT_NETLINK_HELPER=m
CONFIG_NETFILTER_NETLINK_QUEUE_CT=y
CONFIG_NF_NAT=m
CONFIG_NF_NAT_NEEDED=y
CONFIG_NF_NAT_PROTO_DCCP=m
CONFIG_NF_NAT_PROTO_UDPLITE=m
CONFIG_NF_NAT_PROTO_SCTP=m
CONFIG_NF_NAT_AMANDA=m
CONFIG_NF_NAT_FTP=m
CONFIG_NF_NAT_IRC=m
CONFIG_NF_NAT_SIP=m
CONFIG_NF_NAT_TFTP=m
CONFIG_NETFILTER_TPROXY=m
CONFIG_NETFILTER_XTABLES=y

#
# Xtables combined modules
#
CONFIG_NETFILTER_XT_MARK=m
CONFIG_NETFILTER_XT_CONNMARK=m
CONFIG_NETFILTER_XT_SET=m

#
# Xtables targets
#
CONFIG_NETFILTER_XT_TARGET_AUDIT=m
CONFIG_NETFILTER_XT_TARGET_CHECKSUM=m
CONFIG_NETFILTER_XT_TARGET_CLASSIFY=m
CONFIG_NETFILTER_XT_TARGET_CONNMARK=m
CONFIG_NETFILTER_XT_TARGET_CONNSECMARK=m
CONFIG_NETFILTER_XT_TARGET_CT=m
CONFIG_NETFILTER_XT_TARGET_DSCP=m
CONFIG_NETFILTER_XT_TARGET_HL=m
CONFIG_NETFILTER_XT_TARGET_HMARK=m
CONFIG_NETFILTER_XT_TARGET_IDLETIMER=m
CONFIG_NETFILTER_XT_TARGET_LED=m
CONFIG_NETFILTER_XT_TARGET_LOG=m
CONFIG_NETFILTER_XT_TARGET_MARK=m
CONFIG_NETFILTER_XT_TARGET_NETMAP=m
CONFIG_NETFILTER_XT_TARGET_NFLOG=m
CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m
# CONFIG_NETFILTER_XT_TARGET_NOTRACK is not set
CONFIG_NETFILTER_XT_TARGET_RATEEST=m
CONFIG_NETFILTER_XT_TARGET_REDIRECT=m
CONFIG_NETFILTER_XT_TARGET_TEE=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

#
# Xtables matches
#
CONFIG_NETFILTER_XT_MATCH_ADDRTYPE=m
# CONFIG_NETFILTER_XT_MATCH_BPF is not set
CONFIG_NETFILTER_XT_MATCH_CLUSTER=m
CONFIG_NETFILTER_XT_MATCH_COMMENT=m
CONFIG_NETFILTER_XT_MATCH_CONNBYTES=m
# CONFIG_NETFILTER_XT_MATCH_CONNLABEL is not set
CONFIG_NETFILTER_XT_MATCH_CONNLIMIT=m
CONFIG_NETFILTER_XT_MATCH_CONNMARK=m
CONFIG_NETFILTER_XT_MATCH_CONNTRACK=m
CONFIG_NETFILTER_XT_MATCH_CPU=m
CONFIG_NETFILTER_XT_MATCH_DCCP=m
CONFIG_NETFILTER_XT_MATCH_DEVGROUP=m
CONFIG_NETFILTER_XT_MATCH_DSCP=m
CONFIG_NETFILTER_XT_MATCH_ECN=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_IPVS=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_NFACCT=m
CONFIG_NETFILTER_XT_MATCH_OSF=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_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_IP_SET=m
CONFIG_IP_SET_MAX=256
CONFIG_IP_SET_BITMAP_IP=m
CONFIG_IP_SET_BITMAP_IPMAC=m
CONFIG_IP_SET_BITMAP_PORT=m
CONFIG_IP_SET_HASH_IP=m
CONFIG_IP_SET_HASH_IPPORT=m
CONFIG_IP_SET_HASH_IPPORTIP=m
CONFIG_IP_SET_HASH_IPPORTNET=m
CONFIG_IP_SET_HASH_NET=m
CONFIG_IP_SET_HASH_NETPORT=m
CONFIG_IP_SET_HASH_NETIFACE=m
CONFIG_IP_SET_LIST_SET=m
CONFIG_IP_VS=m
CONFIG_IP_VS_IPV6=y
# CONFIG_IP_VS_DEBUG is not set
CONFIG_IP_VS_TAB_BITS=12

#
# IPVS transport protocol load balancing support
#
CONFIG_IP_VS_PROTO_TCP=y
CONFIG_IP_VS_PROTO_UDP=y
CONFIG_IP_VS_PROTO_AH_ESP=y
CONFIG_IP_VS_PROTO_ESP=y
CONFIG_IP_VS_PROTO_AH=y
CONFIG_IP_VS_PROTO_SCTP=y

#
# IPVS scheduler
#
CONFIG_IP_VS_RR=m
CONFIG_IP_VS_WRR=m
CONFIG_IP_VS_LC=m
CONFIG_IP_VS_WLC=m
CONFIG_IP_VS_LBLC=m
CONFIG_IP_VS_LBLCR=m
CONFIG_IP_VS_DH=m
CONFIG_IP_VS_SH=m
CONFIG_IP_VS_SED=m
CONFIG_IP_VS_NQ=m

#
# IPVS SH scheduler
#
CONFIG_IP_VS_SH_TAB_BITS=8

#
# IPVS application helper
#
CONFIG_IP_VS_FTP=m
CONFIG_IP_VS_NFCT=y
CONFIG_IP_VS_PE_SIP=m

#
# IP: Netfilter Configuration
#
CONFIG_NF_DEFRAG_IPV4=m
CONFIG_NF_CONNTRACK_IPV4=m
# CONFIG_NF_CONNTRACK_PROC_COMPAT is not set
CONFIG_IP_NF_QUEUE=m
CONFIG_IP_NF_IPTABLES=m
CONFIG_IP_NF_MATCH_AH=m
CONFIG_IP_NF_MATCH_ECN=m
CONFIG_IP_NF_MATCH_RPFILTER=m
CONFIG_IP_NF_MATCH_TTL=m
CONFIG_IP_NF_FILTER=m
CONFIG_IP_NF_TARGET_REJECT=m
CONFIG_IP_NF_TARGET_ULOG=m
CONFIG_NF_NAT_IPV4=m
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_PPTP=m
CONFIG_NF_NAT_H323=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=m
CONFIG_IP_NF_ARPTABLES=m
CONFIG_IP_NF_ARPFILTER=m
CONFIG_IP_NF_ARP_MANGLE=m

#
# IPv6: Netfilter Configuration
#
CONFIG_NF_DEFRAG_IPV6=m
CONFIG_NF_CONNTRACK_IPV6=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_RPFILTER=m
CONFIG_IP6_NF_MATCH_RT=m
CONFIG_IP6_NF_TARGET_HL=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=m
CONFIG_NF_NAT_IPV6=m
# CONFIG_IP6_NF_TARGET_MASQUERADE is not set
# CONFIG_IP6_NF_TARGET_NPT is not set
CONFIG_BRIDGE_NF_EBTABLES=m
CONFIG_BRIDGE_EBT_BROUTE=m
CONFIG_BRIDGE_EBT_T_FILTER=m
CONFIG_BRIDGE_EBT_T_NAT=m
CONFIG_BRIDGE_EBT_802_3=m
CONFIG_BRIDGE_EBT_AMONG=m
CONFIG_BRIDGE_EBT_ARP=m
CONFIG_BRIDGE_EBT_IP=m
CONFIG_BRIDGE_EBT_IP6=m
CONFIG_BRIDGE_EBT_LIMIT=m
CONFIG_BRIDGE_EBT_MARK=m
CONFIG_BRIDGE_EBT_PKTTYPE=m
CONFIG_BRIDGE_EBT_STP=m
CONFIG_BRIDGE_EBT_VLAN=m
CONFIG_BRIDGE_EBT_ARPREPLY=m
CONFIG_BRIDGE_EBT_DNAT=m
CONFIG_BRIDGE_EBT_MARK_T=m
CONFIG_BRIDGE_EBT_REDIRECT=m
CONFIG_BRIDGE_EBT_SNAT=m
CONFIG_BRIDGE_EBT_LOG=m
CONFIG_BRIDGE_EBT_ULOG=m
CONFIG_BRIDGE_EBT_NFLOG=m
CONFIG_IP_DCCP=m
CONFIG_INET_DCCP_DIAG=m

#
# DCCP CCIDs Configuration
#
# CONFIG_IP_DCCP_CCID2_DEBUG is not set
CONFIG_IP_DCCP_CCID3=y
# CONFIG_IP_DCCP_CCID3_DEBUG is not set
CONFIG_IP_DCCP_TFRC_LIB=y

#
# DCCP Kernel Hacking
#
# CONFIG_IP_DCCP_DEBUG is not set
# CONFIG_NET_DCCPPROBE is not set
CONFIG_IP_SCTP=m
CONFIG_NET_SCTPPROBE=m
# CONFIG_SCTP_DBG_MSG is not set
# CONFIG_SCTP_DBG_OBJCNT is not set
CONFIG_SCTP_DEFAULT_COOKIE_HMAC_MD5=y
# CONFIG_SCTP_DEFAULT_COOKIE_HMAC_SHA1 is not set
# CONFIG_SCTP_DEFAULT_COOKIE_HMAC_NONE is not set
CONFIG_SCTP_COOKIE_HMAC_MD5=y
# CONFIG_SCTP_COOKIE_HMAC_SHA1 is not set
CONFIG_RDS=m
CONFIG_RDS_RDMA=m
CONFIG_RDS_TCP=m
# CONFIG_RDS_DEBUG is not set
# CONFIG_TIPC is not set
CONFIG_ATM=m
CONFIG_ATM_CLIP=m
# CONFIG_ATM_CLIP_NO_ICMP is not set
CONFIG_ATM_LANE=m
# CONFIG_ATM_MPOA is not set
CONFIG_ATM_BR2684=m
# CONFIG_ATM_BR2684_IPFILTER is not set
CONFIG_L2TP=m
CONFIG_L2TP_DEBUGFS=m
CONFIG_L2TP_V3=y
CONFIG_L2TP_IP=m
CONFIG_L2TP_ETH=m
CONFIG_STP=m
CONFIG_GARP=m
CONFIG_BRIDGE=m
CONFIG_BRIDGE_IGMP_SNOOPING=y
# CONFIG_BRIDGE_VLAN_FILTERING is not set
CONFIG_HAVE_NET_DSA=y
CONFIG_NET_DSA=m
CONFIG_NET_DSA_TAG_DSA=y
CONFIG_NET_DSA_TAG_EDSA=y
CONFIG_NET_DSA_TAG_TRAILER=y
CONFIG_VLAN_8021Q=m
CONFIG_VLAN_8021Q_GVRP=y
# CONFIG_VLAN_8021Q_MVRP 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_PHONET is not set
CONFIG_IEEE802154=m
CONFIG_IEEE802154_6LOWPAN=m
CONFIG_MAC802154=m
CONFIG_NET_SCHED=y

#
# Queueing/Scheduling
#
CONFIG_NET_SCH_CBQ=m
CONFIG_NET_SCH_HTB=m
CONFIG_NET_SCH_HFSC=m
CONFIG_NET_SCH_ATM=m
CONFIG_NET_SCH_PRIO=m
CONFIG_NET_SCH_MULTIQ=m
CONFIG_NET_SCH_RED=m
CONFIG_NET_SCH_SFB=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=m
CONFIG_NET_SCH_MQPRIO=m
CONFIG_NET_SCH_CHOKE=m
CONFIG_NET_SCH_QFQ=m
CONFIG_NET_SCH_CODEL=m
CONFIG_NET_SCH_FQ_CODEL=m
CONFIG_NET_SCH_INGRESS=m
CONFIG_NET_SCH_PLUG=m

#
# Classification
#
CONFIG_NET_CLS=y
CONFIG_NET_CLS_BASIC=m
CONFIG_NET_CLS_TCINDEX=m
CONFIG_NET_CLS_ROUTE4=m
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=m
CONFIG_NET_CLS_CGROUP=y
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_EMATCH_IPSET=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=m
CONFIG_NET_ACT_CSUM=m
CONFIG_NET_CLS_IND=y
CONFIG_NET_SCH_FIFO=y
CONFIG_DCB=y
CONFIG_DNS_RESOLVER=m
CONFIG_BATMAN_ADV=m
CONFIG_BATMAN_ADV_BLA=y
# CONFIG_BATMAN_ADV_DAT is not set
# CONFIG_BATMAN_ADV_DEBUG is not set
CONFIG_OPENVSWITCH=m
# CONFIG_VSOCKETS is not set
CONFIG_RPS=y
CONFIG_RFS_ACCEL=y
CONFIG_XPS=y
CONFIG_NETPRIO_CGROUP=m
CONFIG_BQL=y
CONFIG_BPF_JIT=y

#
# Network testing
#
CONFIG_NET_PKTGEN=m
# CONFIG_NET_TCPPROBE is not set
CONFIG_NET_DROP_MONITOR=y
# CONFIG_HAMRADIO is not set
# CONFIG_CAN is not set
# CONFIG_IRDA is not set
CONFIG_BT=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_CMTP=m
CONFIG_BT_HIDP=m

#
# Bluetooth device drivers
#
CONFIG_BT_HCIBTUSB=m
CONFIG_BT_HCIBTSDIO=m
CONFIG_BT_HCIUART=m
CONFIG_BT_HCIUART_H4=y
CONFIG_BT_HCIUART_BCSP=y
CONFIG_BT_HCIUART_ATH3K=y
CONFIG_BT_HCIUART_LL=y
CONFIG_BT_HCIUART_3WIRE=y
CONFIG_BT_HCIBCM203X=m
CONFIG_BT_HCIBPA10X=m
CONFIG_BT_HCIBFUSB=m
CONFIG_BT_HCIDTL1=m
CONFIG_BT_HCIBT3C=m
CONFIG_BT_HCIBLUECARD=m
CONFIG_BT_HCIBTUART=m
CONFIG_BT_HCIVHCI=m
CONFIG_BT_MRVL=m
CONFIG_BT_MRVL_SDIO=m
CONFIG_BT_ATH3K=m
# CONFIG_AF_RXRPC is not set
CONFIG_FIB_RULES=y
CONFIG_WIRELESS=y
CONFIG_WIRELESS_EXT=y
CONFIG_WEXT_CORE=y
CONFIG_WEXT_PROC=y
CONFIG_WEXT_SPY=y
CONFIG_WEXT_PRIV=y
CONFIG_CFG80211=m
# CONFIG_NL80211_TESTMODE is not set
# CONFIG_CFG80211_DEVELOPER_WARNINGS is not set
# CONFIG_CFG80211_REG_DEBUG is not set
CONFIG_CFG80211_DEFAULT_PS=y
# CONFIG_CFG80211_DEBUGFS is not set
# CONFIG_CFG80211_INTERNAL_REGDB is not set
CONFIG_CFG80211_WEXT=y
CONFIG_LIB80211=m
CONFIG_LIB80211_CRYPT_WEP=m
CONFIG_LIB80211_CRYPT_CCMP=m
CONFIG_LIB80211_CRYPT_TKIP=m
# CONFIG_LIB80211_DEBUG is not set
CONFIG_MAC80211=m
CONFIG_MAC80211_HAS_RC=y
CONFIG_MAC80211_RC_MINSTREL=y
CONFIG_MAC80211_RC_MINSTREL_HT=y
CONFIG_MAC80211_RC_DEFAULT_MINSTREL=y
CONFIG_MAC80211_RC_DEFAULT="minstrel_ht"
# CONFIG_MAC80211_MESH is not set
CONFIG_MAC80211_LEDS=y
# CONFIG_MAC80211_DEBUGFS is not set
# CONFIG_MAC80211_MESSAGE_TRACING is not set
# CONFIG_MAC80211_DEBUG_MENU is not set
CONFIG_WIMAX=m
CONFIG_WIMAX_DEBUG_LEVEL=8
CONFIG_RFKILL=m
CONFIG_RFKILL_LEDS=y
CONFIG_RFKILL_INPUT=y
CONFIG_NET_9P=m
CONFIG_NET_9P_VIRTIO=m
CONFIG_NET_9P_RDMA=m
# CONFIG_NET_9P_DEBUG is not set
# CONFIG_CAIF is not set
# CONFIG_CEPH_LIB is not set
CONFIG_NFC=m
CONFIG_NFC_NCI=m
CONFIG_NFC_HCI=m
CONFIG_NFC_SHDLC=y
CONFIG_NFC_LLCP=y

#
# Near Field Communication (NFC) devices
#
CONFIG_NFC_PN533=m
# CONFIG_NFC_PN544 is not set
# CONFIG_NFC_MICROREAD is not set
CONFIG_HAVE_BPF_JIT=y

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER_PATH=""
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
# CONFIG_FIRMWARE_IN_KERNEL is not set
CONFIG_EXTRA_FIRMWARE=""
CONFIG_FW_LOADER_USER_HELPER=y
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_DEBUG_DEVRES is not set
CONFIG_SYS_HYPERVISOR=y
# CONFIG_GENERIC_CPU_DEVICES is not set
CONFIG_REGMAP=y
CONFIG_REGMAP_I2C=m
CONFIG_DMA_SHARED_BUFFER=y

#
# Bus devices
#
CONFIG_CONNECTOR=y
CONFIG_PROC_EVENTS=y
CONFIG_MTD=m
# CONFIG_MTD_TESTS is not set
# CONFIG_MTD_REDBOOT_PARTS is not set
# CONFIG_MTD_CMDLINE_PARTS is not set
# CONFIG_MTD_AR7_PARTS is not set

#
# User Modules And Translation Layers
#
CONFIG_MTD_CHAR=m
# 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_SM_FTL is not set
# CONFIG_MTD_OOPS is not set
# CONFIG_MTD_SWAP 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_DOCG3 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
CONFIG_MTD_UBI=m
CONFIG_MTD_UBI_WL_THRESHOLD=4096
CONFIG_MTD_UBI_BEB_LIMIT=20
# CONFIG_MTD_UBI_FASTMAP is not set
# CONFIG_MTD_UBI_GLUEBI is not set
CONFIG_PARPORT=m
CONFIG_PARPORT_PC=m
CONFIG_PARPORT_SERIAL=m
# CONFIG_PARPORT_PC_FIFO is not set
# CONFIG_PARPORT_PC_SUPERIO is not set
CONFIG_PARPORT_PC_PCMCIA=m
# CONFIG_PARPORT_GSC is not set
# CONFIG_PARPORT_AX88796 is not set
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_DEV_PCIESSD_MTIP32XX=m
# CONFIG_BLK_CPQ_DA is not set
CONFIG_BLK_CPQ_CISS_DA=m
CONFIG_CISS_SCSI_TAPE=y
# 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=y
CONFIG_BLK_DEV_LOOP_MIN_COUNT=8
CONFIG_BLK_DEV_CRYPTOLOOP=m
# CONFIG_BLK_DEV_DRBD is not set
# CONFIG_BLK_DEV_NBD is not set
CONFIG_BLK_DEV_NVME=m
CONFIG_BLK_DEV_OSD=m
CONFIG_BLK_DEV_SX8=m
CONFIG_BLK_DEV_RAM=m
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=16384
# 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=m
CONFIG_XEN_BLKDEV_FRONTEND=m
# CONFIG_XEN_BLKDEV_BACKEND is not set
CONFIG_VIRTIO_BLK=m
# CONFIG_BLK_DEV_HD is not set
# CONFIG_BLK_DEV_RBD is not set
# CONFIG_BLK_DEV_RSXX is not set

#
# Misc devices
#
CONFIG_SENSORS_LIS3LV02D=m
# CONFIG_AD525X_DPOT is not set
# CONFIG_IBM_ASM is not set
# CONFIG_PHANTOM is not set
# CONFIG_INTEL_MID_PTI is not set
CONFIG_SGI_IOC4=m
CONFIG_TIFM_CORE=m
CONFIG_TIFM_7XX1=m
# CONFIG_ICS932S401 is not set
# CONFIG_ATMEL_SSC is not set
CONFIG_ENCLOSURE_SERVICES=m
CONFIG_SGI_XP=m
CONFIG_HP_ILO=m
CONFIG_SGI_GRU=m
# CONFIG_SGI_GRU_DEBUG is not set
CONFIG_APDS9802ALS=m
CONFIG_ISL29003=m
CONFIG_ISL29020=m
CONFIG_SENSORS_TSL2550=m
# CONFIG_SENSORS_BH1780 is not set
CONFIG_SENSORS_BH1770=m
CONFIG_SENSORS_APDS990X=m
# CONFIG_HMC6352 is not set
# CONFIG_DS1682 is not set
CONFIG_VMWARE_BALLOON=m
# CONFIG_BMP085_I2C is not set
CONFIG_PCH_PHUB=m
# CONFIG_USB_SWITCH_FSA9480 is not set
# CONFIG_C2PORT is not set

#
# EEPROM support
#
CONFIG_EEPROM_AT24=m
CONFIG_EEPROM_LEGACY=m
CONFIG_EEPROM_MAX6875=m
CONFIG_EEPROM_93CX6=m
CONFIG_CB710_CORE=m
# CONFIG_CB710_DEBUG is not set
CONFIG_CB710_DEBUG_ASSUMPTIONS=y

#
# Texas Instruments shared transport line discipline
#
CONFIG_SENSORS_LIS3_I2C=m

#
# Altera FPGA firmware download module
#
CONFIG_ALTERA_STAPL=m
CONFIG_INTEL_MEI=m
CONFIG_INTEL_MEI_ME=y
# CONFIG_VMWARE_VMCI is not set
CONFIG_HAVE_IDE=y
# CONFIG_IDE is not set

#
# SCSI device support
#
CONFIG_SCSI_MOD=y
CONFIG_RAID_ATTRS=m
CONFIG_SCSI=y
CONFIG_SCSI_DMA=y
CONFIG_SCSI_TGT=m
CONFIG_SCSI_NETLINK=y
CONFIG_SCSI_PROC_FS=y

#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=m
CONFIG_CHR_DEV_ST=m
CONFIG_CHR_DEV_OSST=m
CONFIG_BLK_DEV_SR=m
CONFIG_BLK_DEV_SR_VENDOR=y
CONFIG_CHR_DEV_SG=m
CONFIG_CHR_DEV_SCH=m
CONFIG_SCSI_ENCLOSURE=m
CONFIG_SCSI_MULTI_LUN=y
CONFIG_SCSI_CONSTANTS=y
CONFIG_SCSI_LOGGING=y
CONFIG_SCSI_SCAN_ASYNC=y

#
# SCSI Transports
#
CONFIG_SCSI_SPI_ATTRS=m
CONFIG_SCSI_FC_ATTRS=m
CONFIG_SCSI_FC_TGT_ATTRS=y
CONFIG_SCSI_ISCSI_ATTRS=m
CONFIG_SCSI_SAS_ATTRS=m
CONFIG_SCSI_SAS_LIBSAS=m
CONFIG_SCSI_SAS_ATA=y
CONFIG_SCSI_SAS_HOST_SMP=y
CONFIG_SCSI_SRP_ATTRS=m
CONFIG_SCSI_SRP_TGT_ATTRS=y
CONFIG_SCSI_LOWLEVEL=y
CONFIG_ISCSI_TCP=m
CONFIG_ISCSI_BOOT_SYSFS=m
CONFIG_SCSI_CXGB3_ISCSI=m
CONFIG_SCSI_CXGB4_ISCSI=m
CONFIG_SCSI_BNX2_ISCSI=m
CONFIG_SCSI_BNX2X_FCOE=m
CONFIG_BE2ISCSI=m
CONFIG_BLK_DEV_3W_XXXX_RAID=m
CONFIG_SCSI_HPSA=m
CONFIG_SCSI_3W_9XXX=m
CONFIG_SCSI_3W_SAS=m
# CONFIG_SCSI_ACARD is not set
CONFIG_SCSI_AACRAID=m
# CONFIG_SCSI_AIC7XXX is not set
# CONFIG_SCSI_AIC7XXX_OLD is not set
CONFIG_SCSI_AIC79XX=m
CONFIG_AIC79XX_CMDS_PER_DEVICE=4
CONFIG_AIC79XX_RESET_DELAY_MS=15000
# CONFIG_AIC79XX_DEBUG_ENABLE is not set
CONFIG_AIC79XX_DEBUG_MASK=0
# CONFIG_AIC79XX_REG_PRETTY_PRINT is not set
CONFIG_SCSI_AIC94XX=m
# CONFIG_AIC94XX_DEBUG is not set
CONFIG_SCSI_MVSAS=m
# CONFIG_SCSI_MVSAS_DEBUG is not set
CONFIG_SCSI_MVSAS_TASKLET=y
CONFIG_SCSI_MVUMI=m
# CONFIG_SCSI_DPT_I2O is not set
# CONFIG_SCSI_ADVANSYS is not set
CONFIG_SCSI_ARCMSR=m
CONFIG_MEGARAID_NEWGEN=y
CONFIG_MEGARAID_MM=m
# CONFIG_MEGARAID_MAILBOX is not set
# CONFIG_MEGARAID_LEGACY is not set
CONFIG_MEGARAID_SAS=m
CONFIG_SCSI_MPT2SAS=m
CONFIG_SCSI_MPT2SAS_MAX_SGE=128
CONFIG_SCSI_MPT2SAS_LOGGING=y
# CONFIG_SCSI_MPT3SAS is not set
CONFIG_SCSI_UFSHCD=m
# CONFIG_SCSI_UFSHCD_PCI is not set
CONFIG_SCSI_HPTIOP=m
# CONFIG_SCSI_BUSLOGIC is not set
CONFIG_VMWARE_PVSCSI=m
CONFIG_HYPERV_STORAGE=m
CONFIG_LIBFC=m
CONFIG_LIBFCOE=m
CONFIG_FCOE=m
CONFIG_FCOE_FNIC=m
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
# CONFIG_SCSI_GDTH is not set
CONFIG_SCSI_ISCI=m
# CONFIG_SCSI_IPS is not set
CONFIG_SCSI_INITIO=m
# CONFIG_SCSI_INIA100 is not set
# CONFIG_SCSI_PPA is not set
# CONFIG_SCSI_IMM is not set
CONFIG_SCSI_STEX=m
# CONFIG_SCSI_SYM53C8XX_2 is not set
CONFIG_SCSI_IPR=m
CONFIG_SCSI_IPR_TRACE=y
CONFIG_SCSI_IPR_DUMP=y
# CONFIG_SCSI_QLOGIC_1280 is not set
CONFIG_SCSI_QLA_FC=m
CONFIG_TCM_QLA2XXX=m
CONFIG_SCSI_QLA_ISCSI=m
CONFIG_SCSI_LPFC=m
# CONFIG_SCSI_LPFC_DEBUG_FS is not set
# CONFIG_SCSI_DC395x is not set
# CONFIG_SCSI_DC390T is not set
CONFIG_SCSI_DEBUG=m
CONFIG_SCSI_PMCRAID=m
CONFIG_SCSI_PM8001=m
CONFIG_SCSI_SRP=m
CONFIG_SCSI_BFA_FC=m
CONFIG_SCSI_VIRTIO=m
# CONFIG_SCSI_CHELSIO_FCOE is not set
# CONFIG_SCSI_LOWLEVEL_PCMCIA is not set
CONFIG_SCSI_DH=y
CONFIG_SCSI_DH_RDAC=y
CONFIG_SCSI_DH_HP_SW=y
CONFIG_SCSI_DH_EMC=y
CONFIG_SCSI_DH_ALUA=y
CONFIG_SCSI_OSD_INITIATOR=m
CONFIG_SCSI_OSD_ULD=m
CONFIG_SCSI_OSD_DPRINT_SENSE=1
# CONFIG_SCSI_OSD_DEBUG is not set
CONFIG_ATA=m
# CONFIG_ATA_NONSTANDARD is not set
CONFIG_ATA_VERBOSE_ERROR=y
CONFIG_ATA_ACPI=y
# CONFIG_SATA_ZPODD is not set
CONFIG_SATA_PMP=y

#
# Controllers with non-SFF native interface
#
CONFIG_SATA_AHCI=m
CONFIG_SATA_AHCI_PLATFORM=m
CONFIG_SATA_INIC162X=m
CONFIG_SATA_ACARD_AHCI=m
CONFIG_SATA_SIL24=m
CONFIG_ATA_SFF=y

#
# SFF controllers with custom DMA interface
#
CONFIG_PDC_ADMA=m
CONFIG_SATA_QSTOR=m
CONFIG_SATA_SX4=m
CONFIG_ATA_BMDMA=y

#
# SATA SFF controllers with BMDMA
#
CONFIG_ATA_PIIX=m
# CONFIG_SATA_HIGHBANK is not set
CONFIG_SATA_MV=m
CONFIG_SATA_NV=m
CONFIG_SATA_PROMISE=m
CONFIG_SATA_SIL=m
CONFIG_SATA_SIS=m
CONFIG_SATA_SVW=m
CONFIG_SATA_ULI=m
CONFIG_SATA_VIA=m
CONFIG_SATA_VITESSE=m

#
# PATA SFF controllers with BMDMA
#
CONFIG_PATA_ALI=m
CONFIG_PATA_AMD=m
CONFIG_PATA_ARASAN_CF=m
CONFIG_PATA_ARTOP=m
CONFIG_PATA_ATIIXP=m
CONFIG_PATA_ATP867X=m
CONFIG_PATA_CMD64X=m
# CONFIG_PATA_CS5520 is not set
# CONFIG_PATA_CS5530 is not set
CONFIG_PATA_CS5536=m
# CONFIG_PATA_CYPRESS is not set
# CONFIG_PATA_EFAR is not set
CONFIG_PATA_HPT366=m
CONFIG_PATA_HPT37X=m
CONFIG_PATA_HPT3X2N=m
CONFIG_PATA_HPT3X3=m
# CONFIG_PATA_HPT3X3_DMA is not set
CONFIG_PATA_IT8213=m
CONFIG_PATA_IT821X=m
CONFIG_PATA_JMICRON=m
CONFIG_PATA_MARVELL=m
CONFIG_PATA_NETCELL=m
CONFIG_PATA_NINJA32=m
# CONFIG_PATA_NS87415 is not set
CONFIG_PATA_OLDPIIX=m
# CONFIG_PATA_OPTIDMA is not set
CONFIG_PATA_PDC2027X=m
CONFIG_PATA_PDC_OLD=m
# CONFIG_PATA_RADISYS is not set
CONFIG_PATA_RDC=m
# CONFIG_PATA_SC1200 is not set
CONFIG_PATA_SCH=m
CONFIG_PATA_SERVERWORKS=m
CONFIG_PATA_SIL680=m
CONFIG_PATA_SIS=m
CONFIG_PATA_TOSHIBA=m
# CONFIG_PATA_TRIFLEX is not set
CONFIG_PATA_VIA=m
# CONFIG_PATA_WINBOND is not set

#
# PIO-only SFF controllers
#
# CONFIG_PATA_CMD640_PCI is not set
# CONFIG_PATA_MPIIX is not set
# CONFIG_PATA_NS87410 is not set
# CONFIG_PATA_OPTI is not set
CONFIG_PATA_PCMCIA=m
# CONFIG_PATA_RZ1000 is not set

#
# Generic fallback / legacy drivers
#
CONFIG_PATA_ACPI=m
CONFIG_ATA_GENERIC=m
# CONFIG_PATA_LEGACY is not set
CONFIG_MD=y
CONFIG_BLK_DEV_MD=y
CONFIG_MD_AUTODETECT=y
CONFIG_MD_LINEAR=m
CONFIG_MD_RAID0=m
CONFIG_MD_RAID1=m
CONFIG_MD_RAID10=m
CONFIG_MD_RAID456=m
# CONFIG_MD_MULTIPATH is not set
CONFIG_MD_FAULTY=m
CONFIG_BLK_DEV_DM=m
CONFIG_DM_DEBUG=y
CONFIG_DM_BUFIO=m
CONFIG_DM_BIO_PRISON=m
CONFIG_DM_PERSISTENT_DATA=m
CONFIG_DM_CRYPT=m
CONFIG_DM_SNAPSHOT=m
CONFIG_DM_THIN_PROVISIONING=m
# CONFIG_DM_DEBUG_BLOCK_STACK_TRACING is not set
# CONFIG_DM_CACHE is not set
CONFIG_DM_MIRROR=m
CONFIG_DM_RAID=m
CONFIG_DM_LOG_USERSPACE=m
CONFIG_DM_ZERO=m
CONFIG_DM_MULTIPATH=m
CONFIG_DM_MULTIPATH_QL=m
CONFIG_DM_MULTIPATH_ST=m
CONFIG_DM_DELAY=m
CONFIG_DM_UEVENT=y
CONFIG_DM_FLAKEY=m
CONFIG_DM_VERITY=m
CONFIG_TARGET_CORE=m
CONFIG_TCM_IBLOCK=m
CONFIG_TCM_FILEIO=m
CONFIG_TCM_PSCSI=m
CONFIG_LOOPBACK_TARGET=m
CONFIG_TCM_FC=m
CONFIG_ISCSI_TARGET=m
CONFIG_SBP_TARGET=m
CONFIG_FUSION=y
CONFIG_FUSION_SPI=m
# CONFIG_FUSION_FC is not set
CONFIG_FUSION_SAS=m
CONFIG_FUSION_MAX_SGE=128
CONFIG_FUSION_CTL=m
CONFIG_FUSION_LOGGING=y

#
# IEEE 1394 (FireWire) support
#
CONFIG_FIREWIRE=m
CONFIG_FIREWIRE_OHCI=m
CONFIG_FIREWIRE_SBP2=m
CONFIG_FIREWIRE_NET=m
CONFIG_FIREWIRE_NOSY=m
# CONFIG_I2O is not set
CONFIG_MACINTOSH_DRIVERS=y
CONFIG_MAC_EMUMOUSEBTN=y
CONFIG_NETDEVICES=y
CONFIG_NET_CORE=y
CONFIG_BONDING=m
CONFIG_DUMMY=m
# CONFIG_EQUALIZER is not set
CONFIG_NET_FC=y
CONFIG_MII=m
CONFIG_IFB=m
CONFIG_NET_TEAM=m
CONFIG_NET_TEAM_MODE_BROADCAST=m
CONFIG_NET_TEAM_MODE_ROUNDROBIN=m
CONFIG_NET_TEAM_MODE_ACTIVEBACKUP=m
CONFIG_NET_TEAM_MODE_LOADBALANCE=m
CONFIG_MACVLAN=m
CONFIG_MACVTAP=m
CONFIG_VXLAN=m
CONFIG_NETCONSOLE=m
CONFIG_NETCONSOLE_DYNAMIC=y
CONFIG_NETPOLL=y
CONFIG_NETPOLL_TRAP=y
CONFIG_NET_POLL_CONTROLLER=y
CONFIG_TUN=m
CONFIG_VETH=m
CONFIG_VIRTIO_NET=m
CONFIG_SUNGEM_PHY=m
# CONFIG_ARCNET is not set
CONFIG_ATM_DRIVERS=y
# CONFIG_ATM_DUMMY is not set
CONFIG_ATM_TCP=m
# CONFIG_ATM_LANAI is not set
# CONFIG_ATM_ENI is not set
# CONFIG_ATM_FIRESTREAM is not set
# CONFIG_ATM_ZATM is not set
# CONFIG_ATM_NICSTAR is not set
# CONFIG_ATM_IDT77252 is not set
# CONFIG_ATM_AMBASSADOR is not set
# CONFIG_ATM_HORIZON is not set
# CONFIG_ATM_IA is not set
# CONFIG_ATM_FORE200E is not set
CONFIG_ATM_HE=m
# CONFIG_ATM_HE_USE_SUNI is not set
# CONFIG_ATM_SOLOS is not set

#
# CAIF transport drivers
#

#
# Distributed Switch Architecture drivers
#
CONFIG_NET_DSA_MV88E6XXX=m
CONFIG_NET_DSA_MV88E6060=m
CONFIG_NET_DSA_MV88E6XXX_NEED_PPU=y
CONFIG_NET_DSA_MV88E6131=m
CONFIG_NET_DSA_MV88E6123_61_65=m
CONFIG_ETHERNET=y
CONFIG_MDIO=m
CONFIG_NET_VENDOR_3COM=y
CONFIG_PCMCIA_3C574=m
CONFIG_PCMCIA_3C589=m
CONFIG_VORTEX=m
CONFIG_TYPHOON=m
CONFIG_NET_VENDOR_ADAPTEC=y
CONFIG_ADAPTEC_STARFIRE=m
CONFIG_NET_VENDOR_ALTEON=y
CONFIG_ACENIC=m
# CONFIG_ACENIC_OMIT_TIGON_I is not set
CONFIG_NET_VENDOR_AMD=y
CONFIG_AMD8111_ETH=m
CONFIG_PCNET32=m
CONFIG_PCMCIA_NMCLAN=m
CONFIG_NET_VENDOR_ATHEROS=y
CONFIG_ATL2=m
CONFIG_ATL1=m
CONFIG_ATL1E=m
CONFIG_ATL1C=m
CONFIG_NET_CADENCE=y
# CONFIG_ARM_AT91_ETHER is not set
# CONFIG_MACB is not set
CONFIG_NET_VENDOR_BROADCOM=y
CONFIG_B44=m
CONFIG_B44_PCI_AUTOSELECT=y
CONFIG_B44_PCICORE_AUTOSELECT=y
CONFIG_B44_PCI=y
CONFIG_BNX2=m
CONFIG_CNIC=m
CONFIG_TIGON3=m
CONFIG_BNX2X=m
CONFIG_BNX2X_SRIOV=y
CONFIG_NET_VENDOR_BROCADE=y
CONFIG_BNA=m
CONFIG_NET_CALXEDA_XGMAC=m
CONFIG_NET_VENDOR_CHELSIO=y
CONFIG_CHELSIO_T1=m
CONFIG_CHELSIO_T1_1G=y
CONFIG_CHELSIO_T3=m
CONFIG_CHELSIO_T4=m
CONFIG_CHELSIO_T4VF=m
CONFIG_NET_VENDOR_CISCO=y
CONFIG_ENIC=m
CONFIG_DNET=m
CONFIG_NET_VENDOR_DEC=y
CONFIG_NET_TULIP=y
CONFIG_DE2104X=m
CONFIG_DE2104X_DSL=0
CONFIG_TULIP=m
# CONFIG_TULIP_MWI is not set
CONFIG_TULIP_MMIO=y
# CONFIG_TULIP_NAPI is not set
CONFIG_DE4X5=m
CONFIG_WINBOND_840=m
CONFIG_DM9102=m
CONFIG_ULI526X=m
CONFIG_PCMCIA_XIRCOM=m
CONFIG_NET_VENDOR_DLINK=y
CONFIG_DL2K=m
CONFIG_SUNDANCE=m
# CONFIG_SUNDANCE_MMIO is not set
CONFIG_NET_VENDOR_EMULEX=y
CONFIG_BE2NET=m
CONFIG_NET_VENDOR_EXAR=y
CONFIG_S2IO=m
CONFIG_VXGE=m
# CONFIG_VXGE_DEBUG_TRACE_ALL is not set
# CONFIG_NET_VENDOR_FUJITSU is not set
# CONFIG_NET_VENDOR_HP is not set
CONFIG_NET_VENDOR_INTEL=y
CONFIG_E100=m
CONFIG_E1000=m
CONFIG_E1000E=m
CONFIG_IGB=m
CONFIG_IGB_HWMON=y
CONFIG_IGB_DCA=y
CONFIG_IGBVF=m
CONFIG_IXGB=m
CONFIG_IXGBE=m
CONFIG_IXGBE_HWMON=y
CONFIG_IXGBE_DCA=y
CONFIG_IXGBE_DCB=y
CONFIG_IXGBEVF=m
# CONFIG_NET_VENDOR_I825XX is not set
CONFIG_IP1000=m
CONFIG_JME=m
CONFIG_NET_VENDOR_MARVELL=y
# CONFIG_MVMDIO is not set
CONFIG_SKGE=m
# CONFIG_SKGE_DEBUG is not set
CONFIG_SKGE_GENESIS=y
CONFIG_SKY2=m
# CONFIG_SKY2_DEBUG is not set
CONFIG_NET_VENDOR_MELLANOX=y
CONFIG_MLX4_EN=m
CONFIG_MLX4_EN_DCB=y
CONFIG_MLX4_CORE=m
CONFIG_MLX4_DEBUG=y
CONFIG_NET_VENDOR_MICREL=y
# CONFIG_KS8842 is not set
# CONFIG_KS8851_MLL is not set
CONFIG_KSZ884X_PCI=m
CONFIG_NET_VENDOR_MYRI=y
CONFIG_MYRI10GE=m
CONFIG_MYRI10GE_DCA=y
CONFIG_FEALNX=m
CONFIG_NET_VENDOR_NATSEMI=y
CONFIG_NATSEMI=m
CONFIG_NS83820=m
CONFIG_NET_VENDOR_8390=y
CONFIG_PCMCIA_AXNET=m
CONFIG_NE2K_PCI=m
CONFIG_PCMCIA_PCNET=m
CONFIG_NET_VENDOR_NVIDIA=y
CONFIG_FORCEDETH=m
CONFIG_NET_VENDOR_OKI=y
CONFIG_PCH_GBE=m
CONFIG_ETHOC=m
CONFIG_NET_PACKET_ENGINE=y
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
CONFIG_NET_VENDOR_QLOGIC=y
CONFIG_QLA3XXX=m
CONFIG_QLCNIC=m
CONFIG_QLGE=m
CONFIG_NETXEN_NIC=m
CONFIG_NET_VENDOR_REALTEK=y
# CONFIG_ATP is not set
CONFIG_8139CP=m
CONFIG_8139TOO=m
# CONFIG_8139TOO_PIO is not set
# CONFIG_8139TOO_TUNE_TWISTER is not set
CONFIG_8139TOO_8129=y
# CONFIG_8139_OLD_RX_RESET is not set
CONFIG_R8169=m
CONFIG_NET_VENDOR_RDC=y
CONFIG_R6040=m
# CONFIG_NET_VENDOR_SEEQ is not set
CONFIG_NET_VENDOR_SILAN=y
CONFIG_SC92031=m
CONFIG_NET_VENDOR_SIS=y
CONFIG_SIS900=m
CONFIG_SIS190=m
CONFIG_SFC=m
# CONFIG_SFC_MTD is not set
CONFIG_SFC_MCDI_MON=y
CONFIG_SFC_SRIOV=y
CONFIG_NET_VENDOR_SMSC=y
CONFIG_PCMCIA_SMC91C92=m
CONFIG_EPIC100=m
CONFIG_SMSC9420=m
CONFIG_NET_VENDOR_STMICRO=y
CONFIG_STMMAC_ETH=m
# CONFIG_STMMAC_PLATFORM is not set
# CONFIG_STMMAC_PCI is not set
# CONFIG_STMMAC_DEBUG_FS is not set
# CONFIG_STMMAC_DA is not set
CONFIG_STMMAC_RING=y
# CONFIG_STMMAC_CHAINED is not set
CONFIG_NET_VENDOR_SUN=y
CONFIG_HAPPYMEAL=m
CONFIG_SUNGEM=m
CONFIG_CASSINI=m
CONFIG_NIU=m
CONFIG_NET_VENDOR_TEHUTI=y
CONFIG_TEHUTI=m
CONFIG_NET_VENDOR_TI=y
CONFIG_TLAN=m
CONFIG_NET_VENDOR_VIA=y
CONFIG_VIA_RHINE=m
CONFIG_VIA_RHINE_MMIO=y
CONFIG_VIA_VELOCITY=m
CONFIG_NET_VENDOR_WIZNET=y
CONFIG_WIZNET_W5100=m
CONFIG_WIZNET_W5300=m
# CONFIG_WIZNET_BUS_DIRECT is not set
# CONFIG_WIZNET_BUS_INDIRECT is not set
CONFIG_WIZNET_BUS_ANY=y
CONFIG_NET_VENDOR_XIRCOM=y
CONFIG_PCMCIA_XIRC2PS=m
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_NET_SB1000 is not set
CONFIG_PHYLIB=y

#
# MII PHY device drivers
#
CONFIG_AT803X_PHY=m
CONFIG_AMD_PHY=m
CONFIG_MARVELL_PHY=m
CONFIG_DAVICOM_PHY=m
CONFIG_QSEMI_PHY=m
CONFIG_LXT_PHY=m
CONFIG_CICADA_PHY=m
CONFIG_VITESSE_PHY=m
CONFIG_SMSC_PHY=m
CONFIG_BROADCOM_PHY=m
CONFIG_BCM87XX_PHY=m
CONFIG_ICPLUS_PHY=m
CONFIG_REALTEK_PHY=m
CONFIG_NATIONAL_PHY=m
CONFIG_STE10XP=m
CONFIG_LSI_ET1011C_PHY=m
CONFIG_MICREL_PHY=m
CONFIG_FIXED_PHY=y
CONFIG_MDIO_BITBANG=m
# CONFIG_PLIP is not set
CONFIG_PPP=m
CONFIG_PPP_BSDCOMP=m
CONFIG_PPP_DEFLATE=m
CONFIG_PPP_FILTER=y
CONFIG_PPP_MPPE=m
CONFIG_PPP_MULTILINK=y
CONFIG_PPPOATM=m
CONFIG_PPPOE=m
CONFIG_PPTP=m
CONFIG_PPPOL2TP=m
CONFIG_PPP_ASYNC=m
CONFIG_PPP_SYNC_TTY=m
CONFIG_SLIP=m
CONFIG_SLHC=m
CONFIG_SLIP_COMPRESSED=y
CONFIG_SLIP_SMART=y
# CONFIG_SLIP_MODE_SLIP6 is not set

#
# USB Network Adapters
#
CONFIG_USB_CATC=m
CONFIG_USB_KAWETH=m
CONFIG_USB_PEGASUS=m
CONFIG_USB_RTL8150=m
CONFIG_USB_USBNET=m
CONFIG_USB_NET_AX8817X=m
CONFIG_USB_NET_AX88179_178A=m
CONFIG_USB_NET_CDCETHER=m
CONFIG_USB_NET_CDC_EEM=m
CONFIG_USB_NET_CDC_NCM=m
# CONFIG_USB_NET_CDC_MBIM is not set
CONFIG_USB_NET_DM9601=m
CONFIG_USB_NET_SMSC75XX=m
CONFIG_USB_NET_SMSC95XX=m
CONFIG_USB_NET_GL620A=m
CONFIG_USB_NET_NET1080=m
CONFIG_USB_NET_PLUSB=m
CONFIG_USB_NET_MCS7830=m
CONFIG_USB_NET_RNDIS_HOST=m
CONFIG_USB_NET_CDC_SUBSET=m
CONFIG_USB_ALI_M5632=y
CONFIG_USB_AN2720=y
CONFIG_USB_BELKIN=y
CONFIG_USB_ARMLINUX=y
CONFIG_USB_EPSON2888=y
CONFIG_USB_KC2190=y
CONFIG_USB_NET_ZAURUS=m
CONFIG_USB_NET_CX82310_ETH=m
CONFIG_USB_NET_KALMIA=m
CONFIG_USB_NET_QMI_WWAN=m
CONFIG_USB_HSO=m
CONFIG_USB_NET_INT51X1=m
CONFIG_USB_IPHETH=m
CONFIG_USB_SIERRA_NET=m
CONFIG_USB_VL600=m
CONFIG_WLAN=y
# CONFIG_PCMCIA_RAYCS is not set
# CONFIG_LIBERTAS_THINFIRM is not set
# CONFIG_AIRO is not set
# CONFIG_ATMEL is not set
CONFIG_AT76C50X_USB=m
# 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=m
CONFIG_RTL8180=m
CONFIG_RTL8187=m
CONFIG_RTL8187_LEDS=y
# CONFIG_ADM8211 is not set
CONFIG_MAC80211_HWSIM=m
CONFIG_MWL8K=m
# CONFIG_ATH_CARDS is not set
CONFIG_B43=m
CONFIG_B43_BCMA=y
# CONFIG_B43_BCMA_EXTRA is not set
CONFIG_B43_SSB=y
CONFIG_B43_PCI_AUTOSELECT=y
CONFIG_B43_PCICORE_AUTOSELECT=y
CONFIG_B43_PCMCIA=y
CONFIG_B43_SDIO=y
CONFIG_B43_BCMA_PIO=y
CONFIG_B43_PIO=y
CONFIG_B43_PHY_N=y
CONFIG_B43_PHY_LP=y
CONFIG_B43_PHY_HT=y
CONFIG_B43_LEDS=y
CONFIG_B43_HWRNG=y
# CONFIG_B43_DEBUG is not set
CONFIG_B43LEGACY=m
CONFIG_B43LEGACY_PCI_AUTOSELECT=y
CONFIG_B43LEGACY_PCICORE_AUTOSELECT=y
CONFIG_B43LEGACY_LEDS=y
CONFIG_B43LEGACY_HWRNG=y
# CONFIG_B43LEGACY_DEBUG is not set
CONFIG_B43LEGACY_DMA=y
CONFIG_B43LEGACY_PIO=y
CONFIG_B43LEGACY_DMA_AND_PIO_MODE=y
# CONFIG_B43LEGACY_DMA_MODE is not set
# CONFIG_B43LEGACY_PIO_MODE is not set
CONFIG_BRCMUTIL=m
CONFIG_BRCMSMAC=m
CONFIG_BRCMFMAC=m
CONFIG_BRCMFMAC_SDIO=y
CONFIG_BRCMFMAC_SDIO_OOB=y
CONFIG_BRCMFMAC_USB=y
# CONFIG_BRCM_TRACING is not set
# CONFIG_BRCMDBG is not set
# CONFIG_HOSTAP is not set
CONFIG_IPW2100=m
CONFIG_IPW2100_MONITOR=y
# CONFIG_IPW2100_DEBUG is not set
CONFIG_IPW2200=m
CONFIG_IPW2200_MONITOR=y
CONFIG_IPW2200_RADIOTAP=y
CONFIG_IPW2200_PROMISCUOUS=y
CONFIG_IPW2200_QOS=y
# CONFIG_IPW2200_DEBUG is not set
CONFIG_LIBIPW=m
# CONFIG_LIBIPW_DEBUG is not set
CONFIG_IWLWIFI=m
CONFIG_IWLDVM=m
# CONFIG_IWLMVM is not set

#
# Debugging Options
#
# CONFIG_IWLWIFI_DEBUG is not set
# CONFIG_IWLWIFI_DEVICE_TRACING is not set
# CONFIG_IWLWIFI_P2P is not set
CONFIG_IWLEGACY=m
CONFIG_IWL4965=m
CONFIG_IWL3945=m

#
# iwl3945 / iwl4965 Debugging Options
#
CONFIG_IWLEGACY_DEBUG=y
CONFIG_LIBERTAS=m
CONFIG_LIBERTAS_USB=m
CONFIG_LIBERTAS_CS=m
CONFIG_LIBERTAS_SDIO=m
# CONFIG_LIBERTAS_DEBUG is not set
CONFIG_LIBERTAS_MESH=y
# CONFIG_HERMES is not set
CONFIG_P54_COMMON=m
CONFIG_P54_USB=m
CONFIG_P54_PCI=m
CONFIG_P54_LEDS=y
CONFIG_RT2X00=m
CONFIG_RT2400PCI=m
CONFIG_RT2500PCI=m
CONFIG_RT61PCI=m
CONFIG_RT2800PCI=m
CONFIG_RT2800PCI_RT33XX=y
CONFIG_RT2800PCI_RT35XX=y
CONFIG_RT2800PCI_RT53XX=y
CONFIG_RT2800PCI_RT3290=y
CONFIG_RT2500USB=m
CONFIG_RT73USB=m
# CONFIG_RT2800USB is not set
CONFIG_RT2800_LIB=m
CONFIG_RT2X00_LIB_PCI=m
CONFIG_RT2X00_LIB_USB=m
CONFIG_RT2X00_LIB=m
CONFIG_RT2X00_LIB_FIRMWARE=y
CONFIG_RT2X00_LIB_CRYPTO=y
CONFIG_RT2X00_LIB_LEDS=y
# CONFIG_RT2X00_DEBUG is not set
CONFIG_RTLWIFI=m
# CONFIG_RTLWIFI_DEBUG is not set
CONFIG_RTL8192CE=m
CONFIG_RTL8192SE=m
CONFIG_RTL8192DE=m
# CONFIG_RTL8723AE is not set
CONFIG_RTL8192CU=m
CONFIG_RTL8192C_COMMON=m
# CONFIG_WL_TI is not set
CONFIG_ZD1211RW=m
# CONFIG_ZD1211RW_DEBUG is not set
CONFIG_MWIFIEX=m
CONFIG_MWIFIEX_SDIO=m
CONFIG_MWIFIEX_PCIE=m
CONFIG_MWIFIEX_USB=m

#
# WiMAX Wireless Broadband devices
#
CONFIG_WIMAX_I2400M=m
CONFIG_WIMAX_I2400M_USB=m
CONFIG_WIMAX_I2400M_DEBUG_LEVEL=8
CONFIG_WAN=y
# CONFIG_LANMEDIA is not set
CONFIG_HDLC=m
CONFIG_HDLC_RAW=m
# CONFIG_HDLC_RAW_ETH is not set
CONFIG_HDLC_CISCO=m
CONFIG_HDLC_FR=m
CONFIG_HDLC_PPP=m

#
# X.25/LAPB support is disabled
#
# CONFIG_PCI200SYN is not set
# CONFIG_WANXL is not set
# CONFIG_PC300TOO is not set
# CONFIG_FARSYNC is not set
# CONFIG_DSCC4 is not set
CONFIG_DLCI=m
CONFIG_DLCI_MAX=8
# CONFIG_SBNI is not set
CONFIG_IEEE802154_DRIVERS=m
CONFIG_IEEE802154_FAKEHARD=m
CONFIG_IEEE802154_FAKELB=m
CONFIG_XEN_NETDEV_FRONTEND=m
# CONFIG_XEN_NETDEV_BACKEND is not set
CONFIG_VMXNET3=m
CONFIG_HYPERV_NET=m
CONFIG_ISDN=y
CONFIG_ISDN_I4L=m
CONFIG_ISDN_PPP=y
CONFIG_ISDN_PPP_VJ=y
CONFIG_ISDN_MPP=y
CONFIG_IPPP_FILTER=y
# CONFIG_ISDN_PPP_BSDCOMP is not set
CONFIG_ISDN_AUDIO=y
CONFIG_ISDN_TTY_FAX=y

#
# ISDN feature submodules
#
CONFIG_ISDN_DIVERSION=m

#
# ISDN4Linux hardware drivers
#

#
# Passive cards
#
CONFIG_ISDN_DRV_HISAX=m

#
# D-channel protocol features
#
CONFIG_HISAX_EURO=y
CONFIG_DE_AOC=y
CONFIG_HISAX_NO_SENDCOMPLETE=y
CONFIG_HISAX_NO_LLC=y
CONFIG_HISAX_NO_KEYPAD=y
CONFIG_HISAX_1TR6=y
CONFIG_HISAX_NI1=y
CONFIG_HISAX_MAX_CARDS=8

#
# HiSax supported cards
#
CONFIG_HISAX_16_3=y
CONFIG_HISAX_TELESPCI=y
CONFIG_HISAX_S0BOX=y
CONFIG_HISAX_FRITZPCI=y
CONFIG_HISAX_AVM_A1_PCMCIA=y
CONFIG_HISAX_ELSA=y
CONFIG_HISAX_DIEHLDIVA=y
CONFIG_HISAX_SEDLBAUER=y
CONFIG_HISAX_NETJET=y
CONFIG_HISAX_NETJET_U=y
CONFIG_HISAX_NICCY=y
CONFIG_HISAX_BKM_A4T=y
CONFIG_HISAX_SCT_QUADRO=y
CONFIG_HISAX_GAZEL=y
CONFIG_HISAX_HFC_PCI=y
CONFIG_HISAX_W6692=y
CONFIG_HISAX_HFC_SX=y
CONFIG_HISAX_ENTERNOW_PCI=y
# CONFIG_HISAX_DEBUG is not set

#
# HiSax PCMCIA card service modules
#
CONFIG_HISAX_SEDLBAUER_CS=m
CONFIG_HISAX_ELSA_CS=m
CONFIG_HISAX_AVM_A1_CS=m
CONFIG_HISAX_TELES_CS=m

#
# HiSax sub driver modules
#
CONFIG_HISAX_ST5481=m
# CONFIG_HISAX_HFCUSB is not set
CONFIG_HISAX_HFC4S8S=m
CONFIG_HISAX_FRITZ_PCIPNP=m

#
# Active cards
#
CONFIG_ISDN_CAPI=m
CONFIG_ISDN_DRV_AVMB1_VERBOSE_REASON=y
# CONFIG_CAPI_TRACE is not set
CONFIG_ISDN_CAPI_MIDDLEWARE=y
CONFIG_ISDN_CAPI_CAPI20=m
CONFIG_ISDN_CAPI_CAPIDRV=m

#
# CAPI hardware drivers
#
CONFIG_CAPI_AVM=y
CONFIG_ISDN_DRV_AVMB1_B1PCI=m
CONFIG_ISDN_DRV_AVMB1_B1PCIV4=y
CONFIG_ISDN_DRV_AVMB1_B1PCMCIA=m
CONFIG_ISDN_DRV_AVMB1_AVM_CS=m
CONFIG_ISDN_DRV_AVMB1_T1PCI=m
CONFIG_ISDN_DRV_AVMB1_C4=m
# CONFIG_CAPI_EICON is not set
CONFIG_ISDN_DRV_GIGASET=m
CONFIG_GIGASET_CAPI=y
# CONFIG_GIGASET_I4L is not set
# CONFIG_GIGASET_DUMMYLL is not set
CONFIG_GIGASET_BASE=m
CONFIG_GIGASET_M105=m
CONFIG_GIGASET_M101=m
# CONFIG_GIGASET_DEBUG is not set
CONFIG_HYSDN=m
CONFIG_HYSDN_CAPI=y
CONFIG_MISDN=m
CONFIG_MISDN_DSP=m
CONFIG_MISDN_L1OIP=m

#
# mISDN hardware drivers
#
CONFIG_MISDN_HFCPCI=m
CONFIG_MISDN_HFCMULTI=m
CONFIG_MISDN_HFCUSB=m
CONFIG_MISDN_AVMFRITZ=m
CONFIG_MISDN_SPEEDFAX=m
CONFIG_MISDN_INFINEON=m
CONFIG_MISDN_W6692=m
CONFIG_MISDN_NETJET=m
CONFIG_MISDN_IPAC=m
CONFIG_MISDN_ISAR=m
CONFIG_ISDN_HDLC=m

#
# Input device support
#
CONFIG_INPUT=y
CONFIG_INPUT_FF_MEMLESS=y
CONFIG_INPUT_POLLDEV=m
CONFIG_INPUT_SPARSEKMAP=m
# CONFIG_INPUT_MATRIXKMAP is not set

#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
CONFIG_INPUT_EVDEV=y
# CONFIG_INPUT_EVBUG is not set

#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
# CONFIG_KEYBOARD_ADP5588 is not set
# CONFIG_KEYBOARD_ADP5589 is not set
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_QT1070 is not set
# CONFIG_KEYBOARD_QT2160 is not set
# CONFIG_KEYBOARD_LKKBD is not set
# CONFIG_KEYBOARD_TCA6416 is not set
# CONFIG_KEYBOARD_TCA8418 is not set
# CONFIG_KEYBOARD_LM8323 is not set
# CONFIG_KEYBOARD_LM8333 is not set
# CONFIG_KEYBOARD_MAX7359 is not set
# CONFIG_KEYBOARD_MCS is not set
# CONFIG_KEYBOARD_MPR121 is not set
# CONFIG_KEYBOARD_NEWTON is not set
# CONFIG_KEYBOARD_OPENCORES 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=y
CONFIG_MOUSE_PS2_ALPS=y
CONFIG_MOUSE_PS2_LOGIPS2PP=y
CONFIG_MOUSE_PS2_SYNAPTICS=y
CONFIG_MOUSE_PS2_CYPRESS=y
CONFIG_MOUSE_PS2_LIFEBOOK=y
CONFIG_MOUSE_PS2_TRACKPOINT=y
CONFIG_MOUSE_PS2_ELANTECH=y
CONFIG_MOUSE_PS2_SENTELIC=y
# CONFIG_MOUSE_PS2_TOUCHKIT is not set
CONFIG_MOUSE_SERIAL=m
CONFIG_MOUSE_APPLETOUCH=m
CONFIG_MOUSE_BCM5974=m
# CONFIG_MOUSE_CYAPA is not set
CONFIG_MOUSE_VSXXXAA=m
CONFIG_MOUSE_SYNAPTICS_I2C=m
CONFIG_MOUSE_SYNAPTICS_USB=m
# CONFIG_INPUT_JOYSTICK is not set
CONFIG_INPUT_TABLET=y
CONFIG_TABLET_USB_ACECAD=m
CONFIG_TABLET_USB_AIPTEK=m
CONFIG_TABLET_USB_GTCO=m
CONFIG_TABLET_USB_HANWANG=m
CONFIG_TABLET_USB_KBTAB=m
CONFIG_TABLET_USB_WACOM=m
CONFIG_INPUT_TOUCHSCREEN=y
# CONFIG_TOUCHSCREEN_AD7879 is not set
CONFIG_TOUCHSCREEN_ATMEL_MXT=m
# CONFIG_TOUCHSCREEN_BU21013 is not set
# CONFIG_TOUCHSCREEN_CYTTSP_CORE is not set
CONFIG_TOUCHSCREEN_DYNAPRO=m
# CONFIG_TOUCHSCREEN_HAMPSHIRE is not set
CONFIG_TOUCHSCREEN_EETI=m
CONFIG_TOUCHSCREEN_FUJITSU=m
CONFIG_TOUCHSCREEN_ILI210X=m
CONFIG_TOUCHSCREEN_GUNZE=m
CONFIG_TOUCHSCREEN_ELO=m
CONFIG_TOUCHSCREEN_WACOM_W8001=m
CONFIG_TOUCHSCREEN_WACOM_I2C=m
# CONFIG_TOUCHSCREEN_MAX11801 is not set
CONFIG_TOUCHSCREEN_MCS5000=m
CONFIG_TOUCHSCREEN_MMS114=m
CONFIG_TOUCHSCREEN_MTOUCH=m
CONFIG_TOUCHSCREEN_INEXIO=m
# CONFIG_TOUCHSCREEN_MK712 is not set
CONFIG_TOUCHSCREEN_PENMOUNT=m
CONFIG_TOUCHSCREEN_EDT_FT5X06=m
CONFIG_TOUCHSCREEN_TOUCHRIGHT=m
CONFIG_TOUCHSCREEN_TOUCHWIN=m
CONFIG_TOUCHSCREEN_PIXCIR=m
# CONFIG_TOUCHSCREEN_WM97XX is not set
CONFIG_TOUCHSCREEN_USB_COMPOSITE=m
CONFIG_TOUCHSCREEN_USB_EGALAX=y
CONFIG_TOUCHSCREEN_USB_PANJIT=y
CONFIG_TOUCHSCREEN_USB_3M=y
CONFIG_TOUCHSCREEN_USB_ITM=y
CONFIG_TOUCHSCREEN_USB_ETURBO=y
CONFIG_TOUCHSCREEN_USB_GUNZE=y
CONFIG_TOUCHSCREEN_USB_DMC_TSC10=y
CONFIG_TOUCHSCREEN_USB_IRTOUCH=y
CONFIG_TOUCHSCREEN_USB_IDEALTEK=y
CONFIG_TOUCHSCREEN_USB_GENERAL_TOUCH=y
CONFIG_TOUCHSCREEN_USB_GOTOP=y
CONFIG_TOUCHSCREEN_USB_JASTEC=y
CONFIG_TOUCHSCREEN_USB_ELO=y
CONFIG_TOUCHSCREEN_USB_E2I=y
CONFIG_TOUCHSCREEN_USB_ZYTRONIC=y
CONFIG_TOUCHSCREEN_USB_ETT_TC45USB=y
CONFIG_TOUCHSCREEN_USB_NEXIO=y
CONFIG_TOUCHSCREEN_USB_EASYTOUCH=y
CONFIG_TOUCHSCREEN_TOUCHIT213=m
CONFIG_TOUCHSCREEN_TSC_SERIO=m
CONFIG_TOUCHSCREEN_TSC2007=m
CONFIG_TOUCHSCREEN_ST1232=m
# CONFIG_TOUCHSCREEN_TPS6507X is not set
CONFIG_INPUT_MISC=y
# CONFIG_INPUT_AD714X is not set
# CONFIG_INPUT_BMA150 is not set
CONFIG_INPUT_PCSPKR=m
# CONFIG_INPUT_MMA8450 is not set
# CONFIG_INPUT_MPU3050 is not set
CONFIG_INPUT_APANEL=m
CONFIG_INPUT_ATLAS_BTNS=m
CONFIG_INPUT_ATI_REMOTE2=m
CONFIG_INPUT_KEYSPAN_REMOTE=m
# CONFIG_INPUT_KXTJ9 is not set
CONFIG_INPUT_POWERMATE=m
CONFIG_INPUT_YEALINK=m
CONFIG_INPUT_CM109=m
CONFIG_INPUT_UINPUT=m
# CONFIG_INPUT_PCF8574 is not set
# CONFIG_INPUT_ADXL34X is not set
# CONFIG_INPUT_CMA3000 is not set
CONFIG_INPUT_XEN_KBDDEV_FRONTEND=y

#
# Hardware I/O ports
#
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_SERIO_SERPORT=y
# CONFIG_SERIO_CT82C710 is not set
# CONFIG_SERIO_PARKBD is not set
# CONFIG_SERIO_PCIPS2 is not set
CONFIG_SERIO_LIBPS2=y
CONFIG_SERIO_RAW=m
CONFIG_SERIO_ALTERA_PS2=m
# CONFIG_SERIO_PS2MULT is not set
# CONFIG_SERIO_ARC_PS2 is not set
# CONFIG_GAMEPORT is not set

#
# Character devices
#
CONFIG_TTY=y
CONFIG_VT=y
CONFIG_CONSOLE_TRANSLATIONS=y
CONFIG_VT_CONSOLE=y
CONFIG_VT_CONSOLE_SLEEP=y
CONFIG_HW_CONSOLE=y
CONFIG_VT_HW_CONSOLE_BINDING=y
CONFIG_UNIX98_PTYS=y
CONFIG_DEVPTS_MULTIPLE_INSTANCES=y
# CONFIG_LEGACY_PTYS is not set
CONFIG_SERIAL_NONSTANDARD=y
# CONFIG_ROCKETPORT is not set
CONFIG_CYCLADES=m
# CONFIG_CYZ_INTR is not set
# CONFIG_MOXA_INTELLIO is not set
# CONFIG_MOXA_SMARTIO is not set
CONFIG_SYNCLINK=m
CONFIG_SYNCLINKMP=m
CONFIG_SYNCLINK_GT=m
CONFIG_NOZOMI=m
# CONFIG_ISI is not set
CONFIG_N_HDLC=m
CONFIG_N_GSM=m
# CONFIG_TRACE_SINK is not set
# CONFIG_DEVKMEM is not set
# CONFIG_STALDRV is not set

#
# Serial drivers
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_PNP=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_SERIAL_8250_DMA=y
CONFIG_SERIAL_8250_PCI=y
CONFIG_SERIAL_8250_CS=m
CONFIG_SERIAL_8250_NR_UARTS=32
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
# CONFIG_SERIAL_8250_DW is not set

#
# Non-8250 serial port support
#
# CONFIG_SERIAL_KGDB_NMI is not set
# CONFIG_SERIAL_MFD_HSU is not set
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_CONSOLE_POLL=y
CONFIG_SERIAL_JSM=m
# CONFIG_SERIAL_SCCNXP is not set
# CONFIG_SERIAL_TIMBERDALE is not set
# CONFIG_SERIAL_ALTERA_JTAGUART is not set
# CONFIG_SERIAL_ALTERA_UART is not set
# CONFIG_SERIAL_PCH_UART is not set
# CONFIG_SERIAL_ARC is not set
# CONFIG_SERIAL_RP2 is not set
CONFIG_PRINTER=m
# CONFIG_LP_CONSOLE is not set
CONFIG_PPDEV=m
CONFIG_HVC_DRIVER=y
CONFIG_HVC_IRQ=y
CONFIG_HVC_XEN=y
CONFIG_HVC_XEN_FRONTEND=y
CONFIG_VIRTIO_CONSOLE=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=y
CONFIG_HW_RANDOM_TIMERIOMEM=m
CONFIG_HW_RANDOM_INTEL=m
CONFIG_HW_RANDOM_AMD=m
CONFIG_HW_RANDOM_VIA=m
CONFIG_HW_RANDOM_VIRTIO=m
CONFIG_HW_RANDOM_TPM=m
CONFIG_NVRAM=y
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set

#
# PCMCIA character devices
#
# CONFIG_SYNCLINK_CS is not set
CONFIG_CARDMAN_4000=m
CONFIG_CARDMAN_4040=m
CONFIG_IPWIRELESS=m
# CONFIG_MWAVE is not set
CONFIG_RAW_DRIVER=y
CONFIG_MAX_RAW_DEVS=8192
CONFIG_HPET=y
# CONFIG_HPET_MMAP is not set
CONFIG_HANGCHECK_TIMER=m
CONFIG_UV_MMTIMER=m
CONFIG_TCG_TPM=y
CONFIG_TCG_TIS=y
# CONFIG_TCG_TIS_I2C_INFINEON is not set
CONFIG_TCG_NSC=m
CONFIG_TCG_ATMEL=m
CONFIG_TCG_INFINEON=m
CONFIG_TELCLOCK=m
CONFIG_DEVPORT=y
CONFIG_I2C=m
CONFIG_I2C_BOARDINFO=y
CONFIG_I2C_COMPAT=y
CONFIG_I2C_CHARDEV=m
# CONFIG_I2C_MUX is not set
CONFIG_I2C_HELPER_AUTO=y
CONFIG_I2C_SMBUS=m
CONFIG_I2C_ALGOBIT=m
CONFIG_I2C_ALGOPCA=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=m
CONFIG_I2C_AMD756_S4882=m
CONFIG_I2C_AMD8111=m
CONFIG_I2C_I801=m
CONFIG_I2C_ISCH=m
# CONFIG_I2C_ISMT is not set
CONFIG_I2C_PIIX4=m
CONFIG_I2C_NFORCE2=m
CONFIG_I2C_NFORCE2_S4985=m
# CONFIG_I2C_SIS5595 is not set
# CONFIG_I2C_SIS630 is not set
CONFIG_I2C_SIS96X=m
CONFIG_I2C_VIA=m
CONFIG_I2C_VIAPRO=m

#
# ACPI drivers
#
CONFIG_I2C_SCMI=m

#
# I2C system bus drivers (mostly embedded / system-on-chip)
#
# CONFIG_I2C_DESIGNWARE_PCI is not set
# CONFIG_I2C_EG20T is not set
# CONFIG_I2C_INTEL_MID is not set
# CONFIG_I2C_OCORES is not set
CONFIG_I2C_PCA_PLATFORM=m
# CONFIG_I2C_PXA_PCI is not set
CONFIG_I2C_SIMTEC=m
# CONFIG_I2C_XILINX is not set

#
# External I2C/SMBus adapter drivers
#
CONFIG_I2C_DIOLAN_U2C=m
CONFIG_I2C_PARPORT=m
CONFIG_I2C_PARPORT_LIGHT=m
# CONFIG_I2C_TAOS_EVM is not set
CONFIG_I2C_TINY_USB=m

#
# Other I2C/SMBus bus drivers
#
CONFIG_I2C_STUB=m
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_SPI is not set
# CONFIG_HSI is not set

#
# PPS support
#
CONFIG_PPS=m
# CONFIG_PPS_DEBUG is not set

#
# PPS clients support
#
# CONFIG_PPS_CLIENT_KTIMER is not set
CONFIG_PPS_CLIENT_LDISC=m
CONFIG_PPS_CLIENT_PARPORT=m
CONFIG_PPS_CLIENT_GPIO=m

#
# PPS generators support
#

#
# PTP clock support
#
CONFIG_PTP_1588_CLOCK=m
CONFIG_DP83640_PHY=m
CONFIG_PTP_1588_CLOCK_PCH=m
CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y
CONFIG_GPIO_DEVRES=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_TEST_POWER is not set
# CONFIG_BATTERY_DS2780 is not set
# CONFIG_BATTERY_DS2781 is not set
# CONFIG_BATTERY_DS2782 is not set
# CONFIG_BATTERY_SBS is not set
# CONFIG_BATTERY_BQ27x00 is not set
# CONFIG_BATTERY_MAX17040 is not set
# CONFIG_BATTERY_MAX17042 is not set
# CONFIG_CHARGER_ISP1704 is not set
# CONFIG_CHARGER_MAX8903 is not set
# CONFIG_CHARGER_LP8727 is not set
# CONFIG_CHARGER_BQ2415X is not set
CONFIG_CHARGER_SMB347=m
# CONFIG_BATTERY_GOLDFISH is not set
# CONFIG_POWER_RESET is not set
# CONFIG_POWER_AVS is not set
CONFIG_HWMON=y
CONFIG_HWMON_VID=m
# CONFIG_HWMON_DEBUG_CHIP is not set

#
# Native drivers
#
CONFIG_SENSORS_ABITUGURU=m
CONFIG_SENSORS_ABITUGURU3=m
CONFIG_SENSORS_AD7414=m
CONFIG_SENSORS_AD7418=m
CONFIG_SENSORS_ADM1021=m
CONFIG_SENSORS_ADM1025=m
CONFIG_SENSORS_ADM1026=m
CONFIG_SENSORS_ADM1029=m
CONFIG_SENSORS_ADM1031=m
CONFIG_SENSORS_ADM9240=m
CONFIG_SENSORS_ADT7410=m
CONFIG_SENSORS_ADT7411=m
CONFIG_SENSORS_ADT7462=m
CONFIG_SENSORS_ADT7470=m
CONFIG_SENSORS_ADT7475=m
CONFIG_SENSORS_ASC7621=m
CONFIG_SENSORS_K8TEMP=m
CONFIG_SENSORS_K10TEMP=m
CONFIG_SENSORS_FAM15H_POWER=m
CONFIG_SENSORS_ASB100=m
CONFIG_SENSORS_ATXP1=m
CONFIG_SENSORS_DS620=m
CONFIG_SENSORS_DS1621=m
CONFIG_SENSORS_I5K_AMB=m
CONFIG_SENSORS_F71805F=m
CONFIG_SENSORS_F71882FG=m
CONFIG_SENSORS_F75375S=m
CONFIG_SENSORS_FSCHMD=m
CONFIG_SENSORS_G760A=m
CONFIG_SENSORS_GL518SM=m
CONFIG_SENSORS_GL520SM=m
# CONFIG_SENSORS_HIH6130 is not set
CONFIG_SENSORS_CORETEMP=m
CONFIG_SENSORS_IBMAEM=m
CONFIG_SENSORS_IBMPEX=m
CONFIG_SENSORS_IT87=m
# CONFIG_SENSORS_JC42 is not set
CONFIG_SENSORS_LINEAGE=m
CONFIG_SENSORS_LM63=m
CONFIG_SENSORS_LM73=m
CONFIG_SENSORS_LM75=m
CONFIG_SENSORS_LM77=m
CONFIG_SENSORS_LM78=m
CONFIG_SENSORS_LM80=m
CONFIG_SENSORS_LM83=m
CONFIG_SENSORS_LM85=m
CONFIG_SENSORS_LM87=m
CONFIG_SENSORS_LM90=m
CONFIG_SENSORS_LM92=m
CONFIG_SENSORS_LM93=m
CONFIG_SENSORS_LTC4151=m
CONFIG_SENSORS_LTC4215=m
CONFIG_SENSORS_LTC4245=m
CONFIG_SENSORS_LTC4261=m
CONFIG_SENSORS_LM95241=m
CONFIG_SENSORS_LM95245=m
CONFIG_SENSORS_MAX16065=m
CONFIG_SENSORS_MAX1619=m
CONFIG_SENSORS_MAX1668=m
CONFIG_SENSORS_MAX197=m
CONFIG_SENSORS_MAX6639=m
CONFIG_SENSORS_MAX6642=m
CONFIG_SENSORS_MAX6650=m
# CONFIG_SENSORS_MAX6697 is not set
CONFIG_SENSORS_MCP3021=m
CONFIG_SENSORS_NTC_THERMISTOR=m
CONFIG_SENSORS_PC87360=m
CONFIG_SENSORS_PC87427=m
CONFIG_SENSORS_PCF8591=m
CONFIG_PMBUS=m
CONFIG_SENSORS_PMBUS=m
CONFIG_SENSORS_ADM1275=m
CONFIG_SENSORS_LM25066=m
CONFIG_SENSORS_LTC2978=m
CONFIG_SENSORS_MAX16064=m
CONFIG_SENSORS_MAX34440=m
CONFIG_SENSORS_MAX8688=m
CONFIG_SENSORS_UCD9000=m
CONFIG_SENSORS_UCD9200=m
CONFIG_SENSORS_ZL6100=m
CONFIG_SENSORS_SHT21=m
CONFIG_SENSORS_SIS5595=m
# CONFIG_SENSORS_SMM665 is not set
CONFIG_SENSORS_DME1737=m
CONFIG_SENSORS_EMC1403=m
# CONFIG_SENSORS_EMC2103 is not set
CONFIG_SENSORS_EMC6W201=m
CONFIG_SENSORS_SMSC47M1=m
CONFIG_SENSORS_SMSC47M192=m
CONFIG_SENSORS_SMSC47B397=m
CONFIG_SENSORS_SCH56XX_COMMON=m
CONFIG_SENSORS_SCH5627=m
CONFIG_SENSORS_SCH5636=m
CONFIG_SENSORS_ADS1015=m
CONFIG_SENSORS_ADS7828=m
CONFIG_SENSORS_AMC6821=m
# CONFIG_SENSORS_INA209 is not set
CONFIG_SENSORS_INA2XX=m
CONFIG_SENSORS_THMC50=m
CONFIG_SENSORS_TMP102=m
CONFIG_SENSORS_TMP401=m
CONFIG_SENSORS_TMP421=m
CONFIG_SENSORS_VIA_CPUTEMP=m
CONFIG_SENSORS_VIA686A=m
CONFIG_SENSORS_VT1211=m
CONFIG_SENSORS_VT8231=m
CONFIG_SENSORS_W83781D=m
CONFIG_SENSORS_W83791D=m
CONFIG_SENSORS_W83792D=m
CONFIG_SENSORS_W83793=m
CONFIG_SENSORS_W83795=m
# CONFIG_SENSORS_W83795_FANCTRL is not set
CONFIG_SENSORS_W83L785TS=m
CONFIG_SENSORS_W83L786NG=m
CONFIG_SENSORS_W83627HF=m
CONFIG_SENSORS_W83627EHF=m
CONFIG_SENSORS_APPLESMC=m

#
# ACPI drivers
#
CONFIG_SENSORS_ACPI_POWER=m
CONFIG_SENSORS_ATK0110=m
CONFIG_THERMAL=y
CONFIG_THERMAL_HWMON=y
CONFIG_THERMAL_DEFAULT_GOV_STEP_WISE=y
# CONFIG_THERMAL_DEFAULT_GOV_FAIR_SHARE is not set
# CONFIG_THERMAL_DEFAULT_GOV_USER_SPACE is not set
# CONFIG_THERMAL_GOV_FAIR_SHARE is not set
CONFIG_THERMAL_GOV_STEP_WISE=y
# CONFIG_THERMAL_GOV_USER_SPACE is not set
# CONFIG_CPU_THERMAL is not set
# CONFIG_THERMAL_EMULATION is not set
# CONFIG_INTEL_POWERCLAMP is not set
CONFIG_WATCHDOG=y
CONFIG_WATCHDOG_CORE=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=m
CONFIG_ALIM7101_WDT=m
CONFIG_F71808E_WDT=m
CONFIG_SP5100_TCO=m
# CONFIG_SC520_WDT is not set
CONFIG_SBC_FITPC2_WATCHDOG=m
# CONFIG_EUROTECH_WDT is not set
CONFIG_IB700_WDT=m
CONFIG_IBMASR=m
# CONFIG_WAFER_WDT is not set
CONFIG_I6300ESB_WDT=m
CONFIG_IE6XX_WDT=m
CONFIG_ITCO_WDT=m
CONFIG_ITCO_VENDOR_SUPPORT=y
CONFIG_IT8712F_WDT=m
CONFIG_IT87_WDT=m
CONFIG_HP_WATCHDOG=m
CONFIG_HPWDT_NMI_DECODING=y
# CONFIG_SC1200_WDT is not set
# CONFIG_PC87413_WDT is not set
CONFIG_NV_TCO=m
# CONFIG_60XX_WDT is not set
# CONFIG_SBC8360_WDT is not set
# CONFIG_CPU5_WDT is not set
CONFIG_SMSC_SCH311X_WDT=m
# CONFIG_SMSC37B787_WDT is not set
CONFIG_VIA_WDT=m
CONFIG_W83627HF_WDT=m
CONFIG_W83697HF_WDT=m
CONFIG_W83697UG_WDT=m
CONFIG_W83877F_WDT=m
CONFIG_W83977F_WDT=m
CONFIG_MACHZ_WDT=m
# CONFIG_SBC_EPX_C3_WATCHDOG is not set
CONFIG_XEN_WDT=m

#
# PCI-based Watchdog Cards
#
CONFIG_PCIPCWATCHDOG=m
CONFIG_WDTPCI=m

#
# USB-based Watchdog Cards
#
CONFIG_USBPCWATCHDOG=m
CONFIG_SSB_POSSIBLE=y

#
# Sonics Silicon Backplane
#
CONFIG_SSB=m
CONFIG_SSB_SPROM=y
CONFIG_SSB_BLOCKIO=y
CONFIG_SSB_PCIHOST_POSSIBLE=y
CONFIG_SSB_PCIHOST=y
CONFIG_SSB_B43_PCI_BRIDGE=y
CONFIG_SSB_PCMCIAHOST_POSSIBLE=y
CONFIG_SSB_PCMCIAHOST=y
CONFIG_SSB_SDIOHOST_POSSIBLE=y
CONFIG_SSB_SDIOHOST=y
# CONFIG_SSB_DEBUG is not set
CONFIG_SSB_DRIVER_PCICORE_POSSIBLE=y
CONFIG_SSB_DRIVER_PCICORE=y
CONFIG_BCMA_POSSIBLE=y

#
# Broadcom specific AMBA
#
CONFIG_BCMA=m
CONFIG_BCMA_BLOCKIO=y
CONFIG_BCMA_HOST_PCI_POSSIBLE=y
CONFIG_BCMA_HOST_PCI=y
CONFIG_BCMA_DRIVER_GMAC_CMN=y
# CONFIG_BCMA_DEBUG is not set

#
# Multifunction device drivers
#
CONFIG_MFD_CORE=m
CONFIG_MFD_SM501=m
# CONFIG_MFD_RTSX_PCI is not set
# CONFIG_MFD_TI_AM335X_TSCADC is not set
# CONFIG_HTC_PASIC3 is not set
# CONFIG_MFD_LM3533 is not set
# CONFIG_TPS6105X is not set
# CONFIG_TPS6507X is not set
# CONFIG_MFD_TPS65217 is not set
# CONFIG_MFD_TMIO is not set
# CONFIG_MFD_ARIZONA_I2C is not set
# CONFIG_MFD_PCF50633 is not set
# CONFIG_MFD_MC13XXX_I2C is not set
# CONFIG_ABX500_CORE is not set
# CONFIG_MFD_CS5535 is not set
CONFIG_LPC_SCH=m
CONFIG_LPC_ICH=m
# CONFIG_MFD_RDC321X is not set
# CONFIG_MFD_JANZ_CMODIO is not set
CONFIG_MFD_VX855=m
# CONFIG_MFD_WL1273_CORE is not set
# CONFIG_MFD_VIPERBOARD is not set
# CONFIG_MFD_RETU is not set
# CONFIG_REGULATOR is not set
CONFIG_MEDIA_SUPPORT=m

#
# Multimedia core support
#
CONFIG_MEDIA_CAMERA_SUPPORT=y
CONFIG_MEDIA_ANALOG_TV_SUPPORT=y
CONFIG_MEDIA_DIGITAL_TV_SUPPORT=y
CONFIG_MEDIA_RADIO_SUPPORT=y
CONFIG_MEDIA_RC_SUPPORT=y
# CONFIG_MEDIA_CONTROLLER is not set
CONFIG_VIDEO_DEV=m
CONFIG_VIDEO_V4L2=m
# CONFIG_VIDEO_ADV_DEBUG is not set
# CONFIG_VIDEO_FIXED_MINOR_RANGES is not set
CONFIG_VIDEO_TUNER=m
CONFIG_VIDEOBUF_GEN=m
CONFIG_VIDEOBUF_DMA_SG=m
CONFIG_VIDEOBUF_VMALLOC=m
CONFIG_VIDEOBUF_DVB=m
CONFIG_VIDEOBUF2_CORE=m
CONFIG_VIDEOBUF2_MEMOPS=m
CONFIG_VIDEOBUF2_VMALLOC=m
# CONFIG_VIDEO_V4L2_INT_DEVICE is not set
CONFIG_DVB_CORE=m
CONFIG_DVB_NET=y
CONFIG_TTPCI_EEPROM=m
CONFIG_DVB_MAX_ADAPTERS=8
CONFIG_DVB_DYNAMIC_MINORS=y

#
# Media drivers
#
CONFIG_RC_CORE=m
CONFIG_RC_MAP=m
CONFIG_RC_DECODERS=y
CONFIG_LIRC=m
CONFIG_IR_LIRC_CODEC=m
CONFIG_IR_NEC_DECODER=m
CONFIG_IR_RC5_DECODER=m
CONFIG_IR_RC6_DECODER=m
CONFIG_IR_JVC_DECODER=m
CONFIG_IR_SONY_DECODER=m
CONFIG_IR_RC5_SZ_DECODER=m
CONFIG_IR_SANYO_DECODER=m
CONFIG_IR_MCE_KBD_DECODER=m
CONFIG_RC_DEVICES=y
CONFIG_RC_ATI_REMOTE=m
CONFIG_IR_ENE=m
CONFIG_IR_IMON=m
CONFIG_IR_MCEUSB=m
CONFIG_IR_ITE_CIR=m
CONFIG_IR_FINTEK=m
CONFIG_IR_NUVOTON=m
CONFIG_IR_REDRAT3=m
CONFIG_IR_STREAMZAP=m
CONFIG_IR_WINBOND_CIR=m
CONFIG_IR_IGUANA=m
CONFIG_IR_TTUSBIR=m
# CONFIG_RC_LOOPBACK is not set
CONFIG_IR_GPIO_CIR=m
CONFIG_MEDIA_USB_SUPPORT=y

#
# Webcam devices
#
CONFIG_USB_VIDEO_CLASS=m
CONFIG_USB_VIDEO_CLASS_INPUT_EVDEV=y
CONFIG_USB_GSPCA=m
CONFIG_USB_M5602=m
CONFIG_USB_STV06XX=m
CONFIG_USB_GL860=m
CONFIG_USB_GSPCA_BENQ=m
CONFIG_USB_GSPCA_CONEX=m
CONFIG_USB_GSPCA_CPIA1=m
CONFIG_USB_GSPCA_ETOMS=m
CONFIG_USB_GSPCA_FINEPIX=m
CONFIG_USB_GSPCA_JEILINJ=m
CONFIG_USB_GSPCA_JL2005BCD=m
# CONFIG_USB_GSPCA_KINECT is not set
CONFIG_USB_GSPCA_KONICA=m
CONFIG_USB_GSPCA_MARS=m
CONFIG_USB_GSPCA_MR97310A=m
CONFIG_USB_GSPCA_NW80X=m
CONFIG_USB_GSPCA_OV519=m
CONFIG_USB_GSPCA_OV534=m
CONFIG_USB_GSPCA_OV534_9=m
CONFIG_USB_GSPCA_PAC207=m
CONFIG_USB_GSPCA_PAC7302=m
CONFIG_USB_GSPCA_PAC7311=m
CONFIG_USB_GSPCA_SE401=m
CONFIG_USB_GSPCA_SN9C2028=m
CONFIG_USB_GSPCA_SN9C20X=m
CONFIG_USB_GSPCA_SONIXB=m
CONFIG_USB_GSPCA_SONIXJ=m
CONFIG_USB_GSPCA_SPCA500=m
CONFIG_USB_GSPCA_SPCA501=m
CONFIG_USB_GSPCA_SPCA505=m
CONFIG_USB_GSPCA_SPCA506=m
CONFIG_USB_GSPCA_SPCA508=m
CONFIG_USB_GSPCA_SPCA561=m
CONFIG_USB_GSPCA_SPCA1528=m
CONFIG_USB_GSPCA_SQ905=m
CONFIG_USB_GSPCA_SQ905C=m
CONFIG_USB_GSPCA_SQ930X=m
CONFIG_USB_GSPCA_STK014=m
CONFIG_USB_GSPCA_STV0680=m
CONFIG_USB_GSPCA_SUNPLUS=m
CONFIG_USB_GSPCA_T613=m
CONFIG_USB_GSPCA_TOPRO=m
CONFIG_USB_GSPCA_TV8532=m
CONFIG_USB_GSPCA_VC032X=m
CONFIG_USB_GSPCA_VICAM=m
CONFIG_USB_GSPCA_XIRLINK_CIT=m
CONFIG_USB_GSPCA_ZC3XX=m
CONFIG_USB_PWC=m
# CONFIG_USB_PWC_DEBUG is not set
CONFIG_USB_PWC_INPUT_EVDEV=y
# CONFIG_VIDEO_CPIA2 is not set
CONFIG_USB_ZR364XX=m
CONFIG_USB_STKWEBCAM=m
CONFIG_USB_S2255=m
# CONFIG_USB_SN9C102 is not set

#
# Analog TV USB devices
#
CONFIG_VIDEO_PVRUSB2=m
CONFIG_VIDEO_PVRUSB2_SYSFS=y
CONFIG_VIDEO_PVRUSB2_DVB=y
# CONFIG_VIDEO_PVRUSB2_DEBUGIFC is not set
CONFIG_VIDEO_HDPVR=m
CONFIG_VIDEO_TLG2300=m
CONFIG_VIDEO_USBVISION=m
CONFIG_VIDEO_STK1160=m
CONFIG_VIDEO_STK1160_AC97=y

#
# Analog/digital TV USB devices
#
CONFIG_VIDEO_AU0828=m
CONFIG_VIDEO_AU0828_V4L2=y
CONFIG_VIDEO_CX231XX=m
CONFIG_VIDEO_CX231XX_RC=y
CONFIG_VIDEO_CX231XX_ALSA=m
CONFIG_VIDEO_CX231XX_DVB=m
CONFIG_VIDEO_TM6000=m
CONFIG_VIDEO_TM6000_ALSA=m
CONFIG_VIDEO_TM6000_DVB=m

#
# Digital TV USB devices
#
CONFIG_DVB_USB=m
# CONFIG_DVB_USB_DEBUG is not set
CONFIG_DVB_USB_A800=m
CONFIG_DVB_USB_DIBUSB_MB=m
# CONFIG_DVB_USB_DIBUSB_MB_FAULTY is not set
CONFIG_DVB_USB_DIBUSB_MC=m
CONFIG_DVB_USB_DIB0700=m
CONFIG_DVB_USB_UMT_010=m
CONFIG_DVB_USB_CXUSB=m
CONFIG_DVB_USB_M920X=m
CONFIG_DVB_USB_DIGITV=m
CONFIG_DVB_USB_VP7045=m
CONFIG_DVB_USB_VP702X=m
CONFIG_DVB_USB_GP8PSK=m
CONFIG_DVB_USB_NOVA_T_USB2=m
CONFIG_DVB_USB_TTUSB2=m
CONFIG_DVB_USB_DTT200U=m
CONFIG_DVB_USB_OPERA1=m
CONFIG_DVB_USB_AF9005=m
CONFIG_DVB_USB_AF9005_REMOTE=m
CONFIG_DVB_USB_PCTV452E=m
CONFIG_DVB_USB_DW2102=m
CONFIG_DVB_USB_CINERGY_T2=m
CONFIG_DVB_USB_DTV5100=m
CONFIG_DVB_USB_FRIIO=m
CONFIG_DVB_USB_AZ6027=m
CONFIG_DVB_USB_TECHNISAT_USB2=m
# CONFIG_DVB_USB_V2 is not set
CONFIG_DVB_TTUSB_BUDGET=m
CONFIG_DVB_TTUSB_DEC=m
CONFIG_SMS_USB_DRV=m
CONFIG_DVB_B2C2_FLEXCOP_USB=m
# CONFIG_DVB_B2C2_FLEXCOP_USB_DEBUG is not set

#
# Webcam, TV (analog/digital) USB devices
#
CONFIG_VIDEO_EM28XX=m
CONFIG_VIDEO_EM28XX_ALSA=m
CONFIG_VIDEO_EM28XX_DVB=m
CONFIG_VIDEO_EM28XX_RC=m
CONFIG_MEDIA_PCI_SUPPORT=y

#
# Media capture support
#
# CONFIG_VIDEO_MEYE is not set

#
# Media capture/analog TV support
#
CONFIG_VIDEO_IVTV=m
# CONFIG_VIDEO_IVTV_ALSA is not set
CONFIG_VIDEO_FB_IVTV=m
# CONFIG_VIDEO_ZORAN is not set
# CONFIG_VIDEO_HEXIUM_GEMINI is not set
# CONFIG_VIDEO_HEXIUM_ORION is not set
# CONFIG_VIDEO_MXB is not set

#
# Media capture/analog/hybrid TV support
#
CONFIG_VIDEO_CX18=m
CONFIG_VIDEO_CX18_ALSA=m
CONFIG_VIDEO_CX23885=m
CONFIG_MEDIA_ALTERA_CI=m
# CONFIG_VIDEO_CX25821 is not set
CONFIG_VIDEO_CX88=m
CONFIG_VIDEO_CX88_ALSA=m
CONFIG_VIDEO_CX88_BLACKBIRD=m
CONFIG_VIDEO_CX88_DVB=m
CONFIG_VIDEO_CX88_VP3054=m
CONFIG_VIDEO_CX88_MPEG=m
CONFIG_VIDEO_BT848=m
CONFIG_DVB_BT8XX=m
CONFIG_VIDEO_SAA7134=m
CONFIG_VIDEO_SAA7134_ALSA=m
CONFIG_VIDEO_SAA7134_RC=y
CONFIG_VIDEO_SAA7134_DVB=m
CONFIG_VIDEO_SAA7164=m

#
# Media digital TV PCI Adapters
#
CONFIG_DVB_AV7110=m
CONFIG_DVB_AV7110_OSD=y
CONFIG_DVB_BUDGET_CORE=m
CONFIG_DVB_BUDGET=m
CONFIG_DVB_BUDGET_CI=m
CONFIG_DVB_BUDGET_AV=m
CONFIG_DVB_BUDGET_PATCH=m
CONFIG_DVB_B2C2_FLEXCOP_PCI=m
# CONFIG_DVB_B2C2_FLEXCOP_PCI_DEBUG is not set
CONFIG_DVB_PLUTO2=m
CONFIG_DVB_DM1105=m
CONFIG_DVB_PT1=m
CONFIG_MANTIS_CORE=m
CONFIG_DVB_MANTIS=m
CONFIG_DVB_HOPPER=m
CONFIG_DVB_NGENE=m
CONFIG_DVB_DDBRIDGE=m
# CONFIG_V4L_PLATFORM_DRIVERS is not set
# CONFIG_V4L_MEM2MEM_DRIVERS is not set
# CONFIG_V4L_TEST_DRIVERS is not set

#
# Supported MMC/SDIO adapters
#
CONFIG_SMS_SDIO_DRV=m
# CONFIG_MEDIA_PARPORT_SUPPORT is not set
# CONFIG_RADIO_ADAPTERS is not set

#
# Supported FireWire (IEEE 1394) Adapters
#
CONFIG_DVB_FIREDTV=m
CONFIG_DVB_FIREDTV_INPUT=y
CONFIG_MEDIA_COMMON_OPTIONS=y

#
# common driver options
#
CONFIG_VIDEO_CX2341X=m
CONFIG_VIDEO_BTCX=m
CONFIG_VIDEO_TVEEPROM=m
CONFIG_DVB_B2C2_FLEXCOP=m
CONFIG_VIDEO_SAA7146=m
CONFIG_VIDEO_SAA7146_VV=m
CONFIG_SMS_SIANO_MDTV=m
CONFIG_SMS_SIANO_RC=y

#
# Media ancillary drivers (tuners, sensors, i2c, frontends)
#
CONFIG_MEDIA_SUBDRV_AUTOSELECT=y
CONFIG_VIDEO_IR_I2C=m

#
# Audio decoders, processors and mixers
#
CONFIG_VIDEO_TVAUDIO=m
CONFIG_VIDEO_TDA7432=m
CONFIG_VIDEO_MSP3400=m
CONFIG_VIDEO_CS5345=m
CONFIG_VIDEO_CS53L32A=m
CONFIG_VIDEO_WM8775=m
CONFIG_VIDEO_WM8739=m
CONFIG_VIDEO_VP27SMPX=m

#
# RDS decoders
#
CONFIG_VIDEO_SAA6588=m

#
# Video decoders
#
CONFIG_VIDEO_SAA711X=m
CONFIG_VIDEO_TVP5150=m

#
# Video and audio decoders
#
CONFIG_VIDEO_SAA717X=m
CONFIG_VIDEO_CX25840=m

#
# Video encoders
#
CONFIG_VIDEO_SAA7127=m

#
# Camera sensor devices
#
CONFIG_VIDEO_MT9V011=m

#
# Flash devices
#

#
# Video improvement chips
#
CONFIG_VIDEO_UPD64031A=m
CONFIG_VIDEO_UPD64083=m

#
# Miscelaneous helper chips
#
CONFIG_VIDEO_M52790=m

#
# Sensors used on soc_camera driver
#
CONFIG_MEDIA_ATTACH=y
CONFIG_MEDIA_TUNER=m
CONFIG_MEDIA_TUNER_SIMPLE=m
CONFIG_MEDIA_TUNER_TDA8290=m
CONFIG_MEDIA_TUNER_TDA827X=m
CONFIG_MEDIA_TUNER_TDA18271=m
CONFIG_MEDIA_TUNER_TDA9887=m
CONFIG_MEDIA_TUNER_TEA5761=m
CONFIG_MEDIA_TUNER_TEA5767=m
CONFIG_MEDIA_TUNER_MT20XX=m
CONFIG_MEDIA_TUNER_MT2060=m
CONFIG_MEDIA_TUNER_MT2063=m
CONFIG_MEDIA_TUNER_MT2266=m
CONFIG_MEDIA_TUNER_MT2131=m
CONFIG_MEDIA_TUNER_QT1010=m
CONFIG_MEDIA_TUNER_XC2028=m
CONFIG_MEDIA_TUNER_XC5000=m
CONFIG_MEDIA_TUNER_XC4000=m
CONFIG_MEDIA_TUNER_MXL5005S=m
CONFIG_MEDIA_TUNER_MXL5007T=m
CONFIG_MEDIA_TUNER_MC44S803=m
CONFIG_MEDIA_TUNER_MAX2165=m

#
# Multistandard (satellite) frontends
#
CONFIG_DVB_STB0899=m
CONFIG_DVB_STB6100=m
CONFIG_DVB_STV090x=m
CONFIG_DVB_STV6110x=m

#
# Multistandard (cable + terrestrial) frontends
#
CONFIG_DVB_DRXK=m
CONFIG_DVB_TDA18271C2DD=m

#
# DVB-S (satellite) frontends
#
CONFIG_DVB_CX24110=m
CONFIG_DVB_CX24123=m
CONFIG_DVB_MT312=m
CONFIG_DVB_ZL10036=m
CONFIG_DVB_ZL10039=m
CONFIG_DVB_S5H1420=m
CONFIG_DVB_STV0288=m
CONFIG_DVB_STB6000=m
CONFIG_DVB_STV0299=m
CONFIG_DVB_STV6110=m
CONFIG_DVB_STV0900=m
CONFIG_DVB_TDA8083=m
CONFIG_DVB_TDA10086=m
CONFIG_DVB_TDA8261=m
CONFIG_DVB_VES1X93=m
CONFIG_DVB_TUNER_ITD1000=m
CONFIG_DVB_TUNER_CX24113=m
CONFIG_DVB_TDA826X=m
CONFIG_DVB_TUA6100=m
CONFIG_DVB_CX24116=m
CONFIG_DVB_SI21XX=m
CONFIG_DVB_TS2020=m
CONFIG_DVB_DS3000=m
CONFIG_DVB_MB86A16=m
CONFIG_DVB_TDA10071=m

#
# DVB-T (terrestrial) frontends
#
CONFIG_DVB_SP8870=m
CONFIG_DVB_SP887X=m
CONFIG_DVB_CX22700=m
CONFIG_DVB_CX22702=m
CONFIG_DVB_DRXD=m
CONFIG_DVB_L64781=m
CONFIG_DVB_TDA1004X=m
CONFIG_DVB_NXT6000=m
CONFIG_DVB_MT352=m
CONFIG_DVB_ZL10353=m
CONFIG_DVB_DIB3000MB=m
CONFIG_DVB_DIB3000MC=m
CONFIG_DVB_DIB7000M=m
CONFIG_DVB_DIB7000P=m
CONFIG_DVB_TDA10048=m
CONFIG_DVB_STV0367=m
CONFIG_DVB_CXD2820R=m

#
# DVB-C (cable) frontends
#
CONFIG_DVB_VES1820=m
CONFIG_DVB_TDA10021=m
CONFIG_DVB_TDA10023=m
CONFIG_DVB_STV0297=m

#
# ATSC (North American/Korean Terrestrial/Cable DTV) frontends
#
CONFIG_DVB_NXT200X=m
CONFIG_DVB_OR51211=m
CONFIG_DVB_OR51132=m
CONFIG_DVB_BCM3510=m
CONFIG_DVB_LGDT330X=m
CONFIG_DVB_LGDT3305=m
CONFIG_DVB_S5H1409=m
CONFIG_DVB_AU8522=m
CONFIG_DVB_AU8522_DTV=m
CONFIG_DVB_AU8522_V4L=m
CONFIG_DVB_S5H1411=m

#
# ISDB-T (terrestrial) frontends
#
CONFIG_DVB_S921=m
CONFIG_DVB_DIB8000=m
CONFIG_DVB_MB86A20S=m

#
# Digital terrestrial only tuners/PLL
#
CONFIG_DVB_PLL=m
CONFIG_DVB_TUNER_DIB0070=m
CONFIG_DVB_TUNER_DIB0090=m

#
# SEC control devices for DVB-S
#
CONFIG_DVB_LNBP21=m
CONFIG_DVB_LNBP22=m
CONFIG_DVB_ISL6405=m
CONFIG_DVB_ISL6421=m
CONFIG_DVB_ISL6423=m
CONFIG_DVB_A8293=m
CONFIG_DVB_LGS8GXX=m
CONFIG_DVB_ATBM8830=m
CONFIG_DVB_TDA665x=m
CONFIG_DVB_M88RS2000=m

#
# Tools to develop new frontends
#
# CONFIG_DVB_DUMMY_FE is not set

#
# Graphics support
#
CONFIG_AGP=y
CONFIG_AGP_AMD64=y
CONFIG_AGP_INTEL=y
CONFIG_AGP_SIS=y
CONFIG_AGP_VIA=y
CONFIG_VGA_ARB=y
CONFIG_VGA_ARB_MAX_GPUS=64
CONFIG_VGA_SWITCHEROO=y
CONFIG_DRM=m
CONFIG_DRM_USB=m
CONFIG_DRM_KMS_HELPER=m
CONFIG_DRM_LOAD_EDID_FIRMWARE=y
CONFIG_DRM_TTM=m

#
# I2C encoder or helper chips
#
CONFIG_DRM_I2C_CH7006=m
CONFIG_DRM_I2C_SIL164=m
# CONFIG_DRM_I2C_NXP_TDA998X is not set
# CONFIG_DRM_TDFX is not set
# CONFIG_DRM_R128 is not set
CONFIG_DRM_RADEON=m
# CONFIG_DRM_RADEON_UMS is not set
CONFIG_DRM_NOUVEAU=m
CONFIG_NOUVEAU_DEBUG=5
CONFIG_NOUVEAU_DEBUG_DEFAULT=3
CONFIG_DRM_NOUVEAU_BACKLIGHT=y
# CONFIG_DRM_I810 is not set
CONFIG_DRM_I915=m
CONFIG_DRM_I915_KMS=y
# 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_DRM_VMWGFX=m
# CONFIG_DRM_VMWGFX_FBCON is not set
CONFIG_DRM_GMA500=m
# CONFIG_DRM_GMA600 is not set
CONFIG_DRM_GMA3600=y
CONFIG_DRM_UDL=m
CONFIG_DRM_AST=m
CONFIG_DRM_MGAG200=m
CONFIG_DRM_CIRRUS_QEMU=m
# CONFIG_VGASTATE is not set
CONFIG_VIDEO_OUTPUT_CONTROL=m
CONFIG_HDMI=y
CONFIG_FB=y
# CONFIG_FIRMWARE_EDID is not set
# CONFIG_FB_DDC is not set
# CONFIG_FB_BOOT_VESA_SUPPORT is not set
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=y
CONFIG_FB_SYS_COPYAREA=y
CONFIG_FB_SYS_IMAGEBLIT=y
# CONFIG_FB_FOREIGN_ENDIAN is not set
CONFIG_FB_SYS_FOPS=y
# CONFIG_FB_WMT_GE_ROPS is not set
CONFIG_FB_DEFERRED_IO=y
# CONFIG_FB_SVGALIB is not set
# CONFIG_FB_MACMODES is not set
CONFIG_FB_BACKLIGHT=y
# CONFIG_FB_MODE_HELPERS is not set
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 is not set
# CONFIG_FB_UVESA is not set
# CONFIG_FB_VESA is not set
CONFIG_FB_EFI=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_I740 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_TMIO is not set
# CONFIG_FB_SM501 is not set
# CONFIG_FB_SMSCUFX is not set
# CONFIG_FB_UDL is not set
# CONFIG_FB_GOLDFISH is not set
CONFIG_FB_VIRTUAL=m
CONFIG_XEN_FBDEV_FRONTEND=y
# CONFIG_FB_METRONOME is not set
# CONFIG_FB_MB862XX is not set
# CONFIG_FB_BROADSHEET is not set
# CONFIG_FB_AUO_K190X is not set
# CONFIG_EXYNOS_VIDEO is not set
CONFIG_BACKLIGHT_LCD_SUPPORT=y
CONFIG_LCD_CLASS_DEVICE=m
CONFIG_LCD_PLATFORM=m
CONFIG_BACKLIGHT_CLASS_DEVICE=y
# CONFIG_BACKLIGHT_GENERIC is not set
CONFIG_BACKLIGHT_APPLE=m
# CONFIG_BACKLIGHT_SAHARA is not set
# CONFIG_BACKLIGHT_ADP8860 is not set
# CONFIG_BACKLIGHT_ADP8870 is not set
# CONFIG_BACKLIGHT_LM3630 is not set
# CONFIG_BACKLIGHT_LM3639 is not set
CONFIG_BACKLIGHT_LP855X=m

#
# 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=y
# 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_SOUND_OSS_CORE_PRECLAIM=y
CONFIG_SND=m
CONFIG_SND_TIMER=m
CONFIG_SND_PCM=m
CONFIG_SND_HWDEP=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 is not set
# CONFIG_SND_PCM_OSS is not set
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 is not set
CONFIG_SND_VERBOSE_PROCFS=y
# CONFIG_SND_VERBOSE_PRINTK is not set
# CONFIG_SND_DEBUG is not set
CONFIG_SND_VMASTER=y
CONFIG_SND_KCTL_JACK=y
CONFIG_SND_DMA_SGBUF=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=m
CONFIG_SND_MPU401_UART=m
CONFIG_SND_VX_LIB=m
CONFIG_SND_AC97_CODEC=m
CONFIG_SND_DRIVERS=y
CONFIG_SND_PCSP=m
CONFIG_SND_DUMMY=m
CONFIG_SND_ALOOP=m
CONFIG_SND_VIRMIDI=m
CONFIG_SND_MTPAV=m
# CONFIG_SND_MTS64 is not set
# CONFIG_SND_SERIAL_U16550 is not set
CONFIG_SND_MPU401=m
# CONFIG_SND_PORTMAN2X4 is not set
CONFIG_SND_AC97_POWER_SAVE=y
CONFIG_SND_AC97_POWER_SAVE_DEFAULT=0
CONFIG_SND_SB_COMMON=m
CONFIG_SND_SB16_DSP=m
CONFIG_SND_TEA575X=m
CONFIG_SND_PCI=y
CONFIG_SND_AD1889=m
# CONFIG_SND_ALS300 is not set
# CONFIG_SND_ALS4000 is not set
CONFIG_SND_ALI5451=m
CONFIG_SND_ASIHPI=m
CONFIG_SND_ATIIXP=m
CONFIG_SND_ATIIXP_MODEM=m
CONFIG_SND_AU8810=m
CONFIG_SND_AU8820=m
CONFIG_SND_AU8830=m
# CONFIG_SND_AW2 is not set
# CONFIG_SND_AZT3328 is not set
CONFIG_SND_BT87X=m
# CONFIG_SND_BT87X_OVERCLOCK is not set
CONFIG_SND_CA0106=m
# CONFIG_SND_CMIPCI is not set
CONFIG_SND_OXYGEN_LIB=m
CONFIG_SND_OXYGEN=m
# CONFIG_SND_CS4281 is not set
CONFIG_SND_CS46XX=m
CONFIG_SND_CS46XX_NEW_DSP=y
CONFIG_SND_CS5530=m
CONFIG_SND_CS5535AUDIO=m
CONFIG_SND_CTXFI=m
CONFIG_SND_DARLA20=m
CONFIG_SND_GINA20=m
CONFIG_SND_LAYLA20=m
CONFIG_SND_DARLA24=m
CONFIG_SND_GINA24=m
CONFIG_SND_LAYLA24=m
CONFIG_SND_MONA=m
CONFIG_SND_MIA=m
CONFIG_SND_ECHO3G=m
CONFIG_SND_INDIGO=m
CONFIG_SND_INDIGOIO=m
CONFIG_SND_INDIGODJ=m
CONFIG_SND_INDIGOIOX=m
CONFIG_SND_INDIGODJX=m
CONFIG_SND_EMU10K1=m
CONFIG_SND_EMU10K1X=m
CONFIG_SND_ENS1370=m
CONFIG_SND_ENS1371=m
# CONFIG_SND_ES1938 is not set
CONFIG_SND_ES1968=m
CONFIG_SND_ES1968_INPUT=y
CONFIG_SND_ES1968_RADIO=y
# CONFIG_SND_FM801 is not set
CONFIG_SND_HDA_INTEL=m
CONFIG_SND_HDA_PREALLOC_SIZE=512
CONFIG_SND_HDA_HWDEP=y
# CONFIG_SND_HDA_RECONFIG is not set
CONFIG_SND_HDA_INPUT_BEEP=y
CONFIG_SND_HDA_INPUT_BEEP_MODE=0
CONFIG_SND_HDA_INPUT_JACK=y
# CONFIG_SND_HDA_PATCH_LOADER is not set
CONFIG_SND_HDA_CODEC_REALTEK=y
CONFIG_SND_HDA_CODEC_ANALOG=y
CONFIG_SND_HDA_CODEC_SIGMATEL=y
CONFIG_SND_HDA_CODEC_VIA=y
CONFIG_SND_HDA_CODEC_HDMI=y
CONFIG_SND_HDA_CODEC_CIRRUS=y
CONFIG_SND_HDA_CODEC_CONEXANT=y
CONFIG_SND_HDA_CODEC_CA0110=y
CONFIG_SND_HDA_CODEC_CA0132=y
# CONFIG_SND_HDA_CODEC_CA0132_DSP is not set
CONFIG_SND_HDA_CODEC_CMEDIA=y
CONFIG_SND_HDA_CODEC_SI3054=y
CONFIG_SND_HDA_GENERIC=y
CONFIG_SND_HDA_POWER_SAVE_DEFAULT=0
CONFIG_SND_HDSP=m
CONFIG_SND_HDSPM=m
CONFIG_SND_ICE1712=m
CONFIG_SND_ICE1724=m
CONFIG_SND_INTEL8X0=m
CONFIG_SND_INTEL8X0M=m
CONFIG_SND_KORG1212=m
CONFIG_SND_LOLA=m
CONFIG_SND_LX6464ES=m
CONFIG_SND_MAESTRO3=m
CONFIG_SND_MAESTRO3_INPUT=y
CONFIG_SND_MIXART=m
# CONFIG_SND_NM256 is not set
CONFIG_SND_PCXHR=m
# CONFIG_SND_RIPTIDE is not set
CONFIG_SND_RME32=m
CONFIG_SND_RME96=m
CONFIG_SND_RME9652=m
# CONFIG_SND_SONICVIBES is not set
CONFIG_SND_TRIDENT=m
CONFIG_SND_VIA82XX=m
CONFIG_SND_VIA82XX_MODEM=m
CONFIG_SND_VIRTUOSO=m
CONFIG_SND_VX222=m
# CONFIG_SND_YMFPCI is not set
CONFIG_SND_USB=y
CONFIG_SND_USB_AUDIO=m
CONFIG_SND_USB_UA101=m
CONFIG_SND_USB_USX2Y=m
CONFIG_SND_USB_CAIAQ=m
CONFIG_SND_USB_CAIAQ_INPUT=y
CONFIG_SND_USB_US122L=m
CONFIG_SND_USB_6FIRE=m
CONFIG_SND_FIREWIRE=y
CONFIG_SND_FIREWIRE_LIB=m
CONFIG_SND_FIREWIRE_SPEAKERS=m
CONFIG_SND_ISIGHT=m
# CONFIG_SND_SCS1X 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

#
# HID support
#
CONFIG_HID=y
CONFIG_HID_BATTERY_STRENGTH=y
CONFIG_HIDRAW=y
CONFIG_UHID=m
CONFIG_HID_GENERIC=y

#
# Special HID drivers
#
CONFIG_HID_A4TECH=y
CONFIG_HID_ACRUX=m
# CONFIG_HID_ACRUX_FF is not set
CONFIG_HID_APPLE=y
CONFIG_HID_AUREAL=m
CONFIG_HID_BELKIN=y
CONFIG_HID_CHERRY=y
CONFIG_HID_CHICONY=y
CONFIG_HID_PRODIKEYS=m
CONFIG_HID_CYPRESS=y
CONFIG_HID_DRAGONRISE=m
# CONFIG_DRAGONRISE_FF is not set
CONFIG_HID_EMS_FF=m
CONFIG_HID_ELECOM=m
CONFIG_HID_EZKEY=y
CONFIG_HID_HOLTEK=m
# CONFIG_HOLTEK_FF is not set
CONFIG_HID_KEYTOUCH=m
CONFIG_HID_KYE=m
CONFIG_HID_UCLOGIC=m
CONFIG_HID_WALTOP=m
CONFIG_HID_GYRATION=m
# CONFIG_HID_ICADE is not set
CONFIG_HID_TWINHAN=m
CONFIG_HID_KENSINGTON=y
CONFIG_HID_LCPOWER=m
CONFIG_HID_LENOVO_TPKBD=m
CONFIG_HID_LOGITECH=y
CONFIG_HID_LOGITECH_DJ=m
# CONFIG_LOGITECH_FF is not set
# CONFIG_LOGIRUMBLEPAD2_FF is not set
# CONFIG_LOGIG940_FF is not set
CONFIG_LOGIWHEELS_FF=y
CONFIG_HID_MAGICMOUSE=m
CONFIG_HID_MICROSOFT=y
CONFIG_HID_MONTEREY=y
CONFIG_HID_MULTITOUCH=m
CONFIG_HID_NTRIG=y
CONFIG_HID_ORTEK=m
CONFIG_HID_PANTHERLORD=m
# CONFIG_PANTHERLORD_FF is not set
CONFIG_HID_PETALYNX=m
CONFIG_HID_PICOLCD=m
CONFIG_HID_PICOLCD_FB=y
CONFIG_HID_PICOLCD_BACKLIGHT=y
CONFIG_HID_PICOLCD_LCD=y
CONFIG_HID_PICOLCD_LEDS=y
CONFIG_HID_PICOLCD_CIR=y
CONFIG_HID_PRIMAX=m
CONFIG_HID_PS3REMOTE=m
CONFIG_HID_ROCCAT=m
CONFIG_HID_SAITEK=m
CONFIG_HID_SAMSUNG=m
CONFIG_HID_SONY=m
CONFIG_HID_SPEEDLINK=m
# CONFIG_HID_STEELSERIES is not set
CONFIG_HID_SUNPLUS=m
CONFIG_HID_GREENASIA=m
# CONFIG_GREENASIA_FF is not set
CONFIG_HID_HYPERV_MOUSE=m
CONFIG_HID_SMARTJOYPLUS=m
# CONFIG_SMARTJOYPLUS_FF is not set
CONFIG_HID_TIVO=m
CONFIG_HID_TOPSEED=m
# CONFIG_HID_THINGM is not set
CONFIG_HID_THRUSTMASTER=m
# CONFIG_THRUSTMASTER_FF is not set
CONFIG_HID_WACOM=m
CONFIG_HID_WIIMOTE=m
CONFIG_HID_WIIMOTE_EXT=y
CONFIG_HID_ZEROPLUS=m
# CONFIG_ZEROPLUS_FF is not set
CONFIG_HID_ZYDACRON=m
# CONFIG_HID_SENSOR_HUB is not set

#
# USB HID support
#
CONFIG_USB_HID=y
CONFIG_HID_PID=y
CONFIG_USB_HIDDEV=y

#
# I2C HID support
#
# CONFIG_I2C_HID is not set
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_ARCH_HAS_EHCI=y
CONFIG_USB_ARCH_HAS_XHCI=y
CONFIG_USB_SUPPORT=y
CONFIG_USB_COMMON=y
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB=y
# CONFIG_USB_DEBUG is not set
CONFIG_USB_ANNOUNCE_NEW_DEVICES=y

#
# Miscellaneous USB options
#
# CONFIG_USB_DYNAMIC_MINORS is not set
CONFIG_USB_SUSPEND=y
# CONFIG_USB_OTG is not set
# CONFIG_USB_DWC3 is not set
CONFIG_USB_MON=y
CONFIG_USB_WUSB=m
CONFIG_USB_WUSB_CBAF=m
# CONFIG_USB_WUSB_CBAF_DEBUG is not set

#
# USB Host Controller Drivers
#
# CONFIG_USB_C67X00_HCD is not set
CONFIG_USB_XHCI_HCD=y
# CONFIG_USB_XHCI_HCD_DEBUGGING is not set
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_EHCI_ROOT_HUB_TT=y
CONFIG_USB_EHCI_TT_NEWSCHED=y
CONFIG_USB_EHCI_PCI=y
# CONFIG_USB_OXU210HP_HCD is not set
# CONFIG_USB_ISP116X_HCD is not set
# CONFIG_USB_ISP1760_HCD is not set
CONFIG_USB_ISP1362_HCD=m
CONFIG_USB_OHCI_HCD=y
# CONFIG_USB_OHCI_HCD_PLATFORM is not set
# CONFIG_USB_EHCI_HCD_PLATFORM is not set
# 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=y
CONFIG_USB_U132_HCD=m
CONFIG_USB_SL811_HCD=m
CONFIG_USB_SL811_HCD_ISO=y
# CONFIG_USB_SL811_CS is not set
# CONFIG_USB_R8A66597_HCD is not set
CONFIG_USB_WHCI_HCD=m
CONFIG_USB_HWA_HCD=m
# CONFIG_USB_HCD_BCMA is not set
# CONFIG_USB_HCD_SSB is not set
# CONFIG_USB_CHIPIDEA is not set

#
# USB Device Class drivers
#
CONFIG_USB_ACM=m
CONFIG_USB_PRINTER=m
CONFIG_USB_WDM=m
CONFIG_USB_TMC=m

#
# 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_REALTEK=m
CONFIG_REALTEK_AUTOPM=y
CONFIG_USB_STORAGE_DATAFAB=m
CONFIG_USB_STORAGE_FREECOM=m
CONFIG_USB_STORAGE_ISD200=m
CONFIG_USB_STORAGE_USBAT=m
CONFIG_USB_STORAGE_SDDR09=m
CONFIG_USB_STORAGE_SDDR55=m
CONFIG_USB_STORAGE_JUMPSHOT=m
CONFIG_USB_STORAGE_ALAUDA=m
CONFIG_USB_STORAGE_ONETOUCH=m
CONFIG_USB_STORAGE_KARMA=m
CONFIG_USB_STORAGE_CYPRESS_ATACB=m
CONFIG_USB_STORAGE_ENE_UB6250=m

#
# USB Imaging devices
#
CONFIG_USB_MDC800=m
CONFIG_USB_MICROTEK=m

#
# USB port drivers
#
CONFIG_USB_USS720=m
CONFIG_USB_SERIAL=y
CONFIG_USB_SERIAL_CONSOLE=y
CONFIG_USB_SERIAL_GENERIC=y
CONFIG_USB_SERIAL_AIRCABLE=m
CONFIG_USB_SERIAL_ARK3116=m
CONFIG_USB_SERIAL_BELKIN=m
CONFIG_USB_SERIAL_CH341=m
CONFIG_USB_SERIAL_WHITEHEAT=m
CONFIG_USB_SERIAL_DIGI_ACCELEPORT=m
CONFIG_USB_SERIAL_CP210X=m
CONFIG_USB_SERIAL_CYPRESS_M8=m
CONFIG_USB_SERIAL_EMPEG=m
CONFIG_USB_SERIAL_FTDI_SIO=m
CONFIG_USB_SERIAL_FUNSOFT=m
CONFIG_USB_SERIAL_VISOR=m
CONFIG_USB_SERIAL_IPAQ=m
CONFIG_USB_SERIAL_IR=m
CONFIG_USB_SERIAL_EDGEPORT=m
CONFIG_USB_SERIAL_EDGEPORT_TI=m
# CONFIG_USB_SERIAL_F81232 is not set
CONFIG_USB_SERIAL_GARMIN=m
CONFIG_USB_SERIAL_IPW=m
CONFIG_USB_SERIAL_IUU=m
CONFIG_USB_SERIAL_KEYSPAN_PDA=m
CONFIG_USB_SERIAL_KEYSPAN=m
CONFIG_USB_SERIAL_KLSI=m
CONFIG_USB_SERIAL_KOBIL_SCT=m
CONFIG_USB_SERIAL_MCT_U232=m
# CONFIG_USB_SERIAL_METRO is not set
CONFIG_USB_SERIAL_MOS7720=m
CONFIG_USB_SERIAL_MOS7715_PARPORT=y
CONFIG_USB_SERIAL_MOS7840=m
CONFIG_USB_SERIAL_MOTOROLA=m
CONFIG_USB_SERIAL_NAVMAN=m
CONFIG_USB_SERIAL_PL2303=m
CONFIG_USB_SERIAL_OTI6858=m
CONFIG_USB_SERIAL_QCAUX=m
CONFIG_USB_SERIAL_QUALCOMM=m
CONFIG_USB_SERIAL_SPCP8X5=m
CONFIG_USB_SERIAL_HP4X=m
CONFIG_USB_SERIAL_SAFE=m
CONFIG_USB_SERIAL_SAFE_PADDED=y
CONFIG_USB_SERIAL_SIEMENS_MPI=m
CONFIG_USB_SERIAL_SIERRAWIRELESS=m
CONFIG_USB_SERIAL_SYMBOL=m
CONFIG_USB_SERIAL_TI=m
CONFIG_USB_SERIAL_CYBERJACK=m
CONFIG_USB_SERIAL_XIRCOM=m
CONFIG_USB_SERIAL_WWAN=m
CONFIG_USB_SERIAL_OPTION=m
CONFIG_USB_SERIAL_OMNINET=m
CONFIG_USB_SERIAL_OPTICON=m
CONFIG_USB_SERIAL_VIVOPAY_SERIAL=m
# CONFIG_USB_SERIAL_XSENS_MT is not set
# CONFIG_USB_SERIAL_ZIO is not set
# CONFIG_USB_SERIAL_ZTE is not set
CONFIG_USB_SERIAL_SSU100=m
CONFIG_USB_SERIAL_QT2=m
CONFIG_USB_SERIAL_DEBUG=m

#
# USB Miscellaneous drivers
#
CONFIG_USB_EMI62=m
CONFIG_USB_EMI26=m
CONFIG_USB_ADUTUX=m
CONFIG_USB_SEVSEG=m
# CONFIG_USB_RIO500 is not set
CONFIG_USB_LEGOTOWER=m
CONFIG_USB_LCD=m
CONFIG_USB_LED=m
# CONFIG_USB_CYPRESS_CY7C63 is not set
# CONFIG_USB_CYTHERM is not set
CONFIG_USB_IDMOUSE=m
CONFIG_USB_FTDI_ELAN=m
CONFIG_USB_APPLEDISPLAY=m
CONFIG_USB_SISUSBVGA=m
CONFIG_USB_SISUSBVGA_CON=y
CONFIG_USB_LD=m
# CONFIG_USB_TRANCEVIBRATOR is not set
CONFIG_USB_IOWARRIOR=m
# CONFIG_USB_TEST is not set
CONFIG_USB_ISIGHTFW=m
CONFIG_USB_YUREX=m
CONFIG_USB_EZUSB_FX2=m
# CONFIG_USB_HSIC_USB3503 is not set

#
# USB Physical Layer drivers
#
# CONFIG_OMAP_USB3 is not set
# CONFIG_OMAP_CONTROL_USB is not set
# CONFIG_USB_ISP1301 is not set
# CONFIG_USB_RCAR_PHY is not set
CONFIG_USB_ATM=m
CONFIG_USB_SPEEDTOUCH=m
CONFIG_USB_CXACRU=m
CONFIG_USB_UEAGLEATM=m
CONFIG_USB_XUSBATM=m
# CONFIG_USB_GADGET is not set

#
# OTG and related infrastructure
#
CONFIG_USB_OTG_UTILS=y
CONFIG_NOP_USB_XCEIV=m
CONFIG_UWB=m
CONFIG_UWB_HWA=m
CONFIG_UWB_WHCI=m
CONFIG_UWB_I1480U=m
CONFIG_MMC=m
# CONFIG_MMC_DEBUG is not set
# CONFIG_MMC_UNSAFE_RESUME is not set
# CONFIG_MMC_CLKGATE is not set

#
# MMC/SD/SDIO Card Drivers
#
CONFIG_MMC_BLOCK=m
CONFIG_MMC_BLOCK_MINORS=8
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=y
# CONFIG_MMC_SDHCI_ACPI is not set
CONFIG_MMC_SDHCI_PLTFM=m
# CONFIG_MMC_WBSD is not set
CONFIG_MMC_TIFM_SD=m
CONFIG_MMC_SDRICOH_CS=m
CONFIG_MMC_CB710=m
CONFIG_MMC_VIA_SDMMC=m
CONFIG_MMC_VUB300=m
CONFIG_MMC_USHC=m
CONFIG_MEMSTICK=m
# CONFIG_MEMSTICK_DEBUG is not set

#
# MemoryStick drivers
#
# CONFIG_MEMSTICK_UNSAFE_RESUME is not set
CONFIG_MSPRO_BLOCK=m

#
# MemoryStick Host Controller Drivers
#
CONFIG_MEMSTICK_TIFM_MS=m
CONFIG_MEMSTICK_JMICRON_38X=m
CONFIG_MEMSTICK_R592=m
CONFIG_NEW_LEDS=y
CONFIG_LEDS_CLASS=y

#
# LED drivers
#
CONFIG_LEDS_LM3530=m
# CONFIG_LEDS_LM3642 is not set
# CONFIG_LEDS_PCA9532 is not set
CONFIG_LEDS_LP3944=m
CONFIG_LEDS_LP55XX_COMMON=m
CONFIG_LEDS_LP5521=m
CONFIG_LEDS_LP5523=m
CONFIG_LEDS_CLEVO_MAIL=m
# CONFIG_LEDS_PCA955X is not set
# CONFIG_LEDS_PCA9633 is not set
# CONFIG_LEDS_BD2802 is not set
CONFIG_LEDS_INTEL_SS4200=m
CONFIG_LEDS_DELL_NETBOOKS=m
# CONFIG_LEDS_TCA6507 is not set
# CONFIG_LEDS_LM355x is not set
# CONFIG_LEDS_OT200 is not set
CONFIG_LEDS_BLINKM=m
CONFIG_LEDS_TRIGGERS=y

#
# LED Triggers
#
CONFIG_LEDS_TRIGGER_TIMER=m
CONFIG_LEDS_TRIGGER_ONESHOT=m
CONFIG_LEDS_TRIGGER_HEARTBEAT=m
CONFIG_LEDS_TRIGGER_BACKLIGHT=m
# CONFIG_LEDS_TRIGGER_CPU is not set
CONFIG_LEDS_TRIGGER_DEFAULT_ON=m

#
# iptables trigger is under Netfilter config (LED target)
#
CONFIG_LEDS_TRIGGER_TRANSIENT=m
# CONFIG_ACCESSIBILITY is not set
CONFIG_INFINIBAND=m
CONFIG_INFINIBAND_USER_MAD=m
CONFIG_INFINIBAND_USER_ACCESS=m
CONFIG_INFINIBAND_USER_MEM=y
CONFIG_INFINIBAND_ADDR_TRANS=y
CONFIG_INFINIBAND_MTHCA=m
CONFIG_INFINIBAND_MTHCA_DEBUG=y
CONFIG_INFINIBAND_IPATH=m
CONFIG_INFINIBAND_QIB=m
# CONFIG_INFINIBAND_AMSO1100 is not set
CONFIG_INFINIBAND_CXGB3=m
# CONFIG_INFINIBAND_CXGB3_DEBUG is not set
CONFIG_INFINIBAND_CXGB4=m
CONFIG_MLX4_INFINIBAND=m
CONFIG_INFINIBAND_NES=m
# CONFIG_INFINIBAND_NES_DEBUG is not set
# CONFIG_INFINIBAND_OCRDMA is not set
CONFIG_INFINIBAND_IPOIB=m
CONFIG_INFINIBAND_IPOIB_CM=y
CONFIG_INFINIBAND_IPOIB_DEBUG=y
# CONFIG_INFINIBAND_IPOIB_DEBUG_DATA is not set
CONFIG_INFINIBAND_SRP=m
CONFIG_INFINIBAND_SRPT=m
CONFIG_INFINIBAND_ISER=m
CONFIG_EDAC=y
CONFIG_EDAC_LEGACY_SYSFS=y
# CONFIG_EDAC_DEBUG is not set
CONFIG_EDAC_DECODE_MCE=m
# CONFIG_EDAC_MCE_INJ is not set
CONFIG_EDAC_MM_EDAC=m
CONFIG_EDAC_AMD64=m
# CONFIG_EDAC_AMD64_ERROR_INJECTION is not set
CONFIG_EDAC_E752X=m
CONFIG_EDAC_I82975X=m
CONFIG_EDAC_I3000=m
CONFIG_EDAC_I3200=m
CONFIG_EDAC_X38=m
CONFIG_EDAC_I5400=m
CONFIG_EDAC_I7CORE=m
CONFIG_EDAC_I5000=m
CONFIG_EDAC_I5100=m
CONFIG_EDAC_I7300=m
CONFIG_EDAC_SBRIDGE=m
CONFIG_RTC_LIB=y
CONFIG_RTC_CLASS=y
# 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 is not set
# CONFIG_RTC_DRV_TEST is not set

#
# I2C RTC drivers
#
CONFIG_RTC_DRV_DS1307=m
CONFIG_RTC_DRV_DS1374=m
CONFIG_RTC_DRV_DS1672=m
CONFIG_RTC_DRV_DS3232=m
CONFIG_RTC_DRV_MAX6900=m
CONFIG_RTC_DRV_RS5C372=m
CONFIG_RTC_DRV_ISL1208=m
CONFIG_RTC_DRV_ISL12022=m
CONFIG_RTC_DRV_X1205=m
# CONFIG_RTC_DRV_PCF8523 is not set
CONFIG_RTC_DRV_PCF8563=m
CONFIG_RTC_DRV_PCF8583=m
CONFIG_RTC_DRV_M41T80=m
CONFIG_RTC_DRV_M41T80_WDT=y
CONFIG_RTC_DRV_BQ32K=m
# CONFIG_RTC_DRV_S35390A is not set
CONFIG_RTC_DRV_FM3130=m
CONFIG_RTC_DRV_RX8581=m
CONFIG_RTC_DRV_RX8025=m
CONFIG_RTC_DRV_EM3027=m
CONFIG_RTC_DRV_RV3029C2=m

#
# SPI RTC drivers
#

#
# Platform RTC drivers
#
CONFIG_RTC_DRV_CMOS=y
CONFIG_RTC_DRV_DS1286=m
CONFIG_RTC_DRV_DS1511=m
CONFIG_RTC_DRV_DS1553=m
CONFIG_RTC_DRV_DS1742=m
CONFIG_RTC_DRV_STK17TA8=m
# CONFIG_RTC_DRV_M48T86 is not set
CONFIG_RTC_DRV_M48T35=m
CONFIG_RTC_DRV_M48T59=m
CONFIG_RTC_DRV_MSM6242=m
CONFIG_RTC_DRV_BQ4802=m
CONFIG_RTC_DRV_RP5C01=m
CONFIG_RTC_DRV_V3020=m
CONFIG_RTC_DRV_DS2404=m

#
# on-CPU RTC drivers
#

#
# HID Sensor RTC drivers
#
# CONFIG_RTC_DRV_HID_SENSOR_TIME is not set
CONFIG_DMADEVICES=y
# CONFIG_DMADEVICES_DEBUG is not set

#
# DMA Devices
#
# CONFIG_INTEL_MID_DMAC is not set
CONFIG_INTEL_IOATDMA=m
# CONFIG_DW_DMAC is not set
# CONFIG_TIMB_DMA is not set
CONFIG_PCH_DMA=m
CONFIG_DMA_ENGINE=y

#
# DMA Clients
#
CONFIG_NET_DMA=y
CONFIG_ASYNC_TX_DMA=y
# CONFIG_DMATEST is not set
CONFIG_DCA=m
CONFIG_AUXDISPLAY=y
CONFIG_KS0108=m
CONFIG_KS0108_PORT=0x378
CONFIG_KS0108_DELAY=2
CONFIG_CFAG12864B=m
CONFIG_CFAG12864B_RATE=20
CONFIG_UIO=m
CONFIG_UIO_CIF=m
# CONFIG_UIO_PDRV is not set
# CONFIG_UIO_PDRV_GENIRQ is not set
# CONFIG_UIO_DMEM_GENIRQ is not set
CONFIG_UIO_AEC=m
CONFIG_UIO_SERCOS3=m
CONFIG_UIO_PCI_GENERIC=m
# CONFIG_UIO_NETX is not set
CONFIG_VFIO_IOMMU_TYPE1=m
CONFIG_VFIO=m
CONFIG_VFIO_PCI=m
# CONFIG_VFIO_PCI_VGA is not set
CONFIG_VIRTIO=y

#
# Virtio drivers
#
CONFIG_VIRTIO_PCI=y
CONFIG_VIRTIO_BALLOON=m
CONFIG_VIRTIO_MMIO=m
# CONFIG_VIRTIO_MMIO_CMDLINE_DEVICES is not set

#
# Microsoft Hyper-V guest support
#
CONFIG_HYPERV=m
CONFIG_HYPERV_UTILS=m
# CONFIG_HYPERV_BALLOON is not set

#
# Xen driver support
#
CONFIG_XEN_BALLOON=y
# CONFIG_XEN_SELFBALLOONING is not set
# CONFIG_XEN_BALLOON_MEMORY_HOTPLUG is not set
CONFIG_XEN_SCRUB_PAGES=y
CONFIG_XEN_DEV_EVTCHN=m
CONFIG_XEN_BACKEND=y
CONFIG_XENFS=m
CONFIG_XEN_COMPAT_XENFS=y
CONFIG_XEN_SYS_HYPERVISOR=y
CONFIG_XEN_XENBUS_FRONTEND=y
# CONFIG_XEN_GNTDEV is not set
# CONFIG_XEN_GRANT_DEV_ALLOC is not set
CONFIG_SWIOTLB_XEN=y
CONFIG_XEN_TMEM=y
CONFIG_XEN_PCIDEV_BACKEND=m
CONFIG_XEN_PRIVCMD=m
# CONFIG_XEN_STUB is not set
CONFIG_XEN_ACPI_PROCESSOR=m
# CONFIG_XEN_MCE_LOG is not set
CONFIG_XEN_HAVE_PVMMU=y
CONFIG_STAGING=y
# CONFIG_ET131X is not set
# CONFIG_SLICOSS is not set
# CONFIG_USBIP_CORE is not set
# CONFIG_W35UND is not set
# CONFIG_PRISM2_USB is not set
# CONFIG_ECHO is not set
# CONFIG_COMEDI is not set
# CONFIG_ASUS_OLED is not set
# CONFIG_PANEL is not set
# CONFIG_R8187SE is not set
# CONFIG_RTL8192U is not set
# CONFIG_RTLLIB is not set
CONFIG_R8712U=m
# CONFIG_RTS5139 is not set
# CONFIG_TRANZPORT is not set
# CONFIG_IDE_PHISON is not set
# CONFIG_LINE6_USB is not set
# CONFIG_USB_SERIAL_QUATECH2 is not set
# CONFIG_VT6655 is not set
# CONFIG_VT6656 is not set
# CONFIG_DX_SEP is not set
# CONFIG_ZSMALLOC is not set
# CONFIG_WLAGS49_H2 is not set
# CONFIG_WLAGS49_H25 is not set
# CONFIG_FB_SM7XX is not set
CONFIG_CRYSTALHD=m
# CONFIG_CXT1E1 is not set
# CONFIG_FB_XGI is not set
# CONFIG_ACPI_QUICKSTART is not set
# CONFIG_SBE_2T3E3 is not set
# CONFIG_USB_ENESTORAGE is not set
# CONFIG_BCM_WIMAX is not set
# CONFIG_FT1000 is not set

#
# Speakup console speech
#
# CONFIG_SPEAKUP is not set
# CONFIG_TOUCHSCREEN_SYNAPTICS_I2C_RMI4 is not set
CONFIG_STAGING_MEDIA=y
# CONFIG_DVB_AS102 is not set
# CONFIG_DVB_CXD2099 is not set
# CONFIG_VIDEO_DT3155 is not set
# CONFIG_VIDEO_GO7007 is not set
# CONFIG_SOLO6X10 is not set
CONFIG_LIRC_STAGING=y
CONFIG_LIRC_BT829=m
CONFIG_LIRC_IGORPLUGUSB=m
CONFIG_LIRC_IMON=m
CONFIG_LIRC_PARALLEL=m
CONFIG_LIRC_SASEM=m
CONFIG_LIRC_SERIAL=m
CONFIG_LIRC_SERIAL_TRANSMITTER=y
CONFIG_LIRC_SIR=m
CONFIG_LIRC_ZILOG=m

#
# Android
#
# CONFIG_ANDROID is not set
# CONFIG_USB_WPAN_HCD is not set
# CONFIG_WIMAX_GDM72XX is not set
# CONFIG_CSR_WIFI is not set
# CONFIG_NET_VENDOR_SILICOM is not set
# CONFIG_CED1401 is not set
# CONFIG_DGRP is not set
# CONFIG_FIREWIRE_SERIAL is not set
# CONFIG_ZCACHE is not set
CONFIG_X86_PLATFORM_DEVICES=y
CONFIG_ACER_WMI=m
CONFIG_ACERHDF=m
CONFIG_ASUS_LAPTOP=m
# CONFIG_CHROMEOS_LAPTOP is not set
CONFIG_DELL_LAPTOP=m
CONFIG_DELL_WMI=m
CONFIG_DELL_WMI_AIO=m
CONFIG_FUJITSU_LAPTOP=m
# CONFIG_FUJITSU_LAPTOP_DEBUG is not set
CONFIG_FUJITSU_TABLET=m
CONFIG_AMILO_RFKILL=m
CONFIG_HP_ACCEL=m
CONFIG_HP_WMI=m
CONFIG_MSI_LAPTOP=m
CONFIG_PANASONIC_LAPTOP=m
CONFIG_COMPAL_LAPTOP=m
CONFIG_SONY_LAPTOP=m
CONFIG_SONYPI_COMPAT=y
CONFIG_IDEAPAD_LAPTOP=m
CONFIG_THINKPAD_ACPI=m
CONFIG_THINKPAD_ACPI_ALSA_SUPPORT=y
# CONFIG_THINKPAD_ACPI_DEBUGFACILITIES is not set
# CONFIG_THINKPAD_ACPI_DEBUG is not set
# CONFIG_THINKPAD_ACPI_UNSAFE_LEDS is not set
CONFIG_THINKPAD_ACPI_VIDEO=y
CONFIG_THINKPAD_ACPI_HOTKEY_POLL=y
CONFIG_SENSORS_HDAPS=m
# CONFIG_INTEL_MENLOW is not set
CONFIG_EEEPC_LAPTOP=m
CONFIG_ASUS_WMI=m
CONFIG_ASUS_NB_WMI=m
CONFIG_EEEPC_WMI=m
CONFIG_ACPI_WMI=m
CONFIG_MSI_WMI=m
CONFIG_TOPSTAR_LAPTOP=m
CONFIG_ACPI_TOSHIBA=m
CONFIG_TOSHIBA_BT_RFKILL=m
CONFIG_ACPI_CMPC=m
CONFIG_INTEL_IPS=m
# CONFIG_IBM_RTL is not set
# CONFIG_XO15_EBOOK is not set
CONFIG_SAMSUNG_LAPTOP=m
CONFIG_MXM_WMI=m
CONFIG_INTEL_OAKTRAIL=m
CONFIG_SAMSUNG_Q10=m
CONFIG_APPLE_GMUX=m

#
# Hardware Spinlock drivers
#
CONFIG_CLKEVT_I8253=y
CONFIG_I8253_LOCK=y
CONFIG_CLKBLD_I8253=y
# CONFIG_MAILBOX is not set
CONFIG_IOMMU_API=y
CONFIG_IOMMU_SUPPORT=y
CONFIG_AMD_IOMMU=y
CONFIG_AMD_IOMMU_STATS=y
CONFIG_AMD_IOMMU_V2=m
CONFIG_DMAR_TABLE=y
CONFIG_INTEL_IOMMU=y
# CONFIG_INTEL_IOMMU_DEFAULT_ON is not set
CONFIG_INTEL_IOMMU_FLOPPY_WA=y
CONFIG_IRQ_REMAP=y

#
# Remoteproc drivers
#
# CONFIG_STE_MODEM_RPROC is not set

#
# Rpmsg drivers
#
# CONFIG_VIRT_DRIVERS is not set
# CONFIG_PM_DEVFREQ is not set
# CONFIG_EXTCON is not set
# CONFIG_MEMORY is not set
# CONFIG_IIO is not set
# CONFIG_NTB is not set
# CONFIG_VME_BUS is not set
# CONFIG_PWM is not set
# CONFIG_IPACK_BUS is not set

#
# Firmware Drivers
#
CONFIG_EDD=m
# CONFIG_EDD_OFF is not set
CONFIG_FIRMWARE_MEMMAP=y
CONFIG_EFI_VARS=y
CONFIG_DELL_RBU=m
CONFIG_DCDBAS=m
CONFIG_DMIID=y
CONFIG_DMI_SYSFS=y
CONFIG_ISCSI_IBFT_FIND=y
CONFIG_ISCSI_IBFT=m
# CONFIG_GOOGLE_FIRMWARE is not set

#
# File systems
#
CONFIG_DCACHE_WORD_ACCESS=y
# CONFIG_EXT2_FS is not set
# CONFIG_EXT3_FS is not set
CONFIG_EXT4_FS=y
CONFIG_EXT4_USE_FOR_EXT23=y
CONFIG_EXT4_FS_POSIX_ACL=y
CONFIG_EXT4_FS_SECURITY=y
# CONFIG_EXT4_DEBUG is not set
CONFIG_JBD2=y
# CONFIG_JBD2_DEBUG is not set
CONFIG_FS_MBCACHE=y
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
CONFIG_XFS_FS=m
CONFIG_XFS_QUOTA=y
CONFIG_XFS_POSIX_ACL=y
# CONFIG_XFS_RT is not set
# CONFIG_XFS_DEBUG is not set
CONFIG_GFS2_FS=m
CONFIG_GFS2_FS_LOCKING_DLM=y
# CONFIG_OCFS2_FS is not set
CONFIG_BTRFS_FS=m
CONFIG_BTRFS_FS_POSIX_ACL=y
# CONFIG_BTRFS_FS_CHECK_INTEGRITY is not set
# CONFIG_NILFS2_FS is not set
CONFIG_FS_POSIX_ACL=y
CONFIG_EXPORTFS=y
CONFIG_FILE_LOCKING=y
CONFIG_FSNOTIFY=y
CONFIG_DNOTIFY=y
CONFIG_INOTIFY_USER=y
CONFIG_FANOTIFY=y
CONFIG_FANOTIFY_ACCESS_PERMISSIONS=y
CONFIG_QUOTA=y
CONFIG_QUOTA_NETLINK_INTERFACE=y
CONFIG_PRINT_QUOTA_WARNING=y
# CONFIG_QUOTA_DEBUG is not set
CONFIG_QUOTA_TREE=y
# CONFIG_QFMT_V1 is not set
CONFIG_QFMT_V2=y
CONFIG_QUOTACTL=y
CONFIG_QUOTACTL_COMPAT=y
CONFIG_AUTOFS4_FS=y
CONFIG_FUSE_FS=m
CONFIG_CUSE=m
CONFIG_GENERIC_ACL=y

#
# Caches
#
CONFIG_FSCACHE=m
CONFIG_FSCACHE_STATS=y
# CONFIG_FSCACHE_HISTOGRAM is not set
# CONFIG_FSCACHE_DEBUG is not set
CONFIG_FSCACHE_OBJECT_LIST=y
CONFIG_CACHEFILES=m
# CONFIG_CACHEFILES_DEBUG is not set
# CONFIG_CACHEFILES_HISTOGRAM is not set

#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=y
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="ascii"
# CONFIG_NTFS_FS is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_PROC_VMCORE=y
CONFIG_PROC_SYSCTL=y
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
CONFIG_TMPFS_POSIX_ACL=y
CONFIG_TMPFS_XATTR=y
CONFIG_HUGETLBFS=y
CONFIG_HUGETLB_PAGE=y
CONFIG_CONFIGFS_FS=y
CONFIG_MISC_FILESYSTEMS=y
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_ECRYPT_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# 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_UBIFS_FS is not set
# CONFIG_LOGFS is not set
CONFIG_CRAMFS=m
CONFIG_SQUASHFS=m
CONFIG_SQUASHFS_XATTR=y
CONFIG_SQUASHFS_ZLIB=y
CONFIG_SQUASHFS_LZO=y
CONFIG_SQUASHFS_XZ=y
# CONFIG_SQUASHFS_4K_DEVBLK_SIZE is not set
# CONFIG_SQUASHFS_EMBEDDED is not set
CONFIG_SQUASHFS_FRAGMENT_CACHE_SIZE=3
# 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_QNX6FS_FS is not set
# CONFIG_ROMFS_FS is not set
CONFIG_PSTORE=y
# CONFIG_PSTORE_CONSOLE is not set
# CONFIG_PSTORE_FTRACE is not set
CONFIG_PSTORE_RAM=m
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
# CONFIG_EXOFS_FS is not set
# CONFIG_F2FS_FS is not set
CONFIG_ORE=m
CONFIG_NETWORK_FILESYSTEMS=y
CONFIG_NFS_FS=m
CONFIG_NFS_V2=m
CONFIG_NFS_V3=m
CONFIG_NFS_V3_ACL=y
CONFIG_NFS_V4=m
# CONFIG_NFS_SWAP is not set
CONFIG_NFS_V4_1=y
CONFIG_PNFS_FILE_LAYOUT=m
CONFIG_PNFS_BLOCK=m
CONFIG_PNFS_OBJLAYOUT=m
CONFIG_NFS_V4_1_IMPLEMENTATION_ID_DOMAIN="kernel.org"
CONFIG_NFS_FSCACHE=y
# CONFIG_NFS_USE_LEGACY_DNS is not set
CONFIG_NFS_USE_KERNEL_DNS=y
CONFIG_NFS_DEBUG=y
CONFIG_NFSD=m
CONFIG_NFSD_V2_ACL=y
CONFIG_NFSD_V3=y
CONFIG_NFSD_V3_ACL=y
CONFIG_NFSD_V4=y
# CONFIG_NFSD_FAULT_INJECTION is not set
CONFIG_LOCKD=m
CONFIG_LOCKD_V4=y
CONFIG_NFS_ACL_SUPPORT=m
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=m
CONFIG_SUNRPC_GSS=m
CONFIG_SUNRPC_BACKCHANNEL=y
CONFIG_SUNRPC_XPRT_RDMA=m
CONFIG_RPCSEC_GSS_KRB5=m
CONFIG_SUNRPC_DEBUG=y
# CONFIG_CEPH_FS is not set
CONFIG_CIFS=m
CONFIG_CIFS_STATS=y
# CONFIG_CIFS_STATS2 is not set
CONFIG_CIFS_WEAK_PW_HASH=y
CONFIG_CIFS_UPCALL=y
CONFIG_CIFS_XATTR=y
CONFIG_CIFS_POSIX=y
CONFIG_CIFS_ACL=y
CONFIG_CIFS_DEBUG=y
# CONFIG_CIFS_DEBUG2 is not set
CONFIG_CIFS_DFS_UPCALL=y
CONFIG_CIFS_SMB2=y
# CONFIG_CIFS_FSCACHE is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set
# CONFIG_9P_FS is not set
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="utf8"
CONFIG_NLS_CODEPAGE_437=y
CONFIG_NLS_CODEPAGE_737=m
CONFIG_NLS_CODEPAGE_775=m
CONFIG_NLS_CODEPAGE_850=m
CONFIG_NLS_CODEPAGE_852=m
CONFIG_NLS_CODEPAGE_855=m
CONFIG_NLS_CODEPAGE_857=m
CONFIG_NLS_CODEPAGE_860=m
CONFIG_NLS_CODEPAGE_861=m
CONFIG_NLS_CODEPAGE_862=m
CONFIG_NLS_CODEPAGE_863=m
CONFIG_NLS_CODEPAGE_864=m
CONFIG_NLS_CODEPAGE_865=m
CONFIG_NLS_CODEPAGE_866=m
CONFIG_NLS_CODEPAGE_869=m
CONFIG_NLS_CODEPAGE_936=m
CONFIG_NLS_CODEPAGE_950=m
CONFIG_NLS_CODEPAGE_932=m
CONFIG_NLS_CODEPAGE_949=m
CONFIG_NLS_CODEPAGE_874=m
CONFIG_NLS_ISO8859_8=m
CONFIG_NLS_CODEPAGE_1250=m
CONFIG_NLS_CODEPAGE_1251=m
CONFIG_NLS_ASCII=y
CONFIG_NLS_ISO8859_1=m
CONFIG_NLS_ISO8859_2=m
CONFIG_NLS_ISO8859_3=m
CONFIG_NLS_ISO8859_4=m
CONFIG_NLS_ISO8859_5=m
CONFIG_NLS_ISO8859_6=m
CONFIG_NLS_ISO8859_7=m
CONFIG_NLS_ISO8859_9=m
CONFIG_NLS_ISO8859_13=m
CONFIG_NLS_ISO8859_14=m
CONFIG_NLS_ISO8859_15=m
CONFIG_NLS_KOI8_R=m
CONFIG_NLS_KOI8_U=m
CONFIG_NLS_MAC_ROMAN=m
CONFIG_NLS_MAC_CELTIC=m
CONFIG_NLS_MAC_CENTEURO=m
CONFIG_NLS_MAC_CROATIAN=m
CONFIG_NLS_MAC_CYRILLIC=m
CONFIG_NLS_MAC_GAELIC=m
CONFIG_NLS_MAC_GREEK=m
CONFIG_NLS_MAC_ICELAND=m
CONFIG_NLS_MAC_INUIT=m
CONFIG_NLS_MAC_ROMANIAN=m
CONFIG_NLS_MAC_TURKISH=m
CONFIG_NLS_UTF8=m
CONFIG_DLM=m
CONFIG_DLM_DEBUG=y

#
# Kernel hacking
#
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_PRINTK_TIME=y
CONFIG_DEFAULT_MESSAGE_LOGLEVEL=4
# CONFIG_ENABLE_WARN_DEPRECATED is not set
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_FRAME_WARN=2048
CONFIG_MAGIC_SYSRQ=y
CONFIG_STRIP_ASM_SYMS=y
# CONFIG_READABLE_ASM is not set
# CONFIG_UNUSED_SYMBOLS is not set
CONFIG_DEBUG_FS=y
CONFIG_HEADERS_CHECK=y
CONFIG_DEBUG_SECTION_MISMATCH=y
CONFIG_DEBUG_KERNEL=y
CONFIG_DEBUG_SHIRQ=y
CONFIG_LOCKUP_DETECTOR=y
CONFIG_HARDLOCKUP_DETECTOR=y
CONFIG_BOOTPARAM_HARDLOCKUP_PANIC=y
CONFIG_BOOTPARAM_HARDLOCKUP_PANIC_VALUE=1
# CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC is not set
CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC_VALUE=0
# CONFIG_PANIC_ON_OOPS is not set
CONFIG_PANIC_ON_OOPS_VALUE=0
CONFIG_DETECT_HUNG_TASK=y
CONFIG_DEFAULT_HUNG_TASK_TIMEOUT=120
# 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_HAVE_DEBUG_KMEMLEAK=y
# CONFIG_DEBUG_KMEMLEAK is not set
# CONFIG_DEBUG_RT_MUTEXES is not set
# CONFIG_RT_MUTEX_TESTER is not set
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_MUTEXES is not set
# CONFIG_DEBUG_LOCK_ALLOC is not set
# CONFIG_PROVE_LOCKING is not set
# CONFIG_LOCK_STAT is not set
# CONFIG_DEBUG_ATOMIC_SLEEP is not set
# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
CONFIG_STACKTRACE=y
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_DEBUG_KOBJECT is not set
CONFIG_DEBUG_BUGVERBOSE=y
CONFIG_DEBUG_INFO=y
# CONFIG_DEBUG_INFO_REDUCED is not set
CONFIG_DEBUG_VM=y
# CONFIG_DEBUG_VM_RB is not set
# CONFIG_DEBUG_VIRTUAL is not set
# CONFIG_DEBUG_WRITECOUNT is not set
CONFIG_DEBUG_MEMORY_INIT=y
CONFIG_DEBUG_LIST=y
# CONFIG_TEST_LIST_SORT is not set
# CONFIG_DEBUG_SG is not set
# CONFIG_DEBUG_NOTIFIERS is not set
# CONFIG_DEBUG_CREDENTIALS is not set
CONFIG_ARCH_WANT_FRAME_POINTERS=y
CONFIG_FRAME_POINTER=y
CONFIG_BOOT_PRINTK_DELAY=y

#
# RCU Debugging
#
CONFIG_SPARSE_RCU_POINTER=y
# CONFIG_RCU_TORTURE_TEST is not set
CONFIG_RCU_CPU_STALL_TIMEOUT=60
# CONFIG_RCU_CPU_STALL_INFO is not set
# CONFIG_RCU_TRACE is not set
# CONFIG_KPROBES_SANITY_TEST is not set
# CONFIG_BACKTRACE_SELF_TEST is not set
# CONFIG_DEBUG_BLOCK_EXT_DEVT is not set
# CONFIG_DEBUG_FORCE_WEAK_PER_CPU is not set
# CONFIG_DEBUG_PER_CPU_MAPS is not set
# CONFIG_LKDTM is not set
# CONFIG_NOTIFIER_ERROR_INJECTION is not set
# CONFIG_FAULT_INJECTION is not set
CONFIG_LATENCYTOP=y
# CONFIG_DEBUG_PAGEALLOC is not set
CONFIG_USER_STACKTRACE_SUPPORT=y
CONFIG_NOP_TRACER=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_DYNAMIC_FTRACE_WITH_REGS=y
CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
CONFIG_HAVE_SYSCALL_TRACEPOINTS=y
CONFIG_HAVE_FENTRY=y
CONFIG_HAVE_C_RECORDMCOUNT=y
CONFIG_TRACER_MAX_TRACE=y
CONFIG_TRACE_CLOCK=y
CONFIG_RING_BUFFER=y
CONFIG_EVENT_TRACING=y
CONFIG_CONTEXT_SWITCH_TRACER=y
CONFIG_RING_BUFFER_ALLOW_SWAP=y
CONFIG_TRACING=y
CONFIG_GENERIC_TRACER=y
CONFIG_TRACING_SUPPORT=y
CONFIG_FTRACE=y
CONFIG_FUNCTION_TRACER=y
CONFIG_FUNCTION_GRAPH_TRACER=y
# CONFIG_IRQSOFF_TRACER is not set
CONFIG_SCHED_TRACER=y
CONFIG_FTRACE_SYSCALLS=y
# CONFIG_TRACER_SNAPSHOT is not set
CONFIG_BRANCH_PROFILE_NONE=y
# CONFIG_PROFILE_ANNOTATED_BRANCHES is not set
# CONFIG_PROFILE_ALL_BRANCHES is not set
CONFIG_STACK_TRACER=y
CONFIG_BLK_DEV_IO_TRACE=y
CONFIG_KPROBE_EVENT=y
CONFIG_UPROBE_EVENT=y
CONFIG_PROBE_EVENTS=y
CONFIG_DYNAMIC_FTRACE=y
CONFIG_DYNAMIC_FTRACE_WITH_REGS=y
CONFIG_FUNCTION_PROFILER=y
CONFIG_FTRACE_MCOUNT_RECORD=y
# CONFIG_FTRACE_STARTUP_TEST is not set
# CONFIG_MMIOTRACE is not set
CONFIG_RING_BUFFER_BENCHMARK=m
# CONFIG_RBTREE_TEST is not set
# CONFIG_INTERVAL_TREE_TEST is not set
CONFIG_PROVIDE_OHCI1394_DMA_INIT=y
# CONFIG_FIREWIRE_OHCI_REMOTE_DMA is not set
CONFIG_BUILD_DOCSRC=y
CONFIG_DYNAMIC_DEBUG=y
# CONFIG_DMA_API_DEBUG is not set
CONFIG_ATOMIC64_SELFTEST=y
CONFIG_ASYNC_RAID6_TEST=m
# CONFIG_SAMPLES is not set
CONFIG_HAVE_ARCH_KGDB=y
CONFIG_KGDB=y
CONFIG_KGDB_SERIAL_CONSOLE=y
CONFIG_KGDB_TESTS=y
# CONFIG_KGDB_TESTS_ON_BOOT is not set
CONFIG_KGDB_LOW_LEVEL_TRAP=y
CONFIG_KGDB_KDB=y
CONFIG_KDB_KEYBOARD=y
CONFIG_KDB_CONTINUE_CATASTROPHIC=0
CONFIG_HAVE_ARCH_KMEMCHECK=y
CONFIG_TEST_KSTRTOX=y
CONFIG_STRICT_DEVMEM=y
# CONFIG_X86_VERBOSE_BOOTUP is not set
CONFIG_EARLY_PRINTK=y
CONFIG_EARLY_PRINTK_DBGP=y
CONFIG_DEBUG_STACKOVERFLOW=y
# CONFIG_X86_PTDUMP is not set
# CONFIG_DEBUG_RODATA is not set
CONFIG_DEBUG_SET_MODULE_RONX=y
CONFIG_DEBUG_NX_TEST=m
# CONFIG_DEBUG_TLBFLUSH is not set
# CONFIG_IOMMU_DEBUG is not set
# CONFIG_IOMMU_STRESS is not set
CONFIG_HAVE_MMIOTRACE_SUPPORT=y
CONFIG_X86_DECODER_SELFTEST=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=y
# CONFIG_CPA_DEBUG is not set
CONFIG_OPTIMIZE_INLINING=y
# CONFIG_DEBUG_STRICT_USER_COPY_CHECKS is not set
# CONFIG_DEBUG_NMI_SELFTEST is not set

#
# Security options
#
CONFIG_KEYS=y
CONFIG_TRUSTED_KEYS=m
CONFIG_ENCRYPTED_KEYS=m
CONFIG_KEYS_DEBUG_PROC_KEYS=y
# CONFIG_SECURITY_DMESG_RESTRICT 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_INTEL_TXT=y
CONFIG_LSM_MMAP_MIN_ADDR=65535
CONFIG_SECURITY_SELINUX=y
CONFIG_SECURITY_SELINUX_BOOTPARAM=y
CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=1
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_SMACK is not set
# CONFIG_SECURITY_TOMOYO is not set
# CONFIG_SECURITY_APPARMOR is not set
# CONFIG_SECURITY_YAMA is not set
CONFIG_INTEGRITY=y
CONFIG_INTEGRITY_SIGNATURE=y
# CONFIG_INTEGRITY_ASYMMETRIC_KEYS is not set
CONFIG_IMA=y
CONFIG_IMA_MEASURE_PCR_IDX=10
CONFIG_IMA_AUDIT=y
CONFIG_IMA_LSM_RULES=y
# CONFIG_IMA_APPRAISE is not set
CONFIG_DEFAULT_SECURITY_SELINUX=y
# CONFIG_DEFAULT_SECURITY_DAC is not set
CONFIG_DEFAULT_SECURITY="selinux"
CONFIG_XOR_BLOCKS=m
CONFIG_ASYNC_CORE=m
CONFIG_ASYNC_MEMCPY=m
CONFIG_ASYNC_XOR=m
CONFIG_ASYNC_PQ=m
CONFIG_ASYNC_RAID6_RECOV=m
CONFIG_ASYNC_TX_DISABLE_PQ_VAL_DMA=y
CONFIG_ASYNC_TX_DISABLE_XOR_VAL_DMA=y
CONFIG_CRYPTO=y

#
# Crypto core or helper
#
CONFIG_CRYPTO_FIPS=y
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_ALGAPI2=y
CONFIG_CRYPTO_AEAD=y
CONFIG_CRYPTO_AEAD2=y
CONFIG_CRYPTO_BLKCIPHER=y
CONFIG_CRYPTO_BLKCIPHER2=y
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_HASH2=y
CONFIG_CRYPTO_RNG=y
CONFIG_CRYPTO_RNG2=y
CONFIG_CRYPTO_PCOMP=m
CONFIG_CRYPTO_PCOMP2=y
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_MANAGER2=y
CONFIG_CRYPTO_USER=m
# CONFIG_CRYPTO_MANAGER_DISABLE_TESTS is not set
CONFIG_CRYPTO_GF128MUL=y
CONFIG_CRYPTO_NULL=m
CONFIG_CRYPTO_PCRYPT=m
CONFIG_CRYPTO_WORKQUEUE=y
CONFIG_CRYPTO_CRYPTD=y
CONFIG_CRYPTO_AUTHENC=m
CONFIG_CRYPTO_TEST=m
CONFIG_CRYPTO_ABLK_HELPER_X86=y
CONFIG_CRYPTO_GLUE_HELPER_X86=m

#
# Authenticated Encryption with Associated Data
#
CONFIG_CRYPTO_CCM=m
CONFIG_CRYPTO_GCM=m
CONFIG_CRYPTO_SEQIV=y

#
# Block modes
#
CONFIG_CRYPTO_CBC=y
CONFIG_CRYPTO_CTR=y
CONFIG_CRYPTO_CTS=m
CONFIG_CRYPTO_ECB=y
CONFIG_CRYPTO_LRW=y
CONFIG_CRYPTO_PCBC=m
CONFIG_CRYPTO_XTS=y

#
# Hash modes
#
CONFIG_CRYPTO_HMAC=y
CONFIG_CRYPTO_XCBC=m
CONFIG_CRYPTO_VMAC=m

#
# Digest
#
CONFIG_CRYPTO_CRC32C=y
CONFIG_CRYPTO_CRC32C_X86_64=y
CONFIG_CRYPTO_CRC32C_INTEL=m
# CONFIG_CRYPTO_CRC32 is not set
# CONFIG_CRYPTO_CRC32_PCLMUL is not set
CONFIG_CRYPTO_GHASH=m
CONFIG_CRYPTO_MD4=m
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_MICHAEL_MIC=m
CONFIG_CRYPTO_RMD128=m
CONFIG_CRYPTO_RMD160=m
CONFIG_CRYPTO_RMD256=m
CONFIG_CRYPTO_RMD320=m
CONFIG_CRYPTO_SHA1=y
CONFIG_CRYPTO_SHA1_SSSE3=m
CONFIG_CRYPTO_SHA256=y
CONFIG_CRYPTO_SHA512=m
CONFIG_CRYPTO_TGR192=m
CONFIG_CRYPTO_WP512=m
CONFIG_CRYPTO_GHASH_CLMUL_NI_INTEL=m

#
# Ciphers
#
CONFIG_CRYPTO_AES=y
CONFIG_CRYPTO_AES_X86_64=y
CONFIG_CRYPTO_AES_NI_INTEL=y
CONFIG_CRYPTO_ANUBIS=m
CONFIG_CRYPTO_ARC4=m
CONFIG_CRYPTO_BLOWFISH=m
CONFIG_CRYPTO_BLOWFISH_COMMON=m
CONFIG_CRYPTO_BLOWFISH_X86_64=m
CONFIG_CRYPTO_CAMELLIA=m
CONFIG_CRYPTO_CAMELLIA_X86_64=m
# CONFIG_CRYPTO_CAMELLIA_AESNI_AVX_X86_64 is not set
CONFIG_CRYPTO_CAST_COMMON=m
CONFIG_CRYPTO_CAST5=m
CONFIG_CRYPTO_CAST5_AVX_X86_64=m
CONFIG_CRYPTO_CAST6=m
CONFIG_CRYPTO_CAST6_AVX_X86_64=m
CONFIG_CRYPTO_DES=m
CONFIG_CRYPTO_FCRYPT=m
CONFIG_CRYPTO_KHAZAD=m
CONFIG_CRYPTO_SALSA20=m
CONFIG_CRYPTO_SALSA20_X86_64=m
CONFIG_CRYPTO_SEED=m
CONFIG_CRYPTO_SERPENT=m
CONFIG_CRYPTO_SERPENT_SSE2_X86_64=m
CONFIG_CRYPTO_SERPENT_AVX_X86_64=m
CONFIG_CRYPTO_TEA=m
CONFIG_CRYPTO_TWOFISH=m
CONFIG_CRYPTO_TWOFISH_COMMON=m
CONFIG_CRYPTO_TWOFISH_X86_64=m
CONFIG_CRYPTO_TWOFISH_X86_64_3WAY=m
CONFIG_CRYPTO_TWOFISH_AVX_X86_64=m

#
# Compression
#
CONFIG_CRYPTO_DEFLATE=m
CONFIG_CRYPTO_ZLIB=m
CONFIG_CRYPTO_LZO=m

#
# Random Number Generation
#
CONFIG_CRYPTO_ANSI_CPRNG=m
CONFIG_CRYPTO_USER_API=y
CONFIG_CRYPTO_USER_API_HASH=y
CONFIG_CRYPTO_USER_API_SKCIPHER=y
CONFIG_CRYPTO_HW=y
CONFIG_CRYPTO_DEV_PADLOCK=m
CONFIG_CRYPTO_DEV_PADLOCK_AES=m
CONFIG_CRYPTO_DEV_PADLOCK_SHA=m
CONFIG_ASYMMETRIC_KEY_TYPE=y
CONFIG_ASYMMETRIC_PUBLIC_KEY_SUBTYPE=y
CONFIG_PUBLIC_KEY_ALGO_RSA=y
CONFIG_X509_CERTIFICATE_PARSER=y
CONFIG_HAVE_KVM=y
CONFIG_HAVE_KVM_IRQCHIP=y
CONFIG_HAVE_KVM_EVENTFD=y
CONFIG_KVM_APIC_ARCHITECTURE=y
CONFIG_KVM_MMIO=y
CONFIG_KVM_ASYNC_PF=y
CONFIG_HAVE_KVM_MSI=y
CONFIG_HAVE_KVM_CPU_RELAX_INTERCEPT=y
CONFIG_VIRTUALIZATION=y
CONFIG_KVM=m
CONFIG_KVM_INTEL=m
CONFIG_KVM_AMD=m
CONFIG_KVM_MMU_AUDIT=y
CONFIG_VHOST_NET=m
CONFIG_TCM_VHOST=m
CONFIG_BINARY_PRINTF=y

#
# Library routines
#
CONFIG_RAID6_PQ=m
CONFIG_BITREVERSE=y
CONFIG_GENERIC_STRNCPY_FROM_USER=y
CONFIG_GENERIC_STRNLEN_USER=y
CONFIG_GENERIC_FIND_FIRST_BIT=y
CONFIG_GENERIC_PCI_IOMAP=y
CONFIG_GENERIC_IOMAP=y
CONFIG_GENERIC_IO=y
CONFIG_PERCPU_RWSEM=y
CONFIG_CRC_CCITT=m
CONFIG_CRC16=y
CONFIG_CRC_T10DIF=m
CONFIG_CRC_ITU_T=m
CONFIG_CRC32=y
# CONFIG_CRC32_SELFTEST is not set
CONFIG_CRC32_SLICEBY8=y
# CONFIG_CRC32_SLICEBY4 is not set
# CONFIG_CRC32_SARWATE is not set
# CONFIG_CRC32_BIT is not set
# CONFIG_CRC7 is not set
CONFIG_LIBCRC32C=m
CONFIG_CRC8=m
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=m
CONFIG_LZO_COMPRESS=y
CONFIG_LZO_DECOMPRESS=y
CONFIG_XZ_DEC=y
CONFIG_XZ_DEC_X86=y
CONFIG_XZ_DEC_POWERPC=y
CONFIG_XZ_DEC_IA64=y
CONFIG_XZ_DEC_ARM=y
CONFIG_XZ_DEC_ARMTHUMB=y
CONFIG_XZ_DEC_SPARC=y
CONFIG_XZ_DEC_BCJ=y
# CONFIG_XZ_DEC_TEST is not set
CONFIG_DECOMPRESS_GZIP=y
CONFIG_DECOMPRESS_BZIP2=y
CONFIG_DECOMPRESS_LZMA=y
CONFIG_DECOMPRESS_XZ=y
CONFIG_DECOMPRESS_LZO=y
CONFIG_GENERIC_ALLOCATOR=y
CONFIG_REED_SOLOMON=m
CONFIG_REED_SOLOMON_ENC8=y
CONFIG_REED_SOLOMON_DEC8=y
CONFIG_TEXTSEARCH=y
CONFIG_TEXTSEARCH_KMP=m
CONFIG_TEXTSEARCH_BM=m
CONFIG_TEXTSEARCH_FSM=m
CONFIG_BTREE=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
CONFIG_CHECK_SIGNATURE=y
CONFIG_CPUMASK_OFFSTACK=y
CONFIG_CPU_RMAP=y
CONFIG_DQL=y
CONFIG_NLATTR=y
CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE=y
CONFIG_AVERAGE=y
CONFIG_CLZ_TAB=y
CONFIG_CORDIC=m
# CONFIG_DDR is not set
CONFIG_MPILIB=y
CONFIG_SIGNATURE=y
CONFIG_OID_REGISTRY=y

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: 3.9-rc1: crash kernel panic - not syncing: Can not allocate SWIOTLB buffer earlier and can't now provide you with the DMA bounce buffer
  2013-03-08 12:12               ` WANG Chao
@ 2013-03-08 18:24                 ` Yinghai Lu
  2013-03-08 19:39                   ` Yinghai Lu
  0 siblings, 1 reply; 101+ messages in thread
From: Yinghai Lu @ 2013-03-08 18:24 UTC (permalink / raw)
  To: WANG Chao
  Cc: CAI Qian, LKML, kexec, Dave Young, Vivek Goyal, H. Peter Anvin,
	Takao Indoh

On Fri, Mar 8, 2013 at 4:12 AM, WANG Chao <chaowang@redhat.com> wrote:

>> what is 00:02.0 in your system?
> This IOMMU issue is related to https://lkml.org/lkml/2012/11/26/814. We can
> discuss this IOMMU issue in that thread.
> Anyway 00:02.0 is a video card, the box is Ivy Bridge.
> # lspci -s 00:02.0 -v
> 00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor
> Graphics Controller (rev 09) (prog-if 00 [VGA controller])
>         Subsystem: Intel Corporation Device 2211
>         Flags: bus master, fast devsel, latency 0, IRQ 44
>         Memory at afc00000 (64-bit, non-prefetchable) [size=4M]
>         Memory at c0000000 (64-bit, prefetchable) [size=256M]
>         I/O ports at 6000 [size=64]
>         Expansion ROM at <unassigned> [disabled]
>         Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
>         Capabilities: [d0] Power Management version 2
>         Capabilities: [a4] PCI Advanced Features
>         Kernel driver in use: i915

disable drm for i915 will make your iommu work with dump?

>
>
> Is it expected to intel_iommu=on or crashkernel_low to make 2nd kernel boot in
> 3.9? Back in 3.8, it works just fine w/ only crashkernel param.

Yes, I really do not want to set crashkernel low range like 72M
automatically for all.
that would have the system with proper iommu support lose 72M under 4G
in first kernel.
And can not play allocate and return tricks, as first kernel have no
idea if iommu will work
on second kernel even iommu is working on first kernel.

Better to fix iommu support at first.

For old system that does not have DMAR or kernel does not have IOMMU
support enabled, or
user does not pass intel_iommu=on.
We could set crashkernel low range to 72M automatically.

Thanks

Yinghai

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: 3.9-rc1: crash kernel panic - not syncing: Can not allocate SWIOTLB buffer earlier and can't now provide you with the DMA bounce buffer
  2013-03-08 18:24                 ` Yinghai Lu
@ 2013-03-08 19:39                   ` Yinghai Lu
  2013-03-11  3:42                     ` WANG Chao
  2013-03-11 13:14                     ` 3.9-rc1: crash kernel panic - not syncing: Can not allocate SWIOTLB buffer earlier and can't now provide you with the DMA bounce buffer Konrad Rzeszutek Wilk
  0 siblings, 2 replies; 101+ messages in thread
From: Yinghai Lu @ 2013-03-08 19:39 UTC (permalink / raw)
  To: WANG Chao, Vivek Goyal, Eric W. Biederman, H. Peter Anvin,
	Shuah Khan, Konrad Rzeszutek Wilk
  Cc: CAI Qian, LKML, kexec, Dave Young, Takao Indoh

[-- Attachment #1: Type: text/plain, Size: 2177 bytes --]

[ Add more to To list ]

On Fri, Mar 8, 2013 at 10:24 AM, Yinghai Lu <yinghai@kernel.org> wrote:
> On Fri, Mar 8, 2013 at 4:12 AM, WANG Chao <chaowang@redhat.com> wrote:
>
>>> what is 00:02.0 in your system?
>> This IOMMU issue is related to https://lkml.org/lkml/2012/11/26/814. We can
>> discuss this IOMMU issue in that thread.
>> Anyway 00:02.0 is a video card, the box is Ivy Bridge.
>> # lspci -s 00:02.0 -v
>> 00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor
>> Graphics Controller (rev 09) (prog-if 00 [VGA controller])
>>         Subsystem: Intel Corporation Device 2211
>>         Flags: bus master, fast devsel, latency 0, IRQ 44
>>         Memory at afc00000 (64-bit, non-prefetchable) [size=4M]
>>         Memory at c0000000 (64-bit, prefetchable) [size=256M]
>>         I/O ports at 6000 [size=64]
>>         Expansion ROM at <unassigned> [disabled]
>>         Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
>>         Capabilities: [d0] Power Management version 2
>>         Capabilities: [a4] PCI Advanced Features
>>         Kernel driver in use: i915
>
> disable drm for i915 will make your iommu work with dump?
>
>>
>>
>> Is it expected to intel_iommu=on or crashkernel_low to make 2nd kernel boot in
>> 3.9? Back in 3.8, it works just fine w/ only crashkernel param.
>
> Yes, I really do not want to set crashkernel low range like 72M
> automatically for all.
> that would have the system with proper iommu support lose 72M under 4G
> in first kernel.
> And can not play allocate and return tricks, as first kernel have no
> idea if iommu will work
> on second kernel even iommu is working on first kernel.
>
> Better to fix iommu support at first.
>
> For old system that does not have DMAR or kernel does not have IOMMU
> support enabled, or
> user does not pass intel_iommu=on.
> We could set crashkernel low range to 72M automatically.

It seem that it is not worthy to check case that does not support
IOMMU in second kernel.

Please check attached patch that will just set crashkernel_low auto, and if the
system DO support iommu with kdump, user can specify crashkernel_low=0
to save low 72M.

Thanks

Yinghai

[-- Attachment #2: fix_crashkernel_low.patch --]
[-- Type: application/octet-stream, Size: 1800 bytes --]

Subject: [PATCH} x86, kdump: auto set crashkernel low size

Current code does not set low range for crashkernel if
the user does not specify that.

That cause regressions on system that does not support
intel_iommu properly.

Chao said his system does work well on 3.8 without extra parameter.
and iommu does not work with kdump.

Set low automatically if the user does not specify that.

For system that does support IOMMU with kdump properly, user could
specify crashkernel_low=0 to save that 72M low ram.

Reported-by: WANG Chao <chaowang@redhat.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>

---
 arch/x86/kernel/setup.c |   15 ++++++++++++---
 1 file changed, 12 insertions(+), 3 deletions(-)

Index: linux-2.6/arch/x86/kernel/setup.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/setup.c
+++ linux-2.6/arch/x86/kernel/setup.c
@@ -521,19 +521,28 @@ static void __init reserve_crashkernel_l
 	unsigned long long low_base = 0, low_size = 0;
 	unsigned long total_low_mem;
 	unsigned long long base;
+	bool auto_set = false;
 	int ret;
 
 	total_low_mem = memblock_mem_size(1UL<<(32-PAGE_SHIFT));
 	ret = parse_crashkernel_low(boot_command_line, total_low_mem,
 						&low_size, &base);
-	if (ret != 0 || low_size <= 0)
-		return;
+	if (ret != 0) {
+		/* default swiotlb size and overflow: 64M + 8M */
+		low_size = 72UL << 20;
+		auto_set = true;
+	} else {
+		/* passed with crashkernel_low=0 ? */
+		if (!low_size)
+			return;
+	}
 
 	low_base = memblock_find_in_range(low_size, (1ULL<<32),
 					low_size, alignment);
 
 	if (!low_base) {
-		pr_info("crashkernel low reservation failed - No suitable area found.\n");
+		if (!auto_set)
+			pr_info("crashkernel low reservation failed - No suitable area found.\n");
 
 		return;
 	}

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: 3.9-rc1: crash kernel panic - not syncing: Can not allocate SWIOTLB buffer earlier and can't now provide you with the DMA bounce buffer
  2013-03-08 19:39                   ` Yinghai Lu
@ 2013-03-11  3:42                     ` WANG Chao
  2013-03-11  4:56                       ` [PATCH] x86, kdump: Set crashkernel_low automatically Yinghai Lu
  2013-03-11 13:14                     ` 3.9-rc1: crash kernel panic - not syncing: Can not allocate SWIOTLB buffer earlier and can't now provide you with the DMA bounce buffer Konrad Rzeszutek Wilk
  1 sibling, 1 reply; 101+ messages in thread
From: WANG Chao @ 2013-03-11  3:42 UTC (permalink / raw)
  To: Yinghai Lu
  Cc: Vivek Goyal, Eric W. Biederman, H. Peter Anvin, Shuah Khan,
	Konrad Rzeszutek Wilk, CAI Qian, LKML, kexec, Dave Young,
	Takao Indoh

On 03/09/2013 03:39 AM, Yinghai Lu wrote:
> [ Add more to To list ]
> 
> On Fri, Mar 8, 2013 at 10:24 AM, Yinghai Lu <yinghai@kernel.org> wrote:
>> On Fri, Mar 8, 2013 at 4:12 AM, WANG Chao <chaowang@redhat.com> wrote:
>>
>>>> what is 00:02.0 in your system?
>>> This IOMMU issue is related to https://lkml.org/lkml/2012/11/26/814. We can
>>> discuss this IOMMU issue in that thread.
>>> Anyway 00:02.0 is a video card, the box is Ivy Bridge.
>>> # lspci -s 00:02.0 -v
>>> 00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor
>>> Graphics Controller (rev 09) (prog-if 00 [VGA controller])
>>>         Subsystem: Intel Corporation Device 2211
>>>         Flags: bus master, fast devsel, latency 0, IRQ 44
>>>         Memory at afc00000 (64-bit, non-prefetchable) [size=4M]
>>>         Memory at c0000000 (64-bit, prefetchable) [size=256M]
>>>         I/O ports at 6000 [size=64]
>>>         Expansion ROM at <unassigned> [disabled]
>>>         Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
>>>         Capabilities: [d0] Power Management version 2
>>>         Capabilities: [a4] PCI Advanced Features
>>>         Kernel driver in use: i915
>>
>> disable drm for i915 will make your iommu work with dump?
>>
>>>
>>>
>>> Is it expected to intel_iommu=on or crashkernel_low to make 2nd kernel boot in
>>> 3.9? Back in 3.8, it works just fine w/ only crashkernel param.
>>
>> Yes, I really do not want to set crashkernel low range like 72M
>> automatically for all.
>> that would have the system with proper iommu support lose 72M under 4G
>> in first kernel.
>> And can not play allocate and return tricks, as first kernel have no
>> idea if iommu will work
>> on second kernel even iommu is working on first kernel.
>>
>> Better to fix iommu support at first.
>>
>> For old system that does not have DMAR or kernel does not have IOMMU
>> support enabled, or
>> user does not pass intel_iommu=on.
>> We could set crashkernel low range to 72M automatically.
> 
> It seem that it is not worthy to check case that does not support
> IOMMU in second kernel.
> 
> Please check attached patch that will just set crashkernel_low auto, and if the
> system DO support iommu with kdump, user can specify crashkernel_low=0
> to save low 72M.

The patch works flawlessly on my box! Thank you, Yinghai!
Let me know if anything else I can help.

WANG Chao

> 
> Thanks
> 
> Yinghai
> 


^ permalink raw reply	[flat|nested] 101+ messages in thread

* [PATCH] x86, kdump: Set crashkernel_low automatically
  2013-03-11  3:42                     ` WANG Chao
@ 2013-03-11  4:56                       ` Yinghai Lu
  2013-03-11 14:48                         ` Vivek Goyal
  0 siblings, 1 reply; 101+ messages in thread
From: Yinghai Lu @ 2013-03-11  4:56 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin
  Cc: WANG Chao, Vivek Goyal, Eric W. Biederman, linux-kernel, Yinghai Lu

Current code does not set low range for crashkernel if the user
does not specify that.

That cause regressions on system that does not support intel_iommu
properly.

Chao said that his system does work well on 3.8 without extra parameter.
even iommu does not work with kdump.

Set crashkernel_low automatically if the user does not specify that.

For system that does support IOMMU with kdump properly, user could
specify crashkernel_low=0 to save that 72M low ram.

Reported-by: WANG Chao <chaowang@redhat.com>
Tested-by: WANG Chao <chaowang@redhat.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>

---
 arch/x86/kernel/setup.c |   15 ++++++++++++---
 1 file changed, 12 insertions(+), 3 deletions(-)

Index: linux-2.6/arch/x86/kernel/setup.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/setup.c
+++ linux-2.6/arch/x86/kernel/setup.c
@@ -547,19 +547,28 @@ static void __init reserve_crashkernel_l
 	unsigned long long low_base = 0, low_size = 0;
 	unsigned long total_low_mem;
 	unsigned long long base;
+	bool auto_set = false;
 	int ret;
 
 	total_low_mem = memblock_mem_size(1UL<<(32-PAGE_SHIFT));
 	ret = parse_crashkernel_low(boot_command_line, total_low_mem,
 						&low_size, &base);
-	if (ret != 0 || low_size <= 0)
-		return;
+	if (ret != 0) {
+		/* default swiotlb size and overflow: 64M + 8M */
+		low_size = 72UL<<20;
+		auto_set = true;
+	} else {
+		/* passed with crashkernel_low=0 ? */
+		if (!low_size)
+			return;
+	}
 
 	low_base = memblock_find_in_range(low_size, (1ULL<<32),
 					low_size, alignment);
 
 	if (!low_base) {
-		pr_info("crashkernel low reservation failed - No suitable area found.\n");
+		if (!auto_set)
+			pr_info("crashkernel low reservation failed - No suitable area found.\n");
 
 		return;
 	}

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: 3.9-rc1: crash kernel panic - not syncing: Can not allocate SWIOTLB buffer earlier and can't now provide you with the DMA bounce buffer
  2013-03-08 19:39                   ` Yinghai Lu
  2013-03-11  3:42                     ` WANG Chao
@ 2013-03-11 13:14                     ` Konrad Rzeszutek Wilk
  1 sibling, 0 replies; 101+ messages in thread
From: Konrad Rzeszutek Wilk @ 2013-03-11 13:14 UTC (permalink / raw)
  To: Yinghai Lu
  Cc: WANG Chao, Vivek Goyal, Eric W. Biederman, H. Peter Anvin,
	Shuah Khan, CAI Qian, LKML, kexec, Dave Young, Takao Indoh

On Fri, Mar 08, 2013 at 11:39:51AM -0800, Yinghai Lu wrote:
> [ Add more to To list ]
> 
> On Fri, Mar 8, 2013 at 10:24 AM, Yinghai Lu <yinghai@kernel.org> wrote:
> > On Fri, Mar 8, 2013 at 4:12 AM, WANG Chao <chaowang@redhat.com> wrote:
> >
> >>> what is 00:02.0 in your system?
> >> This IOMMU issue is related to https://lkml.org/lkml/2012/11/26/814. We can
> >> discuss this IOMMU issue in that thread.
> >> Anyway 00:02.0 is a video card, the box is Ivy Bridge.
> >> # lspci -s 00:02.0 -v
> >> 00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor
> >> Graphics Controller (rev 09) (prog-if 00 [VGA controller])
> >>         Subsystem: Intel Corporation Device 2211
> >>         Flags: bus master, fast devsel, latency 0, IRQ 44
> >>         Memory at afc00000 (64-bit, non-prefetchable) [size=4M]
> >>         Memory at c0000000 (64-bit, prefetchable) [size=256M]
> >>         I/O ports at 6000 [size=64]
> >>         Expansion ROM at <unassigned> [disabled]
> >>         Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
> >>         Capabilities: [d0] Power Management version 2
> >>         Capabilities: [a4] PCI Advanced Features
> >>         Kernel driver in use: i915
> >
> > disable drm for i915 will make your iommu work with dump?
> >
> >>
> >>
> >> Is it expected to intel_iommu=on or crashkernel_low to make 2nd kernel boot in
> >> 3.9? Back in 3.8, it works just fine w/ only crashkernel param.
> >
> > Yes, I really do not want to set crashkernel low range like 72M
> > automatically for all.
> > that would have the system with proper iommu support lose 72M under 4G
> > in first kernel.
> > And can not play allocate and return tricks, as first kernel have no
> > idea if iommu will work
> > on second kernel even iommu is working on first kernel.
> >
> > Better to fix iommu support at first.

It would seem that if we really want to go that route we should export
the number of megabytes that SWIOTLB is using. And it actually is - via the
swiotlb_nr_tbl() - thought it is no megabytes but slabs so you do have
to do some bit-shifting around.

If you want to use that, and perhaps alter the function to be swiotlb_size()
(and the xen-swiotlb to do the proper bit-shifting)?

> >
> > For old system that does not have DMAR or kernel does not have IOMMU
> > support enabled, or
> > user does not pass intel_iommu=on.
> > We could set crashkernel low range to 72M automatically.
> 
> It seem that it is not worthy to check case that does not support
> IOMMU in second kernel.
> 
> Please check attached patch that will just set crashkernel_low auto, and if the
> system DO support iommu with kdump, user can specify crashkernel_low=0
> to save low 72M.
> 
> Thanks
> 
> Yinghai



^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH] x86, kdump: Set crashkernel_low automatically
  2013-03-11  4:56                       ` [PATCH] x86, kdump: Set crashkernel_low automatically Yinghai Lu
@ 2013-03-11 14:48                         ` Vivek Goyal
  2013-03-11 15:02                           ` Vivek Goyal
  0 siblings, 1 reply; 101+ messages in thread
From: Vivek Goyal @ 2013-03-11 14:48 UTC (permalink / raw)
  To: Yinghai Lu
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, WANG Chao,
	Eric W. Biederman, linux-kernel

On Sun, Mar 10, 2013 at 09:56:57PM -0700, Yinghai Lu wrote:
> Current code does not set low range for crashkernel if the user
> does not specify that.
> 
> That cause regressions on system that does not support intel_iommu
> properly.
> 
> Chao said that his system does work well on 3.8 without extra parameter.
> even iommu does not work with kdump.
> 
> Set crashkernel_low automatically if the user does not specify that.
> 
> For system that does support IOMMU with kdump properly, user could
> specify crashkernel_low=0 to save that 72M low ram.
> 

Hi Yinghai,

Had a question about crashkernel_auto_low. So this is the amount of
memory rerved under 4G. I am not very clear about the semantics here.

So by default memory wil always come from areas above 4G (when
crashkernel=X specified) and if user needs reserveation in lower memory
area, it needs to be sepcified explicitly using crashkernel_low?

But will that not break the case of exising bzImage which are 32bit.
They currently work if I specify crashkernel=256M. Now suddenly memory
will come from higher addresses and 32bit bzImage can't be loaded there.
Or I understood the syntax part wrong.

P.S. Explanation in kernel-parameters.txt is really short. Can you please
     add some explanation in kdump.txt to clarify how crashkernel_low
    is supposed to be used.

Thanks
Vivek

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH] x86, kdump: Set crashkernel_low automatically
  2013-03-11 14:48                         ` Vivek Goyal
@ 2013-03-11 15:02                           ` Vivek Goyal
  2013-03-11 17:58                             ` Yinghai Lu
  0 siblings, 1 reply; 101+ messages in thread
From: Vivek Goyal @ 2013-03-11 15:02 UTC (permalink / raw)
  To: Yinghai Lu
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, WANG Chao,
	Eric W. Biederman, linux-kernel

On Mon, Mar 11, 2013 at 10:48:53AM -0400, Vivek Goyal wrote:
> On Sun, Mar 10, 2013 at 09:56:57PM -0700, Yinghai Lu wrote:
> > Current code does not set low range for crashkernel if the user
> > does not specify that.
> > 
> > That cause regressions on system that does not support intel_iommu
> > properly.
> > 
> > Chao said that his system does work well on 3.8 without extra parameter.
> > even iommu does not work with kdump.
> > 
> > Set crashkernel_low automatically if the user does not specify that.
> > 
> > For system that does support IOMMU with kdump properly, user could
> > specify crashkernel_low=0 to save that 72M low ram.
> > 
> 
> Hi Yinghai,
> 
> Had a question about crashkernel_auto_low. So this is the amount of
> memory rerved under 4G. I am not very clear about the semantics here.
> 
> So by default memory wil always come from areas above 4G (when
> crashkernel=X specified) and if user needs reserveation in lower memory
> area, it needs to be sepcified explicitly using crashkernel_low?
> 
> But will that not break the case of exising bzImage which are 32bit.
> They currently work if I specify crashkernel=256M. Now suddenly memory
> will come from higher addresses and 32bit bzImage can't be loaded there.
> Or I understood the syntax part wrong.
> 

IOW, wouldn't it be better that crashkernel=X first tries to find
requested amount of memory in lowest memory area available/possible.

Thanks
Vivek

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH] x86, kdump: Set crashkernel_low automatically
  2013-03-11 15:02                           ` Vivek Goyal
@ 2013-03-11 17:58                             ` Yinghai Lu
  2013-03-11 18:26                               ` Vivek Goyal
  0 siblings, 1 reply; 101+ messages in thread
From: Yinghai Lu @ 2013-03-11 17:58 UTC (permalink / raw)
  To: Vivek Goyal
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, WANG Chao,
	Eric W. Biederman, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 484 bytes --]

On Mon, Mar 11, 2013 at 8:02 AM, Vivek Goyal <vgoyal@redhat.com> wrote:
>
> IOW, wouldn't it be better that crashkernel=X first tries to find
> requested amount of memory in lowest memory area available/possible.

Yest, that is much better, and user even could stay with old kexec-tools
for system that does not tons of memory.
And I don't need to mess up with auto setting crashkernel_low or export
swiotlb_size() etc.

Please check if you are ok with attached one.

Thanks

Yinghai

[-- Attachment #2: fix_crashkernel_low_v2.patch --]
[-- Type: application/octet-stream, Size: 3094 bytes --]

Subject: [PATCH] x86, kdump, 64bit: Try allocate crashkernel under 896M at first

On 64bit system, we try allocate crashkernel above 4G at first,
and does not set low range for crashkernel if the user does not
specify that.

That cause regressions on system that does not support intel_iommu
properly.

Chao said that his system does work well on 3.8 without extra parameter.
even iommu does not work with kdump.

Change to try use old 896M limit at first and then try to allocate above 4G.

Also update kernel parameters to make it clear when that is needed.

Reported-by: WANG Chao <chaowang@redhat.com>
Suggested-by: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>

---
 Documentation/kernel-parameters.txt |   10 +++++++---
 arch/x86/kernel/setup.c             |   10 +++++++++-
 2 files changed, 16 insertions(+), 4 deletions(-)

Index: linux-2.6/Documentation/kernel-parameters.txt
===================================================================
--- linux-2.6.orig/Documentation/kernel-parameters.txt
+++ linux-2.6/Documentation/kernel-parameters.txt
@@ -596,9 +596,6 @@ bytes respectively. Such letter suffixes
 			is selected automatically. Check
 			Documentation/kdump/kdump.txt for further details.
 
-	crashkernel_low=size[KMG]
-			[KNL, x86] parts under 4G.
-
 	crashkernel=range1:size1[,range2:size2,...][@offset]
 			[KNL] Same as above, but depends on the memory
 			in the running system. The syntax of range is
@@ -606,6 +603,13 @@ bytes respectively. Such letter suffixes
 			a memory unit (amount[KMG]). See also
 			Documentation/kdump/kdump.txt for an example.
 
+	crashkernel_low=size[KMG]
+			[KNL, x86_64] range under 4G. When crashkernel= request
+			more than 512M, kernel allocate physical memory region
+			above 4G, that cause second kernel crash on system that
+			need swiotlb later. This one let user to specify extra
+			low range under 4G for second kernel.
+
 	cs89x0_dma=	[HW,NET]
 			Format: <dma>
 
Index: linux-2.6/arch/x86/kernel/setup.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/setup.c
+++ linux-2.6/arch/x86/kernel/setup.c
@@ -507,11 +507,12 @@ static void __init memblock_x86_reserve_
 /*
  * Keep the crash kernel below this limit.  On 32 bits earlier kernels
  * would limit the kernel to the low 512 MiB due to mapping restrictions.
+ * On 64 bits, kexec-tools (before 2.0.4) limits us to 896 MiB.
  */
 #ifdef CONFIG_X86_32
 # define CRASH_KERNEL_ADDR_MAX	(512 << 20)
 #else
-# define CRASH_KERNEL_ADDR_MAX	MAXMEM
+# define CRASH_KERNEL_ADDR_MAX	(896 << 20)
 #endif
 
 static void __init reserve_crashkernel_low(void)
@@ -571,6 +572,13 @@ static void __init reserve_crashkernel(v
 		crash_base = memblock_find_in_range(alignment,
 			       CRASH_KERNEL_ADDR_MAX, crash_size, alignment);
 
+#ifdef CONFIG_X86_64
+		if (!crash_base)
+			crash_base = memblock_find_in_range(alignment,
+				       MAX_MEM, crash_size, alignment);
+
+#endif
+
 		if (!crash_base) {
 			pr_info("crashkernel reservation failed - No suitable area found.\n");
 			return;

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH] x86, kdump: Set crashkernel_low automatically
  2013-03-11 17:58                             ` Yinghai Lu
@ 2013-03-11 18:26                               ` Vivek Goyal
  2013-03-11 18:44                                 ` Yinghai Lu
  2013-03-11 18:46                                 ` H. Peter Anvin
  0 siblings, 2 replies; 101+ messages in thread
From: Vivek Goyal @ 2013-03-11 18:26 UTC (permalink / raw)
  To: Yinghai Lu
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, WANG Chao,
	Eric W. Biederman, linux-kernel

On Mon, Mar 11, 2013 at 10:58:39AM -0700, Yinghai Lu wrote:
> On Mon, Mar 11, 2013 at 8:02 AM, Vivek Goyal <vgoyal@redhat.com> wrote:
> >
> > IOW, wouldn't it be better that crashkernel=X first tries to find
> > requested amount of memory in lowest memory area available/possible.
> 
> Yest, that is much better, and user even could stay with old kexec-tools
> for system that does not tons of memory.
> And I don't need to mess up with auto setting crashkernel_low or export
> swiotlb_size() etc.
> 
> Please check if you are ok with attached one.
> 
Hi Yinghai,

In mutt your patches are showing as attachment instead of inline. Mutt
thinks attachment is of type "application/octet-stream". Not sure if
this is configuration issue on my part or something is going on your
end.

I have few more concerns.

- Are we able to reserve 512MB memory now below 896MB. I remember so
  far it was broken.

- If reserving memory below 896MB fails, we immediately switch to
  reserving anywhere till MAXMEM. Would it make sense to first try
  to reserve it below 4G (so that we don't have to worry much about
  swiotlb or iommu being on).

Thanks
Vivek


^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH] x86, kdump: Set crashkernel_low automatically
  2013-03-11 18:26                               ` Vivek Goyal
@ 2013-03-11 18:44                                 ` Yinghai Lu
  2013-03-11 18:46                                 ` H. Peter Anvin
  1 sibling, 0 replies; 101+ messages in thread
From: Yinghai Lu @ 2013-03-11 18:44 UTC (permalink / raw)
  To: Vivek Goyal
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, WANG Chao,
	Eric W. Biederman, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 1464 bytes --]

On Mon, Mar 11, 2013 at 11:26 AM, Vivek Goyal <vgoyal@redhat.com> wrote:
> On Mon, Mar 11, 2013 at 10:58:39AM -0700, Yinghai Lu wrote:
>> On Mon, Mar 11, 2013 at 8:02 AM, Vivek Goyal <vgoyal@redhat.com> wrote:
>> >
>> > IOW, wouldn't it be better that crashkernel=X first tries to find
>> > requested amount of memory in lowest memory area available/possible.
>>
>> Yest, that is much better, and user even could stay with old kexec-tools
>> for system that does not tons of memory.
>> And I don't need to mess up with auto setting crashkernel_low or export
>> swiotlb_size() etc.
>>
>> Please check if you are ok with attached one.
>>
> Hi Yinghai,
>
> In mutt your patches are showing as attachment instead of inline. Mutt
> thinks attachment is of type "application/octet-stream". Not sure if
> this is configuration issue on my part or something is going on your
> end.

I sent it via gmail and it only can have attachment instead of inline.

>
> I have few more concerns.
>
> - Are we able to reserve 512MB memory now below 896MB. I remember so
>   far it was broken.

It also depends BIOS memmap layout. some bios put reserved on middle of ram
like just below 512M or just 2G.

>
> - If reserving memory below 896MB fails, we immediately switch to
>   reserving anywhere till MAXMEM. Would it make sense to first try
>   to reserve it below 4G (so that we don't have to worry much about
>   swiotlb or iommu being on).

ok.

Attached again.

Thanks

Yinghai

[-- Attachment #2: fix_crashkernel_low_v2.patch --]
[-- Type: application/octet-stream, Size: 3329 bytes --]

Subject: [PATCH] x86, kdump, 64bit: Try allocate crashkernel under 896M at first

On 64bit system, we try allocate crashkernel above 4G at first,
and does not set low range for crashkernel if the user does not
specify that.

That cause regressions on system that does not support intel_iommu
properly.

Chao said that his system does work well on 3.8 without extra parameter.
even iommu does not work with kdump.

Change to try use old 896M limit at first and then try to allocate above 4G.

Also update kernel parameters to make it clear when that is needed.

-v2: try 4G below and at last try MAXMEM according to Vivek.

Reported-by: WANG Chao <chaowang@redhat.com>
Suggested-by: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>

---
 Documentation/kernel-parameters.txt |   10 +++++++---
 arch/x86/kernel/setup.c             |   15 ++++++++++++++-
 2 files changed, 21 insertions(+), 4 deletions(-)

Index: linux-2.6/Documentation/kernel-parameters.txt
===================================================================
--- linux-2.6.orig/Documentation/kernel-parameters.txt
+++ linux-2.6/Documentation/kernel-parameters.txt
@@ -596,9 +596,6 @@ bytes respectively. Such letter suffixes
 			is selected automatically. Check
 			Documentation/kdump/kdump.txt for further details.
 
-	crashkernel_low=size[KMG]
-			[KNL, x86] parts under 4G.
-
 	crashkernel=range1:size1[,range2:size2,...][@offset]
 			[KNL] Same as above, but depends on the memory
 			in the running system. The syntax of range is
@@ -606,6 +603,13 @@ bytes respectively. Such letter suffixes
 			a memory unit (amount[KMG]). See also
 			Documentation/kdump/kdump.txt for an example.
 
+	crashkernel_low=size[KMG]
+			[KNL, x86_64] range under 4G. When crashkernel= request
+			more than 512M, kernel allocate physical memory region
+			above 4G, that cause second kernel crash on system that
+			need swiotlb later. This one let user to specify extra
+			low range under 4G for second kernel.
+
 	cs89x0_dma=	[HW,NET]
 			Format: <dma>
 
Index: linux-2.6/arch/x86/kernel/setup.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/setup.c
+++ linux-2.6/arch/x86/kernel/setup.c
@@ -507,11 +507,12 @@ static void __init memblock_x86_reserve_
 /*
  * Keep the crash kernel below this limit.  On 32 bits earlier kernels
  * would limit the kernel to the low 512 MiB due to mapping restrictions.
+ * On 64 bits, kexec-tools (before 2.0.4) limits us to 896 MiB.
  */
 #ifdef CONFIG_X86_32
 # define CRASH_KERNEL_ADDR_MAX	(512 << 20)
 #else
-# define CRASH_KERNEL_ADDR_MAX	MAXMEM
+# define CRASH_KERNEL_ADDR_MAX	(896 << 20)
 #endif
 
 static void __init reserve_crashkernel_low(void)
@@ -571,6 +572,18 @@ static void __init reserve_crashkernel(v
 		crash_base = memblock_find_in_range(alignment,
 			       CRASH_KERNEL_ADDR_MAX, crash_size, alignment);
 
+#ifdef CONFIG_X86_64
+		/* try under 4G at first */
+		if (!crash_base)
+			crash_base = memblock_find_in_range(alignment,
+				       1UL<<32, crash_size, alignment);
+		/* above 4G now */
+		if (!crash_base)
+			crash_base = memblock_find_in_range(alignment,
+				       MAXMEM, crash_size, alignment);
+
+#endif
+
 		if (!crash_base) {
 			pr_info("crashkernel reservation failed - No suitable area found.\n");
 			return;

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH] x86, kdump: Set crashkernel_low automatically
  2013-03-11 18:26                               ` Vivek Goyal
  2013-03-11 18:44                                 ` Yinghai Lu
@ 2013-03-11 18:46                                 ` H. Peter Anvin
  2013-03-11 18:50                                   ` Yinghai Lu
  2013-03-11 19:02                                   ` Vivek Goyal
  1 sibling, 2 replies; 101+ messages in thread
From: H. Peter Anvin @ 2013-03-11 18:46 UTC (permalink / raw)
  To: Vivek Goyal
  Cc: Yinghai Lu, Thomas Gleixner, Ingo Molnar, WANG Chao,
	Eric W. Biederman, linux-kernel

On 03/11/2013 11:26 AM, Vivek Goyal wrote:
>>
> Hi Yinghai,
> 
> In mutt your patches are showing as attachment instead of inline. Mutt
> thinks attachment is of type "application/octet-stream". Not sure if
> this is configuration issue on my part or something is going on your
> end.
> 
> I have few more concerns.
> 
> - Are we able to reserve 512MB memory now below 896MB. I remember so
>   far it was broken.
> 

What is the purpose of reserving that kind of memory below 896 MB?  If
you have a 32-bit system, it will likely be useless since you are
robbing the primary of most of lowmem, on a 64-bit system 896 MB is not
a magic value in any way...?

	-hpa


^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH] x86, kdump: Set crashkernel_low automatically
  2013-03-11 18:46                                 ` H. Peter Anvin
@ 2013-03-11 18:50                                   ` Yinghai Lu
  2013-03-11 18:55                                     ` H. Peter Anvin
  2013-03-11 19:02                                   ` Vivek Goyal
  1 sibling, 1 reply; 101+ messages in thread
From: Yinghai Lu @ 2013-03-11 18:50 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: Vivek Goyal, Thomas Gleixner, Ingo Molnar, WANG Chao,
	Eric W. Biederman, linux-kernel

On Mon, Mar 11, 2013 at 11:46 AM, H. Peter Anvin <hpa@zytor.com> wrote:
> On 03/11/2013 11:26 AM, Vivek Goyal wrote:
>>>
>> Hi Yinghai,
>>
>> In mutt your patches are showing as attachment instead of inline. Mutt
>> thinks attachment is of type "application/octet-stream". Not sure if
>> this is configuration issue on my part or something is going on your
>> end.
>>
>> I have few more concerns.
>>
>> - Are we able to reserve 512MB memory now below 896MB. I remember so
>>   far it was broken.
>>
>
> What is the purpose of reserving that kind of memory below 896 MB?  If
> you have a 32-bit system, it will likely be useless since you are
> robbing the primary of most of lowmem, on a 64-bit system 896 MB is not
> a magic value in any way...?

We did not touch 32 bit system.

Do you mean that we should
For 64bit, we should try under 4G, and then try MAXMEM
instead of try under 896M, then 4G, and MAXMEM?

Try 896M at first, we will let user to avoid updating their kexec-tools.

Thanks

Yinghai

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH] x86, kdump: Set crashkernel_low automatically
  2013-03-11 18:50                                   ` Yinghai Lu
@ 2013-03-11 18:55                                     ` H. Peter Anvin
  2013-03-11 19:06                                       ` Yinghai Lu
                                                         ` (2 more replies)
  0 siblings, 3 replies; 101+ messages in thread
From: H. Peter Anvin @ 2013-03-11 18:55 UTC (permalink / raw)
  To: Yinghai Lu
  Cc: Vivek Goyal, Thomas Gleixner, Ingo Molnar, WANG Chao,
	Eric W. Biederman, linux-kernel

On 03/11/2013 11:50 AM, Yinghai Lu wrote:
>>
>> What is the purpose of reserving that kind of memory below 896 MB?  If
>> you have a 32-bit system, it will likely be useless since you are
>> robbing the primary of most of lowmem, on a 64-bit system 896 MB is not
>> a magic value in any way...?
> 
> We did not touch 32 bit system.
> 
> Do you mean that we should
> For 64bit, we should try under 4G, and then try MAXMEM
> instead of try under 896M, then 4G, and MAXMEM?
> 
> Try 896M at first, we will let user to avoid updating their kexec-tools.
> 

Are you saying 896M is somehow hardcoded into kexec-tools?

I actually disagree with trying low memory at all.  Push kdump as high
into the memory range as we can go, if there is a performance penalty it
is much better to take it in the kdump kernel.

All the voodoo to try to keep people from updating kexec-tools is
disturbing; although breaking userspace is bad, updating kexec-tools is
probably easier than updating the kernel, and carrying the voodoo on
indefinitely has serious consequences.

	-hpa



^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH] x86, kdump: Set crashkernel_low automatically
  2013-03-11 18:46                                 ` H. Peter Anvin
  2013-03-11 18:50                                   ` Yinghai Lu
@ 2013-03-11 19:02                                   ` Vivek Goyal
  2013-03-11 19:04                                     ` H. Peter Anvin
  1 sibling, 1 reply; 101+ messages in thread
From: Vivek Goyal @ 2013-03-11 19:02 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: Yinghai Lu, Thomas Gleixner, Ingo Molnar, WANG Chao,
	Eric W. Biederman, linux-kernel

On Mon, Mar 11, 2013 at 11:46:45AM -0700, H. Peter Anvin wrote:
> On 03/11/2013 11:26 AM, Vivek Goyal wrote:
> >>
> > Hi Yinghai,
> > 
> > In mutt your patches are showing as attachment instead of inline. Mutt
> > thinks attachment is of type "application/octet-stream". Not sure if
> > this is configuration issue on my part or something is going on your
> > end.
> > 
> > I have few more concerns.
> > 
> > - Are we able to reserve 512MB memory now below 896MB. I remember so
> >   far it was broken.
> > 
> 
> What is the purpose of reserving that kind of memory below 896 MB?  If
> you have a 32-bit system, it will likely be useless since you are
> robbing the primary of most of lowmem, on a 64-bit system 896 MB is not
> a magic value in any way...?

Actually I am not sure where did 896MB magic value had come from for
x86_64 so far. I assumed that it was some kexec-tools limitation so
first trying 896MB will preserve working with old kexec-tools. If it
was some kernel limitation, then I agree it should not be required anymore.

I do remember that old pugatory had 2G limit. So may be we can first
try reserve with-in first 2G, then with-in first 4G and then above
4G. (Assuming 896M was not kexec-tools limitation and had something
to do with kernel/initramfs).

Thanks
Vivek

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH] x86, kdump: Set crashkernel_low automatically
  2013-03-11 19:02                                   ` Vivek Goyal
@ 2013-03-11 19:04                                     ` H. Peter Anvin
  2013-03-11 19:17                                       ` Vivek Goyal
  0 siblings, 1 reply; 101+ messages in thread
From: H. Peter Anvin @ 2013-03-11 19:04 UTC (permalink / raw)
  To: Vivek Goyal
  Cc: Yinghai Lu, Thomas Gleixner, Ingo Molnar, WANG Chao,
	Eric W. Biederman, linux-kernel

On 03/11/2013 12:02 PM, Vivek Goyal wrote:
>>
>> What is the purpose of reserving that kind of memory below 896 MB?  If
>> you have a 32-bit system, it will likely be useless since you are
>> robbing the primary of most of lowmem, on a 64-bit system 896 MB is not
>> a magic value in any way...?
> 
> Actually I am not sure where did 896MB magic value had come from for
> x86_64 so far. I assumed that it was some kexec-tools limitation so
> first trying 896MB will preserve working with old kexec-tools. If it
> was some kernel limitation, then I agree it should not be required anymore.
> 
> I do remember that old pugatory had 2G limit. So may be we can first
> try reserve with-in first 2G, then with-in first 4G and then above
> 4G. (Assuming 896M was not kexec-tools limitation and had something
> to do with kernel/initramfs).
> 

It is obvious where it *originated* from... it is the *default* (but not
necessarily the actual!) HIGHMEM crossover point on x86-32.

Whether this limitation has crept into somewhere else is a good question.

	-hpa



^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH] x86, kdump: Set crashkernel_low automatically
  2013-03-11 18:55                                     ` H. Peter Anvin
@ 2013-03-11 19:06                                       ` Yinghai Lu
  2013-03-11 19:06                                         ` H. Peter Anvin
  2013-03-11 19:20                                         ` Vivek Goyal
  2013-03-11 19:10                                       ` Vivek Goyal
  2013-03-11 19:14                                       ` [PATCH] x86, kdump: Set crashkernel_low automatically Eric W. Biederman
  2 siblings, 2 replies; 101+ messages in thread
From: Yinghai Lu @ 2013-03-11 19:06 UTC (permalink / raw)
  To: H. Peter Anvin, Konrad Rzeszutek Wilk
  Cc: Vivek Goyal, Thomas Gleixner, Ingo Molnar, WANG Chao,
	Eric W. Biederman, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 1508 bytes --]

On Mon, Mar 11, 2013 at 11:55 AM, H. Peter Anvin <hpa@zytor.com> wrote:
> On 03/11/2013 11:50 AM, Yinghai Lu wrote:
>>>
>>> What is the purpose of reserving that kind of memory below 896 MB?  If
>>> you have a 32-bit system, it will likely be useless since you are
>>> robbing the primary of most of lowmem, on a 64-bit system 896 MB is not
>>> a magic value in any way...?
>>
>> We did not touch 32 bit system.
>>
>> Do you mean that we should
>> For 64bit, we should try under 4G, and then try MAXMEM
>> instead of try under 896M, then 4G, and MAXMEM?
>>
>> Try 896M at first, we will let user to avoid updating their kexec-tools.
>>
>
> Are you saying 896M is somehow hardcoded into kexec-tools?

yes, before kexec-tools 2.0.4

>
> I actually disagree with trying low memory at all.  Push kdump as high
> into the memory range as we can go, if there is a performance penalty it
> is much better to take it in the kdump kernel.

Agreed, It's better let 64 bit all use one code path.
And we can find more bugs while load them all high.
otherwise it would be hard to fix them if the bugs only happens on systems
that have bunch of dimms.

>
> All the voodoo to try to keep people from updating kexec-tools is
> disturbing; although breaking userspace is bad, updating kexec-tools is
> probably easier than updating the kernel, and carrying the voodoo on
> indefinitely has serious consequences.

Yes.

So please check you are happy with this one. -v3 that set crashkernel_low
automatically.

Thanks

Yinghai

[-- Attachment #2: fix_crashkernel_low_v3.patch --]
[-- Type: application/octet-stream, Size: 3737 bytes --]

Subject: [PATCH] x86, kdump: Set crashkernel_low automatically

Current code does not set low range for crashkernel if the user
does not specify that.

That cause regressions on system that does not support intel_iommu
properly.

Chao said that his system does work well on 3.8 without extra parameter.
even iommu does not work with kdump.

Set crashkernel_low automatically if the user does not specify that.

For system that does support IOMMU with kdump properly, user could
specify crashkernel_low=0 to save that 72M low ram.

-v3: add swiotlb_size() according to Konrad.

Reported-by: WANG Chao <chaowang@redhat.com>
Tested-by: WANG Chao <chaowang@redhat.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>

---
 arch/x86/kernel/setup.c |   15 ++++++++++++---
 include/linux/swiotlb.h |    1 +
 lib/swiotlb.c           |   19 +++++++++++++++----
 3 files changed, 28 insertions(+), 7 deletions(-)

Index: linux-2.6/arch/x86/kernel/setup.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/setup.c
+++ linux-2.6/arch/x86/kernel/setup.c
@@ -522,19 +522,28 @@ static void __init reserve_crashkernel_l
 	unsigned long long low_base = 0, low_size = 0;
 	unsigned long total_low_mem;
 	unsigned long long base;
+	bool auto_set = false;
 	int ret;
 
 	total_low_mem = memblock_mem_size(1UL<<(32-PAGE_SHIFT));
 	ret = parse_crashkernel_low(boot_command_line, total_low_mem,
 						&low_size, &base);
-	if (ret != 0 || low_size <= 0)
-		return;
+	if (ret != 0) {
+		/* swiotlb size and etc 8M */
+		low_size = swiotlb_size_or_default() + (8UL<<20);
+		auto_set = true;
+	} else {
+		/* passed with crashkernel_low=0 ? */
+		if (!low_size)
+			return;
+	}
 
 	low_base = memblock_find_in_range(low_size, (1ULL<<32),
 					low_size, alignment);
 
 	if (!low_base) {
-		pr_info("crashkernel low reservation failed - No suitable area found.\n");
+		if (!auto_set)
+			pr_info("crashkernel low reservation failed - No suitable area found.\n");
 
 		return;
 	}
Index: linux-2.6/include/linux/swiotlb.h
===================================================================
--- linux-2.6.orig/include/linux/swiotlb.h
+++ linux-2.6/include/linux/swiotlb.h
@@ -25,6 +25,7 @@ extern int swiotlb_force;
 extern void swiotlb_init(int verbose);
 int swiotlb_init_with_tbl(char *tlb, unsigned long nslabs, int verbose);
 extern unsigned long swiotlb_nr_tbl(void);
+unsigned long swiotlb_size_or_default(void);
 extern int swiotlb_late_init_with_tbl(char *tlb, unsigned long nslabs);
 
 /*
Index: linux-2.6/lib/swiotlb.c
===================================================================
--- linux-2.6.orig/lib/swiotlb.c
+++ linux-2.6/lib/swiotlb.c
@@ -105,9 +105,9 @@ setup_io_tlb_npages(char *str)
 	if (!strcmp(str, "force"))
 		swiotlb_force = 1;
 
-	return 1;
+	return 0;
 }
-__setup("swiotlb=", setup_io_tlb_npages);
+early_param("swiotlb", setup_io_tlb_npages);
 /* make io_tlb_overflow tunable too? */
 
 unsigned long swiotlb_nr_tbl(void)
@@ -115,6 +115,18 @@ unsigned long swiotlb_nr_tbl(void)
 	return io_tlb_nslabs;
 }
 EXPORT_SYMBOL_GPL(swiotlb_nr_tbl);
+
+/* default to 64MB */
+#define IO_TLB_DEFAULT_SIZE (64UL<<20)
+unsigned long swiotlb_size_or_default(void)
+{
+	unsigned long size;
+
+	size = io_tlb_nslabs << IO_TLB_SHIFT;
+
+	return size ? size : (IO_TLB_DEFAULT_SIZE);
+}
+
 /* Note that this doesn't work with highmem page */
 static dma_addr_t swiotlb_virt_to_bus(struct device *hwdev,
 				      volatile void *address)
@@ -188,8 +200,7 @@ int __init swiotlb_init_with_tbl(char *t
 void  __init
 swiotlb_init(int verbose)
 {
-	/* default to 64MB */
-	size_t default_size = 64UL<<20;
+	size_t default_size = IO_TLB_DEFAULT_SIZE;
 	unsigned char *vstart;
 	unsigned long bytes;
 

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH] x86, kdump: Set crashkernel_low automatically
  2013-03-11 19:06                                       ` Yinghai Lu
@ 2013-03-11 19:06                                         ` H. Peter Anvin
  2013-03-11 19:08                                           ` Yinghai Lu
  2013-03-11 19:20                                         ` Vivek Goyal
  1 sibling, 1 reply; 101+ messages in thread
From: H. Peter Anvin @ 2013-03-11 19:06 UTC (permalink / raw)
  To: Yinghai Lu
  Cc: Konrad Rzeszutek Wilk, Vivek Goyal, Thomas Gleixner, Ingo Molnar,
	WANG Chao, Eric W. Biederman, linux-kernel

On 03/11/2013 12:06 PM, Yinghai Lu wrote:
>>
>> Are you saying 896M is somehow hardcoded into kexec-tools?
> 
> yes, before kexec-tools 2.0.4
> 

How old is that?

	-hpa



^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH] x86, kdump: Set crashkernel_low automatically
  2013-03-11 19:06                                         ` H. Peter Anvin
@ 2013-03-11 19:08                                           ` Yinghai Lu
  0 siblings, 0 replies; 101+ messages in thread
From: Yinghai Lu @ 2013-03-11 19:08 UTC (permalink / raw)
  To: H. Peter Anvin, Simon Horman
  Cc: Konrad Rzeszutek Wilk, Vivek Goyal, Thomas Gleixner, Ingo Molnar,
	WANG Chao, Eric W. Biederman, linux-kernel

On Mon, Mar 11, 2013 at 12:06 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> On 03/11/2013 12:06 PM, Yinghai Lu wrote:
>>>
>>> Are you saying 896M is somehow hardcoded into kexec-tools?
>>
>> yes, before kexec-tools 2.0.4
>>
>
> How old is that?

2.0.4 is not released yet. and 2.0.4 would support load v3.9 that
support kernel is loaded high.

Thanks

Yinghai

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH] x86, kdump: Set crashkernel_low automatically
  2013-03-11 18:55                                     ` H. Peter Anvin
  2013-03-11 19:06                                       ` Yinghai Lu
@ 2013-03-11 19:10                                       ` Vivek Goyal
  2013-03-11 19:34                                         ` Yinghai Lu
  2013-03-11 19:14                                       ` [PATCH] x86, kdump: Set crashkernel_low automatically Eric W. Biederman
  2 siblings, 1 reply; 101+ messages in thread
From: Vivek Goyal @ 2013-03-11 19:10 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: Yinghai Lu, Thomas Gleixner, Ingo Molnar, WANG Chao,
	Eric W. Biederman, linux-kernel

On Mon, Mar 11, 2013 at 11:55:52AM -0700, H. Peter Anvin wrote:
> On 03/11/2013 11:50 AM, Yinghai Lu wrote:
> >>
> >> What is the purpose of reserving that kind of memory below 896 MB?  If
> >> you have a 32-bit system, it will likely be useless since you are
> >> robbing the primary of most of lowmem, on a 64-bit system 896 MB is not
> >> a magic value in any way...?
> > 
> > We did not touch 32 bit system.
> > 
> > Do you mean that we should
> > For 64bit, we should try under 4G, and then try MAXMEM
> > instead of try under 896M, then 4G, and MAXMEM?
> > 
> > Try 896M at first, we will let user to avoid updating their kexec-tools.
> > 
> 
> Are you saying 896M is somehow hardcoded into kexec-tools?
> 
> I actually disagree with trying low memory at all.  Push kdump as high
> into the memory range as we can go, if there is a performance penalty it
> is much better to take it in the kdump kernel.

Reserving above 2G by default will break old kexec-tools. Purgatory can't
be loaded above 2G.

Loading above 4G will require swiotlb buffers to be reserved in low
memory area. It will break all the existing setups where iommu is
not enabled.

Not breaking existing cases makes sense to me. May be we should use
a new parameter crashkernel_high to force memory reservation above
4G and crashkernel=X continues to reserve memory at lower addresses
and remains backward compatible.

Thanks
Vivek

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH] x86, kdump: Set crashkernel_low automatically
  2013-03-11 18:55                                     ` H. Peter Anvin
  2013-03-11 19:06                                       ` Yinghai Lu
  2013-03-11 19:10                                       ` Vivek Goyal
@ 2013-03-11 19:14                                       ` Eric W. Biederman
  2013-03-11 19:22                                         ` Vivek Goyal
  2013-03-11 19:56                                         ` H. Peter Anvin
  2 siblings, 2 replies; 101+ messages in thread
From: Eric W. Biederman @ 2013-03-11 19:14 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: Yinghai Lu, Vivek Goyal, Thomas Gleixner, Ingo Molnar, WANG Chao,
	linux-kernel

"H. Peter Anvin" <hpa@zytor.com> writes:

> On 03/11/2013 11:50 AM, Yinghai Lu wrote:
>>>
>>> What is the purpose of reserving that kind of memory below 896 MB?  If
>>> you have a 32-bit system, it will likely be useless since you are
>>> robbing the primary of most of lowmem, on a 64-bit system 896 MB is not
>>> a magic value in any way...?
>> 
>> We did not touch 32 bit system.
>> 
>> Do you mean that we should
>> For 64bit, we should try under 4G, and then try MAXMEM
>> instead of try under 896M, then 4G, and MAXMEM?
>> 
>> Try 896M at first, we will let user to avoid updating their kexec-tools.
>> 
>
> Are you saying 896M is somehow hardcoded into kexec-tools?
>
> I actually disagree with trying low memory at all.  Push kdump as high
> into the memory range as we can go, if there is a performance penalty it
> is much better to take it in the kdump kernel.
>
> All the voodoo to try to keep people from updating kexec-tools is
> disturbing; although breaking userspace is bad, updating kexec-tools is
> probably easier than updating the kernel, and carrying the voodoo on
> indefinitely has serious consequences.

I don't totally follow the reasoning, but there is one real motivating
example that is not easy to fix and it has little to do with
kexec-tools.  There is a practical issue that so far the easiest way
to deal with iommus after a kexec on panic is to just not use them.
The problem is what to do with existing DMAs transfers that were setup
by the kernel that crashed and are using the iommu.

When you are loaded above 4G not using iommus can be a challenge.

There are practical consequences to all of this that started this
discussion, and the practical consequences are primarily in kernel
behavior.


Eric

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH] x86, kdump: Set crashkernel_low automatically
  2013-03-11 19:04                                     ` H. Peter Anvin
@ 2013-03-11 19:17                                       ` Vivek Goyal
  0 siblings, 0 replies; 101+ messages in thread
From: Vivek Goyal @ 2013-03-11 19:17 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: Yinghai Lu, Thomas Gleixner, Ingo Molnar, WANG Chao,
	Eric W. Biederman, linux-kernel

On Mon, Mar 11, 2013 at 12:04:38PM -0700, H. Peter Anvin wrote:
> On 03/11/2013 12:02 PM, Vivek Goyal wrote:
> >>
> >> What is the purpose of reserving that kind of memory below 896 MB?  If
> >> you have a 32-bit system, it will likely be useless since you are
> >> robbing the primary of most of lowmem, on a 64-bit system 896 MB is not
> >> a magic value in any way...?
> > 
> > Actually I am not sure where did 896MB magic value had come from for
> > x86_64 so far. I assumed that it was some kexec-tools limitation so
> > first trying 896MB will preserve working with old kexec-tools. If it
> > was some kernel limitation, then I agree it should not be required anymore.
> > 
> > I do remember that old pugatory had 2G limit. So may be we can first
> > try reserve with-in first 2G, then with-in first 4G and then above
> > 4G. (Assuming 896M was not kexec-tools limitation and had something
> > to do with kernel/initramfs).
> > 
> 
> It is obvious where it *originated* from... it is the *default* (but not
> necessarily the actual!) HIGHMEM crossover point on x86-32.
> 

On x86-32, max addr limit is 512M. 896M limit is on x86_64. So it probably
came from somewhere else. 

Also always reserving at high memory cuts down on what kind of bzImage
can be booted from that address. For example, x86_32bit kernels. Hence
reserving at low addresses enables booting more type of images without
rebooting.

Thanks
Vivek

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH] x86, kdump: Set crashkernel_low automatically
  2013-03-11 19:06                                       ` Yinghai Lu
  2013-03-11 19:06                                         ` H. Peter Anvin
@ 2013-03-11 19:20                                         ` Vivek Goyal
  2013-03-11 19:55                                           ` H. Peter Anvin
  1 sibling, 1 reply; 101+ messages in thread
From: Vivek Goyal @ 2013-03-11 19:20 UTC (permalink / raw)
  To: Yinghai Lu
  Cc: H. Peter Anvin, Konrad Rzeszutek Wilk, Thomas Gleixner,
	Ingo Molnar, WANG Chao, Eric W. Biederman, linux-kernel

On Mon, Mar 11, 2013 at 12:06:06PM -0700, Yinghai Lu wrote:

[..]
> > I actually disagree with trying low memory at all.  Push kdump as high
> > into the memory range as we can go, if there is a performance penalty it
> > is much better to take it in the kdump kernel.
> 
> Agreed, It's better let 64 bit all use one code path.
> And we can find more bugs while load them all high.
> otherwise it would be hard to fix them if the bugs only happens on systems
> that have bunch of dimms.

I find it odd that if a user wants to load a 32bit kernel or use 32bit
entry point then he needs to first reboot the kernel and re-reserve
the memory.

At installation time, one does not necessarily know what kind of kernel
will be used for crashdump. So reserving as high as possible limits
the choices.

I would rather prefer that user opt in for higher addresses instead of
these being reserved by default.

Thanks
Vivek

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH] x86, kdump: Set crashkernel_low automatically
  2013-03-11 19:14                                       ` [PATCH] x86, kdump: Set crashkernel_low automatically Eric W. Biederman
@ 2013-03-11 19:22                                         ` Vivek Goyal
  2013-03-11 19:59                                           ` H. Peter Anvin
  2013-03-11 19:56                                         ` H. Peter Anvin
  1 sibling, 1 reply; 101+ messages in thread
From: Vivek Goyal @ 2013-03-11 19:22 UTC (permalink / raw)
  To: Eric W. Biederman
  Cc: H. Peter Anvin, Yinghai Lu, Thomas Gleixner, Ingo Molnar,
	WANG Chao, linux-kernel

On Mon, Mar 11, 2013 at 12:14:16PM -0700, Eric W. Biederman wrote:
> "H. Peter Anvin" <hpa@zytor.com> writes:
> 
> > On 03/11/2013 11:50 AM, Yinghai Lu wrote:
> >>>
> >>> What is the purpose of reserving that kind of memory below 896 MB?  If
> >>> you have a 32-bit system, it will likely be useless since you are
> >>> robbing the primary of most of lowmem, on a 64-bit system 896 MB is not
> >>> a magic value in any way...?
> >> 
> >> We did not touch 32 bit system.
> >> 
> >> Do you mean that we should
> >> For 64bit, we should try under 4G, and then try MAXMEM
> >> instead of try under 896M, then 4G, and MAXMEM?
> >> 
> >> Try 896M at first, we will let user to avoid updating their kexec-tools.
> >> 
> >
> > Are you saying 896M is somehow hardcoded into kexec-tools?
> >
> > I actually disagree with trying low memory at all.  Push kdump as high
> > into the memory range as we can go, if there is a performance penalty it
> > is much better to take it in the kdump kernel.
> >
> > All the voodoo to try to keep people from updating kexec-tools is
> > disturbing; although breaking userspace is bad, updating kexec-tools is
> > probably easier than updating the kernel, and carrying the voodoo on
> > indefinitely has serious consequences.
> 
> I don't totally follow the reasoning, but there is one real motivating
> example that is not easy to fix and it has little to do with
> kexec-tools.  There is a practical issue that so far the easiest way
> to deal with iommus after a kexec on panic is to just not use them.
> The problem is what to do with existing DMAs transfers that were setup
> by the kernel that crashed and are using the iommu.
> 
> When you are loaded above 4G not using iommus can be a challenge.
> 
> There are practical consequences to all of this that started this
> discussion, and the practical consequences are primarily in kernel
> behavior.

iommu is a real concern. We have quite a few issues that with iommu
on kdump did not work. So practically we keep iommu off both in first
kernel and second kernel.

So always reserving memory at highest address will break all the cases
which work without iommu and rely on swiotlb. I think first we need
to make sure that kdump works reliably with iommu on, and then try
to move to always reserving memory at higest possible address.

Thanks
Vivek

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH] x86, kdump: Set crashkernel_low automatically
  2013-03-11 19:10                                       ` Vivek Goyal
@ 2013-03-11 19:34                                         ` Yinghai Lu
  2013-03-11 19:38                                           ` Vivek Goyal
  0 siblings, 1 reply; 101+ messages in thread
From: Yinghai Lu @ 2013-03-11 19:34 UTC (permalink / raw)
  To: Vivek Goyal
  Cc: H. Peter Anvin, Thomas Gleixner, Ingo Molnar, WANG Chao,
	Eric W. Biederman, linux-kernel

On Mon, Mar 11, 2013 at 12:10 PM, Vivek Goyal <vgoyal@redhat.com> wrote:
> Not breaking existing cases makes sense to me.

that is -v2 version:
try 896M, then try 4G, than MAXMEM.

> May be we should use
> a new parameter crashkernel_high to force memory reservation above
> 4G and crashkernel=X continues to reserve memory at lower addresses
> and remains backward compatible.

No need to use crashkernel_high, we can just cashkernel=X@Y instead.

Thanks

Yinghai

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH] x86, kdump: Set crashkernel_low automatically
  2013-03-11 19:34                                         ` Yinghai Lu
@ 2013-03-11 19:38                                           ` Vivek Goyal
  2013-03-11 19:39                                             ` Yinghai Lu
  0 siblings, 1 reply; 101+ messages in thread
From: Vivek Goyal @ 2013-03-11 19:38 UTC (permalink / raw)
  To: Yinghai Lu
  Cc: H. Peter Anvin, Thomas Gleixner, Ingo Molnar, WANG Chao,
	Eric W. Biederman, linux-kernel

On Mon, Mar 11, 2013 at 12:34:00PM -0700, Yinghai Lu wrote:
> On Mon, Mar 11, 2013 at 12:10 PM, Vivek Goyal <vgoyal@redhat.com> wrote:
> > Not breaking existing cases makes sense to me.
> 
> that is -v2 version:
> try 896M, then try 4G, than MAXMEM.
> 
> > May be we should use
> > a new parameter crashkernel_high to force memory reservation above
> > 4G and crashkernel=X continues to reserve memory at lower addresses
> > and remains backward compatible.
> 
> No need to use crashkernel_high, we can just cashkernel=X@Y instead.

crashkernel=X@Y is little different. It assumes user knows the memory
map and location "Y" is fixed. There might not be any memory at "Y".

So it is not same.

Thanks
Vivek

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH] x86, kdump: Set crashkernel_low automatically
  2013-03-11 19:38                                           ` Vivek Goyal
@ 2013-03-11 19:39                                             ` Yinghai Lu
  2013-03-11 19:44                                               ` Vivek Goyal
  2013-03-11 19:44                                               ` Yinghai Lu
  0 siblings, 2 replies; 101+ messages in thread
From: Yinghai Lu @ 2013-03-11 19:39 UTC (permalink / raw)
  To: Vivek Goyal
  Cc: H. Peter Anvin, Thomas Gleixner, Ingo Molnar, WANG Chao,
	Eric W. Biederman, linux-kernel

On Mon, Mar 11, 2013 at 12:38 PM, Vivek Goyal <vgoyal@redhat.com> wrote:
>> No need to use crashkernel_high, we can just cashkernel=X@Y instead.
>
> crashkernel=X@Y is little different. It assumes user knows the memory
> map and location "Y" is fixed. There might not be any memory at "Y".

then use crashkernel=4G?

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH] x86, kdump: Set crashkernel_low automatically
  2013-03-11 19:39                                             ` Yinghai Lu
@ 2013-03-11 19:44                                               ` Vivek Goyal
  2013-03-11 19:44                                               ` Yinghai Lu
  1 sibling, 0 replies; 101+ messages in thread
From: Vivek Goyal @ 2013-03-11 19:44 UTC (permalink / raw)
  To: Yinghai Lu
  Cc: H. Peter Anvin, Thomas Gleixner, Ingo Molnar, WANG Chao,
	Eric W. Biederman, linux-kernel

On Mon, Mar 11, 2013 at 12:39:56PM -0700, Yinghai Lu wrote:
> On Mon, Mar 11, 2013 at 12:38 PM, Vivek Goyal <vgoyal@redhat.com> wrote:
> >> No need to use crashkernel_high, we can just cashkernel=X@Y instead.
> >
> > crashkernel=X@Y is little different. It assumes user knows the memory
> > map and location "Y" is fixed. There might not be any memory at "Y".
> 
> then use crashkernel=4G?

But that will reserve 4G of memory. I just want 128/256 MB of memory
reserved for normal cases. This is even worse than crashkernel=X@Y.

Thanks
Vivek


^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH] x86, kdump: Set crashkernel_low automatically
  2013-03-11 19:39                                             ` Yinghai Lu
  2013-03-11 19:44                                               ` Vivek Goyal
@ 2013-03-11 19:44                                               ` Yinghai Lu
  2013-03-18 14:46                                                 ` Vivek Goyal
  1 sibling, 1 reply; 101+ messages in thread
From: Yinghai Lu @ 2013-03-11 19:44 UTC (permalink / raw)
  To: Vivek Goyal, Eric W. Biederman, H. Peter Anvin, Konrad Rzeszutek Wilk
  Cc: Thomas Gleixner, Ingo Molnar, WANG Chao, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 624 bytes --]

On Mon, Mar 11, 2013 at 12:39 PM, Yinghai Lu <yinghai@kernel.org> wrote:
> On Mon, Mar 11, 2013 at 12:38 PM, Vivek Goyal <vgoyal@redhat.com> wrote:
>>> No need to use crashkernel_high, we can just cashkernel=X@Y instead.
>>
>> crashkernel=X@Y is little different. It assumes user knows the memory
>> map and location "Y" is fixed. There might not be any memory at "Y".
>
> then use crashkernel=4G?

I re attached -v2 and -v3.

I'm ok that any one is applied or two get applied all together.

only affect 64bit
-v2: try under under 896M, then 4G, then MAXMEM
-v3: auto set crashkernel_low with swiotlb size.

Thanks

Yinghai

[-- Attachment #2: fix_crashkernel_low_v2.patch --]
[-- Type: application/octet-stream, Size: 3329 bytes --]

Subject: [PATCH] x86, kdump, 64bit: Try allocate crashkernel under 896M at first

On 64bit system, we try allocate crashkernel above 4G at first,
and does not set low range for crashkernel if the user does not
specify that.

That cause regressions on system that does not support intel_iommu
properly.

Chao said that his system does work well on 3.8 without extra parameter.
even iommu does not work with kdump.

Change to try use old 896M limit at first and then try to allocate above 4G.

Also update kernel parameters to make it clear when that is needed.

-v2: try 4G below and at last try MAXMEM according to Vivek.

Reported-by: WANG Chao <chaowang@redhat.com>
Suggested-by: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>

---
 Documentation/kernel-parameters.txt |   10 +++++++---
 arch/x86/kernel/setup.c             |   15 ++++++++++++++-
 2 files changed, 21 insertions(+), 4 deletions(-)

Index: linux-2.6/Documentation/kernel-parameters.txt
===================================================================
--- linux-2.6.orig/Documentation/kernel-parameters.txt
+++ linux-2.6/Documentation/kernel-parameters.txt
@@ -596,9 +596,6 @@ bytes respectively. Such letter suffixes
 			is selected automatically. Check
 			Documentation/kdump/kdump.txt for further details.
 
-	crashkernel_low=size[KMG]
-			[KNL, x86] parts under 4G.
-
 	crashkernel=range1:size1[,range2:size2,...][@offset]
 			[KNL] Same as above, but depends on the memory
 			in the running system. The syntax of range is
@@ -606,6 +603,13 @@ bytes respectively. Such letter suffixes
 			a memory unit (amount[KMG]). See also
 			Documentation/kdump/kdump.txt for an example.
 
+	crashkernel_low=size[KMG]
+			[KNL, x86_64] range under 4G. When crashkernel= request
+			more than 512M, kernel allocate physical memory region
+			above 4G, that cause second kernel crash on system that
+			need swiotlb later. This one let user to specify extra
+			low range under 4G for second kernel.
+
 	cs89x0_dma=	[HW,NET]
 			Format: <dma>
 
Index: linux-2.6/arch/x86/kernel/setup.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/setup.c
+++ linux-2.6/arch/x86/kernel/setup.c
@@ -507,11 +507,12 @@ static void __init memblock_x86_reserve_
 /*
  * Keep the crash kernel below this limit.  On 32 bits earlier kernels
  * would limit the kernel to the low 512 MiB due to mapping restrictions.
+ * On 64 bits, kexec-tools (before 2.0.4) limits us to 896 MiB.
  */
 #ifdef CONFIG_X86_32
 # define CRASH_KERNEL_ADDR_MAX	(512 << 20)
 #else
-# define CRASH_KERNEL_ADDR_MAX	MAXMEM
+# define CRASH_KERNEL_ADDR_MAX	(896 << 20)
 #endif
 
 static void __init reserve_crashkernel_low(void)
@@ -571,6 +572,18 @@ static void __init reserve_crashkernel(v
 		crash_base = memblock_find_in_range(alignment,
 			       CRASH_KERNEL_ADDR_MAX, crash_size, alignment);
 
+#ifdef CONFIG_X86_64
+		/* try under 4G at first */
+		if (!crash_base)
+			crash_base = memblock_find_in_range(alignment,
+				       1UL<<32, crash_size, alignment);
+		/* above 4G now */
+		if (!crash_base)
+			crash_base = memblock_find_in_range(alignment,
+				       MAXMEM, crash_size, alignment);
+
+#endif
+
 		if (!crash_base) {
 			pr_info("crashkernel reservation failed - No suitable area found.\n");
 			return;

[-- Attachment #3: fix_crashkernel_low_v3.patch --]
[-- Type: application/octet-stream, Size: 3737 bytes --]

Subject: [PATCH] x86, kdump: Set crashkernel_low automatically

Current code does not set low range for crashkernel if the user
does not specify that.

That cause regressions on system that does not support intel_iommu
properly.

Chao said that his system does work well on 3.8 without extra parameter.
even iommu does not work with kdump.

Set crashkernel_low automatically if the user does not specify that.

For system that does support IOMMU with kdump properly, user could
specify crashkernel_low=0 to save that 72M low ram.

-v3: add swiotlb_size() according to Konrad.

Reported-by: WANG Chao <chaowang@redhat.com>
Tested-by: WANG Chao <chaowang@redhat.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>

---
 arch/x86/kernel/setup.c |   15 ++++++++++++---
 include/linux/swiotlb.h |    1 +
 lib/swiotlb.c           |   19 +++++++++++++++----
 3 files changed, 28 insertions(+), 7 deletions(-)

Index: linux-2.6/arch/x86/kernel/setup.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/setup.c
+++ linux-2.6/arch/x86/kernel/setup.c
@@ -522,19 +522,28 @@ static void __init reserve_crashkernel_l
 	unsigned long long low_base = 0, low_size = 0;
 	unsigned long total_low_mem;
 	unsigned long long base;
+	bool auto_set = false;
 	int ret;
 
 	total_low_mem = memblock_mem_size(1UL<<(32-PAGE_SHIFT));
 	ret = parse_crashkernel_low(boot_command_line, total_low_mem,
 						&low_size, &base);
-	if (ret != 0 || low_size <= 0)
-		return;
+	if (ret != 0) {
+		/* swiotlb size and etc 8M */
+		low_size = swiotlb_size_or_default() + (8UL<<20);
+		auto_set = true;
+	} else {
+		/* passed with crashkernel_low=0 ? */
+		if (!low_size)
+			return;
+	}
 
 	low_base = memblock_find_in_range(low_size, (1ULL<<32),
 					low_size, alignment);
 
 	if (!low_base) {
-		pr_info("crashkernel low reservation failed - No suitable area found.\n");
+		if (!auto_set)
+			pr_info("crashkernel low reservation failed - No suitable area found.\n");
 
 		return;
 	}
Index: linux-2.6/include/linux/swiotlb.h
===================================================================
--- linux-2.6.orig/include/linux/swiotlb.h
+++ linux-2.6/include/linux/swiotlb.h
@@ -25,6 +25,7 @@ extern int swiotlb_force;
 extern void swiotlb_init(int verbose);
 int swiotlb_init_with_tbl(char *tlb, unsigned long nslabs, int verbose);
 extern unsigned long swiotlb_nr_tbl(void);
+unsigned long swiotlb_size_or_default(void);
 extern int swiotlb_late_init_with_tbl(char *tlb, unsigned long nslabs);
 
 /*
Index: linux-2.6/lib/swiotlb.c
===================================================================
--- linux-2.6.orig/lib/swiotlb.c
+++ linux-2.6/lib/swiotlb.c
@@ -105,9 +105,9 @@ setup_io_tlb_npages(char *str)
 	if (!strcmp(str, "force"))
 		swiotlb_force = 1;
 
-	return 1;
+	return 0;
 }
-__setup("swiotlb=", setup_io_tlb_npages);
+early_param("swiotlb", setup_io_tlb_npages);
 /* make io_tlb_overflow tunable too? */
 
 unsigned long swiotlb_nr_tbl(void)
@@ -115,6 +115,18 @@ unsigned long swiotlb_nr_tbl(void)
 	return io_tlb_nslabs;
 }
 EXPORT_SYMBOL_GPL(swiotlb_nr_tbl);
+
+/* default to 64MB */
+#define IO_TLB_DEFAULT_SIZE (64UL<<20)
+unsigned long swiotlb_size_or_default(void)
+{
+	unsigned long size;
+
+	size = io_tlb_nslabs << IO_TLB_SHIFT;
+
+	return size ? size : (IO_TLB_DEFAULT_SIZE);
+}
+
 /* Note that this doesn't work with highmem page */
 static dma_addr_t swiotlb_virt_to_bus(struct device *hwdev,
 				      volatile void *address)
@@ -188,8 +200,7 @@ int __init swiotlb_init_with_tbl(char *t
 void  __init
 swiotlb_init(int verbose)
 {
-	/* default to 64MB */
-	size_t default_size = 64UL<<20;
+	size_t default_size = IO_TLB_DEFAULT_SIZE;
 	unsigned char *vstart;
 	unsigned long bytes;
 

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH] x86, kdump: Set crashkernel_low automatically
  2013-03-11 19:20                                         ` Vivek Goyal
@ 2013-03-11 19:55                                           ` H. Peter Anvin
  2013-03-11 20:12                                             ` Vivek Goyal
  0 siblings, 1 reply; 101+ messages in thread
From: H. Peter Anvin @ 2013-03-11 19:55 UTC (permalink / raw)
  To: Vivek Goyal
  Cc: Yinghai Lu, Konrad Rzeszutek Wilk, Thomas Gleixner, Ingo Molnar,
	WANG Chao, Eric W. Biederman, linux-kernel

On 03/11/2013 12:20 PM, Vivek Goyal wrote:
> 
> I find it odd that if a user wants to load a 32bit kernel or use 32bit
> entry point then he needs to first reboot the kernel and re-reserve
> the memory.
> 
> At installation time, one does not necessarily know what kind of kernel
> will be used for crashdump. So reserving as high as possible limits
> the choices.
> 
> I would rather prefer that user opt in for higher addresses instead of
> these being reserved by default.
> 

Quite frankly the whole design seems to be held together with chewing
gum.  At the core, the problem is a tight coupling between kexec-tools
version, kexec-tools options, and kernel command line options that have
to be combined in very ugly ways.  Part of the reason is that the kernel
isn't actually given the information it needs to do the job required.

As far as "if a user wants to load"... why on Earth should that be the
default?  How could that *not* be an exceptional case?

	-hpa



^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH] x86, kdump: Set crashkernel_low automatically
  2013-03-11 19:14                                       ` [PATCH] x86, kdump: Set crashkernel_low automatically Eric W. Biederman
  2013-03-11 19:22                                         ` Vivek Goyal
@ 2013-03-11 19:56                                         ` H. Peter Anvin
  1 sibling, 0 replies; 101+ messages in thread
From: H. Peter Anvin @ 2013-03-11 19:56 UTC (permalink / raw)
  To: Eric W. Biederman
  Cc: Yinghai Lu, Vivek Goyal, Thomas Gleixner, Ingo Molnar, WANG Chao,
	linux-kernel

On 03/11/2013 12:14 PM, Eric W. Biederman wrote:
> 
> I don't totally follow the reasoning, but there is one real motivating
> example that is not easy to fix and it has little to do with
> kexec-tools.  There is a practical issue that so far the easiest way
> to deal with iommus after a kexec on panic is to just not use them.
> The problem is what to do with existing DMAs transfers that were setup
> by the kernel that crashed and are using the iommu.
> 
> When you are loaded above 4G not using iommus can be a challenge.
> 

Isn't that what swiotlb is for?

	-hpa


^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH] x86, kdump: Set crashkernel_low automatically
  2013-03-11 19:22                                         ` Vivek Goyal
@ 2013-03-11 19:59                                           ` H. Peter Anvin
  2013-03-11 20:17                                             ` Vivek Goyal
  0 siblings, 1 reply; 101+ messages in thread
From: H. Peter Anvin @ 2013-03-11 19:59 UTC (permalink / raw)
  To: Vivek Goyal
  Cc: Eric W. Biederman, Yinghai Lu, Thomas Gleixner, Ingo Molnar,
	WANG Chao, linux-kernel

On 03/11/2013 12:22 PM, Vivek Goyal wrote:
> 
> So always reserving memory at highest address will break all the cases
> which work without iommu and rely on swiotlb. I think first we need
> to make sure that kdump works reliably with iommu on, and then try
> to move to always reserving memory at higest possible address.
> 

We should clearly always reserve an swiotlb window, *or*, probably much
better, teach the kdump kernel to *make* an swiotlb window (by having a
memory buffer in its reserved memory area into which it copies a chunk
of low memory, just as we do for the bottom megabyte.  If we are already
in low memory that buffer becomes the swiotlb window, no copy necessary.)

	-hpa


^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH] x86, kdump: Set crashkernel_low automatically
  2013-03-11 19:55                                           ` H. Peter Anvin
@ 2013-03-11 20:12                                             ` Vivek Goyal
  2013-03-11 20:19                                               ` H. Peter Anvin
  0 siblings, 1 reply; 101+ messages in thread
From: Vivek Goyal @ 2013-03-11 20:12 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: Yinghai Lu, Konrad Rzeszutek Wilk, Thomas Gleixner, Ingo Molnar,
	WANG Chao, Eric W. Biederman, linux-kernel

On Mon, Mar 11, 2013 at 12:55:55PM -0700, H. Peter Anvin wrote:
> On 03/11/2013 12:20 PM, Vivek Goyal wrote:
> > 
> > I find it odd that if a user wants to load a 32bit kernel or use 32bit
> > entry point then he needs to first reboot the kernel and re-reserve
> > the memory.
> > 
> > At installation time, one does not necessarily know what kind of kernel
> > will be used for crashdump. So reserving as high as possible limits
> > the choices.
> > 
> > I would rather prefer that user opt in for higher addresses instead of
> > these being reserved by default.
> > 
> 
> Quite frankly the whole design seems to be held together with chewing
> gum.  At the core, the problem is a tight coupling between kexec-tools
> version, kexec-tools options, and kernel command line options that have
> to be combined in very ugly ways.  Part of the reason is that the kernel
> isn't actually given the information it needs to do the job required.
> 
> As far as "if a user wants to load"... why on Earth should that be the
> default?  How could that *not* be an exceptional case?

Because it breaks existing user cases. We had this limitation so far
that bzImage has to be loaded in first 896MB. And for 32bit bzImage
entry, I think that is still true?

So how can kernel assume that user is always loading a 64bit bzImage
and reserve memory accordingly.

Also in the past we did not have relocatable kernel and memory had to
be reserved at the address new kernel is built. Thankfully that is
no more the case.

Thanks
Vivek

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH] x86, kdump: Set crashkernel_low automatically
  2013-03-11 19:59                                           ` H. Peter Anvin
@ 2013-03-11 20:17                                             ` Vivek Goyal
  0 siblings, 0 replies; 101+ messages in thread
From: Vivek Goyal @ 2013-03-11 20:17 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: Eric W. Biederman, Yinghai Lu, Thomas Gleixner, Ingo Molnar,
	WANG Chao, linux-kernel

On Mon, Mar 11, 2013 at 12:59:44PM -0700, H. Peter Anvin wrote:
> On 03/11/2013 12:22 PM, Vivek Goyal wrote:
> > 
> > So always reserving memory at highest address will break all the cases
> > which work without iommu and rely on swiotlb. I think first we need
> > to make sure that kdump works reliably with iommu on, and then try
> > to move to always reserving memory at higest possible address.
> > 
> 
> We should clearly always reserve an swiotlb window, *or*, probably much
> better, teach the kdump kernel to *make* an swiotlb window (by having a
> memory buffer in its reserved memory area into which it copies a chunk
> of low memory, just as we do for the bottom megabyte.  If we are already
> in low memory that buffer becomes the swiotlb window, no copy necessary.)

This sounds like a good idea. It will require exporting how much memory
should be needed for swiotlb. And then kexec-tools should be able to 
backup that memory area and make that memory available to second kernel.

Thanks
Vivek

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH] x86, kdump: Set crashkernel_low automatically
  2013-03-11 20:12                                             ` Vivek Goyal
@ 2013-03-11 20:19                                               ` H. Peter Anvin
  2013-03-11 20:36                                                 ` H. Peter Anvin
  2013-03-11 20:38                                                 ` Eric W. Biederman
  0 siblings, 2 replies; 101+ messages in thread
From: H. Peter Anvin @ 2013-03-11 20:19 UTC (permalink / raw)
  To: Vivek Goyal
  Cc: Yinghai Lu, Konrad Rzeszutek Wilk, Thomas Gleixner, Ingo Molnar,
	WANG Chao, Eric W. Biederman, linux-kernel

On 03/11/2013 01:12 PM, Vivek Goyal wrote:
>>
>> Quite frankly the whole design seems to be held together with chewing
>> gum.  At the core, the problem is a tight coupling between kexec-tools
>> version, kexec-tools options, and kernel command line options that have
>> to be combined in very ugly ways.  Part of the reason is that the kernel
>> isn't actually given the information it needs to do the job required.
>>
>> As far as "if a user wants to load"... why on Earth should that be the
>> default?  How could that *not* be an exceptional case?
> 
> Because it breaks existing user cases. We had this limitation so far
> that bzImage has to be loaded in first 896MB. And for 32bit bzImage
> entry, I think that is still true?
> 
> So how can kernel assume that user is always loading a 64bit bzImage
> and reserve memory accordingly.
> 
> Also in the past we did not have relocatable kernel and memory had to
> be reserved at the address new kernel is built. Thankfully that is
> no more the case.
> 

The problem with this argument here is that we are spiraling down the
drain of increasing user-visible complexity in order to not break
existing but exotic use cases.  We need to stop and reverse this trend.
 I want to make a few observations on this:

1. Running with an archaic kexec-tools should be considered an anomaly.
 If necessary, we could introduce a kernel option to let the kernel know
which kexec-tools version the user will use.

2. As long as memory is available, there is always the option to shift
memory around to accommodate the crashkernel.  That probably should have
been done all along.

3. The memory size reserved should be deduced automatically to the
greatest possible extent.

	-hpa


^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH] x86, kdump: Set crashkernel_low automatically
  2013-03-11 20:19                                               ` H. Peter Anvin
@ 2013-03-11 20:36                                                 ` H. Peter Anvin
  2013-03-11 20:38                                                 ` Eric W. Biederman
  1 sibling, 0 replies; 101+ messages in thread
From: H. Peter Anvin @ 2013-03-11 20:36 UTC (permalink / raw)
  To: Vivek Goyal
  Cc: Yinghai Lu, Konrad Rzeszutek Wilk, Thomas Gleixner, Ingo Molnar,
	WANG Chao, Eric W. Biederman, linux-kernel

On 03/11/2013 01:19 PM, H. Peter Anvin wrote:
> 
> The problem with this argument here is that we are spiraling down the
> drain of increasing user-visible complexity in order to not break
> existing but exotic use cases.  We need to stop and reverse this trend.
>  I want to make a few observations on this:
> 
> 1. Running with an archaic kexec-tools should be considered an anomaly.
>  If necessary, we could introduce a kernel option to let the kernel know
> which kexec-tools version the user will use.
> 
> 2. As long as memory is available, there is always the option to shift
> memory around to accommodate the crashkernel.  That probably should have
> been done all along.
> 
> 3. The memory size reserved should be deduced automatically to the
> greatest possible extent.
> 

The really big picture problem here is that the host kernel is expected
to predict at boot time what will happen in the future: what are the
requirements of the kdump kernel, and its tools, which hasn't been
loaded yet?

Can we get past that as a fundamental problem?

	-hpa


^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH] x86, kdump: Set crashkernel_low automatically
  2013-03-11 20:19                                               ` H. Peter Anvin
  2013-03-11 20:36                                                 ` H. Peter Anvin
@ 2013-03-11 20:38                                                 ` Eric W. Biederman
  2013-03-11 20:42                                                   ` H. Peter Anvin
  2013-03-11 20:45                                                   ` Vivek Goyal
  1 sibling, 2 replies; 101+ messages in thread
From: Eric W. Biederman @ 2013-03-11 20:38 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: Vivek Goyal, Yinghai Lu, Konrad Rzeszutek Wilk, Thomas Gleixner,
	Ingo Molnar, WANG Chao, linux-kernel

"H. Peter Anvin" <hpa@zytor.com> writes:

> On 03/11/2013 01:12 PM, Vivek Goyal wrote:
>>>
>>> Quite frankly the whole design seems to be held together with chewing
>>> gum.  At the core, the problem is a tight coupling between kexec-tools
>>> version, kexec-tools options, and kernel command line options that have
>>> to be combined in very ugly ways.  Part of the reason is that the kernel
>>> isn't actually given the information it needs to do the job required.
>>>
>>> As far as "if a user wants to load"... why on Earth should that be the
>>> default?  How could that *not* be an exceptional case?
>> 
>> Because it breaks existing user cases. We had this limitation so far
>> that bzImage has to be loaded in first 896MB. And for 32bit bzImage
>> entry, I think that is still true?
>> 
>> So how can kernel assume that user is always loading a 64bit bzImage
>> and reserve memory accordingly.
>> 
>> Also in the past we did not have relocatable kernel and memory had to
>> be reserved at the address new kernel is built. Thankfully that is
>> no more the case.
>> 
>
> The problem with this argument here is that we are spiraling down the
> drain of increasing user-visible complexity in order to not break
> existing but exotic use cases.  We need to stop and reverse this trend.
>  I want to make a few observations on this:

> 1. Running with an archaic kexec-tools should be considered an anomaly.
>  If necessary, we could introduce a kernel option to let the kernel know
> which kexec-tools version the user will use.

Sure.  Running with the last release of kexec-tools before new changes
were made is not at all unreasonable, as updating both tools in sync is
a practical problem.

Having thought about this a little more with no changes and reserving
memory high we can run with any memory location we want as the syntax
crashkernel=AMOUNT@LOC is still supported.

A distro may not be able to automate that but shrug, a distro can
upgrade to the latest and greatest version of the tools assuming
those tools can support loading high.

> 2. As long as memory is available, there is always the option to shift
> memory around to accommodate the crashkernel.  That probably should have
> been done all along.

Arguable.  The core strategy is to reserve memory at the beginning of
time so we have memory that we know has never been used for DMA, so
there is a very strong chance that memory will never be the target of
a DMA operation.  The expectation is that we do the shifting around at
boot time.

I doubt we have a mechanism in place that can actually shift around
memory in the quantities some people are after, after a system boots.

Now quite frankly I think there are some very silly things going on.
Why does makedumpfile need to allocate and create a huge bitmap of
which pages to dump?

Last I was playing with this I had my amount of reserved memory down to
32MiB or was it 8MiB.  It was very small and for the small system I was
on it worked fine.

I totally makes sense to figure out how to load a kernel high.  I am not
convinced kexec on panic is the best use of that ability.  I would argue
that it might be better to figure out how to use a small memory
foot-print and try to keep that foot-print from growing.

Eric

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH] x86, kdump: Set crashkernel_low automatically
  2013-03-11 20:38                                                 ` Eric W. Biederman
@ 2013-03-11 20:42                                                   ` H. Peter Anvin
  2013-03-11 21:10                                                     ` Vivek Goyal
  2013-03-11 20:45                                                   ` Vivek Goyal
  1 sibling, 1 reply; 101+ messages in thread
From: H. Peter Anvin @ 2013-03-11 20:42 UTC (permalink / raw)
  To: Eric W. Biederman
  Cc: Vivek Goyal, Yinghai Lu, Konrad Rzeszutek Wilk, Thomas Gleixner,
	Ingo Molnar, WANG Chao, linux-kernel

On 03/11/2013 01:38 PM, Eric W. Biederman wrote:
> 
> I totally makes sense to figure out how to load a kernel high.  I am not
> convinced kexec on panic is the best use of that ability.  I would argue
> that it might be better to figure out how to use a small memory
> foot-print and try to keep that foot-print from growing.
> 

I could not agree more with this.  The whole reason this is a problem is
because we are talking about hundreds of megabytes of crashkernel.  If
we can fix *that* problem, we are much better off.

	-hpa



^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH] x86, kdump: Set crashkernel_low automatically
  2013-03-11 20:38                                                 ` Eric W. Biederman
  2013-03-11 20:42                                                   ` H. Peter Anvin
@ 2013-03-11 20:45                                                   ` Vivek Goyal
  2013-03-11 20:50                                                     ` H. Peter Anvin
  2013-03-11 20:57                                                     ` Yinghai Lu
  1 sibling, 2 replies; 101+ messages in thread
From: Vivek Goyal @ 2013-03-11 20:45 UTC (permalink / raw)
  To: Eric W. Biederman
  Cc: H. Peter Anvin, Yinghai Lu, Konrad Rzeszutek Wilk,
	Thomas Gleixner, Ingo Molnar, WANG Chao, linux-kernel

On Mon, Mar 11, 2013 at 01:38:53PM -0700, Eric W. Biederman wrote:


[..]
> I would argue
> that it might be better to figure out how to use a small memory
> foot-print and try to keep that foot-print from growing.

In my experience, trying to keep foot-print small has kind of been a
losing battle.

- People want more functionality in second kernel, want to dump to more
  complicated IO stacks and that requires pulling in more drivers,
  more libraries, more daemons, more user space tools and what not.

- Now we use dracut generated initramfs and it has been growing in size.
  Now systemd has been pulled in too.

- Drivers keep on increasing their memory usage.

- makdumpfile needs more memory to dump large machines.

There are so many places where memory usage is going up and trying
to keep track of all that has been very hard.

So I would think that it is a good goal to have but continuously 
increasing memory usage is inevitable.

Thanks
Vivek

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH] x86, kdump: Set crashkernel_low automatically
  2013-03-11 20:45                                                   ` Vivek Goyal
@ 2013-03-11 20:50                                                     ` H. Peter Anvin
  2013-03-11 21:03                                                       ` Vivek Goyal
  2013-03-11 20:57                                                     ` Yinghai Lu
  1 sibling, 1 reply; 101+ messages in thread
From: H. Peter Anvin @ 2013-03-11 20:50 UTC (permalink / raw)
  To: Vivek Goyal
  Cc: Eric W. Biederman, Yinghai Lu, Konrad Rzeszutek Wilk,
	Thomas Gleixner, Ingo Molnar, WANG Chao, linux-kernel

On 03/11/2013 01:45 PM, Vivek Goyal wrote:
> 
> - Now we use dracut generated initramfs and it has been growing in size.
>   Now systemd has been pulled in too.
> 

And the solution to that isn't obvious?

> - makdumpfile needs more memory to dump large machines.
> 
> There are so many places where memory usage is going up and trying
> to keep track of all that has been very hard.

Seriously, in particular the O(n) memory requirements you may want to
think very very hard about.

	-hpa



^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH] x86, kdump: Set crashkernel_low automatically
  2013-03-11 20:45                                                   ` Vivek Goyal
  2013-03-11 20:50                                                     ` H. Peter Anvin
@ 2013-03-11 20:57                                                     ` Yinghai Lu
  2013-03-11 21:06                                                       ` Vivek Goyal
  1 sibling, 1 reply; 101+ messages in thread
From: Yinghai Lu @ 2013-03-11 20:57 UTC (permalink / raw)
  To: Vivek Goyal
  Cc: Eric W. Biederman, H. Peter Anvin, Konrad Rzeszutek Wilk,
	Thomas Gleixner, Ingo Molnar, WANG Chao, linux-kernel

On Mon, Mar 11, 2013 at 1:45 PM, Vivek Goyal <vgoyal@redhat.com> wrote:
> In my experience, trying to keep foot-print small has kind of been a
> losing battle.
>
> - People want more functionality in second kernel, want to dump to more
>   complicated IO stacks and that requires pulling in more drivers,
>   more libraries, more daemons, more user space tools and what not.
>
> - Now we use dracut generated initramfs and it has been growing in size.
>   Now systemd has been pulled in too.
>
> - Drivers keep on increasing their memory usage.

If the dump file will be only put one place, why should all the drivers
for all devices get loaded?
for example: dump will be on disk with one scsi controller, can you only
load driver that contoller? and forget about all other storage controller and
network etc drivers.

Thanks

Yinghai

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH] x86, kdump: Set crashkernel_low automatically
  2013-03-11 20:50                                                     ` H. Peter Anvin
@ 2013-03-11 21:03                                                       ` Vivek Goyal
  2013-03-11 21:06                                                         ` H. Peter Anvin
  2013-03-12  8:35                                                         ` Ingo Molnar
  0 siblings, 2 replies; 101+ messages in thread
From: Vivek Goyal @ 2013-03-11 21:03 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: Eric W. Biederman, Yinghai Lu, Konrad Rzeszutek Wilk,
	Thomas Gleixner, Ingo Molnar, WANG Chao, linux-kernel

On Mon, Mar 11, 2013 at 01:50:21PM -0700, H. Peter Anvin wrote:
> On 03/11/2013 01:45 PM, Vivek Goyal wrote:
> > 
> > - Now we use dracut generated initramfs and it has been growing in size.
> >   Now systemd has been pulled in too.
> > 
> 
> And the solution to that isn't obvious?

Sorry, I did not understand what do you mean by above.

If you are suggesting that move away from dracut, it does not work
in practice. Initially we wrote our custom code to generate custom
initramfs, and we were always lagging in terms of what dump targets
can be supported and kept on constantly fixing the issues which had
been taken care of in dracut one way or other. So it was like
maintaining a duplicate initramfs generation tool.

So we do not want to use non-standard tools just for kdump. dracut
generates the initramfs for first kernel and then it should be able
to for second kernel too.

Another problem is that other user space component developers, they don't
know that they are supposed to work with 64MB in total too. Same is true for
anybody who is writing driver code. 

And bloated memory usage is detected, after the fact. After that one
can keep on chasing people, and they say that it is their feature
requirement. And it is not possible to go and optimize every subsystem
so that together they can boot and work with 64MB.

> 
> > - makdumpfile needs more memory to dump large machines.
> > 
> > There are so many places where memory usage is going up and trying
> > to keep track of all that has been very hard.
> 
> Seriously, in particular the O(n) memory requirements you may want to
> think very very hard about.

Well we now also have a mode in makedumpfile where memory requirement is
O(1). Just that it takes more cpu and takes much longer to dump. May be it
can be improved further.

I am more worried about kernel drivers, and all the user space we need
to pull in to initramfs to meet more advanced requirements in kdump
environment.

Thanks
Vivek

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH] x86, kdump: Set crashkernel_low automatically
  2013-03-11 20:57                                                     ` Yinghai Lu
@ 2013-03-11 21:06                                                       ` Vivek Goyal
  2013-03-11 21:15                                                         ` Yinghai Lu
  0 siblings, 1 reply; 101+ messages in thread
From: Vivek Goyal @ 2013-03-11 21:06 UTC (permalink / raw)
  To: Yinghai Lu
  Cc: Eric W. Biederman, H. Peter Anvin, Konrad Rzeszutek Wilk,
	Thomas Gleixner, Ingo Molnar, WANG Chao, linux-kernel

On Mon, Mar 11, 2013 at 01:57:41PM -0700, Yinghai Lu wrote:
> On Mon, Mar 11, 2013 at 1:45 PM, Vivek Goyal <vgoyal@redhat.com> wrote:
> > In my experience, trying to keep foot-print small has kind of been a
> > losing battle.
> >
> > - People want more functionality in second kernel, want to dump to more
> >   complicated IO stacks and that requires pulling in more drivers,
> >   more libraries, more daemons, more user space tools and what not.
> >
> > - Now we use dracut generated initramfs and it has been growing in size.
> >   Now systemd has been pulled in too.
> >
> > - Drivers keep on increasing their memory usage.
> 
> If the dump file will be only put one place, why should all the drivers
> for all devices get loaded?
> for example: dump will be on disk with one scsi controller, can you only
> load driver that contoller? and forget about all other storage controller and
> network etc drivers.

We do try to optimize things this way. Only include drivers as needed. But
a single driver might be handling lots of cards and then try to bring
up all the cards in second kernel.

Just fixed some issues with one driver where around 40MB extra memory
was benig consumed because of multiqueue support. Just bunch of allocation
in driver. And we used kernel command line to disable it.

Point being, in practice how many software development areas one can
change to keep memory requirement with-in few MBs. I have been doing
it for last few years and it has been very hard.

Thanks
Vivek

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH] x86, kdump: Set crashkernel_low automatically
  2013-03-11 21:03                                                       ` Vivek Goyal
@ 2013-03-11 21:06                                                         ` H. Peter Anvin
  2013-03-12 13:46                                                           ` Vivek Goyal
  2013-03-12  8:35                                                         ` Ingo Molnar
  1 sibling, 1 reply; 101+ messages in thread
From: H. Peter Anvin @ 2013-03-11 21:06 UTC (permalink / raw)
  To: Vivek Goyal
  Cc: Eric W. Biederman, Yinghai Lu, Konrad Rzeszutek Wilk,
	Thomas Gleixner, Ingo Molnar, WANG Chao, linux-kernel

On 03/11/2013 02:03 PM, Vivek Goyal wrote:
>>
>> And the solution to that isn't obvious?
> 
> Sorry, I did not understand what do you mean by above.
> 
> If you are suggesting that move away from dracut, it does not work
> in practice. Initially we wrote our custom code to generate custom
> initramfs, and we were always lagging in terms of what dump targets
> can be supported and kept on constantly fixing the issues which had
> been taken care of in dracut one way or other. So it was like
> maintaining a duplicate initramfs generation tool.
> 
> So we do not want to use non-standard tools just for kdump. dracut
> generates the initramfs for first kernel and then it should be able
> to for second kernel too.
> 
> Another problem is that other user space component developers, they don't
> know that they are supposed to work with 64MB in total too. Same is true for
> anybody who is writing driver code. 
> 
> And bloated memory usage is detected, after the fact. After that one
> can keep on chasing people, and they say that it is their feature
> requirement. And it is not possible to go and optimize every subsystem
> so that together they can boot and work with 64MB.
> 

Your problem is fundamentally that you are using the wrong tool for the
job, simply because it is expedient to you.  Arguably dracut & co are
the wrong tool for any job given the enormous amount of bloat it
entails, but at least in the normal kernel case it only affects boot
time as it is jettisoned, but in your case it is not.

>>
>>> - makdumpfile needs more memory to dump large machines.
>>>
>>> There are so many places where memory usage is going up and trying
>>> to keep track of all that has been very hard.
>>
>> Seriously, in particular the O(n) memory requirements you may want to
>> think very very hard about.
> 
> Well we now also have a mode in makedumpfile where memory requirement is
> O(1). Just that it takes more cpu and takes much longer to dump. May be it
> can be improved further.
> 
> I am more worried about kernel drivers, and all the user space we need
> to pull in to initramfs to meet more advanced requirements in kdump
> environment.
> 

That seems like a problem you need to deal with, or you will soon be so
bloated that you have substantial performance impact on any system.

	-hpa



^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH] x86, kdump: Set crashkernel_low automatically
  2013-03-11 20:42                                                   ` H. Peter Anvin
@ 2013-03-11 21:10                                                     ` Vivek Goyal
  2013-03-11 21:13                                                       ` H. Peter Anvin
  0 siblings, 1 reply; 101+ messages in thread
From: Vivek Goyal @ 2013-03-11 21:10 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: Eric W. Biederman, Yinghai Lu, Konrad Rzeszutek Wilk,
	Thomas Gleixner, Ingo Molnar, WANG Chao, linux-kernel

On Mon, Mar 11, 2013 at 01:42:37PM -0700, H. Peter Anvin wrote:
> On 03/11/2013 01:38 PM, Eric W. Biederman wrote:
> > 
> > I totally makes sense to figure out how to load a kernel high.  I am not
> > convinced kexec on panic is the best use of that ability.  I would argue
> > that it might be better to figure out how to use a small memory
> > foot-print and try to keep that foot-print from growing.
> > 
> 
> I could not agree more with this.  The whole reason this is a problem is
> because we are talking about hundreds of megabytes of crashkernel.  If
> we can fix *that* problem, we are much better off.

This kind of goal is achievable only if we also restrict how much memory
first kernel can use. Then all the dependent component will be aware of
how severe boot requirements are. And there is no such requirement. It is
just a goal that keep memory bloat to the minimum. But bloat does not mean
that booting is not allowed. To me kdump environment requirement should be
no different. Otherwise enforcing them becomes a challenge.

Thanks
Vivek

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH] x86, kdump: Set crashkernel_low automatically
  2013-03-11 21:10                                                     ` Vivek Goyal
@ 2013-03-11 21:13                                                       ` H. Peter Anvin
  0 siblings, 0 replies; 101+ messages in thread
From: H. Peter Anvin @ 2013-03-11 21:13 UTC (permalink / raw)
  To: Vivek Goyal
  Cc: Eric W. Biederman, Yinghai Lu, Konrad Rzeszutek Wilk,
	Thomas Gleixner, Ingo Molnar, WANG Chao, linux-kernel

On 03/11/2013 02:10 PM, Vivek Goyal wrote:
> 
> To me kdump environment requirement should be
> no different.
> 

kdump *is* different.  Sounds like you need to realize and deal with
that fact.

	-hpa


^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH] x86, kdump: Set crashkernel_low automatically
  2013-03-11 21:06                                                       ` Vivek Goyal
@ 2013-03-11 21:15                                                         ` Yinghai Lu
  0 siblings, 0 replies; 101+ messages in thread
From: Yinghai Lu @ 2013-03-11 21:15 UTC (permalink / raw)
  To: Vivek Goyal
  Cc: Eric W. Biederman, H. Peter Anvin, Konrad Rzeszutek Wilk,
	Thomas Gleixner, Ingo Molnar, WANG Chao, linux-kernel

On Mon, Mar 11, 2013 at 2:06 PM, Vivek Goyal <vgoyal@redhat.com> wrote:
> On Mon, Mar 11, 2013 at 01:57:41PM -0700, Yinghai Lu wrote:
>> On Mon, Mar 11, 2013 at 1:45 PM, Vivek Goyal <vgoyal@redhat.com> wrote:
>> > In my experience, trying to keep foot-print small has kind of been a
>> > losing battle.
>> >
>> > - People want more functionality in second kernel, want to dump to more
>> >   complicated IO stacks and that requires pulling in more drivers,
>> >   more libraries, more daemons, more user space tools and what not.
>> >
>> > - Now we use dracut generated initramfs and it has been growing in size.
>> >   Now systemd has been pulled in too.
>> >
>> > - Drivers keep on increasing their memory usage.
>>
>> If the dump file will be only put one place, why should all the drivers
>> for all devices get loaded?
>> for example: dump will be on disk with one scsi controller, can you only
>> load driver that contoller? and forget about all other storage controller and
>> network etc drivers.
>
> We do try to optimize things this way. Only include drivers as needed. But
> a single driver might be handling lots of cards and then try to bring
> up all the cards in second kernel.

Can you disable auto_probe at first? and then use /sys bind driver to specific
device.

>
> Just fixed some issues with one driver where around 40MB extra memory
> was benig consumed because of multiqueue support. Just bunch of allocation
> in driver. And we used kernel command line to disable it.

Yes that the is one problem, we should have some facility or helpers to reject
 those invalid request. and driver should reduce their foot print step by step.
for example, we only have 64M, but first driver want to alloc 32M, it
should be just rejected.

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH] x86, kdump: Set crashkernel_low automatically
  2013-03-11 21:03                                                       ` Vivek Goyal
  2013-03-11 21:06                                                         ` H. Peter Anvin
@ 2013-03-12  8:35                                                         ` Ingo Molnar
  1 sibling, 0 replies; 101+ messages in thread
From: Ingo Molnar @ 2013-03-12  8:35 UTC (permalink / raw)
  To: Vivek Goyal
  Cc: H. Peter Anvin, Eric W. Biederman, Yinghai Lu,
	Konrad Rzeszutek Wilk, Thomas Gleixner, WANG Chao, linux-kernel


* Vivek Goyal <vgoyal@redhat.com> wrote:

> On Mon, Mar 11, 2013 at 01:50:21PM -0700, H. Peter Anvin wrote:
> > On 03/11/2013 01:45 PM, Vivek Goyal wrote:
> > > 
> > > - Now we use dracut generated initramfs and it has been growing in 
> > >   size. Now systemd has been pulled in too.
> > 
> > And the solution to that isn't obvious?
> 
> Sorry, I did not understand what do you mean by above.
> 
> If you are suggesting that move away from dracut, it does not work in 
> practice. Initially we wrote our custom code to generate custom 
> initramfs, and we were always lagging in terms of what dump targets can 
> be supported and kept on constantly fixing the issues which had been 
> taken care of in dracut one way or other. So it was like maintaining a 
> duplicate initramfs generation tool.

The fundamental design problem is this artificial split of the kernel from 
kexec-tools, just to support an arguably exotic feature, which in turn 
then tries to support a complex compatibility matrix - making each variant 
even more super exotic. There's just not enough usage and not enough 
manpower to keep all that tidy ...

If there was tools/kexec/ then many of these constraints and quirks with 
old versions would go away: old kernels would come with old kexec tools, 
new kernels would come with new kexec tools.

Just look at how tools/perf/ is packaged up with new kernels: you 
generally get a new perf with a new kernel version. Alone this eliminates 
a fair bit of support complexity and makes it easier to keep users 
uptodate.

[ kexec tooling could go even farther: if included in the initramfs then
  it could do away with ABI constraints and compatibility expectations
  altogether.

  This is one of the cases where it _does_ make sense: kexec tools and in
  general kernel image analysis is obviously coupled to the kernel's
  current data structures. ]

If this was fixed then kexec could step a whole lot further, not just in 
terms of robustness, but also in terms of feature set - and, ultimately, 
increased usage by users and kernel developers.

Thanks,

	Ingo

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH] x86, kdump: Set crashkernel_low automatically
  2013-03-11 21:06                                                         ` H. Peter Anvin
@ 2013-03-12 13:46                                                           ` Vivek Goyal
  0 siblings, 0 replies; 101+ messages in thread
From: Vivek Goyal @ 2013-03-12 13:46 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: Eric W. Biederman, Yinghai Lu, Konrad Rzeszutek Wilk,
	Thomas Gleixner, Ingo Molnar, WANG Chao, linux-kernel

On Mon, Mar 11, 2013 at 02:06:57PM -0700, H. Peter Anvin wrote:
> On 03/11/2013 02:03 PM, Vivek Goyal wrote:
> >>
> >> And the solution to that isn't obvious?
> > 
> > Sorry, I did not understand what do you mean by above.
> > 
> > If you are suggesting that move away from dracut, it does not work
> > in practice. Initially we wrote our custom code to generate custom
> > initramfs, and we were always lagging in terms of what dump targets
> > can be supported and kept on constantly fixing the issues which had
> > been taken care of in dracut one way or other. So it was like
> > maintaining a duplicate initramfs generation tool.
> > 
> > So we do not want to use non-standard tools just for kdump. dracut
> > generates the initramfs for first kernel and then it should be able
> > to for second kernel too.
> > 
> > Another problem is that other user space component developers, they don't
> > know that they are supposed to work with 64MB in total too. Same is true for
> > anybody who is writing driver code. 
> > 
> > And bloated memory usage is detected, after the fact. After that one
> > can keep on chasing people, and they say that it is their feature
> > requirement. And it is not possible to go and optimize every subsystem
> > so that together they can boot and work with 64MB.
> > 
> 
> Your problem is fundamentally that you are using the wrong tool for the
> job, simply because it is expedient to you.  Arguably dracut & co are
> the wrong tool for any job given the enormous amount of bloat it
> entails, but at least in the normal kernel case it only affects boot
> time as it is jettisoned, but in your case it is not.

Dracut is just one piece of the puzzle. We are optimizing away dracut
for kdump environment. We generate host only initramfs and using command
line options actively exclude the components which we don't need when
generating kdump initramfs.

But as kdump usage grows, customers want more out of kdump both in
terms of features and performance. For example, now we support dumping
to multipath over iscsi targets. For this target we first pack relevant
networking drivers and networking utilities, then pack in iscsi related
utiilties, then all the multipath related components go in and on top of
that all the lvm related utilities and components and dependent libraries
go in. And inclusion of more components leads to memory bloat.

I do agree with the optimization part though. That is include minimal
set of components and be vigilant about memory usage of various
components.

One of the things which could help is if we had a way to track module
memory usage. May be some /sys interface which could export how much
memory module is using. We could use that as debug output and
over a period of time we could figure out how module memory usage is
growing and who are worst offenders and where are the optimization
opportunities.

Thanks
Vivek

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH] x86, kdump: Set crashkernel_low automatically
  2013-03-11 19:44                                               ` Yinghai Lu
@ 2013-03-18 14:46                                                 ` Vivek Goyal
  2013-03-18 15:33                                                   ` Vivek Goyal
  0 siblings, 1 reply; 101+ messages in thread
From: Vivek Goyal @ 2013-03-18 14:46 UTC (permalink / raw)
  To: Yinghai Lu
  Cc: Eric W. Biederman, H. Peter Anvin, Konrad Rzeszutek Wilk,
	Thomas Gleixner, Ingo Molnar, WANG Chao, linux-kernel

On Mon, Mar 11, 2013 at 12:44:15PM -0700, Yinghai Lu wrote:
> On Mon, Mar 11, 2013 at 12:39 PM, Yinghai Lu <yinghai@kernel.org> wrote:
> > On Mon, Mar 11, 2013 at 12:38 PM, Vivek Goyal <vgoyal@redhat.com> wrote:
> >>> No need to use crashkernel_high, we can just cashkernel=X@Y instead.
> >>
> >> crashkernel=X@Y is little different. It assumes user knows the memory
> >> map and location "Y" is fixed. There might not be any memory at "Y".
> >
> > then use crashkernel=4G?
> 
> I re attached -v2 and -v3.
> 
> I'm ok that any one is applied or two get applied all together.
> 
> only affect 64bit
> -v2: try under under 896M, then 4G, then MAXMEM
> -v3: auto set crashkernel_low with swiotlb size.

So, what's the resolution on this issue. Is the verdict that we always
reserve high. Update your kexec-tools to cope with that. For swiotlb
issue, modify kexec-tools to copy low memory in backup region and give
low memory to second kernel for software iotlb?

I am assuming that updating tools will not help with loading and using
of 32bit bzImage. So user needs to use crashkernel=X@Y syntax to cope
with that? (Given the fact that copying code around after crash carries
the greater risk of ongoing DMA on destination location).

Thanks
Vivek

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH] x86, kdump: Set crashkernel_low automatically
  2013-03-18 14:46                                                 ` Vivek Goyal
@ 2013-03-18 15:33                                                   ` Vivek Goyal
  2013-03-18 19:05                                                     ` Yinghai Lu
  2013-03-18 19:10                                                     ` H. Peter Anvin
  0 siblings, 2 replies; 101+ messages in thread
From: Vivek Goyal @ 2013-03-18 15:33 UTC (permalink / raw)
  To: Yinghai Lu
  Cc: Eric W. Biederman, H. Peter Anvin, Konrad Rzeszutek Wilk,
	Thomas Gleixner, Ingo Molnar, WANG Chao, linux-kernel

On Mon, Mar 18, 2013 at 10:46:03AM -0400, Vivek Goyal wrote:
> On Mon, Mar 11, 2013 at 12:44:15PM -0700, Yinghai Lu wrote:
> > On Mon, Mar 11, 2013 at 12:39 PM, Yinghai Lu <yinghai@kernel.org> wrote:
> > > On Mon, Mar 11, 2013 at 12:38 PM, Vivek Goyal <vgoyal@redhat.com> wrote:
> > >>> No need to use crashkernel_high, we can just cashkernel=X@Y instead.
> > >>
> > >> crashkernel=X@Y is little different. It assumes user knows the memory
> > >> map and location "Y" is fixed. There might not be any memory at "Y".
> > >
> > > then use crashkernel=4G?
> > 
> > I re attached -v2 and -v3.
> > 
> > I'm ok that any one is applied or two get applied all together.
> > 
> > only affect 64bit
> > -v2: try under under 896M, then 4G, then MAXMEM
> > -v3: auto set crashkernel_low with swiotlb size.
> 
> So, what's the resolution on this issue. Is the verdict that we always
> reserve high. Update your kexec-tools to cope with that. For swiotlb
> issue, modify kexec-tools to copy low memory in backup region and give
> low memory to second kernel for software iotlb?
> 
> I am assuming that updating tools will not help with loading and using
> of 32bit bzImage. So user needs to use crashkernel=X@Y syntax to cope
> with that? (Given the fact that copying code around after crash carries
> the greater risk of ongoing DMA on destination location).

Thinking more about it, if ongoing DMA is an issue, then setting up
software iotlb in those areas is also prone to being overwritten by
those DMAs. Hence, reserving memory low where no DMA is setup by first
kernel, seems somewhat safer.

Thanks
Vivek

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH] x86, kdump: Set crashkernel_low automatically
  2013-03-18 15:33                                                   ` Vivek Goyal
@ 2013-03-18 19:05                                                     ` Yinghai Lu
  2013-03-18 19:10                                                     ` H. Peter Anvin
  1 sibling, 0 replies; 101+ messages in thread
From: Yinghai Lu @ 2013-03-18 19:05 UTC (permalink / raw)
  To: Vivek Goyal
  Cc: Eric W. Biederman, H. Peter Anvin, Konrad Rzeszutek Wilk,
	Thomas Gleixner, Ingo Molnar, WANG Chao, linux-kernel

On Mon, Mar 18, 2013 at 8:33 AM, Vivek Goyal <vgoyal@redhat.com> wrote:
> Thinking more about it, if ongoing DMA is an issue, then setting up
> software iotlb in those areas is also prone to being overwritten by
> those DMAs. Hence, reserving memory low where no DMA is setup by first
> kernel, seems somewhat safer.

So stick with crashkernel_low ? aka if system does not support iommu
with kdump, they need to append
crashkernel_low in first kernel.

I think that could be way to force vendor to double check to find out
why their system does not support
iommu with kdump.

BTW, our systems do support iommu with kdump without problem.

Thanks

Yinghai

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH] x86, kdump: Set crashkernel_low automatically
  2013-03-18 15:33                                                   ` Vivek Goyal
  2013-03-18 19:05                                                     ` Yinghai Lu
@ 2013-03-18 19:10                                                     ` H. Peter Anvin
  2013-03-18 20:00                                                       ` Vivek Goyal
  1 sibling, 1 reply; 101+ messages in thread
From: H. Peter Anvin @ 2013-03-18 19:10 UTC (permalink / raw)
  To: Vivek Goyal
  Cc: Yinghai Lu, Eric W. Biederman, Konrad Rzeszutek Wilk,
	Thomas Gleixner, Ingo Molnar, WANG Chao, linux-kernel

On 03/18/2013 08:33 AM, Vivek Goyal wrote:
> 
> Thinking more about it, if ongoing DMA is an issue, then setting up
> software iotlb in those areas is also prone to being overwritten by
> those DMAs. Hence, reserving memory low where no DMA is setup by first
> kernel, seems somewhat safer.
> 

Agreed.  We really should reserve some memory low.

	-hpa



^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH] x86, kdump: Set crashkernel_low automatically
  2013-03-18 19:10                                                     ` H. Peter Anvin
@ 2013-03-18 20:00                                                       ` Vivek Goyal
  2013-03-18 21:14                                                         ` H. Peter Anvin
  0 siblings, 1 reply; 101+ messages in thread
From: Vivek Goyal @ 2013-03-18 20:00 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: Yinghai Lu, Eric W. Biederman, Konrad Rzeszutek Wilk,
	Thomas Gleixner, Ingo Molnar, WANG Chao, linux-kernel

On Mon, Mar 18, 2013 at 12:10:47PM -0700, H. Peter Anvin wrote:
> On 03/18/2013 08:33 AM, Vivek Goyal wrote:
> > 
> > Thinking more about it, if ongoing DMA is an issue, then setting up
> > software iotlb in those areas is also prone to being overwritten by
> > those DMAs. Hence, reserving memory low where no DMA is setup by first
> > kernel, seems somewhat safer.
> > 
> 
> Agreed.  We really should reserve some memory low.

So which approach do you like for reserving some memory low.

- User specifies crashkernel_low=X to reserve some memory. Biggest problem
  here is how does user know how much memory is required for setting up
  swiotlb.

- Take yinghai's patch where by default low memory for swiotlb is reserved
  and a user need to opt out of it using crashkernel_low=0 if system has
  iommu enabled.

- crashkernel=X by default first looks for specified memory in low
  memory area.


I kind of like yinghai's approach. It is little wasteful of memory when
memory is reserved high but atleast user does not have know how much memory
to reserve low it works both when memory is reserved low (system does
not have any RAM mapped above 4G) and when memory is reserved high.

Thanks
Vivek

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH] x86, kdump: Set crashkernel_low automatically
  2013-03-18 20:00                                                       ` Vivek Goyal
@ 2013-03-18 21:14                                                         ` H. Peter Anvin
  2013-03-18 21:25                                                           ` [PATCH v3] " Yinghai Lu
  0 siblings, 1 reply; 101+ messages in thread
From: H. Peter Anvin @ 2013-03-18 21:14 UTC (permalink / raw)
  To: Vivek Goyal
  Cc: Yinghai Lu, Eric W. Biederman, Konrad Rzeszutek Wilk,
	Thomas Gleixner, Ingo Molnar, WANG Chao, linux-kernel

On 03/18/2013 01:00 PM, Vivek Goyal wrote:
> On Mon, Mar 18, 2013 at 12:10:47PM -0700, H. Peter Anvin wrote:
>> On 03/18/2013 08:33 AM, Vivek Goyal wrote:
>>>
>>> Thinking more about it, if ongoing DMA is an issue, then setting up
>>> software iotlb in those areas is also prone to being overwritten by
>>> those DMAs. Hence, reserving memory low where no DMA is setup by first
>>> kernel, seems somewhat safer.
>>>
>>
>> Agreed.  We really should reserve some memory low.
> 
> So which approach do you like for reserving some memory low.
> 
> - User specifies crashkernel_low=X to reserve some memory. Biggest problem
>   here is how does user know how much memory is required for setting up
>   swiotlb.
> 
> - Take yinghai's patch where by default low memory for swiotlb is reserved
>   and a user need to opt out of it using crashkernel_low=0 if system has
>   iommu enabled.
> 
> - crashkernel=X by default first looks for specified memory in low
>   memory area.
> 
> I kind of like yinghai's approach. It is little wasteful of memory when
> memory is reserved high but atleast user does not have know how much memory
> to reserve low it works both when memory is reserved low (system does
> not have any RAM mapped above 4G) and when memory is reserved high.
> 

I would agree, I think it is the most user friendly.

	-hpa



^ permalink raw reply	[flat|nested] 101+ messages in thread

* [PATCH v3] x86, kdump: Set crashkernel_low automatically
  2013-03-18 21:14                                                         ` H. Peter Anvin
@ 2013-03-18 21:25                                                           ` Yinghai Lu
  2013-03-18 22:52                                                             ` H. Peter Anvin
  0 siblings, 1 reply; 101+ messages in thread
From: Yinghai Lu @ 2013-03-18 21:25 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin
  Cc: WANG Chao, Vivek Goyal, Eric W. Biederman, linux-kernel, Yinghai Lu

Current code does not set low range for crashkernel if the user
does not specify that.

That cause regressions on system that does not support intel_iommu
properly.

Chao said that his system does work well on 3.8 without extra parameter.
even iommu does not work with kdump.

Set crashkernel_low automatically if the user does not specify that.

For system that does support IOMMU with kdump properly, user could
specify crashkernel_low=0 to save that 72M low ram.

-v3: add swiotlb_size() according to Konrad.

Reported-by: WANG Chao <chaowang@redhat.com>
Tested-by: WANG Chao <chaowang@redhat.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>

---
 arch/x86/kernel/setup.c |   15 ++++++++++++---
 include/linux/swiotlb.h |    1 +
 lib/swiotlb.c           |   19 +++++++++++++++----
 3 files changed, 28 insertions(+), 7 deletions(-)

Index: linux-2.6/arch/x86/kernel/setup.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/setup.c
+++ linux-2.6/arch/x86/kernel/setup.c
@@ -522,19 +522,28 @@ static void __init reserve_crashkernel_l
 	unsigned long long low_base = 0, low_size = 0;
 	unsigned long total_low_mem;
 	unsigned long long base;
+	bool auto_set = false;
 	int ret;
 
 	total_low_mem = memblock_mem_size(1UL<<(32-PAGE_SHIFT));
 	ret = parse_crashkernel_low(boot_command_line, total_low_mem,
 						&low_size, &base);
-	if (ret != 0 || low_size <= 0)
-		return;
+	if (ret != 0) {
+		/* swiotlb size and etc 8M */
+		low_size = swiotlb_size_or_default() + (8UL<<20);
+		auto_set = true;
+	} else {
+		/* passed with crashkernel_low=0 ? */
+		if (!low_size)
+			return;
+	}
 
 	low_base = memblock_find_in_range(low_size, (1ULL<<32),
 					low_size, alignment);
 
 	if (!low_base) {
-		pr_info("crashkernel low reservation failed - No suitable area found.\n");
+		if (!auto_set)
+			pr_info("crashkernel low reservation failed - No suitable area found.\n");
 
 		return;
 	}
Index: linux-2.6/include/linux/swiotlb.h
===================================================================
--- linux-2.6.orig/include/linux/swiotlb.h
+++ linux-2.6/include/linux/swiotlb.h
@@ -25,6 +25,7 @@ extern int swiotlb_force;
 extern void swiotlb_init(int verbose);
 int swiotlb_init_with_tbl(char *tlb, unsigned long nslabs, int verbose);
 extern unsigned long swiotlb_nr_tbl(void);
+unsigned long swiotlb_size_or_default(void);
 extern int swiotlb_late_init_with_tbl(char *tlb, unsigned long nslabs);
 
 /*
Index: linux-2.6/lib/swiotlb.c
===================================================================
--- linux-2.6.orig/lib/swiotlb.c
+++ linux-2.6/lib/swiotlb.c
@@ -105,9 +105,9 @@ setup_io_tlb_npages(char *str)
 	if (!strcmp(str, "force"))
 		swiotlb_force = 1;
 
-	return 1;
+	return 0;
 }
-__setup("swiotlb=", setup_io_tlb_npages);
+early_param("swiotlb", setup_io_tlb_npages);
 /* make io_tlb_overflow tunable too? */
 
 unsigned long swiotlb_nr_tbl(void)
@@ -115,6 +115,18 @@ unsigned long swiotlb_nr_tbl(void)
 	return io_tlb_nslabs;
 }
 EXPORT_SYMBOL_GPL(swiotlb_nr_tbl);
+
+/* default to 64MB */
+#define IO_TLB_DEFAULT_SIZE (64UL<<20)
+unsigned long swiotlb_size_or_default(void)
+{
+	unsigned long size;
+
+	size = io_tlb_nslabs << IO_TLB_SHIFT;
+
+	return size ? size : (IO_TLB_DEFAULT_SIZE);
+}
+
 /* Note that this doesn't work with highmem page */
 static dma_addr_t swiotlb_virt_to_bus(struct device *hwdev,
 				      volatile void *address)
@@ -188,8 +200,7 @@ int __init swiotlb_init_with_tbl(char *t
 void  __init
 swiotlb_init(int verbose)
 {
-	/* default to 64MB */
-	size_t default_size = 64UL<<20;
+	size_t default_size = IO_TLB_DEFAULT_SIZE;
 	unsigned char *vstart;
 	unsigned long bytes;
 

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH v3] x86, kdump: Set crashkernel_low automatically
  2013-03-18 21:25                                                           ` [PATCH v3] " Yinghai Lu
@ 2013-03-18 22:52                                                             ` H. Peter Anvin
  2013-03-18 23:26                                                               ` Yinghai Lu
  0 siblings, 1 reply; 101+ messages in thread
From: H. Peter Anvin @ 2013-03-18 22:52 UTC (permalink / raw)
  To: Yinghai Lu
  Cc: Thomas Gleixner, Ingo Molnar, WANG Chao, Vivek Goyal,
	Eric W. Biederman, linux-kernel

On 03/18/2013 02:25 PM, Yinghai Lu wrote:
> Current code does not set low range for crashkernel if the user
> does not specify that.
> 
> That cause regressions on system that does not support intel_iommu
> properly.
> 
> Chao said that his system does work well on 3.8 without extra parameter.
> even iommu does not work with kdump.
> 
> Set crashkernel_low automatically if the user does not specify that.
> 
> For system that does support IOMMU with kdump properly, user could
> specify crashkernel_low=0 to save that 72M low ram.
> 
> -v3: add swiotlb_size() according to Konrad.
> 
> Reported-by: WANG Chao <chaowang@redhat.com>
> Tested-by: WANG Chao <chaowang@redhat.com>
> Signed-off-by: Yinghai Lu <yinghai@kernel.org>

Can we get a bit more of an explanation instead of "and etc 8M"?  At
least a hint of what kind of objects would go in there...

	-hpa



^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH v3] x86, kdump: Set crashkernel_low automatically
  2013-03-18 22:52                                                             ` H. Peter Anvin
@ 2013-03-18 23:26                                                               ` Yinghai Lu
  2013-03-19  0:27                                                                 ` H. Peter Anvin
  0 siblings, 1 reply; 101+ messages in thread
From: Yinghai Lu @ 2013-03-18 23:26 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: Thomas Gleixner, Ingo Molnar, WANG Chao, Vivek Goyal,
	Eric W. Biederman, linux-kernel

On Mon, Mar 18, 2013 at 3:52 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> On 03/18/2013 02:25 PM, Yinghai Lu wrote:
>> Current code does not set low range for crashkernel if the user
>> does not specify that.
>>
>> That cause regressions on system that does not support intel_iommu
>> properly.
>>
>> Chao said that his system does work well on 3.8 without extra parameter.
>> even iommu does not work with kdump.
>>
>> Set crashkernel_low automatically if the user does not specify that.
>>
>> For system that does support IOMMU with kdump properly, user could
>> specify crashkernel_low=0 to save that 72M low ram.
>>
>> -v3: add swiotlb_size() according to Konrad.
>>
>> Reported-by: WANG Chao <chaowang@redhat.com>
>> Tested-by: WANG Chao <chaowang@redhat.com>
>> Signed-off-by: Yinghai Lu <yinghai@kernel.org>
>
> Can we get a bit more of an explanation instead of "and etc 8M"?  At
> least a hint of what kind of objects would go in there...

now only have:
swiotlb overflow buffer

        v_overflow_buffer = alloc_bootmem_low_pages_nopanic(
                                                PAGE_ALIGN(io_tlb_overflow));

and
     /*
      * When the IOMMU overflows we return a fallback buffer. This
sets the size.
     */
     static unsigned long io_tlb_overflow = 32*1024;

so it is 32K, and I round it to 8M.

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH v3] x86, kdump: Set crashkernel_low automatically
  2013-03-18 23:26                                                               ` Yinghai Lu
@ 2013-03-19  0:27                                                                 ` H. Peter Anvin
  2013-03-19  1:04                                                                   ` [PATCH v4] " Yinghai Lu
  0 siblings, 1 reply; 101+ messages in thread
From: H. Peter Anvin @ 2013-03-19  0:27 UTC (permalink / raw)
  To: Yinghai Lu
  Cc: Thomas Gleixner, Ingo Molnar, WANG Chao, Vivek Goyal,
	Eric W. Biederman, linux-kernel

On 03/18/2013 04:26 PM, Yinghai Lu wrote:
> 
> now only have:
> swiotlb overflow buffer
> 
>         v_overflow_buffer = alloc_bootmem_low_pages_nopanic(
>                                                 PAGE_ALIGN(io_tlb_overflow));
> 
> and
>      /*
>       * When the IOMMU overflows we return a fallback buffer. This
> sets the size.
>      */
>      static unsigned long io_tlb_overflow = 32*1024;
> 
> so it is 32K, and I round it to 8M.
> 

So put that into prose, understandable by someone who hasn't followed
this discussion (say, five years from now), and make that part of the
commit.

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.


^ permalink raw reply	[flat|nested] 101+ messages in thread

* [PATCH v4] x86, kdump: Set crashkernel_low automatically
  2013-03-19  0:27                                                                 ` H. Peter Anvin
@ 2013-03-19  1:04                                                                   ` Yinghai Lu
  2013-03-19 13:33                                                                     ` Vivek Goyal
  0 siblings, 1 reply; 101+ messages in thread
From: Yinghai Lu @ 2013-03-19  1:04 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin
  Cc: WANG Chao, Vivek Goyal, Eric W. Biederman, linux-kernel, Yinghai Lu

Current code does not set low range for crashkernel if the user
does not specify that.

That cause regressions on system that does not support intel_iommu
properly.

Chao said that his system does work well on 3.8 without extra parameter.
even iommu does not work with kdump.

Set crashkernel_low automatically if the user does not specify that.

For system that does support IOMMU with kdump properly, user could
specify crashkernel_low=0 to save that 72M low ram.

-v3: add swiotlb_size() according to Konrad.
-v4: add comments what 8M is for according to hpa.
     also update more crashkernel_low= in kernel-parameters.txt

Reported-by: WANG Chao <chaowang@redhat.com>
Tested-by: WANG Chao <chaowang@redhat.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>

---
 Documentation/kernel-parameters.txt |   15 ++++++++++++---
 arch/x86/kernel/setup.c             |   20 +++++++++++++++++---
 include/linux/swiotlb.h             |    1 +
 lib/swiotlb.c                       |   19 +++++++++++++++----
 4 files changed, 45 insertions(+), 10 deletions(-)

Index: linux-2.6/arch/x86/kernel/setup.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/setup.c
+++ linux-2.6/arch/x86/kernel/setup.c
@@ -521,19 +521,33 @@ static void __init reserve_crashkernel_l
 	unsigned long long low_base = 0, low_size = 0;
 	unsigned long total_low_mem;
 	unsigned long long base;
+	bool auto_set = false;
 	int ret;
 
 	total_low_mem = memblock_mem_size(1UL<<(32-PAGE_SHIFT));
 	ret = parse_crashkernel_low(boot_command_line, total_low_mem,
 						&low_size, &base);
-	if (ret != 0 || low_size <= 0)
-		return;
+	if (ret != 0) {
+		/*
+		 * two parts from lib/swiotlb.c:
+		 *	swiotlb size: user specified with swiotlb= or default.
+		 *	swiotlb overflow buffer: now is hardcoded to 32k,
+		 *		round to 8M to cover more others.
+		 */
+		low_size = swiotlb_size_or_default() + (8UL<<20);
+		auto_set = true;
+	} else {
+		/* passed with crashkernel_low=0 ? */
+		if (!low_size)
+			return;
+	}
 
 	low_base = memblock_find_in_range(low_size, (1ULL<<32),
 					low_size, alignment);
 
 	if (!low_base) {
-		pr_info("crashkernel low reservation failed - No suitable area found.\n");
+		if (!auto_set)
+			pr_info("crashkernel low reservation failed - No suitable area found.\n");
 
 		return;
 	}
Index: linux-2.6/include/linux/swiotlb.h
===================================================================
--- linux-2.6.orig/include/linux/swiotlb.h
+++ linux-2.6/include/linux/swiotlb.h
@@ -25,6 +25,7 @@ extern int swiotlb_force;
 extern void swiotlb_init(int verbose);
 int swiotlb_init_with_tbl(char *tlb, unsigned long nslabs, int verbose);
 extern unsigned long swiotlb_nr_tbl(void);
+unsigned long swiotlb_size_or_default(void);
 extern int swiotlb_late_init_with_tbl(char *tlb, unsigned long nslabs);
 
 /*
Index: linux-2.6/lib/swiotlb.c
===================================================================
--- linux-2.6.orig/lib/swiotlb.c
+++ linux-2.6/lib/swiotlb.c
@@ -105,9 +105,9 @@ setup_io_tlb_npages(char *str)
 	if (!strcmp(str, "force"))
 		swiotlb_force = 1;
 
-	return 1;
+	return 0;
 }
-__setup("swiotlb=", setup_io_tlb_npages);
+early_param("swiotlb", setup_io_tlb_npages);
 /* make io_tlb_overflow tunable too? */
 
 unsigned long swiotlb_nr_tbl(void)
@@ -115,6 +115,18 @@ unsigned long swiotlb_nr_tbl(void)
 	return io_tlb_nslabs;
 }
 EXPORT_SYMBOL_GPL(swiotlb_nr_tbl);
+
+/* default to 64MB */
+#define IO_TLB_DEFAULT_SIZE (64UL<<20)
+unsigned long swiotlb_size_or_default(void)
+{
+	unsigned long size;
+
+	size = io_tlb_nslabs << IO_TLB_SHIFT;
+
+	return size ? size : (IO_TLB_DEFAULT_SIZE);
+}
+
 /* Note that this doesn't work with highmem page */
 static dma_addr_t swiotlb_virt_to_bus(struct device *hwdev,
 				      volatile void *address)
@@ -188,8 +200,7 @@ int __init swiotlb_init_with_tbl(char *t
 void  __init
 swiotlb_init(int verbose)
 {
-	/* default to 64MB */
-	size_t default_size = 64UL<<20;
+	size_t default_size = IO_TLB_DEFAULT_SIZE;
 	unsigned char *vstart;
 	unsigned long bytes;
 
Index: linux-2.6/Documentation/kernel-parameters.txt
===================================================================
--- linux-2.6.orig/Documentation/kernel-parameters.txt
+++ linux-2.6/Documentation/kernel-parameters.txt
@@ -596,9 +596,6 @@ bytes respectively. Such letter suffixes
 			is selected automatically. Check
 			Documentation/kdump/kdump.txt for further details.
 
-	crashkernel_low=size[KMG]
-			[KNL, x86] parts under 4G.
-
 	crashkernel=range1:size1[,range2:size2,...][@offset]
 			[KNL] Same as above, but depends on the memory
 			in the running system. The syntax of range is
@@ -606,6 +603,18 @@ bytes respectively. Such letter suffixes
 			a memory unit (amount[KMG]). See also
 			Documentation/kdump/kdump.txt for an example.
 
+	crashkernel_low=size[KMG]
+			[KNL, x86_64] range under 4G. When crashkernel= is
+			passed, kernel allocate physical memory region
+			above 4G, that cause second kernel crash on system
+			that need swiotlb later. Kernel would try to allocate
+			some region below 4G automatically. This one let
+			user to specify own low range under 4G for second
+			kernel instead.
+			0: to disable low allocation on systems that do not
+			need swiotlb, that will save 72M low ram in first
+			kernel.
+
 	cs89x0_dma=	[HW,NET]
 			Format: <dma>
 

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH v4] x86, kdump: Set crashkernel_low automatically
  2013-03-19  1:04                                                                   ` [PATCH v4] " Yinghai Lu
@ 2013-03-19 13:33                                                                     ` Vivek Goyal
  2013-03-19 15:05                                                                       ` [PATCH v5] " Yinghai Lu
  0 siblings, 1 reply; 101+ messages in thread
From: Vivek Goyal @ 2013-03-19 13:33 UTC (permalink / raw)
  To: Yinghai Lu
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, WANG Chao,
	Eric W. Biederman, linux-kernel

On Mon, Mar 18, 2013 at 06:04:08PM -0700, Yinghai Lu wrote:
> Current code does not set low range for crashkernel if the user
> does not specify that.

Hi Yinghai,

While we are modifying changelog, it will also be beneficial to
mention that how did we end up in this situation. Can we mention
changelog little more explanatory, like as follows.

We have now modified crashkernel=X to allocate memory beyong 4G (if
available). And this will cause regression if iommu is not enabled.
Without iommu, swiotlb needs to be setup in first 4G and there is no
low memory available to second kernel.

thanks
Vivek
> 
> That cause regressions on system that does not support intel_iommu
> properly.
> 
> Chao said that his system does work well on 3.8 without extra parameter.
> even iommu does not work with kdump.
> 
> Set crashkernel_low automatically if the user does not specify that.
> 
> For system that does support IOMMU with kdump properly, user could
> specify crashkernel_low=0 to save that 72M low ram.
> 
> -v3: add swiotlb_size() according to Konrad.
> -v4: add comments what 8M is for according to hpa.
>      also update more crashkernel_low= in kernel-parameters.txt
> 
> Reported-by: WANG Chao <chaowang@redhat.com>
> Tested-by: WANG Chao <chaowang@redhat.com>
> Signed-off-by: Yinghai Lu <yinghai@kernel.org>
> 
> ---
>  Documentation/kernel-parameters.txt |   15 ++++++++++++---
>  arch/x86/kernel/setup.c             |   20 +++++++++++++++++---
>  include/linux/swiotlb.h             |    1 +
>  lib/swiotlb.c                       |   19 +++++++++++++++----
>  4 files changed, 45 insertions(+), 10 deletions(-)
> 
> Index: linux-2.6/arch/x86/kernel/setup.c
> ===================================================================
> --- linux-2.6.orig/arch/x86/kernel/setup.c
> +++ linux-2.6/arch/x86/kernel/setup.c
> @@ -521,19 +521,33 @@ static void __init reserve_crashkernel_l
>  	unsigned long long low_base = 0, low_size = 0;
>  	unsigned long total_low_mem;
>  	unsigned long long base;
> +	bool auto_set = false;
>  	int ret;
>  
>  	total_low_mem = memblock_mem_size(1UL<<(32-PAGE_SHIFT));
>  	ret = parse_crashkernel_low(boot_command_line, total_low_mem,
>  						&low_size, &base);
> -	if (ret != 0 || low_size <= 0)
> -		return;
> +	if (ret != 0) {
> +		/*
> +		 * two parts from lib/swiotlb.c:
> +		 *	swiotlb size: user specified with swiotlb= or default.
> +		 *	swiotlb overflow buffer: now is hardcoded to 32k,
> +		 *		round to 8M to cover more others.
> +		 */
> +		low_size = swiotlb_size_or_default() + (8UL<<20);
> +		auto_set = true;
> +	} else {
> +		/* passed with crashkernel_low=0 ? */
> +		if (!low_size)
> +			return;
> +	}
>  
>  	low_base = memblock_find_in_range(low_size, (1ULL<<32),
>  					low_size, alignment);
>  
>  	if (!low_base) {
> -		pr_info("crashkernel low reservation failed - No suitable area found.\n");
> +		if (!auto_set)
> +			pr_info("crashkernel low reservation failed - No suitable area found.\n");
>  
>  		return;
>  	}
> Index: linux-2.6/include/linux/swiotlb.h
> ===================================================================
> --- linux-2.6.orig/include/linux/swiotlb.h
> +++ linux-2.6/include/linux/swiotlb.h
> @@ -25,6 +25,7 @@ extern int swiotlb_force;
>  extern void swiotlb_init(int verbose);
>  int swiotlb_init_with_tbl(char *tlb, unsigned long nslabs, int verbose);
>  extern unsigned long swiotlb_nr_tbl(void);
> +unsigned long swiotlb_size_or_default(void);
>  extern int swiotlb_late_init_with_tbl(char *tlb, unsigned long nslabs);
>  
>  /*
> Index: linux-2.6/lib/swiotlb.c
> ===================================================================
> --- linux-2.6.orig/lib/swiotlb.c
> +++ linux-2.6/lib/swiotlb.c
> @@ -105,9 +105,9 @@ setup_io_tlb_npages(char *str)
>  	if (!strcmp(str, "force"))
>  		swiotlb_force = 1;
>  
> -	return 1;
> +	return 0;
>  }
> -__setup("swiotlb=", setup_io_tlb_npages);
> +early_param("swiotlb", setup_io_tlb_npages);
>  /* make io_tlb_overflow tunable too? */
>  
>  unsigned long swiotlb_nr_tbl(void)
> @@ -115,6 +115,18 @@ unsigned long swiotlb_nr_tbl(void)
>  	return io_tlb_nslabs;
>  }
>  EXPORT_SYMBOL_GPL(swiotlb_nr_tbl);
> +
> +/* default to 64MB */
> +#define IO_TLB_DEFAULT_SIZE (64UL<<20)
> +unsigned long swiotlb_size_or_default(void)
> +{
> +	unsigned long size;
> +
> +	size = io_tlb_nslabs << IO_TLB_SHIFT;
> +
> +	return size ? size : (IO_TLB_DEFAULT_SIZE);
> +}
> +
>  /* Note that this doesn't work with highmem page */
>  static dma_addr_t swiotlb_virt_to_bus(struct device *hwdev,
>  				      volatile void *address)
> @@ -188,8 +200,7 @@ int __init swiotlb_init_with_tbl(char *t
>  void  __init
>  swiotlb_init(int verbose)
>  {
> -	/* default to 64MB */
> -	size_t default_size = 64UL<<20;
> +	size_t default_size = IO_TLB_DEFAULT_SIZE;
>  	unsigned char *vstart;
>  	unsigned long bytes;
>  
> Index: linux-2.6/Documentation/kernel-parameters.txt
> ===================================================================
> --- linux-2.6.orig/Documentation/kernel-parameters.txt
> +++ linux-2.6/Documentation/kernel-parameters.txt
> @@ -596,9 +596,6 @@ bytes respectively. Such letter suffixes
>  			is selected automatically. Check
>  			Documentation/kdump/kdump.txt for further details.
>  
> -	crashkernel_low=size[KMG]
> -			[KNL, x86] parts under 4G.
> -
>  	crashkernel=range1:size1[,range2:size2,...][@offset]
>  			[KNL] Same as above, but depends on the memory
>  			in the running system. The syntax of range is
> @@ -606,6 +603,18 @@ bytes respectively. Such letter suffixes
>  			a memory unit (amount[KMG]). See also
>  			Documentation/kdump/kdump.txt for an example.
>  
> +	crashkernel_low=size[KMG]
> +			[KNL, x86_64] range under 4G. When crashkernel= is
> +			passed, kernel allocate physical memory region
> +			above 4G, that cause second kernel crash on system
> +			that need swiotlb later. Kernel would try to allocate
> +			some region below 4G automatically. This one let
> +			user to specify own low range under 4G for second
> +			kernel instead.
> +			0: to disable low allocation on systems that do not
> +			need swiotlb, that will save 72M low ram in first
> +			kernel.
> +
>  	cs89x0_dma=	[HW,NET]
>  			Format: <dma>
>  

^ permalink raw reply	[flat|nested] 101+ messages in thread

* [PATCH v5] x86, kdump: Set crashkernel_low automatically
  2013-03-19 13:33                                                                     ` Vivek Goyal
@ 2013-03-19 15:05                                                                       ` Yinghai Lu
  2013-03-20 13:08                                                                         ` Vivek Goyal
  0 siblings, 1 reply; 101+ messages in thread
From: Yinghai Lu @ 2013-03-19 15:05 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin
  Cc: WANG Chao, Vivek Goyal, Eric W. Biederman, linux-kernel, Yinghai Lu

Chao said that kdump does does work well on his system on 3.8
without extra parameter, even iommu does not work with kdump.
And now have to append crashkernel_low=Y in first kernel to make
kdump work.

We have now modified crashkernel=X to allocate memory beyong 4G (if
available) and do not allocate low range for crashkernel if the user
does not specify that with crashkernel_low=Y.  This causes regression
if iommu is not enabled.  Without iommu, swiotlb needs to be setup in
first 4G and there is no low memory available to second kernel.

Set crashkernel_low automatically if the user does not specify that.

For system that does support IOMMU with kdump properly, user could
specify crashkernel_low=0 to save that 72M low ram.

-v3: add swiotlb_size() according to Konrad.
-v4: add comments what 8M is for according to hpa.
     also update more crashkernel_low= in kernel-parameters.txt
-v5: update changelog according to Vivek.

Reported-by: WANG Chao <chaowang@redhat.com>
Tested-by: WANG Chao <chaowang@redhat.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>

---
 Documentation/kernel-parameters.txt |   15 ++++++++++++---
 arch/x86/kernel/setup.c             |   20 +++++++++++++++++---
 include/linux/swiotlb.h             |    1 +
 lib/swiotlb.c                       |   19 +++++++++++++++----
 4 files changed, 45 insertions(+), 10 deletions(-)

Index: linux-2.6/arch/x86/kernel/setup.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/setup.c
+++ linux-2.6/arch/x86/kernel/setup.c
@@ -521,19 +521,33 @@ static void __init reserve_crashkernel_l
 	unsigned long long low_base = 0, low_size = 0;
 	unsigned long total_low_mem;
 	unsigned long long base;
+	bool auto_set = false;
 	int ret;
 
 	total_low_mem = memblock_mem_size(1UL<<(32-PAGE_SHIFT));
 	ret = parse_crashkernel_low(boot_command_line, total_low_mem,
 						&low_size, &base);
-	if (ret != 0 || low_size <= 0)
-		return;
+	if (ret != 0) {
+		/*
+		 * two parts from lib/swiotlb.c:
+		 *	swiotlb size: user specified with swiotlb= or default.
+		 *	swiotlb overflow buffer: now is hardcoded to 32k,
+		 *		round to 8M to cover more others.
+		 */
+		low_size = swiotlb_size_or_default() + (8UL<<20);
+		auto_set = true;
+	} else {
+		/* passed with crashkernel_low=0 ? */
+		if (!low_size)
+			return;
+	}
 
 	low_base = memblock_find_in_range(low_size, (1ULL<<32),
 					low_size, alignment);
 
 	if (!low_base) {
-		pr_info("crashkernel low reservation failed - No suitable area found.\n");
+		if (!auto_set)
+			pr_info("crashkernel low reservation failed - No suitable area found.\n");
 
 		return;
 	}
Index: linux-2.6/include/linux/swiotlb.h
===================================================================
--- linux-2.6.orig/include/linux/swiotlb.h
+++ linux-2.6/include/linux/swiotlb.h
@@ -25,6 +25,7 @@ extern int swiotlb_force;
 extern void swiotlb_init(int verbose);
 int swiotlb_init_with_tbl(char *tlb, unsigned long nslabs, int verbose);
 extern unsigned long swiotlb_nr_tbl(void);
+unsigned long swiotlb_size_or_default(void);
 extern int swiotlb_late_init_with_tbl(char *tlb, unsigned long nslabs);
 
 /*
Index: linux-2.6/lib/swiotlb.c
===================================================================
--- linux-2.6.orig/lib/swiotlb.c
+++ linux-2.6/lib/swiotlb.c
@@ -105,9 +105,9 @@ setup_io_tlb_npages(char *str)
 	if (!strcmp(str, "force"))
 		swiotlb_force = 1;
 
-	return 1;
+	return 0;
 }
-__setup("swiotlb=", setup_io_tlb_npages);
+early_param("swiotlb", setup_io_tlb_npages);
 /* make io_tlb_overflow tunable too? */
 
 unsigned long swiotlb_nr_tbl(void)
@@ -115,6 +115,18 @@ unsigned long swiotlb_nr_tbl(void)
 	return io_tlb_nslabs;
 }
 EXPORT_SYMBOL_GPL(swiotlb_nr_tbl);
+
+/* default to 64MB */
+#define IO_TLB_DEFAULT_SIZE (64UL<<20)
+unsigned long swiotlb_size_or_default(void)
+{
+	unsigned long size;
+
+	size = io_tlb_nslabs << IO_TLB_SHIFT;
+
+	return size ? size : (IO_TLB_DEFAULT_SIZE);
+}
+
 /* Note that this doesn't work with highmem page */
 static dma_addr_t swiotlb_virt_to_bus(struct device *hwdev,
 				      volatile void *address)
@@ -188,8 +200,7 @@ int __init swiotlb_init_with_tbl(char *t
 void  __init
 swiotlb_init(int verbose)
 {
-	/* default to 64MB */
-	size_t default_size = 64UL<<20;
+	size_t default_size = IO_TLB_DEFAULT_SIZE;
 	unsigned char *vstart;
 	unsigned long bytes;
 
Index: linux-2.6/Documentation/kernel-parameters.txt
===================================================================
--- linux-2.6.orig/Documentation/kernel-parameters.txt
+++ linux-2.6/Documentation/kernel-parameters.txt
@@ -596,9 +596,6 @@ bytes respectively. Such letter suffixes
 			is selected automatically. Check
 			Documentation/kdump/kdump.txt for further details.
 
-	crashkernel_low=size[KMG]
-			[KNL, x86] parts under 4G.
-
 	crashkernel=range1:size1[,range2:size2,...][@offset]
 			[KNL] Same as above, but depends on the memory
 			in the running system. The syntax of range is
@@ -606,6 +603,18 @@ bytes respectively. Such letter suffixes
 			a memory unit (amount[KMG]). See also
 			Documentation/kdump/kdump.txt for an example.
 
+	crashkernel_low=size[KMG]
+			[KNL, x86_64] range under 4G. When crashkernel= is
+			passed, kernel allocate physical memory region
+			above 4G, that cause second kernel crash on system
+			that need swiotlb later. Kernel would try to allocate
+			some region below 4G automatically. This one let
+			user to specify own low range under 4G for second
+			kernel instead.
+			0: to disable low allocation on systems that do not
+			need swiotlb, that will save 72M low ram in first
+			kernel.
+
 	cs89x0_dma=	[HW,NET]
 			Format: <dma>
 

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH v5] x86, kdump: Set crashkernel_low automatically
  2013-03-19 15:05                                                                       ` [PATCH v5] " Yinghai Lu
@ 2013-03-20 13:08                                                                         ` Vivek Goyal
  2013-03-20 15:53                                                                           ` Yinghai Lu
  0 siblings, 1 reply; 101+ messages in thread
From: Vivek Goyal @ 2013-03-20 13:08 UTC (permalink / raw)
  To: Yinghai Lu
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, WANG Chao,
	Eric W. Biederman, linux-kernel

On Tue, Mar 19, 2013 at 08:05:26AM -0700, Yinghai Lu wrote:
> Chao said that kdump does does work well on his system on 3.8
> without extra parameter, even iommu does not work with kdump.
> And now have to append crashkernel_low=Y in first kernel to make
> kdump work.
> 
> We have now modified crashkernel=X to allocate memory beyong 4G (if
> available) and do not allocate low range for crashkernel if the user
> does not specify that with crashkernel_low=Y.  This causes regression
> if iommu is not enabled.  Without iommu, swiotlb needs to be setup in
> first 4G and there is no low memory available to second kernel.
> 
> Set crashkernel_low automatically if the user does not specify that.
> 
> For system that does support IOMMU with kdump properly, user could
> specify crashkernel_low=0 to save that 72M low ram.

Hi Yinghai,

Have a general question about crashkernel_low. Why does it need to
show up as "Crash kernel low" in /proc/iomem. Will it not be better
that all memory reserved for crashkernel (whether high or low), shows
as "Crash Kernel" and let kexec-tools decide whether to load kernel
high or low etc.

IOW, there should not be any need to differentiate between "Crash kernel"
and "Crash kernel low". There are address ranges associated and looking
at addresses it is obivious that certain memory is below 4G.

Thanks
Vivek
 
> 
> -v3: add swiotlb_size() according to Konrad.
> -v4: add comments what 8M is for according to hpa.
>      also update more crashkernel_low= in kernel-parameters.txt
> -v5: update changelog according to Vivek.
> 
> Reported-by: WANG Chao <chaowang@redhat.com>
> Tested-by: WANG Chao <chaowang@redhat.com>
> Signed-off-by: Yinghai Lu <yinghai@kernel.org>
> 
> ---
>  Documentation/kernel-parameters.txt |   15 ++++++++++++---
>  arch/x86/kernel/setup.c             |   20 +++++++++++++++++---
>  include/linux/swiotlb.h             |    1 +
>  lib/swiotlb.c                       |   19 +++++++++++++++----
>  4 files changed, 45 insertions(+), 10 deletions(-)
> 
> Index: linux-2.6/arch/x86/kernel/setup.c
> ===================================================================
> --- linux-2.6.orig/arch/x86/kernel/setup.c
> +++ linux-2.6/arch/x86/kernel/setup.c
> @@ -521,19 +521,33 @@ static void __init reserve_crashkernel_l
>  	unsigned long long low_base = 0, low_size = 0;
>  	unsigned long total_low_mem;
>  	unsigned long long base;
> +	bool auto_set = false;
>  	int ret;
>  
>  	total_low_mem = memblock_mem_size(1UL<<(32-PAGE_SHIFT));
>  	ret = parse_crashkernel_low(boot_command_line, total_low_mem,
>  						&low_size, &base);
> -	if (ret != 0 || low_size <= 0)
> -		return;
> +	if (ret != 0) {
> +		/*
> +		 * two parts from lib/swiotlb.c:
> +		 *	swiotlb size: user specified with swiotlb= or default.
> +		 *	swiotlb overflow buffer: now is hardcoded to 32k,
> +		 *		round to 8M to cover more others.
> +		 */
> +		low_size = swiotlb_size_or_default() + (8UL<<20);
> +		auto_set = true;
> +	} else {
> +		/* passed with crashkernel_low=0 ? */
> +		if (!low_size)
> +			return;
> +	}
>  
>  	low_base = memblock_find_in_range(low_size, (1ULL<<32),
>  					low_size, alignment);
>  
>  	if (!low_base) {
> -		pr_info("crashkernel low reservation failed - No suitable area found.\n");
> +		if (!auto_set)
> +			pr_info("crashkernel low reservation failed - No suitable area found.\n");
>  
>  		return;
>  	}
> Index: linux-2.6/include/linux/swiotlb.h
> ===================================================================
> --- linux-2.6.orig/include/linux/swiotlb.h
> +++ linux-2.6/include/linux/swiotlb.h
> @@ -25,6 +25,7 @@ extern int swiotlb_force;
>  extern void swiotlb_init(int verbose);
>  int swiotlb_init_with_tbl(char *tlb, unsigned long nslabs, int verbose);
>  extern unsigned long swiotlb_nr_tbl(void);
> +unsigned long swiotlb_size_or_default(void);
>  extern int swiotlb_late_init_with_tbl(char *tlb, unsigned long nslabs);
>  
>  /*
> Index: linux-2.6/lib/swiotlb.c
> ===================================================================
> --- linux-2.6.orig/lib/swiotlb.c
> +++ linux-2.6/lib/swiotlb.c
> @@ -105,9 +105,9 @@ setup_io_tlb_npages(char *str)
>  	if (!strcmp(str, "force"))
>  		swiotlb_force = 1;
>  
> -	return 1;
> +	return 0;
>  }
> -__setup("swiotlb=", setup_io_tlb_npages);
> +early_param("swiotlb", setup_io_tlb_npages);
>  /* make io_tlb_overflow tunable too? */
>  
>  unsigned long swiotlb_nr_tbl(void)
> @@ -115,6 +115,18 @@ unsigned long swiotlb_nr_tbl(void)
>  	return io_tlb_nslabs;
>  }
>  EXPORT_SYMBOL_GPL(swiotlb_nr_tbl);
> +
> +/* default to 64MB */
> +#define IO_TLB_DEFAULT_SIZE (64UL<<20)
> +unsigned long swiotlb_size_or_default(void)
> +{
> +	unsigned long size;
> +
> +	size = io_tlb_nslabs << IO_TLB_SHIFT;
> +
> +	return size ? size : (IO_TLB_DEFAULT_SIZE);
> +}
> +
>  /* Note that this doesn't work with highmem page */
>  static dma_addr_t swiotlb_virt_to_bus(struct device *hwdev,
>  				      volatile void *address)
> @@ -188,8 +200,7 @@ int __init swiotlb_init_with_tbl(char *t
>  void  __init
>  swiotlb_init(int verbose)
>  {
> -	/* default to 64MB */
> -	size_t default_size = 64UL<<20;
> +	size_t default_size = IO_TLB_DEFAULT_SIZE;
>  	unsigned char *vstart;
>  	unsigned long bytes;
>  
> Index: linux-2.6/Documentation/kernel-parameters.txt
> ===================================================================
> --- linux-2.6.orig/Documentation/kernel-parameters.txt
> +++ linux-2.6/Documentation/kernel-parameters.txt
> @@ -596,9 +596,6 @@ bytes respectively. Such letter suffixes
>  			is selected automatically. Check
>  			Documentation/kdump/kdump.txt for further details.
>  
> -	crashkernel_low=size[KMG]
> -			[KNL, x86] parts under 4G.
> -
>  	crashkernel=range1:size1[,range2:size2,...][@offset]
>  			[KNL] Same as above, but depends on the memory
>  			in the running system. The syntax of range is
> @@ -606,6 +603,18 @@ bytes respectively. Such letter suffixes
>  			a memory unit (amount[KMG]). See also
>  			Documentation/kdump/kdump.txt for an example.
>  
> +	crashkernel_low=size[KMG]
> +			[KNL, x86_64] range under 4G. When crashkernel= is
> +			passed, kernel allocate physical memory region
> +			above 4G, that cause second kernel crash on system
> +			that need swiotlb later. Kernel would try to allocate
> +			some region below 4G automatically. This one let
> +			user to specify own low range under 4G for second
> +			kernel instead.
> +			0: to disable low allocation on systems that do not
> +			need swiotlb, that will save 72M low ram in first
> +			kernel.
> +
>  	cs89x0_dma=	[HW,NET]
>  			Format: <dma>
>  

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH v5] x86, kdump: Set crashkernel_low automatically
  2013-03-20 13:08                                                                         ` Vivek Goyal
@ 2013-03-20 15:53                                                                           ` Yinghai Lu
  2013-03-20 16:03                                                                             ` Vivek Goyal
  0 siblings, 1 reply; 101+ messages in thread
From: Yinghai Lu @ 2013-03-20 15:53 UTC (permalink / raw)
  To: Vivek Goyal
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, WANG Chao,
	Eric W. Biederman, linux-kernel

On Wed, Mar 20, 2013 at 6:08 AM, Vivek Goyal <vgoyal@redhat.com> wrote:

> Have a general question about crashkernel_low. Why does it need to
> show up as "Crash kernel low" in /proc/iomem. Will it not be better
> that all memory reserved for crashkernel (whether high or low), shows
> as "Crash Kernel" and let kexec-tools decide whether to load kernel
> high or low etc.
>
> IOW, there should not be any need to differentiate between "Crash kernel"
> and "Crash kernel low". There are address ranges associated and looking
> at addresses it is obivious that certain memory is below 4G.

yes. it is doable.
but
1. will need to add more code to expand parse_iomem_single to handle
multiple "Crash kernel" in kexec-tools.
2. also we already have "crashkernel_low=" in command line, so it is
good to keep them consistent in /proc/iomem.

Thanks

Yinghai

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH v5] x86, kdump: Set crashkernel_low automatically
  2013-03-20 15:53                                                                           ` Yinghai Lu
@ 2013-03-20 16:03                                                                             ` Vivek Goyal
  2013-03-20 16:21                                                                               ` Yinghai Lu
  0 siblings, 1 reply; 101+ messages in thread
From: Vivek Goyal @ 2013-03-20 16:03 UTC (permalink / raw)
  To: Yinghai Lu
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, WANG Chao,
	Eric W. Biederman, linux-kernel

On Wed, Mar 20, 2013 at 08:53:29AM -0700, Yinghai Lu wrote:
> On Wed, Mar 20, 2013 at 6:08 AM, Vivek Goyal <vgoyal@redhat.com> wrote:
> 
> > Have a general question about crashkernel_low. Why does it need to
> > show up as "Crash kernel low" in /proc/iomem. Will it not be better
> > that all memory reserved for crashkernel (whether high or low), shows
> > as "Crash Kernel" and let kexec-tools decide whether to load kernel
> > high or low etc.
> >
> > IOW, there should not be any need to differentiate between "Crash kernel"
> > and "Crash kernel low". There are address ranges associated and looking
> > at addresses it is obivious that certain memory is below 4G.
> 
> yes. it is doable.
> but
> 1. will need to add more code to expand parse_iomem_single to handle
> multiple "Crash kernel" in kexec-tools.
> 2. also we already have "crashkernel_low=" in command line, so it is
> good to keep them consistent in /proc/iomem.

I think command line and /proc/iomem output are very different.
crashkernel_low is just enforcing that reserve it below 4G and memory
type still remains "Crash Kernel".

So to me, /proc/iomem is showing ranges and memory type and both the
memory types should be "Crash Kernel".

IMHO, we should add code in kexec-tools to deal with it (multiple
entries for memory type "Crash Kernel"), instead of especial casing
"Crash Kernel Low". Who knows down the line we end up reserving more
crash kernel memory which is not contiguous. Keeping all reserved
memory of same type will help then.

Thanks
Vivek

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH v5] x86, kdump: Set crashkernel_low automatically
  2013-03-20 16:03                                                                             ` Vivek Goyal
@ 2013-03-20 16:21                                                                               ` Yinghai Lu
  2013-03-20 16:31                                                                                 ` Vivek Goyal
  0 siblings, 1 reply; 101+ messages in thread
From: Yinghai Lu @ 2013-03-20 16:21 UTC (permalink / raw)
  To: Vivek Goyal, Simon Horman
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, WANG Chao,
	Eric W. Biederman, linux-kernel

On Wed, Mar 20, 2013 at 9:03 AM, Vivek Goyal <vgoyal@redhat.com> wrote:
> On Wed, Mar 20, 2013 at 08:53:29AM -0700, Yinghai Lu wrote:
>> On Wed, Mar 20, 2013 at 6:08 AM, Vivek Goyal <vgoyal@redhat.com> wrote:
>>
>> > Have a general question about crashkernel_low. Why does it need to
>> > show up as "Crash kernel low" in /proc/iomem. Will it not be better
>> > that all memory reserved for crashkernel (whether high or low), shows
>> > as "Crash Kernel" and let kexec-tools decide whether to load kernel
>> > high or low etc.
>> >
>> > IOW, there should not be any need to differentiate between "Crash kernel"
>> > and "Crash kernel low". There are address ranges associated and looking
>> > at addresses it is obivious that certain memory is below 4G.
>>
>> yes. it is doable.
>> but
>> 1. will need to add more code to expand parse_iomem_single to handle
>> multiple "Crash kernel" in kexec-tools.
>> 2. also we already have "crashkernel_low=" in command line, so it is
>> good to keep them consistent in /proc/iomem.
>
> I think command line and /proc/iomem output are very different.
> crashkernel_low is just enforcing that reserve it below 4G and memory
> type still remains "Crash Kernel".
>
> So to me, /proc/iomem is showing ranges and memory type and both the
> memory types should be "Crash Kernel".
>
> IMHO, we should add code in kexec-tools to deal with it (multiple
> entries for memory type "Crash Kernel"), instead of especial casing
> "Crash Kernel Low". Who knows down the line we end up reserving more
> crash kernel memory which is not contiguous. Keeping all reserved
> memory of same type will help then.

ok.

Need to fix kexec-tools at first, and the drop Low in kernel.

Before v3.9 and kexec-tools 2.0.4?

Thanks

Yinghai

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH v5] x86, kdump: Set crashkernel_low automatically
  2013-03-20 16:21                                                                               ` Yinghai Lu
@ 2013-03-20 16:31                                                                                 ` Vivek Goyal
  2013-03-20 19:22                                                                                   ` [PATCH] kexec: use Crash kernel for Crash kernel low Yinghai Lu
  0 siblings, 1 reply; 101+ messages in thread
From: Vivek Goyal @ 2013-03-20 16:31 UTC (permalink / raw)
  To: Yinghai Lu
  Cc: Simon Horman, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	WANG Chao, Eric W. Biederman, linux-kernel

On Wed, Mar 20, 2013 at 09:21:31AM -0700, Yinghai Lu wrote:
> On Wed, Mar 20, 2013 at 9:03 AM, Vivek Goyal <vgoyal@redhat.com> wrote:
> > On Wed, Mar 20, 2013 at 08:53:29AM -0700, Yinghai Lu wrote:
> >> On Wed, Mar 20, 2013 at 6:08 AM, Vivek Goyal <vgoyal@redhat.com> wrote:
> >>
> >> > Have a general question about crashkernel_low. Why does it need to
> >> > show up as "Crash kernel low" in /proc/iomem. Will it not be better
> >> > that all memory reserved for crashkernel (whether high or low), shows
> >> > as "Crash Kernel" and let kexec-tools decide whether to load kernel
> >> > high or low etc.
> >> >
> >> > IOW, there should not be any need to differentiate between "Crash kernel"
> >> > and "Crash kernel low". There are address ranges associated and looking
> >> > at addresses it is obivious that certain memory is below 4G.
> >>
> >> yes. it is doable.
> >> but
> >> 1. will need to add more code to expand parse_iomem_single to handle
> >> multiple "Crash kernel" in kexec-tools.
> >> 2. also we already have "crashkernel_low=" in command line, so it is
> >> good to keep them consistent in /proc/iomem.
> >
> > I think command line and /proc/iomem output are very different.
> > crashkernel_low is just enforcing that reserve it below 4G and memory
> > type still remains "Crash Kernel".
> >
> > So to me, /proc/iomem is showing ranges and memory type and both the
> > memory types should be "Crash Kernel".
> >
> > IMHO, we should add code in kexec-tools to deal with it (multiple
> > entries for memory type "Crash Kernel"), instead of especial casing
> > "Crash Kernel Low". Who knows down the line we end up reserving more
> > crash kernel memory which is not contiguous. Keeping all reserved
> > memory of same type will help then.
> 
> ok.
> 
> Need to fix kexec-tools at first, and the drop Low in kernel.
> 
> Before v3.9 and kexec-tools 2.0.4?

I think so. We need to do this in 3.9 otherwise it becomes another
backward compatibility issue.

Thanks
Vivek

^ permalink raw reply	[flat|nested] 101+ messages in thread

* [PATCH] kexec: use Crash kernel for Crash kernel low
  2013-03-20 16:31                                                                                 ` Vivek Goyal
@ 2013-03-20 19:22                                                                                   ` Yinghai Lu
  2013-03-25 19:42                                                                                     ` Vivek Goyal
  0 siblings, 1 reply; 101+ messages in thread
From: Yinghai Lu @ 2013-03-20 19:22 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin
  Cc: WANG Chao, Vivek Goyal, Eric W. Biederman, linux-kernel, Yinghai Lu

We can extend kexec-tools to support multiple "Crash kernel" in /proc/iomem
instead.

So we can use "Crash kernel" instead of "Crash kernel low" in /proc/iomem.

Suggested-by: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>

---
 kernel/kexec.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux-2.6/kernel/kexec.c
===================================================================
--- linux-2.6.orig/kernel/kexec.c
+++ linux-2.6/kernel/kexec.c
@@ -55,7 +55,7 @@ struct resource crashk_res = {
 	.flags = IORESOURCE_BUSY | IORESOURCE_MEM
 };
 struct resource crashk_low_res = {
-	.name  = "Crash kernel low",
+	.name  = "Crash kernel",
 	.start = 0,
 	.end   = 0,
 	.flags = IORESOURCE_BUSY | IORESOURCE_MEM

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH] kexec: use Crash kernel for Crash kernel low
  2013-03-20 19:22                                                                                   ` [PATCH] kexec: use Crash kernel for Crash kernel low Yinghai Lu
@ 2013-03-25 19:42                                                                                     ` Vivek Goyal
  2013-03-25 21:50                                                                                       ` Yinghai Lu
  0 siblings, 1 reply; 101+ messages in thread
From: Vivek Goyal @ 2013-03-25 19:42 UTC (permalink / raw)
  To: Yinghai Lu
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, WANG Chao,
	Eric W. Biederman, linux-kernel

On Wed, Mar 20, 2013 at 12:22:09PM -0700, Yinghai Lu wrote:
> We can extend kexec-tools to support multiple "Crash kernel" in /proc/iomem
> instead.
> 
> So we can use "Crash kernel" instead of "Crash kernel low" in /proc/iomem.
> 
> Suggested-by: Vivek Goyal <vgoyal@redhat.com>
> Signed-off-by: Yinghai Lu <yinghai@kernel.org>

Hi Yinghai,

This patch along with second version of kexec-tools patch works for me.
I had a small concern.

- Older version of kexec-tools do not work when multiple "Crash Kernel"
  entries show up in /proc/iomem. They error out with following.

Memory for crashkernel is not reserved
Please reserve memory by passing "crashkernel=X@Y" parameter to the kernel

I am assuming that crashkernel=X changes will break older kexec-tools
anyway on most of the machines (As it reserves memory as high as possible
by default) and older kexec-tools will not be able to load kernel that
high.

So it is a forgone conclusion that these new kernel changes to 
crashkernel=X in 3.9 are incompatible with older kexec-tools and one
needs to upgrade kexec-tools.

Other syntax of crashkernel=X@Y will continue to work though.

Thanks
Vivek

> 
> ---
>  kernel/kexec.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> Index: linux-2.6/kernel/kexec.c
> ===================================================================
> --- linux-2.6.orig/kernel/kexec.c
> +++ linux-2.6/kernel/kexec.c
> @@ -55,7 +55,7 @@ struct resource crashk_res = {
>  	.flags = IORESOURCE_BUSY | IORESOURCE_MEM
>  };
>  struct resource crashk_low_res = {
> -	.name  = "Crash kernel low",
> +	.name  = "Crash kernel",
>  	.start = 0,
>  	.end   = 0,
>  	.flags = IORESOURCE_BUSY | IORESOURCE_MEM

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH] kexec: use Crash kernel for Crash kernel low
  2013-03-25 19:42                                                                                     ` Vivek Goyal
@ 2013-03-25 21:50                                                                                       ` Yinghai Lu
  2013-03-26 18:14                                                                                         ` Vivek Goyal
  0 siblings, 1 reply; 101+ messages in thread
From: Yinghai Lu @ 2013-03-25 21:50 UTC (permalink / raw)
  To: Vivek Goyal
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, WANG Chao,
	Eric W. Biederman, linux-kernel

On Mon, Mar 25, 2013 at 12:42 PM, Vivek Goyal <vgoyal@redhat.com> wrote:
> So it is a forgone conclusion that these new kernel changes to
> crashkernel=X in 3.9 are incompatible with older kexec-tools and one
> needs to upgrade kexec-tools.

I thought that you and hpa all agreed that user need to update kexec-tools with
new kernel v3.9. It that still right?

Thanks

Yinghai

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH] kexec: use Crash kernel for Crash kernel low
  2013-03-25 21:50                                                                                       ` Yinghai Lu
@ 2013-03-26 18:14                                                                                         ` Vivek Goyal
  2013-04-01 13:34                                                                                           ` Vivek Goyal
  0 siblings, 1 reply; 101+ messages in thread
From: Vivek Goyal @ 2013-03-26 18:14 UTC (permalink / raw)
  To: Yinghai Lu, H. Peter Anvin
  Cc: Thomas Gleixner, Ingo Molnar, WANG Chao, Eric W. Biederman, linux-kernel

On Mon, Mar 25, 2013 at 02:50:18PM -0700, Yinghai Lu wrote:
> On Mon, Mar 25, 2013 at 12:42 PM, Vivek Goyal <vgoyal@redhat.com> wrote:
> > So it is a forgone conclusion that these new kernel changes to
> > crashkernel=X in 3.9 are incompatible with older kexec-tools and one
> > needs to upgrade kexec-tools.
> 
> I thought that you and hpa all agreed that user need to update kexec-tools with
> new kernel v3.9. It that still right?

I can update kexec-tools and I don't have problems with that. I am only
concerned about some xyz user complaining that new kernel stopped working
with old kexec-tools and then possibly face the rant from Linus about
breaking user space. :-)

To me we could maintain backward compatibility by retaining the existing
behavior of crashkernle=X. That is  look for specificied memory below
896M first and then go higher.

And hide new semantics behind new kernel parameters or by extending
existing parameter (say crashkernel=X:search_high_first) to specify how
to search for reserved memory.

In both the cases we should probably retain the logic of auto reserving
low memory for software iotlb and let user opt out if there is no need.

So we don't have a strong reason that why we should break existing
kexec-tools. So I would prefer not to break it.

But I think this is hpa's decision.

Thanks
Vivek

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH] kexec: use Crash kernel for Crash kernel low
  2013-03-26 18:14                                                                                         ` Vivek Goyal
@ 2013-04-01 13:34                                                                                           ` Vivek Goyal
  2013-04-01 18:33                                                                                             ` H. Peter Anvin
  0 siblings, 1 reply; 101+ messages in thread
From: Vivek Goyal @ 2013-04-01 13:34 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: Thomas Gleixner, Ingo Molnar, WANG Chao, Eric W. Biederman,
	linux-kernel, Yinghai Lu

On Tue, Mar 26, 2013 at 02:14:18PM -0400, Vivek Goyal wrote:
> On Mon, Mar 25, 2013 at 02:50:18PM -0700, Yinghai Lu wrote:
> > On Mon, Mar 25, 2013 at 12:42 PM, Vivek Goyal <vgoyal@redhat.com> wrote:
> > > So it is a forgone conclusion that these new kernel changes to
> > > crashkernel=X in 3.9 are incompatible with older kexec-tools and one
> > > needs to upgrade kexec-tools.
> > 
> > I thought that you and hpa all agreed that user need to update kexec-tools with
> > new kernel v3.9. It that still right?
> 
> I can update kexec-tools and I don't have problems with that. I am only
> concerned about some xyz user complaining that new kernel stopped working
> with old kexec-tools and then possibly face the rant from Linus about
> breaking user space. :-)
> 
> To me we could maintain backward compatibility by retaining the existing
> behavior of crashkernle=X. That is  look for specificied memory below
> 896M first and then go higher.
> 
> And hide new semantics behind new kernel parameters or by extending
> existing parameter (say crashkernel=X:search_high_first) to specify how
> to search for reserved memory.
> 
> In both the cases we should probably retain the logic of auto reserving
> low memory for software iotlb and let user opt out if there is no need.
> 
> So we don't have a strong reason that why we should break existing
> kexec-tools. So I would prefer not to break it.
> 
> But I think this is hpa's decision.

hpa,

ping. Any thoughts on this?

Thanks
Vivek

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH] kexec: use Crash kernel for Crash kernel low
  2013-04-01 13:34                                                                                           ` Vivek Goyal
@ 2013-04-01 18:33                                                                                             ` H. Peter Anvin
  2013-04-01 19:26                                                                                               ` Vivek Goyal
  0 siblings, 1 reply; 101+ messages in thread
From: H. Peter Anvin @ 2013-04-01 18:33 UTC (permalink / raw)
  To: Vivek Goyal
  Cc: Thomas Gleixner, Ingo Molnar, WANG Chao, Eric W. Biederman,
	linux-kernel, Yinghai Lu

On 04/01/2013 06:34 AM, Vivek Goyal wrote:
> On Tue, Mar 26, 2013 at 02:14:18PM -0400, Vivek Goyal wrote:
>> On Mon, Mar 25, 2013 at 02:50:18PM -0700, Yinghai Lu wrote:
>>> On Mon, Mar 25, 2013 at 12:42 PM, Vivek Goyal <vgoyal@redhat.com> wrote:
>>>> So it is a forgone conclusion that these new kernel changes to
>>>> crashkernel=X in 3.9 are incompatible with older kexec-tools and one
>>>> needs to upgrade kexec-tools.
>>>
>>> I thought that you and hpa all agreed that user need to update kexec-tools with
>>> new kernel v3.9. It that still right?
>>
>> I can update kexec-tools and I don't have problems with that. I am only
>> concerned about some xyz user complaining that new kernel stopped working
>> with old kexec-tools and then possibly face the rant from Linus about
>> breaking user space. :-)
>>
>> To me we could maintain backward compatibility by retaining the existing
>> behavior of crashkernle=X. That is  look for specificied memory below
>> 896M first and then go higher.
>>
>> And hide new semantics behind new kernel parameters or by extending
>> existing parameter (say crashkernel=X:search_high_first) to specify how
>> to search for reserved memory.
>>
>> In both the cases we should probably retain the logic of auto reserving
>> low memory for software iotlb and let user opt out if there is no need.
>>
>> So we don't have a strong reason that why we should break existing
>> kexec-tools. So I would prefer not to break it.
>>
>> But I think this is hpa's decision.
> 
> hpa,
> 
> ping. Any thoughts on this?

Pardon me while I retch.  The whole kdump dependency mess is making me
sick to my stomach.

The fundamental problem you have is that the user has to take an action
that doesn't make any sense, because there isn't any sane method to
backflow the requirements from the crashkernel to the command line.

The only way I can think how to deal with that in a sane way that
doesn't require that the user has to understand a whole bunch of things
about their system that no user should ever have to be burdened with is
to have the packaging system feed back information about the crashkernel
and kexec-tools that will be used.  That interface probably needs
serious architecting.

I wouldn't object to crashkernel=<size>,<option>,<option>... being the
format for that and it has the plus that it doesn't break less.  So
something like "crashkernel=800M,high" (:search_high_first is
inconsistent with other options and completely pointlessly wordy... this
isn't Multics, and the command line space is a limited resource) would
make sense.

However, I really strongly suggest you work on a mechanism to take the
information about the crashkernel and utilities that the kernel can't
know and feed it into the bootloader configuration.  This can be as
simple as a set of scripts.

	-hpa


^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH] kexec: use Crash kernel for Crash kernel low
  2013-04-01 18:33                                                                                             ` H. Peter Anvin
@ 2013-04-01 19:26                                                                                               ` Vivek Goyal
  2013-04-01 20:47                                                                                                 ` H. Peter Anvin
  0 siblings, 1 reply; 101+ messages in thread
From: Vivek Goyal @ 2013-04-01 19:26 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: Thomas Gleixner, Ingo Molnar, WANG Chao, Eric W. Biederman,
	linux-kernel, Yinghai Lu

On Mon, Apr 01, 2013 at 11:33:13AM -0700, H. Peter Anvin wrote:
> On 04/01/2013 06:34 AM, Vivek Goyal wrote:
> > On Tue, Mar 26, 2013 at 02:14:18PM -0400, Vivek Goyal wrote:
> >> On Mon, Mar 25, 2013 at 02:50:18PM -0700, Yinghai Lu wrote:
> >>> On Mon, Mar 25, 2013 at 12:42 PM, Vivek Goyal <vgoyal@redhat.com> wrote:
> >>>> So it is a forgone conclusion that these new kernel changes to
> >>>> crashkernel=X in 3.9 are incompatible with older kexec-tools and one
> >>>> needs to upgrade kexec-tools.
> >>>
> >>> I thought that you and hpa all agreed that user need to update kexec-tools with
> >>> new kernel v3.9. It that still right?
> >>
> >> I can update kexec-tools and I don't have problems with that. I am only
> >> concerned about some xyz user complaining that new kernel stopped working
> >> with old kexec-tools and then possibly face the rant from Linus about
> >> breaking user space. :-)
> >>
> >> To me we could maintain backward compatibility by retaining the existing
> >> behavior of crashkernle=X. That is  look for specificied memory below
> >> 896M first and then go higher.
> >>
> >> And hide new semantics behind new kernel parameters or by extending
> >> existing parameter (say crashkernel=X:search_high_first) to specify how
> >> to search for reserved memory.
> >>
> >> In both the cases we should probably retain the logic of auto reserving
> >> low memory for software iotlb and let user opt out if there is no need.
> >>
> >> So we don't have a strong reason that why we should break existing
> >> kexec-tools. So I would prefer not to break it.
> >>
> >> But I think this is hpa's decision.
> > 
> > hpa,
> > 
> > ping. Any thoughts on this?
> 
> Pardon me while I retch.  The whole kdump dependency mess is making me
> sick to my stomach.
> 
> The fundamental problem you have is that the user has to take an action
> that doesn't make any sense, because there isn't any sane method to
> backflow the requirements from the crashkernel to the command line.
> 
> The only way I can think how to deal with that in a sane way that
> doesn't require that the user has to understand a whole bunch of things
> about their system that no user should ever have to be burdened with is
> to have the packaging system feed back information about the crashkernel
> and kexec-tools that will be used.  That interface probably needs
> serious architecting.
> 
> I wouldn't object to crashkernel=<size>,<option>,<option>... being the
> format for that and it has the plus that it doesn't break less.  So
> something like "crashkernel=800M,high" (:search_high_first is
> inconsistent with other options and completely pointlessly wordy... this
> isn't Multics, and the command line space is a limited resource) would
> make sense.
> 
> However, I really strongly suggest you work on a mechanism to take the
> information about the crashkernel and utilities that the kernel can't
> know and feed it into the bootloader configuration.  This can be as
> simple as a set of scripts.

Hi Peter,

I agree that this dependency on crashkernel is creating lots of problems
and there should be a better way to manage it.

Sorry, but I did not fully understand your suggestion on how to handle the
problem. IIUC, you are suggesting that kexec-tools has the memory
requirements and when that package installs, it should automatically
update boot loader command line to communicate that requirement to kernel?
Or are you suggesting something else entirely.

Where to reserve is not entirely tied to kexec-tools version. It also
depends on the environment and run time user options. 

For example kernel image being loaded and entry point selected. So if one
decides to load take 32bit entry point of bzImage then memory has to be
reserved in first 4G (despite the fact that kexec-tools is able to load 64bit
bzImage and handle higher reserved ranges).

Also whether to reserve memory for software iotlb will depend on whether
we have chosen to enable iommu in second kernel or not.

So sorting out all the memory reservation requirements based on
kexec-tools version and during installation time alone might not work.

To make user's life easier, we can probably modify "kdump" service and
provide another option which can calculate the right crashkernel= command
line option based on user selected option and system environment and
display it to user (or possibly propogate to bootloader command line and
system is rebooted).

All this will only address the issue of where to reserve memory. It will
still not solve the issue of how much memory to reserve. We have no way
to know. It is all heuristics.

crashkernel=<size>,<option>,<option>.. and crashkernel=800M,high sound
good to me. 

So atleast for 3.9 kernel, shall we hide new semantics behind
crashkernel=XM,high and by default crashkernel=XM tries to emulate
crashkernel=XM,low to retain backward compatibility?

Thanks
Vivek

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH] kexec: use Crash kernel for Crash kernel low
  2013-04-01 19:26                                                                                               ` Vivek Goyal
@ 2013-04-01 20:47                                                                                                 ` H. Peter Anvin
  2013-04-01 21:10                                                                                                   ` Yinghai Lu
  2013-04-02 13:30                                                                                                   ` Vivek Goyal
  0 siblings, 2 replies; 101+ messages in thread
From: H. Peter Anvin @ 2013-04-01 20:47 UTC (permalink / raw)
  To: Vivek Goyal
  Cc: Thomas Gleixner, Ingo Molnar, WANG Chao, Eric W. Biederman,
	linux-kernel, Yinghai Lu

On 04/01/2013 12:26 PM, Vivek Goyal wrote:
> 
> Hi Peter,
> 
> I agree that this dependency on crashkernel is creating lots of problems
> and there should be a better way to manage it.
> 
> Sorry, but I did not fully understand your suggestion on how to handle the
> problem. IIUC, you are suggesting that kexec-tools has the memory
> requirements and when that package installs, it should automatically
> update boot loader command line to communicate that requirement to kernel?
> Or are you suggesting something else entirely.

Yes.  Or rather, kexec-tools should provice a script or utility to
calculate the proper options and let a distribution-specific script add
it to the bootloader configuration.

> Where to reserve is not entirely tied to kexec-tools version. It also
> depends on the environment and run time user options. 

Yes, and the user cannot reasonably be expected to know what that should
be.  You're basically telling the user "guess and pray".

> For example kernel image being loaded and entry point selected. So if one
> decides to load take 32bit entry point of bzImage then memory has to be
> reserved in first 4G (despite the fact that kexec-tools is able to load 64bit
> bzImage and handle higher reserved ranges).
> 
> Also whether to reserve memory for software iotlb will depend on whether
> we have chosen to enable iommu in second kernel or not.
> 
> So sorting out all the memory reservation requirements based on
> kexec-tools version and during installation time alone might not work.
> 
> To make user's life easier, we can probably modify "kdump" service and
> provide another option which can calculate the right crashkernel= command
> line option based on user selected option and system environment and
> display it to user (or possibly propogate to bootloader command line and
> system is rebooted).

Yes, I think we need to so something.

> All this will only address the issue of where to reserve memory. It will
> still not solve the issue of how much memory to reserve. We have no way
> to know. It is all heuristics.

At least heuristics in a script is better than telling the user "guess
and pray".

> crashkernel=<size>,<option>,<option>.. and crashkernel=800M,high sound
> good to me. 
> 
> So atleast for 3.9 kernel, shall we hide new semantics behind
> crashkernel=XM,high and by default crashkernel=XM tries to emulate
> crashkernel=XM,low to retain backward compatibility?

Yes, I suspect so.

	-hpa





^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH] kexec: use Crash kernel for Crash kernel low
  2013-04-01 20:47                                                                                                 ` H. Peter Anvin
@ 2013-04-01 21:10                                                                                                   ` Yinghai Lu
  2013-04-01 22:02                                                                                                     ` H. Peter Anvin
  2013-04-02 13:30                                                                                                   ` Vivek Goyal
  1 sibling, 1 reply; 101+ messages in thread
From: Yinghai Lu @ 2013-04-01 21:10 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: Vivek Goyal, Thomas Gleixner, Ingo Molnar, WANG Chao,
	Eric W. Biederman, Linux Kernel Mailing List

On Mon, Apr 1, 2013 at 1:47 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> On 04/01/2013 12:26 PM, Vivek Goyal wrote:
>
>> crashkernel=<size>,<option>,<option>.. and crashkernel=800M,high sound
>> good to me.
>>
>> So atleast for 3.9 kernel, shall we hide new semantics behind
>> crashkernel=XM,high and by default crashkernel=XM tries to emulate
>> crashkernel=XM,low to retain backward compatibility?
>
> Yes, I suspect so.

current we have:
1. crashkernel=XM
2. crashkernel=XM crashkernel_low=YM

so you want to change to
1. crashkernel=XM,low or crashkernel=XM
2. crashkernel=XM,high
3. crashkernel=XM,high crashkernel=YM,low

looks like you change your mind, now you are agreeing on
some could low and some could be high.

Yinghai

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH] kexec: use Crash kernel for Crash kernel low
  2013-04-01 21:10                                                                                                   ` Yinghai Lu
@ 2013-04-01 22:02                                                                                                     ` H. Peter Anvin
  2013-04-01 22:17                                                                                                       ` Yinghai Lu
  0 siblings, 1 reply; 101+ messages in thread
From: H. Peter Anvin @ 2013-04-01 22:02 UTC (permalink / raw)
  To: Yinghai Lu
  Cc: Vivek Goyal, Thomas Gleixner, Ingo Molnar, WANG Chao,
	Eric W. Biederman, Linux Kernel Mailing List

On 04/01/2013 02:10 PM, Yinghai Lu wrote:
> On Mon, Apr 1, 2013 at 1:47 PM, H. Peter Anvin <hpa@zytor.com> wrote:
>> On 04/01/2013 12:26 PM, Vivek Goyal wrote:
>>
>>> crashkernel=<size>,<option>,<option>.. and crashkernel=800M,high sound
>>> good to me.
>>>
>>> So atleast for 3.9 kernel, shall we hide new semantics behind
>>> crashkernel=XM,high and by default crashkernel=XM tries to emulate
>>> crashkernel=XM,low to retain backward compatibility?
>>
>> Yes, I suspect so.
> 
> current we have:
> 1. crashkernel=XM
> 2. crashkernel=XM crashkernel_low=YM
> 
> so you want to change to
> 1. crashkernel=XM,low or crashkernel=XM
> 2. crashkernel=XM,high
> 3. crashkernel=XM,high crashkernel=YM,low
> 
> looks like you change your mind, now you are agreeing on
> some could low and some could be high.
> 

It sounds that the "never DMA'd to memory" notion requires that we have
some low memory for the iommu, no?

Or am I misunderstanding what you are asking here?

	-hpa



^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH] kexec: use Crash kernel for Crash kernel low
  2013-04-01 22:02                                                                                                     ` H. Peter Anvin
@ 2013-04-01 22:17                                                                                                       ` Yinghai Lu
  2013-04-01 22:20                                                                                                         ` H. Peter Anvin
  0 siblings, 1 reply; 101+ messages in thread
From: Yinghai Lu @ 2013-04-01 22:17 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: Vivek Goyal, Thomas Gleixner, Ingo Molnar, WANG Chao,
	Eric W. Biederman, Linux Kernel Mailing List

On Mon, Apr 1, 2013 at 3:02 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> On 04/01/2013 02:10 PM, Yinghai Lu wrote:
>> On Mon, Apr 1, 2013 at 1:47 PM, H. Peter Anvin <hpa@zytor.com> wrote:

> It sounds that the "never DMA'd to memory" notion requires that we have
> some low memory for the iommu, no?
>
> Or am I misunderstanding what you are asking here?

No. just find where to put second kernel.

When vivek raise the problem at beginning, he suggested
1. try 896M under at first, if it fails, will allocate under 4G, and
if it still fail
    try above 4G.
2. or keep crashkernel=XM, only to low, and add crashkernel_high if someone
    really want it to be high.

and then you said, we should keep consistent to keep all above 4G.

Now Vivek says we should use crashkernel=XM,low and crashkernel=XM,high
, also crashkernel=XM is treated as low.

And his last suggestion is just as his old second suggestion.

I just check the code again, it looks it is easy to change it to support:
1. crashkernel=XM
2. crashkernel_high=XM
3. crashkernel_high=XM crashkernel_low=YM

Yinghai

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH] kexec: use Crash kernel for Crash kernel low
  2013-04-01 22:17                                                                                                       ` Yinghai Lu
@ 2013-04-01 22:20                                                                                                         ` H. Peter Anvin
  2013-04-01 22:40                                                                                                           ` Yinghai Lu
  0 siblings, 1 reply; 101+ messages in thread
From: H. Peter Anvin @ 2013-04-01 22:20 UTC (permalink / raw)
  To: Yinghai Lu
  Cc: Vivek Goyal, Thomas Gleixner, Ingo Molnar, WANG Chao,
	Eric W. Biederman, Linux Kernel Mailing List

On 04/01/2013 03:17 PM, Yinghai Lu wrote:
> 
> And his last suggestion is just as his old second suggestion.
> 
> I just check the code again, it looks it is easy to change it to support:
> 1. crashkernel=XM
> 2. crashkernel_high=XM
> 3. crashkernel_high=XM crashkernel_low=YM
> 

Yes... my objections that you are giving the user the headache of
dealing with this very much remains, but I don't think we have any good
options.  However, the <size>,<options>.... syntax is at least
extensible, which the above syntax is not.

	-hpa



^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH] kexec: use Crash kernel for Crash kernel low
  2013-04-01 22:20                                                                                                         ` H. Peter Anvin
@ 2013-04-01 22:40                                                                                                           ` Yinghai Lu
  2013-04-02  1:11                                                                                                             ` Yinghai Lu
  0 siblings, 1 reply; 101+ messages in thread
From: Yinghai Lu @ 2013-04-01 22:40 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: Vivek Goyal, Thomas Gleixner, Ingo Molnar, WANG Chao,
	Eric W. Biederman, Linux Kernel Mailing List

On Mon, Apr 1, 2013 at 3:20 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> On 04/01/2013 03:17 PM, Yinghai Lu wrote:
>>
>> And his last suggestion is just as his old second suggestion.
>>
>> I just check the code again, it looks it is easy to change it to support:
>> 1. crashkernel=XM
>> 2. crashkernel_high=XM
>> 3. crashkernel_high=XM crashkernel_low=YM
>>
>
> Yes... my objections that you are giving the user the headache of
> dealing with this very much remains, but I don't think we have any good
> options.  However, the <size>,<options>.... syntax is at least
> extensible, which the above syntax is not.

ok, will check crashkernel=XM,high

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH] kexec: use Crash kernel for Crash kernel low
  2013-04-01 22:40                                                                                                           ` Yinghai Lu
@ 2013-04-02  1:11                                                                                                             ` Yinghai Lu
  2013-04-02 13:50                                                                                                               ` Vivek Goyal
  0 siblings, 1 reply; 101+ messages in thread
From: Yinghai Lu @ 2013-04-02  1:11 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: Vivek Goyal, Thomas Gleixner, Ingo Molnar, WANG Chao,
	Eric W. Biederman, Linux Kernel Mailing List

[-- Attachment #1: Type: text/plain, Size: 927 bytes --]

On Mon, Apr 1, 2013 at 3:40 PM, Yinghai Lu <yinghai@kernel.org> wrote:
> On Mon, Apr 1, 2013 at 3:20 PM, H. Peter Anvin <hpa@zytor.com> wrote:
>> On 04/01/2013 03:17 PM, Yinghai Lu wrote:
>>>
>>> And his last suggestion is just as his old second suggestion.
>>>
>>> I just check the code again, it looks it is easy to change it to support:
>>> 1. crashkernel=XM
>>> 2. crashkernel_high=XM
>>> 3. crashkernel_high=XM crashkernel_low=YM
>>>
>>
>> Yes... my objections that you are giving the user the headache of
>> dealing with this very much remains, but I don't think we have any good
>> options.  However, the <size>,<options>.... syntax is at least
>> extensible, which the above syntax is not.
>
> ok, will check crashkernel=XM,high

Please check attached four patches that should get into upstream for 3.9.
I sent first and second before.
other two is addressing old kexec-tools with kdump on new kernel.

Thanks

Yinghai

[-- Attachment #2: fix_crashkernel_low_v3.patch --]
[-- Type: application/octet-stream, Size: 5735 bytes --]

Subject: [PATCH v5] x86, kdump: Set crashkernel_low automatically

Chao said that kdump does does work well on his system on 3.8
without extra parameter, even iommu does not work with kdump.
And now have to append crashkernel_low=Y in first kernel to make
kdump work.

We have now modified crashkernel=X to allocate memory beyong 4G (if
available) and do not allocate low range for crashkernel if the user
does not specify that with crashkernel_low=Y.  This causes regression
if iommu is not enabled.  Without iommu, swiotlb needs to be setup in
first 4G and there is no low memory available to second kernel.

Set crashkernel_low automatically if the user does not specify that.

For system that does support IOMMU with kdump properly, user could
specify crashkernel_low=0 to save that 72M low ram.

-v3: add swiotlb_size() according to Konrad.
-v4: add comments what 8M is for according to hpa.
     also update more crashkernel_low= in kernel-parameters.txt
-v5: update changelog according to Vivek.

Reported-by: WANG Chao <chaowang@redhat.com>
Tested-by: WANG Chao <chaowang@redhat.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>

---
 Documentation/kernel-parameters.txt |   15 ++++++++++++---
 arch/x86/kernel/setup.c             |   20 +++++++++++++++++---
 include/linux/swiotlb.h             |    1 +
 lib/swiotlb.c                       |   19 +++++++++++++++----
 4 files changed, 45 insertions(+), 10 deletions(-)

Index: linux-2.6/arch/x86/kernel/setup.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/setup.c
+++ linux-2.6/arch/x86/kernel/setup.c
@@ -521,19 +521,33 @@ static void __init reserve_crashkernel_l
 	unsigned long long low_base = 0, low_size = 0;
 	unsigned long total_low_mem;
 	unsigned long long base;
+	bool auto_set = false;
 	int ret;
 
 	total_low_mem = memblock_mem_size(1UL<<(32-PAGE_SHIFT));
 	ret = parse_crashkernel_low(boot_command_line, total_low_mem,
 						&low_size, &base);
-	if (ret != 0 || low_size <= 0)
-		return;
+	if (ret != 0) {
+		/*
+		 * two parts from lib/swiotlb.c:
+		 *	swiotlb size: user specified with swiotlb= or default.
+		 *	swiotlb overflow buffer: now is hardcoded to 32k,
+		 *		round to 8M to cover more others.
+		 */
+		low_size = swiotlb_size_or_default() + (8UL<<20);
+		auto_set = true;
+	} else {
+		/* passed with crashkernel_low=0 ? */
+		if (!low_size)
+			return;
+	}
 
 	low_base = memblock_find_in_range(low_size, (1ULL<<32),
 					low_size, alignment);
 
 	if (!low_base) {
-		pr_info("crashkernel low reservation failed - No suitable area found.\n");
+		if (!auto_set)
+			pr_info("crashkernel low reservation failed - No suitable area found.\n");
 
 		return;
 	}
Index: linux-2.6/include/linux/swiotlb.h
===================================================================
--- linux-2.6.orig/include/linux/swiotlb.h
+++ linux-2.6/include/linux/swiotlb.h
@@ -25,6 +25,7 @@ extern int swiotlb_force;
 extern void swiotlb_init(int verbose);
 int swiotlb_init_with_tbl(char *tlb, unsigned long nslabs, int verbose);
 extern unsigned long swiotlb_nr_tbl(void);
+unsigned long swiotlb_size_or_default(void);
 extern int swiotlb_late_init_with_tbl(char *tlb, unsigned long nslabs);
 
 /*
Index: linux-2.6/lib/swiotlb.c
===================================================================
--- linux-2.6.orig/lib/swiotlb.c
+++ linux-2.6/lib/swiotlb.c
@@ -105,9 +105,9 @@ setup_io_tlb_npages(char *str)
 	if (!strcmp(str, "force"))
 		swiotlb_force = 1;
 
-	return 1;
+	return 0;
 }
-__setup("swiotlb=", setup_io_tlb_npages);
+early_param("swiotlb", setup_io_tlb_npages);
 /* make io_tlb_overflow tunable too? */
 
 unsigned long swiotlb_nr_tbl(void)
@@ -115,6 +115,18 @@ unsigned long swiotlb_nr_tbl(void)
 	return io_tlb_nslabs;
 }
 EXPORT_SYMBOL_GPL(swiotlb_nr_tbl);
+
+/* default to 64MB */
+#define IO_TLB_DEFAULT_SIZE (64UL<<20)
+unsigned long swiotlb_size_or_default(void)
+{
+	unsigned long size;
+
+	size = io_tlb_nslabs << IO_TLB_SHIFT;
+
+	return size ? size : (IO_TLB_DEFAULT_SIZE);
+}
+
 /* Note that this doesn't work with highmem page */
 static dma_addr_t swiotlb_virt_to_bus(struct device *hwdev,
 				      volatile void *address)
@@ -188,8 +200,7 @@ int __init swiotlb_init_with_tbl(char *t
 void  __init
 swiotlb_init(int verbose)
 {
-	/* default to 64MB */
-	size_t default_size = 64UL<<20;
+	size_t default_size = IO_TLB_DEFAULT_SIZE;
 	unsigned char *vstart;
 	unsigned long bytes;
 
Index: linux-2.6/Documentation/kernel-parameters.txt
===================================================================
--- linux-2.6.orig/Documentation/kernel-parameters.txt
+++ linux-2.6/Documentation/kernel-parameters.txt
@@ -596,9 +596,6 @@ bytes respectively. Such letter suffixes
 			is selected automatically. Check
 			Documentation/kdump/kdump.txt for further details.
 
-	crashkernel_low=size[KMG]
-			[KNL, x86] parts under 4G.
-
 	crashkernel=range1:size1[,range2:size2,...][@offset]
 			[KNL] Same as above, but depends on the memory
 			in the running system. The syntax of range is
@@ -606,6 +603,18 @@ bytes respectively. Such letter suffixes
 			a memory unit (amount[KMG]). See also
 			Documentation/kdump/kdump.txt for an example.
 
+	crashkernel_low=size[KMG]
+			[KNL, x86_64] range under 4G. When crashkernel= is
+			passed, kernel allocate physical memory region
+			above 4G, that cause second kernel crash on system
+			that need swiotlb later. Kernel would try to allocate
+			some region below 4G automatically. This one let
+			user to specify own low range under 4G for second
+			kernel instead.
+			0: to disable low allocation on systems that do not
+			need swiotlb, that will save 72M low ram in first
+			kernel.
+
 	cs89x0_dma=	[HW,NET]
 			Format: <dma>
 

[-- Attachment #3: crashkernel_low_remove.patch --]
[-- Type: application/octet-stream, Size: 823 bytes --]

Subject: [PATCH] kexec: use Crash kernel for Crash kernel low

We can extend kexec-tools to support multiple "Crash kernel" in /proc/iomem
instead.

So we can use "Crash kernel" instead of "Crash kernel low" in /proc/iomem.

Suggested-by: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>

---
 kernel/kexec.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux-2.6/kernel/kexec.c
===================================================================
--- linux-2.6.orig/kernel/kexec.c
+++ linux-2.6/kernel/kexec.c
@@ -55,7 +55,7 @@ struct resource crashk_res = {
 	.flags = IORESOURCE_BUSY | IORESOURCE_MEM
 };
 struct resource crashk_low_res = {
-	.name  = "Crash kernel low",
+	.name  = "Crash kernel",
 	.start = 0,
 	.end   = 0,
 	.flags = IORESOURCE_BUSY | IORESOURCE_MEM

[-- Attachment #4: crashkernel_high_low_1.patch --]
[-- Type: application/octet-stream, Size: 5133 bytes --]

Subject: [PATCH] x86, kdump: Only allocate high when crashkernel_high=

Vivek found old kexec-tools does not work new kernel anymore.

So change back crashkernel= back to old behavoir, and add crashkernel_high=
to let user decide if buffer is above 4G, and also new kexec-tools will
be needed.

Signed-off-by: Yinghai Lu <yinghai@kernel.org>

---
 Documentation/kernel-parameters.txt |    5 ++++-
 arch/x86/kernel/setup.c             |   26 ++++++++++++++++++++------
 include/linux/kexec.h               |    2 ++
 kernel/kexec.c                      |    9 +++++++++
 4 files changed, 35 insertions(+), 7 deletions(-)

Index: linux-2.6/Documentation/kernel-parameters.txt
===================================================================
--- linux-2.6.orig/Documentation/kernel-parameters.txt
+++ linux-2.6/Documentation/kernel-parameters.txt
@@ -603,8 +603,11 @@ bytes respectively. Such letter suffixes
 			a memory unit (amount[KMG]). See also
 			Documentation/kdump/kdump.txt for an example.
 
+	crashkernel_high=size[KMG]
+			[KNL, x86_64] range above 4G. kernel allocate physical
+			memory region above 4G.
 	crashkernel_low=size[KMG]
-			[KNL, x86_64] range under 4G. When crashkernel= is
+			[KNL, x86_64] range under 4G. When crashkernel_high= is
 			passed, kernel allocate physical memory region
 			above 4G, that cause second kernel crash on system
 			that need swiotlb later. Kernel would try to allocate
Index: linux-2.6/arch/x86/kernel/setup.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/setup.c
+++ linux-2.6/arch/x86/kernel/setup.c
@@ -533,11 +533,14 @@ static void __init memblock_x86_reserve_
 /*
  * Keep the crash kernel below this limit.  On 32 bits earlier kernels
  * would limit the kernel to the low 512 MiB due to mapping restrictions.
+ * On 64bit, old kexec-tools need to under 896MiB.
  */
 #ifdef CONFIG_X86_32
-# define CRASH_KERNEL_ADDR_MAX	(512 << 20)
+# define CRASH_KERNEL_ADDR_LOW_MAX	(512 << 20)
+# define CRASH_KERNEL_ADDR_HIGH_MAX	(512 << 20)
 #else
-# define CRASH_KERNEL_ADDR_MAX	MAXMEM
+# define CRASH_KERNEL_ADDR_LOW_MAX	(896UL<<20)
+# define CRASH_KERNEL_ADDR_HIGH_MAX	MAXMEM
 #endif
 
 static void __init reserve_crashkernel_low(void)
@@ -551,6 +554,7 @@ static void __init reserve_crashkernel_l
 	int ret;
 
 	total_low_mem = memblock_mem_size(1UL<<(32-PAGE_SHIFT));
+	/* crashkernel_low=YM */
 	ret = parse_crashkernel_low(boot_command_line, total_low_mem,
 						&low_size, &base);
 	if (ret != 0) {
@@ -594,14 +598,22 @@ static void __init reserve_crashkernel(v
 	const unsigned long long alignment = 16<<20;	/* 16M */
 	unsigned long long total_mem;
 	unsigned long long crash_size, crash_base;
+	bool high = true;
 	int ret;
 
 	total_mem = memblock_phys_mem_size();
 
-	ret = parse_crashkernel(boot_command_line, total_mem,
+	/* crashkernel_high=XM */
+	ret = parse_crashkernel_high(boot_command_line, total_mem,
 			&crash_size, &crash_base);
-	if (ret != 0 || crash_size <= 0)
-		return;
+	if (ret != 0 || crash_size <= 0) {
+		/* crashkernel=XM */
+		ret = parse_crashkernel(boot_command_line, total_mem,
+				&crash_size, &crash_base);
+		if (ret != 0 || crash_size <= 0)
+			return;
+		high = false;
+	}
 
 	/* 0 means: find the address automatically */
 	if (crash_base <= 0) {
@@ -609,7 +621,9 @@ static void __init reserve_crashkernel(v
 		 *  kexec want bzImage is below CRASH_KERNEL_ADDR_MAX
 		 */
 		crash_base = memblock_find_in_range(alignment,
-			       CRASH_KERNEL_ADDR_MAX, crash_size, alignment);
+					high ? CRASH_KERNEL_ADDR_HIGH_MAX :
+					       CRASH_KERNEL_ADDR_LOW_MAX,
+					crash_size, alignment);
 
 		if (!crash_base) {
 			pr_info("crashkernel reservation failed - No suitable area found.\n");
Index: linux-2.6/include/linux/kexec.h
===================================================================
--- linux-2.6.orig/include/linux/kexec.h
+++ linux-2.6/include/linux/kexec.h
@@ -202,6 +202,8 @@ extern size_t vmcoreinfo_max_size;
 
 int __init parse_crashkernel(char *cmdline, unsigned long long system_ram,
 		unsigned long long *crash_size, unsigned long long *crash_base);
+int parse_crashkernel_high(char *cmdline, unsigned long long system_ram,
+		unsigned long long *crash_size, unsigned long long *crash_base);
 int parse_crashkernel_low(char *cmdline, unsigned long long system_ram,
 		unsigned long long *crash_size, unsigned long long *crash_base);
 int crash_shrink_memory(unsigned long new_size);
Index: linux-2.6/kernel/kexec.c
===================================================================
--- linux-2.6.orig/kernel/kexec.c
+++ linux-2.6/kernel/kexec.c
@@ -1436,6 +1436,15 @@ int __init parse_crashkernel(char *cmdli
 					"crashkernel=");
 }
 
+int __init parse_crashkernel_high(char *cmdline,
+			     unsigned long long system_ram,
+			     unsigned long long *crash_size,
+			     unsigned long long *crash_base)
+{
+	return __parse_crashkernel(cmdline, system_ram, crash_size, crash_base,
+					"crashkernel_high=");
+}
+
 int __init parse_crashkernel_low(char *cmdline,
 			     unsigned long long system_ram,
 			     unsigned long long *crash_size,

[-- Attachment #5: crashkernel_high_low_2.patch --]
[-- Type: application/octet-stream, Size: 4516 bytes --]

Subject: [PATCH] x86, kdump: Change crashkernel_high/low= to crashkernel=,high/low

Per hpa, use crashkernel=XM,high crashkernel=YM,low instead of
crashkernel_hign=XM crashkernel_low=YM.
As that could be extensible.

Signed-off-by: Yinghai Lu <yinghai@kernel.org>

---
 Documentation/kernel-parameters.txt |    6 +++---
 arch/x86/kernel/setup.c             |    6 +++---
 kernel/kexec.c                      |   23 +++++++++++++++++------
 3 files changed, 23 insertions(+), 12 deletions(-)

Index: linux-2.6/Documentation/kernel-parameters.txt
===================================================================
--- linux-2.6.orig/Documentation/kernel-parameters.txt
+++ linux-2.6/Documentation/kernel-parameters.txt
@@ -603,11 +603,11 @@ bytes respectively. Such letter suffixes
 			a memory unit (amount[KMG]). See also
 			Documentation/kdump/kdump.txt for an example.
 
-	crashkernel_high=size[KMG]
+	crashkernel=size[KMG],high
 			[KNL, x86_64] range above 4G. kernel allocate physical
 			memory region above 4G.
-	crashkernel_low=size[KMG]
-			[KNL, x86_64] range under 4G. When crashkernel_high= is
+	crashkernel=size[KMG],low
+			[KNL, x86_64] range under 4G. When crashkernel=X,high is
 			passed, kernel allocate physical memory region
 			above 4G, that cause second kernel crash on system
 			that need swiotlb later. Kernel would try to allocate
Index: linux-2.6/arch/x86/kernel/setup.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/setup.c
+++ linux-2.6/arch/x86/kernel/setup.c
@@ -554,7 +554,7 @@ static void __init reserve_crashkernel_l
 	int ret;
 
 	total_low_mem = memblock_mem_size(1UL<<(32-PAGE_SHIFT));
-	/* crashkernel_low=YM */
+	/* crashkernel=YM,low */
 	ret = parse_crashkernel_low(boot_command_line, total_low_mem,
 						&low_size, &base);
 	if (ret != 0) {
@@ -567,7 +567,7 @@ static void __init reserve_crashkernel_l
 		low_size = swiotlb_size_or_default() + (8UL<<20);
 		auto_set = true;
 	} else {
-		/* passed with crashkernel_low=0 ? */
+		/* passed with crashkernel=0,low ? */
 		if (!low_size)
 			return;
 	}
@@ -603,7 +603,7 @@ static void __init reserve_crashkernel(v
 
 	total_mem = memblock_phys_mem_size();
 
-	/* crashkernel_high=XM */
+	/* crashkernel=XM,high */
 	ret = parse_crashkernel_high(boot_command_line, total_mem,
 			&crash_size, &crash_base);
 	if (ret != 0 || crash_size <= 0) {
Index: linux-2.6/kernel/kexec.c
===================================================================
--- linux-2.6.orig/kernel/kexec.c
+++ linux-2.6/kernel/kexec.c
@@ -1374,7 +1374,7 @@ static int __init parse_crashkernel_simp
 
 	if (*cur == '@')
 		*crash_base = memparse(cur+1, &cur);
-	else if (*cur != ' ' && *cur != '\0') {
+	else if (*cur != ' ' && *cur != ',' && *cur != '\0') {
 		pr_warning("crashkernel: unrecognized char\n");
 		return -EINVAL;
 	}
@@ -1390,7 +1390,8 @@ static int __init __parse_crashkernel(ch
 			     unsigned long long system_ram,
 			     unsigned long long *crash_size,
 			     unsigned long long *crash_base,
-				const char *name)
+			     const char *name,
+			     const char *suffix)
 {
 	char 	*p = cmdline, *ck_cmdline = NULL;
 	char	*first_colon, *first_space;
@@ -1402,7 +1403,17 @@ static int __init __parse_crashkernel(ch
 	/* find crashkernel and use the last one if there are more */
 	p = strstr(p, name);
 	while (p) {
-		ck_cmdline = p;
+		if (!suffix)
+			ck_cmdline = p;
+		else {
+			char *end_p = strchr(p, ' ');
+
+			if (!end_p)
+				end_p = p + strlen(p);
+			end_p -= strlen(suffix);
+			if (!strncmp(end_p, suffix, strlen(suffix)))
+				ck_cmdline = p;
+		}
 		p = strstr(p+1, name);
 	}
 
@@ -1433,7 +1444,7 @@ int __init parse_crashkernel(char *cmdli
 			     unsigned long long *crash_base)
 {
 	return __parse_crashkernel(cmdline, system_ram, crash_size, crash_base,
-					"crashkernel=");
+					"crashkernel=", NULL);
 }
 
 int __init parse_crashkernel_high(char *cmdline,
@@ -1442,7 +1453,7 @@ int __init parse_crashkernel_high(char *
 			     unsigned long long *crash_base)
 {
 	return __parse_crashkernel(cmdline, system_ram, crash_size, crash_base,
-					"crashkernel_high=");
+					"crashkernel=", ",high");
 }
 
 int __init parse_crashkernel_low(char *cmdline,
@@ -1451,7 +1462,7 @@ int __init parse_crashkernel_low(char *c
 			     unsigned long long *crash_base)
 {
 	return __parse_crashkernel(cmdline, system_ram, crash_size, crash_base,
-					"crashkernel_low=");
+					"crashkernel=", ",low");
 }
 
 static void update_vmcoreinfo_note(void)

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH] kexec: use Crash kernel for Crash kernel low
  2013-04-01 20:47                                                                                                 ` H. Peter Anvin
  2013-04-01 21:10                                                                                                   ` Yinghai Lu
@ 2013-04-02 13:30                                                                                                   ` Vivek Goyal
  1 sibling, 0 replies; 101+ messages in thread
From: Vivek Goyal @ 2013-04-02 13:30 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: Thomas Gleixner, Ingo Molnar, WANG Chao, Eric W. Biederman,
	linux-kernel, Yinghai Lu

On Mon, Apr 01, 2013 at 01:47:58PM -0700, H. Peter Anvin wrote:

[..]
> > All this will only address the issue of where to reserve memory. It will
> > still not solve the issue of how much memory to reserve. We have no way
> > to know. It is all heuristics.
> 
> At least heuristics in a script is better than telling the user "guess
> and pray".

Current heuristics are outside the kernel. That is we run tests on bunch
of machines and try to figure out what's a reasonable default amount of
reserved memory (with our kernel and with our initramfs and default
settings).

So we carry a patch in kernel which supports crashkernel=auto option.
Installer puts this option on boot loader command line during installation.

And in kernel we have hardcoded the per arch memory reservation requirements
and we update these limits if something significant changes either in
kernel or in user space in terms of memory consumption.

Initially we had tried to guess second kernel's memory usage based on
first kernel's memory usage, but that did not work. There were many
factors.

- First kernel brought up all the cpus and that inreases the memory
  consumption. While we bring up only one cpu (with nr_cpus=1) in
  kdump kernel.

- We disable memory cgroup controller while first kernel has it enabled
  and that can change memory requirement significantly on large machines.

- We don't bring up all the devices in second kernel while we do in
  first kernel. So module memory usage can be significantly higher in
  first kernel.

So it has been very tricky to come up with some kind of guidelines in
an automated manner. 

But I am more than willing to look into it if there are more ideas on
how one can go about figuring out how much memory to reserve and where
to reserve.

Thanks
Vivek

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH] kexec: use Crash kernel for Crash kernel low
  2013-04-02  1:11                                                                                                             ` Yinghai Lu
@ 2013-04-02 13:50                                                                                                               ` Vivek Goyal
  2013-04-02 14:17                                                                                                                 ` Vivek Goyal
  2013-04-02 14:45                                                                                                                 ` Yinghai Lu
  0 siblings, 2 replies; 101+ messages in thread
From: Vivek Goyal @ 2013-04-02 13:50 UTC (permalink / raw)
  To: Yinghai Lu
  Cc: H. Peter Anvin, Thomas Gleixner, Ingo Molnar, WANG Chao,
	Eric W. Biederman, Linux Kernel Mailing List

On Mon, Apr 01, 2013 at 06:11:38PM -0700, Yinghai Lu wrote:
> On Mon, Apr 1, 2013 at 3:40 PM, Yinghai Lu <yinghai@kernel.org> wrote:
> > On Mon, Apr 1, 2013 at 3:20 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> >> On 04/01/2013 03:17 PM, Yinghai Lu wrote:
> >>>
> >>> And his last suggestion is just as his old second suggestion.
> >>>
> >>> I just check the code again, it looks it is easy to change it to support:
> >>> 1. crashkernel=XM
> >>> 2. crashkernel_high=XM
> >>> 3. crashkernel_high=XM crashkernel_low=YM
> >>>
> >>
> >> Yes... my objections that you are giving the user the headache of
> >> dealing with this very much remains, but I don't think we have any good
> >> options.  However, the <size>,<options>.... syntax is at least
> >> extensible, which the above syntax is not.
> >
> > ok, will check crashkernel=XM,high
> 
> Please check attached four patches that should get into upstream for 3.9.
> I sent first and second before.
> other two is addressing old kexec-tools with kdump on new kernel.

Hi Yinghai,

I think there is still little confusion. What does crashkernel=X,high
mean. Currently it seems to mean that memory is allocated from region
above 4G and if it is not available, allocation fails.

I thought what would be more useful if it means that we start search
for memory from higher range of addresses and continue down till we
find a suitable memory area.

That means memory could either come from higher memory regions (above
4G) or from low memory regions (below 4G) depending on how much physical
RAM system has.

Similary crashkernel=X or crashkernel=X,low will mean that we start
scanning for free memory from low memory area first. And if sufficient
amount of memory is not available below 4G, memory could very well
come from above 4G.

That way a distribution could decide its default memory requirement
(say 128M) and they could simply say, crashkernel=128M or
crashkernel=128M,high (depending on whether they support 64bit bzImage
or not).

To achieve the behavior where we want to enforce that memory either
comes from low or high area only otherwise allocation fails, we could
probably use.

crashkernel=X,high_only
crashkernel=X,low_only

And crashkernel_low could be replaced with crashkernel=X,low_only

I think it is reasonable to continue to reserve low memory automatically
for swiotlb if crash memory reservation happens above 4G. Users should
be able to opt out of it using crashkernel=0M,low_only.

Thanks
Vivek

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH] kexec: use Crash kernel for Crash kernel low
  2013-04-02 13:50                                                                                                               ` Vivek Goyal
@ 2013-04-02 14:17                                                                                                                 ` Vivek Goyal
  2013-04-02 14:50                                                                                                                   ` Yinghai Lu
  2013-04-02 14:45                                                                                                                 ` Yinghai Lu
  1 sibling, 1 reply; 101+ messages in thread
From: Vivek Goyal @ 2013-04-02 14:17 UTC (permalink / raw)
  To: Yinghai Lu
  Cc: H. Peter Anvin, Thomas Gleixner, Ingo Molnar, WANG Chao,
	Eric W. Biederman, Linux Kernel Mailing List

On Tue, Apr 02, 2013 at 09:50:01AM -0400, Vivek Goyal wrote:

[..]
> To achieve the behavior where we want to enforce that memory either
> comes from low or high area only otherwise allocation fails, we could
> probably use.
> 
> crashkernel=X,high_only
> crashkernel=X,low_only

Thinking more about it. We have following existing syntax.

crashkernel=range1:size1[,range2:size2,...][@offset]

Which uses ',' as delimiter for range:size pairs.

May be we can use a different delimiter, say ';'.

crashkernel=<amount_of_memory_to_reserve>;<option1>;<option2>

All the existing crashkernel= options should fall into the category of
<amount_of_memory_to_reserve>.

option1 could specify whether to search for memory from higher addresses
or from lower addresses. (valid values are high or low)

option2 could specify the range of memory search should be performed in.
syntax to specify range could be XM:[YM]. So one could possibly specify.

4G-8G
<4G
>4G:<8G
>8G

Now crashkernel_low=0 could be emulated by

crashkernel=0M;;<4G

If we want to reserve 128MB of memory between 4G and 8G and starting scan
from high, we could say.

crashkernel=128M;high;>4G:<8G

If this is deemed too generic and not worth it. Then we could simplify
option 2 to take values "high_only" and "low_only" and that leaves the
scope of implementing proper ranges down the line if need be.

So crashkernel_low=0 will be emulated by.

crashkernel=0M;;low_only

Thanks
Vivek

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH] kexec: use Crash kernel for Crash kernel low
  2013-04-02 13:50                                                                                                               ` Vivek Goyal
  2013-04-02 14:17                                                                                                                 ` Vivek Goyal
@ 2013-04-02 14:45                                                                                                                 ` Yinghai Lu
  2013-04-02 14:58                                                                                                                   ` Vivek Goyal
  2013-04-02 15:39                                                                                                                   ` Vivek Goyal
  1 sibling, 2 replies; 101+ messages in thread
From: Yinghai Lu @ 2013-04-02 14:45 UTC (permalink / raw)
  To: Vivek Goyal
  Cc: H. Peter Anvin, Thomas Gleixner, Ingo Molnar, WANG Chao,
	Eric W. Biederman, Linux Kernel Mailing List

On Tue, Apr 2, 2013 at 6:50 AM, Vivek Goyal <vgoyal@redhat.com> wrote:
> On Mon, Apr 01, 2013 at 06:11:38PM -0700, Yinghai Lu wrote:
>> On Mon, Apr 1, 2013 at 3:40 PM, Yinghai Lu <yinghai@kernel.org> wrote:
>> > On Mon, Apr 1, 2013 at 3:20 PM, H. Peter Anvin <hpa@zytor.com> wrote:
>> >> On 04/01/2013 03:17 PM, Yinghai Lu wrote:
>> >>>
>> >>> And his last suggestion is just as his old second suggestion.
>> >>>
>> >>> I just check the code again, it looks it is easy to change it to support:
>> >>> 1. crashkernel=XM
>> >>> 2. crashkernel_high=XM
>> >>> 3. crashkernel_high=XM crashkernel_low=YM
>> >>>
>> >>
>> >> Yes... my objections that you are giving the user the headache of
>> >> dealing with this very much remains, but I don't think we have any good
>> >> options.  However, the <size>,<options>.... syntax is at least
>> >> extensible, which the above syntax is not.
>> >
>> > ok, will check crashkernel=XM,high
>>
>> Please check attached four patches that should get into upstream for 3.9.
>> I sent first and second before.
>> other two is addressing old kexec-tools with kdump on new kernel.
>
> Hi Yinghai,
>
> I think there is still little confusion. What does crashkernel=X,high
> mean. Currently it seems to mean that memory is allocated from region
> above 4G and if it is not available, allocation fails.
>
> I thought what would be more useful if it means that we start search
> for memory from higher range of addresses and continue down till we
> find a suitable memory area.
>
> That means memory could either come from higher memory regions (above
> 4G) or from low memory regions (below 4G) depending on how much physical
> RAM system has.
>
> Similary crashkernel=X or crashkernel=X,low will mean that we start
> scanning for free memory from low memory area first. And if sufficient
> amount of memory is not available below 4G, memory could very well
> come from above 4G.
>
> That way a distribution could decide its default memory requirement
> (say 128M) and they could simply say, crashkernel=128M or
> crashkernel=128M,high (depending on whether they support 64bit bzImage
> or not).
>
> To achieve the behavior where we want to enforce that memory either
> comes from low or high area only otherwise allocation fails, we could
> probably use.
>
> crashkernel=X,high_only
> crashkernel=X,low_only
>
> And crashkernel_low could be replaced with crashkernel=X,low_only
>
> I think it is reasonable to continue to reserve low memory automatically
> for swiotlb if crash memory reservation happens above 4G. Users should
> be able to opt out of it using crashkernel=0M,low_only.

No, that make the logic too complicated.

After those four patches:
if the user still use old kexec-tools, they are still with
crashkernel=X, nothing is changed.
if the user want to use crashkernel=X,high, they should update kexec-tools.
   when high is used, memblock will search from top to low.
   if the allocated one is above 4G, kernel will try to auto allocate
72M under 4G for swiotlb
       user could crashkernel=Y,low to change 72M to other value.

The whole point is:
1. keep the transition from old kexec-tools to new one.
2. keep thing unified when new kexec-tools is used: always high.

Thanks

Yinghai

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH] kexec: use Crash kernel for Crash kernel low
  2013-04-02 14:17                                                                                                                 ` Vivek Goyal
@ 2013-04-02 14:50                                                                                                                   ` Yinghai Lu
  0 siblings, 0 replies; 101+ messages in thread
From: Yinghai Lu @ 2013-04-02 14:50 UTC (permalink / raw)
  To: Vivek Goyal
  Cc: H. Peter Anvin, Thomas Gleixner, Ingo Molnar, WANG Chao,
	Eric W. Biederman, Linux Kernel Mailing List

On Tue, Apr 2, 2013 at 7:17 AM, Vivek Goyal <vgoyal@redhat.com> wrote:
> On Tue, Apr 02, 2013 at 09:50:01AM -0400, Vivek Goyal wrote:
>
> [..]
>> To achieve the behavior where we want to enforce that memory either
>> comes from low or high area only otherwise allocation fails, we could
>> probably use.
>>
>> crashkernel=X,high_only
>> crashkernel=X,low_only
>
> Thinking more about it. We have following existing syntax.
>
> crashkernel=range1:size1[,range2:size2,...][@offset]
>
> Which uses ',' as delimiter for range:size pairs.
>
> May be we can use a different delimiter, say ';'.
>
> crashkernel=<amount_of_memory_to_reserve>;<option1>;<option2>
>
> All the existing crashkernel= options should fall into the category of
> <amount_of_memory_to_reserve>.
>
> option1 could specify whether to search for memory from higher addresses
> or from lower addresses. (valid values are high or low)
>
> option2 could specify the range of memory search should be performed in.
> syntax to specify range could be XM:[YM]. So one could possibly specify.
>
> 4G-8G
> <4G
>>4G:<8G
>>8G
>
> Now crashkernel_low=0 could be emulated by
>
> crashkernel=0M;;<4G
>
> If we want to reserve 128MB of memory between 4G and 8G and starting scan
> from high, we could say.
>
> crashkernel=128M;high;>4G:<8G
>
> If this is deemed too generic and not worth it. Then we could simplify
> option 2 to take values "high_only" and "low_only" and that leaves the
> scope of implementing proper ranges down the line if need be.
>
> So crashkernel_low=0 will be emulated by.
>
> crashkernel=0M;;low_only

Oh, no. the grammar for crashkernel= looks crazy now.

You should not burden user like this.

Thanks

Yinghai

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH] kexec: use Crash kernel for Crash kernel low
  2013-04-02 14:45                                                                                                                 ` Yinghai Lu
@ 2013-04-02 14:58                                                                                                                   ` Vivek Goyal
  2013-04-02 15:44                                                                                                                     ` Yinghai Lu
  2013-04-02 15:39                                                                                                                   ` Vivek Goyal
  1 sibling, 1 reply; 101+ messages in thread
From: Vivek Goyal @ 2013-04-02 14:58 UTC (permalink / raw)
  To: Yinghai Lu
  Cc: H. Peter Anvin, Thomas Gleixner, Ingo Molnar, WANG Chao,
	Eric W. Biederman, Linux Kernel Mailing List

On Tue, Apr 02, 2013 at 07:45:36AM -0700, Yinghai Lu wrote:

[..]
> No, that make the logic too complicated.
> 
> After those four patches:
> if the user still use old kexec-tools, they are still with
> crashkernel=X, nothing is changed.
> if the user want to use crashkernel=X,high, they should update kexec-tools.
>    when high is used, memblock will search from top to low.
>    if the allocated one is above 4G, kernel will try to auto allocate
> 72M under 4G for swiotlb
>        user could crashkernel=Y,low to change 72M to other value.

Hm...,

- Ok so atleast use a different delimiter. Otherwise one could specify
  rage1:size1,range2:size2,high which is confusing.

- I think one can look at above as follows.

  crashkernel=<memory_to_reserve>;[<option1>];....

where option1 specifies range of memory where to look for specified amount
of memory. Current valid values are high/low. High means look for memory
above 4G or fail. Low means look for memory below 4G or fail. We can
always extend range syntax later if need be. Similarly we can always
add option2 to emulate where to begin search (high/low). So this still
falls into the generic syntax category and extendable, if need be.

I will test your patches again.

Thanks
Vivek

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH] kexec: use Crash kernel for Crash kernel low
  2013-04-02 14:45                                                                                                                 ` Yinghai Lu
  2013-04-02 14:58                                                                                                                   ` Vivek Goyal
@ 2013-04-02 15:39                                                                                                                   ` Vivek Goyal
  2013-04-02 15:46                                                                                                                     ` Yinghai Lu
  1 sibling, 1 reply; 101+ messages in thread
From: Vivek Goyal @ 2013-04-02 15:39 UTC (permalink / raw)
  To: Yinghai Lu
  Cc: H. Peter Anvin, Thomas Gleixner, Ingo Molnar, WANG Chao,
	Eric W. Biederman, Linux Kernel Mailing List

On Tue, Apr 02, 2013 at 07:45:36AM -0700, Yinghai Lu wrote:

[..]
> 2. keep thing unified when new kexec-tools is used: always high.

I think this is wrong. What if system does not have more than 4G of
memory. crashkernel=x,high will fail. So just because we have new version
of kexec-tools, it does not mean that one can always use crashkernel=x,high.

I think we should do two things.

- Extend crashkernel=X to search for memory below 896M, 4G, MAXMEM in
  that order. To me, this will work best for most of the users.

- For users who really care to not allocate memory in low memory ranges,
  they can use crashkernel=X,high. But even there syntax should be that
  look for memory in higher ranges first otherwise allocate from low
  regions.

  Otherwise it makes life very difficult for a user when there is no
  memory available in higher addresses but it is available in low addresses.
  How does one automate that.

In current form, I double crashkernel=X,high is going to be very useful.

Thanks
Vivek

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH] kexec: use Crash kernel for Crash kernel low
  2013-04-02 14:58                                                                                                                   ` Vivek Goyal
@ 2013-04-02 15:44                                                                                                                     ` Yinghai Lu
  0 siblings, 0 replies; 101+ messages in thread
From: Yinghai Lu @ 2013-04-02 15:44 UTC (permalink / raw)
  To: Vivek Goyal
  Cc: H. Peter Anvin, Thomas Gleixner, Ingo Molnar, WANG Chao,
	Eric W. Biederman, Linux Kernel Mailing List

[-- Attachment #1: Type: text/plain, Size: 452 bytes --]

On Tue, Apr 2, 2013 at 7:58 AM, Vivek Goyal <vgoyal@redhat.com> wrote:
> On Tue, Apr 02, 2013 at 07:45:36AM -0700, Yinghai Lu wrote:
>
> - Ok so atleast use a different delimiter. Otherwise one could specify
>   rage1:size1,range2:size2,high which is confusing.
>
> - I think one can look at above as follows.
>
>   crashkernel=<memory_to_reserve>;[<option1>];....

ok, please check attached one that replace last one of four patches.

Thanks

Yinghai

[-- Attachment #2: crashkernel_high_low_2_v2.patch --]
[-- Type: application/octet-stream, Size: 4564 bytes --]

Subject: [PATCH] x86, kdump: Change crashkernel_high/low= to crashkernel=;high/low

Per hpa, use crashkernel=XM;high crashkernel=YM;low instead of
crashkernel_hign=XM crashkernel_low=YM.
As that could be extensible.

-v2: according to Vivek, change delimiter to ;

Signed-off-by: Yinghai Lu <yinghai@kernel.org>

---
 Documentation/kernel-parameters.txt |    6 +++---
 arch/x86/kernel/setup.c             |    6 +++---
 kernel/kexec.c                      |   23 +++++++++++++++++------
 3 files changed, 23 insertions(+), 12 deletions(-)

Index: linux-2.6/Documentation/kernel-parameters.txt
===================================================================
--- linux-2.6.orig/Documentation/kernel-parameters.txt
+++ linux-2.6/Documentation/kernel-parameters.txt
@@ -603,11 +603,11 @@ bytes respectively. Such letter suffixes
 			a memory unit (amount[KMG]). See also
 			Documentation/kdump/kdump.txt for an example.
 
-	crashkernel_high=size[KMG]
+	crashkernel=size[KMG];high
 			[KNL, x86_64] range above 4G. kernel allocate physical
 			memory region above 4G.
-	crashkernel_low=size[KMG]
-			[KNL, x86_64] range under 4G. When crashkernel_high= is
+	crashkernel=size[KMG];low
+			[KNL, x86_64] range under 4G. When crashkernel=X;high is
 			passed, kernel allocate physical memory region
 			above 4G, that cause second kernel crash on system
 			that need swiotlb later. Kernel would try to allocate
Index: linux-2.6/arch/x86/kernel/setup.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/setup.c
+++ linux-2.6/arch/x86/kernel/setup.c
@@ -554,7 +554,7 @@ static void __init reserve_crashkernel_l
 	int ret;
 
 	total_low_mem = memblock_mem_size(1UL<<(32-PAGE_SHIFT));
-	/* crashkernel_low=YM */
+	/* crashkernel=YM;low */
 	ret = parse_crashkernel_low(boot_command_line, total_low_mem,
 						&low_size, &base);
 	if (ret != 0) {
@@ -567,7 +567,7 @@ static void __init reserve_crashkernel_l
 		low_size = swiotlb_size_or_default() + (8UL<<20);
 		auto_set = true;
 	} else {
-		/* passed with crashkernel_low=0 ? */
+		/* passed with crashkernel=0;low ? */
 		if (!low_size)
 			return;
 	}
@@ -603,7 +603,7 @@ static void __init reserve_crashkernel(v
 
 	total_mem = memblock_phys_mem_size();
 
-	/* crashkernel_high=XM */
+	/* crashkernel=XM;high */
 	ret = parse_crashkernel_high(boot_command_line, total_mem,
 			&crash_size, &crash_base);
 	if (ret != 0 || crash_size <= 0) {
Index: linux-2.6/kernel/kexec.c
===================================================================
--- linux-2.6.orig/kernel/kexec.c
+++ linux-2.6/kernel/kexec.c
@@ -1374,7 +1374,7 @@ static int __init parse_crashkernel_simp
 
 	if (*cur == '@')
 		*crash_base = memparse(cur+1, &cur);
-	else if (*cur != ' ' && *cur != '\0') {
+	else if (*cur != ' ' && *cur != ';' && *cur != '\0') {
 		pr_warning("crashkernel: unrecognized char\n");
 		return -EINVAL;
 	}
@@ -1390,7 +1390,8 @@ static int __init __parse_crashkernel(ch
 			     unsigned long long system_ram,
 			     unsigned long long *crash_size,
 			     unsigned long long *crash_base,
-				const char *name)
+			     const char *name,
+			     const char *suffix)
 {
 	char 	*p = cmdline, *ck_cmdline = NULL;
 	char	*first_colon, *first_space;
@@ -1402,7 +1403,17 @@ static int __init __parse_crashkernel(ch
 	/* find crashkernel and use the last one if there are more */
 	p = strstr(p, name);
 	while (p) {
-		ck_cmdline = p;
+		if (!suffix)
+			ck_cmdline = p;
+		else {
+			char *end_p = strchr(p, ' ');
+
+			if (!end_p)
+				end_p = p + strlen(p);
+			end_p -= strlen(suffix);
+			if (!strncmp(end_p, suffix, strlen(suffix)))
+				ck_cmdline = p;
+		}
 		p = strstr(p+1, name);
 	}
 
@@ -1433,7 +1444,7 @@ int __init parse_crashkernel(char *cmdli
 			     unsigned long long *crash_base)
 {
 	return __parse_crashkernel(cmdline, system_ram, crash_size, crash_base,
-					"crashkernel=");
+					"crashkernel=", NULL);
 }
 
 int __init parse_crashkernel_high(char *cmdline,
@@ -1442,7 +1453,7 @@ int __init parse_crashkernel_high(char *
 			     unsigned long long *crash_base)
 {
 	return __parse_crashkernel(cmdline, system_ram, crash_size, crash_base,
-					"crashkernel_high=");
+					"crashkernel=", ";high");
 }
 
 int __init parse_crashkernel_low(char *cmdline,
@@ -1451,7 +1462,7 @@ int __init parse_crashkernel_low(char *c
 			     unsigned long long *crash_base)
 {
 	return __parse_crashkernel(cmdline, system_ram, crash_size, crash_base,
-					"crashkernel_low=");
+					"crashkernel=", ";low");
 }
 
 static void update_vmcoreinfo_note(void)

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH] kexec: use Crash kernel for Crash kernel low
  2013-04-02 15:39                                                                                                                   ` Vivek Goyal
@ 2013-04-02 15:46                                                                                                                     ` Yinghai Lu
  2013-04-02 15:50                                                                                                                       ` Vivek Goyal
  0 siblings, 1 reply; 101+ messages in thread
From: Yinghai Lu @ 2013-04-02 15:46 UTC (permalink / raw)
  To: Vivek Goyal
  Cc: H. Peter Anvin, Thomas Gleixner, Ingo Molnar, WANG Chao,
	Eric W. Biederman, Linux Kernel Mailing List

On Tue, Apr 2, 2013 at 8:39 AM, Vivek Goyal <vgoyal@redhat.com> wrote:
> On Tue, Apr 02, 2013 at 07:45:36AM -0700, Yinghai Lu wrote:
>
> [..]
>> 2. keep thing unified when new kexec-tools is used: always high.
>
> I think this is wrong. What if system does not have more than 4G of
> memory. crashkernel=x,high will fail. So just because we have new version
> of kexec-tools, it does not mean that one can always use crashkernel=x,high.

no, it will not fail.

If the system have less 4G, and memblock will still find the ram for us.

Thanks

Yinghai

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH] kexec: use Crash kernel for Crash kernel low
  2013-04-02 15:46                                                                                                                     ` Yinghai Lu
@ 2013-04-02 15:50                                                                                                                       ` Vivek Goyal
  2013-04-02 17:21                                                                                                                         ` Yinghai Lu
  0 siblings, 1 reply; 101+ messages in thread
From: Vivek Goyal @ 2013-04-02 15:50 UTC (permalink / raw)
  To: Yinghai Lu
  Cc: H. Peter Anvin, Thomas Gleixner, Ingo Molnar, WANG Chao,
	Eric W. Biederman, Linux Kernel Mailing List

On Tue, Apr 02, 2013 at 08:46:16AM -0700, Yinghai Lu wrote:
> On Tue, Apr 2, 2013 at 8:39 AM, Vivek Goyal <vgoyal@redhat.com> wrote:
> > On Tue, Apr 02, 2013 at 07:45:36AM -0700, Yinghai Lu wrote:
> >
> > [..]
> >> 2. keep thing unified when new kexec-tools is used: always high.
> >
> > I think this is wrong. What if system does not have more than 4G of
> > memory. crashkernel=x,high will fail. So just because we have new version
> > of kexec-tools, it does not mean that one can always use crashkernel=x,high.
> 
> no, it will not fail.
> 
> If the system have less 4G, and memblock will still find the ram for us.

Ok, then description in kernel-parameters.txt is wrong.

+	crashkernel_high=size[KMG]
+                       [KNL, x86_64] range above 4G. kernel allocate
physical
+                       memory region above 4G.


Can you please inline your patches. Otherwise how one is supposed to give
review comments?

Thanks
Vivek

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH] kexec: use Crash kernel for Crash kernel low
  2013-04-02 15:50                                                                                                                       ` Vivek Goyal
@ 2013-04-02 17:21                                                                                                                         ` Yinghai Lu
  0 siblings, 0 replies; 101+ messages in thread
From: Yinghai Lu @ 2013-04-02 17:21 UTC (permalink / raw)
  To: Vivek Goyal
  Cc: H. Peter Anvin, Thomas Gleixner, Ingo Molnar, WANG Chao,
	Eric W. Biederman, Linux Kernel Mailing List

On Tue, Apr 2, 2013 at 8:50 AM, Vivek Goyal <vgoyal@redhat.com> wrote:

> Can you please inline your patches. Otherwise how one is supposed to give
> review comments?

Just sent the whole updated four patches. Please check them.

Thanks

Yinghai

^ permalink raw reply	[flat|nested] 101+ messages in thread

end of thread, other threads:[~2013-04-02 17:21 UTC | newest]

Thread overview: 101+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-03-08  5:54 3.9-rc1: crash kernel panic - not syncing: Can not allocate SWIOTLB buffer earlier and can't now provide you with the DMA bounce buffer WANG Chao
2013-03-08  6:03 ` CAI Qian
2013-03-08  6:32   ` Yinghai Lu
2013-03-08  6:36     ` Yinghai Lu
2013-03-08  7:20       ` WANG Chao
2013-03-08  7:27         ` Yinghai Lu
2013-03-08  7:33           ` WANG Chao
2013-03-08  7:50             ` Yinghai Lu
2013-03-08 12:12               ` WANG Chao
2013-03-08 18:24                 ` Yinghai Lu
2013-03-08 19:39                   ` Yinghai Lu
2013-03-11  3:42                     ` WANG Chao
2013-03-11  4:56                       ` [PATCH] x86, kdump: Set crashkernel_low automatically Yinghai Lu
2013-03-11 14:48                         ` Vivek Goyal
2013-03-11 15:02                           ` Vivek Goyal
2013-03-11 17:58                             ` Yinghai Lu
2013-03-11 18:26                               ` Vivek Goyal
2013-03-11 18:44                                 ` Yinghai Lu
2013-03-11 18:46                                 ` H. Peter Anvin
2013-03-11 18:50                                   ` Yinghai Lu
2013-03-11 18:55                                     ` H. Peter Anvin
2013-03-11 19:06                                       ` Yinghai Lu
2013-03-11 19:06                                         ` H. Peter Anvin
2013-03-11 19:08                                           ` Yinghai Lu
2013-03-11 19:20                                         ` Vivek Goyal
2013-03-11 19:55                                           ` H. Peter Anvin
2013-03-11 20:12                                             ` Vivek Goyal
2013-03-11 20:19                                               ` H. Peter Anvin
2013-03-11 20:36                                                 ` H. Peter Anvin
2013-03-11 20:38                                                 ` Eric W. Biederman
2013-03-11 20:42                                                   ` H. Peter Anvin
2013-03-11 21:10                                                     ` Vivek Goyal
2013-03-11 21:13                                                       ` H. Peter Anvin
2013-03-11 20:45                                                   ` Vivek Goyal
2013-03-11 20:50                                                     ` H. Peter Anvin
2013-03-11 21:03                                                       ` Vivek Goyal
2013-03-11 21:06                                                         ` H. Peter Anvin
2013-03-12 13:46                                                           ` Vivek Goyal
2013-03-12  8:35                                                         ` Ingo Molnar
2013-03-11 20:57                                                     ` Yinghai Lu
2013-03-11 21:06                                                       ` Vivek Goyal
2013-03-11 21:15                                                         ` Yinghai Lu
2013-03-11 19:10                                       ` Vivek Goyal
2013-03-11 19:34                                         ` Yinghai Lu
2013-03-11 19:38                                           ` Vivek Goyal
2013-03-11 19:39                                             ` Yinghai Lu
2013-03-11 19:44                                               ` Vivek Goyal
2013-03-11 19:44                                               ` Yinghai Lu
2013-03-18 14:46                                                 ` Vivek Goyal
2013-03-18 15:33                                                   ` Vivek Goyal
2013-03-18 19:05                                                     ` Yinghai Lu
2013-03-18 19:10                                                     ` H. Peter Anvin
2013-03-18 20:00                                                       ` Vivek Goyal
2013-03-18 21:14                                                         ` H. Peter Anvin
2013-03-18 21:25                                                           ` [PATCH v3] " Yinghai Lu
2013-03-18 22:52                                                             ` H. Peter Anvin
2013-03-18 23:26                                                               ` Yinghai Lu
2013-03-19  0:27                                                                 ` H. Peter Anvin
2013-03-19  1:04                                                                   ` [PATCH v4] " Yinghai Lu
2013-03-19 13:33                                                                     ` Vivek Goyal
2013-03-19 15:05                                                                       ` [PATCH v5] " Yinghai Lu
2013-03-20 13:08                                                                         ` Vivek Goyal
2013-03-20 15:53                                                                           ` Yinghai Lu
2013-03-20 16:03                                                                             ` Vivek Goyal
2013-03-20 16:21                                                                               ` Yinghai Lu
2013-03-20 16:31                                                                                 ` Vivek Goyal
2013-03-20 19:22                                                                                   ` [PATCH] kexec: use Crash kernel for Crash kernel low Yinghai Lu
2013-03-25 19:42                                                                                     ` Vivek Goyal
2013-03-25 21:50                                                                                       ` Yinghai Lu
2013-03-26 18:14                                                                                         ` Vivek Goyal
2013-04-01 13:34                                                                                           ` Vivek Goyal
2013-04-01 18:33                                                                                             ` H. Peter Anvin
2013-04-01 19:26                                                                                               ` Vivek Goyal
2013-04-01 20:47                                                                                                 ` H. Peter Anvin
2013-04-01 21:10                                                                                                   ` Yinghai Lu
2013-04-01 22:02                                                                                                     ` H. Peter Anvin
2013-04-01 22:17                                                                                                       ` Yinghai Lu
2013-04-01 22:20                                                                                                         ` H. Peter Anvin
2013-04-01 22:40                                                                                                           ` Yinghai Lu
2013-04-02  1:11                                                                                                             ` Yinghai Lu
2013-04-02 13:50                                                                                                               ` Vivek Goyal
2013-04-02 14:17                                                                                                                 ` Vivek Goyal
2013-04-02 14:50                                                                                                                   ` Yinghai Lu
2013-04-02 14:45                                                                                                                 ` Yinghai Lu
2013-04-02 14:58                                                                                                                   ` Vivek Goyal
2013-04-02 15:44                                                                                                                     ` Yinghai Lu
2013-04-02 15:39                                                                                                                   ` Vivek Goyal
2013-04-02 15:46                                                                                                                     ` Yinghai Lu
2013-04-02 15:50                                                                                                                       ` Vivek Goyal
2013-04-02 17:21                                                                                                                         ` Yinghai Lu
2013-04-02 13:30                                                                                                   ` Vivek Goyal
2013-03-11 19:14                                       ` [PATCH] x86, kdump: Set crashkernel_low automatically Eric W. Biederman
2013-03-11 19:22                                         ` Vivek Goyal
2013-03-11 19:59                                           ` H. Peter Anvin
2013-03-11 20:17                                             ` Vivek Goyal
2013-03-11 19:56                                         ` H. Peter Anvin
2013-03-11 19:02                                   ` Vivek Goyal
2013-03-11 19:04                                     ` H. Peter Anvin
2013-03-11 19:17                                       ` Vivek Goyal
2013-03-11 13:14                     ` 3.9-rc1: crash kernel panic - not syncing: Can not allocate SWIOTLB buffer earlier and can't now provide you with the DMA bounce buffer Konrad Rzeszutek Wilk
2013-03-08  7:52             ` Takao Indoh

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).