Subject: Still data corruption -> pci/ide handling problem?
To: None <>
From: Markus W Kilbinger <>
List: port-cobalt
Date: 02/05/2005 20:35:54

I'm still fighting (with -current)

mainly data corruption with disk/ide access in 'bigger amounts'.

This still happens with Izumi's patch:

In port-alpha there was some discussion about (mis-configured?) pci
latency timers:

Because /dev/pci0 does not exist/work for cobalt I recompiled a kernel
with PCIVERBOSE and PCI_CONFIG_DUMP to get some more info's about my
qube2's ide pci config (this is with Izumi's patch (see above)):

  viaide0 at pci0 dev 9 function 1: PCI configuration registers:
    Common header:
      0x00: 0x05711106 0x02800285 0x01018a06 0x00004000
      Vendor Name: VIA Technologies (0x1106)
      Device Name: VT82C586A IDE Controller (0x0571)
      Command register: 0x0285
        I/O space accesses: on
        Memory space accesses: off
        Bus mastering: on
        Special cycles: off
        MWI transactions: off
        Palette snooping: off
        Parity error checking: off
        Address/data stepping: on
        System error (SERR): off
        Fast back-to-back transactions: on
      Status register: 0x0280
        Capability List support: off
        66 MHz capable: off
        User Definable Features (UDF) support: off
        Fast back-to-back capable: on
        Data parity error detected: off
        DEVSEL timing: medium (0x1)
        Slave signaled Target Abort: off
        Master received Target Abort: off
        Master received Master Abort: off
        Asserted System Error (SERR): off
        Parity error detected: off
      Class Name: mass storage (0x01)
      Subclass Name: IDE (0x01)
      Interface: 0x8a
      Revision ID: 0x06
      BIST: 0x00
      Header Type: 0x00 (0x00)
      Latency Timer: 0x40
      Cache Line Size: 0x00
    Type 0 ("normal" device) header:
      0x10: 0x00000000 0x00000000 0x00000000 0x00000000
      0x20: 0x0000cc01 0x00000000 0x00000000 0x00000000
      0x30: 0x00000000 0x00000000 0x00000000 0x0000000e
      Base address register at 0x10
        not implemented(?)
      Base address register at 0x14
        not implemented(?)
      Base address register at 0x18
        not implemented(?)
      Base address register at 0x1c
        not implemented(?)
      Base address register at 0x20
        type: 32-bit i/o
        base: 0x0000cc00, size: 0x00000010
      Base address register at 0x24
        not implemented(?)
      Cardbus CIS Pointer: 0x00000000
      Subsystem vendor ID: 0x0000
      Subsystem ID: 0x0000
      Expansion ROM Base Address: 0x00000000
      Reserved @ 0x34: 0x00000000
      Reserved @ 0x38: 0x00000000
      Maximum Latency: 0x00
      Minimum Grant: 0x00
      Interrupt pin: 0x00 (none)
      Interrupt line: 0x0e
    Device-dependent header:
      0x40: 0x3a09020b 0x00c00068 0xa8a8a8a8 0xffff00ff
      0x50: 0x20030303 0x00000000 0xa8a8a8a8 0x00000000
      0x60: 0x00000200 0x00000000 0x00000200 0x00000000
      0x70: 0x00000002 0x00000000 0x00000002 0x00000000
      0x80: 0x004f2000 0x00000000 0x004f2800 0x00000000
      0x90: 0x00000000 0x00000000 0x00000000 0x00000000
      0xa0: 0x00000000 0x00000000 0x00000000 0x00000000
      0xb0: 0x00000000 0x00000000 0x00000000 0x00000000
      0xc0: 0x00000000 0x00000000 0x00000000 0x00000000
      0xd0: 0x05710006 0x00000000 0x00000000 0x00000000
      0xe0: 0x00000000 0x00000000 0x00000000 0x00000000
      0xf0: 0x00000000 0x00000000 0x00000000 0x00000000
      Don't know how to pretty-print device-dependent header.
  VIA Technologies VT82C586A IDE Controller (IDE mass storage, interface 0x8a, revision 0x06) at ? dev 9 function 1 (intrswiz 0, intrpin 0, i/o on, mem off, no quirks)
  viaide0: VIA Technologies VT82C586 (Apollo VP) ATA33 controller
  viaide0: bus-master DMA support present
  viaide0: primary channel configured to compatibility mode
  viaide0: primary channel interrupting at irq 14
  atabus0 at viaide0 channel 0
  viaide0: secondary channel configured to compatibility mode
  viaide0: secondary channel interrupting at irq 15
  atabus1 at viaide0 channel 1

Because I'm absolutely not familiar with this:

Are all these values/configs reasonable? (I can provide more
PCI_CONFIG_DUMP output if neccassry)

'Latency Timer: 0x40' looks reasonable, but what about 'Cache Line
Size: 0x00'?

I've found some linux code ( ) for
qube/raq where these values are explicitly set during initialization

  pci_write_config_byte(dev, PCI_LATENCY_TIMER, 64);
  pci_write_config_byte(dev, PCI_CACHE_LINE_SIZE, 7);

Is (from the same url)

  * On all machines prior to Q2, we had the STOP line disconnected
  * from Galileo to VIA on PCI. The new Galileo does not function
  * correctly unless we have it connected.
  * Therefore we must set the disconnect/retry cycle values to
  * something sensible when using the new Galileo.
  pci_read_config_word(dev, PCI_REVISION_ID, &galileo_id);
  galileo_id &= 0xff; /* mask off class info */
  if (galileo_id >= 0x10) {
  /* New Galileo, assumes PCI stop line to VIA is connected. */
  } else if (galileo_id == 0x1 || galileo_id == 0x2) {
  signed int timeo;
  /* Old Galileo, assumes PCI STOP line to VIA is disconnected. */

relevant for port-cobalt?

How and where could I inject code into -current's source to set pci
latency timer and cache line size for gt and viaide in netbsd-current
for testing purposes? (An example would be nice :-))

Any hint appreciated,