On Fri, 2016-04-08 at 21:27 -0400, Avery Pennarun wrote: > > Just to be clear, this crash is only from *reading* the agg_status > > files. I don't know if the crashiness reduces when disabling the > > aggregation timeouts, since that's a separate bug (in which the > > queue gets stuck and the 'pending' column of this file just keeps > > increasing). Oh, right, I was confusing the two. The reading one is even stranger though, in a way. I have no explanation for it (yet). We could suspect memory corruption, but why would it specifically hit issues here? Not very plausible. > Updated .ko file that definitely has debug symbols this time: > http://apenwarr.ca/tmp/mac80211-agg-status-crash-debugsyms.ko > Ok, that confirms what I did manually in my previous email - that it crashed on this: 141 p += scnprintf(p, sizeof(buf) + buf - p, "\t%#.2x", 142 tid_tx ? tid_tx->dialog_token : 0); (and by hand I'd already checked that it crashed dereferencing the tid_tx->dialog_token, since tid_tx was the value 0x5b35da40. If any people more familiar with ARM are reading this - does the value 0x5b35da40 ring a bell? Is that a userspace area? Or an area where the stack would be? All other points around here seem to look like 0xac0c3c58, or maybe 0x838c6958, but not 0x5b35...., how could we end up with that? 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
