Re: CURRENT (r248128): PKGNG weirdness: openldap-sasl-client-2.4.33_1 conflicts with installed package(s): openldap-sasl-client-2.4.33_1 AND /usr/local AND net/openldap24-sasl-client
On Tue, 2013-03-12 at 17:16 -0500, Bryan Drewery wrote: On 3/10/2013 6:44 AM, O. Hartmann wrote: On FreeBSD 10.0-CURRENT #0 r248128: Sun Mar 10 10:41:10 CET 2013 I receive the error message below when trying to update installed port openldap24-sasl-client: === Cleaning for openldap-sasl-client-2.4.33_1 === Waiting on fetch checksum for net/openldap24-sasl-client === === openldap-sasl-client-2.4.33_1 conflicts with installed package(s): openldap-sasl-client-2.4.33_1 /usr/local net/openldap24-sasl-client They install files into the same place. You may want to stop build with Ctrl + C. This looks weird tome, since how can /usr/local/ be a port? My update tool is ports-mgmt/portmaster. Regards, Oliver I have just committed a fix to the ports tree for this. Hello. Well, I just updated the port's tree a few minutes ago and can not see any changes by now. The port's tree is at Revision: 314034 for me. Regards, Oliver signature.asc Description: This is a digitally signed message part
Re: CURRENT (r248128): PKGNG weirdness: openldap-sasl-client-2.4.33_1 conflicts with installed package(s): openldap-sasl-client-2.4.33_1 AND /usr/local AND net/openldap24-sasl-client
On 3/13/2013 2:55 AM, O. Hartmann wrote: On Tue, 2013-03-12 at 17:16 -0500, Bryan Drewery wrote: I have just committed a fix to the ports tree for this. Hello. Well, I just updated the port's tree a few minutes ago and can not see any changes by now. The port's tree is at Revision: 314034 for me. Regards, Oliver The change was to Mk/bsd.port.mk in r314004 -- Regards, Bryan Drewery bdrewery@freenode/EFNet signature.asc Description: OpenPGP digital signature
Re: using multiple interfaces for same Network Card
Yasir hussan wrote: --20cf3005141ab7271904d7be84ff Yes, i want to use them as vlan interface, Does any one has used *vlandev*, after seen this http://www.cyberciti.biz/faq/howto-configure-freebsd-vlans-with-ifconfig-comm and/i tried to use it as ifconfig vlan11 create 10.10.11.1 255.255.255.0 vlan 11 vlandev arge0 ifconfig vlan12 create 10.10.12.1 255.255.255.0 vlan 12 vlandev arge0 ifconfig vlan13 create 10.10.13.1 255.255.255.0 vlan 13 vlandev arge0 ifconfig vlan14 create 10.10.14.1 255.255.255.0 vlan 14 vlandev arge0 you want: ifconfig vlan11 create vlan 11 vlandev arge0 inet 10.10.11.1 netmask 255.255.255.0 or ifconfig vlan11 create vlan 11 vlandev arge0 inet 10.10.11.1/24 Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CURRENT (r248128): PKGNG weirdness: openldap-sasl-client-2.4.33_1 conflicts with installed package(s): openldap-sasl-client-2.4.33_1 AND /usr/local AND net/openldap24-sasl-client
On Wed, 2013-03-13 at 04:49 -0500, Bryan Drewery wrote: On 3/13/2013 2:55 AM, O. Hartmann wrote: On Tue, 2013-03-12 at 17:16 -0500, Bryan Drewery wrote: I have just committed a fix to the ports tree for this. Hello. Well, I just updated the port's tree a few minutes ago and can not see any changes by now. The port's tree is at Revision: 314034 for me. Regards, Oliver The change was to Mk/bsd.port.mk in r314004 Well, even with clearing the build and the directory and getting it from scratch, on FreeBSD 10-CURRENT I have still the same error. make rmconfig doesn't change anything, also. signature.asc Description: This is a digitally signed message part
Re: CURRENT (r248128): PKGNG weirdness: openldap-sasl-client-2.4.33_1 conflicts with installed package(s): openldap-sasl-client-2.4.33_1 AND /usr/local AND net/openldap24-sasl-client
On 3/13/2013 7:21 AM, O. Hartmann wrote: On Wed, 2013-03-13 at 04:49 -0500, Bryan Drewery wrote: On 3/13/2013 2:55 AM, O. Hartmann wrote: On Tue, 2013-03-12 at 17:16 -0500, Bryan Drewery wrote: I have just committed a fix to the ports tree for this. Hello. Well, I just updated the port's tree a few minutes ago and can not see any changes by now. The port's tree is at Revision: 314034 for me. Regards, Oliver The change was to Mk/bsd.port.mk in r314004 Well, even with clearing the build and the directory and getting it from scratch, on FreeBSD 10-CURRENT I have still the same error. make rmconfig doesn't change anything, also. It's not a problem with net/openldap24-sasl-client specifically. It's a /usr/ports/Mk problem. Run: portsnap fetch extract Mk This will update your Mk files to the latest. -- Regards, Bryan Drewery bdrewery@freenode/EFNet signature.asc Description: OpenPGP digital signature
sysinstall and graid mirror on 9.1R
Hi, I know sysinstall is deprecated and gone from -current, but there is still 8/9 that will be supported for few years so this may worth fixing. Got this anytime I starting sysinstall on a system, installed onto graid mirror: http://people.freebsd.org/~rm/sysinstall_graid.png No more have access to that system, so will not be able to test anything. But it's 100% reproducible in that configuration. -- Regards, Ruslan Tinderboxing kills... the drives. ___ 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: CURRENT (r248128): PKGNG weirdness: openldap-sasl-client-2.4.33_1 conflicts with installed package(s): openldap-sasl-client-2.4.33_1 AND /usr/local AND net/openldap24-sasl-client
On Wed, 2013-03-13 at 07:26 -0500, Bryan Drewery wrote: On 3/13/2013 7:21 AM, O. Hartmann wrote: On Wed, 2013-03-13 at 04:49 -0500, Bryan Drewery wrote: On 3/13/2013 2:55 AM, O. Hartmann wrote: On Tue, 2013-03-12 at 17:16 -0500, Bryan Drewery wrote: I have just committed a fix to the ports tree for this. Hello. Well, I just updated the port's tree a few minutes ago and can not see any changes by now. The port's tree is at Revision: 314034 for me. Regards, Oliver The change was to Mk/bsd.port.mk in r314004 Well, even with clearing the build and the directory and getting it from scratch, on FreeBSD 10-CURRENT I have still the same error. make rmconfig doesn't change anything, also. It's not a problem with net/openldap24-sasl-client specifically. It's a /usr/ports/Mk problem. Run: portsnap fetch extract Mk This will update your Mk files to the latest. I'm with svn update, so I did this and it seems not to be changed. Still no further update in the exspected file nor does the port build properly. I think I have to wait? Oliver signature.asc Description: This is a digitally signed message part
Re: CURRENT (r248128): PKGNG weirdness: openldap-sasl-client-2.4.33_1 conflicts with installed package(s): openldap-sasl-client-2.4.33_1 AND /usr/local AND net/openldap24-sasl-client
On 3/13/2013 8:55 AM, O. Hartmann wrote: On Wed, 2013-03-13 at 07:26 -0500, Bryan Drewery wrote: On 3/13/2013 7:21 AM, O. Hartmann wrote: On Wed, 2013-03-13 at 04:49 -0500, Bryan Drewery wrote: On 3/13/2013 2:55 AM, O. Hartmann wrote: On Tue, 2013-03-12 at 17:16 -0500, Bryan Drewery wrote: I have just committed a fix to the ports tree for this. I'm with svn update, so I did this and it seems not to be changed. Still no further update in the exspected file nor does the port build properly. I think I have to wait? Oliver Exactly what error are you getting now? The weird one showing /usr/local should be fixed. -- Regards, Bryan Drewery bdrewery@freenode/EFNet signature.asc Description: OpenPGP digital signature
Re: CURRENT (r248128): PKGNG weirdness: openldap-sasl-client-2.4.33_1 conflicts with installed package(s): openldap-sasl-client-2.4.33_1 AND /usr/local AND net/openldap24-sasl-client
On Wed, 2013-03-13 at 09:54 -0500, Bryan Drewery wrote: On 3/13/2013 8:55 AM, O. Hartmann wrote: On Wed, 2013-03-13 at 07:26 -0500, Bryan Drewery wrote: On 3/13/2013 7:21 AM, O. Hartmann wrote: On Wed, 2013-03-13 at 04:49 -0500, Bryan Drewery wrote: On 3/13/2013 2:55 AM, O. Hartmann wrote: On Tue, 2013-03-12 at 17:16 -0500, Bryan Drewery wrote: I have just committed a fix to the ports tree for this. I'm with svn update, so I did this and it seems not to be changed. Still no further update in the exspected file nor does the port build properly. I think I have to wait? Oliver Exactly what error are you getting now? The weird one showing /usr/local should be fixed. Ups, I'm very sorry. I confused this PR with another serious PR that concerns build breakage of net/openldap24-server (which is different). The problems regarding to this reported problem (what we are talking about by now) has been gone so far. regards, Oliver ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[PATCH] Add support for Exar XR17V358IV to puc(4)
I've implemented support for Exar XR17V358IV 8-port UARTs. These are quite
similar to previous Exar UARTs, with the notable exception of the strange
125MHz clock. I've done some basic testing using it as a tty at 9600 baud
and 115200 baud, but nothing really extensive. I can't seem to find any
tools for stressing out serial ports. I'm not sure if anybody has any
suggestions for this.
I plan to commit this within a couple of days if nobody has any
objections. I'll try to get it MFC'ed for 8.4-RELEASE,
The patch can be found here:
http://people.freebsd.org/~rstone/patches/exar_358.diff
I've also included it inline in case anybody wants to review it:
commit d1da80b5c90b3ae5a44db165cb032e9e86d2c804
Author: Ryan Stone rst...@freebsd.org
Date: Mon Mar 11 17:02:13 2013 -0400
add support for Exar XR17V358IV 8-port serial port to puc(4)
diff --git a/sys/dev/puc/pucdata.c b/sys/dev/puc/pucdata.c
index 6d933e8..34d6986 100644
--- a/sys/dev/puc/pucdata.c
+++ b/sys/dev/puc/pucdata.c
@@ -50,6 +50,7 @@ __FBSDID($FreeBSD$);
static puc_config_f puc_config_amc;
static puc_config_f puc_config_diva;
static puc_config_f puc_config_exar;
+static puc_config_f puc_config_exar_pcie;
static puc_config_f puc_config_icbook;
static puc_config_f puc_config_moxa;
static puc_config_f puc_config_oxford_pcie;
@@ -630,6 +631,13 @@ const struct puc_cfg puc_pci_devices[] = {
PUC_PORT_8S, 0x10, 0, -1,
},
+ { 0x13a8, 0x0358, 0x, 0,
+ Exar XR17V358IV,
+ 12500,
+ PUC_PORT_8S, 0x10, 0, -1,
+ .config_function = puc_config_exar_pcie
+ },
+
{ 0x13fe, 0x1600, 0x1602, 0x0002,
Advantech PCI-1602,
DEFAULT_RCLK * 8,
@@ -1186,6 +1194,17 @@ puc_config_exar(struct puc_softc *sc, enum
puc_cfg_cmd cmd, int port,
}
static int
+puc_config_exar_pcie(struct puc_softc *sc, enum puc_cfg_cmd cmd, int port,
+intptr_t *res)
+{
+ if (cmd == PUC_CFG_GET_OFS) {
+ *res = port * 0x400;
+ return (0);
+ }
+ return (ENXIO);
+}
+
+static int
puc_config_icbook(struct puc_softc *sc, enum puc_cfg_cmd cmd, int port,
intptr_t *res)
{
___
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: pidfile_open incorrectly returns EAGAIN when pidfile is locked
On Tuesday, March 12, 2013 4:16:32 pm Dirk Engling wrote:
While debugging my own daemon I noticed that pidfile_open does not
perform the appropriate checks for a running daemon if the caller does
not provide a pidptr to pidfile_open
fd = flopen(pfh-pf_path,
O_WRONLY | O_CREAT | O_TRUNC | O_CLOEXEC | O_NONBLOCK, mode);
fails when another daemon holds the lock and flopen sets errno to
EAGAIN, the check 4 lines below in
if (errno == EWOULDBLOCK pidptr != NULL) {
means that the pidfile_read is never executed.
This results in my second daemon receiving an EAGAIN which clearly was
meant to report a race condition between two daemons starting at the
same time and the first one not yet finishing pidfile_write.
The expected behavior would be to set errno to EEXIST, even if no pidptr
was passed.
Yes, I think it should actually perform the same logic even if pidptr is
NULL of waiting for the other daemon to finish starting up. Something like
this:
Index: lib/libutil/pidfile.c
===
--- pidfile.c (revision 248162)
+++ pidfile.c (working copy)
@@ -100,6 +100,7 @@ pidfile_open(const char *path, mode_t mode, pid_t
struct stat sb;
int error, fd, len, count;
struct timespec rqtp;
+ pid_t dummy;
pfh = malloc(sizeof(*pfh));
if (pfh == NULL)
@@ -126,7 +127,9 @@ pidfile_open(const char *path, mode_t mode, pid_t
fd = flopen(pfh-pf_path,
O_WRONLY | O_CREAT | O_TRUNC | O_CLOEXEC | O_NONBLOCK, mode);
if (fd == -1) {
- if (errno == EWOULDBLOCK pidptr != NULL) {
+ if (errno == EWOULDBLOCK) {
+ if (pidptr == NULL)
+ pidptr = dummy;
count = 20;
rqtp.tv_sec = 0;
rqtp.tv_nsec = 500;
--
John Baldwin
___
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: pidfile_open incorrectly returns EAGAIN when pidfile is locked
On Wed, Mar 13, 2013 at 11:18:36AM -0400, John Baldwin wrote:
On Tuesday, March 12, 2013 4:16:32 pm Dirk Engling wrote:
While debugging my own daemon I noticed that pidfile_open does not
perform the appropriate checks for a running daemon if the caller does
not provide a pidptr to pidfile_open
fd = flopen(pfh-pf_path,
O_WRONLY | O_CREAT | O_TRUNC | O_CLOEXEC | O_NONBLOCK, mode);
fails when another daemon holds the lock and flopen sets errno to
EAGAIN, the check 4 lines below in
if (errno == EWOULDBLOCK pidptr != NULL) {
means that the pidfile_read is never executed.
This results in my second daemon receiving an EAGAIN which clearly was
meant to report a race condition between two daemons starting at the
same time and the first one not yet finishing pidfile_write.
The expected behavior would be to set errno to EEXIST, even if no pidptr
was passed.
Yes, I think it should actually perform the same logic even if pidptr is
NULL of waiting for the other daemon to finish starting up. Something like
this:
Index: lib/libutil/pidfile.c
===
--- pidfile.c (revision 248162)
+++ pidfile.c (working copy)
@@ -100,6 +100,7 @@ pidfile_open(const char *path, mode_t mode, pid_t
struct stat sb;
int error, fd, len, count;
struct timespec rqtp;
+ pid_t dummy;
pfh = malloc(sizeof(*pfh));
if (pfh == NULL)
@@ -126,7 +127,9 @@ pidfile_open(const char *path, mode_t mode, pid_t
fd = flopen(pfh-pf_path,
O_WRONLY | O_CREAT | O_TRUNC | O_CLOEXEC | O_NONBLOCK, mode);
if (fd == -1) {
- if (errno == EWOULDBLOCK pidptr != NULL) {
+ if (errno == EWOULDBLOCK) {
+ if (pidptr == NULL)
+ pidptr = dummy;
count = 20;
rqtp.tv_sec = 0;
rqtp.tv_nsec = 500;
I agree EEXIST should be returned, but I don't like reading existing
pidfile (including waiting for the other process to write its PID) just
to throw read PID away.
How about this patch?
http://people.freebsd.org/~pjd/patches/pidfile.c.patch
--
Pawel Jakub Dawidek http://www.wheelsystems.com
FreeBSD committer http://www.FreeBSD.org
Am I Evil? Yes, I Am! http://tupytaj.pl
pgp85B_RZoSMW.pgp
Description: PGP signature
Re: pidfile_open incorrectly returns EAGAIN when pidfile is locked
On Wed, 13 Mar 2013, Pawel Jakub Dawidek wrote:
How about this patch?
http://people.freebsd.org/~pjd/patches/pidfile.c.patch
If you move the lines
+ if (errno == 0 || errno == EAGAIN)
+ errno = EEXIST;
out of the else branch, you can get rid of the if branch, guard the else
branch by a
+ if (pidptr) {
and let the if (errno == 0 || errno == EAGAIN) fix the errno
Regards,
erdgeist
___
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: pidfile_open incorrectly returns EAGAIN when pidfile is locked
On Wed, Mar 13, 2013 at 10:59:17PM +0100, Dirk Engling wrote:
On Wed, 13 Mar 2013, Pawel Jakub Dawidek wrote:
How about this patch?
http://people.freebsd.org/~pjd/patches/pidfile.c.patch
If you move the lines
+ if (errno == 0 || errno == EAGAIN)
+ errno = EEXIST;
out of the else branch, you can get rid of the if branch, guard the else
branch by a
+ if (pidptr) {
and let the if (errno == 0 || errno == EAGAIN) fix the errno
I think I considered something similar at first, but the change I
proposed was optimal, IMHO at the cost of producing pretty large diff,
because of indentation change. But to be sure, can you send a patch of
your proposed change?
--
Pawel Jakub Dawidek http://www.wheelsystems.com
FreeBSD committer http://www.FreeBSD.org
Am I Evil? Yes, I Am! http://tupytaj.pl
pgp1futIji1g8.pgp
Description: PGP signature
FYI - warning: KLD
FreeBSD FBSD10 10.0-CURRENT FreeBSD 10.0-CURRENT #37 r248259: Wed Mar 13 21:46:51 CDT 2013 root@FBSD10:/usr/obj/usr/src/sys/MYKERNEL amd64 I just wanted to report something that I don't recall seeing before. After updating to r248259 on Wed Mar 13 23:00:02 CDT 2013, I experienced a system freeze that required a power cycle. I noticed the following on verbose boot. From dmesg: warning: KLD '/boot/kernel/linprocfs.ko' is newer than the linker.hints file Just a heads up in case it's the symptom of another issue. # dmesg |grep warning warning: KLD '/boot/kernel/linprocfs.ko' is newer than the linker.hints file warning: KLD '/boot/kernel/ums.ko' is newer than the linker.hints file warning: KLD '/boot/kernel/uhid.ko' is newer than the linker.hints file ___ 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
reservation of n, n (3) failed
Hi, I swapped out the CPU on this machine today, I don't recall seeing these messages previously: acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, bfcd (3) failed Does anyone have an idea about what this refers to? Here's the boot log. uname -a FreeBSD dx.burplex.com 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r248165: Mon Mar 11 18:20:30 PDT 2013 r...@dx.burplex.com:/usr/obj/usr/src/sys/FURAHA amd64 Copyright (c) 1992-2013 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.0-CURRENT #0 r248165: Mon Mar 11 18:20:30 PDT 2013 r...@dx.burplex.com:/usr/obj/usr/src/sys/FURAHA amd64 FreeBSD clang version 3.2 (tags/RELEASE_32/final 170710) 20121221 CPU: AMD FX(tm)-8350 Eight-Core Processor(4027.01-MHz K8-class CPU) Origin = AuthenticAMD Id = 0x600f20 Family = 0x15 Model = 0x2 Stepping = 0 Features=0x178bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,C MOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT Features2=0x3e98320bSSE3,PCLMULQDQ,MON,SSSE3,FMA,CX16,SSE4.1,SSE4.2,POPCNT,AE SNI,XSAVE,OSXSAVE,AVX,F16C AMD Features=0x2e500800SYSCALL,NX,MMX+,FFXSR,Page1GB,RDTSCP,LM AMD Features2=0x1ebbfffLAHF,CMP,SVM,ExtAPIC,CR8,ABM,SSE4A,MAS,Prefetch,OSVW,I BS,XOP,SKINIT,WDT,LWP,FMA4,b17,NodeId,TBM,Topology,b23,b24 Standard Extended Features=0x8 TSC: P-state invariant, performance statistics real memory = 34359738368 (32768 MB) avail memory = 33082753024 (31550 MB) Event timer LAPIC quality 400 ACPI APIC Table: GBTGBTUACPI FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs FreeBSD/SMP: 1 package(s) x 8 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 cpu4 (AP): APIC ID: 4 cpu5 (AP): APIC ID: 5 cpu6 (AP): APIC ID: 6 cpu7 (AP): APIC ID: 7 ioapic0: Changing APIC ID to 8 ioapic0 Version 2.1 irqs 0-23 on motherboard acpi0: GBT GBTUACPI on motherboard acpi0: Power Button (fixed) acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, bfcd (3) failed cpu0: ACPI CPU on acpi0 cpu1: ACPI CPU on acpi0 cpu2: ACPI CPU on acpi0 cpu3: ACPI CPU on acpi0 cpu4: ACPI CPU on acpi0 cpu5: ACPI CPU on acpi0 cpu6: ACPI CPU on acpi0 cpu7: ACPI CPU on acpi0 attimer0: AT timer port 0x40-0x43 on acpi0 Timecounter i8254 frequency 1193182 Hz quality 0 Event timer i8254 frequency 1193182 Hz quality 100 hpet0: High Precision Event Timer iomem 0xfed0-0xfed003ff irq 0,8 on acpi0 Timecounter HPET frequency 14318180 Hz quality 950 atrtc0: AT realtime clock port 0x70-0x73 on acpi0 Event timer RTC frequency 32768 Hz quality 0 Timecounter ACPI-safe frequency 3579545 Hz quality 850 Thank you, -- Waitman Gobble San Jose California USA ___ 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
