[Droid Eris Android Development] bftb0:
There's the $10,000 question right there.

Honestly, I don't know for sure.

here's a typical stretch of kernel log messages from my hacked custom recovery (using an Adata Class 6 8 GB SD card):

<6>[ 6.710327] mmc0: Qualcomm MSM SDCC at 0x00000000a0400000 irq 24,0 dma 8
<6>[ 6.710357] mmc0: Platform slot type: Not defined
<6>[ 6.710388] mmc0: 4 bit data mode enabled
<6>[ 6.710418] mmc0: MMC clock 144000 -> 50000000 Hz, PCLK 80000000 Hz
<6>[ 6.710418] mmc0: Slot eject status = 1
<6>[ 6.710449] mmc0: Power save feature enable = 1
<6>[ 6.710449] mmc0: DM non-cached buffer at ffa4c000, dma_addr 0x24951000
<6>[ 6.710479] mmc0: DM cmd busaddr 0x24951000, cmdptr busaddr 0x24951300
<7>[ 6.711090] msmsdcc_platform_status_irq: 102
<6>[ 6.711120] mmc1: Slot status change detected (0 -> 1)
<4>[ 6.711639] desirec_sdslot_switchvdd: Disabling SD slot power
[COLOR=green][B]<6>[ 6.711914] mmc1: Qualcomm MSM SDCC at 0x00000000a0500000 irq 26,102 dma 8[/B][/COLOR]
<6>[ 6.711944] mmc1: Platform slot type: SD
<6>[ 6.711944] mmc1: 4 bit data mode enabled
<6>[ 6.711975] mmc1: MMC clock 144000 -> 50000000 Hz, PCLK 80000000 Hz
<6>[ 6.711975] mmc1: Slot eject status = 0
<6>[ 6.712005] mmc1: Power save feature enable = 1
<6>[ 6.712005] mmc1: DM non-cached buffer at ffa4d000, dma_addr 0x24953000
<6>[ 6.712036] mmc1: DM cmd busaddr 0x24953000, cmdptr busaddr 0x24953300
...
...
<6>[ 7.190765] Freeing init memory: 124K
<4>[ 7.191497] Warning: unable to open an initial console.
<3>[ 7.192138] mmc1: Command timeout (cmd= 5 mci_st=00000004)
<3>[ 7.198303] mmc1: Command timeout (cmd= 5 mci_st=00000004)
<3>[ 7.204620] mmc1: Command timeout (cmd= 5 mci_st=00000004)
<3>[ 7.210784] mmc1: Command timeout (cmd= 5 mci_st=00000004)
<4>[ 7.218078] desirec_sdslot_switchvdd: Setting level to 2800
<4>[ 7.258117] mmc1: host does not support reading read-only switch. assuming write-enable.
[COLOR=green][B]<6>[ 7.258605] mmc1: new high speed SDHC card at address 0001[/B][/COLOR]
<6>[ 7.270416] mmcblk0: mmc1:0001 00000 7.60 GiB
<6>[ 7.271240] mmcblk0: p1 p2
<6>[ 7.437286] keychord: using input dev h2w headset for fevent
<6>[ 7.437805] keychord: using input dev desirec-keypad for fevent
<6>[ 7.438049] keychord: using input dev desirec-nav for fevent
[COLOR=green][B]<3>[ 7.440979] init: Unable to open persistent property directory /data/property errno: 2[/B][/COLOR]
[COLOR=red][B]<6>[ 7.495941] hsusb: ONLINE -> RESET[/B][/COLOR]
<6>[ 7.496429] hsusb: reset controller
<4>[ 7.501342] usb_ept_queue_xfer() tried to queue request while offline
<4>[ 7.530242] desirec_phy_reset
<4>[ 7.551025] usb_ept_queue_xfer() tried to queue request while offline
<4>[ 7.553527] usb_ept_queue_xfer() tried to queue request while offline

Note the three lines I highlighted:

- At around 6.7 sec, the kernel is beginning to initialize the (Qualcomm MSM) SD slot controller and turns the power off to slot #1 - the one that actually has a card in it.

- At 7.218 sec, the kernel turns power back on to that slot (mmc1)

- At 7.258 sec, the kernel starts to recognize that there is an actual card in the slot

- At 7.440 sec, "init" is initializing the Android property system (and reports that /data is not mounted).

- Almost immediately after this (7.496 sec, or 56 msec later), the USB interface resets - this is the "adbd" process coming alive.

I've looked at the Android "init.c" code, and it initializes the property system right before it runs the command queues that start the services (including "adbd") defined in init.rc - so, the point here is that there's only about 190 msec between the time the kernel is beginning to fool with the SD card and (roughly) the time when adbd might get started.

The temporal confluence of these events is probably what makes the race condition possible. If it takes a bit longer, or maybe even a bit less time for the SD card initialization to occur with a certain card, that could certainly change the relative timing of things and make the race "pop open". (Note BTW that the recovery boot never "mounts" any of the partitions of the SD card until you interactively request a SD:update.zip using the menu, so the filesystem contents of the card probably don't matter at all - in which case we/you might be complicating the 2nd race by insisting on usign a blank card, rather than putting a big (valid) HTC update.zip file on there. The same thing could probably be surmised about the cluster size formatting - that's part of the filesystem, not anything low level about the SD card, so the 4096 byte cluster may be unnecessary too.)

I hope this helps. I am damn glad you are going through all this for the leakers.

I think that what is needed at this point is someone who can build a custom kernel for us with a few debugging printk()'s so that we can carefully look at the timing of events in a custom recovery boot. The race is likely to be pretty fine-grained.

bftb0