Andriy Gapon <a...@freebsd.org> wrote:
> on 30/03/2010 18:41 Andriy Gapon said the following:
> > on 30/03/2010 18:36 Fabian Keil said the following:
> >> Andriy Gapon <a...@freebsd.org> wrote:
> >>
> >>> on 29/03/2010 23:29 Fabian Keil said the following:
> >>>> Andriy Gapon <a...@freebsd.org> wrote:
> >>>>> Thus, clearly, it is a fault of a tool that formatted the media
> >>>>> for FAT. It should have picked correct values, or rejected
> >>>>> incorrect values if those were provided as overrides via command
> >>>>> line options.
> >>>> The kernel still shouldn't panic, though.
> >>> A quick reply to this point only - yes, I completely agree.
> >>> But remember that the panic happened only after the sources were
> >>> modified :)
> >> It wasn't clear from my message, but I was mainly referring to the
> >> division-by-zero panic mentioned at the beginning of the thread,
> >> for which I posted a work-around in
> >> <20100319191133.46fe2...@r500.local>.
> >
> > Oh, yes, right.
>
> To clarify - I already forgot that the original problem was division by
> zero panic and for some reason thought that it was EINVAL.
>
> Anyways, here is a patch that I would use.
> Unfortunately, ENOTIME to understand newfs_msdos code and fix it too,
>
> --- a/sys/fs/msdosfs/msdosfs_vfsops.c
> +++ b/sys/fs/msdosfs/msdosfs_vfsops.c
> @@ -580,6 +580,7 @@ mountmsdosfs(struct vnode *devvp, struct mount *mp)
> || (pmp->pm_BytesPerSec & (pmp->pm_BytesPerSec - 1))
> || (pmp->pm_HugeSectors == 0)
> || (pmp->pm_FATsecs == 0)
> + || (SecPerClust * pmp->pm_BlkPerSec > MAXBSIZE / DEV_BSIZE)
> ) {
> error = EINVAL;
> goto error_exit;That works, too: f...@r500 ~ $sudo mdconfig -a -t vnode -f /tank/ipod-image-formatiert md0 f...@r500 ~ $sudo mount_msdosfs /dev/md0 /mnt/ mount_msdosfs: /dev/md0: Invalid argument Is there a chance that this, or some other workaround, could be committed? Fabian
signature.asc
Description: PGP signature
