Skip to contentSkip to conversation

Panda: USB crash with today's linux-next

DISCUSSION Felipe Balbi 4 participants 11 messages May 14, 2012 – May 16, 2012 1 message not in the archive

lore
Share & tools
lore

A message that is not in the archive (sent off-list or not yet received): 1336996151.2333.3.camel@deskari

Felipe Balbi

author
#1 lore raw

Hi,

Quoted 45 lines · Tomi Valkeinen

Hi Felipe,

I'm seeing the following crash on Panda, when booting with today's linux-next, using the attached config.

Tomi

[    1.923400] musb-hdrc: version 6.0, ?dma?, otg (peripheral+host)
[    1.923400] Unable to handle kernel NULL pointer dereference at virtual address 00000036
[    1.938171] pgd = c0004000
[    1.941009] [00000036] *pgd=00000000
[    1.944763] Internal error: Oops: 5 [#1] SMP ARM
[    1.949584] Modules linked in:
[    1.952789] CPU: 0    Not tainted  (3.4.0-rc7-next-20120514-10436-g7769ab8 #450)
[    1.960540] PC is at kobject_get+0xc/0x4c
[    1.964721] LR is at get_device+0x14/0x1c
[    1.968933] pc : [<c0250d60>]    lr : [<c02ac47c>]    psr: 20000113
sp : ebc31d98  ip : 00000003  fp : eb36d1dc
[    1.979553] r10: eb36c128  r9 : eb349880  r8 : fc0ab000
[    1.985015] r7 : eb348408  r6 : c06f2830  r5 : eb348408  r4 : 0000001a
[    1.991851] r3 : eb349880  r2 : 00000000  r1 : c04bf2b4  r0 : 0000001a
[    1.998687] Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
[    2.006317] Control: 10c53c7d  Table: 8000404a  DAC: 00000017
[    2.012329] Process swapper/0 (pid: 1, stack limit = 0xebc302f8)
[    2.018615] Stack: (0xebc31d98 to 0xebc32000)
[    2.023162] 1d80:                                                       eb349880 c0c788f4
[    2.031707] 1da0: eb348408 c02ac47c eb349880 c033d604 eb36c128 c035bdc8 c035bdb0 0000007c
[    2.040283] 1dc0: eb348400 00000010 eb348408 c047dddc ebeba630 00000000 c0c76fd8 eb348408
[    2.048828] 1de0: c0c76fd8 c0c76fe8 00000000 c071c0ac 00000000 c0728b80 0000009e c02b0e68
[    2.057373] 1e00: c02b0e50 c02afab8 c02b10f0 eb348408 c02afcd0 00000000 00000000 c0c76f94
[    2.065948] 1e20: c0728b80 c02ae1dc ebc412d8 ebebbe94 eb348408 eb34843c c070fbc0 c02af9dc
[    2.074493] 1e40: eb348408 eb348408 c070fbc0 c02aefb8 eb348408 eb348410 ebd7c808 c02ad840
[    2.083038] 1e60: c06f8438 00000000 ebebbd78 eb3498c0 ebebbd40 c0690444 00000000 eb348400
[    2.091583] 1e80: eb348408 00000003 eb3498c0 ebebbd40 c0690444 c0728b80 0000009e c02b1480
[    2.100158] 1ea0: eb348400 00000000 ebd7c808 eb3498c0 ebd7dd00 c047e7a0 ebd7c808 c0c76fd8
[    2.108703] 1ec0: c0c76fe8 00000000 c071c16c c02b0e68 c02b0e50 c02afab8 22222222 ebd7c808
[    2.117248] 1ee0: c071c16c ebd7c83c 00000000 c067882c c0728b80 c02afccc c071c16c c02afc38
[    2.125793] 1f00: 00000000 c02ae258 ebc412a8 ebd76790 c071c16c c070fbc0 ebebbdc0 c02af16c
[    2.134368] 1f20: c0598c20 00000000 ebc489c0 c071c16c c0728b80 ebc30000 00000000 c067882c
[    2.142913] 1f40: c0690444 c0728b80 0000009e c02b0200 00000000 c0678844 c0728b80 ebc30000
[    2.151458] 1f60: 00000000 c067882c c0728b80 c0008730 c061fe04 c06207e4 c149014e c066dbe4
[    2.160003] 1f80: c0678850 00000000 c05dc310 00000001 00000006 00000006 c058cec4 c0678844
[    2.168579] 1fa0: 0000001c 00000006 c0678850 c067882c c0690444 c0728b80 0000009e c0647928
[    2.177124] 1fc0: 00000006 00000006 c06471c4 00000000 00000000 00000000 c0647810 c0014f34
Quoted 8 lines
[    2.185668] 1fe0: 00000013 00000000 00000000 00000000 00000000 c0014f34 81aaaa8a 3a80a8aa
[    2.194244] [<c0250d60>] (kobject_get+0xc/0x4c) from [<c02ac47c>] (get_device+0x14/0x1c)
[    2.202697] [<c02ac47c>] (get_device+0x14/0x1c) from [<c033d604>] (usb_get_transceiver+0x1c/0x28)
[    2.212005] [<c033d604>] (usb_get_transceiver+0x1c/0x28) from [<c035bdc8>] (omap2430_musb_init+0x
18/0x184)
[    2.222106] [<c035bdc8>] (omap2430_musb_init+0x18/0x184) from [<c047dddc>] (musb_probe+0x1bc/0x5a
0)
[    2.231567] [<c047dddc>] (musb_probe+0x1bc/0x5a0) from [<c02b0e68>] (platform_drv_probe+0x18/0x1c

looks like MUSB is probing before transceiver driver... could it be ? Can you check transceiver has actually probed ? I guess panda's using twl6030-usb.c

Signature · 1 line
balbi
#2 lore raw
Quoted 3 lines · Felipe Balbi

looks like MUSB is probing before transceiver driver... could it be ? Can you check transceiver has actually probed ? I guess panda's using twl6030-usb.c

Ah. Perhaps it's then about this?

[    0.352905] Skipping twl internal clock init and using bootloader value (unknown osc rate)
[    0.354034] twl 1-0048: PIH (irq 39) chaining IRQs 352..372
[    0.356079] VUSB: 3300 mV normal standby
[    0.358123] genirq: Threaded irq requested with handler=NULL and !ONESHOT for irq 356
[    0.358215] twl6030_usb twl6030_usb: can't get IRQ 356, err -22
[    0.358398] twl6030_usb: probe of twl6030_usb failed with error -22

Tomi

author
#3 lore raw
Quoted 6 lines · Tomi Valkeinen
Quoted 3 lines · Felipe Balbi

looks like MUSB is probing before transceiver driver... could it be ? Can you check transceiver has actually probed ? I guess panda's using twl6030-usb.c

Quoted 8 lines

Ah. Perhaps it's then about this?

[    0.352905] Skipping twl internal clock init and using bootloader value (unknown osc rate)
[    0.354034] twl 1-0048: PIH (irq 39) chaining IRQs 352..372
[    0.356079] VUSB: 3300 mV normal standby
[    0.358123] genirq: Threaded irq requested with handler=NULL and !ONESHOT for irq 356
[    0.358215] twl6030_usb twl6030_usb: can't get IRQ 356, err -22
[    0.358398] twl6030_usb: probe of twl6030_usb failed with error -22

sounds about right. Now, why can't it get the IRQ... Benoit, is this related to your sparse irq/irq_domain changes ?

Signature · 1 line
balbi
author
#4 lore raw

Hi,

Quoted 16 lines · Felipe Balbi
Quoted 6 lines · Tomi Valkeinen
Quoted 3 lines · Felipe Balbi

looks like MUSB is probing before transceiver driver... could it be ? Can you check transceiver has actually probed ? I guess panda's using twl6030-usb.c

Quoted 8 lines

Ah. Perhaps it's then about this?

[    0.352905] Skipping twl internal clock init and using bootloader value (unknown osc rate)
[    0.354034] twl 1-0048: PIH (irq 39) chaining IRQs 352..372
[    0.356079] VUSB: 3300 mV normal standby
[    0.358123] genirq: Threaded irq requested with handler=NULL and !ONESHOT for irq 356
[    0.358215] twl6030_usb twl6030_usb: can't get IRQ 356, err -22
[    0.358398] twl6030_usb: probe of twl6030_usb failed with error -22
Quoted 2 lines

sounds about right. Now, why can't it get the IRQ... Benoit, is this related to your sparse irq/irq_domain changes ?

Looks like twl6030-irq still missed conversion to threaded IRQ. It still has that ugly ass kthread to handle the IRQs. Oh well, yet another broken OMAP driver...

Signature · 1 line
balbi
#5 lore raw
Quoted 19 lines · Felipe Balbi

Hi,

Quoted 16 lines · Felipe Balbi
Quoted 14 lines · Tomi Valkeinen
Quoted 3 lines · Felipe Balbi

looks like MUSB is probing before transceiver driver... could it be ? Can you check transceiver has actually probed ? I guess panda's using twl6030-usb.c

Ah. Perhaps it's then about this?

[    0.352905] Skipping twl internal clock init and using bootloader value (unknown osc rate)
[    0.354034] twl 1-0048: PIH (irq 39) chaining IRQs 352..372
[    0.356079] VUSB: 3300 mV normal standby
[    0.358123] genirq: Threaded irq requested with handler=NULL and !ONESHOT for irq 356
[    0.358215] twl6030_usb twl6030_usb: can't get IRQ 356, err -22
[    0.358398] twl6030_usb: probe of twl6030_usb failed with error -22
Quoted 6 lines
Quoted 2 lines

sounds about right. Now, why can't it get the IRQ... Benoit, is this related to your sparse irq/irq_domain changes ?

Looks like twl6030-irq still missed conversion to threaded IRQ. It still has that ugly ass kthread to handle the IRQs. Oh well, yet another broken OMAP driver...

Well, yeah, I did not clean all that mess.

That being said, we did have some issue recently as well, but due to the increase of IRQ number and the fact the NR_IRQS is still used since SPARSE_IRQ migration is not completed.

At least we saw similar issue with OMAP5.

Maybe increasing NR_IRQS will fix that, but in this case, it looks like the IRQ might already been used by someone else. This is probably because something is still using the hard coded IRQ BASE number from the irqs.h define.

I was planning to get rid of them to highlight the broken driver / board that might still used them. But this is on my TODO list :-(

Regards,
Benoit

author
#6 lore raw

Hi,

Quoted 35 lines · Benoit
Quoted 19 lines · Felipe Balbi

Hi,

Quoted 16 lines · Felipe Balbi
Quoted 14 lines · Tomi Valkeinen
Quoted 3 lines · Felipe Balbi

looks like MUSB is probing before transceiver driver... could it be ? Can you check transceiver has actually probed ? I guess panda's using twl6030-usb.c

Ah. Perhaps it's then about this?

[    0.352905] Skipping twl internal clock init and using bootloader value (unknown osc rate)
[    0.354034] twl 1-0048: PIH (irq 39) chaining IRQs 352..372
[    0.356079] VUSB: 3300 mV normal standby
[    0.358123] genirq: Threaded irq requested with handler=NULL and !ONESHOT for irq 356
[    0.358215] twl6030_usb twl6030_usb: can't get IRQ 356, err -22
[    0.358398] twl6030_usb: probe of twl6030_usb failed with error -22
Quoted 6 lines
Quoted 2 lines

sounds about right. Now, why can't it get the IRQ... Benoit, is this related to your sparse irq/irq_domain changes ?

Looks like twl6030-irq still missed conversion to threaded IRQ. It still has that ugly ass kthread to handle the IRQs. Oh well, yet another broken OMAP driver...

Well, yeah, I did not clean all that mess.

That being said, we did have some issue recently as well, but due to the increase of IRQ number and the fact the NR_IRQS is still used since SPARSE_IRQ migration is not completed.

At least we saw similar issue with OMAP5.

Quoted 7 lines

Maybe increasing NR_IRQS will fix that, but in this case, it looks like the IRQ might already been used by someone else. This is probably because something is still using the hard coded IRQ BASE number from the irqs.h define.

I was planning to get rid of them to highlight the broken driver / board that might still used them. But this is on my TODO list :-(

another thing you might want to add to your TODO list is implementing irq_chip properly on twl6030-irq:

$ git grep -e EXPORT_SYMBOL drivers/mfd/twl6030-irq.c
drivers/mfd/twl6030-irq.c:EXPORT_SYMBOL(twl6030_interrupt_unmask);
drivers/mfd/twl6030-irq.c:EXPORT_SYMBOL(twl6030_interrupt_mask);
drivers/mfd/twl6030-irq.c:EXPORT_SYMBOL(twl6030_mmc_card_detect_config);
drivers/mfd/twl6030-irq.c:EXPORT_SYMBOL(twl6030_mmc_card_detect);
$ git grep -e "twl6030_interrupt_\(mask\|unmask\)" drivers/
drivers/mfd/twl6030-irq.c:int twl6030_interrupt_unmask(u8 bit_mask, u8 offset)
drivers/mfd/twl6030-irq.c:EXPORT_SYMBOL(twl6030_interrupt_unmask);
drivers/mfd/twl6030-irq.c:int twl6030_interrupt_mask(u8 bit_mask, u8 offset)
drivers/mfd/twl6030-irq.c:EXPORT_SYMBOL(twl6030_interrupt_mask);
drivers/mfd/twl6030-irq.c:	twl6030_interrupt_unmask(TWL6030_MMCDETECT_INT_MASK,
drivers/mfd/twl6030-irq.c:	twl6030_interrupt_unmask(TWL6030_MMCDETECT_INT_MASK,
drivers/rtc/rtc-twl.c:		twl6030_interrupt_unmask(TWL6030_RTC_INT_MASK,
drivers/rtc/rtc-twl.c:		twl6030_interrupt_unmask(TWL6030_RTC_INT_MASK,
drivers/rtc/rtc-twl.c:		twl6030_interrupt_mask(TWL6030_RTC_INT_MASK,
drivers/rtc/rtc-twl.c:		twl6030_interrupt_mask(TWL6030_RTC_INT_MASK,
drivers/usb/otg/twl6030-usb.c:	twl6030_interrupt_unmask(0x05, REG_INT_MSK_LINE_C);
drivers/usb/otg/twl6030-usb.c:	twl6030_interrupt_unmask(0x05, REG_INT_MSK_STS_C);
drivers/usb/otg/twl6030-usb.c:	twl6030_interrupt_unmask(TWL6030_CHARGER_CTRL_INT_MASK,
drivers/usb/otg/twl6030-usb.c:	twl6030_interrupt_unmask(TWL6030_CHARGER_CTRL_INT_MASK,
drivers/usb/otg/twl6030-usb.c:	twl6030_interrupt_mask(TWL6030_USBOTG_INT_MASK,
drivers/usb/otg/twl6030-usb.c:	twl6030_interrupt_mask(TWL6030_USBOTG_INT_MASK,

That whole MMC card detection is also pretty screwed up. Balaji/Venkat, can you guys look into that ? Probably making something generic using a threaded IRQ handler ?

I mean, all the MMC core should need is an IRQ number (through GPIOs or not doesn't/shouldn't matter) and it should be able to use a threaded IRQ handler to kick the card detection/initialization.

Signature · 1 line
balbi
#7 lore raw
Quoted 8 lines · Felipe Balbi

That whole MMC card detection is also pretty screwed up. Balaji/Venkat, can you guys look into that ? Probably making something generic using a threaded IRQ handler ?

I mean, all the MMC core should need is an IRQ number (through GPIOs or not doesn't/shouldn't matter) and it should be able to use a threaded IRQ handler to kick the card detection/initialization.

That's mostly done.. Just need to update the patches for it.

I posted some patches to take care of the card detection in the MMC driver by leaving out the platform callbacks:

http://lists.infradead.org/pipermail/linux-arm-kernel/2012-March/087303.html

That's using gpiochip_find_by_name(), but after talking with Grant about that, we agreed gpiochip_find_by_name() should be local as there's no guarantees about anything with the gpiochip names.

Regards,

Tony

#8 lore raw
Quoted 11 lines · Tony Lindgren
Quoted 8 lines · Felipe Balbi

That whole MMC card detection is also pretty screwed up. Balaji/Venkat, can you guys look into that ? Probably making something generic using a threaded IRQ handler ?

I mean, all the MMC core should need is an IRQ number (through GPIOs or not doesn't/shouldn't matter) and it should be able to use a threaded IRQ handler to kick the card detection/initialization.

That's mostly done.. Just need to update the patches for it.

Mostly done meaning "all the MMC core should need is an IRQ number" part that is :)

Quoted 16 lines

I posted some patches to take care of the card detection in the MMC driver by leaving out the platform callbacks:

http://lists.infradead.org/pipermail/linux-arm-kernel/2012-March/087303.html

That's using gpiochip_find_by_name(), but after talking with Grant about that, we agreed gpiochip_find_by_name() should be local as there's no guarantees about anything with the gpiochip names.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

author
#9 lore raw
Quoted 7 lines · Tony Lindgren
Quoted 6 lines · Tony Lindgren
Quoted 5 lines · Felipe Balbi

That whole MMC card detection is also pretty screwed up. Balaji/Venkat, can you guys look into that ? Probably making something generic using a threaded IRQ handler ?

Quoted 8 lines
Quoted 5 lines
Quoted 3 lines

I mean, all the MMC core should need is an IRQ number (through GPIOs or not doesn't/shouldn't matter) and it should be able to use a threaded IRQ handler to kick the card detection/initialization.

That's mostly done.. Just need to update the patches for it.

Mostly done meaning "all the MMC core should need is an IRQ number" part that is :)

but you've done it for omap_hsmmc.c, right ? What I meant is that the whole card detection should be done at the MMC framework level.

I mean, if we tell MMC core what's the card detect IRQ number, it should be able to implement a generic version of omap_hsmmc_detect(). All that thing does is read the current gpio status number and call mmc_detect_change().

mmc_detect_change() then kicks a delayed work, which shouldn't be needed because omap_hsmmc_detect() (or the generic of it) is already using a threaded IRQ.

Signature · 1 line
balbi
#10 lore raw
Quoted 12 lines · Felipe Balbi
Quoted 11 lines · Tony Lindgren
Quoted 10 lines · Tony Lindgren
Quoted 8 lines · Felipe Balbi

That whole MMC card detection is also pretty screwed up. Balaji/Venkat, can you guys look into that ? Probably making something generic using a threaded IRQ handler ?

I mean, all the MMC core should need is an IRQ number (through GPIOs or not doesn't/shouldn't matter) and it should be able to use a threaded IRQ handler to kick the card detection/initialization.

Quoted 7 lines
Quoted 4 lines
Quoted 1 line

That's mostly done.. Just need to update the patches for it.

Mostly done meaning "all the MMC core should need is an IRQ number" part that is :)

but you've done it for omap_hsmmc.c, right ? What I meant is that the whole card detection should be done at the MMC framework level.

Yes what I did was just try to start gettting rid of the platform callbacks.

Quoted 8 lines

I mean, if we tell MMC core what's the card detect IRQ number, it should be able to implement a generic version of omap_hsmmc_detect(). All that thing does is read the current gpio status number and call mmc_detect_change().

mmc_detect_change() then kicks a delayed work, which shouldn't be needed because omap_hsmmc_detect() (or the generic of it) is already using a threaded IRQ.

Yeah maybe it's doable.. The MMC driver needs to read the status of the card insert, but maybe that should be just just gpio_get_value().

Then ideally the MMC driver would not have any knowledge how the GPIO is handled as it can come from whatever gpiochip using internal GPIO or TWL GPIO.

Regards,

Tony

author
#11 lore raw
Quoted 33 lines · Tony Lindgren
Quoted 12 lines · Felipe Balbi
Quoted 11 lines · Tony Lindgren
Quoted 10 lines · Tony Lindgren
Quoted 8 lines · Felipe Balbi

That whole MMC card detection is also pretty screwed up. Balaji/Venkat, can you guys look into that ? Probably making something generic using a threaded IRQ handler ?

I mean, all the MMC core should need is an IRQ number (through GPIOs or not doesn't/shouldn't matter) and it should be able to use a threaded IRQ handler to kick the card detection/initialization.

Quoted 7 lines
Quoted 4 lines
Quoted 1 line

That's mostly done.. Just need to update the patches for it.

Mostly done meaning "all the MMC core should need is an IRQ number" part that is :)

but you've done it for omap_hsmmc.c, right ? What I meant is that the whole card detection should be done at the MMC framework level.

Yes what I did was just try to start gettting rid of the platform callbacks.

Quoted 8 lines

I mean, if we tell MMC core what's the card detect IRQ number, it should be able to implement a generic version of omap_hsmmc_detect(). All that thing does is read the current gpio status number and call mmc_detect_change().

mmc_detect_change() then kicks a delayed work, which shouldn't be needed because omap_hsmmc_detect() (or the generic of it) is already using a threaded IRQ.

Quoted 6 lines

Yeah maybe it's doable.. The MMC driver needs to read the status of the card insert, but maybe that should be just just gpio_get_value().

Then ideally the MMC driver would not have any knowledge how the GPIO is handled as it can come from whatever gpiochip using internal GPIO or TWL GPIO.

correct.

Signature · 1 line
balbi