解析内核错误信息
2015-05-11 20:04
197 查看
BUG: sleeping function called from invalid context at mm/slub.c:795
in_atomic(): 1, irqs_disabled(): 128, pid: 0, name: swapper
[<c0038d70>] (unwind_backtrace+0x0/0xe4) from [<c00a0400>] (__kmalloc+0x6c/0xf4)
[<c00a0400>] (__kmalloc+0x6c/0xf4) from [<c01fac00>] (ohci_urb_enqueue+0x218/0x68c)
[<c01fac00>] (ohci_urb_enqueue+0x218/0x68c) from [<c01eed00>] (usb_hcd_submit_urb+0x7ac/0x8c4)
[<c01eed00>] (usb_hcd_submit_urb+0x7ac/0x8c4) from [<c01edc30>] (usb_hcd_giveback_urb+0x70/0xb8)
[<c01edc30>] (usb_hcd_giveback_urb+0x70/0xb8) from [<c01fa72c>] (finish_urb+0x7c/0xb8)
[<c01fa72c>] (finish_urb+0x7c/0xb8) from [<c01fbddc>] (finish_unlinks+0x168/0x2b8)
[<c01fbddc>] (finish_unlinks+0x168/0x2b8) from [<c01fe288>] (ohci_irq+0x438/0x4e4)
[<c01fe288>] (ohci_irq+0x438/0x4e4) from [<c01ed72c>] (usb_hcd_irq+0x38/0x88)
[<c01ed72c>] (usb_hcd_irq+0x38/0x88) from [<c0076068>] (handle_IRQ_event+0x24/0xe0)
[<c0076068>] (handle_IRQ_event+0x24/0xe0) from [<c00779a0>] (handle_level_irq+0xbc/0x13c)
[<c00779a0>] (handle_level_irq+0xbc/0x13c) from [<c0029070>] (asm_do_IRQ+0x70/0x94)
[<c0029070>] (asm_do_IRQ+0x70/0x94) from [<c0033248>] (__irq_svc+0x48/0xa0)
Exception stack(0xc0395f78 to 0xc0395fc0)
5f60: 00000000 00000000
5f80: c0395fc0 00000000 c0394000 c039925c c03ba3a4 c05f2900 500212f4 410fb766
5fa0: 5002128c 00000000 cfb96044 c0395fc0 c00348c0 c00346dc 60000013 ffffffff
[<c0033248>] (__irq_svc+0x48/0xa0) from [<c00346dc>] (default_idle+0x14/0x18)
[<c00346dc>] (default_idle+0x14/0x18) from [<c00348c0>] (cpu_idle+0x40/0x8c)
[<c00348c0>] (cpu_idle+0x40/0x8c) from [<c00089ec>] (start_kernel+0x270/0x2c8)
[<c00089ec>] (start_kernel+0x270/0x2c8) from [<50008034>] (0x50008034)
这是我写USB鼠标驱动是出现的错误信息,BUG后面写的是出现错误的原因,然后后面的一大坨恐怖的东西原来是内核的堆栈信息,仔细看一下就会知道函数调用顺序了,
unwind_backtrace -> __kmalloc -> ohci_urb_enqueue -> usb_hcd_submit_urb -> usb_hcd_giveback_urb -> finish_urb ... 等等。
终于找到了错误原因了,原来是在鼠标中断处理函数sb_mouse_irq中调用这个函数的参数应该是这样的usb_submit_urb (urb, GFP_ATOMIC);
而不能用韦东山视频中的usb_submit_urb(uk_urb, GFP_KERNEL);
关于这两个宏的解释只找到了英文版的:
GFP_ATOMIC means roughly "make the allocation operation atomic(原子操作)". This
means that the kernel will try to find the memory using a pile of free
memory set aside for urgent allocation. If that pile doesn't have
enough free pages, the operation will fail. This flag is useful for
allocation within interrupt handlers.
GFP_KERNEL will try a little harder to find memory. There's a
possibility that the call to kmalloc() will sleep while the kernel is
trying to find memory (thus making it unsuitable for interrupt
handlers). It's much more rare for an allocation with GFP_KERNEL to
fail than with GFP_ATOMIC.
In all cases, kmalloc() should only be used allocating small amounts of
memory (a few kb). vmalloc() is better for larger amounts.
Also note that in lab 1 and lab 2, it would have been arguably better to
use GFP_KERNEL instead of GFP_ATOMIC. GFP_ATOMIC should be saved for
those instances in which a sleep would be totally unacceptable.
This is a fuzzy issue though...there's no absolute right or wrong
answer.
这也解释了为什么会出现这个错误提示 BUG: sleeping function called from invalid context at mm/slub.c:795
in_atomic(): 1, irqs_disabled(): 128, pid: 0, name: swapper
[<c0038d70>] (unwind_backtrace+0x0/0xe4) from [<c00a0400>] (__kmalloc+0x6c/0xf4)
[<c00a0400>] (__kmalloc+0x6c/0xf4) from [<c01fac00>] (ohci_urb_enqueue+0x218/0x68c)
[<c01fac00>] (ohci_urb_enqueue+0x218/0x68c) from [<c01eed00>] (usb_hcd_submit_urb+0x7ac/0x8c4)
[<c01eed00>] (usb_hcd_submit_urb+0x7ac/0x8c4) from [<c01edc30>] (usb_hcd_giveback_urb+0x70/0xb8)
[<c01edc30>] (usb_hcd_giveback_urb+0x70/0xb8) from [<c01fa72c>] (finish_urb+0x7c/0xb8)
[<c01fa72c>] (finish_urb+0x7c/0xb8) from [<c01fbddc>] (finish_unlinks+0x168/0x2b8)
[<c01fbddc>] (finish_unlinks+0x168/0x2b8) from [<c01fe288>] (ohci_irq+0x438/0x4e4)
[<c01fe288>] (ohci_irq+0x438/0x4e4) from [<c01ed72c>] (usb_hcd_irq+0x38/0x88)
[<c01ed72c>] (usb_hcd_irq+0x38/0x88) from [<c0076068>] (handle_IRQ_event+0x24/0xe0)
[<c0076068>] (handle_IRQ_event+0x24/0xe0) from [<c00779a0>] (handle_level_irq+0xbc/0x13c)
[<c00779a0>] (handle_level_irq+0xbc/0x13c) from [<c0029070>] (asm_do_IRQ+0x70/0x94)
[<c0029070>] (asm_do_IRQ+0x70/0x94) from [<c0033248>] (__irq_svc+0x48/0xa0)
Exception stack(0xc0395f78 to 0xc0395fc0)
5f60: 00000000 00000000
5f80: c0395fc0 00000000 c0394000 c039925c c03ba3a4 c05f2900 500212f4 410fb766
5fa0: 5002128c 00000000 cfb96044 c0395fc0 c00348c0 c00346dc 60000013 ffffffff
[<c0033248>] (__irq_svc+0x48/0xa0) from [<c00346dc>] (default_idle+0x14/0x18)
[<c00346dc>] (default_idle+0x14/0x18) from [<c00348c0>] (cpu_idle+0x40/0x8c)
[<c00348c0>] (cpu_idle+0x40/0x8c) from [<c00089ec>] (start_kernel+0x270/0x2c8)
[<c00089ec>] (start_kernel+0x270/0x2c8) from [<50008034>] (0x50008034)
这是我写USB鼠标驱动是出现的错误信息,BUG后面写的是出现错误的原因,然后后面的一大坨恐怖的东西原来是内核的堆栈信息,仔细看一下就会知道函数调用顺序了,
unwind_backtrace -> __kmalloc -> ohci_urb_enqueue -> usb_hcd_submit_urb -> usb_hcd_giveback_urb -> finish_urb ... 等等。
终于找到了错误原因了,原来是在鼠标中断处理函数sb_mouse_irq中调用这个函数的参数应该是这样的usb_submit_urb (urb, GFP_ATOMIC);
而不能用韦东山视频中的usb_submit_urb(uk_urb, GFP_KERNEL);
关于这两个宏的解释只找到了英文版的:
GFP_ATOMIC means roughly "make the allocation operation atomic(原子操作)". This
means that the kernel will try to find the memory using a pile of free
memory set aside for urgent allocation. If that pile doesn't have
enough free pages, the operation will fail. This flag is useful for
allocation within interrupt handlers.
GFP_KERNEL will try a little harder to find memory. There's a
possibility that the call to kmalloc() will sleep while the kernel is
trying to find memory (thus making it unsuitable for interrupt
handlers). It's much more rare for an allocation with GFP_KERNEL to
fail than with GFP_ATOMIC.
In all cases, kmalloc() should only be used allocating small amounts of
memory (a few kb). vmalloc() is better for larger amounts.
Also note that in lab 1 and lab 2, it would have been arguably better to
use GFP_KERNEL instead of GFP_ATOMIC. GFP_ATOMIC should be saved for
those instances in which a sleep would be totally unacceptable.
This is a fuzzy issue though...there's no absolute right or wrong
answer.
这也解释了为什么会出现这个错误提示 BUG: sleeping function called from invalid context at mm/slub.c:795
相关文章推荐
- ORA-12154: TNS: 无法解析指定的连接标识符的错误信息
- 解析xml文件时,错误信息org.xml.sax.SAXParseException:Parser has reached the entity expansion limit "64,000" set by the Application.的解决办法
- 学习笔记 --- LINUX应用调试之修改内核输出应用程序的段错误信息
- Spring @Value("$XXX")注入值失败,错误信息提示:Could not resolve placeholder占位符不能被解析
- okhttp上传返回的加密信息解析错误
- 应用调试之配置内核输出应用程序的段错误信息
- 20150430 调试分析之 根据内核报错信息栈信息分析错误
- Excel常见错误信息解析
- 常见oj错误提示信息解析
- Blue Screen Of Death ( BSOD ) 错误信息解析解释
- 错误信息:"OraOLEDB.Oracle" 返回了消息 "ORA-12154: TNS: 无法解析指定的连接标识符
- 根据内核打印的段错误信息分析驱动程序——根据出错PC来分析
- ThinkPHP第八天(U函数放置在外部JS不会被解析,错误界面定制,错误信息变量)
- Blue Screen Of Death ( BSOD ) 错误信息解析解释
- svn 错误信息:这是在主机名解析时通常出现的暂时错误,它意味着本地服务器没有从权威服务器上收到响应。
- 系统内核管理模块的实现2--解析内存状态信息
- Android逆向之旅---应用的"反调试"方案解析(附加修改IDA调试端口和修改内核信息)
- Android逆向之旅---应用的"反调试"方案解析(附加修改IDA调试端口和修改内核信息)
- 使用gdb调试内核错误信息
- 前端错误信息收集(errorEruda)解析