MO-Drive under 2.4.7 usinf vfat

MO-Drive under 2.4.7 usinf vfat

[Detlev Offenbach]

[-- Attachment #1: Type: text/plain, Size: 767 bytes --]

Hi all,

I have just tested the new 2.4.7 kernel to see, whether it now works with a 
MO-Drive using the vfat filesystem. Unfortunately it still doesn't. Mounting 
a disk and writing to it is ok. However, when I try to read a file off the 
disk, the program crashes with a Segmentation fault and I get a oops in the 
messages file (see attachment). I tried ksymoops on this file, but either I 
did something wrong or it couldn't analyse it.

I hope, this issue will be fixed soon cause I would like to switch over to 
the 2.4 kernel series without scratching my set of MO-disks.

Regards
Detlev

Btw, please answer by email as well because I think I got removed from the 
mailing list somehow (or is it that quiet?).
-- 
Detlev Offenbach
detlev@offenbach.fs.uunet.de

[-- Attachment #2: oops.txt --]
[-- Type: text/plain, Size: 1290 bytes --]

Jul 21 14:38:21 majestix kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000000
Jul 21 14:38:21 majestix kernel:  printing eip:
Jul 21 14:38:21 majestix kernel: 00000000
Jul 21 14:38:21 majestix kernel: *pde = 00000000
Jul 21 14:38:21 majestix kernel: Oops: 0000
Jul 21 14:38:21 majestix kernel: CPU:    0
Jul 21 14:38:21 majestix kernel: EIP:    0010:[<00000000>]
Jul 21 14:38:21 majestix kernel: EFLAGS: 00010282
Jul 21 14:38:21 majestix kernel: eax: 00000000   ebx: d729dcc0   ecx: 00004000   edx: d729dce0
Jul 21 14:38:21 majestix kernel: esi: 40017000   edi: 00000000   ebp: 00004000   esp: d727ff80
Jul 21 14:38:21 majestix kernel: ds: 0018   es: 0018   ss: 0018
Jul 21 14:38:21 majestix kernel: Process more (pid: 1191, stackpage=d727f000)
Jul 21 14:38:21 majestix kernel: Stack: e2bad8fd d729dcc0 40017000 00004000 d729dce0 d729dcc0 ffffffea c012e156 
Jul 21 14:38:21 majestix kernel:        d729dcc0 40017000 00004000 d729dce0 d727e000 08050b68 08050b68 bffff49c 
Jul 21 14:38:21 majestix kernel:        c0106c2b 00000003 40017000 00004000 08050b68 08050b68 bffff49c 00000003 
Jul 21 14:38:21 majestix kernel: Call Trace: [sys_read+150/208] [system_call+51/56] 
Jul 21 14:38:21 majestix kernel: 
Jul 21 14:38:21 majestix kernel: Code:  Bad EIP value.

Re: MO-Drive under 2.4.7 usinf vfat

[Steven Walter]

On Sat, Jul 21, 2001 at 03:26:58PM +0200, Detlev Offenbach wrote:
> Hi all,
> 
> I have just tested the new 2.4.7 kernel to see, whether it now works with a 
> MO-Drive using the vfat filesystem. Unfortunately it still doesn't. Mounting 
> a disk and writing to it is ok. However, when I try to read a file off the 
> disk, the program crashes with a Segmentation fault and I get a oops in the 
> messages file (see attachment). I tried ksymoops on this file, but either I 
> did something wrong or it couldn't analyse it.
> 
> I hope, this issue will be fixed soon cause I would like to switch over to 
> the 2.4 kernel series without scratching my set of MO-disks.

You might try the -ac series.  I recall 2048 byte blocks being
implemented in its version of vfat (which is likely the problem you're
hitting).  Perhaps that particular patch hasn't made it to Linus' tree,
yet.
-- 
-Steven
In a time of universal deceit, telling the truth is a revolutionary act.
			-- George Orwell

kgdb and/or kdb for RH7.1

[Michael S. Miles]

Does anyone know if patches exist against the stock RedHat 7.1
kernel(2.4.2-2) to support remote kernel debugging(kgdb).  I would also be
interested in the same for kdb, but I'm primarily interested in kgdb.

If it doesn't exist I guess I will have to try to port the patches over
myself, I just didn't want to reinvent the wheel.

hopefully TIA,
michael

Re: kgdb and/or kdb for RH7.1

[Tigran Aivazian]

just in case you are wondering where to download kgdb from, there is one
maintained at sourceforge by Amit Kale

http://kgdb.sourceforge.net/

On Sat, 21 Jul 2001, Michael S. Miles wrote:

> Does anyone know if patches exist against the stock RedHat 7.1
> kernel(2.4.2-2) to support remote kernel debugging(kgdb).  I would also be
> interested in the same for kdb, but I'm primarily interested in kgdb.
> 
> If it doesn't exist I guess I will have to try to port the patches over
> myself, I just didn't want to reinvent the wheel.
> 
> hopefully TIA,
> michael
> 
> -
> 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/
> 

Re: kgdb and/or kdb for RH7.1

[arjan]

In article <KIEKJCGPOOADIOGPDJJLOEPGEFAA.mmiles@alacritech.com> you wrote:
> Does anyone know if patches exist against the stock RedHat 7.1
> kernel(2.4.2-2) to support remote kernel debugging(kgdb).  I would also be
> interested in the same for kdb, but I'm primarily interested in kgdb.

> If it doesn't exist I guess I will have to try to port the patches over
> myself, I just didn't want to reinvent the wheel.

Look in the src.rpm for the kernel, there's a ikd patch there...

Re: kgdb and/or kdb for RH7.1

[Keith Owens]

On Sat, 21 Jul 2001 12:30:34 -0400, 
"Michael S. Miles" <mmiles@alacritech.com> wrote:
>Does anyone know if patches exist against the stock RedHat 7.1
>kernel(2.4.2-2) to support remote kernel debugging(kgdb).  I would also be
>interested in the same for kdb, but I'm primarily interested in kgdb.

ftp://oss.sgi.com/projects/xfs/download/Release-1.0/patches/linux-2.4.2-kdb-04112001.patch.gz
is kdb v1.8 against Redhat 7.1.  There are no XFS dependencies in that
patch, but kdb and xfs hit a couple of common files so you might need
to resolve some patch failures.

It is a lot easier to start from that patch instead of trying to
convert a kdb patch from a standard kernel onto Redhat's kernel.  RH
took patches from the -ac tree as well which really messed up kdb, it
took me several hours to work out whta RH had done to each file, and I
had all the kdb patches.  AFAICR, the IKD patch in RH 7.1 does not fit
correctly.

Re: kgdb and/or kdb for RH7.1

[Keith Owens]

On Sun, 22 Jul 2001 11:58:15 +1000, 
Keith Owens <kaos@ocs.com.au> wrote:
>On Sat, 21 Jul 2001 12:30:34 -0400, 
>"Michael S. Miles" <mmiles@alacritech.com> wrote:
>>Does anyone know if patches exist against the stock RedHat 7.1
>>kernel(2.4.2-2) to support remote kernel debugging(kgdb).  I would also be
>>interested in the same for kdb, but I'm primarily interested in kgdb.
>
>ftp://oss.sgi.com/projects/xfs/download/Release-1.0/patches/linux-2.4.2-kdb-04112001.patch.gz
>is kdb v1.8 against Redhat 7.1.

Correction, that patch is against a standard 2.4.2 kernel.  The closest
I could find is
ftp://oss.sgi.com/projects/xfs/download/testing/Release-1.0.1-PR3/patches/patch-RH2.4.3-xfs-1.0.1-kdb
That is against Rawhide rather than RH 7.1 but it should be fairly
close.  So many patches, so little time :(.

Re: MO-Drive under 2.4.7 usinf vfat

[OGAWA Hirofumi]

Hi,

Detlev Offenbach <detlev@offenbach.fs.uunet.de> writes:

> Hi all,
> 
> I have just tested the new 2.4.7 kernel to see, whether it now works with a 
> MO-Drive using the vfat filesystem. Unfortunately it still doesn't. Mounting 
> a disk and writing to it is ok. However, when I try to read a file off the 
> disk, the program crashes with a Segmentation fault and I get a oops in the 
> messages file (see attachment). I tried ksymoops on this file, but either I 
> did something wrong or it couldn't analyse it.

Is the capacity of your MO disk more than 640M?
In order to clarify a problem, please send the debugging output of FAT.

---------------------- start example --------------------------------
 $ mount -t vfat /dev/sda /mnt -o debug
 $ dmesg | tail
  Type:   Optical Device                     ANSI SCSI revision: 02
Attached scsi removable disk sda at scsi0, channel 0, id 5, lun 0
sym53c875-0-<5,*>: asynchronous.
SCSI device sda: 310352 2048-byte hdwr sectors (636 MB)
sda: Write Protect is off
 sda:
MSDOS: Hardware sector size is 2048
[MS-DOS FS Rel. 12,FAT 16,check=n,conv=b,uid=0,gid=0,umask=022]
[me=0xf8,cs=8,#f=2,fs=1,fl=38,ds=77,de=512,data=85,se=0,ts=310352,ls=2048,rc=0,fc=4294967295]
Transaction block size = 2048
---------------------- end example --------------------------------

Perhaps, your MO disk will have the `ls' of a value smaller than 2048.
Logical sector size smaller than device sector size cannot be handled
with FAT of 2.4 series.

Thanks.
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>

Re: kgdb and/or kdb for RH7.1

[Amit S. Kale]

Hi,

I am not maintaining a kgdb patch for RH7.1 as yet. This is an extact
from the newly uploaded FAQ page on kgdb website.

Why only one kernel version is supported? 
I enhance kgdb and add documentation to kgdb webpage frequently. This
process is easy with a single kernel version as I can work on
enhancing and supporting newer kernel versions at the same time. I
myself need kgdb for kernel debugging on newer kernels for the
translation filesystem. Supporting older kernels involves backporting
enhancements and testing them. Usually a kgdb patch works for
multiple kernel versions with a bit of application of failed hunks by
hand. I plan to support a fixed 2.4 kernel version and a top of the line
2.5
kernel, once 2.5 kernel branch starts. 


Tigran Aivazian wrote:
> 
> just in case you are wondering where to download kgdb from, there is one
> maintained at sourceforge by Amit Kale
> 
> http://kgdb.sourceforge.net/
> 
> On Sat, 21 Jul 2001, Michael S. Miles wrote:
> 
> > Does anyone know if patches exist against the stock RedHat 7.1
> > kernel(2.4.2-2) to support remote kernel debugging(kgdb).  I would also be
> > interested in the same for kdb, but I'm primarily interested in kgdb.
> >
> > If it doesn't exist I guess I will have to try to port the patches over
> > myself, I just didn't want to reinvent the wheel.
> >
> > hopefully TIA,
> > michael
> >
> > -
> > 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/
> >
> 
> -
> 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/

-- 
Amit Kale
Veritas Software ( http://www.veritas.com )

Re: MO-Drive under 2.4.7 usinf vfat

[Pavel Machek]

Hi!

> I have just tested the new 2.4.7 kernel to see, whether it now works with a 
> MO-Drive using the vfat filesystem. Unfortunately it still doesn't. Mounting 
> a disk and writing to it is ok. However, when I try to read a file off the 
> disk, the program crashes with a Segmentation fault and I get a oops in the 
> messages file (see attachment). I tried ksymoops on this file, but either I 
> did something wrong or it couldn't analyse it.
> 
> I hope, this issue will be fixed soon cause I would like to switch over to 
> the 2.4 kernel series without scratching my set of MO-disks.

Try -o loop

-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.

Re: MO-Drive under 2.4.7 usinf vfat

[Jens Axboe]

On Tue, Jul 24 2001, Alan Cox wrote:
> > FAT oopses, right?
> > 
> > It will not be fixed (Logical sector size smaller than device sector
> > size) directly, there needs to be support for this type of thing. For
> > now folks should just use loop on top of DVD-RAM, for instance.
> 
> Oopses are bad. It means any random user can trick you into crashing your
> box just by swapping media around or you crash it in error
> 
> I/O error by all means - but oops is a bug

I'm not disagreeing, I'm just saying how I would like to see it get
fixed. That's all.

-- 
Jens Axboe

Re: MO-Drive under 2.4.7 usinf vfat

[OGAWA Hirofumi]

Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

> > FAT oopses, right?
> > 
> > It will not be fixed (Logical sector size smaller than device sector
> > size) directly, there needs to be support for this type of thing. For
> > now folks should just use loop on top of DVD-RAM, for instance.
> 
> Oopses are bad. It means any random user can trick you into crashing your
> box just by swapping media around or you crash it in error
> 
> I/O error by all means - but oops is a bug
> 

Yes, I agree.

I finished now writing and testing the following patch which fixed
oops and some messages.

Please apply.
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>

diff -urN linux-2.4.7/fs/fat/buffer.c fat-2.4.7/fs/fat/buffer.c
--- linux-2.4.7/fs/fat/buffer.c	Fri May 25 07:36:33 2001
+++ fat-2.4.7/fs/fat/buffer.c	Wed Jul 25 00:39:23 2001
@@ -100,62 +100,3 @@
 {
 	ll_rw_block(opr,nbreq,bh);
 }
-
-struct buffer_head *bigblock_fat_bread(struct super_block *sb, int block)
-{
-	unsigned int hardsect = get_hardsect_size(sb->s_dev);
-	int rblock, roffset;
-	struct buffer_head *real, *dummy;
-
-	if (hardsect <= sb->s_blocksize)
-		BUG();
-
-	dummy = NULL;
-	rblock = block / (hardsect / sb->s_blocksize);
-	roffset = (block % (hardsect / sb->s_blocksize)) * sb->s_blocksize;
-	real = bread(sb->s_dev, rblock, hardsect);
-	if (real != NULL) {
-		dummy = kmalloc(sizeof(struct buffer_head), GFP_KERNEL);
-		if (dummy != NULL) {
-			memset(dummy, 0, sizeof(*dummy));
-			dummy->b_data = real->b_data + roffset;
-			dummy->b_next = real;
-		} else
-			brelse(real);
-	}
-
-	return dummy;
-}
-
-void bigblock_fat_brelse(struct super_block *sb, struct buffer_head *bh)
-{
-	brelse(bh->b_next);
-	kfree(bh);
-}
-
-void bigblock_fat_mark_buffer_dirty(struct super_block *sb, struct buffer_head *bh)
-{
-	mark_buffer_dirty(bh->b_next);
-}
-
-void bigblock_fat_set_uptodate(struct super_block *sb, struct buffer_head *bh,
-			       int val)
-{
-	mark_buffer_uptodate(bh->b_next, val);
-}
-
-int bigblock_fat_is_uptodate(struct super_block *sb, struct buffer_head *bh)
-{
-	return buffer_uptodate(bh->b_next);
-}
-
-void bigblock_fat_ll_rw_block (struct super_block *sb, int opr, int nbreq,
-			       struct buffer_head *bh[32])
-{
-	struct buffer_head *tmp[32];
-	int i;
-
-	for (i = 0; i < nbreq; i++)
-		tmp[i] = bh[i]->b_next;
-	ll_rw_block(opr, nbreq, tmp);
-}
diff -urN linux-2.4.7/fs/fat/cvf.c fat-2.4.7/fs/fat/cvf.c
--- linux-2.4.7/fs/fat/cvf.c	Tue Oct 17 04:58:51 2000
+++ fat-2.4.7/fs/fat/cvf.c	Wed Jul 25 00:39:23 2001
@@ -23,79 +23,32 @@
 
 struct buffer_head *default_fat_bread(struct super_block *,int);
 struct buffer_head *default_fat_getblk(struct super_block *, int);
-struct buffer_head *bigblock_fat_bread(struct super_block *, int);
 void default_fat_brelse(struct super_block *, struct buffer_head *);
-void bigblock_fat_brelse(struct super_block *, struct buffer_head *);
-void default_fat_mark_buffer_dirty (struct super_block *,
-	struct buffer_head *);
-void bigblock_fat_mark_buffer_dirty (struct super_block *,
-	struct buffer_head *);
+void default_fat_mark_buffer_dirty (struct super_block *, struct buffer_head *);
 void default_fat_set_uptodate (struct super_block *, struct buffer_head *,int);
-void bigblock_fat_set_uptodate (struct super_block *, struct buffer_head *,int);
 int default_fat_is_uptodate(struct super_block *, struct buffer_head *);
-int bigblock_fat_is_uptodate(struct super_block *, struct buffer_head *);
 int default_fat_access(struct super_block *sb,int nr,int new_value);
-void default_fat_ll_rw_block (
-	struct super_block *sb,
-	int opr,
-	int nbreq,
-	struct buffer_head *bh[32]);
-void bigblock_fat_ll_rw_block (
-	struct super_block *sb,
-	int opr,
-	int nbreq,
-	struct buffer_head *bh[32]);
+void default_fat_ll_rw_block (struct super_block *sb, int opr, int nbreq,
+			      struct buffer_head *bh[32]);
 int default_fat_bmap(struct inode *inode,int block);
-ssize_t default_fat_file_write(
-	struct file *filp,
-	const char *buf,
-	size_t count,
-	loff_t *ppos);
+ssize_t default_fat_file_write(struct file *filp, const char *buf,
+			       size_t count, loff_t *ppos);
 
 struct cvf_format default_cvf = {
-	0,	/* version - who cares? */	
-	"plain",
-	0,	/* flags - who cares? */
-	NULL,
-	NULL,
-	NULL,
-	default_fat_bread,
-	default_fat_getblk,
-	default_fat_brelse,
-	default_fat_mark_buffer_dirty,
-	default_fat_set_uptodate,
-	default_fat_is_uptodate,
-	default_fat_ll_rw_block,
-	default_fat_access,
-	NULL,
-	default_fat_bmap,
-	generic_file_read,
-	default_fat_file_write,
-	NULL,
-	NULL
-};
-
-struct cvf_format bigblock_cvf = {
-	0,	/* version - who cares? */	
-	"big_blocks",
-	0,	/* flags - who cares? */
-	NULL,
-	NULL,
-	NULL,
-	bigblock_fat_bread,
-	bigblock_fat_bread,
-	bigblock_fat_brelse,
-	bigblock_fat_mark_buffer_dirty,
-	bigblock_fat_set_uptodate,
-	bigblock_fat_is_uptodate,
-	bigblock_fat_ll_rw_block,
-	default_fat_access,
-	NULL,
-	default_fat_bmap,
-	NULL,
-	default_fat_file_write,
-	NULL,
-	NULL
+	cvf_version: 		0,	/* version - who cares? */	
+	cvf_version_text: 	"plain",
+	flags:			0,	/* flags - who cares? */
+	cvf_bread:		default_fat_bread,
+	cvf_getblk:		default_fat_getblk,
+	cvf_brelse:		default_fat_brelse,
+	cvf_mark_buffer_dirty:	default_fat_mark_buffer_dirty,
+	cvf_set_uptodate:	default_fat_set_uptodate,
+	cvf_is_uptodate:	default_fat_is_uptodate,
+	cvf_ll_rw_block:	default_fat_ll_rw_block,
+	fat_access:		default_fat_access,
+	cvf_bmap:		default_fat_bmap,
+	cvf_file_read:		generic_file_read,
+	cvf_file_write:		default_fat_file_write,
 };
 
 struct cvf_format *cvf_formats[MAX_CVF_FORMATS];
diff -urN linux-2.4.7/fs/fat/inode.c fat-2.4.7/fs/fat/inode.c
--- linux-2.4.7/fs/fat/inode.c	Tue Jun 12 11:15:27 2001
+++ fat-2.4.7/fs/fat/inode.c	Wed Jul 25 01:22:35 2001
@@ -36,7 +36,7 @@
 #include <asm/uaccess.h>
 #include <asm/unaligned.h>
 
-extern struct cvf_format default_cvf, bigblock_cvf;
+extern struct cvf_format default_cvf;
 
 /* #define FAT_PARANOIA 1 */
 #define DEBUG_LEVEL 0
@@ -448,8 +448,6 @@
 	hard_blksize = get_hardsect_size(sb->s_dev);
 	if (!hard_blksize)
 		hard_blksize = 512;
-	if (hard_blksize != 512)
-		printk("MSDOS: Hardware sector size is %d\n", hard_blksize);
 
 	opts.isvfat = sbi->options.isvfat;
 	if (!parse_options((char *) data, &fat, &debug, &opts,
@@ -464,8 +462,8 @@
 	set_blocksize(sb->s_dev, hard_blksize);
 	bh = bread(sb->s_dev, 0, sb->s_blocksize);
 	if (bh == NULL) {
-		brelse (bh);
-		goto out_no_bread;
+		printk("FAT: unable to read boot sector\n");
+		goto out_fail;
 	}
 
 /*
@@ -489,15 +487,23 @@
 		CF_LE_W(get_unaligned((unsigned short *) &b->sector_size));
 	if (!logical_sector_size
 	    || (logical_sector_size & (logical_sector_size - 1))) {
-		printk("fatfs: bogus logical sector size %d\n",
+		printk("FAT: bogus logical sector size %d\n",
 		       logical_sector_size);
 		brelse(bh);
 		goto out_invalid;
 	}
 
 	sbi->cluster_size = b->cluster_size;
-	if (!sbi->cluster_size || (sbi->cluster_size & (sbi->cluster_size - 1))) {
-		printk("fatfs: bogus cluster size %d\n", sbi->cluster_size);
+	if (!sbi->cluster_size
+	    || (sbi->cluster_size & (sbi->cluster_size - 1))) {
+		printk("FAT: bogus cluster size %d\n", sbi->cluster_size);
+		brelse(bh);
+		goto out_invalid;
+	}
+
+	if (logical_sector_size < hard_blksize) {
+		printk("FAT: logical sector size too small for device"
+		       " (logical sector size = %d)\n", logical_sector_size);
 		brelse(bh);
 		goto out_invalid;
 	}
@@ -528,8 +534,8 @@
 		if (bh->b_blocknr != fsinfo_block) {
 			fsinfo_bh = bread(sb->s_dev, fsinfo_block, hard_blksize);
 			if (fsinfo_bh == NULL) {
-				printk("FAT: bread failed, fsinfo block %d\n",
-				       fsinfo_block);
+				printk("FAT: bread failed, FSINFO block"
+				       " (blocknr = %d)\n", fsinfo_block);
 				brelse(bh);
 				goto out_invalid;
 			}
@@ -585,20 +591,14 @@
 
 	sb->s_blocksize = logical_sector_size;
 	sb->s_blocksize_bits = ffs(logical_sector_size) - 1;
-	if (sb->s_blocksize >= hard_blksize) {
-		set_blocksize(sb->s_dev, sb->s_blocksize);
-		sbi->cvf_format = &default_cvf;
-	} else {
-		set_blocksize(sb->s_dev, hard_blksize);
-		sbi->cvf_format = &bigblock_cvf;
-	}
-
-	if (!strcmp(cvf_format,"none"))
+	set_blocksize(sb->s_dev, sb->s_blocksize);
+	sbi->cvf_format = &default_cvf;
+	if (!strcmp(cvf_format, "none"))
 		i = -1;
 	else
 		i = detect_cvf(sb,cvf_format);
 	if (i >= 0)
-		error = cvf_formats[i]->mount_cvf(sb,cvf_options);
+		error = cvf_formats[i]->mount_cvf(sb, cvf_options);
 	if (error || debug) {
 		/* The MSDOS_CAN_BMAP is obsolete, but left just to remember */
 		printk("[MS-DOS FS Rel. 12,FAT %d,check=%c,conv=%c,"
@@ -607,16 +607,14 @@
 		       opts.conversion,opts.fs_uid,opts.fs_gid,opts.fs_umask,
 		       MSDOS_CAN_BMAP(sbi) ? ",bmap" : "");
 		printk("[me=0x%x,cs=%d,#f=%d,fs=%d,fl=%ld,ds=%ld,de=%d,data=%ld,"
-		       "se=%d,ts=%ld,ls=%d,rc=%ld,fc=%u]\n",
-		       b->media,sbi->cluster_size,
-		       sbi->fats,sbi->fat_start,
-		       sbi->fat_length,
-		       sbi->dir_start,sbi->dir_entries,
-		       sbi->data_start,
-		       CF_LE_W(*(unsigned short *) &b->sectors),
-		       (unsigned long)b->total_sect,logical_sector_size,
-		       sbi->root_cluster,sbi->free_clusters);
-		printk ("Transaction block size = %d\n", hard_blksize);
+		       "se=%u,ts=%u,ls=%d,rc=%ld,fc=%u]\n",
+		       b->media, sbi->cluster_size, sbi->fats,
+		       sbi->fat_start, sbi->fat_length, sbi->dir_start,
+		       sbi->dir_entries, sbi->data_start,
+		       CF_LE_W(get_unaligned((unsigned short *)&b->sectors)),
+		       CF_LE_L(b->total_sect), logical_sector_size,
+		       sbi->root_cluster, sbi->free_clusters);
+		printk ("hard sector size = %d\n", hard_blksize);
 	}
 	if (i < 0)
 		if (sbi->clusters + 2 > fat_clusters)
@@ -653,7 +651,7 @@
 	if (! sbi->nls_io)
 		sbi->nls_io = load_nls_default();
 
-	root_inode=new_inode(sb);
+	root_inode = new_inode(sb);
 	if (!root_inode)
 		goto out_unload_nls;
 	root_inode->i_ino = MSDOS_ROOT_INO;
@@ -662,29 +660,27 @@
 	sb->s_root = d_alloc_root(root_inode);
 	if (!sb->s_root)
 		goto out_no_root;
-	if(i>=0) {
+	if(i >= 0) {
 		sbi->cvf_format = cvf_formats[i];
 		++cvf_format_use_count[i];
 	}
 	return sb;
 
 out_no_root:
-	printk("get root inode failed\n");
+	printk("FAT: get root inode failed\n");
 	iput(root_inode);
 	unload_nls(sbi->nls_io);
 out_unload_nls:
 	unload_nls(sbi->nls_disk);
 	goto out_fail;
 out_invalid:
-	if (!silent)
-		printk("VFS: Can't find a valid MSDOS filesystem on dev %s.\n",
+	if (!silent) {
+		printk("VFS: Can't find a valid FAT filesystem on dev %s.\n",
 			kdevname(sb->s_dev));
-	goto out_fail;
-out_no_bread:
-	printk("FAT bread failed\n");
+	}
 out_fail:
 	if (opts.iocharset) {
-		printk("VFS: freeing iocharset=%s\n", opts.iocharset);
+		printk("FAT: freeing iocharset=%s\n", opts.iocharset);
 		kfree(opts.iocharset);
 	}
 	if(sbi->private_data)

Re: MO-Drive under 2.4.7 usinf vfat

[Alan Cox]

> FAT oopses, right?
> 
> It will not be fixed (Logical sector size smaller than device sector
> size) directly, there needs to be support for this type of thing. For
> now folks should just use loop on top of DVD-RAM, for instance.

Oopses are bad. It means any random user can trick you into crashing your
box just by swapping media around or you crash it in error

I/O error by all means - but oops is a bug

Re: MO-Drive under 2.4.7 usinf vfat

[Jens Axboe]

On Sun, Jul 22 2001, Douglas Gilbert wrote:
> > Logical sector size smaller than device sector size cannot
> > be handled with FAT of 2.4 series.
> 
> Great. When will that be fixed (Jens?) ? If not, can we get 
> a more civilized response than the current oops?

FAT oopses, right?

It will not be fixed (Logical sector size smaller than device sector
size) directly, there needs to be support for this type of thing. For
now folks should just use loop on top of DVD-RAM, for instance.

-- 
Jens Axboe

Re: MO-Drive under 2.4.7 usinf vfat

[OGAWA Hirofumi]

Hi,

Douglas Gilbert <dougg@torque.net> writes:

> OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> wrote:
> > Is the capacity of your MO disk more than 640M?
> 
> No, the capacity is 635600896 bytes.

[...]

> 
> > Perhaps, your MO disk will have the `ls' of a value smaller 
> > than 2048.
> Yes, ls=512 .
> 
> > Logical sector size smaller than device sector size cannot
> > be handled with FAT of 2.4 series.
> 
> Great. When will that be fixed (Jens?) ? If not, can we get 
> a more civilized response than the current oops?

The cause of this problem is me, and I think that it is the bug.
How should this problem be solved? I think that it is either of the
following.

    1) logical sector size smaller than device sector size isn't
       supported. (and output the message)

    2) read a file data via block buffer (like FAT of 2.2 series).

    3) other (drivers/block/loop.c?)

Please comment.
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>

Re: MO-Drive under 2.4.7 usinf vfat

[Douglas Gilbert]

OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> wrote:
> Is the capacity of your MO disk more than 640M?

No, the capacity is 635600896 bytes.

$ sg_readcap /dev/sg1
Read Capacity results:
   Last block address = 310351 (0x4bc4f), Number of blocks = 310352
   Block size = 2048 bytes

This is from my log:
 Attached scsi removable disk sdb at scsi4, channel 0, id 0, lun 0
 SCSI device sdb: 310352 2048-byte hdwr sectors (636 MB)

$ cat /proc/scsi/scsi 
Attached devices: 
Host: scsi1 Channel: 00 Id: 01 Lun: 00
  Vendor: IBM      Model: DNES-309170W     Rev: SA30
  Type:   Direct-Access                    ANSI SCSI revision: 03
Host: scsi4 Channel: 00 Id: 00 Lun: 00
  Vendor: FUJITSU  Model: M25-MCC3064AP    Rev: 0023
  Type:   Optical Device                   ANSI SCSI revision: 02

On my box the MO drive is /dev/sdb or /dev/sg1 .

Executing 'mount -t vfat /dev/sdb /mnt/extra -o debug'
put this in my log:
 MSDOS: Hardware sector size is 2048
 [MS-DOS FS Rel. 12,FAT 16,check=n,conv=b,uid=0,gid=0,umask=022]
 [me=0xf8,cs=32,#f=2,fs=1,fl=152,ds=305,de=512,data=
   337,se=0,ts=1241408,ls=512,rc=0,fc=4294967295]
 Transaction block size = 2048

> Perhaps, your MO disk will have the `ls' of a value smaller 
> than 2048.
Yes, ls=512 .

> Logical sector size smaller than device sector size cannot
> be handled with FAT of 2.4 series.

Great. When will that be fixed (Jens?) ? If not, can we get 
a more civilized response than the current oops?

Doug Gilbert

Re: MO-Drive under 2.4.7 usinf vfat

[Douglas Gilbert]

Detlev Offenbach <detlev@offenbach.fs.uunet.de> wrote:
> I have just tested the new 2.4.7 kernel to see, whether 
> it now works with a  MO-Drive using the vfat filesystem. 
> Unfortunately it still doesn't. Mounting a disk and 
> writing to it is ok. However, when I try to read a file 
> off the disk, the program crashes with a Segmentation 
> fault and I get a oops in the messages file (see 
> attachment). I tried ksymoops on this file, but either I 
> did something wrong or it couldn't analyse it.
> 
> I hope, this issue will be fixed soon cause I would 
> like to switch over to the 2.4 kernel series without 
> scratching my set of MO-disks.

Detlev,
I can confirm lk 2.4.6 is broken w.r.t. 2048 byte sectored
MO disks with vfat file systems. I have a FUJITSU  
Model: M25-MCC3064AP here (IDE device that uses the ide-scsi
driver) and it works just fine with dd (and through the sg 
interface). So I'm quite confident the failure is not being 
caused by the SCSI subsystem.

I cannot see any code changes in the sd driver between
lk 2.2 and lk 2.4 that impact this problem (as some
have suggested). When it works in lk 2.2 it follows
existing code pathes in the sd driver that exist and
work in the sd driver found in lk 2.4 .

Now the block subsystem might be expecting the sd driver
to play the same tricks as the sr driver in the way it
handles 2048 byte sectors. If so, that logic has never
been added to the sd driver. From memory there was a
thread on this issue that decided there were better ways
to address the block mismatch problem.

Anyway, I'll keep poking around.

Doug Gilbert