[9fans] Fossil errors

[9fans] Fossil errors

[Devon H. O'Dell]

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

Re: [9fans] Fossil errors

[erik quanstrom]

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, devon.odell@gmail.com 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

Re: [9fans] Fossil errors

[Devon H. O'Dell]

2007/3/21, erik quanstrom <quanstro@coraid.com>:
> 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?

In either case, it doesn't seem to happen very often. I got it by @{
cd ; tar -c . } | tar -xv ing my MP3s. So far, using cpdir, I haven't
seen any of this yet.

--dho

> - erik
> On Wed Mar 21 09:29:52 EDT 2007, devon.odell@gmail.com 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
>

Re: [9fans] Fossil errors

[erik quanstrom]

fossil should never do this.  this is a thread locking bug.

btw, why not use "all=+; disk/mkfs -vd $dst -s $src /env/all"?

- erik

On Wed Mar 21 11:54:29 EDT 2007, devon.odell@gmail.com wrote:
> 2007/3/21, erik quanstrom <quanstro@coraid.com>:
> > 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?
> 
> In either case, it doesn't seem to happen very often. I got it by @{
> cd ; tar -c . } | tar -xv ing my MP3s. So far, using cpdir, I haven't
> seen any of this yet.
> 
> --dho