Am 15.08.2013 20:00, schrieb Linus Torvalds:
> Ok, so I've slept on it, and here's my current thinking.
> [...]
Many thoughts which as a user I'm am unable to follow ;-)
> This patch tries to fix the interface instead of trying to patch up
> the individual places that *should* set the range so
Am 15.08.2013 14:02, schrieb Linus Torvalds:
>> I just cherry-picked e6c495a96ce0 into 3.9.11 and 3.7.10.
>> Unfortunately this does _not resolve_ my issue (too good to be true) :-(
> Ho humm. I've found at least one other bug, but that one only affects
> hugepages. Do you perhaps have transparent
Am 14.08.2013 20:35, schrieb Linus Torvalds:
> Yes, the bug was originally introduced in 597e1c35, but in practice it
> never happened, [...]
>
> NOTE! I still absolutely want Ben to actually test that fix (ie
> backport commit e6c495a96ce0 to his tree), because without testing
> this is all just
Shameless self-bump: Since kernel 3.7.x i can reproduce a sporadic data
corruption using git on 2 different machine (same model, though).
Can anybody give me a hint who can help to trace down/fix this regression?
For more information please refer to my first post on Friday.
Sorry to bother again
Hello Kernel list!
On two machines a very specific repository the SHA1 implementation of
git-fsck and git-show fails in 9/10 cases for a specific 39MB blob.
This only occurs on vanilla Linux kernels 3.7.10, 3.8.0 (Ubuntu),
3.9.11, 3.10.5 _but not on_ 3.6.11 and 3.5.7
For details please refer to
5 matches
Mail list logo