Messages in this thread | | | Date | Fri, 16 Aug 2013 01:05:54 +0200 | From | Ben Tebulin <> | Subject | Re: [Bug] Reproducible data corruption on i5-3340M: Please continue your great work! :-) |
| |
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 particular way > [...] > This patch is against current git, so to apply you need to have > that commit e6c495a96ce0 cherry-picked to older kernels first.
I took a shot based on 3.9.11 + e6c495a96ce0. The reason why I don't simply use the current git master is, that for some reasons my linux-image-*.deb become 750MB and larger since 3.10.y and I have no clue at all why and what to do about it.
The patch failed. Due to my outstanding incompetence I resorted into applying it onto master, cherry-picking that back and trying to resolve the remaining conflicts correctly.
> - I have no idea whether this will fix the problem Ben sees, but I > feel happier about the code, because now any place that forgets to set > up start/end will work just fine, because they are always valid.
Simpler code? Resilient API? Happy people? Great!
> Ben, please test. I'm worried that the problem you see is something > even more fundamentally wrong with the whole "oops, must flush in the > middle" logic, but I'm _hoping_ this fixes it.
It's gone.
Really!
I git-fsck'ed successfully around 30 times in a row. And even all the other things still seem to work ;-)
Honestly I have to confess that I'm deeply impressed how this finally worked out: I just threw a particular, innocent-looking commit hash and nothing more into the round. And while still being unsure if this might be a plain user space issue, only 24h later I received a 11kb sized kernel patch (with blatant typos in it !1! *g* ) apparently solving my issue.
/me happy now, too! :)
- Ben
| |