顾客须知模板:遇到问题后。。。

遇到问题后。。。

      今天被彻底的打击了，很想从办公楼直接跳下去。

二周了，二周的时间都花在了加载一个新的controller driver,在项目里，这个是最底层的USB驱动，所以它没有工作，等于芯片就是一堆废铁。在上一周还不是很着急，但是这周彻底急了，team leader已经忍受不了整组人对这那个不能工作的片子束手无策，就这样，我开始了每天的加班生活。

底层的芯片怎么也不能工作，自己也从没有接触到这么底层的东西，而且完全是看不到摸不着想不到的。于是开始学习如何调试驱动，内核。 然后自己加printk调试，看到的仅仅是module init后就没了，然后想到了还有一个叫dummy_hcd的驱动，于是用它来试，进而了解主控制驱动是如何工作的。经对比后知道问题出在了probe时，就这样有开始了痛苦的看LDD3的生活。 当了解了USB驱动的编写后，开始了近10万行的代码上，在每晚加班到办公楼要锁门，然后回家继续到三点的痛苦阅读中，得到的结论是问题不是在代码上。 看看原来的代码已经被自己改的面目全飞。 今天上班做了一个重大决定，切从头开始！

解压出一个新的内核，尽量保留他的原貌，然后用最保守的方法－－ 将所有驱动都直接编译进内核。 然后make bzImage，将这个自己认为完全是不可能用的镜像下到了板子上后。。

s1r72v17 module init
s1r72v17: ioaddr: 0xC1852000, Chip Rev: 0x0010
gs_bind: controller 's1r72v17' not recognized
gs_bind: Gadget Serial v2.0 bound
@@(gs_module_init)usb_gadget_register_driver return[0]
gs_module_init: Gadget Serial v2.0 loaded
gs_disconnect: Gadget Serial disconnected

这个梦里都想看到的信息竟然出现了，当时真的很不想承认这是真的。 我的工作也有此转型成为一个侦探了－－是什么，为什么当初没有成功？

然后将自己一直用的内核，用同样的方法后。。

s1r72v17 module init
Unable to handle kernel NULL pointer dereference at virtual address 000000e0
pgd = c0004000
[000000e0] *pgd=00000000
Internal error: Oops: 805 [#1]
Modules linked in:
CPU: 0
PC is at usb_gadget_register_driver+0x7c/0x108
LR is at 0x1
pc : []    lr : [<00000001>]    Not tainted
sp : c028bf78  ip : 60000093  fp : c028bf94
r10: 00000000  r9 : 00000000  r8 : 00000000
r7 : c00197e8  r6 : 0000001c  r5 : 00000000  r4 : c020d7f8
r3 : c01424f8  r2 : c020d818  r1 : 00000b7c  r0 : c01d1300
Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  Segment kernel
Control: 5317F  Table: 00004000  DAC: 00000017
Process swapper (pid: 1, stack limit = 0xc028a194)
Stack: (0xc028bf78 to 0xc028c000)
bf60:                                                       c00197a8 c028a000
bf80: 00000000 c00197e8 c028bfb0 c028bf98 c00160c4 c013e790 20000013 c00197a8
bfa0: c028a000 c028bfd0 c028bfb4 c0008a44 c00160bc c023ff0c 00000000 00000000
bfc0: 00000000 c028bfe0 c028bfd4 c0008ae0 c00089f4 c028bff4 c028bfe4 c001e0a4
bfe0: c0008acc 00000000 00000000 c028bff8 c0036d48 c001e080 00000000 00000000
Backtrace:
[] (usb_gadget_register_driver+0x0/0x108) from [] (gs_module
_init+0x18/0x1b4)
 r7 = C00197E8  r6 = 00000000  r5 = C028A000  r4 = C00197A8
[] (gs_module_init+0x0/0x1b4) from [] (do_initcalls+0x60/0xd
8)
 r5 = C028A000  r4 = C00197A8
[] (do_initcalls+0x0/0xd8) from [] (do_basic_setup+0x24/0x28
)
 r7 = 00000000  r6 = 00000000  r5 = 00000000  r4 = C023FF0C
[] (do_basic_setup+0x0/0x28) from [] (init+0x34/0x134)
[] (init+0x0/0x134) from [] (do_exit+0x0/0x3b8)
 r4 = 00000000
Code: 1a000002 ebfbd8dd e3e00015 e91ba8f0 (e58520e0)
 <0>Kernel panic - not syncing: Attempted to kill init!

还是老错误。

现在想到了的就是最简单的排除法，将错内核的文件一个一个替换成功内核的，替换一个编译一次，加载看什么时候会出现错误信息。

就这样编译，加载，有20遍左右，终于找到了罪魁祸首－－ ../linux-2.6.14.6/driver/usb/gadget/Makefile 和Kconfig

就是这二个我最后替换，也认为最不可能引起错误的文件，他们让我苦了二周。

但是这二个文件中的内容在二个内核源码里都是一样的，加了同样的脚本语言，但是有一个就是成功，一个就是失败。将成功中的这二个文件拷到失败内核中，就解决了问题。 为什么，为什么，一样的文件，里面的东西也一模一样，但是会有这种事情。

最后想到的是隐藏符号引起的，是不是有些隐藏符号没有看到。 就这样将二个文件所有的制表符和空格符都显示了出来，最后看到了失败内核中的Makefile中某一行的结尾竟然多了一个空格！！！

我的天，这个也会引起错误么，就算引起错误怎么会显示是PROBE时kernel取不到handler，返回空指针导致系统崩溃。 我当时已经崩溃了，想跳楼（当时心里真实的想法）。

不过虽然是很让人郁闷，不过在逆境中学会了解决问题，自己感觉还是很值得的。 不过真的太累了，脑子有点不够用了。 想休息一下了。 还好明天公司组织去某度假村玩，生活总是这样，苦味却充满了挑战和乐趣。