Re: [PATCH #upstream-fixes] libata: implement and use HORKAGE_NOSETXFER

Re: [PATCH #upstream-fixes] libata: implement and use HORKAGE_NOSETXFER

[Moritz Rigler]

>There are two more reports linked from the thread.

>  http://ubuntuforums.org/showthread.php?t=986871
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/299865

There are also
https://bugs.launchpad.net/ubuntu/+bug/305724
http://ubuntuforums.org/showthread.php?t=1031170
http://forum.ubuntu-it.org/index.php?topic=230995.msg1741414
The problem appears at least on two models (Sony Vaio FW and Sony Vaio VGN-NS11S). So I really don't agree with your "one report, from one user, with one configuration, on one controller, using one firmware set" statement, Alan.

I think that the particular laptop model I have (Sony Vaio VGN-NS11S) has sold in large numbers only recently. So if you decide to do nothing there will likely be more reports soon. If you wait for that to happen a good share of the users encountering the problem will (unjustly) blame it on Linux and just turn back to using preinstalled Vista (where the drive works). I've already thought myself that it was perhaps unwise to run Linux on a newly bought computer (where issues like this have not been fixed yet).

>That said, Moritz, can you please post the output of "hdparm -I" with
>and without the quirk applied?  
unpatched:
http://article.gmane.org/gmane.linux.ide/36819
patched:
http://article.gmane.org/gmane.linux.ide/36840

>And can you please use a preoper mail
>address?
Hope you like this one better.

Regards,
Moritz
-- 
Sensationsangebot verlängert: GMX FreeDSL - Telefonanschluss + DSL 
für nur 16,37 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K1308T4569a

Re: [PATCH #upstream-fixes] libata: implement and use HORKAGE_NOSETXFER

[Alan Cox]

> The problem appears at least on two models (Sony Vaio FW and Sony Vaio VGN-NS11S). So I really don't agree with you "one report, from one user, with one configuration, on one controller, using one firmware set" statement, Alan.

Thanks - yours was the only one I had seen references too. I don't spend
my days reading the Ubuntu forums.

> (where issues like this have not been fixed yet).

Its probably a better idea to buy a computer that appears to work in the
way it is expected yes. However there is more to making a good quality
OS than running around flapping at every warped piece of hardware we
meet. It would be good if this works but it would also be good to know
therefore why it happens to work in Vista - are the delays longer, are
they clearing some other undefined command bits that the spec says don't
matter etc.

Simply saying 'oh it didn't work lets just pretend we don't care' isn't
always a good idea, particuarly when the worst case failure for it on
other devices where it indicates a real failing might be corruption of
user data.

Yes - I'd like it to just work, but I'd like it to just work without
breaking anything else, without adding device specific special cases and
ideally in a way that makes other stuff that is similarly odd just work
too.

Alan

Re: [PATCH #upstream-fixes] libata: implement and use HORKAGE_NOSETXFER

[Robert Hancock]

Alan Cox wrote:
>> The problem appears at least on two models (Sony Vaio FW and Sony Vaio VGN-NS11S). So I really don't agree with you "one report, from one user, with one configuration, on one controller, using one firmware set" statement, Alan.
> 
> Thanks - yours was the only one I had seen references too. I don't spend
> my days reading the Ubuntu forums.
> 
>> (where issues like this have not been fixed yet).
> 
> Its probably a better idea to buy a computer that appears to work in the
> way it is expected yes. However there is more to making a good quality
> OS than running around flapping at every warped piece of hardware we
> meet. It would be good if this works but it would also be good to know
> therefore why it happens to work in Vista - are the delays longer, are
> they clearing some other undefined command bits that the spec says don't
> matter etc.
> 
> Simply saying 'oh it didn't work lets just pretend we don't care' isn't
> always a good idea, particuarly when the worst case failure for it on
> other devices where it indicates a real failing might be corruption of
> user data.
> 
> Yes - I'd like it to just work, but I'd like it to just work without
> breaking anything else, without adding device specific special cases and
> ideally in a way that makes other stuff that is similarly odd just work
> too.

I wonder if whatever storage driver Sony has it set up to run with in 
Vista is just skipping the set transfer mode command on SATA devices?

If you guys still have the Vista install, can you tell us what driver 
it's using in Windows (the Intel one, standard Microsoft AHCI, etc?)

Re: [PATCH #upstream-fixes] libata: implement and use HORKAGE_NOSETXFER

[Tejun Heo]

Hello, Alan, Moritz.

Alan Cox wrote:
>> The problem appears at least on two models (Sony Vaio FW and Sony
>> Vaio VGN-NS11S). So I really don't agree with you "one report, from
>> one user, with one configuration, on one controller, using one
>> firmware set" statement, Alan.
> Thanks - yours was the only one I had seen references too. I don't
> spend my days reading the Ubuntu forums.
> 
>> (where issues like this have not been fixed yet).
> 
> Its probably a better idea to buy a computer that appears to work in the
> way it is expected yes. However there is more to making a good quality
> OS than running around flapping at every warped piece of hardware we
> meet. It would be good if this works but it would also be good to know
> therefore why it happens to work in Vista - are the delays longer, are
> they clearing some other undefined command bits that the spec says don't
> matter etc.
> 
> Simply saying 'oh it didn't work lets just pretend we don't care' isn't
> always a good idea, particuarly when the worst case failure for it on
> other devices where it indicates a real failing might be corruption of
> user data.
>
> Yes - I'd like it to just work, but I'd like it to just work without
> breaking anything else, without adding device specific special cases and
> ideally in a way that makes other stuff that is similarly odd just work
> too.

Then, how do you suggest proceeding on it?  Without a bus tracer, we
can't easily tell what Windows is doing and on native SATA skipping
SETXFER isn't likely to cause any serious problem.  It's basically
noop.

If you're worried about the match being triggered on unaffected
configurations, how about doing a DMI & device ID match, so we flip
the stupid quirk only on the stupid machine?  It's not like we're
adding a lot of complexities and it's not likely that someone would
invest the time and resource to root-cause problem this specific
unless it begins to appear on other places.  So, let's get the thing
working and if similar problems creep up on other machines, deal with
them then.

Thanks.

-- 
tejun

Re: [PATCH #upstream-fixes] libata: implement and use HORKAGE_NOSETXFER

[Alan Cox]

> > Yes - I'd like it to just work, but I'd like it to just work without
> > breaking anything else, without adding device specific special cases and
> > ideally in a way that makes other stuff that is similarly odd just work
> > too.
> 
> Then, how do you suggest proceeding on it?  Without a bus tracer, we
> can't easily tell what Windows is doing and on native SATA skipping
> SETXFER isn't likely to cause any serious problem.  It's basically
> noop.

I would suggest we issue the SETXFER always. If it times out then we will
revalidate the identify data so we can use that to see what mode we are
actually in.

Alan

Re: [PATCH #upstream-fixes] libata: implement and use HORKAGE_NOSETXFER

[Tejun Heo]

Alan Cox wrote:
>>> Yes - I'd like it to just work, but I'd like it to just work without
>>> breaking anything else, without adding device specific special cases and
>>> ideally in a way that makes other stuff that is similarly odd just work
>>> too.
>> Then, how do you suggest proceeding on it?  Without a bus tracer, we
>> can't easily tell what Windows is doing and on native SATA skipping
>> SETXFER isn't likely to cause any serious problem.  It's basically
>> noop.
> 
> I would suggest we issue the SETXFER always. If it times out then we will
> revalidate the identify data so we can use that to see what mode we are
> actually in.

Hmmm... our current timeout for SETXFER is 5s, so it wouldn't be nice
but not too bad either.  Alright, I'll brew up something.

-- 
tejun

Re: [PATCH #upstream-fixes] libata: implement and use HORKAGE_NOSETXFER

[Tejun Heo]

Tejun Heo wrote:
> Alan Cox wrote:
>>>> Yes - I'd like it to just work, but I'd like it to just work without
>>>> breaking anything else, without adding device specific special cases and
>>>> ideally in a way that makes other stuff that is similarly odd just work
>>>> too.
>>> Then, how do you suggest proceeding on it?  Without a bus tracer, we
>>> can't easily tell what Windows is doing and on native SATA skipping
>>> SETXFER isn't likely to cause any serious problem.  It's basically
>>> noop.
>> I would suggest we issue the SETXFER always. If it times out then we will
>> revalidate the identify data so we can use that to see what mode we are
>> actually in.
> 
> Hmmm... our current timeout for SETXFER is 5s, so it wouldn't be nice
> but not too bad either.  Alright, I'll brew up something.

Hmm... There's a problem.  After a timeout, libata EH always resets
and reset can reset transfer mode settings and stuff, so the whole
dancing becomes a bit pointless.  The device in question in this case
seems to retain (either that or udma/33 is the default which is
unlikely) the configuration over resets but I'm skeptical how useful
such logic would be generally.

We can change EH logic such that it does its best to issue IDENTIFY
after a SETXFER timeout without reset but that's likely to bring more
problem than it solves.  Some LLDs might be okay with it but there
simply is no guarantee.  Given the rarity, I don't think the problem
warrants such major behavior change.

Any more thoughts?

Thanks.

-- 
tejun

Re: [PATCH #upstream-fixes] libata: implement and use HORKAGE_NOSETXFER

[Moritz Rigler]

>There are two more reports linked from the thread.

>  http://ubuntuforums.org/showthread.php?t=986871
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/299865

There are also
https://bugs.launchpad.net/ubuntu/+bug/305724
http://ubuntuforums.org/showthread.php?t=1031170
http://forum.ubuntu-it.org/index.php?topic=230995.msg1741414
The problem appears at least on two models (Sony Vaio FW and Sony Vaio VGN-NS11S). So I really don't agree with your "one report, from one user, with one configuration, on one controller, using one firmware set" statement, Alan.

I think that the particular laptop model I have (Sony Vaio VGN-NS11S) has sold in large numbers only recently. So if you decide to do nothing there will likely be more reports soon. If you wait for that to happen a good share of the users encountering the problem will (unjustly) blame it on Linux and just turn back to using preinstalled Vista (where the drive works). I've already thought myself that it was perhaps unwise to run Linux on a newly bought computer (where issues like this have not been fixed yet).

>That said, Moritz, can you please post the output of "hdparm -I" with
>and without the quirk applied?  
unpatched:
http://article.gmane.org/gmane.linux.ide/36819
patched:
http://article.gmane.org/gmane.linux.ide/36840

>And can you please use a preoper mail
>address?
Hope you like this one better.

Regards,
Moritz


-- 
Sensationsangebot verlängert: GMX FreeDSL - Telefonanschluss + DSL 
für nur 16,37 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K1308T4569a

PIONEER DVD-RW DVRTD08 is disabled if there is no disc present at boot time

[linux-ide]

Hello,
several Sony Vaio laptops seem to have the PIONEER DVD-RW DVRTD08 DVD/CD
drive built in. This drive is available only when a disc is inserted
during boot.
when no disc is present, dmesg has

[    3.715535] ata2: SATA max UDMA/133 abar m2048@0xd3e04000 port
0xd3e04180 irq 218
[    4.368166] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[    4.380063] ata2.00: ATAPI: PIONEER DVD-RW  DVRTD08, 1.00, max UDMA/33
[    9.380102] ata2.00: qc timeout (cmd 0xef)
[    9.380112] ata2.00: failed to set xfermode (err_mask=0x4)
[    9.700093] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[   19.712097] ata2.00: qc timeout (cmd 0xef)
[   19.712105] ata2.00: failed to set xfermode (err_mask=0x4)
[   19.712158] ata2: limiting SATA link speed to 1.5 Gbps
[   19.712160] ata2.00: limiting speed to UDMA/33:PIO3
[   20.032106] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
[   30.040084] ata2.00: qc timeout (cmd 0xef)
[   30.040091] ata2.00: failed to set xfermode (err_mask=0x4)
[   30.040144] ata2.00: disabled
[   30.056102] ata2: hard resetting link
[   30.376108] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
[   30.376114] ata2: EH complete

when a disc is present, dmesg has
[    3.804304] ata2: SATA max UDMA/133 irq_stat 0x00000040, cirq 219
[    5.268599] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[    5.270213] ata2.00: ATAPI: PIONEER DVD-RW  DVRTD08, 1.00, max UDMA/33
[    5.272217] ata2.00: configured for UDMA/33

You'll find more details at http://ubuntuforums.org/showthread.php?p=6412465#post6412465

Having read http://www.mail-archive.com/linux-ide@vger.kernel.org/msg06127.html I guess it is not OK for the device to timeout in response to 0xef.
Still I would like to be able to use the drive without having to insert a CD at every boot. Is there any workaround? Can't the driver just treat
repeated timeouts like it would treat an abort?

Any help would be greatly appreciated.
Regards,
Moritz Rigler

Re: PIONEER DVD-RW DVRTD08 is disabled if there is no disc present at boot time

[Robert Hancock]

linux-ide@momail.e4ward.com wrote:
> Hello,
> several Sony Vaio laptops seem to have the PIONEER DVD-RW DVRTD08 DVD/CD
> drive built in. This drive is available only when a disc is inserted
> during boot.
> when no disc is present, dmesg has
> 
> [    3.715535] ata2: SATA max UDMA/133 abar m2048@0xd3e04000 port
> 0xd3e04180 irq 218
> [    4.368166] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> [    4.380063] ata2.00: ATAPI: PIONEER DVD-RW  DVRTD08, 1.00, max UDMA/33
> [    9.380102] ata2.00: qc timeout (cmd 0xef)
> [    9.380112] ata2.00: failed to set xfermode (err_mask=0x4)
> [    9.700093] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> [   19.712097] ata2.00: qc timeout (cmd 0xef)
> [   19.712105] ata2.00: failed to set xfermode (err_mask=0x4)
> [   19.712158] ata2: limiting SATA link speed to 1.5 Gbps
> [   19.712160] ata2.00: limiting speed to UDMA/33:PIO3
> [   20.032106] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
> [   30.040084] ata2.00: qc timeout (cmd 0xef)
> [   30.040091] ata2.00: failed to set xfermode (err_mask=0x4)
> [   30.040144] ata2.00: disabled
> [   30.056102] ata2: hard resetting link
> [   30.376108] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
> [   30.376114] ata2: EH complete
> 
> when a disc is present, dmesg has
> [    3.804304] ata2: SATA max UDMA/133 irq_stat 0x00000040, cirq 219
> [    5.268599] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> [    5.270213] ata2.00: ATAPI: PIONEER DVD-RW  DVRTD08, 1.00, max UDMA/33
> [    5.272217] ata2.00: configured for UDMA/33
> 
> You'll find more details at http://ubuntuforums.org/showthread.php?p=6412465#post6412465
> 
> Having read http://www.mail-archive.com/linux-ide@vger.kernel.org/msg06127.html I guess it is not OK for the device to timeout in response to 0xef.
> Still I would like to be able to use the drive without having to insert a CD at every boot. Is there any workaround? Can't the driver just treat
> repeated timeouts like it would treat an abort?

That case was a bit different in that it was a CompactFlash device 
(which has some different rules, especially older ones), but there was 
also a SATA-PATA bridge chip involved (which seems quite likely the case 
here too since the drive reports UDMA33 maximum). This could be another 
case of the bridge chip being broken. Set Features - Set Transfer Mode 
is a mandatory command that all ATA devices must implement, and the 
device really can't be used properly if it's not successful (for true 
SATA devices it's mostly vestigial, but if there's any actual PATA 
involved, it's required). It's rather bizarre that having a disc 
inserted avoids the problem.

Is there any firmware update available for the drive?

Re: PIONEER DVD-RW DVRTD08 is disabled if there is no disc present at boot time

[Tejun Heo]

Robert Hancock wrote:
> linux-ide@momail.e4ward.com wrote:
>> Hello,
>> several Sony Vaio laptops seem to have the PIONEER DVD-RW DVRTD08 DVD/CD
>> drive built in. This drive is available only when a disc is inserted
>> during boot.
>> when no disc is present, dmesg has
>>
>> [    3.715535] ata2: SATA max UDMA/133 abar m2048@0xd3e04000 port
>> 0xd3e04180 irq 218
>> [    4.368166] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
>> [    4.380063] ata2.00: ATAPI: PIONEER DVD-RW  DVRTD08, 1.00, max UDMA/33
>> [    9.380102] ata2.00: qc timeout (cmd 0xef)
>> [    9.380112] ata2.00: failed to set xfermode (err_mask=0x4)
>> [    9.700093] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
>> [   19.712097] ata2.00: qc timeout (cmd 0xef)
>> [   19.712105] ata2.00: failed to set xfermode (err_mask=0x4)
>> [   19.712158] ata2: limiting SATA link speed to 1.5 Gbps
>> [   19.712160] ata2.00: limiting speed to UDMA/33:PIO3
>> [   20.032106] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
>> [   30.040084] ata2.00: qc timeout (cmd 0xef)
>> [   30.040091] ata2.00: failed to set xfermode (err_mask=0x4)
>> [   30.040144] ata2.00: disabled
>> [   30.056102] ata2: hard resetting link
>> [   30.376108] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
>> [   30.376114] ata2: EH complete
>>
>> when a disc is present, dmesg has
>> [    3.804304] ata2: SATA max UDMA/133 irq_stat 0x00000040, cirq 219
>> [    5.268599] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
>> [    5.270213] ata2.00: ATAPI: PIONEER DVD-RW  DVRTD08, 1.00, max UDMA/33
>> [    5.272217] ata2.00: configured for UDMA/33
>>
>> You'll find more details at
>> http://ubuntuforums.org/showthread.php?p=6412465#post6412465
>>
>> Having read
>> http://www.mail-archive.com/linux-ide@vger.kernel.org/msg06127.html I
>> guess it is not OK for the device to timeout in response to 0xef.
>> Still I would like to be able to use the drive without having to
>> insert a CD at every boot. Is there any workaround? Can't the driver
>> just treat
>> repeated timeouts like it would treat an abort?
> 
> That case was a bit different in that it was a CompactFlash device
> (which has some different rules, especially older ones), but there was
> also a SATA-PATA bridge chip involved (which seems quite likely the case
> here too since the drive reports UDMA33 maximum). This could be another
> case of the bridge chip being broken. Set Features - Set Transfer Mode
> is a mandatory command that all ATA devices must implement, and the
> device really can't be used properly if it's not successful (for true
> SATA devices it's mostly vestigial, but if there's any actual PATA
> involved, it's required). It's rather bizarre that having a disc
> inserted avoids the problem.

Aiee... these broken devices.  :-(

So, w/ a disk inserted, there's no error whatsoever?  Can you please
post the output of "hdparm -I /dev/sr0"?

-- 
tejun

Re: PIONEER DVD-RW DVRTD08 is disabled if there is no disc present at boot time

[linux-ide]

Am Montag, den 22.12.2008, 19:02 +0900 schrieb ein unbekannter Absender:
> Robert Hancock wrote:
> > linux-ide@momail.e4ward.com wrote:
> >> Hello,
> >> several Sony Vaio laptops seem to have the PIONEER DVD-RW DVRTD08 DVD/CD
> >> drive built in. This drive is available only when a disc is inserted
> >> during boot.
> >> when no disc is present, dmesg has
> >>
> >> [    3.715535] ata2: SATA max UDMA/133 abar m2048@0xd3e04000 port
> >> 0xd3e04180 irq 218
> >> [    4.368166] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> >> [    4.380063] ata2.00: ATAPI: PIONEER DVD-RW  DVRTD08, 1.00, max UDMA/33
> >> [    9.380102] ata2.00: qc timeout (cmd 0xef)
> >> [    9.380112] ata2.00: failed to set xfermode (err_mask=0x4)
> >> [    9.700093] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> >> [   19.712097] ata2.00: qc timeout (cmd 0xef)
> >> [   19.712105] ata2.00: failed to set xfermode (err_mask=0x4)
> >> [   19.712158] ata2: limiting SATA link speed to 1.5 Gbps
> >> [   19.712160] ata2.00: limiting speed to UDMA/33:PIO3
> >> [   20.032106] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
> >> [   30.040084] ata2.00: qc timeout (cmd 0xef)
> >> [   30.040091] ata2.00: failed to set xfermode (err_mask=0x4)
> >> [   30.040144] ata2.00: disabled
> >> [   30.056102] ata2: hard resetting link
> >> [   30.376108] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
> >> [   30.376114] ata2: EH complete
> >>
> >> when a disc is present, dmesg has
> >> [    3.804304] ata2: SATA max UDMA/133 irq_stat 0x00000040, cirq 219
> >> [    5.268599] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> >> [    5.270213] ata2.00: ATAPI: PIONEER DVD-RW  DVRTD08, 1.00, max UDMA/33
> >> [    5.272217] ata2.00: configured for UDMA/33
> >>
> >> You'll find more details at
> >> http://ubuntuforums.org/showthread.php?p=6412465#post6412465
> >>
> >> Having read
> >> http://www.mail-archive.com/linux-ide@vger.kernel.org/msg06127.html I
> >> guess it is not OK for the device to timeout in response to 0xef.
> >> Still I would like to be able to use the drive without having to
> >> insert a CD at every boot. Is there any workaround? Can't the driver
> >> just treat
> >> repeated timeouts like it would treat an abort?
> > 
> > That case was a bit different in that it was a CompactFlash device
> > (which has some different rules, especially older ones), but there was
> > also a SATA-PATA bridge chip involved (which seems quite likely the case
> > here too since the drive reports UDMA33 maximum). This could be another
> > case of the bridge chip being broken. Set Features - Set Transfer Mode
> > is a mandatory command that all ATA devices must implement, and the
> > device really can't be used properly if it's not successful (for true
> > SATA devices it's mostly vestigial, but if there's any actual PATA
> > involved, it's required). It's rather bizarre that having a disc
> > inserted avoids the problem.
> 
> Aiee... these broken devices.  :-(
> 
> So, w/ a disk inserted, there's no error whatsoever?  
There's no error in dmesg output. But when I boot with a disk in the
drive, I get the following errors in the boot screen:
* Loading hardware devices
[23.927373] end_request: I/O error, dev sr0, sector 1431744
[23.927373] Buffer I/O error on device sr0, logical block 178968
and then several more with just a different number in the square
brackets. However, that does not seem to affect the operation of the
drive.
> Can you please
> post the output of "hdparm -I /dev/sr0"?

/dev/sr0:

ATAPI CD-ROM, with removable media
	Model Number:       PIONEER DVD-RW  DVRTD08                 
	Serial Number:      
	Firmware Revision:  1.00    
Standards:
	Likely used CD-ROM ATAPI-1
Configuration:
	DRQ response: 50us.
	Packet size: 12 bytes
Capabilities:
	LBA, IORDY(can be disabled)
	Buffer size: 64.0kB
	DMA: mdma0 mdma1 mdma2 udma0 udma1 *udma2 
	     Cycle time: min=120ns recommended=120ns
	PIO: pio0 pio1 pio2 pio3 pio4 
	     Cycle time: no flow control=120ns  IORDY flow control=120ns
Commands/features:
	Enabled	Supported:
	   *	Power Management feature set
	   *	PACKET command feature set
	   *	DEVICE_RESET command
	   *	NOP cmd
	   *	SATA-I signaling speed (1.5Gb/s)
	   *	Host-initiated interface power management
	   *	Phy event counters
	    	Device-initiated interface power management
	   *	Software settings preservation

Re: PIONEER DVD-RW DVRTD08 is disabled if there is no disc present at boot time

[Tejun Heo]

[-- Attachment #1: Type: text/plain, Size: 690 bytes --]

linux-ide@momail.e4ward.com wrote:
> There's no error in dmesg output. But when I boot with a disk in the
> drive, I get the following errors in the boot screen:
> * Loading hardware devices
> [23.927373] end_request: I/O error, dev sr0, sector 1431744
> [23.927373] Buffer I/O error on device sr0, logical block 178968
> and then several more with just a different number in the square
> brackets. However, that does not seem to affect the operation of the
> drive.

Does the attached patch fix the problem?  Please do some data
integrity checks as it skips setxfermode on the drive.  If it's native
SATA, it probably should be okay but still it's way out of the spec.

Thanks.

-- 
tejun

[-- Attachment #2: nosetxfer.patch --]
[-- Type: text/x-patch, Size: 1518 bytes --]

diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index c71f3ac..d89817a 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -3303,14 +3303,17 @@ static int ata_dev_set_mode(struct ata_device *dev)
 	struct ata_eh_context *ehc = &dev->link->eh_context;
 	const char *dev_err_whine = "";
 	int ign_dev_err = 0;
-	unsigned int err_mask;
+	unsigned int err_mask = 0;
 	int rc;
 
 	dev->flags &= ~ATA_DFLAG_PIO;
 	if (dev->xfer_shift == ATA_SHIFT_PIO)
 		dev->flags |= ATA_DFLAG_PIO;
 
-	err_mask = ata_dev_set_xfermode(dev);
+	if (!(dev->horkage & ATA_HORKAGE_NOSETXFER))
+		err_mask = ata_dev_set_xfermode(dev);
+	else
+		dev_err_whine = " (SET_XFERMODE skipped)";
 
 	if (err_mask & ~AC_ERR_DEV)
 		goto fail;
@@ -4132,6 +4135,8 @@ static const struct ata_blacklist_entry ata_device_blacklist [] = {
 	/* Devices that do not need bridging limits applied */
 	{ "MTRON MSP-SATA*",		NULL,	ATA_HORKAGE_BRIDGE_OK, },
 
+	{ "PIONEER DVD-RW  DVRTD08",	"1.00",	ATA_HORKAGE_NOSETXFER },
+
 	/* End Marker */
 	{ }
 };
diff --git a/include/linux/libata.h b/include/linux/libata.h
index b79c319..f647d26 100644
--- a/include/linux/libata.h
+++ b/include/linux/libata.h
@@ -376,6 +376,7 @@ enum {
 	ATA_HORKAGE_BRIDGE_OK	= (1 << 10),	/* no bridge limits */
 	ATA_HORKAGE_ATAPI_MOD16_DMA = (1 << 11), /* use ATAPI DMA for commands
 						    not multiple of 16 bytes */
+	ATA_HORKAGE_NOSETXFER	= (1 << 12),
 
 	 /* DMA mask for user DMA control: User visible values; DO NOT
 	    renumber */

Re: PIONEER DVD-RW DVRTD08 is disabled if there is no disc present at boot time

[linux-ide]

Hello,
I've tried the patch (thanks a lot for your help) and it works more or
less. 

More precisely:
when booting without a CD in the drive:
* no errors during the boot
* the drive is now active (that's a big plus)
* it can read about half the CDs that I insert (in a sample of ~7 audio
and data, burnt and pressed), I have tested no DVDs yet, and I haven't
burnt anything yet
* sudo hdparm -I /dev/sr0 now gives

/dev/sr0:

ATAPI CD-ROM, with removable media
	Model Number:       PIONEER DVD-RW  DVRTD08                 
	Serial Number:      
	Firmware Revision:  1.00    
Standards:
	Likely used CD-ROM ATAPI-1
Configuration:
	DRQ response: 50us.
	Packet size: 12 bytes
Capabilities:
	LBA, IORDY(can be disabled)
	Buffer size: 64.0kB
	DMA: mdma0 mdma1 mdma2 udma0 udma1 *udma2 
	     Cycle time: min=120ns recommended=120ns
	PIO: pio0 pio1 pio2 pio3 pio4 
	     Cycle time: no flow control=120ns  IORDY flow control=120ns
Commands/features:
	Enabled	Supported:
	   *	Power Management feature set
	   *	PACKET command feature set
	   *	DEVICE_RESET command
	   *	NOP cmd
	   *	SATA-I signaling speed (1.5Gb/s)
	   *	Host-initiated interface power management
	   *	Phy event counters
	    	Device-initiated interface power management
	   *	Software settings preservation


* and the error log when a CD can't be read looks like this (dmesg tail)
[  227.213893] sr 1:0:0:0: [sr0] Result: hostbyte=DID_OK
driverbyte=DRIVER_SENSE,SUGGEST_OK
[  227.213914] sr 1:0:0:0: [sr0] Sense Key : Medium Error [current] 
[  227.213926] Info fld=0x2e81
[  227.213930] sr 1:0:0:0: [sr0] Add. Sense: L-EC uncorrectable error
[  227.213942] end_request: I/O error, dev sr0, sector 47616
[  227.213954] Buffer I/O error on device sr0, logical block 5952
[  234.227424] sr 1:0:0:0: [sr0] Result: hostbyte=DID_OK
driverbyte=DRIVER_SENSE,SUGGEST_OK
[  234.227446] sr 1:0:0:0: [sr0] Sense Key : Medium Error [current] 
[  234.227457] Info fld=0x2e81
[  234.227461] sr 1:0:0:0: [sr0] Add. Sense: L-EC uncorrectable error
[  234.227473] end_request: I/O error, dev sr0, sector 47616
[  234.227484] Buffer I/O error on device sr0, logical block 5952
[  241.163142] sr 1:0:0:0: [sr0] Result: hostbyte=DID_OK
driverbyte=DRIVER_SENSE,SUGGEST_OK
[  241.163162] sr 1:0:0:0: [sr0] Sense Key : Medium Error [current] 
[  241.163173] Info fld=0x2e81
[  241.163177] sr 1:0:0:0: [sr0] Add. Sense: L-EC uncorrectable error
[  241.163189] end_request: I/O error, dev sr0, sector 47616
[  241.163200] Buffer I/O error on device sr0, logical block 5952
[  248.171706] sr 1:0:0:0: [sr0] Result: hostbyte=DID_OK
driverbyte=DRIVER_SENSE,SUGGEST_OK
[  248.171726] sr 1:0:0:0: [sr0] Sense Key : Medium Error [current] 
[  248.171738] Info fld=0x2e81
[  248.171742] sr 1:0:0:0: [sr0] Add. Sense: L-EC uncorrectable error
[  248.171754] end_request: I/O error, dev sr0, sector 47616
[  248.171765] Buffer I/O error on device sr0, logical block 5952
[  255.183025] sr 1:0:0:0: [sr0] Result: hostbyte=DID_OK
driverbyte=DRIVER_SENSE,SUGGEST_OK
[  255.183044] sr 1:0:0:0: [sr0] Sense Key : Medium Error [current] 
[  255.183056] Info fld=0x2e81
[  255.183060] sr 1:0:0:0: [sr0] Add. Sense: L-EC uncorrectable error
[  255.183072] end_request: I/O error, dev sr0, sector 47616
[  255.183083] Buffer I/O error on device sr0, logical block 5952
[  262.195902] sr 1:0:0:0: [sr0] Result: hostbyte=DID_OK
driverbyte=DRIVER_SENSE,SUGGEST_OK
[  262.195920] sr 1:0:0:0: [sr0] Sense Key : Medium Error [current] 
[  262.195932] Info fld=0x2e81
[  262.195936] sr 1:0:0:0: [sr0] Add. Sense: L-EC uncorrectable error
[  262.195948] end_request: I/O error, dev sr0, sector 47616
[  262.195961] Buffer I/O error on device sr0, logical block 5952
[  269.198031] sr 1:0:0:0: [sr0] Result: hostbyte=DID_OK
driverbyte=DRIVER_SENSE,SUGGEST_OK
[  269.198051] sr 1:0:0:0: [sr0] Sense Key : Medium Error [current] 
[  269.198063] Info fld=0x2e81
[  269.198067] sr 1:0:0:0: [sr0] Add. Sense: L-EC uncorrectable error
[  269.198079] end_request: I/O error, dev sr0, sector 47616
[  269.198090] Buffer I/O error on device sr0, logical block 5952
[  276.667490] sr 1:0:0:0: [sr0] Result: hostbyte=DID_OK
driverbyte=DRIVER_SENSE,SUGGEST_OK
[  276.667509] sr 1:0:0:0: [sr0] Sense Key : Medium Error [current] 
[  276.667521] Info fld=0x2e81
[  276.667525] sr 1:0:0:0: [sr0] Add. Sense: L-EC uncorrectable error
[  276.667536] end_request: I/O error, dev sr0, sector 47616
[  276.667547] Buffer I/O error on device sr0, logical block 5952

* When booting with a CD that doesn't work after an 'empty boot', I get
similar errors as before (and like the last pair of lines above), but
the CD can be read. When I insert another CD that didn't work after an
empty boot afterwards, it still doesn't work.

I guess that this is a state of things I can more or less live with
(unless you have a still better idea), I don't know whether the patch
should go in the trunk. Though it doesn't completely fix things, for me
it's better than before. Obviously, it would be best if the Pioneer
people fixed their broken firmware soon, which I hope they will.

Anyway, thank you very much for your help. With other OSs it's probably
not so easy to get developer support ;-)

Merry christmas,
Moritz



Am Dienstag, den 23.12.2008, 12:03 +0900 schrieb
linux-ide@vger.kernel.org:
> linux-ide@momail.e4ward.com wrote:
> > There's no error in dmesg output. But when I boot with a disk in the
> > drive, I get the following errors in the boot screen:
> > * Loading hardware devices
> > [23.927373] end_request: I/O error, dev sr0, sector 1431744
> > [23.927373] Buffer I/O error on device sr0, logical block 178968
> > and then several more with just a different number in the square
> > brackets. However, that does not seem to affect the operation of the
> > drive.
> 
> Does the attached patch fix the problem?  Please do some data
> integrity checks as it skips setxfermode on the drive.  If it's native
> SATA, it probably should be okay but still it's way out of the spec.
> 
> Thanks.
> 

Re: PIONEER DVD-RW DVRTD08 is disabled if there is no disc present at boot time

[Tejun Heo]

Hello,

linux-ide@momail.e4ward.com wrote:
> Hello,
> I've tried the patch (thanks a lot for your help) and it works more or
> less. 
> 
> More precisely:
> when booting without a CD in the drive:
> * no errors during the boot
> * the drive is now active (that's a big plus)
> * it can read about half the CDs that I insert (in a sample of ~7 audio
> and data, burnt and pressed), I have tested no DVDs yet, and I haven't
> burnt anything yet

Hmmm...

> * and the error log when a CD can't be read looks like this (dmesg tail)
> [  227.213893] sr 1:0:0:0: [sr0] Result: hostbyte=DID_OK
> driverbyte=DRIVER_SENSE,SUGGEST_OK
> [  227.213914] sr 1:0:0:0: [sr0] Sense Key : Medium Error [current] 
> [  227.213926] Info fld=0x2e81
> [  227.213930] sr 1:0:0:0: [sr0] Add. Sense: L-EC uncorrectable error
> [  227.213942] end_request: I/O error, dev sr0, sector 47616
> [  227.213954] Buffer I/O error on device sr0, logical block 5952
> [  234.227424] sr 1:0:0:0: [sr0] Result: hostbyte=DID_OK
> driverbyte=DRIVER_SENSE,SUGGEST_OK
> [  234.227446] sr 1:0:0:0: [sr0] Sense Key : Medium Error [current] 
> [  234.227457] Info fld=0x2e81
> [  234.227461] sr 1:0:0:0: [sr0] Add. Sense: L-EC uncorrectable error
> [  234.227473] end_request: I/O error, dev sr0, sector 47616
> [  234.227484] Buffer I/O error on device sr0, logical block 5952
> [  241.163142] sr 1:0:0:0: [sr0] Result: hostbyte=DID_OK
> driverbyte=DRIVER_SENSE,SUGGEST_OK
...
> * When booting with a CD that doesn't work after an 'empty boot', I get
> similar errors as before (and like the last pair of lines above), but
> the CD can be read. When I insert another CD that didn't work after an
> empty boot afterwards, it still doesn't work.

Those errors shouldn't have much to do with how the transport is
configured.  These are the drive failing to read the media and these
errors can be quite indetermininstic, so it's possible that the
pattern really isn't a pattern but then again the drive doesn't seem
to have much problem being peculiar.  Can you please test more times
and verify the pattern?

> I guess that this is a state of things I can more or less live with
> (unless you have a still better idea), I don't know whether the patch
> should go in the trunk. Though it doesn't completely fix things, for me
> it's better than before. Obviously, it would be best if the Pioneer
> people fixed their broken firmware soon, which I hope they will.

As the behavior is so peculiar, one thing I'm worried about is whether
the problem is common to the model or is specific to the drive.  If
the former, it should go into mainline.  Do you happen to know anyone
who has the same model?

> Anyway, thank you very much for your help. With other OSs it's probably
> not so easy to get developer support ;-)

Happy new year.  :-)

-- 
tejun

Re: PIONEER DVD-RW DVRTD08 is disabled if there is no disc present at boot time

[linux-ide]

Am Montag, den 29.12.2008, 17:14 +0900 schrieb
linux-ide@vger.kernel.org:

> ...
> > * When booting with a CD that doesn't work after an 'empty boot', I get
> > similar errors as before (and like the last pair of lines above), but
> > the CD can be read. When I insert another CD that didn't work after an
> > empty boot afterwards, it still doesn't work.
> 
> Those errors shouldn't have much to do with how the transport is
> configured.  These are the drive failing to read the media and these
> errors can be quite indetermininstic, so it's possible that the
> pattern really isn't a pattern but then again the drive doesn't seem
> to have much problem being peculiar.  Can you please test more times
> and verify the pattern?

I have randomly tested a few CDs and DVDs since my last post, and there
were none that didn't work (after an "empty boot"). Since I found all
those that did not work before at my parents' there is a chance that
those CDs were not in the best of states. I will be far from a computer
during the next couple of days. But afterwards I plan to do some more
systematic tests, and I will also attempt to burn a CD and a DVD. 
> 
> As the behavior is so peculiar, one thing I'm worried about is whether
> the problem is common to the model or is specific to the drive.  If
> the former, it should go into mainline.  Do you happen to know anyone
> who has the same model?
The basic problem seems to be common to the model (or at least to more
than just my drive) since there are several posts by other people:
http://ubuntuforums.org/showthread.php?t=986871
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/299865
None of them has a solution or workaround. I think I had found more
reports before this thread started to dominate the search engine results
on the issue. As far as I see your patch skips setxfer only after a
failed first try. That should prevent it from affecting drives that
don't show the problem.

Happy New Year,

Moritz

Re: PIONEER DVD-RW DVRTD08 is disabled if there is no disc present at boot time

[linux-ide]

Am Montag, den 29.12.2008, 22:32 +0100 schrieb ein unbekannter Absender:
> 
> Am Montag, den 29.12.2008, 17:14 +0900 schrieb
> linux-ide@vger.kernel.org:
> 
> I have randomly tested a few CDs and DVDs since my last post, and there
> were none that didn't work (after an "empty boot"). 
>  But afterwards I plan to do some more
> systematic tests, and I will also attempt to burn a CD and a DVD. 
Hi, I have successfully burnt several Video-DVDs (with growisofs; on
DVD-R and DVD+RW media), an Audio-CD (brasero) and a Data-CD (brasero).
Also, I have not experienced any more problems reading CDs or DVDs. I
guess that the CDs that did not work after I applied the patch were
damaged.
Therefore, I tend to regard the problem as fixed by tejun's patch and I
would recommend to let it go into mainline.
Thank you once more for your valuable help.
Moritz
 

[PATCH #upstream-fixes] libata: implement and use HORKAGE_NOSETXFER

[Tejun Heo]

PIONEER DVD-RW DVRTD08 times out SETXFER if no media is present.  The
device is SATA and simply skipping SETXFER works around the problem.
Implement ATA_HORKAGE_NOSETXFER and apply it to the device.

Reported by Moritz Rigler in the following thread.

  http://thread.gmane.org/gmane.linux.ide/36790

Signed-off-by: Tejun Heo <tj@kernel.org>
---
 drivers/ata/libata-core.c |   10 ++++++++--
 include/linux/libata.h    |    1 +
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index fecca42..eceaace 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -3310,14 +3310,17 @@ static int ata_dev_set_mode(struct ata_device *dev)
 	struct ata_eh_context *ehc = &dev->link->eh_context;
 	const char *dev_err_whine = "";
 	int ign_dev_err = 0;
-	unsigned int err_mask;
+	unsigned int err_mask = 0;
 	int rc;
 
 	dev->flags &= ~ATA_DFLAG_PIO;
 	if (dev->xfer_shift == ATA_SHIFT_PIO)
 		dev->flags |= ATA_DFLAG_PIO;
 
-	err_mask = ata_dev_set_xfermode(dev);
+	if (!(dev->horkage & ATA_HORKAGE_NOSETXFER))
+		err_mask = ata_dev_set_xfermode(dev);
+	else
+		dev_err_whine = " (SET_XFERMODE skipped)";
 
 	if (err_mask & ~AC_ERR_DEV)
 		goto fail;
@@ -4207,6 +4210,9 @@ static const struct ata_blacklist_entry ata_device_blacklist [] = {
 	/* Devices that do not need bridging limits applied */
 	{ "MTRON MSP-SATA*",		NULL,	ATA_HORKAGE_BRIDGE_OK, },
 
+	/* Devices which choke on SETXFER.  Presumably SATA only. */
+	{ "PIONEER DVD-RW  DVRTD08",	"1.00",	ATA_HORKAGE_NOSETXFER },
+
 	/* End Marker */
 	{ }
 };
diff --git a/include/linux/libata.h b/include/linux/libata.h
index 3449de5..e78dc6b 100644
--- a/include/linux/libata.h
+++ b/include/linux/libata.h
@@ -377,6 +377,7 @@ enum {
 	ATA_HORKAGE_ATAPI_MOD16_DMA = (1 << 11), /* use ATAPI DMA for commands
 						    not multiple of 16 bytes */
 	ATA_HORKAGE_FIRMWARE_WARN = (1 << 12),	/* firwmare update warning */
+	ATA_HORKAGE_NOSETXFER	= (1 << 13),
 
 	 /* DMA mask for user DMA control: User visible values; DO NOT
 	    renumber */

Re: [PATCH #upstream-fixes] libata: implement and use HORKAGE_NOSETXFER

[Alan Cox]

On Wed, 07 Jan 2009 11:01:05 +0900
Tejun Heo <tj@kernel.org> wrote:

> PIONEER DVD-RW DVRTD08 times out SETXFER if no media is present.  The
> device is SATA and simply skipping SETXFER works around the problem.
> Implement ATA_HORKAGE_NOSETXFER and apply it to the device.

NAK

Sorry you can't just blindly do this because some of the controllers snoop
the SETXFER command to set their timings and whether they expect DMA. Also
we've no idea if this is a bug in a specific firmware revision, a quirky
pata/sata bridge or a timing problem of some sort.

Alan

Re: [PATCH #upstream-fixes] libata: implement and use HORKAGE_NOSETXFER

[Tejun Heo]

Alan Cox wrote:
> On Wed, 07 Jan 2009 11:01:05 +0900
> Tejun Heo <tj@kernel.org> wrote:
> 
>> PIONEER DVD-RW DVRTD08 times out SETXFER if no media is present.  The
>> device is SATA and simply skipping SETXFER works around the problem.
>> Implement ATA_HORKAGE_NOSETXFER and apply it to the device.
> 
> NAK
> 
> Sorry you can't just blindly do this because some of the controllers snoop
> the SETXFER command to set their timings and whether they expect DMA. Also
> we've no idea if this is a bug in a specific firmware revision, a quirky
> pata/sata bridge or a timing problem of some sort.

I think it'll generally be okay for SATA unless it's bridged over to
PATA controller.  Any other ideas?

Thanks.

-- 
tejun

Re: [PATCH #upstream-fixes] libata: implement and use HORKAGE_NOSETXFER

[Alan Cox]

> > Sorry you can't just blindly do this because some of the controllers snoop
> > the SETXFER command to set their timings and whether they expect DMA. Also
> > we've no idea if this is a bug in a specific firmware revision, a quirky
> > pata/sata bridge or a timing problem of some sort.
> 
> I think it'll generally be okay for SATA unless it's bridged over to
> PATA controller.  Any other ideas?

We seem to have one report, from one user, with one configuration, on one
controller, using one firmware set.

That to me isn't meaningful evidence of anything that needs a workaround,
beyond maybe doing what old IDE does and if a setxfer times out
continuing in hope.

(We should of course then re-read the identify pages and check the mode
in use)

Alan

Re: [PATCH #upstream-fixes] libata: implement and use HORKAGE_NOSETXFER

[Tejun Heo]

Alan Cox wrote:
>>> Sorry you can't just blindly do this because some of the controllers snoop
>>> the SETXFER command to set their timings and whether they expect DMA. Also
>>> we've no idea if this is a bug in a specific firmware revision, a quirky
>>> pata/sata bridge or a timing problem of some sort.
>> I think it'll generally be okay for SATA unless it's bridged over to
>> PATA controller.  Any other ideas?
> 
> We seem to have one report, from one user, with one configuration, on one
> controller, using one firmware set.

There are two more reports linked from the thread.

  http://ubuntuforums.org/showthread.php?t=986871
  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/299865

And all of them are showing the same problem.  This being a slim SATA
drive for a laptop, I don't really expect to see the drive in varied
configurations.  The problem might as well be limited to certain OEM
drive(s).

> That to me isn't meaningful evidence of anything that needs a workaround,
> beyond maybe doing what old IDE does and if a setxfer times out
> continuing in hope.

So, as far as the validity of the report goes, I think it's at
reasonable level.  Add to that my general trigger happiness toward
quirks and the machine is a VAIO and to me quirking it doesn't seem
too careless.

> (We should of course then re-read the identify pages and check the mode
> in use)

Of course, whether the workaround is proper is a completely separate
issue but unless other devices with the same problem creep up and the
device is happy with the quirk, I don't really think we should modify
the default configuration sequence for devices like this.

That said, Moritz, can you please post the output of "hdparm -I" with
and without the quirk applied?  And can you please use a preoper mail
address?

Thanks.

-- 
tejun

Re: [PATCH #upstream-fixes] libata: implement and use HORKAGE_NOSETXFER

[Tejun Heo]

[-- Attachment #1: Type: text/plain, Size: 2326 bytes --]

Reviving an old thread and quoting whole body for new reporter.

Tejun Heo wrote:
> Alan Cox wrote:
>>>> Sorry you can't just blindly do this because some of the controllers snoop
>>>> the SETXFER command to set their timings and whether they expect DMA. Also
>>>> we've no idea if this is a bug in a specific firmware revision, a quirky
>>>> pata/sata bridge or a timing problem of some sort.
>>> I think it'll generally be okay for SATA unless it's bridged over to
>>> PATA controller.  Any other ideas?
>> We seem to have one report, from one user, with one configuration, on one
>> controller, using one firmware set.
> 
> There are two more reports linked from the thread.
> 
>   http://ubuntuforums.org/showthread.php?t=986871
>   https://bugs.launchpad.net/ubuntu/+source/linux/+bug/299865
> 
> And all of them are showing the same problem.  This being a slim SATA
> drive for a laptop, I don't really expect to see the drive in varied
> configurations.  The problem might as well be limited to certain OEM
> drive(s).
> 
>> That to me isn't meaningful evidence of anything that needs a workaround,
>> beyond maybe doing what old IDE does and if a setxfer times out
>> continuing in hope.
> 
> So, as far as the validity of the report goes, I think it's at
> reasonable level.  Add to that my general trigger happiness toward
> quirks and the machine is a VAIO and to me quirking it doesn't seem
> too careless.
> 
>> (We should of course then re-read the identify pages and check the mode
>> in use)
> 
> Of course, whether the workaround is proper is a completely separate
> issue but unless other devices with the same problem creep up and the
> device is happy with the quirk, I don't really think we should modify
> the default configuration sequence for devices like this.
> 
> That said, Moritz, can you please post the output of "hdparm -I" with
> and without the quirk applied?  And can you please use a preoper mail
> address?

Martin Novak (cc'd) is reporting the same problem.  I really think
doing nothing is the worst choice here.  Given the rarity of the
issue, I don't think we need worry too much about long term impact of
the quirk.

Anyways, Martin, can you please post what I asked Moritz - the output
of "hdparm -I" with and without the quirk applied?  Quirk patch is
attached.

Thanks.

-- 
tejun

[-- Attachment #2: horkage-notsetxfer.patch --]
[-- Type: text/x-patch, Size: 2101 bytes --]

libata: implement and use HORKAGE_NOSETXFER

PIONEER DVD-RW DVRTD08 times out SETXFER if no media is present.  The
device is SATA and simply skipping SETXFER works around the problem.
Implement ATA_HORKAGE_NOSETXFER and apply it to the device.

Reported by Moritz Rigler in the following thread.

  http://thread.gmane.org/gmane.linux.ide/36790

Signed-off-by: Tejun Heo <tj@kernel.org>
---
 drivers/ata/libata-core.c |   10 ++++++++--
 include/linux/libata.h    |    1 +
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index c924230..5dcdcb4 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -3390,14 +3390,17 @@ static int ata_dev_set_mode(struct ata_device *dev)
 	struct ata_eh_context *ehc = &dev->link->eh_context;
 	const char *dev_err_whine = "";
 	int ign_dev_err = 0;
-	unsigned int err_mask;
+	unsigned int err_mask = 0;
 	int rc;
 
 	dev->flags &= ~ATA_DFLAG_PIO;
 	if (dev->xfer_shift == ATA_SHIFT_PIO)
 		dev->flags |= ATA_DFLAG_PIO;
 
-	err_mask = ata_dev_set_xfermode(dev);
+	if (!(dev->horkage & ATA_HORKAGE_NOSETXFER))
+		err_mask = ata_dev_set_xfermode(dev);
+	else
+		dev_err_whine = " (SET_XFERMODE skipped)";
 
 	if (err_mask & ~AC_ERR_DEV)
 		goto fail;
@@ -4292,6 +4295,9 @@ static const struct ata_blacklist_entry ata_device_blacklist [] = {
 	/* Devices which aren't very happy with higher link speeds */
 	{ "WD My Book",			NULL,	ATA_HORKAGE_1_5_GBPS, },
 
+	/* Devices which choke on SETXFER.  Presumably SATA only. */
+	{ "PIONEER DVD-RW  DVRTD08",	"1.00",	ATA_HORKAGE_NOSETXFER },
+
 	/* End Marker */
 	{ }
 };
diff --git a/include/linux/libata.h b/include/linux/libata.h
index 3d501db..2b641af 100644
--- a/include/linux/libata.h
+++ b/include/linux/libata.h
@@ -385,6 +385,7 @@ enum {
 						    not multiple of 16 bytes */
 	ATA_HORKAGE_FIRMWARE_WARN = (1 << 12),	/* firmware update warning */
 	ATA_HORKAGE_1_5_GBPS	= (1 << 13),	/* force 1.5 Gbps */
+	ATA_HORKAGE_NOSETXFER	= (1 << 14),
 
 	 /* DMA mask for user DMA control: User visible values; DO NOT
 	    renumber */

Re: [PATCH #upstream-fixes] libata: implement and use HORKAGE_NOSETXFER

[Alan Cox]

On Mon, 25 May 2009 12:10:19 +0900
Tejun Heo <tj@kernel.org> wrote:

> Reviving an old thread and quoting whole body for new reporter.

I've not changed my view btw - which is that the quirk should match what
old IDE does here - issue the command and if it fails carry on regardless.


Alan

Re: [PATCH #upstream-fixes] libata: implement and use HORKAGE_NOSETXFER

[Tejun Heo]

cc'ing Lars.  New bug reporter on this problem.

Alan Cox wrote:
> On Mon, 25 May 2009 12:10:19 +0900
> Tejun Heo <tj@kernel.org> wrote:
> 
>> Reviving an old thread and quoting whole body for new reporter.
> 
> I've not changed my view btw - which is that the quirk should match what
> old IDE does here - issue the command and if it fails carry on regardless.

That isn't possible because the host machine state is unknown after a
timeout.  The problem is not confined to TF based controllers and even
on TF based controllers, it's far too dangerous to continue as nothing
happened.  That can easily lead to complete system lock up on quite a
few controllers due to fragile TF emulation layer.

The drive is full SATA.  SETXFER doesn't mean anything to it.  Let's
just skip it.

Thanks.

-- 
tejun

Re: [PATCH #upstream-fixes] libata: implement and use HORKAGE_NOSETXFER

[Alan Cox]

> That isn't possible because the host machine state is unknown after a
> timeout.  The problem is not confined to TF based controllers and even
> on TF based controllers, it's far too dangerous to continue as nothing
> happened.  That can easily lead to complete system lock up on quite a
> few controllers due to fragile TF emulation layer.

It works fine on old style taskfile controllers, and the old IDE layer
has done it for years

> The drive is full SATA.  SETXFER doesn't mean anything to it.  Let's
> just skip it.

What if there is a bridge, what if the controller needs SETXFER for
internal use (HPT PATA with on card SATA bridges) ?

I have a feeling this is one case where there isn't a generic solution
for all devices

For PATA we need SETXFER to be issued
For SATA we can maybe avoid it sometimes but its getting into deeply
undefined territory and will break the early HPT at least.

Alan

Re: [PATCH #upstream-fixes] libata: implement and use HORKAGE_NOSETXFER

[Tejun Heo]

Alan Cox wrote:
>> That isn't possible because the host machine state is unknown after a
>> timeout.  The problem is not confined to TF based controllers and even
>> on TF based controllers, it's far too dangerous to continue as nothing
>> happened.  That can easily lead to complete system lock up on quite a
>> few controllers due to fragile TF emulation layer.
> 
> It works fine on old style taskfile controllers, and the old IDE layer
> has done it for years

Yeah, exactly.  libata covers more diverse set of controllers and
nothing has ever been tested for issuing commands without full reset
after exceptions which can put HSM into unknown state.  The whole EH
is designed and implemented that way.  So, many reset methods reset
not only the ATA bus but also the HSM.  This also coincides with
hardware design.  So, if the problem is confined to TF based old IDE,
issuing commands after timeout could work fine but I don't think
that's a viable option here.

>> The drive is full SATA.  SETXFER doesn't mean anything to it.  Let's
>> just skip it.
> 
> What if there is a bridge, what if the controller needs SETXFER for
> internal use (HPT PATA with on card SATA bridges) ?

The device is horridly broken.  I don't think we can please everyone
here.  Also, it being a slim oem dvd which gets shipped with laptops,
I don't think we need to worry too much about highly varied
configurations.

> I have a feeling this is one case where there isn't a generic solution
> for all devices
> 
> For PATA we need SETXFER to be issued
> For SATA we can maybe avoid it sometimes but its getting into deeply
> undefined territory and will break the early HPT at least.

Sure, fully agreed.  It's a trade off.  There are three options.

1. Don't do anything.  The device is broken everywhere.

2. Skip SETXFER.  Any direct SATA connection to the device would work
   fine.

2. Ignore SETXFER timeout.  Probably would work for TF based
   controllers but it's largely untested for sata controllers and the
   behavior is likely undefined for more advanced controllers.

So, #2 seems like the logical choice here.  If worst comes to worst
and some idiot decides to ship the drive with SATA bridge (but really
how many of those configurations do we see anymore?), we can blacklist
that particular machine using dmi or whatnot and craft workaround such
that timeout is ignored for that particular case if it works.

Thanks.

-- 
tejun

Re: [PATCH #upstream-fixes] libata: implement and use HORKAGE_NOSETXFER

[Alan Cox]

> > What if there is a bridge, what if the controller needs SETXFER for
> > internal use (HPT PATA with on card SATA bridges) ?
> 
> The device is horridly broken. 

I know 8(

> 1. Don't do anything.  The device is broken everywhere.
> 
> 2. Skip SETXFER.  Any direct SATA connection to the device would work
>    fine.
> 
> 2. Ignore SETXFER timeout.  Probably would work for TF based
>    controllers but it's largely untested for sata controllers and the
>    behavior is likely undefined for more advanced controllers.

> So, #2 seems like the logical choice here.  If worst comes to worst

You have two #2's but I agree that providing its for this specific drive
and we document it carefully so people don't add it to stuff that is
wrong then your first #2 is probably safest.

Possibly  HORKAGE_NO_SETXFER_SATA and check word 93 ?


Alan

Re: [PATCH #upstream-fixes] libata: implement and use HORKAGE_NOSETXFER

[Tejun Heo]

Hello,

Alan Cox wrote:
>> 2. Skip SETXFER.  Any direct SATA connection to the device would work
>>    fine.
>>
>> 2. Ignore SETXFER timeout.  Probably would work for TF based
>>    controllers but it's largely untested for sata controllers and the
>>    behavior is likely undefined for more advanced controllers.
> 
>> So, #2 seems like the logical choice here.  If worst comes to worst
> 
> You have two #2's

Oops.

> but I agree that providing its for this specific drive
> and we document it carefully so people don't add it to stuff that is
> wrong then your first #2 is probably safest.
> 
> Possibly  HORKAGE_NO_SETXFER_SATA and check word 93 ?

How about something like the following?

diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 045a486..2c6aeda 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -3392,17 +3392,27 @@ int ata_down_xfermask_limit(struct ata_device *dev, unsigned int sel)
 
 static int ata_dev_set_mode(struct ata_device *dev)
 {
+	struct ata_port *ap = dev->link->ap;
 	struct ata_eh_context *ehc = &dev->link->eh_context;
+	const bool nosetxfer = dev->horkage & ATA_HORKAGE_NOSETXFER;
 	const char *dev_err_whine = "";
 	int ign_dev_err = 0;
-	unsigned int err_mask;
+	unsigned int err_mask = 0;
 	int rc;
 
 	dev->flags &= ~ATA_DFLAG_PIO;
 	if (dev->xfer_shift == ATA_SHIFT_PIO)
 		dev->flags |= ATA_DFLAG_PIO;
 
-	err_mask = ata_dev_set_xfermode(dev);
+	if (nosetxfer && ap->flags & ATA_FLAG_SATA && ata_id_is_sata(dev->id))
+		dev_err_whine = " (SET_XFERMODE skipped)";
+	else {
+		if (nosetxfer)
+			ata_dev_printk(dev, KERN_WARNING,
+				       "NOSETXFER but PATA detected - can't "
+				       "skip SETXFER, might malfunction\n");
+		err_mask = ata_dev_set_xfermode(dev);
+	}
 
 	if (err_mask & ~AC_ERR_DEV)
 		goto fail;
@@ -4297,6 +4307,12 @@ static const struct ata_blacklist_entry ata_device_blacklist [] = {
 	/* Devices which aren't very happy with higher link speeds */
 	{ "WD My Book",			NULL,	ATA_HORKAGE_1_5_GBPS, },
 
+	/*
+	 * Devices which choke on SETXFER.  Applies only if both the
+	 * device and controller are SATA.
+	 */
+	{ "PIONEER DVD-RW  DVRTD08",	"1.00",	ATA_HORKAGE_NOSETXFER },
+
 	/* End Marker */
 	{ }
 };
diff --git a/include/linux/libata.h b/include/linux/libata.h
index 3d501db..2b641af 100644
--- a/include/linux/libata.h
+++ b/include/linux/libata.h
@@ -385,6 +385,7 @@ enum {
 						    not multiple of 16 bytes */
 	ATA_HORKAGE_FIRMWARE_WARN = (1 << 12),	/* firmware update warning */
 	ATA_HORKAGE_1_5_GBPS	= (1 << 13),	/* force 1.5 Gbps */
+	ATA_HORKAGE_NOSETXFER	= (1 << 14),
 
 	 /* DMA mask for user DMA control: User visible values; DO NOT
 	    renumber */

-- 
tejun

Re: [PATCH #upstream-fixes] libata: implement and use HORKAGE_NOSETXFER

[Sergei Shtylyov]

Hello.

Alan Cox wrote:

>>That isn't possible because the host machine state is unknown after a
>>timeout.  The problem is not confined to TF based controllers and even
>>on TF based controllers, it's far too dangerous to continue as nothing
>>happened.  That can easily lead to complete system lock up on quite a
>>few controllers due to fragile TF emulation layer.

> It works fine on old style taskfile controllers, and the old IDE layer
> has done it for years

>>The drive is full SATA.  SETXFER doesn't mean anything to it.  Let's
>>just skip it.

> What if there is a bridge, what if the controller needs SETXFER for
> internal use (HPT PATA with on card SATA bridges) ?

    Do you mean HPT36x/37x here? If so, what internal use the controller has 
for this command?

> I have a feeling this is one case where there isn't a generic solution
> for all devices

> For PATA we need SETXFER to be issued
> For SATA we can maybe avoid it sometimes but its getting into deeply
> undefined territory and will break the early HPT at least.

    Hm...

> Alan

MBR, Sergei

Re: [PATCH #upstream-fixes] libata: implement and use HORKAGE_NOSETXFER

[Alan Cox]

> >>The drive is full SATA.  SETXFER doesn't mean anything to it.  Let's
> >>just skip it.
> 
> > What if there is a bridge, what if the controller needs SETXFER for
> > internal use (HPT PATA with on card SATA bridges) ?
> 
>     Do you mean HPT36x/37x here? If so, what internal use the controller has 
> for this command?

HPT37x - if you don't issue a SETXFER it doesn't work with the SATA
bridge (it also blows up if you don't select certain modes). All very
weird and I've no idea why it does that. Tejun is right however that we
don't need to care for the DVD case in question

Alan