2002-04-05 13:22:05

by Denis Vlasenko

[permalink] [raw]
Subject: [DEADLOCK] automount, kupdated: D state

I was saving my daily work on an IDE disk.
I use automounter. On an attempt to mount it several processes
got stuck in D state.

kernel: 2.5.7 + new NTFS driver
ps and ksymoopsed parts of Alt-Sysrq-T output are attached.
ksymoops warnings trimmed except automount.dump.ksymoops
(they were the same).
--
vda


Attachments:
ps (4.84 kB)
automount.dump.ksymoops (1.16 kB)
umount.dump.ksymoops (1.15 kB)
sync.dump.ksymoops (761.00 B)
mount.dump.ksymoops (0.98 kB)
kupdated.dump.ksymoops (676.00 B)
Download all attachments

2002-04-05 14:59:51

by Anton Altaparmakov

[permalink] [raw]
Subject: Re: [DEADLOCK] automount, kupdated: D state

At 19:22 05/04/02, Denis Vlasenko wrote:
>I was saving my daily work on an IDE disk.
>I use automounter. On an attempt to mount it several processes
>got stuck in D state.
>
>kernel: 2.5.7 + new NTFS driver
>ps and ksymoopsed parts of Alt-Sysrq-T output are attached.
>ksymoops warnings trimmed except automount.dump.ksymoops
>(they were the same).

From looking at the information supplied, NTFS doesn't seem to be
involved. The processes seem to be stuck trying to write dirty buffers as
well as in nfs and pipefs - buffers could never get dirtied by the current
NTFS as it is entirely read-only.

btw. You had sent a problem report about cyrillic names with NTFS and I
suggested to try the new NTFS driver but you never got back to me whether
that fixed it or not... How is the new driver behaving? Are you stil seing
problems or is everything working fine now?

Best regards,

Anton


--
"I've not lost my mind. It's backed up on tape somewhere." - Unknown
--
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS Maintainer / WWW: http://linux-ntfs.sf.net/
IRC: #ntfs on irc.openprojects.net / ICQ: 8561279
WWW: http://www-stu.christs.cam.ac.uk/~aia21/

2002-04-06 09:55:11

by Denis Vlasenko

[permalink] [raw]
Subject: Re: [DEADLOCK] automount, kupdated: D state

On 5 April 2002 16:22, Denis Vlasenko wrote:
> I was saving my daily work on an IDE disk.
> I use automounter. On an attempt to mount it several processes
> got stuck in D state.
>
> kernel: 2.5.7 + new NTFS driver
> ps and ksymoopsed parts of Alt-Sysrq-T output are attached.
> ksymoops warnings trimmed except automount.dump.ksymoops
> (they were the same).

Forgot to add that it was a hdc. IDE led is constantly on,
any attempt to mount (even partitions from _hda_) are leading to
more "D" state processes (I already have: mount, cat and dd).
CPU load in low.

Box is alive thanks to fully NFS-based setup.

I decided to disconnect hdc from IDE and power connectors without
poweroff, and - whoa! - processes got unstuck. I must mention that
this disk seem to have intermittent problems with DMA
(a flaky/too long IDE cable I guess, DMA works flawlessly at home
with the same disk).

Maybe new IDE code is not timing out on DMA failure or something
like this? lspci says:
00:04.1 IDE interface: Intel Corp. 82371AB PIIX4 IDE (rev 01)

syslog around this event:
Apr 5 16:03:09 manta automount[2173]: do_mount /dev/hdc2 /.local/mnt/auto/hdc2/ type auto options noatime using module generic
Apr 5 16:03:09 manta automount[2173]: mount(generic): calling mkdir_path /.local/mnt/auto/hdc2/
Apr 5 16:03:09 manta automount[2173]: mount(generic): calling mount -t auto -s -o noatime /dev/hdc2 /.local/mnt/auto/hdc2/
Apr 5 16:03:09 manta kernel: EXT2-fs warning: maximal mount count reached, running e2fsck is recommended
Apr 5 16:03:09 manta automount[2173]: mount(generic): mounted /dev/hdc2 type auto on /.local/mnt/auto/hdc2/
Apr 5 16:03:34 manta automount[2180]: running expiration on path /.local/mnt/auto/hdc2
Apr 5 16:03:39 manta automount[1911]: attempting to mount entry /.local/mnt/auto/hdc2
Apr 5 16:03:39 manta automount[2182]: lookup(program): looking up hdc2
Apr 5 16:03:39 manta automount[2182]: lookup(program): hdc2 -> -fstype=auto,noatime :/dev/hdc2
Apr 5 16:03:39 manta automount[2182]: parse(sun): expanded entry: -fstype=auto,noatime :/dev/hdc2
Apr 5 16:03:39 manta automount[2182]: parse(sun): dequote("fstype=auto,noatime") -> fstype=auto,noatime
Apr 5 16:03:39 manta automount[2182]: parse(sun): gathered options: fstype=auto,noatime
Apr 5 16:03:39 manta automount[2182]: parse(sun): dequote("/dev/hdc2") -> /dev/hdc2
Apr 5 16:03:39 manta automount[2182]: parse(sun): core of entry: options=fstype=auto,noatime, loc=/dev/hdc2
Apr 5 16:03:39 manta automount[2182]: parse(sun): mounting root /.local/mnt/auto, mountpoint hdc2/, what /dev/hdc2, fstype auto, options noatime
Apr 5 16:03:39 manta automount[2182]: do_mount /dev/hdc2 /.local/mnt/auto/hdc2/ type auto options noatime using module generic
Apr 5 16:03:39 manta automount[2182]: mount(generic): calling mkdir_path /.local/mnt/auto/hdc2/
Apr 5 16:03:39 manta automount[2182]: mount(generic): calling mount -t auto -s -o noatime /dev/hdc2 /.local/mnt/auto/hdc2/
Apr 5 16:05:54 manta kernel: SysRq : Show State

[snip: read my 1st email to see ksymoopsed "D" state processes]

Apr 5 16:31:51 manta -- MARK --

[I disconnect hdc here]

Apr 5 16:32:26 manta kernel: hdc: dma_intr: status=0x7f { DriveReady DeviceFault SeekComplete DataRequest CorrectedError Index Error }
Apr 5 16:32:26 manta kernel: hdc: dma_intr: error=0x7f { DriveStatusError UncorrectableError SectorIdNotFound TrackZeroNotFound AddrMarkNotFound }, LBAsect=260013951, sector=229312
Apr 5 16:32:26 manta kernel: hdc: DMA disabled
Apr 5 16:32:26 manta kernel: ide1: reset: master: error (0x7f?)
Apr 5 16:32:26 manta kernel: hdc: status error: status=0x7f { DriveReady DeviceFault SeekComplete DataRequest CorrectedError Index Error }
Apr 5 16:32:26 manta kernel: hdc: status error: error=0x7f { DriveStatusError UncorrectableError SectorIdNotFound TrackZeroNotFound AddrMarkNotFound }, LBAsect=260013951, sector=229312
Apr 5 16:32:26 manta kernel: hdc: drive not ready for command
Apr 5 16:32:27 manta kernel: 255864
Apr 5 16:32:27 manta kernel: end_request: I/O error, dev 16:00, sector 255872
Apr 5 16:32:27 manta kernel: end_request: I/O error, dev 16:00, sector 255880
Apr 5 16:32:27 manta kernel: end_request: I/O error, dev 16:00, sector 255888
Apr 5 16:32:27 manta kernel: end_request: I/O error, dev 16:00, sector 255896
[snip]
Apr 5 16:32:27 manta kernel: end_request: I/O error, dev 16:00, sector 256024
Apr 5 16:32:27 manta kernel: end_request: I/O error, dev 16:00, sector 256032
Apr 5 16:32:27 manta kernel: end_request: I/O error, dev 16:00, sector 256040
Apr 5 16:32:27 manta kernel: end_request: I/O error, dev 16:00, sector 256048
Apr 5 16:32:27 manta automount[2182]: >> mount: wrong fs type, bad option, bad superblock on /dev/hdc2,
Apr 5 16:32:27 manta kernel: end_request: I/O error, dev 16:00, sector 256056
Apr 5 16:32:27 manta automount[2180]: expired /.local/mnt/auto/hdc2
Apr 5 16:32:27 manta automount[2182]: >> or too many mounted file systems
Apr 5 16:32:27 manta kernel: end_request: I/O error, dev 16:00, sector 256064
Apr 5 16:32:27 manta automount[2182]: mount(generic): failed to mount /dev/hdc2 (type auto) on /.local/mnt/auto/hdc2/
Apr 5 16:32:27 manta kernel: end_request: I/O error, dev 16:00, sector 256072
Apr 5 16:32:27 manta automount[1911]: attempting to mount entry /.local/mnt/auto/hdc2
Apr 5 16:32:27 manta kernel: end_request: I/O error, dev 16:00, sector 256080
Apr 5 16:32:27 manta automount[2363]: lookup(program): looking up hdc2
Apr 5 16:32:27 manta kernel: end_request: I/O error, dev 16:00, sector 256088
Apr 5 16:32:27 manta kernel: end_request: I/O error, dev 16:00, sector 256096
Apr 5 16:32:27 manta kernel: end_request: I/O error, dev 16:00, sector 256104
...

2002-04-09 09:03:51

by Denis Vlasenko

[permalink] [raw]
Subject: Re: [DEADLOCK] automount, kupdated: D state

On 5 April 2002 12:59, Anton Altaparmakov wrote:
> >kernel: 2.5.7 + new NTFS driver
> >ps and ksymoopsed parts of Alt-Sysrq-T output are attached.
> >ksymoops warnings trimmed except automount.dump.ksymoops
> >(they were the same).
>
> From looking at the information supplied, NTFS doesn't seem to be
> involved. The processes seem to be stuck trying to write dirty buffers as
> well as in nfs and pipefs - buffers could never get dirtied by the current
> NTFS as it is entirely read-only.

I don't think NTFS is related, I just wanted people to know what kernel I'm
using.

> btw. You had sent a problem report about cyrillic names with NTFS and I
> suggested to try the new NTFS driver but you never got back to me whether
> that fixed it or not... How is the new driver behaving? Are you stil seing
> problems or is everything working fine now?

I tried four times to post a reply to lkml, never seen my own posts.
This is becoming a problem, need to debug email route to lkml :-)

I needed storage badly and had to delete problematic files before
trying new NTFS driver, sorry. :-( Now I'm running 2.5.7 with new driver,
seems to work fine. Well done! I'll report anything unusual.

Are there any plans for RW support for NTFS?
--
vda