[Defy Android Development] Sublimis:
To share my newest findings again, which could (hopefully) help [MENTION=513620]Quarx[/MENTION] solve the telephony problem (RIL). (Quarx sorry if you already know all this...)

First of all, telephony problem is not caused by wrong baseband or baseband bug, in fact baseband has little to do with this. It is kernel power management that's responsible for leading baseband processor into panic.

To be more specific, 3.0 kernel has different ehci and usb host drivers than 2.x kernel, and it seems that it handles usb suspend/resume/reset states differently - which ultimatively leads to baseband processor disconnect/poweroff and consequently into bp_panic.

To be even more specific, 3.0 kernel resets the baseband processor (Motorola Phone () / usb device number 2 on bus 1) when it shouldn't, and this leaves the BP inaccessible. From the last_kmsg log:

[ 141.760620] usb 1-3: reset high speed USB device number 2 using ehci-omap
[ 141.773223] usb 1-3: device descriptor read/64, error -71
[ 141.900207] usb 1-3: device descriptor read/64, error -71
[ 142.002929] usb 1-3: reset high speed USB device number 2 using ehci-omap
[ 142.027343] usb 1-3: device descriptor read/64, error -71
[ 142.148010] usb 1-3: device descriptor read/64, error -71
[ 142.252777] usb 1-3: reset high speed USB device number 2 using ehci-omap
[ 142.296752] usb 1-3: device descriptor read/8, error -71
[ 142.449890] usb 1-3: device descriptor read/8, error -71
[ 142.557586] usb 1-3: reset high speed USB device number 2 using ehci-omap
[ 142.606140] usb 1-3: device descriptor read/8, error -71
[ 142.762145] usb 1-3: device descriptor read/8, error -71
[ 142.869995] usb 1-3: Reset Failed - Initiate Logical Disconnect
[ 142.870147] usb 1-3: USB disconnect, device number 2
[ 142.870697] usb 1-3: gone after usb resume? status -19,reset_count 0
[ 142.870758] usb 1-3: can't resume, status -19 Initiate Logical Disconnect
[ 142.885711] usb 1-3: new high speed USB device number 3 using ehci-omap
[ 142.907989] usb 1-3: device descriptor read/64, error -71
[ 143.035766] usb 1-3: device descriptor read/64, error -71
[ 143.143524] usb 1-3: new high speed USB device number 4 using ehci-omap
[ 143.171722] usb 1-3: device descriptor read/64, error -71
[ 143.301513] usb 1-3: device descriptor read/64, error -71
[ 143.409149] usb 1-3: new high speed USB device number 5 using ehci-omap
[ 143.457672] usb 1-3: device descriptor read/8, error -71
[ 143.613891] usb 1-3: device descriptor read/8, error -71
[ 143.721771] usb 1-3: new high speed USB device number 6 using ehci-omap
[ 143.770172] usb 1-3: device descriptor read/8, error -71
[ 143.926422] usb 1-3: device descriptor read/8, error -71
[ 144.034088] hub 1-0:1.0: unable to enumerate USB device on port 3
[ 599.971374] dyn fsync: reboot: force flush!
[ 600.174438] Restarting system.

"status -19" means "error: no device", from: errno-base.h#L22.

To learn how this happens, we note that on 2.x kernel usb hub port reset is deferred for bus #1: hub.c#L2611.

While the similar facility is present in the corresponding kernel 3.0 source: hub.c#L2852, there are also these lines present: hub.c#L3019.

Since it seems like the symbol CONFIG_MACH_OMAP_MAPPHONE_DEFY is nowhere defined, the hub_port_reset() line will ultimatively be called and will result in "device descriptor read/8, error -71" as seen in the log, also leading to subsequent errors.

Of course these are only my beliefs and could potentially be total B*S*. Sorry if this should be the case.

There is also an other possibility in my mind, that BP gets suspended in a foul way (maybe it shouldn't get suspended in the first place) and can't get resumed anymore, but I haven't researched this.

While researching, stumbled upon potentially useful page: http://lists.denx.de/pipermail/u-boot/2013-July/159262.html.