我正在进行wifi驱动的移植,android SDK的版本是4.2.2 内核是3.2.0的,但是当我将驱动代码
加入到kernel里后,编译module时出现了如下错误:
CC [M] drivers/net/wireless/bcmdhd/wl_cfg80211.o
drivers/net/wireless/bcmdhd/wl_iw.c:3062:2: error: unknown field 'num_private' specified in initializer
drivers/net/wireless/bcmdhd/wl_iw.c:3062:17: warning: initialization makes pointer from integer without a cast [enabled by default]
drivers/net/wireless/bcmdhd/wl_iw.c:3062:17: warning: (near initialization for 'wl_iw_handler_def.get_wireless_stats') [enabled by default]
drivers/net/wireless/bcmdhd/wl_iw.c:3063:2: error: unknown field 'num_private_args' specified in initializer
drivers/net/wireless/bcmdhd/wl_iw.c:3063:22: warning: excess elements in struct initializer [enabled by default]
drivers/net/wireless/bcmdhd/wl_iw.c:3063:22: warning: (near initialization for 'wl_iw_handler_def') [enabled by default]
drivers/net/wireless/bcmdhd/wl_iw.c:3065:2: error: unknown field 'private' specified in initializer
drivers/net/wireless/bcmdhd/wl_iw.c:3065:2: warning: initialization makes integer from pointer without a cast [enabled by default]
drivers/net/wireless/bcmdhd/wl_iw.c:3065:2: warning: (near initialization for 'wl_iw_handler_def.num_standard') [enabled by default]
drivers/net/wireless/bcmdhd/wl_iw.c:3065:2: error: initializer element is not computable at load time
drivers/net/wireless/bcmdhd/wl_iw.c:3065:2: error: (near initialization for 'wl_iw_handler_def.num_standard')
drivers/net/wireless/bcmdhd/wl_iw.c:3066:2: error: unknown field 'private_args' specified in initializer
drivers/net/wireless/bcmdhd/wl_iw.c:3066:2: warning: initialization from incompatible pointer type [enabled by default]
drivers/net/wireless/bcmdhd/wl_iw.c:3066:2: warning: (near initialization for 'wl_iw_handler_def.get_wireless_stats') [enabled by default]
make[4]: *** [drivers/net/wireless/bcmdhd/wl_iw.o] 错误 1
make[4]: *** 正在等待未完成的任务....
make[3]: *** [drivers/net/wireless/bcmdhd] 错误 2
make[2]: *** [drivers/net/wireless] 错误 2
make[1]: *** [drivers/net] 错误 2
make: *** [drivers] 错误 2
我找到了上面说的结构体如下:
struct iw_handler_def {
const iw_handler *standard;
__u16 num_standard;
#ifdef CONFIG_WEXT_PRIV
__u16 num_private;
__u16 num_private_args;
const iw_handler *private;
#endif
};
是不是因为kernel里面CONFIG_WEXT_PRIV没配置上啊,如果是的话要怎么配置啊,为什么我在内核里没找到这个选项啊, 而且我在.config文件中增加了CONFIG_WEXT_PRIV=y 再编译也还是出错,为什么啊?
哪位大神帮帮我啊,万分感谢
设置 1.安装kexec-tools工具,至于如何安装,在此不再多 说。 2.编译支持kdump的系统内核,我们叫他primary kernel。 确认以下内核选项已经被打开并重编内核。 1) 使能"kexec system call => Processor type and features." ,使内核支持kexec系统调用 CONFIG_KEXEC=y 2) 使能"Filesystem" => "Pseudo filesystems."=> "sysfs file system support" CONFIG_SYSFS=y 注意:如果"General Setup."=>"Configure standard kernel features (for small system)" 没有打开的话,"sysfs file system support"可能并不会在"Pseudo filesystems."中出现,如果是 这种情况,可以直接检nfig文件,确认CONFIG_SYSFS是不是已经开启。 grep 'CONFIG_SYSFS'nfig 3)使能"Kernel hacking."=>"Compile the kernel with debug info" ,保证编译出的内核带有调试符号。因为dump分析工具在读取和分析dump文件时需要这些调试符号。 CONFIG_DEBUG_INFO=Y 3. 编译dump-capture kernel 针对不同的架构,内核选项也有不同,但是不论哪种架构,以下两个选项是必选的 "Processor type and features"=> "kernel crash dumps" CONFIG_CRASH_DUMP=y "Filesystems" => "Pseudo filesystems"=>"/proc/vmcore support" CONFIG_PROC_VMCORE=y (当 CONFIG_CRASH_DUMP 被选中时,CONFIG_PROC_VMCORE会被自动选中) 下面我们看一下针对不同的架构,编 译内核还有哪些特殊的选项 1)i386 和x86_64 *在i386上,使能高内存支持"Processor type and features"=>"high memory support" CONFIG_HIGHMEM64G=y or CONFIG_HIGHMEM4G * 在i386 和x86_64上,关闭"Processor type and features"=>"symmetric multi-processing support" CONFIG_SMP=n 如果没有将该选项设为n,则需要在加载dump- capture kernel时指定参数maxcpus=1。 *如果想编译一个加载地址可浮动的内核,则选中"Processor type and features"=>"Build a relocatable kernel" CONFIG_RELOCATABLE=y * 设置合适的值给"Processor type and features"=>"Physical address where the kernel is loaded" 该值的设置与内核加载地址是否是可浮动的(即是否选中CONFIG_RELOCATABLE)有关。 如 果内核加载地址不可浮动, 则该值必须与crashkernel=Y@X中的X相同(至于crashkernel=Y@X的含义即如何使用将在后面讲到),例 如:crashkernel=64M@16M,则CONFIG_PHYSICAL_START=0x100000 0。 如果内核加载地址可 浮动,则CONFIG_PHYSICAL_START的值便可不必在意,使用默认的即可。不过为了保险起见,为了能使kdump正确执 行,CONFIG_PHYSICAL_START的值不论在何时,都要于X的值相同。 2)ppc64 除了前面两个必须的选项,其 余选项默认即可。 3)ia64 除了前面两个必须的选项,其余选项默认即可。 4.准备好两个内核后,即可按如下步 骤使用kdump 1)使用primary kernel启动系统,但是要在启动参数中加入“crashkernel=Y@X”,Y表示为dump-capture kernel 预留了多少内存空间,X该段空间的起始地址,即内核选项中CONFIG_PHYSICAL_START的值。 对于x86和x86_64架构,一般 使用crashkernel=64M@16M,CONFIG_PHYSICAL_START=0x1000000 对于ppc64架构,一般使用 crashkernel=128M@32M,CONFIG_PHYSICAL_START=0x2000000 对于ia64架构,通常使用 crashkernel=256M@256M。 2)加载dump-capture kernel 系统启动后,即可加载dump- capture kernle。 不同的架构,可以选择使用为压缩的dump-capture kernle (vmlinux) 或者压缩过的dump-capture kernle(bzImage/vmlinuz)。 i386 和x86_64: 如果dump-capture kernel编译时未选中CONFIG_RELOCATABLE,则只能使用vmlinux 如果dump-capture kernel编译时打开了CONFIG_RELOCATABLE,则可以使用bzImage/vmlinuz ppc64 : 只能使用vmlinux ia64: 可以使用vmlinux或者vmlinuz.gz 加载方法: kexec -p <dump-capture-kernel-vmlinux-image> \ --initrd=<initrd-for-dump-capture-kernel> --args-linux \ --append="root=<root-dev> <arch-specific-options>" dump- capture-kernel-vmlinux-image:表示存放dump-capture kernel 的路径 initrd-for- dump-capture-kernel:表示initrd的路径,如果没有,可以省略该参数 --args-linux:表示Pass linux kernel style options,没看明白什么意思,但是ia64架构不需要加这个参数,其他架构都要有。 --append: 该参数后跟内核启动参数。 arch-specific-options:内核启动参数的一部分,该处根据不同架构,填写不同参数。 i386, x86_64 和 ia64 填"1 irqpoll maxcpus=1 reset_devices",ppc64填"1 maxcpus=1 noirqdistrib reset_devices"。 注: 默认情况下,ELF文件头采用ELF64格式存储以支持那些拥有超过 4GB内存的系统。但是可以指定“--elf32-core-headers”标志以 强制使用ELF32格式的ELF文件头。这个标志是有必要注意的,一个重要的原因就是:当前版本的GDB不能在一个32位系统上打开一个使用ELF64格 式的vmcore文件。ELF32格式的文件头不能使用在一个“没有物理地址扩展”(non-PAE)的系统上。(即是说,少于4GB内存的系统) 1 这个参数,将启动“转储捕捉内核”到一个没有网络支持的单用户模式。如果你希望有网络支持,那么使用“init 3” maxcpus=1,这个前 面说过,如果CONFIG_SMP=n,则需要在启动参数中加入maxcpus=1。 irqpoll 的启动参数可以减低由于在“转储捕获内核”中使用了“共享中断”技术而导致出现驱动初始化失败这种情况发生的概率。 举例: kexec -p /boot/vmlinux_capture --args-linux --append="root=/dev/nfs rw nfsroot=128.224.149.6:/tftpboot/cxu/15554/rootfs ip=dhcp console=ttyS0,115200 1 maxcpus=1 noirqdistrib reset_devices" 3)测试 kdump是否成功 手动产生一个crash:echo c > /proc/sysrq-trigger。 或者可以些一个强制产生 crash的模块。 如果成功,系统将会进入热启动过程,系统启动完成后,可以执行一下uname -a ,看看内核的名字是不是有-kdump的标签呢? 然后就可以把生成的转储文件vmcore拷贝出来了,直接cp即可: cp /proc/vmcore <anywhere> 也可以通过/dev/oldmem这个设备将其考出: cd ~ mknod /dev/oldmem c 1 12 dd if=/dev/oldmem of=oldmem.001 成功将vmcore 拷贝出来后即可重启系统了。 4)分析vmcore文件 在开始分析“转储文件”之前,应该确定重启到一个稳定的内核。 可以 使用GDB在‘转储文件’上做有限的分析。分析的时候需要“带有调试信息的vmlinux文件”(编译的时候带有-g选项),运行如下命令: gdb vmlinux vmcore 注意:GDB不能分析x86平台上以ELF64格式产生的“内核转储文件”。在一个最大内存为4GB的系统上,可 以通过在“转储捕捉内核”上指定“--elf32-core-headers”标志来使用ELF32格式的文件头。 也可以使用Crash工具集来 分析Kdump产生的“内核转储文件”,crash 工具可以到网上下载: ~anderson/ 以上文档主要是翻译自内核自带文档linux/Documentation/kdump/kdump.txt,部分使用自己的语言表达。如有错误,请指正。 标签: 内核崩溃转储机制 Linux
“答案来源于网络,供您参考”
版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。