Re: MIDI gadget allocating too much from coherent pool

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Sep 16, 2015 at 06:22:27PM +0100, Felipe Tonello wrote:
> Hi Estevam,
> 
> On Tue, Sep 15, 2015 at 5:09 AM, Fabio Estevam <festevam@xxxxxxxxx> wrote:
> > On Thu, Sep 10, 2015 at 6:47 AM, Felipe Tonello <eu@xxxxxxxxxxxxxxxxx> wrote:
> >> Hi,
> >>
> >> I have the following setup:
> >>
> >> DSP (read sensors and read/send MIDI) <- UART -> SOC (imx6) <- USB
> >> MIDI GADGET -> HOST
> >>
> >> When the throughput from the DSP is high, thus causing the throughput
> >> on the USB to be high as well, I get a Kernel Panic saying to increase
> >> the coherent_pool. I've used some crazy sizes like 1M, 4M and even 8M.
> >> Obviously when I increase, it takes longer to crash but it still
> >> crashes.
> >>
> >> I am using linux-fsl 3.14.28.
> >
> > Please test it with 4.2 or 4.3-rc1 kernel.
> 
> I tested on 4.2 and still crashes. Same thing. But it doesn't say
> about the dma any longer.

then this is a different problem with v4.2, right. Which UDC controller is
your board using ? Who's the maintainer for that ?

> [  148.712916] Unable to handle kernel NULL pointer dereference at
> virtual address 00000000
> [  148.721135] pgd = 80004000
> [  148.723859] [00000000] *pgd=00000000
> [  148.727475] Internal error: Oops: 817 [#1] PREEMPT SMP ARM
> [  148.732975] Modules linked in: snd_seq_midi snd_seq_dummy
> snd_seq_midi_event snd_seq usb_f_midi snd_rawmidi snd_seq_device
> g_midi libcomposite configfs snd_soc_fsl_ssi ime
> [  148.761694] CPU: 0 PID: 3 Comm: ksoftirqd/0 Not tainted
> 4.2.0-mx6-seaboard-dirty #1
> [  148.769364] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
> [  148.775909] task: ee070980 ti: ee086000 task.ti: ee086000
> [  148.781342] PC is at _ep_queue.isra.18+0x178/0x480

care to use addr2line or gdb to figure out exactly where this is ?
gdb vmlinux followed by l *(_ep_queue.isra.18 + 0x178) should tell you
which line cause the NULL pointer dereference.

> 
> gdb shows this calls:
> (gdb) list *(ep_queue+0x44)

can you check the other one which I mentioned above ?

> 0x803caae4 is in ep_queue (../include/linux/spinlock.h:372).
> 367             raw_spin_unlock_irq(&lock->rlock);
> 368     }
> 369
> 370     static inline void spin_unlock_irqrestore(spinlock_t *lock,
> unsigned long flags)
> 371     {
> 372             raw_spin_unlock_irqrestore(&lock->rlock, flags);
> 373     }
> 374
> 375     static inline int spin_trylock_bh(spinlock_t *lock)
> 376     {
> (gdb) list *(_ep_queue)
> 0x803c9790 is in _ep_queue (../drivers/usb/chipidea/udc.c:756).
> 751     /**
> 752      * _ep_queue: queues (submits) an I/O request to an endpoint
> 753      *
> 754      * Caller must hold lock
> 755      */
> 756     static int _ep_queue(struct usb_ep *ep, struct usb_request *req,
> 757                         gfp_t __maybe_unused gfp_flags)
> 758     {
> 759             struct ci_hw_ep  *hwep  = container_of(ep,  struct
> ci_hw_ep, ep);
> 760             struct ci_hw_req *hwreq = container_of(req, struct
> ci_hw_req, req);
> 
> Any ideas on how to debug it?

you gotta figure out where is this NULL pointer coming from, then
find a way to fix it. Considering you're using chipidea, it would
be a good idea to Cc Peter, who's the chipidea maintainer.

-- 
balbi

Attachment: signature.asc
Description: Digital signature


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux