TI中文支持网我用的内核版本为2.6.32.17,dvsdk是4.02的,文件系统是用dvsdk中自带的.
因为udev脚本启动时间过长,1.有裁剪过内核,把内核中tty的个数减少了;2.去掉了在udev/rules.d文件夹下不需要的配置文件.
大部分情况下系统是可以正常启动的…但有时会阻塞在udev脚本里的/sbin/udevadm settle这条语句(等待uenvent完成).在这时候如果触发一个信号(如ctrl+c信号或者SD插拔),则系统会继续执行下去…
大家有没有遇到类似的情况?该怎么解决?
zheng chen：
问题重现方式：
1、 不断的重启系统，在某一时刻系统就会挂载失败，该方式出现的几率会比较小；
2、 进入系统后，编写一个脚本不断的重新运行udev脚本。不论是NFS，Flash启动，都会出现该问题；采用TI 365的demo板同样会出现该问题。
失败原因猜测：
udevadm settle 这条语句是等待udevadm trigger所触发的uevent事件全部处理完毕。所以猜测启动失败是由于某个uevent事件无法被正常处理，导致系统阻塞，此时只要系统有产生一个异常信号并被阻塞的进程给捕捉到，系统就可以继续正常执行。
针对该问题已做测试：
1、 查找资料知道当udevd这个守护进程没有正常跑时，对于uevent事件就没办法进行排队处理，会出现异常。所以最初猜测应该跟udevd有关，不过经过多次测试发现每次异常出现时，守护进程udevd都有正常在运行，该假设可以排除。
2、 猜想既然是某个uevent给阻塞了，而ColdPlug执行的操作是针对系统一启动就已经连接到系统的设备，没有通过HotPlug产生uevent进而在dev目录下产生设备文件，只有/sys目录下有设备信息的设备全部重新触发一次uevent事件，经过系统处理后，在dev目录下创造出设备文件。那出现该问题的原因是由于某个设备文件没有被正常创建，但是经测试发现，无论是正常启动还是异常启动，/dev目录下的设备文件都是一样的(或者可能是因为测试方法不对)。
fang zhang：
回复 zheng chen:
请问楼主有没有解决这个问题？ 设置udevadm settle –timeout=**，这种方式可行吗？
我将/dev下的tty和pty的个数减少后，基本不会挂死在那（可能是概率很小），但是还是有10秒左右的阻塞。请问有没有什么更好的建议？谢谢。
zheng chen：
回复 fang zhang:
那时候试过这个方法也不行
后来我改成启动时不去检测设备,只有在第一次启动没有dev.tar时才检测一次,之后开机启动时都不检测…. 我也没有找到好的解决方法
