On Mon, Jan 06, 2020 at 09:45:34PM +0100, Peter Seiderer wrote: > On Fri, 27 Dec 2019 22:52:04 +0000, Mark Brown <broonie@xxxxxxxxxx> wrote: > > On Fri, Dec 27, 2019 at 04:20:56PM +0100, Peter Seiderer wrote: > > Please think hard before including complete backtraces in upstream > > reports, they are very large and contain almost no useful information > > relative to their size so often obscure the relevant content in your > > message. If part of the backtrace is usefully illustrative then it's > > usually better to pull out the relevant sections. > Thanks for review..., but a little disagree here, do not know much which > is more informative than a complete back trace for a division by zero (and > which is the complete information/starting point for investigating the > reason therefore) and it would be a pity to loose this valuable information? Right, some backtrace is definitely often useful for understanding where things broke and helping people search for problems - it's just providing the *full* backtrace that can be an issue as a lot of it can end up being redundant. As a rule of thumb I'd tend to say that once you get out of the driver or subsystem you're starting to loose relevance. For example with a probe failure like this once you get out of the driver probe function it almost never matters exactly what the stack in the device model core is, it's not adding anything and it's usually more than a screenful that needs to be paged through. Cutting that out helps people focus on the bits that matter. > Maybe I should have added more information about why and how the failing > regmap_read() call leads to a division by zero? Any analysis you've done about why things got confused and broken is definitely good to include!
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
