You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficserver.apache.org by "John Plevyak (JIRA)" <ji...@apache.org> on 2009/11/11 22:50:48 UTC
[jira] Closed: (TS-13) x86_64 linux port
[ https://issues.apache.org/jira/browse/TS-13?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
John Plevyak closed TS-13.
--------------------------
Resolution: Fixed
Fix Version/s: 2.0a
Reviewed and tested. Looks good so far, so I am closing this issue.
> x86_64 linux port
> -----------------
>
> Key: TS-13
> URL: https://issues.apache.org/jira/browse/TS-13
> Project: Traffic Server
> Issue Type: New Feature
> Components: Portability
> Affects Versions: 2.0a
> Environment: 64-bit linux (fedora 8 w/gcc 4.3.2)
> Reporter: John Plevyak
> Fix For: 2.0a
>
> Attachments: 0001-Properly-search-usr-lib64-for-tclConfig.sh.patch, 0003-TS-13-Add-support-to-only-add-march-pentium-if-CFLAG.patch, 64-bit-cluster.patch, 64bit-bcall-001.patch, 64bit-bcall-002.patch, rhel4_32bit_gmake.out, ts-64bit-v1.patch, ts-64bit-v2.patch, ts-64bit-v3.patch, ts-64bit-v4.patch, ts-64bit-v5.patch, ts-gcc32-builtin-atomic.patch
>
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> Need to compile and run in x86_64 mode on 64-bit linux
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: BZ 59274
Posted by Bryan Call <bc...@yahoo-inc.com>.
I found a description about BZ59274:
There are about 12 caches which does not have any HITs. The caches will
show HITs when the cache is cleared but later the problem reappears
after few weeks.
I don't know what the means, but hopefully you can decipher it.
BTW - we are on #traffic-sever on irc.freenode.net if you want to chat...
-Bryan
On 11/11/2009 03:56 PM, Bryan Call wrote:
> There was some work done by a consulting group when I first join the
> group a couple years ago. Part of the project was for them to supply
> bug fixes they did in their version of the source tree.
>
> We might be able to lookup the bug numbers. I might have had a
> spreadsheet with information about it.
>
> -Bryan
>
> On 11/11/2009 03:43 PM, John Plevyak wrote:
>>
>> Weird. Here are the comments that prompted me:
>>
>> Cache.cc: prev_recover_pos = 0; //Bug fixed by YTS Team,
>> yamsat BZ 59274
>> Cache.cc: if (recover_pos == prev_recover_pos) //Bug fixed by YTS
>> Team, yamsat BZ59274
>> Cache.cc: goto Lclear; //Bug fixed by YTS Team,
>> yamsat BZ59274
>> Cache.cc: prev_recover_pos = recover_pos; //Bug fixed by YTS
>> Team, yamsat BZ59274
>> P_CachePart.h: ink_off_t prev_recover_pos; //Bug fixed by YTS
>> Team, yamsat BZ59274
>>
>>
>>
>> Leif Hedstrom wrote:
>>> On 11/11/2009 04:14 PM, John Plevyak wrote:
>>>>
>>>>
>>>> Would it be possible for me to see bug report BZ59274 and follow up
>>>> discussion?
>>>> I'd like to understand the situation better.
>>>
>>>
>>> Hmmm, is that an old Inktomi bug? We don't have those, I'm prety
>>> sure :/. I checked the Yahoo Bugzilla, and that ticket number is
>>> something unrelated to TS. :)
>>>
>>> -- leif
>>
>
Re: BZ 59274
Posted by Bryan Call <bc...@yahoo-inc.com>.
There was some work done by a consulting group when I first join the
group a couple years ago. Part of the project was for them to supply
bug fixes they did in their version of the source tree.
We might be able to lookup the bug numbers. I might have had a
spreadsheet with information about it.
-Bryan
On 11/11/2009 03:43 PM, John Plevyak wrote:
>
> Weird. Here are the comments that prompted me:
>
> Cache.cc: prev_recover_pos = 0; //Bug fixed by YTS Team,
> yamsat BZ 59274
> Cache.cc: if (recover_pos == prev_recover_pos) //Bug fixed by YTS
> Team, yamsat BZ59274
> Cache.cc: goto Lclear; //Bug fixed by YTS Team,
> yamsat BZ59274
> Cache.cc: prev_recover_pos = recover_pos; //Bug fixed by YTS
> Team, yamsat BZ59274
> P_CachePart.h: ink_off_t prev_recover_pos; //Bug fixed by YTS Team,
> yamsat BZ59274
>
>
>
> Leif Hedstrom wrote:
>> On 11/11/2009 04:14 PM, John Plevyak wrote:
>>>
>>>
>>> Would it be possible for me to see bug report BZ59274 and follow up
>>> discussion?
>>> I'd like to understand the situation better.
>>
>>
>> Hmmm, is that an old Inktomi bug? We don't have those, I'm prety sure
>> :/. I checked the Yahoo Bugzilla, and that ticket number is something
>> unrelated to TS. :)
>>
>> -- leif
>
Re: BZ 59274
Posted by John Plevyak <jp...@acm.org>.
Weird. Here are the comments that prompted me:
Cache.cc: prev_recover_pos = 0; //Bug fixed by YTS Team, yamsat
BZ 59274
Cache.cc: if (recover_pos == prev_recover_pos) //Bug fixed by YTS
Team, yamsat BZ59274
Cache.cc: goto Lclear; //Bug fixed by YTS Team, yamsat
BZ59274
Cache.cc: prev_recover_pos = recover_pos; //Bug fixed by YTS
Team, yamsat BZ59274
P_CachePart.h: ink_off_t prev_recover_pos; //Bug fixed by YTS Team,
yamsat BZ59274
Leif Hedstrom wrote:
> On 11/11/2009 04:14 PM, John Plevyak wrote:
>>
>>
>> Would it be possible for me to see bug report BZ59274 and follow up
>> discussion?
>> I'd like to understand the situation better.
>
>
> Hmmm, is that an old Inktomi bug? We don't have those, I'm prety sure
> :/. I checked the Yahoo Bugzilla, and that ticket number is something
> unrelated to TS. :)
>
> -- leif
Re: BZ 59274
Posted by Leif Hedstrom <zw...@apache.org>.
On 11/11/2009 04:14 PM, John Plevyak wrote:
>
>
> Would it be possible for me to see bug report BZ59274 and follow up
> discussion?
> I'd like to understand the situation better.
Hmmm, is that an old Inktomi bug? We don't have those, I'm prety sure
:/. I checked the Yahoo Bugzilla, and that ticket number is something
unrelated to TS. :)
-- leif
BZ 59274
Posted by John Plevyak <jp...@acm.org>.
Would it be possible for me to see bug report BZ59274 and follow up
discussion?
I'd like to understand the situation better.
john