:Hi.
:While trying to find a procedure to reliably reproduce the panic
:I reported last time, I caught a different panic (uploaded at
: ~y0netan1/crash/9/ on my leaf account). I wrote the following shell
:script (make sure to edit variables DISKS and MOUNTPT before using this
:script or it may trash your system):
(from the core)
panic: assertion: node->lock.refs == 0 && node->ondisk == NULL in hammer_flush_buffer_nodes
Yah, I've seen this failure. Add a sync or two before the umount and
tell me if it still occurs. It's either a node reference leak somewhere
or it is a race between bufdaemon and umount. The assertions are really
strict there precisely to catch those sorts of cases.
Also note that the code to deal with a full HAMMMER filesystem has not
been written yet (The failure you are reporting is unrelated to a full
HAMMER filesystem, though, just mentioning it).
-Matt
| Pavel Machek | Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching |
| David Newall | Re: Slow DOWN, please!!! |
| Mark Weber | hdparm standby timeout not working for WD raptors? |
| Andrea Arcangeli | [PATCH 01 of 11] mmu-notifier-core |
git: | |
| David Kastrup | Empty directories... |
| linux | [DRAFT] Branching and merging with git |
| Peter Stahlir | Git as a filesystem |
| Junio C Hamano | Re: irc usage.. |
| Darrin Chandler | Re: bcw(4) is gone |
| Jacob Yocom-Piatt | Re: Real men don't attack straw men |
| Siju George | Re: Real men don't attack straw men |
| Ihar Hrachyshka | Re: That whole "Linux stealing our code" thing |
| YAMAMOTO Takashi | yamt-km branch |
| Martin Husemann | Re: iic(4) device discovery |
| Andrew Doran | Thread benchmarks, round 2 |
| Jonathan Stone | Re: fixing send(2) semantics (kern/29750) |
