Little help in reporting a bug

[Paulo Pedro]

Paulo Pedro wrote:
> Nicolas Pitre wrote:
>   
>> On Fri, 8 Jan 2010, Paulo Pedro wrote:
>>
>>   
>>     
>>> Hi guys, i have a Buffalo Linkstation Pro/Live.
>>>
>>> # cat /proc/cpuinfo
>>> Processor    : Feroceon rev 0 (v5l)
>>> BogoMIPS    : 266.24
>>> Features    : swp half thumb fastmult edsp
>>> CPU implementer    : 0x41
>>> CPU architecture: 5TEJ
>>> CPU variant    : 0x0
>>> CPU part    : 0x926
>>> CPU revision    : 0
>>> Hardware    : Buffalo Linkstation Pro/Live
>>>     
>>>       
>> So it has some vintage... having an "old" Feroceon CPU ID.
>>
>>   
>>     
>>> I mainly use this box like a fileserver and a torrent client with low
>>> power consumption, but since i started to use encryption in my harddrive
>>> and my swap i started to get problems and i dont know where to report them.
>>> After update kernel to 2.6.32.1 , the page allocation failures i was
>>> having and a few SATA reset errors in log vanished , but there is still
>>> one error when downloading big files in the encrypted partition using
>>> rtorrent. I contacted the rtorrent developer and he said me errors in
>>> "check hash/corruption" are almost always hidden bugs in the filesystem
>>> , and in this case , since i do not have errors when using unencrypted
>>> partition, it probably is a kernel/fs problem related to mmap.
>>> What can i do to try to debug this ? Where should i report this ?
>>>     
>>>       
>> REporting this here is fine for now, unless we can rule out any possible 
>> ARM related issues.
>>
>> Is the problem reliably reproduced?
>>   
>>     
> Yes , almost every big torrent i download gets a few MB corrupted.
>   
>> What size is "big" in this case?
>>   
>>     
> If inside the torrent exists at least one file over 500Mb this will
> happen. Though sometimes i get corruption in small files too [50Mb]
>   
>> What is your encryption setup?
>>
>>
>>   
>>     
> cipher=serpent-cbc-essiv:sha256,size=256 holding a 1TB ext4 partition
> tested with AES , but get the same problem ... and since serpent is much
> faster on this machine i decided to keep it.
>   
>> Nicolas
>>
>>   
>>     
>
>
>   
Any other info i can provide ?