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

[PATCH] libata: convert ATAPI_ENABLE_DMADIR to module parameter

[Albert Lee]

Convert the ATAPI_ENABLE_DMADIR compile time option needed
by some SATA-PATA bridge to runtime module parameter.

Signed-off-by: Albert Lee <albertcc@tw.ibm.com>
---
Before we can detect the bridge chips which need the ATAPI DMADIR workaround
automatically, maybe using a module parameter is easier for the end users to
turn on this option.

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

--- upstream/drivers/scsi/libata-core.c	2006-04-03 13:15:20.000000000 +0800
+++ upstream_dmadir/drivers/scsi/libata-core.c	2006-04-04 10:40:39.000000000 +0800
@@ -76,6 +76,10 @@ int atapi_enabled = 1;
 module_param(atapi_enabled, int, 0444);
 MODULE_PARM_DESC(atapi_enabled, "Enable discovery of ATAPI devices (0=off, 1=on)");
 
+int atapi_dmadir = 0;
+module_param(atapi_dmadir, int, 0444);
+MODULE_PARM_DESC(atapi_dmadir, "Enable ATAPI DMADIR bridge support (0=off, 1=on)");
+
 int libata_fua = 0;
 module_param_named(fua, libata_fua, int, 0444);
 MODULE_PARM_DESC(fua, "FUA support (0=off, 1=on)");
--- upstream/drivers/scsi/libata-scsi.c	2006-04-03 13:15:20.000000000 +0800
+++ upstream_dmadir/drivers/scsi/libata-scsi.c	2006-04-04 10:33:52.000000000 +0800
@@ -2163,11 +2163,9 @@ static unsigned int atapi_xlat(struct at
 		qc->tf.protocol = ATA_PROT_ATAPI_DMA;
 		qc->tf.feature |= ATAPI_PKT_DMA;
 
-#ifdef ATAPI_ENABLE_DMADIR
-		/* some SATA bridges need us to indicate data xfer direction */
-		if (cmd->sc_data_direction != DMA_TO_DEVICE)
+		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;
-#endif
 	}
 
 	qc->nbytes = cmd->bufflen;
--- upstream/drivers/scsi/libata.h	2006-04-03 13:15:20.000000000 +0800
+++ upstream_dmadir/drivers/scsi/libata.h	2006-04-04 10:39:14.000000000 +0800
@@ -41,6 +41,7 @@ struct ata_scsi_args {
 
 /* libata-core.c */
 extern int atapi_enabled;
+extern int atapi_dmadir;
 extern int libata_fua;
 extern struct ata_queued_cmd *ata_qc_new_init(struct ata_port *ap,
 				      struct ata_device *dev);
--- upstream/include/linux/libata.h	2006-04-03 13:15:27.000000000 +0800
+++ upstream_dmadir/include/linux/libata.h	2006-04-04 10:41:01.000000000 +0800
@@ -44,7 +44,6 @@
 #undef ATA_NDEBUG		/* define to disable quick runtime checks */
 #undef ATA_ENABLE_PATA		/* define to enable PATA support in some
 				 * low-level drivers */
-#undef ATAPI_ENABLE_DMADIR	/* enables ATAPI DMADIR bridge support */
 
 
 /* note: prints function name for you */

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: [PATCH] libata: convert ATAPI_ENABLE_DMADIR to module parameter

[Tejun Heo]

Albert Lee wrote:
> Convert the ATAPI_ENABLE_DMADIR compile time option needed
> by some SATA-PATA bridge to runtime module parameter.
> 
> Signed-off-by: Albert Lee <albertcc@tw.ibm.com>

Acked-by: Tejun Heo <htejun@gmail.com>

-- 
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: [PATCH] libata: convert ATAPI_ENABLE_DMADIR to module parameter

[Jeff Garzik]

Albert Lee wrote:
> Convert the ATAPI_ENABLE_DMADIR compile time option needed
> by some SATA-PATA bridge to runtime module parameter.
> 
> Signed-off-by: Albert Lee <albertcc@tw.ibm.com>
> ---
> Before we can detect the bridge chips which need the ATAPI DMADIR workaround
> automatically, maybe using a module parameter is easier for the end users to
> turn on this option.

agreed, applied

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]

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",