• State
  • Locked Locked
  • Replies 11 replies
  • Subscribers 104 subscribers
  • Views 1428 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DM8148 USB serial gadget causes kworker process to 100%

dc90210
Prodigy 180 points

I enabled the USB serial gadget in the EZSDK 5.05.01.04 following these instructions:

http://processors.wiki.ti.com/index.php/Usbgeneralpage#MUSB_controller_in_gadget_mode

I see the /dev/ttyGS0 device and when I connect to a USB device I can read the vendor and product IDs.  However, the kworder process consumes 100% of the CPU until the USB cable is removed.  Has anyone encountered this?

  • 0
    TI__Genius 11470 points

    Hello,

    I will try to reproduce the issue and I will let you know, if I have something.

    Thank you.

    BR

    Vladimir

  • 0 in reply to Vladimir-XID
    Prodigy 180 points

    Hi Vladimir,

    Did you have any luck with this issue?

  • 0 in reply to dc90210
    Prodigy 10 points

    check for the interrupts on the usb controller.  They might be overloading the cpu.

  • 0 in reply to dogma tetris
    Prodigy 180 points

    dogma tetris said:

    check for the interrupts on the usb controller.  They might be overloading the cpu.

    /proc/interrupts doesn't show anything abnormal.
  • 0 in reply to dc90210
    TI__Genius 11470 points

    Hello,

    I enabled the [serial] usb gadget and everything was fine. The CPU load was completely normal. I even have tried to change the Linux console to the serial gadget and that was also working fine with normal CPU load. Please, try to search the Internet for generic possible solutions of the kworker overload issue in order to see will they work on you side.

    Thank you.

    BR

    Vladimir

  • 0 in reply to Vladimir-XID
    Prodigy 180 points

    Hi,

    I got back to looking at this after a long delay.  What I found is the kworker goes to 100% when the USB is connected but there is no serial terminal running on the PC.  Once a serial terminal application is opened on the PC, the kworker usage drops back to near zero percent and the system operates normally.  This problem also happens on the TI EVM.  So, to make this happen connect the EVM to a PC but do not start hyperterm or other app.  The problem happens if the USB is connected during boot or if it's hot plugged.

  • 0 in reply to dc90210
    Prodigy 180 points

    After more debugging I narrowed the problem to txdma_completion_work in cpii41_dma.c.  

    void txdma_completion_work(struct work_struct *data)
    {
            struct cppi41 *cppi = container_of(data, struct cppi41, txdma_work);
            struct cppi41_channel *tx_ch;
            struct musb *musb = cppi->musb;
            unsigned index;
            u8 resched = 0;
            unsigned long flags;
            while (1) {
                    spin_lock_irqsave(&musb->lock, flags);
                    for (index = 0; index < USB_CPPI41_NUM_CH; index++) {
                            void __iomem *epio;
                            u16 csr;
                            tx_ch = &cppi->tx_cppi_ch[index];
                            if (tx_ch->tx_complete) {
                                    /* Sometimes a EP can unregister from a DMA
                                     * channel while the data is still in the FIFO.
                                     * Probable reason a proper abort was not
                                     * called before taking such a step.
                                     * Protect against such cases.
                                     */
                                    if (!tx_ch->end_pt) {
                                            tx_ch->tx_complete = 0;
                                            continue;
                                    }
                                    epio = tx_ch->end_pt->regs;
                                    csr = musb_readw(epio, MUSB_TXCSR);
                                    if (!cppi->txfifo_intr_enable &&
                                            (csr & (MUSB_TXCSR_TXPKTRDY |
                                            MUSB_TXCSR_FIFONOTEMPTY))) {
                                            resched = 1;
                                    } else {
                                            tx_ch->channel.status =
                                                    MUSB_DMA_STATUS_FREE;
                                            tx_ch->tx_complete = 0;
                                            musb_dma_completion(musb, index+1, 1);
                                    }
                            }
                    }
                    spin_unlock_irqrestore(&musb->lock, flags);
                    if (!cppi->txfifo_intr_enable && resched) {
                            resched = 0;
                            cond_resched();
                    } else {
                            return ;
                    }
            }
    }
    The tx fifo has data to be sent which causes the work queue to call cond_resched infinitely until a serial connection is established.  Googling I see lots of references to this problem but no response or solution from TI.
  • 0 in reply to dc90210
    TI__Genius 11470 points

    Hello,

    I have checked for these PSP releases and the USB serial gadget is not officially supported by TI.

    BR

    Vladimir

  • 0 in reply to Vladimir-XID
    TI__Genius 11470 points

    However, unofficially I can share my personal opinion with you. If the the problem is where you saying, you could try to replace

    cond_resched();

    with something like:

    /* set task's state to interruptible sleep */
    set_current_state(TASK_INTERRUPTIBLE);

    /* take a nap and wake up in "s" seconds */
    schedule_timeout(s * HZ);

    Choose a timeout value. This should offload the system. It is not tested, not verified, no guarantees; it is just a suggestion.

    BR

    Vladimir

  • 0 in reply to Vladimir-XID
    Intellectual 745 points

    We see a similiar problem with a USB-Serial /dev/ttyUSB0.  When have a modem connect via USB that looks like USB serial.  We have serial port available to us over USB ttyUSB0/USB1.  We use the serial port to establish a ppp0 connection and all works,  However if we are send a lot of data on the ppp0 interface (over the USB serial port).  We have seem random lockup of the system.  Once we caught a kworker thread running close to 100%.

    Does the USB-Serial device (ttyUSB0) uses this same driver?  I assume it would experience the same problem?

    Thanks,

    Craig

  • 0 in reply to dc90210
    Intellectual 745 points

    What solution did you come up with?  Did you use what the TI member suggested?  Did it work?

    Thanks,

    Craig