Re: [Bug] Reproducible data corruption on i5-3340M: Please continue your great work! :-)

2013-08-15 Thread Ben Tebulin
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

Re: [Bug] Reproducible data corruption on i5-3340M: Please revert 53a59fc67!

2013-08-15 Thread Ben Tebulin
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

Re: [Bug] Reproducible data corruption on i5-3340M: Please revert 53a59fc67!

2013-08-15 Thread Ben Tebulin
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

Re: [Bug] Reproducible data corruption on i5-3340M: Please revert 53a59fc67!

2013-08-15 Thread Ben Tebulin
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

Re: [Bug] Reproducible data corruption on i5-3340M: Please revert 53a59fc67!

2013-08-15 Thread Ben Tebulin
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

Re: [Bug] Reproducible data corruption on i5-3340M: Please continue your great work! :-)

2013-08-15 Thread Ben Tebulin
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 some

Reproducible data corruption since 3.7.x on i5-3340M machines

2013-08-12 Thread Ben Tebulin
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

Reproducible data corruption since 3.7.x on i5-3340M machines

2013-08-12 Thread Ben Tebulin
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

Reproducible git-fsck/SHA1 failures since 3.7.x on a Dell E6430 / i5-3340M

2013-08-09 Thread Ben Tebulin
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

Reproducible git-fsck/SHA1 failures since 3.7.x on a Dell E6430 / i5-3340M

2013-08-09 Thread Ben Tebulin
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