On Sun, Feb 12, 2017 at 09:38:20AM +0100, Vegard Nossum wrote: > You may consider adding a Reported-by: and/or a link to the previous discussion: > > https://patchwork.ozlabs.org/patch/648817/ I'm trying to remember if you always included the git commit of the kernel you were testing. One of the reasons why I had trouble root causes some of your crashes was because I wasn't able to map the addresses back to line numbers. I think I must have missed the git commit ID, since I see you have historical information for all of them in your reports. In any case, what happened is for those reports that weren't caused by superblock corruption (where you had provided the superblock dump), if it wasn't immediately obvious from the stack trace, I eventually gave up, because I had a finite amount of time and energy, and it was too hard to figure out *where* in the source the kernel was actually crashing. As a wishlist item, it would be nice if your web reports included hotlinks from the addresses / symbol_name+offset to the git tree sources at the indicated line number. For example: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/fs/ext4/inode.c?id=07f00f06ba9a5533d6650d46d3e938f6cbeee97e#n3738 One of the crash dump analysis tool at $WORK does that, and it saves a huge amount of developer time. Anyway, at least for the ones where there is an explicit BUG_ON with a line number, I should revisit your reports to see if I might not be able clear out more of them. (Is there a list of which ones are still valid?) But for ones where there is a stack trace without a BUG_INFO or WARN_ON to give me a line number, any chance you could use addr2line or otherwise make the kernel (with debugging information compiled in) available? Thanks!! - Ted
