From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <53134A2E.1000406@xenomai.org> References: <530CFC27.5050700@xenomai.org> <530D0205.9050406@xenomai.org> <530D0BBD.6070704@xenomai.org> <530D2C92.9010607@xenomai.org> <530E6159.4050204@xenomai.org> <530F17EC.6020204@xenomai.org> <530F9CA2.2040601@xenomai.org> <531075E7.7060107@xenomai.org> <53134A2E.1000406@xenomai.org> Date: Sun, 2 Mar 2014 17:26:16 +0000 Message-ID: From: Gregory Dymarek Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Xenomai] RaspberryPi kernel 3.8 issue List-Id: Discussions about the Xenomai project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: xenomai@xenomai.org So I started from scratch, have not used any xenomai/ipipe patches. But used the same .config. As a result all worked fine. The USB device is getting initialized correctly. So the current situation is that xenomai does work on 3.2 but does not on 3.8 because of some USB driver issues. I diff'ed the code for dwc_otg_hcd_handle_intr and this has changed. What is intriguing: https://github.com/raspberrypi/linux/blob/rpi-3.8.y/drivers/usb/host/dwc_otg/dwc_otg_hcd_intr.c#L530 // We should be OK doing this because the common interrupts should already have been serviced So I removed all the DEBUG code from this function, but this did not help either. Not sure if my test is valid in here. On 2 March 2014 15:11, Gilles Chanteperdrix < gilles.chanteperdrix@xenomai.org> wrote: > On 03/01/2014 01:27 PM, Gregory Dymarek wrote: > > Hi Gilles, > > > > Uploaded a new trace in here with them being reduced to 10 and 9 > > respectively: > > https://github.com/gregd72002/rpicopter/blob/master/tmp/frozen > > Hi Gregory, > > we see what happens before the irq storm, but unfortunately, this looks > like the USB driver is at fault. A transfer is programmed, a little bit > later the irq is received while the root domain is stalled, so is > logged, a little bit later the root domain is unstalled and the log > played, at the end it is unmasked and it triggers again. From the error > that occur we know that the irq handler returned IRQ_NONE, so did not > acknowledged the irq at device level, so it makes perfect sense that the > irq triggers again. > > In order to go further, we would have to understand how the driver > works, but it is something that is hard to do by proxy. > > The question is: are you sure that the same issue does not happen with > the exact same configuration, except without Xenomai (and without > CONFIG_IPIPE)? > > Regards. > > -- > Gilles. >