We decided to look at the modules table in the kernel to see which modules were loaded in the system. Sure enough, after we reviewed the nearly 1200 lines of output, it appeared we were dealing with a system that not only had a third-party application, but also involved a fair number of third-party kernel modules! Here is a tiny snippet of the output, just so you can see what it looks like. Here we see two of the entries in the modules table. To view the information, we used the modules macro. Hiya on clem... adb -k unix.0 vmcore.0 physmem fd87 $<modules (Severely trimmed output) fdvfs+0x6bdc: module 'abc_watch' fdvfs+0x4adc: file '/usr/kernel/drv/abc_watch' fdvfs+0x485c: next prev id mp f5b1ee40 f59b8340 67 f5b1e700 fdvfs+0x486c: thread modinfo linkage 0 0 f5bafa64 fdvfs+0x4878: filename module name f59b8740 f59ba840 fdvfs+0x4880: busy stub hold state 0 0 d0000000 fdvfs+0x488c: requisites dependents loadcnt f59b8a80 0 1 0xf5f33640: module 'abc_streams' 0xf5cff5f0: file 'strmod/abc_streams' pckt_bufcall_lock+0x6acc: next prev id mp f5f33780 f5f5d740 76 f5cdff00 pckt_bufcall_lock+0x6adc: thread modinfo linkage 0 0 f5f75624 pckt_bufcall_lock+0x6ae8: filename module name f5cff5f0 f5f33640 pckt_bufcall_lock+0x6af0: busy stub hold state 0 0 c0000000 pckt_bufcall_lock+0x6afc: requisites dependents loadcnt f5f3f560 0 1 Yes, from this, it was safe to say that the "abc" application had customized the kernel via the use of loadable modules! |