it means that lock() (/sys/src/9/port/taslock.c:/^lock) is looping way too much in rendezvous. 0x37a34 is in rendezvous.s.
i don't know fossil or venti very well. it would be hard to say what is wrong with the threading here without some serious groveling. my wild guess would be that there are three processes (21 26 23) at the same rendezvous point at the same time. rendezvous works for two processes. i wonder why libventi doesn't use the thread library? - erik On Wed Mar 21 09:29:52 EDT 2007, [EMAIL PROTECTED] wrote: > I installed Inferno on my FreeBSD machine so that I could copy my MP3s > over to the Plan 9 fileserver. I left last night around midnight, and > when coming in again this morning, I notice a few kernel messages: > > lock 0xf0a685c8 loop key 0xdeaddead pc 0xf01c9af2 held by pc 0xf01c9af2 proc > 21 > 26: fossil pc f01ca23d dbgpc 37a34 Rendez (Running) ut 959 st 4926 > bss 703000 qpc 0 nl 0 nd 0 lpc f01c1f5d pri 4 > 21: fossil pc f01bda3e dbgpc 37a34 Rendez (Ready) ut 89555 st 244 bss > 703000 qpc 0 nl 1 nd 0 lpc f01bd877 pri 3 > lock 0xf0a685c8 loop key 0xdeaddead pc 0xf01c9af2 held by pc 0xf01c9af2 proc > 21 > 23: fossil pc f01ca20f dbgpc 37a34 Rendez (Running) ut 352 676 bss > 703000 qpc 0 nl 0 nd 0 lpc f01c1f5d pri 4 > 21: fossil pc f01xdxxx (unreadable due to terminals) qpc 0 nl 1 nd 0 > lpc f01bd877 pri 3 > > Not sure what this means. I guess typically 0xdeaddead-like stuff is > used to signify use of memory after a free, but I'm kind of unsure. > > Also, it looks like it decided to randomly stop copying somewhere in > the middle of my MP3 stream. > > *shrugs* > > --dho
