[Android Software/Hacking General [Developers Only]] mkasick:
I have a suspicion that what's going on here is actually just a (possibly long-standing) bug. However, the situation is a bit strange all around.

To be specific, I suspect it's a race condition that happens to be triggered by your kernel build, but not Samsung's. This could easily be due to nothing more than using a different compiler, i.e., one that produces more efficient code.

I notice that in "Bad Boot #1" and "Bad Boot #2", the "[MULTIPDP][poll_thread] dpram_open failed!!" message is preceeded by "[MULTIPDP]filp_open() failed~!: -6". Looking at multipdp.c, dpram_open is failing to open "/dev/dpram1" and returning ENXIO ("No such device or address"), indicating that /dev/dpram1 doesn't exist yet.

Now, there's only two references to "/dev/dpram1" in the entire stock kernel image. The first is the line in multipdp.c that it's failing on. The second is in initramfs's /sbin/init. Here, Android's init actually contains a simplified implementation of udev to handle kernel uevents. That is, it's responsible for dynamically creating device nodes as kernel drivers are loaded, one of which is /dev/dpram1.

What I think is happening is this:

init.rc insmods dpram.ko

dpram.ko registers the dpram tty devices, issuing an add uevent message for device 252:2.

... (some time elapses) ...

init processes the uevent message, creates /dev/dpram1.

Meanwhile:

init.rc insmods multipdp.ko

multipdp.ko creates the poll_thread kernel thread.

poll_tread calls dpram_open.

dpram_open attempts to open /dev/dpram1, which might not exist yet.

Probably what's happening is that Samsung's kernel "takes long enough" to get to the "insmod multipdp.ko" part of init.rc that init has time to process the dpram.ko uevents and create /dev/dpram1, so that by the time dpram_open is called, the device node exists. However, your kernel is "fast enough" that init.rc gets to "insmod multipdp.ko", creates the new kernel thread and executes it, before init has caught up on device node creation. Thus, /dev/dpram1 doesn't exist and everything goes to ****.

Now here is where it gets bizarre. If we compare against the Epic's EC05 init.rc, there's an interesting stanza prior to module initialization that's missing here:

#samsung dpram modules
mknod 0666 /dev/dpram0 c 255 1
mknod 0666 /dev/dpram1 c 255 2
mknod 0666 /dev/dpramerr c 255 0
mknod 0666 /dev/ttyCDMA0 c 240 1

Presumably this is supposed to create the missing device nodes before insmoding both dpram.ko and multipdp.ko, eliminating the race condition. However, mknod is a command not supported by init, there's no mknod program in the initramfs, and those are the wrong device numbers. Perhaps it's an acknowledgment that the race condition exists on both devices, even though nothing is actually done on the Epic to avoid it? It's just, ... strange.

Unfortunately I can't think of a great solution. One option would be to modify multipdp.c to add a sleep loop around "filp_open(DPRAM_DEVNAME, ...)" to wait for the device to be created. However, that would mean using your own compile of multipdp.ko instead of the one Samsung provides, which could open a different can of worms.

A second option is to move "insmod /lib/modules/multipdp.ko" until after mounting /system, hoping that init would've caught up by then. This can even be insured by running a script that checks for the device node and sleeps if it doesn't exist yet. Something like:

#!/system/bin/sh
for i in 1 2 3 4 5; do
ls /dev/dpram1 && break
sleep 1
done

and call it from init.rc, after mounting /system, with:

exec /system/etc/wait_for_dpram1.sh

Anyways, even if this particular issue turns out not to be the culprit, I wouldn't be too quick to conclude that Samsung must've released bad/wrong/old source code. In general, building code with a different compiler, or even a different compiler version, can shake out unfortunate bugs like this. I really hate to ruin any good-will between Samsung and the community by making inflammatory acusations when, frankly, they're probably just as puzzled as we are over this.

Best of luck!