On Tue, Oct 01, 2024 at 10:20:02AM GMT, Lorenzo Stoakes wrote: > On Tue, Oct 01, 2024 at 11:10:55AM GMT, Bert Karwatzki wrote: > > It seems that the maple tree broke down, here's the result of the run with > > CONFIG_DEBUG_MAPLETREE=y in all it's g(l)ory. (Here I didn't need to try to > > kill > > the processes to get an error and soon after the error occured everything > > stopped working so I had to reboot via powerbutton.) > > > > Bert Karwatzki > > Yike thanks very much! > > If it's at all possible for you to confirm this happens on Linus's tree > just to be super super sure (again I totally expect this) then that'd be > amazing. > > I ask because we have another thread which bisected a problem to this > commit which we didn't think was the cause and seemed actually to be the > result of something else fiddling around with things it shouldn't so just > want to entirely rule that out (a fix was applied to Linus's tree for > that). > > [snip for snaity] OK so looking at the output it looks very much like your report is unfortunate truncated... There is a 'BUG at mas_validate_limits:7523 (1)' report but immediately prior to this there should be a line containing data formatted to "node%p: data_end %u != the last slot offset %u". Could you do something like: dmesg -w | tee log.txt Prior to kicking off the repro to make sure we get it all? Or you could set a cmdline parameter of log_buf_len=1G or something crazy to make sure dmseg has it all :>) Thanks! And repeating myself but your help is very much appreciated.
