On Wed, 2011-12-14 at 15:22 +0100, Wolfgang Breyha wrote: > Johannes Berg wrote, on 13.12.2011 16:38: > > The program will allocate 2GiB memory (edit to suit, should be OK on > > your machine), fill them with 0x94 and then continually scan them for > > corruption. Identifying what kind of corruption happened will hopefully > > allow me to figure out where it's coming from. > > > > It prints out the wrong data & resets the memory so new corruption later > > is also identified. > > Ok, I had only 20 minutes yesterday evening, but the results are not very > pleasant, because there are no results:( Ouch! So we aren't actually just dealing with random memory corruption?! > I did the usual steps to reproduce the case on my laptop: > > *) stay connected on the "working" AP (no rekeying) > --> *) new here: start "mc" > *) echo "1" >...iwlwifi/debug > *) open multitail, firefox, vlc > *) connect to the other AP (rekeying every 20 seconds currently) > *) start video stream > *) wait for the second "group rekey finished" > *) watch the artifacts, closing applications and listen to crackling sound > > Everything happened exactly the same way as always. BUT "mc" didn't show any > corrupted memory regions. Hmmm. Yeah if it was random memory corruption that should have done something. > I already tried to remember which applications crashed, but currently I'm not > able to give them a clear category like "all (network-)IO" or "all > audio/video". Allocating memory seems not to be enough to trigger "something". > <brainstorm mode>Maybe mmap'ed regions are affected?</brainstorm mode> But my tool was using mmap ;-) I can't think why mmap would make a difference though. > Watching a video is only one way to notice that issue. Simply starting firefox > with a group of tabs open is an other and has a high probability to > immediately crash firefox while fetching the contents. > > Watching a video shows the coincidence with the second rekeying event best. > > I'll try to give "mc" some more time and start it after/before the others as > soon as my pre-x-mas schedule allows it. I wouldn't. If it was really memory corruption, this should've caught it. No way firefox would crash while "mc" would run fine. Back to square 1! Maybe we somehow invented the best fuzzer ever? Wrongly decrypted packets being sent up without being dropped, and your video stream and firefox hating random binary data in the middle of the input? johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
