Re: Hang during rm on ext2 mounted sync (2.6.14-rc2+)

[Chris Sykes <chris@sigsegv.plus.com>]

[-- Attachment #1.1: Type: text/plain, Size: 3127 bytes --]

On Fri, Sep 23, 2005 at 01:19:32PM +0100, Chris Sykes wrote:
> > Suggest you generate the `dmesg -s 1000000' output for both good and bad
> > kernels, do a `diff -u' on them and look for IDE complaints (or SCSI, if
> > you're on SCSI).

OK booted and tested 2.6.13-git9 and 2.6.13-git10 in single user mode.

2.6.13-git9 survived 10000 iterations of my test script without a
hiccup.
2.6.13-git10 got stuck on the first one.

The only ide related errors are in the dmesg output for 2.6.13-git9
(good kernel), and related to hdc.  The ext2 image I've been using is
on /dev/sda2 (SATA), and my ext2 boot partition on which I first saw this
behaviour is on /dev/hda1.

Having said that something does feel funny about the IDE on this PC
ATM.  I've just booted into 2.6.13.2, and get no hdc error messages in
the logs.  Yet, when I loopback mount the ext2 image file on sda2,
the following is spewed:

loop: loaded (max 8 devices)
hdc: status error: status=0x59 { DriveReady SeekComplete DataRequest
Error }
hdc: status error: error=0x54 { AbortedCommand LastFailedSense=0x05 }
ide: failed opcode was: unknown
hdc: drive not ready for command
hdc: set_drive_speed_status: status=0x59 { DriveReady SeekComplete
DataRequest Error }
hdc: set_drive_speed_status: error=0xd0 { LastFailedSense=0x0d }
ide: failed opcode was: unknown
hdc: status error: status=0x59 { DriveReady SeekComplete DataRequest
Error }
hdc: status error: error=0x24 { AbortedCommand LastFailedSense=0x02 }
ide: failed opcode was: unknown
hdc: drive not ready for command
hdc: set_drive_speed_status: status=0x59 { DriveReady SeekComplete
DataRequest Error }
hdc: set_drive_speed_status: error=0xd0 { LastFailedSense=0x0d }
ide: failed opcode was: unknown

I've got the following mounted:

/dev/hda2 on / type ext3 (rw,noatime,errors=remount-ro)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
tmpfs on /dev/shm type tmpfs (rw)
usbfs on /proc/bus/usb type usbfs (rw)
/dev/hda1 on /boot type ext2 (rw,noatime)
/dev/sda2 on /home type ext3 (rw,noatime)
/dev/hda5 on /srv/media type ext3 (rw,noatime)
/dev on /.dev type unknown (rw,bind)
none on /dev type tmpfs (rw,size=5M,mode=0755)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
/home/csykes/tmp/1stext2 on /mnt type ext2 (rw,sync,loop=/dev/loop/0)

I assume that is was the access to /dev/hda2 (my root partition) to
load 'loop' that prompted the hdc errors, but a subsequent
'find / -xdev' doesn't produce any more errors.

I've attached the dmesg output from 2.6.13-git9 and 2.6.13-git10, also
the full output from sysrq-t and lsmod.

I'll try to track down the changeset between 2.6.13-git9 and
2.6.13-git10 that causes this for me, but I have to get on with other
work this afternoon so it won't be until this evening.

Kind regards,

-- 

(o-  Chris Sykes
//\       "Don't worry. Everything is getting nicely out of control ..."
V_/_                          Douglas Adams - The Salmon of Doubt
GPG Fingerprint: 5E8E D17F F96C CC08 911D  CAF2 9049 70D8 5143 8090

[-- Attachment #1.2: dmesg-2.6.13-git10.gz --]
[-- Type: application/octet-stream, Size: 7794 bytes --]

[-- Attachment #1.3: dmesg-2.6.13-git9.gz --]
[-- Type: application/octet-stream, Size: 8025 bytes --]

[-- Attachment #1.4: lsmod.out.gz --]
[-- Type: application/octet-stream, Size: 689 bytes --]

[-- Attachment #1.5: new_trace.gz --]
[-- Type: application/octet-stream, Size: 9453 bytes --]

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]