pxa27x_udc: Oops on probe with usb cable connected.

pxa27x_udc: Oops on probe with usb cable connected.

[Antonio Ospite]

Hi,

this is a quite old issue but I'd like to bring it back on.
I get this Oops when pxa27x_udc is probed with the usb cable plugged,
this happens on a Motorola A780 phone using the openezx kernel[1] and
the gen-blob[2] second stage bootloader which disables the UDC before
booting the kernel from flash.

See the trace here:
http://people.openezx.org/ao2/tmp/pxa27x-udc_BUG/log_CRASH.txt

Here is the log of a working case (cable not plugged):
http://people.openezx.org/ao2/tmp/pxa27x-udc_BUG/log_OK.txt

Note that using the original blob bootloader from Motorola there is no
Oops but the UDC does not work at all, but maybe this is another
issue, I mean: should pxa27x_udc probe consider the case when UDC is
already active?

Here a log for this last case:
http://people.openezx.org/ao2/tmp/pxa27x-udc_BUG/log_NOCRASH_NOT_WORKING.txt

Tell me how can i help debugging this, I've put the binary and the
disassembled code in http://people.openezx.org/ao2/tmp/pxa27x-udc_BUG/
plus some notes about old discussions on the same matter.

Thanks,
   Antonio

[1] http://git.openezx.org/openezx.git
[2] http://git.openezx.org/gen-blob.git

-- 
Antonio Ospite
http://ao2.it

PGP public key ID: 0x4553B001

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20100630/1326cb47/attachment.sig>

pxa27x_udc: Oops on probe with usb cable connected.

[Robert Jarzmik]

Antonio Ospite <ospite@studenti.unina.it> writes:
> Note that using the original blob bootloader from Motorola there is no
> Oops but the UDC does not work at all, but maybe this is another
> issue, I mean: should pxa27x_udc probe consider the case when UDC is
> already active?
It was not designed for, but it actually works on my platform, when I launch
linux kernel from haret without disabling the UDC.

> Tell me how can i help debugging this, I've put the binary and the
> disassembled code in http://people.openezx.org/ao2/tmp/pxa27x-udc_BUG/
> plus some notes about old discussions on the same matter.
There are a few things I can do with a little more information.

 - Prevent gcc from being too smart by inlining functions : I think the right
   flag is -fno-inline. This will prevent irq_handle_data() and others to be
   inlined into pxa_udc_irq(), and ease the debugging.

 - add, on the first line of pxa27x_udc.c :
   #define DEBUG 1
   #define VERBOSE_DEBUG 1

Then, crash your device, and provide me with the very same traces as before :
 - the log
 - the module disassembly (which will contain irq_handle_data() and others

I will work from that.

Cheers.

--
Robert

pxa27x_udc: Oops on probe with usb cable connected.

[Antonio Ospite]

On Fri, 02 Jul 2010 20:17:42 +0200
Robert Jarzmik <robert.jarzmik@free.fr> wrote:

> Antonio Ospite <ospite@studenti.unina.it> writes:
> > Note that using the original blob bootloader from Motorola there is no
> > Oops but the UDC does not work at all, but maybe this is another
> > issue, I mean: should pxa27x_udc probe consider the case when UDC is
> > already active?
> It was not designed for, but it actually works on my platform, when I launch
> linux kernel from haret without disabling the UDC.
>

I see.

> > Tell me how can i help debugging this, I've put the binary and the
> > disassembled code in http://people.openezx.org/ao2/tmp/pxa27x-udc_BUG/
> > plus some notes about old discussions on the same matter.
> There are a few things I can do with a little more information.
> 
>  - Prevent gcc from being too smart by inlining functions : I think the right
>    flag is -fno-inline. This will prevent irq_handle_data() and others to be
>    inlined into pxa_udc_irq(), and ease the debugging.
>

Done that as well this time. See
http://people.openezx.org/ao2/tmp/pxa27x-udc_BUG/
I replaced the old files with the new ones as per your instructions.

Thanks,
   Antonio

-- 
Antonio Ospite
http://ao2.it

PGP public key ID: 0x4553B001

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20100703/c34854b0/attachment.sig>

pxa27x_udc: Oops on probe with usb cable connected.

[Robert Jarzmik]

Antonio Ospite <ospite@studenti.unina.it> writes:

> Done that as well this time. See
> http://people.openezx.org/ao2/tmp/pxa27x-udc_BUG/
> I replaced the old files with the new ones as per your instructions.
>
> Thanks,
>    Antonio

Nice.

Now, would you test the patch attached in this mail to see if :
 - it fixes your Oops
 - the UDC is usable after you attach a gadget driver to pxa27x_udc

Cheers.

--
Robert

---
diff --git a/drivers/usb/gadget/pxa27x_udc.c b/drivers/usb/gadget/pxa27x_udc.c
index 85b0d89..d76d9ee 100644
--- a/drivers/usb/gadget/pxa27x_udc.c
+++ b/drivers/usb/gadget/pxa27x_udc.c
@@ -1938,6 +1938,9 @@ static void handle_ep0_ctrl_req(struct pxa_udc *udc,
 	nuke(ep, -EPROTO);
 	spin_lock_irqsave(&ep->lock, flags);
 
+	if (!udc->driver)
+		goto stall;
+
 	/*
 	 * In the PXA320 manual, in the section about Back-to-Back setup
 	 * packets, it describes this situation.  The solution is to set OPC to

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch.txt
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20100704/0c0b80fc/attachment.txt>

pxa27x_udc: Oops on probe with usb cable connected.

[Antonio Ospite]

On Sun, 04 Jul 2010 01:48:57 +0200
Robert Jarzmik <robert.jarzmik@free.fr> wrote:

> Antonio Ospite <ospite@studenti.unina.it> writes:
> 
> > Done that as well this time. See
> > http://people.openezx.org/ao2/tmp/pxa27x-udc_BUG/
> > I replaced the old files with the new ones as per your instructions.
> 
> Nice.
> 
> Now, would you test the patch attached in this mail to see if :
>  - it fixes your Oops
>  - the UDC is usable after you attach a gadget driver to pxa27x_udc
>

The Oops does not occurr anymore but UDC does not work yet, with DEBUG
disabled I see kernel stops here, no more messages _at_all_ after that:
<6>[    7.196467] pxa27x_udc: version 2008-04-18
<6>[    7.201653] pxa27x-udc pxa27x-udc: USB reset

And on the host side I get:
[ 6512.104045] usb 4-2: new full speed USB device using ohci_hcd and address 50
[ 6512.512030] usb 4-2: device not accepting address 50, error -62
[ 6512.512063] hub 4-0:1.0: unable to enumerate USB device on port 2

If I enable debug back I can see some messages repeated over
and over:

<7>[   12.545381] pxa27x-udc pxa27x-udc: ep0:handle_ep0_ctrl_req: protocol STALL, udccsr0=0c1 err 1
<7>[   12.554164] pxa27x-udc pxa27x-udc: ep0:set_ep0state: state=SETUP_STAGE->STALL, udccsr0=0x0c1, udcbcr=8
<7>[   12.562987] pxa27x-udc pxa27x-udc: ep0:handle_ep0: state=STALL, req=(null), udccsr0=0x0c1, udcbcr=8, irq_msk=1
<7>[   12.571818] pxa27x-udc pxa27x-udc: ep0:set_ep0state: state=STALL->SETUP_STAGE, udccsr0=0x0c1, udcbcr=8
<7>[   12.580628] pxa27x-udc pxa27x-udc: ep0:handle_ep0_ctrl_req: protocol STALL, udccsr0=0c1 err 1
<7>[   12.589416] pxa27x-udc pxa27x-udc: ep0:set_ep0state: state=SETUP_STAGE->STALL, udccsr0=0x0c1, udcbcr=8
<7>[   12.598241] pxa27x-udc pxa27x-udc: ep0:handle_ep0: state=STALL, req=(null), udccsr0=0x0c1, udcbcr=8, irq_msk=1
<7>[   12.607076] pxa27x-udc pxa27x-udc: ep0:set_ep0state: state=STALL->SETUP_STAGE, udccsr0=0x0c1, udcbcr=8
<7>[   12.615890] pxa27x-udc pxa27x-udc: ep0:handle_ep0_ctrl_req: protocol STALL, udccsr0=0c1 err 1
<7>[   12.624681] pxa27x-udc pxa27x-udc: ep0:set_ep0state: state=SETUP_STAGE->STALL, udccsr0=0x0c1, udcbcr=8
<7>[   12.633513] pxa27x-udc pxa27x-udc: ep0:handle_ep0: state=STALL, req=(null), udccsr0=0x0c1, udcbcr=8, irq_msk=1
<7>[   12.642354] pxa27x-udc pxa27x-udc: ep0:set_ep0state: state=STALL->SETUP_STAGE, udccsr0=0x0c1, udcbcr=8

I noted that (either with or without this patch) a quite similar phone
works, it's Motorola A1200 and has a different bootloader.
Maybe comparing some registers can help here?

Regards,
   Antonio

-- 
Antonio Ospite
http://ao2.it

PGP public key ID: 0x4553B001

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20100705/d8f776b2/attachment.sig>

pxa27x_udc: Oops on probe with usb cable connected.

[Robert Jarzmik]

Antonio Ospite <ospite@studenti.unina.it> writes:

>> Now, would you test the patch attached in this mail to see if :
>>  - it fixes your Oops
>>  - the UDC is usable after you attach a gadget driver to pxa27x_udc
>>
>
> The Oops does not occurr anymore but UDC does not work yet, with DEBUG
> disabled I see kernel stops here, no more messages _at_all_ after that:
> <6>[    7.196467] pxa27x_udc: version 2008-04-18
> <6>[    7.201653] pxa27x-udc pxa27x-udc: USB reset
>
> And on the host side I get:
> [ 6512.104045] usb 4-2: new full speed USB device using ohci_hcd and address 50
> [ 6512.512030] usb 4-2: device not accepting address 50, error -62
> [ 6512.512063] hub 4-0:1.0: unable to enumerate USB device on port 2
>
> If I enable debug back I can see some messages repeated over
> and over:
>
> <7>[   12.545381] pxa27x-udc pxa27x-udc: ep0:handle_ep0_ctrl_req: protocol STALL, udccsr0=0c1 err 1
> <7>[   12.554164] pxa27x-udc pxa27x-udc: ep0:set_ep0state: state=SETUP_STAGE->STALL, udccsr0=0x0c1, udcbcr=8
> <7>[   12.562987] pxa27x-udc pxa27x-udc: ep0:handle_ep0: state=STALL, req=(null), udccsr0=0x0c1, udcbcr=8, irq_msk=1
> <7>[   12.571818] pxa27x-udc pxa27x-udc: ep0:set_ep0state: state=STALL->SETUP_STAGE, udccsr0=0x0c1, udcbcr=8
> <7>[   12.580628] pxa27x-udc pxa27x-udc: ep0:handle_ep0_ctrl_req: protocol STALL, udccsr0=0c1 err 1
> <7>[   12.589416] pxa27x-udc pxa27x-udc: ep0:set_ep0state: state=SETUP_STAGE->STALL, udccsr0=0x0c1, udcbcr=8
> <7>[   12.598241] pxa27x-udc pxa27x-udc: ep0:handle_ep0: state=STALL, req=(null), udccsr0=0x0c1, udcbcr=8, irq_msk=1
> <7>[   12.607076] pxa27x-udc pxa27x-udc: ep0:set_ep0state: state=STALL->SETUP_STAGE, udccsr0=0x0c1, udcbcr=8
> <7>[   12.615890] pxa27x-udc pxa27x-udc: ep0:handle_ep0_ctrl_req: protocol STALL, udccsr0=0c1 err 1
> <7>[   12.624681] pxa27x-udc pxa27x-udc: ep0:set_ep0state: state=SETUP_STAGE->STALL, udccsr0=0x0c1, udcbcr=8
> <7>[   12.633513] pxa27x-udc pxa27x-udc: ep0:handle_ep0: state=STALL, req=(null), udccsr0=0x0c1, udcbcr=8, irq_msk=1
> <7>[   12.642354] pxa27x-udc pxa27x-udc: ep0:set_ep0state: state=STALL->SETUP_STAGE, udccsr0=0x0c1, udcbcr=8
That sequence prooves the patch works.
The patch purpose is to stall the control endpoint as long as no gadget driver
regitered itself and prevent the Oops.

What should be happening is that you didn't inserted one of the modules :
 - g_ether
 - or g_zero
 - or g_storage

Or, if you did, there is a sequence that somehow prevents the correct hook up
between the pxa27_udc and g_ether for instance. If you want to be convinced, add
a printk() at the beginning of usb_gadget_register_driver() in pxa27x_udc.c, and
you shall see that it is never called in your case.

That's pretty wierd, because as soon as g_ether is inserted, and because
pxa27x_udc was inserted before, the gadget layer calls the register function of
pxa27x_udc, which should link the gadget and the gadget driver.

> I noted that (either with or without this patch) a quite similar phone
> works, it's Motorola A1200 and has a different bootloader.
> Maybe comparing some registers can help here?
Mmmm. I would rather bet on modules order if I had to. Or some wierd sequence.

Do you have the possibility, in your boot sequence, in one of the init scripts,
to add :
modprobe pxa27x_udc
modprobe g_ether

And see what comes out of it ?

I'm afraid I'm a bit at a loss to investigate further, as I can't reproduce the
test case myself ... All I can think of is modules ordering ATM.

Cheers.

--
Robert

pxa27x_udc: Oops on probe with usb cable connected.

[Antonio Ospite]

On Wed, 07 Jul 2010 00:34:46 +0200
Robert Jarzmik <robert.jarzmik@free.fr> wrote:

> Antonio Ospite <ospite@studenti.unina.it> writes:
> 
> >> Now, would you test the patch attached in this mail to see if :
> >>  - it fixes your Oops
> >>  - the UDC is usable after you attach a gadget driver to pxa27x_udc
> >>
> >
> > The Oops does not occurr anymore but UDC does not work yet, with DEBUG
> > disabled I see kernel stops here, no more messages _at_all_ after that:
> > <6>[    7.196467] pxa27x_udc: version 2008-04-18
> > <6>[    7.201653] pxa27x-udc pxa27x-udc: USB reset
> >
> > And on the host side I get:
> > [ 6512.104045] usb 4-2: new full speed USB device using ohci_hcd and address 50
> > [ 6512.512030] usb 4-2: device not accepting address 50, error -62
> > [ 6512.512063] hub 4-0:1.0: unable to enumerate USB device on port 2
> >
> > If I enable debug back I can see some messages repeated over
> > and over:
> >
> > <7>[   12.545381] pxa27x-udc pxa27x-udc: ep0:handle_ep0_ctrl_req: protocol STALL, udccsr0=0c1 err 1
> > <7>[   12.554164] pxa27x-udc pxa27x-udc: ep0:set_ep0state: state=SETUP_STAGE->STALL, udccsr0=0x0c1, udcbcr=8
> > <7>[   12.562987] pxa27x-udc pxa27x-udc: ep0:handle_ep0: state=STALL, req=(null), udccsr0=0x0c1, udcbcr=8, irq_msk=1
> > <7>[   12.571818] pxa27x-udc pxa27x-udc: ep0:set_ep0state: state=STALL->SETUP_STAGE, udccsr0=0x0c1, udcbcr=8
> > <7>[   12.580628] pxa27x-udc pxa27x-udc: ep0:handle_ep0_ctrl_req: protocol STALL, udccsr0=0c1 err 1
> > <7>[   12.589416] pxa27x-udc pxa27x-udc: ep0:set_ep0state: state=SETUP_STAGE->STALL, udccsr0=0x0c1, udcbcr=8
> > <7>[   12.598241] pxa27x-udc pxa27x-udc: ep0:handle_ep0: state=STALL, req=(null), udccsr0=0x0c1, udcbcr=8, irq_msk=1
> > <7>[   12.607076] pxa27x-udc pxa27x-udc: ep0:set_ep0state: state=STALL->SETUP_STAGE, udccsr0=0x0c1, udcbcr=8
> > <7>[   12.615890] pxa27x-udc pxa27x-udc: ep0:handle_ep0_ctrl_req: protocol STALL, udccsr0=0c1 err 1
> > <7>[   12.624681] pxa27x-udc pxa27x-udc: ep0:set_ep0state: state=SETUP_STAGE->STALL, udccsr0=0x0c1, udcbcr=8
> > <7>[   12.633513] pxa27x-udc pxa27x-udc: ep0:handle_ep0: state=STALL, req=(null), udccsr0=0x0c1, udcbcr=8, irq_msk=1
> > <7>[   12.642354] pxa27x-udc pxa27x-udc: ep0:set_ep0state: state=STALL->SETUP_STAGE, udccsr0=0x0c1, udcbcr=8
> That sequence prooves the patch works.
> The patch purpose is to stall the control endpoint as long as no gadget driver
> regitered itself and prevent the Oops.
>

but it looks like it is stalling the whole kernel, as I said before:
 The Oops does not occurr anymore but UDC does not work yet, with DEBUG
 disabled I see kernel stops here, no more messages _at_all_ after that:
 <6>[    7.196467] pxa27x_udc: version 2008-04-18
 <6>[    7.201653] pxa27x-udc pxa27x-udc: USB reset

> What should be happening is that you didn't inserted one of the modules :
>  - g_ether
>  - or g_zero
>  - or g_storage
> 
> Or, if you did, there is a sequence that somehow prevents the correct hook up
> between the pxa27_udc and g_ether for instance. If you want to be convinced, add
> a printk() at the beginning of usb_gadget_register_driver() in pxa27x_udc.c, and
> you shall see that it is never called in your case.
>

The weird thing is that the same kernel binary works on one machine
(A1200) and doesn't on the other (A780), so a linking problem is to
exclude.

I am talking about linking because right now I have both:
CONFIG_USB_GADGET_PXA27X=y
CONFIG_USB_ETH=y

I'll try building them as modules and using the loading order you
suggest below.

> That's pretty wierd, because as soon as g_ether is inserted, and because
> pxa27x_udc was inserted before, the gadget layer calls the register function of
> pxa27x_udc, which should link the gadget and the gadget driver.
>

I am sure I am missing something here, if pxa27x_udc stalls, and prevent
my kernel doing anything else at all, how can g_ether ever be loaded?

> > I noted that (either with or without this patch) a quite similar phone
> > works, it's Motorola A1200 and has a different bootloader.
> > Maybe comparing some registers can help here?
> Mmmm. I would rather bet on modules order if I had to. Or some wierd sequence.
> 
> Do you have the possibility, in your boot sequence, in one of the init scripts,
> to add :
> modprobe pxa27x_udc
> modprobe g_ether
>
> And see what comes out of it ?
>

I'll try that btw, to see if there's some difference.
 
> I'm afraid I'm a bit at a loss to investigate further, as I can't reproduce the
> test case myself ... All I can think of is modules ordering ATM.
>

I understand. You've been always very helpful btw, I am sure if you
happen to have some "enlightenment" you'll get back to this :)

Thanks again,
   Antonio

-- 
Antonio Ospite
http://ao2.it

PGP public key ID: 0x4553B001

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20100707/9bdb462e/attachment-0001.sig>

pxa27x_udc: Oops on probe with usb cable connected.

[Robert Jarzmik]

Antonio Ospite <ospite@studenti.unina.it> writes:

> The Oops does not occurr anymore but UDC does not work yet, with DEBUG
> disabled I see kernel stops here, no more messages _at_all_ after that:
> <6>[    7.196467] pxa27x_udc: version 2008-04-18
> <6>[    7.201653] pxa27x-udc pxa27x-udc: USB reset
>
> And on the host side I get:
> [ 6512.104045] usb 4-2: new full speed USB device using ohci_hcd and address 50
> [ 6512.512030] usb 4-2: device not accepting address 50, error -62
> [ 6512.512063] hub 4-0:1.0: unable to enumerate USB device on port 2
>
> If I enable debug back I can see some messages repeated over
> and over:
>
> <7>[   12.545381] pxa27x-udc pxa27x-udc: ep0:handle_ep0_ctrl_req: protocol STALL, udccsr0=0c1 err 1
> <7>[   12.554164] pxa27x-udc pxa27x-udc: ep0:set_ep0state: state=SETUP_STAGE->STALL, udccsr0=0x0c1, udcbcr=8
> <7>[   12.562987] pxa27x-udc pxa27x-udc: ep0:handle_ep0: state=STALL, req=(null), udccsr0=0x0c1, udcbcr=8, irq_msk=1
> <7>[   12.571818] pxa27x-udc pxa27x-udc: ep0:set_ep0state: state=STALL->SETUP_STAGE, udccsr0=0x0c1, udcbcr=8
> <7>[   12.580628] pxa27x-udc pxa27x-udc: ep0:handle_ep0_ctrl_req: protocol STALL, udccsr0=0c1 err 1
> <7>[   12.589416] pxa27x-udc pxa27x-udc: ep0:set_ep0state: state=SETUP_STAGE->STALL, udccsr0=0x0c1, udcbcr=8
> <7>[   12.598241] pxa27x-udc pxa27x-udc: ep0:handle_ep0: state=STALL, req=(null), udccsr0=0x0c1, udcbcr=8, irq_msk=1
> <7>[   12.607076] pxa27x-udc pxa27x-udc: ep0:set_ep0state: state=STALL->SETUP_STAGE, udccsr0=0x0c1, udcbcr=8
> <7>[   12.615890] pxa27x-udc pxa27x-udc: ep0:handle_ep0_ctrl_req: protocol STALL, udccsr0=0c1 err 1
> <7>[   12.624681] pxa27x-udc pxa27x-udc: ep0:set_ep0state: state=SETUP_STAGE->STALL, udccsr0=0x0c1, udcbcr=8
> <7>[   12.633513] pxa27x-udc pxa27x-udc: ep0:handle_ep0: state=STALL, req=(null), udccsr0=0x0c1, udcbcr=8, irq_msk=1
> <7>[   12.642354] pxa27x-udc pxa27x-udc: ep0:set_ep0state:
> state=STALL->SETUP_STAGE, udccsr0=0x0c1, udcbcr=8

Well, the UDC is responding to each request from the USB host by stalling the
USB endpoint (and not by stalling the full kernel). This shows that at least
kernel interrupts are still alive and working.

> I noted that (either with or without this patch) a quite similar phone
> works, it's Motorola A1200 and has a different bootloader.
> Maybe comparing some registers can help here?

I'm still not fully convinced the pxa27x_udc is blocking the kernel. As the
interrupt is working properly, and the interrupt handler relies on a spinlock,
the spinlock is correcly released after each interrupt, and the driver should
work normally.
Now, the interrupt "storm" could block the kernel. That would rather be an host
issue. Did you try to connect your phone to another computer ?

I would ask for a last test : on the first line of function pxa_udc_probe(),
insert "return 0;". If kernel still stalls, the pxa27x-udc is not involved.

Cheers.

--
Robert

pxa27x_udc: Oops on probe with usb cable connected.

[Antonio Ospite]

On Sun, 11 Jul 2010 10:13:56 +0200
Robert Jarzmik <robert.jarzmik@free.fr> wrote:

> Antonio Ospite <ospite@studenti.unina.it> writes:
> 
> > The Oops does not occurr anymore but UDC does not work yet, with DEBUG
> > disabled I see kernel stops here, no more messages _at_all_ after that:
> > <6>[    7.196467] pxa27x_udc: version 2008-04-18
> > <6>[    7.201653] pxa27x-udc pxa27x-udc: USB reset
> >
> > And on the host side I get:
> > [ 6512.104045] usb 4-2: new full speed USB device using ohci_hcd and address 50
> > [ 6512.512030] usb 4-2: device not accepting address 50, error -62
> > [ 6512.512063] hub 4-0:1.0: unable to enumerate USB device on port 2
> >
> > If I enable debug back I can see some messages repeated over
> > and over:
> >
[...]
> 
> Well, the UDC is responding to each request from the USB host by stalling the
> USB endpoint (and not by stalling the full kernel). This shows that at least
> kernel interrupts are still alive and working.
> 
> > I noted that (either with or without this patch) a quite similar phone
> > works, it's Motorola A1200 and has a different bootloader.
> > Maybe comparing some registers can help here?
> 
> I'm still not fully convinced the pxa27x_udc is blocking the kernel. As the
> interrupt is working properly, and the interrupt handler relies on a spinlock,
> the spinlock is correcly released after each interrupt, and the driver should
> work normally.
> Now, the interrupt "storm" could block the kernel. That would rather be an host
> issue. Did you try to connect your phone to another computer ?
>
> I would ask for a last test : on the first line of function pxa_udc_probe(),
> insert "return 0;". If kernel still stalls, the pxa27x-udc is not involved.
>

By inserting that "return 0;" the kernel goes on and I can complete
booting.

BTW, I added some dumb debug calls to see the driver functions sequence
on both a780 and a1200 and it turns out that on A1200 I don't have this
IRQ that makes the driver(?) crazy on a780, does this new info give any
new element to you to find out the root cause? The two phones have
slight different hardware tho.

Here are the two calling sequences:
http://people.openezx.org/ao2/tmp/pxa27x-udc_BUG/udc_a780.txt
http://people.openezx.org/ao2/tmp/pxa27x-udc_BUG/udc_a1200.txt

And the changes to obtain them:
http://people.openezx.org/ao2/tmp/pxa27x-udc_BUG/udc_fcall_printk.patch

Thanks a lot,
   Antonio

-- 
Antonio Ospite
http://ao2.it

PGP public key ID: 0x4553B001

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20100722/00ed3d24/attachment.sig>

pxa27x_udc: Oops on probe with usb cable connected.

[Antonio Ospite]

On Thu, 22 Jul 2010 17:14:04 +0200
Antonio Ospite <ospite@studenti.unina.it> wrote:

> On Sun, 11 Jul 2010 10:13:56 +0200
> Robert Jarzmik <robert.jarzmik@free.fr> wrote:
> 
[...]
> > Well, the UDC is responding to each request from the USB host by stalling the
> > USB endpoint (and not by stalling the full kernel). This shows that at least
> > kernel interrupts are still alive and working.
> > 
> > > I noted that (either with or without this patch) a quite similar phone
> > > works, it's Motorola A1200 and has a different bootloader.
> > > Maybe comparing some registers can help here?
> > 
> > I'm still not fully convinced the pxa27x_udc is blocking the kernel. As the
> > interrupt is working properly, and the interrupt handler relies on a spinlock,
> > the spinlock is correcly released after each interrupt, and the driver should
> > work normally.
> > Now, the interrupt "storm" could block the kernel. That would rather be an host
> > issue. Did you try to connect your phone to another computer ?
> >
> > I would ask for a last test : on the first line of function pxa_udc_probe(),
> > insert "return 0;". If kernel still stalls, the pxa27x-udc is not involved.
> >
> 
> By inserting that "return 0;" the kernel goes on and I can complete
> booting.
> 
> BTW, I added some dumb debug calls to see the driver functions sequence
> on both a780 and a1200 and it turns out that on A1200 I don't have this
> IRQ that makes the driver(?) crazy on a780, does this new info give any
> new element to you to find out the root cause? The two phones have
> slight different hardware tho.
> 
> Here are the two calling sequences:
> http://people.openezx.org/ao2/tmp/pxa27x-udc_BUG/udc_a780.txt
> http://people.openezx.org/ao2/tmp/pxa27x-udc_BUG/udc_a1200.txt
>

After that I tried deferring request_irq until the gadget driver has
been registered, and it seems to work I don't get the Oops anymore,
I see this as a quickfix I don't know if I like it as it does not look
correct to me, but it could be another element toward a proper solution.

See the inlined patch:

diff --git a/drivers/usb/gadget/pxa27x_udc.c b/drivers/usb/gadget/pxa27x_udc.c
index 85b0d89..f083c5e 100644
--- a/drivers/usb/gadget/pxa27x_udc.c
+++ b/drivers/usb/gadget/pxa27x_udc.c
@@ -1791,6 +1791,7 @@ static void udc_enable(struct pxa_udc *udc)
 	udc->enabled = 1;
 }
 
+static irqreturn_t pxa_udc_irq(int irq, void *_dev);
 /**
  * usb_gadget_register_driver - Register gadget driver
  * @driver: gadget driver
@@ -1847,6 +1848,16 @@ int usb_gadget_register_driver(struct usb_gadget_driver *driver)
 
 	if (should_enable_udc(udc))
 		udc_enable(udc);
+
+	/* irq setup after old hardware state is cleaned up */
+	retval = request_irq(udc->irq, pxa_udc_irq,
+			IRQF_SHARED, driver_name, udc);
+	if (retval != 0) {
+		dev_err(udc->dev, "%s: can't get irq %i, err %d\n",
+			driver_name, IRQ_USB, retval);
+		goto transceiver_fail;
+	}
+
 	return 0;
 
 transceiver_fail:
@@ -2507,15 +2518,6 @@ static int __init pxa_udc_probe(struct platform_device *pdev)
 	udc_init_data(udc);
 	pxa_eps_setup(udc);
 
-	/* irq setup after old hardware state is cleaned up */
-	retval = request_irq(udc->irq, pxa_udc_irq,
-			IRQF_SHARED, driver_name, udc);
-	if (retval != 0) {
-		dev_err(udc->dev, "%s: can't get irq %i, err %d\n",
-			driver_name, IRQ_USB, retval);
-		goto err_irq;
-	}
-
 	pxa_init_debugfs(udc);
 	return 0;
 err_irq:

-- 
Antonio Ospite
http://ao2.it

PGP public key ID: 0x4553B001

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20100723/9bef7365/attachment.sig>

pxa27x_udc: Oops on probe with usb cable connected.

[Robert Jarzmik]

Antonio Ospite <ospite@studenti.unina.it> writes:

> On Thu, 22 Jul 2010 17:14:04 +0200
> Antonio Ospite <ospite@studenti.unina.it> wrote:
>> > Now, the interrupt "storm" could block the kernel. That would rather be an host
>> > issue. Did you try to connect your phone to another computer ?
>> >
>> > I would ask for a last test : on the first line of function pxa_udc_probe(),
>> > insert "return 0;". If kernel still stalls, the pxa27x-udc is not involved.
>> >
>> 
>> By inserting that "return 0;" the kernel goes on and I can complete
>> booting.
Too bad, pxa27x_udc has to be the culprit ...

Okay, I have a new track.
Would you apply the patch below and see if that improves your problem. This one
should:
 - disable the pullup line (and thus no irq should be triggered)
 - if an early irq is triggered anyway, don't handle it if no gadget driver was subscribed

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch.txt
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20100723/defe4b44/attachment.txt>
-------------- next part --------------

Cheers.

-- 
Robert