内核bug中的"cut here "是什么意思呢？
yy Hong
我最近做一个存储产品。在格式化盘为ext3,然后往里写文件，会出现crash.
提示类似如下。我想知道其中的cut here是什么意思呢？我找到出错是在BUG_ON函数。但是我该如何进一步定位呢？
请大家给些提示啊，谢谢。
Nov 19 09:48:17 localhost kernel: ------------[ cut here ]------------
Nov 19 09:48:17 localhost kernel: kernel BUG at mm/slab.c:3057!
Nov 19 09:48:17 localhost kernel: invalid opcode: 0000 [#1]
Nov 19 09:48:17 localhost kernel: last sysfs file:
/sys/module/zd1211b/refcnt
Nov 19 09:48:17 localhost kernel: Modules linked in: zd1211b(+) w83627ehf
hwmon_vid hwmon ipv6 dm_mirror dm_region_hash dm_log dm_mod ppdev parport_pc
parport e1000e pcspkr i2c_i801 sg snd_hda_codec_intelhdmi
snd_hda_codec_realtek
snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm
snd_timer
snd soundcore snd_page_alloc ext3 jbd mbcache sd_mod crc_t10dif pata_acpi
ata_generic ata_piix ehci_hcd i915 drm_kms_helper drm i2c_algo_bit i2c_core
video output [last unloaded: zd1211b]
Nov 19 09:48:17 localhost kernel:
Nov 19 09:48:17 localhost kernel: Pid: 6680, comm: modprobe Not tainted
2.6.36
#9 Cantiga/OEM
Nov 19 09:48:17 localhost kernel: EIP: 0060:[<c04e0aca>] EFLAGS: 00010082
CPU:
0
Nov 19 09:48:17 localhost kernel: EIP is at cache_alloc_refill+0x2ea/0x4b0
Nov 19 09:48:17 localhost kernel: EAX: 00000004 EBX: f5483de0 ECX: f74026d0
EDX: ffffffff
Nov 19 09:48:17 localhost kernel: ESI: 00000000 EDI: 000080d0 EBP: f7400cc0
ESP: f51b7d08
Nov 19 09:48:17 localhost kernel: DS: 007b ES: 007b FS: 0000 GS: 00e0 SS:
0068
Nov 19 09:48:17 localhost kernel: Process modprobe (pid: 6680, ti=f51b6000
task=f5ce7550 task.ti=f51b6000)
Nov 19 09:48:17 localhost kernel: Stack:
Nov 19 09:48:17 localhost kernel: c0aaf7b0 00000013 f7400cc0 f7402c00
f74026c0
f74026c8 f74026d0 00000010
Nov 19 09:48:17 localhost kernel: <0> 00000000 000000d0 00000000 000000d0
0000dd37 00000000 000080d0 f7400cc0
Nov 19 09:48:17 localhost kernel: <0> c04e0db3 00000007 00000000 f5dd1744
00000202 000080d0 c070456d c053c8f9
Nov 19 09:48:17 localhost kernel: Call Trace:
Nov 19 09:48:17 localhost kernel: [<c04e0db3>] ? __kmalloc+0x123/0x160
Nov 19 09:48:17 localhost kernel: [<c070456d>] ? alloc_netdev_mq+0x3d/0x1b0
Nov 19 09:48:17 localhost kernel: [<c053c8f9>] ? sysfs_find_dirent+0x29/0x40
Nov 19 09:48:17 localhost kernel: [<c070456d>] ? alloc_netdev_mq+0x3d/0x1b0
Nov 19 09:48:17 localhost kernel: [<c0717230>] ? ether_setup+0x0/0x60
Nov 19 09:48:17 localhost kernel: [<c0717225>] ? alloc_etherdev_mq+0x15/0x20
Nov 19 09:48:17 localhost kernel: [<f9aa3a63>] ? zd1211_probe+0x73/0x2e0
[zd1211b]
Nov 19 09:48:17 localhost kernel: [<c069e3dd>] ?
usb_probe_interface+0xed/0x2b0
Nov 19 09:48:17 localhost kernel: [<c064af37>] ?
driver_probe_device+0x117/0x2c0
Nov 19 09:48:17 localhost kernel: [<c069d199>] ? usb_match_id+0x39/0x60
Nov 19 09:48:17 localhost kernel: [<c069d217>] ? usb_device_match+0x57/0xb0
Nov 19 09:48:17 localhost kernel: [<c064b159>] ? __driver_attach+0x79/0x80
Nov 19 09:48:17 localhost kernel: [<c064b0e0>] ? __driver_attach+0x0/0x80
Nov 19 09:48:17 localhost kernel: [<c064a2c2>] ? bus_for_each_dev+0x52/0x80
Nov 19 09:48:17 localhost kernel: [<c064ac76>] ? driver_attach+0x16/0x20
Nov 19 09:48:17 localhost kernel: [<c064b0e0>] ? __driver_attach+0x0/0x80
Nov 19 09:48:17 localhost kernel: [<c064a667>] ? bus_add_driver+0x1a7/0x2f0
Nov 19 09:48:17 localhost kernel: [<c064b3e3>] ? driver_register+0x63/0x120
Nov 19 09:48:17 localhost kernel: [<c069e10a>] ?
usb_register_driver+0x7a/0x130
Nov 19 09:48:17 localhost kernel: [<c079abf2>] ? printk+0x17/0x1d
Nov 19 09:48:17 localhost kernel: [<c0403033>] ? do_one_initcall+0x33/0x170
Nov 19 09:48:17 localhost kernel: [<f92d6000>] ? init_module+0x0/0x8a
[zd1211b]
Nov 19 09:48:17 localhost kernel: [<c046dafb>] ?
sys_init_module+0x13b/0x10f0
Nov 19 09:48:17 localhost kernel: [<c040921f>] ? sysenter_do_call+0x12/0x28
Nov 19 09:48:17 localhost kernel: Code: 03 69 c9 ec 02 00 00 01 91 1c da 97
c0
01 15 10 ba ae c0 89 c1 31 db 39 da 7e 18 0f ba 29 07 83 c3 01 83 c1 20 eb
f0
0f 0b eb fe <0f> 0b 8d 74 26 00 eb fa e8 39 4e fe ff 85 c0 89 c7 0f 84 c8 00
Nov 19 09:48:17 localhost kernel: EIP: [<c04e0aca>]
cache_alloc_refill+0x2ea/0x4b0 SS:ESP 0068:f51b7d08
Nov 19 09:48:17 localhost kernel: ---[ end trace a2ed639020037e50 ]---
_______________________________________________
Linux 内核开发中文邮件列表
Linux-...@zh-kernel.org
http://zh-kernel.org/mailman/listinfo/linux-kernel
Linux 内核开发中文社区： http://zh-kernel.org
Yang Xu
]------------本身没有什么特殊含义，就跟调试程序时做的一个标记，方便从一大堆调试输出信息中快速找到它而已
BUG_ON 不过是打印调试信息的地方，不是出错的地方
你没有把panic信息贴全
最重要的信息是Call Trace:
看起来是zd1211_probe 下的alloc_etherdev_mq的参数不对
不知道你的内核版本，不知道你的产品是怎么组织的，又是usb又是以太网的，够热闹的
在 2011年5月6日 上午9:26，yy Hong <yaa...@gmail.com> 写道：
> 大家好：
> 我最近做一个存储产品。在格式化盘为ext3,然后往里写文件，会出现crash.
> 提示类似如下。我想知道其中的cut here是什么意思呢？我找到出错是在BUG_ON函数。但是我该如何进一步定位呢？
> 请大家给些提示啊，谢谢。
Yang Xu
在 2011年5月6日 上午10:58，Yang Xu <kernel....@gmail.com> 写道：
> 当我之前的没说，因为我不熟悉文件系统，不知道为什么会牵扯出zd1211这个模块的东西，看起来是跟你的应用不相关的东西。
> 建议您在定位到的BUG_ON宏附件使用dump_stack(); 打印当前调用栈，查找问题
Yang Xu
建议您在定位到的BUG_ON宏附件使用dump_stack(); 打印当前调用栈，查找问题
yy Hong
> 当我之前的没说，因为我不熟悉文件系统，不知道为什么会牵扯出zd1211这个模块的东西，看起来是跟你的应用不相关的东西。
> 建议您在定位到的BUG_ON宏附件使用dump_stack(); 打印当前调用栈，查找问题
>
Yang:
> sorry,上午只是想了解cut here的意义举的例子。
>
下边绿色是我的oops现场：我保证所有oops信息都贴出来了。看起来象调用了空指针。可是我objdump -S -d 反汇编mm/slab.c
看不到汇编对应的C代码。不知道是不是没有编译调试信息进去：（根据NIP应该是在cache_alloc_refill函数里出现的oops，根据LR则cache_alloc_refill是被kmem_cache_alloc调用，可是我怎么能定位到具体的行呢。一开始我以为从kernel
BUG at mm/slab.c:3057 就可以定位Bug发生的行，但是不对，是吗？thanks in advanced.
------------[ cut here
]------------
kernel BUG at
mm/slab.c:3057!
Oops: Exception in kernel mode, sig: 5
[#1]
MPC837x
RDB/WLAN
last sysfs file:
/sys/devices/e0000000.immr/e001a000.sata/host2/target2:0:0/2:0e
Modules linked
in:
NIP: c007a810 LR: c007ae80 CTR:
00000038
REGS: d4535ad0 TRAP: 0700 Not tainted
(2.6.36-svn384)
MSR: 00021032 <ME,CE,IR,DR> CR: 22244044 XER:
00000000
TASK = df0a1430[919] 'test' THREAD:
d4534000
GPR00: 0000003b d4535b80 df0a1430 00000005 df00ac70 d6bf101c d6bf1000
00000004
GPR08: ff2bffff 00000001 0000003b df00ac60 00000037 10018b54 00000050
c0430000
GPR16: c043f994 c0440000 c043f998 c0440000 c042d9cc c042e26c 00000050
00000000
GPR24: 00200200 00100100 c09986c0 00000000 df00ac68 df00ac60 df003260
df00c400
NIP [c007a810]
cache_alloc_refill+0x114/0x5a8
LR [c007ae80] +0xc0/0xc8
Call
Trace:
[d4535b80] [ffffffff] 0xffffffff
(unreliable)
[d4535be0] [c007ae80]
kmem_cache_alloc+0xc0/0xc8
[d4535c00] [c00a45a0]
alloc_buffer_head+0x20/0x60
[d4535c10] [c00a4ee4]
alloc_page_buffers+0x84/0xec
[d4535c40] [c00a4f6c]
create_empty_buffers+0x20/0x110
[d4535c50] [c00a6558]
block_prepare_write+0x42c/0x478
[d4535cc0] [c00dabc8]
ext3_write_begin+0xc4/0x288
[d4535d30] [c0056de0]
generic_file_buffered_write+0x198/0x250
[d4535db0] [c0058428]
__generic_file_aio_write+0x268/0x464
[d4535e20] [c0058694]
generic_file_aio_write+0x70/0xec
[d4535e50] [c007f0f0]
do_sync_write+0xac/0x120
[d4535ef0] [c007fb44]
vfs_write+0xb4/0x16c
[d4535f10] [c0080074]
sys_write+0x4c/0x90
[d4535f40] [c000f3f4]
ret_from_syscall+0x0/0x38
--- Exception: c01 at
0x4804c034
LR =
0x48066f04
Instruction
dump:
2f0c0000 409900f0 389d0010 3b9d0008 80dd0000 7f9d3000 419e0138
81460010
801e001c 7d205010 39200000 7d294914 <0f090000> 7f8a0040 409c007c
2f8c0000
---[ end trace 1e8c01ad65e730e3
]---
Trace/breakpoint trap
Yang Xu
等内核函数的可靠性比自己写的代码可靠性高。
不知道您的存储设备是什么，存储设备的驱动是哪来的。
我猜测是使用mpc837x的sata接口接的市场上的主流硬盘。这样的话，所有驱动都来自内核而不是自己写的，以我的水平，只会升级内核，然后祈祷.
在 2011年5月6日 下午2:00，yy Hong <yaa...@gmail.com> 写道：
>
>
> 在 2011年5月6日 上午10:58，Yang Xu <kernel....@gmail.com>写道：
>>
>> 当我之前的没说，因为我不熟悉文件系统，不知道为什么会牵扯出zd1211这个模块的东西，看起来是跟你的应用不相关的东西。
>> 建议您在定位到的BUG_ON宏附件使用dump_stack(); 打印当前调用栈，查找问题
>
> Yang:
>>
>> sorry,上午只是想了解cut here的意义举的例子。
>
> 下边绿色是我的oops现场：我保证所有oops信息都贴出来了。看起来象调用了空指针。可是我objdump -S -d 反汇编mm/slab.c
> 看不到汇编对应的C代码。不知道是不是没有编译调试信息进去：（根据NIP应该是在cache_alloc_refill函数里出现的oops，根据LR则cache_alloc_refill是被kmem_cache_alloc调用，可是我怎么能定位到具体的行呢。一开始我以为从kernel
> BUG at mm/slab.c:3057 就可以定位Bug发生的行，但是不对，是吗？thanks in advanced.