Public bug reported: We have a Ubuntu Raring server running kernel 3.8.13-030813-generic
We use iscsi to consume LUNs out of a storage array in the backend. When the server is loaded we run into the issue of iSCSI device discovery failing to scan partitions on LUNs with Jul 30 12:12:01 srv1 kernel: [101661.119322] kworker/u:20: page allocation failure: order:4, mode:0x10c0d0 Jul 30 12:12:01 srv1 kernel: [101661.119327] Pid: 32539, comm: kworker/u:20 Tainted: GF W O 3.8.13-030813-generic #201305111843 Jul 30 12:12:01 srv1 kernel: [101661.119329] Call Trace: Jul 30 12:12:01 srv1 kernel: [101661.119340] [<ffffffff8113ac96>] warn_alloc_failed+0xf6/0x150 Jul 30 12:12:01 srv1 kernel: [101661.119345] [<ffffffff8113e156>] ? drain_local_pages+0x16/0x20 Jul 30 12:12:01 srv1 kernel: [101661.119350] [<ffffffff810bc8e0>] ? on_each_cpu_mask+0x50/0x70 Jul 30 12:12:01 srv1 kernel: [101661.119354] [<ffffffff8113e8ce>] __alloc_pages_nodemask+0x76e/0x9b0 Jul 30 12:12:01 srv1 kernel: [101661.119359] [<ffffffff8117af3a>] alloc_pages_current+0xba/0x170 Jul 30 12:12:01 srv1 kernel: [101661.119363] [<ffffffff81139aae>] __get_free_pages+0xe/0x40 Jul 30 12:12:01 srv1 kernel: [101661.119367] [<ffffffff8118427f>] kmalloc_order_trace+0x3f/0xd0 Jul 30 12:12:01 srv1 kernel: [101661.119373] [<ffffffff8133af30>] check_partition+0x30/0x200 Jul 30 12:12:01 srv1 kernel: [101661.119376] [<ffffffff8133ac58>] rescan_partitions+0xb8/0x2b0 Jul 30 12:12:01 srv1 kernel: [101661.119381] [<ffffffff811d52cb>] __blkdev_get+0x39b/0x480 Jul 30 12:12:01 srv1 kernel: [101661.119386] [<ffffffff8107f7eb>] ? bit_waitqueue+0x1b/0xc0 Jul 30 12:12:01 srv1 kernel: [101661.119389] [<ffffffff811d540e>] blkdev_get+0x5e/0x1e0 Jul 30 12:12:01 srv1 kernel: [101661.119393] [<ffffffff81337a82>] register_disk+0x172/0x190 Jul 30 12:12:01 srv1 kernel: [101661.119396] [<ffffffff81338334>] add_disk+0xb4/0x230 Jul 30 12:12:01 srv1 kernel: [101661.119403] [<ffffffff814bba76>] sd_probe_async+0x126/0x220 Jul 30 12:12:01 srv1 kernel: [101661.119407] [<ffffffff8108704f>] async_run_entry_fn+0xaf/0x1d0 Jul 30 12:12:01 srv1 kernel: [101661.119410] [<ffffffff81078b81>] process_one_work+0x141/0x490 Jul 30 12:12:01 srv1 kernel: [101661.119413] [<ffffffff81079b48>] worker_thread+0x168/0x400 Jul 30 12:12:01 srv1 kernel: [101661.119416] [<ffffffff810799e0>] ? manage_workers+0x120/0x120 Jul 30 12:12:01 srv1 kernel: [101661.119419] [<ffffffff8107f050>] kthread+0xc0/0xd0 Jul 30 12:12:01 srv1 kernel: [101661.119423] [<ffffffff8107ef90>] ? flush_kthread_worker+0xb0/0xb0 Jul 30 12:12:01 srv1 kernel: [101661.119429] [<ffffffff816f61ec>] ret_from_fork+0x7c/0xb0 Jul 30 12:12:01 srv1 kernel: [101661.119432] [<ffffffff8107ef90>] ? flush_kthread_worker+0xb0/0xb0 We see this issue is fixed in 3.9 kernels with the following commit https://github.com/torvalds/linux/commit/ac2e5327a5e4f6477afc6a3b3b0dc6e0476d71d4 Kindly request you to pull this patch into Ubuntu raring stable 3.8 kernel version as detailed in http://lwn.net/Articles/550581/ Thank You ** Affects: linux (Ubuntu) Importance: Undecided Status: Incomplete ** Tags: raring -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1206837 Title: Ubuntu Raring Kernel - pull patch block/partitions: optimize memory allocation in check_partition Status in “linux” package in Ubuntu: Incomplete Bug description: We have a Ubuntu Raring server running kernel 3.8.13-030813-generic We use iscsi to consume LUNs out of a storage array in the backend. When the server is loaded we run into the issue of iSCSI device discovery failing to scan partitions on LUNs with Jul 30 12:12:01 srv1 kernel: [101661.119322] kworker/u:20: page allocation failure: order:4, mode:0x10c0d0 Jul 30 12:12:01 srv1 kernel: [101661.119327] Pid: 32539, comm: kworker/u:20 Tainted: GF W O 3.8.13-030813-generic #201305111843 Jul 30 12:12:01 srv1 kernel: [101661.119329] Call Trace: Jul 30 12:12:01 srv1 kernel: [101661.119340] [<ffffffff8113ac96>] warn_alloc_failed+0xf6/0x150 Jul 30 12:12:01 srv1 kernel: [101661.119345] [<ffffffff8113e156>] ? drain_local_pages+0x16/0x20 Jul 30 12:12:01 srv1 kernel: [101661.119350] [<ffffffff810bc8e0>] ? on_each_cpu_mask+0x50/0x70 Jul 30 12:12:01 srv1 kernel: [101661.119354] [<ffffffff8113e8ce>] __alloc_pages_nodemask+0x76e/0x9b0 Jul 30 12:12:01 srv1 kernel: [101661.119359] [<ffffffff8117af3a>] alloc_pages_current+0xba/0x170 Jul 30 12:12:01 srv1 kernel: [101661.119363] [<ffffffff81139aae>] __get_free_pages+0xe/0x40 Jul 30 12:12:01 srv1 kernel: [101661.119367] [<ffffffff8118427f>] kmalloc_order_trace+0x3f/0xd0 Jul 30 12:12:01 srv1 kernel: [101661.119373] [<ffffffff8133af30>] check_partition+0x30/0x200 Jul 30 12:12:01 srv1 kernel: [101661.119376] [<ffffffff8133ac58>] rescan_partitions+0xb8/0x2b0 Jul 30 12:12:01 srv1 kernel: [101661.119381] [<ffffffff811d52cb>] __blkdev_get+0x39b/0x480 Jul 30 12:12:01 srv1 kernel: [101661.119386] [<ffffffff8107f7eb>] ? bit_waitqueue+0x1b/0xc0 Jul 30 12:12:01 srv1 kernel: [101661.119389] [<ffffffff811d540e>] blkdev_get+0x5e/0x1e0 Jul 30 12:12:01 srv1 kernel: [101661.119393] [<ffffffff81337a82>] register_disk+0x172/0x190 Jul 30 12:12:01 srv1 kernel: [101661.119396] [<ffffffff81338334>] add_disk+0xb4/0x230 Jul 30 12:12:01 srv1 kernel: [101661.119403] [<ffffffff814bba76>] sd_probe_async+0x126/0x220 Jul 30 12:12:01 srv1 kernel: [101661.119407] [<ffffffff8108704f>] async_run_entry_fn+0xaf/0x1d0 Jul 30 12:12:01 srv1 kernel: [101661.119410] [<ffffffff81078b81>] process_one_work+0x141/0x490 Jul 30 12:12:01 srv1 kernel: [101661.119413] [<ffffffff81079b48>] worker_thread+0x168/0x400 Jul 30 12:12:01 srv1 kernel: [101661.119416] [<ffffffff810799e0>] ? manage_workers+0x120/0x120 Jul 30 12:12:01 srv1 kernel: [101661.119419] [<ffffffff8107f050>] kthread+0xc0/0xd0 Jul 30 12:12:01 srv1 kernel: [101661.119423] [<ffffffff8107ef90>] ? flush_kthread_worker+0xb0/0xb0 Jul 30 12:12:01 srv1 kernel: [101661.119429] [<ffffffff816f61ec>] ret_from_fork+0x7c/0xb0 Jul 30 12:12:01 srv1 kernel: [101661.119432] [<ffffffff8107ef90>] ? flush_kthread_worker+0xb0/0xb0 We see this issue is fixed in 3.9 kernels with the following commit https://github.com/torvalds/linux/commit/ac2e5327a5e4f6477afc6a3b3b0dc6e0476d71d4 Kindly request you to pull this patch into Ubuntu raring stable 3.8 kernel version as detailed in http://lwn.net/Articles/550581/ Thank You To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1206837/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
