Re: dot snap folder
On Sun, Jan 15, 2012 at 09:54:52PM -0800, Chip Camden wrote: > Quoth Polytropon on Monday, 16 January 2012: > > On Sun, 15 Jan 2012 15:40:20 -0800, Jim Pazarena wrote: > > > Is it permissible to delete the dot snap folder which is created > > > in a filesystem? > > > > First of all, it's called a directory, not a "folder". :-) > > > > After all, it doesn't fold (for that you need a little Haskell or OCaml). Hmm. That was direct. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: access(FULLPATH, xxx);
On Mon, 16 Jan 2012 12:03:52 +1000, Da Rock wrote: > On 01/14/12 22:06, Polytropon wrote: > > On Sat, 14 Jan 2012 20:37:14 +1000, Da Rock wrote: > >> On 01/14/12 19:54, Robert Bonomi wrote: > From owner-freebsd-questi...@freebsd.org Sat Jan 14 02:32:15 2012 > Date: Sat, 14 Jan 2012 09:28:21 +0100 > From: Polytropon > To: Robert Bonomi > Cc: freebsd-questions@freebsd.org > Subject: Re: access(FULLPATH, xxx); > > On Sat, 14 Jan 2012 02:00:12 -0600 (CST), Robert Bonomi wrote: > > To repeat some advice from one of my Computer Science professors, many > > years > > ago, whenever I asked 'how does it work' questions: "Try it and find > > out." > I bet my professor can beat up your professor. :-) > > Mine used to say several times: "Trial and error is NOT > a programming concept!" > >>> As far as writing applications goes, that is _somewhat_ correct. > >>> > >>> However, 'trial and error' is _not_ the same thing as 'try it and find > >>> out'. > >>> See the entire subject area of 'benchmarking'. > >>> > >>> And, the only way to definitively establish if an alternate approach is > >>> 'better' -- i.e. 'faster', or 'smaller', or 'more efficient', etc. -- *IS* > >>> to run a trial. > >>> > >>> Your professor undoubtedly would not of approved when I wrote bubble-sort > >>> code that _out-performed_ any other sorting technique -- up to the limits > >>> of memory. Or when I re-wrote an application that used binary searches > >>> of records, with a new version that used a brute-force linear search. I > >>> thought I could 'do it better/faster' than the existing code, but the only > >>> way to "definitively" find out was to 'try it'. And the 'trial' proved > >>> out -- the replacement code was 'merely' somewhat over 100 times faster. > >>> *grin* > >> Ha! Love it... :D > > Mee too - except that I didn't want to show that > > "typical attitude". In fact, I tried to make a > > (kinf of humourical) statement about a habit that > > I could observe at many students when I was at > > university. > > > > Background: > > > > When you write source code, you can make errors. > > Compiler shows errors. Some students started > > with "trial& error" to just silence the compiler. > > One form was that all functional parts of the > > program were enclosed in /* and */ (it was a > > C class) - no errors, but no action. A different > > approach was to arbitrarily (!) change the source > > code, something like that: > > > > void *foo(int blah, void *meow())(int ouch); > > > > Hmmm... gives me segfaults. Maybe something's > > wrong with the pointers? > > > > void *foo(int blah, void **meow())(int ouch); > > > > Not much better, segfaults too. How about that? > > > > void *foo(int blah, void meow())(int *ouch); > > > > Well... also not better. I've heared about parentheses, > > maybe those can help? > > > > void *foo(int blah), void *meow)(int ouch); > > > > Shit, doesn't even compile anymore! Uhm... _what_ did > > I change? Oh wait, I know: > > > > void *foo(int blah, (void *)meow())(int ouch); > > > > Just produces garbage, then segfaults... what could I > > change next? > > > > I think you get the idea. > > > > Other students could not understand that even if a > > program compiles without any errors, there _may_ be > > the possibility that it doesn't do what they intended > > it to do. They seemed to believe in some kind of > > magical "semantic compiler": > > > > int x, y, sum; > > x = 100; > > y = 250; > > sum = a - b; > > > > They expected the compiler to notice what's wrong here > > if you consider the _meaning_ of the identifiers. It's > > not that obvious if you use x, y, and z. :-) > > > > > > > >>> As far as 'doing it once' for the purpose of answering a 'how does it > >>> work' > >>> question -- where one has _not_ read the documentation, *OR* the existing > >>> documentation is _not_clear_, then simple experimentation -- to get *the* > >>> authoritative answer -- is entirly justified. > >>> > >>> When I got the 'try it and find out' advice, I was asking questions about > >>> situations where the language _specification_ was unclear -- there were > >>> two 'reasonable interpretations' of what the language inthe speciication > >>> said, and I just wanted to know which one was the proper interpretation. > >>> > >>> Now, given that the language in the specification _was_ abiguous and both > >>> interpretations were reasonsble, different compiler builders could have > >>> implemented differently, and 'try it and find out' was _necessary_ to > >>> establish what that particular implementation did. > >> There appears to be 2 schools of thought on this subject: a classic case > >> of the "old" vs the "new", in this case "punchcards/slow compilers" vs > >> "gcc/all-in-one compile, link and go"of todays tech. I saw a similar > >> conversation about 5 years ago on the linux lists... :) > > I didn't want to complai
Re: COMPAT_* kernel config options -- some housecleaning overdue?
Hi,
"Conrad J. Sabatier" wrote:
> I've been wondering for a while now about the accuracy of some of the
> comments in /sys/conf/NOTES re: the various COMPAT_* options, and now,
> with 9.0-RELEASE already out the door and 10.0-CURRENT as the current
> development branch, it seems even more relevant to ask just how
> necessary or useful some of these options are anymore.
>
> Let me preface the following by saying that I just recently built a
> 10.0-CURRENT kernel with no COMPAT_* options besides COMPAT_FREEBSD32
> and COMPAT_LINUX32, and everything seems to be working just fine (yes,
> including Linux emulation).
>
> First and foremost, the comment re: COMPAT_43: "You probably do NOT
> want to remove this as much current code still relies on the 4.3
> emulation."
This might not be just refering to code runing on FreeBSD, but
perhaps also code running on older other legacy net machines ? I suspect
I may have needed it to talk to eg my Symmetric 375 (a 4.2BSD Bill Jollitz
product pre 386BSD pre FreeBSD http://www.berklix.com/~jhs/symmetric/
) (Not that I put that comment in), it might be an ifdef
that allows adaptive detection of logic low & high for TCP broadcast
address ?
Whatever, searching & updated comments on what they all do would be nice.
Feel free to search the source with find & grep
& use send-pr to update the comments, would be useful :-)
cd /usr/src
vi -c/COMPAT_43TTY `find . -type f -exec grep -l COMPAT_43TTY {} \;`
dmesg
> This would appear to no longer be true. And similarly,
> how relevant or viable is COMPAT_43TTY anymore? Why would one want to
> use this?
To support legacy code/ apps. Warning "There be dragons" as it says
on old maps ;-) ie tty in Unix has traditionaly been a complex
place to mess around, personaly I'd stear clear & leave it to those
willing to futz about with tty :-).
> I suspect that neither of these options has any real effect
> anymore and both may, in fact, be essentially NOOPs. How close to the
> real picture is that?
>
> It is my understanding that, on 64-bit platforms, COMPAT_FREEBSD32
> *is* necessary if COMPAT_LINUX32 is enabled, which seems perfectly
> reasonable. However, the comment accompanying COMPAT_LINUX32 states
> that COMPAT_43 is also required, which simply is not true.
> And speaking of Linux compatibility, we still have an erroneous reference to
> COMPAT_LINUX instead of COMPAT_LINUX32 accompanying 'device tdfx'.
dmesg then
> Then, of course, there are the various COMPAT_FREEBSD[4-7] options,
> each accompanied by a comment which merely states the obvious but
> offers no real clue as to whether or not any of them are actually
> necessary.
was mentioned on another list in last few days
> I don't know, this whole COMPAT area just seems really messy to me --
> disorganized, unclearly documented and probably suffering from no small
> amount of bit rot and neglect. I really do think it's time for some
> cleaning up.
>
> Hope I didn't ruffle any feathers, but I just hate this type of gray
> fuzziness. Clarification (maybe even some deprecation?) seems to be in
> order here.
Yup, certainly needs clearer comments ... find ... grep ... vi ... dmesg :-)
Cheers,
Julian
--
Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com
Reply below not above, cumulative like a play script, & indent with "> ".
Format: Plain text. Not HTML, multipart/alternative, base64, quoted-printable.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: dot snap folder
Quoth Polytropon on Monday, 16 January 2012: > On Sun, 15 Jan 2012 15:40:20 -0800, Jim Pazarena wrote: > > Is it permissible to delete the dot snap folder which is created > > in a filesystem? > > First of all, it's called a directory, not a "folder". :-) > After all, it doesn't fold (for that you need a little Haskell or OCaml). -- .O. | Sterling (Chip) Camden | http://camdensoftware.com ..O | sterl...@camdensoftware.com | http://chipsquips.com OOO | 2048R/D6DBAF91 | http://chipstips.com pgpEbPoDy8cui.pgp Description: PGP signature
Re: dot snap folder
On Sun, 15 Jan 2012 15:40:20 -0800, Jim Pazarena wrote: > Is it permissible to delete the dot snap folder which is created > in a filesystem? First of all, it's called a directory, not a "folder". :-) The .snap directory in a partition's root directory is used by the program "dump" to store a snapshot of a live (i. e. possibly changing) file system prior to dumping it (i. e. it dumps the snapshot). See "man dump", the -L option: This option is to notify dump that it is dumping a live file sys- tem. To obtain a consistent dump image, dump takes a snapshot of the file system in the .snap directory in the root of the file system being dumped and then does a dump of the snapshot. The snapshot is unlinked as soon as the dump starts, and is thus removed when the dump is complete. This option is ignored for unmounted or read-only file systems. If the .snap directory does not exist in the root of the file system being dumped, a warning will be issued and the dump will revert to the standard behavior. This problem can be corrected by creating a .snap directory in the root of the file system to be dumped; its owner should be ``root'', its group should be ``operator'', and its mode should be ``0770''. *** So unless you're currently running a dump -L session, you can delete that directory. Maybe you need to be member of "operator" or be "root" in order to do it due to access permissions described above. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
[SOLVED] Re: buildworld -DWITHOUT_OPENSSL fails at usr.sbin/wpa/wpa_supplicant (all) (was usr.sbin/wpa/hostapd (depend) (was: lib/libbsnmp/libbsnmp (all) (was: lib/libarchive (depend))))
On Jan 15, 2012, at 7:28 PM, Devin Teske wrote:
>
> On Jan 15, 2012, at 5:57 PM, Devin Teske wrote:
>
>>
>> On Jan 15, 2012, at 10:43 AM, Devin Teske wrote:
>>
>>>
>>> On Jan 15, 2012, at 10:11 AM, Devin Teske wrote:
On Jan 13, 2012, at 7:28 PM, Devin Teske wrote:
> Trying to buildworld in RELENG_9 with -DWITHOUT_OPENSSL and getting
> failures.
>
> First failure we encountered required the following patch to get past
> "lib/libarchive (depend)"...
>
>>
>> --- lib/libarchive/config_freebsd.h.orig 2012-01-05 03:44:55.0
>> -0800
>> +++ lib/libarchive/config_freebsd.h 2012-01-13 18:43:46.0
>> -0800
>> @@ -176,9 +176,4 @@
>> #define ARCHIVE_HASH_SHA256_OPENSSL 1
>> #define ARCHIVE_HASH_SHA384_OPENSSL 1
>> #define ARCHIVE_HASH_SHA512_OPENSSL 1
>> -#else
>> -#define ARCHIVE_HASH_MD5_LIBC 1
>> -#define ARCHIVE_HASH_SHA1_LIBC 1
>> -#define ARCHIVE_HASH_SHA256_LIBC 1
>> -#define ARCHIVE_HASH_SHA512_LIBC 1
>> #endif
>>
>> The above patch allowed the mkdep to succeed and later-compilation in
>> the same directory succeeded (yay).
>
> However, you don't get far before the next error.
>
> Making all in lib/libbsnmp/libbsnmp with -DWITHOUT_OPENSSL...
>
> cc -I/usr/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib
> -DHAVE_ERR_H -DHAVE_GETADDRINFO -DHAVE_STRLCPY -DHAVE_STDINT_H
> -DHAVE_INTTYPES_H -DQUADFMT='"llu"' -DQUADXFMT='"llx"' -std=gnu99
> -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W
> -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes
> -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch
> -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline
> -Wnested-externs -Wredundant-decls -Wold-style-definition
> -Wno-pointer-sign -c
> /usr/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib/snmpcrypto.c
> /usr/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib/snmpcrypto.c:371:
> error: conflicting types for 'snmp_passwd_to_keys'
> /usr/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib/snmp.h:273:
> error: previous declaration of 'snmp_passwd_to_keys' was here
> /usr/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib/snmpcrypto.c:384:
> error: conflicting types for 'snmp_get_local_keys'
> /usr/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib/snmp.h:274:
> error: previous declaration of 'snmp_get_local_keys' was here
>
The solution to this appears to be the following patch:
= BEGIN PATCH ==
--- contrib/bsnmp/lib/snmpcrypto.c.orig2011-09-22 17:51:37.0
-0700
+++ contrib/bsnmp/lib/snmpcrypto.c 2012-01-15 09:49:27.0 -0800
@@ -366,7 +366,7 @@ snmp_pdu_decrypt(const struct snmp_pdu *
return (SNMP_CODE_OK);
}
-int
+enum snmp_code
snmp_passwd_to_keys(struct snmp_user *user, char *passwd __unused)
{
if (user->auth_proto == SNMP_AUTH_NOAUTH &&
@@ -378,7 +378,7 @@ snmp_passwd_to_keys(struct snmp_user *us
return (SNMP_CODE_FAILED);
}
-int
+enum snmp_code
snmp_get_local_keys(struct snmp_user *user, uint8_t *eid __unused,
uint32_t elen __unused)
{
== END PATCH ==
>>>
>>> Then you churn along for some lengthy time (even making it all the way
>>> through clang successfully), but then stop again at usr.sbin/wpa/hostapd
>>> (depend) (output at end).
>>>
>>> Probably going to be a patch similar to the libarchive one.
>>> --
>>> Devin
>>>
>>>
>>> ===> usr.sbin/wpa/hostapd (depend)
>>> rm -f .depend
>>> mkdep -f .depend -a-DDRUID -I/usr/src/usr.sbin/wpa/hostapd
>>> -I/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src
>>> -I/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/common
>>> -I/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/crypto
>>> -I/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/l2_packet
>>> -I/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/utils
>>> -DCONFIG_CTRL_IFACE -DCONFIG_CTRL_IFACE_UNIX
>>> -I/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//hostapd
>>> -I/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/drivers
>>> -DCONFIG_DRIVER_BSD -DHOSTAPD -DCONFIG_DRIVER_RADIUS_ACL -DCONFIG_IPV6
>>> -DEAP_TLS_NONE -DINTERNAL_AES -DINTERNAL_SHA1 -DINTERNAL_MD5
>>> -I/usr/src/usr.sbin/wpa/hostapd
>>> -I/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src
>>> -I/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/common
>>> -I/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/crypto
>>> -I/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/l2_packet
>>> -I/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/utils
>>> -DCONFIG_CTRL_IFACE -DCONFIG_CTRL_IFACE_UNIX
>>> /usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/ap
Re: buildworld -DWITHOUT_OPENSSL fails at usr.sbin/wpa/wpa_supplicant (all) (was usr.sbin/wpa/hostapd (depend) (was: lib/libbsnmp/libbsnmp (all) (was: lib/libarchive (depend))))
On Jan 15, 2012, at 5:57 PM, Devin Teske wrote:
>
> On Jan 15, 2012, at 10:43 AM, Devin Teske wrote:
>
>>
>> On Jan 15, 2012, at 10:11 AM, Devin Teske wrote:
>>> On Jan 13, 2012, at 7:28 PM, Devin Teske wrote:
Trying to buildworld in RELENG_9 with -DWITHOUT_OPENSSL and getting
failures.
First failure we encountered required the following patch to get past
"lib/libarchive (depend)"...
>
> --- lib/libarchive/config_freebsd.h.orig 2012-01-05 03:44:55.0
> -0800
> +++ lib/libarchive/config_freebsd.h 2012-01-13 18:43:46.0
> -0800
> @@ -176,9 +176,4 @@
> #define ARCHIVE_HASH_SHA256_OPENSSL 1
> #define ARCHIVE_HASH_SHA384_OPENSSL 1
> #define ARCHIVE_HASH_SHA512_OPENSSL 1
> -#else
> -#define ARCHIVE_HASH_MD5_LIBC 1
> -#define ARCHIVE_HASH_SHA1_LIBC 1
> -#define ARCHIVE_HASH_SHA256_LIBC 1
> -#define ARCHIVE_HASH_SHA512_LIBC 1
> #endif
>
> The above patch allowed the mkdep to succeed and later-compilation in the
> same directory succeeded (yay).
However, you don't get far before the next error.
Making all in lib/libbsnmp/libbsnmp with -DWITHOUT_OPENSSL...
cc -I/usr/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib
-DHAVE_ERR_H -DHAVE_GETADDRINFO -DHAVE_STRLCPY -DHAVE_STDINT_H
-DHAVE_INTTYPES_H -DQUADFMT='"llu"' -DQUADXFMT='"llx"' -std=gnu99
-fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W
-Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes
-Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch
-Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline
-Wnested-externs -Wredundant-decls -Wold-style-definition
-Wno-pointer-sign -c
/usr/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib/snmpcrypto.c
/usr/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib/snmpcrypto.c:371:
error: conflicting types for 'snmp_passwd_to_keys'
/usr/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib/snmp.h:273:
error: previous declaration of 'snmp_passwd_to_keys' was here
/usr/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib/snmpcrypto.c:384:
error: conflicting types for 'snmp_get_local_keys'
/usr/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib/snmp.h:274:
error: previous declaration of 'snmp_get_local_keys' was here
>>>
>>> The solution to this appears to be the following patch:
>>>
>>> = BEGIN PATCH ==
>>> --- contrib/bsnmp/lib/snmpcrypto.c.orig 2011-09-22 17:51:37.0
>>> -0700
>>> +++ contrib/bsnmp/lib/snmpcrypto.c 2012-01-15 09:49:27.0 -0800
>>> @@ -366,7 +366,7 @@ snmp_pdu_decrypt(const struct snmp_pdu *
>>> return (SNMP_CODE_OK);
>>> }
>>>
>>> -int
>>> +enum snmp_code
>>> snmp_passwd_to_keys(struct snmp_user *user, char *passwd __unused)
>>> {
>>> if (user->auth_proto == SNMP_AUTH_NOAUTH &&
>>> @@ -378,7 +378,7 @@ snmp_passwd_to_keys(struct snmp_user *us
>>> return (SNMP_CODE_FAILED);
>>> }
>>>
>>> -int
>>> +enum snmp_code
>>> snmp_get_local_keys(struct snmp_user *user, uint8_t *eid __unused,
>>> uint32_t elen __unused)
>>> {
>>>
>>> == END PATCH ==
>>>
>>
>> Then you churn along for some lengthy time (even making it all the way
>> through clang successfully), but then stop again at usr.sbin/wpa/hostapd
>> (depend) (output at end).
>>
>> Probably going to be a patch similar to the libarchive one.
>> --
>> Devin
>>
>>
>> ===> usr.sbin/wpa/hostapd (depend)
>> rm -f .depend
>> mkdep -f .depend -a-DDRUID -I/usr/src/usr.sbin/wpa/hostapd
>> -I/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src
>> -I/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/common
>> -I/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/crypto
>> -I/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/l2_packet
>> -I/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/utils
>> -DCONFIG_CTRL_IFACE -DCONFIG_CTRL_IFACE_UNIX
>> -I/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//hostapd
>> -I/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/drivers
>> -DCONFIG_DRIVER_BSD -DHOSTAPD -DCONFIG_DRIVER_RADIUS_ACL -DCONFIG_IPV6
>> -DEAP_TLS_NONE -DINTERNAL_AES -DINTERNAL_SHA1 -DINTERNAL_MD5
>> -I/usr/src/usr.sbin/wpa/hostapd
>> -I/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src
>> -I/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/common
>> -I/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/crypto
>> -I/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/l2_packet
>> -I/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/utils
>> -DCONFIG_CTRL_IFACE -DCONFIG_CTRL_IFACE_UNIX
>> /usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/ap/accounting.c
>> /usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/crypto/aes-wrap.c
>> /usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/ap
Re: access(FULLPATH, xxx);
On 01/14/12 22:06, Polytropon wrote: On Sat, 14 Jan 2012 20:37:14 +1000, Da Rock wrote: On 01/14/12 19:54, Robert Bonomi wrote: From owner-freebsd-questi...@freebsd.org Sat Jan 14 02:32:15 2012 Date: Sat, 14 Jan 2012 09:28:21 +0100 From: Polytropon To: Robert Bonomi Cc: freebsd-questions@freebsd.org Subject: Re: access(FULLPATH, xxx); On Sat, 14 Jan 2012 02:00:12 -0600 (CST), Robert Bonomi wrote: To repeat some advice from one of my Computer Science professors, many years ago, whenever I asked 'how does it work' questions: "Try it and find out." I bet my professor can beat up your professor. :-) Mine used to say several times: "Trial and error is NOT a programming concept!" As far as writing applications goes, that is _somewhat_ correct. However, 'trial and error' is _not_ the same thing as 'try it and find out'. See the entire subject area of 'benchmarking'. And, the only way to definitively establish if an alternate approach is 'better' -- i.e. 'faster', or 'smaller', or 'more efficient', etc. -- *IS* to run a trial. Your professor undoubtedly would not of approved when I wrote bubble-sort code that _out-performed_ any other sorting technique -- up to the limits of memory. Or when I re-wrote an application that used binary searches of records, with a new version that used a brute-force linear search. I thought I could 'do it better/faster' than the existing code, but the only way to "definitively" find out was to 'try it'. And the 'trial' proved out -- the replacement code was 'merely' somewhat over 100 times faster. *grin* Ha! Love it... :D Mee too - except that I didn't want to show that "typical attitude". In fact, I tried to make a (kinf of humourical) statement about a habit that I could observe at many students when I was at university. Background: When you write source code, you can make errors. Compiler shows errors. Some students started with "trial& error" to just silence the compiler. One form was that all functional parts of the program were enclosed in /* and */ (it was a C class) - no errors, but no action. A different approach was to arbitrarily (!) change the source code, something like that: void *foo(int blah, void *meow())(int ouch); Hmmm... gives me segfaults. Maybe something's wrong with the pointers? void *foo(int blah, void **meow())(int ouch); Not much better, segfaults too. How about that? void *foo(int blah, void meow())(int *ouch); Well... also not better. I've heared about parentheses, maybe those can help? void *foo(int blah), void *meow)(int ouch); Shit, doesn't even compile anymore! Uhm... _what_ did I change? Oh wait, I know: void *foo(int blah, (void *)meow())(int ouch); Just produces garbage, then segfaults... what could I change next? I think you get the idea. Other students could not understand that even if a program compiles without any errors, there _may_ be the possibility that it doesn't do what they intended it to do. They seemed to believe in some kind of magical "semantic compiler": int x, y, sum; x = 100; y = 250; sum = a - b; They expected the compiler to notice what's wrong here if you consider the _meaning_ of the identifiers. It's not that obvious if you use x, y, and z. :-) As far as 'doing it once' for the purpose of answering a 'how does it work' question -- where one has _not_ read the documentation, *OR* the existing documentation is _not_clear_, then simple experimentation -- to get *the* authoritative answer -- is entirly justified. When I got the 'try it and find out' advice, I was asking questions about situations where the language _specification_ was unclear -- there were two 'reasonable interpretations' of what the language inthe speciication said, and I just wanted to know which one was the proper interpretation. Now, given that the language in the specification _was_ abiguous and both interpretations were reasonsble, different compiler builders could have implemented differently, and 'try it and find out' was _necessary_ to establish what that particular implementation did. There appears to be 2 schools of thought on this subject: a classic case of the "old" vs the "new", in this case "punchcards/slow compilers" vs "gcc/all-in-one compile, link and go"of todays tech. I saw a similar conversation about 5 years ago on the linux lists... :) I didn't want to complain about using a test case, with determined variables (relative path vs. absolute path) to see if the interpretation of "man 2 access" was matching the actual inner workings of the function in use. In fact, I would even judge this the _preferred_ method to be sure. In the light of this conversation and given todays tech I'd say give it a shot unless you think something could break (as in fatal to service quality in production/hardware). Fully agree. Know your variables and construct a test within a fixed environment. The result will be a valid source of conclusion.
Re: buildworld -DWITHOUT_OPENSSL fails at usr.sbin/wpa/wpa_supplicant (all) (was usr.sbin/wpa/hostapd (depend) (was: lib/libbsnmp/libbsnmp (all) (was: lib/libarchive (depend))))
On Jan 15, 2012, at 10:43 AM, Devin Teske wrote:
>
> On Jan 15, 2012, at 10:11 AM, Devin Teske wrote:
>> On Jan 13, 2012, at 7:28 PM, Devin Teske wrote:
>>> Trying to buildworld in RELENG_9 with -DWITHOUT_OPENSSL and getting
>>> failures.
>>>
>>> First failure we encountered required the following patch to get past
>>> "lib/libarchive (depend)"...
>>>
--- lib/libarchive/config_freebsd.h.orig 2012-01-05 03:44:55.0
-0800
+++ lib/libarchive/config_freebsd.h2012-01-13 18:43:46.0
-0800
@@ -176,9 +176,4 @@
#defineARCHIVE_HASH_SHA256_OPENSSL 1
#defineARCHIVE_HASH_SHA384_OPENSSL 1
#defineARCHIVE_HASH_SHA512_OPENSSL 1
-#else
-#define ARCHIVE_HASH_MD5_LIBC 1
-#define ARCHIVE_HASH_SHA1_LIBC 1
-#define ARCHIVE_HASH_SHA256_LIBC 1
-#define ARCHIVE_HASH_SHA512_LIBC 1
#endif
The above patch allowed the mkdep to succeed and later-compilation in the
same directory succeeded (yay).
>>>
>>> However, you don't get far before the next error.
>>>
>>> Making all in lib/libbsnmp/libbsnmp with -DWITHOUT_OPENSSL...
>>>
>>> cc -I/usr/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib
>>> -DHAVE_ERR_H -DHAVE_GETADDRINFO -DHAVE_STRLCPY -DHAVE_STDINT_H
>>> -DHAVE_INTTYPES_H -DQUADFMT='"llu"' -DQUADXFMT='"llx"' -std=gnu99
>>> -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W
>>> -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes
>>> -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow
>>> -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs
>>> -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c
>>> /usr/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib/snmpcrypto.c
>>> /usr/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib/snmpcrypto.c:371:
>>> error: conflicting types for 'snmp_passwd_to_keys'
>>> /usr/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib/snmp.h:273:
>>> error: previous declaration of 'snmp_passwd_to_keys' was here
>>> /usr/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib/snmpcrypto.c:384:
>>> error: conflicting types for 'snmp_get_local_keys'
>>> /usr/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib/snmp.h:274:
>>> error: previous declaration of 'snmp_get_local_keys' was here
>>>
>>
>> The solution to this appears to be the following patch:
>>
>> = BEGIN PATCH ==
>> --- contrib/bsnmp/lib/snmpcrypto.c.orig 2011-09-22 17:51:37.0
>> -0700
>> +++ contrib/bsnmp/lib/snmpcrypto.c 2012-01-15 09:49:27.0 -0800
>> @@ -366,7 +366,7 @@ snmp_pdu_decrypt(const struct snmp_pdu *
>> return (SNMP_CODE_OK);
>> }
>>
>> -int
>> +enum snmp_code
>> snmp_passwd_to_keys(struct snmp_user *user, char *passwd __unused)
>> {
>> if (user->auth_proto == SNMP_AUTH_NOAUTH &&
>> @@ -378,7 +378,7 @@ snmp_passwd_to_keys(struct snmp_user *us
>> return (SNMP_CODE_FAILED);
>> }
>>
>> -int
>> +enum snmp_code
>> snmp_get_local_keys(struct snmp_user *user, uint8_t *eid __unused,
>>uint32_t elen __unused)
>> {
>>
>> == END PATCH ==
>>
>
> Then you churn along for some lengthy time (even making it all the way
> through clang successfully), but then stop again at usr.sbin/wpa/hostapd
> (depend) (output at end).
>
> Probably going to be a patch similar to the libarchive one.
> --
> Devin
>
>
> ===> usr.sbin/wpa/hostapd (depend)
> rm -f .depend
> mkdep -f .depend -a-DDRUID -I/usr/src/usr.sbin/wpa/hostapd
> -I/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src
> -I/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/common
> -I/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/crypto
> -I/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/l2_packet
> -I/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/utils
> -DCONFIG_CTRL_IFACE -DCONFIG_CTRL_IFACE_UNIX
> -I/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//hostapd
> -I/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/drivers
> -DCONFIG_DRIVER_BSD -DHOSTAPD -DCONFIG_DRIVER_RADIUS_ACL -DCONFIG_IPV6
> -DEAP_TLS_NONE -DINTERNAL_AES -DINTERNAL_SHA1 -DINTERNAL_MD5
> -I/usr/src/usr.sbin/wpa/hostapd
> -I/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src
> -I/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/common
> -I/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/crypto
> -I/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/l2_packet
> -I/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/utils
> -DCONFIG_CTRL_IFACE -DCONFIG_CTRL_IFACE_UNIX
> /usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/ap/accounting.c
> /usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/crypto/aes-wrap.c
> /usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/ap/ap_config.c
> /usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/ap/ap_drv_ops.c
> /usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/ap/ap_mlme.
COMPAT_* kernel config options -- some housecleaning overdue?
I've been wondering for a while now about the accuracy of some of the comments in /sys/conf/NOTES re: the various COMPAT_* options, and now, with 9.0-RELEASE already out the door and 10.0-CURRENT as the current development branch, it seems even more relevant to ask just how necessary or useful some of these options are anymore. Let me preface the following by saying that I just recently built a 10.0-CURRENT kernel with no COMPAT_* options besides COMPAT_FREEBSD32 and COMPAT_LINUX32, and everything seems to be working just fine (yes, including Linux emulation). First and foremost, the comment re: COMPAT_43: "You probably do NOT want to remove this as much current code still relies on the 4.3 emulation." This would appear to no longer be true. And similarly, how relevant or viable is COMPAT_43TTY anymore? Why would one want to use this? I suspect that neither of these options has any real effect anymore and both may, in fact, be essentially NOOPs. How close to the real picture is that? It is my understanding that, on 64-bit platforms, COMPAT_FREEBSD32 *is* necessary if COMPAT_LINUX32 is enabled, which seems perfectly reasonable. However, the comment accompanying COMPAT_LINUX32 states that COMPAT_43 is also required, which simply is not true. And speaking of Linux compatibility, we still have an erroneous reference to COMPAT_LINUX instead of COMPAT_LINUX32 accompanying 'device tdfx'. Then, of course, there are the various COMPAT_FREEBSD[4-7] options, each accompanied by a comment which merely states the obvious but offers no real clue as to whether or not any of them are actually necessary. I don't know, this whole COMPAT area just seems really messy to me -- disorganized, unclearly documented and probably suffering from no small amount of bit rot and neglect. I really do think it's time for some cleaning up. Hope I didn't ruffle any feathers, but I just hate this type of gray fuzziness. Clarification (maybe even some deprecation?) seems to be in order here. Thank you. -- Conrad J. Sabatier conr...@cox.net ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: dot snap folder
On Sun, Jan 15, 2012 at 6:40 PM, Jim Pazarena wrote: > Is it permissible to delete the dot snap folder which is created > in a filesystem? See dump(8) -L option. Deleting .snap is safe as long you don't need to dump that file system while it is mounted in rw mode. - Max ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
dot snap folder
Is it permissible to delete the dot snap folder which is created in a filesystem? -- Jim Pazarena fqu...@paz.bz ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: 9.0 buildworld problems
On 15.01.2012 12:51, Dean E. Weimer wrote: It appears to be the following lines in make.conf: SENDMAIL_CFLAGS=-I/usr/local/include/sasl -DSASL SENDMAIL_LDADD=-lsasl2 /usr/src/lib/libmilter/../../contrib/sendmail/src/sendmail.h:142:20: error: sasl.h: No such file or directory /usr/src/lib/libmilter/../../contrib/sendmail/src/sendmail.h:143:24: error: saslutil.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /usr/src/lib/libmilter. *** Error code 1 Stop in /usr/src/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. The system I was testing the upgrade process on of course already had cyrus-sasl and cyrus-sasl-salsauthd already installed. I am still waiting to see if the buildworld completes without those to lines. If it does, I will install the cyrus-sasl ports add the lines back in and rerun the buildworld. The buildworld, buildkernel, and install process all completed successfully after installing the cyrus-sasl ports. -- Thanks, Dean E. Weimer dwei...@dweimer.net http://www.dweimer.net/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Portmanager Status Report Gone
--As of January 15, 2012 3:35:20 PM -0500, Jerry is alleged to have said: You don't have to manually erase the tree. I believe that: "portsnap fetch extract" is all you need to do to replace the ports tree with a fresh copy. It won't hurt anything since it doesn't touch the configuration files. --As for the rest, it is mine. Done, and it didn't fix my problem. Something's obviously gone seriously weird with my system. What would happen if I did blow away the config files? What's the minimum necessary for my system to be able to manage it's ports collection? I really don't want to reinstall from scratch over this (If nothing else, it's my main fileserver. I've got backups, but that would take ages.), but I'm thinking rebuilding my ports database from bare bones sounds like it might be a good idea. Daniel T. Staal --- This email copyright the author. Unless otherwise noted, you are expressly allowed to retransmit, quote, or otherwise use the contents for non-commercial purposes. This copyright will expire 5 years after the author's death, or in 30 years, whichever is longer, unless such a period is in excess of local copyright law. --- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: SSD for ZIL suggestions?
On Fri, Jan 13, 2012 at 09:40:58PM -0600, Rob wrote: > I'm looking at getting a couple of SSDs to act as ZIL drives on FreeBSD > 8/9 systems. Are there any recommended drives? We recently bought the Intel 311 for that purpose. This drive is quite cheap and should perform ok. If you want something better have a look at the 710 line. You should always mirror your ZIL drives. There's a lot of content available on this subject actually. I once read about a tool called zilstat which should help you decide if you do actually need a SSD. NFS and db's are the usual usecases. cherio, Leon ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: ipv6 in FreeBSD 9
On Sun, 15 Jan 2012, the wise Erik Nørgaard wrote: Don't use ipv6, but reading above: Did you replace ipv6_enable with ipv6_activate_all_interfaces? because the error seems to tell you that you must keep ipv6_enable I replaced it with the new lines because according to the manpage ipv6_enable is deprecated. But why shouldn't I use ipv6? Sorry, meant to say, I don't use ipv6 so I can't do much debugging. Aaah, :-), perhaps I should have read better. Or, maybe there was an error with mergemaster? old scripts, new kernel variables? I ran mergemaster, but didn't get any error messages. Afaik all scripts in /etc are new. OK, in the error messages you posted it seems that some script checks or use these variables. Maybe try to run the different networking scripts manually and see where it fails. Thanks for the tip. I'll do some trial and error and dig deeper. -- Paul's Law: You can't fall off the floor.___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: ipv6 in FreeBSD 9
On 15/01/2012 21:41, Marco Beishuizen wrote: On Sun, 15 Jan 2012, the wise Erik Nørgaard wrote: Don't use ipv6, but reading above: Did you replace ipv6_enable with ipv6_activate_all_interfaces? because the error seems to tell you that you must keep ipv6_enable I replaced it with the new lines because according to the manpage ipv6_enable is deprecated. But why shouldn't I use ipv6? Sorry, meant to say, I don't use ipv6 so I can't do much debugging. Or, maybe there was an error with mergemaster? old scripts, new kernel variables? I ran mergemaster, but didn't get any error messages. Afaik all scripts in /etc are new. OK, in the error messages you posted it seems that some script checks or use these variables. Maybe try to run the different networking scripts manually and see where it fails. BR, Erik -- M: +34 666 334 818 T: +34 915 211 157 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
how to look debug info
Hi in sys/net/netisr.c I have found: SYSCTL_PROC(_net_isr, OID_AUTO, work, CTLFLAG_RD|CTLTYPE_STRUCT|CTLFLAG_MPSAFE, 0, 0, sysctl_netisr_work, "S,sysctl_netisr_work", "Return list of per-workstream, per-protocol work in netisr"); how to look that info? -- С уважением, Коньков mailto:kes-...@yandex.ru ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: ipv6 in FreeBSD 9
On Sun, 15 Jan 2012, the wise Erik Nørgaard wrote: Don't use ipv6, but reading above: Did you replace ipv6_enable with ipv6_activate_all_interfaces? because the error seems to tell you that you must keep ipv6_enable I replaced it with the new lines because according to the manpage ipv6_enable is deprecated. But why shouldn't I use ipv6? Or, maybe there was an error with mergemaster? old scripts, new kernel variables? I ran mergemaster, but didn't get any error messages. Afaik all scripts in /etc are new. Regards, Marco -- Kin, n.: An affliction of the blood.___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Portmanager Status Report Gone
On Sun, 15 Jan 2012 13:01:23 -0500 Daniel Staal articulated: > I have csup set to run once a week in cron. I don't think that > corrupted anything: `portmanager -s -y` ran fine before I ran > portmaster, and I didn't update the tree in between. But blowing > away the tree and re-creating it is starting to sound like something > worth a try. You don't have to manually erase the tree. I believe that: "portsnap fetch extract" is all you need to do to replace the ports tree with a fresh copy. It won't hurt anything since it doesn't touch the configuration files. -- Jerry ♔ Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: buildworld -DWITHOUT_OPENSSL fails at usr.sbin/wpa/hostapd (depend) (was: lib/libbsnmp/libbsnmp (all) (was: lib/libarchive (depend)))
On Jan 15, 2012, at 10:11 AM, Devin Teske wrote:
> On Jan 13, 2012, at 7:28 PM, Devin Teske wrote:
>> Trying to buildworld in RELENG_9 with -DWITHOUT_OPENSSL and getting failures.
>>
>> First failure we encountered required the following patch to get past
>> "lib/libarchive (depend)"...
>>
>>>
>>> --- lib/libarchive/config_freebsd.h.orig2012-01-05 03:44:55.0
>>> -0800
>>> +++ lib/libarchive/config_freebsd.h 2012-01-13 18:43:46.0 -0800
>>> @@ -176,9 +176,4 @@
>>> #define ARCHIVE_HASH_SHA256_OPENSSL 1
>>> #define ARCHIVE_HASH_SHA384_OPENSSL 1
>>> #define ARCHIVE_HASH_SHA512_OPENSSL 1
>>> -#else
>>> -#defineARCHIVE_HASH_MD5_LIBC 1
>>> -#defineARCHIVE_HASH_SHA1_LIBC 1
>>> -#defineARCHIVE_HASH_SHA256_LIBC 1
>>> -#defineARCHIVE_HASH_SHA512_LIBC 1
>>> #endif
>>>
>>> The above patch allowed the mkdep to succeed and later-compilation in the
>>> same directory succeeded (yay).
>>
>> However, you don't get far before the next error.
>>
>> Making all in lib/libbsnmp/libbsnmp with -DWITHOUT_OPENSSL...
>>
>> cc -I/usr/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib -DHAVE_ERR_H
>> -DHAVE_GETADDRINFO -DHAVE_STRLCPY -DHAVE_STDINT_H -DHAVE_INTTYPES_H
>> -DQUADFMT='"llu"' -DQUADXFMT='"llx"' -std=gnu99 -fstack-protector
>> -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter
>> -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type
>> -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter
>> -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls
>> -Wold-style-definition -Wno-pointer-sign -c
>> /usr/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib/snmpcrypto.c
>> /usr/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib/snmpcrypto.c:371:
>> error: conflicting types for 'snmp_passwd_to_keys'
>> /usr/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib/snmp.h:273: error:
>> previous declaration of 'snmp_passwd_to_keys' was here
>> /usr/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib/snmpcrypto.c:384:
>> error: conflicting types for 'snmp_get_local_keys'
>> /usr/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib/snmp.h:274: error:
>> previous declaration of 'snmp_get_local_keys' was here
>>
>
> The solution to this appears to be the following patch:
>
> = BEGIN PATCH ==
> --- contrib/bsnmp/lib/snmpcrypto.c.orig 2011-09-22 17:51:37.0
> -0700
> +++ contrib/bsnmp/lib/snmpcrypto.c2012-01-15 09:49:27.0 -0800
> @@ -366,7 +366,7 @@ snmp_pdu_decrypt(const struct snmp_pdu *
> return (SNMP_CODE_OK);
> }
>
> -int
> +enum snmp_code
> snmp_passwd_to_keys(struct snmp_user *user, char *passwd __unused)
> {
> if (user->auth_proto == SNMP_AUTH_NOAUTH &&
> @@ -378,7 +378,7 @@ snmp_passwd_to_keys(struct snmp_user *us
> return (SNMP_CODE_FAILED);
> }
>
> -int
> +enum snmp_code
> snmp_get_local_keys(struct snmp_user *user, uint8_t *eid __unused,
> uint32_t elen __unused)
> {
>
> == END PATCH ==
>
Then you churn along for some lengthy time (even making it all the way through
clang successfully), but then stop again at usr.sbin/wpa/hostapd (depend)
(output at end).
Probably going to be a patch similar to the libarchive one.
--
Devin
===> usr.sbin/wpa/hostapd (depend)
rm -f .depend
mkdep -f .depend -a-DDRUID -I/usr/src/usr.sbin/wpa/hostapd
-I/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src
-I/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/common
-I/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/crypto
-I/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/l2_packet
-I/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/utils
-DCONFIG_CTRL_IFACE -DCONFIG_CTRL_IFACE_UNIX
-I/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//hostapd
-I/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/drivers
-DCONFIG_DRIVER_BSD -DHOSTAPD -DCONFIG_DRIVER_RADIUS_ACL -DCONFIG_IPV6
-DEAP_TLS_NONE -DINTERNAL_AES -DINTERNAL_SHA1 -DINTERNAL_MD5
-I/usr/src/usr.sbin/wpa/hostapd
-I/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src
-I/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/common
-I/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/crypto
-I/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/l2_packet
-I/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/utils
-DCONFIG_CTRL_IFACE -DCONFIG_CTRL_IFACE_UNIX
/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/ap/accounting.c
/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/crypto/aes-wrap.c
/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/ap/ap_config.c
/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/ap/ap_drv_ops.c
/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/ap/ap_mlme.c
/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/ap/authsrv.c
/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src/eap_common/chap.c
/usr/src/usr.sbin/wpa/hostapd/../../../contrib/wpa//src
Re: ipv6 in FreeBSD 9
On 14/01/2012 18:07, Marco Beishuizen wrote: Hi, In 8.2 ipv6 was enabled by adding ipv6_enable="YES" in rc.conf, and all worked fine. In FreeBSD 9 that changed to ipv6_activate_all_interfaces="YES". But now there are still some error messages at boot time, and ipv6 doesn't seem to work correctly: ... root: /etc/rc: WARNING: $ipv6_firewall_enable is not set properly - see rc.conf(5). root: /etc/rc: WARNING: $ipv6_enable is not set properly - see rc.conf(5). ... I do not use a static IP adress, but DHCP. Wat do I need to do more to enable ipv6? Don't use ipv6, but reading above: Did you replace ipv6_enable with ipv6_activate_all_interfaces? because the error seems to tell you that you must keep ipv6_enable Or, maybe there was an error with mergemaster? old scripts, new kernel variables? BR, Erik -- M: +34 666 334 818 T: +34 915 211 157 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: buildworld -DWITHOUT_OPENSSL fails at (lib/libbsnmp/libbsnmp (all)) (was: lib/libarchive (depend))
On Jan 13, 2012, at 7:28 PM, Devin Teske wrote:
> Trying to buildworld in RELENG_9 with -DWITHOUT_OPENSSL and getting failures.
>
> First failure we encountered required the following patch to get past
> "lib/libarchive (depend)"...
>
>
>>
>> --- lib/libarchive/config_freebsd.h.orig 2012-01-05 03:44:55.0
>> -0800
>> +++ lib/libarchive/config_freebsd.h 2012-01-13 18:43:46.0 -0800
>> @@ -176,9 +176,4 @@
>> #define ARCHIVE_HASH_SHA256_OPENSSL 1
>> #define ARCHIVE_HASH_SHA384_OPENSSL 1
>> #define ARCHIVE_HASH_SHA512_OPENSSL 1
>> -#else
>> -#define ARCHIVE_HASH_MD5_LIBC 1
>> -#define ARCHIVE_HASH_SHA1_LIBC 1
>> -#define ARCHIVE_HASH_SHA256_LIBC 1
>> -#define ARCHIVE_HASH_SHA512_LIBC 1
>> #endif
>>
>> The above patch allowed the mkdep to succeed and later-compilation in the
>> same directory succeeded (yay).
>
> However, you don't get far before the next error.
>
> Making all in lib/libbsnmp/libbsnmp with -DWITHOUT_OPENSSL...
>
> cc -I/usr/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib -DHAVE_ERR_H
> -DHAVE_GETADDRINFO -DHAVE_STRLCPY -DHAVE_STDINT_H -DHAVE_INTTYPES_H
> -DQUADFMT='"llu"' -DQUADXFMT='"llx"' -std=gnu99 -fstack-protector
> -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter
> -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type
> -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align
> -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls
> -Wold-style-definition -Wno-pointer-sign -c
> /usr/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib/snmpcrypto.c
> /usr/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib/snmpcrypto.c:371:
> error: conflicting types for 'snmp_passwd_to_keys'
> /usr/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib/snmp.h:273: error:
> previous declaration of 'snmp_passwd_to_keys' was here
> /usr/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib/snmpcrypto.c:384:
> error: conflicting types for 'snmp_get_local_keys'
> /usr/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib/snmp.h:274: error:
> previous declaration of 'snmp_get_local_keys' was here
>
The solution to this appears to be the following patch:
= BEGIN PATCH ==
--- contrib/bsnmp/lib/snmpcrypto.c.orig 2011-09-22 17:51:37.0 -0700
+++ contrib/bsnmp/lib/snmpcrypto.c 2012-01-15 09:49:27.0 -0800
@@ -366,7 +366,7 @@ snmp_pdu_decrypt(const struct snmp_pdu *
return (SNMP_CODE_OK);
}
-int
+enum snmp_code
snmp_passwd_to_keys(struct snmp_user *user, char *passwd __unused)
{
if (user->auth_proto == SNMP_AUTH_NOAUTH &&
@@ -378,7 +378,7 @@ snmp_passwd_to_keys(struct snmp_user *us
return (SNMP_CODE_FAILED);
}
-int
+enum snmp_code
snmp_get_local_keys(struct snmp_user *user, uint8_t *eid __unused,
uint32_t elen __unused)
{
== END PATCH ==
I'll file a PR later (still trying to get a successful build first).
--
Devin
_
The information contained in this message is proprietary and/or confidential.
If you are not the intended recipient, please: (i) delete the message and all
copies; (ii) do not disclose, distribute or use the message in any manner; and
(iii) notify the sender immediately. In addition, please be aware that any
message addressed to our domain is subject to archiving and review by persons
other than the intended recipient. Thank you.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: database apps that ignore sockets? [was: Solution: mysqld fails to run, can't create/find mysql.sock]
On 15/01/2012 17:50, Paul Beard wrote: > The app configurations are not this granular: hostname and port are > configured but there is nothing that makes clear that IF you specify > localhost, you WILL BE using a domain socket which MUST BE > /tmp/mysql.sock and IF you move it or your distribution prefers some > other location you MAY NOT use localhost as you are now using a TCP > socket which shouldn't require a hostname but because of the way the > app is written, it does. You can specify an alternate socket location in your connection parameters. For the command line client, it is: mysql -S /var/run/mysql/sock This doesn't help if you say 'mysql -h localhost' and get diverted to use the default socket though -- in that case you can have a .my.cnf file containing (inter-alia) [client] socket = /var/run/mysql/sock For the various language APIs, you generally need to specify a DSN string -- usually this looks something like mysql:database=$database;host=$hostname;port=$port but for a socket connection you could say instead: mysql:database=$database;mysql_socket=/var/run/mysql/sock ... assuming that whoever wrote the application you're using made it sufficiently flexible as to be able to accept something like that. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: Portmanager Status Report Gone
--As of January 15, 2012 12:25:47 PM -0500, Jerry is alleged to have said: Well, you might try and deinstall and then reinstall "portmanager". Perhaps something got corrupted, although I don't know why that might have happened. No joy. Worth a try though. ;) My suspicion is that it's a permissions issue someplace, somehow: I was trying portmaster in it's 'run as wheel, sudo to root when needed' mode, and it kept throwing permissions errors at me which I fixed for a while. (Before reverting to just running it as root.) Of course, I'm running *portmanager* as root, so... (Both under sudo, and from root's cron.) I have "BATCH=yes" set in the "/etc/make.conf" file to avoid receiving those annoying "config screens." Of course that does require you to insure that your ports are configured the way you want them prior to updating them. I don't find it a problem; however, others might. Interesting. I'll keep that in mind. Something to take a look at once I've gotten this solved. ;) By the way, how do you update your ports tree? Perhaps something got corrupted there. I use portsnap myself, so you could use it to just create a new tree thereby over writing the old one. Just a thought. I have csup set to run once a week in cron. I don't think that corrupted anything: `portmanager -s -y` ran fine before I ran portmaster, and I didn't update the tree in between. But blowing away the tree and re-creating it is starting to sound like something worth a try. Daniel T. Staal --- This email copyright the author. Unless otherwise noted, you are expressly allowed to retransmit, quote, or otherwise use the contents for non-commercial purposes. This copyright will expire 5 years after the author's death, or in 30 years, whichever is longer, unless such a period is in excess of local copyright law. --- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: database apps that ignore sockets? [was: Solution: mysqld fails to run, can't create/find mysql.sock]
On 15/01/2012 17:20, Chuck Swiger wrote: > If you specify a hostname and port via "--host=localhost > --port=3306", then you are describing a TCP socket. There is no > pathname involved. You could connect regardless of where mysqld is > putting the socket. Some MySQL clients will gratuitously change a connection attempt to localhost to use the /tmp/mysql.sock unix domain socket because it does perform a bit faster, and it seems they don't expect their users to just ask for a socket connection explicitly. You can test this fairly simply: set up your server with 'skip-networking' temporarily and try making client connections to it. Of course, for some language API's there's no option but to use a network socket -- Java being a case in point -- but that's the exception rather than the rule. To force the command line mysql(1) client to use a network connection to localhost you need to use the --protocol=TCP argument Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: 9.0 buildworld problems
On 14.01.2012 17:39, Joshua Isom wrote: Run `make -DNO_CLEAN buildworld`. Because you used -j6, there's no way to know what went wrong without a full log, and even with a full log it'll be a pain. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org" It appears to be the following lines in make.conf: SENDMAIL_CFLAGS=-I/usr/local/include/sasl -DSASL SENDMAIL_LDADD=-lsasl2 /usr/src/lib/libmilter/../../contrib/sendmail/src/sendmail.h:142:20: error: sasl.h: No such file or directory /usr/src/lib/libmilter/../../contrib/sendmail/src/sendmail.h:143:24: error: saslutil.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /usr/src/lib/libmilter. *** Error code 1 Stop in /usr/src/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. The system I was testing the upgrade process on of course already had cyrus-sasl and cyrus-sasl-salsauthd already installed. I am still waiting to see if the buildworld completes without those to lines. If it does, I will install the cyrus-sasl ports add the lines back in and rerun the buildworld. -- Thanks, Dean E. Weimer dwei...@dweimer.net http://www.dweimer.net/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: database apps that ignore sockets? [was: Solution: mysqld fails to run, can't create/find mysql.sock]
On Jan 15, 2012, at 9:20 AM, Chuck Swiger wrote: > You're confusing two things which are different. At the risk of boring everyone on this list, I think I understand it as far as I need to: I am not the developer of the app(s) that seem to generate this issue. > If you specify a path via "--socket=/tmp/mysqld.sock", you are describing a > UNIX domain socket. While you can also specify "--host=localhost", that > would be ignored because it it implicit. If you change where the socket > lives in mysqld config or CLI options, you need to change where the clients > look for the socket as well. > > If you specify a hostname and port via "--host=localhost --port=3306", then > you are describing a TCP socket. There is no pathname involved. You could > connect regardless of where mysqld is putting the socket. If I gave the impression I didn't understand this, my mistake. The app configurations are not this granular: hostname and port are configured but there is nothing that makes clear that IF you specify localhost, you WILL BE using a domain socket which MUST BE /tmp/mysql.sock and IF you move it or your distribution prefers some other location you MAY NOT use localhost as you are now using a TCP socket which shouldn't require a hostname but because of the way the app is written, it does. Put another way, if you specify localhost, the port is ignored: I just tested this by setting the port to with a symlink to the socket placed in /tmp. It worked fine. If you change the location of the socket, you MUST use a TCP socket which mean identifying the host by name, not as localhost, even if it is localhost. There is no way to specify the location of the domain socket. It must be in /tmp. Note I am not arguing that the use of localhost requires a named domain socket, in UNIX, just that it does in this app. I learned a couple of things here. I hope I can make them clear to the people who need 'em. -- Paul Beard Are you trying to win an argument or solve a problem?
Re: Question on select() : why am I getting absurd output ?
Sometimes I do wonder how much stupid I can be.
Thanks
MJ
On 15-Jan-12 22:49, ss griffon wrote:
On Sun, Jan 15, 2012 at 8:48 AM, Manish Jain wrote:
Hi All,
I was trying to write a small demo code using the select() system call. Here
are the sources :
#include
#include
#include
#include
#include
#include
int nice_child(int * fd, int * fd_close)
{
close(fd[0]);
close(fd_close[0]);
close(fd_close[1]);
char buffer[32];
while (1)
{
sleep(3);
strcpy(buffer, "I love my wife !");
write(fd[1], buffer, strlen(buffer) + 1);
}
return 0;
}
int naughty_child(int * fd, int * fd_close)
{
close(fd[0]);
close(fd_close[0]);
close(fd_close[1]);
char buffer[32];
while (1)
{
sleep(4);
strcpy(buffer, "I love your wife !");
write(fd[1], buffer, strlen(buffer) + 1);
}
return 0;
}
int main()
{
int fd_nice[2];
int fd_naughty[2];
pipe(fd_nice);
pipe(fd_naughty);
if (fork() == 0)
{
return nice_child(fd_nice, fd_naughty);
}
else
{
if (fork() == 0)
{
return naughty_child(fd_naughty, fd_nice);
}
}
close(fd_nice[1]);
close(fd_naughty[1]);
fd_set fdset;
char buffer[64];
int fd = (*fd_naughty> *fd_nice) ? *fd_naughty : *fd_nice;
FD_ZERO(&fdset);
FD_SET(fd_nice[0],&fdset);
FD_SET(fd_naughty[0],&fdset);
while (1)
{
int result = select(fd + 1,&fdset, 0, 0, 0);
assert(result> 0);
if (FD_ISSET(fd_nice[0],&fdset))
{
int result = read(fd, buffer, sizeof(buffer));
buffer[result] = 0;
std::cout<< "Nice child sent : "<< buffer<<
std::endl;
}
if (FD_ISSET(fd_naughty[0],&fdset))
{
int result = read(fd, buffer, sizeof(buffer));
buffer[result] = 0;
std::cout<< "Naughty child sent : "<< buffer<<
std::endl;
}
}
return 0;
}
I was expecting the output to be like :
Nice child sent : I love my wife !
Naughty child sent : I love your wife !
Nice child sent : I love my wife !
But what I actually get is :
Nice child sent : I love your wife !
Nice child sent : I love your wife !
Nice child sent : I love your wife !
Nice child sent : I love your wife !
Nice child sent : I love your wife !
Nice child sent : I love your wife !
Can somebody throw some light on what might be wrong ?
Thank you&
Regards
Manish Jain
invalid.poin...@gmail.com
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
It looks like you are always reading from the same file descriptor
'fd'. Instead you should read from fd_naughty[0] or fd_nice[0] based
on your FD_ISSET checks. Also, don't forget to wait() for your child
processes.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Portmanager Status Report Gone
On Sun, 15 Jan 2012 11:48:55 -0500 Daniel Staal articulated: Well, you might try and deinstall and then reinstall "portmanager". Perhaps something got corrupted, although I don't know why that might have happened. I have "BATCH=yes" set in the "/etc/make.conf" file to avoid receiving those annoying "config screens." Of course that does require you to insure that your ports are configured the way you want them prior to updating them. I don't find it a problem; however, others might. By the way, how do you update your ports tree? Perhaps something got corrupted there. I use portsnap myself, so you could use it to just create a new tree thereby over writing the old one. Just a thought. -- Jerry ♔ Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ Psychiatrists say that one out of four people are mentally ill. Check three friends. If they're OK, you're it. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: database apps that ignore sockets? [was: Solution: mysqld fails to run, can't create/find mysql.sock]
On Jan 15, 2012, at 8:43 AM, Paul Beard wrote: > Useful clarification but a UNIX domain socket sounds less like networking and > more like interprocess communication, i.e., something explicitly tied to a > single host. Yes, that's right. > There is a "skip networking" option for MySQL that references the domain > socket for use by processes on the same host but doesn't accept connections > on port 3306. That also sounds familiar. > There's no indication that using localhost will default to a domain socket > which will explicitly be looked for in /tmp and if you put it anywhere else, > you must specify a hostname to access the TCP socket. You're confusing two things which are different. If you specify a path via "--socket=/tmp/mysqld.sock", you are describing a UNIX domain socket. While you can also specify "--host=localhost", that would be ignored because it it implicit. If you change where the socket lives in mysqld config or CLI options, you need to change where the clients look for the socket as well. If you specify a hostname and port via "--host=localhost --port=3306", then you are describing a TCP socket. There is no pathname involved. You could connect regardless of where mysqld is putting the socket. > I'll quote your definition in the bug report as it seems crystal clear. I would have said that the documentation seem clear as well: http://dev.mysql.com/doc/refman/5.5/en/multiple-server-clients.html http://dev.mysql.com/doc/refman/5.5/en/multiple-unix-servers.html ...but there's evidently some confusing aspect. Regards, -- -Chuck ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Portmanager Status Report Gone
--As of January 15, 2012 10:33:32 AM -0500, Jerry is alleged to have said: Exactly how are you invoking "portmanager"? Usually, just give it it the "-s" flag will get you a list of port and there status as you probably know. Yep. I have that in a weekly cron command, so I know what's out of date. ;) Basically, any way I invoke portmanager is showing the problem: If I invoke with -s, the status doesn't show. If I invoke with -u, it doesn't upgrade anything. Either way the result is the same: It gathers all the data on the ports (at least to 1), and then prints the header for the next section and quits, without actually doing anything. If you just want to update everything before updating FreeBSD itself, I would suggest running it as: "portmanager -u -l -p -y" Obviously, update your ports tree prior to running that command. At the very least, you will end up with a log file telling you what failed to update properly. The problem is that it's not *getting* to the updating, somehow. It gathers all the info on what it needs to know for the updating, and then stops. No error message, no output, no log, just stop. Running that command (or any other) doesn't result in portmanager actually *doing* anything. Here is the last four lines of output of a `portmanager -u -l`: 1 sane-backends-1.0.22 /graphics/sane-backends Port Status Report The log noted two broken ports (geany-plugins, both times). No other output. I use portmanager myself because it "just works" when other port management tools fail. This has been my experience as well. ;) The one thing I don't like about it is that it tends to need someone to watch it: If a port has changed it's config options, or added a new dependency that I haven't configured before, it will pull up the config screen and wait for input. I'd heard some of the other port management tools went and did that all at the beginning, which would mean I wouldn't have to sit and watch the screen as much. Unfortunatly, they appear to have more annoying behaviors. (portmaster tended to die on the smallest problem, where portmanager would have just logged a failure and gone on.) I'm mostly happy with portmanager. I just want it *back.* Daniel T. Staal --- This email copyright the author. Unless otherwise noted, you are expressly allowed to retransmit, quote, or otherwise use the contents for non-commercial purposes. This copyright will expire 5 years after the author's death, or in 30 years, whichever is longer, unless such a period is in excess of local copyright law. --- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: database apps that ignore sockets? [was: Solution: mysqld fails to run, can't create/find mysql.sock]
On Jan 15, 2012, at 8:17 AM, Chuck Swiger wrote: > Something looking for a network location specified as a host and port (ie, > localhost:3306) is using a TCP socket. Something looking for > /tmp/mysqld.sock is using a UNIX domain socket. > > Changing the path to the UNIX domain socket will have no effect upon the port > used by the TCP socket, or vice versa. > Useful clarification but a UNIX domain socket sounds less like networking and more like interprocess communication, i.e., something explicitly tied to a single host. There is a "skip networking" option for MySQL that references the domain socket for use by processes on the same host but doesn't accept connections on port 3306. There's no indication that using localhost will default to a domain socket which will explicitly be looked for in /tmp and if you put it anywhere else, you must specify a hostname to access the TCP socket. I'll quote your definition in the bug report as it seems crystal clear. -- Paul Beard Are you trying to win an argument or solve a problem?
Question on select() : why am I getting absurd output ?
Hi All,
I was trying to write a small demo code using the select() system call.
Here are the sources :
#include
#include
#include
#include
#include
#include
int nice_child(int * fd, int * fd_close)
{
close(fd[0]);
close(fd_close[0]);
close(fd_close[1]);
char buffer[32];
while (1)
{
sleep(3);
strcpy(buffer, "I love my wife !");
write(fd[1], buffer, strlen(buffer) + 1);
}
return 0;
}
int naughty_child(int * fd, int * fd_close)
{
close(fd[0]);
close(fd_close[0]);
close(fd_close[1]);
char buffer[32];
while (1)
{
sleep(4);
strcpy(buffer, "I love your wife !");
write(fd[1], buffer, strlen(buffer) + 1);
}
return 0;
}
int main()
{
int fd_nice[2];
int fd_naughty[2];
pipe(fd_nice);
pipe(fd_naughty);
if (fork() == 0)
{
return nice_child(fd_nice, fd_naughty);
}
else
{
if (fork() == 0)
{
return naughty_child(fd_naughty, fd_nice);
}
}
close(fd_nice[1]);
close(fd_naughty[1]);
fd_set fdset;
char buffer[64];
int fd = (*fd_naughty > *fd_nice) ? *fd_naughty : *fd_nice;
FD_ZERO(&fdset);
FD_SET(fd_nice[0], &fdset);
FD_SET(fd_naughty[0], &fdset);
while (1)
{
int result = select(fd + 1, &fdset, 0, 0, 0);
assert(result > 0);
if (FD_ISSET(fd_nice[0], &fdset))
{
int result = read(fd, buffer, sizeof(buffer));
buffer[result] = 0;
std::cout << "Nice child sent : " << buffer <<
std::endl;
}
if (FD_ISSET(fd_naughty[0], &fdset))
{
int result = read(fd, buffer, sizeof(buffer));
buffer[result] = 0;
std::cout << "Naughty child sent : " << buffer <<
std::endl;
}
}
return 0;
}
I was expecting the output to be like :
Nice child sent : I love my wife !
Naughty child sent : I love your wife !
Nice child sent : I love my wife !
But what I actually get is :
Nice child sent : I love your wife !
Nice child sent : I love your wife !
Nice child sent : I love your wife !
Nice child sent : I love your wife !
Nice child sent : I love your wife !
Nice child sent : I love your wife !
Can somebody throw some light on what might be wrong ?
Thank you &
Regards
Manish Jain
invalid.poin...@gmail.com
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: database apps that ignore sockets? [was: Solution: mysqld fails to run, can't create/find mysql.sock]
On Jan 14, 2012, at 5:18 PM, Paul Beard wrote: > Turns out some applications won't work if you move the socket if they are > configured to access localhost. Seems like a misunderstanding of networking > if you can specify a port number in a configuration file but the application > looks to the filesystem for the socket. There is no way to specify a file > location so it seems doomed to fail — as it did. Something looking for a network location specified as a host and port (ie, localhost:3306) is using a TCP socket. Something looking for /tmp/mysqld.sock is using a UNIX domain socket. Changing the path to the UNIX domain socket will have no effect upon the port used by the TCP socket, or vice versa. Regards, -- -Chuck ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Portmanager Status Report Gone
On Sun, 15 Jan 2012 10:09:06 -0500 Daniel Staal articulated: > I was trying out portmaster to see if it worked better than my > current tool of choice for keeping my ports up to date (portmanager) > and when I went back to portmanager I can no longer get it to give me > a 'Port Status Report', or to update anything. It just collects the > installed port data, and stops. > > Any ideas on what I may have messed up? I'd like to upgrade my ports > to the latest versions before upgrading to 9.0 (and I'd want > portmanager working afterwards to help me fix any port-related > problems that come up.) I'm on 8.2. Exactly how are you invoking "portmanager"? Usually, just give it it the "-s" flag will get you a list of port and there status as you probably know. If you just want to update everything before updating FreeBSD itself, I would suggest running it as: "portmanager -u -l -p -y" Obviously, update your ports tree prior to running that command. At the very least, you will end up with a log file telling you what failed to update properly. I use portmanager myself because it "just works" when other port management tools fail. -- Jerry ♔ Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Disable auto_linklocal
Hello, I like to disable linklocal IPv6 addresses on my host, running FreeBSD 9.0-RC3. I already set net.inet6.ip6.auto_linklocal in /etc/sysctl.conf. # sysctl net.inet6.ip6.auto_linklocal net.inet6.ip6.auto_linklocal: 0 Even after a reboot, this does not seem to have any effect. Here is the config on one interface: % ifconfig em3 em3: flags=8843 metric 0 mtu 1500 options=219b ether 00:00:24:ce:69:ef inet 172.25.129.1 netmask 0xff00 broadcast 172.25.129.255 inet6 fe80::200:24ff:fece:69ef%em3 prefixlen 64 scopeid 0xc inet6 2001:610::::1 prefixlen 64 nd6 options=21 media: Ethernet autoselect (1000baseT ) status: active Did I overlook something? Is there perhaps a per-interface option I need to configure in /etc/rc.conf? The link-local addresses don't really harm, but I found them confusing, as the host is running as a router, and rtadv announces the link-local address by default. Thanks for any help, Freek ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: SSD for ZIL suggestions?
--As of January 13, 2012 9:40:58 PM -0600, Rob is alleged to have said: I'm looking at getting a couple of SSDs to act as ZIL drives on FreeBSD 8/9 systems. Are there any recommended drives? Rob --As for the rest, it is mine. I remember that Intel released a line of SSDs that looked ideal for this, but I can't recall which one it was... For a ZIL, write/IOP speed and endurance are primary considerations. Size is not: The ZIL will never need more space than 1/2 the RAM of the box, IIRC. Anything more than that is just wasted space. Daniel T. Staal --- This email copyright the author. Unless otherwise noted, you are expressly allowed to retransmit, quote, or otherwise use the contents for non-commercial purposes. This copyright will expire 5 years after the author's death, or in 30 years, whichever is longer, unless such a period is in excess of local copyright law. --- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Portmanager Status Report Gone
I was trying out portmaster to see if it worked better than my current tool of choice for keeping my ports up to date (portmanager) and when I went back to portmanager I can no longer get it to give me a 'Port Status Report', or to update anything. It just collects the installed port data, and stops. Any ideas on what I may have messed up? I'd like to upgrade my ports to the latest versions before upgrading to 9.0 (and I'd want portmanager working afterwards to help me fix any port-related problems that come up.) I'm on 8.2. Daniel T. Staal --- This email copyright the author. Unless otherwise noted, you are expressly allowed to retransmit, quote, or otherwise use the contents for non-commercial purposes. This copyright will expire 5 years after the author's death, or in 30 years, whichever is longer, unless such a period is in excess of local copyright law. --- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Problem with ntfs and fusesf since upgrade to 9.0
On 15/01/12 at 01:18pm, Patrick Lamaiziere wrote: > Le Sun, 15 Jan 2012 10:01:04 +, > Dave Morgan a écrit : > > > Hi, > > Hello, > > > After upgrading from 8.2 to 9.0 I get the following and I am unable > > to access my external ntfs usb drive. > > > > KLD fuse.ko: depends on kernel - not available or version mismatch > > kldload: can't load /usr/local/modules/fuse.ko: File exists > > > > All ports were rebuilt with "portupgrade -af" and the sources do > > match the kernel. > > > > Have I done something wrong or is this a known problem or bug? > > It works for me (c). So I guess you have made something wrong. > Double check that the source / kernel are uptodate and are the > same as the release (ie cvsup RELENG_9_0). > > here (but with a hand built kernel) > > $ kldstat > Id Refs AddressSize Name > 1 44 0x8020 11cda30 kernel > ... > 131 0x8275a000 a96b fuse.ko > > $ uname -a > FreeBSD roxette.lamaiziere.net 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Sat > Jan 7 17:18:15 CET 2012 > patr...@roxette.lamaiziere.net:/usr/obj/usr/src/sys/ROXETTE amd64 > > Regards. Thanks that fixed it. I had tag=RELENG_9 changing it to tag=RELENG_9_0 is what I needed to do. -- Dave. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Probable Hardware Failure
On 14 Jan 2012 at 16:12, Doug Hardie wrote: > I have a pretty old desktop that has been around quite awhile. It has > started periodic crashes. No log messages. However, the core status > files all show "double fault". I am confident this is a hardware > issue, but is there any easy way to determine if its power or memory > related? Those are the primary candidates although memory is also > possible. We really need to replace the entire unit, but that might > be a bit more salable if I can present convincing evidence of the > cause of the problem. > Doug. First check the Power Supply voltages are correct, and not too noisy. You'll need a good DMM, and 'scope for that. Then, Visually examine the motherboard. Are any of the round can electrolytic cap's "Bulging" at the top, or showing some brown or green gunk leaking out from where they sit on the board. Likewise, it's often worth checking the low voltage caps in the PSU too. CAUTION! Lots of volts exist in places inside them, take care, leave it a few mins after unplugging before taking it apart. If so, it's not uncommon, you'll need to re-cap the Mobo, and or the PSU. Chances are, it's just one particular make/type that has failed, so if the others look OK, just change the failed ones. Get the same value and voltage, but if you can from a reputable manufaturer, Panasonic or some such. NOTE! It's not uncommon either, for some parts to be installed at manufature the wrong way round. It's amazing they last as long as they do before letting go. Also, at least one Mobo maker had the wrong polarity markings on the board. In those cases, you'll need to "buzz out" the associated power rail, comparing the polarity of the suspect part, with it's copanions on the same power rail. For some common Mobo's, if you google the model number, you'll find websites selling complete re-cap kits, or offering an exchange service. This is A LOT more common, than failing RAM, but can present itself in many and varied ways, from corrupted display's, to systems that wont boot. Laptops are not immune to this either. Also, Hard Drives can "go funny" with age, not failing as such, but the surface getting corrupted so that the drives own logic cant always unscramble the mess to the OS's satisfaction. Then, there is the situation (I had one recently) where a failing PSU, caused Hard Drive data corruption. Mr Gibson's product "Spinrite" is the tool to use to fix that (and it did!) Not free, but more than worth the weight of a CD, Floppy or USB stick in Gold! But you'll need to make sure the Mobo and everything else is OK. It also works on Floppy drives, if you "Just HAVE" to recover that data. If you have a fleet of machines, you should have your own copy. No affiliation, just a more than happy long term owner/user of that tool. (www.grc.com) I've resurected more than one "Sick" PC by following some or all of the above, there again, I can wield a soldering iron with the best of them, and have the test gear to hand to fault find these things, and a source of parts. But it saves a shed load of money if you can afford the time to do it... Hope something helps. Best Regards. Dave B. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
update from 8.2 ZFS on root to 9.0
Does anybody already did a *binary* update (w/ freebsd-update) from a zfs on root freebsd-8.2-RELEASE to a new freebsd-9.0-RELEASE zfs on root system? Did all went well? I know the procedure (freebsd-update, recompile all ports, finish freebsd-update). Succes stories please.. ;-) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: upgrade from 8.2 to 9.0
Op 14-1-2012 17:04, Mike Clarke schreef: On Saturday 14 January 2012, Dick Hoogendijk wrote: I had not heard of this project before. Sounds very nice if it works. Manging BE's is one of the main things I miss in the FreeBSD ZFS support. Coming from (open)Solaris this was quite a disappointment. BE's rock! Yes, it's working fine here. [...] Thank you very much for giving these examples. Sounds really nice. Have not tried it yet however. Still feel it's a pity FreeBSD did not incorporate the creation and managing of BE's within the system. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Problem with ntfs and fusesf since upgrade to 9.0
Le Sun, 15 Jan 2012 10:01:04 +, Dave Morgan a écrit : > Hi, Hello, > After upgrading from 8.2 to 9.0 I get the following and I am unable > to access my external ntfs usb drive. > > KLD fuse.ko: depends on kernel - not available or version mismatch > kldload: can't load /usr/local/modules/fuse.ko: File exists > > All ports were rebuilt with "portupgrade -af" and the sources do > match the kernel. > > Have I done something wrong or is this a known problem or bug? It works for me (c). So I guess you have made something wrong. Double check that the source / kernel are uptodate and are the same as the release (ie cvsup RELENG_9_0). here (but with a hand built kernel) $ kldstat Id Refs AddressSize Name 1 44 0x8020 11cda30 kernel ... 131 0x8275a000 a96b fuse.ko $ uname -a FreeBSD roxette.lamaiziere.net 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Sat Jan 7 17:18:15 CET 2012 patr...@roxette.lamaiziere.net:/usr/obj/usr/src/sys/ROXETTE amd64 Regards. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Problem with mfi driver, 9.0-RELEASE
Johan Hendriks schreef: james schreef: I transferred a PERC5/i controller to my NAS system, which is using a Sapphire mini-ITX board with an AMD M350 CPU. It seems the card is detected but driver initialisation fails: mfi0: mem 0xd000-0xd000,0xfea0-0xfea1 irq 96 at device 14.0 on pci2 mfi0: Megaraid SAS driver Ver 3.00 mfi0: 10970 (379716350s/0x0020/info) - Hibernate command received from host mfi0: 10971 (boot + 0s/0x0020/info) - Firmware initialization started (PCI ID 0015/1028/1f02/1028) mfi0: 10972 (boot + 0s/0x0020/info) - Firmware version 1.03.40-0232 mfi0: 10973 (boot + 0s/0x0020/info) - Firmware initialization started (PCI ID 0015/1028/1f02/1028) ... mfi0: 11056 (boot + 29s/0x0002/info) - Inserted: PD 00(e0/s0) Info: enclPd=, scsiType=0, portMap=01, sasAddr=5000c546b6d5, mfi0: 11057 (boot + 29s/0x0002/info) - Inserted: PD 01(e0/s1) mfi0: 11058 (boot + 29s/0x0002/info) - Inserted: PD 01(e0/s1) Info: enclPd=, scsiType=0, portMap=02, sasAddr=5000c546b8cd, mfi0: Cannot allocate interrupt device_attach: mfi0 attach returned 22 This would seem to be similar to discussions in November which eventually led to JHB committing change in r227580 (and perhaps earlier). I have downloaded the sources for 9.0-RELEASE and it looks like this commit did not get back-ported to the release branch. I'm a bit of a noob with FreeBSD. The instructions for tracking FreeBSD-STABLE seem a bit scary. Is that the only way that I would get the necessary fixes for the mfi driver? (Indeed, would I get those on FreeBSD stable?) James ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org" If you do not want to use stable, you could try to import the diff to your release src yourself. The only change then is the mfi driver, the rest is just release. But stable is not that bad to run, i know many people that run a stable release, just for this kind of things. Many people runs 8.2 Stable for the latest ZFS version. regards Johan Sorry replying to myself. Here you can download the raw diff at the end of the page. http://freshbsd.org/commit/freebsd/r227580 Well here is the link http://freshbsd.org/commit/freebsd/r227580/diff.txt So you can patch your own source. I do not know if it apply's cleanly, if not, maybe jhb knows why then. regards Johan ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Problem with mfi driver, 9.0-RELEASE
james schreef: I transferred a PERC5/i controller to my NAS system, which is using a Sapphire mini-ITX board with an AMD M350 CPU. It seems the card is detected but driver initialisation fails: mfi0: mem 0xd000-0xd000,0xfea0-0xfea1 irq 96 at device 14.0 on pci2 mfi0: Megaraid SAS driver Ver 3.00 mfi0: 10970 (379716350s/0x0020/info) - Hibernate command received from host mfi0: 10971 (boot + 0s/0x0020/info) - Firmware initialization started (PCI ID 0015/1028/1f02/1028) mfi0: 10972 (boot + 0s/0x0020/info) - Firmware version 1.03.40-0232 mfi0: 10973 (boot + 0s/0x0020/info) - Firmware initialization started (PCI ID 0015/1028/1f02/1028) ... mfi0: 11056 (boot + 29s/0x0002/info) - Inserted: PD 00(e0/s0) Info: enclPd=, scsiType=0, portMap=01, sasAddr=5000c546b6d5, mfi0: 11057 (boot + 29s/0x0002/info) - Inserted: PD 01(e0/s1) mfi0: 11058 (boot + 29s/0x0002/info) - Inserted: PD 01(e0/s1) Info: enclPd=, scsiType=0, portMap=02, sasAddr=5000c546b8cd, mfi0: Cannot allocate interrupt device_attach: mfi0 attach returned 22 This would seem to be similar to discussions in November which eventually led to JHB committing change in r227580 (and perhaps earlier). I have downloaded the sources for 9.0-RELEASE and it looks like this commit did not get back-ported to the release branch. I'm a bit of a noob with FreeBSD. The instructions for tracking FreeBSD-STABLE seem a bit scary. Is that the only way that I would get the necessary fixes for the mfi driver? (Indeed, would I get those on FreeBSD stable?) James ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org" If you do not want to use stable, you could try to import the diff to your release src yourself. The only change then is the mfi driver, the rest is just release. But stable is not that bad to run, i know many people that run a stable release, just for this kind of things. Many people runs 8.2 Stable for the latest ZFS version. regards Johan ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Problem with ntfs and fusesf since upgrade to 9.0
Hi, After upgrading from 8.2 to 9.0 I get the following and I am unable to access my external ntfs usb drive. KLD fuse.ko: depends on kernel - not available or version mismatch kldload: can't load /usr/local/modules/fuse.ko: File exists All ports were rebuilt with "portupgrade -af" and the sources do match the kernel. Have I done something wrong or is this a known problem or bug? uname -a 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:15:25 UTC 2012 r...@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 -- Dave. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
How much of the manual needs adjustment for 9.0?
I originally installed without selecting sources. The manual says to run sysinstall and do the configuration step to add source distribution and I did that, but it then failed to download the 'sbase' source. I admit I gave up 'fairly quickly' and just downloaded src.txz, but its not clear to me how many of the functions of sysinstall are still supposed to work with a 9.0 release. James ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Problem with mfi driver, 9.0-RELEASE
I transferred a PERC5/i controller to my NAS system, which is using a Sapphire mini-ITX board with an AMD M350 CPU. It seems the card is detected but driver initialisation fails: mfi0: mem 0xd000-0xd000,0xfea0-0xfea1 irq 96 at device 14.0 on pci2 mfi0: Megaraid SAS driver Ver 3.00 mfi0: 10970 (379716350s/0x0020/info) - Hibernate command received from host mfi0: 10971 (boot + 0s/0x0020/info) - Firmware initialization started (PCI ID 0015/1028/1f02/1028) mfi0: 10972 (boot + 0s/0x0020/info) - Firmware version 1.03.40-0232 mfi0: 10973 (boot + 0s/0x0020/info) - Firmware initialization started (PCI ID 0015/1028/1f02/1028) ... mfi0: 11056 (boot + 29s/0x0002/info) - Inserted: PD 00(e0/s0) Info: enclPd=, scsiType=0, portMap=01, sasAddr=5000c546b6d5, mfi0: 11057 (boot + 29s/0x0002/info) - Inserted: PD 01(e0/s1) mfi0: 11058 (boot + 29s/0x0002/info) - Inserted: PD 01(e0/s1) Info: enclPd=, scsiType=0, portMap=02, sasAddr=5000c546b8cd, mfi0: Cannot allocate interrupt device_attach: mfi0 attach returned 22 This would seem to be similar to discussions in November which eventually led to JHB committing change in r227580 (and perhaps earlier). I have downloaded the sources for 9.0-RELEASE and it looks like this commit did not get back-ported to the release branch. I'm a bit of a noob with FreeBSD. The instructions for tracking FreeBSD-STABLE seem a bit scary. Is that the only way that I would get the necessary fixes for the mfi driver? (Indeed, would I get those on FreeBSD stable?) James ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Smartcam (or can you use linux dev driver + program)
Smartcam is an app that let's you use a phone's camera as webcam. You connect you your phone via bluetooth and the program gives you access to the devices cam. It works on most smartphone OS's even Symbian. There is a Linux version and it creates a module for the device and also builds the program: http://sourceforge.net/projects/smartcam/files/smartcam_linux/smartcam_linux_v_1.4.0/ QUESTION Is it even possible to use the Linux dev driver under FreeBSD? Since Smartcam is a 2-part suite: driver and application. If it's not possible to use linuxator, will it be possible to use the source to create a FreeBSD version of the dev driver? I assume the program will be easier to port than the actual driver. Cheers. -- Lyubomir Grigorov (bgalakazam) signature.asc Description: This is a digitally signed message part.
Re: Probable Hardware Failure
On Sat, 14 Jan 2012 16:12:24 -0800 Doug Hardie wrote: > I have a pretty old desktop that has been around quite awhile. It > has started periodic crashes. No log messages. However, the core > status files all show "double fault". I am confident this is a > hardware issue, but is there any easy way to determine if its power > or memory related? Those are the primary candidates although memory > is also possible. We really need to replace the entire unit, but > that might be a bit more salable if I can present convincing evidence > of the cause of the problem. In regards to the RAM, I would strongly suggest memtest86/memtest86+. When you begin seeing odd issues like that, it can be a handy tool to use for a quick RAM check. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
