31244 & sata_vsc & PPC

31244 & sata_vsc & PPC

[Ajit Prem]

The email archives indicate that sata_vsc worked
on a 31244 in a Dell Powervault once the
kernel included the following configuration:

Processor type and features -> Local APIC support on uniprocessors
Processor type and features -> IO-APIC support on uniprocessors
General setup -> Power Management support -> ACPI Support

Trying to use sata_vsc on a 31244 in a PPC board
results in the same problem as other users had on
an X86 board configured without ACPI support - interrupts
come in too early to vsc_sata_interrupt, the interrupt
doesn't get cleared, and the kernel finally disables the irq.
What should one do to get sata_vsc/libata to work on a PPC board?


Using kernel 2.6.10 with only 1 disk connected to port 2.

bash-2.05b# modprobe sata_vsc
ata_device_add: ENTER
ata_host_add: ENTER
ata_port_start: prd alloc, virt ded0c000, dma 1ed0c000
ata_host_add: ENTER
ata_port_start: prd alloc, virt decd3000, dma 1ecd3000
ata_host_add: ENTER
ata_port_start: prd alloc, virt decc7000, dma 1ecc7000
ata_host_add: ENTER
ata_port_start: prd alloc, virt ded00000, dma 1ed00000
ata_device_add: probe begin
ata_device_add: ata1: probe begin
ata_device_add: ata1: probe end
ata_device_add: ata2: probe begin
ata_bus_reset: ENTER, host 2, port 1
ata_dev_classify: found ATA device by sig
ata_bus_reset: EXIT
ata_dev_identify: ENTER, host 2, dev 0
ata_dev_select: ENTER, ata2: device 0, wait 1
ata_dev_identify: do ATA identify
ata_dev_select: ENTER, ata2: device 0, wait 1
ata_exec_command_mmio: ata2: cmd 0xEC
irq 98: nobody cared!
Call trace:
 [c003bd8c] __report_bad_irq+0x38/0xb8
 [c003bef8] note_interrupt+0xd0/0x108
 [c003b868] __do_IRQ+0x174/0x184
 [c0003a70] do_IRQ+0x38/0xa0
 [c0002838] ret_from_except+0x0/0x18
 [c0003b28] default_idle+0x50/0x5c
 [c0001c44] rest_init+0x24/0x34
 [c0342630] start_kernel+0x174/0x1b4
 [c000037c] skpinv+0x2ac/0x2e8
handlers:
[<e1078348>] (vsc_sata_interrupt+0x0/0xcc [sata_vsc])
Disabling IRQ #98
ata_pio_sector: data read
ata_qc_complete: EXIT
ata_dump_id: 49==0x2b00  53==0x0007  63==0x0407  64==0x0003  75==0x0000 
ata_dump_id: 80==0x007c  81==0x0019  82==0x346b  83==0x5b68  84==0x4003 
ata_dump_id: 88==0x003f  93==0x600b
ata_dev_identify: EXIT, drv_stat = 0x50
ata_dev_identify: ENTER/EXIT (host 2, dev 1) -- nodev
ata_host_set_pio: base 0x8 xfer_mode 0xc mask 0x1f x 4
ata_dev_set_xfermode: set features - xfer mode
ata_dev_select: ENTER, ata2: device 0, wait 1
ata_exec_command_mmio: ata2: cmd 0xEF

Message from syslogd@vmeexec at Wed Feb 16 11:47:39 2005 ...
vmeexec kernel: Disabling IRQ #98


The modprobe command hangs. The machine is usable
otherwise.

bash-2.05b# cat /proc/interrupts
           CPU0      
 77:       4891   OpenPIC   Level     enet_tx
 78:       5666   OpenPIC   Level     enet_rx
 82:          0   OpenPIC   Level     enet_error
 90:        257   OpenPIC   Level     serial
 96:          3   OpenPIC   Level     VMEBus (Tsi148)
 98:     100000   OpenPIC   Level     libata
100:          0   OpenPIC   Level     ohci_hcd
101:          0   OpenPIC   Level     ohci_hcd
102:          0   OpenPIC   Level     ehci_hcd
106:          2   OpenPIC   Level     phy_interrupt
BAD:          0


# lscpi -vvvxxx

00:04.0 Class 0106: 8086:3200
        Subsystem: 8086:3200
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
ParErr- Step
ping- SERR- FastB2B-
        Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
<TAbort
- <MAbort- >SERR- <PERR-
        Latency: 128 (4000ns min, 250ns max), cache line size 08
        Interrupt: pin A routed to IRQ 98
        Region 0: Memory at dfaff000 (64-bit, non-prefetchable) [size=4K]
        Capabilities: [e0] PCI-X non-bridge device.
                Command: DPERE- ERO+ RBC=0 OST=3
                Status: Bus=255 Dev=4 Func=0 64bit+ 133MHz+ SCD- USC-, 
DC=simple
, DMMRBC=0, DMOST=3, DMCRS=1, RSCEM-    Capabilities: [e8] Power 
Management vers
ion 2
                Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA 
PME(D0-,D1-,D2-,D3hot
-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [f0] Message Signalled Interrupts: 64bit+ 
Queue=0/2 Enable
-
                Address: 0000000000000000  Data: 0000
00: 86 80 00 32 07 00 30 02 00 00 06 01 08 80 00 00
10: 04 f0 af df 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 00 32
30: 00 00 00 00 e0 00 00 00 00 00 00 00 62 01 10 01
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 03 80 00 08 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 82
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 07 e8 32 00 20 ff 83 05 01 f0 22 00 00 00 00 00
f0: 05 00 84 00 00 00 00 00 00 00 00 00 00 00 00 00

Thanks,

AP

Re: 31244 & sata_vsc & PPC

[Jeff Garzik]

On Wed, Feb 16, 2005 at 12:05:16PM -0700, Ajit Prem wrote:
> The email archives indicate that sata_vsc worked
> on a 31244 in a Dell Powervault once the
> kernel included the following configuration:
> 
> Processor type and features -> Local APIC support on uniprocessors
> Processor type and features -> IO-APIC support on uniprocessors
> General setup -> Power Management support -> ACPI Support
> 
> Trying to use sata_vsc on a 31244 in a PPC board
> results in the same problem as other users had on
> an X86 board configured without ACPI support - interrupts
> come in too early to vsc_sata_interrupt, the interrupt
> doesn't get cleared, and the kernel finally disables the irq.
> What should one do to get sata_vsc/libata to work on a PPC board?

Ultimately I wonder if sata_vsc is masking/clearing all interrupt
conditions during startup.

There might also be a problem with PIO polling.

	Jeff

Re: 31244 & sata_vsc & PPC

[Ajit Prem]

Thanks for the help.

I printed the int_status register on interrupt
entry into vsc_sata_interrupt and got 0x8300.
According to the 31244 spec, this means (I have
only 1 disk connected to port 1) :

-- SATA Port 1 IDE Interrupt (0x8000)
-- SATA Port 1 PHY Ready Interrupt (0x0200)
-- SATA Port 1 Phy Change State Interrupt (0x0100)

Any patch I can try?

Thanks,

AP


Jeff Garzik wrote:

>On Wed, Feb 16, 2005 at 12:05:16PM -0700, Ajit Prem wrote:
>  
>
>>The email archives indicate that sata_vsc worked
>>on a 31244 in a Dell Powervault once the
>>kernel included the following configuration:
>>
>>Processor type and features -> Local APIC support on uniprocessors
>>Processor type and features -> IO-APIC support on uniprocessors
>>General setup -> Power Management support -> ACPI Support
>>
>>Trying to use sata_vsc on a 31244 in a PPC board
>>results in the same problem as other users had on
>>an X86 board configured without ACPI support - interrupts
>>come in too early to vsc_sata_interrupt, the interrupt
>>doesn't get cleared, and the kernel finally disables the irq.
>>What should one do to get sata_vsc/libata to work on a PPC board?
>>    
>>
>
>Ultimately I wonder if sata_vsc is masking/clearing all interrupt
>conditions during startup.
>
>There might also be a problem with PIO polling.
>
>	Jeff
>
>
>
>  
>

Re: 31244 & sata_vsc & PPC

[Jeremy Higdon]

On Wed, Feb 16, 2005 at 01:51:24PM -0700, Ajit Prem wrote:
> 
> Thanks for the help.
> 
> I printed the int_status register on interrupt
> entry into vsc_sata_interrupt and got 0x8300.
> According to the 31244 spec, this means (I have
> only 1 disk connected to port 1) :
> 
> -- SATA Port 1 IDE Interrupt (0x8000)
> -- SATA Port 1 PHY Ready Interrupt (0x0200)
> -- SATA Port 1 Phy Change State Interrupt (0x0100)
> 
> Any patch I can try?
> 
> Thanks,
> 
> AP

Interesting that I haven't seen this, but then I only have
the Vitesse part.

Jeff, I don't see where libata-core writes to the SCR_ERROR
register to clear the PHY Ready and Phy Change State interrupts.
Is this something that sata_vsc is supposed to do in its
interrupt handler?  The core would miss such info if sata_vsc
did this . . . .

jeremy

Re: 31244 & sata_vsc & PPC

[Ajit Prem]

As a follow-up to my previous email where
I indicated that int_status on entry into
vsc_sata_interrupt indicates 0x8300, I
put in a crude fix in the vsc_sata_interrupt
handler to read the taskfile status register,
and to clear the appropriate bits in the
SATA SError register, and now things work
just fine.

Thank you very much for your help.

AP


Jeff Garzik wrote:

>On Wed, Feb 16, 2005 at 12:05:16PM -0700, Ajit Prem wrote:
>  
>
>>The email archives indicate that sata_vsc worked
>>on a 31244 in a Dell Powervault once the
>>kernel included the following configuration:
>>
>>Processor type and features -> Local APIC support on uniprocessors
>>Processor type and features -> IO-APIC support on uniprocessors
>>General setup -> Power Management support -> ACPI Support
>>
>>Trying to use sata_vsc on a 31244 in a PPC board
>>results in the same problem as other users had on
>>an X86 board configured without ACPI support - interrupts
>>come in too early to vsc_sata_interrupt, the interrupt
>>doesn't get cleared, and the kernel finally disables the irq.
>>What should one do to get sata_vsc/libata to work on a PPC board?
>>    
>>
>
>Ultimately I wonder if sata_vsc is masking/clearing all interrupt
>conditions during startup.
>
>There might also be a problem with PIO polling.
>
>	Jeff
>
>
>
>  
>

Re: 31244 & sata_vsc & PPC

[Jeff Garzik]

Ajit Prem wrote:
> 
> As a follow-up to my previous email where
> I indicated that int_status on entry into
> vsc_sata_interrupt indicates 0x8300, I
> put in a crude fix in the vsc_sata_interrupt
> handler to read the taskfile status register,
> and to clear the appropriate bits in the
> SATA SError register, and now things work
> just fine.

Wanna post your crude patch to the list?

	Jeff

Re: 31244 & sata_vsc & PPC

[Ajit Prem]

It's just a dirty hack that works
for the limited case where I'm
using only 1 disk off port 1 on a
board that makes 3 ports available.
I'm not sure what the side effects
are, or how things will work if
all 3 ports are used (which I'm
unable to test).

Anyway, here's the hack I used:

@@ -174,6 +174,9 @@
    if (ap && (!(ap->flags & ATA_FLAG_PORT_DISABLED))) {
        struct ata_queued_cmd *qc;
 
+       vsc_sata_scr_write(ap, VSC_SATA_SCR_ERROR_OFFSET, 0x00010001);
+       readl((void *)ap->ioaddr.status_addr);
+
        qc = ata_qc_from_tag(ap, ap->active_tag);
        if (qc && (!(qc->tf.ctl & ATA_NIEN)))
            handled += ata_host_intr(ap, qc);


Now, on "modprobe sata_vsc", I get:

 ata1: SATA max UDMA/133 cmd 0xE107C200 ctl 0xE107C229 bmdma 0xE107C270 
irq 98
 ata2: SATA max UDMA/133 cmd 0xE107C400 ctl 0xE107C429 bmdma 0xE107C470 
irq 98
 ata3: SATA max UDMA/133 cmd 0xE107C600 ctl 0xE107C629 bmdma 0xE107C670 
irq 98
 ata4: SATA max UDMA/133 cmd 0xE107C800 ctl 0xE107C829 bmdma 0xE107C870 
irq 98
 ata1: no device found (phy stat 00000000)
 scsi0 : sata_vsc
 ata2: dev 0 ATA, max UDMA/100, 78140160 sectors:
 ata2(0): applying bridge limits
 ata2: dev 0 configured for UDMA/100
 scsi1 : sata_vsc
 ata3: no device found (phy stat 00000000)
 scsi2 : sata_vsc
 ata4: no device found (phy stat 00000000)
 scsi3 : sata_vsc
   Vendor: ATA       Model: FUJITSU MHS2040A  Rev   : C003
   Type:   Direct-Access                      ANSI SCSI revision: 05
 SCSI device sda: 78140160 512-byte hdwr sectors (40008 MB)
 SCSI device sda: drive cache: write back
 SCSI device sda: 78140160 512-byte hdwr sectors (40008 MB)
 SCSI device sda: drive cache: write back
  sda: sda1 sda2 sda3
 Attached scsi disk sda at scsi1, channel 0, id 0, lun 0
 Attached scsi generic sg0 at scsi1, channel 0, id 0, lun 0,  type 0


I can then fdisk, mount, and use the SATA disk with no problems.

AP


Jeff Garzik wrote:

> Ajit Prem wrote:
>
>>
>> As a follow-up to my previous email where
>> I indicated that int_status on entry into
>> vsc_sata_interrupt indicates 0x8300, I
>> put in a crude fix in the vsc_sata_interrupt
>> handler to read the taskfile status register,
>> and to clear the appropriate bits in the
>> SATA SError register, and now things work
>> just fine.
>
>
> Wanna post your crude patch to the list?
>
>     Jeff
>
>
>

Re: 31244 & sata_vsc & PPC

[Jeremy Higdon]

On Wed, Feb 16, 2005 at 06:21:46PM -0700, Ajit Prem wrote:
> 
> It's just a dirty hack that works
> for the limited case where I'm
> using only 1 disk off port 1 on a
> board that makes 3 ports available.
> I'm not sure what the side effects
> are, or how things will work if
> all 3 ports are used (which I'm
> unable to test).
> 
> Anyway, here's the hack I used:
> 
> @@ -174,6 +174,9 @@
>    if (ap && (!(ap->flags & ATA_FLAG_PORT_DISABLED))) {
>        struct ata_queued_cmd *qc;
> 
> +       vsc_sata_scr_write(ap, VSC_SATA_SCR_ERROR_OFFSET, 0x00010001);

I think this should be 0x00010002, since you're trying to clear
bits 1 and 16.

> +       readl((void *)ap->ioaddr.status_addr);
> +
>        qc = ata_qc_from_tag(ap, ap->active_tag);
>        if (qc && (!(qc->tf.ctl & ATA_NIEN)))
>            handled += ata_host_intr(ap, qc);


jeremy