* [2.6.27-rc6, patch] fix SWIOTLB oops... @ 2008-09-10 20:07 Daniel J Blueman 2008-09-11 13:29 ` FUJITA Tomonori 0 siblings, 1 reply; 5+ messages in thread From: Daniel J Blueman @ 2008-09-10 20:07 UTC (permalink / raw) To: Linux Kernel, Linus Torvalds With SWIOTLB being enabled and straight-forward page allocation failure [1], the swiotlb_alloc_coherent fall-back path hits an issue [2], resulting in my webcam failing to work. At the time of oops, RDI is clearly a pointer to a structure which has arrived as NULL, leading to the typo in swiotlb_map_single's callsite arguments. Correctly passing the device structure [3] addresses the issue and gets my webcam working again (the allocation failure still occuring). Please apply, Daniel --- [1] skype: page allocation failure. order:3, mode:0x1 Pid: 5895, comm: skype Not tainted 2.6.27-rc6-235c-debug #1 Call Trace: [<ffffffff802b7cf0>] __alloc_pages_internal+0x4a0/0x5d0 [<ffffffff802d5ddd>] alloc_pages_current+0xad/0x110 [<ffffffff802b4ccd>] __get_free_pages+0x1d/0x60 [<ffffffff8046cd39>] swiotlb_alloc_coherent+0x49/0x180 [<ffffffff80212731>] dma_alloc_coherent+0x281/0x310 [<ffffffff805621c0>] hcd_buffer_alloc+0x50/0x90 [<ffffffff805547fd>] usb_buffer_alloc+0x2d/0x40 [<ffffffffa0056763>] uvc_alloc_urb_buffers+0x53/0xf0 [uvcvideo] [<ffffffffa0056958>] uvc_init_video+0x158/0x3e0 [uvcvideo] [<ffffffffa0056c17>] uvc_video_enable+0x37/0x80 [uvcvideo] [<ffffffffa0055853>] uvc_v4l2_do_ioctl+0x723/0x1260 [uvcvideo] [<ffffffff8026dd61>] ? trace_hardirqs_off_caller+0x21/0xc0 [<ffffffff8026dd61>] ? trace_hardirqs_off_caller+0x21/0xc0 [<ffffffffa0032c9f>] video_usercopy+0x19f/0x390 [videodev] [<ffffffffa0055130>] ? uvc_v4l2_do_ioctl+0x0/0x1260 [uvcvideo] [<ffffffff8026d0ce>] ? put_lock_stats+0xe/0x30 [<ffffffffa0054dad>] uvc_v4l2_ioctl+0x4d/0x80 [uvcvideo] [<ffffffffa0045083>] native_ioctl+0x83/0x90 [compat_ioctl32] [<ffffffffa004534e>] v4l_compat_ioctl32+0x2be/0x1da4 [compat_ioctl32] [<ffffffff806aad21>] ? do_page_fault+0x3d1/0xae0 [<ffffffff80270ccd>] ? trace_hardirqs_on+0xd/0x10 [<ffffffff80270c59>] ? trace_hardirqs_on_caller+0x149/0x1b0 [<ffffffff80270ccd>] ? trace_hardirqs_on+0xd/0x10 [<ffffffff80329afa>] compat_sys_ioctl+0x8a/0x3c0 [<ffffffff806a700d>] ? trace_hardirqs_off_thunk+0x3a/0x3c [<ffffffff8022f816>] sysenter_dispatch+0x7/0x2c [<ffffffff806a6fce>] ? trace_hardirqs_on_thunk+0x3a/0x3f Mem-Info: Node 0 DMA per-cpu: CPU 0: hi: 0, btch: 1 usd: 0 CPU 1: hi: 0, btch: 1 usd: 0 Node 0 DMA32 per-cpu: CPU 0: hi: 186, btch: 31 usd: 3 CPU 1: hi: 186, btch: 31 usd: 0 Node 0 Normal per-cpu: CPU 0: hi: 186, btch: 31 usd: 23 CPU 1: hi: 186, btch: 31 usd: 179 Active:78545 inactive:48683 dirty:31 writeback:0 unstable:2 free:830202 slab:17516 mapped:17473 pagetables:3496 bounce:0 Node 0 DMA free:36kB min:28kB low:32kB high:40kB active:0kB inactive:0kB present:15156kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 3207 3956 3956 Node 0 DMA32 free:3197192kB min:6512kB low:8140kB high:9768kB active:0kB inactive:0kB present:3284896kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 0 748 748 Node 0 Normal free:123580kB min:1516kB low:1892kB high:2272kB active:314180kB inactive:194732kB present:766464kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 0 0 0 Node 0 DMA: 1*4kB 0*8kB 0*16kB 1*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 36kB Node 0 DMA32: 4*4kB 3*8kB 2*16kB 3*32kB 4*64kB 5*128kB 3*256kB 5*512kB 4*1024kB 5*2048kB 776*4096kB = 3197224kB Node 0 Normal: 14*4kB 14*8kB 8*16kB 6*32kB 1*64kB 3*128kB 3*256kB 2*512kB 4*1024kB 1*2048kB 28*4096kB = 123560kB 64847 total pagecache pages 0 pages in swap cache Swap cache stats: add 0, delete 0, find 0/0 Free swap = 502752kB Total swap = 502752kB 1048576 pages RAM 52120 pages reserved 71967 pages shared 143004 pages non-shared --- [2] BUG: unable to handle kernel NULL pointer dereference at 00000000000002c8 IP: [<ffffffff8046c84c>] map_single+0x1c/0x280 PGD 10e54e067 PUD 10e595067 PMD 0 Oops: 0000 [1] PREEMPT SMP DEBUG_PAGEALLOC CPU 0 Modules linked in: kvm_intel kvm microcode uvcvideo compat_ioctl32 videodev v4l1_compat shpchp pci_hotplug Pid: 5895, comm: skype Not tainted 2.6.27-rc6-235c-debug #1 RIP: 0010:[<ffffffff8046c84c>] [<ffffffff8046c84c>] map_single+0x1c/0x280 RSP: 0018:ffff88010e78d988 EFLAGS: 00210296 RAX: 0000780000000000 RBX: 0000000000000000 RCX: 0000000000000002 RDX: 0000000000005000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffff88010e78d9e8 R08: 0000000000000000 R09: 0000000000000001 R10: ffff88010e78d698 R11: 0000000000000001 R12: 0000000000000002 R13: 0000000000000000 R14: 0000000000005000 R15: ffff88012f1c9968 FS: 0000000000000000(0000) GS:ffffffff80a6cdc0(0063) knlGS:00000000f6355b90 CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033 CR2: 00000000000002c8 CR3: 000000010e57d000 CR4: 00000000000026e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process skype (pid: 5895, threadinfo ffff88010e78c000, task ffff88012b9cc460) Stack: 0000000200000000 0000000000005000 0000000000000000 0000000000000000 00000000000017b8 0000000000000000 ffff88010e78d9c8 0000000000000000 0000000000000002 0000000000000000 0000000000005000 ffff88012f1c9968 Call Trace: [<ffffffff8046cbb0>] swiotlb_map_single_attrs+0x60/0xf0 [<ffffffff8046cc4c>] swiotlb_map_single+0xc/0x10 [<ffffffff8046cdee>] swiotlb_alloc_coherent+0xfe/0x180 [<ffffffff80212731>] dma_alloc_coherent+0x281/0x310 [<ffffffff805621c0>] hcd_buffer_alloc+0x50/0x90 [<ffffffff805547fd>] usb_buffer_alloc+0x2d/0x40 [<ffffffffa0056763>] uvc_alloc_urb_buffers+0x53/0xf0 [uvcvideo] [<ffffffffa0056958>] uvc_init_video+0x158/0x3e0 [uvcvideo] [<ffffffffa0056c17>] uvc_video_enable+0x37/0x80 [uvcvideo] [<ffffffffa0055853>] uvc_v4l2_do_ioctl+0x723/0x1260 [uvcvideo] [<ffffffff8026dd61>] ? trace_hardirqs_off_caller+0x21/0xc0 [<ffffffff8026dd61>] ? trace_hardirqs_off_caller+0x21/0xc0 [<ffffffffa0032c9f>] video_usercopy+0x19f/0x390 [videodev] [<ffffffffa0055130>] ? uvc_v4l2_do_ioctl+0x0/0x1260 [uvcvideo] [<ffffffff8026d0ce>] ? put_lock_stats+0xe/0x30 [<ffffffffa0054dad>] uvc_v4l2_ioctl+0x4d/0x80 [uvcvideo] [<ffffffffa0045083>] native_ioctl+0x83/0x90 [compat_ioctl32] [<ffffffffa004534e>] v4l_compat_ioctl32+0x2be/0x1da4 [compat_ioctl32] [<ffffffff806aad21>] ? do_page_fault+0x3d1/0xae0 [<ffffffff80270ccd>] ? trace_hardirqs_on+0xd/0x10 [<ffffffff80270c59>] ? trace_hardirqs_on_caller+0x149/0x1b0 [<ffffffff80270ccd>] ? trace_hardirqs_on+0xd/0x10 [<ffffffff80329afa>] compat_sys_ioctl+0x8a/0x3c0 [<ffffffff806a700d>] ? trace_hardirqs_off_thunk+0x3a/0x3c [<ffffffff8022f816>] sysenter_dispatch+0x7/0x2c [<ffffffff806a6fce>] ? trace_hardirqs_on_thunk+0x3a/0x3f Code: 45 31 c0 48 89 e5 e8 a4 ff ff ff c9 c3 66 90 55 48 89 e5 41 57 41 56 41 55 41 54 53 48 83 ec 38 48 89 75 b0 48 89 55 a8 89 4d a4 <48> 8b 87 c8 02 00 00 48 85 c0 0f 84 1c 02 00 00 48 8b 58 08 48 RIP [<ffffffff8046c84c>] map_single+0x1c/0x280 RSP <ffff88010e78d988> CR2: 00000000000002c8 ---[ end trace 5d15baeeb7025a0e ]--- --- [3] ffffffff8046c830 <map_single>: map_single(): /store/kernel/linux/lib/swiotlb.c:291 ffffffff8046c830: 55 push %rbp ffffffff8046c831: 48 89 e5 mov %rsp,%rbp ffffffff8046c834: 41 57 push %r15 ffffffff8046c836: 41 56 push %r14 ffffffff8046c838: 41 55 push %r13 ffffffff8046c83a: 41 54 push %r12 ffffffff8046c83c: 53 push %rbx ffffffff8046c83d: 48 83 ec 38 sub $0x38,%rsp ffffffff8046c841: 48 89 75 b0 mov %rsi,-0x50(%rbp) ffffffff8046c845: 48 89 55 a8 mov %rdx,-0x58(%rbp) ffffffff8046c849: 89 4d a4 mov %ecx,-0x5c(%rbp) dma_get_seg_boundary(): /store/kernel/linux/include/linux/dma-mapping.h:80 ffffffff8046c84c: 48 8b 87 c8 02 00 00 mov 0x2c8(%rdi),%rax <---- --- [4] Fix back-off path when memory allocation fails Signed-off-by: Daniel J Blueman <daniel.blueman@gmail.com> diff --git a/lib/swiotlb.c b/lib/swiotlb.c index 977edbd..8826fdf 100644 --- a/lib/swiotlb.c +++ b/lib/swiotlb.c @@ -491,7 +491,7 @@ swiotlb_alloc_coherent(struct device *hwdev, size_t size, * the lowest available address range. */ dma_addr_t handle; - handle = swiotlb_map_single(NULL, NULL, size, DMA_FROM_DEVICE); + handle = swiotlb_map_single(hwdev, NULL, size, DMA_FROM_DEVICE); if (swiotlb_dma_mapping_error(hwdev, handle)) return NULL; -- Daniel J Blueman ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [2.6.27-rc6, patch] fix SWIOTLB oops... 2008-09-10 20:07 [2.6.27-rc6, patch] fix SWIOTLB oops Daniel J Blueman @ 2008-09-11 13:29 ` FUJITA Tomonori 2008-09-13 17:53 ` Daniel J Blueman 0 siblings, 1 reply; 5+ messages in thread From: FUJITA Tomonori @ 2008-09-11 13:29 UTC (permalink / raw) To: daniel.blueman, mingo; +Cc: linux-kernel, torvalds On Wed, 10 Sep 2008 21:07:55 +0100 "Daniel J Blueman" <daniel.blueman@gmail.com> wrote: > With SWIOTLB being enabled and straight-forward page allocation > failure [1], the swiotlb_alloc_coherent fall-back path hits an issue > [2], resulting in my webcam failing to work. > > At the time of oops, RDI is clearly a pointer to a structure which has > arrived as NULL, leading to the typo in swiotlb_map_single's callsite > arguments. > > Correctly passing the device structure [3] addresses the issue and > gets my webcam working again (the allocation failure still occuring). > > Please apply, > Daniel > > --- [1] > > skype: page allocation failure. order:3, mode:0x1 > Pid: 5895, comm: skype Not tainted 2.6.27-rc6-235c-debug #1 > > Call Trace: > [<ffffffff802b7cf0>] __alloc_pages_internal+0x4a0/0x5d0 > [<ffffffff802d5ddd>] alloc_pages_current+0xad/0x110 > [<ffffffff802b4ccd>] __get_free_pages+0x1d/0x60 > [<ffffffff8046cd39>] swiotlb_alloc_coherent+0x49/0x180 > [<ffffffff80212731>] dma_alloc_coherent+0x281/0x310 > [<ffffffff805621c0>] hcd_buffer_alloc+0x50/0x90 > [<ffffffff805547fd>] usb_buffer_alloc+0x2d/0x40 > [<ffffffffa0056763>] uvc_alloc_urb_buffers+0x53/0xf0 [uvcvideo] > [<ffffffffa0056958>] uvc_init_video+0x158/0x3e0 [uvcvideo] > [<ffffffffa0056c17>] uvc_video_enable+0x37/0x80 [uvcvideo] > [<ffffffffa0055853>] uvc_v4l2_do_ioctl+0x723/0x1260 [uvcvideo] > [<ffffffff8026dd61>] ? trace_hardirqs_off_caller+0x21/0xc0 > [<ffffffff8026dd61>] ? trace_hardirqs_off_caller+0x21/0xc0 > [<ffffffffa0032c9f>] video_usercopy+0x19f/0x390 [videodev] > [<ffffffffa0055130>] ? uvc_v4l2_do_ioctl+0x0/0x1260 [uvcvideo] > [<ffffffff8026d0ce>] ? put_lock_stats+0xe/0x30 > [<ffffffffa0054dad>] uvc_v4l2_ioctl+0x4d/0x80 [uvcvideo] > [<ffffffffa0045083>] native_ioctl+0x83/0x90 [compat_ioctl32] > [<ffffffffa004534e>] v4l_compat_ioctl32+0x2be/0x1da4 [compat_ioctl32] > [<ffffffff806aad21>] ? do_page_fault+0x3d1/0xae0 > [<ffffffff80270ccd>] ? trace_hardirqs_on+0xd/0x10 > [<ffffffff80270c59>] ? trace_hardirqs_on_caller+0x149/0x1b0 > [<ffffffff80270ccd>] ? trace_hardirqs_on+0xd/0x10 > [<ffffffff80329afa>] compat_sys_ioctl+0x8a/0x3c0 > [<ffffffff806a700d>] ? trace_hardirqs_off_thunk+0x3a/0x3c > [<ffffffff8022f816>] sysenter_dispatch+0x7/0x2c > [<ffffffff806a6fce>] ? trace_hardirqs_on_thunk+0x3a/0x3f > > Mem-Info: > Node 0 DMA per-cpu: > CPU 0: hi: 0, btch: 1 usd: 0 > CPU 1: hi: 0, btch: 1 usd: 0 > Node 0 DMA32 per-cpu: > CPU 0: hi: 186, btch: 31 usd: 3 > CPU 1: hi: 186, btch: 31 usd: 0 > Node 0 Normal per-cpu: > CPU 0: hi: 186, btch: 31 usd: 23 > CPU 1: hi: 186, btch: 31 usd: 179 > Active:78545 inactive:48683 dirty:31 writeback:0 unstable:2 > free:830202 slab:17516 mapped:17473 pagetables:3496 bounce:0 > Node 0 DMA free:36kB min:28kB low:32kB high:40kB active:0kB > inactive:0kB present:15156kB pages_scanned:0 all_unreclaimable? no > lowmem_reserve[]: 0 3207 3956 3956 > Node 0 DMA32 free:3197192kB min:6512kB low:8140kB high:9768kB > active:0kB inactive:0kB present:3284896kB pages_scanned:0 > all_unreclaimable? no > lowmem_reserve[]: 0 0 748 748 > Node 0 Normal free:123580kB min:1516kB low:1892kB high:2272kB > active:314180kB inactive:194732kB present:766464kB pages_scanned:0 > all_unreclaimable? no > lowmem_reserve[]: 0 0 0 0 > Node 0 DMA: 1*4kB 0*8kB 0*16kB 1*32kB 0*64kB 0*128kB 0*256kB 0*512kB > 0*1024kB 0*2048kB 0*4096kB = 36kB > Node 0 DMA32: 4*4kB 3*8kB 2*16kB 3*32kB 4*64kB 5*128kB 3*256kB 5*512kB > 4*1024kB 5*2048kB 776*4096kB = 3197224kB > Node 0 Normal: 14*4kB 14*8kB 8*16kB 6*32kB 1*64kB 3*128kB 3*256kB > 2*512kB 4*1024kB 1*2048kB 28*4096kB = 123560kB > 64847 total pagecache pages > 0 pages in swap cache > Swap cache stats: add 0, delete 0, find 0/0 > Free swap = 502752kB > Total swap = 502752kB > 1048576 pages RAM > 52120 pages reserved > 71967 pages shared > 143004 pages non-shared > > --- [2] > > BUG: unable to handle kernel NULL pointer dereference at 00000000000002c8 > IP: [<ffffffff8046c84c>] map_single+0x1c/0x280 > PGD 10e54e067 PUD 10e595067 PMD 0 > Oops: 0000 [1] PREEMPT SMP DEBUG_PAGEALLOC > CPU 0 > Modules linked in: kvm_intel kvm microcode uvcvideo compat_ioctl32 > videodev v4l1_compat shpchp pci_hotplug > Pid: 5895, comm: skype Not tainted 2.6.27-rc6-235c-debug #1 > RIP: 0010:[<ffffffff8046c84c>] [<ffffffff8046c84c>] map_single+0x1c/0x280 > RSP: 0018:ffff88010e78d988 EFLAGS: 00210296 > RAX: 0000780000000000 RBX: 0000000000000000 RCX: 0000000000000002 > RDX: 0000000000005000 RSI: 0000000000000000 RDI: 0000000000000000 > RBP: ffff88010e78d9e8 R08: 0000000000000000 R09: 0000000000000001 > R10: ffff88010e78d698 R11: 0000000000000001 R12: 0000000000000002 > R13: 0000000000000000 R14: 0000000000005000 R15: ffff88012f1c9968 > FS: 0000000000000000(0000) GS:ffffffff80a6cdc0(0063) knlGS:00000000f6355b90 > CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033 > CR2: 00000000000002c8 CR3: 000000010e57d000 CR4: 00000000000026e0 > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 > Process skype (pid: 5895, threadinfo ffff88010e78c000, task ffff88012b9cc460) > Stack: 0000000200000000 0000000000005000 0000000000000000 0000000000000000 > 00000000000017b8 0000000000000000 ffff88010e78d9c8 0000000000000000 > 0000000000000002 0000000000000000 0000000000005000 ffff88012f1c9968 > Call Trace: > [<ffffffff8046cbb0>] swiotlb_map_single_attrs+0x60/0xf0 > [<ffffffff8046cc4c>] swiotlb_map_single+0xc/0x10 > [<ffffffff8046cdee>] swiotlb_alloc_coherent+0xfe/0x180 > [<ffffffff80212731>] dma_alloc_coherent+0x281/0x310 > [<ffffffff805621c0>] hcd_buffer_alloc+0x50/0x90 > [<ffffffff805547fd>] usb_buffer_alloc+0x2d/0x40 > [<ffffffffa0056763>] uvc_alloc_urb_buffers+0x53/0xf0 [uvcvideo] > [<ffffffffa0056958>] uvc_init_video+0x158/0x3e0 [uvcvideo] > [<ffffffffa0056c17>] uvc_video_enable+0x37/0x80 [uvcvideo] > [<ffffffffa0055853>] uvc_v4l2_do_ioctl+0x723/0x1260 [uvcvideo] > [<ffffffff8026dd61>] ? trace_hardirqs_off_caller+0x21/0xc0 > [<ffffffff8026dd61>] ? trace_hardirqs_off_caller+0x21/0xc0 > [<ffffffffa0032c9f>] video_usercopy+0x19f/0x390 [videodev] > [<ffffffffa0055130>] ? uvc_v4l2_do_ioctl+0x0/0x1260 [uvcvideo] > [<ffffffff8026d0ce>] ? put_lock_stats+0xe/0x30 > [<ffffffffa0054dad>] uvc_v4l2_ioctl+0x4d/0x80 [uvcvideo] > [<ffffffffa0045083>] native_ioctl+0x83/0x90 [compat_ioctl32] > [<ffffffffa004534e>] v4l_compat_ioctl32+0x2be/0x1da4 [compat_ioctl32] > [<ffffffff806aad21>] ? do_page_fault+0x3d1/0xae0 > [<ffffffff80270ccd>] ? trace_hardirqs_on+0xd/0x10 > [<ffffffff80270c59>] ? trace_hardirqs_on_caller+0x149/0x1b0 > [<ffffffff80270ccd>] ? trace_hardirqs_on+0xd/0x10 > [<ffffffff80329afa>] compat_sys_ioctl+0x8a/0x3c0 > [<ffffffff806a700d>] ? trace_hardirqs_off_thunk+0x3a/0x3c > [<ffffffff8022f816>] sysenter_dispatch+0x7/0x2c > [<ffffffff806a6fce>] ? trace_hardirqs_on_thunk+0x3a/0x3f > > Code: 45 31 c0 48 89 e5 e8 a4 ff ff ff c9 c3 66 90 55 48 89 e5 41 57 > 41 56 41 55 41 54 53 48 83 ec 38 48 89 75 b0 48 89 55 a8 89 4d a4 <48> > 8b 87 c8 02 00 00 48 85 c0 0f 84 1c 02 00 00 48 8b 58 08 48 > RIP [<ffffffff8046c84c>] map_single+0x1c/0x280 > RSP <ffff88010e78d988> > CR2: 00000000000002c8 > ---[ end trace 5d15baeeb7025a0e ]--- > > --- [3] > > ffffffff8046c830 <map_single>: > map_single(): > /store/kernel/linux/lib/swiotlb.c:291 > ffffffff8046c830: 55 push %rbp > ffffffff8046c831: 48 89 e5 mov %rsp,%rbp > ffffffff8046c834: 41 57 push %r15 > ffffffff8046c836: 41 56 push %r14 > ffffffff8046c838: 41 55 push %r13 > ffffffff8046c83a: 41 54 push %r12 > ffffffff8046c83c: 53 push %rbx > ffffffff8046c83d: 48 83 ec 38 sub $0x38,%rsp > ffffffff8046c841: 48 89 75 b0 mov %rsi,-0x50(%rbp) > ffffffff8046c845: 48 89 55 a8 mov %rdx,-0x58(%rbp) > ffffffff8046c849: 89 4d a4 mov %ecx,-0x5c(%rbp) > dma_get_seg_boundary(): > /store/kernel/linux/include/linux/dma-mapping.h:80 > ffffffff8046c84c: 48 8b 87 c8 02 00 00 mov 0x2c8(%rdi),%rax <---- > > --- [4] > > Fix back-off path when memory allocation fails > Signed-off-by: Daniel J Blueman <daniel.blueman@gmail.com> > > diff --git a/lib/swiotlb.c b/lib/swiotlb.c > index 977edbd..8826fdf 100644 > --- a/lib/swiotlb.c > +++ b/lib/swiotlb.c > @@ -491,7 +491,7 @@ swiotlb_alloc_coherent(struct device *hwdev, size_t size, > * the lowest available address range. > */ > dma_addr_t handle; > - handle = swiotlb_map_single(NULL, NULL, size, DMA_FROM_DEVICE); > + handle = swiotlb_map_single(hwdev, NULL, size, DMA_FROM_DEVICE); I think that it's better to use map_single instead of swiotlb_map_single since we always need swiotlb memory here. http://www.uwsg.iu.edu/hypermail/linux/kernel/0809.1/0043.html ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [2.6.27-rc6, patch] fix SWIOTLB oops... 2008-09-11 13:29 ` FUJITA Tomonori @ 2008-09-13 17:53 ` Daniel J Blueman 2008-09-13 18:47 ` FUJITA Tomonori 0 siblings, 1 reply; 5+ messages in thread From: Daniel J Blueman @ 2008-09-13 17:53 UTC (permalink / raw) To: FUJITA Tomonori, Ingo Molnar, torvalds Cc: linux-kernel, jbeulich, Jens Axboe, tony.luck, Andrew Morton On Thu, Sep 11, 2008 at 2:29 PM, FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> wrote: > On Wed, 10 Sep 2008 21:07:55 +0100 > "Daniel J Blueman" <daniel.blueman@gmail.com> wrote: > >> With SWIOTLB being enabled and straight-forward page allocation >> failure [1], the swiotlb_alloc_coherent fall-back path hits an issue >> [2], resulting in my webcam failing to work. >> >> At the time of oops, RDI is clearly a pointer to a structure which has >> arrived as NULL, leading to the typo in swiotlb_map_single's callsite >> arguments. >> >> Correctly passing the device structure [3] addresses the issue and >> gets my webcam working again (the allocation failure still occuring). >> >> Please apply, >> Daniel >> >> --- [1] >> >> skype: page allocation failure. order:3, mode:0x1 >> Pid: 5895, comm: skype Not tainted 2.6.27-rc6-235c-debug #1 >> >> Call Trace: >> [<ffffffff802b7cf0>] __alloc_pages_internal+0x4a0/0x5d0 >> [<ffffffff802d5ddd>] alloc_pages_current+0xad/0x110 >> [<ffffffff802b4ccd>] __get_free_pages+0x1d/0x60 >> [<ffffffff8046cd39>] swiotlb_alloc_coherent+0x49/0x180 >> [<ffffffff80212731>] dma_alloc_coherent+0x281/0x310 >> [<ffffffff805621c0>] hcd_buffer_alloc+0x50/0x90 >> [<ffffffff805547fd>] usb_buffer_alloc+0x2d/0x40 >> [<ffffffffa0056763>] uvc_alloc_urb_buffers+0x53/0xf0 [uvcvideo] >> [<ffffffffa0056958>] uvc_init_video+0x158/0x3e0 [uvcvideo] >> [<ffffffffa0056c17>] uvc_video_enable+0x37/0x80 [uvcvideo] >> [<ffffffffa0055853>] uvc_v4l2_do_ioctl+0x723/0x1260 [uvcvideo] >> [<ffffffff8026dd61>] ? trace_hardirqs_off_caller+0x21/0xc0 >> [<ffffffff8026dd61>] ? trace_hardirqs_off_caller+0x21/0xc0 >> [<ffffffffa0032c9f>] video_usercopy+0x19f/0x390 [videodev] >> [<ffffffffa0055130>] ? uvc_v4l2_do_ioctl+0x0/0x1260 [uvcvideo] >> [<ffffffff8026d0ce>] ? put_lock_stats+0xe/0x30 >> [<ffffffffa0054dad>] uvc_v4l2_ioctl+0x4d/0x80 [uvcvideo] >> [<ffffffffa0045083>] native_ioctl+0x83/0x90 [compat_ioctl32] >> [<ffffffffa004534e>] v4l_compat_ioctl32+0x2be/0x1da4 [compat_ioctl32] >> [<ffffffff806aad21>] ? do_page_fault+0x3d1/0xae0 >> [<ffffffff80270ccd>] ? trace_hardirqs_on+0xd/0x10 >> [<ffffffff80270c59>] ? trace_hardirqs_on_caller+0x149/0x1b0 >> [<ffffffff80270ccd>] ? trace_hardirqs_on+0xd/0x10 >> [<ffffffff80329afa>] compat_sys_ioctl+0x8a/0x3c0 >> [<ffffffff806a700d>] ? trace_hardirqs_off_thunk+0x3a/0x3c >> [<ffffffff8022f816>] sysenter_dispatch+0x7/0x2c >> [<ffffffff806a6fce>] ? trace_hardirqs_on_thunk+0x3a/0x3f >> >> Mem-Info: >> Node 0 DMA per-cpu: >> CPU 0: hi: 0, btch: 1 usd: 0 >> CPU 1: hi: 0, btch: 1 usd: 0 >> Node 0 DMA32 per-cpu: >> CPU 0: hi: 186, btch: 31 usd: 3 >> CPU 1: hi: 186, btch: 31 usd: 0 >> Node 0 Normal per-cpu: >> CPU 0: hi: 186, btch: 31 usd: 23 >> CPU 1: hi: 186, btch: 31 usd: 179 >> Active:78545 inactive:48683 dirty:31 writeback:0 unstable:2 >> free:830202 slab:17516 mapped:17473 pagetables:3496 bounce:0 >> Node 0 DMA free:36kB min:28kB low:32kB high:40kB active:0kB >> inactive:0kB present:15156kB pages_scanned:0 all_unreclaimable? no >> lowmem_reserve[]: 0 3207 3956 3956 >> Node 0 DMA32 free:3197192kB min:6512kB low:8140kB high:9768kB >> active:0kB inactive:0kB present:3284896kB pages_scanned:0 >> all_unreclaimable? no >> lowmem_reserve[]: 0 0 748 748 >> Node 0 Normal free:123580kB min:1516kB low:1892kB high:2272kB >> active:314180kB inactive:194732kB present:766464kB pages_scanned:0 >> all_unreclaimable? no >> lowmem_reserve[]: 0 0 0 0 >> Node 0 DMA: 1*4kB 0*8kB 0*16kB 1*32kB 0*64kB 0*128kB 0*256kB 0*512kB >> 0*1024kB 0*2048kB 0*4096kB = 36kB >> Node 0 DMA32: 4*4kB 3*8kB 2*16kB 3*32kB 4*64kB 5*128kB 3*256kB 5*512kB >> 4*1024kB 5*2048kB 776*4096kB = 3197224kB >> Node 0 Normal: 14*4kB 14*8kB 8*16kB 6*32kB 1*64kB 3*128kB 3*256kB >> 2*512kB 4*1024kB 1*2048kB 28*4096kB = 123560kB >> 64847 total pagecache pages >> 0 pages in swap cache >> Swap cache stats: add 0, delete 0, find 0/0 >> Free swap = 502752kB >> Total swap = 502752kB >> 1048576 pages RAM >> 52120 pages reserved >> 71967 pages shared >> 143004 pages non-shared >> >> --- [2] >> >> BUG: unable to handle kernel NULL pointer dereference at 00000000000002c8 >> IP: [<ffffffff8046c84c>] map_single+0x1c/0x280 >> PGD 10e54e067 PUD 10e595067 PMD 0 >> Oops: 0000 [1] PREEMPT SMP DEBUG_PAGEALLOC >> CPU 0 >> Modules linked in: kvm_intel kvm microcode uvcvideo compat_ioctl32 >> videodev v4l1_compat shpchp pci_hotplug >> Pid: 5895, comm: skype Not tainted 2.6.27-rc6-235c-debug #1 >> RIP: 0010:[<ffffffff8046c84c>] [<ffffffff8046c84c>] map_single+0x1c/0x280 >> RSP: 0018:ffff88010e78d988 EFLAGS: 00210296 >> RAX: 0000780000000000 RBX: 0000000000000000 RCX: 0000000000000002 >> RDX: 0000000000005000 RSI: 0000000000000000 RDI: 0000000000000000 >> RBP: ffff88010e78d9e8 R08: 0000000000000000 R09: 0000000000000001 >> R10: ffff88010e78d698 R11: 0000000000000001 R12: 0000000000000002 >> R13: 0000000000000000 R14: 0000000000005000 R15: ffff88012f1c9968 >> FS: 0000000000000000(0000) GS:ffffffff80a6cdc0(0063) knlGS:00000000f6355b90 >> CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033 >> CR2: 00000000000002c8 CR3: 000000010e57d000 CR4: 00000000000026e0 >> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 >> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 >> Process skype (pid: 5895, threadinfo ffff88010e78c000, task ffff88012b9cc460) >> Stack: 0000000200000000 0000000000005000 0000000000000000 0000000000000000 >> 00000000000017b8 0000000000000000 ffff88010e78d9c8 0000000000000000 >> 0000000000000002 0000000000000000 0000000000005000 ffff88012f1c9968 >> Call Trace: >> [<ffffffff8046cbb0>] swiotlb_map_single_attrs+0x60/0xf0 >> [<ffffffff8046cc4c>] swiotlb_map_single+0xc/0x10 >> [<ffffffff8046cdee>] swiotlb_alloc_coherent+0xfe/0x180 >> [<ffffffff80212731>] dma_alloc_coherent+0x281/0x310 >> [<ffffffff805621c0>] hcd_buffer_alloc+0x50/0x90 >> [<ffffffff805547fd>] usb_buffer_alloc+0x2d/0x40 >> [<ffffffffa0056763>] uvc_alloc_urb_buffers+0x53/0xf0 [uvcvideo] >> [<ffffffffa0056958>] uvc_init_video+0x158/0x3e0 [uvcvideo] >> [<ffffffffa0056c17>] uvc_video_enable+0x37/0x80 [uvcvideo] >> [<ffffffffa0055853>] uvc_v4l2_do_ioctl+0x723/0x1260 [uvcvideo] >> [<ffffffff8026dd61>] ? trace_hardirqs_off_caller+0x21/0xc0 >> [<ffffffff8026dd61>] ? trace_hardirqs_off_caller+0x21/0xc0 >> [<ffffffffa0032c9f>] video_usercopy+0x19f/0x390 [videodev] >> [<ffffffffa0055130>] ? uvc_v4l2_do_ioctl+0x0/0x1260 [uvcvideo] >> [<ffffffff8026d0ce>] ? put_lock_stats+0xe/0x30 >> [<ffffffffa0054dad>] uvc_v4l2_ioctl+0x4d/0x80 [uvcvideo] >> [<ffffffffa0045083>] native_ioctl+0x83/0x90 [compat_ioctl32] >> [<ffffffffa004534e>] v4l_compat_ioctl32+0x2be/0x1da4 [compat_ioctl32] >> [<ffffffff806aad21>] ? do_page_fault+0x3d1/0xae0 >> [<ffffffff80270ccd>] ? trace_hardirqs_on+0xd/0x10 >> [<ffffffff80270c59>] ? trace_hardirqs_on_caller+0x149/0x1b0 >> [<ffffffff80270ccd>] ? trace_hardirqs_on+0xd/0x10 >> [<ffffffff80329afa>] compat_sys_ioctl+0x8a/0x3c0 >> [<ffffffff806a700d>] ? trace_hardirqs_off_thunk+0x3a/0x3c >> [<ffffffff8022f816>] sysenter_dispatch+0x7/0x2c >> [<ffffffff806a6fce>] ? trace_hardirqs_on_thunk+0x3a/0x3f >> >> Code: 45 31 c0 48 89 e5 e8 a4 ff ff ff c9 c3 66 90 55 48 89 e5 41 57 >> 41 56 41 55 41 54 53 48 83 ec 38 48 89 75 b0 48 89 55 a8 89 4d a4 <48> >> 8b 87 c8 02 00 00 48 85 c0 0f 84 1c 02 00 00 48 8b 58 08 48 >> RIP [<ffffffff8046c84c>] map_single+0x1c/0x280 >> RSP <ffff88010e78d988> >> CR2: 00000000000002c8 >> ---[ end trace 5d15baeeb7025a0e ]--- >> >> --- [3] >> >> ffffffff8046c830 <map_single>: >> map_single(): >> /store/kernel/linux/lib/swiotlb.c:291 >> ffffffff8046c830: 55 push %rbp >> ffffffff8046c831: 48 89 e5 mov %rsp,%rbp >> ffffffff8046c834: 41 57 push %r15 >> ffffffff8046c836: 41 56 push %r14 >> ffffffff8046c838: 41 55 push %r13 >> ffffffff8046c83a: 41 54 push %r12 >> ffffffff8046c83c: 53 push %rbx >> ffffffff8046c83d: 48 83 ec 38 sub $0x38,%rsp >> ffffffff8046c841: 48 89 75 b0 mov %rsi,-0x50(%rbp) >> ffffffff8046c845: 48 89 55 a8 mov %rdx,-0x58(%rbp) >> ffffffff8046c849: 89 4d a4 mov %ecx,-0x5c(%rbp) >> dma_get_seg_boundary(): >> /store/kernel/linux/include/linux/dma-mapping.h:80 >> ffffffff8046c84c: 48 8b 87 c8 02 00 00 mov 0x2c8(%rdi),%rax <---- >> >> --- [4] >> >> Fix back-off path when memory allocation fails >> Signed-off-by: Daniel J Blueman <daniel.blueman@gmail.com> >> >> diff --git a/lib/swiotlb.c b/lib/swiotlb.c >> index 977edbd..8826fdf 100644 >> --- a/lib/swiotlb.c >> +++ b/lib/swiotlb.c >> @@ -491,7 +491,7 @@ swiotlb_alloc_coherent(struct device *hwdev, size_t size, >> * the lowest available address range. >> */ >> dma_addr_t handle; >> - handle = swiotlb_map_single(NULL, NULL, size, DMA_FROM_DEVICE); >> + handle = swiotlb_map_single(hwdev, NULL, size, DMA_FROM_DEVICE); > > I think that it's better to use map_single instead of > swiotlb_map_single since we always need swiotlb memory here. > > http://www.uwsg.iu.edu/hypermail/linux/kernel/0809.1/0043.html Thanks Fujita; this looks a better way of doing this. I've tested the three patches you posted and they address the original issue I bumped into, so seem an appropriate fix for -rc7. Not sure if preceding comments need tweaking though. Our work isn't done yet though, since we see unexpected page state [5] on the release path. Calling the appropriate IOMMU/SWIOTLB release function [6] corrects this. Verified on x86-64 Intel system with SWIOTLB in use due to large memory; without this, processes end up hosed, so I'd say it's -rc7 material. Thanks, Daniel --- [5] Bad page state in process 'skype' page:ffffe20000d52a58 flags:0x0040000000000400 mapping:0000000000000000 mapcount:0 count:0 Trying to fix it up, but a reboot is needed Backtrace: Pid: 4950, comm: skype Not tainted 2.6.27-rc6-235c-debug #6 Call Trace: [<ffffffff802b50de>] bad_page+0x7e/0xd0 [<ffffffff802b74f8>] __free_pages_ok+0x348/0x480 [<ffffffff806a7ea7>] ? _spin_unlock_irqrestore+0x47/0x80 [<ffffffff802b7685>] __free_pages+0x35/0x50 [<ffffffff802b771e>] free_pages+0x7e/0x90 [<ffffffff80212400>] dma_free_coherent+0x80/0xc0 [<ffffffff8056211b>] hcd_buffer_free+0x4b/0x90 [<ffffffff805547b5>] usb_buffer_free+0x25/0x30 [<ffffffffa005447e>] uvc_uninit_video+0x7e/0xb0 [uvcvideo] [<ffffffffa0054c28>] uvc_video_enable+0x48/0x80 [uvcvideo] [<ffffffffa0053828>] uvc_v4l2_do_ioctl+0x6f8/0x1260 [uvcvideo] [<ffffffff8026dd61>] ? trace_hardirqs_off_caller+0x21/0xc0 [<ffffffff8026de0d>] ? trace_hardirqs_off+0xd/0x10 [<ffffffffa0030c9f>] video_usercopy+0x19f/0x390 [videodev] [<ffffffffa0053130>] ? uvc_v4l2_do_ioctl+0x0/0x1260 [uvcvideo] [<ffffffff8026d084>] ? get_lock_stats+0x34/0x70 [<ffffffff8026d0ce>] ? put_lock_stats+0xe/0x30 [<ffffffff80274c50>] ? futex_wake+0x100/0x130 [<ffffffffa0052dad>] uvc_v4l2_ioctl+0x4d/0x80 [uvcvideo] [<ffffffffa0043083>] native_ioctl+0x83/0x90 [compat_ioctl32] [<ffffffffa004334e>] v4l_compat_ioctl32+0x2be/0x1da4 [compat_ioctl32] [<ffffffff8027647b>] ? do_futex+0x9b/0xab0 [<ffffffff80270ccd>] ? trace_hardirqs_on+0xd/0x10 [<ffffffff80270c59>] ? trace_hardirqs_on_caller+0x149/0x1b0 [<ffffffff80270ccd>] ? trace_hardirqs_on+0xd/0x10 [<ffffffff80329afa>] compat_sys_ioctl+0x8a/0x3c0 [<ffffffff806a6ffd>] ? trace_hardirqs_off_thunk+0x3a/0x3c [<ffffffff8022f816>] sysenter_dispatch+0x7/0x2c [<ffffffff806a6fbe>] ? trace_hardirqs_on_thunk+0x3a/0x3f ...followed by dup stack traces with the rest of the pages: page:ffffe20000d52ac0 flags:0x0040000000000400 mapping:0000000000000000 mapcount:0 count:1 page:ffffe20000d52b28 flags:0x0040000000000400 mapping:0000000000000000 mapcount:0 count:1 page:ffffe20000d52b90 flags:0x0040000000000400 mapping:0000000000000000 mapcount:0 count:1 page:ffffe20000d52bf8 flags:0x0040000000000400 mapping:0000000000000000 mapcount:0 count:1 page:ffffe20000d52c60 flags:0x0040000000000400 mapping:0000000000000000 mapcount:0 count:1 page:ffffe20000d52cc8 flags:0x0040000000000400 mapping:0000000000000000 mapcount:0 count:1 page:ffffe20000d52d30 flags:0x0040000000000400 mapping:0000000000000000 mapcount:0 count:1 --- [6] Ensure the SWIOTLB/IOMMU buffers aren't incorrectly freed by calling appropriate release function. Signed-off-by: Daniel J Blueman <daniel.blueman@gmail.com> diff --git a/arch/x86/kernel/pci-dma.c b/arch/x86/kernel/pci-dma.c index 87d4d69..265805c 100644 --- a/arch/x86/kernel/pci-dma.c +++ b/arch/x86/kernel/pci-dma.c @@ -378,7 +378,11 @@ void dma_free_coherent(struct device *dev, size_t size, return; if (ops->unmap_single) ops->unmap_single(dev, bus, size, 0); - free_pages((unsigned long)vaddr, order); + + if (ops->alloc_coherent) + ops->free_coherent(dev, size, vaddr, bus); + else + free_pages((unsigned long)vaddr, order); } EXPORT_SYMBOL(dma_free_coherent); -- Daniel J Blueman ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [2.6.27-rc6, patch] fix SWIOTLB oops... 2008-09-13 17:53 ` Daniel J Blueman @ 2008-09-13 18:47 ` FUJITA Tomonori 2008-09-14 15:31 ` Ingo Molnar 0 siblings, 1 reply; 5+ messages in thread From: FUJITA Tomonori @ 2008-09-13 18:47 UTC (permalink / raw) To: daniel.blueman Cc: fujita.tomonori, mingo, torvalds, linux-kernel, jbeulich, jens.axboe, tony.luck, akpm On Sat, 13 Sep 2008 18:53:13 +0100 "Daniel J Blueman" <daniel.blueman@gmail.com> wrote: > >> Fix back-off path when memory allocation fails > >> Signed-off-by: Daniel J Blueman <daniel.blueman@gmail.com> > >> > >> diff --git a/lib/swiotlb.c b/lib/swiotlb.c > >> index 977edbd..8826fdf 100644 > >> --- a/lib/swiotlb.c > >> +++ b/lib/swiotlb.c > >> @@ -491,7 +491,7 @@ swiotlb_alloc_coherent(struct device *hwdev, size_t size, > >> * the lowest available address range. > >> */ > >> dma_addr_t handle; > >> - handle = swiotlb_map_single(NULL, NULL, size, DMA_FROM_DEVICE); > >> + handle = swiotlb_map_single(hwdev, NULL, size, DMA_FROM_DEVICE); > > > > I think that it's better to use map_single instead of > > swiotlb_map_single since we always need swiotlb memory here. > > > > http://www.uwsg.iu.edu/hypermail/linux/kernel/0809.1/0043.html > > Thanks Fujita; this looks a better way of doing this. I've tested the > three patches you posted and they address the original issue I bumped > into, so seem an appropriate fix for -rc7. Not sure if preceding > comments need tweaking though. > > Our work isn't done yet though, since we see unexpected page state [5] > on the release path. Calling the appropriate IOMMU/SWIOTLB release > function [6] corrects this. Verified on x86-64 Intel system with > SWIOTLB in use due to large memory; without this, processes end up > hosed, so I'd say it's -rc7 material. Are you sure your patch doesn't break other x86 IOMMU implementations (note that this patch affects all the IOMMUs)? x86 IOMMU coherent code has been broken for a long time. The coherent code was completely rewritten for 2.6.28 to fix all the issues. git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-tip.git I think it's too late to try to fix v2.6.27. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [2.6.27-rc6, patch] fix SWIOTLB oops... 2008-09-13 18:47 ` FUJITA Tomonori @ 2008-09-14 15:31 ` Ingo Molnar 0 siblings, 0 replies; 5+ messages in thread From: Ingo Molnar @ 2008-09-14 15:31 UTC (permalink / raw) To: FUJITA Tomonori Cc: daniel.blueman, torvalds, linux-kernel, jbeulich, jens.axboe, tony.luck, akpm * FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> wrote: > On Sat, 13 Sep 2008 18:53:13 +0100 > "Daniel J Blueman" <daniel.blueman@gmail.com> wrote: > > > >> Fix back-off path when memory allocation fails > > >> Signed-off-by: Daniel J Blueman <daniel.blueman@gmail.com> > > >> > > >> diff --git a/lib/swiotlb.c b/lib/swiotlb.c > > >> index 977edbd..8826fdf 100644 > > >> --- a/lib/swiotlb.c > > >> +++ b/lib/swiotlb.c > > >> @@ -491,7 +491,7 @@ swiotlb_alloc_coherent(struct device *hwdev, size_t size, > > >> * the lowest available address range. > > >> */ > > >> dma_addr_t handle; > > >> - handle = swiotlb_map_single(NULL, NULL, size, DMA_FROM_DEVICE); > > >> + handle = swiotlb_map_single(hwdev, NULL, size, DMA_FROM_DEVICE); > > > > > > I think that it's better to use map_single instead of > > > swiotlb_map_single since we always need swiotlb memory here. > > > > > > http://www.uwsg.iu.edu/hypermail/linux/kernel/0809.1/0043.html > > > > Thanks Fujita; this looks a better way of doing this. I've tested the > > three patches you posted and they address the original issue I bumped > > into, so seem an appropriate fix for -rc7. Not sure if preceding > > comments need tweaking though. > > > > Our work isn't done yet though, since we see unexpected page state [5] > > on the release path. Calling the appropriate IOMMU/SWIOTLB release > > function [6] corrects this. Verified on x86-64 Intel system with > > SWIOTLB in use due to large memory; without this, processes end up > > hosed, so I'd say it's -rc7 material. > > Are you sure your patch doesn't break other x86 IOMMU implementations > (note that this patch affects all the IOMMUs)? > > x86 IOMMU coherent code has been broken for a long time. The coherent > code was completely rewritten for 2.6.28 to fix all the issues. > > git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-tip.git > > I think it's too late to try to fix v2.6.27. definitely - but if there are minimal fixes possible for regressions, those are still fine. Ingo ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2008-09-14 15:32 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2008-09-10 20:07 [2.6.27-rc6, patch] fix SWIOTLB oops Daniel J Blueman 2008-09-11 13:29 ` FUJITA Tomonori 2008-09-13 17:53 ` Daniel J Blueman 2008-09-13 18:47 ` FUJITA Tomonori 2008-09-14 15:31 ` Ingo Molnar
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®