On 05/20/2013 04:28 AM, Eric Sandeen wrote: > It's probably possible that it's memory corruption too. > >> > Can you replicate it? Do you have the corrupted file system? > Right, these bugs need to be narrowed down to be useful. > When the bug occurred I was neither able to cd into the directory where the log files resides nor I could do a sync. psgrep and friends hang too. On the other hand I was able to write an email with thunderbird and send it out before I had to power off the system - sysrq key alt+print+b didn't worked too. > Does trinity start w/ a random seed, so you can restart? Or better > yet, restart w/ that seed and show the last 20 syscalls before the > bug, etc? yes - trinity uses a randomly choosen seed. SO a replay is possible later. But because the bug occurred after 3 hours /me thinks that a simple replay with just few syscalls won't work. > "I threw random garbage at the kernel and something fell off after a > few hours" is a bit vague. ;) yes - I do know that the bug report lacks data to easy reproduce it - OTOH I thought it is better to report that then to ignore. To speed up things for fuzzy tests I do use file systems living in a tempfs. I'll change my scripts to hold at least the main log file of trinity on a hard disk and came back if I do have useful log data too. -- MfG/Sincerely Toralf Förster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3 -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
