Re: Bad page state in tidspbridge driver
Hi Laurent, On Sun, Jan 8, 2012 at 12:17 PM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi, I'm hitting what seems to be a tidspbridge driver issue when using gst-dsp with the DSP JPEG encoder. My application captures images from the OMAP3 ISP directly to frame buffer memory for display. It then passes the frame buffer buffer pointer to gst-dsp and the tidspbridge driver, which maps them to the DSP IOMMU address space. Frame buffer sounds like kernel memory not user's, this because tidspbridge map functions do get_user_pages on the memory passed to it, unless you set VM_IO (I believe, so tidspbridge just does a get_page), however the issue might be related with the page count in the end. When starting the JPEG encoder a bunch of identical messages are printed to the kernel log: [14643.065490] BUG: Bad page state in process source:src pfn:89e39 [14643.072143] page:c0b11720 count:0 mapcount:0 mapping: (null) index:0x0 [14643.079437] page flags: 0x410(dirty|reserved) [14643.084197] [c003ee5c] (unwind_backtrace+0x0/0xe0) from [c00a4c34] (bad_page+0xc4/0xec) [14643.093505] [c00a4c34] (bad_page+0xc4/0xec) from [c00a5480] (free_pages_prepare+0x70/0xe8) [14643.102935] [c00a5480] (free_pages_prepare+0x70/0xe8) from [c00a5634] (free_hot_cold_page+0x20/0x1ac) [14643.113525] [c00a5634] (free_hot_cold_page+0x20/0x1ac) from [bf00d120] (bridge_brd_mem_un_map+0x12c/0x3d4 [bridgedriver]) [14643.126007] [bf00d120] (bridge_brd_mem_un_map+0x12c/0x3d4 [bridgedriver]) from [bf01cda8] (proc_un_map+0x6c/0xa0 [bridgedriver]) [14643.139404] [bf01cda8] (proc_un_map+0x6c/0xa0 [bridgedriver]) from [bf014490] (api_call_dev_ioctl+0xe8/0x10c [bridgedriver]) [14643.152160] [bf014490] (api_call_dev_ioctl+0xe8/0x10c [bridgedriver]) from [bf0208b8] (bridge_ioctl+0x12c/0x15c [bridgedriver]) [14643.165191] [bf0208b8] (bridge_ioctl+0x12c/0x15c [bridgedriver]) from [c00d8fd8] (do_vfs_ioctl+0x4e8/0x55c) [14643.176177] [c00d8fd8] (do_vfs_ioctl+0x4e8/0x55c) from [c00d9080] (sys_ioctl+0x34/0x54) [14643.185333] [c00d9080] (sys_ioctl+0x34/0x54) from [c003a700] (ret_fast_syscall+0x0/0x3c) The backtrace is printed because the page has the PG_reserved flag set, which is expected (as far as I know) for the frame buffer memory. Yes, PG_reserved is set, and given that tidspbridge is unmapping, it is also telling the kernel that the pages are not going to be used anymore, however in the beginning the memory was allocated by either frame buffer or display driver. I believe the issue is because the page count reaches to 0 but PG_reserved is set as you point out. Is this use case unsupported ? Not entirely supported, as long as the memory used by other drivers increases the page count of each page there shouldn't be any issue, since bridge doesn't know which pages have more than X number of users. Regards, Omar -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bad page state in tidspbridge driver
Hi Omar, On Monday 09 January 2012 18:30:11 Ramirez Luna, Omar wrote: On Sun, Jan 8, 2012 at 12:17 PM, Laurent Pinchart wrote: Hi, I'm hitting what seems to be a tidspbridge driver issue when using gst-dsp with the DSP JPEG encoder. My application captures images from the OMAP3 ISP directly to frame buffer memory for display. It then passes the frame buffer buffer pointer to gst-dsp and the tidspbridge driver, which maps them to the DSP IOMMU address space. Frame buffer sounds like kernel memory not user's, this because tidspbridge map functions do get_user_pages on the memory passed to it, unless you set VM_IO (I believe, so tidspbridge just does a get_page), however the issue might be related with the page count in the end. The frame buffer memory is first mapped to userspace in the omap_vout driver, and then passed to the tidspbridge driver. When starting the JPEG encoder a bunch of identical messages are printed to the kernel log: [14643.065490] BUG: Bad page state in process source:src pfn:89e39 [14643.072143] page:c0b11720 count:0 mapcount:0 mapping: (null) index:0x0 [14643.079437] page flags: 0x410(dirty|reserved) [14643.084197] [c003ee5c] (unwind_backtrace+0x0/0xe0) from [c00a4c34] (bad_page+0xc4/0xec) [14643.093505] [c00a4c34] (bad_page+0xc4/0xec) from [c00a5480] (free_pages_prepare+0x70/0xe8) [14643.102935] [c00a5480] (free_pages_prepare+0x70/0xe8) from [c00a5634] (free_hot_cold_page+0x20/0x1ac) [14643.113525] [c00a5634] (free_hot_cold_page+0x20/0x1ac) from [bf00d120] (bridge_brd_mem_un_map+0x12c/0x3d4 [bridgedriver]) [14643.126007] [bf00d120] (bridge_brd_mem_un_map+0x12c/0x3d4 [bridgedriver]) from [bf01cda8] (proc_un_map+0x6c/0xa0 [bridgedriver]) [14643.139404] [bf01cda8] (proc_un_map+0x6c/0xa0 [bridgedriver]) from [bf014490] (api_call_dev_ioctl+0xe8/0x10c [bridgedriver]) [14643.152160] [bf014490] (api_call_dev_ioctl+0xe8/0x10c [bridgedriver]) from [bf0208b8] (bridge_ioctl+0x12c/0x15c [bridgedriver]) [14643.165191] [bf0208b8] (bridge_ioctl+0x12c/0x15c [bridgedriver]) from [c00d8fd8] (do_vfs_ioctl+0x4e8/0x55c) [14643.176177] [c00d8fd8] (do_vfs_ioctl+0x4e8/0x55c) from [c00d9080] (sys_ioctl+0x34/0x54) [14643.185333] [c00d9080] (sys_ioctl+0x34/0x54) from [c003a700] (ret_fast_syscall+0x0/0x3c) The backtrace is printed because the page has the PG_reserved flag set, which is expected (as far as I know) for the frame buffer memory. Yes, PG_reserved is set, and given that tidspbridge is unmapping, it is also telling the kernel that the pages are not going to be used anymore, however in the beginning the memory was allocated by either frame buffer or display driver. I believe the issue is because the page count reaches to 0 but PG_reserved is set as you point out. Probably. I'll try to investigate more. Is this use case unsupported ? Not entirely supported, as long as the memory used by other drivers increases the page count of each page there shouldn't be any issue, since bridge doesn't know which pages have more than X number of users. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Bad page state in tidspbridge driver
Hi, I'm hitting what seems to be a tidspbridge driver issue when using gst-dsp with the DSP JPEG encoder. My application captures images from the OMAP3 ISP directly to frame buffer memory for display. It then passes the frame buffer buffer pointer to gst-dsp and the tidspbridge driver, which maps them to the DSP IOMMU address space. When starting the JPEG encoder a bunch of identical messages are printed to the kernel log: [14643.065490] BUG: Bad page state in process source:src pfn:89e39 [14643.072143] page:c0b11720 count:0 mapcount:0 mapping: (null) index:0x0 [14643.079437] page flags: 0x410(dirty|reserved) [14643.084197] [c003ee5c] (unwind_backtrace+0x0/0xe0) from [c00a4c34] (bad_page+0xc4/0xec) [14643.093505] [c00a4c34] (bad_page+0xc4/0xec) from [c00a5480] (free_pages_prepare+0x70/0xe8) [14643.102935] [c00a5480] (free_pages_prepare+0x70/0xe8) from [c00a5634] (free_hot_cold_page+0x20/0x1ac) [14643.113525] [c00a5634] (free_hot_cold_page+0x20/0x1ac) from [bf00d120] (bridge_brd_mem_un_map+0x12c/0x3d4 [bridgedriver]) [14643.126007] [bf00d120] (bridge_brd_mem_un_map+0x12c/0x3d4 [bridgedriver]) from [bf01cda8] (proc_un_map+0x6c/0xa0 [bridgedriver]) [14643.139404] [bf01cda8] (proc_un_map+0x6c/0xa0 [bridgedriver]) from [bf014490] (api_call_dev_ioctl+0xe8/0x10c [bridgedriver]) [14643.152160] [bf014490] (api_call_dev_ioctl+0xe8/0x10c [bridgedriver]) from [bf0208b8] (bridge_ioctl+0x12c/0x15c [bridgedriver]) [14643.165191] [bf0208b8] (bridge_ioctl+0x12c/0x15c [bridgedriver]) from [c00d8fd8] (do_vfs_ioctl+0x4e8/0x55c) [14643.176177] [c00d8fd8] (do_vfs_ioctl+0x4e8/0x55c) from [c00d9080] (sys_ioctl+0x34/0x54) [14643.185333] [c00d9080] (sys_ioctl+0x34/0x54) from [c003a700] (ret_fast_syscall+0x0/0x3c) The backtrace is printed because the page has the PG_reserved flag set, which is expected (as far as I know) for the frame buffer memory. Is this use case unsupported ? -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
