Hi Doug,
On Thu, Oct 15, 2015 at 04:50:55PM -0700, Doug Anderson wrote:
> Gregory,
>
> On Mon, Oct 12, 2015 at 2:17 AM, Gregory Herrero
> <gregory.herrero@xxxxxxxxx> wrote:
> > - qh->desc_list = kzalloc(qh->desc_list_sz, flags | GFP_DMA32);
> > + qh->desc_list = kmem_cache_zalloc(desc_cache, flags | GFP_DMA32);
>
> I haven't gotten your series to work yet on Rockchip rk3288, but when
> I was trying the first error I got was a crash due to this line.
> Specifically:
>
> BUG_ON(flags & GFP_SLAB_BUG_MASK);
>
> In "new_slab()" in slub.c. I'm running on kernel 3.14 (with dwc2
> backported), so maybe things are different on ToT mainline, but I
> still see this in mainline:
>
> if (unlikely(flags & GFP_SLAB_BUG_MASK)) {
> pr_emerg("gfp: %u\n", flags & GFP_SLAB_BUG_MASK);
> BUG();
> }
>
> I see that:
> mm/internal.h:#define GFP_SLAB_BUG_MASK
> (__GFP_DMA32|__GFP_HIGHMEM|~__GFP_BITS_MASK)
>
>
> The stack crawl I had was:
>
> [<c020ff38>] (new_slab) from [<c0211a94>]
> (__slab_alloc.constprop.65+0x49c/0x548)
> [<c0211a94>] (__slab_alloc.constprop.65) from [<c0211f58>]
> (kmem_cache_alloc+0x68/0x174)
> [<c0211f58>] (kmem_cache_alloc) from [<c0462b7c>]
> (dwc2_hcd_qh_init_ddma+0x94/0x2f0)
> [<c0462b7c>] (dwc2_hcd_qh_init_ddma) from [<c0461c6c>]
> (dwc2_hcd_qh_create+0x1f4/0x23c)
> [<c0461c6c>] (dwc2_hcd_qh_create) from [<c045dd90>]
> (_dwc2_hcd_urb_enqueue+0x250/0x558)
> [<c045dd90>] (_dwc2_hcd_urb_enqueue) from [<c0449690>]
> (usb_hcd_submit_urb+0x694/0x7e0)
> [<c0449690>] (usb_hcd_submit_urb) from [<c044a814>] (usb_submit_urb+0x3f8/0x428)
> [<c044a814>] (usb_submit_urb) from [<c044af64>] (usb_start_wait_urb+0x60/0xe8)
> [<c044af64>] (usb_start_wait_urb) from [<c044b0b0>] (usb_control_msg+0xc4/0x104)
> [<c044b0b0>] (usb_control_msg) from [<c0444814>] (hub_port_init+0x368/0x948)
> [<c0444814>] (hub_port_init) from [<c044618c>] (hub_thread+0x898/0xf4c)
> [<c044618c>] (hub_thread) from [<c013e970>] (kthread+0xe4/0xfc)
> [<c013e970>] (kthread) from [<c0106278>] (ret_from_fork+0x14/0x20)
>
>
> Anyway, I'll try to continue to debug a little tomorrow, but I figured
> I'd post my findings for now.
>
Thanks for sharing your findings.
I can't reproduce this issue so far but using GFP_DMA32 is obviously
wrong here, so I will replace with GFP_DMA.
> When I reverted this patch and tried to enable DMA descriptor
> transfers, I got no crash but got:
>
> [ 40.956331] dwc2 ff540000.usb: AHB ERROR, Channel 0
> [ 40.961214] dwc2 ff540000.usb: hcchar 0x80b418c0, hcsplt 0x00000000
> [ 40.967652] dwc2 ff540000.usb: hctsiz 0x60003fff, hc_dma 0x20c3b0c0
> [ 40.974084] dwc2 ff540000.usb: Device address: 2
> [ 40.978868] dwc2 ff540000.usb: Endpoint: 3, OUT
> [ 40.983565] dwc2 ff540000.usb: Endpoint type: ISOCHRONOUS
> [ 40.989129] dwc2 ff540000.usb: Speed: FULL
> [ 40.993392] dwc2 ff540000.usb: Max packet size: 192
> [ 40.998434] dwc2 ff540000.usb: Data buffer length: 1152
> [ 41.003824] dwc2 ff540000.usb: Transfer buffer: f142d000,
> Transfer DMA: 258f6000
> [ 41.011383] dwc2 ff540000.usb: Setup buffer: (null), Setup DMA: 00000000
> [ 41.018420] dwc2 ff540000.usb: Interval: 1
>
> ...I haven't tried debugging that at all yet. ;)
>
> -Doug
You may retry with GFP_DMA. This patch is needed to get correct buffer
alignment for dwc2 controller. I guess, using non correct alignment
could lead to this kind of AHB error.
BR,
Gregory
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
