Re: Panics after AHCI timeouts

2011-10-25 Thread Alexey Shuvaev 
On Mon, Oct 24, 2011 at 08:27:49PM +0200, C. P. Ghost wrote:
 On Tue, Oct 18, 2011 at 3:13 PM, Alexey Shuvaev
 shuv...@physik.uni-wuerzburg.de wrote:
  On Tue, Oct 18, 2011 at 06:19:19AM +0800, Adrian Chadd wrote:
  On 18 October 2011 03:00, Alexey Shuvaev
  shuv...@physik.uni-wuerzburg.de wrote:
   On Sat, Oct 08, 2011 at 10:14:56PM +0200, Alexey Shuvaev wrote:
   Hello list!
  
   Errr... Replying to myself... Ping? Should I file a PR and put it
   in the back burner? :)
 
  I think filing a PR is a good move. Then just be proactive and poke
  people about it. It'd be good to get this fixed. :)
 
  Done, kern/161768.
 
  Question to the list: does anybody see successful recovery from AHCI
  timeout an a recent CURRENT? Recent means June 2011 or newer, so 9.0
  branch counts also. That is, there are some kernel messages like this:
 
  ahcich0: Timeout on slot 29 port 0
  ahcich0: is  cs  ss  rs  tfd 40 serr 
   cmd fc17
 
  but then AHCI recovers and the system does not panic?
 
 I'm seeing these timeouts too on an 8.2-STABLE amd64 r222832
 from June 7. The system hangs partially -- or, more precisely, all
 processes that attempt to access the disk on this channel hang,
 everything else continues as normal.
 
 I suspect a faulty cable, but I don't have physical access to the system
 to replace parts right now. A panic would be a regression, so I'm holding
 off updates on that server until AHCI becomes more tolerant and somewhat
 self-healing. :(
 
In a communication not on the list mav has said he has done some tests
not so long ago by injecting artificial failures in the AHCI code.
He has not observed any panics and it is not clear if the problem is
generic / hardware related / or purely local. I would not have any time
to investigate further till November.

So, Your Mileage May Vary :)

0.02$,
Alexey.
___
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: Panics after AHCI timeouts

2011-10-18 Thread Alexey Shuvaev 
On Tue, Oct 18, 2011 at 06:19:19AM +0800, Adrian Chadd wrote:
 On 18 October 2011 03:00, Alexey Shuvaev
 shuv...@physik.uni-wuerzburg.de wrote:
  On Sat, Oct 08, 2011 at 10:14:56PM +0200, Alexey Shuvaev wrote:
  Hello list!
 
  Errr... Replying to myself... Ping? Should I file a PR and put it
  in the back burner? :)
 
 I think filing a PR is a good move. Then just be proactive and poke
 people about it. It'd be good to get this fixed. :)
 
Done, kern/161768.

Question to the list: does anybody see successful recovery from AHCI
timeout an a recent CURRENT? Recent means June 2011 or newer, so 9.0
branch counts also. That is, there are some kernel messages like this:

ahcich0: Timeout on slot 29 port 0
ahcich0: is  cs  ss  rs  tfd 40 serr  
cmd fc17

but then AHCI recovers and the system does not panic?

Poking Alexey.
___
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: Panics after AHCI timeouts

2011-10-17 Thread Alexey Shuvaev 
On Sat, Oct 08, 2011 at 10:14:56PM +0200, Alexey Shuvaev wrote:
 Hello list!
 
Errr... Replying to myself... Ping? Should I file a PR and put it
in the back burner? :)

 In the view of upcoming RELEASE-9.0 I should have reported it earlier,
 but it is better later than never... Every time I wanted to report
 this, the system was ~one month old and I tried to upgrade it
 to see, if the problem was still there, waiting for the next panic...
 and when it finally paniced it was one month old again.
 
[snip]
 From core.txt.5:
 [snip]
 Unread portion of the kernel message buffer:
 Memory modified after free 0xfe000416e200(248) val=79e8800 @ 
 0xfe000416e200
 panic: Most recently used by cred
 
 cpuid = 2
 Uptime: 20h11m1s
 Dumping 1308 out of 7914 MB:..2%..12%..21%..31%..41%..51%..62%..71%..81%..91%
 [snip]
 #0  doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:252
 252 if (textdump  textdump_pending) {
 (kgdb) #0  doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:252
 #1  0x808234aa in kern_reboot (howto=260)
 at /usr/src/sys/kern/kern_shutdown.c:430
 #2  0x80822f41 in panic (fmt=Variable fmt is not available.
 )
 at /usr/src/sys/kern/kern_shutdown.c:595
 #3  0x80a6f7b4 in mtrash_ctor (mem=Variable mem is not available.
 ) at /usr/src/sys/vm/uma_dbg.c:137
 #4  0x80a6f01c in uma_zalloc_arg (zone=0xfe021ffe0700, udata=0x0, 
 flags=258) at /usr/src/sys/vm/uma_core.c:2018
 #5  0x808108be in malloc (size=Variable size is not available.
 ) at uma.h:305
 #6  0x8081c21f in crget () at /usr/src/sys/kern/kern_prot.c:1809
 #7  0x8081c269 in crdup (cr=0xfe0143103300)
 at /usr/src/sys/kern/kern_prot.c:1911
 #8  0x808c5ca6 in kern_accessat (td=0xfe0007dd7000, fd=-100, 
 path=0x80065c000 Address 0x80065c000 out of bounds, 
 pathseg=UIO_USERSPACE, flags=Variable flags is not available.
 ) at /usr/src/sys/kern/vfs_syscalls.c:2201
 #9  0x8086719a in syscallenter (td=0xfe0007dd7000, 
 sa=0xff8223f67bb0) at /usr/src/sys/kern/subr_trap.c:344
 #10 0x80b0b43c in syscall (frame=0xff8223f67c50)
 at /usr/src/sys/amd64/amd64/trap.c:910
 #11 0x80af617d in Xfast_syscall ()
 at /usr/src/sys/amd64/amd64/exception.S:384
 #12 0x00080062dbdc in ?? ()
 Previous frame inner to this frame (corrupt stack?)
 [snip]
 [last message in dmesg]
 ahcich0: Timeout on slot 29 port 0
 ahcich0: is  cs  ss  rs  tfd 40 serr  
 cm
 d fc17
 [snip]
 
___
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

Panics after AHCI timeouts

2011-10-08 Thread Alexey Shuvaev 
Hello list!

In the view of upcoming RELEASE-9.0 I should have reported it earlier,
but it is better later than never... Every time I wanted to report
this, the system was ~one month old and I tried to upgrade it
to see, if the problem was still there, waiting for the next panic...
and when it finally paniced it was one month old again.

For some time (around half a year actually :) under some heavy disk load
my desktop panics. The panics are not 100% reproducible, two situations
which could lead to a panic are:
 - svn up in /usr/src
 - last stage of openoffice building (I think, during the packaging stage)

Updating the sources is less probable to panic the system (I would give
~30% of probability), but building OOO is close to 100% to cause the panic.

The root cause seems to be the Samsung hard drive in use -
it times out on some NCQ slots under heavy load.
Same problem is reported, for example here:
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/157397

Earlier this year (I would say March - May), AHCI handled these timeouts,
at least to the point when the disk (and, possibly, the controlled too)
were completely wedged (only power cycling had brought them back again,
reset was not sufficient). From ~June, however, the system paniced
right after the first timeout. So it is this panic immediately after ahci
timeout which could be hopefully fixed.

Some info about the system:

~ uname -a
FreeBSD lexx.ifp.tuwien.ac.at 9.0-BETA2 FreeBSD 9.0-BETA2 #0 r225311: Thu Sep  
1 17:17:57 CEST 2011 
r...@lexx.ifp.tuwien.ac.at:/usr/obj/usr/src/sys/GENERIC  amd64

From dmesg.boot:
[snip]
ahci0: ATI IXP700 AHCI SATA controller port 
0xb000-0xb007,0xa000-0xa003,0x9000-0x9007,0x8000-0x8003,0x7000-0x700f mem 
0xfe5ffc00-0xfe5f irq 19 at device 17.0 on pci0
ahci0: AHCI v1.20 with 6 6Gbps ports, Port Multiplier supported
ahcich0: AHCI channel at channel 0 on ahci0
ahcich1: AHCI channel at channel 1 on ahci0
ahcich2: AHCI channel at channel 2 on ahci0
ahcich3: AHCI channel at channel 3 on ahci0
ahcich4: AHCI channel at channel 4 on ahci0
ahcich5: AHCI channel at channel 5 on ahci0
[snip]
ada0 at ahcich0 bus 0 scbus1 target 0 lun 0
ada0: SAMSUNG HD204UI 1AQ10001 ATA-8 SATA 2.x device
ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)
ada0: Command Queueing enabled
ada0: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C)
ada0: Previously was known as ad4
[snip]

~ cat /etc/rc.local 
#!/bin/sh
ddb script kdb.enter.panic=capture on; show pcpu; trace; ps; show locks; 
alltrace; show alllocks; show lockedvnods; call doadump; reset
sysctl debug.debugger_on_panic=0

I have two cores:
~ ll /var/crash/
total 2628524
-rw-r--r--  1 root  wheel   2 Oct  7 15:12 bounds
-rw-r-  1 root  wheel  224897 Aug  5 18:07 core.txt.3
-rw-r-  1 root  wheel  151478 Oct  7 15:13 core.txt.5
-rw-r-  1 root  wheel 475 Aug  5 18:06 info.3
-rw-r-  1 root  wheel 478 Oct  7 15:12 info.5
-rw-r--r--  1 root  wheel   5 Jan 26  2011 minfree
-rw-r-  1 root  wheel  1390616576 Aug  5 18:07 vmcore.3
-rw-r-  1 root  wheel  1371832320 Oct  7 15:13 vmcore.5

However, I do not have the old kernel for the core N 3 anymore
(but the current kernel is the one which produced core N 5).





From core.txt.3:
[snip]
Unread portion of the kernel message buffer:

Fatal trap 9: general protection fault while in kernel mode
cpuid = 0; apic id = 00
instruction pointer = 0x20:0x8092988e
stack pointer   = 0x28:0xff8000256a80
frame pointer   = 0x28:0xff8000256aa0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 12 (swi4: clock)
trap number = 9
panic: general protection fault
cpuid = 0
VNASSERT failed
Uptime: 0xfe0073591780: 3dtag ufs, type VDIR
7h59musecount 1, writecount 0, refcount 4 mountedhere 0
45s
flags ()
v_object 0xfe00888501b0 ref 0 pages 1
lock type ufs: UNLOCKED
ino 2709060, on dev ada0p6
VNASSERT failed
0xfe0073591780: tag ufs, type VDIR
usecount 1, writecount 0, refcount 4 mountedhere 0
flags ()
v_object 0xfe00888501b0 ref 0 pages 1
lock type ufs: UNLOCKED
ino 2709060, on dev ada0p6
Dumping 1326 out of 7914 MB:..2%..11%..21%..31%..42%..51%..61%..72%..81%..91%
[snip]
#0  doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:252
252 if (textdump  textdump_pending) {
(kgdb) #0  doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:252
#1  0x8081f3ca in kern_reboot (howto=260)
at /usr/src/sys/kern/kern_shutdown.c:430
#2  0x8081ee61 in panic (fmt=Variable fmt is not available.
)
at /usr/src/sys/kern/kern_shutdown.c:595
#3  0x80b04b70 in trap_fatal (frame=0x9, eva=Variable eva is not 
available.
)
at /usr/src/sys/amd64/amd64/trap.c:805
#4  0x80b05145 in

Re: FreeBSD mbufs() cache poisoning local priv escalation v2 by KCOPE

2011-08-24 Thread Alexey Shuvaev 
On Wed, Aug 24, 2011 at 11:59:01AM -0300, Victor Detoni wrote:
 Does Someone know if this was fixed?
 
 On Wed, Aug 24, 2011 at 11:57 AM, Victor Detoni victordet...@gmail.comwrote:
 
  Oh shit guys!
 
  http://pastebin.com/dyKLRr0v
 

It is already one year old... and it was fixed before this pastebin:
http://security.freebsd.org/advisories/FreeBSD-SA-10:07.mbuf.asc

Alexey.
___
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

[clang] OpenOffice does not work with clang-compiled libgcc_s.so.1

2011-07-27 Thread Alexey Shuvaev 
Hello list!

I have decided that clang in mature enough to give it a try on a main
desktop. Everything is working fine except OpenOffice. The problem was
already reported [1] and even analyzed [2]. Although the OP has reported [3]
that since r218915 he has no problems anymore, I still have :(
Note, that according to [4] it seems it was not specifically fixed upstream.

So, if I compile the whole world (and kernel) with clang, soffice.bin
dumps core. If I recompile the world with gcc and replace /lib/libgcc_s.so.1
with the new one, OpenOffice works fine again. Here are some information
about the system that may be useful:

~ uname -a
FreeBSD lexx.ifp.tuwien.ac.at 9.0-BETA1 FreeBSD 9.0-BETA1 #0 r224414: Tue Jul 
26 16:00:43 CEST 2011 
r...@lexx.ifp.tuwien.ac.at:/usr/obj/usr/src/sys/GENERIC  amd64

~ gcc --version
gcc (GCC) 4.2.2 20070831 prerelease [FreeBSD]
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

~ clang --version
FreeBSD clang version 3.0 (trunk 135360) 20110717
Target: x86_64-unknown-freebsd9.0
Thread model: posix

~ cat /etc/make.conf
SUP_UPDATE= YES
PORTSSUPFILE=   /root/ports-supfile
DOCSUPFILE= /root/doc-supfile
DOC_LANG=   en_US.ISO8859-1

.if ${.CURDIR:M*/usr/ports*}
.include /etc/ports.conf
.endif

# Building base with clang
.if ${.CURDIR:M*/usr/src*}
.if !defined(CC) || ${CC} == cc
CC= clang
.endif
.if !defined(CXX) || ${CXX} == c++
CXX=clang++
.endif
.if !defined(CPP) || ${CPP} == cpp
CPP=clang -E
.endif
# Don't die on warnings
NO_WERROR=
WERROR=
.endif
# added by use.perl 2011-07-18 17:50:51
PERL_VERSION=5.14.1

I don't have much time recently, so any further debugging will be on a
best effort basis. Anyway I thought it is better to post it here, so
it won't be just lost. If necessary I can file a PR about it.

Thanks,
Alexey.

[1] http://lists.freebsd.org/pipermail/freebsd-current/2010-October/020668.html
[2] http://lists.freebsd.org/pipermail/freebsd-current/2010-November/020838.html
[3] http://lists.freebsd.org/pipermail/freebsd-current/2011-February/023003.html
[4] http://llvm.org/bugs/show_bug.cgi?id=8541
___
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: [PATCH] Simple tidy up of puc(4) bus driver

2011-06-15 Thread Alexey Shuvaev 
On Tue, Jun 14, 2011 at 11:34:34AM -0400, John Baldwin wrote:
 On Tuesday, June 14, 2011 10:44:18 am Alexey Shuvaev wrote:
  On Fri, Jun 10, 2011 at 03:11:02PM -0400, John Baldwin wrote:
   On Monday, May 23, 2011 10:39:02 am John Baldwin wrote:
This small patch makes the puc(4) bus drivers a little more friendly.  
It 
should now list the port for each child device in the boot messages, 
and 
devinfo -v should list the type and port of each child device in its 
output as 
well:
   
   Can I get a volunteer to test these changes?
   
  Would it be OK to use r202285 as a base for your patch?
  If so, I will test it today/tomorrow. If not, it will take a little bit
  longer...
 
 Yes, it should apply fine to that.  It doesn't touch pucdata.c which is the
 only thing in the puc driver that has changed since that revision.  Thanks!
 
Seems to work fine. Attached are relevant diff-s of dmesg.boot and
devinfo -v output.

Alexey.
--- dmesg.boot_old  2011-06-15 16:18:52.0 +0200
+++ dmesg.boot_new  2011-06-15 16:23:56.0 +0200
@@ -49,11 +49,11 @@
 pcm0: Analog Devices AD1881A AC97 Codec
 puc0: NetMos NM9835 Dual UART and 1284 Printer port port 
0x7c00-0x7c07,0x8000-0x8007,0x8400-0x8407,0x8800-0x8807,0x8c00-0x8c07,0x9000-0x900f
 irq 7 at device 10.0 on pci0
 puc0: [FILTER]
-uart2: Non-standard ns8250 class UART with FIFOs on puc0
+uart2: Non-standard ns8250 class UART with FIFOs at port 1 on puc0
 uart2: [FILTER]
-uart3: Non-standard ns8250 class UART with FIFOs on puc0
+uart3: Non-standard ns8250 class UART with FIFOs at port 2 on puc0
 uart3: [FILTER]
-ppc0: Parallel port on puc0
+ppc0: Parallel port at port 3 on puc0
 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode
 ppc0: FIFO with 16/16/12 bytes threshold
 ppbus0: Parallel port bus on ppc0
--- devinfo_old 2011-06-15 16:19:03.0 +0200
+++ devinfo_new 2011-06-15 16:24:02.0 +0200
@@ -38,9 +38,9 @@
 hostb1 pnpinfo vendor=0x1106 device=0x3057 subvendor=0x 
subdevice=0x class=0x06 at slot=7 function=4 handle=\_SB_.PCI0.VTAC
 pcm0 pnpinfo vendor=0x1106 device=0x3058 subvendor=0x11d6 
subdevice=0x7358 class=0x040100 at slot=7 function=5
 puc0 pnpinfo vendor=0x9710 device=0x9835 subvendor=0x1000 
subdevice=0x0012 class=0x078000 at slot=10 function=0
-  uart2
-  uart3
-  ppc0
+  uart2 pnpinfo type=1 at port=1
+  uart3 pnpinfo type=1 at port=2
+  ppc0 pnpinfo type=2 at port=3
 ppbus0
   plip0
   lpt0
___
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: [PATCH] Simple tidy up of puc(4) bus driver

2011-06-14 Thread Alexey Shuvaev 
On Fri, Jun 10, 2011 at 03:11:02PM -0400, John Baldwin wrote:
 On Monday, May 23, 2011 10:39:02 am John Baldwin wrote:
  This small patch makes the puc(4) bus drivers a little more friendly.  It 
  should now list the port for each child device in the boot messages, and 
  devinfo -v should list the type and port of each child device in its output 
  as 
  well:
 
 Can I get a volunteer to test these changes?
 
Would it be OK to use r202285 as a base for your patch?
If so, I will test it today/tomorrow. If not, it will take a little bit
longer...

Alexey.
___
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: looking for a fast way to dump a dvd to a file on my hdd

2011-02-02 Thread Alexey Shuvaev 
On Wed, Feb 02, 2011 at 07:54:41PM +, Alexander Best wrote:
 hi there,
 
 i'd like to copy several dvds to my hdd. however my attempts so far haven't
 really been that successfull. basically using dd(1) is just way too slow.
 
 this is my dvd drive:
 
 cd0 at ata2 bus 0 scbus2 target 0 lun 0
 cd0: HL-DT-ST DVDRAM GSA-H10N JL12 Removable CD-ROM SCSI-0 device 
 cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes)
 cd0: cd present [342970 x 2048 byte records]
 
 being connected to
 
 ata2: ATA channel 0 on atapci0
 atapci0: JMicron JMB363 UDMA133 controller port 
 0xd000-0xd007,0xd100-0xd103,0xd200-0xd207,0xd300-0xd303,0xd400-0xd40f irq 16 
 at device 0.1 on pci3
 
 please not that this is an atapi drive, but i'm using ATA_CAM.
 
 so far dd(1) with a bs=2048 finished after:
 
Try using larger bs, for example bs=1m

 4676648960 bytes transferred in 1639.108763 secs (2853166 bytes/sec)
 
 ... this drive is capable of reading dvds at a speed of 16x. [1] tells me,
 that this means the entire disc (SL) should have been read after ~ 4 minutes.
 
 please also note that hw.ata.atapi_dma = 1. any suggestions how i can speed up
 the process? might switching back to the ata(4) subsystem increase the speed?
 
 i'm running HEAD (r218104) on the amd64 architecture.
 
 cheers.
 alex
 
 [1] http://en.wikipedia.org/wiki/DVD#Technology
 
___
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: [WORKAROUND] www/seamonkey2 on CURRENT

2011-01-29 Thread Alexey Shuvaev 
On Fri, Jan 28, 2011 at 05:37:51PM -0800, Garrett Cooper wrote:
 On Fri, Jan 28, 2011 at 3:58 PM, Alexey Shuvaev
 shuv...@physik.uni-wuerzburg.de wrote:
  Hello!
 
  It seems www/seamonkey2 is broken on CURRENT for at least 1 month now [1].
  Examining build log and reproducing it locally, the problem is in the
  usage of libiconv in nsNativeCharsetUtils.cpp. The linker fails to
  produce libxpcom_core.so although -L/usr/local/lib and -liconv
  are specified [2]. Examining this further I found that 
  nsNativeCharsetUtils.o
  produced with [3] fails to link with libiconv alone too [4] (note
  still unresolved libiconv references).
  I'm not a compiler/linker guru and do not understand what is happening
  here. As a workaroud I use the attached patch which disables the usage
  of libiconv in nsNativeCharsetUtils.cpp.
 
 ls /usr/local/lib/libiconv*so* ?

~ ll /usr/local/lib/libiconv*so*
lrwxr-xr-x  1 root  wheel   13 Jan 27 13:14 /usr/local/lib/libiconv.so - 
libiconv.so.3
-r--r--r--  1 root  wheel  1078567 Jan 27 13:14 /usr/local/lib/libiconv.so.3

I'm not so lame :)

On Sat, Jan 29, 2011 at 01:39:15PM -0500, Alexander Kabaev wrote:
 On Sat, 29 Jan 2011 13:21:44 -0500
 Alexander Kabaev kab...@gmail.com wrote:
 
  On Sat, 29 Jan 2011 13:02:24 -0500 (EST)
  Daniel Eischen deisc...@freebsd.org wrote:
  
   On Sat, 29 Jan 2011, Alexey Shuvaev wrote:
   
Hello!
   
It seems www/seamonkey2 is broken on CURRENT for at least 1 month
now [1]. Examining build log and reproducing it locally, the
problem is in the usage of libiconv in nsNativeCharsetUtils.cpp.
The linker fails to produce libxpcom_core.so although
-L/usr/local/lib and -liconv are specified [2]. Examining this
further I found that nsNativeCharsetUtils.o produced with [3]
fails to link with libiconv alone too [4] (note still unresolved
libiconv references). I'm not a compiler/linker guru and do not
understand what is happening here. As a workaroud I use the
attached patch which disables the usage of libiconv in
nsNativeCharsetUtils.cpp.
   
   Yes, I had this problem also on -current.  Does seamonkey build
   on recent 8.x?
   
   libxpcomio_s.a is a static library that has unresolved references
   to libiconv.  I guess I'd expect those references to be resolved
   with a later -L/usr/local/lib -liconv when building the shared
   library (libxpcom_core.so), but they are not.
   
  
  My wild guess: seamonkey tries to hide symbols that are coming from
  different .o file (this time one from libiconv.a) and that fails with
  our toolchain.
  
  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20218
  -- 
  Alexander Kabaev
 
 Follow-up to myself: Nope, the fix to said bug appears in our compiler.
 Can you make amd64 version of nsNativeCharsetUtils.
 -- 
 Alexander Kabaev

??? (It is already on amd64)
Well, I have fogotten to put my environment:
~ uname -a
FreeBSD lexx.ifp.tuwien.ac.at 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r217884: Wed 
Jan 26 17:00:37 CET 2011 
r...@lexx.ifp.tuwien.ac.at:/usr/obj/usr/src/sys/GENERIC  amd64

And here is the winner:

On Sat, Jan 29, 2011 at 08:32:07AM +0300, Anonymous wrote:
 Alexey Shuvaev shuv...@physik.uni-wuerzburg.de writes:
 
  Hello!
 
  It seems www/seamonkey2 is broken on CURRENT for at least 1 month now [1].
  Examining build log and reproducing it locally, the problem is in the
  usage of libiconv in nsNativeCharsetUtils.cpp. The linker fails to
  produce libxpcom_core.so although -L/usr/local/lib and -liconv
  are specified [2]. Examining this further I found that 
  nsNativeCharsetUtils.o
  produced with [3] fails to link with libiconv alone too [4] (note
  still unresolved libiconv references).
  I'm not a compiler/linker guru and do not understand what is happening
  here. As a workaroud I use the attached patch which disables the usage
  of libiconv in nsNativeCharsetUtils.cpp.
 
 [...]
  /usr/bin/ld: aaa: hidden symbol `libiconv_open' isn't defined
 
 /head per r215840 has working -fvisibility=hidden, i.e. config/gcc_hidden.h.
 Try following diff, it should enable patching iconv.h wrapper in bsd.gecko.mk
 
   @${ECHO_CMD} #pragma GCC system_header  ${MOZSRC}/${subdir}/iconv.h
   @${ECHO_CMD} #pragma GCC visibility push(default)  
 ${MOZSRC}/${subdir}/iconv.h
   @${ECHO_CMD} #include \${LOCALBASE}/include/iconv.h\  
 ${MOZSRC}/${subdir}/iconv.h
   @${ECHO_CMD} #pragma GCC visibility pop  ${MOZSRC}/${subdir}/iconv.h
 
 %%
 Index: www/seamonkey2/Makefile
 ===
 RCS file: /a/.cvsup/ports/www/seamonkey2/Makefile,v
 retrieving revision 1.315
 diff -u -p -r1.315 Makefile
 --- www/seamonkey2/Makefile   10 Dec 2010 13:31:12 -  1.315
 +++ www/seamonkey2/Makefile   29 Jan 2011 05:22:11 -
 @@ -28,11 +28,10 @@ ALL_TARGET=   default
  MAKE_JOBS_SAFE=  yes
  MOZ_PIS_SCRIPTS= moz_pis_S50cleanhome
  MAKE_ENV=LD_LIBRARY_PATH=${WRKSRC}/dist/bin
 -CONFIGURE_ENV

[WORKAROUND] www/seamonkey2 on CURRENT

2011-01-28 Thread Alexey Shuvaev 
Hello!

It seems www/seamonkey2 is broken on CURRENT for at least 1 month now [1].
Examining build log and reproducing it locally, the problem is in the
usage of libiconv in nsNativeCharsetUtils.cpp. The linker fails to
produce libxpcom_core.so although -L/usr/local/lib and -liconv
are specified [2]. Examining this further I found that nsNativeCharsetUtils.o
produced with [3] fails to link with libiconv alone too [4] (note
still unresolved libiconv references).
I'm not a compiler/linker guru and do not understand what is happening
here. As a workaroud I use the attached patch which disables the usage
of libiconv in nsNativeCharsetUtils.cpp.

My little more than 0.02$,
Alexey.


[1]: 
http://portsmon.freebsd.org/portoverview.py?category=wwwportname=seamonkey2wildcard=

[2]: c++ -I/usr/local/include/nss -I/usr/local/include/nss/nss   
-I/usr/local/include  -I/usr/local/include -fno-rtti -fno-exceptions -Wall 
-Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy 
-Wno-non-virtual-dtor -Wcast-align -Wno-invalid-offsetof -Wno-long-long -O2 
-pipe -fno-strict-aliasing -fno-strict-aliasing -fshort-wchar -pipe  -DNDEBUG 
-DTRIMMED -O -fPIC -shared -Wl,-z,defs -Wl,-h,libxpcom_core.so -o 
libxpcom_core.so  pldhash.o nsArrayEnumerator.o nsArrayUtils.o 
nsCategoryCache.o nsCOMPtr.o nsCOMArray.o nsCRTGlue.o nsComponentManagerUtils.o 
nsEnumeratorUtils.o nsID.o nsIInterfaceRequestorUtils.o nsINIParser.o 
nsISupportsImpl.o nsMemory.o nsWeakReference.o nsGREGlue.o 
nsVersionComparator.o nsTHashtable.o nsQuickSort.o nsVoidArray.o nsTArray.o 
nsThreadUtils.o nsTObserverArray.o nsCycleCollectionParticipant.o nsDeque.o 
nsAutoLock.o nsGenericFactory.o nsProxyRelease.o nsTextFormatter.o 
nsXPComInit.o nsXPCOMStrings.o -pthread   -L/usr/local/lib/nss 
-Wl,-rpath,/usr/local/lib/seamonkey  -lc  
-Wl,-rpath-link,/work/a/ports/www/seamonkey2/work/comm-1.9.1/mozilla/dist/bin 
-Wl,-rpath-link,/work/a/ports/www/seamonkey2/work/fake/lib  -Wl,--whole-archive 
../ds/libxpcomds_s.a ../io/libxpcomio_s.a ../components/libxpcomcomponents_s.a 
../threads/libxpcomthreads_s.a ../proxy/src/libxpcomproxy_s.a 
../base/libxpcombase_s.a ../reflect/xptcall/src/libxptcall.a 
../reflect/xptcall/src/libxptcmd.a ../reflect/xptinfo/src/libxptinfo.a 
../../dist/lib/libxpt.a ../string/src/libstring_s.a  -Wl,--no-whole-archive  
-L/usr/local/lib -lplds4 -lplc4 -lnspr4 -pthread -pthread -L/usr/local/lib 
-lgtk-x11-2.0 -latk-1.0 -lgdk-x11-2.0 -lpangocairo-1.0 -lXext -lXrender 
-lXinerama -lXi -lXrandr -lXcursor -lXcomposite -lXdamage -lgdk_pixbuf-2.0 
-lpangoft2-1.0 -lpango-1.0 -lfreetype -lfontconfig -lgio-2.0 -lXfixes 
-lgobject-2.0 -lgmodule-2.0 -lpng -lz -lm -lgthread-2.0 -lglib-2.0 -lcairo 
-lX11   -lm -pthread -lm -pthread -pthread -L/usr/local/lib -liconv
../io/libxpcomio_s.a(nsNativeCharsetUtils.o)(.text+0x32): In function 
`xp_iconv(void*, char const**, unsigned int*, char**, unsigned int*)':
: undefined reference to `libiconv'

[3]: c++ -o nsNativeCharsetUtils.o -c -I../../dist/include/system_wrappers 
-include ../../config/gcc_hidden.h -DMOZILLA_INTERNAL_API -DMOZ_SUITE=1 
-DOSTYPE=\FreeBSD9\ -DOSARCH=FreeBSD -D_IMPL_NS_COM -I.. -I. -I. 
-I../../dist/include/string -I../../dist/include   -I../../dist/include/xpcom 
-I/usr/local/include/nspr   -I/usr/include -I/usr/local/include   -fPIC  
-I/usr/local/include/nss -I/usr/local/include/nss/nss   -I/usr/local/include  
-I/usr/local/include -fno-rtti -fno-exceptions -Wall -Wpointer-arith 
-Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor 
-Wcast-align -Wno-invalid-offsetof -Wno-long-long -O2 -pipe 
-fno-strict-aliasing -fno-strict-aliasing -fshort-wchar -pipe  -DNDEBUG 
-DTRIMMED -Os -fno-strict-aliasing   -I/usr/local/include/nss 
-I/usr/local/include/nss/nss   -I/usr/local/include  -I/usr/local/include 
-DMOZILLA_CLIENT -include ../../mozilla-config.h nsNativeCharsetUtils.cpp

[4]: c++ -o aaa nsNativeCharsetUtils.o -L/usr/local/lib -liconv
/usr/lib/crt1.o(.text+0x8a): In function `_start':
: undefined reference to `main'
nsNativeCharsetUtils.o(.text+0x16): In function `xp_iconv(void*, char const**, 
unsigned long*, char**, unsigned long*)':
: undefined reference to `libiconv'
nsNativeCharsetUtils.o(.text+0x571): In function 
`nsNativeCharsetConverter::GlobalShutdown()':
: undefined reference to `PR_DestroyLock'
nsNativeCharsetUtils.o(.text+0x58e): In function 
`nsNativeCharsetConverter::GlobalShutdown()':
: undefined reference to `libiconv_close'
nsNativeCharsetUtils.o(.text+0x5ab): In function 
`nsNativeCharsetConverter::GlobalShutdown()':
: undefined reference to `libiconv_close'
nsNativeCharsetUtils.o(.text+0x5c8): In function 
`nsNativeCharsetConverter::GlobalShutdown()':
: undefined reference to `libiconv_close'
nsNativeCharsetUtils.o(.text+0x5e5): In function 
`nsNativeCharsetConverter::GlobalShutdown()':
: undefined reference to `libiconv_close'
nsNativeCharsetUtils.o(.text+0x602): In function 
`nsNativeCharsetConverter::GlobalShutdown()':
:

Re: issue with options DDB

2010-11-11 Thread Alexey Shuvaev 
On Thu, Nov 11, 2010 at 04:18:30PM +, Alexander Best wrote:
 On Wed Nov 10 10, Alexander Best wrote:
  On Wed Nov 10 10, Alexander Best wrote:
   On Tue Nov  9 10, Alexey Shuvaev wrote:
On Tue, Nov 09, 2010 at 06:25:12PM +, Alexander Best wrote:
 On Fri Nov  5 10, Ulrich Spörlein wrote:
  On Sat, 30.10.2010 at 23:22:44 +, Alexander Best wrote:
   hi there,
   
   with options DDB in my kernel conf i run into the following 
   issue with my
   kernel modules:
   
   link_elf_lookup_symbol: missing symbol hash table
   KLD file snd_hda.ko is missing dependencies
   KLD file sound.ko is missing dependencies
   KLD file nvidia.ko is missing dependencies
   KLD file linux.ko is missing dependencies
   KLD file ng_ubt.ko is missing dependencies
   KLD file ng_hci.ko is missing dependencies
   KLD file ng_bluetooth.ko is missing dependencies
   KLD file netgraph.ko is missing dependencies
   link_elf_lookup_symbol: missing symbol hash table
   
   removing the option solves the issue. any advice?
   
   cheers.
   alex
   
   ps: i'm running HEAD (r214542; amd64).
  
  You failed to mention the command that you run. I assume 
  'buildkernel'?
  Please note that you need and update-to-date buildworld for the 
  kernel
  tools to be there, so please try the following (with options DDB):
  
  cd /usr/src
  make clean; make cleandir; make clean
  make buildworld
  make buildkernel KERNCONF=YOURKERNEL
 
 hmmmseems there is a problem with gcc. this is what i get during
 buildworld:
 
 
 clang++ -O2 -pipe -fno-strict-aliasing -funroll-loops -march=native 
 -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H 
 -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcclibs/include 
 -I/usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++ 
 -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcc 
 -I/usr/src/gnu/lib/libsupc++/../libstdc++ -I. 
 -frandom-seed=RepeatabilityConsideredGood -g -fstack-protector 
 -fconserve-space -fno-implicit-templates -ffunction-sections 
 -fdata-sections -c 
 /usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++/tinfo2.cc
 clang++: warning: argument unused during compilation: 
 '-fconserve-space'
^^^

 clang++: warning: argument unused during compilation: 
 '-fno-implicit-templates'
 clang++ -O2 -pipe -fno-strict-aliasing -funroll-loops -march=native 
 -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H 
 -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcclibs/include 
 -I/usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++ 
 -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcc 
 -I/usr/src/gnu/lib/libsupc++/../libstdc++ -I. 
 -frandom-seed=RepeatabilityConsideredGood -g -fstack-protector 
 -fconserve-space -fno-implicit-templates -ffunction-sections 
 -fdata-sections -c 
 /usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++/vec.cc
 clang++: warning: argument unused during compilation: 
 '-fconserve-space'
 clang++: warning: argument unused during compilation: 
 '-fno-implicit-templates'
 clang++ -O2 -pipe -fno-strict-aliasing -funroll-loops -march=native 
 -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H 
 -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcclibs/include 
 -I/usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++ 
 -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcc 
 -I/usr/src/gnu/lib/libsupc++/../libstdc++ -I. 
 -frandom-seed=RepeatabilityConsideredGood -g -fstack-protector 
 -fconserve-space -fno-implicit-templates -ffunction-sections 
 -fdata-sections -c 
 /usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++/vterminate.cc
 clang++: warning: argument unused during compilation: 
 '-fconserve-space'
 clang++: warning: argument unused during compilation: 
 '-fno-implicit-templates'
 clang -O2 -pipe -fno-strict-aliasing -funroll-loops -march=native 
 -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H 
 -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcclibs/include 
 -I/usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++ 
 -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcc 
 -I/usr/src/gnu/lib/libsupc++/../libstdc++ -I. 
 -frandom-seed=RepeatabilityConsideredGood -g -std=gnu99 
 -fstack-protector  -c 
 /usr/src/gnu/lib/libsupc++/../../../contrib/gcclibs/libiberty/cp-demangle.c
 building static supc++ library
 ranlib libsupc++.a
 === gnu/lib/libobjc (all)
 gcc -O2 -pipe -fno-strict-aliasing -funroll-loops -march=native 
 -DHAVE_GTHR_DEFAULT -DIN_GCC -DIN_TARGET_LIBS -I. 
 -I/usr/src/gnu/lib/libobjc/../../usr.bin/cc/cc_tools 
 -I/usr/src/gnu/lib/libobjc/../../../contrib/libobjc/objc 
 -I/usr/src/gnu/lib/libobjc/../../../contrib/libobjc 
 -I/usr/src/gnu/lib/libobjc

Re: issue with options DDB

2010-11-09 Thread Alexey Shuvaev 
On Tue, Nov 09, 2010 at 06:25:12PM +, Alexander Best wrote:
 On Fri Nov  5 10, Ulrich Spörlein wrote:
  On Sat, 30.10.2010 at 23:22:44 +, Alexander Best wrote:
   hi there,
   
   with options DDB in my kernel conf i run into the following issue with 
   my
   kernel modules:
   
   link_elf_lookup_symbol: missing symbol hash table
   KLD file snd_hda.ko is missing dependencies
   KLD file sound.ko is missing dependencies
   KLD file nvidia.ko is missing dependencies
   KLD file linux.ko is missing dependencies
   KLD file ng_ubt.ko is missing dependencies
   KLD file ng_hci.ko is missing dependencies
   KLD file ng_bluetooth.ko is missing dependencies
   KLD file netgraph.ko is missing dependencies
   link_elf_lookup_symbol: missing symbol hash table
   
   removing the option solves the issue. any advice?
   
   cheers.
   alex
   
   ps: i'm running HEAD (r214542; amd64).
  
  You failed to mention the command that you run. I assume 'buildkernel'?
  Please note that you need and update-to-date buildworld for the kernel
  tools to be there, so please try the following (with options DDB):
  
  cd /usr/src
  make clean; make cleandir; make clean
  make buildworld
  make buildkernel KERNCONF=YOURKERNEL
 
 hmmmseems there is a problem with gcc. this is what i get during
 buildworld:
 
 
 clang++ -O2 -pipe -fno-strict-aliasing -funroll-loops -march=native 
 -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H 
 -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcclibs/include 
 -I/usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++ 
 -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcc 
 -I/usr/src/gnu/lib/libsupc++/../libstdc++ -I. 
 -frandom-seed=RepeatabilityConsideredGood -g -fstack-protector 
 -fconserve-space -fno-implicit-templates -ffunction-sections -fdata-sections 
 -c /usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++/tinfo2.cc
 clang++: warning: argument unused during compilation: '-fconserve-space'
^^^

 clang++: warning: argument unused during compilation: 
 '-fno-implicit-templates'
 clang++ -O2 -pipe -fno-strict-aliasing -funroll-loops -march=native 
 -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H 
 -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcclibs/include 
 -I/usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++ 
 -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcc 
 -I/usr/src/gnu/lib/libsupc++/../libstdc++ -I. 
 -frandom-seed=RepeatabilityConsideredGood -g -fstack-protector 
 -fconserve-space -fno-implicit-templates -ffunction-sections -fdata-sections 
 -c /usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++/vec.cc
 clang++: warning: argument unused during compilation: '-fconserve-space'
 clang++: warning: argument unused during compilation: 
 '-fno-implicit-templates'
 clang++ -O2 -pipe -fno-strict-aliasing -funroll-loops -march=native 
 -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H 
 -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcclibs/include 
 -I/usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++ 
 -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcc 
 -I/usr/src/gnu/lib/libsupc++/../libstdc++ -I. 
 -frandom-seed=RepeatabilityConsideredGood -g -fstack-protector 
 -fconserve-space -fno-implicit-templates -ffunction-sections -fdata-sections 
 -c 
 /usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++/vterminate.cc
 clang++: warning: argument unused during compilation: '-fconserve-space'
 clang++: warning: argument unused during compilation: 
 '-fno-implicit-templates'
 clang -O2 -pipe -fno-strict-aliasing -funroll-loops -march=native 
 -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H 
 -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcclibs/include 
 -I/usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++ 
 -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcc 
 -I/usr/src/gnu/lib/libsupc++/../libstdc++ -I. 
 -frandom-seed=RepeatabilityConsideredGood -g -std=gnu99 -fstack-protector  -c 
 /usr/src/gnu/lib/libsupc++/../../../contrib/gcclibs/libiberty/cp-demangle.c
 building static supc++ library
 ranlib libsupc++.a
 === gnu/lib/libobjc (all)
 gcc -O2 -pipe -fno-strict-aliasing -funroll-loops -march=native 
 -DHAVE_GTHR_DEFAULT -DIN_GCC -DIN_TARGET_LIBS -I. 
 -I/usr/src/gnu/lib/libobjc/../../usr.bin/cc/cc_tools 
 -I/usr/src/gnu/lib/libobjc/../../../contrib/libobjc/objc 
 -I/usr/src/gnu/lib/libobjc/../../../contrib/libobjc 
 -I/usr/src/gnu/lib/libobjc/../../../contrib/gcc/config 
 -I/usr/src/gnu/lib/libobjc/../../../contrib/gcc 
 -I/usr/src/gnu/lib/libobjc/../../../contrib/gcclibs/include -fexceptions 
 -frandom-seed=RepeatabilityConsideredGood -g -std=gnu99 -fstack-protector  -c 
 /usr/src/gnu/lib/libobjc/../../../contrib/libobjc/archive.c
 *** Signal 11
 
 Stop in /usr/src/gnu/lib/libobjc.
 *** Error code 1
 
 Stop in /usr/src/gnu/lib.
 *** Error code 1
 
 Stop in /usr/src.
 *** Error code 1
 
 Stop in /usr/src.
 *** Error code 1
 
 Stop in /usr/src.
 *** Error code 1
 
 Stop in /usr/src.
 
 
 i've ran buildworld twice (with a clean /usr/src and non-existing /usr/obj/*)

Re: Setting up IPv6 in /etc/rc.conf

2010-10-15 Thread Alexey Shuvaev 
On Fri, Oct 15, 2010 at 07:04:47PM +0100, Mark Murray wrote:
 Hi
 
 IPv6 gurus: what are the CURRENT /etc/rc.conf incantations to do the
 following (which works):
 
 $ ifconfig gif0 create
 $ ifconfig gif0 tunnel 192.168.0.2 11.22.33.44
 $ ifconfig gif0 inet6 2001:::::2 2001:::::1 prefixlen 
 128
 $ route -n add -inet6 default 2001:::::1
 $ ifconfig gif0 up
 
 ... when my non-working setup in /etc/rc.conf contains
 
 gif_interfaces=gif0
 gifconfig_gif0=192.168.0.2 11.22.33.44
 gifconfig_gif0_ipv6=2001:::::2 2001:::::1 prefixlen 
 128
   
I suppose you should prefix it with inet6 keyword.
There are 2 examples in rc.conf (search for Sample IPv6).

 ipv6_defaultrouter=-inet6 default 2001:::::1
 
 ... which used to work. The bit that fails is the bit where gif0 gets
 its tunnel IPv6 addresses.  I've tried both gifconfig_gif0_ipv6=...
 and ifconfig_gif0_ipv6= The IPv6 endmpoints never make it onto
 gif0.
 
 This used to work, but setting up IPv6 in CURRENT is a moving
 target, and I can't find a working example any more. I've looked in
 /etc/defaults/rc.conf, but the gifN examples there are all devoid of any
 IPv6 examples.
 
HTH,
Alexey.
___
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: tput clear/vi breakage on console

2010-09-22 Thread Alexey Shuvaev 
On Wed, Sep 22, 2010 at 01:58:31PM -0700, Pyun YongHyeon wrote:
 Hi,
 
 It seems tput clear on console wipes out entire screen without
 even showing a shell prompt. The only way I get characters is to
 enter enter key. I'm under the impression that the first line of
 console output is not displayed at all after tput clear command.
 Another thing I noticed is vi also does not show the first line
 of a file. Any idea?

Seems to work fine for me both in xterm and in the text console.

~ uname -a
FreeBSD wep4035 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r212998: Wed Sep 22 16:28:09 
CEST 2010 r...@wep4035:/usr/obj/usr/src/sys/GENERIC  amd64

[In xterm]
~ locale
LANG=en_US.UTF-8
LC_CTYPE=en_US.UTF-8
LC_COLLATE=en_US.UTF-8
LC_TIME=en_US.UTF-8
LC_NUMERIC=C
LC_MONETARY=en_US.UTF-8
LC_MESSAGES=C
LC_ALL=

[In text console]
# locale
LANG=
LC_CTYPE=C
LC_COLLATE=C
LC_TIME=C
LC_NUMERIC=C
LC_MONETARY=C
LC_MESSAGES=C
LC_ALL=

The 'cl' capability from the xterm session (part of TERMCAP):
cl=\E[H\E[2J

HTH,
Alexey.
___
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: bsdgrep does not work with tail -f | grep combination

2010-08-04 Thread Alexey Shuvaev 
On Wed, Aug 04, 2010 at 06:28:10PM +0200, Lars Engels wrote:
 On Wed, Aug 04, 2010 at 10:51:08AM -0400, Alexandre Sunny Kovalenko wrote:
  On Tue, 2010-08-03 at 20:21 +0200, Gabor Kovesdan wrote:
   Em 2010.08.03. 19:25, poyop...@puripuri.plala.or.jp escreveu:
Hi,
   
It seems bsdgrep does not work when piped from tail -f.
I'm running r210728.
   
term0$ jot 10  /tmp/1
term0$ tail -f /tmp/1 | grep 0
[no output]
   
otherterm$ jot 10  /tmp/1
[no output to term0]
   
=
   
with GNU grep:
   
term0$ tail -f /tmp/1 | gnugrep 0
10
otherterm$ jot 10  /tmp/1
[on term0]
10
10
   
   I've checked on 8.0 and GNU grep doesn't output anything either for me. 
   If you use tail -f, you will enter more lines and end it with EOF, won't 
   you? And then BSD grep will process the input and print out matches. I 
   don't think it's bad behaviour in itself but if you can explain why you 
   think it's bad I'm willing to change it.
   
  I am not sure it is specific to the GNU grep -- below is the example
  from AIX 5.3:
 
 [...]
 
 Same on Solaris, so this is not a GNU feature.

Just to clarify things, bsdgrep of course works with tail -f,
the data just sits in its buffer:

~ jot 10  test
~ tail -f test | grep 0

[on another terminal]

~ jot 10  test

[nothing happens on original terminal]

~ jot 4000  test

[on the original terminal]

10
10
10
20
30
40
50
60
70
80
90
100
101
102
103
[snip]
3950
3960
3970
3980
3990
4000

Alexey.
___
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

dc(1) -e 6 2 / p is still broken as of r207919

2010-05-12 Thread Alexey Shuvaev 
Hello!

Just to remind that still:

~ dc -e 6 2 / p
Segmentation fault (core dumped)

This was already mentioned on this list:
http://lists.freebsd.org/pipermail/freebsd-current/2010-April/016560.html
and there is a patch proposed in the same thread:
http://lists.freebsd.org/pipermail/freebsd-current/2010-April/016603.html

Note, however, that reverting r203438 also fixes the problem (gabor@ CC-ed),
so I'm not sure what is the right way to fix it.
Attached is slightly modified reverse patch to revert 203438.

Thanks,
Alexey.
--- dc.c2010/01/20 21:30:52 202719
+++ dc.c2010/02/03 19:13:41 203438
@@ -82,15 +82,7 @@
 {
int ch;
bool extended_regs = false, preproc_done = false;
-   char*buf;
 
-   if ((buf = strdup()) == NULL)
-   err(1, NULL);
-
-   init_bmachine(extended_regs);
-   setlinebuf(stdout);
-   setlinebuf(stderr);
-
/* accept and ignore a single dash to be 4.4BSD dc(1) compatible */
while ((ch = getopt_long(argc, argv, e:f:Vx, long_options, NULL)) != 
-1) {
switch (ch) {
@@ -123,6 +115,10 @@
argc -= optind;
argv += optind;
 
+   init_bmachine(extended_regs);
+   setlinebuf(stdout);
+   setlinebuf(stderr);
+
if (argc  1)
usage();
if (argc == 1) {
___
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

Addition of lzma/xz compression to HEAD

2010-05-11 Thread Alexey Shuvaev 
Hello!

Just FYI: noticed addition of lzma directory to BSD.include.dist mtree file.
Well, now it seems to work!

/* Test file size 264 MiB */
[wep4035] ~ ll /usr/local/tinderbox/jails/9-amd64/9-amd64.tar 
-rw-r--r--  1 root  wheel  277209600 Apr 20 20:58 
/usr/local/tinderbox/jails/9-amd64/9-amd64.tar

/* Cache file in memory */
[wep4035] ~ cat /usr/local/tinderbox/jails/9-amd64/9-amd64.tar  
/dev/null

/* 30 seconds to gzip it */
[wep4035] ~ time tar -cvzf 9-amd64.tar.tar.gz 
/usr/local/tinderbox/jails/9-amd64/9-amd64.tar 
tar: Removing leading '/' from member names
a usr/local/tinderbox/jails/9-amd64/9-amd64.tar
30.043u 0.541s 0:15.32 199.6%   37+2093k 0+747io 0pf+0w

/* 64 seconds to bzip2 it */
[wep4035] ~ time tar -cvjf 9-amd64.tar.tar.bz2 
/usr/local/tinderbox/jails/9-amd64/9-amd64.tar
tar: Removing leading '/' from member names
a usr/local/tinderbox/jails/9-amd64/9-amd64.tar
63.454u 0.686s 0:32.09 199.8%   37+2108k 0+650io 1pf+0w

/* And 140 seconds to xz it */
[wep4035] ~ time tar -cvJf 9-amd64.tar.tar.xz 
/usr/local/tinderbox/jails/9-amd64/9-amd64.tar
tar: Removing leading '/' from member names
a usr/local/tinderbox/jails/9-amd64/9-amd64.tar
277.625u 0.857s 2:19.26 199.9%  37+2092k 0+432io 0pf+0w

/* Resulting sizes : */
[wep4035] ~ ll 9-amd64.tar.tar.*
-rw-r--r--  1 lexx  lexx  84830128 May 11 21:07 9-amd64.tar.tar.bz2
-rw-r--r--  1 lexx  lexx  97667581 May 11 21:07 9-amd64.tar.tar.gz
-rw-r--r--  1 lexx  lexx  56366908 May 11 21:10 9-amd64.tar.tar.xz

/* 3.5 seconds to gunzip the file (mostly IO-limited) */
[wep4035] ~ cat 9-amd64.tar.tar.gz  /dev/null 
[wep4035] ~ time tar -xvf 9-amd64.tar.tar.gz 
x usr/local/tinderbox/jails/9-amd64/9-amd64.tar
2.721u 0.747s 0:03.54 97.7% 42+2365k 3+2116io 0pf+0w
[wep4035] ~ rm -R usr/

/* 18 seconds to bunzip2 it */
[wep4035] ~ cat 9-amd64.tar.tar.bz2  /dev/null
[wep4035] ~ time tar -xvf 9-amd64.tar.tar.bz2 
x usr/local/tinderbox/jails/9-amd64/9-amd64.tar
18.136u 0.999s 0:09.59 199.3%   37+2110k 1+2116io 0pf+0w
[wep4035] ~ rm -R usr/

/* And only 10 seconds to xzdec it */
[wep4035] ~ cat 9-amd64.tar.tar.xz  /dev/null
[wep4035] ~ time tar -xvf 9-amd64.tar.tar.xz
x usr/local/tinderbox/jails/9-amd64/9-amd64.tar
10.304u 0.771s 0:05.59 198.0%   38+2164k 3+2116io 0pf+0w
[wep4035] ~ rm -R usr/


Thanks to all involved in bringing it to HEAD!

Alexey.

P.S. I'm not claiming any statistical validity of provided timings nor
that the testing procedure is correct. It is just to show that tar in HEAD
now works with lzma/xz compression.
___
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: Ruby w/clang (Was: Re: [CFT]: ClangBSD is selfhosting, we need testers now)

2010-04-28 Thread Alexey Shuvaev 
On Thu, Apr 29, 2010 at 02:40:24AM +1100, Dima Panov wrote:
 On Wednesday 28 April 2010 23:16:38 Ollivier Robert wrote:
  According to Dima Panov:
   while building lang/ruby18:
  Which options to you use?
  
  _OPTIONS_READ=ruby+oniguruma-1.8.7.248_1,1
  WITHOUT_ONIGURUMA=true
  WITH_RDOC=true
  WITHOUT_DEBUG=true
  
  I notice your ruby is compiling w/o any -On, try with -O at least?
 
 same here. also on 1.8.7.249 snapshot.
 
 ar rcu libruby18-static.a array.o  bignum.o  class.o  compar.o  dir.o  dln.o  
 enum.o  
 enumerator.o  error.o  eval.o  file.o  gc.o  hash.o  inits.o  io.o  marshal.o 
  math.o  
 numeric.o  object.o  pack.o  parse.o  process.o  prec.o  random.o  range.o  
 re.o  regex.o  
 ruby.o  signal.o  sprintf.o  st.o  string.o  struct.o  time.o  util.o  
 variable.o  
 version.o   dmyext.o
 clang -I/usr/include -O2 -fno-strict-aliasing -pipe -std=gnu89  -fPIC
 -DRUBY_EXPORT -I. 
 -I. -I/usr/include-c main.c
 clang -I/usr/include -O2 -fno-strict-aliasing -pipe -std=gnu89  -fPIC
 -DRUBY_EXPORT -L.  
 -rpath=/usr/lib:/usr/local/lib -pthread -rdynamic  -pthread main.o  
 libruby18-static.a -
 lrt -lcrypt -lm -L/usr/lib  -rpath=/usr/lib:/usr/local/lib -pthread  -o 
 miniruby
 ./lib/fileutils.rb:1437: [BUG] unexpected local variable assignment
 ruby 1.8.7 (2010-01-10 patchlevel 249) [amd64-freebsd9]
 
 *** Signal 6
 
 Stop in /tmp/usr/ports/lang/ruby18/work/ruby-1.8.7-p249.
 *** Error code 1
 
 
 _OPTIONS_READ=ruby-1.8.7.249,1
 WITHOUT_ONIGURUMA=true
 WITH_RDOC=true
 WITHOUT_DEBUG=true
 
 
  
   clang -I/usr/include -pipe -g -g -std=gnu89  -fPIC-DRUBY_EXPORT -I.
   -I. -I/usr/include -c main.c
   clang -I/usr/include -pipe -g -g -std=gnu89  -fPIC-DRUBY_EXPORT -L. 
   - rpath=/usr/lib:/usr/local/lib -pthread -rdynamic  -pthread main.o 
   libruby18-static.a -lrt -lcrypt -lm -L/usr/lib 
   -rpath=/usr/lib:/usr/local/lib -pthread  -o miniruby
   ./lib/fileutils.rb:1429: fu_same? is not a class/module (TypeError)
   
   from ./mkconfig.rb:11:in `require'
   from ./mkconfig.rb:11
   
   *** Error code 1
  
  Interesting, using a fairly recent clang snapshot from trunk, I get a sig11
  :(
 
 
 Ruby is bad?
 
For the record, ruby compilation also fails with base gcc inside
i386 ports tinderbox on amd64-CURRENT host:

[snip]
cc -I/usr/include -O2 -pipe -fno-strict-aliasing  -fPIC-DRUBY_EXPORT -I. 
-I. -I/usr/include-c variable.c
cc -I/usr/include -O2 -pipe -fno-strict-aliasing  -fPIC-DRUBY_EXPORT -I. 
-I. -I/usr/include-c version.c
In file included from version.c:14:
version.h:29:41: warning: no newline at end of file
cc -I/usr/include -O2 -pipe -fno-strict-aliasing  -fPIC-DRUBY_EXPORT -I. 
-I. -I/usr/include-c dmyext.c
ar rcu libruby18-static.a array.o  bignum.o  class.o  compar.o  dir.o  dln.o  
enum.o  enumerator.o  error.o  eval.o  file.o  gc.o  hash.o  inits.o  io.o  
marshal.o  math.o  numeric.o  object.o  pack.o  parse.o  process.o  prec.o  
random.o  range.o  re.o  regex.o  ruby.o  signal.o  sprintf.o  st.o  string.o  
struct.o  time.o  util.o  variable.o  version.o   dmyext.o
cc -I/usr/include -O2 -pipe -fno-strict-aliasing  -fPIC-DRUBY_EXPORT -I. 
-I. -I/usr/include-c main.c
cc -I/usr/include -O2 -pipe -fno-strict-aliasing  -fPIC-DRUBY_EXPORT -L.  
-rpath=/usr/lib:/usr/local/lib -pthread -rdynamic  -pthread main.o  
libruby18-static.a -lrt -lcrypt -lm -L/usr/lib  -rpath=/usr/lib:/usr/local/lib 
-pthread  -o miniruby
./lib/fileutils.rb:1030: retry outside of rescue clause
rbconfig.rb updated
*** Error code 1

Stop in /work/a/ports/lang/ruby18/work/ruby-1.8.7-p248.
*** Error code 1

Stop in /a/ports/lang/ruby18.

build of /usr/ports/lang/ruby18 ended at Sat Apr 24 04:57:59 UTC 2010

I don't know why it is failing in the same file (is it just included first
or is it really troublesome?), but it looks quite suspicious.
I am nowhere the ruby expert but it may be that the problem is in ruby itself.
Note, that I have successfully built quite a lot of packages inside
this i386 tinderbox on amd64 host including full kde4, openoffice3, jdk16,
virtualbox-ose, mplayer, ...

On the topic, if I understand it correctly, one can build clandbsd branch
with normal gcc from base, so it is backward compatible.
What are the general showstoppers then to merge to HEAD
the part of clangbsd that allows building HEAD with llvm from ports?
I think this will significantly increase the number of testers...

Alexey.
___
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: Can not boot after r203503. Unable to open /dev/ada(1/2)p3 for writing

2010-02-26 Thread Alexey Shuvaev 
On Fri, Feb 26, 2010 at 02:47:06PM +, Paul Wootton wrote:
 Hi,
 
 I have an unusual problem. Last night I tried updating from my
 old-ish kernel/world to an up to date version. I had been using
 202500-ish successfully. I can build and install the newer world and
 kernel fine, but when I reboot I get the following
 
 Trying to mount root from zfs:raid250/root
 ZFS WARNING: Unable to open /dev/ada1p3 for writing (error=1). ZFS
 WARNING: Unable to open /dev/ada2p3 for writing (error=1). ROOT
 MOUNT ERROR.
 If you have invalid mount options, reboot, and first try the
 following from the loader prompt:
set vfs.root.mountfrom.options=rw
 and then remove the invalid options from /etc/fstab
 loader variables:
vfs.root.mountfrom=zfs:raid250/root
vfs.root.mountfrom.options=rw
 
 
 Im using 2 drives in a ZFS mirror configuration (ada1 and ada2
 making raid250)
 
 I tried going back over the older revisions, and the last kernel
 that I can build and boot is 203503. It seems the changes in 203504
 are what cause me the problems.
 
 Now for the weird bit, I took a friends kernel (204324) and that
 boots fine. I pulled his kernel configuration and built against that
 (I had decided to remake my kernel configuration just before I tried
 updating). Still I get the same error. I have checked my
 /etc/make.conf and that looks right.
 
 I attached my /etc/fstab and /etc/make.conf. Im using  an Intel
 Q8300 running amd64.
 
 Anyone have any ideas? This is my work computer, so unfortunately I
 wont have access to it over the weekend but will be able to give
 more information if required on monday
 
 Cheers
 
 Paul
 

 # DeviceMountpoint  FStypeOptions DumpPass#
 raid250/root  /   zfs rw  0   0
 raid250/usr   /usrzfs rw  0   0
 raid250/var   /varzfs rw  0   0
 raid250/tmp   /tmpzfs rw,noatime  0   0
 /dev/ada1p2   noneswapsw  0   0
 /dev/ada2p2   noneswapsw  0   0
 linproc   /usr/compat/linux/proc linprocfs rw 0   0

 CPUTYPE?=core2
 
 CFLAGS= -msse3 -mmmx -O2 -fno-strict-aliasing -pipe -s
^^^
Are you sure you are allowed to use these flags to compile the kernel?
I would try removing this line completely.

 CXXFLAGS+= -fconserve-space
 
 #CFLAGS= -march=native  -O2  -fno-strict-aliasing -pipe -s
 #CXXFLAGS+= -fconserve-space -fpermissive -Wl,-rpath-link,/usr/local/lib/gcc44
 #CC=gcc44
 #CXX=g++44
 #NO_CPU_CFLAGS= # Don't add -march=cpu to CFLAGS automatically
 #NO_CPU_COPTFLAGS=  # Don't add -march=cpu to COPTFLAGS automatically
 
 
 KERNCONF=DEMOPHON
 
 MAKE_IDEA=YES
 BATCH=YES
 WITH_JADETEX=YES
 
 LOADER_ZFS_SUPPORT=YES
 # added by use.perl 2009-07-20 19:58:21
 PERL_VERSION=5.8.9
___
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: Virtualbox

2010-02-23 Thread Alexey Shuvaev 
On Tue, Feb 23, 2010 at 06:20:22PM +0200, Ian FREISLICH wrote:
 Hi
 
 Has anyone managed to make Virtualbox work on 9-Current?  Since
 installing 3.1.2-OSE VMs, all brand new, abort on startup.
 
 The last part of the log seems pertinent:
 
 00:00:15.481 !!Assertion Failed!!
 00:00:15.481 Expression: paPages[i].Phys != 0  paPages[i].Phys != 
 NIL_RTHCPHYS  !(paPages[i].Phys  PAGE_OFFSET_MASK)
 00:00:15.481 Location  : 
 /usr/ports/emulators/virtualbox-ose/work/VirtualBox-3.1.2_OSE/src/VBox/VMM/MMHyper.cpp(610)
  int MMR3HyperMapPages(VM*, void*, RTR0PTR, size_t, const SUPPAGE*, const 
 char*, RTGCPTR64*)
 00:00:15.482 i=0x0 Phys= Heap
 
 Does anyone have any ideas?
 
Me not.
Just FYI:

~ VBoxManage startvm WinXP --type sdl
VirtualBox Command Line Management Interface Version 3.1.2_OSE
(C) 2005-2009 Sun Microsystems, Inc.
All rights reserved.

Waiting for the remote session to open...
Remote session has been successfully opened.

~ uname -a
FreeBSD wep4035 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r202285: Thu Jan 14 19:04:21 
CET 2010 r...@wep4035:/usr/obj/usr/src/sys/GENERIC  amd64

~ sysctl vm.pmap.pg_ps_enabled
vm.pmap.pg_ps_enabled: 1

~ cat /boot/loader.conf
loader_logo=beastie
ichsmb_load=YES
snd_hda_load=YES
speaker_load=YES
i915_load=YES
linux_load=YES
vboxdrv_load=YES

The virtial machine was newly created and installed already on this CURRENT.

0.02$,
Alexey.
___
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