Re: atapicam broken by ata_lowlevel.c rev.1.23

slave-mike wrote:
> Does this correct the sense bugs/requirements for -force when using 
> cdrecord when burning cd's?

I really don't know.  Unfortunately, I also don't have time at the 
moment to test this myself.  If it's still broken in HEAD and/or
5.2-RC, please let me know.

Scott

> Scott Long wrote:
> 
>> Bruce Evans wrote:
>>
>>> On Fri, 12 Dec 2003 bremner_at_unb.ca wrote:
>>>
>>>
>>>> At Thu, 27 Nov 2003 00:07:30 -0600,
>>>> Dan Nelson wrote:
>>>>
>>>>> In the last episode (Nov 27), Bruce Evans said:
>>>>>
>>>>>> [Resending due to no response after 2 weeks.]
>>>>>>
>>>>>> Rev.1.23 of ata-lowlevel.c broke atapicam on my BP6 system as shown
>>>>>> by the enclosed boot -v messages (the system just hangs, apparently
>>>>>> waiting for a disk interrupt that never arrives; there seems to be no
>>>>>> timeout).
>>>>>
>>>>>
>>>>>
>>>>> If it's any consolation: "me too" :)  Backing out 1.23 worked for 
>>>>> me as
>>>>> well.  The system that I saw the hang on isn't SMP.  I also
>>>>> pre-emptively patched another SMP system before I had to drive in to
>>>>> fix it if it hung.
>>>>
>>>>
>>>>
>>>> I just wanted to report that my boot hang problems (which were "cured"
>>>> by reverting to revision 1.22 of ata-lowlevel.c) have gone away with
>>>> 5.2-RC1; more precisely with 5.2-CURRENT of Dec. 10.
>>>
>>>
>>>
>>>
>>> This was fixed (apparently without knowing about all the reports of the
>>> bug's realized potential) in:
>>>
>>> % RCS file: /home/ncvs/src/sys/dev/ata/atapi-cam.c,v
>>> % Working file: atapi-cam.c
>>> % head: 1.29
>>> % ...
>>> % ----------------------------
>>> % revision 1.29
>>> % date: 2003/12/05 01:02:46;  author: scottl;  state: Exp;  lines: +1 -1
>>> % Fix a potential problem with atapi-cam where an incorrect flag is 
>>> passed
>>> % into the ata queueing layer.
>>> %
>>> % Approved by:    re
>>> % ----------------------------
>>>
>>> Bruce
>>>
>>
>> Oh, I knew about the reports, but I couldn't find a direct link between
>> the bug that I was fixing (merely via code inspection) and the reported
>> problems.  Since I couldn't prove the link, I didn't want to get
>> everyone's hopes up.  It's good to see that my suspicion of it fixing
>> the problems was correct =-)
>>
>> Scott
>>
>> _______________________________________________
>> freebsd-current_at_freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to 
>> "freebsd-current-unsubscribe_at_freebsd.org"
> 
> 
>