----- Original Message ----- ^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^ Huh? The stack contents from ffff880028283b40 to ffff880028283b80 were used by dev_queue_xmit() prior to it calling whatever function is in frame #6. The contents are either stack variables and/or register-saves. Because the function parameters are passed in registers, it's not obvious what, or where, they are saved on the stack. It's possible that several functions may be called with the same register argument, and that it was not saved in the calling function. So with function parameters and local variables, you'll have to disassemble the function up to the point where it made the call to the next function, and figure out what's what on the stack. (Use dis -rl <return-address>") It's often helpful to use "bt -F" instead of "bt -f". If a stack variable can be expressed symbolically, it will be, and if a stack variable can be determined to be a slab cache object, the slab cache name in brackets will be shown. For example: crash> bt -f ... [cut] ... #4 [ffff81014d877ec0] sysfs_read_file at ffffffff8010bee9 ffff81014d877ec8: 0000000000001000 00000000078bb000 ffff81014d877ed8: ffffffff80323840 ffff81015ed59b80 ffff81014d877ee8: 0000000000001000 00000000078bb000 ffff81014d877ef8: ffff81014d877f50 0000000000001000 ffff81014d877f08: 0000000000000000 ffffffff8000bd48 ... crash> bt -F ... [cut[ ... #4 [ffff81014d877ec0] sysfs_read_file at ffffffff8010bee9 ffff81014d877ec8: 0000000000001000 00000000078bb000 ffff81014d877ed8: class_device_attr_cpuaffinity [filp] ffff81014d877ee8: 0000000000001000 00000000078bb000 ffff81014d877ef8: [sighand_cache] 0000000000001000 ffff81014d877f08: 0000000000000000 vfs_read+203 ... Dave