Re: debugging patch for ide-cd/isofs

Bill Hawes (whawes@star.net)
Wed, 16 Sep 1998 08:04:11 -0400

Gordon Chaffee wrote:
>
> After a bit more thought, I was missing something. It seems it is
> hanging somewhere after it returns from the ide-cd and cdrom routines
> and in fs/devices:check_disk_change(). OK, I think I know what is
> going on. If either an error occurs when trying to detect a disk
> change or a disk is actually changed, it falls through to the next
> operation instead of returning. The next operation happens to be
> a get_super(), but the superblock is already locked in isofs_read_super(),
> so we hang.
>
> Bill, this makes perfect sense when looking at your changes. Previously,
> the superblock was unlocked before calling check_disk_change(). Now,
> it is unlocked after calling check_disk_change(). With all the
> reordering you've done with error conditions, I'm not sure how you
> want to handle this one. As a test to make sure this is indeed the
> case, apply this pseudo patch to your fs/isofs/inode.c:

Hi Gordon,

It's good that you've tracked down the source of the hang, but there's a
good reason for keeping the superblock locked at that point -- The
locking is supposed to keep others from seeing the sb in an inconsistent
state. Even though the sb is technically correct at the time of the
check_disk_change(), a disk change will result in the releasing the sb
resources and returning a fail for the mount. So I'd prefer to not
unlock until we're certain that the mount will succeed.

Let me look at the check_disk_change code and see if something can be
done there ...

> It should fix the problem. It would seem to me there is something a
> bit wrong in check_disk_change(). If it gets an error as it appears
> to in this case, it assumes the disk has been changed. Should the
> check be instead:
>
> if (fops->check_media_change(dev) <= 0)
> return 0;

Apparently check_disk_change is being conservative; if it can't be sure
the disk didn't change, then assume that it has.

> Erik, the ide-cd code is completely clear of any blame.

Well, not exactly -- we still don't know why (1) the drive got a DMA
error and turned off DMA, and (2) why the subsequent check_disk_change
then returns an error. Apart from the question of why DMA gets turned
off, it appears that there may be some problems with the transition into
using PIO.

Regards,
Bill

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