[PATCH libata-dev-2.6 1/2] ata_dev_identify() check status fix

Hi Jeff,

    In the ata_dev_identify() function, ata_chk_status() is used to check whether an error has occurred.
However, in some error situation, the device's status register always reads 0x0. (Please see attached
dmesg below.)
And the error found by the state machine is not seen by ata_dev_identify().

Changes:
- use qc->private_data to carry the drv_stat returned from the state machine.
- ata_qc_complete_noop() saves the drv_stat to *(qc->private_data).
- ata_dev_identify() use the status returned from ata_qc_complete_noop(), instead of ata_chk_status().
- noisy PIO error printk() changed to DPRINTK()

Attached please find the patch 1/2 against the libata-dev-2.6 tree for your review. Thanks.

Albert

Signed-off-by: Albert Lee <albertcc <at> tw.ibm.com>
---------------------------------------
dmesg:
libata version 1.10 loaded.
pata_pdc2027x version 0.58
pata_pdc2027x: PLL input clock 32783 kHz
ata_device_add: ENTER
ata_host_add: ENTER
ata_port_start: prd alloc, virt c0000001ded82000, dma 19ae0000
ata1: PATA max UDMA/133 cmd 0xDE400 ctl 0xDDC02 bmdma 0xDEC00 irq 134
ata_host_add: ENTER
ata_port_start: prd alloc, virt c0000001de8c6000, dma 19af0000
ata2: PATA max UDMA/133 cmd 0xDE800 ctl 0xDE002 bmdma 0xDEC08 irq 134

[PATCH libata-dev-2.6 2/2] check status fix for ata_dev_set_xfermode, etc.

Hi Jeff,

    The same check status fix for the functions using ata_qc_complete_noop() :
i.e. ata_dev_set_xfermode(), ata_dev_init_params() and atapi_request_sense().

Changes:
- Get the status returned from ata_qc_complete_noop() and check it for possible error.

Attached please find the patch 2/2 against the libata-dev-2.6 tree for your review. Thanks.

Albert

Signed-off-by: Albert Lee <albertcc <at> tw.ibm.com>
---------------------------------------
--- libata-dev-2.6-mod/drivers/scsi/libata-core.c	2005-04-01 11:21:22.000000000 +0800
+++ libata-dev-2.6-mod2/drivers/scsi/libata-core.c	2005-04-01 11:22:07.000000000 +0800
 <at>  <at>  -52,9 +52,9  <at>  <at> 
  static unsigned int ata_busy_sleep (struct ata_port *ap,
  				    unsigned long tmout_pat,
  			    	    unsigned long tmout);
-static void ata_dev_init_params(struct ata_port *ap, struct ata_device *dev);
+static int ata_dev_init_params(struct ata_port *ap, struct ata_device *dev);
  static void ata_set_mode(struct ata_port *ap);
-static void ata_dev_set_xfermode(struct ata_port *ap, struct ata_device *dev);
+static int ata_dev_set_xfermode(struct ata_port *ap, struct ata_device *dev);
  static unsigned int ata_get_mode_mask(struct ata_port *ap, int shift);
  static int fgb(u32 bitmap);
  static int ata_choose_xfer_mode(struct ata_port *ap,
 <at>  <at>  -1885,12 +1885,13  <at>  <at> 
   *	LOCKING:

Re: [PATCH libata-dev-2.6 1/2] ata_dev_identify() check status fix

Albert Lee wrote:
> -    printk(KERN_WARNING "ata%u: PIO error, drv_stat 0x%x\n",
> -           ap->id, drv_stat);
> +    DPRINTK("ata%u: PIO error, drv_stat 0x%x\n", ap->id, drv_stat);

You'd probably want this to stay a printk so it persists when ATA_DEBUG 
is off, right?

BR
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH libata-dev-2.6 1/2] ata_dev_identify() check status fix

Brett Russ wrote:

> Albert Lee wrote:
> 
>> -    printk(KERN_WARNING "ata%u: PIO error, drv_stat 0x%x\n",
>> -           ap->id, drv_stat);
>> +    DPRINTK("ata%u: PIO error, drv_stat 0x%x\n", ap->id, drv_stat);
> 
> 
> You'd probably want this to stay a printk so it persists when ATA_DEBUG 
> is off, right?
> 
> BR

Hi Brett,

The problem is ata_pio_error() doesn't know whether the error condition is normal or not.
Only the caller that issued the command knows what's going on.
Please see the attached dmesg for an example.
If we print out error message each time ata_pio_error() is called, it might be too noisy.

Albert
============================================================================================================
Mar 31 18:57:28 linux kernel: libata version 1.10 loaded.
Mar 31 18:57:28 linux kernel: pata_pdc2027x version 0.58
Mar 31 18:57:28 linux kernel: pata_pdc2027x: PLL input clock 65552 kHz
Mar 31 18:57:28 linux kernel: ata1: PATA max UDMA/133 cmd 0xDE400 ctl 0xDDC02 bmdma 0xDEC00 irq 134
Mar 31 18:57:28 linux kernel: ata2: PATA max UDMA/133 cmd 0xDE800 ctl 0xDE002 bmdma 0xDEC08 irq 134
Mar 31 18:57:28 linux kernel: ata1: dev 0 cfg 49:0f00 82:4210 83:4000 84:4000 85:0000 86:0000 87:0000 88:0407

RE: 2.6.11, IDE: Strange scheduling behaviour: high-pri RT process not scheduled?

> > The following tests are made with 'IRQ 8' at 95, rtc_wakeup 
> at 89(99):
> > * Heavy mmap load, no oom: max jitter:     42.1% (   51 usec)
> > * Heavy mmap load, oom:    max jitter:  11989.2% (14635 usec)
> >   (but still "missed irqs: 0", so IRQ 8 was also blocked for 14 ms)
> 
> did you get any kernel messages in that time? (about missed 
> irqs, etc.)  
> Please do a 'dmesg -n 0' to minimize the effect of kernel messages.

Excellent, thanks!

It turned out that the latencies are not caused by the kernel
messages themselves, but by sending them to a serial console
(which was off), in all my high latency cases at rtpri 89(99).

After removing the serial console from the boot parameters,
* the OOM timings are back to normal (around 50 microseconds)
* the USB error and remove timings are back to normal
* the USB plugin timings are in the range of the USB read
  (which is up to 1 ms - still bad)

However, latencies at rtprio 2 are still very frustrating
(details will follow).

--

-- 
Klaus Kusche
Entwicklung Software - Steuerung
Software Development - Control

Booting from SATA disables IDE?

Hi,

I've a very serious and annoying problem I have tracked down to a
likely libata problem.

Here's the scenario:
I have a fileserver which, for temporary backup purposes, transfers
data from one drive to another. In order to get some nice SATA
equipment I decided to buy a SATA drive for which the mainboard
(AsRock K7VT4A Pro) already has the necessary facilities (sata_via).

Got the drive connected, loaded the drivers, checked for bad blocks,
partitioned and mkfs'ed the drive, mounted the new partitions: good.

Now the tricky part. After copying over the data from the old drive
the SATA is intended to replace, I installed a bootloader (grub),
forced the system (Debian testing) to rebuild the initrd for the
kernel (2.6.10) with the included sata_via driver and libata.
Rebooted, works: good.

However, I can not use the regular PATA Via driver anymore because
it simply will not detect any devices.

I checked mailinglists, google, even the sourcecode but there seems
to be no way to to make that work correctly.

So everytime I boot from SATA I cannot use PATA anymore because
the driver loads but doesn't work and vice versa (PATA before SATA)
does work but only in theory because I have no system on the PATA
drive and couldn't install one even if I wanted to (and I do not).

Re: Booting from SATA disables IDE?

Daniel Egger wrote:
> So everytime I boot from SATA I cannot use PATA anymore because
> the driver loads but doesn't work and vice versa (PATA before SATA)
> does work but only in theory because I have no system on the PATA
> drive and couldn't install one even if I wanted to (and I do not).

Well, sata_via never touches the VIA PATA side of things.  Probably a 
config or BIOS error, or similar.

> libata version 1.10 loaded.
> sata_via version 1.0
> ACPI: PCI interrupt 0000:00:0f.0[B] -> GSI 20 (level, low) -> IRQ 169
> sata_via(0000:00:0f.0): routed to hard irq line 11
> ata1: SATA max UDMA/133 cmd 0xEC00 ctl 0xE802 bmdma 0xDC00 irq 169
> ata2: SATA max UDMA/133 cmd 0xE400 ctl 0xE002 bmdma 0xDC08 irq 169
> ata1: dev 0 cfg 49:2f00 82:7c6b 83:7f09 84:4063 85:7c69 86:3e01 87:4063 
> 88:407f
> ata1: dev 0 ATA, max UDMA/133, 398297088 sectors: lba48
> ata1: dev 0 configured for UDMA/133
> scsi0 : sata_via
> ata2: no device found (phy stat 00000000)
> scsi1 : sata_via
> elevator: using anticipatory as default io scheduler
>   Vendor: ATA       Model: Maxtor 6B200M0    Rev: BANC
>   Type:   Direct-Access                      ANSI SCSI revision: 05
> SCSI device sda: 398297088 512-byte hdwr sectors (203928 MB)
> SCSI device sda: drive cache: write back
> SCSI device sda: 398297088 512-byte hdwr sectors (203928 MB)
> SCSI device sda: drive cache: write back
>  /dev/scsi/host0/bus0/target0/lun0: p1 p2 p3 p4

Re: Booting from SATA disables IDE?

On 01.04.2005, at 19:04, Jeff Garzik wrote:

> Well, sata_via never touches the VIA PATA side of things.  Probably a 
> config or BIOS error, or similar.

So I though but since since the device is visible on the PCI
bus at all times that strikes me a bit odd.

> Where's the IDE driver output?

...
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with 
idebus=xx
vesafb: probe of vesafb0 failed with error -6
NET: Registered protocol family 1
SCSI subsystem initialized
libata version 1.10 loaded.
sata_via version 1.0
ACPI: PCI interrupt 0000:00:0f.0[B] -> GSI 20 (level, low) -> IRQ 169
sata_via(0000:00:0f.0): routed to hard irq line 11
...

That's all.

One thing is pretty strange though which would support your
guess with the BIOS problem: I modified the Debian initrd
system to forcefully load the via82cxxx module before the
libata and sata_via driver but it still does not work, so
at least it doesn't seem to be the order in which the drivers

[BK PATCHES] ide-2.6 update

Hi Linus,

short ChangeLog:
* ide-default pseudo-driver is gone
* VIA resume failure is fixed

Bartlomiej

Please do a

 	bk pull bk://bart.bkbits.net/ide-2.6

This will update the following files:

  drivers/ide/ide-default.c   |   76 ---------------------------
  drivers/ide/Makefile        |    3 -
  drivers/ide/ide-cd.c        |   71 ++++++++++++++++---------
  drivers/ide/ide-cd.h        |    2
  drivers/ide/ide-disk.c      |   30 ++++++++--
  drivers/ide/ide-dma.c       |    8 ++
  drivers/ide/ide-floppy.c    |   48 ++++++++++++-----
  drivers/ide/ide-io.c        |   46 ++++++++++++----
  drivers/ide/ide-probe.c     |  122 +++++++++++++++++++++++---------------------
  drivers/ide/ide-proc.c      |   12 +---
  drivers/ide/ide-tape.c      |   41 ++++++++++++--
  drivers/ide/ide-taskfile.c  |   11 ++-
  drivers/ide/ide.c           |   86 ++++++++++++-------------------
  drivers/ide/pci/via82cxxx.c |    7 --
  drivers/scsi/ide-scsi.c     |   44 ++++++++++++---

Re: [PATCH libata-dev-2.6 1/2] ata_dev_identify() check status fix

Hi Jeff,

    Revised since lowlevel driver might use qc->private_data. qc->upper_private_data added instead.

Desc:
    In the ata_dev_identify() function, ata_chk_status() is used to check whether an error has occurred.
However, in some error situation, the device's status register always reads 0x0.
(Please see previously attached dmesg for detail.)
And the error found by the state machine is not seen by ata_dev_identify().

Changes:
- upper_private_data added to ata_queued_cmd
- use qc->upper_private_data to carry the drv_stat returned from the state machine.
- ata_qc_complete_noop() saves the drv_stat to *(qc->upper_private_data).
- ata_dev_identify() use the status returned from ata_qc_complete_noop(), instead of ata_chk_status().
- noisy PIO error printk() changed to DPRINTK()

Attached please find the revised patch 1/2 against the libata-dev-2.6 tree for your review. Thanks.

Albert

Signed-off-by: Albert Lee <albertcc <at> tw.ibm.com>

--- 1.74/include/linux/libata.h	2005-03-08 13:59:27 +08:00
+++ 1.75/include/linux/libata.h	2005-04-02 22:22:11 +08:00
 <at>  <at>  -256,6 +256,9  <at>  <at> 

 	struct completion	*waiting;