VIA SATA not recognizing drives

VIA SATA not recognizing drives

[Marc Singer]

In using a BK pull from linus's tree (Sat May 8) and applying Jeff
Garzik's Apr 26 patch, I'm not seeing my SATA drives.  I've tried
several kernel versions, from 2.6.3 up to this patched 2.6.6-rc?
version. 

The dmesg's seem to indicate that the driver is loading.

  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:0f.1
  VP_IDE: chipset revision 6
  VP_IDE: not 100% native mode: will probe irqs later
  VP_IDE: VIA vt8237 (rev 00) IDE UDMA133 controller on pci0000:00:0f.1
  ide0: BM-DMA at 0xfc00-0xfc07, BIOS settings: hda:DMA, hdb:pio
  ide1: BM-DMA at 0xfc08-0xfc0f, BIOS settings: hdc:DMA, hdd:pio
  hda: ST380021A, ATA DISK drive
  ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
  hdc: TOSHIBA CD-ROM XM-6202B, ATAPI CD/DVD-ROM drive
  ide1 at 0x170-0x177,0x376 on irq 15
  hda: max request size: 128KiB
  hda: 156301488 sectors (80026 MB) w/2048KiB Cache, CHS=65535/16/63, UDMA(100)
  hda: hda1
  libata version 1.02 loaded.
  sata_via version 0.20
  sata_via(0000:00:0f.0): routed to hard irq line 10
  ata1: SATA max UDMA/133 cmd 0xEC00 ctl 0xE802 bmdma 0xDC00 irq 10
  ata2: SATA max UDMA/133 cmd 0xE400 ctl 0xE002 bmdma 0xDC08 irq 10
  ata1: no device found (phy stat 00000000)
  ata1: thread exiting
  scsi0 : sata_via
  ata2: no device found (phy stat 00000000)
  ata2: thread exiting
  scsi1 : sata_via

Is there something else I should check?

Re: VIA SATA not recognizing drives

[Jeff Garzik]

Marc Singer wrote:
>   libata version 1.02 loaded.
>   sata_via version 0.20
>   sata_via(0000:00:0f.0): routed to hard irq line 10
>   ata1: SATA max UDMA/133 cmd 0xEC00 ctl 0xE802 bmdma 0xDC00 irq 10
>   ata2: SATA max UDMA/133 cmd 0xE400 ctl 0xE002 bmdma 0xDC08 irq 10
>   ata1: no device found (phy stat 00000000)
>   ata1: thread exiting
>   scsi0 : sata_via
>   ata2: no device found (phy stat 00000000)
>   ata2: thread exiting
>   scsi1 : sata_via


Those "phy stat 00000000" are the hardware saying there is no SATA 
device attached.

Are you sure you plugged them into the VIA SATA ports?  Maybe you have a 
Promise chip on-board too, or something like that?  Or SATA is disabled 
in BIOS?

	Jeff

Re: VIA SATA not recognizing drives

[Marc Singer]

On Sat, May 08, 2004 at 05:29:10PM -0400, Jeff Garzik wrote:
> Marc Singer wrote:
> >  libata version 1.02 loaded.
> >  sata_via version 0.20
> >  sata_via(0000:00:0f.0): routed to hard irq line 10
> >  ata1: SATA max UDMA/133 cmd 0xEC00 ctl 0xE802 bmdma 0xDC00 irq 10
> >  ata2: SATA max UDMA/133 cmd 0xE400 ctl 0xE002 bmdma 0xDC08 irq 10
> >  ata1: no device found (phy stat 00000000)
> >  ata1: thread exiting
> >  scsi0 : sata_via
> >  ata2: no device found (phy stat 00000000)
> >  ata2: thread exiting
> >  scsi1 : sata_via
> 
> 
> Those "phy stat 00000000" are the hardware saying there is no SATA 
> device attached.
> 
> Are you sure you plugged them into the VIA SATA ports?  Maybe you have a 
> Promise chip on-board too, or something like that?  Or SATA is disabled 
> in BIOS?

I'm embarassed to say, though not too proud to admit, that the power
cables weren't properly seated.  It's working just fine.

I have another question, though.  I've patched the ide driver to
permit an IDE interface to operate without an IRQ.  It needs a little
bit of tweaking before it will be accepted by that IDE maintainer.
Are you planning to subsume all of the IDE functionality into libata
that is handled by the other IDE driver?  If so, have you considered
adding polling mode?

Cheers.

Re: VIA SATA not recognizing drives

[Jeff Garzik]

Marc Singer wrote:
> On Sat, May 08, 2004 at 05:29:10PM -0400, Jeff Garzik wrote:
> 
>>Marc Singer wrote:
>>
>>> libata version 1.02 loaded.
>>> sata_via version 0.20
>>> sata_via(0000:00:0f.0): routed to hard irq line 10
>>> ata1: SATA max UDMA/133 cmd 0xEC00 ctl 0xE802 bmdma 0xDC00 irq 10
>>> ata2: SATA max UDMA/133 cmd 0xE400 ctl 0xE002 bmdma 0xDC08 irq 10
>>> ata1: no device found (phy stat 00000000)
>>> ata1: thread exiting
>>> scsi0 : sata_via
>>> ata2: no device found (phy stat 00000000)
>>> ata2: thread exiting
>>> scsi1 : sata_via
>>
>>
>>Those "phy stat 00000000" are the hardware saying there is no SATA 
>>device attached.
>>
>>Are you sure you plugged them into the VIA SATA ports?  Maybe you have a 
>>Promise chip on-board too, or something like that?  Or SATA is disabled 
>>in BIOS?
> 
> 
> I'm embarassed to say, though not too proud to admit, that the power
> cables weren't properly seated.  It's working just fine.
> 
> I have another question, though.  I've patched the ide driver to
> permit an IDE interface to operate without an IRQ.  It needs a little
> bit of tweaking before it will be accepted by that IDE maintainer.
> Are you planning to subsume all of the IDE functionality into libata
> that is handled by the other IDE driver?  If so, have you considered
> adding polling mode?


PIO code in libata operates exclusively in polling mode.

I'm not too confident of polling DMA being a good idea.

	Jeff

Re: VIA SATA not recognizing drives

[Marc Singer]

On Tue, May 11, 2004 at 02:54:27AM -0400, Jeff Garzik wrote:
> >I have another question, though.  I've patched the ide driver to
> >permit an IDE interface to operate without an IRQ.  It needs a little
> >bit of tweaking before it will be accepted by that IDE maintainer.
> >Are you planning to subsume all of the IDE functionality into libata
> >that is handled by the other IDE driver?  If so, have you considered
> >adding polling mode?
> 
> 
> PIO code in libata operates exclusively in polling mode.
> 
> I'm not too confident of polling DMA being a good idea.

In my case, there is no DMA.  The hardware I have on hand is
admittedly degenerate.  The only issue is that the existing IDE code
cannot work without interrupts.  While I made patches to the ide
driver to make this work, I'd rather hitch my pony to something less
hack-ish.

In a cursory overview of libata, here's what stands out in my
special-needs case.

  1) PIO stands for port-IO which I interpret as register-level IO
     which, I assume, contrasts with task-file or mailbox type IO.
  2) Libata does have an MMIO mode, nice.  My platform is ARM.  While
     these calls will work, I have a further requirement that all
     register IO must be followed by the hokey-pokey to work around
     some oddities in the hardware.  Yes, I've suggested that they fix
     the problem in hardware.  So, how can be make this configurable?
     For me, it is OK that all IDE io would require the hack.  In
     other words, even if there were another IDE controller that
     worked properly it would be OK for both to need the hack.
  3) If a device has no DMA, how do you plan to handle the data
     transfer?  Is this what ata_pio_sector() is doing?
  4) Is ata_piix.c the model? 

It doesn't really look that tough.  The only thing I'm unclear about
is how to handle read/write with the requisite hokey-pokey.
  

 

Re: VIA SATA not recognizing drives

[Jeff Garzik]

Marc Singer wrote:
> In a cursory overview of libata, here's what stands out in my
> special-needs case.
> 
>   1) PIO stands for port-IO which I interpret as register-level IO
>      which, I assume, contrasts with task-file or mailbox type IO.

There are two different things known as PIO:
a) x86-style 'IN' and 'OUT' instructions for bus IO
b) data transfer via ATA's Data register.  In some bizarre situations 
you have PIO over DMA, initiated by MMIO.  :)

so be prepared to be confused ;-)


>   2) Libata does have an MMIO mode, nice.  My platform is ARM.  While
>      these calls will work, I have a further requirement that all
>      register IO must be followed by the hokey-pokey to work around
>      some oddities in the hardware.  Yes, I've suggested that they fix
>      the problem in hardware.  So, how can be make this configurable?
>      For me, it is OK that all IDE io would require the hack.  In
>      other words, even if there were another IDE controller that
>      worked properly it would be OK for both to need the hack.

Everything is done via custom hooks you provide, in struct 
ata_port_operations.


>   3) If a device has no DMA, how do you plan to handle the data
>      transfer?  Is this what ata_pio_sector() is doing?

Correct.


>   4) Is ata_piix.c the model? 

I don't know your hardware at all, so I cannot say.

All of drivers/scsi/ata_*.c drivers/scsi/sata_*.c are the model :)


> It doesn't really look that tough.  The only thing I'm unclear about
> is how to handle read/write with the requisite hokey-pokey.

libata needs a hook for PIO data xfer, since it is currently hardcoded 
to use outsl() and insl().  Other than that, existing 
ata_port_operations hooks can do that "hokey-pokey".

	Jeff

Re: VIA SATA not recognizing drives

[Marc Singer]

On Wed, May 19, 2004 at 10:14:38PM -0400, Jeff Garzik wrote:
> >  2) Libata does have an MMIO mode, nice.  My platform is ARM.  While
> >     these calls will work, I have a further requirement that all
> >     register IO must be followed by the hokey-pokey to work around
> >     some oddities in the hardware.  Yes, I've suggested that they fix
> >     the problem in hardware.  So, how can be make this configurable?
> >     For me, it is OK that all IDE io would require the hack.  In
> >     other words, even if there were another IDE controller that
> >     worked properly it would be OK for both to need the hack.
> 
> Everything is done via custom hooks you provide, in struct 
> ata_port_operations.

Nice.

> >  4) Is ata_piix.c the model? 
> 
> I don't know your hardware at all, so I cannot say.
> 
> All of drivers/scsi/ata_*.c drivers/scsi/sata_*.c are the model :)

OK.  That's helpful.

> >It doesn't really look that tough.  The only thing I'm unclear about
> >is how to handle read/write with the requisite hokey-pokey.
> 
> libata needs a hook for PIO data xfer, since it is currently hardcoded 
> to use outsl() and insl().  Other than that, existing 
> ata_port_operations hooks can do that "hokey-pokey".

Excellent.  Thanks.