On 8 April 2016 at 21:56, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > 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? .. that looks very userland-y to me. Is it just some pointer garbage perhaps? Do you have a full crashdump? what's sta->ampdu_mlme look like? -a -- 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
