All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tejun Heo <htejun@gmail.com>
To: Alan <alan@lxorguk.ukuu.org.uk>
Cc: Art Haas <ahaas@airmail.net>, linux-ide@vger.kernel.org
Subject: Re: CDROM drive not found when booting using new libata code
Date: Thu, 07 Dec 2006 21:37:09 +0900	[thread overview]
Message-ID: <45780AF5.2020605@gmail.com> (raw)
In-Reply-To: <20061207105525.4ebb4547@localhost.localdomain>

[-- Attachment #1: Type: text/plain, Size: 1574 bytes --]

Alan wrote:
> On Thu, 07 Dec 2006 13:28:02 +0900
> Tejun Heo <htejun@gmail.com> wrote:
> 
>> Please test the attached patch.
> 
> That should be getting done automatically by the driver and used to work
> with the old eh/probe code. It does rely on having done the initial PIO0
> identify of both devices and the mode decision being made before mode
> setting functions are called however, and that is/was documented as a
> guarantee, and is relied upon all over.

I broke it in the following commit while implementing per-dev xfermode.
 I have no idea what I was thinking.  :-(

commit 37deecb5139ee431233781a9a093d9fcaab54c5b
[PATCH] libata: implement per-dev xfermask

> Definitely worth testing Art, especially if it shows something up.

Art, I attached the wrong patch and it won't apply to vanilla 2.6.19.
Patch against 2.6.19 is attached here.  Please test this one.

> Tejun: pata_amd does the timing merges itself both for 8bit which is
> shared and in the timing compute for the DMA cases. Also the other
> pattern to these reports is ATAPI, although that might I guess be a
> symptom of "slave". 

Yeap, I noticed the ATAPI devices and also that in many reports those
devices are pretty old ones which support only upto MWDMA modes.  My
suspicion was that people are pairing a slower ODD with a newer HDD on
the same channel and seeing this problem.

> The other problem is that mmio bus reset is broken, but the AMD always
> uses PIO cycles so that shouldn't be involved.
> 
> Alan (still baffled by this one)

Let's see if this patch fixes anything.

-- 
tejun

[-- Attachment #2: patch --]
[-- Type: text/plain, Size: 1298 bytes --]

diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 915a55a..b54ca36 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -3109,6 +3109,7 @@ static void ata_dev_xfermask(struct ata_device *dev)
 	struct ata_port *ap = dev->ap;
 	struct ata_host *host = ap->host;
 	unsigned long xfer_mask;
+	int i;
 
 	/* controller modes available */
 	xfer_mask = ata_pack_xfermask(ap->pio_mask,
@@ -3120,10 +3121,27 @@ static void ata_dev_xfermask(struct ata_device *dev)
 	if (ap->cbl == ATA_CBL_PATA40)
 		xfer_mask &= ~(0xF8 << ATA_SHIFT_UDMA);
 
+	/* apply xfermask limits of this device */
 	xfer_mask &= ata_pack_xfermask(dev->pio_mask,
 				       dev->mwdma_mask, dev->udma_mask);
 	xfer_mask &= ata_id_xfermask(dev->id);
 
+	/* PIO xfermask limits are shared by all devices on the same
+	 * channel to avoid violating device selection timing.
+	 */
+	for (i = 0; i < ATA_MAX_DEVICES; i++) {
+		struct ata_device *d = &ap->device[i];
+		unsigned int pio_mask;
+
+		if (ata_dev_absent(d))
+			continue;
+
+		ata_unpack_xfermask(ata_id_xfermask(d->id),
+				    &pio_mask, NULL, NULL);
+		pio_mask &= d->pio_mask;
+		xfer_mask &= ata_pack_xfermask(pio_mask, UINT_MAX, UINT_MAX);
+	}
+
 	/*
 	 *	CFA Advanced TrueIDE timings are not allowed on a shared
 	 *	cable

  reply	other threads:[~2006-12-07 12:37 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-24 22:10 CDROM drive not found when booting using new libata code Art Haas
2006-11-21  9:26 ` Tejun Heo
2006-12-06 18:16   ` Art Haas
2006-12-07  4:28     ` Tejun Heo
2006-12-07 10:55       ` Alan
2006-12-07 12:37         ` Tejun Heo [this message]
2006-12-08  1:06           ` Art Haas
2006-12-27 13:29             ` Tejun Heo
2006-12-28  3:51               ` Tejun Heo
2007-01-02 21:07                 ` Art Haas
2007-01-03  3:31                   ` Tejun Heo
2007-01-03 18:08                     ` Art Haas
2007-01-03 23:19                       ` Dâniel Fraga
  -- strict thread matches above, loose matches on Subject: below --
2007-03-14 19:33 YUP
2007-03-14 19:59 YUP

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=45780AF5.2020605@gmail.com \
    --to=htejun@gmail.com \
    --cc=ahaas@airmail.net \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=linux-ide@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.