Al? The first bug was a legitimate partial completion error in
ll_rw_blk, however there appears to be other breakage hitting floppy as
well.
> (2.5.38 tarball, plain UP config, gcc-2.95.3)
>
> Unable to handle kernel paging request at virtual address 00001738
> c01370f0
> *pde = 00000000
> Oops: 0000
> CPU: 0
> EIP: 0060:[<c01370f0>] Not tainted
> Using defaults from ksymoops -t elf32-i386 -a i386
> EFLAGS: 00010292
> eax: c02fe12c ebx: c11a02a0 ecx: 00001810 edx: c7b09350
> esi: c11a0240 edi: c11a021c ebp: 00000000 esp: c6c2df10
> ds: 0068 es: 0068 ss: 0068
> Stack: c7b09350 c6f09aa0 ffffffe9 c114b360 c11a0260 00000000 00000000 c0137276
> c11a0240 c7b09350 c6f09aa0 c7b09350 c6f09aa0 c7b09350 c0130869 c7b09350
> c6f09aa0 00000000 c118c000 00008000 bffff9a8 c01307a6 c6c96ca0 c114b360
> Call Trace: [<c0137276>] [<c0130869>] [<c01307a6>] [<c0130b13>] [<c0106dbf>]
> Code: 83 b9 28 ff ff ff 00 75 1f 8b 46 44 ff 48 50 8b 46 44 8d 48
>
>
> >>EIP; c01370f0 <do_open+258/344> <=====
>
> >>eax; c02fe12c <blk_dev+22c/d340>
> >>ebx; c11a02a0 <END_OF_CODE+e87c20/????>
> >>ecx; 00001810 Before first symbol
> >>edx; c7b09350 <END_OF_CODE+77f0cd0/????>
> >>esi; c11a0240 <END_OF_CODE+e87bc0/????>
> >>edi; c11a021c <END_OF_CODE+e87b9c/????>
> >>esp; c6c2df10 <END_OF_CODE+6915890/????>
>
> Trace; c0137276 <blkdev_open+22/28>
> Trace; c0130869 <dentry_open+b9/16c>
> Trace; c01307a6 <filp_open+52/5c>
> Trace; c0130b13 <sys_open+37/78>
> Trace; c0106dbf <syscall_call+7/b>
>
> Code; c01370f0 <do_open+258/344>
> 00000000 <_EIP>:
> Code; c01370f0 <do_open+258/344> <=====
> 0: 83 b9 28 ff ff ff 00 cmpl $0x0,0xffffff28(%ecx) <=====
> Code; c01370f7 <do_open+25f/344>
> 7: 75 1f jne 28 <_EIP+0x28> c0137118 <do_open+280/344>
> Code; c01370f9 <do_open+261/344>
> 9: 8b 46 44 mov 0x44(%esi),%eax
> Code; c01370fc <do_open+264/344>
> c: ff 48 50 decl 0x50(%eax)
> Code; c01370ff <do_open+267/344>
> f: 8b 46 44 mov 0x44(%esi),%eax
> Code; c0137102 <do_open+26a/344>
> 12: 8d 48 00 lea 0x0(%eax),%ecx
>
> fs/block_dev.c:
> static int do_open(struct block_device *bdev, struct inode *inode, struct file *file)
> {
> ...
> if (bdev->bd_contains == bdev) {
> ...
> } else {
> down(&bdev->bd_contains->bd_sem);
> bdev->bd_contains->bd_part_count++;
> if (!bdev->bd_openers) {
> struct gendisk *g = get_gendisk(dev);
> struct hd_struct *p;
> BOGUS? -> p = g->part + minor(dev) - g->first_minor - 1;
> inode->i_data.backing_dev_info =
> bdev->bd_inode->i_data.backing_dev_info =
> bdev->bd_contains->bd_inode->i_data.backing_dev_info;
> OOPS HERE -> if (!p->nr_sects) {
> bdev->bd_contains->bd_part_count--;
> up(&bdev->bd_contains->bd_sem);
> ret = -ENXIO;
> goto out2;
> }
>
> I correlated a gdb disassembly with do_open(), and it looks like
> 'p' got a bogus value (ecx, 0x1810) at the indicated line.
>
> /Mikael
>
-- Jens Axboe- 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/