Re: Port GlusterFS as a GSoC project
On Fri, 26 Apr 2013, Mike Ma wrote: Hi there, I'm now a student and trying to get involved in GSoC this year. I found the proposal of about GlusterFS in the idea list wiki page very interesting to me, possibly it will be porting from NetBSD implementation. As I'm quite distant from idea owner, he also suggested me to try to find some folks that are physically closer to me to help mentoring. So I'm writing to ask if there's any folk in Europe is interested helping me with the project in any way, it could be easier for communication and discussion. Thanks a lot. [...] I am very interested in this effort and could help with testing and the occassional odd line of code. I wouldn't be of much help for mentoring, though. MfG CoCo ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
How to sabotage 9.*-RELEASE worldbuilds?
Just do this: # echo 'FORMATS="html txt"' >> /etc/make.conf buildworld fails, at the SAME point for ALL 9.*-RELEASE-es: === ===> lib/libauditd (all) ===> lib/libcom_err (all) gzip -cn /usr/src/lib/libcom_err/../../contrib/com_err/com_err.3 > com_err.3.gz ===> lib/libcom_err/doc (all) Graph cycles through com_err.'html make: don't know how to make txt'. Stop *** Error code 2 Stop in /usr/src/lib/libcom_err. *** 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. === If you aren't in a mood, to wait for a buildworld to fail, you can see errors faster: # cd /usr/src && make cleandir > /dev/null --- "/usr/src/share/mk/bsd.info.mk", line 140: warning: duplicate script for target "txt".gz" ignored ... --- For /usr/doc builds, in /etc/make.conf, I have: === # For port textproc/docproj WITH_JADETEX=YES DOC_LANG="en_US.ISO8859-1" FORMATS="html txt" === Domagoj Smolčić ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: How to sabotage 9.*-RELEASE worldbuilds?
On 27 Apr 2013 11:09, wrote: > > Just do this: > # echo 'FORMATS="html txt"' >> /etc/make.conf > > buildworld fails, at the SAME point for ALL 9.*-RELEASE-es: > === > ===> lib/libauditd (all) > ===> lib/libcom_err (all) > gzip -cn /usr/src/lib/libcom_err/../../contrib/com_err/com_err.3 > com_err.3.gz > ===> lib/libcom_err/doc (all) > Graph cycles through com_err.'html > > make: don't know how to make txt'. Stop > *** Error code 2 > > Stop in /usr/src/lib/libcom_err. > *** 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. > === > > > If you aren't in a mood, to wait for a buildworld to fail, you can see errors faster: > # cd /usr/src && make cleandir > /dev/null > --- > "/usr/src/share/mk/bsd.info.mk", line 140: warning: duplicate script for target "txt".gz" ignored > ... > --- > > > For /usr/doc builds, in /etc/make.conf, I have: > === > # For port textproc/docproj > WITH_JADETEX=YES > DOC_LANG="en_US.ISO8859-1" > FORMATS="html txt" And yet another example of misunderstanding how quotes in Makefiles breaks things :) If in doubt, leave quotes out! (This only applies to make) Chris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
config(8) -x headscratcher
I'm getting a core dump on 'config -x /boot/kernel/kernel' on 9.1-RELEASE i386.
Assertion failed: (r != '\0' && ("Char present in the configuration "
"string mustn't be equal to 0")), function kernconfdump, file
/usr/src/usr.sbin/config/main.c, line 710.
I have double checked that my config file is sane and does not have
any funny characters anywhere.
The system is i386 9.1-RELEASE r249856. The world and kernel are built
with clang and I'm suspecting that the use of clang has something to
do with this segfault.
Looking at the kernel files I can see one very obvious difference.
This is the 'elfdump -c kernel | grep -A 8 kern_conf' output (what
config -x seems to use for finding out the config file from the kernel
image) for the GENERIC kernel from the stock installation:
sh_name: kern_conf
sh_type: SHT_PROGBITS
sh_flags: SHF_ALLOC
sh_addr: 0xc1039f80
sh_offset: 12820352
sh_size: 3771
sh_link: 0
sh_info: 0
sh_addralign: 32
And this is from the kernel I have built myself using clang and a
custom config file:
sh_name: kern_conf
sh_type: SHT_PROGBITS
sh_flags: SHF_ALLOC
sh_addr: 0xc09aee9c
sh_offset: 5959324
sh_size: 1994
sh_link: 0
sh_info: 0
sh_addralign: 1
The align field looks suspicious, config -x seems to use it to check
for padding but to me it looks like the logic may not work if the
alignment is 1.
This the relevant bit from main.c of config(8)
if (r == '\0' && (size - i) < align)
break;
assert(r != '\0' && ("Char present in the configuration "
"string mustn't be equal to 0"));
fputc(r, stdout);
-Kimmo
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: How to sabotage 9.*-RELEASE worldbuilds?
> > Just do this: > > # echo 'FORMATS="html txt"' >> /etc/make.conf > > > > buildworld fails, at the SAME point for ALL 9.*-RELEASE-es: > > === > > ===> lib/libauditd (all) > > ===> lib/libcom_err (all) > > gzip -cn /usr/src/lib/libcom_err/../../contrib/com_err/com_err.3 > > com_err.3.gz > > ===> lib/libcom_err/doc (all) > > Graph cycles through com_err.'html > > > > make: don't know how to make txt'. Stop > > *** Error code 2 > > > > Stop in /usr/src/lib/libcom_err. > > *** 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. > > === > > > > > > If you aren't in a mood, to wait for a buildworld to fail, you can see > errors faster: > > # cd /usr/src && make cleandir > /dev/null > > --- > > "/usr/src/share/mk/bsd.info.mk", line 140: warning: duplicate script for > target "txt".gz" ignored > > ... > > --- > > > > > > For /usr/doc builds, in /etc/make.conf, I have: > > === > > # For port textproc/docproj > > WITH_JADETEX=YES > > DOC_LANG="en_US.ISO8859-1" > > FORMATS="html txt" > > And yet another example of misunderstanding how quotes in Makefiles breaks > things :) > > If in doubt, leave quotes out! > > (This only applies to make) > > Chris > I see. So now I've used this: == # For port textproc/docproj WITH_JADETEX=YES DOC_LANG=en_US.ISO8859-1 FORMATS=html txt == buildworld failed again, but with different error: == gzip -cn /usr/src/lib/libbsm/../../contrib/openbsm/man/setauid.2 > setauid.2.gz ===> lib/libauditd (all) ===> lib/libcom_err (all) gzip -cn /usr/src/lib/libcom_err/../../contrib/com_err/com_err.3 > com_err.3.gz ===> lib/libcom_err/doc (all) makeinfo --no-split -I /usr/src/lib/libcom_err/doc -I /usr/src/lib/libcom_err/doc /usr/src/lib/libcom_err/doc/com_err.texinfo - o com_err.info /usr/src/lib/libcom_err/doc/com_err.texinfo:377: warning: unlikely character ( in @var. /usr/src/lib/libcom_err/doc/com_err.texinfo:377: warning: unlikely character ) in @var. /usr/src/lib/libcom_err/doc/com_err.texinfo:384: warning: unlikely character ( in @var. /usr/src/lib/libcom_err/doc/com_err.texinfo:384: warning: unlikely character ) in @var. /usr/src/lib/libcom_err/doc/com_err.texinfo:577: warning: unlikely character ( in @var. /usr/src/lib/libcom_err/doc/com_err.texinfo:577: warning: unlikely character ) in @var. info2html com_err.info info2html: No such file or directory *** [com_err.html] Error code 1 Stop in /usr/src/lib/libcom_err/doc. *** [all] Error code 1 Stop in /usr/src/lib/libcom_err. *** [all] Error code 1 Stop in /usr/src/lib. *** [lib.all__D] Error code 1 Stop in /usr/src. *** [everything] Error code 1 Stop in /usr/src. *** [buildworld] Error code 1 Stop in /usr/src. == However: # cd /usr/src && make cleandir > /dev/null , now doesn't emit any errors. Domagoj ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: config(8) -x headscratcher
On Sat, Apr 27, 2013 at 06:54:11PM +0300, Kimmo Paasiala wrote:
> I'm getting a core dump on 'config -x /boot/kernel/kernel' on 9.1-RELEASE
> i386.
>
> Assertion failed: (r != '\0' && ("Char present in the configuration "
> "string mustn't be equal to 0")), function kernconfdump, file
> /usr/src/usr.sbin/config/main.c, line 710.
>
> I have double checked that my config file is sane and does not have
> any funny characters anywhere.
>
> The system is i386 9.1-RELEASE r249856. The world and kernel are built
> with clang and I'm suspecting that the use of clang has something to
> do with this segfault.
>
> Looking at the kernel files I can see one very obvious difference.
> This is the 'elfdump -c kernel | grep -A 8 kern_conf' output (what
> config -x seems to use for finding out the config file from the kernel
> image) for the GENERIC kernel from the stock installation:
>
> sh_name: kern_conf
> sh_type: SHT_PROGBITS
> sh_flags: SHF_ALLOC
> sh_addr: 0xc1039f80
> sh_offset: 12820352
> sh_size: 3771
> sh_link: 0
> sh_info: 0
> sh_addralign: 32
>
> And this is from the kernel I have built myself using clang and a
> custom config file:
>
> sh_name: kern_conf
> sh_type: SHT_PROGBITS
> sh_flags: SHF_ALLOC
> sh_addr: 0xc09aee9c
> sh_offset: 5959324
> sh_size: 1994
> sh_link: 0
> sh_info: 0
> sh_addralign: 1
>
> The align field looks suspicious, config -x seems to use it to check
> for padding but to me it looks like the logic may not work if the
> alignment is 1.
>
> This the relevant bit from main.c of config(8)
>
Kimmo,
Lets keep discussion on hackers@ only. I do agree with you that config(8)
internal implementation might have its issues.
Can you make your kernel configuration file, faulty kernel image and exact
build instructions available to me?
--
Wojciech A. Koszek
wkos...@freebsd.czest.pl
http://FreeBSD.czest.pl/~wkoszek/
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
review of patches for the gssd that handle getpwXX_r ERANGE return
Hi,
I have attached two patches, which can also be found at:
http://people.freebsd.org/~rmacklem/getpw.patch1 and getpw.patch2
They are almost identical and handle the ERANGE error return from
getpw[nam|uid]_r() when buf[128] isn't large enough.
Is anyone interested in reviewing these? (This has been discussed
some time ago, but the patch was never reviewed. Actually I reviewed
a patch similar to this, but the submitter subsequently requested that
I not use their patch, so I wrote similar ones.)
Thanks in advance for any review, rick
--- usr.sbin/gssd/gssd.c.sav 2013-04-26 20:38:45.0 -0400
+++ usr.sbin/gssd/gssd.c 2013-04-26 20:38:53.0 -0400
@@ -37,6 +37,7 @@ __FBSDID("$FreeBSD: head/usr.sbin/gssd/g
#include
#include
#include
+#include
#ifndef WITHOUT_KERBEROS
#include
#endif
@@ -557,8 +558,11 @@ gssd_pname_to_uid_1_svc(pname_to_uid_arg
{
gss_name_t name = gssd_find_resource(argp->pname);
uid_t uid;
- char buf[128];
+ char buf[1024], *bufp;
struct passwd pwd, *pw;
+ size_t buflen;
+ int error;
+ static size_t buflen_hint = 1024;
memset(result, 0, sizeof(*result));
if (name) {
@@ -567,7 +571,24 @@ gssd_pname_to_uid_1_svc(pname_to_uid_arg
name, argp->mech, &uid);
if (result->major_status == GSS_S_COMPLETE) {
result->uid = uid;
- getpwuid_r(uid, &pwd, buf, sizeof(buf), &pw);
+ buflen = buflen_hint;
+ for (;;) {
+pw = NULL;
+bufp = buf;
+if (buflen > sizeof(buf))
+ bufp = malloc(buflen);
+if (bufp == NULL)
+ break;
+error = getpwuid_r(uid, &pwd, bufp, buflen,
+&pw);
+if (error != ERANGE)
+ break;
+if (buflen > sizeof(buf))
+ free(bufp);
+buflen += 1024;
+if (buflen > buflen_hint)
+ buflen_hint = buflen;
+ }
if (pw) {
int len = NGRPS;
int groups[NGRPS];
@@ -584,6 +605,8 @@ gssd_pname_to_uid_1_svc(pname_to_uid_arg
result->gidlist.gidlist_len = 0;
result->gidlist.gidlist_val = NULL;
}
+ if (bufp != NULL && buflen > sizeof(buf))
+free(bufp);
}
} else {
result->major_status = GSS_S_BAD_NAME;
--- kerberos5/lib/libgssapi_krb5/pname_to_uid.c.sav 2013-04-26 20:37:45.0 -0400
+++ kerberos5/lib/libgssapi_krb5/pname_to_uid.c 2013-04-27 16:25:14.0 -0400
@@ -26,6 +26,7 @@
*/
/* $FreeBSD: head/kerberos5/lib/libgssapi_krb5/pname_to_uid.c 181344 2008-08-06 14:02:05Z dfr $ */
+#include
#include
#include "krb5/gsskrb5_locl.h"
@@ -37,8 +38,12 @@ _gsskrb5_pname_to_uid(OM_uint32 *minor_s
krb5_context context;
krb5_const_principal name = (krb5_const_principal) pname;
krb5_error_code kret;
- char lname[MAXLOGNAME + 1], buf[128];
+ char lname[MAXLOGNAME + 1], buf[1024], *bufp;
struct passwd pwd, *pw;
+ size_t buflen;
+ int error;
+ OM_uint32 ret;
+ static size_t buflen_hint = 1024;
GSSAPI_KRB5_INIT (&context);
@@ -49,11 +54,30 @@ _gsskrb5_pname_to_uid(OM_uint32 *minor_s
}
*minor_status = 0;
- getpwnam_r(lname, &pwd, buf, sizeof(buf), &pw);
+ buflen = buflen_hint;
+ for (;;) {
+ pw = NULL;
+ bufp = buf;
+ if (buflen > sizeof(buf))
+ bufp = malloc(buflen);
+ if (bufp == NULL)
+ break;
+ error = getpwnam_r(lname, &pwd, bufp, buflen, &pw);
+ if (error != ERANGE)
+ break;
+ if (buflen > sizeof(buf))
+ free(bufp);
+ buflen += 1024;
+ if (buflen > buflen_hint)
+ buflen_hint = buflen;
+ }
if (pw) {
*uidp = pw->pw_uid;
- return (GSS_S_COMPLETE);
+ ret = GSS_S_COMPLETE;
} else {
- return (GSS_S_FAILURE);
+ ret = GSS_S_FAILURE;
}
+ if (bufp != NULL && buflen > sizeof(buf))
+ free(bufp);
+ return (ret);
}
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: config(8) -x headscratcher
On Sat, Apr 27, 2013 at 10:05 PM, Wojciech A. Koszek
wrote:
> On Sat, Apr 27, 2013 at 06:54:11PM +0300, Kimmo Paasiala wrote:
>> I'm getting a core dump on 'config -x /boot/kernel/kernel' on 9.1-RELEASE
>> i386.
>>
>> Assertion failed: (r != '\0' && ("Char present in the configuration "
>> "string mustn't be equal to 0")), function kernconfdump, file
>> /usr/src/usr.sbin/config/main.c, line 710.
>>
>> I have double checked that my config file is sane and does not have
>> any funny characters anywhere.
>>
>> The system is i386 9.1-RELEASE r249856. The world and kernel are built
>> with clang and I'm suspecting that the use of clang has something to
>> do with this segfault.
>>
>> Looking at the kernel files I can see one very obvious difference.
>> This is the 'elfdump -c kernel | grep -A 8 kern_conf' output (what
>> config -x seems to use for finding out the config file from the kernel
>> image) for the GENERIC kernel from the stock installation:
>>
>> sh_name: kern_conf
>> sh_type: SHT_PROGBITS
>> sh_flags: SHF_ALLOC
>> sh_addr: 0xc1039f80
>> sh_offset: 12820352
>> sh_size: 3771
>> sh_link: 0
>> sh_info: 0
>> sh_addralign: 32
>>
>> And this is from the kernel I have built myself using clang and a
>> custom config file:
>>
>> sh_name: kern_conf
>> sh_type: SHT_PROGBITS
>> sh_flags: SHF_ALLOC
>> sh_addr: 0xc09aee9c
>> sh_offset: 5959324
>> sh_size: 1994
>> sh_link: 0
>> sh_info: 0
>> sh_addralign: 1
>>
>> The align field looks suspicious, config -x seems to use it to check
>> for padding but to me it looks like the logic may not work if the
>> alignment is 1.
>>
>> This the relevant bit from main.c of config(8)
>>
>
> Kimmo,
>
> Lets keep discussion on hackers@ only. I do agree with you that config(8)
> internal implementation might have its issues.
>
> Can you make your kernel configuration file, faulty kernel image and exact
> build instructions available to me?
>
> --
> Wojciech A. Koszek
> wkos...@freebsd.czest.pl
> http://FreeBSD.czest.pl/~wkoszek/
The kernel config file:
http://pastebin.com/j0J9NPCi
My /etc/make.conf:
http://pastebin.com/HYudWCA9
And /etc/src.conf:
http://pastebin.com/ZAKq6ABT
I'll see how I can make the kernel image available.
-Kimmo
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: config(8) -x headscratcher
On Sat, Apr 27, 2013 at 11:42 PM, Kimmo Paasiala wrote:
> On Sat, Apr 27, 2013 at 10:05 PM, Wojciech A. Koszek
> wrote:
>> On Sat, Apr 27, 2013 at 06:54:11PM +0300, Kimmo Paasiala wrote:
>>> I'm getting a core dump on 'config -x /boot/kernel/kernel' on 9.1-RELEASE
>>> i386.
>>>
>>> Assertion failed: (r != '\0' && ("Char present in the configuration "
>>> "string mustn't be equal to 0")), function kernconfdump, file
>>> /usr/src/usr.sbin/config/main.c, line 710.
>>>
>>> I have double checked that my config file is sane and does not have
>>> any funny characters anywhere.
>>>
>>> The system is i386 9.1-RELEASE r249856. The world and kernel are built
>>> with clang and I'm suspecting that the use of clang has something to
>>> do with this segfault.
>>>
>>> Looking at the kernel files I can see one very obvious difference.
>>> This is the 'elfdump -c kernel | grep -A 8 kern_conf' output (what
>>> config -x seems to use for finding out the config file from the kernel
>>> image) for the GENERIC kernel from the stock installation:
>>>
>>> sh_name: kern_conf
>>> sh_type: SHT_PROGBITS
>>> sh_flags: SHF_ALLOC
>>> sh_addr: 0xc1039f80
>>> sh_offset: 12820352
>>> sh_size: 3771
>>> sh_link: 0
>>> sh_info: 0
>>> sh_addralign: 32
>>>
>>> And this is from the kernel I have built myself using clang and a
>>> custom config file:
>>>
>>> sh_name: kern_conf
>>> sh_type: SHT_PROGBITS
>>> sh_flags: SHF_ALLOC
>>> sh_addr: 0xc09aee9c
>>> sh_offset: 5959324
>>> sh_size: 1994
>>> sh_link: 0
>>> sh_info: 0
>>> sh_addralign: 1
>>>
>>> The align field looks suspicious, config -x seems to use it to check
>>> for padding but to me it looks like the logic may not work if the
>>> alignment is 1.
>>>
>>> This the relevant bit from main.c of config(8)
>>>
>>
>> Kimmo,
>>
>> Lets keep discussion on hackers@ only. I do agree with you that config(8)
>> internal implementation might have its issues.
>>
>> Can you make your kernel configuration file, faulty kernel image and exact
>> build instructions available to me?
>>
>> --
>> Wojciech A. Koszek
>> wkos...@freebsd.czest.pl
>> http://FreeBSD.czest.pl/~wkoszek/
>
> The kernel config file:
>
> http://pastebin.com/j0J9NPCi
>
> My /etc/make.conf:
>
> http://pastebin.com/HYudWCA9
>
> And /etc/src.conf:
>
> http://pastebin.com/ZAKq6ABT
>
> I'll see how I can make the kernel image available.
>
> -Kimmo
The kernel file:
https://www.dropbox.com/s/07mjk6j4ditbl9r/kernel
-Kimmo
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: config(8) -x headscratcher
On Sat, Apr 27, 2013 at 11:53 PM, Kimmo Paasiala wrote:
> On Sat, Apr 27, 2013 at 11:42 PM, Kimmo Paasiala wrote:
>> On Sat, Apr 27, 2013 at 10:05 PM, Wojciech A. Koszek
>> wrote:
>>> On Sat, Apr 27, 2013 at 06:54:11PM +0300, Kimmo Paasiala wrote:
I'm getting a core dump on 'config -x /boot/kernel/kernel' on 9.1-RELEASE
i386.
Assertion failed: (r != '\0' && ("Char present in the configuration "
"string mustn't be equal to 0")), function kernconfdump, file
/usr/src/usr.sbin/config/main.c, line 710.
I have double checked that my config file is sane and does not have
any funny characters anywhere.
The system is i386 9.1-RELEASE r249856. The world and kernel are built
with clang and I'm suspecting that the use of clang has something to
do with this segfault.
Looking at the kernel files I can see one very obvious difference.
This is the 'elfdump -c kernel | grep -A 8 kern_conf' output (what
config -x seems to use for finding out the config file from the kernel
image) for the GENERIC kernel from the stock installation:
sh_name: kern_conf
sh_type: SHT_PROGBITS
sh_flags: SHF_ALLOC
sh_addr: 0xc1039f80
sh_offset: 12820352
sh_size: 3771
sh_link: 0
sh_info: 0
sh_addralign: 32
And this is from the kernel I have built myself using clang and a
custom config file:
sh_name: kern_conf
sh_type: SHT_PROGBITS
sh_flags: SHF_ALLOC
sh_addr: 0xc09aee9c
sh_offset: 5959324
sh_size: 1994
sh_link: 0
sh_info: 0
sh_addralign: 1
The align field looks suspicious, config -x seems to use it to check
for padding but to me it looks like the logic may not work if the
alignment is 1.
This the relevant bit from main.c of config(8)
>>>
>>> Kimmo,
>>>
>>> Lets keep discussion on hackers@ only. I do agree with you that config(8)
>>> internal implementation might have its issues.
>>>
>>> Can you make your kernel configuration file, faulty kernel image and exact
>>> build instructions available to me?
>>>
>>> --
>>> Wojciech A. Koszek
>>> wkos...@freebsd.czest.pl
>>> http://FreeBSD.czest.pl/~wkoszek/
>>
>> The kernel config file:
>>
>> http://pastebin.com/j0J9NPCi
>>
>> My /etc/make.conf:
>>
>> http://pastebin.com/HYudWCA9
>>
>> And /etc/src.conf:
>>
>> http://pastebin.com/ZAKq6ABT
>>
>> I'll see how I can make the kernel image available.
>>
>> -Kimmo
>
> The kernel file:
>
> https://www.dropbox.com/s/07mjk6j4ditbl9r/kernel
>
> -Kimmo
dmesg(8) output of the system:
http://pastebin.com/hqjsak2n
-Kimmo
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
