Re: bsnmpd always died on HDD detach

[Mikolaj Golub]

On Wed, Sep 12, 2012 at 10:39:12AM +0200, Miroslav Lachman wrote:

> (gdb) bt
> #0  0x000801046cba in disk_query_disk (entry=0x0) at 
> hostres_diskstorage_tbl.c:241
> #1  0x000801dd6a00 in ?? ()
> #2  0x000801dd6600 in ?? ()
> #3  0x in ?? ()
> #4  0x000801048230 in device_entry_create (name=0x0, 
> location=0x800c14ee0 "0", descr=0x8010482a6 "") at hostres_device_tbl.c:217
> #5  0x000801dd7800 in ?? ()
> #6  0x000801dd7800 in ?? ()
> #7  0x000801dd7400 in ?? ()
> #8  0x in ?? ()
> #9  0x000801048230 in device_entry_create (name=0x801dd7c00 "", 
> location=0x801048230 "˙˙I\213|$8čŕ\201˙˙L\211çčŘ\201˙˙é\035ţ˙˙H\215\025",
>  descr=0x8010482a6 "") at hostres_device_tbl.c:217
> #10 0x000801dd4a00 in ?? ()
> #11 0x000801dd4a00 in ?? ()
> #12 0x000801dd1a00 in ?? ()
> #13 0x in ?? ()
> #14 0x000801048230 in device_entry_create (name=0x801dd8400 "", 
> location=0x801048230 "˙˙I\213|$8čŕ\201˙˙L\211çčŘ\201˙˙é\035ţ˙˙H\215\025",
>  descr=0x8010482a6 "") at hostres_device_tbl.c:217
> #15 0x000801dd1800 in ?? ()
> #16 0x000801dd1800 in ?? ()
> #17 0x000800c00ea8 in ?? ()
> #18 0x0051b1c8 in ?? ()
> #19 0x000800c00938 in ?? ()
> #20 0x0051b258 in ?? ()
> #21 0x000801dc8a00 in ?? ()
> #22 0x0008009f7be9 in free () from /lib/libc.so.7
> #23 0x in ?? ()
> #24 0x7fffed98 in ?? ()
> #25 0x0008010478bd in device_entry_delete () at hostres_device_tbl.c:266
> #26 0x005187d0 in snmp_error ()
> #27 0x000801047be6 in op_hrDeviceTable (ctx=Variable "ctx" is not 
> available.
> ) at hostres_device_tbl.c:671
> #28 0x0051b840 in ?? ()
> #29 0x0051b830 in ?? ()
> #30 0x in ?? ()
> #31 0x7fffc360 in ?? ()
> #32 0x0051b830 in ?? ()
> #33 0x in ?? ()
> #34 0x0008009efbd2 in _pthread_mutex_init_calloc_cb () from 
> /lib/libc.so.7
> #35 0x0008009f2d32 in _malloc_prefork () from /lib/libc.so.7
> #36 0x0008009f6e1f in realloc () from /lib/libc.so.7
> #37 0x000800e0b441 in mib_if_is_dyn () from /usr/lib/snmp_mibII.so
> #38 0x in ?? ()
> #39 0x7fffc5cc in ?? ()
> #40 0x0001 in ?? ()
> #41 0x7fffc5e0 in ?? ()
> #42 0x31fa39e2fac72819 in ?? ()
> #43 0x0001 in ?? ()
> #44 0x00080065fad5 in poll_dispatch () from /lib/libbegemot.so.4
> #45 0x0040616a in main ()
> 
> 
> I hope it helps you to debug this problem.

Looks like we can't trust to this output.

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

GEOM_RAID in GENERIC is harmful

[Eugene Grosbein]

Hi!

9-STABLE has got options GEOM_RAID in GENERIC.
In real world, this change is pretty harmful and there are lots of cases
when 9.0-RELEASE systems upgraded to 9-STABLE fail to mount root UFS filesystem
or attach ZFS.

It seems, there are lots of HDDs supplied with pseudo-RAID labels at the end:
pre-installed Windows machined having motherboards with pseudo-RAID
like Intel RapidStore and alike. One can not even be aware of these labels.

9.0-RELEASE can be installed on such HDDs and use them with GMIRROR or ZFS
without a problem. Upgraded to 9-STABLE, such system fails to build due
to GRAID jumping out of box and grabbing HDDs for itself,
so GMIRROR or ZFS got broken.

That's makes users very angry when production server fails to boot
with GENERIC kernel after correctly performed upgrade.

GEOM_RAID compiled in GENERIC should be deactivated and require activation
with some loader knob. Also, we need distinct RELEASE NOTES warning about the 
issue.

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

Re: Issue with igb and lagg (was Re: Problem with link aggregation + sshd)

[Sean Bruno]

> > igb+lagg worked for us on 8.3.  Haven't tried it since moving to 9.0
> > and 9-STABLE on those three boxes.
> >
> > igb+lagg doesn't work for him on 9.0.  Although, I don't recall if
> > non-LACP options were tried earlier in this thread, or if it's just
> > the LACP mode that's failing.  If one mode works (say failover) and
> > LACP mode doesn't, that "seems to" point to lagg.
> >
> > I'll see if I can free up an igb port on my 9.0 and 9-STABLE boxes to
> > test this with as well.
> >
> >
> 
> I wouldn't use 9.0, go with 9.1 RC or whatever has the latest igb code,
> if you see the issue there I can see about getting some time to look into
> it here.
> 
> Jack


We're running igb + lagg on two interfaces here at Yahoo without issues
like this.  We're using LACP exclusively with Cisco switches.  If you're
seeing failover issues, I wonder if its the switch you're using as
opposed to the host and ethernet card?  Just a shot in the dark here.


Sean

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

Re: A BSD-licensed internationalization solution?

[Jan Beich]

Zhihao Yuan  writes:

>>
>> Here are many applications using GNU gettext to provide an
>> internationalized user interface. But I found that there isn't a
>> BSD-licensed gettext. (so BSD apps do not have internationalization?)
>>
>> Is there one? Then I can just switch from gettext to that.
>
> libintl is LGPL, we don't have license issues against it.

There is BSD licensed libintl, though. It seems to work fine with GPL
gettext/msgfmt tools and no recompilation (libmap.conf trick).

# grep for "citrus"
http://www.netbsd.org/docs/software/3rdparty/

Index: lib/Makefile
===
--- lib/Makefile	(revision 240180)
+++ lib/Makefile	(working copy)
@@ -37,6 +37,7 @@ SUBDIR_ORDERED=	${_csu} \
 	libcrypt \
 	libelf \
 	${_libiconv_modules} \
+	${_libintl} \
 	libkvm \
 	msun \
 	libmd \
@@ -166,6 +167,7 @@ _librpcsec_gss=	librpcsec_gss
 
 .if ${MK_ICONV} != "no"
 _libiconv_modules=	libiconv_modules
+_libintl=	libintl
 .endif
 
 .if ${MK_IPX} != "no"
Index: lib/libc/iconv/Symbol.map
===
--- lib/libc/iconv/Symbol.map	(revision 240180)
+++ lib/libc/iconv/Symbol.map	(working copy)
@@ -39,6 +39,7 @@ FBSDprivate_1.0 {
 	_citrus_bcs_strtoul;
 	_citrus_bcs_tolower;
 	_citrus_bcs_toupper;
+	_citrus_bcs_trunc_rws_len;
 	_citrus_bcs_trunc_ws_len;
 	_citrus_csmapper_open;
 	_citrus_csmapper_close;
Index: lib/libintl/Makefile
===
RCS file: /cvsroot/src/lib/libintl/Makefile,v
retrieving revision 1.6
diff -u -p -r1.6 Makefile
--- lib/libintl/Makefile	14 May 2005 17:58:56 -	1.6
+++ lib/libintl/Makefile	9 Sep 2012 03:46:47 -
@@ -1,15 +1,13 @@
 #	$NetBSD: Makefile,v 1.6 2005/05/14 17:58:56 tshiozak Exp $
 
-.include 
-
 LIB=	intl
+SHLIB_MAJOR=	1
 SRCS=	gettext.c textdomain.c gettext_iconv.c gettext_dummy.c strhash.c \
 	sysdep.c plural_parser.c
 INCS=	libintl.h
-INCSDIR=/usr/include
+CFLAGS+=-I${.CURDIR} -I${.CURDIR}/../libc
 
-#CFLAGS+=-g
-CPPFLAGS+=-I${.CURDIR} -I${.CURDIR}/../libc
+NO_WCAST_ALIGN.clang=
 
 MAN=	gettext.3
 MLINKS=	gettext.3 dgettext.3 gettext.3 dcgettext.3 \
Index: lib/libintl/gettext.c
===
RCS file: /cvsroot/src/lib/libintl/gettext.c,v
retrieving revision 1.28
diff -u -p -r1.28 gettext.c
--- lib/libintl/gettext.c	30 Jul 2012 23:04:42 -	1.28
+++ lib/libintl/gettext.c	9 Sep 2012 03:46:47 -
@@ -290,7 +290,9 @@ validate(void *arg, struct mohandle *moh
 static __inline uint32_t
 calc_collision_step(uint32_t hashval, uint32_t hashsize)
 {
-	_DIAGASSERT(hashsize>2);
+#ifdef DIAGNOSTIC
+	assert(hashsize > 2);
+#endif
 	return (hashval % (hashsize - 2)) + 1;
 }
 
@@ -856,7 +856,7 @@ get_indexed_string(const char *str, size
 }
 
 #define	_NGETTEXT_DEFAULT(msgid1, msgid2, n)	\
-	((char *)__UNCONST((n) == 1 ? (msgid1) : (msgid2)))
+	__DECONST(char *, (n) == 1 ? (msgid1) : (msgid2))
 
 char *
 dcngettext(const char *domainname, const char *msgid1, const char *msgid2,
@@ -970,7 +970,7 @@ found:
 		msgid = v;
 	}
 
-	return (char *)__UNCONST(msgid);
+	return __DECONST(char *, msgid);
 
 fail:
 	return _NGETTEXT_DEFAULT(msgid1, msgid2, n);
Index: lib/libintl/gettext_iconv.c
===
RCS file: /cvsroot/src/lib/libintl/gettext_iconv.c,v
retrieving revision 1.8
diff -u -p -r1.8 gettext_iconv.c
--- lib/libintl/gettext_iconv.c	18 Feb 2009 13:08:22 -	1.8
+++ lib/libintl/gettext_iconv.c	9 Sep 2012 05:57:56 -
@@ -55,7 +55,7 @@ static void *cacheroot;
 
 /* ARGSUSED1 */
 static const struct cache *
-cache_find(const char *msg, struct domainbinding *db)
+cache_find(const char *msg, struct domainbinding *db __unused)
 {
 	struct cache key;
 	struct cache **c;
Index: lib/libintl/libintl.h
===
RCS file: /cvsroot/src/lib/libintl/libintl.h,v
retrieving revision 1.4
diff -u -p -r1.4 libintl.h
--- lib/libintl/libintl.h	14 Oct 2011 22:42:01 -	1.4
+++ lib/libintl/libintl.h	9 Sep 2012 03:46:47 -
@@ -31,6 +31,16 @@
 
 #include 
 
+#define gettext libintl_gettext
+#define dgettext libintl_dgettext
+#define dcgettext libintl_dcgettext
+#define ngettext libintl_ngettext
+#define dngettext libintl_dngettext
+#define dcngettext libintl_dcngettext
+#define textdomain libintl_textdomain
+#define bindtextdomain libintl_bindtextdomain
+#define bind_textdomain_codeset libintl_bind_textdomain_codeset
+
 __BEGIN_DECLS
 char *gettext(const char *) __format_arg(1);
 char *dgettext(const char *, const char *) __format_arg(2);
Index: lib/libintl/plural_parser.c
===
RCS file: /cvsroot/src/lib/libintl/plural_parser.c,v
retrieving revision 1.2
diff -u -p -r1.2 plural_parser.c
--- lib/libintl/plural_parser.c	17 Jan 2007 23:24:22 -	1.2
+++ lib/libintl/plural_parser.c	9 Sep 2012 03:46:48 -
@@ -34,10

Re: Issue with igb and lagg (was Re: Problem with link aggregation + sshd)

[Jack Vogel]

On Wed, Sep 12, 2012 at 1:51 PM, Freddie Cash  wrote:

> On Wed, Sep 12, 2012 at 1:48 PM, Jack Vogel  wrote:
> > On Wed, Sep 12, 2012 at 12:40 PM, Freddie Cash 
> wrote:
> >> Thanks for checking.  I've used lagg(4) with igb, just not on 9.x.
> >>
> >> You're right, it seems to be pointing to the igb(4) driver in 9.x
> >> compared to < 9.0.
> >>
> > How do you determine that since it doesn't happen without lagg?  I've no
> > reports of igb hanging otherwise and its being used extensively.
>
> Well, I did say "seems to".  :)
>
> igb+lagg worked for us on 8.3.  Haven't tried it since moving to 9.0
> and 9-STABLE on those three boxes.
>
> igb+lagg doesn't work for him on 9.0.  Although, I don't recall if
> non-LACP options were tried earlier in this thread, or if it's just
> the LACP mode that's failing.  If one mode works (say failover) and
> LACP mode doesn't, that "seems to" point to lagg.
>
> I'll see if I can free up an igb port on my 9.0 and 9-STABLE boxes to
> test this with as well.
>
>

I wouldn't use 9.0, go with 9.1 RC or whatever has the latest igb code,
if you see the issue there I can see about getting some time to look into
it here.

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

Re: Issue with igb and lagg (was Re: Problem with link aggregation + sshd)

[Freddie Cash]

On Wed, Sep 12, 2012 at 1:48 PM, Jack Vogel  wrote:
> On Wed, Sep 12, 2012 at 12:40 PM, Freddie Cash  wrote:
>> Thanks for checking.  I've used lagg(4) with igb, just not on 9.x.
>>
>> You're right, it seems to be pointing to the igb(4) driver in 9.x
>> compared to < 9.0.
>>
> How do you determine that since it doesn't happen without lagg?  I've no
> reports of igb hanging otherwise and its being used extensively.

Well, I did say "seems to".  :)

igb+lagg worked for us on 8.3.  Haven't tried it since moving to 9.0
and 9-STABLE on those three boxes.

igb+lagg doesn't work for him on 9.0.  Although, I don't recall if
non-LACP options were tried earlier in this thread, or if it's just
the LACP mode that's failing.  If one mode works (say failover) and
LACP mode doesn't, that "seems to" point to lagg.

I'll see if I can free up an igb port on my 9.0 and 9-STABLE boxes to
test this with as well.

-- 
Freddie Cash
fjwc...@gmail.com
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Issue with igb and lagg (was Re: Problem with link aggregation + sshd)

[Jack Vogel]

On Wed, Sep 12, 2012 at 12:40 PM, Freddie Cash  wrote:

> On Wed, Sep 12, 2012 at 12:22 PM, Giulio Ferro 
> wrote:
> > On 09/11/2012 11:34 PM, Freddie Cash wrote:
> >>
> >> On Sep 11, 2012 2:12 PM, "Giulio Ferro"  >> > wrote:
> >>  >
> >>  > Well, there definitely seems to be a problem with igb and lagg.
> >>  >
> >>  > igb alone works as it should, but doesn't seem to work properly in
> >> lagg.
> >>  >
> >>  > To be sure I started from scratch from a 9.0 release with nothing
> but:
> >>  >
> >>  > /etc/rc.conf
> >>  > ---
> >>  > ifconfig_igb0="inet ..."
> >>  >
> >>  > ifconfig_igb1="up"
> >>  > ifconfig_igb2="up"
> >>  > ifconfig_igb3="up"
> >>  >
> >>  > cloned_interfaces="lagg0"
> >>  > ifconfig_lagg0="laggproto lacp laggport igb1 laggport igb2 laggport
> >> igb3 192.168.x.x/24"
> >>  >
> >>  > sshd_enable="YES"
> >>  > ---
> >>  >
> >>  > This doesn't even manage to start sshd, it just hangs there at boot.
> >>  >
> >>  > Disabling lagg configuration everything works correctly.
> >>  >
> >>
> >> Just curious: does it work if you split the lagg configuration from the
> >> IP config:
> >>
> >> ifconfig_lagg0="laggproto ..."
> >> ifconfig_lagg0_alias0="inet 192..."
> >>
> >> I've had problems in the past with cloned interfaces not working right
> >> if you do everything in one ifconfig line. Never spent much time
> >> debugging it, though, as the split config always worked.
> >>
> >
> > Nope, doesn't work. It always hangs at boot and cannot be killed
> (freebsd 9
> > RELEASE)
> >
> > I still think the problem is with lagg and / or igb.
> > Someone should look into it.
>
> Thanks for checking.  I've used lagg(4) with igb, just not on 9.x.
>
> You're right, it seems to be pointing to the igb(4) driver in 9.x
> compared to < 9.0.
>
> How do you determine that since it doesn't happen without lagg?  I've no
reports
of igb hanging otherwise and its being used extensively.

Jack


> --
> Freddie Cash
> fjwc...@gmail.com
> ___
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
>
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

9.1-rc1 cd/mps error

[Jason Keltz]

Hi.

I'm running the 9.1-RC1 release.

At the end of the boot sequence, I see:

mps0: mpssas_scsiio_timeout checking sc 0xff8000759000 cm 
0xff8000784380
(probe19:mps0:0:19:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 length 0 SMID 
240 command timeout cm 0xff8000784380 ccb 0xfe0006918000

mps0: mpssas_alloc_tm freezing simq
mps0: timedout cm 0xff8000784380 allocated tm 0xff8000771148
(probe19:mps0:0:19:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 length 0 SMID 
240 completed timedout cm 0xff8000784380 ccb 0xfe0006918000 
during recovery ioc 8048 scsi 0 state c xfer 0

(noperiph:mps0:0:19:0): SMID 1 abort TaskMID 240 status 0x0 code 0x0 count 1
(noperiph:mps0:0:19:0): SMID 1 finished recovery after aborting TaskMID 240
mps0: mpssas_free_tm releasing simq

(I had a similar error with a hang in 9.0 -- couldn't get out of it .. 
at least under 9.1 it doesn't hang).


... Can someone help me to figure out what this means?  Should I be alarmed?

The system has an Intel S3000AH server board with an LSI 9211-8i card 
with SAS2008 chipset, running IT firmware.It is connected to an 
older Chenbro CK12803 expander card which is connected to the 16 disk 
ports in the AIC RMC3E2-XPSS 3U chassis.  The disks are all recognized 
-- da0 is a 1 TB, da1-11 are 2 TB disks.


Any ideas?

Thanks ..

Jason Keltz


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

Re: Thinkpad X61s cannot boot 9.1-BETA1

[Alexander Motin]

On 12.09.2012 22:58, Lars Engels wrote:

On Wed, Sep 12, 2012 at 09:58:31PM +0300, Alexander Motin wrote:

On 12.09.2012 20:46, Lars Engels wrote:

On Wed, Sep 12, 2012 at 08:30:36PM +0300, Andriy Gapon wrote:

on 12/09/2012 20:25 Lars Engels said the following:

On Wed, Sep 12, 2012 at 03:54:30PM +0300, Andriy Gapon wrote:

Could you try to play with different eventtimer settings (preferably in 
current) ?
You can use this thread / PR as a guide:
http://thread.gmane.org/gmane.os.freebsd.devel.amd64/14480/focus=14495

The place where boot stop looks suspiciously close to the place where timer
interrupts should start driving the system.


Yes, that's it!
Setting  kern.eventtimer.timer="i8254" let's the Thinkpad boot on
CURRENT with the AC cable inserted.



Please share your sysctl kern.eventtimer output with Alexander.
He will probably ask for some additional information :-)


Sorry if I've missed, but it would be useful to see verbose dmesg in
situation where system couldn't boot without switching eventtimer.


No problem. See: http://bsd-geek.de/FreeBSD/IMAG0190.jpg


No, I've seen that one and I don't mean it. I mean full verbose dmesg of 
successful boot in conditions where system was not booting before 
without setting kern.eventtimer.timer="i8254".


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

Re: Thinkpad X61s cannot boot 9.1-BETA1

[Lars Engels]

On Wed, Sep 12, 2012 at 09:58:31PM +0300, Alexander Motin wrote:
> On 12.09.2012 20:46, Lars Engels wrote:
> > On Wed, Sep 12, 2012 at 08:30:36PM +0300, Andriy Gapon wrote:
> >> on 12/09/2012 20:25 Lars Engels said the following:
> >>> On Wed, Sep 12, 2012 at 03:54:30PM +0300, Andriy Gapon wrote:
>  Could you try to play with different eventtimer settings (preferably in 
>  current) ?
>  You can use this thread / PR as a guide:
>  http://thread.gmane.org/gmane.os.freebsd.devel.amd64/14480/focus=14495
> 
>  The place where boot stop looks suspiciously close to the place where 
>  timer
>  interrupts should start driving the system.
> >>>
> >>> Yes, that's it!
> >>> Setting  kern.eventtimer.timer="i8254" let's the Thinkpad boot on
> >>> CURRENT with the AC cable inserted.
> >>>
> >>
> >> Please share your sysctl kern.eventtimer output with Alexander.
> >> He will probably ask for some additional information :-)
> 
> Sorry if I've missed, but it would be useful to see verbose dmesg in 
> situation where system couldn't boot without switching eventtimer.

No problem. See: http://bsd-geek.de/FreeBSD/IMAG0190.jpg


pgpPlvdaSCCXj.pgp
Description: PGP signature

Re: Issue with igb and lagg (was Re: Problem with link aggregation + sshd)

[Freddie Cash]

On Wed, Sep 12, 2012 at 12:22 PM, Giulio Ferro  wrote:
> On 09/11/2012 11:34 PM, Freddie Cash wrote:
>>
>> On Sep 11, 2012 2:12 PM, "Giulio Ferro" > > wrote:
>>  >
>>  > Well, there definitely seems to be a problem with igb and lagg.
>>  >
>>  > igb alone works as it should, but doesn't seem to work properly in
>> lagg.
>>  >
>>  > To be sure I started from scratch from a 9.0 release with nothing but:
>>  >
>>  > /etc/rc.conf
>>  > ---
>>  > ifconfig_igb0="inet ..."
>>  >
>>  > ifconfig_igb1="up"
>>  > ifconfig_igb2="up"
>>  > ifconfig_igb3="up"
>>  >
>>  > cloned_interfaces="lagg0"
>>  > ifconfig_lagg0="laggproto lacp laggport igb1 laggport igb2 laggport
>> igb3 192.168.x.x/24"
>>  >
>>  > sshd_enable="YES"
>>  > ---
>>  >
>>  > This doesn't even manage to start sshd, it just hangs there at boot.
>>  >
>>  > Disabling lagg configuration everything works correctly.
>>  >
>>
>> Just curious: does it work if you split the lagg configuration from the
>> IP config:
>>
>> ifconfig_lagg0="laggproto ..."
>> ifconfig_lagg0_alias0="inet 192..."
>>
>> I've had problems in the past with cloned interfaces not working right
>> if you do everything in one ifconfig line. Never spent much time
>> debugging it, though, as the split config always worked.
>>
>
> Nope, doesn't work. It always hangs at boot and cannot be killed (freebsd 9
> RELEASE)
>
> I still think the problem is with lagg and / or igb.
> Someone should look into it.

Thanks for checking.  I've used lagg(4) with igb, just not on 9.x.

You're right, it seems to be pointing to the igb(4) driver in 9.x
compared to < 9.0.

-- 
Freddie Cash
fjwc...@gmail.com
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Issue with igb and lagg (was Re: Problem with link aggregation + sshd)

[Giulio Ferro]

On 09/11/2012 11:34 PM, Freddie Cash wrote:


On Sep 11, 2012 2:12 PM, "Giulio Ferro" mailto:au...@zirakzigil.org>> wrote:
 >
 > Well, there definitely seems to be a problem with igb and lagg.
 >
 > igb alone works as it should, but doesn't seem to work properly in lagg.
 >
 > To be sure I started from scratch from a 9.0 release with nothing but:
 >
 > /etc/rc.conf
 > ---
 > ifconfig_igb0="inet ..."
 >
 > ifconfig_igb1="up"
 > ifconfig_igb2="up"
 > ifconfig_igb3="up"
 >
 > cloned_interfaces="lagg0"
 > ifconfig_lagg0="laggproto lacp laggport igb1 laggport igb2 laggport
igb3 192.168.x.x/24"
 >
 > sshd_enable="YES"
 > ---
 >
 > This doesn't even manage to start sshd, it just hangs there at boot.
 >
 > Disabling lagg configuration everything works correctly.
 >

Just curious: does it work if you split the lagg configuration from the
IP config:

ifconfig_lagg0="laggproto ..."
ifconfig_lagg0_alias0="inet 192..."

I've had problems in the past with cloned interfaces not working right
if you do everything in one ifconfig line. Never spent much time
debugging it, though, as the split config always worked.



Nope, doesn't work. It always hangs at boot and cannot be killed 
(freebsd 9 RELEASE)


I still think the problem is with lagg and / or igb.
Someone should look into it.


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

Re: Thinkpad X61s cannot boot 9.1-BETA1

[Alexander Motin]

On 12.09.2012 20:46, Lars Engels wrote:

On Wed, Sep 12, 2012 at 08:30:36PM +0300, Andriy Gapon wrote:

on 12/09/2012 20:25 Lars Engels said the following:

On Wed, Sep 12, 2012 at 03:54:30PM +0300, Andriy Gapon wrote:

Could you try to play with different eventtimer settings (preferably in 
current) ?
You can use this thread / PR as a guide:
http://thread.gmane.org/gmane.os.freebsd.devel.amd64/14480/focus=14495

The place where boot stop looks suspiciously close to the place where timer
interrupts should start driving the system.


Yes, that's it!
Setting  kern.eventtimer.timer="i8254" let's the Thinkpad boot on
CURRENT with the AC cable inserted.



Please share your sysctl kern.eventtimer output with Alexander.
He will probably ask for some additional information :-)


Sorry if I've missed, but it would be useful to see verbose dmesg in 
situation where system couldn't boot without switching eventtimer.


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

Re: Thinkpad X61s cannot boot 9.1-BETA1

[Lars Engels]

On Wed, Sep 12, 2012 at 08:30:36PM +0300, Andriy Gapon wrote:
> on 12/09/2012 20:25 Lars Engels said the following:
> > On Wed, Sep 12, 2012 at 03:54:30PM +0300, Andriy Gapon wrote:
> >> Could you try to play with different eventtimer settings (preferably in 
> >> current) ?
> >> You can use this thread / PR as a guide:
> >> http://thread.gmane.org/gmane.os.freebsd.devel.amd64/14480/focus=14495
> >>
> >> The place where boot stop looks suspiciously close to the place where timer
> >> interrupts should start driving the system.
> > 
> > Yes, that's it!
> > Setting  kern.eventtimer.timer="i8254" let's the Thinkpad boot on
> > CURRENT with the AC cable inserted.
> > 
> 
> Please share your sysctl kern.eventtimer output with Alexander.
> He will probably ask for some additional information :-)
> 
> Thanks for testing!

lars@pts/12 > cat kern.eventtimer_10_r238992M.txt
kern.eventtimer.choice: HPET(450) HPET1(440) HPET2(440) LAPIC(400)
i8254(100) RTC(0)
kern.eventtimer.et.LAPIC.flags: 15
kern.eventtimer.et.LAPIC.frequency: 0
kern.eventtimer.et.LAPIC.quality: 400
kern.eventtimer.et.i8254.flags: 1
kern.eventtimer.et.i8254.frequency: 1193182
kern.eventtimer.et.i8254.quality: 100
kern.eventtimer.et.HPET.flags: 3
kern.eventtimer.et.HPET.frequency: 14318180
kern.eventtimer.et.HPET.quality: 450
kern.eventtimer.et.HPET1.flags: 3
kern.eventtimer.et.HPET1.frequency: 14318180
kern.eventtimer.et.HPET1.quality: 440
kern.eventtimer.et.HPET2.flags: 3
kern.eventtimer.et.HPET2.frequency: 14318180
kern.eventtimer.et.HPET2.quality: 440
kern.eventtimer.et.RTC.flags: 17
kern.eventtimer.et.RTC.frequency: 32768
kern.eventtimer.et.RTC.quality: 0
kern.eventtimer.periodic: 1
kern.eventtimer.timer: i8254
kern.eventtimer.activetick: 1
kern.eventtimer.idletick: 0
kern.eventtimer.singlemul: 2
 


lars@pts/12 > cat kern.eventtimer_9.1-RC1.txt
kern.eventtimer.choice: HPET(450) HPET1(440) HPET2(440) LAPIC(400)
i8254(100) RTC(0)
kern.eventtimer.et.LAPIC.flags: 15
kern.eventtimer.et.LAPIC.frequency: 0
kern.eventtimer.et.LAPIC.quality: 400
kern.eventtimer.et.i8254.flags: 1
kern.eventtimer.et.i8254.frequency: 1193182
kern.eventtimer.et.i8254.quality: 100
kern.eventtimer.et.HPET.flags: 3
kern.eventtimer.et.HPET.frequency: 14318180
kern.eventtimer.et.HPET.quality: 450
kern.eventtimer.et.HPET1.flags: 3
kern.eventtimer.et.HPET1.frequency: 14318180
kern.eventtimer.et.HPET1.quality: 440
kern.eventtimer.et.HPET2.flags: 3
kern.eventtimer.et.HPET2.frequency: 14318180
kern.eventtimer.et.HPET2.quality: 440
kern.eventtimer.et.RTC.flags: 17
kern.eventtimer.et.RTC.frequency: 32768
kern.eventtimer.et.RTC.quality: 0
kern.eventtimer.periodic: 0
kern.eventtimer.timer: HPET
kern.eventtimer.activetick: 1
kern.eventtimer.idletick: 0
kern.eventtimer.singlemul: 2



lars@pts/12 > diff -u kern.eventtimer_9.1-RC1.txt
kern.eventtimer_10_r238992M.txt
--- kern.eventtimer_9.1-RC1.txt 2012-09-12 19:43:58.0 +0200
+++ kern.eventtimer_10_r238992M.txt 2012-09-12 19:43:58.0
+0200
@@ -17,8 +17,8 @@
 kern.eventtimer.et.RTC.flags: 17
 kern.eventtimer.et.RTC.frequency: 32768
 kern.eventtimer.et.RTC.quality: 0
-kern.eventtimer.periodic: 0
-kern.eventtimer.timer: HPET
+kern.eventtimer.periodic: 1
+kern.eventtimer.timer: i8254
 kern.eventtimer.activetick: 1
 kern.eventtimer.idletick: 0
 kern.eventtimer.singlemul: 2


pgpqwoQ2njqdh.pgp
Description: PGP signature

Re: Thinkpad X61s cannot boot 9.1-BETA1

[Andriy Gapon]

on 12/09/2012 20:25 Lars Engels said the following:
> On Wed, Sep 12, 2012 at 03:54:30PM +0300, Andriy Gapon wrote:
>> Could you try to play with different eventtimer settings (preferably in 
>> current) ?
>> You can use this thread / PR as a guide:
>> http://thread.gmane.org/gmane.os.freebsd.devel.amd64/14480/focus=14495
>>
>> The place where boot stop looks suspiciously close to the place where timer
>> interrupts should start driving the system.
> 
> Yes, that's it!
> Setting  kern.eventtimer.timer="i8254" let's the Thinkpad boot on
> CURRENT with the AC cable inserted.
> 

Please share your sysctl kern.eventtimer output with Alexander.
He will probably ask for some additional information :-)

Thanks for testing!

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

Re: Thinkpad X61s cannot boot 9.1-BETA1

[Lars Engels]

On Wed, Sep 12, 2012 at 03:54:30PM +0300, Andriy Gapon wrote:
> on 12/09/2012 14:34 Lars Engels said the following:
> > On Wed, Aug 22, 2012 at 08:02:12PM +0200, Thomas Steen Rasmussen wrote:
> >>
> >> -BEGIN PGP SIGNED MESSAGE-
> >> Hash: SHA1
> >>  
> >> On 22-08-2012 18:52, Lars Engels wrote:
> >>> On Wed, Aug 22, 2012 at 02:47:09PM +0200, Thomas Steen Rasmussen wrote:
> 
>  On 22-08-2012 11:33, Lars Engels wrote:
> >
> > I have a T61 running 9.1-BETA1 (with PC-BSD). In most cases it is
> > booting fine, but from time to time it hangs at boot time but the last
> > lines are uhub0: ... to uhub4
> > Is that the same or a different issue?
>  Hello,
> 
>  I have that exact issue on an X301 after upgrading from 9.0 to
>  9-STABLE a little while ago. It feels like it happens mostly when
>  rebooting from Windows to FreeBSD (dualboot machine), but I've
>  seen it from a cold boot as well. I've never seen it twice in
>  a row - turning the machine off and on again (by holding the
>  power button down) and it boots normally the next time.
> 
>  I am willing to test patches or enable extra debugging, or
>  help out any other way I can :)
> >>>
> >>> Have you ever seen that with verbose boot enabled?
> >> Hello,
> >>
> >> No, but I can boot verbosely the next times I boot and see if it comes up ?
> > 
> > Meanwhile I found out what's the cause of it. On 9.x it only hung from
> > time to time, but I tried a few weeks old CURRENT and it hung at every
> > boot at the same time.
> > With enabled verbose boot it looked like this:
> > http://bsd-geek.de/FreeBSD/IMAG0190.jpg
> > 
> > Then I removed the AC cable and booted from battery and that worked. So
> > it seems to me that some ACPI change in CURRENT made the situation even
> > worse.
> > 
> 
> Could you try to play with different eventtimer settings (preferably in 
> current) ?
> You can use this thread / PR as a guide:
> http://thread.gmane.org/gmane.os.freebsd.devel.amd64/14480/focus=14495
> 
> The place where boot stop looks suspiciously close to the place where timer
> interrupts should start driving the system.

Yes, that's it!
Setting  kern.eventtimer.timer="i8254" let's the Thinkpad boot on
CURRENT with the AC cable inserted.


pgpFFz7PQV7KB.pgp
Description: PGP signature

systutils/arcconf errors on 9.x versions

[David Boyd]

Back in July, this error was discussed briefly on the mailing list(s).

It appears that a fix (r238182) was submitted for inclusion in 9.1 (early).

This problem still appears in 9.1-RC1.

Will the fix be included in 9.1-RELEASE (or better yet 9.1-RC2)?

Thanks.

David Boyd.


--
1st e-mail from pluknet responding to Sergey Kandaurov

--
On 6 July 2012 14:49, Serg R  wrote:
> Hi!
>
> There is a problem with running the Adaptec Storage Manager in freebsd 9.
>
> # uname -a
> FreeBSD sorgo 9.0-STABLE FreeBSD 9.0-STABLE #4: Thu May 31 13:39:39 SAMT
2012 root@sorgo:/usr/obj/usr/src/sys/SORGO  amd64
> # portversion -v | grep arc
> arcconf-v7.30.18837 = up-to-date with port
> # arcconf
> Undefined symbol "__collate_load_error" referenced from COPY relocation in
/usr/local/sbin/arcconf

This is probably because the private symbol __collate_load_error changed
to macro (i.e. removed) in r235785 after 9.0. If so, it might brake those
older binaries which rely on that symbol, though it's still defined in
Symbol.map. Probably David Chisnall could further comment on this.

--
wbr,
pluknet

--
2nd e-mail from David Chisnall responding to Sergey Kandaurov

--
On 6 Jul 2012, at 20:32, Sergey Kandaurov wrote:

> This is probably because the private symbol __collate_load_error =
changed
> to macro (i.e. removed) in r235785 after 9.0. If so, it might brake =
those
> older binaries which rely on that symbol, though it's still defined in
> Symbol.map. Probably David Chisnall could further comment on this.

This was accidentally removed in the xlocale refactoring.  I've restored =
it in r238182 and CC'd re@ for permission to merge to the 9.1 release =
branch.

David=

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

Re: Thinkpad X61s cannot boot 9.1-BETA1

[Andriy Gapon]

on 12/09/2012 15:54 Andriy Gapon said the following:
> on 12/09/2012 14:34 Lars Engels said the following:
>> Meanwhile I found out what's the cause of it. On 9.x it only hung from
>> time to time, but I tried a few weeks old CURRENT and it hung at every
>> boot at the same time.
>> With enabled verbose boot it looked like this:
>> http://bsd-geek.de/FreeBSD/IMAG0190.jpg
>>
>> Then I removed the AC cable and booted from battery and that worked. So
>> it seems to me that some ACPI change in CURRENT made the situation even
>> worse.
>>
> 
> Could you try to play with different eventtimer settings (preferably in 
> current) ?
> You can use this thread / PR as a guide:
> http://thread.gmane.org/gmane.os.freebsd.devel.amd64/14480/focus=14495
> 
> The place where boot stop looks suspiciously close to the place where timer
> interrupts should start driving the system.
> 

Just in case.  My point is that your system might using a timer that stops in
certain (deeper) C-states.  Generally FreeBSD disables deeper C-states in such a
situation, but your system may require additional quirks.

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

Re: Thinkpad X61s cannot boot 9.1-BETA1

[Andriy Gapon]

on 12/09/2012 14:34 Lars Engels said the following:
> On Wed, Aug 22, 2012 at 08:02:12PM +0200, Thomas Steen Rasmussen wrote:
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>  
>> On 22-08-2012 18:52, Lars Engels wrote:
>>> On Wed, Aug 22, 2012 at 02:47:09PM +0200, Thomas Steen Rasmussen wrote:

 On 22-08-2012 11:33, Lars Engels wrote:
>
> I have a T61 running 9.1-BETA1 (with PC-BSD). In most cases it is
> booting fine, but from time to time it hangs at boot time but the last
> lines are uhub0: ... to uhub4
> Is that the same or a different issue?
 Hello,

 I have that exact issue on an X301 after upgrading from 9.0 to
 9-STABLE a little while ago. It feels like it happens mostly when
 rebooting from Windows to FreeBSD (dualboot machine), but I've
 seen it from a cold boot as well. I've never seen it twice in
 a row - turning the machine off and on again (by holding the
 power button down) and it boots normally the next time.

 I am willing to test patches or enable extra debugging, or
 help out any other way I can :)
>>>
>>> Have you ever seen that with verbose boot enabled?
>> Hello,
>>
>> No, but I can boot verbosely the next times I boot and see if it comes up ?
> 
> Meanwhile I found out what's the cause of it. On 9.x it only hung from
> time to time, but I tried a few weeks old CURRENT and it hung at every
> boot at the same time.
> With enabled verbose boot it looked like this:
> http://bsd-geek.de/FreeBSD/IMAG0190.jpg
> 
> Then I removed the AC cable and booted from battery and that worked. So
> it seems to me that some ACPI change in CURRENT made the situation even
> worse.
> 

Could you try to play with different eventtimer settings (preferably in 
current) ?
You can use this thread / PR as a guide:
http://thread.gmane.org/gmane.os.freebsd.devel.amd64/14480/focus=14495

The place where boot stop looks suspiciously close to the place where timer
interrupts should start driving the system.

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

Re: Thinkpad X61s cannot boot 9.1-BETA1

[Lars Engels]

On Wed, Aug 22, 2012 at 08:02:12PM +0200, Thomas Steen Rasmussen wrote:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>  
> On 22-08-2012 18:52, Lars Engels wrote:
> > On Wed, Aug 22, 2012 at 02:47:09PM +0200, Thomas Steen Rasmussen wrote:
> >>
> >> On 22-08-2012 11:33, Lars Engels wrote:
> >>>
> >>> I have a T61 running 9.1-BETA1 (with PC-BSD). In most cases it is
> >>> booting fine, but from time to time it hangs at boot time but the last
> >>> lines are uhub0: ... to uhub4
> >>> Is that the same or a different issue?
> >> Hello,
> >>
> >> I have that exact issue on an X301 after upgrading from 9.0 to
> >> 9-STABLE a little while ago. It feels like it happens mostly when
> >> rebooting from Windows to FreeBSD (dualboot machine), but I've
> >> seen it from a cold boot as well. I've never seen it twice in
> >> a row - turning the machine off and on again (by holding the
> >> power button down) and it boots normally the next time.
> >>
> >> I am willing to test patches or enable extra debugging, or
> >> help out any other way I can :)
> >
> > Have you ever seen that with verbose boot enabled?
> Hello,
> 
> No, but I can boot verbosely the next times I boot and see if it comes up ?

Meanwhile I found out what's the cause of it. On 9.x it only hung from
time to time, but I tried a few weeks old CURRENT and it hung at every
boot at the same time.
With enabled verbose boot it looked like this:
http://bsd-geek.de/FreeBSD/IMAG0190.jpg

Then I removed the AC cable and booted from battery and that worked. So
it seems to me that some ACPI change in CURRENT made the situation even
worse.


pgp884LxxyJGb.pgp
Description: PGP signature

Re: Clang as default compiler

[Volodymyr Kostyrko]

12.09.2012 00:49, Andreas Nilsson wrote:

On another clang note: Is there a page specifying valid settings for
-march, my google-foo is failing me. Ie, I'm looking for the equivalent of
http://gcc.gnu.org/onlinedocs/gcc-4.7.1/gcc/i386-and-x86_002d64-Options.html#i386-and-x86_002d64-Options


I'm using the minimum of:

   : | gcc -E -v -march=native -
   : | clang -E -v -march=native -

because there are number of ports that still doesn't compile with clang 
or GCC4.6.



After successful install I went on to upgrade some ports. Is there a specif
PR to use for ports that fails with clang and does not specify to use gcc (
devel/cdecl and deskutils/calibre so were the culprits so far)


It's up to you to fix this ports and submit patches. You can always 
rollback to using GCC.


--
Sphinx of black quartz judge my vow.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Clang as default compiler

[Andreas Nilsson]

>
>
> > in src.conf. No problem so far. However I wanted to avoid building base
> gcc
> > ( the whole collection ). Is  WITHOUT_GCC what I'm looking for?
> >
>
> It probably is. However, WITHOUT_GCC is not supported yet.
>
> > On another clang note: Is there a page specifying valid settings for
> > -march, my google-foo is failing me. Ie, I'm looking for the equivalent
> of
> >
> http://gcc.gnu.org/onlinedocs/gcc-4.7.1/gcc/i386-and-x86_002d64-Options.htm
> > l#i386-and-x86_002d64-Options
> >
>
> Take a look at lines 120 and below of contrib/llvm/lib/Target/X86/X86.td in
> the FreeBSD source directory for supported march switches.
>

 >There is no specific PR.  We have not yet placed the requirement on our
 >ports maintainers to deal with clang.

Is there a time frame for this requirement?

And for the know broken ports, how are the users supposed to deal with them
until the ports is fixed? Modifying the port by hand in the local ports
tree?

Best regards
Andreas
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Issue with igb and lagg (was Re: Problem with link aggregation + sshd)

[Vincent Hoffman]

On 11/09/2012 22:03, Giulio Ferro wrote:
> Well, there definitely seems to be a problem with igb and lagg.
>
> igb alone works as it should, but doesn't seem to work properly in lagg.
>
> To be sure I started from scratch from a 9.0 release with nothing but:
>
> /etc/rc.conf
> ---
> ifconfig_igb0="inet ..."
>
> ifconfig_igb1="up"
> ifconfig_igb2="up"
> ifconfig_igb3="up"
>
> cloned_interfaces="lagg0"
> ifconfig_lagg0="laggproto lacp laggport igb1 laggport igb2 laggport
> igb3 192.168.x.x/24"
>
> sshd_enable="YES"
> ---
>
> This doesn't even manage to start sshd, it just hangs there at boot.
>
> Disabling lagg configuration everything works correctly.
For what is worth its working fine for me on 8.3-RELEASE using failover.
ifconfig_igb0="up"
ifconfig_igb1="up"
cloned_interfaces="lagg0 lagg0.53 lagg0.52 lagg0.66"
ifconfig_lagg0="laggproto failover laggport igb0 laggport igb1
85.233.xxx.xxx/23"
ifconfig_lagg0_53="inet 192.168.xxx.226/24"
ifconfig_lagg0_52="inet 192.168.xxx.254/24"
ifconfig_lagg0_66="inet 192.168.xxx.250/24"
ipv4_addrs_lagg0_52="192.168.xxx.254/24 192.168.0.70/24"


lagg0: flags=8843 metric 0 mtu 1500
   
options=401bb
ether 00:25:90:39:64:76
inet 85.233.xx.xx netmask 0xfe00 broadcast 85.233.xx.255
media: Ethernet autoselect
status: active
laggproto failover
laggport: igb1 flags=0<>
laggport: igb0 flags=5




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

Re: Clang as default compiler

[Mark Linimon]

On Wed, Sep 12, 2012 at 11:54:51AM +0300, Alexander Yerenkow wrote:
> How about run automated test on two poudriere setups, one with CLANG set
> up, other with USE_GCC=4.2 applied to all ports which marked as broken,

We have been running various tests for quite some time.

> Is there somewhere list of these clang-failing ports?

http://wiki.freebsd.org/PortsAndClang .  I have been maintaing and
updating this for over a year now.

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

Re: Clang as default compiler

[Alexander Yerenkow]

How about run automated test on two poudriere setups, one with CLANG set
up, other with USE_GCC=4.2 applied to all ports which marked as broken,
and find in pretty long but relatively easy way ports which should have
USE_GCC=4.2 to survive clang-era, and ports which even with that require a
bit more love?

Is there somewhere list of these clang-failing ports? I think some mass
testing could be organized by little efforts.

-- 
Regards,
Alexander Yerenkow
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: bsnmpd always died on HDD detach

[Miroslav Lachman]

Mikolaj Golub wrote:

On Tue, Sep 11, 2012 at 10:16:57PM +0200, Miroslav Lachman wrote:


(gdb) bt
#0  0x000801046cba in refresh_disk_storage_tbl () from
/usr/lib/snmp_hostres.so
#1  0x0008010478bd in refresh_device_tbl () from
/usr/lib/snmp_hostres.so
#2  0x000801047be6 in start_device_tbl () from /usr/lib/snmp_hostres.so
#3  0x00080065fad5 in poll_dispatch () from /lib/libbegemot.so.4
#4  0x0040616a in main ()


Is it all you need? (I don't know how to use gdb)

It is on FreeBSD 8.3-RELEASE #0: Mon Apr  9 21:23:18 UTC 2012
r...@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  amd64


Not sure we can get more than provided from this core as snmp_hostres
is not built with debugging symbols. You can try rebuilding
snmp_hostres with -g option, intalling and running gdb/bt again

DEBUG_FLAGS=-g make -C /usr/src/usr.sbin/bsnmpd/modules/snmp_hostres clean all 
install

AFAIK it might work or not. If it does not then wait for another crash :-)


I don't know it is better or not. All I can say is: "it's different" ;)

# gdb /usr/sbin/bsnmpd /bsnmpd.core
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain 
conditions.

Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...(no debugging 
symbols found)...

Core was generated by `bsnmpd'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libbegemot.so.4...(no debugging symbols 
found)...done.

Loaded symbols for /lib/libbegemot.so.4
Reading symbols from /lib/libbsnmp.so.5...(no debugging symbols 
found)...done.

Loaded symbols for /lib/libbsnmp.so.5
Reading symbols from /usr/lib/libwrap.so.6...(no debugging symbols 
found)...done.

Loaded symbols for /usr/lib/libwrap.so.6
Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done.
Loaded symbols for /lib/libc.so.7
Reading symbols from /usr/lib/snmp_mibII.so...(no debugging symbols 
found)...done.

Loaded symbols for /usr/lib/snmp_mibII.so
Reading symbols from /usr/lib/snmp_pf.so...(no debugging symbols 
found)...done.

Loaded symbols for /usr/lib/snmp_pf.so
Reading symbols from /usr/lib/snmp_hostres.so...done.
Loaded symbols for /usr/lib/snmp_hostres.so
Reading symbols from /lib/libkvm.so.5...done.
Loaded symbols for /lib/libkvm.so.5
Reading symbols from /usr/lib/libdevinfo.so.5...done.
Loaded symbols for /usr/lib/libdevinfo.so.5
Reading symbols from /lib/libm.so.5...done.
Loaded symbols for /lib/libm.so.5
Reading symbols from /lib/libgeom.so.5...done.
Loaded symbols for /lib/libgeom.so.5
Reading symbols from /usr/lib/libmemstat.so.3...done.
Loaded symbols for /usr/lib/libmemstat.so.3
Reading symbols from /lib/libbsdxml.so.4...done.
Loaded symbols for /lib/libbsdxml.so.4
Reading symbols from /lib/libsbuf.so.5...done.
Loaded symbols for /lib/libsbuf.so.5
Reading symbols from /libexec/ld-elf.so.1...done.
Loaded symbols for /libexec/ld-elf.so.1
#0  0x000801046cba in disk_query_disk (entry=0x0) at 
hostres_diskstorage_tbl.c:241

241 partition_tbl_handle_disk(entry->index, entry->dev_name);
(gdb) bt
#0  0x000801046cba in disk_query_disk (entry=0x0) at 
hostres_diskstorage_tbl.c:241

#1  0x000801dd6a00 in ?? ()
#2  0x000801dd6600 in ?? ()
#3  0x in ?? ()
#4  0x000801048230 in device_entry_create (name=0x0, 
location=0x800c14ee0 "0", descr=0x8010482a6 "") at hostres_device_tbl.c:217

#5  0x000801dd7800 in ?? ()
#6  0x000801dd7800 in ?? ()
#7  0x000801dd7400 in ?? ()
#8  0x in ?? ()
#9  0x000801048230 in device_entry_create (name=0x801dd7c00 "", 
location=0x801048230 "˙˙I\213|$8čŕ\201˙˙L\211çčŘ\201˙˙é\035ţ˙˙H\215\025",

descr=0x8010482a6 "") at hostres_device_tbl.c:217
#10 0x000801dd4a00 in ?? ()
#11 0x000801dd4a00 in ?? ()
#12 0x000801dd1a00 in ?? ()
#13 0x in ?? ()
#14 0x000801048230 in device_entry_create (name=0x801dd8400 "", 
location=0x801048230 "˙˙I\213|$8čŕ\201˙˙L\211çčŘ\201˙˙é\035ţ˙˙H\215\025",

descr=0x8010482a6 "") at hostres_device_tbl.c:217
#15 0x000801dd1800 in ?? ()
#16 0x000801dd1800 in ?? ()
#17 0x000800c00ea8 in ?? ()
#18 0x0051b1c8 in ?? ()
#19 0x000800c00938 in ?? ()
#20 0x0051b258 in ?? ()
#21 0x000801dc8a00 in ?? ()
#22 0x0008009f7be9 in free () from /lib/libc.so.7
#23 0x in ?? ()
#24 0x7fffed98 in ?? ()
#25 0x0008010478bd in device_entry_delete () at hostres_device_tbl.c:266
#26 0x005187d0 in snmp_error ()
#27 0x000801047be6 in op_hrDeviceTable (ctx=Variable "ctx" is not 
available.

) at hostres_device_tbl.c:671
#28 0x0051b840 in ?? ()
#29 0x0051b830 in ?? ()
#30 0x in ?? ()
#31 0x7fffc360 in ?? ()
#32 0x0051b83

Re: Clang as default compiler

[Mark Linimon]

On Wed, Sep 12, 2012 at 08:00:46AM +0100, Chris Rees wrote:
> We don't want thousands of PRs duplicating the information from a simple
> list of failures.

Thanks, that was the point I was trying to make.

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

Re: Clang as default compiler

[Chris Rees]

On 12 Sep 2012 07:19, "Christer Solskogen" 
wrote:
>
> On Wed, Sep 12, 2012 at 8:04 AM, Mark Linimon 
wrote:
>
> > For most of the failures, we are already aware of them, as a result of
> > our periodic runs.  So, just filing a PR to say "broken on clang"
doesn't
> > really help us all that much.
> >
>
> I disagree. Just a tiny bit ;-)
> If the PR says that USE_GCC=4.2 works as a workaround, it helps.

We don't want thousands of PRs duplicating the information from a simple
list of failures.

Any can be fixed in this way.

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