[9fans] Fossil errors - Plan9

This is a discussion on [9fans] Fossil errors - Plan9 ; 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 ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: [9fans] Fossil errors

  1. [9fans] Fossil errors

    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

  2. Re: [9fans] Fossil errors

    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


  3. Re: [9fans] Fossil errors

    2007/3/21, 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?


    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

    >


  4. Re: [9fans] Fossil errors

    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 :
    > > 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


+ Reply to Thread