Re: [E1000-devel] PROBLEM: [x86] Running ptpd2 using an Intel 82572EI (e1000e) leads to a kernel oops (3.12.26)
On Wed, 2014-08-06 at 15:38 +, Fujinaka, Todd wrote: > Looking at your patches on netdev, it appears that there are flags set in the > skb that should never be set for the 82572EI as that part doesn't have > hardware timestamping. This points to a bug in the ptpd code. > > Todd Fujinaka > Software Application Engineer > Networking Division (ND) > Intel Corporation > todd.fujin...@intel.com > (503) 712-4565 Surely we can bail here instead of generating a kernel oops? Even though ptpd may be incorrect here, we still shouldn't do this. I think this may be a bug in the set_ts_config possibly as well (since it shouldn't be able to set the hardware timestamp flags for the 82572EI Thanks, Jake
RE: [E1000-devel] PROBLEM: [x86] Running ptpd2 using an Intel 82572EI (e1000e) leads to a kernel oops (3.12.26)
Looking at your patches on netdev, it appears that there are flags set in the skb that should never be set for the 82572EI as that part doesn't have hardware timestamping. This points to a bug in the ptpd code. Todd Fujinaka Software Application Engineer Networking Division (ND) Intel Corporation todd.fujin...@intel.com (503) 712-4565 -Original Message- From: Hannes Frederic Sowa [mailto:han...@stressinduktion.org] Sent: Wednesday, August 06, 2014 2:29 AM To: Koehrer Mathias; linux-kernel@vger.kernel.org; net...@vger.kernel.org Cc: e1000-de...@lists.sourceforge.net Subject: Re: [E1000-devel] PROBLEM: [x86] Running ptpd2 using an Intel 82572EI (e1000e) leads to a kernel oops (3.12.26) [added e1000-devel] Hi, On Mon, Aug 4, 2014, at 14:26, Koehrer Mathias (ETAS/ESW5) wrote: > [1.] One line summary of the problem: > Running ptpd2 using an Intel 82572EI (e1000e) leads to a kernel oops > (3.12.26) > > [2.] Full description of the problem/report: > I run the PTP daemon ptpd2 (http://ptpd.sourceforge.net/), version > 2.3.1 on a x86 PC using an Intel 82572EI NIC (driver e1000e). > The ptpd2 is started as > ptpd2 -i eth0 --masteronly --foreground --verbose I have another PC in > the same network that is running the PTP slave. > After a couple of seconds the kernel generates an Oops. > > Using a different network adapter works fine. > > Thanks for any support on this! > > [3.] Keywords (i.e., modules, networking, kernel): > PTP, networking, e1000e > > [4.] Kernel information > > [4.1.] Kernel version (from /proc/version): > Linux version 3.12.26-4 (user@rtpc) (gcc version 4.7.2 (Debian > 4.7.2-5) ) > #1 SMP PREEMPT Mon Aug 4 11:04:11 CEST 2014 > > [4.2.] Kernel .config file: > [...] > [ cut here ] > WARNING: CPU: 0 PID: 5358 at kernel/workqueue.c:1386 > __queue_work+0x18f/0x300() > Modules linked in: e100 mii e1000 nfsd exportfs nfs lockd sunrpc igb > i2c_algo_bit i2c_core dca bridge stp llc e1000e smsc47b397 coretemp > kvm_intel kvm usb_storage tg3 psmouse ptp pps_core libphy ehci_pci > pcspkr processor parport_pc parport thermal_sys hwmon reiserfs sg > sr_mod sd_mod cdrom ahci libahci microcode uhci_hcd ehci_hcd > CPU: 0 PID: 5358 Comm: ptpd2 Not tainted 3.12.26-4 #1 Hardware name: > Hewlett-Packard HP xw4600 Workstation/0AA0h, BIOS 786F3 > v01.13 06/25/2008 > f48dfad4 c07b2d07 f48dfb04 c0440e64 > c08ee514 > 14ee c08f4e3c 056a c045775f c045775f f5877100 > f501f900 > f5875e80 f48dfb14 c0440ea2 0009 f48dfb48 c045775f > f48dfb34 Call Trace: > [] dump_stack+0x4b/0x79 > [] warn_slowpath_common+0x84/0xa0 [] ? > __queue_work+0x18f/0x300 [] ? __queue_work+0x18f/0x300 > [] warn_slowpath_null+0x22/0x30 [] > __queue_work+0x18f/0x300 [] queue_work_on+0x3d/0x50 > [] schedule_work+0x15/0x20 [e1000e] [] > e1000_xmit_frame+0xc4a/0xcb0 [e1000e] Quick analysis so far: Looks like the socket enabled hw timestamping but the network card (from the lspci output below) is not capable of hw timestamping. queue_work thus gets fed an uninitialized work struct and bails out here. > [] ? harmonize_features+0x2b/0x1d0 [] > dev_hard_start_xmit+0x2c3/0x560 [] ? > sock_alloc_send_pskb+0x161/0x380 [] > sch_direct_xmit+0xa2/0x190 [] dev_queue_xmit+0x184/0x410 > [] ip_finish_output+0x1f1/0x3c0 [] > ip_mc_output+0x8f/0x140 [] ip_local_out+0x20/0x30 > [] ip_send_skb+0x1a/0x80 [] > udp_send_skb+0x1fa/0x280 [] udp_sendmsg+0x2a3/0x8b0 > [] ? ip_setup_cork+0xf0/0xf0 [] ? > dequeue_task_fair+0x211/0x660 [] ? > __enqueue_entity+0x78/0x80 [] inet_sendmsg+0x70/0xa0 > [] sock_sendmsg+0x62/0xa0 [] ? > _copy_from_user+0x35/0x50 [] SYSC_sendto+0xf1/0x130 > [] ? ptrace_do_notify+0x8a/0xa0 [] > SyS_sendto+0x2d/0x30 [] SyS_socketcall+0x1c8/0x300 > [] syscall_call+0x7/0x7 ---[ end trace d87b1e283af6ddc9 ]--- > [7.] A small shell script or example program which triggers the > problem (if possible) > ptpd2 -i eth0 --masteronly --foreground --verbose > > 34:00.0 Ethernet controller: Intel Corporation 82572EI Gigabit > Ethernet Controller (Copper) (rev 06) Bye, Hannes -- Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk ___ E1000-devel mailing list e1000-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: PROBLEM: [x86] Running ptpd2 using an Intel 82572EI (e1000e) leads to a kernel oops (3.12.26)
> -Original Message-
> From: Nick Krause [mailto:xerofo...@gmail.com]
> Sent: Wednesday, August 06, 2014 2:37 PM
> To: Koehrer Mathias (ETAS/ESW5)
> Cc: linux-kernel@vger.kernel.org; net...@vger.kernel.org
> Subject: Re: PROBLEM: [x86] Running ptpd2 using an Intel 82572EI (e1000e)
> leads
> to a kernel oops (3.12.26)
>
> On Wed, Aug 6, 2014 at 8:17 AM, Koehrer Mathias (ETAS/ESW5)
> wrote:
> >> Mathias ,
> >> After tracing this it seems to be either one of two things based on
> >> the warn on messages in
> >> __queue_work. Normally it would be because of this line.
> >> WARN_ON_ONCE(!irqs_disabled());.
> >> However it would also be the second warn on, If you want I can send a
> >> simple patch with
> >> a printk statement to see which one it is.
> >> Regards Nick
> > That would be helpful. I can try to see what's happening.
> >
> > Regards
> >
> > Mathias
> Sorry for the late reply but couldn't figure out how to print the flags.
> Cheers Nick
Hi Nick,
thanks for the patch.
I applied it, however there was no change at all in the output.
My impression is, that it has to do with the network driver as everything works
fine if I am using a different NIC.
When I apply the patch
Index: linux-3.12.26/drivers/net/ethernet/intel/e1000e/netdev.c
===
--- linux-3.12.26.orig/drivers/net/ethernet/intel/e1000e/netdev.c
2014-08-04 10:56:56.0 +0200
+++ linux-3.12.26/drivers/net/ethernet/intel/e1000e/netdev.c2014-08-06
15:15:42.0 +0200
@@ -5549,7 +5549,8 @@
count = e1000_tx_map(tx_ring, skb, first, adapter->tx_fifo_limit,
nr_frags);
if (count) {
- if (unlikely((skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP) &&
+ if ((adapter->flags & FLAG_HAS_HW_TIMESTAMP) &&
+unlikely((skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP)
&&
!adapter->tx_hwtstamp_skb)) {
skb_shinfo(skb)->tx_flags |= SKBTX_IN_PROGRESS;
tx_flags |= E1000_TX_FLAGS_HWTSTAMP;
to the e1000e driver it seems to work...
This makes sense as the work queue is only created if "adapter->flags &
FLAG_HAS_HW_TIMESTAMP" is set.
With this NIC this is *not* the case.
Regards
Mathias
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: PROBLEM: [x86] Running ptpd2 using an Intel 82572EI (e1000e) leads to a kernel oops (3.12.26)
> Mathias ,
> After tracing this it seems to be either one of two things based on
> the warn on messages in
> __queue_work. Normally it would be because of this line.
> WARN_ON_ONCE(!irqs_disabled());.
> However it would also be the second warn on, If you want I can send a
> simple patch with
> a printk statement to see which one it is.
> Regards Nick
That would be helpful. I can try to see what's happening.
Regards
Mathias
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
RE: PROBLEM: [x86] Running ptpd2 using an Intel 82572EI (e1000e) leads to a kernel oops (3.12.26)
> -Original Message- > From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org] On > Behalf Of Heinz Diehl > Sent: Wednesday, August 06, 2014 10:33 AM > To: linux-kernel@vger.kernel.org > Cc: Koehrer Mathias (ETAS/ESW5); net...@vger.kernel.org > Subject: Re: PROBLEM: [x86] Running ptpd2 using an Intel 82572EI (e1000e) > leads > to a kernel oops (3.12.26) > > On 06.08.2014, Nick Krause wrote: > > > I am going to have to ask a few questions first, what distribution is > > and is this a vanilla kernel? > > Read his mail. He's on Debian, and it's a Debian kernel. I am on Debian. But it is a vanilla kernel from kernel.org without any additional patches. > > > If it's not just send the report to the distribution developers. > > His mail is quite sure a copy from the data entered into the Debian > bugtracker. No. I've never entered this into the Debian bugtracker. Mathias -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: PROBLEM: [x86] Running ptpd2 using an Intel 82572EI (e1000e) leads to a kernel oops (3.12.26)
Hey Nick, > Hey Koehrer Mathias, > I am going to have to ask a few questions first, what distribution is > and is this a vanilla kernel? > If it's not just send the report to the distribution developers. > Regards Nick The distribution is Debian stable (Wheezy, V7.6). However, the kernel is a pure vanilla kernel. Regards Mathias
Re: PROBLEM: [x86] Running ptpd2 using an Intel 82572EI (e1000e) leads to a kernel oops (3.12.26)
[added e1000-devel] Hi, On Mon, Aug 4, 2014, at 14:26, Koehrer Mathias (ETAS/ESW5) wrote: > [1.] One line summary of the problem: > Running ptpd2 using an Intel 82572EI (e1000e) leads to a kernel oops > (3.12.26) > > [2.] Full description of the problem/report: > I run the PTP daemon ptpd2 (http://ptpd.sourceforge.net/), version 2.3.1 > on a x86 PC using an Intel 82572EI NIC (driver e1000e). > The ptpd2 is started as > ptpd2 -i eth0 --masteronly --foreground --verbose > I have another PC in the same network that is running the PTP slave. > After a couple of seconds the kernel generates an Oops. > > Using a different network adapter works fine. > > Thanks for any support on this! > > [3.] Keywords (i.e., modules, networking, kernel): > PTP, networking, e1000e > > [4.] Kernel information > > [4.1.] Kernel version (from /proc/version): > Linux version 3.12.26-4 (user@rtpc) (gcc version 4.7.2 (Debian 4.7.2-5) ) > #1 SMP PREEMPT Mon Aug 4 11:04:11 CEST 2014 > > [4.2.] Kernel .config file: > [...] > [ cut here ] > WARNING: CPU: 0 PID: 5358 at kernel/workqueue.c:1386 > __queue_work+0x18f/0x300() > Modules linked in: e100 mii e1000 nfsd exportfs nfs lockd sunrpc igb > i2c_algo_bit i2c_core dca bridge stp llc e1000e smsc47b397 coretemp > kvm_intel kvm usb_storage tg3 psmouse ptp pps_core libphy ehci_pci pcspkr > processor parport_pc parport thermal_sys hwmon reiserfs sg sr_mod sd_mod > cdrom ahci libahci microcode uhci_hcd ehci_hcd > CPU: 0 PID: 5358 Comm: ptpd2 Not tainted 3.12.26-4 #1 > Hardware name: Hewlett-Packard HP xw4600 Workstation/0AA0h, BIOS 786F3 > v01.13 06/25/2008 > f48dfad4 c07b2d07 f48dfb04 c0440e64 c08ee514 > 14ee c08f4e3c 056a c045775f c045775f f5877100 f501f900 > f5875e80 f48dfb14 c0440ea2 0009 f48dfb48 c045775f f48dfb34 > Call Trace: > [] dump_stack+0x4b/0x79 > [] warn_slowpath_common+0x84/0xa0 > [] ? __queue_work+0x18f/0x300 > [] ? __queue_work+0x18f/0x300 > [] warn_slowpath_null+0x22/0x30 > [] __queue_work+0x18f/0x300 > [] queue_work_on+0x3d/0x50 > [] schedule_work+0x15/0x20 [e1000e] > [] e1000_xmit_frame+0xc4a/0xcb0 [e1000e] Quick analysis so far: Looks like the socket enabled hw timestamping but the network card (from the lspci output below) is not capable of hw timestamping. queue_work thus gets fed an uninitialized work struct and bails out here. > [] ? harmonize_features+0x2b/0x1d0 > [] dev_hard_start_xmit+0x2c3/0x560 > [] ? sock_alloc_send_pskb+0x161/0x380 > [] sch_direct_xmit+0xa2/0x190 > [] dev_queue_xmit+0x184/0x410 > [] ip_finish_output+0x1f1/0x3c0 > [] ip_mc_output+0x8f/0x140 > [] ip_local_out+0x20/0x30 > [] ip_send_skb+0x1a/0x80 > [] udp_send_skb+0x1fa/0x280 > [] udp_sendmsg+0x2a3/0x8b0 > [] ? ip_setup_cork+0xf0/0xf0 > [] ? dequeue_task_fair+0x211/0x660 > [] ? __enqueue_entity+0x78/0x80 > [] inet_sendmsg+0x70/0xa0 > [] sock_sendmsg+0x62/0xa0 > [] ? _copy_from_user+0x35/0x50 > [] SYSC_sendto+0xf1/0x130 > [] ? ptrace_do_notify+0x8a/0xa0 > [] SyS_sendto+0x2d/0x30 > [] SyS_socketcall+0x1c8/0x300 > [] syscall_call+0x7/0x7 > ---[ end trace d87b1e283af6ddc9 ]--- > [7.] A small shell script or example program which triggers the > problem (if possible) > ptpd2 -i eth0 --masteronly --foreground --verbose > > 34:00.0 Ethernet controller: Intel Corporation 82572EI Gigabit Ethernet > Controller (Copper) (rev 06) Bye, Hannes -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: [x86] Running ptpd2 using an Intel 82572EI (e1000e) leads to a kernel oops (3.12.26)
On 06.08.2014, Nick Krause wrote: > I am going to have to ask a few questions first, what distribution is > and is this a vanilla kernel? Read his mail. He's on Debian, and it's a Debian kernel. > If it's not just send the report to the distribution developers. His mail is quite sure a copy from the data entered into the Debian bugtracker. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
PROBLEM: [x86] Running ptpd2 using an Intel 82572EI (e1000e) leads to a kernel oops (3.12.26)
[1.] One line summary of the problem: Running ptpd2 using an Intel 82572EI (e1000e) leads to a kernel oops (3.12.26) [2.] Full description of the problem/report: I run the PTP daemon ptpd2 (http://ptpd.sourceforge.net/), version 2.3.1 on a x86 PC using an Intel 82572EI NIC (driver e1000e). The ptpd2 is started as ptpd2 -i eth0 --masteronly --foreground --verbose I have another PC in the same network that is running the PTP slave. After a couple of seconds the kernel generates an Oops. Using a different network adapter works fine. Thanks for any support on this! [3.] Keywords (i.e., modules, networking, kernel): PTP, networking, e1000e [4.] Kernel information [4.1.] Kernel version (from /proc/version): Linux version 3.12.26-4 (user@rtpc) (gcc version 4.7.2 (Debian 4.7.2-5) ) #1 SMP PREEMPT Mon Aug 4 11:04:11 CEST 2014 [4.2.] Kernel .config file: # # Automatically generated file; DO NOT EDIT. # Linux/x86 3.12.26 Kernel Configuration # # CONFIG_64BIT is not set CONFIG_X86_32=y CONFIG_X86=y CONFIG_INSTRUCTION_DECODER=y CONFIG_OUTPUT_FORMAT="elf32-i386" CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig" CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_MMU=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_BUG=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_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_ARCH_WANT_HUGE_PMD_SHARE=y CONFIG_ARCH_WANT_GENERAL_HUGETLB=y # CONFIG_ZONE_DMA32 is not set # CONFIG_AUDIT_ARCH is not set CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_X86_32_SMP=y CONFIG_X86_HT=y CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-ecx -fcall-saved-edx" 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_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE="" # CONFIG_COMPILE_TEST is not set CONFIG_LOCALVERSION="-4" # 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_HAVE_KERNEL_LZ4=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_KERNEL_LZ4 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 is not set # CONFIG_AUDIT is not set # # IRQ subsystem # 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_KTIME_SCALAR=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_HZ_PERIODIC=y # CONFIG_NO_HZ_IDLE is not set # CONFIG_NO_HZ is not set CONFIG_HIGH_RES_TIMERS=y # # CPU/Task time and stats accounting # CONFIG_TICK_CPU_ACCOUNTING=y # CONFIG_IRQ_TIME_ACCOUNTING is not set CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y CONFIG_TASKSTATS=y CONFIG_TASK_DELAY_ACCT=y # CONFIG_TASK_XACCT is not set # # RCU Subsystem # CONFIG_TREE_PREEMPT_RCU=y CONFIG_PREEMPT_RCU=y CONFIG_RCU_STALL_COMMON=y CONFIG_RCU_FANOUT=32 CONFIG_RCU_FANOUT_LEAF=16 # CONFIG_RCU_FANOUT_EXACT is not set # CONFIG_TREE_RCU_TRACE is not set # CONFIG_RCU_BOOST is not set # CONFIG_RCU_NOCB_CPU is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y 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_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 is not set CONFIG_CGROUP_PERF=y CONFIG_CGROUP_SCHED=y CONFIG_FAIR_GROUP_SCHED=y CONFIG_CFS_BANDWIDTH=y # CONFIG_RT_GROUP_SCHED is not set 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_USER_NS=y CONFIG_PID_NS=y CONFIG_NET_NS=y CONFIG_UIDGID_STRICT_TYPE_CHECKS=y CONFIG_SCHED_AUTOGROUP=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_RD_LZ4=y # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CON
