(was Re: [RFC] IDE 80-core cable detect - chipset-specific code to over-ride eighty_ninty_three())

(was Re: [RFC] IDE 80-core cable detect - chipset-specific code to over-ride eighty_ninty_three())

[Bartlomiej Zolnierkiewicz]

Hi,

word93 of drive identify is:

0x603b for IC35L120AVV207-0
0x3469 for QUANTUM FIREBALLlct20 30

and eighty_ninty_three() checks for bit 0x4000, so...

Willy, it seems you are hitting some other problem.
Have you already tried booting with "ide0=ata66"?

Athol, does this patch solves your problem?

[PATCH] add 80-wires cable detection quirk for QUANTUM FIREBALLlct20 30

 linux-2.6.3-rc2-root/drivers/ide/ide-iops.c |   30 ++++++++++++++--------------
 1 files changed, 16 insertions(+), 14 deletions(-)

diff -puN drivers/ide/ide-iops.c~ide_quantum_ivb_fix drivers/ide/ide-iops.c
--- linux-2.6.3-rc2/drivers/ide/ide-iops.c~ide_quantum_ivb_fix	2004-02-12 19:53:14.480791880 +0100
+++ linux-2.6.3-rc2-root/drivers/ide/ide-iops.c	2004-02-12 20:00:32.562193384 +0100
@@ -618,10 +618,14 @@ EXPORT_SYMBOL(ide_wait_stat);
  */
 u8 eighty_ninty_three (ide_drive_t *drive)
 {
-#if 0
+	struct hd_driveid *id = drive->id;
+#ifndef CONFIG_IDEDMA_IVB
+	unsigned int ivb = 0;
+#endif
+
 	if (!HWIF(drive)->udma_four)
 		return 0;
-
+#if 0
 	if (drive->id->major_rev_num) {
 		int hssbd = 0;
 		int i;
@@ -641,21 +645,19 @@ u8 eighty_ninty_three (ide_drive_t *driv
 				return 0;
 		}
 	}
-
-	return ((u8) (
+#endif
 #ifndef CONFIG_IDEDMA_IVB
-		(drive->id->hw_config & 0x4000) &&
-#endif /* CONFIG_IDEDMA_IVB */
-		 (drive->id->hw_config & 0x6000)) ? 1 : 0);
-
+	/* We can convert this to ivb_drives list if necessary. */
+	if (!strcmp("QUANTUM FIREBALLlct20 30", id->model) &&
+	    !strcmp("APL.0900", id->fw_rev))
+		ivb = 1;
+	if ((id->hw_config & 0x4000) || (ivb && (id->hw_config & 0x2000)))
+		return 1;
 #else
-
-	return ((u8) ((HWIF(drive)->udma_four) &&
-#ifndef CONFIG_IDEDMA_IVB
-			(drive->id->hw_config & 0x4000) &&
-#endif /* CONFIG_IDEDMA_IVB */
-			(drive->id->hw_config & 0x6000)) ? 1 : 0);
+	if (id->hw_config & 0x6000)
+		return 1;
 #endif
+	return 0;
 }
 
 EXPORT_SYMBOL(eighty_ninty_three);

_

Re: (was Re: [RFC] IDE 80-core cable detect - chipset-specific code to over-ride eighty_ninty_three())

[Miquel van Smoorenburg]

In article <200402122106.41947.bzolnier@elka.pw.edu.pl>,
Bartlomiej Zolnierkiewicz  <B.Zolnierkiewicz@elka.pw.edu.pl> wrote:
>
>Hi,
>
>word93 of drive identify is:
>
>0x603b for IC35L120AVV207-0
>0x3469 for QUANTUM FIREBALLlct20 30
>
>and eighty_ninty_three() checks for bit 0x4000, so...
>
>Willy, it seems you are hitting some other problem.
>Have you already tried booting with "ide0=ata66"?

That reminds me, there is currenly no way to boot with
ide0=ata33, right ?

I have a tyan motherboard with a serverworks chipset, and the
(2.5" system-) disk is connected with a 40 pins cable. However
the serverworks chipset doesn't detect this, and tries to run
it in UDMA<lots> mode. That results in lots of nasty messages
before it falls back to UDMA33 mode.

Could you put a way to force it into UDMA33 (UDMA2) mode on the
wishlist, please ?

Mike.

Re: (was Re: [RFC] IDE 80-core cable detect - chipset-specific code to over-ride eighty_ninty_three())

[Willy Tarreau]

Hi Bart,

On Thu, Feb 12, 2004 at 09:06:41PM +0100, Bartlomiej Zolnierkiewicz wrote:
> Willy, it seems you are hitting some other problem.
> Have you already tried booting with "ide0=ata66"?

Sorry, I think I mangled it like "hda=ata66" or "ide0=udma66" instead when I
tried. I just rechecked with "ide0=ata66", and I confirm that it works (it
uses UDMA100). BTW, wouldn't it be more appropriate to use something such as
"udma4" or "80pin" or something else which would be more intuitive than
"ata66" ?

Thanks for your help and particularly for your quick response, Bart.
Willy

Re: (was Re: [RFC] IDE 80-core cable detect - chipset-specific code to over-ride eighty_ninty_three())

[Bartlomiej Zolnierkiewicz]

On Friday 13 of February 2004 09:37, Willy Tarreau wrote:
> Hi Bart,
>
> On Thu, Feb 12, 2004 at 09:06:41PM +0100, Bartlomiej Zolnierkiewicz wrote:
> > Willy, it seems you are hitting some other problem.
> > Have you already tried booting with "ide0=ata66"?
>
> Sorry, I think I mangled it like "hda=ata66" or "ide0=udma66" instead when
> I tried. I just rechecked with "ide0=ata66", and I confirm that it works

Great, but I wonder why cable bits are set incorrectly.
Probably it's a BIOS bug, maybe BIOS update will help?

> (it uses UDMA100). BTW, wouldn't it be more appropriate to use something
> such as "udma4" or "80pin" or something else which would be more intuitive
> than "ata66" ?

It is "ata66" because of compatibility :/.

Cheers,
--bart

Re: (was Re: [RFC] IDE 80-core cable detect - chipset-specific code to over-ride eighty_ninty_three())

[Bartlomiej Zolnierkiewicz]

On Thursday 12 of February 2004 21:41, Miquel van Smoorenburg wrote:
> In article <200402122106.41947.bzolnier@elka.pw.edu.pl>,
>
> Bartlomiej Zolnierkiewicz  <B.Zolnierkiewicz@elka.pw.edu.pl> wrote:
> >Hi,
> >
> >word93 of drive identify is:
> >
> >0x603b for IC35L120AVV207-0
> >0x3469 for QUANTUM FIREBALLlct20 30
> >
> >and eighty_ninty_three() checks for bit 0x4000, so...
> >
> >Willy, it seems you are hitting some other problem.
> >Have you already tried booting with "ide0=ata66"?
>
> That reminds me, there is currenly no way to boot with
> ide0=ata33, right ?

Right.

> I have a tyan motherboard with a serverworks chipset, and the
> (2.5" system-) disk is connected with a 40 pins cable. However
> the serverworks chipset doesn't detect this, and tries to run
> it in UDMA<lots> mode. That results in lots of nasty messages
> before it falls back to UDMA33 mode.

It sounds like driver or BIOS bug.  Can I get dmesg from this system?

> Could you put a way to force it into UDMA33 (UDMA2) mode on the
> wishlist, please ?

Yep.

Re: (was Re: [RFC] IDE 80-core cable detect - chipset-specific code to over-ride eighty_ninty_three())

[Erik Mouw]

On Fri, Feb 13, 2004 at 06:23:53PM +0100, Bartlomiej Zolnierkiewicz wrote:
> Great, but I wonder why cable bits are set incorrectly.
> Probably it's a BIOS bug, maybe BIOS update will help?

I think there is something wrong in the cable detection code. I've
tried chasing the bug a couple of weeks ago, but got distracted by
other work. On an AMD-768 based motherboard disks run in UDMA5 without
problem using linux-2.4.20, but on 2.4.24 (or anything with the new IDE
code), I can't get any further than UDMA2. At first glance it looks
like the 80-pin bits in the chipset registers aren't set. When I
manually force them, the driver has no problem running the disks in
UDMA5.

So far I've seen this behaviour with the following chipset:

  Bus  0, device   7, function  1:
    IDE interface: Advanced Micro Devices [AMD] AMD-768 [Opus] IDE (rev 4).
      Master Capable.  Latency=32.  
      I/O at 0xd800 [0xd80f].

But rumours are that even on Intel ICH2 it goes wrong (haven't
confirmed this myself).

FWIW, I'm using modular IDE, I still have to test it with IDE built
into the kernel.


Erik

-- 
+-- Erik Mouw -- www.harddisk-recovery.nl -- 0800 220 20 20 --
| Eigen lab: Delftechpark 26, 2628 XH, Delft, Nederland
| Files foetsie, bestanden kwijt, alle data weg?!
| Blijf kalm en neem contact op met Harddisk-recovery.nl!

Re: (was Re: [RFC] IDE 80-core cable detect - chipset-specific code to over-ride eighty_ninty_three())

[Bartlomiej Zolnierkiewicz]

On Friday 13 of February 2004 18:44, Erik Mouw wrote:
> On Fri, Feb 13, 2004 at 06:23:53PM +0100, Bartlomiej Zolnierkiewicz wrote:
> > Great, but I wonder why cable bits are set incorrectly.
> > Probably it's a BIOS bug, maybe BIOS update will help?
>
> I think there is something wrong in the cable detection code. I've
> tried chasing the bug a couple of weeks ago, but got distracted by
> other work. On an AMD-768 based motherboard disks run in UDMA5 without
> problem using linux-2.4.20, but on 2.4.24 (or anything with the new IDE
> code), I can't get any further than UDMA2. At first glance it looks
> like the 80-pin bits in the chipset registers aren't set. When I
> manually force them, the driver has no problem running the disks in
> UDMA5.
>
> So far I've seen this behaviour with the following chipset:
>
>   Bus  0, device   7, function  1:
>     IDE interface: Advanced Micro Devices [AMD] AMD-768 [Opus] IDE (rev 4).
>       Master Capable.  Latency=32.
>       I/O at 0xd800 [0xd80f].

It might be also chipset specific bug:
2.4.20 - amd74xx.c driver by Andre Hedrick
2.4.21-2.4.24 - new amd74xx.c driver by Vojtech Pavlik

Please try narrow it down.

> But rumours are that even on Intel ICH2 it goes wrong (haven't
> confirmed this myself).

This tells us nothing about the problem.

Re: (was Re: [RFC] IDE 80-core cable detect - chipset-specific code to over-ride eighty_ninty_three())

[Athol Mullen]

Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl> wrote:

> Athol, does this patch solves your problem?

> [PATCH] add 80-wires cable detection quirk for QUANTUM FIREBALLlct20 30

My apologies for the delay.  Paid work gets in the way sometimes...

I haven't had a chance to test the patch yet, but have confirmed that it is 
definately a drive-related problem.  I put it on my ICH4 as slave to another 
drive that passes the validation bit, then put the Quantum back on the ICH5 
and put the other drive in as slave.  The other drive always passes the 
validation bit and the Quantum always fails.

Another suggestion would be to make a kernel parameter such as ide0=ivb or 
hda=ivb to force ignoring the validation bit...  That way, we don't need a 
list of drive models hardcoded into the kernel.

I'll test the patch ASAP.

-- 
Athol
<http://cust.idl.com.au/athol>
Linux Registered User # 254000
I'm a Libran Engineer. I don't argue, I discuss.