mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl>
To: Mark Haverkamp <markh@osdl.org>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
	Cliff White <cliffw@osdl.org>
Subject: Re: ide taskfile and cdrom hang
Date: Mon, 2 Feb 2004 20:45:02 +0100	[thread overview]
Message-ID: <200402022045.02346.bzolnier@elka.pw.edu.pl> (raw)
In-Reply-To: <1075747608.8503.198.camel@markh1.pdx.osdl.net>

On Monday 02 of February 2004 19:46, Mark Haverkamp wrote:
> On Sun, 2004-02-01 at 12:48, Bartlomiej Zolnierkiewicz wrote:
> > Hi,
> >
> > On Friday 30 of January 2004 23:36, Mark Haverkamp wrote:
> > > We have some test machines here at OSDL that have a problem with the
> > > ide cdrom driver hanging when we cat the /proc/ide/hda/identify file.
> > > After 30 seconds the console displays: "hda: lost interrupt" which
> > > reoccurs every 30 seconds forever. We noticed it on 2.6.2-rc2-mm1 but
> > > It looks like this has been a problem for a while. Our test machines
> > > just changed their configuration to use make defconfig.  I found that
> > > if
> > > CONFIG_IDE_TASKFILE_IO is N then the hang doesn't occur.  Is this a
> > > common problem or are there just certain drives that won't work with
> > > taskfile i/o enabled?  I've included my .config, lspci as attachments.
> > > The cdrom model is CD-224E.
> >
> > Does 'hdparm -I /dev/hda" work?  If so can you try this patch?
> > It reverts taskfile code to use old (non-taskfile) order of accessing
> > port registers for ATAPI identify command.  This is a good starting
> > point.
> >
> > If CONFIG_IDE_TASKFILE_IO is N code just ignores BUSY status of a drive
> > and reads some random data.  I would like to have this problem solved
> > at least instead of adding the same workaround to CONFIG_IDE_TASKFILE_IO.
> >
> > Cheers,
> > --bart
>
> Thanks,
>
> hdparm -I /dev/hda didn't hang.  I got this on the console:
>
> hda: drive_cmd: status=0x51 { DriveReady SeekComplete Error }
> hda: drive_cmd: error=0x04Aborted Command

That's okay.
hdparm first tries WIN_IDENTIFY which can fail on ATAPI devices.

> I added the patch that you provided and I still get the hang when I cat
> /proc/ide/hda/identify.  I put a printk In the code to make sure that it
> was going through the added code, and it is.

So it is something different.  Can you give this patch a go?
We will know more about what's going on.

Thanks,
--bart

 linux-2.6.2-rc2-root/drivers/ide/ide-taskfile.c |    3 +++
 1 files changed, 3 insertions(+)

diff -puN drivers/ide/ide-taskfile.c~ide_tf_identify_debug1 drivers/ide/ide-taskfile.c
--- linux-2.6.2-rc2/drivers/ide/ide-taskfile.c~ide_tf_identify_debug1	2004-02-02 20:30:16.435636072 +0100
+++ linux-2.6.2-rc2-root/drivers/ide/ide-taskfile.c	2004-02-02 20:40:25.604028400 +0100
@@ -794,6 +794,7 @@ static u8 wait_drive_not_busy(ide_drive_
 	 */
 	while (((stat = hwif->INB(IDE_STATUS_REG)) & BUSY_STAT) && retries--)
 		udelay(10);
+	printk("%s: (WAIT_NOT_BUSY) status=0x%02x\n", drive->name, stat);
 	return stat;
 }
 
@@ -811,6 +812,7 @@ check_status:
 	if (!OK_STAT(stat, good_stat, BAD_R_STAT)) {
 		if (stat & (ERR_STAT | DRQ_STAT))
 			return DRIVER(drive)->error(drive, __FUNCTION__, stat);
+		printk("%s: (BUSY) status=0x%02x\n", drive->name, stat);
 		/* BUSY_STAT: No data yet, so wait for another IRQ. */
 		ide_set_handler(drive, &task_in_intr, WAIT_WORSTCASE, NULL);
 		return ide_started;
@@ -836,6 +838,7 @@ check_status:
 	if (!rq->nr_sectors) {
 		good_stat = 0;
 		stat = wait_drive_not_busy(drive);
+		printk("%s: (CHECK_STATUS) status=0x%02x\n", drive->name, stat);
 		goto check_status;
 	}
 

_


  reply	other threads:[~2004-02-02 19:40 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-30 22:36 Mark Haverkamp
2004-02-01 20:48 ` Bartlomiej Zolnierkiewicz
2004-02-02 18:46   ` Mark Haverkamp
2004-02-02 19:45     ` Bartlomiej Zolnierkiewicz [this message]
2004-02-02 20:45       ` Mark Haverkamp
2004-02-02 21:35         ` Bartlomiej Zolnierkiewicz
2004-02-02 21:44           ` Mark Haverkamp
2004-02-02 23:37             ` Bartlomiej Zolnierkiewicz
2004-02-02 23:52               ` Mark Haverkamp
2004-02-03  0:13                 ` Bartlomiej Zolnierkiewicz
2004-02-03  0:16                   ` Mark Haverkamp
2004-02-03  1:09                     ` Bartlomiej Zolnierkiewicz
     [not found] <1075502193.26342.61.camel@markh1.pdx.osdl.net.suse.lists.linux.kernel>
2004-01-31  0:46 ` Andi Kleen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200402022045.02346.bzolnier@elka.pw.edu.pl \
    --to=b.zolnierkiewicz@elka.pw.edu.pl \
    --cc=cliffw@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=markh@osdl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®