libata machine check on Alpha

libata machine check on Alpha

[Jonathan Blake Benson]

I posted a couple of months ago regarding enabling libata.atapi on a
Digital Alpha 164LX, equipped with a Silicon Image 3114 controller.  I
decied to give kernel 2.6.16 (release, was previously using rc-1) a
shot, and it no longer longer panics.  I still have a Lite-ON DVD ROM
drive connected via a sil3611 bridge to port number 4, hoping that I
can avoid using the onboard CMD646.

No panic this time, though it appears to throw a machine check.  The
system continues all the way to multi-user, and the Maxtor drives are
usable.  Hope the attached dmesg helps.  Let me know if I can be of
any assitance.

Jonathan Benson


libata version 1.20 loaded.
sata_sil 0000:00:09.0: version 0.9
sata_sil 0000:00:09.0: cache line size not set.  Driver may not
function
sata_sil 0000:00:09.0: Applying R_ERR on DMA activate FIS errata fix
PCI: Setting latency timer of device 0000:00:09.0 to 64
ata1: SATA max UDMA/100 cmd 0xFFFFFC88093C1080 ctl 0xFFFFFC88093C108A
bmdma 0xFFFFFC88093C1000 irq 19
ata2: SATA max UDMA/100 cmd 0xFFFFFC88093C10C0 ctl 0xFFFFFC88093C10CA
bmdma 0xFFFFFC88093C1008 irq 19
ata3: SATA max UDMA/100 cmd 0xFFFFFC88093C1280 ctl 0xFFFFFC88093C128A
bmdma 0xFFFFFC88093C1200 irq 19
ata4: SATA max UDMA/100 cmd 0xFFFFFC88093C12C0 ctl 0xFFFFFC88093C12CA
bmdma 0xFFFFFC88093C1208 irq 19
ata1: SATA link up 1.5 Gbps (SStatus 113)
ata1: dev 0 cfg 49:2f00 82:7c6b 83:7b09 84:4003 85:7c68 86:3a01
87:4003 88:007f
ata1: dev 0 ATA-7, max UDMA/133, 240121728 sectors: LBA
ata1(0): applying bridge limits
ata1: dev 0 configured for UDMA/100
scsi0 : sata_sil
ata2: SATA link up 1.5 Gbps (SStatus 113)
ata2: dev 0 cfg 49:2f00 82:7c6b 83:7b09 84:4003 85:7c69 86:3a01
87:4003 88:007f
ata2: dev 0 ATA-7, max UDMA/133, 240121728 sectors: LBA
ata2(0): applying bridge limits
ata2: dev 0 configured for UDMA/100
scsi1 : sata_sil
ata3: SATA link up 1.5 Gbps (SStatus 113)
ata3: dev 0 cfg 49:2f00 82:7c6b 83:7b09 84:4003 85:7c69 86:3a01
87:4003 88:007f
ata3: dev 0 ATA-7, max UDMA/133, 240121728 sectors: LBA
ata3(0): applying bridge limits
ata3: dev 0 configured for UDMA/100
scsi2 : sata_sil
ata4: SATA link up 1.5 Gbps (SStatus 113)
ata4: dev 0 cfg 49:0b00 82:0210 83:1000 84:0000 85:0000 86:0000
87:0000 88:0007
ata4: dev 0 ATAPI, max UDMA/33
ata4: dev 0 configured for UDMA/33
scsi3 : sata_sil
  Vendor: ATA       Model: Maxtor 6Y120P0    Rev: YAR4
  Type:   Direct-Access                      ANSI SCSI revision: 05
  Vendor: ATA       Model: Maxtor 6Y120P0    Rev: YAR4
  Type:   Direct-Access                      ANSI SCSI revision: 05
  Vendor: ATA       Model: Maxtor 6Y120P0    Rev: YAR4
  Type:   Direct-Access                      ANSI SCSI revision: 05
CIA machine check: vector=0x670 pc=0xfffffc000053af50 code=0x98
machine check type: processor detected hard error
pc = [<fffffc000053af50>]  ra = [<fffffc0000540078>]  ps = 0007    Not
tainted
pc is at ata_altstatus+0x30/0x90
ra is at ata_qc_timeout+0x168/0x180
v0 = 0000000000000000  t0 = fffffc88093c12ca  t1 = fffffc88093c1208
t2 = fffffc8900000000  t3 = fffffc001fcdb418  t4 = 0000000000000000
t5 = 0000000017bfabb0  t6 = 0000000000000000  t7 = fffffc001fcf0000
a0 = fffffc001fcdb418  a1 = fffffc00006f5f38  a2 = fffffc001ff8b960
a3 = 0000000000000000  a4 = 0000000000000000  a5 = 0000000000000001
t8 = 000000000000001f  t9 = 000000000008bb52  t10= 0000000000000000
t11= 0000000000000000  pv = 0000000000000000  at = 0000000000000000
gp = fffffc0000788600  sp = fffffc001fcf3ad8
ata4: command 0xa0 timeout, stat 0xf8 host_stat 0x0
ata4: translated ATA stat/err 0xf8/00 to SCSI SK/ASC/ASCQ 0xb/47/00
SCSI device sda: 240121728 512-byte hdwr sectors (122942 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write back
SCSI device sda: 240121728 512-byte hdwr sectors (122942 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write back
 sda: sda1
sd 0:0:0:0: Attached scsi disk sda
SCSI device sdb: 240121728 512-byte hdwr sectors (122942 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: drive cache: write back
SCSI device sdb: 240121728 512-byte hdwr sectors (122942 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: drive cache: write back
 sdb: sdb1
sd 1:0:0:0: Attached scsi disk sdb
SCSI device sdc: 240121728 512-byte hdwr sectors (122942 MB)
sdc: Write Protect is off
sdc: Mode Sense: 00 3a 00 00
SCSI device sdc: drive cache: write back
SCSI device sdc: 240121728 512-byte hdwr sectors (122942 MB)
sdc: Write Protect is off
sdc: Mode Sense: 00 3a 00 00
SCSI device sdc: drive cache: write back
 sdc: sdc1
sd 2:0:0:0: Attached scsi disk sdc
sd 0:0:0:0: Attached scsi generic sg0 type 0
sd 1:0:0:0: Attached scsi generic sg1 type 0
sd 2:0:0:0: Attached scsi generic sg2 type 0

Re: libata machine check on Alpha

[Tejun Heo]

Jonathan Blake Benson wrote:
> I posted a couple of months ago regarding enabling libata.atapi on a
> Digital Alpha 164LX, equipped with a Silicon Image 3114 controller.  I
> decied to give kernel 2.6.16 (release, was previously using rc-1) a
> shot, and it no longer longer panics.  I still have a Lite-ON DVD ROM
> drive connected via a sil3611 bridge to port number 4, hoping that I
> can avoid using the onboard CMD646.
> 
> No panic this time, though it appears to throw a machine check.  The
> system continues all the way to multi-user, and the Maxtor drives are
> usable.  Hope the attached dmesg helps.  Let me know if I can be of
> any assitance.
> 

Can you build your kernel with ATA_DEBUG set and post dmesg?  Just 
change #undef ATA_DEBUG to #define ATA_DEBUG at the top of 
include/linux/libata.h

-- 
tejun

Re: libata machine check on Alpha

[Albert Lee]

Tejun Heo wrote:
> Jonathan Blake Benson wrote:
> 
>> I posted a couple of months ago regarding enabling libata.atapi on a
>> Digital Alpha 164LX, equipped with a Silicon Image 3114 controller.  I
>> decied to give kernel 2.6.16 (release, was previously using rc-1) a
>> shot, and it no longer longer panics.  I still have a Lite-ON DVD ROM
>> drive connected via a sil3611 bridge to port number 4, hoping that I
>> can avoid using the onboard CMD646.
>>
>> No panic this time, though it appears to throw a machine check.  The
>> system continues all the way to multi-user, and the Maxtor drives are
>> usable.  Hope the attached dmesg helps.  Let me know if I can be of
>> any assitance.
>>
> 
> Can you build your kernel with ATA_DEBUG set and post dmesg?  Just
> change #undef ATA_DEBUG to #define ATA_DEBUG at the top of
> include/linux/libata.h
> 

For the SiI 3611 bridge + ATAPI devices, maybe the ATAPI_ENABLE_DMADIR
workaround should also be turned on as well. (in linux/libata.h)

My JMicron 20330 bridge + SiI 3112 can handle ATAPI DMA without
the ATAPI_ENABLE_DMADIR workaround. However, the SiI 3611 bridge seems
need it.
--
Albert

Re: libata machine check on Alpha

[Tejun Heo]

Albert Lee wrote:
> Tejun Heo wrote:
>> Jonathan Blake Benson wrote:
>>
>>> I posted a couple of months ago regarding enabling libata.atapi on a
>>> Digital Alpha 164LX, equipped with a Silicon Image 3114 controller.  I
>>> decied to give kernel 2.6.16 (release, was previously using rc-1) a
>>> shot, and it no longer longer panics.  I still have a Lite-ON DVD ROM
>>> drive connected via a sil3611 bridge to port number 4, hoping that I
>>> can avoid using the onboard CMD646.
>>>
>>> No panic this time, though it appears to throw a machine check.  The
>>> system continues all the way to multi-user, and the Maxtor drives are
>>> usable.  Hope the attached dmesg helps.  Let me know if I can be of
>>> any assitance.
>>>
>> Can you build your kernel with ATA_DEBUG set and post dmesg?  Just
>> change #undef ATA_DEBUG to #define ATA_DEBUG at the top of
>> include/linux/libata.h
>>
> 
> For the SiI 3611 bridge + ATAPI devices, maybe the ATAPI_ENABLE_DMADIR
> workaround should also be turned on as well. (in linux/libata.h)
> 
> My JMicron 20330 bridge + SiI 3112 can handle ATAPI DMA without
> the ATAPI_ENABLE_DMADIR workaround. However, the SiI 3611 bridge seems
> need it.

Is there any way to make this thing automatic?  'Recompile with #define 
tweak if you have some invisible bridge chip' doesn't sound too hot.

-- 
tejun

Re: libata machine check on Alpha

[Albert Lee]

Tejun Heo wrote:
> Albert Lee wrote:
> 
>> Tejun Heo wrote:
>>
>>> Jonathan Blake Benson wrote:
>>>
>>>> I posted a couple of months ago regarding enabling libata.atapi on a
>>>> Digital Alpha 164LX, equipped with a Silicon Image 3114 controller.  I
>>>> decied to give kernel 2.6.16 (release, was previously using rc-1) a
>>>> shot, and it no longer longer panics.  I still have a Lite-ON DVD ROM
>>>> drive connected via a sil3611 bridge to port number 4, hoping that I
>>>> can avoid using the onboard CMD646.
>>>>
>>>> No panic this time, though it appears to throw a machine check.  The
>>>> system continues all the way to multi-user, and the Maxtor drives are
>>>> usable.  Hope the attached dmesg helps.  Let me know if I can be of
>>>> any assitance.
>>>>
>>> Can you build your kernel with ATA_DEBUG set and post dmesg?  Just
>>> change #undef ATA_DEBUG to #define ATA_DEBUG at the top of
>>> include/linux/libata.h
>>>
>>
>> For the SiI 3611 bridge + ATAPI devices, maybe the ATAPI_ENABLE_DMADIR
>> workaround should also be turned on as well. (in linux/libata.h)
>>
>> My JMicron 20330 bridge + SiI 3112 can handle ATAPI DMA without
>> the ATAPI_ENABLE_DMADIR workaround. However, the SiI 3611 bridge seems
>> need it.
> 
> 
> Is there any way to make this thing automatic?  'Recompile with #define
> tweak if you have some invisible bridge chip' doesn't sound too hot.
> 

The bridge is transparent to the software. So, it's hard to detect the chip
used. Maybe the SiImage developers know how to detect the chip?

For the time being, maybe we can use a module paramater instead of
compile time #ifdef. Will submit a patch for this later.
--
Albert

Re: libata machine check on Alpha

[Tejun Heo]

Albert Lee wrote:
> Tejun Heo wrote:
>> Albert Lee wrote:
>>
>>> Tejun Heo wrote:
>>>
>>>> Jonathan Blake Benson wrote:
>>>>
>>>>> I posted a couple of months ago regarding enabling libata.atapi on a
>>>>> Digital Alpha 164LX, equipped with a Silicon Image 3114 controller.  I
>>>>> decied to give kernel 2.6.16 (release, was previously using rc-1) a
>>>>> shot, and it no longer longer panics.  I still have a Lite-ON DVD ROM
>>>>> drive connected via a sil3611 bridge to port number 4, hoping that I
>>>>> can avoid using the onboard CMD646.
>>>>>
>>>>> No panic this time, though it appears to throw a machine check.  The
>>>>> system continues all the way to multi-user, and the Maxtor drives are
>>>>> usable.  Hope the attached dmesg helps.  Let me know if I can be of
>>>>> any assitance.
>>>>>
>>>> Can you build your kernel with ATA_DEBUG set and post dmesg?  Just
>>>> change #undef ATA_DEBUG to #define ATA_DEBUG at the top of
>>>> include/linux/libata.h
>>>>
>>> For the SiI 3611 bridge + ATAPI devices, maybe the ATAPI_ENABLE_DMADIR
>>> workaround should also be turned on as well. (in linux/libata.h)
>>>
>>> My JMicron 20330 bridge + SiI 3112 can handle ATAPI DMA without
>>> the ATAPI_ENABLE_DMADIR workaround. However, the SiI 3611 bridge seems
>>> need it.
>>
>> Is there any way to make this thing automatic?  'Recompile with #define
>> tweak if you have some invisible bridge chip' doesn't sound too hot.
>>
> 
> The bridge is transparent to the software. So, it's hard to detect the chip
> used. Maybe the SiImage developers know how to detect the chip?
> 
> For the time being, maybe we can use a module paramater insted of
> compile time #ifdef. Will submit a patch for this later.

[CC'ing Carlos Pardo]

Hello, Carlos.

Is there anyway to detect SiL3611 bridge?  As written above, the chip 
requires a workaround in libata and it would be nice if we can do it 
automatically.

Thanks.

-- 
tejun

Re: libata machine check on Alpha

[Jeff Garzik]

Albert Lee wrote:
> Tejun Heo wrote:
>> Albert Lee wrote:
>>
>>> Tejun Heo wrote:
>>>
>>>> Jonathan Blake Benson wrote:
>>>>
>>>>> I posted a couple of months ago regarding enabling libata.atapi on a
>>>>> Digital Alpha 164LX, equipped with a Silicon Image 3114 controller.  I
>>>>> decied to give kernel 2.6.16 (release, was previously using rc-1) a
>>>>> shot, and it no longer longer panics.  I still have a Lite-ON DVD ROM
>>>>> drive connected via a sil3611 bridge to port number 4, hoping that I
>>>>> can avoid using the onboard CMD646.
>>>>>
>>>>> No panic this time, though it appears to throw a machine check.  The
>>>>> system continues all the way to multi-user, and the Maxtor drives are
>>>>> usable.  Hope the attached dmesg helps.  Let me know if I can be of
>>>>> any assitance.
>>>>>
>>>> Can you build your kernel with ATA_DEBUG set and post dmesg?  Just
>>>> change #undef ATA_DEBUG to #define ATA_DEBUG at the top of
>>>> include/linux/libata.h
>>>>
>>> For the SiI 3611 bridge + ATAPI devices, maybe the ATAPI_ENABLE_DMADIR
>>> workaround should also be turned on as well. (in linux/libata.h)
>>>
>>> My JMicron 20330 bridge + SiI 3112 can handle ATAPI DMA without
>>> the ATAPI_ENABLE_DMADIR workaround. However, the SiI 3611 bridge seems
>>> need it.
>>
>> Is there any way to make this thing automatic?  'Recompile with #define
>> tweak if you have some invisible bridge chip' doesn't sound too hot.
>>
> 
> The bridge is transparent to the software. So, it's hard to detect the chip
> used. Maybe the SiImage developers know how to detect the chip?

There's a spec for DMADIR on t13.org, with IDENTIFY DEVICE bits to 
recognize, etc.

	Jeff

RE: libata machine check on Alpha

[Carlos Pardo]

The 3611 bridge does not support the ATAPI DMA direction bit in hardware.(software support only)  

The 3811 bridge supports ATAPI DMA direction bit in both software and hardware.

The 646 chip is ancient and he should upgrade.  The behavior of this device is unknown since this part was EOL'd years ago.


-----Original Message-----
From: Tejun Heo [mailto:htejun@gmail.com] 
Sent: Monday, April 03, 2006 8:06 PM
To: albertl@mail.com
Cc: Jonathan Blake Benson; linux-ide@vger.kernel.org; Carlos Pardo
Subject: Re: libata machine check on Alpha

Albert Lee wrote:
> Tejun Heo wrote:
>> Albert Lee wrote:
>>
>>> Tejun Heo wrote:
>>>
>>>> Jonathan Blake Benson wrote:
>>>>
>>>>> I posted a couple of months ago regarding enabling libata.atapi on a
>>>>> Digital Alpha 164LX, equipped with a Silicon Image 3114 controller.  I
>>>>> decied to give kernel 2.6.16 (release, was previously using rc-1) a
>>>>> shot, and it no longer longer panics.  I still have a Lite-ON DVD ROM
>>>>> drive connected via a sil3611 bridge to port number 4, hoping that I
>>>>> can avoid using the onboard CMD646.
>>>>>
>>>>> No panic this time, though it appears to throw a machine check.  The
>>>>> system continues all the way to multi-user, and the Maxtor drives are
>>>>> usable.  Hope the attached dmesg helps.  Let me know if I can be of
>>>>> any assitance.
>>>>>
>>>> Can you build your kernel with ATA_DEBUG set and post dmesg?  Just
>>>> change #undef ATA_DEBUG to #define ATA_DEBUG at the top of
>>>> include/linux/libata.h
>>>>
>>> For the SiI 3611 bridge + ATAPI devices, maybe the ATAPI_ENABLE_DMADIR
>>> workaround should also be turned on as well. (in linux/libata.h)
>>>
>>> My JMicron 20330 bridge + SiI 3112 can handle ATAPI DMA without
>>> the ATAPI_ENABLE_DMADIR workaround. However, the SiI 3611 bridge seems
>>> need it.
>>
>> Is there any way to make this thing automatic?  'Recompile with #define
>> tweak if you have some invisible bridge chip' doesn't sound too hot.
>>
> 
> The bridge is transparent to the software. So, it's hard to detect the chip
> used. Maybe the SiImage developers know how to detect the chip?
> 
> For the time being, maybe we can use a module paramater insted of
> compile time #ifdef. Will submit a patch for this later.

[CC'ing Carlos Pardo]

Hello, Carlos.

Is there anyway to detect SiL3611 bridge?  As written above, the chip 
requires a workaround in libata and it would be nice if we can do it 
automatically.

Thanks.

-- 
tejun

Re: libata machine check on Alpha

[Jonathan Benson]

My apologies for the length ahead of time. Per Tejun Heo's request, I  
have attached a dmesg with
#define ATA_DEBUG set in include/linux/libata.h

Looks like the dmesg buffer length ran past 16k, but I think the  
important parts are in there.

When I get home, I'll try Albert Lee's suggestion for enabling  
ATAPI_ENABLE_DMADIR


93C1080 ctl 0xFFFFFC88093C108A bmdma 0xFFFFFC88093C1000 irq 19
ata_host_add: ENTER
ata_port_start: prd alloc, virt fffffc001fcb2000, dma 9fcb2000
ata2: SATA max UDMA/100 cmd 0xFFFFFC88093C10C0 ctl 0xFFFFFC88093C10CA  
bmdma 0xFFFFFC88093C1008 irq 19
ata_host_add: ENTER
ata_port_start: prd alloc, virt fffffc001fcb6000, dma 9fcb6000
ata3: SATA max UDMA/100 cmd 0xFFFFFC88093C1280 ctl 0xFFFFFC88093C128A  
bmdma 0xFFFFFC88093C1200 irq 19
ata_host_add: ENTER
ata_port_start: prd alloc, virt fffffc001fcdc000, dma 9fcdc000
ata4: SATA max UDMA/100 cmd 0xFFFFFC88093C12C0 ctl 0xFFFFFC88093C12CA  
bmdma 0xFFFFFC88093C1208 irq 19
ata_device_add: probe begin
ata_device_add: ata1: probe begin
ata1: SATA link up 1.5 Gbps (SStatus 113)
ata_bus_reset: ENTER, host 1, port 0
ata_bus_softreset: ata1: bus reset via SRST
ata_dev_classify: found ATA device by sig
ata_bus_reset: EXIT
ata_dev_identify: ENTER, host 1, dev 0
ata_dev_identify: do ATA identify
ata_exec_command_mmio: ata1: cmd 0xEC
ata_pio_sector: data read
ata1: dev 0 cfg 49:2f00 82:7c6b 83:7b09 84:4003 85:7c68 86:3a01  
87:4003 88:007f
ata_dump_id: 49==0x2f00  53==0x0007  63==0x0407  64==0x0003  75==0x0000
ata_dump_id: 80==0x00fe  81==0x001e  82==0x7c6b  83==0x7b09  84==0x4003
ata_dump_id: 88==0x007f  93==0x400b
ata1: dev 0 ATA-7, max UDMA/133, 240121728 sectors: LBA
ata_dev_identify: EXIT, drv_stat = 0x50
ata1(0): applying bridge limits
ata_dev_identify: ENTER/EXIT (host 1, 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_exec_command_mmio: ata1: cmd 0xEF
ata_host_intr: ata1: protocol 1 (dev_stat 0x50)
ata_dev_set_xfermode: EXIT
ata_dev_set_mode: idx=5 xfer_shift=0, xfer_mode=0x45, base=0x40,  
offset=5
ata1: dev 0 configured for UDMA/100
ata_device_add: ata1: probe end
scsi0 : sata_sil
ata_device_add: ata2: probe begin
ata2: SATA link up 1.5 Gbps (SStatus 113)
ata_bus_reset: ENTER, host 2, port 1
ata_bus_softreset: ata2: bus reset via SRST
ata_dev_classify: found ATA device by sig
ata_bus_reset: EXIT
ata_dev_identify: ENTER, host 2, dev 0
ata_dev_identify: do ATA identify
ata_exec_command_mmio: ata2: cmd 0xEC
ata_pio_sector: data read
ata2: dev 0 cfg 49:2f00 82:7c6b 83:7b09 84:4003 85:7c69 86:3a01  
87:4003 88:007f
ata_dump_id: 49==0x2f00  53==0x0007  63==0x0407  64==0x0003  75==0x0000
ata_dump_id: 80==0x00fe  81==0x001e  82==0x7c6b  83==0x7b09  84==0x4003
ata_dump_id: 88==0x007f  93==0x400b
ata2: dev 0 ATA-7, max UDMA/133, 240121728 sectors: LBA
ata_dev_identify: EXIT, drv_stat = 0x50
ata2(0): applying bridge limits
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_exec_command_mmio: ata2: cmd 0xEF
ata_host_intr: ata2: protocol 1 (dev_stat 0x50)
ata_dev_set_xfermode: EXIT
ata_dev_set_mode: idx=5 xfer_shift=0, xfer_mode=0x45, base=0x40,  
offset=5
ata2: dev 0 configured for UDMA/100
ata_device_add: ata2: probe end
scsi1 : sata_sil
ata_device_add: ata3: probe begin
ata3: SATA link up 1.5 Gbps (SStatus 113)
ata_bus_reset: ENTER, host 3, port 2
ata_bus_softreset: ata3: bus reset via SRST
ata_dev_classify: found ATA device by sig
ata_bus_reset: EXIT
ata_dev_identify: ENTER, host 3, dev 0
ata_dev_identify: do ATA identify
ata_exec_command_mmio: ata3: cmd 0xEC
ata_pio_sector: data read
ata3: dev 0 cfg 49:2f00 82:7c6b 83:7b09 84:4003 85:7c69 86:3a01  
87:4003 88:007f
ata_dump_id: 49==0x2f00  53==0x0007  63==0x0407  64==0x0003  75==0x0000
ata_dump_id: 80==0x00fe  81==0x001e  82==0x7c6b  83==0x7b09  84==0x4003
ata_dump_id: 88==0x007f  93==0x400b
ata3: dev 0 ATA-7, max UDMA/133, 240121728 sectors: LBA
ata_dev_identify: EXIT, drv_stat = 0x50
ata3(0): applying bridge limits
ata_dev_identify: ENTER/EXIT (host 3, 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_exec_command_mmio: ata3: cmd 0xEF
ata_host_intr: ata3: protocol 1 (dev_stat 0x50)
ata_dev_set_xfermode: EXIT
ata_dev_set_mode: idx=5 xfer_shift=0, xfer_mode=0x45, base=0x40,  
offset=5
ata3: dev 0 configured for UDMA/100
ata_device_add: ata3: probe end
scsi2 : sata_sil
ata_device_add: ata4: probe begin
ata4: SATA link up 1.5 Gbps (SStatus 113)
ata_bus_reset: ENTER, host 4, port 3
ata_bus_softreset: ata4: bus reset via SRST
ata_dev_classify: found ATAPI device by sig
ata_bus_reset: EXIT
ata_dev_identify: ENTER, host 4, dev 0
ata_dev_identify: do ATAPI identify
ata_exec_command_mmio: ata4: cmd 0xA1
ata_pio_sector: data read
ata4: dev 0 cfg 49:0b00 82:0210 83:1000 84:0000 85:0000 86:0000  
87:0000 88:0007
ata_dump_id: 49==0x0b00  53==0x0006  63==0x0407  64==0x0003  75==0x0000
ata_dump_id: 80==0x0020  81==0x0000  82==0x0210  83==0x1000  84==0x0000
ata_dump_id: 88==0x0007  93==0x0000
ata4: dev 0 ATAPI, max UDMA/33
ata_dev_identify: EXIT, drv_stat = 0x50
ata_dev_identify: ENTER/EXIT (host 4, 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_exec_command_mmio: ata4: cmd 0xEF
ata_host_intr: ata4: protocol 1 (dev_stat 0x50)
ata_dev_set_xfermode: EXIT
ata_dev_set_mode: idx=2 xfer_shift=0, xfer_mode=0x42, base=0x40,  
offset=2
ata4: dev 0 configured for UDMA/33
ata_device_add: ata4: probe end
scsi3 : sata_sil
ata_device_add: probe begin
ata_scsi_dump_cdb: CDB (1:0,0,0) 12 00 00 00 24 00 aa 85 87
ata_scsi_dump_cdb: CDB (1:0,0,0) 12 00 00 00 60 00 aa 85 87
   Vendor: ATA       Model: Maxtor 6Y120P0    Rev: YAR4
   Type:   Direct-Access                      ANSI SCSI revision: 05
ata_scsi_dump_cdb: CDB (2:0,0,0) 12 00 00 00 24 00 a8 a5 b4
ata_scsi_dump_cdb: CDB (2:0,0,0) 12 00 00 00 60 00 a8 a5 b4
   Vendor: ATA       Model: Maxtor 6Y120P0    Rev: YAR4
   Type:   Direct-Access                      ANSI SCSI revision: 05
ata_scsi_dump_cdb: CDB (3:0,0,0) 12 00 00 00 24 00 00 00 24
ata_scsi_dump_cdb: CDB (3:0,0,0) 12 00 00 00 60 00 00 00 24
   Vendor: ATA       Model: Maxtor 6Y120P0    Rev: YAR4
   Type:   Direct-Access                      ANSI SCSI revision: 05
ata_scsi_dump_cdb: CDB (4:0,0,0) 12 00 00 00 24 00 8a b5 b5
ata_sg_setup: 1 sg elements mapped
ata_exec_command_mmio: ata4: cmd 0xA0
atapi_packet_task: busy wait
atapi_packet_task: send cdb
ata_scsi_error: ENTER
ata_eng_timeout: ENTER
ata_qc_timeout: ENTER
CIA machine check: vector=0x670 pc=0xfffffc000053aff0 code=0x98
machine check type: processor detected hard error
pc = [<fffffc000053aff0>]  ra = [<fffffc00005408a8>]  ps = 0007     
Not tainted
pc is at ata_altstatus+0x30/0x90
ra is at ata_qc_timeout+0x1b8/0x1d0
v0 = 000000000000004b  t0 = fffffc88093c12ca  t1 = fffffc88093c1208
t2 = fffffc8900000000  t3 = fffffc8900000000  t4 = 000000000000000b
t5 = 000000000000000a  t6 = fffffffffffff83c  t7 = fffffc001fcf0000
a0 = fffffc001fcdb418  a1 = 000000000000383c  a2 = ffffffffffffffff
a3 = 0000000000000001  a4 = 0000000000000001  a5 = 0000000000000001
t8 = 000000000000001f  t9 = 000000000009564a  t10= 0000000000000000
t11= 0000000000000000  pv = 0000000000000000  at = 0000000000000000
gp = fffffc0000788800  sp = fffffc001fcf3a98
ata4: command 0xa0 timeout, stat 0xf8 host_stat 0x0
ata4: translated ATA stat/err 0xf8/00 to SCSI SK/ASC/ASCQ 0xb/47/00
ata_qc_timeout: EXIT
ata_eng_timeout: EXIT
ata_scsi_error: EXIT
ata_scsi_dump_cdb: CDB (1:0,0,0) 00 00 00 00 00 00 00 00 24
ata_scsi_dump_cdb: CDB (1:0,0,0) 25 00 00 00 00 00 00 00 00
SCSI device sda: 240121728 512-byte hdwr sectors (122942 MB)
ata_scsi_dump_cdb: CDB (1:0,0,0) 5a 00 3f 00 00 00 00 00 08
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
ata_scsi_dump_cdb: CDB (1:0,0,0) 5a 00 08 00 00 00 00 00 08
ata_scsi_dump_cdb: CDB (1:0,0,0) 5a 00 08 00 00 00 00 00 24
SCSI device sda: drive cache: write back
ata_scsi_dump_cdb: CDB (1:0,0,0) 00 00 00 00 00 00 00 00 24
ata_scsi_dump_cdb: CDB (1:0,0,0) 25 00 00 00 00 00 00 00 00
SCSI device sda: 240121728 512-byte hdwr sectors (122942 MB)
ata_scsi_dump_cdb: CDB (1:0,0,0) 5a 00 3f 00 00 00 00 00 08
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
ata_scsi_dump_cdb: CDB (1:0,0,0) 5a 00 08 00 00 00 00 00 08
ata_scsi_dump_cdb: CDB (1:0,0,0) 5a 00 08 00 00 00 00 00 24
SCSI device sda: drive cache: write back
sda:<3>ata_scsi_dump_cdb: CDB (1:0,0,0) 28 00 00 00 00 00 00 00 10
ata_sg_setup: 1 sg elements mapped
ata_exec_command_mmio: ata1: cmd 0xC8
ata_host_intr: ata1: protocol 4 (dev_stat 0x50)
sda1
sd 0:0:0:0: Attached scsi disk sda
ata_scsi_dump_cdb: CDB (2:0,0,0) 00 00 00 00 00 00 00 00 24
ata_scsi_dump_cdb: CDB (2:0,0,0) 25 00 00 00 00 00 00 00 00
SCSI device sdb: 240121728 512-byte hdwr sectors (122942 MB)
ata_scsi_dump_cdb: CDB (2:0,0,0) 5a 00 3f 00 00 00 00 00 08
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
ata_scsi_dump_cdb: CDB (2:0,0,0) 5a 00 08 00 00 00 00 00 08
ata_scsi_dump_cdb: CDB (2:0,0,0) 5a 00 08 00 00 00 00 00 24
SCSI device sdb: drive cache: write back
ata_scsi_dump_cdb: CDB (2:0,0,0) 00 00 00 00 00 00 00 00 24
ata_scsi_dump_cdb: CDB (2:0,0,0) 25 00 00 00 00 00 00 00 00
SCSI device sdb: 240121728 512-byte hdwr sectors (122942 MB)
ata_scsi_dump_cdb: CDB (2:0,0,0) 5a 00 3f 00 00 00 00 00 08
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
ata_scsi_dump_cdb: CDB (2:0,0,0) 5a 00 08 00 00 00 00 00 08
ata_scsi_dump_cdb: CDB (2:0,0,0) 5a 00 08 00 00 00 00 00 24
SCSI device sdb: drive cache: write back
sdb:<3>ata_scsi_dump_cdb: CDB (2:0,0,0) 28 00 00 00 00 00 00 00 10
ata_sg_setup: 1 sg elements mapped
ata_exec_command_mmio: ata2: cmd 0xC8
ata_host_intr: ata2: protocol 4 (dev_stat 0x50)
sdb1
sd 1:0:0:0: Attached scsi disk sdb
ata_scsi_dump_cdb: CDB (3:0,0,0) 00 00 00 00 00 00 00 00 24
ata_scsi_dump_cdb: CDB (3:0,0,0) 25 00 00 00 00 00 00 00 00
SCSI device sdc: 240121728 512-byte hdwr sectors (122942 MB)
ata_scsi_dump_cdb: CDB (3:0,0,0) 5a 00 3f 00 00 00 00 00 08
sdc: Write Protect is off
sdc: Mode Sense: 00 3a 00 00
ata_scsi_dump_cdb: CDB (3:0,0,0) 5a 00 08 00 00 00 00 00 08
ata_scsi_dump_cdb: CDB (3:0,0,0) 5a 00 08 00 00 00 00 00 24
SCSI device sdc: drive cache: write back
ata_scsi_dump_cdb: CDB (3:0,0,0) 00 00 00 00 00 00 00 00 24
ata_scsi_dump_cdb: CDB (3:0,0,0) 25 00 00 00 00 00 00 00 00
SCSI device sdc: 240121728 512-byte hdwr sectors (122942 MB)
ata_scsi_dump_cdb: CDB (3:0,0,0) 5a 00 3f 00 00 00 00 00 08
sdc: Write Protect is off
sdc: Mode Sense: 00 3a 00 00
ata_scsi_dump_cdb: CDB (3:0,0,0) 5a 00 08 00 00 00 00 00 08
ata_scsi_dump_cdb: CDB (3:0,0,0) 5a 00 08 00 00 00 00 00 24
SCSI device sdc: drive cache: write back
sdc:<3>ata_scsi_dump_cdb: CDB (3:0,0,0) 28 00 00 00 00 00 00 00 10
ata_sg_setup: 1 sg elements mapped
ata_exec_command_mmio: ata3: cmd 0xC8
ata_host_intr: ata3: protocol 4 (dev_stat 0x50)
sdc1
sd 2:0:0:0: Attached scsi disk sdc
sd 0:0:0:0: Attached scsi generic sg0 type 0
sd 1:0:0:0: Attached scsi generic sg1 type 0
sd 2:0:0:0: Attached scsi generic sg2 type 0
mice: PS/2 mouse device common for all mice
md: raid0 personality registered for level 0
md: raid1 personality registered for level 1
md: raid5 personality registered for level 5
md: raid4 personality registered for level 4
raid5: measuring checksumming speed
    8regs     :   712.704 MB/sec
    32regs    :   950.272 MB/sec
    alpha     :  1089.536 MB/sec
    alpha prefetch:   950.272 MB/sec
raid5: using function: alpha (1089.536 MB/sec)
raid6: int64x1    236 MB/s
raid6: int64x2    368 MB/s
raid6: int64x4    492 MB/s
raid6: int64x8    332 MB/s
raid6: using algorithm int64x4 (492 MB/s)
md: raid6 personality registered for level 6
md: md driver 0.90.3 MAX_MD_DEVS=256, MD_SB_DISKS=27
md: bitmap version 4.39
NET: Registered protocol family 2
IP route cache hash table entries: 8192 (order: 3, 65536 bytes)
TCP established hash table entries: 32768 (order: 5, 262144 bytes)
TCP bind hash table entries: 32768 (order: 5, 262144 bytes)
TCP: Hash tables configured (established 32768 bind 32768)
TCP reno registered
TCP bic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.
ReiserFS: rd/c0d0p4: found reiserfs format "3.6" with standard journal
input: AT Translated Set 2 keyboard as /class/input/input0
ReiserFS: rd/c0d0p4: using ordered data mode
ReiserFS: rd/c0d0p4: journal params: device rd/c0d0p4, size 8192,  
journal first block 18, max trans len 1024, max batch 900, max commit  
age 30, max trans age 30
ReiserFS: rd/c0d0p4: checking transaction log (rd/c0d0p4)
ReiserFS: rd/c0d0p4: Using r5 hash to sort names
VFS: Mounted root (reiserfs filesystem) readonly.
Freeing unused kernel memory: 184k freed
input: ImExPS/2 Generic Explorer Mouse as /class/input/input1
ata_scsi_dump_cdb: CDB (2:0,0,0) 12 01 80 00 fe 00 00 00 00
ata_scsi_dump_cdb: CDB (1:0,0,0) 12 01 80 00 fe 00 00 00 00
ata_scsi_dump_cdb: CDB (3:0,0,0) 12 01 80 00 fe 00 00 00 00
ata_scsi_dump_cdb: CDB (1:0,0,0) 28 00 0e 4f f6 bf 00 00 10
ata_sg_setup: 1 sg elements mapped
ata_exec_command_mmio: ata1: cmd 0xC8
ata_host_intr: ata1: protocol 4 (dev_stat 0x50)
ata_scsi_dump_cdb: CDB (2:0,0,0) 28 00 0e 4f f6 bf 00 00 10
ata_sg_setup: 1 sg elements mapped
ata_exec_command_mmio: ata2: cmd 0xC8
ata_scsi_dump_cdb: CDB (3:0,0,0) 28 00 0e 4f f6 bf 00 00 10
ata_sg_setup: 1 sg elements mapped
ata_exec_command_mmio: ata3: cmd 0xC8
ata_host_intr: ata2: protocol 4 (dev_stat 0x50)
ata_host_intr: ata3: protocol 4 (dev_stat 0x50)
Adding 506024k swap on /dev/rd/c0d0p2.  Priority:-1 extents:1 across: 
506024k
e100: Intel(R) PRO/100 Network Driver, 3.5.10-k2-NAPI
e100: Copyright(c) 1999-2005 Intel Corporation
PCI: Setting latency timer of device 0000:00:07.0 to 64
e100: eth0: e100_probe: addr 0x93c0000, irq 17, MAC addr  
00:A0:C9:EF:DC:F9
md: md0 stopped.
ata_scsi_dump_cdb: CDB (1:0,0,0) 28 00 0e 4f f6 bf 00 00 10
ata_sg_setup: 1 sg elements mapped
ata_exec_command_mmio: ata1: cmd 0xC8
ata_host_intr: ata1: protocol 4 (dev_stat 0x50)
ata_scsi_dump_cdb: CDB (2:0,0,0) 28 00 0e 4f f6 bf 00 00 10
ata_sg_setup: 1 sg elements mapped
ata_exec_command_mmio: ata2: cmd 0xC8
ata_host_intr: ata2: protocol 4 (dev_stat 0x50)
ata_scsi_dump_cdb: CDB (3:0,0,0) 28 00 0e 4f f6 bf 00 00 10
ata_sg_setup: 1 sg elements mapped
ata_exec_command_mmio: ata3: cmd 0xC8
ata_host_intr: ata3: protocol 4 (dev_stat 0x50)
ata_scsi_dump_cdb: CDB (1:0,0,0) 28 00 0e 4f f6 bf 00 00 10
ata_sg_setup: 1 sg elements mapped
ata_exec_command_mmio: ata1: cmd 0xC8
ata_host_intr: ata1: protocol 4 (dev_stat 0x50)
ata_scsi_dump_cdb: CDB (2:0,0,0) 28 00 0e 4f f6 bf 00 00 08
ata_sg_setup: 1 sg elements mapped
ata_exec_command_mmio: ata2: cmd 0xC8
ata_host_intr: ata2: protocol 4 (dev_stat 0x50)
md: bind<sdb1>
ata_scsi_dump_cdb: CDB (3:0,0,0) 28 00 0e 4f f6 bf 00 00 08
ata_sg_setup: 1 sg elements mapped
ata_exec_command_mmio: ata3: cmd 0xC8
ata_host_intr: ata3: protocol 4 (dev_stat 0x50)
md: bind<sdc1>
ata_scsi_dump_cdb: CDB (1:0,0,0) 28 00 0e 4f f6 bf 00 00 08
ata_sg_setup: 1 sg elements mapped
ata_exec_command_mmio: ata1: cmd 0xC8
ata_host_intr: ata1: protocol 4 (dev_stat 0x50)
md: bind<sda1>
raid5: device sda1 operational as raid disk 0
raid5: device sdc1 operational as raid disk 2
raid5: device sdb1 operational as raid disk 1
raid5: allocated 6282kB for md0
raid5: raid level 5 set md0 active with 3 out of 3 devices, algorithm 2
RAID5 conf printout:
--- rd:3 wd:3 fd:0
disk 0, o:1, dev:sda1
disk 1, o:1, dev:sdb1
disk 2, o:1, dev:sdc1
e100: eth0: e100_watchdog: link up, 100Mbps, full-duplex

Re: libata machine check on Alpha

[Jonathan Blake Benson]

On Tue, 04 Apr 2006 10:12:05 +0800, you wrote:

>Tejun Heo wrote:
>> Jonathan Blake Benson wrote:
>> 
>>> I posted a couple of months ago regarding enabling libata.atapi on a
>>> Digital Alpha 164LX, equipped with a Silicon Image 3114 controller.  I
>>> decied to give kernel 2.6.16 (release, was previously using rc-1) a
>>> shot, and it no longer longer panics.  I still have a Lite-ON DVD ROM
>>> drive connected via a sil3611 bridge to port number 4, hoping that I
>>> can avoid using the onboard CMD646.
>>>
>>> No panic this time, though it appears to throw a machine check.  The
>>> system continues all the way to multi-user, and the Maxtor drives are
>>> usable.  Hope the attached dmesg helps.  Let me know if I can be of
>>> any assitance.
>>>
>> 
>> Can you build your kernel with ATA_DEBUG set and post dmesg?  Just
>> change #undef ATA_DEBUG to #define ATA_DEBUG at the top of
>> include/linux/libata.h
>> 
>For the SiI 3611 bridge + ATAPI devices, maybe the ATAPI_ENABLE_DMADIR
>workaround should also be turned on as well. (in linux/libata.h)
>
>My JMicron 20330 bridge + SiI 3112 can handle ATAPI DMA without
>the ATAPI_ENABLE_DMADIR workaround. However, the SiI 3611 bridge seems
>need it.

Albert, enabling the ATAPI_ENABLE_DMADIR workaround did the trick.
The DVD-ROM drive now works as it should.  Thanks again!

Jonathan Benson

libata version 1.20 loaded.
sata_sil 0000:00:09.0: version 0.9
sata_sil 0000:00:09.0: cache line size not set.  Driver may not
function
sata_sil 0000:00:09.0: Applying R_ERR on DMA activate FIS errata fix
PCI: Setting latency timer of device 0000:00:09.0 to 64
ata1: SATA max UDMA/100 cmd 0xFFFFFC88093C1080 ctl 0xFFFFFC88093C108A
bmdma 0xFF
FFFC88093C1000 irq 19
ata2: SATA max UDMA/100 cmd 0xFFFFFC88093C10C0 ctl 0xFFFFFC88093C10CA
bmdma 0xFF
FFFC88093C1008 irq 19
ata3: SATA max UDMA/100 cmd 0xFFFFFC88093C1280 ctl 0xFFFFFC88093C128A
bmdma 0xFF
FFFC88093C1200 irq 19
ata4: SATA max UDMA/100 cmd 0xFFFFFC88093C12C0 ctl 0xFFFFFC88093C12CA
bmdma 0xFF
FFFC88093C1208 irq 19
ata1: SATA link up 1.5 Gbps (SStatus 113)
ata1: dev 0 cfg 49:2f00 82:7c6b 83:7b09 84:4003 85:7c68 86:3a01
87:4003 88:007f
ata1: dev 0 ATA-7, max UDMA/133, 240121728 sectors: LBA
ata1(0): applying bridge limits
ata1: dev 0 configured for UDMA/100
scsi0 : sata_sil
ata2: SATA link up 1.5 Gbps (SStatus 113)
ata2: dev 0 cfg 49:2f00 82:7c6b 83:7b09 84:4003 85:7c69 86:3a01
87:4003 88:007f
ata2: dev 0 ATA-7, max UDMA/133, 240121728 sectors: LBA
ata2(0): applying bridge limits
ata2: dev 0 configured for UDMA/100
scsi1 : sata_sil
ata3: SATA link up 1.5 Gbps (SStatus 113)
ata3: dev 0 cfg 49:2f00 82:7c6b 83:7b09 84:4003 85:7c69 86:3a01
87:4003 88:007f
ata3: dev 0 ATA-7, max UDMA/133, 240121728 sectors: LBA
ata3(0): applying bridge limits
ata3: dev 0 configured for UDMA/100
scsi2 : sata_sil
ata4: SATA link up 1.5 Gbps (SStatus 113)
ata4: dev 0 cfg 49:0b00 82:0210 83:1000 84:0000 85:0000 86:0000
87:0000 88:0007
ata4: dev 0 ATAPI, max UDMA/33
ata4: dev 0 configured for UDMA/33
scsi3 : sata_sil
  Vendor: ATA       Model: Maxtor 6Y120P0    Rev: YAR4
  Type:   Direct-Access                      ANSI SCSI revision: 05
  Vendor: ATA       Model: Maxtor 6Y120P0    Rev: YAR4
  Type:   Direct-Access                      ANSI SCSI revision: 05
  Vendor: ATA       Model: Maxtor 6Y120P0    Rev: YAR4
  Type:   Direct-Access                      ANSI SCSI revision: 05
  Vendor: LITE-ON   Model: DVD SOHD-167T     Rev: 9S16
  Type:   CD-ROM                             ANSI SCSI revision: 05
SCSI device sda: 240121728 512-byte hdwr sectors (122942 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write back
SCSI device sda: 240121728 512-byte hdwr sectors (122942 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write back
 sda: sda1
sd 0:0:0:0: Attached scsi disk sda
SCSI device sdb: 240121728 512-byte hdwr sectors (122942 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: drive cache: write back
SCSI device sdb: 240121728 512-byte hdwr sectors (122942 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: drive cache: write back
 sdb: sdb1
sd 1:0:0:0: Attached scsi disk sdb
SCSI device sdc: 240121728 512-byte hdwr sectors (122942 MB)
sdc: Write Protect is off
sdc: Mode Sense: 00 3a 00 00
SCSI device sdc: drive cache: write back
SCSI device sdc: 240121728 512-byte hdwr sectors (122942 MB)
sdc: Write Protect is off
sdc: Mode Sense: 00 3a 00 00
SCSI device sdc: drive cache: write back
 sdc: sdc1
sd 2:0:0:0: Attached scsi disk sdc
sr0: scsi3-mmc drive: 48x/48x cd/rw xa/form2 cdda tray
Uniform CD-ROM driver Revision: 3.20
sr 3:0:0:0: Attached scsi CD-ROM sr0
sd 0:0:0:0: Attached scsi generic sg0 type 0
sd 1:0:0:0: Attached scsi generic sg1 type 0
sd 2:0:0:0: Attached scsi generic sg2 type 0
sr 3:0:0:0: Attached scsi generic sg3 type 5

Re: libata machine check on Alpha

[Albert Lee]

Carlos Pardo wrote:
> The 3611 bridge does not support the ATAPI DMA direction bit in hardware.(software support only)  
> 
> The 3811 bridge supports ATAPI DMA direction bit in both software and hardware.
> 
> The 646 chip is ancient and he should upgrade.  The behavior of this device is unknown since this part was EOL'd years ago.
> 
> 

Hi Carlos,

Does this mean that only the 3611 bridge needs the DMA_DIR bit set by host software, while 3811
can detect the ATAPI DMA direction by hardware and doesn't need the DMA_DIR bit?
(I guess that 3811 detects the direction by looking into the SCSI CDB. If the SCSI command is
unknown to it, 3811 still needs the DMA_DIR bit set by software.)
Is there anyway that we could detect whether the DMA_DIR needs to be set by host software?
Is there anyway that we could detect whether the bridge is a 3611 or a 3811 chip automatically?

Per Jeff's comment, there is a document on t13 (http://www.t13.org/docs2003/e03131r0.pdf).
The documents reads:
"Eg. – Word 50, bit 13: Set to 1 for devices that support DMAIN bit in Features Register for Packet Command".
However, this looks more for the ATAPI device than for the bridge?
Also it looks not a t13 standard yet?
Can we use this word 50 to identify 3611/3811?

Thanks,

Albert

Re: libata machine check on Alpha

[Jeff Garzik]

Albert Lee wrote:
> Per Jeff's comment, there is a document on t13 (http://www.t13.org/docs2003/e03131r0.pdf).
> The documents reads:
> "Eg. – Word 50, bit 13: Set to 1 for devices that support DMAIN bit in Features Register for Packet Command".
> However, this looks more for the ATAPI device than for the bridge?
> Also it looks not a t13 standard yet?
> Can we use this word 50 to identify 3611/3811?


DMADIR is in my copy of ATA-7...

	Jeff

Re: libata machine check on Alpha

[Tejun Heo]

Jeff Garzik wrote:
> Albert Lee wrote:
>> Per Jeff's comment, there is a document on t13 
>> (http://www.t13.org/docs2003/e03131r0.pdf).
>> The documents reads:
>> "Eg. – Word 50, bit 13: Set to 1 for devices that support DMAIN bit in 
>> Features Register for Packet Command".
>> However, this looks more for the ATAPI device than for the bridge?
>> Also it looks not a t13 standard yet?
>> Can we use this word 50 to identify 3611/3811?
> 
> 
> DMADIR is in my copy of ATA-7...
> 

Here's the relavant part from ATA8 draft.  It seems that the bridge is 
supposed to mangle the IDENTIFY PACKET DEVICE result.  It's supposed to 
nuke all DMA transfer mode information reported from the original device 
and report supported modes from the view point of the bridge in bits 
10:1 (which, BTW, should be all 1's).

The question is whether or not bridges implement this properly. I think 
we can add a printk to word 62 and ask Jonathan to test it.

----

7.18.6.17 Word 62: DMADIR

ATAPI devices that use a serial ATA bridge chip for connection to a 
serial ATA host may require use of the DMADIR bit to indicate transfer 
direction for Packet DMA commands. Word 62 is used to indicate if such
support is required.

If bit 15 of word 62 is set to one, then DMADIR bit in the Packet 
Command is required by the device for Packet DMA and Bits 2:0 of word 
63, bits 15 and 8 in word 49, and bits 6:0 of word 88 shall be cleared 
to 0,.

If bit 15 of word 62 is cleared to 0, DMADIR bit in the PACKET command 
is not required. If bit 15 of word 62 is cleared to zero, then all bits 
of word 62 shall be cleared to zero.

Bits (14:11) are reserved.

Bits (10:1) indicate DMA mode support. Since the DMADIR bit is only used 
for a Serial ATAPI device, all of these bits are set to 1.

-- 
tejun

Re: libata machine check on Alpha

[Albert Lee]

Tejun Heo wrote:
> Jeff Garzik wrote:
> 
>> Albert Lee wrote:
>>
>>> Per Jeff's comment, there is a document on t13
>>> (http://www.t13.org/docs2003/e03131r0.pdf).
>>> The documents reads:
>>> "Eg. – Word 50, bit 13: Set to 1 for devices that support DMAIN bit
>>> in Features Register for Packet Command".
>>> However, this looks more for the ATAPI device than for the bridge?
>>> Also it looks not a t13 standard yet?
>>> Can we use this word 50 to identify 3611/3811?
>>
>>
>>
>> DMADIR is in my copy of ATA-7...
>>
> 
> Here's the relavant part from ATA8 draft.  It seems that the bridge is
> supposed to mangle the IDENTIFY PACKET DEVICE result.  It's supposed to
> nuke all DMA transfer mode information reported from the original device
> and report supported modes from the view point of the bridge in bits
> 10:1 (which, BTW, should be all 1's).
> 
> The question is whether or not bridges implement this properly. I think
> we can add a printk to word 62 and ask Jonathan to test it.
> 

Ah, thanks for the info. The DMADIR is in my copy ATA-7, too.
I just checked word 50 and overlooked it. :(
I should have checked other part of the spec...

Anyway, will try to make a patch based on the ATA-7 spec.
--
Albert

Re: libata machine check on Alpha

[Doug Maxey]

On Thu, 06 Apr 2006 14:38:39 +0800, Albert Lee wrote:
>Tejun Heo wrote:
>> Jeff Garzik wrote:
>> 
>>> Albert Lee wrote:
>>>
>>>> Per Jeff's comment, there is a document on t13
>>>> (http://www.t13.org/docs2003/e03131r0.pdf).
>>>> The documents reads:
>>>> "Eg. – Word 50, bit 13: Set to 1 for devices that support DMAIN bit
>>>> in Features Register for Packet Command".
>>>> However, this looks more for the ATAPI device than for the bridge?
>>>> Also it looks not a t13 standard yet?
>>>> Can we use this word 50 to identify 3611/3811?
>>>
>>>
>>>
>>> DMADIR is in my copy of ATA-7...
>>>
>> 
>> Here's the relavant part from ATA8 draft.  It seems that the bridge is
>> supposed to mangle the IDENTIFY PACKET DEVICE result.  It's supposed to
>> nuke all DMA transfer mode information reported from the original device
>> and report supported modes from the view point of the bridge in bits
>> 10:1 (which, BTW, should be all 1's).
>> 
>> The question is whether or not bridges implement this properly. I think
>> we can add a printk to word 62 and ask Jonathan to test it.
>> 
>
>Ah, thanks for the info. The DMADIR is in my copy ATA-7, too.
>I just checked word 50 and overlooked it. :(
>I should have checked other part of the spec...
>
>Anyway, will try to make a patch based on the ATA-7 spec.

Do we have any devices to test your patch with?  Perhaps in Rochester?

++doug

Re: libata machine check on Alpha

[Albert Lee]

Doug Maxey wrote:
> On Thu, 06 Apr 2006 14:38:39 +0800, Albert Lee wrote:
> 
>>Tejun Heo wrote:
>>
>>>Jeff Garzik wrote:
>>>
>>>>DMADIR is in my copy of ATA-7...
>>>>
>>>
>>>Here's the relavant part from ATA8 draft.  It seems that the bridge is
>>>supposed to mangle the IDENTIFY PACKET DEVICE result.  It's supposed to
>>>nuke all DMA transfer mode information reported from the original device
>>>and report supported modes from the view point of the bridge in bits
>>>10:1 (which, BTW, should be all 1's).
>>>
>>>The question is whether or not bridges implement this properly. I think
>>>we can add a printk to word 62 and ask Jonathan to test it.
>>>
>>
>>Ah, thanks for the info. The DMADIR is in my copy ATA-7, too.
>>I just checked word 50 and overlooked it. :(
>>I should have checked other part of the spec...
>>
>>Anyway, will try to make a patch based on the ATA-7 spec.
> 
> 
> Do we have any devices to test your patch with?  Perhaps in Rochester?
> 

Yes, we have some Marvell bridges in Rochester to test.
I'll also test the JMicron bridge, once the auto enable DMADIR patch is ready.
We have no SiI 3611 at hand, so, need Jonathan's help.

--
Albert

Re: libata machine check on Alpha

[Albert Lee]

Jonathan Blake Benson wrote:
 
> 
> Albert, enabling the ATAPI_ENABLE_DMADIR workaround did the trick.
> The DVD-ROM drive now works as it should.  Thanks again!
> 

Hi Jonathan,

Could you please give a try to the attached patch and post the content of word 62?
If word 62 + SiI 3611 looks good, we can turn on the DMADIR automatically. Thanks!

--
albert

--- upstream0/drivers/scsi/libata-core.c	2006-04-06 16:07:32.000000000 +0800
+++ upstream0-show/drivers/scsi/libata-core.c	2006-04-06 17:08:10.000000000 +0800
@@ -1322,6 +1322,9 @@ static int ata_dev_configure(struct ata_
 		}
 		dev->cdb_len = (unsigned int) rc;
 
+		printk(KERN_ERR "ata%u: dev %u word 62 [%x]\n",
+		       ap->id, dev->devno, id[62]);
+
 		/* print device info to dmesg */
 		if (print_info)
 			printk(KERN_INFO "ata%u: dev %u ATAPI, max %s\n",

Re: libata machine check on Alpha

[Jonathan Benson]

 >Hi Jonathan,

 >Could you please give a try to the attached patch and post the  
content of word 62?
 >If word 62 + SiI 3611 looks good, we can turn on the DMADIR  
automatically. Thanks!

Per Albert's request, I've tested his patch to check the status of  
word 62 with the SiI 3611 bridge chip.  I used kernel version 2.6.17- 
rc1, as 2.6.16 reported fuzz when I applied the patch.  2.6.17-rc1  
reported an offset, but applied without any errors.  I've tested with  
the ATAPI_ENABLE_DMADIR workaround enabled, and disabled.  Debugging  
is disabled.  Looks like word 62 returns 0 as its value, dmesg with  
the relevant parts attached below.

If you need any more information, let me know and I'll be happy to  
provide it.

Jonathan Benson

Workaround Enabled

libata version 1.20 loaded.
sata_sil 0000:00:09.0: version 0.9
sata_sil 0000:00:09.0: cache line size not set.  Driver may not function
sata_sil 0000:00:09.0: Applying R_ERR on DMA activate FIS errata fix
PCI: Setting latency timer of device 0000:00:09.0 to 64
ata1: SATA max UDMA/100 cmd 0xFFFFFC88093C1080 ctl 0xFFFFFC88093C108A  
bmdma 0xFFFFFC88093C1000 irq 19
ata2: SATA max UDMA/100 cmd 0xFFFFFC88093C10C0 ctl 0xFFFFFC88093C10CA  
bmdma 0xFFFFFC88093C1008 irq 19
ata3: SATA max UDMA/100 cmd 0xFFFFFC88093C1280 ctl 0xFFFFFC88093C128A  
bmdma 0xFFFFFC88093C1200 irq 19
ata4: SATA max UDMA/100 cmd 0xFFFFFC88093C12C0 ctl 0xFFFFFC88093C12CA  
bmdma 0xFFFFFC88093C1208 irq 19
ata1: SATA link up 1.5 Gbps (SStatus 113)
ata1: dev 0 cfg 49:2f00 82:7c6b 83:7b09 84:4003 85:7c68 86:3a01  
87:4003 88:007f
ata1: dev 0 ATA-7, max UDMA/133, 240121728 sectors: LBA
ata1(0): applying bridge limits
ata1: dev 0 configured for UDMA/100
scsi0 : sata_sil
ata2: SATA link up 1.5 Gbps (SStatus 113)
ata2: dev 0 cfg 49:2f00 82:7c6b 83:7b09 84:4003 85:7c69 86:3a01  
87:4003 88:007f
ata2: dev 0 ATA-7, max UDMA/133, 240121728 sectors: LBA
ata2(0): applying bridge limits
ata2: dev 0 configured for UDMA/100
scsi1 : sata_sil
ata3: SATA link up 1.5 Gbps (SStatus 113)
ata3: dev 0 cfg 49:2f00 82:7c6b 83:7b09 84:4003 85:7c69 86:3a01  
87:4003 88:007f
ata3: dev 0 ATA-7, max UDMA/133, 240121728 sectors: LBA
ata3(0): applying bridge limits
ata3: dev 0 configured for UDMA/100
scsi2 : sata_sil
ata4: SATA link up 1.5 Gbps (SStatus 113)
ata4: dev 0 cfg 49:0b00 82:0210 83:1000 84:0000 85:0000 86:0000  
87:0000 88:0007
ata4: dev 0 word 62 [0]
ata4: dev 0 ATAPI, max UDMA/33
ata4: dev 0 word 62 [0]
ata4: dev 0 configured for UDMA/33
scsi3 : sata_sil
   Vendor: ATA       Model: Maxtor 6Y120P0    Rev: YAR4
   Type:   Direct-Access                      ANSI SCSI revision: 05
   Vendor: ATA       Model: Maxtor 6Y120P0    Rev: YAR4
   Type:   Direct-Access                      ANSI SCSI revision: 05
   Vendor: ATA       Model: Maxtor 6Y120P0    Rev: YAR4
   Type:   Direct-Access                      ANSI SCSI revision: 05
   Vendor: LITE-ON   Model: DVD SOHD-167T     Rev: 9S16
   Type:   CD-ROM                             ANSI SCSI revision: 05
SCSI device sda: 240121728 512-byte hdwr sectors (122942 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write back
SCSI device sda: 240121728 512-byte hdwr sectors (122942 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write back
sda: sda1
sd 0:0:0:0: Attached scsi disk sda
SCSI device sdb: 240121728 512-byte hdwr sectors (122942 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: drive cache: write back
SCSI device sdb: 240121728 512-byte hdwr sectors (122942 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: drive cache: write back
sdb: sdb1
sd 1:0:0:0: Attached scsi disk sdb
SCSI device sdc: 240121728 512-byte hdwr sectors (122942 MB)
sdc: Write Protect is off
sdc: Mode Sense: 00 3a 00 00
SCSI device sdc: drive cache: write back
SCSI device sdc: 240121728 512-byte hdwr sectors (122942 MB)
sdc: Write Protect is off
sdc: Mode Sense: 00 3a 00 00
SCSI device sdc: drive cache: write back
sdc: sdc1
sd 2:0:0:0: Attached scsi disk sdc
sr0: scsi3-mmc drive: 48x/48x cd/rw xa/form2 cdda tray
Uniform CD-ROM driver Revision: 3.20
sr 3:0:0:0: Attached scsi CD-ROM sr0
sd 0:0:0:0: Attached scsi generic sg0 type 0
sd 1:0:0:0: Attached scsi generic sg1 type 0
sd 2:0:0:0: Attached scsi generic sg2 type 0
sr 3:0:0:0: Attached scsi generic sg3 type 5

Workaround Disabled

libata version 1.20 loaded.
sata_sil 0000:00:09.0: version 0.9
sata_sil 0000:00:09.0: cache line size not set.  Driver may not function
sata_sil 0000:00:09.0: Applying R_ERR on DMA activate FIS errata fix
PCI: Setting latency timer of device 0000:00:09.0 to 64
ata1: SATA max UDMA/100 cmd 0xFFFFFC88093C1080 ctl 0xFFFFFC88093C108A  
bmdma 0xFFFFFC88093C1000 irq 19
ata2: SATA max UDMA/100 cmd 0xFFFFFC88093C10C0 ctl 0xFFFFFC88093C10CA  
bmdma 0xFFFFFC88093C1008 irq 19
ata3: SATA max UDMA/100 cmd 0xFFFFFC88093C1280 ctl 0xFFFFFC88093C128A  
bmdma 0xFFFFFC88093C1200 irq 19
ata4: SATA max UDMA/100 cmd 0xFFFFFC88093C12C0 ctl 0xFFFFFC88093C12CA  
bmdma 0xFFFFFC88093C1208 irq 19
ata1: SATA link up 1.5 Gbps (SStatus 113)
ata1: dev 0 cfg 49:2f00 82:7c6b 83:7b09 84:4003 85:7c68 86:3a01  
87:4003 88:007f
ata1: dev 0 ATA-7, max UDMA/133, 240121728 sectors: LBA
ata1(0): applying bridge limits
ata1: dev 0 configured for UDMA/100
scsi0 : sata_sil
ata2: SATA link up 1.5 Gbps (SStatus 113)
ata2: dev 0 cfg 49:2f00 82:7c6b 83:7b09 84:4003 85:7c69 86:3a01  
87:4003 88:007f
ata2: dev 0 ATA-7, max UDMA/133, 240121728 sectors: LBA
ata2(0): applying bridge limits
ata2: dev 0 configured for UDMA/100
scsi1 : sata_sil
ata3: SATA link up 1.5 Gbps (SStatus 113)
ata3: dev 0 cfg 49:2f00 82:7c6b 83:7b09 84:4003 85:7c69 86:3a01  
87:4003 88:007f
ata3: dev 0 ATA-7, max UDMA/133, 240121728 sectors: LBA
ata3(0): applying bridge limits
ata3: dev 0 configured for UDMA/100
scsi2 : sata_sil
ata4: SATA link up 1.5 Gbps (SStatus 113)
ata4: dev 0 cfg 49:0b00 82:0210 83:1000 84:0000 85:0000 86:0000  
87:0000 88:0007
ata4: dev 0 word 62 [0]
ata4: dev 0 ATAPI, max UDMA/33
ata4: dev 0 word 62 [0]
ata4: dev 0 configured for UDMA/33
scsi3 : sata_sil
   Vendor: ATA       Model: Maxtor 6Y120P0    Rev: YAR4
   Type:   Direct-Access                      ANSI SCSI revision: 05
   Vendor: ATA       Model: Maxtor 6Y120P0    Rev: YAR4
   Type:   Direct-Access                      ANSI SCSI revision: 05
   Vendor: ATA       Model: Maxtor 6Y120P0    Rev: YAR4
   Type:   Direct-Access                      ANSI SCSI revision: 05
CIA machine check: vector=0x670 pc=0xfffffc00005330e0 code=0x98
machine check type: processor detected hard error
pc = [<fffffc00005330e0>]  ra = [<fffffc000052d148>]  ps = 0007     
Not tainted
pc is at ata_altstatus+0x30/0x90
ra is at ata_qc_timeout+0x178/0x190
v0 = 0000000000000001  t0 = fffffc88093c12ca  t1 = fffffc88093c1208
t2 = fffffc8900000000  t3 = 0000000020010058  t4 = 0000000000000000
t5 = 00000000256d7116  t6 = 00000000fffb8c53  t7 = fffffc001fc20000
a0 = fffffc001fedec18  a1 = fffffc001fc23a48  a2 = 0000000000000318
a3 = fffffc0000610722  a4 = 0000000000000000  a5 = 0000000000000001
t8 = 000000000000001f  t9 = 000000000008efbe  t10= 0000000000000000
t11= 0000000000000000  pv = 0000000000000000  at = 0000000000000000
gp = fffffc000075f400  sp = fffffc001fc23a88
ata4: command 0xa0 timeout, stat 0xf8 host_stat 0x0
ata4: translated ATA stat/err 0xf8/00 to SCSI SK/ASC/ASCQ 0xb/47/00
SCSI device sda: 240121728 512-byte hdwr sectors (122942 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write back
SCSI device sda: 240121728 512-byte hdwr sectors (122942 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write back
sda: sda1
sd 0:0:0:0: Attached scsi disk sda
SCSI device sdb: 240121728 512-byte hdwr sectors (122942 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: drive cache: write back
SCSI device sdb: 240121728 512-byte hdwr sectors (122942 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: drive cache: write back
sdb: sdb1
sd 1:0:0:0: Attached scsi disk sdb
SCSI device sdc: 240121728 512-byte hdwr sectors (122942 MB)
sdc: Write Protect is off
sdc: Mode Sense: 00 3a 00 00
SCSI device sdc: drive cache: write back
SCSI device sdc: 240121728 512-byte hdwr sectors (122942 MB)
sdc: Write Protect is off
sdc: Mode Sense: 00 3a 00 00
SCSI device sdc: drive cache: write back
sdc: sdc1
sd 2:0:0:0: Attached scsi disk sdc
sd 0:0:0:0: Attached scsi generic sg0 type 0
sd 1:0:0:0: Attached scsi generic sg1 type 0
sd 2:0:0:0: Attached scsi generic sg2 type 0

Re: libata machine check on Alpha

[Albert Lee]

Jonathan Benson wrote:
> 
>>Could you please give a try to the attached patch and post the  content
> of word 62?
>>If word 62 + SiI 3611 looks good, we can turn on the DMADIR 
> automatically. Thanks!
> 
> Per Albert's request, I've tested his patch to check the status of  word
> 62 with the SiI 3611 bridge chip.  I used kernel version 2.6.17- rc1, as
> 2.6.16 reported fuzz when I applied the patch.  2.6.17-rc1  reported an
> offset, but applied without any errors.  I've tested with  the
> ATAPI_ENABLE_DMADIR workaround enabled, and disabled.  Debugging  is
> disabled.  Looks like word 62 returns 0 as its value, dmesg with  the
> relevant parts attached below.
> 
> If you need any more information, let me know and I'll be happy to 
> provide it.
> 
> Jonathan Benson
> 
> (snip)
> 
> ata2: dev 0 ATA-7, max UDMA/133, 240121728 sectors: LBA
> ata2(0): applying bridge limits
> ata2: dev 0 configured for UDMA/100
> scsi1 : sata_sil
> ata3: SATA link up 1.5 Gbps (SStatus 113)
> ata3: dev 0 cfg 49:2f00 82:7c6b 83:7b09 84:4003 85:7c69 86:3a01  87:4003
> 88:007f
> ata3: dev 0 ATA-7, max UDMA/133, 240121728 sectors: LBA
> ata3(0): applying bridge limits
> ata3: dev 0 configured for UDMA/100
> scsi2 : sata_sil
> ata4: SATA link up 1.5 Gbps (SStatus 113)
> ata4: dev 0 cfg 49:0b00 82:0210 83:1000 84:0000 85:0000 86:0000  87:0000
> 88:0007
> ata4: dev 0 word 62 [0]
> ata4: dev 0 ATAPI, max UDMA/33
> ata4: dev 0 word 62 [0]
> ata4: dev 0 configured for UDMA/33

Word 62 is also zero on my JMicron 20330 bridge.
Since JMicron doesn't need the DMA DIR bit, it looks consistent
(maybe by coincidence) with the ATA-7 spec.

For SiI 3611, it was made before the ATA-7 spec is finalized. So, it is
reasonable that SiI 3611 doesn't implement word 62 and we have to 
manually enable the DMA DIR support as work around unless SiImage provides
other solution to identify the SiI 3611 bridge.

Thanks for the test result. :)
--
albert

[PATCH/RFC] libata: turn on the ATAPI DMA DIR support per word 62

[Albert Lee]

Turn on the ATAPI DMA DIR support if word 62 indicates it.

Signed-off-by: Albert Lee <albertcc@tw.ibm.com>
---
ATAPI DMA DIR follow-up patch to turn on the DMA_DIR support automatically
by checking identify device word 62. (Thanks for Jeff and Tejun's pointer.)

According to Jonathan's test result, SiI 3611 (the current known bridge that
requires the ATAPI DMA DIR support) doesn't implement word 62. So, the
atapi_dmadir parameter is preserved to enable the DMA DIR support manually as
work around.

Patch against upstream (c2a6585296009379e0f4eff39cdcb108b457ebf2).
For your review, thanks.

--- upstream0/include/linux/ata.h	2006-04-06 16:07:36.000000000 +0800
+++ upstream1/include/linux/ata.h	2006-04-06 16:50:54.000000000 +0800
@@ -264,6 +264,7 @@ struct ata_taskfile {
 #define ata_id_has_dma(id)	((id)[49] & (1 << 8))
 #define ata_id_removeable(id)	((id)[0] & (1 << 7))
 #define ata_id_has_dword_io(id)	((id)[50] & (1 << 0))
+#define ata_id_dmadir_needed(id) ((id)[62] & (1 << 15))
 #define ata_id_u32(id,n)	\
 	(((u32) (id)[(n) + 1] << 16) | ((u32) (id)[(n)]))
 #define ata_id_u64(id,n)	\
--- upstream0/include/linux/libata.h	2006-04-06 16:07:37.000000000 +0800
+++ upstream1/include/linux/libata.h	2006-04-06 16:53:35.000000000 +0800
@@ -121,6 +121,7 @@ enum {
 	/* struct ata_device stuff */
 	ATA_DFLAG_LBA		= (1 << 0), /* device supports LBA */
 	ATA_DFLAG_LBA48		= (1 << 1), /* device supports LBA48 */
+	ATA_DFLAG_DMADIR	= (1 << 2), /* device requires ATAPI DMADIR */
 	ATA_DFLAG_CFG_MASK	= (1 << 8) - 1,
 
 	ATA_DFLAG_PIO		= (1 << 8), /* device currently in PIO mode */
--- upstream0/drivers/scsi/libata-scsi.c	2006-04-06 16:07:32.000000000 +0800
+++ upstream1/drivers/scsi/libata-scsi.c	2006-04-07 13:54:28.000000000 +0800
@@ -2163,9 +2163,12 @@ static unsigned int atapi_xlat(struct at
 		qc->tf.protocol = ATA_PROT_ATAPI_DMA;
 		qc->tf.feature |= ATAPI_PKT_DMA;
 
-		if (atapi_dmadir && (cmd->sc_data_direction != DMA_TO_DEVICE))
-			/* some SATA bridges need us to indicate data xfer direction */
-			qc->tf.feature |= ATAPI_DMADIR;
+		if ((dev->flags & ATA_DFLAG_DMADIR) || atapi_dmadir)
+			/* some SATA bridges need us to indicate
+			 * data xfer direction
+			 */
+			if (cmd->sc_data_direction != DMA_TO_DEVICE)
+				qc->tf.feature |= ATAPI_DMADIR;
 	}
 
 	qc->nbytes = cmd->bufflen;
--- upstream0/drivers/scsi/libata-core.c	2006-04-06 16:07:32.000000000 +0800
+++ upstream1/drivers/scsi/libata-core.c	2006-04-07 13:59:01.000000000 +0800
@@ -78,7 +78,7 @@ MODULE_PARM_DESC(atapi_enabled, "Enable 
 
 int atapi_dmadir = 0;
 module_param(atapi_dmadir, int, 0444);
-MODULE_PARM_DESC(atapi_dmadir, "Enable ATAPI DMADIR bridge support (0=off, 1=on)");
+MODULE_PARM_DESC(atapi_dmadir, "Manually enable ATAPI DMADIR bridge support (0=off, 1=on)");
 
 int libata_fua = 0;
 module_param_named(fua, libata_fua, int, 0444);
@@ -1322,6 +1322,9 @@ static int ata_dev_configure(struct ata_
 		}
 		dev->cdb_len = (unsigned int) rc;
 
+		if (ata_id_dmadir_needed(id))
+			dev->flags |= ATA_DFLAG_DMADIR;
+
 		/* print device info to dmesg */
 		if (print_info)
 			printk(KERN_INFO "ata%u: dev %u ATAPI, max %s\n",

Re: [PATCH/RFC] libata: turn on the ATAPI DMA DIR support per word 62

[Jeff Garzik]

Albert Lee wrote:
> Turn on the ATAPI DMA DIR support if word 62 indicates it.
> 
> Signed-off-by: Albert Lee <albertcc@tw.ibm.com>
> ---
> ATAPI DMA DIR follow-up patch to turn on the DMA_DIR support automatically
> by checking identify device word 62. (Thanks for Jeff and Tejun's pointer.)
> 
> According to Jonathan's test result, SiI 3611 (the current known bridge that
> requires the ATAPI DMA DIR support) doesn't implement word 62. So, the
> atapi_dmadir parameter is preserved to enable the DMA DIR support manually as
> work around.

Two comments:

* I would like to find a device that's compliant with the spec, and test 
the patch, before committing.

* DMADIR not only includes a bit flag indicating its presence, it also 
moves all the DMA capability bits from their standard places.  You'll 
have to audit every place that reads dev->id[]'s mwdma/udma masks and 
make sure they look at the DMADIR-special-case location, when DMADIR is set.

	Jeff

Re: [PATCH/RFC] libata: turn on the ATAPI DMA DIR support per word 62

[Albert Lee]

Jeff Garzik wrote:
> 
> Two comments:
> 
> * I would like to find a device that's compliant with the spec, and test
> the patch, before committing.

I'm trying to get an Acard AEC-7900A and a Sunplus 3811A (which looks like
a SiI 3811 rebrand) for test. Since the DMADIR is SiImage's idea,
hopefully the Sunplus 3811A may support DMADIR. For bridges from other
vendors, I guess the chance is low.

> 
> * DMADIR not only includes a bit flag indicating its presence, it also
> moves all the DMA capability bits from their standard places.  You'll
> have to audit every place that reads dev->id[]'s mwdma/udma masks and
> make sure they look at the DMADIR-special-case location, when DMADIR is
> set.
> 

Fortunately only ata_id_xfermask() uses the mwdma/udma bits. Revised
patch to follow. Thanks for the advice.

--
albert

[PATCH/RFC] libata: turn on the ATAPI DMADIR support per word 62 (revised)

[Albert Lee]

Turn on the ATAPI DMADIR support if word 62 indicates it.

Signed-off-by: Albert Lee <albertcc@tw.ibm.com>
---
(Revised to add mwdma/udma mask of word 62 per Jeff's comments.
Need more testing once I get the SiI 3811, etc.)

ATAPI DMADIR follow-up patch to turn on the DMADIR support automatically
by checking identify device word 62. (Thanks for Jeff and Tejun's pointer.)

According to Jonathan's test result, SiI 3611 (the current known bridge that
requires the ATAPI DMADIR support) doesn't implement word 62. So, the
atapi_dmadir parameter is preserved to enable the DMA DIR support manually as
work around.

Patch against upstream (c2a6585296009379e0f4eff39cdcb108b457ebf2).
For your review, thanks.

--- upstream0/include/linux/ata.h	2006-04-06 16:07:36.000000000 +0800
+++ upstream1/include/linux/ata.h	2006-04-07 17:52:24.000000000 +0800
@@ -47,6 +47,7 @@ enum {
 	ATA_ID_PROD_OFS		= 27,
 	ATA_ID_OLD_PIO_MODES	= 51,
 	ATA_ID_FIELD_VALID	= 53,
+	ATA_ID_DMADIR		= 62,
 	ATA_ID_MWDMA_MODES	= 63,
 	ATA_ID_PIO_MODES	= 64,
 	ATA_ID_EIDE_DMA_MIN	= 65,
@@ -264,6 +265,7 @@ struct ata_taskfile {
 #define ata_id_has_dma(id)	((id)[49] & (1 << 8))
 #define ata_id_removeable(id)	((id)[0] & (1 << 7))
 #define ata_id_has_dword_io(id)	((id)[50] & (1 << 0))
+#define ata_id_dmadir_needed(id) ((id)[62] & (1 << 15))
 #define ata_id_u32(id,n)	\
 	(((u32) (id)[(n) + 1] << 16) | ((u32) (id)[(n)]))
 #define ata_id_u64(id,n)	\
--- upstream0/include/linux/libata.h	2006-04-06 16:07:37.000000000 +0800
+++ upstream1/include/linux/libata.h	2006-04-07 17:53:19.000000000 +0800
@@ -121,6 +121,7 @@ enum {
 	/* struct ata_device stuff */
 	ATA_DFLAG_LBA		= (1 << 0), /* device supports LBA */
 	ATA_DFLAG_LBA48		= (1 << 1), /* device supports LBA48 */
+	ATA_DFLAG_DMADIR	= (1 << 2), /* device requires ATAPI DMADIR */
 	ATA_DFLAG_CFG_MASK	= (1 << 8) - 1,
 
 	ATA_DFLAG_PIO		= (1 << 8), /* device currently in PIO mode */
--- upstream0/drivers/scsi/libata-scsi.c	2006-04-06 16:07:32.000000000 +0800
+++ upstream1/drivers/scsi/libata-scsi.c	2006-04-07 17:54:06.000000000 +0800
@@ -2163,9 +2163,12 @@ static unsigned int atapi_xlat(struct at
 		qc->tf.protocol = ATA_PROT_ATAPI_DMA;
 		qc->tf.feature |= ATAPI_PKT_DMA;
 
-		if (atapi_dmadir && (cmd->sc_data_direction != DMA_TO_DEVICE))
-			/* some SATA bridges need us to indicate data xfer direction */
-			qc->tf.feature |= ATAPI_DMADIR;
+		if ((dev->flags & ATA_DFLAG_DMADIR) || atapi_dmadir)
+			/* some SATA bridges need us to indicate
+			 * data xfer direction
+			 */
+			if (cmd->sc_data_direction != DMA_TO_DEVICE)
+				qc->tf.feature |= ATAPI_DMADIR;
 	}
 
 	qc->nbytes = cmd->bufflen;
--- upstream0/drivers/scsi/libata-core.c	2006-04-06 16:07:32.000000000 +0800
+++ upstream1/drivers/scsi/libata-core.c	2006-04-07 18:35:38.000000000 +0800
@@ -78,7 +78,7 @@ MODULE_PARM_DESC(atapi_enabled, "Enable 
 
 int atapi_dmadir = 0;
 module_param(atapi_dmadir, int, 0444);
-MODULE_PARM_DESC(atapi_dmadir, "Enable ATAPI DMADIR bridge support (0=off, 1=on)");
+MODULE_PARM_DESC(atapi_dmadir, "Manually enable ATAPI DMADIR bridge support (0=off, 1=on)");
 
 int libata_fua = 0;
 module_param_named(fua, libata_fua, int, 0444);
@@ -831,6 +831,7 @@ static inline void ata_dump_id(const u16
 /**
  *	ata_id_xfermask - Compute xfermask from the given IDENTIFY data
  *	@id: IDENTIFY data to compute xfer mask from
+ *	@class: class of attached device
  *
  *	Compute the xfermask for this device. This is not as trivial
  *	as it seems if we must consider early devices correctly.
@@ -843,7 +844,7 @@ static inline void ata_dump_id(const u16
  *	RETURNS:
  *	Computed xfermask
  */
-static unsigned int ata_id_xfermask(const u16 *id)
+static unsigned int ata_id_xfermask(const u16 *id, unsigned int class)
 {
 	unsigned int pio_mask, mwdma_mask, udma_mask;
 
@@ -873,6 +874,23 @@ static unsigned int ata_id_xfermask(cons
 	if (id[ATA_ID_FIELD_VALID] & (1 << 2))
 		udma_mask = id[ATA_ID_UDMA_MODES] & 0xff;
 
+	if (class == ATA_DEV_ATAPI && ata_id_dmadir_needed(id)) {
+		/* To prevent the pre ATA-7 host software (which is
+		 * not aware of the DMADIR word) from using ATAPI DMA
+		 * and causing trouble, the bridge mangles id[49],
+		 * id[63] and id[88] to report no DMA support.
+		 * 
+		 * We turn on DMA here if word 62 indicates it.
+		 * (Per ATA-7, DMADIR is only used for S-ATAPI
+		 * devices, therefore bits 0-10 are set to 1.
+		 * Anyway, we just use these bits as is.)
+		 */
+		WARN_ON(mwdma_mask || udma_mask);
+
+		mwdma_mask = (id[ATA_ID_DMADIR] >> 7) & 0x07;
+		udma_mask = id[ATA_ID_DMADIR] & 0x7f;
+	}
+
 	return ata_pack_xfermask(pio_mask, mwdma_mask, udma_mask);
 }
 
@@ -1256,7 +1274,7 @@ static int ata_dev_configure(struct ata_
 	 */
 
 	/* find max transfer mode; for printk only */
-	xfer_mask = ata_id_xfermask(id);
+	xfer_mask = ata_id_xfermask(id, dev->class);
 
 	ata_dump_id(id);
 
@@ -1322,6 +1340,9 @@ static int ata_dev_configure(struct ata_
 		}
 		dev->cdb_len = (unsigned int) rc;
 
+		if (ata_id_dmadir_needed(id))
+			dev->flags |= ATA_DFLAG_DMADIR;
+
 		/* print device info to dmesg */
 		if (print_info)
 			printk(KERN_INFO "ata%u: dev %u ATAPI, max %s\n",
@@ -2941,7 +2962,7 @@ static void ata_dev_xfermask(struct ata_
 
 		xfer_mask &= ata_pack_xfermask(d->pio_mask,
 					       d->mwdma_mask, d->udma_mask);
-		xfer_mask &= ata_id_xfermask(d->id);
+		xfer_mask &= ata_id_xfermask(d->id, d->class);
 		if (ata_dma_blacklisted(d))
 			xfer_mask &= ~(ATA_MASK_MWDMA | ATA_MASK_UDMA);
 	}

Re: [PATCH/RFC] libata: turn on the ATAPI DMADIR support per word 62 (revised)

[Jeff Garzik]

Albert Lee wrote:
> Turn on the ATAPI DMADIR support if word 62 indicates it.
> 
> Signed-off-by: Albert Lee <albertcc@tw.ibm.com>
> ---
> (Revised to add mwdma/udma mask of word 62 per Jeff's comments.
> Need more testing once I get the SiI 3811, etc.)
> 
> ATAPI DMADIR follow-up patch to turn on the DMADIR support automatically
> by checking identify device word 62. (Thanks for Jeff and Tejun's pointer.)
> 
> According to Jonathan's test result, SiI 3611 (the current known bridge that
> requires the ATAPI DMADIR support) doesn't implement word 62. So, the
> atapi_dmadir parameter is preserved to enable the DMA DIR support manually as
> work around.
> 
> Patch against upstream (c2a6585296009379e0f4eff39cdcb108b457ebf2).
> For your review, thanks.

I ACK the patch, though like I said, I would like to see this tested 
first with some compliant devices.

	Jeff

Re: [PATCH/RFC] libata: turn on the ATAPI DMADIR support per word 62 (revised)

[Albert Lee]

Jeff Garzik wrote:
> Albert Lee wrote:
> 
>> Turn on the ATAPI DMADIR support if word 62 indicates it.
>>
>> Signed-off-by: Albert Lee <albertcc@tw.ibm.com>
>> ---
>> (Revised to add mwdma/udma mask of word 62 per Jeff's comments.
>> Need more testing once I get the SiI 3811, etc.)
>>
>> ATAPI DMADIR follow-up patch to turn on the DMADIR support automatically
>> by checking identify device word 62. (Thanks for Jeff and Tejun's
>> pointer.)
>>
>> According to Jonathan's test result, SiI 3611 (the current known
>> bridge that
>> requires the ATAPI DMADIR support) doesn't implement word 62. So, the
>> atapi_dmadir parameter is preserved to enable the DMA DIR support
>> manually as
>> work around.
>>
>> Patch against upstream (c2a6585296009379e0f4eff39cdcb108b457ebf2).
>> For your review, thanks.
> 
> 
> I ACK the patch, though like I said, I would like to see this tested
> first with some compliant devices.
> 

I've collected/tested most of the PATA-to-SATA bridges, none of them 
implements the word 62 behavior as defined in ATA-7.
So, maybe we don't need the word 62 patch at this moment.
(And I guess few vendor is going to implement it in the future:
depending on host software for the DMA direction isn't too backward
compatible with old host software.)

The following are test results:
(Tested with SiI 3112 SATA adapter + LITEON SOHR-5238S CD-RW drive.)

1. SiI 3611:
   - ATAPI DMA supported (DMADIR needed)
   - id[62] == 0
   - IDENTIFY PACKET DEVICE unchanged

2. SiI 3811:
   There is a jumper on board. When the jumper installed (default),
   DMADIR is not needed.
   - ATAPI DMA supported (DMADIR not needed)
   - id[62] == 0
   - IDENTIFY PACKET DEVICE unchanged

   When the jumper is removed, SiI 3811 behaves like SiI 3611
   and needs the DMADIR bit for ATAPI DMA to work.

3. Marvell 88i8030:
   - ATAPI not supported. Device timeout on probe.

4. Marvell 88SA8040:
   - ATAPI DMA supported (DMADIR not needed)
   - id[62] == 0
   - IDENTIFY PACKET DEVICE unchanged

5. Marvell 88SA8050:
   - Not tested

6. Acard ARC770:
   - ATAPI DMA supported (DMADIR not needed)
   - id[62] == 0
   - IDENTIFY PACKET DEVICE mangled to report "no MWDMA support".
     (UDMA is supported.)

7. JMicron JM20330:
   - ATAPI DMA supported (DMADIR not needed)
   - id[62] == 0
   - IDENTIFY PACKET DEVICE mangled. id[76] == 0x0202 id[78] == 0008.
     (Don't know why yet. Maybe device signature?)

Summary:
  SiI 3611 is currently the only known chip that needs DMADIR.
Since SiI 3611 doesn't implement the ATA-7 word 62 or mangle identify
packet device data, it's hard to check the chip and turn on the DMADIR
support automatically. (Currently the libata DMADIR support can be 
turned on manually by module parameter.)

To turn on the DMADIR support automatically, maybe we can check whether
the ATAPI device is bridged (by ata_dev_knobble()). If bridged, we can
try to issue a ATAPI DMA read command to check if ATAPI DMA works.
If not work, then try turning on DMADIR or turn off ATAPI DMA.
--
albert
     

Re: [PATCH/RFC] libata: turn on the ATAPI DMADIR support per word 62 (revised)

[Jeff Garzik]

Albert Lee wrote:
> Summary:
>   SiI 3611 is currently the only known chip that needs DMADIR.
> Since SiI 3611 doesn't implement the ATA-7 word 62 or mangle identify
> packet device data, it's hard to check the chip and turn on the DMADIR
> support automatically. (Currently the libata DMADIR support can be 
> turned on manually by module parameter.)

Wonderful test report, thanks a _bunch_ for investigating this.


> To turn on the DMADIR support automatically, maybe we can check whether
> the ATAPI device is bridged (by ata_dev_knobble()). If bridged, we can
> try to issue a ATAPI DMA read command to check if ATAPI DMA works.
> If not work, then try turning on DMADIR or turn off ATAPI DMA.

Sounds like more complexity than its worth, for one non-spec-compliant 
bridge chip.  The module option gets the 3611 going, so IMO the current 
level of support is adequate.

BTW, I found a 3611 here, and put it into my primary fileserver, 
attaching to a DMA-capable PATA CD-RW drive.

	Jeff