dwc_otg sleeping in atomic (3.10.y)

[daniel-santos]

hmm, is there any way to add attachments in github?

Here's a single backtrace: http://pastebin.com/mek0rqn7
Here is the whole log (I didn't have a very large ringbuffer configured, but it's most of it) http://pastebin.com/fpjdcGdJ.
Here is my .config: http://pastebin.com/S8PwUAX8

[daniel-santos]

The issue is also present on the head of rpi-3.9.y. I rewound back to ecba5d7 (dwc_otg: fix NAK holdoff and allow on split transactions only) and the problem is not present. I don't really have time to finish bisecting it to pin-point the offending commit right now, however.

[P33M]

Can you try 30500d9 vs 8cdf875?

[P33M]

Found it, I think. In dwc_otg_hcd_linux.c:

#if USB_URB_EP_LINKING
        DWC_SPINLOCK_IRQSAVE(dwc_otg_hcd->lock, &irqflags);
    retval = usb_hcd_link_urb_to_ep(hcd, urb);
        DWC_SPINUNLOCK_IRQRESTORE(dwc_otg_hcd->lock, irqflags);
    if (0 == retval) 
#endif
        {
                retval = dwc_otg_hcd_urb_enqueue(dwc_otg_hcd, dwc_otg_urb,
                                                 /*(dwc_otg_qh_t **)*/
                                                 ref_ep_hcpriv, 
                                                 mem_flags == GFP_ATOMIC ? 1 : 0);
                if (0 == retval) {
                        if (alloc_bandwidth) {
                                allocate_bus_bandwidth(hcd,
                                        dwc_otg_hcd_get_ep_bandwidth(
                                                dwc_otg_hcd, *ref_ep_hcpriv),
                                                       urb);
                        }
                } else {
#if USB_URB_EP_LINKING
                    dwc_irqflags_t irqflags;
                        DWC_DEBUGPL(DBG_HCD, "DWC OTG dwc_otg_hcd_urb_enqueue failed rc %d\n", retval);
                        DWC_SPINLOCK_IRQSAVE(dwc_otg_hcd->lock, &irqflags);
                        usb_hcd_unlink_urb_from_ep(hcd, urb);
                        DWC_SPINUNLOCK_IRQRESTORE(dwc_otg_hcd->lock, irqflags);
#endif
                        if (retval == -DWC_E_NO_DEVICE) {
                                retval = -ENODEV;
                        }
                }
        }

We erroneously don't force the dwc_otg_hcd_urb_enqueue atomic_alloc parameter when inside the critical section. QTD is then allocated potentially without the atomic flag passed to kmalloc.

Changing this last parameter to dwc_otg_hcd_urb_enqueue to 1 inside this section fixes the issue with BUG()s for sleeping inside atomic for me, can you confirm?

[P33M]

Should be fixed as of #347

[daniel-santos]

Thank you. I apologize for not getting with you sooner on this. I was just about to do this when my apartment complex began to fumigate my apartment with toxic fumes leading me to have to take an ambulance to the hospital!! Anyway, I'll try to check this out soon and thank you for your work on this.

[popcornmix]

@daniel-santos
rpi-update will get firmware with #347

[daniel-santos]

hmm. To be honest, I didn't know how to deal with that, so I just wrote a quick-n-dirty script to create a tarball that I unpack in the pi's / dir.

#!/bin/bash
. /usr/local/bin/utils.sh

export CROSS_COMPILE=/usr/bin/armv6j-hardfloat-linux-gnueabi-
export ARCH=arm
install_dir=/tmp/rpi/install
export INSTALL_MOD_PATH=${install_dir}
export INSTALL_PATH=${install_dir}/boot

make clean
make -j4 || die

rm -rf ${install_dir}
mkdir -p ${install_dir}/boot || die
make modules_install install || die
tar czf /tmp/kernel.tgz -C ${install_dir} .
scp /tmp/kernel.tgz pi@pi:

then on my pi, I basically

#!/bin/bash

tar xf /home/pi/kernel.tgz --no-same-permissions -C /
sync

So I'm guessing that rpi-update is a cleaner way of updating the firmware eh? :)

Oh yes, and I almost forgot the most important part, no more sleeping in atomic! :) Thanks!

[popcornmix]

For the future:
https://github.com/Hexxeh/rpi-update
may be easier, but glad to hear it's fixed.

[daniel-santos]

On 08/02/2013 04:08 PM, popcornmix wrote:

For the future:
https://github.com/Hexxeh/rpi-update
may be easier, but glad to hear it's fixed.

Oh no, that's not all! It would appear that the problem with my URB
callbacks not being called is fixed as well! I'm running the latest
3.10.y (with a small patch of my own for something unrelated) and my
MCP2210 driver in full verbose-debug-spam mode and not a single URB had
to be killed and re-submitted. Good work guys!

Daniel