EXT2-fs error

EXT2-fs error

[Kiah Tang]

Hi all,
 
I have to say that I am a totally newbie in Linux kernel, yet I need to build a Linux kernel in very short period of time. 

I have an embedded MIPS box equipped with a 64MB of NAND flash and 64MB of DRAM. I am using a cross-compiler (buildroot) on the PC. 

I built Linux kernel (V2.4) as follows: 
- Created EXT2 ramdisk.gz as documented in Documentation/ramdisk.txt 
- The ramdisk contains the content of buildroot/build_mipsel/root/, which contains bin, etc, lib, linuxrc, sbin (sh.. etc), usr. I also created under /dev console null, tty*.... 
- Copied ramdisk.gz to /linux/arc/mips/ramdisk/ 
- Compiled the kernel 
- Donwloaded to the DRAM (0x800c0000) via PMON. 

Linux seems to boot up and the ramdisk seems to be mounted correctly. However modprobe failed. When I removed modprobe by undef CONFIG_KMOD, the system failed earlier at /sbin/sh step. 

Tracing down the codes, I noticed I got EXT2-fs error. 

Can anyone help? 

In addition, as a newbie, I would like to ask: 
- Is ramdisk necessary at all? 
- (How) Can I build a complete filesystem and kernel in a single piece and download on NAND flash? 

The printk messages is as follow: 

[snip] 
<6>Linux NET4.0 for Linux 2.4 
<6>Based upon Swansea University Computer Society NET3.039 
<4>sock_init: calling sk_init... 
<4>sock_init: calling skb_init... 
<4>sock_init: calling register_filesystem... 
<4>register_filesystem: calling find_filesystem... 
<4>find_filesystem: i(*p)->name=rootfs name=sockfs 
<4>find_filesystem: i(*p)->name=bdev name=sockfs 
<4>find_filesystem: p=801a4460 
<4>register_filesystem: p=801a4460 *p=00000000 
<4>sock_init: &sock_fs_type=801ab938 name=%S fs_flag=80177494 
<4>sock_init: calling sock_mnt... 
<4>find_filesystem: i(*p)->name=rootfs name=sockfs 
<4>find_filesystem: i(*p)->name=bdev name=sockfs 
<4>find_filesystem: i(*p)->name=sockfs name=sockfs 
<4>find_filesystem: p=801a4460 
<4>do_kern_mount: fstype="sockfs" type=801ab938 flags=0 name="sockfs" data=00000000 
<4>do_kern_mount: get_sb_nodev sb=802b5400 
<4>do_kern_mount: mnt=810b61a0 
<4>sock_init: calling rtnetlink_init... 
<4>Initializing RT netlink socket 
<4>__get_free_pages calling page_address... 
<4>do_basic_setup: calling start_context_thread... 
<4>__get_free_pages calling page_address... 
<4>__get_free_pages calling page_address... 
<4>add_to_runqueue: p=802b0000 
<4>do_basic_setup: calling do_initcalls... 
<4>__get_free_pages calling page_address... 
<4>add_to_runqueue: p=810fa000 
<4>Starting kswapd 
<4>__get_free_pages calling page_address... 
<4>add_to_runqueue: p=810f8000 
<4>register_filesystem: calling find_filesystem... 
<4>find_filesystem: i(*p)->name=rootfs name=tmpfs 
<4>find_filesystem: i(*p)->name=bdev name=tmpfs 
<4>find_filesystem: i(*p)->name=sockfs name=tmpfs 
<4>find_filesystem: p=801ab948 
<4>register_filesystem: p=801ab948 *p=00000000 
<4>find_filesystem: i(*p)->name=rootfs name=tmpfs 
<4>find_filesystem: i(*p)->name=bdev name=tmpfs 
<4>find_filesystem: i(*p)->name=sockfs name=tmpfs 
<4>find_filesystem: i(*p)->name=tmpfs name=tmpfs 
<4>find_filesystem: p=801ab948 
<4>do_kern_mount: fstype="tmpfs" type=801a4278 flags=0 name="tmpfs" data=00000000 
<4>do_kern_mount: get_sb_nodev sb=802b5800 
<4>do_kern_mount: mnt=810b61e0 
<4>__get_free_pages calling page_address... 
<4>add_to_runqueue: p=810f6000 
<4>__get_free_pages calling page_address... 
<4>add_to_runqueue: p=810f4000 
<4>add_to_runqueue: p=802b6000 
<4>register_filesystem: calling find_filesystem... 
<4>find_filesystem: i(*p)->name=rootfs name=pipefs 
<4>find_filesystem: i(*p)->name=bdev name=pipefs 
<4>find_filesystem: i(*p)->name=sockfs name=pipefs 
<4>find_filesystem: i(*p)->name=tmpfs name=pipefs 
<4>find_filesystem: p=801a4288 
<4>register_filesystem: p=801a4288 *p=00000000 
<4>find_filesystem: i(*p)->name=rootfs name=pipefs 
<4>find_filesystem: i(*p)->name=bdev name=pipefs 
<4>find_filesystem: i(*p)->name=sockfs name=pipefs 
<4>find_filesystem: i(*p)->name=tmpfs name=pipefs 
<4>find_filesystem: i(*p)->name=pipefs name=pipefs 
<4>find_filesystem: p=801a4288 
<4>do_kern_mount: fstype="pipefs" type=801a4748 flags=0 name="pipefs" data=00000000 
<4>do_kern_mount: get_sb_nodev sb=802b5c00 
<4>do_kern_mount: mnt=810b6220 
<4>register_filesystem: calling find_filesystem... 
<4>find_filesystem: i(*p)->name=rootfs name=ext2 
<4>find_filesystem: i(*p)->name=bdev name=ext2 
<4>find_filesystem: i(*p)->name=sockfs name=ext2 
<4>find_filesystem: i(*p)->name=tmpfs name=ext2 
<4>find_filesystem: i(*p)->name=pipefs name=ext2 
<4>find_filesystem: p=801a4758 
<4>register_filesystem: p=801a4758 *p=00000000 
<4>register_filesystem: calling find_filesystem... 
<4>find_filesystem: i(*p)->name=rootfs name=ramfs 
<4>find_filesystem: i(*p)->name=bdev name=ramfs 
<4>find_filesystem: i(*p)->name=sockfs name=ramfs 
<4>find_filesystem: i(*p)->name=tmpfs name=ramfs 
<4>find_filesystem: i(*p)->name=pipefs name=ramfs 
<4>find_filesystem: i(*p)->name=ext2 name=ramfs 
<4>find_filesystem: p=801a4c90 
<4>register_filesystem: p=801a4c90 *p=00000000 
<4>__get_free_pages calling page_address... 
<4>__get_free_pages calling page_address... 
<4>__get_free_pages calling page_address... 
<4>add_to_runqueue: p=810fa000 
<6>Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabledþ 
<6>ttyS00 at 0xbe800000 (irq = 2) is a ST16654 
<6>ttyS01 at 0xbe880000 (irq = 0) is a ST16654 
<6>ttyS02 at 0xbe900000 (irq = 0) is a ST16654 
<6>ttyS03 at 0xbe980000 (irq = 0) is a ST16654 
<6>ttyS04 at 0xbea00000 (irq = 0) is a ST16654 
<6>ttyS05 at 0xbea80000 (irq = 0) is a ST16654 
<6>ttyS06 at 0xbeb00000 (irq = 0) is a ST16654 
<6>ttyS07 at 0xbeb80000 (irq = 0) is a ST16654 
<4>RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize 
<4>add_to_runqueue: p=802b0000 
<4>add_to_runqueue: p=802b6000 
<4>add_to_runqueue: p=802b0000 
<4>add_to_runqueue: p=802b6000 
<4>init: calling prepare_namespace.. 
<4>prepare_namespace: sys_mkdir dev 
<4>__get_free_pages calling page_address... 
<4>sys_mkdir: tmp=/dev mode=1c0 
<4>path_lookup: calling path_init with path=/dev flags=10 nd=802b7f50 
<4>path_init: name=/dev flags=10 nd=802b7f50 
<4>path_lookup: calling path_walk.. 
<4>path_lookup: error=0 
<4>sys_mkdir: path_lookup error=0 
<4>sys_mkdir: lookup_create dentry=802bd320 
<4>sys_mkdir: vfs_mkdir error=0 
<4>sys_mkdir: tmp=810f1000 error=0 
<4>prepare_namespace: sys_mkdir root 
<4>sys_mkdir: tmp=/root mode=1c0 
<4>path_lookup: calling path_init with path=/root flags=10 nd=802b7f50 
<4>path_init: name=/root flags=10 nd=802b7f50 
<4>path_lookup: calling path_walk.. 
<4>path_lookup: error=0 
<4>sys_mkdir: path_lookup error=0 
<4>sys_mkdir: lookup_create dentry=802bd3a0 
<4>sys_mkdir: vfs_mkdir error=0 
<4>sys_mkdir: tmp=810f1000 error=0 
<4>prepare_namespace: sys_mknod dev/console 
<4>sys_mknod: filename=/dev/console mode=2180 dev=501 
<4>path_lookup: calling path_init with path=/dev/console flags=10 nd=802b7f48 
<4>path_init: name=/dev/console flags=10 nd=802b7f48 
<4>path_lookup: calling path_walk.. 
<4>path_lookup: error=0 
<4>sys_mknod: path_lookup error=0 
<4>sys_mknod: lookup_create dentry=802bd420 
<4>__get_free_pages calling page_address... 
<4>__get_free_pages calling page_address... 
<4>sys_mknod: vfs_mknod error=0 
<4>sys_mknod: tmp=/dev/console error=0 
<4>prepare_namespace: ROOT_DEV=100 
<4>create_dev: *name=/dev/root dev=100 *devfs_name= 
<4>path_lookup: calling path_init with path=/dev/root flags=10 nd=802b7ef8 
<4>path_init: name=/dev/root flags=10 nd=802b7ef8 
<4>path_lookup: calling path_walk.. 
<4>path_lookup: error=0 
<4>sys_mknod: filename=/dev/root mode=6180 dev=100 
<4>path_lookup: calling path_init with path=/dev/root flags=10 nd=802b7ee8 
<4>path_init: name=/dev/root flags=10 nd=802b7ee8 
<4>path_lookup: calling path_walk.. 
<4>path_lookup: error=0 
<4>sys_mknod: path_lookup error=0 
<4>sys_mknod: lookup_create dentry=802bd4a0 
<4>sys_mknod: vfs_mknod error=0 
<4>sys_mknod: tmp=/dev/root error=0 
<4>create_dev: *name=/dev/ram dev=100 *devfs_name= 
<4>path_lookup: calling path_init with path=/dev/ram flags=10 nd=802b7ee0 
<4>path_init: name=/dev/ram flags=10 nd=802b7ee0 
<4>path_lookup: calling path_walk.. 
<4>path_lookup: error=0 
<4>sys_mknod: filename=/dev/ram mode=6180 dev=100 
<4>path_lookup: calling path_init with path=/dev/ram flags=10 nd=802b7ed0 
<4>path_init: name=/dev/ram flags=10 nd=802b7ed0 
<4>path_lookup: calling path_walk.. 
<4>path_lookup: error=0 
<4>sys_mknod: path_lookup error=0 
<4>sys_mknod: lookup_create dentry=802bd520 
<4>sys_mknod: vfs_mknod error=0 
<4>sys_mknod: tmp=/dev/ram error=0 
<4>create_dev: *name=/dev/initrd dev=1fa *devfs_name= 
<4>path_lookup: calling path_init with path=/dev/initrd flags=10 nd=802b7ee0 
<4>path_init: name=/dev/initrd flags=10 nd=802b7ee0 
<4>path_lookup: calling path_walk.. 
<4>path_lookup: error=0 
<4>sys_mknod: filename=/dev/initrd mode=6180 dev=1fa 
<4>path_lookup: calling path_init with path=/dev/initrd flags=10 nd=802b7ed0 
<4>path_init: name=/dev/initrd flags=10 nd=802b7ed0 
<4>path_lookup: calling path_walk.. 
<4>path_lookup: error=0 
<4>sys_mknod: path_lookup error=0 
<4>sys_mknod: lookup_create dentry=802bd5a0 
<4>sys_mknod: vfs_mknod error=0 
<4>sys_mknod: tmp=/dev/initrd error=0 
<4>open_namei: pathname=/dev/ram 
<4>path_lookup: calling path_init with path=/dev/ram flags=1 nd=802b7e28 
<4>path_init: name=/dev/ram flags=1 nd=802b7e28 
<4>path_lookup: calling path_walk.. 
<4>path_lookup: error=0 
<4>open_namei: inode=810f0420 
<4>open_namei: error=0 permission=80102fe0 
<4>open_namei: get_lease error=0 
<4>open_namei: inode=810f0420 
<4>open_namei: return with 0 
<4>dentry_open: calling get_empty_filp... 
<4>__get_free_pages calling page_address... 
<4>dentry_open: get_empty_filp f=810ee0a0 
<4>dentry_open: calling get_write_access... 
<4>dentry_open: get_write_access error=0 
<4>dentry_open: calling fops_get... 
<4>dentry_open: f->f_op=801a4498 
<4>dentry_open: inode->i_sb->s_files=810ee0a0 
<4>dentry_open: calling f->f_op->open... 
<4>__get_free_pages calling page_address... 
<4>dentry_open: f->f_op->open error=0 
<4>dentry_open: return f=810ee0a0 
<4>open_namei: pathname=/dev/initrd 
<4>path_lookup: calling path_init with path=/dev/initrd flags=1 nd=802b7e28 
<4>path_init: name=/dev/initrd flags=1 nd=802b7e28 
<4>path_lookup: calling path_walk.. 
<4>path_lookup: error=0 
<4>open_namei: inode=810f0600 
<4>open_namei: error=0 permission=80102fe0 
<4>open_namei: get_lease error=0 
<4>open_namei: return with 0 
<4>dentry_open: calling get_empty_filp... 
<4>dentry_open: get_empty_filp f=810ee120 
<4>dentry_open: calling fops_get... 
<4>dentry_open: f->f_op=801a4498 
<4>dentry_open: inode->i_sb->s_files=810ee120 
<4>dentry_open: calling f->f_op->open... 
<4>dentry_open: f->f_op->open error=0 
<4>dentry_open: return f=810ee120 
<5>RAMDISK: Compressed image found at block 0 
<4>__get_free_pages calling page_address... 
<4>__get_free_pages calling page_address... 
<4>__get_free_pages calling page_address... 
<4>__get_free_pages calling page_address... 
<3>crc error<6>Freeing initrd memory: 388k freed 
<4>path_lookup: calling path_init with path=/dev/ram flags=10 nd=802b7ef8 
<4>path_init: name=/dev/ram flags=10 nd=802b7ef8 
<4>path_lookup: calling path_walk.. 
<4>path_lookup: error=0 
<4>mount_root: root_device_name= 
<4>create_dev: *name=/dev/root dev=100 *devfs_name= 
<4>path_lookup: calling path_init with path=/dev/root flags=10 nd=802b7ed8 
<4>path_init: name=/dev/root flags=10 nd=802b7ed8 
<4>path_lookup: calling path_walk.. 
<4>path_lookup: error=0 
<4>sys_mknod: filename=/dev/root mode=6180 dev=100 
<4>path_lookup: calling path_init with path=/dev/root flags=10 nd=802b7ec8 
<4>path_init: name=/dev/root flags=10 nd=802b7ec8 
<4>path_lookup: calling path_walk.. 
<4>path_lookup: error=0 
<4>sys_mknod: path_lookup error=0 
<4>sys_mknod: lookup_create dentry=802bd4a0 
<4>sys_mknod: vfs_mknod error=0 
<4>sys_mknod: tmp=/dev/root error=0 
<4>mount_block_root: fs_names=810f1000: "/dev/root" 
<4>get_fs_names: s=00008001 page=810f1000 "/dev/root" 
<4>get_fs_names: root_fs_names=00000000 page=810f1000 "/dev/root" 
<4>get_fs_names: len=80 
<4>get_fs_names: p= 
<4>get_fs_names: p= 
<4>nodev bdev 
<4>nodev sockfs 
<4>nodev tmpfs 
<4>nodev pipefs 
<4> ext2 
<4>nodev ramfs 
<4> 
<4>get_fs_names: p= 
<4>nodev sockfs 
<4>nodev tmpfs 
<4>nodev pipefs 
<4> ext2 
<4>nodev ramfs 
<4> 
<4>get_fs_names: p= 
<4>nodev tmpfs 
<4>nodev pipefs 
<4> ext2 
<4>nodev ramfs 
<4> 
<4>get_fs_names: p= 
<4>nodev pipefs 
<4> ext2 
<4>nodev ramfs 
<4> 
<4>get_fs_names: p= 
<4> ext2 
<4>nodev ramfs 
<4> 
<4>get_fs_names: p= 
<4>nodev ramfs 
<4> 
<4>get_fs_names: p= 
<4> 
<4>mount_block_root: get_fs_names done 
<4>sys_mount: dev_name=/dev/root dir_name=/root type=ext2 flags=8001 data= 
<4>__get_free_pages calling page_address... 
<4>sys_mount: type_page=ext2 retval=0 
<4>__get_free_pages calling page_address... 
<4>sys_mount: dir_page=/root 
<4>__get_free_pages calling page_address... 
<4>sys_mount: dev_page=/dev/root retval=0 
<4>sys_mount: data_page= retval=0 
<4>do_mount: flags=8001 
<4>path_lookup: calling path_init with path=/root flags=9 nd=802b7eb0 
<4>path_init: name=/root flags=9 nd=802b7eb0 
<4>path_lookup: calling path_walk.. 
<4>path_lookup: error=0 
<4>do_mount: &nd=802b7eb0 retval=0 
<4>find_filesystem: i(*p)->name=rootfs name=ext2 
<4>find_filesystem: i(*p)->name=bdev name=ext2 
<4>find_filesystem: i(*p)->name=sockfs name=ext2 
<4>find_filesystem: i(*p)->name=tmpfs name=ext2 
<4>find_filesystem: i(*p)->name=pipefs name=ext2 
<4>find_filesystem: i(*p)->name=ext2 name=ext2 
<4>find_filesystem: p=801a4758 
<4>do_kern_mount: fstype="ext2" type=801a4c80 flags=8001 name="/dev/root" data=00000000 
<4>get_sb_bdev: fs_type=801a4c80 flags=8001 dev_name="/dev/root" data=00000000 
<4>path_lookup: calling path_init with path=/dev/root flags=9 nd=802b7df0 
<4>path_init: name=/dev/root flags=9 nd=802b7df0 
<4>path_lookup: calling path_walk.. 
<4>path_lookup: error=0 
<4>get_sb_bdev: path_lookup error=0 
<4>get_sb_bdev: bdev->bd_dev= 
<4>get_sb_bdev: blkdev_get error=0 
<4>__get_free_pages calling page_address... 
<4>get_sb_bdev: s=-2129713152 
<4>do_kern_mount: get_sb_bdev sb=810f2800 
<4>do_kern_mount: mnt=810b6260 
<4>do_add_mount: mnt=810b6260 err=-2129960352 
<4>do_add_mount: 
<4>do_mount: do_add_mount retval=0 
<4>do_mount: exiting with retval=0 
<4>sys_mount: do_mount retval=0 
<4>sys_mount: retval=0 
<4>mount_block_root: err=0 *p= flags=8001 root_mount_data=0 
<4>path_lookup: calling path_init with path=/root flags=b nd=802b7f00 
<4>path_init: name=/root flags=b nd=802b7f00 
<4>path_lookup: calling path_walk.. 
<4>path_lookup: error=0 
<4>mount_block_root: ROOT_DEV=100 
<4>VFS: Mounted root (ext2 filesystem) readonly. 
<4>path_lookup: calling path_init with path=/dev flags=9 nd=802b7f58 
<4>path_init: name=/dev flags=9 nd=802b7f58 
<4>path_lookup: calling path_walk.. 
<4>path_lookup: error=0 
<4>sys_mount: dev_name=. dir_name=/ type= flags=2000 data= 
<4>sys_mount: type_page= retval=0 
<4>sys_mount: dir_page=/ 
<4>__get_free_pages calling page_address... 
<4>sys_mount: dev_page=. retval=0 
<4>sys_mount: data_page= retval=0 
<4>do_mount: flags=2000 
<4>path_lookup: calling path_init with path=/ flags=9 nd=802b7f08 
<4>path_init: name=/ flags=9 nd=802b7f08 
<4>path_lookup: calling path_walk.. 
<4>path_lookup: error=0 
<4>do_mount: &nd=802b7f08 retval=0 
<4>path_lookup: calling path_init with path=. flags=9 nd=802b7ea0 
<4>path_init: name=. flags=9 nd=802b7ea0 
<4>path_lookup: calling path_walk.. 
<4>path_lookup: error=0 
<4>do_mount: do_move_mount retval=0 
<4>do_mount: exiting with retval=0 
<4>sys_mount: do_mount retval=0 
<4>sys_mount: retval=0 
<4>path_lookup: calling path_init with path=. flags=2b nd=802b7f60 
<4>path_init: name=. flags=2b nd=802b7f60 
<4>path_lookup: calling path_walk.. 
<4>path_lookup: error=0 
<4>init: calling free_initmem.. 
<6>Freeing unused kernel memory: 80k freed 
<4>init: calling unlock_kernel.. 
<4>__get_free_pages calling page_address... 
<4>init: calling open dev console.. 
<4>open_namei: pathname=/dev/console 
<4>path_lookup: calling path_init with path=/dev/console flags=1 nd=802b7ea8 
<4>path_init: name=/dev/console flags=1 nd=802b7ea8 
<4>path_lookup: calling path_walk.. 
<2>EXT2-fs error (device ramdisk(1,0)): ext2_check_page: bad entry in directory #69: rec_len is smaller than minimal - offset=0, inode=0, rec_len=0, name_len=0 
<4>path_lookup: error=0 
<4>open_namei: inode=00000000 
<4>open_namei: exit error=-2 
<4>Warning: unable to open an initial console. 
<4>init: open dev console done 
<4>init: calling run_init_process sbin init.. 
<4>path_lookup: calling path_init with path=/sbin/init flags=9 nd=802b7d40 
<4>path_init: name=/sbin/init flags=9 nd=802b7d40 
<4>path_lookup: calling path_walk.. 
<2>EXT2-fs error (device ramdisk(1,0)): ext2_check_page: bad entry in directory #56: rec_len is smaller than minimal - offset=0, inode=0, rec_len=0, name_len=0 
<4>path_lookup: error=-2 
<4>init: calling run_init_process etc init.. 
<4>path_lookup: calling path_init with path=/etc/init flags=9 nd=802b7d40 
<4>path_init: name=/etc/init flags=9 nd=802b7d40 
<4>path_lookup: calling path_walk.. 
<4>path_lookup: error=-2 
<4>init: calling run_init_process bin init.. 
<4>path_lookup: calling path_init with path=/bin/init flags=9 nd=802b7d40 
<4>path_init: name=/bin/init flags=9 nd=802b7d40 
<4>path_lookup: calling path_walk.. 
<4>__get_free_pages calling page_address... 
<4>path_lookup: error=-2 
<4>init: calling run_init_process bin sh.. 
<4>path_lookup: calling path_init with path=/bin/sh flags=9 nd=802b7d40 
<4>path_init: name=/bin/sh flags=9 nd=802b7d40 
<4>path_lookup: calling path_walk.. 
<4>path_lookup: error=0 
<4>dentry_open: calling get_empty_filp... 
<4>dentry_open: get_empty_filp f=810ee0a0 
<4>dentry_open: calling fops_get... 
<4>dentry_open: f->f_op=801a4b10 
<4>dentry_open: inode->i_sb->s_files=810ee0a0 
<4>dentry_open: calling f->f_op->open... 
<4>dentry_open: f->f_op->open error=0 
<4>dentry_open: return f=810ee0a0 
<4>__get_free_pages calling page_address... 
<4>__get_free_pages calling page_address... 
<4>add_to_runqueue: p=80190000 
<4>path_lookup: calling path_init with path=/sbin/modprobe flags=9 nd=80191cf0 
<4>path_init: name=/sbin/modprobe flags=9 nd=80191cf0 
<4>path_lookup: calling path_walk.. 
<4>path_lookup: error=-2 
<3>kmod: failed to exec /sbin/modprobe -s -k binfmt-464c, errno = 2 
<4>add_to_runqueue: p=802b6000 
<4>__get_free_pages calling page_address... 
<4>add_to_runqueue: p=80190000 
<4>path_lookup: calling path_init with path=/sbin/modprobe flags=9 nd=80191cf0 
<4>path_init: name=/sbin/modprobe flags=9 nd=80191cf0 
<4>path_lookup: calling path_walk.. 
<4>path_lookup: error=-2 
<3>kmod: failed to exec /sbin/modprobe -s -k binfmt-464c, errno = 2 
<4>add_to_runqueue: p=802b6000 
<0>Kernel panic: No init found. Try passing init= option to kernel. 
<4> 
[system rebooted to PMON...]

Re: EXT2-fs error

[Wolfgang Denk]

In message <20060806040329.51416.qmail@web27003.mail.ukl.yahoo.com> you wrote:

> I built Linux kernel (V2.4) as follows: 
> - Created EXT2 ramdisk.gz as documented in Documentation/ramdisk.txt 
> - The ramdisk contains the content of buildroot/build_mipsel/root/, which contains bin, etc, lib, linuxrc, sbin (sh.. etc), usr. I also created under /dev console null, tty*.... 
> - Copied ramdisk.gz to /linux/arc/mips/ramdisk/ 
...
> Tracing down the codes, I noticed I got EXT2-fs error. 

Your ramdisk is probably much bigger than the kernel's default of 4 MB.

Please see the FAQ at
http://www.denx.de/wiki/view/DULG/RamdiskGreaterThan4MBCausesProblems

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
My play was a complete success.  The audience was a failure.

Re: EXT2-fs error

[WCT Tang]

Hello Wolfgang,

Thanks for your reply.  I have checked that my total file size is only 
384KB, and the ramdisk I created is 4096KB, and my Kernel's ram size 
CONFIG_BLK_DEV_RAM_SIZE is set to 4096.

Here are the steps I used to create ramdisk:

dd if=/dev/zero of=/dev/ram bs=1k count=4096
mke2fs -vm0 /dev/ram 4096
mount /dev/ram ramdisk/
cd ramdisk/
cp -r /home/devel/root/* .
mkdir dev etc tmp var proc mnt home root
cd dev/
mknod console c 5 1
mknod ttyS0 c 4 64
mknod tty c 5 0
mknod ram0 b 1 0
mknod ram1 b 1 1
mknod mem c 1 1
mknod kmem c 1 2
mknod null c 1 3
mknod zero c 1 5
mknod fb0 c 29 0
ln -s fb0 fb
ln -s ram1 ram
ln -s ram0 ramdisk
ln -s ../proc/kcore kcore
ln -s ../proc/self/fd/0 stdin
ln -s ../proc/self/fd/1 stdout
ln -s ../proc/self/fd/2 stderr
cd ..
umount ramdisk
dd if=/dev/ram bs=1k count=4096 | gzip -vf > 
/home/devel/linux/arc/mips/ramdisk/ramdisk.gz


Any other suggestion?


p/s: I have got lots of junk mails sent from this mailing lists, 
probably triggered by my email. Could the administrator do something?


Wolfgang Denk wrote:
> In message <20060806040329.51416.qmail@web27003.mail.ukl.yahoo.com> you wrote:
>
>   
>> I built Linux kernel (V2.4) as follows: 
>> - Created EXT2 ramdisk.gz as documented in Documentation/ramdisk.txt 
>> - The ramdisk contains the content of buildroot/build_mipsel/root/, which contains bin, etc, lib, linuxrc, sbin (sh.. etc), usr. I also created under /dev console null, tty*.... 
>> - Copied ramdisk.gz to /linux/arc/mips/ramdisk/ 
>>     
> ...
>   
>> Tracing down the codes, I noticed I got EXT2-fs error. 
>>     
>
> Your ramdisk is probably much bigger than the kernel's default of 4 MB.
>
> Please see the FAQ at
> http://www.denx.de/wiki/view/DULG/RamdiskGreaterThan4MBCausesProblems
>
> Best regards,
>
> Wolfgang Denk
>
>   

EXT2-fs error

[khromy]

Linux vingeren.girl 2.4.3-pre7 #5 Mon Mar 26 23:33:59 EST 2001 i686 unknown

EXT2-fs error (device ide2(33,3)): ext2_free_blocks: bit already cleared for block 1048576
EXT2-fs error (device ide2(33,3)): ext2_free_blocks: bit already cleared for block 1048576

^
I got the following while rm -rf'ing my mozilla cvs checkout.  Deadly or not deadly?

-- 
L1:	khromy		;khromy(at)khromy.lnuxlab.net

Re: EXT2-fs error

[Rogier Wolff]

khromy wrote:
> Linux vingeren.girl 2.4.3-pre7 #5 Mon Mar 26 23:33:59 EST 2001 i686 unknown
> 
> EXT2-fs error (device ide2(33,3)): ext2_free_blocks: bit already cleared for block 1048576
> EXT2-fs error (device ide2(33,3)): ext2_free_blocks: bit already cleared for block 1048576
> 
> ^
> I got the following while rm -rf'ing my mozilla cvs checkout.  Deadly or not deadly?

Highly deadly. 

Your disk is dropping bits, or, more likely, your RAM. This is very,
very bad.

Can you compile 100 kernes without error?

				Roger. 

-- 
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots. 
* There are also old, bald pilots. 

Re: EXT2-fs error

[Alan Cox]

> > I got the following while rm -rf'ing my mozilla cvs checkout.  Deadly or not deadly?
> 
> Highly deadly. 
> 
> Your disk is dropping bits, or, more likely, your RAM. This is very,
> very bad.

if it was 2.2 I'd believe it. 2.4 is still showing these kind of problems in
software on many VIA chipset athlon boards and under extreme loads on other
boxes too.

Re: EXT2-fs error

[Dale E Martin]

> Linux vingeren.girl 2.4.3-pre7 #5 Mon Mar 26 23:33:59 EST 2001 i686 unknown
> 
> EXT2-fs error (device ide2(33,3)): ext2_free_blocks: bit already cleared for block 1048576
> EXT2-fs error (device ide2(33,3)): ext2_free_blocks: bit already cleared for block 1048576
> 
> ^
> I got the following while rm -rf'ing my mozilla cvs checkout.  Deadly or not deadly?

Are you running with a Buslogic SCSI card?  2.4.x (x < 3 - pre something)
has a problem with them.  I was seeing exactly these sorts of errors before
I went to 2.4.3 pre-8.

Later,
	Dale
-- 
Dale E. Martin, Clifton Labs, Inc.
Senior Computer Engineer
dmartin@cliftonlabs.com
http://www.cliftonlabs.com
pgp key available

Re: EXT2-fs error

[Ian Wehrman]

Mohammad A. Haque <mhaque@haque.net> wrote:
> I got the following after compiling/rebooting into 2.4.2 and forcing a
> fsck.
> 
> EXT2-fs error (device ide0(3,3)): ext2_readdir: bad entry in directory
> #508411: rec_len is smaller than minimal - offset=0, inode=0, rec_len=0,
> name_len=0
> EXT2-fs error (device ide0(3,3)): ext2_readdir: bad entry in directory
> #508411: rec_len is smaller than minimal - offset=0, inode=0, rec_len=0,
> name_len=0
> 
> Possibly the result of the 'silent' bug in 2.4.1?

you are not the only one who found this bug. immediately after booting 2.4.2 i
received dozens of these errors, resulting in _major_ filesystem corruption.
after a half hour of fsck'ing i managed to bring the machine back into a usable
state, but there are still many files and directories around the fs that have
the wrong uid/gid associated with them, as well as incorrect file type,
permissions, etc. i'm not using any unusual hardware, and haven't had any
other recent issues like this. let me know if i can provide further information,
or test patches. 

thanks,
ian wehrman 

Re: EXT2-fs error

[John Heil]

On Fri, 23 Feb 2001, Ian Wehrman wrote:

> Date: Fri, 23 Feb 2001 13:12:05 -0600
> From: Ian Wehrman <ian@wehrman.com>
> To: mhaque@haque.net, adilger@turbolinux.com, linux-kernel@vger.kernel.org
> Subject: Re: EXT2-fs error
> 
> Mohammad A. Haque <mhaque@haque.net> wrote:
> > I got the following after compiling/rebooting into 2.4.2 and forcing a
> > fsck.
> > 
> > EXT2-fs error (device ide0(3,3)): ext2_readdir: bad entry in directory
> > #508411: rec_len is smaller than minimal - offset=0, inode=0, rec_len=0,
> > name_len=0
> > EXT2-fs error (device ide0(3,3)): ext2_readdir: bad entry in directory
> > #508411: rec_len is smaller than minimal - offset=0, inode=0, rec_len=0,
> > name_len=0
> > 
> > Possibly the result of the 'silent' bug in 2.4.1?
> 
> you are not the only one who found this bug. immediately after booting 2.4.2 i
> received dozens of these errors, resulting in _major_ filesystem corruption.

In contrast perhaps, 2.4.1-ac19 seems clean so far in this regard after
having some different but equivalently bad corruption in 2.4.1-final.  


> after a half hour of fsck'ing i managed to bring the machine back into a usable
> state, but there are still many files and directories around the fs that have
> the wrong uid/gid associated with them, as well as incorrect file type,
> permissions, etc. i'm not using any unusual hardware, and haven't had any
> other recent issues like this. let me know if i can provide further information,
> or test patches. 
> 
> thanks,
> ian wehrman 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

-----------------------------------------------------------------
John Heil
South Coast Software
Custom systems software for UNIX and IBM MVS mainframes
1-714-774-6952
kerndev@sc-software.com
johnhscs@sc-software.com
http://www.sc-software.com
-----------------------------------------------------------------

Re: EXT2-fs error

[Alan Cox]

> > Possibly the result of the 'silent' bug in 2.4.1?
> 
> you are not the only one who found this bug. immediately after booting 2.4.2 i
> received dozens of these errors, resulting in _major_ filesystem corruption.
> after a half hour of fsck'ing i managed to bring the machine back into a usable

Had you been running 2.4.1 before that ?

Re: EXT2-fs error

[John Heil]

On Fri, 23 Feb 2001, Alan Cox wrote:

> Date: Fri, 23 Feb 2001 19:26:17 +0000 (GMT)
> From: Alan Cox <alan@lxorguk.ukuu.org.uk>
> To: ian@wehrman.com
> Cc: mhaque@haque.net, adilger@turbolinux.com, linux-kernel@vger.kernel.org
> Subject: Re: EXT2-fs error
> 
> > > Possibly the result of the 'silent' bug in 2.4.1?
> > 
> > you are not the only one who found this bug. immediately after booting 2.4.2 i
> > received dozens of these errors, resulting in _major_ filesystem corruption.
> > after a half hour of fsck'ing i managed to bring the machine back into a usable
> 
> Had you been running 2.4.1 before that ?

I had, and received a bit different corruption involving inode and block
bitmap errors rather than directories... ac19 seems so far to have solved
it.


> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

-----------------------------------------------------------------
John Heil
South Coast Software
Custom systems software for UNIX and IBM MVS mainframes
1-714-774-6952
kerndev@sc-software.com
johnhscs@sc-software.com
http://www.sc-software.com
-----------------------------------------------------------------

Re: EXT2-fs error

[A E Lawrence]

Alan Cox wrote:
> 
> > > Possibly the result of the 'silent' bug in 2.4.1?
> >
> > you are not the only one who found this bug. immediately after booting 2.4.2 i
> > received dozens of these errors, resulting in _major_ filesystem corruption.
> > after a half hour of fsck'ing i managed to bring the machine back into a usable
> 
> Had you been running 2.4.1 before that ?

I have seen similar problems on stock 2.4.2 a machine which has not run
2.4.1.

ael
-- 
Dr A E Lawrence

Re: EXT2-fs error

[Alan Cox]

> I have seen similar problems on stock 2.4.2 a machine which has not run
> 2.4.1.

What disk controllers ? We really need that sort of info in order to see the
pattern in the odd reports of corruption we get

Re: EXT2-fs error

[A E Lawrence]

Alan Cox wrote:
> 
> > I have seen similar problems on stock 2.4.2 a machine which has not run
> > 2.4.1.
> 
> What disk controllers ? We really need that sort of info in order to see the
> pattern in the odd reports of corruption we get

Sorry:-

00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev
10) (prog-if 8a [Master SecP PriP])
	Flags: bus master, medium devsel, latency 32
	I/O ports at d000
	Capabilities: [c0] Power Management version 2

With dma enabled. If this is a known problem on this chipset, that may
be the explanation.

ael
-- 
A E Lawrence

Re: EXT2-fs error

[A E Lawrence]

A E Lawrence wrote:
> 
> Alan Cox wrote:
> >
> > > I have seen similar problems on stock 2.4.2 a machine which has not run
> > > 2.4.1.
> >
> > What disk controllers ? We really need that sort of info in order to see the
> > pattern in the odd reports of corruption we get

Problems have just started to show up under 2.2.18, so it is likely that
the hardware has become flakey. Bit of a coincidence, unless it is a
side effect of upgrading one of the packages for 2.4.2 :-( or a damaged
library.

So you had better discount this report. Apologies.

Adrian 
-- 
A E Lawrence

Re: EXT2-fs error

[A E Lawrence]

A E Lawrence wrote:
> 
> A E Lawrence wrote:
> >
> > Alan Cox wrote:
> > >
> > > > I have seen similar problems on stock 2.4.2 a machine which has not run
> > > > 2.4.1.
> > >
> > > What disk controllers ? We really need that sort of info in order to see the
> > > pattern in the odd reports of corruption we get
> 
> Problems have just started to show up under 2.2.18, so it is likely that
> the hardware has become flakey. Bit of a coincidence, unless it is a
> side effect of upgrading one of the packages for 2.4.2 :-( or a damaged
> library.
> 
> So you had better discount this report. Apologies.

Now investigated: the hardware has not changed. Rather the corruption
under 2.2.18 only happens when hdparm -d1 is executed. I guess that is
well reported, but I had forgotten if I ever knew :-(

In contrast 2.4.2 corruptions happen whether dma is explicitly turned on
by hdparm or not.

[IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 10)]

ael
-- 
A E Lawrence

Re: EXT2-fs error

[John Heil]

On Sun, 25 Feb 2001, A E Lawrence wrote:
> A E Lawrence wrote:
> > 
> > A E Lawrence wrote:
> > >
> > > Alan Cox wrote:
> > > >
> > > > > I have seen similar problems on stock 2.4.2 a machine which has not run
> > > > > 2.4.1.
> > > >
> > > > What disk controllers ? We really need that sort of info in order to see the
> > > > pattern in the odd reports of corruption we get
> > 
> > Problems have just started to show up under 2.2.18, so it is likely that
> > the hardware has become flakey. Bit of a coincidence, unless it is a
> > side effect of upgrading one of the packages for 2.4.2 :-( or a damaged
> > library.
> > 
> > So you had better discount this report. Apologies.
> 
> Now investigated: the hardware has not changed. Rather the corruption
> under 2.2.18 only happens when hdparm -d1 is executed. I guess that is
> well reported, but I had forgotten if I ever knew :-(
> 
> In contrast 2.4.2 corruptions happen whether dma is explicitly turned on
> by hdparm or not.
> 
> [IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 10)]
> 

The corruption I got seemed to be non-chipset related.

The 2.4.1 corruption I experienced spanned 2.2.14 (RH 6.2)... 

The 2.4.1 IDE support was in an ALI 1535 south bridge in a Crusoe based
embedded system...  

00:0f.0 IDE interface: Acer Laboratories Inc. [ALi] M5229 IDE (rev c3)
(prog-if b4)
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
	Latency: 64 (500ns min, 1000ns max)
	Interrupt: pin A routed to IRQ 0
	Region 0: I/O ports at 01f0 [size=16]
	Region 1: I/O ports at 03f4
	Region 2: I/O ports at 0170 [size=8]
	Region 3: I/O ports at 0374
	Region 4: I/O ports at 1400 [size=16]
	Capabilities: [60] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

Disk was...

/dev/hdb:

 Model=HITACHI_DK23AA-60, FwRev=00XEA0A0, SerialNo=F77166
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
 RawCHS=12416/15/63, TrkSize=36477, SectSize=579, ECCbytes=4
 BuffType=3(DualPortCache), BuffSize=512kB, MaxMultSect=16, MultSect=off
 DblWordIO=no, OldPIO=2, DMA=yes, OldDMA=2
 CurCHS=12416/15/63, CurSects=142606515, LBA=yes, LBAsects=11733120
 tDMA={min:120,rec:120}, DMA modes: sword0 sword1 sword2 mword0 mword1
mword2 
 IORDY=yes, tPIO={min:400,w/IORDY:120}, PIO modes: mode3 mode4 
 UDMA modes: mode0 mode1 *mode2 mode3 mode4 


When the above system couldn't adequately repair itself,
I fsck'd it on the following....

2.2.14-5.0 RH 6.2 desktop PII w PIIX4 IDE...
 
00:07.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01)
(prog-if 80 [Master])
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
	Latency: 64 set
	Region 4: I/O ports at 1460

Initially, the  2.2.14  RH 6.2 had e2fsprogs 1.18, but I ugraded it to 
e2fsck 1.19,  thinking that might be the problem but it did _not_ help.

The 2 systems, both with e2fsck 1.19, would do fsck repairs 
after the other had touched it. It seemed impossible to keep it 
error free.  

This cross-system disk transfering was error free in 2.4.0-test10-pre3. 

2.4.1-final was the first post 2.4.0-final kernel after t10p3, that
saw any significant activity.

I've since upgraded the RH to 2.2.18 and the embedded to -ac19.

So far, no more problems but I still haven't used the ac19's disk  
on 2.2.18 very much yet but it will have to happen soon... 
I am a bit gun-shy of it still.

I didn't/don't have much time to spend on this and I'm hoping ac19
is bug free is this regard... but I'm interested in how this 
turns out.  

My guess was that I may have hit the bug Russel King fixed for his ARM
system.  IRC, that fix hit the -ac tree from Linus's 2.4.2-pre2. 


-----------------------------------------------------------------
John Heil
South Coast Software
Custom systems software for UNIX and IBM MVS mainframes
1-714-774-6952
johnhscs@sc-software.com
http://www.sc-software.com
-----------------------------------------------------------------

Re: EXT2-fs error

[Mike Brown]

On Sat, 24 Feb 2001, Alan Cox wrote:

>> I have seen similar problems on stock 2.4.2 a machine which has not run
>> 2.4.1.
>
>What disk controllers ? We really need that sort of info in order to see the
>pattern in the odd reports of corruption we get
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/
>

I also just ran into the ext2 bug:

Feb 25 06:27:05 morpheus kernel: EXT2-fs error (device ide0(3,1)):
ext2_readdir:
 directory #881700 contains a hole at offset 0
Feb 25 06:27:05 morpheus kernel: Remounting filesystem read-only

I had been running 2.4.1 before upgrading to 2.4.2.  My machine had been
up with 2.4.1 for 13 days, then i added a system fan, then it was up for
another 8 days after that with no problems.

Up with 2.4.2 for about a day and I ran into the above ext2 error.  I also
have the VIA Apollo chipset:

00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 10) (prog-if 8a [Master SecP PriP])
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 32 set
        Region 4: I/O ports at d000 [size=16]
        Capabilities: [c0] Power Management version 2
                Flags: PMEClk- AuxPwr- DSI- D1- D2- PME-
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

Also, during boot phase I had been manually running:

/sbin/hdparm -d1 /dev/hda

To turn on DMA on my primary disk since the 2.2.x series didn't turn this
on by default.  /dev/hda is a Western Digital:

Feb 25 12:35:37 morpheus kernel: hda: WDC WD273BA, ATA DISK drive
Feb 25 12:35:37 morpheus kernel: ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Feb 25 12:35:37 morpheus kernel: hda: 53464320 sectors (27374 MB) w/1961KiB Cache, CHS=3328/255/63


Let me know if there is any other information I can provide.  I also have
a notebook which as been running 2.4.2 without trouble for a few days.
This notebook has an Intel IDE controller.  Seems to me like this is a VIA
Apollo bug......  Thanks.


-Michael F. Brown, UMass Lowell Computer Science

phone:  (978) 934-5354
email:  mbrown@cs.uml.edu

int *x; while (1) { x = (int *) malloc (sizeof (int)); }

EXT2-fs error

[Mohammad A. Haque]

I got the following after compiling/rebooting into 2.4.2 and forcing a
fsck.

EXT2-fs error (device ide0(3,3)): ext2_readdir: bad entry in directory
#508411: rec_len is smaller than minimal - offset=0, inode=0, rec_len=0,
name_len=0
EXT2-fs error (device ide0(3,3)): ext2_readdir: bad entry in directory
#508411: rec_len is smaller than minimal - offset=0, inode=0, rec_len=0,
name_len=0

Possibly the result of the 'silent' bug in 2.4.1?

-- 

=====================================================================
Mohammad A. Haque                              http://www.haque.net/
                                               mhaque@haque.net

  "Alcohol and calculus don't mix.             Project Lead
   Don't drink and derive." --Unknown          http://wm.themes.org/
                                               batmanppc@themes.org
=====================================================================

Re: EXT2-fs error

[Andreas Dilger]

Mohammad A. Haque writes:
> I got the following after compiling/rebooting into 2.4.2 and forcing a
> fsck.

Did fsck complain?  If not, then it is a 2.4.2 kernel/driver bug, possibly
not reading any data from disk (the below errors are generated from a zero
filled directory block).

> EXT2-fs error (device ide0(3,3)): ext2_readdir: bad entry in directory
> #508411: rec_len is smaller than minimal - offset=0, inode=0, rec_len=0,
> name_len=0
> EXT2-fs error (device ide0(3,3)): ext2_readdir: bad entry in directory
> #508411: rec_len is smaller than minimal - offset=0, inode=0, rec_len=0,
> name_len=0

Cheers, Andreas
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert

Re: EXT2-fs error

[Mohammad A. Haque]

Well, here's the whole situtation...

Compiled 2.4.2 and reboot forcing fsck. No errors.

Tried mounting a cd image via loopback to see if loopback was working
again. Mount hangs. Reboot command stalled waiting for filesystems to
unmount. Force with alt-sysreq-<s,u,b>. Booted w/o any errors. Restart
forcing fsck and this time fsck needs to clear some inodes.

Once I am rebooted again, I went to reinstall some rpms for files I saw
fsck complain about and I get these errors.


On Thu, 22 Feb 2001, Andreas Dilger wrote:

> Did fsck complain?  If not, then it is a 2.4.2 kernel/driver bug, possibly
> not reading any data from disk (the below errors are generated from a zero
> filled directory block).
>
> > EXT2-fs error (device ide0(3,3)): ext2_readdir: bad entry in directory
> > #508411: rec_len is smaller than minimal - offset=0, inode=0, rec_len=0,
> > name_len=0
> > EXT2-fs error (device ide0(3,3)): ext2_readdir: bad entry in directory
> > #508411: rec_len is smaller than minimal - offset=0, inode=0, rec_len=0,
> > name_len=0

-- 

=====================================================================
Mohammad A. Haque                              http://www.haque.net/
                                               mhaque@haque.net

  "Alcohol and calculus don't mix.             Project Lead
   Don't drink and derive." --Unknown          http://wm.themes.org/
                                               batmanppc@themes.org
=====================================================================

Ext2-fs error

[mkloppstech]

The EXT2-fs errors I recently reported for test11 seem to be gone with
test12-pre5. At least I couldn't reproduce the error, neither with
overcommit_memory turned on nor off; maybe the error was due to
turning on write cache of my hard disk.

The error was a wrong reading of directory lengths and inode nnumbers:
The file system seemed to read the inode numbers not as supposed to do:
xxxx|xxxx|xxxx|xxxx|xxxx
     rrrr

but like this:
xxxx|xxxx|xxxx|xxxx|xxxx
 rrr_r
The message was:

Dec  4 13:04:19 john kernel: EXT2-fs error (device ide0(3,3)): ext2_readdir: bad entry in directory #280596: rec_len % 4 != 0 - offset=0, inode=68583844, rec_len=13758, name_len=0
Dec  4 15:38:07 john kernel: EXT2-fs error (device ide0(3,3)): ext2_readdir: bad entry in directory #280596: rec_len % 4 != 0 - offset=0, inode=33188, rec_len=3591, name_len=0
Dec  4 15:38:07 john kernel: EXT2-fs error (device ide0(3,3)): ext2_readdir: bad entry in directory #659481: directory entry across
blocks - offset=0, inode=33188, rec_len=2536, name_len=0
Dec  4 15:39:38 john kernel: EXT2-fs error (device ide0(3,3)): ext2_readdir: bad entry in directory #280596: rec_len % 4 != 0 - offset=0, inode=33188, rec_len=3591, name_len=0
Dec  4 15:39:38 john kernel: EXT2-fs error (device ide0(3,3)): ext2_readdir: bad entry in directory #659481: directory entry across
blocks - offset=0, inode=33188, rec_len=2536, name_len=0

Mirko Kloppstech
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/