Latest working kernel version: Earliest failing kernel version: Distribution:Scientific Linux 5.1 / Updated Kernel Hardware Environment: HP Proliant ML115 Software Environment: 2.6.19-92.el5 and 2.6.18-53 (default SL5.1 kernel) Problem Description: I installed a linux server based on SL 5.1 linux and run a backup using dump. The effect was the the kernel panic'ed in map_bio() with 2.6.18-53.1.4.el5. After I upgraded to 2.6.18-92 the system seem to hang. Always after some time, ie. when 17% of the dump is done. I do a dump level 0 (-b64) from a RAID 1 array mounted on /data to a file in root fs in /backup. It's called /dev/mapper/nvidia_bcacfdbgp1 The system is in normal user mode, but also in single user mode. Steps to reproduce: /sbin/dump -0u -b64 -f /backup/data.0 /data either in single or multiuser mode. Maybe it has something todo with the -b option? I've created a few backups before I introduced the -b64 option to improve the speed. -b64 seems to panic always. Right now I start over with -b16. EIP was pointing to map_bio(). Callstack which I could read of the console: add_to_page_cache __do_pache_cache_readahead dm_any_congested blockable_page_cache_readahead make_ahead_window page_cache_readahead do_generic_mapping __generic_file_io_read file_read_actor generic_file_read auto_remove_wake_function mutex_lock block_lseek vfs_read sys_read sys_call Let me know if you need more information... Thanks, Alf
You're using a kernel shipped by Suse...you must file this bug in their bugzilla (https://bugzilla.novell.com). (But if you can reproduce this bug in the mainline stable kernel that you can download and compile at kernel.org, we'd be interested in it)