On Sun, Nov 6, 2011 at 5:48 PM, Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> wrote: > Yet again I find that I'm having to email about crap on OMAP3. > > I'm getting really fed up with OMAP stuff which keeps breaking in > idiotic ways - and the way there's fatal build errors at EVERY merge > window. The OMAP workflow is totally broken. Something MUST change > in the way the OMAP community works to stop the continual breakage > at every single bloody merge window. > > One is new: > > WARNING: at arch/arm/mach-omap2/usb-musb.c:141 usb_musb_init+0xc0/0x174() > usb_musb_init: could not find omap_hwmod for usb_otg_hs > Modules linked in: > Backtrace: > [<c0017920>] (dump_backtrace+0x0/0x10c) from [<c02d9368>] (dump_stack+0x18/0x1c) r7:c181ff20 r6:c03ceb54 r5:c037545b r4:0000008d > [<c02d9350>] (dump_stack+0x0/0x1c) from [<c003adfc>] (warn_slowpath_common+0x58/0x70) > [<c003ada4>] (warn_slowpath_common+0x0/0x70) from [<c003aeb8>] (warn_slowpath_fmt+0x38/0x40) > r8:00000000 r7:00000013 r6:c0374b05 r5:c03f06e4 r4:c0374190 > [<c003ae80>] (warn_slowpath_fmt+0x0/0x40) from [<c03ceb54>] (usb_musb_init+0xc0/0x174) > r3:c02df894 r2:c03707d9 > [<c03cea94>] (usb_musb_init+0x0/0x174) from [<c03ce02c>] (omap_ldp_init+0xb0/0x100) > r6:c003e7d8 r5:c03f06e4 r4:c04053e4 > [<c03cdf7c>] (omap_ldp_init+0x0/0x100) from [<c03c6788>] (customize_machine+0x24/0x30) > r4:c03f03a8 > [<c03c6764>] (customize_machine+0x0/0x30) from [<c0008710>] (do_one_initcall+0x9c/0x164) > [<c0008674>] (do_one_initcall+0x0/0x164) from [<c03c3284>] (kernel_init+0x7c/0x120) > [<c03c3208>] (kernel_init+0x0/0x120) from [<c003e7d8>] (do_exit+0x0/0x62c) > r5:c03c3208 r4:00000000 > ---[ end trace 1b75b31a2719ed1c ]--- > omap_timer.1: alias fck already exists > omap_timer.2: alias fck already exists > omap_timer.3: alias fck already exists > omap_timer.4: alias fck already exists > omap_timer.5: alias fck already exists > omap_timer.6: alias fck already exists > omap_timer.7: alias fck already exists > omap_timer.8: alias fck already exists > omap_timer.9: alias fck already exists > omap_timer.10: alias fck already exists > omap_timer.11: alias fck already exists > omap_timer.12: alias fck already exists > omap-mcbsp.2: alias fck already exists > omap-mcbsp.3: alias fck already exists > > And this, which I reported on August 26th - so it's now over three months > old is still there. Clearly, no one cares about this driver so shall I > delete the omap-hsmmc driver, or is someone going to clean up their crap? > Or shall we revert all those patches for adding the asynchronous mapping > of MMC requests until the _REGRESSION_ is fixed properly? > > mmcblk0: error -84 transferring data, sector 149209, nr 56, cmd response 0x900, > card status 0xb00 > ------------[ cut here ]------------ > WARNING: at lib/dma-debug.c:865 check_unmap+0x1b0/0x76c() > omap_hsmmc omap_hsmmc.0: DMA-API: device driver tries to free DMA memory it has not allocated [device address=0x0000000080000000] [size=16384 bytes] > Modules linked in: > Backtrace: > [<c0017920>] (dump_backtrace+0x0/0x10c) from [<c02d9368>] (dump_stack+0x18/0x1c) r7:c1af7cb0 r6:c018bfc8 r5:c038b4ff r4:00000361 > [<c02d9350>] (dump_stack+0x0/0x1c) from [<c003adfc>] (warn_slowpath_common+0x58/0x70) > [<c003ada4>] (warn_slowpath_common+0x0/0x70) from [<c003aeb8>] (warn_slowpath_fmt+0x38/0x40) > r8:c1af7d48 r7:00000000 r6:00004000 r5:00000000 r4:80000000 > [<c003ae80>] (warn_slowpath_fmt+0x0/0x40) from [<c018bfc8>] (check_unmap+0x1b0/0x76c) > r3:c0375450 r2:c038b8f7 > [<c018be18>] (check_unmap+0x0/0x76c) from [<c018c6fc>] (debug_dma_unmap_sg+0x100/0x134) > [<c018c5fc>] (debug_dma_unmap_sg+0x0/0x134) from [<c0019848>] (dma_unmap_sg+0x24/0x7c) > [<c0019824>] (dma_unmap_sg+0x0/0x7c) from [<c021112c>] (omap_hsmmc_post_req+0x48/0x54) > [<c02110e4>] (omap_hsmmc_post_req+0x0/0x54) from [<c0204a8c>] (mmc_start_req+0x9c/0x128) > r4:c1ab2000 > [<c02049f0>] (mmc_start_req+0x0/0x128) from [<c020e6a4>] (mmc_blk_issue_rw_rq+0x80/0x4e8) > r8:c1aefc00 r7:c1aed800 r6:c1aefc24 r5:c1aed800 r4:c1aefc24 > [<c020e624>] (mmc_blk_issue_rw_rq+0x0/0x4e8) from [<c020ef04>] (mmc_blk_issue_rq+0x3f8/0x428) > [<c020eb0c>] (mmc_blk_issue_rq+0x0/0x428) from [<c020fa8c>] (mmc_queue_thread+0xa0/0x104) > [<c020f9ec>] (mmc_queue_thread+0x0/0x104) from [<c0055bf0>] (kthread+0x88/0x90) > [<c0055b68>] (kthread+0x0/0x90) from [<c003e7d8>] (do_exit+0x0/0x62c) > r7:00000013 r6:c003e7d8 r5:c0055b68 r4:c1831c5c > ---[ end trace 1b75b31a2719ed1e ]--- > This hsmmc issue is fixed by this patch sent out today.. http://marc.info/?l=linux-mmc&m=132068306510134&w=2 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
