Linux 2.6.6 "IDE cache-flush at shutdown fixes"

Linux 2.6.6 "IDE cache-flush at shutdown fixes"

[Rene Herman]

Good day.

The 2.6.6-rc3 -> 2.6.6-final changes to ide-disk.c unfortunately make my 
machine complain loudly both at boot and reboot:

Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
AMD7409: IDE controller at PCI slot 0000:00:07.1
AMD7409: chipset revision 7
AMD7409: not 100% native mode: will probe irqs later
AMD7409: 0000:00:07.1 (rev 07) UDMA66 controller
     ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:pio
     ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:DMA, hdd:pio
hda: Maxtor 6Y120P0, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hdc: PLEXTOR DVD-ROM PX-116A, ATAPI CD/DVD-ROM drive
ide1 at 0x170-0x177,0x376 on irq 15
hda: max request size: 128KiB
hda: 240121728 sectors (122942 MB) w/7936KiB Cache, CHS=65535/16/63, 
UDMA(66)
  hda: hda1 < hda5 hda6 hda7 hda8 hda9 hda10 hda11 hda12 hda13 > hda2 
hda3 hda4
  hda2: <bsd: hda14 hda15 hda16 hda17 hda18 >
  hda4: <minix: hda19 hda20 >
hda: task_no_data_intr: status=0x51 { DriveReady SeekComplete Error }
hda: task_no_data_intr: error=0x04 { DriveStatusError }
hda: Write Cache FAILED Flushing!

The disk, 6Y120P0, is a new-ish Maxtor "DiamondMax Plus 9", 120G, 8M 
cache. Controller is an AMD756. Same complaints on reboot. Reverting the 
rc3->final changes to ide-disk.c fixes/supresses them again.

Rene.

Re: Linux 2.6.6 "IDE cache-flush at shutdown fixes"

[Gene Heskett]

On Monday 10 May 2004 05:20, Rene Herman wrote:
>Good day.
>
>The 2.6.6-rc3 -> 2.6.6-final changes to ide-disk.c unfortunately
> make my machine complain loudly both at boot and reboot:
>
>Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
>ide: Assuming 33MHz system bus speed for PIO modes; override with
> idebus=xx AMD7409: IDE controller at PCI slot 0000:00:07.1
>AMD7409: chipset revision 7
>AMD7409: not 100% native mode: will probe irqs later
>AMD7409: 0000:00:07.1 (rev 07) UDMA66 controller
>     ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:pio
>     ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:DMA, hdd:pio
>hda: Maxtor 6Y120P0, ATA DISK drive
>ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
>hdc: PLEXTOR DVD-ROM PX-116A, ATAPI CD/DVD-ROM drive
>ide1 at 0x170-0x177,0x376 on irq 15
>hda: max request size: 128KiB
>hda: 240121728 sectors (122942 MB) w/7936KiB Cache, CHS=65535/16/63,
>UDMA(66)
>  hda: hda1 < hda5 hda6 hda7 hda8 hda9 hda10 hda11 hda12 hda13 >
> hda2 hda3 hda4
>  hda2: <bsd: hda14 hda15 hda16 hda17 hda18 >
>  hda4: <minix: hda19 hda20 >
>hda: task_no_data_intr: status=0x51 { DriveReady SeekComplete Error
> } hda: task_no_data_intr: error=0x04 { DriveStatusError }
>hda: Write Cache FAILED Flushing!
>
I have this too:
Linux version 2.6.6 (root@coyote.coyote.den) (gcc version 3.3.2 
20031022 (Red Hat Linux 3.3.2-1)) #1 Mon May 10 02:20:54 EDT 2004
[...]
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with 
idebus=xx
VP_IDE: IDE controller at PCI slot 0000:00:11.1
VP_IDE: chipset revision 6
VP_IDE: not 100% native mode: will probe irqs later
VP_IDE: VIA vt8233 (rev 00) IDE UDMA100 controller on pci0000:00:11.1
    ide0: BM-DMA at 0xd800-0xd807, BIOS settings: hda:DMA, hdb:DMA
[...]
hda: Maxtor 6Y120P0, ATA DISK drive
[...]
hda: max request size: 128KiB
hda: 240121728 sectors (122942 MB) w/7936KiB Cache, CHS=65535/16/63, 
UDMA(100)
 hda: hda1 hda2 hda3 hda4 < hda5 hda6 hda7 hda8 >
hda: task_no_data_intr: status=0x51 { DriveReady SeekComplete Error }
hda: task_no_data_intr: error=0x04 { DriveStatusError }
hda: Write Cache FAILED Flushing!

>The disk, 6Y120P0, is a new-ish Maxtor "DiamondMax Plus 9", 120G, 8M
>cache. Controller is an AMD756. Same complaints on reboot. Reverting
> the rc3->final changes to ide-disk.c fixes/supresses them again.
>
>Rene.

I note the drive is the same model here too, Rene.

The question remains however, is our data in danger?

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.22% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2004 by Maurice Eugene Heskett, all rights reserved.

Re: Linux 2.6.6 "IDE cache-flush at shutdown fixes"

[Rene Herman]

Gene Heskett wrote:

>> hda: Maxtor 6Y120P0, ATA DISK drive

> I note the drive is the same model here too, Rene.
> 
> The question remains however, is our data in danger?

There's a fair change that we'll be told, yes, very much so, since these 
drives don't seem to correctly support this life saving feature. The 
real answer though will be more easily deducted by calculating the ratio 
of unexplained file system corruptions you've had and reboots you've 
managed (0, that is).

Rene.

Re: Linux 2.6.6 "IDE cache-flush at shutdown fixes"

[Arjan van de Ven]

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


> I note the drive is the same model here too, Rene.
> 
> The question remains however, is our data in danger?

You have a disk with an active write back cache but that doesn't support
the flush-cache IDE command. That's obviously a bad combo ;)
The other fixes in 2.6.6 ought to make it a bit less dangerous than
before, eg the power off at shutdown WILL flush the cache.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Linux 2.6.6 "IDE cache-flush at shutdown fixes"

[Bartlomiej Zolnierkiewicz]

Hi,

Rene, can you test these (incremental) patches?

[PATCH] set drive->wcache only on the first ->open() call

--- linux/drivers/ide/ide-disk.c.orig   2004-05-07 15:05:46.000000000 +0200
+++ linux/drivers/ide/ide-disk.c        2004-05-07 18:30:09.544793448 +0200
@@ -1758,6 +1758,8 @@
                if (drive->doorlocking && ide_raw_taskfile(drive, &args, NULL))
                        drive->doorlocking = 0;
        }
+       if (drive->usage != 1)
+               return 0;
        drive->wcache = 0;
        /* Cache enabled? */
        if (drive->id->csfo & 1)


Patch below reverts handling of flush cache to be _exactly_ the same
as in 2.4 (no unknown commands on ->suspend() and ->shutdown()).

[PATCH] ide: don't send cacheflush to drives that don't understand it #2

--- linux/drivers/ide/ide-disk.c.orig 2004-05-07 18:30:09.000000000 +0200
+++ linux/drivers/ide/ide-disk.c        2004-05-07 18:34:18.766905928 +0200
@@ -1758,7 +1758,7 @@
                if (drive->doorlocking && ide_raw_taskfile(drive, &args, NULL))
                        drive->doorlocking = 0;
        }
-       if (drive->usage != 1)
+       if (drive->usage != 1 || !drive->removable)
                return 0;
        drive->wcache = 0;
        /* Cache enabled? */

On Monday 10 of May 2004 11:20, Rene Herman wrote:
> Good day.
>
> The 2.6.6-rc3 -> 2.6.6-final changes to ide-disk.c unfortunately make my
> machine complain loudly both at boot and reboot:

These warnings are _harmless_.

Your drives have write cache support
but don't understand flush cache commands.

> Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
> ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
> AMD7409: IDE controller at PCI slot 0000:00:07.1
> AMD7409: chipset revision 7
> AMD7409: not 100% native mode: will probe irqs later
> AMD7409: 0000:00:07.1 (rev 07) UDMA66 controller
>      ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:pio
>      ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:DMA, hdd:pio
> hda: Maxtor 6Y120P0, ATA DISK drive
> ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
> hdc: PLEXTOR DVD-ROM PX-116A, ATAPI CD/DVD-ROM drive
> ide1 at 0x170-0x177,0x376 on irq 15
> hda: max request size: 128KiB
> hda: 240121728 sectors (122942 MB) w/7936KiB Cache, CHS=65535/16/63,
> UDMA(66)
>   hda: hda1 < hda5 hda6 hda7 hda8 hda9 hda10 hda11 hda12 hda13 > hda2
> hda3 hda4
>   hda2: <bsd: hda14 hda15 hda16 hda17 hda18 >
>   hda4: <minix: hda19 hda20 >
> hda: task_no_data_intr: status=0x51 { DriveReady SeekComplete Error }
> hda: task_no_data_intr: error=0x04 { DriveStatusError }
> hda: Write Cache FAILED Flushing!
>
> The disk, 6Y120P0, is a new-ish Maxtor "DiamondMax Plus 9", 120G, 8M
> cache. Controller is an AMD756. Same complaints on reboot. Reverting the
> rc3->final changes to ide-disk.c fixes/supresses them again.
>
> Rene.

Re: Linux 2.6.6 "IDE cache-flush at shutdown fixes"

[Rene Herman]

Bartlomiej Zolnierkiewicz wrote:

> Rene, can you test these (incremental) patches?

> +       if (drive->usage != 1)
> +               return 0;

Only this one does not make a change.

> -       if (drive->usage != 1)
> +       if (drive->usage != 1 || !drive->removable)

With this one, the cache flushing noise is no more, but still a problem 
unfortunately. With or without these patches, 2.6.6 powers down the 
drive during reboot. This is very annoying, seeing as how it immediately 
needs to spin up again for POST.

Thanks for now!

Rene.

Re: Linux 2.6.6 "IDE cache-flush at shutdown fixes"

[Bartlomiej Zolnierkiewicz]

On Monday 10 of May 2004 23:13, you wrote:
> Bartlomiej Zolnierkiewicz wrote:
> > Rene, can you test these (incremental) patches?
> >
> > +       if (drive->usage != 1)
> > +               return 0;
>
> Only this one does not make a change.
>
> > -       if (drive->usage != 1)
> > +       if (drive->usage != 1 || !drive->removable)

Thanks.

Rene, can you send me copies of /proc/ide/hda/identify and
/proc/ide/hdc/identify?  I still would like to know why these
drives don't accept flush cache commands (or it is a driver's bug?).

> With this one, the cache flushing noise is no more, but still a problem
> unfortunately. With or without these patches, 2.6.6 powers down the
> drive during reboot. This is very annoying, seeing as how it immediately
> needs to spin up again for POST.

There is a problem with new 2.6 generic ->shutdown framework,
it doesn't differentiate between reboot / halt and power_off.
We may try to fix it or revert to 2.4 way of doing things if
this is too big change for 2.6.

Thanks,
Bartlomiej

Re: Linux 2.6.6 "IDE cache-flush at shutdown fixes"

[Andrew Morton]

Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl> wrote:
>
> There is a problem with new 2.6 generic ->shutdown framework,
>  it doesn't differentiate between reboot / halt and power_off.
>  We may try to fix it or revert to 2.4 way of doing things if
>  this is too big change for 2.6.

It's a bit grubby, but we could easily add a fourth state to
`system_state': split SYSTEM_SHUTDOWN into SYSTEM_REBOOT and SYSTEM_HALT. 
That would be a quite simple change.

Re: Linux 2.6.6 "IDE cache-flush at shutdown fixes"

[Andrew Morton]

Andrew Morton <akpm@osdl.org> wrote:
>
> It's a bit grubby, but we could easily add a fourth state to
>  `system_state': split SYSTEM_SHUTDOWN into SYSTEM_REBOOT and SYSTEM_HALT. 
>  That would be a quite simple change.

Like this.  I checked all the SYSTEM_FOO users and none of them seem to
care about the shutdown state at present.  Easy.



 25-akpm/include/linux/kernel.h |   11 +++++++----
 25-akpm/init/main.c            |    3 ++-
 25-akpm/kernel/sys.c           |    8 ++++----
 3 files changed, 13 insertions(+), 9 deletions(-)

diff -puN include/linux/kernel.h~system-state-splitup include/linux/kernel.h
--- 25/include/linux/kernel.h~system-state-splitup	2004-05-10 22:05:15.127191856 -0700
+++ 25-akpm/include/linux/kernel.h	2004-05-10 22:05:15.133190944 -0700
@@ -109,14 +109,17 @@ static inline void console_verbose(void)
 extern void bust_spinlocks(int yes);
 extern int oops_in_progress;		/* If set, an oops, panic(), BUG() or die() is in progress */
 extern int panic_on_oops;
-extern int system_state;		/* See values below */
 extern int tainted;
 extern const char *print_tainted(void);
 
 /* Values used for system_state */
-#define SYSTEM_BOOTING 0
-#define SYSTEM_RUNNING 1
-#define SYSTEM_SHUTDOWN 2
+extern enum system_states {
+	SYSTEM_BOOTING,
+	SYSTEM_RUNNING,
+	SYSTEM_HALT,
+	SYSTEM_POWER_OFF,
+	SYSTEM_RESTART,
+} system_state;
 
 #define TAINT_PROPRIETARY_MODULE	(1<<0)
 #define TAINT_FORCED_MODULE		(1<<1)
diff -puN init/main.c~system-state-splitup init/main.c
--- 25/init/main.c~system-state-splitup	2004-05-10 22:05:15.128191704 -0700
+++ 25-akpm/init/main.c	2004-05-10 22:05:15.135190640 -0700
@@ -95,7 +95,8 @@ extern void prepare_namespace(void);
 extern void tc_init(void);
 #endif
 
-int system_state;	/* SYSTEM_BOOTING/RUNNING/SHUTDOWN */
+enum system_states system_state;
+EXPORT_SYMBOL(system_state);
 
 /*
  * Boot command-line arguments
diff -puN kernel/sys.c~system-state-splitup kernel/sys.c
--- 25/kernel/sys.c~system-state-splitup	2004-05-10 22:05:15.130191400 -0700
+++ 25-akpm/kernel/sys.c	2004-05-10 22:05:15.135190640 -0700
@@ -451,7 +451,7 @@ asmlinkage long sys_reboot(int magic1, i
 	switch (cmd) {
 	case LINUX_REBOOT_CMD_RESTART:
 		notifier_call_chain(&reboot_notifier_list, SYS_RESTART, NULL);
-		system_state = SYSTEM_SHUTDOWN;
+		system_state = SYSTEM_RESTART;
 		device_shutdown();
 		printk(KERN_EMERG "Restarting system.\n");
 		machine_restart(NULL);
@@ -467,7 +467,7 @@ asmlinkage long sys_reboot(int magic1, i
 
 	case LINUX_REBOOT_CMD_HALT:
 		notifier_call_chain(&reboot_notifier_list, SYS_HALT, NULL);
-		system_state = SYSTEM_SHUTDOWN;
+		system_state = SYSTEM_HALT;
 		device_shutdown();
 		printk(KERN_EMERG "System halted.\n");
 		machine_halt();
@@ -477,7 +477,7 @@ asmlinkage long sys_reboot(int magic1, i
 
 	case LINUX_REBOOT_CMD_POWER_OFF:
 		notifier_call_chain(&reboot_notifier_list, SYS_POWER_OFF, NULL);
-		system_state = SYSTEM_SHUTDOWN;
+		system_state = SYSTEM_POWER_OFF;
 		device_shutdown();
 		printk(KERN_EMERG "Power down.\n");
 		machine_power_off();
@@ -493,7 +493,7 @@ asmlinkage long sys_reboot(int magic1, i
 		buffer[sizeof(buffer) - 1] = '\0';
 
 		notifier_call_chain(&reboot_notifier_list, SYS_RESTART, buffer);
-		system_state = SYSTEM_SHUTDOWN;
+		system_state = SYSTEM_RESTART;
 		device_shutdown();
 		printk(KERN_EMERG "Restarting system with command '%s'.\n", buffer);
 		machine_restart(buffer);

_

Re: Linux 2.6.6 "IDE cache-flush at shutdown fixes"

[Rene Herman]

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

Andrew Morton wrote:

>>It's a bit grubby, but we could easily add a fourth state to
>> `system_state': split SYSTEM_SHUTDOWN into SYSTEM_REBOOT and SYSTEM_HALT. 
>> That would be a quite simple change.
> 
> Like this.  I checked all the SYSTEM_FOO users and none of them seem to
> care about the shutdown state at present.  Easy.

Wonderful. Placed the following quick hack on top:

[drivers/ide/ide-disk.c]

@@ -1704,10 +1704,11 @@

  static void ide_device_shutdown(struct device *dev)
  {
-       ide_drive_t *drive = container_of(dev, ide_drive_t, gendev);
-
-       printk("Shutdown: %s\n", drive->name);
-       dev->bus->suspend(dev, PM_SUSPEND_STANDBY);
+       if (system_state != SYSTEM_RESTART) {
+               ide_drive_t *drive = container_of(dev, ide_drive_t, gendev);
+               printk("Shutdown: %s\n", drive->name);
+               dev->bus->suspend(dev, PM_SUSPEND_STANDBY);
+       }
  }

  /*

Seems very wrong there; will likely want to be pushed up a few levels, 
but... Works For Me.

Have attached a patch of what I'm currently using against 2.6.6 just in 
case anyone interested lost track. It's bart+morton+hack.

Rene.

[-- Attachment #2: linux-2.6.6_rollup.diff --]
[-- Type: text/plain, Size: 3569 bytes --]

diff -urN linux-2.6.6.orig/drivers/ide/ide-disk.c linux-2.6.6/drivers/ide/ide-disk.c
--- linux-2.6.6.orig/drivers/ide/ide-disk.c	2004-05-11 12:40:53.000000000 +0200
+++ linux-2.6.6/drivers/ide/ide-disk.c	2004-05-11 12:09:30.000000000 +0200
@@ -1704,10 +1704,11 @@
 
 static void ide_device_shutdown(struct device *dev)
 {
-	ide_drive_t *drive = container_of(dev, ide_drive_t, gendev);
-
-	printk("Shutdown: %s\n", drive->name);
-	dev->bus->suspend(dev, PM_SUSPEND_STANDBY);
+	if (system_state != SYSTEM_RESTART) {
+		ide_drive_t *drive = container_of(dev, ide_drive_t, gendev);
+		printk("Shutdown: %s\n", drive->name);
+		dev->bus->suspend(dev, PM_SUSPEND_STANDBY);
+	}
 }
 
 /*
@@ -1758,6 +1759,8 @@
 		if (drive->doorlocking && ide_raw_taskfile(drive, &args, NULL))
 			drive->doorlocking = 0;
 	}
+	if (drive->usage != 1 || !drive->removable)
+		return 0;
 	drive->wcache = 0;
 	/* Cache enabled? */
 	if (drive->id->csfo & 1)
diff -urN linux-2.6.6.orig/include/linux/kernel.h linux-2.6.6/include/linux/kernel.h
--- linux-2.6.6.orig/include/linux/kernel.h	2004-05-10 09:31:47.000000000 +0200
+++ linux-2.6.6/include/linux/kernel.h	2004-05-11 11:18:09.000000000 +0200
@@ -109,14 +109,17 @@
 extern void bust_spinlocks(int yes);
 extern int oops_in_progress;		/* If set, an oops, panic(), BUG() or die() is in progress */
 extern int panic_on_oops;
-extern int system_state;		/* See values below */
 extern int tainted;
 extern const char *print_tainted(void);
 
 /* Values used for system_state */
-#define SYSTEM_BOOTING 0
-#define SYSTEM_RUNNING 1
-#define SYSTEM_SHUTDOWN 2
+extern enum system_states {
+	SYSTEM_BOOTING,
+	SYSTEM_RUNNING,
+	SYSTEM_HALT,
+	SYSTEM_POWER_OFF,
+	SYSTEM_RESTART,
+} system_state;
 
 #define TAINT_PROPRIETARY_MODULE	(1<<0)
 #define TAINT_FORCED_MODULE		(1<<1)
diff -urN linux-2.6.6.orig/init/main.c linux-2.6.6/init/main.c
--- linux-2.6.6.orig/init/main.c	2004-05-10 09:31:47.000000000 +0200
+++ linux-2.6.6/init/main.c	2004-05-11 11:18:09.000000000 +0200
@@ -95,7 +95,8 @@
 extern void tc_init(void);
 #endif
 
-int system_state;	/* SYSTEM_BOOTING/RUNNING/SHUTDOWN */
+enum system_states system_state;
+EXPORT_SYMBOL(system_state);
 
 /*
  * Boot command-line arguments
diff -urN linux-2.6.6.orig/kernel/sys.c linux-2.6.6/kernel/sys.c
--- linux-2.6.6.orig/kernel/sys.c	2004-05-10 09:31:47.000000000 +0200
+++ linux-2.6.6/kernel/sys.c	2004-05-11 11:18:09.000000000 +0200
@@ -447,7 +447,7 @@
 	switch (cmd) {
 	case LINUX_REBOOT_CMD_RESTART:
 		notifier_call_chain(&reboot_notifier_list, SYS_RESTART, NULL);
-		system_state = SYSTEM_SHUTDOWN;
+		system_state = SYSTEM_RESTART;
 		device_shutdown();
 		printk(KERN_EMERG "Restarting system.\n");
 		machine_restart(NULL);
@@ -463,7 +463,7 @@
 
 	case LINUX_REBOOT_CMD_HALT:
 		notifier_call_chain(&reboot_notifier_list, SYS_HALT, NULL);
-		system_state = SYSTEM_SHUTDOWN;
+		system_state = SYSTEM_HALT;
 		device_shutdown();
 		printk(KERN_EMERG "System halted.\n");
 		machine_halt();
@@ -473,7 +473,7 @@
 
 	case LINUX_REBOOT_CMD_POWER_OFF:
 		notifier_call_chain(&reboot_notifier_list, SYS_POWER_OFF, NULL);
-		system_state = SYSTEM_SHUTDOWN;
+		system_state = SYSTEM_POWER_OFF;
 		device_shutdown();
 		printk(KERN_EMERG "Power down.\n");
 		machine_power_off();
@@ -489,7 +489,7 @@
 		buffer[sizeof(buffer) - 1] = '\0';
 
 		notifier_call_chain(&reboot_notifier_list, SYS_RESTART, buffer);
-		system_state = SYSTEM_SHUTDOWN;
+		system_state = SYSTEM_RESTART;
 		device_shutdown();
 		printk(KERN_EMERG "Restarting system with command '%s'.\n", buffer);
 		machine_restart(buffer);

Re: Linux 2.6.6 "IDE cache-flush at shutdown fixes"

[Rene Herman]

Rene Herman wrote:

> Bartlomiej Zolnierkiewicz wrote:
> 
>> Please revert ALL changes to 2.6.6 and gather some debug information
>> using these simple patch.
> 
> 
> Vanilla 2.6.6 with just this patch, at boot, directly after the 
> partition scan:
> 
> hda: wcache=1 cmd=234
> hda: task_no_data_intr: status=0x51 { DriveReady SeekComplete Error }
> hda: task_no_data_intr: error=0x04 { DriveStatusError }
> hda: Write Cache FAILED Flushing!
> 
> At reboot or halt:
> 
> Shutdown: hda
> hda: task_no_data_intr: status=0x51 { DriveReady SeekComplete Error }
> hda: task_no_data_intr: error=0x04 { DriveStatusError }
> hda: task_no_data_intr: status=0x51 { DriveReady SeekComplete Error }
> hda: task_no_data_intr: error=0x04 { DriveStatusError }
> hda: task_no_data_intr: status=0x51 { DriveReady SeekComplete Error }
> hda: task_no_data_intr: error=0x04 { DriveStatusError }
> hda: task_no_data_intr: status=0x51 { DriveReady SeekComplete Error }
> hda: task_no_data_intr: error=0x04 { DriveStatusError }
> hda: DMA disabled
> ide0: reset: success
> hda: task_no_data_intr: status=0x51 { DriveReady SeekComplete Error }
> hda: task_no_data_intr: error=0x04 { DriveStatusError }
> hda: task_no_data_intr: status=0x51 { DriveReady SeekComplete Error }
> hda: task_no_data_intr: error=0x04 { DriveStatusError }
> hda: task_no_data_intr: status=0x51 { DriveReady SeekComplete Error }
> hda: task_no_data_intr: error=0x04 { DriveStatusError }
> hda: task_no_data_intr: status=0x51 { DriveReady SeekComplete Error }
> hda: task_no_data_intr: error=0x04 { DriveStatusError }
> ide0: reset: success
> hda: task_no_data_intr: status=0x51 { DriveReady SeekComplete Error }
> hda: task_no_data_intr: error=0x04 { DriveStatusError }
> Restarting system.
> 
>> Oh and please check 'wcache' value from /proc/ide/hda/settings
>> now and with this patch applied.
> 
> 
> Vanilla 2.6.6:
> 
> rene@7ixe4:~/cache$ grep wcache settings-2.6.6
> wcache                  1               0               1               rw
> 
> 2.6.6 with the de{flush,spin}ification patches:
> 
> rene@7ixe4:~/cache$ grep wcache settings-2.6.6-hackedup
> wcache                  0               0               1               rw
> 
> Hrmpf. 0?
> 
> Will test a few older Maxtor drives as well tonight. Hope it's useful.

Sorry for quoting everything, forgot to CC lkml first time.

Only took one. Does not happen on a (slightly) older Maxtor 4W030H2, 30G 
5400RPM drive. 2.6.6 vanilla with your debug patch:

Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
PIIX4: IDE controller at PCI slot 0000:00:07.1
PIIX4: chipset revision 1
PIIX4: not 100% native mode: will probe irqs later
     ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:DMA
     ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:DMA, hdd:DMA
hda: Maxtor 4W030H2, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hdc: ATAPI-CD ROM-DRIVE-52MAX, ATAPI CD/DVD-ROM drive
hdd: 6X4X32, ATAPI CD/DVD-ROM drive
ide1 at 0x170-0x177,0x376 on irq 15
hda: max request size: 128KiB
hda: 60030432 sectors (30735 MB) w/2048KiB Cache, CHS=59554/16/63, UDMA(33)
  hda: hda1 hda2 hda3 hda4
hdc: ATAPI 52X CD-ROM drive, 128kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.20
hdd: ATAPI 32X CD-ROM CD-R/RW drive, 2048kB Cache, DMA

rene@5bt0:~$ su -c "cat /proc/ide/hda/settings" | grep wcache
wcache                  1               0               1               rw

Rene.

Re: Linux 2.6.6 "IDE cache-flush at shutdown fixes"

[Rene Herman]

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

Bartlomiej Zolnierkiewicz wrote:

>>Vanilla 2.6.6:
>>
>>rene@7ixe4:~/cache$ grep wcache settings-2.6.6
>>wcache                  1               0               1               rw
>>
>>2.6.6 with the de{flush,spin}ification patches:
>>
>>rene@7ixe4:~/cache$ grep wcache settings-2.6.6-hackedup
>>wcache                  0               0               1               rw
>>
>>Hrmpf. 0?
> 
> Very interesting, can you try vanilla 2.6.5 (or some other 2.6.x)?

2.4.26		: wcache = 0, 0, 1
2.6.6-rc3-mm2	: wcache = 0, 0, 1
2.6.6		: wcache = 1, 0, 1
2.6.6-hackedup	: wcache = 0, 0, 1

(on none of these hdparm -W0/1 has any effect, by the way)

> We are getting close to the real problem.

Indeed. I have attached two "tiobench" seq. write results, one for 
vanilla 2.6.6, and one for 2.6.6-hackedup (your changes). I remember the 
result for the latter are the normal ones I got with previous kernels as 
well. The differences are very interesting.

2.6.6-vanilla (ie, the one showing wcache=1): +/- 10MB/s
2.6.6-hackedup (ie, shows wcache=0)	    : +/- 46MB/s

As said, that 46 is the expected value. Is this a logic inversion bug in 
either driver (but then both 2.4.26 and 2.6) or drive firmware?

Rene.


[-- Attachment #2: tiobench-2.6.6 --]
[-- Type: text/plain, Size: 772 bytes --]

Sequential Writes
                              File  Blk   Num                   Avg      Maximum      Lat%     Lat%    CPU
Identifier                    Size  Size  Thr   Rate  (CPU%)  Latency    Latency      >2s      >10s    Eff
---------------------------- ------ ----- ---  ------ ------ --------- -----------  -------- -------- -----
2.6.6                         1534  4096    1   10.74 9.440%     0.298     2641.08   0.00102  0.00000   114
2.6.6                         1534  4096    2   10.64 9.999%     0.586     7005.74   0.00331  0.00000   106
2.6.6                         1534  4096    4   10.64 9.730%     1.129    17964.34   0.02550  0.00025   109
2.6.6                         1534  4096    8   10.12 9.423%     2.099    28425.08   0.04065  0.00256   107

[-- Attachment #3: tiobench-2.6.6-hackedup --]
[-- Type: text/plain, Size: 772 bytes --]

Sequential Writes
                              File  Blk   Num                   Avg      Maximum      Lat%     Lat%    CPU
Identifier                    Size  Size  Thr   Rate  (CPU%)  Latency    Latency      >2s      >10s    Eff
---------------------------- ------ ----- ---  ------ ------ --------- -----------  -------- -------- -----
2.6.6                         1534  4096    1   46.59 57.01%     0.069      598.21   0.00000  0.00000    82
2.6.6                         1534  4096    2   42.44 50.34%     0.155     1951.60   0.00000  0.00000    84
2.6.6                         1534  4096    4   44.65 52.23%     0.267     1336.76   0.00000  0.00000    85
2.6.6                         1534  4096    8   37.78 41.34%     0.604     6720.81   0.00307  0.00000    91

Re: Linux 2.6.6 "IDE cache-flush at shutdown fixes"

[Mike Houston]

On Tue, 11 May 2004 13:24:10 +0200
Rene Herman <rene.herman@keyaccess.nl> wrote:

> Have attached a patch of what I'm currently using against 2.6.6 just in 
> case anyone interested lost track. It's bart+morton+hack.
> 
> Rene.
> 

[linux-2.6.6_rollup.diff  text/plain (3726 bytes)]

I applied your bart+morton+hack rollup earlier today and it seems to be doing the right thing by me. The only problem I was having, was the suspend on restart and bios initialization delay (~ 15 seconds) because of it. That niggle was bugging me a bit and I'm glad to have it corrected.

So thanks Rene, Andrew and Bartlomiej :-)

Mike

Re: Linux 2.6.6 "IDE cache-flush at shutdown fixes"

[Bill Davidsen]

Rene Herman wrote:
> Andrew Morton wrote:
> 
>>> It's a bit grubby, but we could easily add a fourth state to
>>> `system_state': split SYSTEM_SHUTDOWN into SYSTEM_REBOOT and 
>>> SYSTEM_HALT. That would be a quite simple change.
>>
>>
>> Like this.  I checked all the SYSTEM_FOO users and none of them seem to
>> care about the shutdown state at present.  Easy.
> 
> 
> Wonderful. Placed the following quick hack on top:
	[snip]
> Seems very wrong there; will likely want to be pushed up a few levels, 
> but... Works For Me.
> 
> Have attached a patch of what I'm currently using against 2.6.6 just in 
> case anyone interested lost track. It's bart+morton+hack.
> 
> Rene.

For which patch I say thank you, it saves a lot of time for people who 
have been following but not applying each level of fix as it came up.

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: Linux 2.6.6 "IDE cache-flush at shutdown fixes"

[Pavel Machek]

Hi!


> > It's a bit grubby, but we could easily add a fourth state to
> >  `system_state': split SYSTEM_SHUTDOWN into SYSTEM_REBOOT and SYSTEM_HALT. 
> >  That would be a quite simple change.
> 
> Like this.  I checked all the SYSTEM_FOO users and none of them seem to
> care about the shutdown state at present.  Easy.

Perhaps this should be parameter to device_shutdown? This is quite
ugly.

								Pavel

> diff -puN include/linux/kernel.h~system-state-splitup include/linux/kernel.h
> --- 25/include/linux/kernel.h~system-state-splitup	2004-05-10 22:05:15.127191856 -0700
> +++ 25-akpm/include/linux/kernel.h	2004-05-10 22:05:15.133190944 -0700
> @@ -109,14 +109,17 @@ static inline void console_verbose(void)
>  extern void bust_spinlocks(int yes);
>  extern int oops_in_progress;		/* If set, an oops, panic(), BUG() or die() is in progress */
>  extern int panic_on_oops;
> -extern int system_state;		/* See values below */
>  extern int tainted;
>  extern const char *print_tainted(void);
>  
>  /* Values used for system_state */
> -#define SYSTEM_BOOTING 0
> -#define SYSTEM_RUNNING 1
> -#define SYSTEM_SHUTDOWN 2
> +extern enum system_states {
> +	SYSTEM_BOOTING,
> +	SYSTEM_RUNNING,
> +	SYSTEM_HALT,
> +	SYSTEM_POWER_OFF,
> +	SYSTEM_RESTART,
> +} system_state;
>  
>  #define TAINT_PROPRIETARY_MODULE	(1<<0)
>  #define TAINT_FORCED_MODULE		(1<<1)
...
> diff -puN kernel/sys.c~system-state-splitup kernel/sys.c
> --- 25/kernel/sys.c~system-state-splitup	2004-05-10 22:05:15.130191400 -0700
> +++ 25-akpm/kernel/sys.c	2004-05-10 22:05:15.135190640 -0700
> @@ -451,7 +451,7 @@ asmlinkage long sys_reboot(int magic1, i
>  	switch (cmd) {
>  	case LINUX_REBOOT_CMD_RESTART:
>  		notifier_call_chain(&reboot_notifier_list, SYS_RESTART, NULL);
> -		system_state = SYSTEM_SHUTDOWN;
> +		system_state = SYSTEM_RESTART;
>  		device_shutdown();
>  		printk(KERN_EMERG "Restarting system.\n");
>  		machine_restart(NULL);

-- 
When do you have heart between your knees?

Re: Linux 2.6.6 "IDE cache-flush at shutdown fixes"

[Andrew Morton]

Pavel Machek <pavel@ucw.cz> wrote:
>
> > > It's a bit grubby, but we could easily add a fourth state to
> > >  `system_state': split SYSTEM_SHUTDOWN into SYSTEM_REBOOT and SYSTEM_HALT. 
> > >  That would be a quite simple change.
> > 
> > Like this.  I checked all the SYSTEM_FOO users and none of them seem to
> > care about the shutdown state at present.  Easy.
> 
> Perhaps this should be parameter to device_shutdown? This is quite
> ugly.

That was judged to be a 2.7 exercise.  Seems to affect 143 files already.

Re: Linux 2.6.6 "IDE cache-flush at shutdown fixes"

[Andrew Morton]

Pavel Machek <pavel@ucw.cz> wrote:
>
> > > It's a bit grubby, but we could easily add a fourth state to
> > >  `system_state': split SYSTEM_SHUTDOWN into SYSTEM_REBOOT and SYSTEM_HALT. 
> > >  That would be a quite simple change.
> > 
> > Like this.  I checked all the SYSTEM_FOO users and none of them seem to
> > care about the shutdown state at present.  Easy.
> 
> Perhaps this should be parameter to device_shutdown? This is quite
> ugly.

Rather than a parameter to ->shutdown it would be better to add a new
->restart method to devices and IDE can implement one of those.

I don't know if it's worth the effort though.  Is any other driver likely
to want to discriminate between reboot and shutdown?

Re: Linux 2.6.6 "IDE cache-flush at shutdown fixes"

[Bartlomiej Zolnierkiewicz]

On Saturday 15 of May 2004 02:59, Andrew Morton wrote:
> Pavel Machek <pavel@ucw.cz> wrote:
> > > > It's a bit grubby, but we could easily add a fourth state to
> > > >  `system_state': split SYSTEM_SHUTDOWN into SYSTEM_REBOOT and
> > > > SYSTEM_HALT. That would be a quite simple change.
> > >
> > > Like this.  I checked all the SYSTEM_FOO users and none of them seem to
> > > care about the shutdown state at present.  Easy.
> >
> > Perhaps this should be parameter to device_shutdown? This is quite
> > ugly.
>
> Rather than a parameter to ->shutdown it would be better to add a new
> ->restart method to devices and IDE can implement one of those.
>
> I don't know if it's worth the effort though.  Is any other driver likely
> to want to discriminate between reboot and shutdown?

it seems only drivers/char/watchdog/alim7101_wdt.c
(currently uses reboot notifier for that)

Re: Linux 2.6.6 "IDE cache-flush at shutdown fixes"

[Herbert Xu]

Andrew Morton <akpm@osdl.org> wrote:
> 
> I don't know if it's worth the effort though.  Is any other driver likely
> to want to discriminate between reboot and shutdown?

e100 used to (and still does in 2.4) send the device into D3 on shutdown.
This causes problems on a number of boards if the box is only rebooting
as the driver fails to bring the device back out of D3.
-- 
Visit Openswan at http://www.openswan.org/
Email:  Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: Linux 2.6.6 "IDE cache-flush at shutdown fixes"

[Andrew Morton]

Herbert Xu <herbert@gondor.apana.org.au> wrote:
>
> Andrew Morton <akpm@osdl.org> wrote:
> > 
> > I don't know if it's worth the effort though.  Is any other driver likely
> > to want to discriminate between reboot and shutdown?
> 
> e100 used to (and still does in 2.4) send the device into D3 on shutdown.
> This causes problems on a number of boards if the box is only rebooting
> as the driver fails to bring the device back out of D3.

Ho hum.  Greg, any preferences?  We can either:

a) Add a `restart' driver method and call that during reboot instead of
   ->shutdown, if the driver implements ->restart.  Otherwise call
   ->shutdown or

b) stick with the

	if (system_state == SYSTEM_RESTART)
		...

   thing in IDE and potentially a couple of other places?

Re: Linux 2.6.6 "IDE cache-flush at shutdown fixes"

[Greg KH]

On Fri, May 14, 2004 at 11:16:20PM -0700, Andrew Morton wrote:
> Herbert Xu <herbert@gondor.apana.org.au> wrote:
> >
> > Andrew Morton <akpm@osdl.org> wrote:
> > > 
> > > I don't know if it's worth the effort though.  Is any other driver likely
> > > to want to discriminate between reboot and shutdown?
> > 
> > e100 used to (and still does in 2.4) send the device into D3 on shutdown.
> > This causes problems on a number of boards if the box is only rebooting
> > as the driver fails to bring the device back out of D3.
> 
> Ho hum.  Greg, any preferences?  We can either:
> 
> a) Add a `restart' driver method and call that during reboot instead of
>    ->shutdown, if the driver implements ->restart.  Otherwise call
>    ->shutdown or
> 
> b) stick with the
> 
> 	if (system_state == SYSTEM_RESTART)
> 		...
> 
>    thing in IDE and potentially a couple of other places?

I think we should stick with option b) for now, as we are already
keeping this system state, right?  The number of different drivers that
will care about this is probably quite small.

But if I'm proven wrong, we can add "restart" to 2.7 :)

thanks,

greg k-h

Re: Linux 2.6.6 "IDE cache-flush at shutdown fixes"

[Andrew Morton]

Greg KH <greg@kroah.com> wrote:
>
> > Ho hum.  Greg, any preferences?  We can either:
> > 
> > a) Add a `restart' driver method and call that during reboot instead of
> >    ->shutdown, if the driver implements ->restart.  Otherwise call
> >    ->shutdown or
> > 
> > b) stick with the
> > 
> > 	if (system_state == SYSTEM_RESTART)
> > 		...
> > 
> >    thing in IDE and potentially a couple of other places?
> 
> I think we should stick with option b) for now, as we are already
> keeping this system state, right?

Yes, it's currently used in arch code which is otuside the driver model.

And the "current state of the entire system" maps comfortably onto a global
variable.

Re: Linux 2.6.6 "IDE cache-flush at shutdown fixes"

[Pavel Machek]

Hi!

> > There is a problem with new 2.6 generic ->shutdown framework,
> >  it doesn't differentiate between reboot / halt and power_off.
> >  We may try to fix it or revert to 2.4 way of doing things if
> >  this is too big change for 2.6.
> 
> It's a bit grubby, but we could easily add a fourth state to
> `system_state': split SYSTEM_SHUTDOWN into SYSTEM_REBOOT and SYSTEM_HALT. 
> That would be a quite simple change.

I believe that we do not want to split that. These paths get pretty
little testing, and splitting testing effort even more could be pretty
bad.
								Pavel
-- 
When do you have heart between your knees?

Re: Linux 2.6.6 "IDE cache-flush at shutdown fixes"

[Rene Herman]

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

Bartlomiej Zolnierkiewicz wrote:

> Rene, can you send me copies of /proc/ide/hda/identify and
> /proc/ide/hdc/identify?

Sure, attached. Quite sure you wanted hdc though? That's a DVD-ROM.

> I still would like to know why these drives don't accept flush cache 
> commands (or it is a driver's bug?).

No idea I'm afraid. Seems at least new Maxtor drives are affected. Both
the "120P0" (120G, 8M cache) and "L0" (120G, 2M cache) were reported in
this thread.

> There is a problem with new 2.6 generic ->shutdown framework,
> it doesn't differentiate between reboot / halt and power_off.
> We may try to fix it or revert to 2.4 way of doing things if
> this is too big change for 2.6.

Please also see reply to Andrew...

Rene.


[-- Attachment #2: hda --]
[-- Type: text/plain, Size: 1335 bytes --]

# Maxtor 6Y120P0 (DiamondMax Plus 9, 120G, 8M cache)

0040 3fff c837 0010 0000 0000 003f 0000
0000 0000 5933 3232 4144 4a45 2020 2020
2020 2020 2020 2020 0003 3e00 0039 5941
5234 3142 5730 4d61 7874 6f72 2036 5931
3230 5030 2020 2020 2020 2020 2020 2020
2020 2020 2020 2020 2020 2020 2020 8010
0000 2f00 4000 0200 0000 0007 0fcf 0010
00ff f310 00fb 0108 f780 0e4f 0000 0007
0003 0078 0078 0078 0078 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
00fe 001e 7c6b 7b09 4003 7c69 3a01 4003
107f 0000 0000 0000 fffe 600d c0c0 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0001 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0001 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 98a5


[-- Attachment #3: hdc --]
[-- Type: text/plain, Size: 1308 bytes --]

# Plextor PX-116A DVD-ROM

85c0 0000 0000 0000 0000 0000 0000 0000
0000 0000 2020 2020 2020 2020 2020 2020
2020 2020 2020 2020 0000 0000 0000 312e
3030 2020 2020 504c 4558 544f 5220 4456
442d 524f 4d20 5058 2d31 3136 4120 2020
2020 2020 2020 2020 2020 2020 2020 0000
0000 0b00 0000 0400 0200 0006 0000 0000
0000 0000 0000 0000 0000 0000 0000 0007
0003 0078 0078 00b4 0078 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
003e 0000 4218 4000 4000 4218 0000 4000
101f 0000 0000 0000 0000 6000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000

Re: Linux 2.6.6 "IDE cache-flush at shutdown fixes"

[Craig Bradney]

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

On Tue, 2004-05-11 at 13:24, Rene Herman wrote:
> Bartlomiej Zolnierkiewicz wrote:
> 
> > Rene, can you send me copies of /proc/ide/hda/identify and
> > /proc/ide/hdc/identify?
> 
> Sure, attached. Quite sure you wanted hdc though? That's a DVD-ROM.
> 
> > I still would like to know why these drives don't accept flush cache 
> > commands (or it is a driver's bug?).
> 
> No idea I'm afraid. Seems at least new Maxtor drives are affected. Both
> the "120P0" (120G, 8M cache) and "L0" (120G, 2M cache) were reported in
> this thread.

At a guess the 80P0 drives will also be affected (80G, 8mb cache), but
as yet I havent tried 2.6.6 on the boxes with them. Tonight if theres
time.

Craig

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Linux 2.6.6 "IDE cache-flush at shutdown fixes"

[Athanasius]

On Tue, May 11, 2004 at 02:56:38PM +0200, Craig Bradney wrote:
> > > Rene, can you send me copies of /proc/ide/hda/identify and
> > > /proc/ide/hdc/identify?
> At a guess the 80P0 drives will also be affected (80G, 8mb cache), but
> as yet I havent tried 2.6.6 on the boxes with them. Tonight if theres
> time.

/dev/hda:

 Model=Maxtor 6Y080P0, FwRev=YAR41BW0, SerialNo=Y24X835E
 Config={ Fixed }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=57
 BuffType=DualPortCache, BuffSize=7936kB, MaxMultSect=16, MultSect=off
 CurCHS=4047/16/255, CurSects=16511760, LBA=yes, LBAsects=160086528
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes:  pio0 pio1 pio2 pio3 pio4 
 DMA modes:  mdma0 mdma1 mdma2 
 UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5 udma6 
 AdvancedPM=yes: disabled (255) WriteCache=enabled
 Drive conforms to: (null): 

At boot-time I did get two lots of:

hda: task_no_data_intr: status=0x51 { DriveReady SeekComplete Error }
hda: task_no_data_intr: error=0x04 { DriveStatusError }
hda: Write Cache FAILED Flushing!

Still on the first boot of 2.6.6 atm, so don't know if it bitches at
shutdown too.

16:50:02 0$ cat /proc/ide/hda/identify
0040 3fff c837 0010 0000 0000 003f 0000
0000 0000 5932 3458 3833 3545 2020 2020
2020 2020 2020 2020 0003 3e00 0039 5941
5234 3142 5730 4d61 7874 6f72 2036 5930
3830 5030 2020 2020 2020 2020 2020 2020
2020 2020 2020 2020 2020 2020 2020 8010
0000 2f00 4000 0200 0000 0007 0fcf 0010
00ff f310 00fb 0100 ba00 098a 0000 0007
0003 0078 0078 0078 0078 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
00fe 001e 7c6b 7b09 4003 7c69 3a01 4003
207f 0000 0000 0000 fffe 600b c0fe 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0009 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0001 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 d6a5
root@emelia:~;
16:50:03 0$ 

-Ath
-- 
- Athanasius = Athanasius(at)miggy.org / http://www.miggy.org/
                  Finger athan(at)fysh.org for PGP key
	   "And it's me who is my enemy. Me who beats me up.
Me who makes the monsters. Me who strips my confidence." Paula Cole - ME

Re: Linux 2.6.6 "IDE cache-flush at shutdown fixes"

[dobrev]

Craig Bradney wrote:

>On Tue, 2004-05-11 at 13:24, Rene Herman wrote:
>  
>
>>Bartlomiej Zolnierkiewicz wrote:
>>
>>    
>>
>>>Rene, can you send me copies of /proc/ide/hda/identify and
>>>/proc/ide/hdc/identify?
>>>      
>>>
>>Sure, attached. Quite sure you wanted hdc though? That's a DVD-ROM.
>>
>>    
>>
>>>I still would like to know why these drives don't accept flush cache 
>>>commands (or it is a driver's bug?).
>>>      
>>>
>>No idea I'm afraid. Seems at least new Maxtor drives are affected. Both
>>the "120P0" (120G, 8M cache) and "L0" (120G, 2M cache) were reported in
>>this thread.
>>    
>>
>
>At a guess the 80P0 drives will also be affected (80G, 8mb cache), but
>as yet I havent tried 2.6.6 on the boxes with them. Tonight if theres
>time.
>
>Craig
>

I have Maxtor 6Y060L0 and is also affected. Now I am with 2.6.5.
SvrWks IDE controller also have problems with 2.6.6 because the drive 
works in mdma2 mode.
When in 2.6.5 the transfer mode is udma2.
Probably because of this (from patch-2.6.6):
diff -Nru a/drivers/ide/pci/serverworks.c b/drivers/ide/pci/serverworks.c
--- a/drivers/ide/pci/serverworks.c     Sun May  9 19:33:36 2004
+++ b/drivers/ide/pci/serverworks.c     Sun May  9 19:33:36 2004
@@ -472,7 +472,9 @@
                                int dma = config_chipset_for_dma(drive);
                                if ((id->field_valid & 2) && !dma)
                                        goto try_dma_modes;
-                       }
+                       } else
+                               /* UDMA disabled by mask, try other DMA 
modes */+                               goto try_dma_modes;
                } else if (id->field_valid & 2) {
 try_dma_modes:
                        if ((id->dma_mword & hwif->mwdma_mask) ||

Here is part of dmesg from 2.6.6:


ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
SvrWks OSB4: IDE controller at PCI slot 0000:00:0f.1
SvrWks OSB4: chipset revision 0
SvrWks OSB4: not 100% native mode: will probe irqs later
    ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:DMA, hdb:pio
    ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:pio, hdd:pio
hda: Maxtor 6Y060L0, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hda: max request size: 128KiB
hda: 120103200 sectors (61492 MB) w/2048KiB Cache, CHS=65535/16/63, (U)DMA
 hda: hda1 hda2 hda3 < hda5 hda6 hda7 >
hda: task_no_data_intr: status=0x51 { DriveReady SeekComplete Error }
hda: task_no_data_intr: error=0x04 { DriveStatusError }
hda: Write Cache FAILED Flushing!
mice: PS/2 mouse device common for all mice
input: PC Speaker
serio: i8042 AUX port at 0x60,0x64 irq 12
input: GenPS/2 Genius Wheel Mouse on isa0060/serio1
serio: i8042 KBD port at 0x60,0x64 irq 1
input: AT Translated Set 2 keyboard on isa0060/serio0
NET: Registered protocol family 2
IP: routing cache hash table of 2048 buckets, 16Kbytes
TCP: Hash tables configured (established 16384 bind 16384)
NET: Registered protocol family 1
NET: Registered protocol family 17
BIOS EDD facility v0.13 2004-Mar-09, 1 devices found
Please report your BIOS at http://linux.dell.com/edd/results.html
hda: task_no_data_intr: status=0x51 { DriveReady SeekComplete Error }
hda: task_no_data_intr: error=0x04 { DriveStatusError }
hda: Write Cache FAILED Flushing!
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 368k freed
Adding 297192k swap on /dev/hda2.  Priority:-1 extents:1
Linux agpgart interface v0.100 (c) Dave Jones

Re: Linux 2.6.6 "IDE cache-flush at shutdown fixes"

[Bartlomiej Zolnierkiewicz]

On Tuesday 11 of May 2004 18:10, dobrev wrote:
> Craig Bradney wrote:
> >On Tue, 2004-05-11 at 13:24, Rene Herman wrote:
> >>Bartlomiej Zolnierkiewicz wrote:
> >>>Rene, can you send me copies of /proc/ide/hda/identify and
> >>>/proc/ide/hdc/identify?
> >>
> >>Sure, attached. Quite sure you wanted hdc though? That's a DVD-ROM.
> >>
> >>>I still would like to know why these drives don't accept flush cache
> >>>commands (or it is a driver's bug?).
> >>
> >>No idea I'm afraid. Seems at least new Maxtor drives are affected. Both
> >>the "120P0" (120G, 8M cache) and "L0" (120G, 2M cache) were reported in
> >>this thread.
> >
> >At a guess the 80P0 drives will also be affected (80G, 8mb cache), but
> >as yet I havent tried 2.6.6 on the boxes with them. Tonight if theres
> >time.
> >
> >Craig
>
> I have Maxtor 6Y060L0 and is also affected. Now I am with 2.6.5.

Please see http://bugme.osdl.org/show_bug.cgi?id=2672

> SvrWks IDE controller also have problems with 2.6.6 because the drive
> works in mdma2 mode.
> When in 2.6.5 the transfer mode is udma2.

UDMA2 on OSB4?  Weird.

from serverwoks.c:

	/* If we are about to put a disk into UDMA mode we screwed up.
	   Our code assumes we never _ever_ do this on an OSB4 */

	if(dev->device == PCI_DEVICE_ID_SERVERWORKS_OSB4 &&
		drive->media == ide_disk && speed >= XFER_UDMA_0)
			BUG();

I need more data: .config (2.6.5/2.6.6) and full dmesg output (2.6.5/2.6.6).

> Probably because of this (from patch-2.6.6):
> diff -Nru a/drivers/ide/pci/serverworks.c b/drivers/ide/pci/serverworks.c
> --- a/drivers/ide/pci/serverworks.c     Sun May  9 19:33:36 2004
> +++ b/drivers/ide/pci/serverworks.c     Sun May  9 19:33:36 2004
> @@ -472,7 +472,9 @@
>                                 int dma = config_chipset_for_dma(drive);
>                                 if ((id->field_valid & 2) && !dma)
>                                         goto try_dma_modes;
> -                       }
> +                       } else
> +                               /* UDMA disabled by mask, try other DMA
> modes */+                               goto try_dma_modes;
>                 } else if (id->field_valid & 2) {
>  try_dma_modes:
>                         if ((id->dma_mword & hwif->mwdma_mask) ||
>
> Here is part of dmesg from 2.6.6:
>
>
> ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
> SvrWks OSB4: IDE controller at PCI slot 0000:00:0f.1
> SvrWks OSB4: chipset revision 0
> SvrWks OSB4: not 100% native mode: will probe irqs later
>     ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:DMA, hdb:pio
>     ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:pio, hdd:pio
> hda: Maxtor 6Y060L0, ATA DISK drive
> ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
> hda: max request size: 128KiB
> hda: 120103200 sectors (61492 MB) w/2048KiB Cache, CHS=65535/16/63, (U)DMA
>  hda: hda1 hda2 hda3 < hda5 hda6 hda7 >
> hda: task_no_data_intr: status=0x51 { DriveReady SeekComplete Error }
> hda: task_no_data_intr: error=0x04 { DriveStatusError }
> hda: Write Cache FAILED Flushing!
> mice: PS/2 mouse device common for all mice
> input: PC Speaker
> serio: i8042 AUX port at 0x60,0x64 irq 12
> input: GenPS/2 Genius Wheel Mouse on isa0060/serio1
> serio: i8042 KBD port at 0x60,0x64 irq 1
> input: AT Translated Set 2 keyboard on isa0060/serio0
> NET: Registered protocol family 2
> IP: routing cache hash table of 2048 buckets, 16Kbytes
> TCP: Hash tables configured (established 16384 bind 16384)
> NET: Registered protocol family 1
> NET: Registered protocol family 17
> BIOS EDD facility v0.13 2004-Mar-09, 1 devices found
> Please report your BIOS at http://linux.dell.com/edd/results.html
> hda: task_no_data_intr: status=0x51 { DriveReady SeekComplete Error }
> hda: task_no_data_intr: error=0x04 { DriveStatusError }
> hda: Write Cache FAILED Flushing!
> VFS: Mounted root (ext2 filesystem) readonly.
> Freeing unused kernel memory: 368k freed
> Adding 297192k swap on /dev/hda2.  Priority:-1 extents:1
> Linux agpgart interface v0.100 (c) Dave Jones

Re: Linux 2.6.6 "IDE cache-flush at shutdown fixes"

[dobrev]

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



Bartlomiej Zolnierkiewicz wrote:

>On Tuesday 11 of May 2004 18:10, dobrev wrote:
>  
>
>>Craig Bradney wrote:
>>    
>>
>>>On Tue, 2004-05-11 at 13:24, Rene Herman wrote:
>>>      
>>>
>>>>Bartlomiej Zolnierkiewicz wrote:
>>>>        
>>>>
>>>>>Rene, can you send me copies of /proc/ide/hda/identify and
>>>>>/proc/ide/hdc/identify?
>>>>>          
>>>>>
>>>>Sure, attached. Quite sure you wanted hdc though? That's a DVD-ROM.
>>>>
>>>>        
>>>>
>>>>>I still would like to know why these drives don't accept flush cache
>>>>>commands (or it is a driver's bug?).
>>>>>          
>>>>>
>>>>No idea I'm afraid. Seems at least new Maxtor drives are affected. Both
>>>>the "120P0" (120G, 8M cache) and "L0" (120G, 2M cache) were reported in
>>>>this thread.
>>>>        
>>>>
>>>At a guess the 80P0 drives will also be affected (80G, 8mb cache), but
>>>as yet I havent tried 2.6.6 on the boxes with them. Tonight if theres
>>>time.
>>>
>>>Craig
>>>      
>>>
>>I have Maxtor 6Y060L0 and is also affected. Now I am with 2.6.5.
>>    
>>
>
>Please see http://bugme.osdl.org/show_bug.cgi?id=2672
>  
>

Yes, I know.

>  
>
>>SvrWks IDE controller also have problems with 2.6.6 because the drive
>>works in mdma2 mode.
>>When in 2.6.5 the transfer mode is udma2.
>>    
>>
>
>UDMA2 on OSB4?  Weird.
>
>from serverwoks.c:
>
>	/* If we are about to put a disk into UDMA mode we screwed up.
>	   Our code assumes we never _ever_ do this on an OSB4 */
>
>	if(dev->device == PCI_DEVICE_ID_SERVERWORKS_OSB4 &&
>		drive->media == ide_disk && speed >= XFER_UDMA_0)
>			BUG();
>
>I need more data: .config (2.6.5/2.6.6) and full dmesg output (2.6.5/2.6.6).
>  
>

Yes, it's a OSB4.
I attached files you need. .config is the same.
The problem is that when in 2.6.6 hdparm  reports that the drive is much 
slower than 2.6.5
2.6.6 => 13 MB/s
2.6.5 => 23 MB/s
When I  remove the code related to serverworks.c (see bellow) in 
patch-2.6.6 transfer is like 2.6.5.

>  
>
>>Probably because of this (from patch-2.6.6):
>>diff -Nru a/drivers/ide/pci/serverworks.c b/drivers/ide/pci/serverworks.c
>>--- a/drivers/ide/pci/serverworks.c     Sun May  9 19:33:36 2004
>>+++ b/drivers/ide/pci/serverworks.c     Sun May  9 19:33:36 2004
>>@@ -472,7 +472,9 @@
>>                                int dma = config_chipset_for_dma(drive);
>>                                if ((id->field_valid & 2) && !dma)
>>                                        goto try_dma_modes;
>>-                       }
>>+                       } else
>>+                               /* UDMA disabled by mask, try other DMA
>>modes */+                               goto try_dma_modes;
>>                } else if (id->field_valid & 2) {
>> try_dma_modes:
>>                        if ((id->dma_mword & hwif->mwdma_mask) ||
>>    
>>





[-- Attachment #2: attach.tar.gz --]
[-- Type: application/x-tar, Size: 10162 bytes --]

Re: Linux 2.6.6 "IDE cache-flush at shutdown fixes"

[Patrick Wildi]

On Wed, 12 May 2004, dobrev wrote:

>
>
> Bartlomiej Zolnierkiewicz wrote:
>
> >On Tuesday 11 of May 2004 18:10, dobrev wrote:
> >
> >
> >>Craig Bradney wrote:
> >>
> >>
> >>>On Tue, 2004-05-11 at 13:24, Rene Herman wrote:
> >>>
> >>>
> >>>>Bartlomiej Zolnierkiewicz wrote:
> >>>>
> >>>>
> >>>>>Rene, can you send me copies of /proc/ide/hda/identify and
> >>>>>/proc/ide/hdc/identify?
> >>>>>
> >>>>>
> >>>>Sure, attached. Quite sure you wanted hdc though? That's a DVD-ROM.
> >>>>
> >>>>
> >>>>
> >>>>>I still would like to know why these drives don't accept flush cache
> >>>>>commands (or it is a driver's bug?).
> >>>>>
> >>>>>
> >>>>No idea I'm afraid. Seems at least new Maxtor drives are affected. Both
> >>>>the "120P0" (120G, 8M cache) and "L0" (120G, 2M cache) were reported in
> >>>>this thread.
> >>>>
> >>>>
> >>>At a guess the 80P0 drives will also be affected (80G, 8mb cache), but
> >>>as yet I havent tried 2.6.6 on the boxes with them. Tonight if theres
> >>>time.
> >>>
> >>>Craig
> >>>
> >>>
> >>I have Maxtor 6Y060L0 and is also affected. Now I am with 2.6.5.
> >>
> >>
> >
> >Please see http://bugme.osdl.org/show_bug.cgi?id=2672
> >
> >
>
> Yes, I know.
>
> >
> >
> >>SvrWks IDE controller also have problems with 2.6.6 because the drive
> >>works in mdma2 mode.
> >>When in 2.6.5 the transfer mode is udma2.
> >>
> >>
> >
> >UDMA2 on OSB4?  Weird.
> >
> >from serverwoks.c:
> >
> >	/* If we are about to put a disk into UDMA mode we screwed up.
> >	   Our code assumes we never _ever_ do this on an OSB4 */
> >
> >	if(dev->device == PCI_DEVICE_ID_SERVERWORKS_OSB4 &&
> >		drive->media == ide_disk && speed >= XFER_UDMA_0)
> >			BUG();
> >
> >I need more data: .config (2.6.5/2.6.6) and full dmesg output (2.6.5/2.6.6).
> >
> >
>
> Yes, it's a OSB4.
> I attached files you need. .config is the same.
> The problem is that when in 2.6.6 hdparm  reports that the drive is much
> slower than 2.6.5
> 2.6.6 => 13 MB/s
> 2.6.5 => 23 MB/s
> When I  remove the code related to serverworks.c (see bellow) in
> patch-2.6.6 transfer is like 2.6.5.

I believe what happens, is that with the old logic UDMA disks on
OSB4 "fell through the cracks" in svwks_config_drive_xfer_rate().
It was basically a noop (unintentionally) and the settings were
left at whatever BIOS set them to.
Looking through some old threads, it looks like UDMA was considered
not safe on an OSB4.

Patrick

> >
> >
> >>Probably because of this (from patch-2.6.6):
> >>diff -Nru a/drivers/ide/pci/serverworks.c b/drivers/ide/pci/serverworks.c
> >>--- a/drivers/ide/pci/serverworks.c     Sun May  9 19:33:36 2004
> >>+++ b/drivers/ide/pci/serverworks.c     Sun May  9 19:33:36 2004
> >>@@ -472,7 +472,9 @@
> >>                                int dma = config_chipset_for_dma(drive);
> >>                                if ((id->field_valid & 2) && !dma)
> >>                                        goto try_dma_modes;
> >>-                       }
> >>+                       } else
> >>+                               /* UDMA disabled by mask, try other DMA
> >>modes */+                               goto try_dma_modes;
> >>                } else if (id->field_valid & 2) {
> >> try_dma_modes:
> >>                        if ((id->dma_mword & hwif->mwdma_mask) ||
> >>
> >>
>
>
>
>
>

Re: Linux 2.6.6 "IDE cache-flush at shutdown fixes"

[dobrev]

Patrick Wildi wrote:

>On Wed, 12 May 2004, dobrev wrote:
>
>  
>
>>Bartlomiej Zolnierkiewicz wrote:
>>
>>    
>>
>>>On Tuesday 11 of May 2004 18:10, dobrev wrote:
>>>
>>>
>>>      
>>>
>>>>Craig Bradney wrote:
>>>>
>>>>
>>>>        
>>>>
>>>>>On Tue, 2004-05-11 at 13:24, Rene Herman wrote:
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>>>Bartlomiej Zolnierkiewicz wrote:
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>>>>Rene, can you send me copies of /proc/ide/hda/identify and
>>>>>>>/proc/ide/hdc/identify?
>>>>>>>
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>Sure, attached. Quite sure you wanted hdc though? That's a DVD-ROM.
>>>>>>
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>>>>I still would like to know why these drives don't accept flush cache
>>>>>>>commands (or it is a driver's bug?).
>>>>>>>
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>No idea I'm afraid. Seems at least new Maxtor drives are affected. Both
>>>>>>the "120P0" (120G, 8M cache) and "L0" (120G, 2M cache) were reported in
>>>>>>this thread.
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>>At a guess the 80P0 drives will also be affected (80G, 8mb cache), but
>>>>>as yet I havent tried 2.6.6 on the boxes with them. Tonight if theres
>>>>>time.
>>>>>
>>>>>Craig
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>I have Maxtor 6Y060L0 and is also affected. Now I am with 2.6.5.
>>>>
>>>>
>>>>        
>>>>
>>>Please see http://bugme.osdl.org/show_bug.cgi?id=2672
>>>
>>>
>>>      
>>>
>>Yes, I know.
>>
>>    
>>
>>>      
>>>
>>>>SvrWks IDE controller also have problems with 2.6.6 because the drive
>>>>works in mdma2 mode.
>>>>When in 2.6.5 the transfer mode is udma2.
>>>>
>>>>
>>>>        
>>>>
>>>UDMA2 on OSB4?  Weird.
>>>
>>>      
>>>
>>>from serverwoks.c:
>>    
>>
>>>	/* If we are about to put a disk into UDMA mode we screwed up.
>>>	   Our code assumes we never _ever_ do this on an OSB4 */
>>>
>>>	if(dev->device == PCI_DEVICE_ID_SERVERWORKS_OSB4 &&
>>>		drive->media == ide_disk && speed >= XFER_UDMA_0)
>>>			BUG();
>>>
>>>I need more data: .config (2.6.5/2.6.6) and full dmesg output (2.6.5/2.6.6).
>>>
>>>
>>>      
>>>
>>Yes, it's a OSB4.
>>I attached files you need. .config is the same.
>>The problem is that when in 2.6.6 hdparm  reports that the drive is much
>>slower than 2.6.5
>>2.6.6 => 13 MB/s
>>2.6.5 => 23 MB/s
>>When I  remove the code related to serverworks.c (see bellow) in
>>patch-2.6.6 transfer is like 2.6.5.
>>    
>>
>
>I believe what happens, is that with the old logic UDMA disks on
>OSB4 "fell through the cracks" in svwks_config_drive_xfer_rate().
>It was basically a noop (unintentionally) and the settings were
>left at whatever BIOS set them to.
>Looking through some old threads, it looks like UDMA was considered
>not safe on an OSB4.
>
>Patrick
>  
>
I agree, I think config_chipset_for_dma() was never entered before 2.6.6.
Transfer rate was udma2 and there were no problems. Same was with 2.4.
I don't know why OSB4 was concidered not to work in udma.
I have no problems for a long time and I want to use udma2.

>  
>
>>>      
>>>
>>>>Probably because of this (from patch-2.6.6):
>>>>diff -Nru a/drivers/ide/pci/serverworks.c b/drivers/ide/pci/serverworks.c
>>>>--- a/drivers/ide/pci/serverworks.c     Sun May  9 19:33:36 2004
>>>>+++ b/drivers/ide/pci/serverworks.c     Sun May  9 19:33:36 2004
>>>>@@ -472,7 +472,9 @@
>>>>                               int dma = config_chipset_for_dma(drive);
>>>>                               if ((id->field_valid & 2) && !dma)
>>>>                                       goto try_dma_modes;
>>>>-                       }
>>>>+                       } else
>>>>+                               /* UDMA disabled by mask, try other DMA
>>>>modes */+                               goto try_dma_modes;
>>>>               } else if (id->field_valid & 2) {
>>>>try_dma_modes:
>>>>                       if ((id->dma_mword & hwif->mwdma_mask) ||
>>>>
>>>>
>>>>        
>>>>
>>
>>
>>
>>    
>>
>
>  
>

Re: Linux 2.6.6 "IDE cache-flush at shutdown fixes"

[Rene Herman]

Rene Herman wrote:

> With this one, the cache flushing noise is no more, but still a problem 
> unfortunately. With or without these patches, 2.6.6 powers down the 
> drive during reboot. This is very annoying, seeing as how it immediately 
> needs to spin up again for POST.

Sorry, mistaken. This only happens _with_ your change. Without, 2.6.6 
just complains.

Rene.

Re: Linux 2.6.6 "IDE cache-flush at shutdown fixes"

[Mike Houston]

On Mon, 10 May 2004 23:59:32 +0200
Rene Herman <rene.herman@keyaccess.nl> wrote:

> Rene Herman wrote:
> 
> > With this one, the cache flushing noise is no more, but still a problem 
> > unfortunately. With or without these patches, 2.6.6 powers down the 
> > drive during reboot. This is very annoying, seeing as how it immediately 
> > needs to spin up again for POST.
> 
> Sorry, mistaken. This only happens _with_ your change. Without, 2.6.6 
> just complains.
> 
> Rene.

I am having this "spin up" behaviour with plain 2.6.6 (I haven't tried any patches)

On reboot, after it suspended the drives, there is a roughly 15 second delay at post while the bios is initializing the hard disks. During this time the hard disk LED is lit.

Shut down and power up behaviour is normal, it's only on a reboot that the above occurs.

Hardware: Pentium4, Gigabyte motherboard, i845, ICH2 IDE controllers.
Disks:  Two identical Maxtor 40 Gb 6E040L0 models. Primary master and primary slave. UDMA (100).

Note that I do hear a bit of a "cache flush" noise, but I assume that's normal because Windows XP makes that same noise when shutting down. It seems to be a normal hard disk sound.

I do not get any complaints like you have in the boot logs though. Everything is normal unless I reboot (and even that is just a trivial delay and probably not at all harmful)

Mike

scsi shutdown flush, journaled fses

[Tom Vier]

so ide drives caching writes is ok now, but what about scsi drives? do
reiserfs and ext3 both use proper write barriers (especially for
data=ordered)?

-- 
Tom Vier <tmv@comcast.net>
DSA Key ID 0x15741ECE

Re: Linux 2.6.6 "IDE cache-flush at shutdown fixes"

[Robert Hancock]

If this is indeed the case, that those drives don't support the "flush write
cache" command, I'd like to see Maxtor's excuse as to why.. I believe that
Windows always powers down IDE drives before shutdown, maybe this is because
of non-universal support for the "flush write cache" command?


----- Original Message ----- 
From: "Rene Herman" <rene.herman@keyaccess.nl>
Newsgroups: fa.linux.kernel
To: <gene.heskett@verizon.net>
Cc: <linux-kernel@vger.kernel.org>
Sent: Monday, May 10, 2004 6:08 AM
Subject: Re: Linux 2.6.6 "IDE cache-flush at shutdown fixes"


> Gene Heskett wrote:
>
> >> hda: Maxtor 6Y120P0, ATA DISK drive
>
> > I note the drive is the same model here too, Rene.
> >
> > The question remains however, is our data in danger?
>
> There's a fair change that we'll be told, yes, very much so, since these
> drives don't seem to correctly support this life saving feature. The
> real answer though will be more easily deducted by calculating the ratio
> of unexplained file system corruptions you've had and reboots you've
> managed (0, that is).
>
> Rene.
>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.6 "IDE cache-flush at shutdown fixes"

[Eric D. Mudama]

On Wed, May 12 at  0:09, Robert Hancock wrote:
>If this is indeed the case, that those drives don't support the "flush write
>cache" command, I'd like to see Maxtor's excuse as to why.. I believe that
>Windows always powers down IDE drives before shutdown, maybe this is because
>of non-universal support for the "flush write cache" command?

The issue is a bit more subtle, and I'm not making an "excuse" per
say...

(Not speaking officially for Maxtor, but I'm just trying to help...)


As per the email I got from Bart, the drive in question doesn't
support 48-bit commands.  The wierdness is that it claims to support
the FLUSH CACHE EXT (0xEA) command.  Obviously, this combination
doesn't make it safe to issue FLUSH CACHE EXT since the drive will not
be able to properly report a failing location in the event of a
failure to flush due to a fatal write fault.  The drive knows a FLUSH
CACHE EXT command isn't safe, so it aborts that command which is the
error message you see.

The code that Bart showed me does a '&' on the feature word with the
required support bits, but uses the result in an 'if' conditional.  I
believe that means that in C, if either of the bits is set, then the
'if' will evaluate to true, which is causing the problem.

The solution (that should work for all drives) would be to test
properly to make sure the drive reports support for both 48-bit
commands and FLUSH CACHE EXT, with something like:

  if ((feature & bits) == bits)

then issue that command.  If *either* of these bits is false, then the
drive should be issued a normal FLUSH CACHE (0xE7) command (which is a
reasonably standard 28-bit command, and all Maxtor drives support,
including the models in question.)

Note that this only affects newer drives (last 18 months or so) that
are <120GB. (Yes, I know that is still a truckload)

There are a gazillion of these in the field (we sell ~60 million
drives/year?) so I don't believe a firmware "upgrade" or equivalent
simply is logistically possible, but this inconsistency is going to be
addressed in future products, I'm making sure of it.


If anyone has questions, please don't hesitate to email and I'll do my
best to help.

-- 
Eric D. Mudama
edmudama@mail.bounceswoosh.org

Re: Linux 2.6.6 "IDE cache-flush at shutdown fixes"

[Rene Herman]

Eric D. Mudama wrote:

Thanks much for responding. I have one of these maxtor drives.

> Note that this only affects newer drives (last 18 months or so) that
> are <120GB. (Yes, I know that is still a truckload)

Possibly <=, but at least both 6Y120P0 (120G, 8M cache) en 6Y120L0 
(120G, 2M cache) are affected. Experiencing it myself on 6Y120P0.

> There are a gazillion of these in the field (we sell ~60 million
> drives/year?) so I don't believe a firmware "upgrade" or equivalent
> simply is logistically possible, but this inconsistency is going to be
> addressed in future products, I'm making sure of it.

As to logistics... must say I'd already be satisfied with a new firmware 
  downloadable from the maxtor site and a means to upload it. Of course, 
a linux means would be best for me. If not possible, real-mode DOS is 
useable.

> If anyone has questions, please don't hesitate to email and I'll do my
> best to help.

Thanks for responding! Please do consider making an updated firmware 
available through the site...

Rene.

Re: Linux 2.6.6 "IDE cache-flush at shutdown fixes"

[Bartlomiej Zolnierkiewicz]

[ Rene, Alan, Arjan, Andrew and Linus added to cc: ]

On Wednesday 12 of May 2004 20:52, Eric D. Mudama wrote:
> On Wed, May 12 at  0:09, Robert Hancock wrote:
> >If this is indeed the case, that those drives don't support the "flush
> > write cache" command, I'd like to see Maxtor's excuse as to why.. I
> > believe that Windows always powers down IDE drives before shutdown, maybe
> > this is because of non-universal support for the "flush write cache"
> > command?
>
> The issue is a bit more subtle, and I'm not making an "excuse" per
> say...
>
> (Not speaking officially for Maxtor, but I'm just trying to help...)
>
>
> As per the email I got from Bart, the drive in question doesn't
> support 48-bit commands.  The wierdness is that it claims to support
> the FLUSH CACHE EXT (0xEA) command.  Obviously, this combination
> doesn't make it safe to issue FLUSH CACHE EXT since the drive will not
> be able to properly report a failing location in the event of a
> failure to flush due to a fatal write fault.  The drive knows a FLUSH
> CACHE EXT command isn't safe, so it aborts that command which is the
> error message you see.
>
> The code that Bart showed me does a '&' on the feature word with the
> required support bits, but uses the result in an 'if' conditional.  I
> believe that means that in C, if either of the bits is set, then the
> 'if' will evaluate to true, which is causing the problem.
>
> The solution (that should work for all drives) would be to test
> properly to make sure the drive reports support for both 48-bit
> commands and FLUSH CACHE EXT, with something like:
>
>   if ((feature & bits) == bits)
>
> then issue that command.  If *either* of these bits is false, then the
> drive should be issued a normal FLUSH CACHE (0xE7) command (which is a
> reasonably standard 28-bit command, and all Maxtor drives support,
> including the models in question.)

Yes, this should work.  Thanks Eric.

The other part of the story is a nasty bug in ide-disk.c driver:

write_cache() is called with (drive->id->cfs_enable_2 & 0x300) as argument
'arg' of type 'int' and then this value is assigned to the 'drive->wcache'
of type 'unsigned char' so drive->wcache == 0 because 0x3000 gets truncated.

This bug has been present since introduction of drive->wcache (2.5.3),
therefore we have never handled cache flush correctly before and never
hit '& 0x2400' problem before.

Linus & Alan, you were almost right after all, drive->wcache was almost
always zero for normal disks before 2.6.6.  It could be forced by user but
only for disks having ATA-6 cache flush bits and was auto-set but only for
removable disks (after Alan's fixes in 2.6.65).  You lucky b*st*rds.  ;-)

Rene, that's why wcache is 0 in /proc/ide/hdX/settings for older kernels
or with my 'bandaid' fixes for 2.6.6.  'hdparm -W1' should work but only on
quite recent drives (having ATA-6 bits).  However I don't know why you get
regression in tiobench, we still need to explain this.

Andrew, I will send some patches to you today/tomorrow.

> Note that this only affects newer drives (last 18 months or so) that
> are <120GB. (Yes, I know that is still a truckload)
>
> There are a gazillion of these in the field (we sell ~60 million
> drives/year?) so I don't believe a firmware "upgrade" or equivalent
> simply is logistically possible, but this inconsistency is going to be
> addressed in future products, I'm making sure of it.

Yep, I don't think firmware 'upgrade' is needed/feasable.

Cheers.

Re: Linux 2.6.6 "IDE cache-flush at shutdown fixes"

[Rene Herman]

Bartlomiej Zolnierkiewicz wrote:

> The other part of the story is a nasty bug in ide-disk.c driver:
> 
> write_cache() is called with (drive->id->cfs_enable_2 & 0x300) as argument
> 'arg' of type 'int' and then this value is assigned to the 'drive->wcache'
> of type 'unsigned char' so drive->wcache == 0 because 0x3000 gets truncated.
> 
> This bug has been present since introduction of drive->wcache (2.5.3),
> therefore we have never handled cache flush correctly before and never
> hit '& 0x2400' problem before.
> 
> Linus & Alan, you were almost right after all, drive->wcache was almost
> always zero for normal disks before 2.6.6.  It could be forced by user but
> only for disks having ATA-6 cache flush bits and was auto-set but only for
> removable disks (after Alan's fixes in 2.6.65).  You lucky b*st*rds.  ;-)
> 
> Rene, that's why wcache is 0 in /proc/ide/hdX/settings for older kernels
> or with my 'bandaid' fixes for 2.6.6.  'hdparm -W1' should work but only on
> quite recent drives (having ATA-6 bits).  However I don't know why you get
> regression in tiobench, we still need to explain this.

I'm afraid I can explain it. Even though hdparm -W0/-W1 didn't show up 
in the settings, they certainly do take effect (on this drive). The bad 
results I posted appear to have been with -W0. By default, and after 
-W1, it's back up to normal again. Sorry if I confused the issue.

Rene.

Re: Linux 2.6.6 "IDE cache-flush at shutdown fixes"

[Gene Heskett]

On Wednesday 12 May 2004 14:52, Eric D. Mudama wrote:
>On Wed, May 12 at  0:09, Robert Hancock wrote:
>>If this is indeed the case, that those drives don't support the
>> "flush write cache" command, I'd like to see Maxtor's excuse as to
>> why.. I believe that Windows always powers down IDE drives before
>> shutdown, maybe this is because of non-universal support for the
>> "flush write cache" command?
>
>The issue is a bit more subtle, and I'm not making an "excuse" per
>say...
>
>(Not speaking officially for Maxtor, but I'm just trying to help...)
>
>
>As per the email I got from Bart, the drive in question doesn't
>support 48-bit commands.  The wierdness is that it claims to support
>the FLUSH CACHE EXT (0xEA) command.  Obviously, this combination
>doesn't make it safe to issue FLUSH CACHE EXT since the drive will
> not be able to properly report a failing location in the event of a
> failure to flush due to a fatal write fault.  The drive knows a
> FLUSH CACHE EXT command isn't safe, so it aborts that command which
> is the error message you see.
>
>The code that Bart showed me does a '&' on the feature word with the
>required support bits, but uses the result in an 'if' conditional. 
> I believe that means that in C, if either of the bits is set, then
> the 'if' will evaluate to true, which is causing the problem.
>
>The solution (that should work for all drives) would be to test
>properly to make sure the drive reports support for both 48-bit
>commands and FLUSH CACHE EXT, with something like:
>
>  if ((feature & bits) == bits)
>
>then issue that command.  If *either* of these bits is false, then
> the drive should be issued a normal FLUSH CACHE (0xE7) command
> (which is a reasonably standard 28-bit command, and all Maxtor
> drives support, including the models in question.)
>
>Note that this only affects newer drives (last 18 months or so) that
>are <120GB. (Yes, I know that is still a truckload)
>
>There are a gazillion of these in the field (we sell ~60 million
>drives/year?) so I don't believe a firmware "upgrade" or equivalent
>simply is logistically possible, but this inconsistency is going to
> be addressed in future products, I'm making sure of it.
>
>
>If anyone has questions, please don't hesitate to email and I'll do
> my best to help.

Thank you Eric, for such a clear explanation of the problem (I have 
one of those drives and was the one who made the second report I 
believe...  Now it seems that a fix can be written into our driver 
without a lot of fuss, so it becomes a non-issue for us once thats 
filtered thru Andrew and on up to Linus.

My Q for you, is, does M$ already have a similar workaround in their 
drivers?  Just curious. :)

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.22% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2004 by Maurice Eugene Heskett, all rights reserved.

Re: Linux 2.6.6 "IDE cache-flush at shutdown fixes"

[Eric D. Mudama]

On Wed, May 12 at 17:28, Gene Heskett wrote:
>Thank you Eric, for such a clear explanation of the problem (I have 
>one of those drives and was the one who made the second report I 
>believe...  Now it seems that a fix can be written into our driver 
>without a lot of fuss, so it becomes a non-issue for us once thats 
>filtered thru Andrew and on up to Linus.

Glad I could help.  As I said in a private email to a few people, I
fixed this for all future drives this morning, so that wierdness
shouldn't show up again.  If anyone notices anything wierd or has
questions, I'd be happy to hear about it and try to help.

>My Q for you, is, does M$ already have a similar workaround in their 
>drivers?  Just curious. :)

I am not privy to any "M$" driver code so I have no idea what is in
their driver.

--eric


-- 
Eric D. Mudama
edmudama@mail.bounceswoosh.org