Re: cvsup servers broken?

2011-07-03 Thread Ian FREISLICH
Gavin Atkinson wrote:
 On Sat, 2 Jul 2011, Ian FREISLICH wrote:
  Matt wrote:
   On 07/01/11 09:34, Ian FREISLICH wrote:
It looks like the server is just exiting.  I've tested cvsup4 and
cvsup5 as well.  Is cvsup deprecated these days or has something
else broken it?
   
   Try csup instead of cvsup...I've found it works better. Any possibility 
   of network issues?
  
  csup gets into an infinite loop near the end of the ports tree and
  starts growing in memory consumption.  I killed it after it grew
  to about 500M resident.  The following is a ktrace snippet after
  it stalls:
  
   75390 csup RET   ioctl -1 errno 25 Inappropriate ioctl for device
   75390 csup CALL  ioctl(0x4,TIOCGETA,0xbf5fac60)
   75390 csup RET   ioctl -1 errno 25 Inappropriate ioctl for device
   75390 csup CALL  ioctl(0x4,TIOCGETA,0xbf5fac60)
   75390 csup RET   ioctl -1 errno 25 Inappropriate ioctl for device
   75390 csup CALL  ioctl(0x4,TIOCGETA,0xbf5fac60)
   75390 csup RET   ioctl -1 errno 25 Inappropriate ioctl for device
   75390 csup CALL  ioctl(0x4,TIOCGETA,0xbf5fac60)
   75390 csup RET   ioctl -1 errno 25 Inappropriate ioctl for device
   75390 csup CALL  ioctl(0x4,TIOCGETA,0xbf5fac60)
  
  The first part of csup's stack trace.  It appears to be corrupted
  with several null frames, and is very, very deep.
  
  (gdb) bt
  #0  0x2832c1f3 in ioctl () from /lib/libc.so.7
  #1  0x2832bdbc in tcgetattr () from /lib/libc.so.7
  #2  0x2832b7ea in isatty () from /lib/libc.so.7
  #3  0x08051832 in fnmatch ()
  #4  0x08051906 in fnmatch ()
  #5  0x08052135 in fnmatch ()
  #6  0x08059c19 in fnmatch ()
  #7  0x08059a76 in fnmatch ()
  #8  0x0804c1ff in ?? ()
  #9  0x28c11380 in ?? ()
  #10 0x2845f402 in ?? ()
  
  [mini] /usr/home/ianf # procstat -f  75390
PID COMM   FD T V FLAGSREF  OFFSET PRO NAME
  75390 csup text v r r---   -   - -   /usr/bin/csup 
  75390 csup ctty v c rw--   -   - -   /dev/pts/1
  75390 csup  cwd v d r---   -   - -   /usr/src  
  75390 csup root v d r---   -   - -   / 
  75390 csup0 v c rw--  14 10464115 -   /dev/pts/1   
 
  75390 csup1 v c rw--  14 10464115 -   /dev/pts/1   
 
  75390 csup2 v c rw--  14 10464115 -   /dev/pts/1   
 
  75390 csup3 s - rw--   2   0 TCP 10.0.2.67:19238 12
8.205.32.24:5999
  75390 csup4 v r r---   1   0 -   /usr/home/ncvs/por
ts/x11/wbar/Makefile,v
  75390 csup5 v r r---   11023 -   /var/db/sup/ports-
all/checkouts
  75390 csup6 v r r---   1 24492073 -   /var/db/sup/ports
-all/checkouts
  75390 csup7 v r -w--   1 24491389 -   /var/db/sup/ports
-all/#cvs.csup-75390.0
  
  filedescriptor 4's directory listing:
  
  [mini] /usr/home/ncvs/ports/x11/wbar # ls -la
  total 24
  drwxr-xr-x3 root  wheel512 Jul  1 07:21 .
  drwxr-xr-x  694 root  wheel  14848 Jun 28 16:29 ..
  -r--r--r--1 root  wheel  0 Feb  8 22:51 Makefile,v
  -r--r--r--1 root  wheel  0 Mar 19 14:38 distinfo,v
  drwxr-xr-x2 root  wheel512 Jul  1 07:21 files
  -r--r--r--1 root  wheel  0 Feb  8 22:51 pkg-descr,v
  -r--r--r--1 root  wheel  0 Feb  8 22:51 pkg-plist,v
  
  After removing the zero sized files, csup continued until it hit
  x11-toolkits/Makefile,v and then ports/x11-wm/Makefile,v which was
  also zero sized.  Having deleted all the zero files, both cvsup and
  csup complete their run.
 
 I don't think you'll get much interest in fixing cvsup, but if you can 
 recreate this at will with csup and haven't had a response in a few days, 
 could you please submit a PR?

This debugging above was with csup.  cvsup would cause the remote
to exit (hence the RST).  csup would just consume all RAM and CPU
when it encounters an empty ,v file.

Ian

-- 
Ian Freislich
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: devel/subversion: svn: Couldn't perform atomic initialization

2011-07-03 Thread Hartmann, O.

On 07/02/11 20:45, Alexander Kabaev wrote:

On Sat, 02 Jul 2011 09:27:42 +0200
Hartmann, O.ohart...@zedat.fu-berlin.de  wrote:


Hello.
Since two days now I realize on several recently ports-updated
servers a failure of the subversion server running on those servers.
Sneaking around the internet I found several issues exactly targeting
this error with an sqlite 3.7.7/3.7.7.1 issue, which has been fixed
in sqlite-3.7.7.2. At this very moment, our subversion servers in
question has all recently been updated and it seems, they all fail
the same way. Does anyone also realize this behaviour shown below
when commiting?

Is there a workaround? Any help or hint is appreciated.

Thanks in advance,
Oliver

Transmitting file data .svn: Commit failed (details follow):
svn: Couldn't perform atomic initialization
svn: database schema has changed
svn: Your commit message was left in a temporary file:


Update database/sqlite3 port to the 3.7.7.1 version committed today.



Done - and it works fine. Thanks. But why
3.7.7.1 and not  3.7.7.2?

Thanks, anyway.

Regards,
Oliver
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: cardbus panic: end address is not aligned

2011-07-03 Thread Adrian Chadd
The obvious question - can you bisect kernel versions to find out when it broke?


Adrian

On 3 July 2011 13:39, Doug Barton do...@freebsd.org wrote:
 I have 2 ath-based pc-card adapters. If I put either one of them in the slot
 while the system is up, or if I try booting with them in the slot, I get an
 instant panic. The cards previously worked in -current, and continue to work
 in 8-stable and windows xp. I don't have any other pc-cards to compare with.
 Full core.txt.0 file is in my home directory on freefall.

 This problem persists on r223732 but happened to me for the first time a
 week or 2 ago (haven't had time to report it previously, apologies). It
 likely originated a while before though, I don't use these cards very often.

 panic: end address is not aligned

 #1  0x80426a8a in kern_reboot (howto=260)
    at /home/svn/head/sys/kern/kern_shutdown.c:430
 #2  0x80426521 in panic (fmt=Variable fmt is not available.
 )
    at /home/svn/head/sys/kern/kern_shutdown.c:604
 #3  0x8032c648 in pcib_grow_window (sc=0xfe0002603400,
    w=0xfe0002603498, type=3, start=0, end=4294967295, count=65536,
 flags=Variable flags is not available.

 ) at /home/svn/head/sys/dev/pci/pci_pci.c:1018
 #4  0x8032c8f7 in pcib_alloc_resource (dev=0xfe00026f2600,
    child=0xfe0002eaf800, type=Variable type is not available.
 )
    at /home/svn/head/sys/dev/pci/pci_pci.c:1090
 #5  0x80325bdd in pci_alloc_resource (dev=0xfe000279bd00,
    child=0xfe0002eaf800, type=3, rid=0xff8000309688,
    start=2281701376, end=18446744073709551615, count=65536, flags=16384)
    at bus_if.h:263
 #6  0x8031bd25 in cbb_alloc_resource (brdev=Variable brdev is not
 available.
 ) at bus_if.h:263
 #7  0x80325d8e in pci_alloc_resource (dev=0xfe000279ed00,
    child=0xfe0002eaf800, type=3, rid=0xff8000309688, start=0,
    end=18446744073709551615, count=1, flags=16384) at bus_if.h:263
 #8  0x80456f39 in bus_alloc_resource (dev=0xfe0002eaf800,
 type=3,
    rid=0xff8000309688, start=0, end=18446744073709551615, count=1,
    flags=12290) at bus_if.h:263
 #9  0x802faa60 in cardbus_parse_cis (cbdev=0xfe000279ed00,
    child=0xfe0002eaf800, callbacks=0xff8000309af0,
    argp=0xfe0002e2d140) at bus.h:415
 #10 0x802fb0c1 in cardbus_device_create (sc=0xfe00025d8030,
    devi=0xfe0002e2d000, parent=Variable parent is not available.
 )
    at /home/svn/head/sys/dev/cardbus/cardbus_device.c:105
 #11 0x802f9c4e in cardbus_attach_card (cbdev=0xfe000279ed00)
    at /home/svn/head/sys/dev/cardbus/cardbus.c:191
 #12 0x8031ba44 in cbb_event_thread (arg=Variable arg is not
 available.
 ) at card_if.h:83
 #13 0x803fb355 in fork_exit (
    callout=0x8031b660 cbb_event_thread, arg=0xfe0002599800,
    frame=0xff8000309c50) at /home/svn/head/sys/kern/kern_fork.c:920
 #14 0x80666c4e in fork_trampoline ()
    at /home/svn/head/sys/amd64/amd64/exception.S:603



 --

        Nothin' ever doesn't change, but nothin' changes much.
                        -- OK Go

        Breadth of IT experience, and depth of knowledge in the DNS.
        Yours for the right price.  :)  http://SupersetSolutions.com/

 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: Problems with cvsup on FreeBSD 9, AMD64, osreldate: 900038

2011-07-03 Thread Vassilis Laganakos

On 02/07/2011 17:07, Garrett Cooper wrote:

On Sat, Jul 2, 2011 at 8:33 AM, Vassilis Laganakos
vassilis.lagana...@yahoo.com  wrote:

Hello,

I am facing the same problems as Holger here:

http://lists.freebsd.org/pipermail/freebsd-current/2011-June/025205.html

although CVSup dies in gmtime_r in libc.so.7:

...
Updating collection src-all/cvs
Edit src/UPDATING

Program received signal SIGSEGV, Segmentation fault.
0x2ca10fb9 in gmtime_r () from /lib/libc.so.7
...

See full gdb backtrace at:

http://www.pastie.org/pastes/2154271

So I'm now stuck in osrel 900038... I guess I need to rebuild libc.so.7
with debugging symbols to find out what is going wrong there.

Any quick ideas on how to correct this, or if someone else is seeing this
issue?


Have you tried recompiling cvsup and all of its dependencies?


Yeah, I rebuilt every port installed with pormaster -dBfa, hoping that 
that would correct it, but that gave the same behaviour.


Thanks,
Vassilis L.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: Problems with cvsup on FreeBSD 9, AMD64, osreldate: 900038

2011-07-03 Thread Vassilis Laganakos

On 02/07/2011 17:54, Kurt Jaeger wrote:

Hi!


Any quick ideas on how to correct this, or if someone else is seeing
this issue?


Does csup work ?


Yeah! That works!

I see that csups is part of the build system. So is this to replace the 
cvsup port?


Thanks,
Vassilis L.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: Problems with cvsup on FreeBSD 9, AMD64, osreldate: 900038

2011-07-03 Thread Vassilis Laganakos

On 03/07/2011 04:25, jhell wrote:



On Sat, Jul 02, 2011 at 04:33:39PM +0100, Vassilis Laganakos wrote:

Hello,

I am facing the same problems as Holger here:

http://lists.freebsd.org/pipermail/freebsd-current/2011-June/025205.html

although CVSup dies in gmtime_r in libc.so.7:

  ...
  Updating collection src-all/cvs
  Edit src/UPDATING

  Program received signal SIGSEGV, Segmentation fault.
  0x2ca10fb9 in gmtime_r () from /lib/libc.so.7
  ...

See full gdb backtrace at:

  http://www.pastie.org/pastes/2154271

So I'm now stuck in osrel 900038... I guess I need to rebuild libc.so.7
with debugging symbols to find out what is going wrong there.

Any quick ideas on how to correct this, or if someone else is seeing
this issue?



Use csup(1) in base. This is in 7, 8  9. cvsup has been deprecated for
much longer than it really needed to be and should probably be removed
from use as a client entirely and links generated for installation of
cvsup -  csup.

Oh, I wasn't aware of that. csup worked sweet, thanks! So I'll remove 
the cvsup port and switch to using csup.



Only drawback for you may be no X interface but it really was not that
pretty in the first place and served no real good purpose over the
functionality of the command line client.

An alternative if you need and X interface is creating a icon on your
desktop that runs ( xterm -e csup /path/to/supfile ) or something
similiar.
Ok. I haven't been using the X interface, and I agree it hasn't been 
that great.


Thanks for the information!

Vassilis L.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


seeing pf: state key linking mismatch! with pf on up to date current but not on FreeBSD 7.4-STABLE

2011-07-03 Thread eculp
Something is strange with PF.  I get the above error using pf on  
current but not on FreeBSD stable.  The pf configuration hasn't  
changed for a couple of years on either and they are the same except  
for hardware names.


The two machines are:
9.0-CURRENT FreeBSD 9.0-CURRENT #247: Wed Jun 29 04:49:16 CDT 2011
7.4-STABLE FreeBSD 7.4-STABLE #1228: Sat Jun 25 04:42:55 CDT 2011

Anyone else seeing this?

Thanks,

ed
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: seeing pf: state key linking mismatch! with pf on up to date current but not on FreeBSD 7.4-STABLE

2011-07-03 Thread Fabian Keil
eculp ec...@encontacto.net wrote:

 Something is strange with PF.  I get the above error using pf on  
 current but not on FreeBSD stable.  The pf configuration hasn't  
 changed for a couple of years on either and they are the same except  
 for hardware names.

pf has recently been updated in CURRENT.

 The two machines are:
 9.0-CURRENT FreeBSD 9.0-CURRENT #247: Wed Jun 29 04:49:16 CDT 2011
 7.4-STABLE FreeBSD 7.4-STABLE #1228: Sat Jun 25 04:42:55 CDT 2011
 
 Anyone else seeing this?

Yes:
http://lists.freebsd.org/pipermail/freebsd-pf/2011-June/006191.html

Fabian


signature.asc
Description: PGP signature


Re: seeing pf: state key linking mismatch! with pf on up to date current but not on FreeBSD 7.4-STABLE

2011-07-03 Thread eculp

Quoting Fabian Keil freebsd-lis...@fabiankeil.de:


eculp ec...@encontacto.net wrote:


Something is strange with PF.  I get the above error using pf on
current but not on FreeBSD stable.  The pf configuration hasn't
changed for a couple of years on either and they are the same except
for hardware names.


pf has recently been updated in CURRENT.


The two machines are:
9.0-CURRENT FreeBSD 9.0-CURRENT #247: Wed Jun 29 04:49:16 CDT 2011
7.4-STABLE FreeBSD 7.4-STABLE #1228: Sat Jun 25 04:42:55 CDT 2011

Anyone else seeing this?


Yes:
http://lists.freebsd.org/pipermail/freebsd-pf/2011-June/006191.html

Fabian


Thanks, Fabian.  From what I understand, not officially fixed yet.

Have a great weekend.

ed





___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: devel/subversion: svn: Couldn't perform atomic initialization

2011-07-03 Thread Alexander Kabaev
On Sun, 03 Jul 2011 11:15:50 +0200
Hartmann, O. ohart...@zedat.fu-berlin.de wrote:

 On 07/02/11 20:45, Alexander Kabaev wrote:
  On Sat, 02 Jul 2011 09:27:42 +0200
  Hartmann, O.ohart...@zedat.fu-berlin.de  wrote:
 
SKIP/
 
  Update database/sqlite3 port to the 3.7.7.1 version committed today.
 
 
 Done - and it works fine. Thanks. But why
 3.7.7.1 and not  3.7.7.2?
 
 Thanks, anyway.
 
 Regards,
 Oliver

No reason other than 3.7.7.1 appears to be the latest version currently
in ports.

-- 
Alexander Kabaev


signature.asc
Description: PGP signature


Re: seeing pf: state key linking mismatch! with pf on up to date current but not on FreeBSD 7.4-STABLE

2011-07-03 Thread Matt

On 07/03/11 06:27, eculp wrote:
Something is strange with PF.  I get the above error using pf on 
current but not on FreeBSD stable.  The pf configuration hasn't 
changed for a couple of years on either and they are the same except 
for hardware names.


The two machines are:
9.0-CURRENT FreeBSD 9.0-CURRENT #247: Wed Jun 29 04:49:16 CDT 2011
7.4-STABLE FreeBSD 7.4-STABLE #1228: Sat Jun 25 04:42:55 CDT 2011

Anyone else seeing this?

Thanks,

ed
___

I am also seeing this, especially when a website/browser/tab is closed 
but the remote site is still sending data I think.


I am using the same basic pf.conf I have used for client machines for a 
while, but there is not much other than pf options and allowing traffic 
out (modulate state for tcp, keep state for everything else). I do have 
scrub, and antispoof rules for the interfaces, as well as a block log 
all at the top.


For now, like i said, I've only seen the state key mismatches with web 
traffic. Also, synproxy state seems to hang all traffic.


Matt

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: Problems with cvsup on FreeBSD 9, AMD64, osreldate: 900038

2011-07-03 Thread Stephen Montgomery-Smith

On 07/02/2011 10:25 PM, jhell wrote:


Use csup(1) in base. This is in 7, 8  9. cvsup has been deprecated for
much longer than it really needed to be and should probably be removed
from use as a client entirely and links generated for installation of
cvsup -  csup.

Only drawback for you may be no X interface but it really was not that
pretty in the first place and served no real good purpose over the
functionality of the command line client.


Another drawback to csup is that csup doesn't seem to recognize the 
.cvsup/auth file.  At least not on FreeBSD 7 of a few months ago.


I run CTM generation, and I need access to cvsup-master.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org