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:( 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. 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> 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. Greetings, Wolfgang -- Wolfgang Breyha <wbreyha@xxxxxxx> | http://www.blafasel.at/ Vienna University Computer Center | Austria -- 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
